网络瀑布图介绍：什么是瀑布图、用于依赖分析的意义
你在调试 SystemUI 启动慢时，是不是经常盯着 log 日志一行行看？我一开始也这样。后来发现，盯着时间戳比对实在太低效了。真正让我开窍的，是学会了画瀑布图。
说白了，瀑布图就是一种按时间顺序展示各个事件开始和结束的条形图。从上往下看，就像瀑布一样层层叠落。每个横条代表一个阶段或一个任务，横条的长度就是耗时。多个横条之间的位置关系，能一眼看出它们是串行执行还是并行跑。
核心思想：一张图看清所有依赖链条，找到谁在等谁、谁拖慢了整体速度。
为什么 SystemUI 依赖分析偏偏要用瀑布图？
我做过好几个版本的 SystemUI 启动优化，最痛苦的就是不知道哪里卡住。你想想看，SystemUI 启动时要加载资源、绑定服务、创建窗口、注册广播…… 这些步骤之间常常有先后依赖。比如，StatusBar 得等通知管理器初始化完才能注册监听。如果依赖关系没梳理清楚，你根本不知道哪个环节是关键瓶颈。
瀑布图正好适合干这活。它天生就是为展示依赖时序而生的。在图上，你能看到：
- 哪些任务在并行跑，哪些在排队等
- 关键路径是哪条（最长的那条决定总耗时）
- 某个任务延迟了，会波及哪些下游任务
嗯，这里要注意：瀑布图不只是画几个矩形。关键是要把依赖箭头画上去。箭头表示“我必须等你做完才能开始”。没有箭头的瀑布图，顶多算个甘特图。
瀑布图里到底有什么元素？
我个人习惯把瀑布图拆成四个核心要素，你对照着看就懂了：
| 要素 | 定义 | 在 SystemUI 中的例子 |
|---|---|---|
| 阶段/任务 | 一个可独立观察的执行单元 | SystemUI 主线程初始化、注册广播接收器 |
| 时间线 | 从开始到结束的条形长度 | 从 T0 到 T0+120ms |
| 依赖箭头 | 表示前置条件 | StatusBar 必须等 NotificationManager 就绪 |
| 关键路径 | 图中最长的依赖链 | AM -> WM -> NS -> SB，决定启动总时长 |
一张图帮你理解：SystemUI 依赖解析网络瀑布图
下面这张图是一个简化的 SystemUI 启动依赖瀑布图。我故意把时间轴放在左侧，从上往下走。每个横条代表一个模块的生命周期，箭头表示依赖关系。你看完应该就能明白瀑布图是怎么表达依赖网络的。
这张图能告诉我们什么？
我在项目中遇到过这样的场景：有个同事总觉得是 StatusBar 启动慢，花了一周优化它的渲染代码。结果瀑布图一画，发现真正等的是 NotificationManager —— 它依赖 AMS 就绪，而 AMS 自己在等 WMS。实际问题在 WMS 的初始化。你看，依赖没理清，优化方向全错了。
从上面那张图里，你能发现几个关键信息：
- 关键路径： SystemServer → 通知管理器 → StatusBar → 首帧渲染。这条线最长，总耗时约 200ms。
- 并行机会： NavigationBar 和 StatusBar 在同一个时间窗口启动，但它们依赖的前置条件不同。如果 NavigationBar 不依赖通知管理器，理论上可以和 StatusBar 完全并行，能再压缩 30ms。
- 瓶颈点： 主线程初始化占据了 100ms 左右，而且它和通知管理器是串行的（因为我画了箭头）。但实际上，我后来在真机调试时发现，主线程初始化的一部分操作完全可以提前到 AMS 就绪阶段并行做。这就是瀑布图带来的优化空间。
怎么把瀑布图用到实际依赖分析中？
别觉得瀑布图只能用来事后分析。我在做 SystemUI 性能优化时，经常在开发阶段就画一个预期的瀑布图，然后等代码跑起来再用工具采集真实的时间戳，对比看看差异在哪。这种“预期 vs 实际”的对照，特别容易发现隐藏的依赖问题。
具体操作步骤我建议这样走：
- 列出所有任务节点 —— 比如资源加载、服务绑定、广播注册、视图创建。
- 标出每个节点的开始和结束时间戳 —— 可以用 Systrace 或自定义 log。
- 画出依赖箭头 —— 从代码逻辑里找出 wait / 回调 / 锁等待位置。
- 识别关键路径 —— 计算每条路径的总耗时，找最长的一条。
- 针对关键路径上的节点做优化 —— 比如提前初始化、并行化、懒加载。
你想想看，如果每次启动卡顿都只凭感觉猜哪个模块慢，那跟盲人摸象有什么区别？瀑布图就是给你一副透视眼镜。说实话，我现在接手任何 SystemUI 相关项目，第一件事就是让团队把模块的依赖图用瀑布方式画出来。哪怕只是草稿，也比空想强一百倍。
嗯，讲到这里，你应该已经清楚瀑布图是干什么用的了。它不只是一张图，更是一种系统化的依赖分析思维。下一回当你遇到 SystemUI 启动慢、响应卡顿，试试先画一张瀑布图，把依赖链条摆在桌面上。相信我，答案往往就在箭头的交汇处。