App 启动流程源码分析（五）：Application 启动阶段与启动框架设计
本文内容整理自享学团队直播课《App 启动流程源码分析（五）》 一、从启动屏动画到 Application 有一个很容易复现的现象：给 Application.onCreate 的头尾各打一个 Trace.beginSection / endSection，测出来只有 30ms；但用 adb shell am start -W 量整体，接入几个三方 SDK 前后 TotalTime 涨了一百多毫秒
App 启动流程源码分析（四）：黑白屏原因与优化方向
本文内容整理自享学团队直播课《App 启动流程源码分析（四）》 一、App启动性能标准设定 点击桌面图标，屏幕立刻被一整块纯白（或纯黑）铺满，几百毫秒后才切成 App 的真实界面。可以通过在冷启动过程中执行 adb shell dumpsys window windows grep -i starting进行流程观测，通过上述命令能看到一个类型为 TYPEAPPLICATIONSTARTING
App 启动流程源码分析（三）：启动耗时分析 — WMS 方向
本文内容整理自享学团队直播课《App 启动流程源码分析（三）》 一、从 WMS 方向看启动，问题落在哪里 冷启动的耗时账单最后要落到"首帧什么时候上屏"，这条线的终点在 WMS 一侧。但往回追一步就会撞上一个不太好回答的地方：进程创建完成、ApplicationThread 回连 AMS 之后，AMS 在同一段加锁逻辑里干了两件事——把 Application 的信息发过去，以及把 Activit
App 启动流程源码分析（一）：先定义清楚"启动"，再谈优化
本文内容整理自享学团队直播课《App 启动流程源码分析（一）》 一、耳熟能详的优化方向，为什么不足以解决问题 避免主线程 IO、减少主线程耗时、减少布局层级、优化线程的使用方式、对部分启动任务做懒加载与按需加载、用 profile 工具定位热点——这些条目出现在几乎每一份启动优化清单里。它们单独看都成立，麻烦在于它们是并列的散点，条目之间没有先后关系，也没有权重。 散点式优化的典型失效方式，是注意
