关于android:深入探索-Android-内存优化炼狱级别上

前言

成为一名优良的 Android 开发，须要一份齐备的常识体系，在这里，让咱们一起成长为本人所想的那样~。

本篇是 Android 内存优化的进阶篇，难度能够说达到了炼狱级别，倡议对内存优化不是十分相熟的认真看看前篇文章：Android 性能优化之内存优化，其中详细分析了以下几大模块：

• 1）、Android 的内存管理机制
• 2）、优化内存的意义
• 3）、防止内存透露
• 4）、优化内存空间
• 5）、图片治理模块的设计与实现

如果你对以上根底内容都比拟理解了，那么咱们便开始 Android 内存优化的探索之旅吧。

本篇文章十分长，倡议珍藏后缓缓享受~

目录

• 一、重识内存优化
• 1、手机 RAM
• 2、内存优化的纬度
• 3、内存问题
• 二、常见工具抉择
• 1、Memory Profiler
• 2、Memory Analyzer
• 3、LeakCanary
• 三、Android 内存管理机制回顾
• 1、Java 内存调配
• 2、Java 内存回收算法
• 3、Android 内存管理机制
• 4、小结
• 四、内存抖动
• 1、那么，为什么内存抖动会导致 OOM？
• 2、内存抖动解决实战
• 3、内存抖动常见案例
• 五、内存优化体系化搭建
• 1、MAT 回顾
• 2、搭建体系化的图片优化 / 监控机制
• 3、建设线上利用内存监控体系
• 4、建设全局的线程监控组件
• 5、GC 监控组件搭建
• 6、建设线上 OOM 监控组件：Probe
• 7、实现 单机版 的 Profile Memory 自动化内存剖析
• 8、搭建线下 Native 内存透露监控体系
• 9、设置内存兜底策略
• 10、更深刻的内存优化策略
• 六、内存优化演进
• 1、自动化测试阶段
• 2、LeakCanary
• 3、应用基于 LeakCannary 的改进版 ResourceCanary
• 七、内存优化工具
• 1、top
• 2、dumpsys meminfo
• 3、LeakInspector
• 4、JHat
• 5、ART GC Log
• 6、Chrome Devtool
• 八、内存问题总结
• 1、内类是有危险的编码方式
• 2、一般 Hanlder 外部类的问题
• 3、登录界面的内存问题
• 4、应用零碎服务时产生的内存问题
• 5、把 WebView 类型的透露装进垃圾桶过程
• 6、在适当的时候对组件进行登记
• 7、Handler / FrameLayout 的 postDelyed 办法触发的内存问题
• 8、图片放错资源目录也会有内存问题
• 9、列表 item 被回收时留神开释图片的援用
• 10、应用 ViewStub 进行占位
• 11、留神定时清理 App 过期的埋点数据
• 12、针对匿名外部类 Runnable 造成内存透露的解决
• 九、内存优化常见问题
• 1、你们内存优化我的项目的过程是怎么做的？
• 2、你做了内存优化最大的感触是什么？
• 3、如何检测所有不合理的中央？
• 十、总结
• 1、优化大方向
• 2、优化细节
• 3、内存优化体系化建设总结

一、重识内存优化

Android 给每个利用过程调配的内存都是十分无限的，那么，为什么不能把图片下载下来都放到磁盘中呢 ？那是因为放在  内存  中，展示会更“ 快”，快的起因有两点，如下所示：

• 1）、硬件快：内存自身读取、存入速度快。
• 2）、复用快：解码成绩无效保留，复用时，间接应用解码后对象，而不是再做一次图像解码。

这里说一下解码的概念。Android 零碎要在屏幕上展现图片的时候只认“像素缓冲 ”，而这也是大多数操作系统的特色。而咱们  常见的 jpg，png 等图片格式，都是把“像素缓冲”应用不同的伎俩压缩后的后果 ，所以这些格局的图片，要在设施上  展现 ，就  必须通过一次解码 ，它的  执行速度会受图片压缩比、尺寸等因素影响 。(官网倡议： 把从内存中淘汰的图片，升高压缩比后存储到本地，以备后用，这样能够最大限度地升高当前复用时的解码开销。)

上面，咱们来理解一下内存优化的一些重要概念。

1、手机 RAM

手机不应用 PC 的 DDR 内存 ，采纳的是 LPDDR RAM，即” 低功耗双倍数据速率内存“。其计算规定如下所示：

LPDDR 系列的带宽 = 时钟频率 ✖️内存总线位数 / 8
LPDDR4 = 1600MHZ ✖️64 / 8 ✖️双倍速率 = 25.6GB/s。

那么内存占用是否越少越好？

当零碎 内存短缺  的时候，咱们能够  多用  一些取得  更好的性能 。当零碎  内存不足  的时候，咱们心愿能够做到” 用时调配，及时开释“。

2、内存优化的纬度

对于 Android 内存优化来说又能够细分为如下两个维度，如下所示：

• 1）、RAM 优化
• 2）、ROM 优化

1、RAM 优化

次要是 升高运行时内存 。它的  目标 有如下三个：

• 1）、避免利用产生 OOM。
• 2）、升高利用因为内存过大被 LMK 机制杀死的概率。
• 3）、防止不合理应用内存导致 GC 次数增多，从而导致利用产生卡顿。

2、ROM 优化

升高利用占 ROM 的体积，进行 APK 瘦身。它的 目标  次要是为了  升高利用占用空间，防止因 ROM 空间有余导致程序无奈装置。

3、内存问题

那么，内存问题次要是有哪几类呢？内存问题通常来说，能够细分为如下 三类:

• 1）、内存抖动
• 2）、内存透露
• 3）、内存溢出

上面，咱们来理解下它们。

1、内存抖动

内存稳定图形呈 锯齿张、GC 导致卡顿。

这个问题在 Dalvik 虚拟机  上会  更加显著 ，而 ART 虚拟机 在  内存治理跟回收策略  上都做了  大量优化 ， 内存调配和 GC 效率相比晋升了 5~10 倍 ，所以  呈现内存抖动的概率会小很多。

2、内存透露

