回锅肉

昨天第一次开原创评论留言，想不到这么多人捧场，本来想把各位的留言全部都放出来的，但是没想到，居然留言只能放出100条！所以，昨天没看见自己留言的朋友，大概知道自己的名次了~

在前面的菜单中，我上了一道『单应用的多进程架构』，地址如下：

http://mp.weixin.qq.com/s?__biz=MzAxNzMxNzk5OQ==&mid=2649484574&idx=1&sn=0d4fde0fb26940f8d1cd421eed7d2292#rd 大家可以点击原文查看。

这道菜上了之后，有位朋友跟我在后台留言，说有些多进程的问题想和我一起讨论下，双方就这个问题，彼此发表了各自的看法，并达成了高度统一的意见，对增进多进程的理解，起到了极大的促进作用，为维护真理作出了巨大贡献，下面请看详细报道。

疑问1：多进程架构并不能降低被LMK杀的概率

对于这个问题，我认为应该是我没有写清楚，我的意思是，一个App本来需要50M的内存，但是进入一个页面后，需要内存飚升至200M，一旦返回后台，那么这个App就很容易被LMK杀掉，但是，如果改成多进程架构，将很耗内存的那个页面放入另一个进程，那么即使这个进程被Kill，也不会影响App本身的那个进程。

但是，LMK杀进程是基于整个系统的全局策略，使用多进程架构在系统层面上，会带来更多的内存开销，也会加剧内存紧张的问题，反而会提高被杀的可能性。

另外，在Android L之后，系统对杀进程往往会采取以pkg为单位的策略，所以在很多设备上，即使是通过NDK层Fork出来的进程，也会因为App进程被杀而被停止。

疑问2：ROM对进程管理行为的修改

不同的ROM厂商，通常都会对进程管理系统做一定的修改，特别是在Android N之前，实际上很多ROM都已经有了自己的权限系统。而不同ROM的Launcher中的清理进程，甚至都有不同的进程管理策略，有的可能按pid进行管理，有的可能按pkg进行管理。所以，不同的ROM对多进程的清理方式也是不同的。而且，对于原生ROM来说，在安装pkg进行进程管理的时候，不仅仅会以pkg的方式来进行Kill，即使两个进程间产生了反射关系，也有可能会被Kill。

疑问3：ContentProvider的Call方法

对于这个方法，我在那天的文章中说了，是进行跨进程调用的一个非常好用而且方便的方法，但是，这个方法在原生的Android系统中，就存在一个Bug，即调用call方法的进程，有一定几率被杀，虽然概率极低，但一旦发生这个问题，几乎是无法进行分析的。不过，这个问题我暂时还没有遇到，准备通过自动化脚本来测试下具体的Kill概率有多少。

疑问4：系统按照pkg来管理内存，为什么多进程中的崩溃不会影响另一个进程

在多进程中，如果Crash一个进程，而这个进程在内存中是独立的，没有与其它进程建立联系，那么系统之后Kill Crash的进程，也就是说，系统在进行进程管理的时候，是采用的多种策略，不仅仅是只按照pkg或者pid。

疑问5：关于多进程保活

在这一点上，我是极力反对通过多进程来进行所谓的保活的，保活应该是让用户建立对App的依赖，从而来提高留存，而不是通过所谓的后台唤起，这种只会让数据好看的方式。很多比较智障的产品经理，动不动就说，微信、QQ都可以保活呀，对于这种产品，我只想说，你TM能把App做到微信、QQ这种程度，我也能让你活！这些大厂的App的保活，基本上都是靠ROM的白名单，如果ROM想Kill你的进程，那真是可以让你有一万种死法。而大部分的ROM厂商，为了降低自己手机的功耗和内存，基本上对于第三方的App都会采取直接Kill的方式来管理，所以，如果再有产品让你来给应用保活，请直接向它抛出一个异常。

OK，那天的谈话内容基本就是上面这些了，这里再次感谢这位朋友，我已经很久没有从事Framework层的开发了，所以对底层的理解在4.4时代后可能有一些偏差，也有很多新的东西没有来得及了解，多谢他的提醒和指导，才得以把那天的文章中的一些问题重新整理下，这才有了今天的这盘回锅肉！

那么感谢他的帮助，所以给他打个广告，这位朋友是小米的一位高级开发工程师——Gityuan，大家可以去他的博客上看看，有很多非常好的关于Framework的文章，地址如下：

http://gityuan.com/

再次对他表示感谢，也希望大家对文章中的问题提出自己的看法，毕竟现在开通留言了，可以很方便的进行讨论啦~~