谈一谈Android内存优化那些事（二）Android常用的内存优化方法

由于内容比较多，我从三个方面分为三篇对Android内存优化进行介绍：

1.Android内存分配与回收机制
2.Android常用的内存优化方法
3.Android内存分析与监控

上一篇文章我们说完了内存分配与回收机制的事，下面我们就来谈一谈内存优化吧！

Android常用的内存优化方法

在Android中内存优化的方式实在是太多了，往细了说，到你写的每一行代码其实都和内存优化相关。在这里我从三个方面来说下Android内存优化的方法：

降低运行时内存

代码优化

内存泄漏优化

在实际开发中我们可以先考虑降低应用的运行时内存，然后针对代码写的不好的地方着重优化，最后通过规避一些可能导致内存泄漏的编码方式，去提前避免内存泄漏的问题。

一、降低运行时内存

降低运行时内存可以分为减小APK的体积和Bitmap优化两部分：

减小APK体积

去除无用的资源和代码，通过合理使用git，一些由于业务变更而基本不会用到的代码，该删除的绝不能手软。即使以后要用到，通过git也能找回。同时一些图片资源未用到的也应该删除，因为即使gradle配了sharkresource选项，发布的时候这些没有用到的图片依然会被打包到你的apk。

尽量复用资源，其实这是一种比较好的编码习惯。

对应用的启动图引导页图片进行压缩，往往这些图片占据了大部分空间，压缩后可以起到很好的效果。平时开发中对于分辨率大雨100*100的图片基本上都会进行压缩，很多好的压缩算法经常可以减少一半的大小，而感官上基本看不出有任何改变。

Bitmap优化

统一的bitmap加载器，选择Glide、Fresco、Picasso中的一个作为图片加载框架。实际开发中加载到view的图片的大小不应该超过view的大小，图片加载框架默认会对图片进行缓存，按view实际大小加载。在开发中为了减少apk的大小，一般只放一套3X图片，但是这些图片在小分辨率的手机上直接加载就会出现内存浪费。统一的bitmap加载器就可以很好的解决该问题。

图片存在像素浪费，对于.9图，美工可能在出图时在拉伸与非拉伸区域都有大量的像素重复。而这些图片是可以缩小，但并不影响显示效果。

inSampleSize:缩放比例，在把图片载入内存之前，我们需要计算一个合适的缩放比例，避免不必要的大图载入。

选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。

inBitmap：这个参数用来实现Bitmap内存的复用，但复用存在一些限制，具体体现在：在Android 4.4之前只能重用相同大小的Bitmap的内存，而Android 4.4及以后版本则只要后来的Bitmap比之前的小即可。使用inBitmap参数前，每创建一个Bitmap对象都会分配一块内存供其使用，而使用了inBitmap参数后，多个Bitmap可以复用一块内存，这样可以提高性能。

参考：

Android 官网文档Managing Bitmap Memory、Handling bitmaps

二、代码优化

这里介绍一些好的编码习惯：

考虑使用ArrayMap/SpareseArray而不是传统的HashMap等数据结构，Android系统为移动系统设计的容器ArrayMap更加高效，占用内存更少，因为HashMap需要一个额外的实例对象来记录Mapping的操作。而SparesArray高效的避免了key和value的自动装箱，而且避免了装箱后的解箱。详细参考Android性能优化典范
在onDraw这种频繁调用的方法要避免对象的创建操作，因为他会迅速增加内存的使用，引起频繁的gc，甚至内存抖动。
SoftReference(软引用)、WeakReference(弱引用)、PhantomReference(虚引用)

SoftReference：如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。

WeakReference：与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。

PhantomReference：虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列（ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。
谨慎使用large heap，android设备由于软硬件的差异，heap阀值不同，特殊情况下可以在manifest中使用largeheap=true声明一个更大的heap空间，使用getLargeMemoryClass()来获取到这个更大的空间。但是要谨慎使用，因为额外的空间会影响到系统整体的用户体验，切换任务时性能大打折扣，对于oom异常是治标不治本的一种做法。
谨慎使用多进程，使用多进程可以把应用中的部分组件运行在单独的进程当中，这样可以扩大应用的内存占用范围，但是这个技术必须谨慎使用，绝大多数应用都不应该贸然使用多进程，一方面是因为使用多进程会使得代码逻辑更加复杂，另外如果使用不当，它可能反而会导致显著增加内存。当你的应用需要运行一个常驻后台的任务，而且这个任务并不轻量，可以考虑使用这个技术，一个典型的例子是创建一个可以长时间后台播放的Music Player。如果整个应用都运行在一个进程中，当后台播放的时候，前台的那些UI资源也没有办法得到释放。类似这样的应用可以切分成2个进程：一个用来操作UI，另外一个给后台的Service。
考虑第三方库的大小，如果会和现有的代码或其他库的代码重复，考虑不要真个引入而是把库的代码精简之后再引入。

三、内存泄漏优化

内存泄漏的原因有很多，下面介绍一些常见的，我们需要在开发中多注意：

Activity调用了finish，但是引用Activity的对象未被释放(生命周期没有结束)，Activity Context被传递到其他实例中，可能导致自身被引用而发生泄露，建议使用weakReferce。
除必须使用Activity Context的情况(Dialog的context必须是Activity),我们可以使用Application Context来避免Activity泄露。
大多数情况下，我们对Bitmap对象增加缓存机制，但是有时候部分bitmap需要及时回收。比如我们临时创建的摸个相对大的bitmap对象，变换得到新的bitmap对象后，尽快回收原始的bitmap，及时释放原来的空间。
webview引起的内存泄漏主要是因为org.chromium.android_webview.AwContents 类中注册了component callbacks，但是未正常反注册而导致的。让onDetachedFromWindow先走，在主动调用destroy()之前，把webview从它的parent上面移除掉(Basewebfragment onDestroy())
虽然单例模式简单实用，提供了很多便利性，但是因为单例的生命周期和应用保持一致，使用不合理很容易出现持有对象的泄漏。
我们在对数据库进行操作时，使用完cursor没有及时关闭，cursor的泄露，会对内存管理带来负面影响。
谨慎使用static对象，因为static的生命周期过长，和应用的进程保持一致，使用不当很可能导致对象泄漏。

总结：在实际的线上环境中发现，大部分内存泄漏是因为被调用的对象生命周期不同步导致，生命周期不同步不仅仅会导致内存泄漏，更会出现异常，崩溃等更严重的问题。

做好上面说的1、2、3就够了吗？

上篇文章我们已经从系统级别了解了Android Framework、Darlvik/Art虚拟机、Linux在内存分配上的原理，接着又在代码级别分别从减少内存占用、避免内存泄漏和代码优化三个方面介绍了如何避免内存问题，再加上当前科技发展是如此迅速，4GB内存已经是很常见的手机配置。LPDDR4X的高速闪存也越来越被广泛的使用。对于内存优化我们是不是就已经可以高枕无忧了，有上面这些就够了吗？

我想即使我们再了解内存，写的代码再好，用户的手机再先进，总还是有出错的时候，那么事后的内存分析和监控是必不可少的了！下一篇文章我们就来谈一谈内存分析和监控。