归档: 2017/4

共 47 篇文章

对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虚拟地址转物理地址

如何写出GC友好的应用

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

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

原文地址: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

如何使用ddmlib dump出堆文件

一般情况下如果我想要较详细的分析内存状况,会使用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.jarddmuilib.jar中,ddmlib需要依赖common.jarguava.jar

Read More