归档

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

病已Android Developer

如何写出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

病已Android Developer

[译]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

病已Android Developer

如何使用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.jar和ddmuilib.jar中，ddmlib需要依赖common.jar和guava.jar。

Read More

病已Android Developer

Android Bitmap的内存大小是如何计算的？

性能优化 , , 评论

一、前言

本来只想说下Bitmap和内存的基本关系，但发现如果真的想把这看似简单的事情说清楚，实际上未必那么简单，你不信？不妨先尝试下回答下面几个问题！

  • 问1：什么是dpi？什么是dp？答：你在侮辱我？我拒绝回答！（：无辜脸
  • 问2：以Nexus6为例，分辨率1440*2560，5.96英寸，ppi是什么？dpi是什么？1dp是多少像素？
  • 问3：还以Nexus6为例，一张180*180的图片，放置在设置了wrap_content属性的ImageView中，当这张图片，分别放在drawable-nodpi,drawable-mdpi,drawable-hdpi, drawable-xxhdpi,drawable-xxxhdpi这几个资源目录中，在屏幕上分别显示多大(像素)的图片？
  • 问4：这张图片占用的内存大小分别为多少？
  • 问5：如果设置ImageView的宽和高为固定的值，如50px，那么上述情况下，加载的Bitmap占用内存大小分别为多大？

本文主要围绕上述问题，介绍Android图片资源加载的基本机制，图片的内存大小如何计算，以及内存图片分析工具。

Read More

病已Android Developer

Android安全之应用防dex2jar原理及实现

Android安全 , , 评论

最近在看某外卖平台的代码，发现某外卖平台最新版本版本无法正常的通过dex2jar工具将dex转换出Java源代码，在转换过程中会提示出错，如图：

Read More

病已Android Developer

Android安全之APP去广告

Android安全 , , 评论

一、工具介绍

更多反编译工具可查看：Uncle Chen—Android反编译技术总结

二、去除应用开发助手的广告

CodeKK公众号在17年初推出了一个应用开发助手。V1.0版本是有广告版本的，下面以这个版本为例，简单看下去广告过程。它的后续的V1.1.0和V1.2.0已经去除了广告功能。

2.1、反编译

1
apktool.sh d -f ./dev-tools.apk


2.2、注释广告代码

这里可以先用dex2jar转jar后查看下源码，会发现使用的是Google AdMob作为广告平台，简单看下代码可以发现在主页面activty_main.xml中包含广告视图的布局文件。所以只需要找到ad_layout.xml将其 android:visibility="gone"属性设置成gone就可以了。

2.3、重打包

这里重打包的过程可能会遇到一些错误，不过认真查看日志并结合Google都是可以找到解决方案的，这里暂且不表。使用apktool b命令，生成的apk默认路径为/dist路径下

1
apktool.sh b ./dev-tools

2.4、制作一个名为hackapk.keystore的证书,并重新签名应用

1
2
3
4
5
制作证书：
keytool -genkey -keystore hackapk.keystore -keyalg RSA -validity 10000 -alias hackapk

签名：
jarsigner -verbose -keystore hackapk.keystore -signedjar dev-tools-no-ads.apk ./dev-tools/dist/dev-tools.apk hackapk

详细的参数可以参考：
APK签名之keytool生成keystore和jarsigner签名apk

2.5、安装

1
adb install -r dev-tools-no-ads.apk

有广告版本

无广告版本

2.6、下载去广告版本的应用开发助手

三、反编译脚本

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
#!/bin/sh
workDir=./
if [ "$2" ]
then
         mkdir $2
         workDir=./$2/
fi

echo $workDir
name=`basename $1 .apk`
zipPath=$workDir$name.zip

##apkTool反编译
smaliDir=$workDir$name@smali
apktool.sh d -f $1 -o $smaliDir

## 解压缩，使用dex2jar处理
unzipDir=$workDir$name@unzip
cp $1 $zipPath
unzip $zipPath -d $unzipDir

d2j-dex2jar.sh -f $unzipDir/classes.dex -o ${workDir}dex2jar.jar
d2j-dex2jar.sh -f $unzipDir/classes2.dex -o ${workDir}dex2jar2.jar
d2j-dex2jar.sh -f $unzipDir/classes3.dex -o ${workDir}dex2jar3.jar
open $workDir

将上述内容保存到本地hack.sh文件中，使用下面的命令就会把apktool和dex2jar的结果输出到meipu这个目录中，这样就不需要每次收到敲命令喽，只要知道需要反编译的apk和输出的文件夹名称就可以~

./hack.sh ./美铺_1487845975713.apk meipu

转载请标明出处病已blog https://ivonhoe.github.io/

病已Android Developer

Mac OS上编译Android源码

学习总结 评论

一、制作一个大小写敏感的磁盘分区

1.1.Mac OS磁盘工具

这里我使用一块移动硬盘，将移动硬盘的一个分区使用Mac OS的硬盘工具，抹掉数据，选择MacOS扩展(区分大小写，日志式)，创建成大小写敏感的分区。

这里会遇到一个问题，抹掉分区数据的时候，会报错：“Mac OSX 抹盘发生错误:Mediakit 报告设备上空间不足以执行此操作”，这里的原因是磁盘没有大于200M的UEFI分区。

Read More

病已Android Developer

Mac/Linux下gcc编译动态链接库[.so文件]

学习总结 评论

一、以bsdiff.c和bspatch.c为例编译bsdiff.so

bsdiff.c和bspatch.c分别依赖bzip2

项目结构

步骤

  • 使用BsDiff.java生成BsDiff.class文件

    javac ivonhoe/spring/wrcenter/jni/BsDiff.java

  • 生成BsDiff.h文件

    javah ivonhoe.spring.wrcenter.jni.BsDiff

  • 生成bspatch.o

    Read More

病已Android Developer