自从2015年Google发布16个短视频介绍Android性能优化典范以来，所有的公司对于App的要求就不仅仅停留在用的程度上，更多要考虑到用户的使用体验，App的流畅度；程序猿们写代码的时候也得考虑“我这一段代码会不会引起什么性能方面的问题”。

今天之前，虽然我也曾了解过关于性能优化方面的知识，但是没有自己写过东西，都只能算是纸上谈兵，那么下面就初探下Android的性能优化（如何处理内存泄漏）。Android的内存优化包含了Android的渲染机制，内存与GC，电量优化，网络优化，图片压缩、缓存等，解决内存泄漏，多线程并发etc。

一：内存泄漏的根本原因

内存泄漏的根本原因是长生命周期的对象持有了一个短生命周期对象的引用，尽管短生命周期的对象已经不再需要，但由于长生命周期对象还持有它，导致不能被回收，最终可能会引发OOM的问题。

二：什么样的情况会引发内存泄漏

1.静态变量导致的内存泄漏

2.单例模式引发的内存泄漏，因为单例的静态特性使得其生命周期跟应用的生命周期一样长，如果这个时候单例对象持有外部对象的引用，那么这个外部对象将不能被正常回收，导致内存泄露。比如：

单例

这是一个很普遍的单例模式，因为某些需要要传入一个context，那么这个context的生命周期就很重要了，如果context是getApplicationContext，那么没有问题，如果传入的是activity的context，那么当context对应的activity退出的时候，因为context被单例持有，不会被回收，就会出现内存泄漏。如果修改的话，可以直接在构造函数里面，直接使用mContext = context.getApplicationContext();

3.Handler创建的时候有可能会使用非静态匿名内部类的形式，这样就会隐式持有外部activity的引用。android的消息机制其实Looper线程中的一个无限for循环处理消息，如果当前Activity退出时消息队列中还有未处理的消息或者正在处理消息，而消息队列中的Message持有Handler实例的引用，导致Activity的内存资源无法回收，引发内存泄漏。修改方式：

Handler

也可以考虑使用第三方的weakhandler来解决内存泄漏的问题，比如：https://github.com/badoo/android-weak-handler

4.非静态内部类，上面的例子中，非静态内部类会持有外部类的引用，如果这个类你创建的时候创建的是静态实例，那么就会出现问题（静态实例的生命周期和应用一样长），修改的时候改为静态内部类即可。

5.还有比如newThread或者new AsyncTask的时候，子线程都是匿名内部类对象，而匿名内部类会隐式持有外部类的引用，一样会有内存泄漏的风险，修改方式和Handler的修改差不多，改成静态内部类。

6.webview造成的内存泄漏，Webview下面的Callback持有Activity引用，造成Webview内存无法释放，即使是调用了Webview.destory()等方法都无法解决问题（Android5.1之后）。解决方案可以参考：https://blog.csdn.net/xygy8860/article/details/53334476

7.资源未及时关闭造成的内存泄漏，比如，Cursor，Stream，Bitmap，ContentObserver，BraodcastReceiver等，在Activity destroy的时候需要去关闭这些资源，bitmap可以直接使用bitmap = null；

三：内存泄漏检测工具

Square公司基于MAT开源了LeakCanary，目前最新版本为1.5.4，使用方式在github中都有介绍，这里就不去写那些重复的代码了。LeakCanary-Github地址