Android 零碎虚拟机的垃圾回收是通过虚拟机 GC 机制来实现的。GC 会抉择一些还存活的对象作为内存遍历的根节点 GC Roots，通过对 GC Roots 的可达性来判断是否须要回收。内存透露就是 在以后利用周期内不再应用的对象被 GC Roots 援用，导致不能回收，使理论可应用内存变小 。简言之，就是  对象被持有导致无奈开释或不能依照对象失常的生命周期进行开释 。一般来说， 可用内存缩小、频繁 GC，容易导致内存透露。

3、内存溢出

即 OOM，OOM 时会导致程序异样。Android 设施出厂当前，java 虚拟机对单个利用的最大内存调配就确定下来了，超出这个值就会 OOM。单个利用可用的最大内存对应于 /system/build.prop 文件中的 dalvik.vm.heapgrowthlimit。

此外，除了因内存透露累积到肯定水平导致 OOM 的状况以外，也有一次性申请很多内存，比如说 一次创立大的数组或者是载入大的文件如图片的时候会导致 OOM。而且，理论状况下 很多 OOM 就是因图片处理不当 而产生的。

二、常见工具抉择

在 Android 性能优化之内存优化中咱们曾经介绍过了相干的优化工具，这里再简略回顾一下。

1、Memory Profiler

作用

• 1）、实时图表展现利用内存使用量。
• 2）、用于辨认内存透露、抖动等。
• 3）、提供捕捉堆转储、强制 GC 以及依据内存调配的能力。

长处

• 1）、不便直观
• 2）、线下应用

2、Memory Analyzer

弱小的 Java Heap 剖析工具，查找 内存透露及内存占用 ，生成  整体报告 、 剖析内存问题  等等。倡议  线下深刻应用。

3、LeakCanary

自动化  内存透露检测神器。倡议仅用于 线下集成。

它的 毛病 比拟显著，具体有如下两点：

• 1）、尽管应用了 idleHandler 与多过程，然而 dumphprof 的 SuspendAll Thread 的个性仍然会导致利用卡顿。
• 2）、在三星等手机，零碎会缓存最初一个 Activity，此时应该采纳更严格的检测模式。

三、Android 内存管理机制回顾

ART 和 Dalvik 虚拟机应用 分页和内存映射 来治理内存。上面咱们先从 Java 的内存调配开始说起。

1、Java 内存调配

Java 的 内存调配区域  分为如下  五局部：

• 1）、办法区：次要寄存动态常量。
• 2）、虚拟机栈：Java 变量援用。
• 3）、本地办法栈：native 变量援用。
• 4）、堆：对象。
• 5）、程序计数器：计算以后线程的以后办法执行到多少行。

2、Java 内存回收算法

1、标记 - 革除算法

流程可简述为 两步：

• 1）、标记所有须要回收的对象。
• 2）、对立回收所有被标记的对象。

长处

实现比较简单。

毛病

• 1）、标记、革除 效率不高。
• 2）、产生 大量内存碎片。

2、复制算法

流程可简述为 三步：

• 1）、将内存划分为大小相等的两块。
• 2）、一块内存用完之后复制存活对象到另一块。
• 3）、清理另一块内存。

长处

实现简略，运行高效，每次仅需遍历标记一半的内存区域。

毛病

会 节约一半的空间，代价大。

3、标记 - 整顿算法

流程可简述为 三步：

• 1）、标记过程与 标记 - 革除算法 一样。
• 2）、存活对象往一端进行挪动。
• 3）、清理其余内存。

长处

• 1）、防止 标记 - 革除 导致的内存碎片。
• 2）、防止复制算法的空间节约。

4、分代收集算法

当初 支流的虚拟机  个别用的比拟多的还是分代收集算法，它具备如下  特点：

• 1）、联合多种算法劣势。
• 2）、新生代对象存活率低，应用 复制算法。
• 3）、老年代对象存活率高，应用 标记 - 整顿算法。

3、Android 内存管理机制

Android 中的内存是 弹性调配  的， 调配值 与 最大值 受具体设施影响。

对于 OOM 场景 其实能够细分为如下两种：

• 1）、内存真正有余。
• 2）、可用（被调配的）内存不足。

咱们须要着重留神一下这两种的辨别。

4、小结

以 Android 中虚拟机的角度来说，咱们要分明 Dalvik 与 ART 区别 ，Dalvik 仅固定 一种回收算法 ，而 ART 回收算法可在  运行期按需抉择 ，并且，ART 具备  内存整理  能力， 缩小内存空洞。

最初，LMK（Low Memory killer） 机制保障了 过程资源的正当利用 ，它的 实现原理 次要是 依据过程分类和回收收益来综合决定的一套算法集。

四、内存抖动

当 内存频繁调配和回收  导致内存  不稳固 ，就会呈现内存抖动，它通常体现为  频繁 GC、内存曲线呈锯齿状。

并且，它的危害也很重大，通常会导致 页面卡顿，甚至造成 OOM。

1、那么，为什么内存抖动会导致 OOM？

次要起因有如下两点：

• 1）、频繁创建对象，导致内存不足及碎片（不间断）。
• 2）、不间断的内存片无奈被调配，导致 OOM。

2、内存抖动解决实战

这里咱们假如有这样一个场景：点击按钮应用 handler 发送一个空音讯，handler 的 handleMessage 接管到音讯后创立内存抖动，即在 for 循环创立 100 个容量为 10 万 的 strings 数组并在 30ms 后持续发送空音讯。

个别应用 Memory Profiler（体现为 频繁 GC、内存曲线呈锯齿状）联合代码排查 即可找到内存抖动呈现的中央。

通常的技巧就是着重查看 循环或频繁被调用 的中央。

3、内存抖动常见案例

上面列举一些导致内存抖动的常见案例，如下所示：

1、字符串应用加号拼接

• 1）、应用 StringBuilder 代替。
• 2）、初始化时设置容量，缩小 StringBuilder 的扩容。

2、资源复用

• 1）、应用 全局缓存池 ，以  重用频繁申请和开释的对象。
• 2）、留神 完结  应用后，须要  手动开释对象池中的对象。

3、缩小不合理的对象创立

• 1）、ondraw、getView 中创立的对象尽量进行复用。
• 2）、防止在循环中一直创立局部变量。

4、应用正当的数据结构

