Android(安卓)平台侧性能优化之应用启动[问题已解决]
- 曙光出现
- 还是IO速度
- 插播 systrace 使用简介
- 解决办法
- 写在最后
上一篇文章Android 平台侧性能优化之应用启动采用多个命令分析了平台的cpu/memory等方面对Email启动慢照成的影响。很遗憾花了许多精力，但依然没有找出问题所在，这个坑终于填平了。手动撒花^_^
回头看来，问题其实很简单，一开始走错方向，导致花了许多精力，不过这个过程也同样积累了不少知识。
本篇文章记录填坑的过程，重新换个角度分析。
曙光出现：
同事在分析另外一个I/O读取慢的问题时发现我们的设备是被加密的，得知这个消息后，我的内心是激动的。一度以为找到了问题的root cause.
adb shell getprop ro.crypto.state
用上述命令查看问题机的加密状态，返回encrypted，果然是已经默认加密了。感觉曙光出现了，我们的设备加密时将/data分区也进行了加密，而应用启动的文件正是放在/data分区下的。按理来讲加密后的/data分区读写速度肯定弱于未加密状态。问题会不会跟此相关呢？
我们采用的是高通8909平台芯片，找到对应的fstab.qcom文件。修改如下：
- /dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,forceencrypt=footer+ /dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard wait,check,encryptable=footer关键就是修改这一句forceencrypt=footer===>encryptable=footer
forceencrypt表示强制加密，我们改成encryptable意味着加密是让用户主动去选择的。
怀着胸有成竹的心情验证修改后的版本。发现根本没有起任何作用。whats’s the fuck!说不过去啊。
满以为找到突破口了，结果希望的火焰还是被无情的浇灭了。
还是IO速度
自己写了一个test apk，专门测试平台emcc的读写速度。测试问题机Log如下：
03-24 20:05:52.126 30578 30727 D Sunny-Test: start call writeData--->03-24 20:05:52.144 30578 30727 D Sunny-Test-Utils: befWriteTime=9367668957915703-24 20:05:52.144 30578 30727 D Sunny-Test-Utils: NewBufTime use time--->39229203-24 20:06:12.656 30578 30727 D Sunny-Test-Utils: initBufData use time--->2051231488803-24 20:06:12.656 30578 30727 D Sunny-Test-Utils: total create BufData use time--->2051270718003-24 20:06:12.695 30578 30727 D Sunny-Test-Utils: aftWriteTime=9369724099581603-24 20:06:12.695 30578 30727 D Sunny-Test-Utils: delta=2055141665903-24 20:06:12.696 30578 30727 D Sunny-Test: start call writeData--->03-24 20:06:12.710 30578 30727 D Sunny-Test-Utils: befWriteTime=9369725565779503-24 20:06:12.710 30578 30727 D Sunny-Test-Utils: NewBufTime use time--->55119803-24 20:06:33.188 30578 30727 D Sunny-Test-Utils: initBufData use time--->2047797499203-24 20:06:33.188 30578 30727 D Sunny-Test-Utils: total create BufData use time--->2047852619003-24 20:06:33.227 30578 30727 D Sunny-Test-Utils: aftWriteTime=9371777256492303-24 20:06:33.227 30578 30727 D Sunny-Test-Utils: delta=20516907128在测试参考机Log如下：
03-24 06:03:42.766 18541 18576 D Sunny-Test: start call writeData--->03-24 06:03:42.780 18541 18576 D Sunny-Test-Utils: befWriteTime=713637254514103-24 06:03:42.787 18541 18576 D Sunny-Test-Utils: NewBufTime use time--->663593803-24 06:03:45.272 18541 18576 D Sunny-Test-Utils: initBufData use time--->248571468603-24 06:03:45.272 18541 18576 D Sunny-Test-Utils: total create BufData use time--->249235062403-24 06:03:45.359 18541 18576 D Sunny-Test-Utils: aftWriteTime=713895172503603-24 06:03:45.359 18541 18576 D Sunny-Test-Utils: delta=257917989503-24 06:03:45.360 18541 18576 D Sunny-Test: start call writeData--->03-24 06:03:45.371 18541 18576 D Sunny-Test-Utils: befWriteTime=713896365748403-24 06:03:45.371 18541 18576 D Sunny-Test-Utils: NewBufTime use time--->38718803-24 06:03:47.898 18541 18576 D Sunny-Test-Utils: initBufData use time--->252635130103-24 06:03:47.898 18541 18576 D Sunny-Test-Utils: total create BufData use time--->252673848903-24 06:03:47.983 18541 18576 D Sunny-Test-Utils: aftWriteTime=714157549263903-24 06:03:47.983 18541 18576 D Sunny-Test-Utils: delta=2611835155可以看到
问题机写入耗时：Sunny-Test-Utils: delta=20516907128
参考机写入耗时：Sunny-Test-Utils: delta=2611835155
参考机比问题机写入速度快了一个数量级。再用其他的工具测试I/O读写速度，同样发现参考机比问题机快。但知道这个还是没有办法解决问题，也没法量化I/O差异到底会对Email的启动速度影响多大。
问题到这一度陷入窘境，迷失了分析方向。是时候祭出systrace工具了。
插播 systrace 使用简介
systrace位于/platform-tools/systrace目录下。
我们主要分析Email的性能问题，因此可以用命令：
python systrace.py –app=com.tct.email gfx view sched dalvik -o email_launch.html
来抓取trace log分析启动过程。systrace 支持的trace类型可以通过:
python systrace.py -l
查看，用Android N下的systrace工具输出结果如下：
输入上述命令，然后启动Email，待主界面展示出来后，根据提示输入回车键，此时systrace工具开始生成报告。
Tips:
systrace.py位于SDK/platform-tools/systrace目录下。抓取时最好用系统对应的SDK工具抓取。同时如果有源码，也可以用源码的external/chromium-trace/catapult/systrace/systrace/systrace.py 抓取。同样注意抓取systrace的手机跟源码版本一直。
然后打开chrome，在地址栏里输入
chrome://tracing/
点击Load 按钮，载入email_launch.html文件。显示入下图：
查看systrace主要用到4个快捷键：
| W | 放大视图 |
|---|---|
| S | 缩小视图 |
| A | 右移视图 |
| D | 左移视图 |
# systrace 报告分析
为了排除apk版本差异的干扰，将同版本的apk分别安装到问题机跟参考机上。然后对比systrace报告。
先用TestActivityLaunchTime.py测试问题机以及参考机的启动时间。脚本获取地址：https://github.com/guanglixiang/Android_Performance/blob/master/TestActivityLaunchTime.py
问题机：
************************************************** Test APK version info is: versionCode=317022801 minSdk=17 targetSdk=24 versionName=v7.0.4.1.0312.0_0228 ************************************************** 1 lunch time is 875 2 lunch time is 884 3 lunch time is 897 4 lunch time is 873 5 lunch time is 862 5 launch time average is 878参考机：
**************************************************
Test APK version info is:
versionCode=317022801 targetSdk=24
versionName=v7.0.4.1.0312.0_0228
versionCode=216030401 targetSdk=23
versionName=v5.2.10.3.0214.0
**************************************************
1 lunch time is 806
2 lunch time is 773
3 lunch time is 782
4 lunch time is 777
5 lunch time is 835
5 launch time average is 794
这里看差距貌似不大，但多次测试总是发现参考机就是比问题机快那么一点点。从配置上来将问题机跟参考机配置差不多，并且问题机的内存还比参考机大。为什么就是慢那么一点点呢。
下面尝试通过systrace文件去找原因。
这里我用命令：
./systrace.py gfx input view wm am sm app res dalvik bionic pm database sched freq idle disk mmc load -t 5 -o vJ5E-no-encrypt-no-net_emailv7.html
分别抓取参考机和问题机的systrace。终于发现了问题所在。
从systrace对比非常明显的看到参考机没有bindApplication的过程，而问题机却在这个过程中消耗了0.226s。
我们知道冷启动应用都是需要走bindApplication过程的。
bindApplication过程会：
1.创建应用进程
2.加载应用dex执行文件
3.获取应用资源文件
4.makeApplication,初始化JavaContextClassLoader。
相应的热启动是不需要走上述过程的。
为了验证上述分析。可以有个简单的方法，只要先启动Email,然后点击menu清除最近的应用，最后通过ps命令查看email进程是否还存在。
透过上面的分析可以确定参考机的Email应用一直都在后台运行。而测试测冷启动case时只是点击menu键，然后清除所有应用，在去启动Email。参考机的Email逃过了这一劫，清除的过程中，进程并没有被杀死。而问题机的Email就没那么幸运了，直接被杀的它妈都不认识它了。
解决办法
由于参考机将Email配置成了后台一直运行，相当于拿问题机的冷启动耗时对比参考机的热启动应用耗时。想要达到参考机的启动速度，在平台侧可以也可以效仿参考机将Email配置成后台一直运行。
修改方法：
在frameworks/base/services/core/java/com/android/server/am/ProcessRecord.java
``` void kill(String reason, boolean noisy) { if("com.tct.email".equals(processName) && !KILL_APP_REASON_PERMISSIONS_REVOKED.equals(reason)) { return; } //忽略其他code } ```但这种做法需要项目上根据需求做权衡。Email应用本身会定时去check邮件列表，发起网络请求，属于高耗电程序。一直在后台运行会消耗电量。
写在最后
Email问题陆陆续续的分析了两周多，最开始一心要去从I/O速度上去分析个结果出来。没有去想其它的可能。中间一度想放弃，打算将问题归结到I/O，抛给底层同事去check。但心里始终不安，有空了就去想该问题。其实一开始也抓取过systrace，只是重点放在了分析I/O上，没有跟参考机做对比。没有对比就带来了伤害啊TT
systrace是个好东西，有空打算专门写篇针对该工具的文章。
更多相关文章
- Android(安卓)Develop Training——和其它Android应用交互(Inter
- Android(安卓)9 (P) Zygote进程启动源码分析指南一
- 一个简短的android病毒分析
- Android(安卓)4.4 Kitkat 音频实现及简要分析
- Android(安卓)framwork 分析之智能指针LightRefBase ，sp,wp,RefBa
- Android(安卓)Activity启动流程分析--------基于Android(安卓)O
- android studio for android learning (八)开机启动界面splashAc
- Android(安卓)studio启动后卡在refreshing gradle project（包解决
- 手机管理应用研究【4】—— 手机加速篇