老司机系列之Android OOM分析

今日 有喜有悲!
写这个文章的时候 skt 已经被msf 打成2:1了 嗯 很开森....

image.png

然而悲剧是 今天2个安卓同事一休假,MMP 生产就出问题了报了个OOM ,吓死老子了。以为要狗带了！
于是我就分析了下今天这个事情的由来
通过本文的阅读 我将授予你

image.png

1 首先来看

image.png

操作步骤
点击购物车 点击结算 然后崩溃掉了
机型是小米note 内存为3g
当时我就觉得不应该啊 因为毕竟3个g 的内存

![Uploading image_401928.png . . .]

接着开始解析开始
---------分析原因 :
1 在内存不足的情况下 创建订单页面失败了 然后系统产生gc
2 在由购物车页面传递参数的情况下 传递了参数给订单页面 然后发送了gc导致订单页面创建失败 所以导致订单页面创建失败导致崩溃(为了验证这个问题 在传递过来的参数我们做了非空校验 然后我现在 在传递成功的情况下 然后将其参数清理掉 然后 看创建是否会成功 如果成功 证明不是这个问题 )验证结果是我不传入参数也会创建成功 只是没有商品而已 所以就不是这个原因
所以说 传递数据为空 即使被回收也不会影响使用 也不会崩溃 导致oom 的原因
3 在log 日子 发现 onResume 方法 发觉是在onResume中 事实上 在onResume 和onPause 中我都没写任何东西 。就是说是在执行 onResume 方法的时候才崩溃的 也就是之前已经创建过一次了 然后 在此进入

思考: 根据onResume 方法的场景 一共3种
1 一个Activity启动另一个Activity: onPause()->onStop(),再返回：onRestart()->onStart()->onResume()
2 程序按back 退出： onPause()->onStop()->onDestory(),再进入：onCreate()->onStart()->onResume();
3 程序按home 退出： onPause()->onStop(),再进入：onRestart()->onStart()->onResume();

--------细节方面的处理 Activity 第一次创建时会调用 onCreate(Bundle)。 该方法用于创建 Activity 的用户界面，创建所需的后台线程，并执行其他的全局初始化。如果能获得Activity以前的状态，就可以将包含此状态的 android.os.Bundle 对象传给onCreate()；否则就传入一个空引用。在调用 onCreate(Bundle)之后。
Android 总是会调用onStop()的;

so! 真相只有一个！
那就是还得继续分析。。。。。。

image.png

--------- 所以在activity 不操作的时候 不外乎2中 退出 不显示 和意外退出的时候 保存下Bundle 在下次进来的时候判断是否为空 如果不为空就加载上次的在onstop 方法中调用保存就行了因为始终会调用onstop 方法。但是 还有一种究极情况.
----------内存不够 android 会托管acvitity 这个时候。
----------在 Activity 被销毁之前会调用 onDestroy()，除非是内存不够， Android 强行终止了Activity 的进程。在这种情况下就不会调用 onDestroy()。如果调用了 onDestroy()，那它就是该 Activity 接收的最终调用。在 onPause()、 onStop()或 onDestroy()返回之后， Android 可以终止托管 Activity 的进程。从 onPause()返回后到调用 onResume()之前， Activity 都处于可终止状态。在 onPause()再次返回之前， Activity 都不会再处于可终止状态.
---------上面的话看起来有点绕。但是其实如果你用心了解过安卓的内核机制就会明白.所有的安卓进程都是用zygote这个进程frok 出来的。所以我们在崩溃日志可以很容易看到这个词。你必须要了解到activity 的原理。我们的activity 都是由activityThead 管理的 所以在托管的时候都是由系统帮我们管理的。
接下来 我们看看什么情况才会android才会触发gc 机制。(http://blog.csdn.net/cscs111/article/details/77558168) 可以看这个文章
自己去阅读这个android的gc 机制 我这边直接说结果了
--------activity 如果要被回收掉 虚拟机要使用的内存必须要超过最大内存的3/4 这个时候才会触发一次 大规模的Gc 回收掉activity 这个时候不管app 是在运行或者是低内存的运行状态下都是如此 剩下的情况就只有activity 在onstop 之后才会触发 所以在activity 在执行了onstop 之后没有被finish 或者x销毁的时候 才会进行回收 之后才会在Activity 的performDestroy 中执行 ondestroy 然后就等待GC回收的处理了。
所以

image.png

于是 .........问题的定位就是 在执行onResume 方法的时候 发生了gc 无解。只能在之前的时候 界面不可见得时候 我们保存在Bundle 中 然后 activity由于系统内存不足时被杀死，在onSaveInstanceState方法里存储数据，onCreate时取出数据。 onSaveInstanceState 的调用是由于android 的framework帮忙调用的 • onSaveInstanceState方法是Activity的生命周期方法，主要用于在Activity销毁时保存一些信息。当Activity只执行onPause方法时（Activity a打开一个透明Activity b）这时候如果App设置的targetVersion大于android3.0则不会执行onSaveInstanceState方法。当Activity执行onStop方法时，通过分析源码我们知道调用onSaveInstanceState的方法直接传值为true，所以都会执行onSaveInstanceState方法。
所以------ 能够解决大部分问题 因为activity 创建的时间很短 所以 很快就会执行了到onResume 如果不执行onstop 就无法保存了。
哎........其实谷歌的思想是没有错误的, 因为你一个app 都占了3/4的内存了, 肯定要回收的啊 主要是 android 其他的app 占了内存 如果你占了3/4 都还不够用 只能说你的app 差。问题是 app 根本没有占到3/4嘛 ！mmp

image.png