Android 显示问题最终常落到两个问题上：一块 Buffer 什么时候被拿去合成，以及它以什么形式交给显示硬件。SurfaceFlinger 的核心价值就在这里。它不负责 App 怎么画，也不直接控制 DPU 的寄存器；它站在系统窗口模型和硬件合成能力之间，把可见 Layer、Buffer、VSync、Fence、HWC 策略组织成一次可送显的提交。 这条链路看起来长，但边界清楚。App 生产

本文内容整理自技术讲解视频《handler 运行的整个流程源码解析》。 主线程里有一个 for (;;) 死循环，从应用启动一直转到进程结束，应用却不卡。死循环与不卡顿为什么能同时成立？ 原因可以总结为：send 系列方法把消息交给 Handler.enqueueMessage，消息带着一个执行时刻 when 被插进 MessageQueue 的单向链表（按 when 升序，所以它是优先级队列而不

本文内容整理自享学团队直播课《App 启动流程源码分析（五）》 一、从启动屏动画到 Application 有一个很容易复现的现象：给 Application.onCreate 的头尾各打一个 Trace.beginSection / endSection，测出来只有 30ms；但用 adb shell am start -W 量整体，接入几个三方 SDK 前后 TotalTime 涨了一百多毫秒

本文内容整理自享学团队直播课《App 启动流程源码分析（四）》 一、App启动性能标准设定 点击桌面图标，屏幕立刻被一整块纯白（或纯黑）铺满，几百毫秒后才切成 App 的真实界面。可以通过在冷启动过程中执行 adb shell dumpsys window windows grep -i starting进行流程观测，通过上述命令能看到一个类型为 TYPEAPPLICATIONSTARTING

本文内容整理自享学团队直播课《App 启动流程源码分析（三）》 一、从 WMS 方向看启动，问题落在哪里 冷启动的耗时账单最后要落到"首帧什么时候上屏"，这条线的终点在 WMS 一侧。但往回追一步就会撞上一个不太好回答的地方：进程创建完成、ApplicationThread 回连 AMS 之后，AMS 在同一段加锁逻辑里干了两件事——把 Application 的信息发过去，以及把 Activit

本文内容整理自享学团队直播课《App 启动流程源码分析（二）》 一、本集要解决的问题 《一》把"启动"的边界定死了：从点击 icon 到主 Activity 显示。也画了四进程的地图，结尾留了一个口子——下一篇从 Launcher 的 startActivity 跟到 AMS 请求 Zygote fork。本集从这个口子接上。 核心问题只有一个：从点击桌面图标，到 App 进程真正跑起来并创建好

本文内容整理自享学团队直播课《App 启动流程源码分析（一）》 一、耳熟能详的优化方向，为什么不足以解决问题 避免主线程 IO、减少主线程耗时、减少布局层级、优化线程的使用方式、对部分启动任务做懒加载与按需加载、用 profile 工具定位热点——这些条目出现在几乎每一份启动优化清单里。它们单独看都成立，麻烦在于它们是并列的散点，条目之间没有先后关系，也没有权重。 散点式优化的典型失效方式，是注意

一、为什么需要理解事件分发 Android 提供的原生控件——比如 Button、ScrollView、RecyclerView——内部已经把事件处理逻辑写好了。用它们的时候，你几乎不需要操心事件冲突的问题。 但一旦开始写自定义 View，情况就变了。比如你做了一个自定义的滑动面板，里面嵌套了一个列表，手指一滑，要么外面的面板不动，要么里面的列表不响应。这就是事件冲突。 要解决冲突，就必须搞清楚两