应用 SparseArray 类族、ArrayMap 来代替 HashMap。

五、内存优化体系化搭建

在开始咱们明天正式的主题之前，咱们先来回归一下内存透露的概念与解决技巧。

所谓的内存透露就是 内存中存在曾经没有用的对象 。它的  体现  个别为  内存抖动、可用内存逐步缩小 。它的  危害  即会导致  内存不足、GC 频繁、OOM。

而对于 内存透露的剖析  个别可简述为如下  两步：

• 1）、应用 Memory Profiler 初步察看。
• 2）、通过 Memory Analyzer 联合代码确认。

1、MAT 回顾

MAT 查找内存透露

对于 MAT 来说，其惯例的查找内存透露的形式能够细分为如下三步：

• 1）、首先，找到以后 Activity，在 Histogram 中抉择其 List Objects 中的 with incoming reference（哪些援用引向了我）。
• 2）、而后，抉择以后的一个 Path to GC Roots/Merge to GC Roots 的 exclude All 弱软虚援用。
• 3）、最初，找到的透露对象在左下角下会有一个小圆圈。

此外，在 Android 性能优化之内存优化还有几种进阶的应用形式，这里就不一一赘述了，上面，咱们来看看对于 MAT 应用时的一些要害细节。

MAT 的要害应用细节

要全面把握 MAT 的用法，必须要先理解 暗藏在 MAT 应用中的四大细节，如下所示：

• 1）、长于应用 Regex 查找对应透露类。
• 2）、应用 group by package 查找对应包下的具体类。
• 3）、明确 with outgoing references 和 with incoming references 的区别。
• with outgoing references：它援用了哪些对象。
• with incoming references：哪些对象援用了它。
• 4）、理解 Shallow Heap 和 Retained Heap 的区别。
• Shallow Heap：示意对象本身占用的内存。
• Retained Heap：对象本身占用的内存 + 对象援用的对象所占用的内存。

MAT 要害组件回顾

除此之外，MAT 共有  5 个要害组件 帮忙咱们去剖析内存方面的问题，别离如下所示：

• 1）、Dominator_tree
• 2）、Histogram
• 3）、thread_overview
• 4）、Top Consumers
• 5）、Leak Suspects

上面咱们这里再简略地回顾一下它们。

1、Dominator（支配者）：

如果从 GC Root 达到对象 A 的门路上必须通过对象 B，那么 B 就是 A 的支配者。

2、Histogram 和 dominator_tree 的区别：

• 1）、Histogram 显示 Shallow Heap、Retained Heap、Objects，而 dominator_tree 显示的是 Shallow Heap、Retained Heap、Percentage。
• 2）、Histogram 基于 类  的角度，dominator_tree 是基于  实例 的角度。Histogram 不会具体显示每一个透露的对象，而 dominator_tree 会。

3、thread_overview

查看 线程数量  和  线程的 Shallow Heap、Retained Heap、Context Class Loader 与 is Daemon。

4、Top Consumers

通过 图形  的模式列出  占用内存比拟多的对象。

在下方的 Biggest Objects 还能够查看其 绝对比拟具体的信息，例如 Shallow Heap、Retained Heap。

5、Leak Suspects

列出有内存透露的中央，点击 Details 能够查看其产生内存透露的援用链。

2、搭建体系化的图片优化 / 监控机制

在介绍图片监控体系的搭建之前，首先咱们来回顾下 Android Bitmap 内存调配的变动。

Android Bitmap 内存调配的变动

在 Android 3.0 之前

• 1）、Bitmap 对象寄存在 Java Heap，而像素数据是寄存在 Native 内存中的。
• 2）、如果不手动调用 recycle，Bitmap Native 内存的回收齐全依赖 finalize 函数回调，然而回调机会是不可控的。

Android 3.0 ~ Android 7.0

将 Bitmap 对象  和  像素数据 对立放到 Java Heap 中，即便不调用 recycle，Bitmap 像素数据也会随着对象一起被回收。

然而，Bitmap 全副放在 Java Heap 中的毛病很显著，大抵有如下两点：

• 1）、Bitmap 是内存耗费的小户，而 Max Java Heap 个别限度为 256、512MB，Bitmap 过大过多容易导致 OOM。
• 2）、容易引起大量 GC，没有充分利用零碎的可用内存。

Android 8.0 及当前

• 1）、应用了可能辅助回收 Native 内存的 NativeAllocationRegistry，以实现将像素数据放到 Native 内存中，并且能够和 Bitmap 对象一起疾速开释，最初，在 GC 的时候还能够思考到这些 Bitmap 内存以避免被滥用。
• 2）、Android 8.0 为了 解决图片内存占用过多和图像绘制效率过慢 的问题新增了硬件位图Hardware Bitmap。

那么，咱们如何将图片内存寄存在 Native 中呢？

将图片内存寄存在 Native 中的步骤有 四步，如下所示：

• 1）、调用 libandroid_runtime.so 中的 Bitmap 构造函数，申请一张空的 Native Bitmap。对于不同 Android 版本而言，这里的获取过程都有一些差别须要适配。
• 2）、申请一张一般的 Java Bitmap。
• 3）、将 Java Bitmap 的内容绘制到 Native Bitmap 中。
• 4）、开释 Java Bitmap 内存。

咱们都晓得的是，当 零碎内存不足  的时候，LMK 会依据 OOM_adj 开始杀过程，从  后盾、桌面、服务、前台，直到手机重启 。并且，如果频繁申请开释 Java Bitmap 也很容易导致内存抖动。对于这种种问题，咱们该  如何评估内存对利用性能的影响 呢？

对此，咱们能够次要从以下 两个方面 进行评估，如下所示：

• 1）、解体中异样退出和 OOM 的比例。
• 2）、低内存设施更容易呈现内存不足和卡顿，须要查看利用中用户的手机内存在 2GB 以下所占的比例。

对于具体的优化策略与伎俩，咱们能够从以下 七个方面  来搭建一套  成体系化的图片优化 / 监控机制。

1、对立图片库

在我的项目中，咱们须要 收拢图片的调用，防止应用 Bitmap.createBitmap、BitmapFactory 相干的接口创立 Bitmap，而应该应用本人的图片框架。

2、设施分级优化策略

