Android 优化——内存优化 - 好文

<>优化的意义

* 减少 OOM，提高应用稳定性。
* 减少卡顿，提高应用流畅度。
* 减少内存占用，提高应用后台运行时的存活率。
* 减少异常发生，减少代码逻辑隐患。
<>垃圾回收

在 GC 的过程中，其它在工作的线程会暂停，包括负责绘制的 UI 线程，并且在不同区域的内存释放速度也有一定的差异，但不管在哪个区域，都要到这次 GC
内存回收完成后，才会继续执行原来的线程。

虽然一次消耗性能不大，但如果大量这样的重复，就会影响到应用的渲染工作，造成垃圾回收动作太频繁。这种情况很容易发生在短时间内申请大量
的对象时，并且它们在极少的情况下能得到有效的释放，这样会出现内存泄漏的情况。

一旦达到了剩余内存的阈值，垃圾回收活动就会启动。即使有时内存申请很小，**它们仍然会给应用程序的堆内存造成压力，还是会启动垃圾回收，**在 GC
频繁的工作过程中消耗了非常多的时间，并且可能导致卡顿。为了避免这样的情况，设置一个 16ms 界线，只要 GC 消耗的时间超过了 16ms
的阈值，就会有丢帧的情况出现。

<>分析工具

使用 Memory Profiler 查看 Java 堆和内存分配（
https://developer.android.com/studio/profile/memory-profiler）可分析内存情况和内存泄露。
<https://developer.android.com/studio/profile/memory-profiler%EF%BC%89%E5%8F%AF%E5%88%86%E6%9E%90%E5%86%85%E5%AD%98%E6%83%85%E5%86%B5%E5%92%8C%E5%86%85%E5%AD%98%E6%B3%84%E9%9C%B2%E3%80%82>

<>内存泄露

内存泄漏就是存在一些被分配的对象，可达但不可用，用不着了但还有链接引用着，导致 GC 无法回收。会导致内存空间不断减少，最终内存耗尽引起 OOM 问题。

<>分类

* 资源对象未关闭
资源性对象比如 BraodcastReceiver、Cursor、File
等、往往都用了一些缓冲，在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。
它们的缓冲不仅存在于 Java 虚拟机内，还存在于 Java 虚拟机外。如果我们仅仅是把它的引用设置为
null，而不关闭它们，往往会造成内存泄露。因为有些资源性对象，比如 SQLiteCursor(在析构函数finalize()，如果没有关闭它，它自己会调
close() 关闭)，但是这样的效率太低。
对于资源性对象不使用的时候，应该立即调用它的 close() 函数，将其关闭掉，然后再置为 null。

* 注册对象未注销
比如广播、观察者监听未解除注册，会导致所在的 Activity 退出后无法释放，不断重新进入，可能造成多个对象一直释放不掉。

* 类的静态变量持有大数据对象
静态变量长期维持对象的引用，阻止垃圾回收，如果静态变量持有大的数据对象，如 Bitmap 等，就很容易引起内存不足等问题。
比如 Activity 里创建静态的 View，而 View 又持有 Activity 对象，导致资源无法释放。

* 非静态内部类的静态实例
非静态内部类会维持一个到外部类实例的引用，如果非静态内部类的实例是静态的，就会间接长期维持着外部类的引用，阻止被系统回收。
比如 AsyncTask 或线程 new Runnable 都会有一个匿名内部类，因此它们对当前 Activity 都有一个隐式引用，如果
Activity 在销毁之前任务还未完成，那么将导致 Activity 的内存资源无法回收，造成内存泄漏。

* 非静态 Handler
Handler 通过发送 Message 与主线程交互，Message 发出之后存储在 MessageQueue 中，有些 Message 不能马上被处理。
在 Message 中存在一个 target，是 Handler 的一个引用，如果 Message 在 Queue 中存在的时间过长，就会导致
Handler 无法被回收。

