与产品经理的故事之因内存引发的惨案

我从这里进去详情页，然后再点多几个页面的话，我整部手机就卡死了，完全动不了啊，你看怎么解决一下啊！”程序猿白眼了一下突然坐在他旁边的产品汪，“之前需求会的时候我就说了这样的操作肯定是有问题的啊，一直点一直点都能进去，无限循环了啊！手机再大的内存都会占用了啊！就是不听，还说这样的操作灰常正常喔！”，“这是很正的一个逻辑啊，有得点击肯定能进去下一个页面了啊...”产品汪又在噼里啪啦的讲着大道理...

“行行行，你就别说了，好吗？下来我先看看是什么原因”，程序猿不耐烦的说，“这就对了嘛，我看好你哦！”产品汪边说边摸了下程序猿的后背...

故事的开始是在一个星期前的需求会上，产品汪跟程序猿在争吵着一个页面逻辑的问题，一个详情页里面含有推荐的帖子或者等东西，点击可以进去另一个页面，并且是无限循环的状态，一直可以进到下一个页面。

程序猿一直坚持这样的逻辑是非常不合理的，然而谁叫程序猿一直都是弱势群体，只能忍气吞声的接受这一残忍的事实，做呗。

PS：其实从产品经理的角度看，这个是非常正常的一个操作，有推荐自然会进去新的页面，返回当然还是回到上一个页面，这是一个非常合乎其理的设计啊。

其实，程序猿心里早就知道是什么原因了，只是之前的时间一直在赶项目，没有时间优化，因为这事还跟产品汪说了几次，说了要有一个空档期给客户端优化，还一直不安排，一直说了要让产品、UI、服务器先行，客户端紧随起步，那样就有更好的空档期进行优化，就是不听，现在好了，终于有时间优化优化了。

PS：敏捷开发，小步快跑！其实很多研发还是很难掌握敏捷开发的，团队必须要有很强的协作和应变能力。

趁这个机会，把整个项目一起优化优化，程序猿心里还是有种变态的开心的。

之前已经大范围的进行了UI的优化了，还会出现卡死的情况，到底是什么原因呢？程序猿陷入沉思...

突然灵光一闪 内存！程序猿欣喜若狂，急忙把手机连接上，打开APP。

先来模拟定位一下到底是哪里出现问题吧，打开Android Profiler（Android Studio 3.0.1自带工具），点点点...一直重复操作进入到新的页面，我去，内存一直在升高啊，并且我退出了当前页面，也没有一点内存回收的迹象啊...

这肯定是内存泄漏了啊！回收不了啊！长期积累肯定会造成APP卡顿，乃至卡死呀，并且会出现崩溃（OOM）啊！

想想为什么会造成内存泄漏了呢？

注：造成内存泄露就是一个对象持有超过自己生命周期以外的对象强引用导致该对象无法被正常回收。

好吧，既然知道问题所在，那就对症下药吧。

首先，要知道在什么情况下会出现内存泄漏，然后，我们才能解决问题。

1、Context

不要对一个Activity Context保持长生命周期的引用。尽量在可以使用ApplicationContext代替Context的地方进行替换，比如一个单例需要传入Context，则可以使用ApplicationContext进行替代，这里就涉及到了不同Context的使用域了。

2、非静态内部类的静态实例

一个类中如果你不能够控制它其中内部类的生命周期（譬如Handler），则尽量使用静态类和弱引用来处理。

3、线程未终止造成的内存泄露

如在Activity中创建了一个Thread，如在退出Activity时线程还在跑，必须要结束线程。

4、对象的注册与反注册没有成对出现

如注册广播接收器、注册观察者等。

5、创建与关闭没有成对出现造成的泄露

如Cursor必须关闭，WebView必须销毁，流等I/O对象必须关闭。

6、Bitmap

在不使用的时候，记得要手动回收Bitmap，在加载Bitmap的时候一定一定要按需加载进行压缩处理并且重复利用，有些时候还可以使用弱引用替代强引用。

7、ListView的优化（这个不是在UI布局优化那里说了吗？）。

8、尽量使用线程池来替代多线程，节约内存并且能节省CPU的使用率。

9、最重要的一点！！！不断优化自己的代码，时刻保持优良的习惯，减少冗余，进行编译打包等优化对齐处理，避免类加载时浪费内存。

不错，思路已经非常清晰了，一步一步来，开始动手检查代码优化代码了。

注：适当时候可以结合一些工具进行持续优化，如LeakCanary，还有AS的工具Android Profiler，Eclipse的DDMS Heap，MAT。

“来来来，我们欢迎Android开发组的猿猿为我们分享一下如何对APP进行调优的，并且给我们介绍一下那些调优工具是怎么使用的，我们一起来好好学习一下！”产品汪拍着手笑嘻嘻的说道。

To Be Continue...

看到此处说明本文对你还是有帮助的，关于“与产品经理的故事之因内存引发的惨案”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！