讲一讲 Android 内存优化的小秘密

/   内存的划分   /

procrank是一个adb的root指令，能够查询内存的划分：

• VSS - Virtual Set Size虚拟耗用内存（包含共享库占用的内存）
• RSS- Resident Set Size实际使用物理内存（包含全部共享库占用的内存）
• PSS- Proportional Set Size实际使用的物理内存（按比例分配共享库占用的内存）
• USS- Unique Set Size进程独自占用的物理内存（不包含共享库占用的内存）

那么最值得关注的是PSS和USS，咱们能够用dumpsys meminfo来查询（无需root权限）

dumpsys meminfo查询pss划分

重点字段解读：

• Native Heap - Native堆内存
• Dalvik Heap - Dalvik虚拟机内存，Dalvik虚拟机代码在 libdvm.so 主要负责运行时dex解析成机器码（android 5.0+ ART 中已经取消 Dalvik 虚拟机，这里任然出现 Dalvik 目测是没改过来）
• .art mmap - Android RunTime映射内存，art代码在 android_runtime.so, mmap（是linux C的一个函数接口，用来作内存映射）
• Private Dirty - 进程独占的内存，内存已经被本进程修改过，只能被本身进程使用
• Private clean - 进程独占的内存，内存是映射过来的，没有作修改，能够置换给到其余进程使用
• java heap - Dalvik heap（dirty+ clean） + art heap（dirty + clean）

经过上面图片可得launcher app占用的内存是250M，大部份内存在Native Heap、code、graphics，那如何分析和解决，咱们下面讲。

android studio profile是ide提供出来的分类：

• Total - 整个应用占据的总内存
• Java - java堆占据的内存
• Native - Native层调用malloc/new（C/C++）占据的内存
• Graphics - 图形缓冲区队列向屏幕显示像素，（若是没有用到OpenGL或者不是游戏，能够直接忽略）
• Stack - 线程栈占据的内存
• Code - dex+so库占据的内存
• Others - 未解之谜

JMM 分类

• 方法区 - 存放常量和静态变量区域
• java堆 - new出来的对象内存都放在这里面
• java栈 - 方法中执行的基本类型变量 和 变量引用都在栈中。（类中的内部成员属性的引用在堆中）
• native栈 - 同java栈，指针引用都在native栈中
• 程序计数器 - 做用是多线程切换记录上一个线程执行到的点。譬如：A线程 切换到B线程。程序计数器要记录A线程 已经执行到哪一行代码。接着cpu切换到B线程，再切换回来A线程的时候，cpu才知道从A线程哪一行代码继续执行

注意：

• java栈、native栈、程序计数器是线程私有
• java堆、方法区是线程共有的

/   Java内存优化   /

Java内存优化	内存泄漏	内存抖动	大内存对象使用
发生的场景	单例、匿名内部类、接口忘记释放 ...	String拼接、循环内重复生成对象 ...	HashMap、ArrayList ...

Java检查泄漏 - LeakCanary使用

LeakCanary结果分析

LeakCanary能够检查Activity Fragment View界面的泄漏问题。经过接入LeakCanary跑上monkey接着静等java内存泄漏的出现：

经过上图能够知道SearchActivity被HistorySource.mContext持有，HistorySource是一个单例，而后最顶层的Thread.contextClassLoader就是GC root（注意：静态变量不是GC root），Thread.contextClassLoader是PathClassLoader类，只要把 SearchActivity的context换成Application那就解决了。

Android中GC root有哪些：

• 被System ClassLoader加载过的类，继而生成的对象，譬如rt.jar中的类

• PathClassLoader、DexClassLoader

• 活着的线程Thread

• 函数方法中的局部变量（跑在线程中的）

• JNI中的全局变量和局部变量

LeakCanary的核心原理：

• 经过registerActivityLifecycleCallbacks()监听各个Activity的退出

• Activity退出后，拿到Activity的对象封装成KeyedWeakReference弱引用对象。