如果 Handler 是非静态的，则会导致 Activity 或者 Service 不会被回收。所以 Handler 应该定义为静态内部类，通过弱引用持有
Activity。
java static class MyHandler extends Handler { WeakReference<Activity>
mActivityReference; MyHandler(Activity activity) { mActivityReference = new
WeakReference<Activity>(activity); } @Override public void
handleMessage(Message msg) { final Activity activity =
mActivityReference.get(); if (activity != null) {
activity.mImageView.setImageBitmap(mBitmap); } } }
退出时 mHandler.removeCallbacksAndMessages(null)，移除消息队列中所有消息和所有的 Runnable。

* 集合中对象没清理
把一些对象的引用加入到了集合中，当不需要该对象时，如果没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是 static
的话，情况就更严重。

* WebView 泄露
为 WebView 开启独立的一个进程，使用 AIDL 与应用的主进程通信，WebView
所在的进程可以根据业务的需要选择合适的时机进行销毁，达到正常释放内存的目的。

* HandlerThread 没有主动调用 quit
HandlerThread 的 run 方法是一个死循环，它不会自己结束。线程的生命周期超过了 Activity
生命周期，当横竖屏切换，HandlerThread 线程的数量会随着 Activity 重建次数的增加而增加。
应该在 onDestroy 时将线程停止掉：mThread.getLooper().quit()，比如 IntentService 里做完任务自动调用了
stopSelf，进而调用 quit。

* Bitmap 使用不当
用完 Bitmap 时，要及时的 recycle 掉。recycle 并不能确定立即就会将 Bitmap
释放掉，但是会给虚拟机一个暗示：“该图片可以释放了”。

* 获取系统服务
用 ApplicationContext 代替 Activity。

<>检测函数库 LeakCanary

LeakCanary 是 Square 公司的检测内存泄漏的函数库，在 Debug 版本中监控 Activity、Fragment
等的内存泄漏。检测到内存泄漏时会将消息发到系统通知栏，点击后打开 DisplayLeakActivity 的页面，显示泄漏的跟踪消息，还默认保存了最近的 7
个 dump 文件到 APP 的目录中，可以用 MAT 等工具进一步分析。

使用
配置 gradle 文件：
dependencies { debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.1'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1' }
只有 Debug 版本使用，Release 和 Test 版本用 no-op 版本，没有实际代码和操作，不会对 APP 体积和性能产生影响。

在 Application 中初始化：
public class ExampleApplication extends Application { @Override public void
onCreate() { super.onCreate(); if (LeakCanary.isInAnalyzerProcess(this)) { //
This process is dedicated to LeakCanary for heap analysis. // You should not
init your app in this process. return; } LeakCanary.install(this); // Normal
app init code... } }
其中，LeakCanary.install 方法会自动启动一个 ActivityRefWatcher，自动监控应用中调用
Activity.onDestroy 之后发生泄漏的 Activity。

