上一篇文章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=93676689579157
03-24 20:05:52.144 30578 30727 D Sunny-Test-Utils: NewBufTime use time--->392292
03-24 20:06:12.656 30578 30727 D Sunny-Test-Utils: initBufData use time--->20512314888
03-24 20:06:12.656 30578 30727 D Sunny-Test-Utils: total create BufData use time--->20512707180
03-24 20:06:12.695 30578 30727 D Sunny-Test-Utils: aftWriteTime=93697240995816
03-24 20:06:12.695 30578 30727 D Sunny-Test-Utils: delta=20551416659
03-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=93697255657795
03-24 20:06:12.710 30578 30727 D Sunny-Test-Utils: NewBufTime use time--->551198
03-24 20:06:33.188 30578 30727 D Sunny-Test-Utils: initBufData use time--->20477974992
03-24 20:06:33.188 30578 30727 D Sunny-Test-Utils: total create BufData use time--->20478526190
03-24 20:06:33.227 30578 30727 D Sunny-Test-Utils: aftWriteTime=93717772564923
03-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=7136372545141
03-24 06:03:42.787 18541 18576 D Sunny-Test-Utils: NewBufTime use time--->6635938
03-24 06:03:45.272 18541 18576 D Sunny-Test-Utils: initBufData use time--->2485714686
03-24 06:03:45.272 18541 18576 D Sunny-Test-Utils: total create BufData use time--->2492350624
03-24 06:03:45.359 18541 18576 D Sunny-Test-Utils: aftWriteTime=7138951725036
03-24 06:03:45.359 18541 18576 D Sunny-Test-Utils: delta=2579179895
03-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=7138963657484
03-24 06:03:45.371 18541 18576 D Sunny-Test-Utils: NewBufTime use time--->387188
03-24 06:03:47.898 18541 18576 D Sunny-Test-Utils: initBufData use time--->2526351301
03-24 06:03:47.898 18541 18576 D Sunny-Test-Utils: total create BufData use time--->2526738489
03-24 06:03:47.983 18541 18576 D Sunny-Test-Utils: aftWriteTime=7141575492639
03-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位于<sdk>/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，在地址栏里输入
点击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是个好东西，有空打算专门写篇针对该工具的文章。