内存优化首先须要依据 设施环境  来综合思考， 让高端设施应用更多的内存 ，做到  针对设施性能的好坏应用不同的内存调配和回收策略。

因而，咱们能够应用相似 device-year-class 的策略对设施进行分级，对于低端机用户能够敞开简单的动画或”重性能“，应用 565 格局的图片或更小的缓存内存 等等。

业务开发人员须要 思考性能是否对低端机开启，在系统资源不够时被动去做降级解决。

3、建设对立的缓存治理组件

建设对立的缓存治理组件，并正当应用 OnTrimMemory / LowMemory 回调，依据零碎不同的状态去开释相应的缓存与内存。

在实现过程中，须要 解决应用 static LRUCache 来缓存大尺寸 Bitmap 的问题。

并且，在通过理论的测试后，发现 onTrimMemory 的 ComponetnCallbacks2.TRIM_MEMORY_COMPLETE 并不等价于 onLowMemory，因而倡议依然要去监听 onLowMemory 回调。

4、低端机防止应用多过程

一个 空过程 也会占用 10MB 内存，低端机应该尽可能减少应用多过程。

针对低端机用户能够推出 4MB 的轻量级版本，现在日头条极速版、Facebook Lite。

5、线下大图片检测

在开发过程中，如果检测到不合规的图片应用（如图片宽度超过 View 的宽度甚至屏幕宽度），应该立即提醒图片所在的 Activity 和堆栈，让开发人员更快发现并解决问题。在灰度和线上环境，能够将异样信息上报到后盾，还能够计算超宽率（图片超过屏幕大小所占图片总数的比例）。

上面，咱们介绍下如何实现对大图片的检测。

惯例实现

继承 ImageView，重写实现计算图片大小。然而侵入性强，并且不通用。

因而，这里咱们介绍一种更好的计划：ARTHook。

ARTHook 优雅检测大图

ARTHook，即 挂钩，用额定的代码勾住原有的办法，以批改执行逻辑，次要能够用于以下四个方面：

• 1）、AOP 编程
• 2）、运行时插桩
• 3）、性能剖析
• 4）、平安审计

具体咱们是应用 Epic 来进行 Hook，Epic 是 一个虚拟机层面，以 Java 办法为粒度的运行时 Hook 框架 。简略来说，它就是 ART 上的 Dexposed，并且它目前  反对 Android 4.0~10.0。

应用步骤

Epic 通常的应用步骤为如下三个步骤：

1、在我的项目 moudle 的 build.gradle 中增加

compile 'me.weishu:epic:0.6.0'

2、继承 XC_MethodHook，实现 Hook 办法前后的逻辑。如 监控 Java 线程的创立和销毁：

class ThreadMethodHook extends XC_MethodHook{
    @Override
    protected void beforeHookedMethod(MethodHookParam param) throws Throwable {super.beforeHookedMethod(param);
        Thread t = (Thread) param.thisObject;
        Log.i(TAG, "thread:" + t + ", started..");
    }
 
    @Override
    protected void afterHookedMethod(MethodHookParam param) throws Throwable {super.afterHookedMethod(param);
        Thread t = (Thread) param.thisObject;
        Log.i(TAG, "thread:" + t + ", exit..");
    }
}

3、注入 Hook 好的办法：

DexposedBridge.findAndHookMethod(Thread.class, "run", new ThreadMethodHook());

晓得了 Epic 的根本应用办法之后，咱们便能够利用它来实现大图片的监控报警了。

我的项目实战

以 Awesome-WanAndroid 我的项目为例，首先，在 WanAndroidApp 的 onCreate 办法中增加如下代码：

DexposedBridge.hookAllConstructors(ImageView.class, new XC_MethodHook() {
        @Override
        protected void afterHookedMethod(MethodHookParam param) throws Throwable {super.afterHookedMethod(param);
        // 1
        DexposedBridge.findAndHookMethod(ImageView.class, "setImageBitmap", Bitmap.class, new ImageHook());
        }
    });

在正文 1 处，咱们 通过调用 DexposedBridge 的 findAndHookMethod 办法找到所有通过 ImageView 的 setImageBitmap 办法设置的切入点 ，其中最初一个参数 ImageHook 对象是继承了 XC_MethodHook 类，其目标是为了  重写 afterHookedMethod 办法拿到相应的参数进行监控逻辑的判断。

接下来，咱们来实现咱们的 ImageHook 类，代码如下所示：

public class ImageHook extends XC_MethodHook {
 
    @Override
    protected void afterHookedMethod(MethodHookParam param) throws Throwable {super.afterHookedMethod(param);
        // 1
        ImageView imageView = (ImageView) param.thisObject;
        checkBitmap(imageView,((ImageView) param.thisObject).getDrawable());
    }
 
    private static void checkBitmap(Object thiz, Drawable drawable) {if (drawable instanceof BitmapDrawable && thiz instanceof View) {final Bitmap bitmap = ((BitmapDrawable) drawable).getBitmap();
            if (bitmap != null) {final View view = (View) thiz;
                int width = view.getWidth();
                int height = view.getHeight();
                if (width > 0 && height > 0) {
                    // 2、图标宽高都大于 view 的 2 倍以上，则正告
                    if (bitmap.getWidth() >= (width << 1)
                        &&  bitmap.getHeight() >= (height << 1)) {warn(bitmap.getWidth(), bitmap.getHeight(), width, height, new RuntimeException("Bitmap size too large"));
                }
                } else {
                    // 3、当宽高度等于 0 时，阐明 ImageView 还没有进行绘制，应用 ViewTreeObserver 进行大图检测的解决。final Throwable stackTrace = new RuntimeException();
                    view.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
                        @Override
                        public boolean onPreDraw() {int w = view.getWidth();
                            int h = view.getHeight();
                            if (w > 0 && h > 0) {if (bitmap.getWidth() >= (w << 1)
                                    && bitmap.getHeight() >= (h << 1)) {warn(bitmap.getWidth(), bitmap.getHeight(), w, h, stackTrace);
                                }
                                view.getViewTreeObserver().removeOnPreDrawListener(this);
                            }
                            return true;
                        }
                    });
                }
            }
        }
    }
 
    private static void warn(int bitmapWidth, int bitmapHeight, int viewWidth, int viewHeight, Throwable t) {
        String warnInfo = "Bitmap size too large:" +
            "\n real size: (" + bitmapWidth + ',' + bitmapHeight + ')' +
            "\n desired size: (" + viewWidth + ',' + viewHeight + ')' +
            "\n call stack trace: \n" + Log.getStackTraceString(t) + '\n';
 
        LogHelper.i(warnInfo);
    }
}