• 经过手动Runtime.getRuntime().gc();垃圾回收

• 经过removeWeaklyReachableReferences()手动移除已经被回收的对象

• 经过gone()函数判断是否被移除，若是移除了，说明Activity 已经没有其余强引用 在引用它，没有泄露

• 若是没有移除，经过android原生接口Debug.dumpHprofData()，把Hprof文件搞下来，经过haha这个第三方库去解析是否有指定Activity的残留。（haha是分析Hprof的java库）

小结

那么LeakCanary只能解决界面上的泄漏，其余内存上的优化是作不到的，譬如：线程池的泄漏，内存的抖动，大对象的滥用.. 那么就须要更为强大的工具MAT了。

内存检测工具MAT

MAT是分析内存文件hprof的工具。

抓取步骤

跑几分钟monkey后，退回应用主界面，手动屡次点击GC按钮，把可回收的回收掉，为了剔除脏数据。经过Android Studio的Profile把内存文件hprof给dump下来。

• 进入Android SDK目录：G:\AndroidSDK\platform-tools
• 把dump下载的文件memory-20190828T162317.hprof拖进platform-tools文件夹
• 敲入cmd命令hprof-conv memory-20190828T162317.hprof 1.hprof转成可被MAT识别的1.hprof文件
• 使用MAT打开1.hprof

分析内存完成以上步骤以后的结果图。

• 直接点击左上角Histogram查看内存分布
• objects - 对象数目
• shallow heap - 对象自身实际占用的堆大小
• retained heap - 对象被回收后能释放多少内存
• Inspector - 能够看到对象的GC Root是谁

• with outgoing references - 表示的是 当前对象，引用了内部哪些成员对象
• with incoming references - 表示的是 当前对象，被外部哪些对象应用了（重点操做）

• merge shortest paths to gc roots - 从GC roots到一个或一组对象的公共路径
• exclude all phantom/weak/soft etc. references - 排除一些类型的引用（如软引用、弱引用、虚引用），留下强引用

为了不查看太多并非强相关的对象，直接从本应用的java 类入手，MAT 也提供正则式过滤，直接输入.com.vd.（本应用 packageName）去过滤，结果就很是明显，整个应用本身写的对象占用的内存都在这里。从大的对象下手，是否这个对象有存在的意义，是否须要占这么大的一个内存。是否能够对其作相应的处理。

MAT提供了更加方便的OQL查询，能够找到指定一个名字的对象，包括能够根据自己java对象的成员属性来作条件语句。譬如上图我找长宽都大于100px的图片都有哪些。能够把大图片揪出来。

小结

可先用LeakCanary跑出明显的内存泄漏，再用MAT检查整个应用的内存分布情况，去优化该优化的Java堆内存。

/   Native内存优化   /

native 内存优化	malloc_debug	heapsnap	DDMS
root权限	须要	须要	不须要
环境	python	jni	须要使用sdk18 的 tools/ddms.bat(sdk 18以后就被剔除了)

• malloc_debug是官方推荐的一种方法，目前效果还不错

• heapsnap 是一个能够跑在Adnroid的C库github开源库 ，目前只能查询内存泄漏。并且编译不过，缘由是缺乏了一些库。在它基础上我整合了一份编译成功，有兴趣点击这里

• DDMS目前被遗弃，在android 9.0没整成功，放弃。

malloc_debug步骤开启malloc debug模式，打开cmd窗口输入。

//查询全部内存
adb shell setprop wrap.packagename '"LIBC_DEBUG_MALLOC_OPTIONS=backtrace logwrapper"'

//查询内存泄漏
adb shell setprop wrap.packagename '"LIBC_DEBUG_MALLOC_OPTIONS=leak_track logwrapper"'
复制代码

• 关掉自身应用，再打开，monkey跑起来
• 经过adb shell dumpsys meminfo com.all.videodownloader.videodownload查到pid为2968

