- Handler:
- interface Callback -> handleMessage(Message msg)
- handleMessage(Message msg): 交由子类定制自己的Message处理逻辑.
- dispatchMessage(Message msg):
- 如果msg自己的callback不是null, 那么会调用handleCallback(msg), message.callback.run()
- 如果mCallback不是null, 那么会调用mCallback.handleMessage(msg)
- 最后如果还没有人处理, 那么调用handleMessage(msg).
- 上面三步就是一个简单的职责链模式.
- Handler的构造函数有好几类:
- Handler()->this(null, false)
- Handler(Callback callback) -> this(callback, false)
- Handler(Looper looper) -> this(looper, null, false)
- Handler(Looper looper, Callback callback) -> this(looper, callback, false)
- Handler(boolean async) -> this(null, async): 异步Message
- Handler(Callback callback, boolean async): 没有指定Looper的构造需要一些额外操作:
- mLooper会尝试获取Looper.myLooper(), 获取该线程对应的TLS, 如果为null, 那么会throw RuntimeException.
- mQueue = looper.mQueue
- Handler(Looper looper, Callback callback, boolean async):
- mQueue = looper.mQueue
- String getMessageName(Message message):
- 如果message的callback不是null, 那么会返回message.callback.getClass().getName()
- 否则返回”0x” + Integer.toHexString(message.what)
- Message obtainMessage():
- Message.obtain(this): Message m = obtain(); m.target = h; return m: 可见Handler的obtainMessage()返回的Message默认已经打上了handler的烙印, target指向该handler
- obtainMessage(int what):
- 和上面基本相同, 只是多了会将what赋值给message的what.
- Message obtainMessage(int what, Object obj):
- 多了将obj赋值给message 的obj.
- obtainMessage(int what, int arg1, int arg2):
- m.arg1 = arg1; m.arg2 = arg2;
- obtainMessage(int what, int arg1, int arg2, Object obj):
- 复合体.
- boolean post(Runnable r):
- 如果成功的将r加入到MessageQueue, 那么返回true, 否则会因为message queue正在退出而返回false.
- boolean postAtTime(Runnable r, long uptimeMillis):
- 一个注意点是成功的将runnable插入(返回true)并不代表着r一定会在指定时间被执行，如果looper在这个时间点之前被quit, 那么runnable是不会被执行的.
- boolean postAtTime(Runnable r, Object token, long uptimeMillis):
- *
- postAtFrontOfQueue(Runnable r):
- 和不同的Post相对，普通的是追加到队列末尾，而这个则是放在队列头，高优先级.
- boolean runWithScissors(final Runnable r, long timeout), 一个比较特殊的方法:
- 如果当前方法调用的Thread就是Handler所依附的Thread, 那么r会被立即执行不需要入队，否则，将r加入到handler的队列中，并同步的等待其运行完毕
- 该方法是危险的，不当的使用会导致死锁(因为同步等待就是靠锁实现的), 永远不要在重入的操作中调用此方法.
- 该方法的一个使用case是这样:一个后台线程需要同步的等待在一个handler中的某一个Task的运行完毕，不过这往往是垃圾设计的一个征兆，这个时候可能改进程序设计更合适
- 那么一个合适的使用例子是这样的: 启动一个HandlerThread，并且要在其上进行一些初始化操作之后，才能继续执行整个程序
- 如果超时的话，会返回false.
- 如果使用了这个方法，那么在结束Looper的时候一定要调用Looper的quitSafely, 否则会造成这个方法的永久挂起
- 从注释看，这个方法不受待见，应该会被拿掉或者修改或者hide.
- 其实现很简单: 先判断handler的Looper是否是当前Thread的Looper，如果是，那么直接Runnable.run(), 否则new一个BlockingRunnable(r)，然后调用其br.postAndWait(this, timeout)
- removeCallbacks(Runnable r):
- mQueue.removeMessages(this, r, null);
- removeCallbacks(Runnable r, Object token):
- mQueue.removeMessages(this, r, token);
- sendMessage(Message msg):
- 最简单的使用，将msg插入到当前队列的末尾(除去那么运行时间是当前之后的Message)
- sendEmptyMessage(int what)：
- 发一个空的Message, 只有一个what值.
- sendMessageAtFrontOfQueue(Message msg):
- postAtFrontOfQueue的实现体， 真正的操作MessageQueue
- enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis):
- 将msg的tagert设置为handler, 将Message和handler关联起来
- 如果是异步的, 那么还会msg.setAsynchronous(true);
- 最后queue.enqueueMessage(msg, uptimeMillis);
- removeMessages(…):
- 支持好几种查找方式: what, callback, Object
- hasMessages(…)/hasCallbacks(…)
- 还提供了RPC的接口:
- class MessengerImpl extends IMessenger.Stub:
- 供RPC使用，send(Message msg)实现也只是简单的调用Handler的sendMessage(msg)
- getIMessenger():
- 会同步mQueue(因为涉及到多线程: binder线程池中的线程)
- 如果没有可用的mMessenger，会new一个MessengerImpl()然后返回.
- class BlockingRunnable implements Runnable:
- 接受一个Runnable作为构造参数，包含了真正要执行的Task, mTask
- run()函数很简单，直接调用mTask.run(), 一个finally内会同步对象本身(因为mDone涉及到多线程，而notifyAll()则需要synchronized配合)
- postAndWait(Handler handler, long timeout)(根据后面的逻辑，显然这个handler依附的Thread不能是这个函数调用的线程):
- 在调用线程上调用的函数,和run()运行时不一定是一个线程
- 首先尝试将BlockingRunnable自己post到handler上，如果post都失败，那么直接返回false.
- 然后就需要同步对象本身(为了使用wait()),
- 如果timeout>0, 那么就一个while循环 + wait(…), 中间有任何的interrupt都直接catch重新计算wait的时间, 只有在任务完成(mDone = true, 另外一个线程的run()函数会设置此值)或者超时才会返回(true/false)
- 如果timeout <=0, 那么就是无限等待了.
