一、分析一个Hello World App中bitmap对象的分布

使用BitmapAnalyzer分析一个Android Hello World App时你会dump出400+张图片，什么是BitmapAnalyzer？BitmapAnalyzer是一个自动分析Android dump heap中bitmap对象的工具，详细请看《Android Bitmap的内存大小是如何计算的？》这篇文章的介绍。

分析仔细看一下可以发现，上图中sPreloadedDrawables数组所引用的预加载Drawable就会占用10M以上的内存空间。这些都是Android系统的主题资源图片，为什么会有这么多主题资源被加载？不需要的无用的系统资源能否避免被加载？那么要如何做到？

二、为什么有这么多系统资源被加载？

使用Android Studio(简称AS)的monitor工具dump内存如上图所示，hprof中的内存信息分为三类，分别是App heap，Image heap，Zygote heap。App heap很好理解，就是应用进程独占的内存空间，在应用中创建的对象都会在App heap上。而在Dalvik虚拟机上运行的app，只有App heap和Zygote heap，并没有Image heap。Android官网文档的三者的解释是：

1
2
3
4
5

App heap - The heap used by the current app.

Image heap - The memory mapped copy of the current app on disk.

Zygote heap - The common set of libraries and runtime classes and data that all apps are forked from. The zygote space is created during device startup and is never allocated into.

Zygote机制总的来说是app_process启动Zygote并创建第一个虚拟机进程，Zygote启动时会预加载所有需要的Java classes和”必要的”资源文件，这些资源文件就包括我们在hprof文件中看到的被sPreloadedDrawables所直接引用的Bitmap资源。应用进程都是从Zygote中fork出来的，所以所有的应用进程都会包含上面提到的资源文件。这些资源的拷贝可以看成浅拷贝，并不是真正的内存copy，而是作为进程间的共享内存使用。详细的可以查看《Zygote》这篇文章。

三、强制清除未使用的系统资源图片会怎样？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

