OOM处理的一个例子

我使用的工具是Android Studio的Android Profiler，如果打开关闭某个页面时，memory有明显波动，而且波谷两侧的高度基本一致，我们大致可以判断它没有内存泄漏。如下图：

如果发现打开关闭Activity过程中波动不大，那么这个Activity就需要检查是否有内存泄漏的情况出现：

如果memory有明显攀升，那么就必须进行细致的检查了，这个界面可能很快就会oom！

根据需求某界面存在二级按钮，内部ViewPager需要重新装载，于是写了适配器，不停的setAdapter,然后发现虽然没有报异常，但相关对象一直不进行释放，于是改回单适配器，重置view，然后notifyDataSetChanged()刷新，发现无效，百度后找到更新方法，更新后，出现新问题，setOnPageChangedListener失效，于是每次重置，成功实现没有内存泄漏。

有时候，出现第三种也不会oom,因为某个页面比如像淘宝的商品详情，上方有轮播图，下方有滑动的大图，这样的界面会出现内存大幅度增长的情况，这种情况需要观察一段时间，如果突然增长之后不进行增长，返回后立刻释放了那问题不大，这个内存暴增是大图造成的，进行缓存后，轮播图播过一次就不会再增内存，当然最好观察一段时间，另外尝试home键进入后台再重启情况，如果都没有出现持续增长，那就没什么问题了。

学到的oom检查顺序（打开某界面再关闭）：
1.看图，如果图上内存gc后前后差距还是有，那么需要检查Activity层对象是否释放了，这个过程可以gc多次后等待1分钟左右再试。

2.看对象数量和总占用，alloc count和shallow size在打开关闭界面前后中没有变化（使用极其少的页面可以允许少量变化）

3.看Activity对象，你打开关闭的新界面的Activity是重点观察对象，如果此Activity在执行后没有遗留对象（前后alloc count为0，包括内部静态对象），那么可以认为此页面完美释放，否则是有问题的。

4.关于匿名内部类如xx.setOnClickListener(new OnClickListener(){
@Overriade
public void onClick(View v){}
});
这种的可能会造成一定的界面对象残留，建议onDestroy时进行处理xx.setOnClickListener(null);另外，此情况的匿名，静态方式没什么区别，匿名有时还会优于静态方式。总之，要学会用自己的观察得出结论，不要随意相信匿名，内部类就内存泄漏。