如果想监控其它的对象，比如 Fragment，可以通过 install 方法返回的 RefWatcher 去监控。
public class ExampleApplication extends Application { @Override public void
onCreate() { super.onCreate(); if (LeakCanary.isInAnalyzerProcess(this)) { //
This process is dedicated to LeakCanary for heap analysis. // You should not
init your app in this process. return; } refWatcher = LeakCanary.install(this);
// Normal app init code... } private RefWatcher refWatcher; // get 方法返回
RefWatcher 对象 public static RefWatcher getRefWatcher(Context context) {
ExampleApplication application = (ExampleApplication)
context.getApplicationContext(); return application.refWatcher; } }
然后在 Fragment 的 onDestroy 方法中调用 refWatcher 监控
@Override public void onDestroy() { super.onDestroy(); RefWatcher refWatcher =
ExampleApplication.getRefWatcher(getActivity()); refWatcher.watch(this); }
可以使用 watch 来监控任何你认为已经销毁的对象。

<>原理

* RefWatcher.watch() 为被监控对象创建一个 KeyedWeakReference 弱引用对象，它是
WeakReference 的子类，添加键值对，后面会根据指定 Key 找到弱引用对象。
* 在后台线程 AndroidWatchExecutor 中，检查 KeyedWeakReference
弱引用是否被清除，如果存在则触发一次垃圾回收。垃圾回收后，如果弱引用对象依然存在，说明已经内存泄漏，会将 Heap 内存导出到
.hprof 文件中，并将文件放在 APP 的文件目录中。
* 在一个独立的进程中启动 HeapAnalyzerService 服务，解析 heap dump 信息。基于唯一的 reference
key，在 heap dump 中找到对应的
KeyedWeakReference，并定位发生内存泄漏的对象引用。HeapAnalyzer 会计算 GC Roots
的最短强引用路径，并判断是否存在泄漏，并构建出导致泄漏的对象引用链。
<>定制

RefWatcher 的自定义
由于 Release 版本使用的 leakcanary-android-no-op 库，若自定义 LeakCanary，需确保只影响 Debug
版本，因为可能引用到 leakcanary-android-no-op 中没有的 API。因此需要将 Release 和 Debug 部分的代码分离。例如定义
ExampleApplication 用于 Release 版本，DebugExampleApplication 用于 Debug 版本，继承
ExampleApplication。
public class ExampleApplication extends Application { public static RefWatcher
getRefWatcher(Context context) { ExampleRefWatcher application =
(ExampleRefWatcher) context.getApplicationContext(); return
application.refWatcher(); } private RefWatcher refWatcher; @Override public
void onCreate() { super.onCreate(); ... // 不再是调用 install 方法 refWatcher =
installLeakCanary(); ... } protected RefWatcher installLeakCanary() { return
RefWatcher.DISABLED; } }
新建 src/debug/java 文件夹，在其中创建 DebugExampleApplication：
// Debug 版本的 Application 类 public class DebugExampleApplication extends
ExampleApplication { protected RefWatcher installLeakCanary() { RefWatcher
refWatcher = LeakCanary.install(this); return refWatcher; } }
在 src/debug 中新建 AndroidManifest.xml 文件：
<?xml version="1.0 encoding="utf-8" ?> <manifest ...> <application
tools:replace="android:name" android:name=".DebugExampleApplication" />
</manifest>
Gradle 构建时，如果是 debug 版本，会将 src/debug/AndroidManifest.xml 的内容合并入
src/main/AndroidManifest.xml 文件中。同时由于使用了 tools:replace属性，所以 android:name 的值
DebugExampleApplication 会替换 ExampleApplication。

通知页面样式的自定义
内存泄漏通知页面 DisplayLeakActivity 默认的图标和标签两个值，可以进行覆盖。

图标定义在 res 下的
drawable-hdpi/drawable-mdpi/drawable-xhdpi/drawable-xxhdpi/drawable-xxxhdpi 里，名为
__leak_canary_icon.png。

标签定义在：
<?xml version="1.0" encoding="utf-8"?> <resources> <string
name="__leak_canary_display_activity_label">MyLeaks</string> </resources>
内存泄漏堆栈信息保存个数的自定义
默认情况下，DisplayLeakActivity 在 APP 目录中最多保存 7 个 HeapDump 文件和泄漏堆栈信息，可以在 APP 中定义
R.integer.__leak_canary_max_stored_leaks 来修改。
<?xml version="1.0" encoding="utf-8"?> <resources> <string
name="__leak_canary_max_stored_leaks">20</string> </resources>
Watcher 的延时
通过定义 R.integer.leak_canary_watch_delay_millis 来修改弱引用对象被认为出现内存泄漏的延时时间，默认 5
秒，下面修改为 1.5 秒：
<?xml version="1.0" encoding="utf-8"?> <resources> <string
name="leak_canary_watch_delay_millis">1500</string>
自定义堆栈信息和 heap dump 的处理方式
可以通过继承 DisplayLeakService 并重写其中的 afterDefaultHandling 函数来实现定制化操作，例如将 heap
dump 文件发送到服务端：
public class LeakUploadService extends DisplayLeakService { @Override
protected void afterDefaultHandling(HeapDump headDump, AnalysisResult result,
String leakInfo) { if (!result.leakFound || result.excludedLeak) { return; }
myServer.uploadLeakBlocking(heapDump.headDumpFile, leakInfo); } } public class
DebugExampleApplication extends ExampleApplication { protected RefWatcher
installLeakCanary() { return LeakCanary.install(app, LeakUploadService.class,
AndroidExcludedRefs.createAppDefaults().build()); } }
为了使 LeakUploadService 生效，需要在 AndroidManifest.xml 中注册。

忽略特定的弱引用
实现自己的 ExcludedRefs 忽略某些特定的弱引用对象，不对其进行内存泄漏的监视。
public class DebugExampleApplication extends ExampleApplication { protected
RefWatcher installLeakCanary() { ExcludedRefs excludedRefs =
AndroidExcludedRefs.createAppDefaults()
.instanceField("com.example.Example.class", "exampleField") .build(); return
LeakCanary.install(this, DisplayLeakService.class, excludedRefs); } }
不监视特定 Activity
默认会监视所有 Activity 的内存泄漏，默认只支持 Android 4.0 以上的系统，如果 4.0 以下需要在 onDestroy 中主动
watch。
public class DebugExampleApplication extends ExampleApplication { @Override
protected RefWatcher installLeakCanary() { if
(LeakCanary.isInAnalyzerProcess(this)) { return RefWatcher.DISABLED; } else {
ExcludedRefs excludedRefs = AndroidExcludedRefs.createAppDefaults().build();
LeakCanary.enableDisplayLeakActivity(this); ServiceHeapDumpListener
heapDumpListener = new ServiceHeapDumpListener(this, DisplayLeakService.class);
final RefWatcher refWatcher = LeakCanary.androidWathcer(this, heapDumpListener,
exlcudedRefs); registerActivityLifecycleCallbacks(new
ActivityLifecycleCallbacks() { public void onActivityDestroyed(Activity
activity) { if (activity instanceof MainActivyt) { // 排除某些 Activity return; }
refWatcher.watch(activity); } }); return refWatcher; } } }
<>内存优化

*
使用软/弱/虚引用

*
使用 ArrayMap 代替 HashMap

*
使用 SparseArray，SparseBooleanArray，SparseLongArray 和 SparseIntArray 替换
HashMap，以减少装箱带来的内存占用，也避免了拆箱。

*
@IntDef，@StringDef 代替枚举

*
zipalign 优化 apk

*
节制使用 Service 如果需要使用 Service 来执行后台任务，一定要任务正在执行的时候才启动
Service。另外，当任务执行完之后去停止 Service 的时候，要小心停止失败导致内存泄漏的情况。可以使用
IntentService，后台任务结束后会自动停止，从而极大程度上避免了 Service 内存泄漏的可能性。

*
当界面不可见时释放内存 Activity 中重写 onTrimMemory()，当处于 TRIM_MEMORY_UI_HIDDEN
这个级别时，表明用户已经离开了程序，所有界面都不可见，此时可以进行一些资源释放操作。 @Override public
void onTrimMemory(int level) { super.onTrimMemory(level);
switch (level) { case TRIM_MEMORY_UI_HIDDEN: // 释放资源
break; } }

<>图片优化

*
设置位图规格 ARGB_8888 占用内存最高，是系统默认。 RGB_565
会损失较多的图片数据，但除了大图，一般看不出什么区别。但它不支持 PNG 图片的透明通道。 ARGB_4444
减少一半的数据，但保留了透明通道，视觉差异变化较大，一般用于用户头像，特别是圆角头像。 Aplha_8 主要用于 Alpha
通道模板，相当于做一个染色。图像要渲染两次，虽然减少内存，但增加了绘制的开销。在 Android 的基本文件结构中不支持
PNG、JPEG 和 WEBP 格式，因此需要通过 inPreferredConfig 参数来实现不同的位图规格
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565;
BitmapFactory.decodeStream(is, null, options);

*
设置采样率 BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResource(), R.drawable.ic, options);
int height = options.outHeight; int width = options.outWidth; String
imageType = options.outMimeType; options.inSampleSize = 2;
options.inJustDecodeBounds = false;
BitmapFactory.decodeResource(getResource(), R.drawable.ic, options)

*
inScaled，inDensity 和 inTargetDensity BitmapFactory.Options options =
new BitmapFactory.Options(); options.inScaled = true;
options.inDensity = srcWidth; options.inTargetDensity = dstWidth;
BitmapFactory.decodeStream(is, null, options); 当 inScaled 设为 true
时，系统会按照现有的密度来划分目标密度，通过派生绽放数来应用到位图上，使用这个方法会重设图片大小，并对它应用一个新的过滤。
虽然这些方法都非常好用，并且减少图片显示需要的内存，但因为过多的算法，导致图片显示的过程需要更多的时间开销，如果图片很多的话，就影响到图片的显示效果。
最好的方案是结合这两个方法，首先使用 inSampleSize 处理图片，转换为接近目标的 2 次幂，然后用 inDensity 和
inTargetdensy 生成最终想要的准确大小，因为 inSamplesize 会减少像素的数量，而
基于输出密度的需要对像素重新过滤。 BitmapFactory.Options options = new
BitmapFactory.Options(); options.inJustDecodeBounds = true;
BitmapFactory.decodeStream(is, null, options); options.inScaled =
true; options.inDensity = options.outWidth; options.inSampleSize =
4; options.inTargetDensity = dstWith * options.inSampleSize;
options.inJustDecodeBounds = false; BitmapFactory.decodeStream(is,
null, options);

*
inBitmap Android 3.0（API 11）引进了 BitmapFactory.Options.inBitmap
字段，设置该属性后，当使用了带有该 Options 参数的 decode 方法加载内容时，decode
方法会尝试重用一个已经存在的位图。这意味着位图内存被重用，从而改善性能，并且没有内存的分配和释放过程。常见的使用方案可以结合
LruCache 来实现，在 LruCache 移除超出 cache size 的图片时，暂时缓存 Bitmap
到一个软引用集合，需要创建新的 Bitmap 时，可以从这个软引用集合中找到最适合重用的 Bitmap 来重用它的内存区域。新申请
Bitmap 与旧的 Bitmap 必须有相同的解码格式，并且在 Android 4.4 之前，只能重用相同大小的 Bitmap
的内存区域，Android 4.4 后可以重用任何 bitmap 的内存区域。

*
drawable 目录不同的目录对应不同的显示密度
目录名称 Density res/drawable 0 res/drawable-hdpi 240 res/drawable-ldpi 120
res/drawable-mdpi 160 res/drawable-xhdpi
320 res/drawable-xxhdpi 480
加载资源图片时，会先算出屏幕密度，然后再到对应的资源目录下寻找图片，如果没有，则到最近的目录中寻找。比如一张图片只放在了
res/drawable-mdpi，但当前设备密度是 480，那么系统会将这张图片放大 3 倍加载到内存。 res/drawable
在不同的设备下会被替换成不同的密度，即系统本身的默认密度。
所以抓不准该放到哪个目录的图片，就尽量问设计人员要高品质图片然后往高密度目录下放，这样在低密屏上“放大倍数”是小于 1
的，在保证画质的前提下，内存也是可控的。拿不准的图片，使用 Drawable.createFromStream 替换
getResources().getDrawable 来加载，这样就可以绕过 Android 的这套默认适配法则。

热门工具换一换