private void clearPreloadedDrawables() {
    try {
        Field mFieldPreloadedDrawables = getField(Resources.class, "sPreloadedDrawables");
        if (mFieldPreloadedDrawables != null) {
            mFieldPreloadedDrawables.setAccessible(true);

            boolean access = mFieldPreloadedDrawables.isAccessible();
            if (!access) {
                mFieldPreloadedDrawables.setAccessible(true);
            }

            if (Build.VERSION.SDK_INT <= 17) {
                LongSparseArray<Drawable.ConstantState> dArray = (LongSparseArray<Drawable.ConstantState>) mFieldPreloadedDrawables.get(getResources());
                if (dArray != null) {
                    dArray.clear();
                }

                // dArray.put(1, createDrawableConstant());
            } else if (Build.VERSION.SDK_INT >= 18) {
                LongSparseArray<Drawable.ConstantState>[] dArray = (LongSparseArray<Drawable.ConstantState>[]) mFieldPreloadedDrawables.get(getResources());
                if (dArray != null) {
                    for (int i = 0; i < dArray.length; i++) {
                        if (dArray[i] != null) {
                            dArray[i].clear();
                            // dArray[i].put(1, createDrawableConstant());
                        }
                    }
                }
            }

            mFieldPreloadedDrawables.setAccessible(true);
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
}

当通过上述clearPreloadedDrawables函数清除sPreloadDrawable对这些资源的强引用，然后使用Android Studio的monitor工具发现，gc以后App heap发生了断崖式的内存回收，并且使用adb shell dumpsys meminfo命令可以发现Heap Alloc和Heap Size都发生了显著的减小，但Pss total并没有显著变化。这里的理解是PSS = Private RAM + 按比例计算的Shared RAM，这两部分都没有发生显著变化，所以PSS Total没有变化。

那请问，上面👆的内存清理有意义吗？Heap allocated较少了10M，但PSS并没有明显的变化，给我的感觉就像大家在吃大锅饭，我只吃了1碗，别人吃了10碗，付钱的时候却是AA，甚至可能我付的还更多一些。你说你是不是萨？

四、Copy-On-Write(COW)

Zygote heap是系统共享内存heap，这里我尝试修改sPreloadDrawable对应数据时，如下图所示，系统默认预加载399张资源图片，当手动插入一张新的图片到缓存后，缓存大小变成了400。但让我觉得诡异的是，不是说Android系统使用COW机制吗？为啥插入前后sPreloadDrawable相关的内存地址根本没有变化？

我的理解是在fork子进程的时候并不会真正拷贝父进程内存数据，而是子进程的虚拟内存空间指向父进程的物理内存空间。子进程和父进程的虚拟空间不同，但物理空间是同一个。当子进程需要重写共享内存数据时，系统才会为子进程分配响应的物理内存。这里的虚拟内存空间对应用程序来说就是逻辑地址，对于CPU来说就是线性地址。

五、总结

回到之前思考的几个问题：

• 为什么会有这么多主题资源被加载？
  这些主题资源是系统启动时Zygote预加载的系统资源，Zygote认为这些资源每个App都会用到，特别是5.0+的系统会达到400+的默认theme图片，占用10M+的内存空间，不过这些内存是系统共享的你用或不用他们都在那里。改变应用的主题样式并不会改变sPreloadDrawable的加载内容。
• 不需要的无用资源能否避免被加载？
  这些默认系统资源无法避免被系统预加载，但是不同ROM厂商针对这些资源的看法差别还是很大的，根据测试的情况看，三星的预加载资源比源码的还要多，清空sPreloadDrawable也不能减少Heap allocte的大小。相反锤子手机对这些预加载资源的作用倒是不太看好，在锤子坚果上看到的预加载资源就很少，几乎可以忽略不计。而在Android 5.0以下的系统版本，这块预加载的资源也不是很夸张。
• 清空预加载资源对应用内存有无优化作用？
  说下个人看法，如果你的应用分为UI进程和后台服务进程。在UI进程清除系统预加载资源可能并不是明智的选择，为啥？因为这是一件吃力未必讨好的事情，虽然这10M空间你并没有使用，但系统并没有领情，反而当你想要在使用系统资源的时候，那这些资源就会完全算到你的头上。那样反而会造成应用进程内存的上升。为啥？清除系统的共享内存后，再加载系统资源时分配的就是应用的私有内存了。
  如果是后台服务进程，打死也不会用到系统主题资源的情况下，清除预加载资源为什么不是对自己有利的事情呢？因为这样做确实让Heap变小了呀！

当然以上都是个人的理解，如有理解错误，恳请能够指出。对于如何获取Java对象的物理地址，我还没有找到更好的办法，所以暂时还没有实践验证COW。

临帖顿首，不知所言，2017.4.26日夜。

参考

HPROF Viewer and Analyzer

Manage Your App’s Memory

深入理解 Zygote

Linux写时拷贝技术(copy-on-write)

linux虚拟地址转物理地址

作者：乐蛙科技高级研发经理 易宁

Android应用普遍没有iOS应用流畅，这与Android应用是运行在Java虚拟机上有很大的关系，而关系最大的恐怕就是Java虚拟机上的Garbage Collection（GC）了。Java语言提供了自动内存管理，垃圾对象会在GC过程中自动被释放。这提供了开发效率，使开发者能集中精力在业务逻辑上；但天下没有免费的午餐，你写的Android应用的某些性能上的问题很可能就是GC导致的。

下面是一段非常简单的Java语句：

1

byte[] data = new byte[512 * 512 * 4];

这条语句申请了一块大小相等于512*512大小图片的内存。执行这条语句会消耗多少时间呢？0+ms吗？基本没有性能影响吗？

Read More

原文地址：Zygote https://anatomyofandroid.com/2013/10/15/zygote/

Zygote（受精卵）是一个启动应用的守护进程，在Server Manager之后被init.rc触发，但其实他是真正被app_process启动的，下面是启动这个特殊进程的流程。

1
2
3
4
5
6
7

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
class main
socket zygote stream 660 root system
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
onrestart restart media
onrestart restart netd

你可以发现Zygote是如何当做系统服务启动的，你也可以看到app_process为什么说app_process是启动Zygote的真正命令。就像之前说的，Zygote是一个以专门启动应用为的守护进程。这意味着Zygote是所有App进程的父进程。当app_process启动Zygote时，它通过调用Zygote的main()方法创建了第一个Dalvik虚拟机。当Zygote启动后，zygote会预加载所有必须的Java类和资源，启动System Server并打开一个名为/dev/socket/zygote的socket服务，去监听所有启动应用的请求。 想之前的文章所说，System Server 是一个和它的父进程完全分离的进程。一旦System Server创建完成，它会初始化一系列不同的System Services并启动Activity Manager。那Zygote是如何启动新的应用的呢？

Read More

一般情况下如果我想要较详细的分析内存状况，会使用android monitor(下简称monitor)和Memory Analyzer工具(下简称MAT)，但步骤有些麻烦。

1. 使用monitor dump堆文件
2. 使用hprof-conv工具，将hprof转换成MAT能够识别的格式
3. 使用MAT分析

需要手动dump hprof再使用hprof-conv工具手动转码，上篇Android Bitmap的内存大小是如何计算的？说到使用square的haha来做内存堆中Bitmap的分析。所以在思考如何一键完成内存dump和analyze的过程，当然也可以任意其他Java对象做分析。
如何完成dump和转码，思路还是Read the fucking source code，看下monitor是如何dump hprof文件的。打开Android sdk目录，monitor和其依赖的jar分别在/tools和’/tools/lib’目录，核心代码在ddmlib.jar中，Java swring代码在ddms.jar和ddmuilib.jar中，ddmlib需要依赖common.jar和guava.jar。

Read More