Surface 是一块内存吗？从 Java 层的使用方式看，lockCanvas 像是直接锁定一块画布。底层对象关系却显示，Surface 并不对应一块固定内存。它持有 IGraphicBufferProducer（下文简称 IGBP），也就是 GraphicBuffer 生产者的远程 Binder 对象。 App 进程里的 Surface、Canvas 和 SkBitmap 负责申请缓冲区并

一帧画面为什么要等 VSync？requestLayout 发起布局请求后，App 如何申请下一个信号，SurfaceFlinger 又如何把它送回 App 主线程？这条链路横跨 Java、JNI、Binder、Unix socket 与 Looper。 一、VSync 要解决的问题：为什么不能想画就画 1.1 一次 requestLayout 到一次真正上屏 requestLayout

在 onDraw 里画完的东西不会立刻出现在屏幕上。这不是 Android 故意拖慢刷新，而是因为“画进内存”和“显示到屏幕”本来就是两件事：App 先把像素写进一块 Buffer，再把它交出去；SurfaceFlinger 等到合适的刷新时刻，合成各个窗口的 Buffer，最后才把结果送给显示硬件。 这条链路真正的节拍器是 Vsync，即垂直同步信号。对 60Hz 屏幕来说，它约每 16.6

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

InputDispatcher 已经选中目标窗口，并把触摸事件写进对应的 socket。应用进程此时没有主动向系统轮询，它怎么及时接住事件，又怎么把一个 native 消息送到 Java 的 View 树？另一个常见疑问是：上层窗口没有消费事件，系统能否把同一事件继续交给下层窗口？ 应用侧的完整链路由注册、监听、读取和分发组成。ViewRootImpl.setView 通过 WindowSessi

Q：一次手指触摸屏幕，产生的 MotionEvent 怎样从内核输入设备文件到达 View.dispatchTouchEvent？应用在原窗口上覆盖一个全屏窗口，能否由上层窗口接收触摸，再把事件交给下面的窗口？ A：输入链路是一条由系统侧控制的单向流水线。EventHub 从 /dev/input 读取原始事件，InputReader 将其解释成设备无关的 NotifyMotionArgs，Inp

本文整理自 corpus 仓库中的以下三集课程： 本文源码基准为 AOSP android-6.0.0_r1。一次 ContentResolver.insert 看上去是普通的方法调用，开始数据操作前，客户端却要先取得一个 IContentProvider。这个接口可能指向本进程对象，也可能是另一个进程中 ContentProvider 的 Binder 代理。 代理的取得过程由客户端两级缓存

一次广播从应用发出后，系统怎样找到接收者，又怎样把调用送回 onReceive？动态注册和 manifest 静态声明使用不同的收集路径，却会在 AMS 的分发阶段汇合。本文沿注册、入队、投递与完成回调追踪对象和状态的变化，并说明静态接收者为何依赖目标进程的创建与 attach。全文源码以 AOSP android-6.0.0_r1 为基准。 一、一次广播的两个入口：注册与发送 1.1 示例里的三