Android 7.0 Message Que詳細
22685 ワード
Androidにおけるメッセージ処理機構はHandlerに大きく依存している。各Handlerには対応するLooperがあり、常に対応するMessage Queからメッセージを取り出して処理する。
これまでMessage QueはJava層の抽象的なものだと思っていましたが、実際にMessage Queの主要な部分はNative層の中にあります。
自分はMessage QueのNative層での仕事にあまり詳しくないので、この機会に分析してみます。
一、メッセンジャーQueの作成
Looperを使用する必要がある場合、Looperのprepare関数を呼び出します。
メッセンジャーQueの構造関数を見てみます。
2 Native層のlooper
Native層looperの構造関数を見ます。
二、メッセンジャーQueを使う
1書き込みメッセージ
Androidでは、Java層でメッセージをMessage Queに書き込むこともでき、Native層でメッセージをMessage Queに書き込むこともできます。私たちはそれぞれ対応する操作の流れを見ます。
1.1 Java層書き込みメッセージ
Java層はメッセージをMessage Queに書き込み、enqueue Message関数に依存する:
私達はnative Awakeをフォローします。
実際にMessage Queからデータを取り出す時、データが来ないなら、epollを利用して待ちます。したがって、Java層がメッセージを書き込むと、待ち状態のメッセージQueが呼び覚まされます。
後の記事でMessage Queからメッセージを抽出すると、再度この問題を分析します。
1.2 Native層書き込みメッセージ
Native層書き込みメッセージは、Native層looperのsendMessage関数に依存します。
2、メッセージを抽出する
Java層のLooperオブジェクトがloop関数を呼び出すと、Message Queを使用してメッセージを抽出し始めます。
メッセージを抽出する全体のプロセスは、概略上の図に示されている。
Java層では、LooperがMessage Queのメッセージを取り出す以外に、列の空き時間にIdleHandler定義の関数を実行することも見られます。
2.1 native PollOnce
今唯一の疑問点は、native PollOnceがどのようにNative層データを処理しているかです。対応するnative関数を見てみます。
正直に言えば、native層のコードは乱れています。この関数の機能は多いです。
上記の図に示すように、native PollOnceでは、epollで傍受してデータが到来したかどうか、その後、native message、native resonseを処理する。
最後に、どのようにnative層にrequestを入れるかを見ます。
3モニタ要求の追加
native層の増加requestはlooperのインターフェースaddFdに依存する:
指定されたイベントが発生したら、コールバック関数とパラメータ構造で対応するレスポンスを利用します。
native層のlooperがレスポンスを処理すると、対応するコールバック関数が実行されます。
実際のコードを見てください。
三、まとめ
1、流れのまとめ
Message Queの全体の流れはJavaの部分とNativeの部分を含んでいます。Native層の比重はやはり大きいことが図から分かります。上の図に合わせて、Message Que全体の対応する処理フローを思い出します。
1、Java層がLooperオブジェクトを作成すると、Java層のメッセンジャーQueが作成されます。Java層のメッセンジャーQueを初期化すると、Native関数を利用してNative層のメッセンジャーQueを作成します。
2、Native層のメッセンジャーQueを初期化すると、対応するNative Looperオブジェクトを作成します。Nativeオブジェクトを初期化すると、対応するepollFdとWakeEventFdが作成されます。ここで、epollFdは、epollの傍受ピリオドとして、初期の時はepollFdはWakeEventFdのみを傍受します。
3、図中の赤い線がLooperでMessage Queからメッセージを取る時、処理ロジックの流れです。
3.1、Java層のLooperがサイクルを開始する時、まずJNI関数でNative Looperを呼び出してpollOnceの操作を行う必要があります。
3.2、Native Looperが運転を開始したら、epollFdが呼び覚まされるのを待つ必要があります。epollFdがタイムアウトを待っている時や傍受しているハンドルにイベントが来ると、Native Looperはイベントの処理を開始できます。
3.3、Native層では、Native LooperはNative Message Queのメッセージを先に処理し、Resonse対応のコールバック関数を呼び出します。
3.4、今回のサイクルでNative層イベントが処理された後、Java層におけるMessage Queのメッセージの処理を開始します。メッセージがない場合は、MessageQueに処理が必要です。また、Message QueにIdlerが存在する場合は、IdleHandler定義の処理関数を呼び出します。
図中の青の部分は対応する関数の呼び出しです。
Java層:
Message QueのaddIIdleHandlerを利用して、Message QueのためにIdlerを追加することができます。
メッセンジャーQueのenqueue Messageを利用して、メッセンジャーQueにメッセージを追加することができます。必要に応じてNative関数を利用して、epollFdを起動するためにNative層のWakeEventFdにメッセージを書き込みます。
Native層:
looper:sendMessageを利用してNative Message Queにメッセージを追加できます。同じように、必要な時は、epollFdを起動するためにNative層のWakeEventFdにメッセージを書き込みます。
looper:addFdを利用してNative Looperに傍受要求を登録することができ、傍受要求は傍受したいfd、傍受したいイベントおよび対応するコールバック関数などを含み、傍受要求に対応するfdはepollFd傍受の対象となります。傍受されたfdに対応するイベントが発生すると、epollFdが起動され、その際に対応するレスポンスが加わったレスポンスListが生成され、処理が待つ。レスポンスが処理されると、対応するコールバック関数が呼び出されます。
2、注意事項
メッセンジャーQueは、Java層とNative層にそれぞれ格納構造があり、それぞれメッセージを追加することができる。処理ロジックでは、native層のMessageを優先的に処理し、Native層で生成されたレスポンスを処理し、最後にJava層のメッセンジャーを処理する。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。
これまでMessage QueはJava層の抽象的なものだと思っていましたが、実際にMessage Queの主要な部分はNative層の中にあります。
自分はMessage QueのNative層での仕事にあまり詳しくないので、この機会に分析してみます。
一、メッセンジャーQueの作成
Looperを使用する必要がある場合、Looperのprepare関数を呼び出します。
public static void prepare() {
prepare(true);
}
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
//sThreadLocal ; Looper
sThreadLocal.set(new Looper(quitAllowed));
}
private Looper(boolean quitAllowed) {
// MessageQueue
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}
1 NativeMessage QueメッセンジャーQueの構造関数を見てみます。
MessageQueue(boolean quitAllowed) {
mQuitAllowed = quitAllowed;
//mPtr long?
mPtr = nativeInit();
}
MessageQueのコンストラクターからnative関数を呼び出しました。android_を見てみます。オズMessage Que.cppでの実現:
static jlong android_os_MessageQueue_nativeInit(JNIEnv* env, jclass clazz) {
//MessageQueue Native
NativeMessageQueue* nativeMessageQueue = new NativeMessageQueue();
............
// long , Java ; Java , native long ,
return reinterpret_cast<jlong>(nativeMessageQueue);
}
NativeMessage Queの構造関数をフォローします。
NativeMessageQueue::NativeMessageQueue() :
mPollEnv(NULL), mPollObj(NULL), mExceptionObj(NULL) {
// Native Looper,
mLooper = Looper::getForThread();
if (mLooper == NULL) {
mLooper = new Looper(false);
Looper::setForThread(mLooper);
}
}
コードから見ると、Native層とJava層は全部Looperオブジェクトであり、MessageQueを操作しているはずです。MessageQueは、Java層とNative層にそれぞれ格納構造があり、それぞれJava層とNative層のメッセージを格納する。2 Native層のlooper
Native層looperの構造関数を見ます。
Looper::Looper(bool allowNonCallbacks) :
mAllowNonCallbacks(allowNonCallbacks), mSendingMessage(false),
mPolling(false), mEpollFd(-1), mEpollRebuildRequired(false),
mNextRequestSeq(0), mResponseIndex(0), mNextMessageUptime(LLONG_MAX) {
// fd
mWakeEventFd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
.......
rebuildEpollLocked();
}
native層では、Message QueのLooper初期化時に、rebuildEpollLocked関数も呼び出しました。私達はフォローします。
void Looper::rebuildEpollLocked() {
// Close old epoll instance if we have one.
if (mEpollFd >= 0) {
close(mEpollFd);
}
// Allocate the new epoll instance and register the wake pipe.
mEpollFd = epoll_create(EPOLL_SIZE_HINT);
............
struct epoll_event eventItem;
memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
eventItem.events = EPOLLIN;
eventItem.data.fd = mWakeEventFd;
// mEpollFd mWakeEventFd
int result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeEventFd, & eventItem);
...........
for (size_t i = 0; i < mRequests.size(); i++) {
const Request& request = mRequests.valueAt(i);
struct epoll_event eventItem;
request.initEventItem(&eventItem);
// request fd
int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, request.fd, & eventItem);
............
}
}
native層のlooperから,Native層がepollに依存してイベント処理を駆動することが分かった。ここではまず大体の映像を残して、後の文を詳しく分析します。二、メッセンジャーQueを使う
1書き込みメッセージ
Androidでは、Java層でメッセージをMessage Queに書き込むこともでき、Native層でメッセージをMessage Queに書き込むこともできます。私たちはそれぞれ対応する操作の流れを見ます。
1.1 Java層書き込みメッセージ
Java層はメッセージをMessage Queに書き込み、enqueue Message関数に依存する:
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) {
if (mQuitting) {
.....
return false;
}
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
// , MessageQueue ,
needWake = mBlocked;
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) {
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
// ,needWake false
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
上記のコードは比較的簡単で、主に新規加入したMessageを実行時間ごとに元のキューに挿入し、状況に応じてnative Awake関数を呼び出します。私達はnative Awakeをフォローします。
void NativeMessageQueue::wake() {
mLooper->wake();
}
void Looper::wake() {
uint64_t inc = 1;
// mWakeEventFd
ssize_t nWrite = TEMP_FAILURE_RETRY(write(mWakeEventFd, &inc, sizeof(uint64_t)));
.............
}
native層のlooper初期化において、native層のlooperがepollを利用してイベントを駆動することに言及しました。ここで構築されたepollハンドルはmWakeEventFdを傍受しました。実際にMessage Queからデータを取り出す時、データが来ないなら、epollを利用して待ちます。したがって、Java層がメッセージを書き込むと、待ち状態のメッセージQueが呼び覚まされます。
後の記事でMessage Queからメッセージを抽出すると、再度この問題を分析します。
1.2 Native層書き込みメッセージ
Native層書き込みメッセージは、Native層looperのsendMessage関数に依存します。
void Looper::sendMessage(const sp<MessageHandler>& handler, const Message& message) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
sendMessageAtTime(now, handler, message);
}
void Looper::sendMessageAtTime(nsecs_t uptime, const sp<MessageHandler>& handler,
const Message& message) {
size_t i = 0;
{
AutoMutex _l(mLock);
//
size_t messageCount = mMessageEnvelopes.size();
while (i < messageCount && uptime >= mMessageEnvelopes.itemAt(i).uptime) {
i += 1;
}
// message MessageEnvelope
MessageEnvelope messageEnvelope(uptime, handler, message);
mMessageEnvelopes.insertAt(messageEnvelope, i, 1);
// Optimization: If the Looper is currently sending a message, then we can skip
// the call to wake() because the next thing the Looper will do after processing
// messages is to decide when the next wakeup time should be. In fact, it does
// not even matter whether this code is running on the Looper thread.
if (mSendingMessage) {
return;
}
}
// Wake the poll loop only when we enqueue a new message at the head.
if (i == 0) {
// , wake epoll
wake();
}
}
以上がメッセンジャーQueにメッセージを入れる主な流れです。次にメッセンジャーQueからメッセージを取り出す流れを見てみます。2、メッセージを抽出する
Java層のLooperオブジェクトがloop関数を呼び出すと、Message Queを使用してメッセージを抽出し始めます。
public static void loop() {
final Looper me = myLooper();
.......
for (;;) {
Message msg = queue.next(); // might block
.......
try {
// Message
msg.target.dispatchMessage(msg);
}........
}
}
ここではメッセンジャーQueのnext関数を見ます。
Message next() {
//mPtr NativeMessageQueue
final long ptr = mPtr;
.......
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
// Native , IPCThread talkWithDriver, Binder
// ?
Binder.flushPendingCommands();
}
// native , epoll blocked
nativePollOnce(ptr, nextPollTimeoutMillis);
synchronized (this) {
final long now = SystemClock.uptimeMillis();
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());
}
if (msg != null) {
if (now < msg.when) {
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else {
// Got a message.
mBlocked = false;
// next
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
// No more messages.
nextPollTimeoutMillis = -1;
}
// Process the quit message now that all pending messages have been handled.
if (mQuitting) {
dispose();
return null;
}
//MessageQueue IdleHandler , MessageQueue , IdleHandler
//pendingIdleHandlerCount IdleHandler, -1
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
//mIdleHandlers size 0, addIdleHandler
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
// IdleHandler PendingIdleHandlers
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
// ArrayList.toArray(T[]) ; Message.Next ,
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
// queueIdle ,
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
pendingIdleHandlerCount = 0;
nextPollTimeoutMillis = 0;
}
}
メッセージを抽出する全体のプロセスは、概略上の図に示されている。
Java層では、LooperがMessage Queのメッセージを取り出す以外に、列の空き時間にIdleHandler定義の関数を実行することも見られます。
2.1 native PollOnce
今唯一の疑問点は、native PollOnceがどのようにNative層データを処理しているかです。対応するnative関数を見てみます。
static void android_os_MessageQueue_nativePollOnce(JNIEnv* env, jobject obj,
jlong ptr, jint timeoutMillis) {
// Java native MessageQueue , long ptr
NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);
nativeMessageQueue->pollOnce(env, obj, timeoutMillis);
}
void NativeMessageQueue::pollOnce(JNIEnv* env, jobject pollObj, int timeoutMillis) {
mPollEnv = env;
mPollObj = pollObj;
// Native looper pollOnce
mLooper->pollOnce(timeoutMillis);
mPollObj = NULL;
mPollEnv = NULL;
if (mExceptionObj) {
.........
}
}
native層looperのpollOnce関数を見てください。
//timeoutMillis 。 -1 , ; 0 ,
//outFd null, :
//outEvents null, : outFd , 、 、
//outData null, : ,
int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
int result = 0;
for (;;) {
// response, response
while (mResponseIndex < mResponses.size()) {
const Response& response = mResponses.itemAt(mResponseIndex++);
int ident = response.request.ident;
if (ident >= 0) {
int fd = response.request.fd;
int events = response.events;
void* data = response.request.data;
if (outFd != NULL) *outFd = fd;
if (outEvents != NULL) *outEvents = events;
if (outData != NULL) *outData = data;
return ident;
}
}
// pollInner ,
if (result != 0) {
if (outFd != NULL) *outFd = 0;
if (outEvents != NULL) *outEvents = 0;
if (outData != NULL) *outData = NULL;
return result;
}
// pollInner
result = pollInner(timeoutMillis);
}
}
pollInner関数をフォローします。
int Looper::pollInner(int timeoutMillis) {
// Adjust the timeout based on when the next message is due.
//timeoutMillis Java
//native native message
//
if (timeoutMillis != 0 && mNextMessageUptime != LLONG_MAX) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
int messageTimeoutMillis = toMillisecondTimeoutDelay(now, mNextMessageUptime);
if (messageTimeoutMillis >= 0
&& (timeoutMillis < 0 || messageTimeoutMillis < timeoutMillis)) {
timeoutMillis = messageTimeoutMillis;
}
}
int result = POLL_WAKE;
//pollInner response
mResponses.clear();
mResponseIndex = 0;
// We are about to idle.
mPolling = true;
// epoll mEpollFd
struct epoll_event eventItems[EPOLL_MAX_EVENTS];
int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
// No longer idling.
mPolling = false;
// Acquire lock.
mLock.lock();
// rebuildEpollLocked , epoll request fd
if (mEpollRebuildRequired) {
mEpollRebuildRequired = false;
rebuildEpollLocked();
goto Done;
}
// Check for poll error.
if (eventCount < 0) {
if (errno == EINTR) {
goto Done;
}
......
result = POLL_ERROR;
goto Done;
}
// Check for poll timeout.
if (eventCount == 0) {
result = POLL_TIMEOUT;
goto Done;
}
for (int i = 0; i < eventCount; i++) {
if (fd == mWakeEventFd) {
if (epollEvents & EPOLLIN) {
// , java native , mWakeEventFd, epoll
//awoken mWakeEventFd
awoken();
} else {
.........
}
} else {
//epoll request fd
ssize_t requestIndex = mRequests.indexOfKey(fd);
if (requestIndex >= 0) {
int events = 0;
if (epollEvents & EPOLLIN) events |= EVENT_INPUT;
if (epollEvents & EPOLLOUT) events |= EVENT_OUTPUT;
if (epollEvents & EPOLLERR) events |= EVENT_ERROR;
if (epollEvents & EPOLLHUP) events |= EVENT_HANGUP;
// fd response
pushResponse(events, mRequests.valueAt(requestIndex));
} else {
..........
}
}
}
Dune:
// Invoke pending message callbacks.
mNextMessageUptime = LLONG_MAX;
// Native Message
while (mMessageEnvelopes.size() != 0) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
if (messageEnvelope.uptime <= now) {
// Remove the envelope from the list.
// We keep a strong reference to the handler until the call to handleMessage
// finishes. Then we drop it so that the handler can be deleted *before*
// we reacquire our lock.
{
sp<MessageHandler> handler = messageEnvelope.handler;
Message message = messageEnvelope.message;
mMessageEnvelopes.removeAt(0);
mSendingMessage = true;
mLock.unlock();
// Native Message
handler->handleMessage(message);
}
mLock.lock();
mSendingMessage = false;
result = POLL_CALLBACK;
} else {
// The last message left at the head of the queue determines the next wakeup time.
mNextMessageUptime = messageEnvelope.uptime;
break;
}
}
// Release lock.
mLock.unlock();
// response
for (size_t i = 0; i < mResponses.size(); i++) {
Response& response = mResponses.editItemAt(i);
if (response.request.ident == POLL_CALLBACK) {
int fd = response.request.fd;
int events = response.events;
void* data = response.request.data;
// response callback
int callbackResult = response.request.callback->handleEvent(fd, events, data);
if (callbackResult == 0) {
removeFd(fd, response.request.seq);
}
response.request.callback.clear();
result = POLL_CALLBACK;
}
}
return result;
}
正直に言えば、native層のコードは乱れています。この関数の機能は多いです。
上記の図に示すように、native PollOnceでは、epollで傍受してデータが到来したかどうか、その後、native message、native resonseを処理する。
最後に、どのようにnative層にrequestを入れるかを見ます。
3モニタ要求の追加
native層の増加requestはlooperのインターフェースaddFdに依存する:
//fd
//ident
//events , EVENT_INPUT、EVENT_OUTPUT、EVENT_ERROR EVENT_HANGUP
//callback
//data
int Looper::addFd(int fd, int ident, int events, Looper_callbackFunc callback, void* data) {
return addFd(fd, ident, events, callback ? new SimpleLooperCallback(callback) : NULL, data);
}
上記のnative層ポーリングキューの動作に関連して、addFdの目的は、native層のlooperに、新しく加入したfd上で指定されたイベントが発生しているかどうかを監視させることである。指定されたイベントが発生したら、コールバック関数とパラメータ構造で対応するレスポンスを利用します。
native層のlooperがレスポンスを処理すると、対応するコールバック関数が実行されます。
実際のコードを見てください。
int Looper::addFd(int fd, int ident, int events, const sp<LooperCallback>& callback, void* data) {
........
{
AutoMutex _l(mLock);
// request
Request request;
request.fd = fd;
request.ident = ident;
request.events = events;
request.seq = mNextRequestSeq++;
request.callback = callback;
request.data = data;
if (mNextRequestSeq == -1) mNextRequestSeq = 0; // reserve sequence number -1
struct epoll_event eventItem;
request.initEventItem(&eventItem);
// fd Request
ssize_t requestIndex = mRequests.indexOfKey(fd);
if (requestIndex < 0) {
//mEpollFd fd
int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, fd, & eventItem);
.......
mRequests.add(fd, request);
} else {
//mEpollFd fd
int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_MOD, fd, & eventItem);
if (epollResult < 0) {
if (errno == ENOENT) {
// Tolerate ENOENT because it means that an older file descriptor was
// closed before its callback was unregistered and meanwhile a new
// file descriptor with the same number has been created and is now
// being registered for the first time.
epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, fd, & eventItem);
.......
}
// , EpollRebuildLocked, epollFd fd
scheduleEpollRebuildLocked();
}
mRequests.replaceValueAt(requestIndex, request);
}
}
}
監視要求を追加する処理については、pollInner関数を上記で紹介したときに分析しましたが、ここでは説明を省略します。三、まとめ
1、流れのまとめ
Message Queの全体の流れはJavaの部分とNativeの部分を含んでいます。Native層の比重はやはり大きいことが図から分かります。上の図に合わせて、Message Que全体の対応する処理フローを思い出します。
1、Java層がLooperオブジェクトを作成すると、Java層のメッセンジャーQueが作成されます。Java層のメッセンジャーQueを初期化すると、Native関数を利用してNative層のメッセンジャーQueを作成します。
2、Native層のメッセンジャーQueを初期化すると、対応するNative Looperオブジェクトを作成します。Nativeオブジェクトを初期化すると、対応するepollFdとWakeEventFdが作成されます。ここで、epollFdは、epollの傍受ピリオドとして、初期の時はepollFdはWakeEventFdのみを傍受します。
3、図中の赤い線がLooperでMessage Queからメッセージを取る時、処理ロジックの流れです。
3.1、Java層のLooperがサイクルを開始する時、まずJNI関数でNative Looperを呼び出してpollOnceの操作を行う必要があります。
3.2、Native Looperが運転を開始したら、epollFdが呼び覚まされるのを待つ必要があります。epollFdがタイムアウトを待っている時や傍受しているハンドルにイベントが来ると、Native Looperはイベントの処理を開始できます。
3.3、Native層では、Native LooperはNative Message Queのメッセージを先に処理し、Resonse対応のコールバック関数を呼び出します。
3.4、今回のサイクルでNative層イベントが処理された後、Java層におけるMessage Queのメッセージの処理を開始します。メッセージがない場合は、MessageQueに処理が必要です。また、Message QueにIdlerが存在する場合は、IdleHandler定義の処理関数を呼び出します。
図中の青の部分は対応する関数の呼び出しです。
Java層:
Message QueのaddIIdleHandlerを利用して、Message QueのためにIdlerを追加することができます。
メッセンジャーQueのenqueue Messageを利用して、メッセンジャーQueにメッセージを追加することができます。必要に応じてNative関数を利用して、epollFdを起動するためにNative層のWakeEventFdにメッセージを書き込みます。
Native層:
looper:sendMessageを利用してNative Message Queにメッセージを追加できます。同じように、必要な時は、epollFdを起動するためにNative層のWakeEventFdにメッセージを書き込みます。
looper:addFdを利用してNative Looperに傍受要求を登録することができ、傍受要求は傍受したいfd、傍受したいイベントおよび対応するコールバック関数などを含み、傍受要求に対応するfdはepollFd傍受の対象となります。傍受されたfdに対応するイベントが発生すると、epollFdが起動され、その際に対応するレスポンスが加わったレスポンスListが生成され、処理が待つ。レスポンスが処理されると、対応するコールバック関数が呼び出されます。
2、注意事項
メッセンジャーQueは、Java層とNative層にそれぞれ格納構造があり、それぞれメッセージを追加することができる。処理ロジックでは、native層のMessageを優先的に処理し、Native層で生成されたレスポンスを処理し、最後にJava層のメッセンジャーを処理する。
以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。