经过adb shell am dumpheap -n <PID_TO_DUMP> /data/local/tmp/heap.txt把文件抓取出来到/data/local/tmp/heap.txt。

把native内存文件拷贝出来，等下分析。

使用python分析

搭建环境

• 下载native_heapdump_viewer.py

• python编译器我选择了PyCharm

• 新建项目，把native_heapdump_viewer.py和 heap.txt,放到同一个目录，以下图

修改python代码修改native_heapdump_viewer.py 代码中NDK配置地方：

resByte = subprocess.check_output(["G:/AndroidNDK/android-ndk-r17/toolchains/aarch64-linux-android-4.9/prebuilt/windows-x86_64/bin/aarch64-linux-android-objdump", "-w", "-j", ".text", "-h", sofile])
复制代码

p = subprocess.Popen(["G:/AndroidNDK/android-ndk-r17/toolchains/aarch64-linux-android-4.9/prebuilt/windows-x86_64/bin/aarch64-linux-android-addr2line", "-C", "-j", ".text", "-e", sofile, "-f"], stdout=subprocess.PIPE, stdin=subprocess.PIPE)
复制代码

替换def init(self):函数中的部分代码，把下面代码：

if len(extra_args) != 1:
      print(self._usage)
      sys.exit(1)
复制代码

替换为：

self.symboldir = "C:/Users/chaojiong.zhang/Documents/AndroidStudio/DeviceExplorer/xiaomi-mi_8-4b429b4"
extra_args.append("dump.txt")
复制代码

self.symboldir - 就是dump.txt 里面的内存地址都须要 经过so库来查找对应的是哪个函数。而so存放的父路径地址就是self.symboldir，那么也就是说须要把 手机上的/system/lib6四、/vendor/lib64/整个 文件夹pull 下来到电脑上，譬如这里是pull到C:/Users/chaojiong.zhang/Documents/AndroidStudio/DeviceExplorer/xiaomi-mi_8-4b429b4。

在def main():函数插入部分代码在函数第一行插入和最后一行插入如下代码，目的是直接把结果log输出到test.txt能够直接查看。

def main(): sys.stdout= open("test.txt", "w")

 //...
sys.stdout.close()
复制代码

跑起来看看。

malloc_debug内存文件分析

字段解读

• BYTES- 占用的内存大小单位byte

• %TOTAL - 占总 native 内存百分比

• %PARENT - 占父帧内存百分比

• COUNT - 调用了多少次

• ADDR- 内存地址

• LIBRARY - 占用的内存所属哪个 so 库

• FUNCTION- 占用的内存所属哪个方法

• LOCATION - 占用的内存所属哪一行

内存信息分析一

10285756  58.29%  99.95%       49     eac0b276 /system/lib/libhwui.so android::Bitmap::allocateHeapBitmap(SkBitmap*)
复制代码

能够看得出来 allocateHeapBitmap方法占用了，10M左右的内存，占总native内存 58.29%，占父帧 99.95% （意思是：A-> B ，A方法调用B方法，A方法总共占用了10M，其中9.9M是在B方法中申请的，那么%PARENT 就是99%），调用了49次，动做发生在libhwui.so中的 android::Bitmap::allocateHeapBitmap方法。下面是allocateHeapBitmap被调用的流程：

BitmapFactory.decodeResource -> BitmapFactory.nativeDecodeStream ->BitmapFactory.cpp 中 nativeDecodeStream() -> doDecode() -> SkBitmap.tryAllocPixels() -> ... -> android::Bitmap::allocateHeapBitmap()
复制代码

Bitmap.createBitmap -> nativeCreate() -> Bitmap.cpp 中的 nativeCreate() -> GraphicsJNI.cpp zhong de allocateJavaPixelRef() -> ... -> android::Bitmap::allocateHeapBitmap() 
复制代码

