启动优化其实是一个比较大的命题,在一些特地的场景下,快速启动有比较强烈的需求,这篇博客主要简单的介绍一些在android O平台上的进行启动优化的思路与想法。
而优化启动的一个很重要的东西就是如何来准确度量启动时间,也就是说是否有比较好的办法来度量整个系统的启动耗时。毕竟只有能够毕竟准确的度量了相应的时间,才能更好的了解分析每个启动阶段的情况。所以我打算按照如下的方式来组织:
- Android 相关计时工具的介绍
- 一些重点代码端的分析
- 优化思路
Android 相关计时工具的介绍
1) bootchart工具
在Android O当中,bootchart已经默认集成在Init当中。所以收集数据可以用以下步骤:
- 只需要你通过开关打开即可生效:“adb shell ‘touch /data/bootchart/enabled’”
- 重启设备
- $ANDROID_BUILD_TOP/system/core/init/grab-bootchart.sh抓取数据生成一张png图片,即可进行分析。
但是如果碰到bootchart工具不能使用的情况,就需要自己下载bootchart源码:http://www.bootchart.org/download.html,解压后:
- ant编译
-
java -jar bootchart.jar ../bootchart/bootchart.tgz 生成分析结果图片:
从这张启动图片里,我们能够看到:
1. 总共的启动时间是30s,这里指的是从kernel开始启动的时间开始计时,一直到Android 启动结束.
2. Init 进程一直到13s左右才是启动其他进程,如ueventd。
3. Zygote64/Zygote进程大约在22s左右启动。
4. 这样计算下来Android fw的启动时间大致为8s左右。
这样看起来就比较清晰了,Init进程13秒才开始工作的原因是什么?这个时间如果能缩短的话启动时间会效果很显著。
通过dmesg信息,可以看到:
[32m[ 13.227842] [0m[33minit[0m: init second stage started!
[32m[ 13.237508] [0m[33mselinux[0m: SELinux: Loaded file_contexts\x0a
[32m[ 13.243342] [0m[33mselinux[0m: SELinux: Loaded property_contexts from /plat_property_contexts & /nonplat_property_contexts.\x0a
[32m[ 13.254522] [0m[33minit[0m: Running restorecon…
[32m[ 13.593214] [0m[33mselinux[0m[31m: SELinux: Could not stat /dev/block: No such file or directory.\x0a[0m
[32m[ 13.601607] [0m[33minit[0m[31m: waitpid failed: No child processes[0m
[32m[ 13.606477] [0m[33minit[0m: Couldn’t load properties from /system/etc/prop.default: No such file or directory
[32m[ 13.615416] [0m[33minit[0m: Couldn’t load properties from /prop.default: No such file or directory
[32m[ 13.623768] [0m[33minit[0m: Couldn’t load properties from /odm/default.prop: No such file or directory
[32m[ 13.631946] [0m[33minit[0m: Couldn’t load properties from /vendor/default.prop: No such file or directory
[32m[ 13.641126] [0m[33minit[0m: Created socket ‘/dev/socket/property_service’, mode 666, user 0, group 0
[32m[ 13.648925] [0m[33minit[0m: Parsing file /init.rc…
[32m[ 13.653220] [0m[33minit[0m: Added ‘/init.environ.rc’ to import list
[32m[ 13.658291] [0m[33minit[0m: Added ‘/init.usb.rc’ to import list
[32m[ 13.663329] [0m[33minit[0m: Added ‘/init.angler.rc’ to import list
[32m[ 13.668660] [0m[33minit[0m: Added ‘/vendor/etc/init/hw/init.angler.rc’ to import list
[32m[ 13.675611] [0m[33minit[0m: Added ‘/init.usb.configfs.rc’ to import list
[32m[ 13.681379] [0m[33minit[0m: Added ‘/init.zygote64_32.rc’ to import list
[32m[ 13.688215] [0m[33minit[0m: Parsing file /init.environ.rc…
[32m[ 13.692099] [0m[33minit[0m: Parsing file /init.usb.rc…
[32m[ 13.696775] [0m[33minit[0m: Parsing file /init.angler.rc…
[32m[ 13.701323] [0m[33minit[0m: Added ‘init.angler.usb.rc’ to import list
[32m[ 13.706678] [0m[33minit[0m: Added ‘init.angler.diag.rc’ to import list
[32m[ 13.712305] [0m[33minit[0m: Added ‘init.angler.sensorhub.rc’ to import list
[32m[ 13.719668] [0m[33minit[0m: Parsing file init.angler.usb.rc…
[32m[ 13.724264] [0m[33minit[0m: Parsing file init.angler.diag.rc…
确实是13s左右init进程才开始工作。所以第一步我们来想办法把这个时间看看能不能缩短。
通过这个工具,我们能够大致清楚了从系统启动到Android启动完成后的主要时间,同时也能够简单的分析出kernel启动时间,zygote启动时间,sysetmserver启动时间,但是这个工具还是不能把Android 启动阶段毕竟清晰的展现出来,这个时候就需要使用到第二个工具了。
2) boot mesg
我们很高兴的可以看到在Android中已经加入了一系列的mesg,我们可以通过这一系列的mesg可以抓出android fw启动的相关时间。
到此为止,我们大致能够得出android 启动的每个阶段所耗费的时间了,后续我们来仔细分析每个阶段的代码,看看都干了啥。
第一步,关闭kernel log输出:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
简单粗暴,全部关闭掉,重新编译boot.img测试下,快了将近10s.。。。
通过查看dmesg:
- 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
发现Init进程确实提前到kernel启动5s左右。。