Android基础第七天 ｜ 字节跳动第四届青训营笔记

这是我参与「第四届青训营 」笔记创作活动的的第7天

初识性能优化及工具

课程回顾

Android 客户端开发的基础知识、UI编程、数据库和网络通信、客户端上的直播技术、端智能技术。

01 为什么做性能优化？

性能优化带来体验的改善进而帮助业务指标的提升。

从更长的时间范围来看：

• 硬件性能提升速度变缓

• ARM平台受益于架构和工艺的演进，最近几年趋势比X86平台好

• 多核带来的提升取决于可以真正并行执行的部分

【未来】

• 未来会有新的材料和工艺来驱动芯片性能的进一步提升，但是目前还没有成熟

• 移动处理器还受到电池技术的限制

• 软件的性能优化仍可持续带来提升

02 性能优化是什么？

2.1 性能优化的目标：

→ 快 、 稳 、 省

2.2 性能优化分类

• 流畅性优化：快——极致的响应与流畅的体验

• 资源优化： 省——最小负载带来最大的收益

• 稳定性优化：稳——稳定的实现，减少不必要打断

• 系统级优化：底层boooster

2.2.1 流畅性优化

Android的线程结构

界面是如何刷新的？

卡顿感知如何产生？

如何解决卡顿？

【人肉眼能感知到不卡顿的最低帧数：25帧】

【如果没有vsync信号，会产生画面撕裂】

2.2.2 资源优化

资源: 即Android手机的软件和硬件资源,通俗意义上应用依赖的移动终端的有限资源和系统设置的数值，即功耗、存储、流量、系统参数、CPU、内存等。

Android端能做哪些资源类优化？

2.2.3 稳定性优化

ANR是(Application Not Responding)的缩写，即应用程序无响应。如果Android应用的界面线程处于阻塞状态的时间过长，会触发App ANR错误。如果应用位于前台，系统会向用户显示一个对话框，ANR对话框会为用户提供强行退出应用或等待的选项。

2.2.4 系统级优化

移动操作系统和硬件厂商的性能优化

03 最佳性能工具选型

性能监控价值：

• 监控和优化相生相伴。

• 监控有攻也有防。

• 攻是为了发现现有问题，指导优化方向。

• 防是为了发现劣化问题，及时止损。

• 线上监控发现问题并聚合排序，线下监控作为线上辅助，并发版前置发现问题。

3.1 GPU呈现模式

原理：系统通过记录每一帧的相关数据，然后通过图形的形式呈现。

优点：无需二次开发，简单易用。

缺点：并不完全准确，且无法明确指出造成卡顿问题的具体原因。

3.2 Layertool

原理：通过遍历ViewTree信息，输出View层级关系。

优点：清楚明了，可以宏观感知ViewTree现状，也可以定制，帮助分析overdraw。

缺点：还不能够清除明确的分析出UI的性能瓶颈。

3.3 CPU Profiler

原理：基于JVMTI

优点：完整的方法调用栈输出，支持Java、C、C++方法耗时检测、上手简单。

缺点：性能损耗太大。

3.4 TraceView

• Instrument

  • 虚拟监听函数入口回调 Enter/Exit/Unwind

  • 耗时点：读时间、写数据到buffer、加锁等指令

• Sample

  • 通过定时抓取多次堆栈diff，近似确定函数的进入和退出时间

  • 耗时点：堆栈diff 、 同Instrument

  • 间隔抓取堆栈的时间越长，性能损耗越少，而越会导致短函数检测不到。

3.5 Systrace

• ftrace：debugfs采集和读取trace数据，记录trace events

• atrace：用户侧的trace跟踪，聚合所有的trace event

• 系统级的Trace数据：锁监控等。

3.6 btrace(aka rhea) —— 进阶

• rhea-systrace ： 全函数插桩，自动生成Trace代码，对层数做限制，性能损耗50%

• rhea-mtrace：全函数插桩，抛弃systrace，自己统计函数耗时，最后数据展现同systrace。

• rhea-atrace：优化systrace性能，聚合更多性能数据：类加载、Lock、IO等。

3.7 Battery Historian

04 如何做性能优化？

4.1 现状分析

4.1.1 耗时成因

• CPU Time：循环、反射、序列化/反序列化，类解析

• IO Wait：IO操作，等待IO返回结果

• IPC：Binder调用耗时

• Lock Wait：主线程是等锁状态，等待其他线程或者自己超时唤醒。

• CPU Schedule：主线程是可执行状态，但是获取不到CPU时间片。

4.1.2 运行环境归因

• 根据耗时成因归类

• 根据运行所在线程环境采用不同的策略

1. 主线程优化

2. 运行时优化

3. 后台线程优化

4.1.3 抖音启动耗时归因

4.1.4 渲染分析

4.2 优化策略 (性能优化案例)

4.2.1 UI-构建解决方案

官方解决方案：AsyncLayoutInflater

4.2.2 数据请求 + 解析

GSON解析优化

数据协议优化：json → protobuf

4.2.3 渲染耗时优化

4.2.4 异步渲染

• SurfaceView：采用独立的线程进行绘制和渲染，生命周期需要自己控制。

• Jecpack Compose：基于组合优于继承的思想，重新设计一套解耦的UI框架。

• Litho：复杂UI下的高性能渲染框架。

  • 扁平化：Litho采用Yoga完成组件布局measure和layout，实现布局的扁平化。

  • 组件化：Litho使用Drawable作为Node绘制单元，实现了布局的细粒度复用和异步计算布局的能力。

  • 缺点：不支持现有逻辑，需要重新实现。