太丑了，呜呜。我一直是放在左右的，放下面太占高度了，现在本来就是宽屏主流。

@chutsetien 哇好贵，哭了。

@jswh 以后可以跟孙笑川喝酒。

@yuecheng320 感觉成都的外卖还不如北上广的好吃。😂我是不是太过分了，可能大家还是喜欢出去吃吧。

群名是啥意思？

成都杭州上海北京都居住过，确实还是上海杭州最舒服，成都除了一环，其他地方和小城市没啥区别，街道卫生也不行，东西部还是有巨大差距。

中和那边还有一片城乡结合部未开发的样子，居然也卖这个价，真的不如杭州。

这还真就众包啊！太可怕了。

什么职位的？前端后端客户端？还是什么。

啊为什么 V 站还不支持编辑，我再补充一下吧。其实利用 ContentProvider 配合数据库就挺好，也是最快的实现方式。如果还使用 Room+LiveData 的话，更方便。

个人认为这个还是很难避免 3 次跨进程通信，说白了还是需要某种计数的。要说最优雅，我觉得 ContentProvider 就能实现，主进程 observe 进行计数，其他进程任务完成后分别写标识。
此外，也可以利用类似 Handler 这种有消息队列的机制，但是原生 Handler 不是用来跨进程的，不过有人用 Binder 机制实现了跨进程的 Handler，可以谷歌一下。不过利用跨进程 Handler 的话，一样地需要在主进程计数，也避免不了 3 次跨进程通信。
我能想到的减少进程间通信次数办法，可能还是预估延时机制，你这里是写文件，如果可以提前知道写数据的大小，就能预测一个所有任务都完成的大概时间，到时候就不需要跨进程通信了，主进程在 timeout 之后直接去处理生成的文件，如果发现少了 1 个，就说明还有子进程没完成任务，这时候再降级成跨进程监听吧。这种办法对于及时性要求不高的场景我觉得还是可以的，想法可能不成熟。

话说社保什么的断了是不是很麻烦啊。

说起刷题，我刚开始几天是有激情的，后来就开始玩起来了，哼哼。还是出去面试找找感觉比较好。

上面的附言说得对，而且网上一堆长篇大论的都没说到要点，一会儿扯什么 ThreadLocal 一会儿又是 IPC 。
在 B 线程调用 A 线程的 Handler 来发消息，这特么当然就跨线程了啊，就这么简单。服务端开发里面的消息队列本身也是这个原理，队列对所有线程都是可见的，大家都可以往里面 enqueue 消息。

说实话，现在 Apple 在国内的数据也是在云上贵州，隐私什么的也不存在的，用搜狗用原生都差不多。

太极还是的作者还是牛逼，是个取名鬼才。