Android app被系统kill的场景

什么时候发生

当咱们的app被切到后台的时候，好比用户按下了home键或者切换到了别的应用，总之是咱们的app再也不和用户交互了，这个时候对于咱们的app来讲就是什么事情均可能发生的时候了，由于系统会认为你如今已经不是那么重要了，而和用户正在交互的app的优先级是最高的了，系统会想尽一切办法保证这些app的正常运行，若是这时这些app再申请更多的资源，如内存时，当目前的系统情况没法知足时，系统便会拿后台app开刀，也就是很粗鲁的杀掉整个app的进程，这时你也别期望onDestroy之类的callback会触发，你惟一能期望的就是在切后台的时候onPause、onStop和onSaveInstanceState之类的方法，若是你有状态须要保存那么应该在这些地方处理，不要寄但愿于onDestroy，它会让你失望的，在这个地方用来释放资源仍是ok的。因为系统要杀进程，那么紧接着的问题就是杀哪一个进程，系统为此专门有个模块叫LML（low memory killer），详情能够参考下官方文档，见这里：processes-and-threads。

再次切回app的行为

好比你在离开app的时候，已经打开了3个act，分别是A，B，C，C在最顶端，也就是任务栈顶，A是你的main activity，假设在后台期间被系统杀掉进程了，后面若是用户再次回来（经过recent tasks或者直接点击launcher里的app icon），这时展示在你眼前的将会是重建后的C activity，而不是正常状况下启动的A，系统同时也恢复了当初的任务栈，也就是说栈里的内容仍是A，B，C，这时若是你按下了back键结束了C，那么系统又会帮咱们重建B，A在B结束的时候也是同样的逻辑。这里须要注意一点就是，若是是用户本身杀掉了app，那么再次启动的时候回到的是A而不是C，只要记住是系统的错致使咱们被杀的话，那么再次回到的话系统就有责任帮咱们重建act。关于重建act的详情，能够参考官方文档recreating-activity。切回来以后虽然act是被重建了，但若是你代码里用了单例这样的东西来存一些变量的值，那么很不幸，这时全部单例中的字段全变成默认值了(0, false or null)，由于你想啊，进程都被杀死了啊，全部静态字段等等都没了。stackoverflow有这样的问题，好比这个静态变量变成null了。
目前笔者在维护的代码里有相似的构造，线上也确实出现了些相似的问题，着实蛋疼啊，准备改掉这种单例datakeeper的写法，思路大致有如下几种：

1. 不改现有的单例datakeeper写法，可是增长永久存储支持，好比写到SP中，之后若是发现字段中没值了，那么就去SP中读一发；
2. 数据经过Intent传递，这样也能保证不丢失，由于系统重建act的时候，用的Intent和当时启动act时的Intent是同样的，因此若是你所须要的数据都是以这种方式传递的，那恭喜你，you are safe，你要作的只是从Intent中解析出来你须要的数据；
3. 在onSaveInstanceState中保存数据，在onCreate()/onRestoreInstanceState()中恢复数据；

 

如何模拟

因为系统后台杀进程具备必定的随机性，因此做为开发人员不可能去坐等这种状况发生，咱们得有方法能很快速的复现，具体步骤以下：

                           模拟后台杀进程的步骤

参考 stackoverflow的提问。