Message 产生
用户滑动屏幕,产生了一系列 input 事件 (一个 Down 事件,若干个 Move 事件,一个 Up 事件),这些事件被系统包装成了一系列 Message(一个 Down Message,若干个 Move Message,一个 Up Message)
Message 是用来传递信息的,上述 Message 中就包含了这些 input 事件的信息,比如 x 坐标,y 坐标。
MessageQueue 存放 Message
Message 产生后,有一个问题就是这些 Message 怎么发给应用?我要滑动朋友圈,那么这些个 Message 就得传给微信,让微信去处理,微信将这些事件给到朋友圈的 List 控件,让 List 产生新内容,并且实现上下滑动。
首先想到的能不能直接把这些 Message 给到朋友圈的 List 控件(SystemServer 可以直接 Binder 发给 List 控件),可以是可以,但是麻烦;SystemServer 直接给朋友圈的 List 控件发 input message,那 SystemServer 得先知道有这么个控件,问题是应用有哪些控件,SystemServer 是不知道的,难道要遍历所有的控件,每个控件都发一个重复的 Message?这显然不是我们想要的。
SystemServer 不能直接发给控件,那么能不能直接发给应用,让应用自己去处理呢?答案是肯定的,现在的 Android 也是这么做的, 你应用准备一个 MessageQueue(消息队列),我有 Message 就放到这个 MessageQueue 里面,你应用自己去处理,岂不美哉,这就是 MessageQueue 出现的原因
Looper 派发 Message
应用准备了一个 MessageQueue 之后,SystemServer 把之前包装好的一系列 Input Message(一系列 Message(一个 Down Message,若干个 Move Message,一个 Up Message))放到了微信的 MessageQueue 里面,剩下的就让微信自己去读取 MessageQueue 里面的内容,自己更新 UI 去
问题是 MessageQueue 只是用来存放 Message 的,得有人来管理这个 MessageQueue。比如 MessageQueue 里面进了几个 Message,这些 Message 该到发给谁去处理?
这里就引入了 Looper,Looper 来决定这个 Message 该发给谁去处理,Looper 会按照 Message 在 MessageQueue 里面的顺序,一个一个取出 Message,根据 Message 自带的信息(我想被谁处理 - target),发给对应的人去处理
这个例子里面,这些 Message 的 target 就是微信的主线程的 handler
Handler 处理 Message
这时候,Handler 出场了,上面说 Looper 把 Message 发给对应的人去处理,这个人就是 Handler。Handler 就是用来处理 Message 的,作为 Message 机制的最后一环,Handler 读取 Message 内容后,根据内容来做相关的处理。
这个例子里面,一系列 Input Message 最终会由微信的主线程 Handler 来处理,经过复杂的事件传递和事件分发流程,传给对应的 List 控件,List 控件根据 Input Message 里面的内容,计算出自己下一帧的各个 Item 的位置,更新自己的 Item 和 Item 内的内容,从而产生 List 滑动效果,朋友圈滑动的流程就完成了
Message 机制总结
有了上面的 Message 机制的案例,理解下面这张图就顺理成章了,如上面几个标题所示
- Message 承载内容
- MessageQueue 存放 Message
- Looper 派发 Message
- Handler 处理 Message