Android应用性能优化和性能分析

Memory 分析和优化

有OOM发生但是没有现场保留

结合logcat和代码分析造成oom的泄漏点， 一般OOM 都是程序员自身每注意Handler, bitmap，以及对象相互引用等等造成的， 具体平时怎么防范可以参考【没有OOM发生Memory分析】

有OOM 发生但是有现场保留

现场有保留情况dump memory 和 查看 进程top 信息， 然后按照测试手法操作查看memory 信息， 结合操作和日志确认最终泄漏点

没有OOM发生Memory分析

OOM 产生一般都是程序员疏忽产生的， 以下分享一下自己对memory 的一些处理

1. 代码每次书写完毕， 可以使用AS Profiler 分析一下对应memory， 一般比较常见的leak 都可以被发现

   
   Screenshot from 2021-08-01 15-36-12.png

2. 操作apk 界面一段时间， 期间查看AS Profiler Memory 走形曲线， 如果曲线一直处于上升，GC 后也没有太大变化， 此时可以record 并查看对应memory分析文件

3. 使用monkey 工具进行测试， 并记录对应进程的memory, cpu信息， 操作相对一段时间， 将产生的memory和cpu数据导成图形， 查看对应图形曲线， 结合对应时间点和monkey 操作进行分析

4. 使用LeakCanary 等第三方工具， 具体使用流程网上有很多， 我这里就不多做介绍。

应用启动速度

分析应用启动优化点

1. adb shell am start -W -S com.test.Myaplication/.MainActivity 该命令只能大致看到应用启动条件
2. log过滤Displayed关键字
3. 获得并分析trace 文件

// 进程启动时加入
 Debug.startMethodTracing("XXXTrace");
在自己想结束trace的地方加入
 // Debug.stopMethodTracing();
// 自己可以根据自己的需求进行trace 文件的记录, 分享一下我的做法
1. application onCreate 加入Debug.startMethodTracing("XXXTrace");
2. 第一帧上屏时结束
getWindow().getDecorView().post(() -> new Handler().post(() -> {
       Debug.stopMethodTracing();
})); 
// trace 文件地址
/sdcard/Android/data/包名/files/XXXXTrace.trace 

然后自己可以使用Chrome或者AS 分析产生的trace 文件, 分析对应组件的启动时间

4. 关键点埋日志, 并计算执行时差, 这个也是最通用也最简单的方式

优化应用启用速度

1. 使用懒加载, 建议数据在首帧上屏后再加载
2. 有广告页的app, 可以利用广告页空隙进行预加载
3. 禁止使用xml 加载帧数比较多的帧动画
4. 采用分页加载

Apk 瘦身

1. 网络加载图片, 图片尽量少预置
2. 简单图片或者动画采用自定义view 或者 Vector 的方式加载
3. 动态下载文件, 不要将文件轻易放到asset 中
4. 引入第三方库要谨慎