首先，在正文 1 处，咱们 重写了 ImageHook 的 afterHookedMethod 办法，拿到了以后的 ImageView 和要设置的 Bitmap 对象 。而后，在正文 2 处， 如果以后 ImageView 的宽高大于 0，咱们便进行大图检测的解决：ImageView 的宽高都大于 View 的 2 倍以上，则正告 。接着，在正文 3 处， 如果以后 ImageView 的宽低等于 0，则阐明 ImageView 还没有进行绘制，则应用 ImageView 的 ViewTreeObserver 获取其宽高进行大图检测的解决。至此，咱们的大图检测检测组件就曾经实现了。

ARTHook 计划实现小结

• 1）、无侵入性
• 2）、通用性强
• 3）、兼容性问题大，开源计划不能带到线上环境。

6、线下反复图片检测

首先咱们来理解一下这里的 反复图片 所指的概念：即 Bitmap 像素数据完全一致，然而有多个不同的对象存在。

反复图片检测的原理其实就是 应用内存 Hprof 剖析工具，主动将反复 Bitmap 的图片和援用堆栈输入。

应用阐明

应用非常简单，只须要批改 Main 类的 main 办法的第一行代码，如下所示：

// 设置咱们本人 App 中对应的 hprof 文件门路
String dumpFilePath = "//Users//quchao//Documents//heapdump//memory-40.hprof";

而后，咱们执行 main 办法即可在 //Users//quchao//Documents//heapdump 这个门路下看到生成的 images 文件夹，外面保留了我的项目中检测进去的反复的图片。images 目录如下所示：

留神：须要应用 8.0 以下的机器，因为 8.0 及当前 Bitmap 中的 buffer 已保留在 native 内存之中。

实现步骤

具体的实现能够细分为如下三个步骤：

• 1）、首先，获取 android.graphics.Bitmap 实例对象的 mBuffer 作为 ArrayInstance，通过 getValues 获取的数据为 Object 类型 。因为前面计算 md5 须要为 byte[] 类型，所以 通过反射的形式调用 ArrayInstance#asRawByteArray 间接返回 byte[] 数据。
• 2）、而后，依据 mBuffer 的数据生成 png 图片文件。
• 3）、最初，获取堆栈信息 ，间接  应用 LeakCanary 获取 stack 的办法，应用 leakcanary-analyzer-1.6.2.jar 和 leakcanary-watcher-1.6.2.jar 这两个库文件 。并用  反射 的形式调用了 HeapAnalyzer#findLeakTrace 办法。

其中，获取堆栈  的信息也能够间接应用 haha 库来进行获取。这里简略说一下  应用 haha 库获取堆栈的流程，其具体能够细分为八个步骤，如下所示：

• 1）、首先，准备一个曾经存在反复 bitmap 的 hprof 文件。
• 2）、利用 haha 库上的 MemoryMappedFileBuffer 读取 hrpof 文件 [要害代码 new MemoryMappedFileBuffer(heapDumpFile) ]。
• 3）、解析生成 snapshot，获取 heap，这里我只获取了 app heap [要害代码 snapshot.getHeaps(); heap.getName().equals(“app”) ]。
• 4）、从 snapshot 中依据指定 class 查找出所有的 Bitmap Classes [要害代码 snapshot.findClasses(Bitmap.class.getName()) ]。
• 5）、从 heap 中取得所有的 Bitmap 实例 instance [要害代码 clazz.getHeapInstances(heap.getId()) ]。
• 6）、依据 instance 中获取所有的属性信息 Field[]，并从 Field[] 查找出咱们须要的 “mWidth” “mHeight” “mBuffer” 信息。
• 7）、通过 “mBuffer” 属性即可获取到他们的 hashcode 来判断是否是反复图片。
• 8）、最初，通过 instance 中 mNextInstanceToGcRoot 获取整个援用链信息并打印。

7、建设全局的线上 Bitmap 监控

为了建设全局的 Bitmap 监控，咱们必须 对 Bitmap 的调配和回收 进行追踪。咱们先来看看 Bitmap 有哪些特点：

• 1）、创立场景比拟繁多 ：在 Java 层调用 Bitmap.create 或 BitmapFactory 等办法创立，能够封装一层对 Bitmap 创立的接口，留神要  蕴含调用第三方库产生的 Bitmap，这里咱们具体能够应用 ASM 编译插桩 + Gradle Transform 的形式来高效地实现。
• 2）、创立频率比拟低。
• 3）、和 Java 对象的生命周期一样遵从 GC，能够应用 WeakReference 来追踪 Bitmap 的销毁。

依据以上特点，咱们能够 建设一套 Bitmap 的高性价比监控组件：

• 1）、首先，在接口层将所有创立进去的 Bitmap 放入一个 WeakHashMap 中，并记录创立 Bitmap 的数据、堆栈等信息。
• 2）、而后，每隔肯定工夫查看 WeakHashMap 中有哪些 Bitmap 依然存活来判断是否呈现 Bitmap 滥用或透露。
• 3）、最初，如果产生了 Bitmap 滥用或泄露，则将相干的数据与堆栈等信息打印进去或上报至 APM 后盾。

这个计划的 性能耗费很低 ，能够在  正式环境 中进行。然而，须要留神的一点是，正式与测试环境须要采纳不同水平的监控。

3、建设线上利用内存监控体系

要建设线上利用的内存监控体系，咱们须要 先获取 App 的 DalvikHeap 与 NativeHeap，它们的获取形式可归结为如下四个步骤：

• 1、首先，通过 ActivityManager 的 getProcessMemoryInfo => Debug.MemoryInfo 获取内存信息数据。
• 2、而后，通过 hook Debug.MemoryInfo 的 getMemoryStat 办法（os v23 及以上）能够取得 Memory Profiler 中的多项数据 ，进而取得  细分内存的应用状况。
• 3、接着，通过 Runtime 获取 DalvikHeap。
• 4、最初，通过 Debug.getNativeHeapAllocatedSize 获取 NativeHeap。

