青训营笔记
这是我参与「第四届青训营 」笔记创作活动的第22天
1.流畅性优化：
安卓内部是主线程模型，所有UI交互都应该在主线程进行，优化主要集中在程序员可调控的操作上面，避免操作影响主线程，影响主线程会影响流畅性。
可操作的部分：
1.System Event（系统事件），如关闭页面
2.Input Event (输入事件）
3.Application（应用事件），如应用启动，关闭
4.Service
5.Alarm（定时事件）
UI的绘制 UI Drawing部分是每隔16ms绘制一次（60帧）
卡顿感知产生的原因：
1.输入事件无法及时响应，前面代码有过重的任务导致挤压了Input的时间，表现为点按无响应
2.输入事件耗时过长，在输入时执行了过多控制逻辑判断、计算等，挤压了UI绘制的时间
3.除了绘制任务外，其他任务过多占用主线程，挤压了UI绘制的时间
解决：把耗时操作从主线程移动=到其他线程进行，多线程，让主线程只为交互和刷新负责。
人体肉眼感知到不卡顿的最低帧数是25帧。 没有Vsync信号会导致画面撕裂
2.资源优化：
例子：如用户上传视频时，视频音量是不统一的，时大时小；上传后通过资源优化，统一视频内部的声音大小，能够拥有很高的体验优化。 功耗方面如应用色系，亮度等。AMOLED黑色不发光，在黑色下可以大幅节省功耗
3.稳定性优化：
ANR,即应用程序无响应。如果Android应用的界面线程处于阻塞状态的时间过长,会触发App ANR错误。如果应用位于前台，系统会向用户显示一个对话框，ANR对话框会为用户提供强行退出应用或等待的选项。 系统厂商和硬件厂商针对其有很多特定优化。
性能监控工具：
1.GPU呈现模式分析
原理︰系统通过记录每一帧的相关数据，然后通过图形的形式呈现优点∶无需二次开发，简单易用 缺点:并不完全准确，且无法明确指出造成卡顿问题的具体原因
2.Layertool
原理:通过遍历ViewTree信息，输出view层级关系优点︰清楚明了，可以宏观感知ViewTree现状,也可 定制，帮助分析overdraw。缺点:还不能够清楚明确的分析出UI的性能瓶颈
3.CPU Profiler
原理:基于JVMTI 优点∶完整的方法调用栈输出、支持Java、C、C++方法耗时检测、上手简单 缺点:性能损耗太大
总结：
- 快速流畅性找出问题:GPU呈现模式
- 快速找出布局问题:LayerTool
- 深入性能归因:初阶CPU profiler中阶Tracview高阶Systrace
- 如何查出功耗问题:Battery Historian
4.如何优化：
1.现状分析：耗时原因
CPU Time
循环，反射，序列化/反序列化，类解析
Io Wait
Io操作，等待Io返回结果
IPC
Binder调用耗时
Lock Wait
主线程是等锁状态，等待其他线程或者自己超时唤醒
CPU Schedule
主线程是可执行状态，但是获取不到CPu时间片
现状分析：运行环境原因
根据耗时成因归类 根据运行所在线程环境采用不同的策略 主线程优化、运行时优化、后台线程优化 渲染耗时、渲染瓶颈 性能优化案例 异步渲染
SurfaceView:采用独立的线程进行绘制和渲染，生命周期需要自己控制。
Jetpack Compose:基于组合优于继承的思想，相重新设计一套解耦的UI框架。
Litho :复杂Ul下的高性能渲染框架。
扁平化:Litho采用Yoga完成组件布局measure和layout，实现布局的扁平化。
组件化:Litho使用Drawable作为Node绘制单元，实现了布局的细粒度复用和异步计算布局的能力。缺点:不支持现有逻辑，需要重新实现
