我們知道Java層 有Handler、Looper、MessageQueue的 鐵三角模型,Android的消息循環真的就只有這些么?
Android 2.2 之前確實只有Java 層的MessageQueue,但是Android 2.2之后,MessageQueue的核心功能下移到了Native層,導致現在的MessageQueue除了支持Java層的Message派發外,還新增了支持Native Message派發,以及處理來自所監控的文件句柄的事件。
Java 層的MessageQueue創建時,在Native層會創建一個NativeMessageQueue對象,
NativeMessageQueue 持有一個Looper(C++)。
一、sendMessage發送消息
Native層 通過Looper 來發送消息
Native MessageQueue 通過Looper 來發送Message
1.1、Native層 Looper持有一個mMessageEnvelopes 來存儲待處理的Message
mMessageEnvelopes中的MessageEnvelope也是按照觸發時間,從小到大排序的,排在前面的優先處理。
Vector<MessageEnvelope> mMessageEnvelopes; // guarded by mLock
1.2、Looper發送消息,最終會進入sendMessageAtTime()
Native sendMessageAtTime()方法做的事情和Java層很相似:
- 將新Message 添加到消息隊列(mMessageEnvelopes)的合適的位置。
- 新Message插入 隊首時,需要立即喚醒隊列wake()
void Looper::sendMessageAtTime(nsecs_t uptime, const sp<MessageHandler>& handler,
const Message& message) {
size_t i = 0;
{ // acquire lock
AutoMutex _l(mLock);
size_t messageCount = mMessageEnvelopes.size();
while (i < messageCount && uptime >= mMessageEnvelopes.itemAt(i).uptime) {
i += 1;
}
MessageEnvelope messageEnvelope(uptime, handler, message);
mMessageEnvelopes.insertAt(messageEnvelope, i, 1);
if (mSendingMessage) {
return;
}
} // release lock
// Wake the poll loop only when we enqueue a new message at the head.
if (i == 0) {
wake();
}
}
由上面可知
Java層和Natvie的MessageQueue,有各自維護的獨立的消息隊列,可以互不干擾的向消息隊列中插入Message.
二、MessageQueue處理消息
在Android的MessqgeQueue模型中,Java和Native層 sendMessage是各自獨立的,消費隊里中的消息卻是綁定在一起的。
2.1、MessageQueue.nativePollOnce()
Java層消息循環中,調用MessageQueue.next(),獲取下一條待處理的消息。
next()方法中會調用nativePollOnce()方法。
對于Java層nativePollOnce() 會阻塞當前線程
- 當隊列沒有消息時 會阻塞
- 當隊列頭部消息 未到達觸發時間(msg.when > now),阻塞一個固定的時間,超時后返回。
對于Natvie層nativePollOnce()的調用 是Native層消息被處理的唯一時機。
int Looper::pollInner(int timeoutMillis) {
struct epoll_event eventItems[EPOLL_MAX_EVENTS];
//(1)epoll_wait()返回,阻塞結束
int eventCount = epoll_wait(mEpollFd.get(), eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
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++) {
int fd = eventItems[i].data.fd;
uint32_t epollEvents = eventItems[i].events;
if (fd == mWakeEventFd.get()) {
if (epollEvents & EPOLLIN) {
awoken();
} else {
ALOGW("Ignoring unexpected epoll events 0x%x on wake event fd.", epollEvents);
}
} else {
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;
pushResponse(events, mRequests.valueAt(requestIndex));
} else {
ALOGW("Ignoring unexpected epoll events 0x%x on fd %d that is "
"no longer registered.", epollEvents, fd);
}
}
}
Done: ;
// (2) 處理Native層的消息
mNextMessageUptime = LLONG_MAX;
while (mMessageEnvelopes.size() != 0) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
if (messageEnvelope.uptime <= now) {
.
{ // obtain handler
sp<MessageHandler> handler = messageEnvelope.handler;
Message message = messageEnvelope.message;
mMessageEnvelopes.removeAt(0);
mSendingMessage = true;
mLock.unlock();
handler->handleMessage(message);
} // release handler
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();
// Invoke all response callbacks.
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.request.callback.clear();
result = POLL_CALLBACK;
}
}
return result;
}
- (1)epoll_wait()返回,表示阻塞結束
- (2) Done: 代碼塊 遍歷消息隊列,處理到期的message
nativePollOnce() 阻塞時長
阻塞時長 最終取決于epoll_wait 傳入的超時時間
int eventCount = epoll_wait(mEpollFd.get(), eventItems, EPOLL_MAX_EVENTS, timeoutMillis);
計算過程如下:
int Looper::pollInner(int timeoutMillis) {
if (timeoutMillis != 0 && mNextMessageUptime != LLONG_MAX) {
nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
//messageTimeoutMillis 表示Native層下一條消息的到期時間
int messageTimeoutMillis = toMillisecondTimeoutDelay(now, mNextMessageUptime);
if (messageTimeoutMillis >= 0
&& (timeoutMillis < 0 || messageTimeoutMillis < timeoutMillis)) {
timeoutMillis = messageTimeoutMillis;
}
}
- Java層消息隊列未空時,nativePollOnce(-1),timeoutMillis 取決于Native消息隊里最新一條消息的到期時間
- Java層 nativePollOnce(0) 時,timeoutMillis = 0,不阻塞
- Java層 傳遞timeoutMillis為最新一條Message的超時時間時,最終的超時時間timeoutMillis 取Java和Native層最新消息到期執行時間的最小值。
epoll_wait的喚醒
epoll_wait的喚醒分為下面幾種情況:
- epoll_wait 超時返回
- epoll_wait 出錯
- Java層sendMessage調用natvieWake()
- Native層sendMessage 調用wake()
- 其他監聽的Fd事件
三、Android MessageQueue模型小結
- Java層和Native層MessageQueue有各自的消息隊列,sendMessage是彼此獨立的。
- Java層和Native層MessageQueue處理消息是綁定在一起的,紐帶就是nativePollOnce()
- nativePollOnce()是Native層消息得以處理的唯一路徑
- natvie層的Mesage消息要先于Java層的Mesage被處理。Native層的消息處理完成之后,Java層的消息才會被處理。
四、Native MessageQueue 可以處理哪些消息呢?
Looper/Handler的模型主要是依靠不斷的喚醒epoll來實現的。主要的手段是喚醒 mWakeFd, 或者是epoll的timeout。
timeout手段主要是針對 sendMessageDelayed()這樣的函數。
epoll 的喚醒除了 mWakeFd的喚醒和epoll的timeout外,還支持監聽其它事件。主要是通過Looper::addFd來實現的。
int Looper::addFd(int fd, int ident, int events, Looper_callbackFunc callback, void* data) {
return addFd(fd, ident, events, callback ? new SimpleLooperCallback(callback) : nullptr, data);
}
int Looper::addFd(int fd, int ident, int events, const sp<LooperCallback>& callback, void* data) {
{ // acquire lock
AutoMutex _l(mLock);
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);
ssize_t requestIndex = mRequests.indexOfKey(fd);
if (requestIndex < 0) {
int epollResult = epoll_ctl(mEpollFd.get(), EPOLL_CTL_ADD, fd, &eventItem);
if (epollResult < 0) {
ALOGE("Error adding epoll events for fd %d: %s", fd, strerror(errno));
return -1;
}
mRequests.add(fd, request);
} else {
int epollResult = epoll_ctl(mEpollFd.get(), EPOLL_CTL_MOD, fd, &eventItem);
if (epollResult < 0) {
if (errno == ENOENT) {
epollResult = epoll_ctl(mEpollFd.get(), EPOLL_CTL_ADD, fd, &eventItem);
if (epollResult < 0) {
ALOGE("Error modifying or adding epoll events for fd %d: %s",
fd, strerror(errno));
return -1;
}
scheduleEpollRebuildLocked();
} else {
ALOGE("Error modifying epoll events for fd %d: %s", fd, strerror(errno));
return -1;
}
}
mRequests.replaceValueAt(requestIndex, request);
}
} // release lock
return 1;
}
從上面的代碼可以看出addFd就是創建一個Request,并添加到epoll監聽池中,并插入到mRequests中。
epoll_wait()函數等待消息,當接收到消息或者消息發生超時后調用返回。
對返回的events 進行遍歷,如果對應的fd為喚醒專用的mWakeEventId,執行awoken()函數清空管道,這個事件的作用只是為了喚醒Looper對新消息進行處理。
如果不是mWakeEventFd,說明為我們之前通過addFd()函數添加的自定義fd,我們需要對這個event進行處理,處理函數為pushResponse():
ssize_t requestIndex = mRequests.indexOfKey(fd);
pushResponse(events, mRequests.valueAt(requestIndex));
這里將request對象包裝成了一個response,然后存入了mResponses中等待后面的處理。
void Looper::pushResponse(int events, const Request& request) {
Response response;
response.events = events;
response.request = request;
mResponses.push(response);
}
然后是對response的處理操作,主要是如下調用
int callbackResult = response.request.callback->handleEvent(fd, events, data);
4.1、舉個栗子
Android的屏幕觸摸事件以及按鍵事件 就是通過Looper::addFd()的方法,經由Native的MessageQueue 進行事件分發的。
void NativeInputEventReceiver::setFdEvents(int events) {
if (mFdEvents != events) {
mFdEvents = events;
int fd = mInputConsumer.getChannel()->getFd();
if (events) {
mMessageQueue->getLooper()->addFd(fd, 0, events, this, nullptr);
} else {
mMessageQueue->getLooper()->removeFd(fd);
}
}
}
int fd = mInputConsumer.getChannel()->getFd() 是一個socket的fd文件描述符。
NativeInputEventReceiver 通過addFd,將自己作為監聽回調注冊到了Looper中。
status_t InputChannel::sendMessage(const InputMessage* msg) {
size_t msgLength = msg->size();
ssize_t nWrite;
do {
nWrite = ::send(mFd, msg, msgLength, MSG_DONTWAIT | MSG_NOSIGNAL);
} while (nWrite == -1 && errno == EINTR);
...
return OK;
}
當原始事件通過建立好的InputChannel的sendMessage()函數發送觸摸事件時,會直接調用send()函數向fd表示的socket中寫入數據,同時在另一邊的epoll_wait()調用就會因socket另一端fd數據的到來而喚醒,并通過fd找到注冊好的request,進而調用request中的NativeInputEventReceiver的handleEvent()方法,參數就是我們接收到的事件信息與數據。
4.2、彩蛋
BlockCanary 缺點分析一文中指出,MessageQueue.next()阻塞 導致的ANR,BlockCanary是捕捉不到的。
Message msg = queue.next(); // might block
用舉出實例,在Activity中重寫dispatchTouchEvent和dispatchKeyEvent,模擬耗時操作,彈出ANR告警,但BlockCanary沒有任何反應。
@Override
public boolean dispatchTouchEvent(MotionEvent event){
Log.d("feifei","dispatchTouchEvent A ");
try {
Thread.sleep(20000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.d("feifei","dispatchTouchEvent B ");
return super.dispatchTouchEvent(event);
}
我試驗了一次,BlockCanary缺失沒有捕獲ANR。
問題來了
為什么dispatchTouchEvent執行耗時操作,MessageQueue.next()就會被阻塞呢?
經過本文對Native層的MessageQueue的運行機制梳理,可以知道:
- 觸摸事件,是Native層的MessageQueue,通過NativeInputEventReceiver進行事件分發的。
- NativePollOnce()進入native層調用epoll_wait()阻塞線程,阻塞解除后,會先對Native層的消息進行分發處理,處理完成之后,才會返回Java層。
綜合上面兩點:dispatchTouchEvent中執行耗時操作,會直接導致Native層分發消息耗時,進而導致Java層MessageQueue.next()長時間阻塞,觸發ANR。
五、參考文章
http://www.lxweimin.com/p/48cf21ad637b