AndroidにおけるHandlerメッセージメカニズム
Androidで私たちが一般的に話しているメッセージメカニズムとは、Handlerメッセージ処理メカニズム、あるいはHandlerの実行メカニズムです.HandlerといえばLooper、MessageQueueと連絡を取るのは避けられません.Handlerはpost、send方式でMessageをMessageQueueに入れ、Looperは無限ループでMessageQueueがデータがあればデータがないと処理して待っています.
まず、ThreadLocalの動作原理
Looperにはこのような変数があるので、ThreadLocalが何者かを理解する必要があります.ThreadLocalはスレッド内部のデータ格納であり、ThreadLocalが呼び出される.set()メソッドの後、setスレッドでしかデータを入手できない他のスレッドはThreadLocal.get()はデータを得る.
ThreadLocal変数をプライマリスレッドにset(true)、Thread 1にset(false)と宣言し、Thread 2には何の処理もありません.
実行結果から、同じ変数でも異なるスレッドの読み取りが異なる値であることがわかります.これがThreadLocalの奇妙で奇妙な場所です.
次に、Looperのワークフロー
LooperオブジェクトのようにsThreadLocalに保存します.
LooperではmQueue=new MessageQueue(quitAllowed)がLooperとMessageQueueにチェックを入れるので、各Looperの内部にMessageQueueが1つずつ存在してMessageを格納します.
最後に、HandlerワークフローHandlerはpost、sendメッセージを実行できますが、最終的には呼び出しです.
現在送信されているMessageをメッセージキューに追加します.この時Looper.loop()メソッドはメッセージポーリングを待っています.
Message msg = queue.next()このコードは、データloopがないとブロックされ、msgがnullでない場合msgに起動する.target.dispatchMessage(msg)はここまで順調に行きます.その中でmsg.targetとは、実はHandlerオブジェクトなのでdispatchMessageメソッドにジャンプします
handlerならpost…(new Runnable…)ではhandleCallbackメソッドを実行してRunnableオブジェクトにコールバックするrunメソッドなので、このRunnableはスレッドではなくコールバッククラスにすぎません.handlerならsendMessage...シリーズはhandleMessageメソッドにコールバックするので、handleMessageというメッセージを書き換えるのが一般的です.もし私たちがHandler(Callback callback)でHanlderを初期化したらmCallbackになります.handleMessage(msg)なのでCallbackのhandleMessageを書き換えてメッセージを受信する必要があります.
最後に、典型的なHandlerを初期化したら?
しかし、メインスレッドで初期化するときにnew Handler()だけが必要であれば良いのですが、これはなぜですか.システムが起動するときにLooperが呼び出されているからです.prepare()とLooper.loop(). このように初期化された後、どのスレッドでそのHandler対応を初期化するかは、どのスレッドで実行され、その中でThreadLocalによって特定のスレッドの下のLooperが読み出される.
だからどのようにして1つのスレッドの中で1つのメインスレッドのHandlerを初期化しますか?
Looper.getMainLooper()取得はapp起動時にメインスレッドのLooperである.prepareMainLooperが初期化したLooperオブジェクトは,このLooperを転送することによってこのHandlerがプライマリスレッドにメッセージを転送する.
以上、Handlerメッセージメカニズムに対する私自身の理解です.
まず、ThreadLocalの動作原理
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
Looperにはこのような変数があるので、ThreadLocalが何者かを理解する必要があります.ThreadLocalはスレッド内部のデータ格納であり、ThreadLocalが呼び出される.set()メソッドの後、setスレッドでしかデータを入手できない他のスレッドはThreadLocal.get()はデータを得る.
ThreadLocal<Boolean> mThreadLocal = new ThreadLocal<Boolean>();
mThreadLocal.set(true);
System.out.println("--Main == " + mThreadLocal.get());
new Thread() {
public void run() {
mThreadLocal.set(false);
System.out.println("--thread1 == " + mThreadLocal.get());
};
}.start();
new Thread() {
public void run() {
System.out.println("--thread2 == " + mThreadLocal.get());
};
}.start();
ThreadLocal変数をプライマリスレッドにset(true)、Thread 1にset(false)と宣言し、Thread 2には何の処理もありません.
--Main == true --thread1 == false --thread2 == null
実行結果から、同じ変数でも異なるスレッドの読み取りが異なる値であることがわかります.これがThreadLocalの奇妙で奇妙な場所です.
次に、Looperのワークフロー
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
}
LooperオブジェクトのようにsThreadLocalに保存します.
private Looper(boolean quitAllowed) {
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
LooperではmQueue=new MessageQueue(quitAllowed)がLooperとMessageQueueにチェックを入れるので、各Looperの内部にMessageQueueが1つずつ存在してMessageを格納します.
最後に、HandlerワークフローHandlerはpost、sendメッセージを実行できますが、最終的には呼び出しです.
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
現在送信されているMessageをメッセージキューに追加します.この時Looper.loop()メソッドはメッセージポーリングを待っています.
public static void loop() {
final Looper me = myLooper();
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue;
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
// This must be in a local variable, in case a UI event sets the logger
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
msg.target.dispatchMessage(msg);
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
}
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "Thread identity changed from 0x"
+ Long.toHexString(ident) + " to 0x"
+ Long.toHexString(newIdent) + " while dispatching to "
+ msg.target.getClass().getName() + " "
+ msg.callback + " what=" + msg.what);
}
msg.recycleUnchecked();
}
}
Message msg = queue.next()このコードは、データloopがないとブロックされ、msgがnullでない場合msgに起動する.target.dispatchMessage(msg)はここまで順調に行きます.その中でmsg.targetとは、実はHandlerオブジェクトなのでdispatchMessageメソッドにジャンプします
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
handlerならpost…(new Runnable…)ではhandleCallbackメソッドを実行してRunnableオブジェクトにコールバックするrunメソッドなので、このRunnableはスレッドではなくコールバッククラスにすぎません.handlerならsendMessage...シリーズはhandleMessageメソッドにコールバックするので、handleMessageというメッセージを書き換えるのが一般的です.もし私たちがHandler(Callback callback)でHanlderを初期化したらmCallbackになります.handleMessage(msg)なのでCallbackのhandleMessageを書き換えてメッセージを受信する必要があります.
最後に、典型的なHandlerを初期化したら?
Looper.prepare();
new Handler();
Looper.loop();
しかし、メインスレッドで初期化するときにnew Handler()だけが必要であれば良いのですが、これはなぜですか.システムが起動するときにLooperが呼び出されているからです.prepare()とLooper.loop(). このように初期化された後、どのスレッドでそのHandler対応を初期化するかは、どのスレッドで実行され、その中でThreadLocalによって特定のスレッドの下のLooperが読み出される.
だからどのようにして1つのスレッドの中で1つのメインスレッドのHandlerを初期化しますか?
new Thread() {
@Override
public void run() {
new Handler(Looper.getMainLooper());
}
};
Looper.getMainLooper()取得はapp起動時にメインスレッドのLooperである.prepareMainLooperが初期化したLooperオブジェクトは,このLooperを転送することによってこのHandlerがプライマリスレッドにメッセージを転送する.
以上、Handlerメッセージメカニズムに対する私自身の理解です.