性能优化及工具|青训营笔记
这是我参与「第四届青训营 」笔记创作活动的第7天
01 性能优化的目的
短期：业务和用户 长期：硬件性能提升速度变缓；ARM平台受益于架构和工艺的演进（），近年趋势比X86平台好；多核带来的提升取决于可以真正并行执行的部分
02 性能优化的方向 快稳省
2.1流畅性优化
Android的线程结构
- 进程
- Main Thread（UI线程）
system events - input events - application - services - alarm - UI drawing
手机是输入输出设备，不是控制设备
卡顿产生原因：
- 主线程代码耗时过长，无法接受Input Event，无法滑动
- Input Event耗时过长，导致丢帧
- Lamework丢帧
- 人眼能感知到不卡帧的最低帧数是25
- 没有VSYNC信号会导致画面撕裂
垂直同步（VSync）：当屏幕从缓冲区扫描完一帧到屏幕上之后，开始扫描下一帧之前，发出的一个同步信号，该信号用来切换前缓冲区和后缓冲区。
2.2 资源优化
- MEMORY
- BATTERY
- CELLULAR流量
- FREEZES
- RESOLUTION
- CRASHES
- SOUND OUT OF SYNC
2.3 稳定性优化
ANR应用无响应
2.4系统级优化 移动操作系统和硬件厂商的性能优化
android runtime(ART)使用字节码，提升安卓系统的响应速度 HMP scheduler解决大小核的调度 Vulkan 处理图像 F2FS：内存 ART:更精确进行代码的加速 EAS scheduler
framework：接口
03 最佳工具选型
- 性能工具的必要性
- 快速流畅性找出问题->GPU呈现模式
- 快速找出布局问题->LayerTool
- 深入性能归因：初阶CPU profiler；中阶TraceView;高阶Systrace
- 抖音神器：btrace
- 查出功耗问题：Battery Historian
04 性能优化技术案例
现状分析——耗时成因
- CPU time：循环、反射、序列化/反序列化、类解析
- IO wait
- IPC:进程间通信，BINDER调用耗时
- lock wait：等所状态，等待其他线程或自己超市唤醒
- cpu schedule：主线程是可执行状态，但获取不到CPU时间片
现状分析——抖音启动耗时归因
Cold process
- create process:栈堆创建
- contentprovider init：注册逻辑
- applocation#create:应用创建
- aim for <3 seconds
Warm create
- activity#create
- inflate view hierarchy
- aim for <1 s
Hot create
- activity#onStart
现状分析——渲染分析 进程分析&渲染瓶颈
-
bind：绑定页面
-
overdraw：不同层级间
-
AndInflater:解决xml性能问题-外界方案X2C
-
LegoLnflate：高优先级的启动预加载方案
-
AsyncInflater:随时随地预加载，不与具体逻辑绑定，生命周期存活
GSON解析优化：数据复用
数据协议优化：json->protobuf
布局的优化：VIEW层级的简介
渲染优化的异步化方案
- surfaceview
- jetpackcompose：异步绘制
