对Android系统资源预加载的思考

性能优化 , , 评论

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

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

image.png

分析仔细看一下可以发现，上图中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》这篇文章。

image.png

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

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没有变化。

image.png
image.png

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

四、Copy-On-Write(COW)

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

我的理解是在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 Developer