对于监控场景，咱们须要将其划分为两大类，如下所示：

• 1）、惯例内存监控
• 2）、低内存监控

1、惯例内存监控

依据 斐波那契数列 每隔一段时间（max：30min）获取内存的应用状况 。惯例内存的监控办法有多种实现形式，上面，咱们依照  我的项目晚期 => 壮大期 => 成熟期  的惯例内存监控形式进行  演进式 解说。

我的项目晚期：针对场景进行线上 Dump 内存的形式

具体应用 Debug.dumpHprofData() 实现。

其实现的流程为如下四个步骤：

• 1）、超过最大内存的 80%。
• 2）、内存 Dump。
• 3）、回传文件至服务器。
• 4）、MAT 手动剖析。

然而，这种形式有如下几个毛病：

• 1）、Dump 文件太大，和对象数正相干，能够进行裁剪。
• 2）、上传失败率高，剖析艰难。

壮大期：LeakCanary 带到线上的形式

在应用 LeakCanary 的时候咱们须要 预设透露狐疑点，一旦发现透露进行回传。但这种实现形式毛病比拟显著，如下所示：

• 1）、不适宜所有状况，须要预设狐疑点。
• 2）、剖析比拟耗时，容易导致 OOM。

成熟期：定制 LeakCanary 形式

那么，如何定制线上的 LeakCanary？

定制 LeakCanary 其实就是对 haha 组件  来进行  定制 。haha 库是 square 出品的一款  主动剖析 Android 堆栈的 java 库。

对于 haha 库，它的 根本用法 个别遵循为如下四个步骤：

1、导出堆栈文件

File heapDumpFile = ...
Debug.dumpHprofData(heapDumpFile.getAbsolutePath());

2、依据堆栈文件创建出内存映射文件缓冲区

DataBuffer buffer = new MemoryMappedFileBuffer(heapDumpFile);

3、依据文件缓存区创立出对应的快照

Snapshot snapshot = Snapshot.createSnapshot(buffer);

4、从快照中获取指定的类

ClassObj someClass = snapshot.findClass("com.example.SomeClass");

咱们在实现线上版的 LeakCanary 的时候次要要解决的问题有三个，如下所示：

• 1）、解决 预设狐疑点 时不精确的问题 => 主动找狐疑点。
• 2）、解决掉将 hprof 文件映射到内存中的时候可能导致内存暴涨甚至产生 OOM 的问题 => 对象裁剪，不全副加载到内存。即对生成的 Hprof 内存快照文件做一些优化：裁剪大部分图片对应的 byte 数据 以缩小文件开销，最初，应用 7zip 压缩，个别可 节俭 90% 大小。
• 3）、剖析透露链路慢而导致剖析工夫过长 => 剖析 Retain size 大的对象。

成熟期：实现内存透露监控闭环

在实现了线上版的 LeakCanary 之后，就须要 将线上版的 LeakCanary 与服务器和前端页面联合  起来。具体的  内存透露监控闭环流程 如下所示：

• 1）、当在线上版 LeakCanary 上发现内存透露时，手机将上传内存快照至服务器。
• 2）、此时服务器剖析 Hprof，如果不是零碎起因导致误报则通过 git 失去该最近批改人。
• 3）、最初将内存透露 bug 单提交给负责人。该负责人通过前端实现的 bug 单零碎即可看到本人新增的 bug。

此外, 在实现 图片内存监控  的过程中，应留神  两个关键点，如下所示：

• 1）、在线上能够依照 不同的零碎、屏幕分辨率  等纬度去  剖析图片内存的占用状况。
• 2）、在 OOM 解体时，能够将 图片总内存、Top N 图片占用内存  写入  解体日志。

2、低内存监控

对于低内存的监控，通常有两种形式，别离如下所示：

• 1、利用 onTrimMemory / onLowMemory 监听系统回调的物理内存正告。
• 2、在后盾起一个服务定时监控零碎的内存占用，只有超过虚拟内存大小最大限度的 90% 则间接触发内存正告。

3、内存监控指标

为了精确掂量内存性能，咱们须要引入一系列的内存监控指标，如下所示：

1）、产生频率

2）、产生时各项内存应用情况

3）、产生时 App 的以后场景

4）、内存异样率

内存 UV 异样率 = PSS 超过 400MB 的 UV / 采集 UV
PSS 获取：调用 Debug.MemoryInfo 的 API 即可

如果呈现 新的内存使用不当或内存透露  的场景，这个指标会有所  上涨。

5）、触顶率

内存 UV 触顶率 = Java 堆占用超过最大堆限度的 85% 的 UV / 采集 UV

计算触顶率的代码如下所示：

long javaMax = Runtime.maxMemory();
long javaTotal = Runtime.totalMemory();
long javaUsed = javaTotal - runtime.freeMemory();
float proportion = (float) javaUsed / javaMax;

如果超过 85% 最大堆  的限度，GC 会变得更加  频发，容易造成 OOM 和 卡顿。

4、小结

在具体实现的时候，客户端  尽量只负责  上报数据 ，而  指标值的计算  能够由  后盾  来计算。这样便能够通过  版本比照  来 监控 是否有 新增内存问题 。因而， 建设线上内存监控的残缺计划  至多须要蕴含以下 四点：

• 1）、待机内存、重点模块内存、OOM 率。
• 2）、整体及重点模块 GC 次数、GC 工夫。
• 3）、加强的 LeakCanry 自动化内存透露剖析。
• 4）、低内存监控模块的设置。

4、建设全局的线程监控组件

每个线程初始化都须要 mmap 肯定的栈大小，在默认状况下初始化一个线程须要 mmap 1MB 左右的内存空间。

在 32bit 的利用中有 4g 的 vmsize，理论 能应用的有 3g+，这样一个过程 最大能创立的线程数  能够达到 3000 个，然而，linux 对每个过程可创立的线程数也有肯定的限度（/proc/pid/limits），并且， 不同厂商也能批改这个限度，超过该限度就会 OOM。

