① 卡顿分析与布局优化
人眼与大脑无法感知超过60fps画面更新。所以app的性能目标保持60fps。换算后就是1000/60 = 16 ms/帧 的刷新率
如果某个界面操作超过16ms，加入24ms，那么系统的到的垂直同步值（VSYNC)无法正常渲染。造成丢帧，用户32ms内看到的就是同一帧画面。
造成这个现象原因：
主线程过多UI绘制，大量的IO操作，大量计算操作占用CPU
为什么要有vsync垂直同步？
从下层，到上层，分析surface显示。分别有前台和后台的缓冲区buffer
前台负责缓冲用来展示界面，后台为下一帧做准备，然后前后台进行交换，这样不断交替，就可以一帧一帧的显示。由于前后台缓冲速率不一样，就会造成问题。
这就需要了解SurfaceFlinger
上层每个界面对应Surface，SurfaceFlinger 负责管理Surface。
SurfaceFlinger 合成 Surface 到屏幕后台缓冲区，等下一个vsync信号来显示到屏幕。
如何理解Surface
- Surface对应Window（对话框，Activity，状态栏等）
- 上层图像绘制滑板Canvas画笔，通过Canvas的API向Surface绘制图形。
- Surface 内部存在多个缓冲区，行程一个队列，BufferQueue
从执行者角度看
- CPU：Messure，Layout，负责纹理和多边形绘制，生成，发送纹理和多边形给GPU
- GPU： 将CPU产生的纹理和栅格化进行合成处理。
VSYNC 信号有三个缓冲区：
Drawing with Vsync 底层绘制缓冲
Choreographer Vsync 控制上层绘制节奏的缓冲
View的requestLayhout和invalidate控制缓冲
开发中如何应用：
- Trace API 打标签
- APP 层面监控卡顿，Looper日志监控卡顿，自己实现Printer（BlockCaneray原理）
- 我们在Choreographer.Framecallback 回到方法doFrame中计算时间戳 diff < 16.6f 否则上报卡顿
- Looper 日志监控适合发布前的灰度测试，Choreographer.Framecallback 适合上线监控卡顿。
布局优化
层级优化
ConstrantLayout 减少层级尽量扁平
Merge标签，布局需要多出共同使用，使用的地方用inclue引入可以减少层级
ViewStub，在visible和inflate优化显示的时候使用。
过度绘制
手机选项开关中打开检测开关。查看是否以后过度绘制。
解决：
移除不必要的背景。
降低颜色等透明度。
尽量简单绘制。
布局加载优化
- 减少IO，在加载XML的时候
- 使用AsyncLayoutInflater 一步加载布局。使用条件：
- 线程安全的时候才能使用
- 不支持设置LayoutInflater的Factory和Factory2
- 不能创建Handler，调用Looper.myLooper
- 如果失败会退回UI线程加载。
② ANR
-
Service Timeout
前台服务20s，后台服务200s -
BroadCastQueue Timeout
前台广播10s，后台广播60s -
ContentProvider Timeout
ContentProvider 10s -
InputDispatching Timeout
界面操作5s
避免ANR
- Activity 稍作创建 类的操作
- Intent Receiver 不做启动Activity的操作，换成Notification Manager进行操作
- 如果游戏相关：在子线程做移动计算
③ 启动优化
- 通过Log的方式，查看Displayer的值，检测Activity绘制完成的时间。
- 冷启动，我们优化一般遵循2-5-8原则，少于2s优秀，2-5s之间相对体验还好超过5s体验变差
- 使用CPU Profile工具进行查验
查看分析，火焰图
Top Down Tree
耗时方法调用栈
- Self Time 自身的耗时
- Children Time 调用其他函数耗时
- TotalTime 前两者耗时总和
Bottom To Top Tree
方便查看是谁，调用了自己耗时情况
利用Debug API
Debug.setupDebugTracing("name");
执行代码包裹在其中查看。
Debug.stopDebugTracing();
API StrickMode模式
④ 内存优化
OOM问题
- Java 堆内存溢出
- 无足够连续的内存空间
- FD数量（进程打开文件数）超出了限制
- 线程数量超出限制
- 虚拟内存不够
常用命令检测
- dumpsys memeinfo
- 内存分析procrank命令
1、Vss
Vss与PS的VSIZE相同是单个进程全部可访问的地址空间
其大小包括可能还尚未在内存中驻留的部分。比如地址空间已经被 malloc 分配，但是还没有实际写入。
对于确定单个进程实际内存使用大小， VSS 用处不大。
2、Rss
RSS是单个进程实际占用的内存大小。
RSS易被误导的原因在于， 它包括了该进程所使用的所有共享库的全部内存大小。对于单个共享库， 尽管无论多少个进程使用，
实际该共享库只会被装入内存一次。
对于单个进程的内存使用大小， RSS 不是一个精确的描述。
3、Pss
PSS 不同于RSS，它只是按比例包含其所使用的共享库大小。
例如， 三个进程使用同一个占用 30 内存页的共享库。 对于三个进程中的任何一个，PSS 将只包括 10 个内存页。
PSS 是一个非常有用的数字，因为系统中全部进程以整体的方式被统计， 对于系统中的整体内存使用是一个很好的描述。
如果一个进程被终止， 其PSS 中所使用的共享库大小将会重新按比例分配给剩下的仍在运行并且仍在使用该共享库的进程。
此种计算方式有轻微的误差，因为当某个进程中止的时候，PSS没有精确的表示被返还给整个系统的内存大小。
4、Uss
USS 是单个进程的全部私有内存大小。亦即全部被该进程独占的内存大小。
USS 是一个非常非常有用的数字， 因为它揭示了运行一个特定进程的真实的内存增量大小。
如果进程被终止， USS 就是实际被返还给系统的内存大小。
USS 是针对某个进程开始有可疑内存泄露的情况，进行检测的最佳数字。
- cat /proc/meminfo
- free
- showmap
- vmstat
内存泄露工具使用
- MAT
- LeakCanary
- AS Memory-Profile
常见泄露场景和解决
- 资源为关闭
- 注册未及时注销
- 静态变量持有数据对象
- 单利造成
Activity context 传入（解决：进行弱引用封装，用的时候弱引用获取） - 非静态内部类引用了实例
- Handler 临时性问题
- 容器对象未清理
- WebView的泄露 （解决：未WebView单独开启进程，用AIDL与应用进行通信，WebView泄露也不会对主进程造成过多影像）
解决：
静态Handler内部类对handler持有的对象弱引用，可回收handler持有的对象。
Activity，Stop/Destory的时候移除消息，避免有待处理的消息占用空间。
⑤ Crash监控
- Java Crash 监控，
实现Thread.UncaughtExceptionHandler全局异常捕获 - NDK Crash
-
工具考虑Bugly 接入
-
AS 的目录bin下面
minidump_stackwalk 工具使用
minidump_stackwalk xxxx.dump > xxxx.txt
进行分析 -
breakPad 工具的引入。
网友评论