Android源码分析之Message
来源:互联网 发布:mac virtualbox 全屏 编辑:程序博客网 时间:2024/06/06 00:38
在Android的开发中,我们经常用到Handler.postXXX方法,或者View.postXXX方法,用来在下一次looper到来时执行。
我是那样的人,什么事情最好能够知道下内部实现机理是什么,否则我在用它的时候可能会觉得不爽,或者说不自然,不太愿意去用。
典型例子就是我始终不太愿意用Android引入的SparseArray<E>,而是一直坚持Java的HashMap<Key, Value>,直到我自己读了
SparseArray<E>的源码,才开始放心大胆的使用(后面会写一篇文章专门分析它)。
首先来看下面的代码:
private Runnable mRunnable = new Runnable() { @Override public void run() { // do something... removeCallbacks(this); }};postDelayed(mRunnable, SOME_DELAY_IN_MILLIMS);
第一直觉告诉我run方法里的removeCallbacks(this);调用显然是多余的。通读代码发现的确是如此,因为任何Message
(即使post的是Runnable也会被包装到Message里)在被处理之前都已经从MessageQueue里取出来了(delete掉了,所以客户端
代码大可不必有这样的代码)。这里顺便提下慎用View.removeCallbacks的返回值,看源码:
1 /** 2 * <p>Removes the specified Runnable from the message queue.</p> 3 * 4 * @param action The Runnable to remove from the message handling queue 5 * 6 * @return true if this view could ask the Handler to remove the Runnable, 7 * false otherwise. When the returned value is true, the Runnable 8 * may or may not have been actually removed from the message queue 9 * (for instance, if the Runnable was not in the queue already.)10 *11 * @see #post12 * @see #postDelayed13 * @see #postOnAnimation14 * @see #postOnAnimationDelayed15 */16 public boolean removeCallbacks(Runnable action) {17 if (action != null) {18 final AttachInfo attachInfo = mAttachInfo;19 if (attachInfo != null) {20 attachInfo.mHandler.removeCallbacks(action);21 attachInfo.mViewRootImpl.mChoreographer.removeCallbacks(22 Choreographer.CALLBACK_ANIMATION, action, null);23 } else {24 // Assume that post will succeed later25 ViewRootImpl.getRunQueue().removeCallbacks(action);26 }27 }28 return true;29 }
我们可以看到这个方法always返回true,所以不要基于它的返回值做任何事情,还有它的返回值的意义也需要格外留意下。
我在第一次看到这个方法时就自以为然的觉得返回值肯定代表了Runnable action有没有成功地从MessageQueue中移除,true代表成功
移除了,false代表移除失败,呵呵,你想错了。仔细看看方法的doc,人家说的是return true表示这个view可以让它的Handler
去处理这件事情,并没提及处理的结果,而且即使返回true的时候也不能说明Runnable就已经从MessageQueue中移除了,
比如说此时Runnable已经不在MessageQueue中了;其他情况都是返回false。这里顺便看眼View.postDelayed方法:
1 public boolean postDelayed(Runnable action, long delayMillis) {2 final AttachInfo attachInfo = mAttachInfo;3 if (attachInfo != null) {4 return attachInfo.mHandler.postDelayed(action, delayMillis);5 }6 // Assume that post will succeed later7 ViewRootImpl.getRunQueue().postDelayed(action, delayMillis);8 return true;9 }
这里不论是postDelayed还是removeCallbacks方法都首先检查了自己的mAttachInfo,如果非空才delegate给attachInfo的Handler
处理,所以你尽量不要过早(mAttachInfo还没初始化完毕)的调用这些方法。比如在早期版本的Android中如果你过早的调用post,
runnable不会被执行,参考这个问题:
http://stackoverflow.com/questions/4083787/runnable-is-posted-successfully-but-not-run;
感兴趣的同学可以在google中搜索view post runnable not run或者自行验证。我现在分析的是Android4.4的源码,依现在的代码来看
即使mAttachInfo是null,也会执行ViewRootImpl.getRunQueue().postDelayed(action, delayMillis); 所以可能在较新的平台上不是
问题(有待考证)。经测试验证确实没问题,即使在Activity.onCreate中调用View.postXXX方法,runnable还是会被执行。
好了说了一大堆了,开始正题。作为开始我今天挑了一个最简单的开始分析,那就是Message.java文件。
其实说白了,Message就是一个数据类,持有data的。基本的数据字段我就不介绍了,都能望文生义。看下几个我觉得有必要的字段:
1 /*package*/ Handler target; 2 3 /*package*/ Runnable callback; 4 5 // sometimes we store linked lists of these things 6 /*package*/ Message next; 7 8 private static final Object sPoolSync = new Object(); 9 private static Message sPool;10 private static int sPoolSize = 0;11 12 private static final int MAX_POOL_SIZE = 50;
target是消息的处理者,在以后Looper.loop()方法中Message被从MessageQueue取出来后会调用msg.target.dispatchMessage(msg);
callback是消息要执行的动作action。这里提前插播下Handler的dispatchMessage方法:
1 public void dispatchMessage(Message msg) { 2 if (msg.callback != null) { 3 handleCallback(msg); 4 } else { 5 if (mCallback != null) { 6 if (mCallback.handleMessage(msg)) { 7 return; 8 } 9 }10 handleMessage(msg);11 }12 }
我们可以看到Handler在分发消息的时候,Message自身的callback优先级高,先被调用如果非空的话(callback的run方法直接被调用)。
next表示消息队列中的下一个Message,类似单链表的概念。
剩下的pool相关的字段都是Message引入的重用(reuse)所要用到的变量,sPoolSync是对象锁,因为Message.obtain方法会在任意
线程调用;sPool代表接下来要被重用的Message对象;sPoolSize表示有多少个可以被重用的对象;MAX_POOL_SIZE显然是pool的上限,
这里hardcode是50。这里我要分析的就2个方法,
obtain和recycle,代码如下:
1 /** 2 * Return a new Message instance from the global pool. Allows us to 3 * avoid allocating new objects in many cases. 4 */ 5 public static Message obtain() { 6 synchronized (sPoolSync) { 7 if (sPool != null) { 8 Message m = sPool; 9 sPool = m.next;10 m.next = null;11 sPoolSize--;12 return m;13 }14 }15 return new Message();16 }17 18 /**19 * Return a Message instance to the global pool. You MUST NOT touch20 * the Message after calling this function -- it has effectively been21 * freed.22 */23 public void recycle() {24 clearForRecycle();25 26 synchronized (sPoolSync) {27 if (sPoolSize < MAX_POOL_SIZE) {28 next = sPool;29 sPool = this;30 sPoolSize++;31 }32 }33 }
首先我们来看obtain方法,第一次调用也就是说没有什么东西可以重用,这时sPool是null,直接new一个Message对象返回,等到
Message对象使用完毕(在Looper.loop方法最后有msg.recycle();这样的代码),它的recycle会被调用,在recycle里首先会调用
clearForRecycle方法,它只是把各个字段置空或清零。接下来sPoolSize没到上限,next保存下sPool的旧值(也就是在当前Message
回收利用之前上一个要被回收利用的对象),然后sPool被更新成新值,即当前Message,sPoolSize加1,表示又多了一个可以重用的
Message对象。之后在等到obtain被调用的时候就不是直接return一个new Message了,因为我们已经有可以重用的Message对象了。
将sPool的值设置给我们要返回的Message m对象,接着sPool被更新成上一个要被重用的Message对象(相比recycle是反向过程),
最后设置m的next字段为空(m.next会在重新入队列的时候被设置成合适的值),相应的sPoolSize减1,表示可重用的对象少了一个,
最后返回重用的对象m。
基于有这么个回收再利用的机制,Android建议我们调用Message的obtain方法来获取一个Message对象,而不是调用ctor,因为很
可能会省掉分配一个新对象的开销。
到目前为止,我们好像忽略了Message的一个(重要)方面,即异步性,代码如下:
/** * Sets whether the message is asynchronous. * * Asynchronous messages represent interrupts or events that do not require global ordering * with represent to synchronous messages. Asynchronous messages are not subject to * the synchronization barriers introduced by {@link MessageQueue#enqueueSyncBarrier(long)}. * * @param async True if the message is asynchronous. * * @see #isAsynchronous() * @see MessageQueue#enqueueSyncBarrier(long) * @see MessageQueue#removeSyncBarrier(int) * * @hide */ public void setAsynchronous(boolean async) { if (async) { flags |= FLAG_ASYNCHRONOUS; } else { flags &= ~FLAG_ASYNCHRONOUS; } }
看方法的doc,我们知道异步的Message表示那些不需要全局顺序的中断或事件(相比同步Message来说),这里的全局顺序是指
MessageQueue中的先后顺序,而且异步消息的处理不受MessageQueue中引入的enqueueSyncBarrier(long)方法的影响;
具体见MessageQueue的next()方法中有段这样的代码:
Message prevMsg = null; Message msg = mMessages; if (msg != null && msg.target == null) { // Stalled by a barrier. Find the next asynchronous message in the queue. do { prevMsg = msg; msg = msg.next; } while (msg != null && !msg.isAsynchronous()); }
也就是说当我们在队列中遇到一个sync barrier的时候,紧接着的同步Message的处理就会被本次循环忽略,而是直奔下一个
异步的消息。sync barrier是通过MessageQueue中的enqueueSyncBarrier(long when)、removeSyncBarrier(int token)
调用来实现添加、删除的;它们是在android.view.ViewRootImpl执行Traversals相关的代码时被调到的,代码如下:
final class TraversalRunnable implements Runnable { @Override public void run() { doTraversal(); } } final TraversalRunnable mTraversalRunnable = new TraversalRunnable(); void scheduleTraversals() { if (!mTraversalScheduled) { mTraversalScheduled = true; mTraversalBarrier = mHandler.getLooper().postSyncBarrier(); // 添加一个sync barrier mChoreographer.postCallback( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); scheduleConsumeBatchedInput(); } } void unscheduleTraversals() { if (mTraversalScheduled) { mTraversalScheduled = false; mHandler.getLooper().removeSyncBarrier(mTraversalBarrier); // 移除对应的sync barrier mChoreographer.removeCallbacks( Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); } } void doTraversal() { if (mTraversalScheduled) { mTraversalScheduled = false; mHandler.getLooper().removeSyncBarrier(mTraversalBarrier); // 移除对应的sync barrier if (mProfile) { Debug.startMethodTracing("ViewAncestor"); } Trace.traceBegin(Trace.TRACE_TAG_VIEW, "performTraversals"); try { performTraversals(); } finally { Trace.traceEnd(Trace.TRACE_TAG_VIEW); } if (mProfile) { Debug.stopMethodTracing(); mProfile = false; } } }
Message类的分析就到这了,以后会陆续分析下常见于Android开发中的类。。。(由于本人水平有限,欢迎批评指正)
转自:http://www.cnblogs.com/zhaoxiaowei/p/3660245.html
- Android源码分析之Message
- [Android源码]Message分析
- ZeroMQ源码分析之Message
- Message(Message Pool)源码分析
- Android消息机制源码分析--Lopper,Handler,Message
- Android 消息机制 - Handler, Looper, Message, MessageQueue 的源码分析
- Android开发Message源码分析【享元模式|对象池】
- Android Handler、Looper、MessageQueue以及Message源码分析
- android源码解析--Message
- android源码解析--Message
- AndRoid源码分析----------Handler消息机制(1)Handler获取Message对象及Message的复用
- Mongodb源码分析--消息(message)
- Mongodb源码分析--消息(message)
- Mongodb源码分析--消息(message)
- Handler-Looper-Message源码分析
- Mongodb源码分析--消息(message)
- Android 8.0系统源码分析--Message发送、处理过程源码分析
- Android源码解析之消息机制系列(一)Message
- css中单位px和em,rem的区别
- 1、《穷爸爸富爸爸》有感
- Dubbo+Zookeeper+Spring MVC+JDK8整合应用
- ASP.NET最新快速开发框架源码,用MVC+EF架构,前台使用Jquery+Bootstrap
- APC缓存简介
- Android源码分析之Message
- 如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
- url请求带参编码及解码
- Android 查看SIM卡状态及SIM信息
- 如何将他人实现的caffe的层整合到自己caffe的框架下
- Unity UGUI 的RectTransform参数的设置
- 利用iptables的DNAT功能实现流量转发
- Pascal's Triangle II
- file_get_contents 输出乱码问题