Android 平台侧性能优化之应用启动[问题已解决]

最新推荐文章于 2022-11-28 11:10:20 发布

思棉叶

最新推荐文章于 2022-11-28 11:10:20 发布

阅读量1.9k

点赞数 1

分类专栏： android Android Performance 文章标签： android 性能优化应用

本文链接：https://blog.csdn.net/azhengye/article/details/67054941

版权

android 同时被 2 个专栏收录

42 篇文章 6 订阅

订阅专栏

Android Performance

11 篇文章 7 订阅

订阅专栏

曙光出现
还是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=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位于/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工具输出结果如下：

systrace.py -l 输出结果

输入上述命令，然后启动Email，待主界面展示出来后，根据提示输入回车键，此时systrace工具开始生成报告。

生成systrace过程

Tips:
systrace.py位于SDK/platform-tools/systrace目录下。抓取时最好用系统对应的SDK工具抓取。同时如果有源码，也可以用源码的external/chromium-trace/catapult/systrace/systrace/systrace.py 抓取。同样注意抓取systrace的手机跟源码版本一直。

然后打开chrome，在地址栏里输入

chrome://tracing/

load systrace界面

点击Load 按钮，载入email_launch.html文件。显示入下图：

systrace 主界面

查看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

问题机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是个好东西，有空打算专门写篇针对该工具的文章。