因而，对线程数量的限度，在肯定水平上能够 无效地防止 OOM 的产生 。那么，实现一套  全局的线程监控组件  便是  迫不及待 的了。

全局线程监控组件的实现原理

在线下或灰度的环境下通过一个定时器每隔 10 分钟 dump 出利用所有的线程相干信息，当线程数超过以后阈值时，则将以后的线程信息上报并预警。

5、GC 监控组件搭建

通过 Debug.startAllocCounting 来监控 GC 状况，留神有肯定 性能影响。

在 Android 6.0 之前  能够拿到  内存调配次数和大小以及 GC 次数，其对应的代码如下所示：

long allocCount = Debug.getGlobalAllocCount();
long allocSize = Debug.getGlobalAllocSize();
long gcCount = Debug.getGlobalGcInvocationCount();

并且，在 Android 6.0 及之后  能够拿到  更精准 的 GC 信息：

Debug.getRuntimeStat("art.gc.gc-count");
Debug.getRuntimeStat("art.gc.gc-time");
Debug.getRuntimeStat("art.gc.blocking-gc-count");
Debug.getRuntimeStat("art.gc.blocking-gc-time");

对于 GC 信息的排查 ，咱们个别关注  阻塞式 GC 的次数和耗时 ，因为它会  暂停线程 ，可能导致利用产生  卡顿 。倡议  仅对重度场景应用。

6、建设线上 OOM 监控组件：Probe

美团的 Android 内存透露自动化链路剖析组件  Probe 在 OOM 时会生成 Hprof 内存快照，而后，它会通过  独自过程  对这个  文件  做进一步  剖析。

Probe 组件的缺点及解决方案

它的毛病比拟多，具体为如下几点：

• 1、在解体的时候生成内存快照容易导致二次解体。
• 2、局部手机生成 Hprof 快照比拟耗时。
• 3、局部 OOM 是由虚拟内存有余导致。

在实现自动化链路剖析组件 Probe 的过程中次要要解决两个问题，如下所示：

1、链路剖析工夫过长

• 1）、应用 链路归并 ：将具备  雷同层级与构造  的链路进行  合并。
• 2）、应用 自适应扩容法 ： 通过一直比拟现有链路和新链路，联合扩容因子，逐步欠缺为残缺的透露链路。

2、剖析过程占用内存过大

剖析过程占用的内存  跟  内存快照文件的大小  不成正相干，而跟  内存快照文件的 Instance 数量  呈  正相干 。所以在开发过程中咱们应该  尽可能排除不须要的 Instance 实例。

Prope 剖析流程揭秘

Prope 的 总体架构图 如下所示：

而它的整个剖析流程具体能够细分为八个步骤，如下所示：

1、hprof 映射到内存 => 解析成 Snapshot & 计数压缩：

解析后的 Snapshot 中的 Heap 有四种类型，具体为：

• 1）、DefaultHeap
• 2）、ImageHeap
• 3）、App Heap：包含 ClassInstance、ClassObj、ArrayInstance、RootObj。
• 4）、System Heap

解析完  后应用了  计数压缩策略 ，对  雷同的 Instance 应用 计数 ，以  缩小占用内存。超过计数阈值的须要计入计数桶（计数桶记录了 抛弃个数 和 每个 Instance 的大小）。

2、生成 Dominator Tree。

3、计算 RetainSize。

4、生成 Reference 链 && 根底数据类型加强:

如果对象是 根底数据类型 ，会将  本身的 RetainSize 累加到父节点  上，将  怀疑对象  替换为它的  父节点。

5、链路归并。

6、计数桶弥补 & 根底数据类型和父节点交融：

应用计数弥补策略计算 RetainSize，次要是 判断对象是否在计数桶中，如果在的话则将 抛弃的个数和大小弥补到对象上，累积计算 RetainSize，最初对 RetainSize 排序以查找可疑对象。

7、排序扩容。

8、查找泄露链路。

7、实现 单机版 的 Profile Memory 自动化内存剖析

在配置的时候要留神两个问题：

• 1、liballoc-lib.so 在构建后工程的 build => intermediates => cmake 目录下。将对应的 cpu abi 目录拷贝到新建的 libs 目录下。
• 2、在 DumpPrinter Java 库的 build.gradle 中的 jar 闭包中须要退出以下代码以辨认源码门路:
  sourceSets.main.java.srcDirs = [‘src’]

应用步骤

具体的应用步骤如下所示：

1、首先，点击”开始记录“按钮能够看到触发对象调配的记录，阐明对象曾经开始记录对象的调配，log 如下所示：

12-26 10:54:03.963 30450-30450/com.dodola.alloctrack I/AllocTracker: ====current alloc count 388=====

2、而后，点击屡次”生成 1000 个对象“按钮，当对象达到设置的最大数量的时候触发内存 dump，会失去保留数据门路的日志。如下所示：

12-26 10:54:03.963 30450-30450/com.dodola.alloctrack I/AllocTracker: ====current alloc count 388=====
12-26 10:56:45.103 30450-30450/com.dodola.alloctrack I/AllocTracker: saveARTAllocationData write file to /storage/emulated/0/crashDump/1577329005

3、此时，能够看到数据保留在 sdk 下的 crashDump 目录下。

4、接着，通过 gradle task :buildAlloctracker 工作编译出寄存在 tools/DumpPrinter-1.0.jar 的 dump 工具，而后采纳如下命令来将数据解析 到 dump_log.txt 文件中。

java -jar tools/DumpPrinter-1.0.jar dump 文件门路 > dump_log.txt

5、最初，就能够在 dump_log.txt 文件中看到解析进去的数据，如下所示：

