Android 性能测试与优化中遇到的七个场景

一、 某个版本性能突然下降

现象：针对系统应用性能下降30%左右，第三方应用也有较大的性能下降。
分析：ODEX优化未加，/system/framework/arm下是空目录，比如boot.art等文件皆未生成。
解决方法：将WITH_ODEXOPT打开
系统应用：USB充电/传输选择启动时间：539ms->310ms
淘宝应用：启动测试平均启动时间：10229ms->9235ms

二、twitter等应用启动时间过长

现象：twitter应用启动时间在5s-7s，目标5s以内
分析：
1） 工具分析：TF_Perf.apk

• 每隔15s做一个循环测试，应用超过15s则无不做记录
• 初次测试应用时等待5s显示图标，同一个应用可能被测试2次，如果有2个Activity的话，以第二次结果为准，当前应用被后一个应用覆盖即表明启动完成，比打印Displayed时间要长；
• 整体测试结果不一定严谨。

2） 性能分析

性能每次测试差异明显，表现为：

• 最近列表中清空后再立刻测试启动时间会延长2s以上，原因为twitter没有完成自启动，解决方法可见下面第4点；
• 隔天测试数据要远好于刚安装应用时的结果，原因为odex后台优化，判断条件为充电状态下空闲，检测周期为1天，影响开机时间也有大约2s左右，可见第5点。
• WW连续开机测试时，时间差异在4s左右，原因为温控影响，可见第6点。

3） 解决方法（通用方法）

• 将WITH_ODEXOPT打开，UMX测试即可通过，5s以内。但WW依然未过。
• 增加perfboostsconfig.xml：淘宝平均启动时间：9181ms（对于启动时间越短的应用越有效果，在另外一个应用的对比中8007ms vs 7166ms，twitter中在LA3.0.1上这个优化效果也较为明显）
• 配置pinservice增加boot.art等项：淘宝平均启动时间：8804ms （对启动时间长的应用还是有些效果，但在LA3.0.1的twitter测试中并没有如此明显），但是对于系统开机内存增加了20-30M之间，对于1G版本目前未合入。
• 可考虑配置ro.vendor.qti.sys.fw.empty_app_percent的50%比例，目前来说32个进程空进程在16个，增加此项可以将一些开机自启动的应用提前加载进来，从而提高运行速度，比如twitter如果不能提前加载，则启动时机增大2s-2.7s之间。但此项同样会带来系统内存的增加，可通过dumpsy meminfo –t 20查看空应用情况。
• 主动odex优化详见第3小节，淘宝启动时间最快能在7s左右完成
• 新的温控策略

结果验证：twitter启动时间在3300ms左右, 淘宝平均启动时间：7076ms

三、Facebook启动时间过长

现象：Facebook启动时间过长，在10s以上

分析：1）twitter在安装时是有odex文件的，但没有.art文件，这与大部分第三方应用相同，如淘宝等，主动odex优化可以生成.art文件，还可以生成更全的.odex信息（vdex相应会减小，因此其为未编译过的apk信息）。这可加速启动。应用启动信息收集的profile越多，则一般启动速度则越快。

一般来说第一次启动可收集大部分信息，可主动做一个odex优化，目前采取3分钟后主动odex优化，目前仅针对/data/app下的应用。

2）Facebook稍有不同，PlayStore下载后没有odex文件，需要不停的解释执行，因此速度极慢，因此主动odex优化，可以生成这个odex文件（该应用不会生成.art文件），这已经足够加速其启动了。

解决方法：主动odex优化，Facebook平均启动时间：3800ms。

四、AngryBirds启动时间过长

现象：客户启动时间长达8s，正常msm8909版本启动4s左右
分析：
其一，如下图，systrace可见进程大部分时间均是Sleep, 是在等待IO操作。

其二，查看systrace的kernel一项，The UI thread is wakeup by “kworker/u9:3/ kworker/u9:5/ kworker/u9:0” when it is “Uninterruptible Sleep|Wakekill” status.
其三，查看线程名为kworker/u9:3是在做什么工作，发现是userdata加密工作。
解决方法：取消userdata的加密，时间提升4s。

五、系统应用Dialer、Camera启动时间较长

现象：Camera启动时间为1300ms

分析：未主动odex优化，对于系统应用可以在编译时加入已优化过的odex文件，包括.art文件

解决方法：

1. PRODUCT_DEX_PREOPT_PROFILE_DIR := device/qcom/xx/profiles
2. 增加比如Dialer.prof.txt文件在此目录下，需要用户手动启动几次，收集profile文件，
   profman --dump-classes-and-methods --apk=Dialer.apk --dex-location=Dialer.apk --profile-file=/data/misc/profiles/cur/0/com.android.dialer/primary.prof > Dialer.prof.txt
3. 针对此类应用，需要classes.jar文件（可在debug版本中加入，user版本不需要）
   ifeq (true,$(LOCAL_DEX_PREOPT_GENERATE_PROFILE))
   LOCAL_DEX_PREOPT := nostripping
4. 可以通过将boot整个文件进行优化，这个改进注定不会很大，如下：
   a) PRODUCT_DEX_PREOPT_BOOT_IMAGE_PROFILE_LOCATION := xx/profiles/boot-image-profile.
   txt
   b) 将系统boot-image-profile.txt文件放在在如上文件夹内。生成过程如下：

   The first step is to enable profiling of the boot class path by setting the property “dalvik.vm.extra-opts” to “-Xps-profile-boot-class- path'”and running a set of use cases. Profiles are located in “/data/misc/profiles/cur/0/*”on the device
  After having run the use cases, pull the profiles from the device and run the art/tools/generate-boot-image-profile.sh script to generate a new boot image profile
  Final, merge with framework/base/boot-image-profile.txt

最终结果：Camera启动时间在1020ms

六. 客户版本测试不过关之Camera预览卡顿

现象：Snap Camera预览卡顿
分析：GPU合成所致
解决方法：MDP合成

七. b612预览卡顿

现象：bpCamera预览卡顿
分析：帧率在8fps，CPU利用率不算高，GPU利用率99%，且在最大频率。
1） Wm size降低分辨率提升明显；
2） Android N表现好于O，高通称shader有所区别，但未有结果。
解决方法：
增加白名单配置减小分辨率
1）

   ro.vendor.at_library=libqti-at.so 
   persist.vendor.qti.debug.appdensity=240 
   persist.vendor.qti.res.override.enable=1  

2）

<ResolutionOverrideApps> 
<AppAttributes
   PackageName="com.campmobile.snowcamera" 
   ActivityName="com.linecorp.b612.android.activity.ActivityCamera"/>
</ResolutionOverrideApps>  

结果验证：帧率在12fps，而这对于原生摄像机的后置帧率相同。