也就是说java层的bitmap 建立都会跑到allocateHeapBitmap这个函数。那么上面这个占用了10M的 allocateHeapBitmap，到底是java层哪一个类调用下来的，这个目前是无解（包括最近华为的方舟环境平台DevEco也不行），只能在java层去全盘查询了，哪些图片使用了较多的内存。内存信息分析二

• WebViewGoogle.apk占用了10M的内存，WebViewGoogle.apk就是应用使用的WebView，android 5.0以前做为模块存在于frameworks/base目录下，并提供接口。android 5.0以后变成了编译为一个独立的apk，包名是 com.android.webview。检查全部的WebView使用状况，譬如：若是场景容许，使用完毕是否有 调用WebView.clearCache()

• boot-framework.oat 占了5M ，Android framework代码经过dex2oat转成的oat二进制文件（机器码），无需优化

• libandroid_runtime.so 占了 5M，虚拟机内存，属于按比例划分共享库，无需优化

小结

native内存目前没法很清晰的定位到对应的java层代码，无解。只能看个大概，而后有目的性去排查某个类，或者某个模块。

/   graphics内存优化   /

若应用没有本身接入OpenGL/ GL surfaces/ GL textures开源库，来绘制图形，可没必要理会。毕竟已经超出android应用工程师的范围了。

/   stack内存优化   /

解决栈溢出

死循环问题

JDK 1.8以前的HaskMap，避免使用多线程形成死循环问题。

递归问题

避免深层次的递归问题，较深层次的递归可采用尾递归的方法。递归的退出，最好用标识位退出。或者经过线程interrupt()，isInterrupted()去退出递归，确保递归正确退出。递归中若是有Thread.sleep ,要注意中断被消费问题。

Intenet问题

对于Intent传递大对象，或者ArrayList，Intent的上限是505K 。解决方案：

• 通常经过 static 持有须要传递的对象解决。

• 把跳转的页面写成 fragment ，数据能够不须要传递也可获取

• 经过EventBus RxBus（原理都是经过全局单例来传递）

• 经过ObjectCache把对象转成json串，保存到本地，获取时候序列化为对象。

解决重复生成局部变量

避免在循环内重复生成局部变量

 private void memoryShake() {
        ArrayList<Integer> shakes = new ArrayList<>();
        for (int i = 0; i < 100; i++) {
            Integer shake = new Integer(i);
            shakes.add(shake);
        }
    }

    private void memoryShake1() {
        ArrayList<Integer> shakes = new ArrayList<>();
        Integer shake;
        for (int i = 0; i < 100; i++) {
            shake = new Integer(i);
            shakes.add(shake);
        }
    }
复制代码

memoryShake()会在循环内生成100个shake局部变量+100个局部变量的引用，memoryShake1()会在循环内生成100个shake局部变量+1个局部变量的引用，一个对象引用在64bit的环境是8byte 。100*8 = 800 byte = 0.8KB。

String使用问题

循环内字符的拼接不要使用+符号，（使用+符号，编译成字节码后，循环内会生成StringBuilder对象去拼接）。正确应该使用StringBuffer（线程安全）或者StringBuilder（线程不安全）。

/   code内存优化   /

code内存消耗主要是：so库，dex，ttf。

以上三种文件都是要加载到运行内存才能被解析运行，因此它们的体积要算进自身的应用内存中。so库，能够经过STRIP去掉一些符号表和调试信息，在Android.mk加入 LOCAL_STRIP_MODULE:= true，便可。

dex，是java代码编译成的字节码，没混淆的apk中的dex会大不少，混淆后的dex 会小不少，因此debug包的内存占用会大于release包。Android Studio 3.3带了了一个新特性R8压缩，能够在gradle.properties加入 android.enableR8=true ，减少dex包的体积（完美兼容现有混淆）。固然还要剔除自身应用的无用代码，可以使用Android Studio Menu > Refactor > Remove Unused Resources进行排查，这里再也不详细展开。

ttf - 若是应用中只用到部分字体，可经过FontZip提取使用的字体。