Found 4949 records:
tid=1 byte[] (94208 bytes)
    dalvik.system.VMRuntime.newNonMovableArray (Native method)
    android.graphics.Bitmap.nativeCreate (Native method)
    android.graphics.Bitmap.createBitmap (Bitmap.java:975)
    android.graphics.Bitmap.createBitmap (Bitmap.java:946)
    android.graphics.Bitmap.createBitmap (Bitmap.java:913)
    android.graphics.drawable.RippleDrawable.updateMaskShaderIfNeeded (RippleDrawable.java:776)
    android.graphics.drawable.RippleDrawable.drawBackgroundAndRipples (RippleDrawable.java:860)
    android.graphics.drawable.RippleDrawable.draw (RippleDrawable.java:700)
    android.view.View.getDrawableRenderNode (View.java:17736)
    android.view.View.drawBackground (View.java:17660)
    android.view.View.draw (View.java:17467)
    android.view.View.updateDisplayListIfDirty (View.java:16469)
    android.view.ViewGroup.recreateChildDisplayList (ViewGroup.java:3905)
    android.view.ViewGroup.dispatchGetDisplayList (ViewGroup.java:3885)
    android.view.View.updateDisplayListIfDirty (View.java:16429)
    android.view.ViewGroup.recreateChildDisplayList (ViewGroup.java:3905)

8、搭建线下 Native 内存透露监控体系

在 Android 8.0 及之后，能够应用 Address Sanitizer、Malloc 调试和 Malloc 钩子 进行 native 内存剖析，

对于线下 Native 内存透露监控的建设，次要针对 是否能重编 so 的状况 来记录调配的内存信息。

针对无奈重编 so 的状况

• 1）、首先，应用 PLT Hook 拦挡库的内存调配函数 ，而后，重定向到咱们本人的实现后去  记录调配的 内存地址、大小、起源 so 库门路 等信息。
• 2）、最初，定期 扫描调配与开释 的配对内存块，对于 不配对的调配 输入上述记录的信息。

针对可重编的 so 状况

• 1）、首先，通过 GCC 的 ”-finstrument-functions“ 参数给 所有函数插桩 ，而后， 在桩中模仿调用栈的入栈与出栈操作。
• 2）、接着，通过 ld 的 ”–warp“ 参数 拦挡内存调配和开释函数 ，重定向到咱们本人的实现后 记录调配的 内存地址、大小、起源 so 以及插桩调用栈此刻的内容。
• 3）、最初，定期扫描调配与开释是否配对，对于不配对的调配输入咱们记录的信息。

9、设置内存兜底策略

设置内存兜底策略的目标，是为了 在用户无感知的状况下，在靠近触发零碎异样前，抉择适合的场景杀死过程并将其重启，从而使得利用内存占用回到失常状况。

通常执行内存兜底策略时至多须要满足六个条件，如下所示：

• 1）、是否在主界面退到后盾且位于后盾工夫超过 30min。
• 2）、以后工夫为早上 2~5 点。
• 3）、不存在前台服务（告诉栏、音乐播放栏等状况）。
• 4）、Java heap 必须大于以后过程最大可调配的 85% || native 内存大于 800MB。
• 5）、vmsize 超过了 4G（32bit）的 85%。
• 6）、非大量的流量耗费（不超过 1M/min）&& 过程无大量 CPU 调度状况。

只有在满足了以上条件之后，咱们才会去 杀死以后主过程并通过 push 过程从新拉起及初始化。

10、更深刻的内存优化策略

除了在 Android 性能优化之内存优化 => 优化内存空间中解说过的一些惯例的内存优化策略以外，在上面列举了一些更深刻的内存优化策略。

1、使 bitmap 资源在 native 中调配

对于 Android 2.x 零碎，应用反射将 BitmapFactory.Options 外面暗藏的 inNativeAlloc 关上。

对于 Android 4.x 零碎，应用或借鉴 Fresco 将 bitmap 资源在 native 中调配的形式。

2、图片加载时的降级解决

应用 Glide、Fresco 等图片加载库，通过定制，在加载 bitmap 时，若产生 OOM，则应用 try catch 将其捕捉，而后革除图片 cache，尝试升高 bitmap format（ARGB8888、RGB565、ARGB4444、ALPHA8）。

须要留神的是，OOM 是能够捕捉的，只有 OOM 是由 try 语句中的对象申明所导致的，那么在 catch 语句中，是能够开释掉这些对象，解决 OOM 的问题的。

3、前台每隔 3 分钟去获取以后利用内存占最大内存的比例，超过设定的危险阈值（如 80%）则被动开释利用 cache（Bitmap 为大头），并且显示地除去利用的 memory，以减速内存收集的过程。

计算以后利用内存占最大内存的比例的代码如下：

max = Runtime.getRuntime().maxMemory();
available = Runtime.getRuntime.totalMemory() - Runtime.getFreeMemory();
ratio = available / max;

显示地除去利用的 memory，以减速内存收集过程的代码如下所示：

WindowManagerGlobal.getInstance().startTrimMemory(TRIM_MEMORY_COMPLETE);

4、因为 webview 存在内存零碎透露，还有 图库占用内存过多 的问题，能够采纳独自的过程。

5、当 UI 暗藏时开释内存

当用户切换到其它利用并且你的利用 UI 不再可见时，应该开释利用 UI 所占用的所有内存资源。这可能显著减少零碎缓存过程的能力，可能晋升用户体验。

在所有 UI 组件都暗藏的时候会接管到 Activity 的 onTrimMemory() 回调并带有参数 TRIM_MEMORY_UI_HIDDEN。

6、Activity 的兜底内存回收策略

在 Activity 的 onDestory 中递归开释其援用到的 Bitmap、DrawingCache 等资源，以升高产生内存透露时对利用内存的压力。

7、应用相似 Hack 的形式修复零碎内存透露

LeakCanary 的 AndroidExcludeRefs 列出了一些因为零碎起因导致援用无奈开释的例子，可应用相似 Hack 的形式去修复。

8、当利用应用的 Service 不再应用时应该销毁它，倡议应用 IntentServcie。

9、审慎应用第三方库，防止为了应用其中一两个性能而导入一个大而全的解决方案。

很感谢您浏览这篇文章，心愿您能将它分享给您的敌人或技术群，这对我意义重大。

文章转自 https://juejin.cn/post/6844904099998089230 如有侵权，请分割删除。

相干视频举荐：

Android 性能优化学习【一】：APK 瘦身优化_哔哩哔哩_bilibili

Android 性能优化学习【二】：APP 启动速度优化_哔哩哔哩_bilibili

Android 性能优化学习【三】：如何解决 OOM 问题_哔哩哔哩_bilibili

Android 性能优化学习【四】：UI 卡顿优化_哔哩哔哩_bilibili