聊一聊Android的消息机制 侯 亮 1概述在Android平台上,主要用到两种通信机制,即Binder机制和消息机制,前者用于跨进程通信,后者用于进程内部通信。 从技术实现上来说,消息机制还是比较简单的。从大的方面讲,不光是Android平台,各种平台的消息机制的原理基本上都是相近的,其中用到的主要概念大概有: 1)消息发送者; 图中表达的基本意思是,消息发送者通过某种方式,将消息发送到某个消息队列里,同时还有一个消息处理循环,不断从消息队列里摘取消息,并进一步解析处理。 在Android平台上,把上图的右边部分包装成了一个Looper类,(looper 英文意思:打环的人)这个类的内部具有对应的消息队列(MessageQueue mQueue)和loop函数。 Android平台上另一个关键类是Handler。(handler 处理者管理者)当消息循环在其寄身的线程里正式运作后,外界就是通过Handler向消息循环发出事件的。我们再画一张示意图如下:
整个消息机制的轮廓也就是这些啦,下面我们来详细阐述。 2先说一下Looper部分 Looper类的定义截选如下:
当一个线程运行到某处,准备运作一个Looper时,它必须先调用Looper类的静态函数prepare(),做一些准备工作。说穿了就是创建一个Looper对象,并把它设置进线程的本地存储区(TLS)里。然后线程才能继续调用Looper类的另一个静态函数loop(),从而建立起消息处理循环。示意图如下: prepare()函数的代码如下: 为了便于大家理解,我们多说两句关于sThreadLocal的细节,这会牵扯一点儿本地存储的技术。简单地说,每个线程对象内部会记录一张逻辑上的key-value表,当然,这张表在具体实现时不一定会被实现成HashMap,以我们目前的代码来说,它被记录成一个数组,其中每两个数组项作为一个key-value单元。反正大家从逻辑上理解概念即可,不必拘泥于具体实现。很明显,一个线程内部是可以记录多个本地存储单元的,我们关心的sThreadLocal只是其中一个本地存储单元的key而已。 当我们在不同Thread里调用Looper.prepare()时,其实是向Thread对应的那张表里添加一个key-value项,其中的key部分,指向的是同一个对象,即Looper.sThreadLocal静态对象,而value部分,则彼此不同,我们可以画出如下示意图: 看到了吧,不同Thread会对应不同Object[]数组,该数组以每2个元素为一个key-value对。请注意不同Thread虽然使用同一个静态对象作为key值,最终却会对应不同的Looper对象,这一点系统是不会弄错的。 为了由浅入深地阐述问题,我们暂时先不看Looper.loop()内部的代码,这个后文还会再讲。现在我们接着说说Handler。 3接着说一下Handler部分一般而言,运作Looper的线程会负责构造自己的Handler对象,当然,其他线程也可以针对某个Looper构造Handler对象。 Handler对象在构造时,不但会把Looper对象记录在它内部的mLooper成员变量中,还会把Looper对象的消息队列也一并记录,代码截选如下: 我们也可以直接传入Looper对象,此时可以使用另一个构造函数: 简单说来,只要一个线程可以获取另一个目标线程的某个Handler对象,它就具有了向目标线程发送消息的能力。不过,也只是发送消息而已,消息的真正处理却是在目标线程的消息循环里完成的。 前文已经说过,在Looper准备停当后,我们的线程会调用Looper.loop(),从而进入真正的循环机制。loop()函数的代码流程非常简单,只不过是在一个for循环里不停从消息队列中摘取消息,而后调用msg.target.dispatchMessage()对消息进行派发处理而已。 这么看来,msg.target域就显得比较重要了,说穿了,这个域记录的其实就是当初向消息队列发送消息的那个handler啦。当我们调用handler的send函数时,最终基本上都会走到sendMessageAtTime(),其代码如下:
请大家注意msg.target = this;一句,记录的就是handler对象。 当Looper的消息循环最终调用到msg.target.dispatchMessage()时,会间接调用到handler的handleMessage()函数,从而对消息进行实际处理。 在实际运用handler时,大体有两种方式。一种方式是写一个继承于Handler的新类,并在新类里实现自己的handleMessage()成员函数;另一种方式是在创建匿名Handler对象时,直接修改handleMessage()成员函数。 4消息队列MessageQueue 在刚刚介绍Handler的sendMessageAtTime()时,我们已经看到最终会调用queue.enqueueMessage()来向消息队列打入消息。queue对应的类是MessageQueue,其定义截选如下:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 | boolean enqueueMessage(Message msg, long when) { . . . . . . . . . . . . msg.when = when; Message p = mMessages; boolean needWake; if (p == null || when == 0 || when < p.when) { // 此时,新消息会插入到链表的表头,这意味着队列需要调整唤醒时间啦。 msg.next = p; mMessages = msg; needWake = mBlocked; } else { // 此时,新消息会插入到链表的内部,一般情况下,这不需要调整唤醒时间。 // 但还必须考虑到当表头为“同步分割栏”的情况 needWake = mBlocked && p.target == null && msg.isAsynchronous(); Message prev; for (;;) { prev = p; p = p.next; if (p == null || when < p.when) { break ; } if (needWake && p.isAsynchronous()) { // 说明即便msg是异步的,也不是链表中第一个异步消息,所以没必要唤醒了 needWake = false ; } } msg.next = p; prev.next = msg; } if (needWake) { nativeWake(mPtr); } . . . . . . } |
上面的代码中还有一个“同步分割栏”的概念需要提一下。所谓“同步分割栏”,可以被理解为一个特殊Message,它的target域为null。它不能通过sendMessageAtTime()等函数打入到消息队列里,而只能通过调用Looper的postSyncBarrier()来打入。
“同步分割栏”是起什么作用的呢?它就像一个卡子,卡在消息链表中的某个位置,当消息循环不断从消息链表中摘取消息并进行处理时,一旦遇到这种“同步分割栏”,那么即使在分割栏之后还有若干已经到时的普通Message,也不会摘取这些消息了。请注意,此时只是不会摘取“普通Message”了,如果队列中还设置有“异步Message”,那么还是会摘取已到时的“异步Message”的。
在Android的消息机制里,“普通Message”和“异步Message”也就是这点儿区别啦,也就是说,如果消息列表中根本没有设置“同步分割栏”的话,那么“普通Message”和“异步Message”的处理就没什么大的不同了。
打入“同步分割栏”的postSyncBarrier()函数的代码如下:
【frameworks/base/core/java/android/os/Looper.java】
【frameworks/base/core/java/android/os/MessageQueue.java】
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | int enqueueSyncBarrier( long when) { synchronized ( this ) { final int token = mNextBarrierToken++; final Message msg = Message.obtain(); msg.when = when; msg.arg1 = token; Message prev = null ; Message p = mMessages; if (when != 0 ) { while (p != null && p.when <= when) { prev = p; p = p.next; } } if (prev != null ) { msg.next = p; prev.next = msg; } else { msg.next = p; mMessages = msg; } return token; } } |
要得到“异步Message”,只需调用一下Message的setAsynchronous()即可:
【frameworks/base/core/java/android/os/Message.java】
一般,我们是通过“异步Handler”向消息队列打入“异步Message”的。异步Handler的mAsynchronous域为true,因此它在调用enqueueMessage()时,可以走入:
现在我们画一张关于“同步分割栏”的示意图:
图中的消息队列中有一个“同步分割栏”,因此它后面的“2”号Message即使到时了,也不会摘取下来。而“3”号Message因为是个异步Message,所以当它到时后,是可以进行处理的。
“同步分割栏”这种卡子会一直卡在消息队列中,除非我们调用removeSyncBarrier()删除这个卡子。
【frameworks/base/core/java/android/os/Looper.java】
【frameworks/base/core/java/android/os/MessageQueue.java】
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | void removeSyncBarrier( int token) { // Remove a sync barrier token from the queue. // If the queue is no longer stalled by a barrier then wake it. synchronized ( this ) { Message prev = null ; Message p = mMessages; while (p != null && (p.target != null || p.arg1 != token)) { prev = p; p = p.next; } if (p == null ) { throw new IllegalStateException( "The specified message queue synchronization " + " barrier token has not been posted or has already been removed." ); } final boolean needWake; if (prev != null ) { prev.next = p.next; needWake = false ; } else { mMessages = p.next; needWake = mMessages == null || mMessages.target != null ; } p.recycle(); // If the loop is quitting then it is already awake. // We can assume mPtr != 0 when mQuitting is false. if (needWake && !mQuitting) { nativeWake(mPtr); } } } |
nativeWake()对应的C++层函数如下:
【frameworks/base/core/jni/android_os_MessageQueue.cpp】
【system/core/libutils/Looper.cpp】
接下来我们来看看消息循环。我们从Looper的Loop()函数开始讲起。下面是loop()函数的简略代码,我们只保留了其中最关键的部分:
【frameworks/base/core/java/android/os/Looper.java】
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | public static void loop() { final Looper me = myLooper(); . . . . . . final MessageQueue queue = me.mQueue; Binder.clearCallingIdentity(); final long ident = Binder.clearCallingIdentity(); for (;;) { Message msg = queue.next(); // might block . . . . . . msg.target.dispatchMessage(msg); // 派发消息 . . . . . . final long newIdent = Binder.clearCallingIdentity(); . . . . . . msg.recycle(); } } |
对于Looper而言,它主要关心的是从消息队列里摘取消息,而后分派消息。然而对消息队列而言,在摘取消息时还要考虑更多技术细节。它关心的细节有:
1)如果消息队列里目前没有合适的消息可以摘取,那么不能让它所属的线程“傻转”,而应该使之阻塞;
2)队列里的消息应该按其“到时”的顺序进行排列,最先到时的消息会放在队头,也就是mMessages域所指向的消息,其后的消息依次排开;
3)阻塞的时间最好能精确一点儿,所以如果暂时没有合适的消息节点可摘时,要考虑链表首个消息节点将在什么时候到时,所以这个消息节点距离当前时刻的时间差,就是我们要阻塞的时长。
4)有时候外界希望队列能在即将进入阻塞状态之前做一些动作,这些动作可以称为idle动作,我们需要兼顾处理这些idle动作。一个典型的例子是外界希望队列在进入阻塞之前做一次垃圾收集。
以上所述的细节,基本上都体现在MessageQueue的next()函数里了,现在我们就来看这个函数的主要流程。
MessageQueue的next()函数的代码截选如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 | Message next() { int pendingIdleHandlerCount = - 1 ; // -1 only during first iteration int nextPollTimeoutMillis = 0 ; for (;;) { . . . . . . nativePollOnce(mPtr, nextPollTimeoutMillis); // 阻塞于此 . . . . . . // 获取next消息,如能得到就返回之。 final long now = SystemClock.uptimeMillis(); Message prevMsg = null ; Message msg = mMessages; // 先尝试拿消息队列里当前第一个消息 if (msg != null && msg.target == null ) { // 如果从队列里拿到的msg是个“同步分割栏”,那么就寻找其后第一个“异步消息” 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 ; if (prevMsg != null ) { prevMsg.next = msg.next; } else { mMessages = msg.next; // 重新设置一下消息队列的头部 } msg.next = null ; if ( false ) Log.v( "MessageQueue" , "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 ; } if (pendingIdleHandlerCount < 0 && (mMessages == null || now < mMessages.when)) { pendingIdleHandlerCount = mIdleHandlers.size(); } if (pendingIdleHandlerCount <= 0 ) { // No idle handlers to run. Loop and wait some more. mBlocked = true ; continue ; } . . . . . . // 处理idle handlers部分 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 { keep = idler.queueIdle(); } catch (Throwable t) { Log.wtf( "MessageQueue" , "IdleHandler threw exception" , t); } if (!keep) { synchronized ( this ) { mIdleHandlers.remove(idler); } } } pendingIdleHandlerCount = 0 ; nextPollTimeoutMillis = 0 ; } } |
上面代码中也处理了“同步分割栏”的情况。如果从队列里获取的消息是个“同步分割栏”的话,可千万不能把“同步分割栏”给返回了,此时会尝试找寻其后第一个“异步消息”。
next()里另一个要说的是那些Idle Handler,当消息队列中没有消息需要马上处理时,会判断用户是否设置了Idle Handler,如果有的话,则会尝试处理mIdleHandlers中所记录的所有Idle Handler,此时会逐个调用这些Idle Handler的queueIdle()成员函数。我们举一个例子,在ActivityThread中,在某种情况下会在消息队列中设置GcIdler,进行垃圾收集,其定义如下:
前文我们已经说过,next()中调用的nativePollOnce()起到了阻塞作用,保证消息循环不会在无消息处理时一直在那里“傻转”。那么,nativePollOnce()函数究竟是如何实现阻塞功能的呢?我们来探索一下。首先,MessageQueue类里声明的几个native函数,对应的JNI实现位于android_os_MessageQueue.cpp文件中:
【frameworks/base/core/jni/android_os_MessageQueue.cpp】
1 2 3 4 5 6 7 8 | static JNINativeMethod gMessageQueueMethods[] = { /* name, signature, funcPtr */ { "nativeInit" , "()I" , ( void *)android_os_MessageQueue_nativeInit }, { "nativeDestroy" , "(I)V" , ( void *)android_os_MessageQueue_nativeDestroy }, { "nativePollOnce" , "(II)V" , ( void *)android_os_MessageQueue_nativePollOnce }, { "nativeWake" , "(I)V" , ( void *)android_os_MessageQueue_nativeWake }, { "nativeIsIdling" , "(I)Z" , ( void *)android_os_MessageQueue_nativeIsIdling } }; |
目前我们只关心nativePollOnce对应的android_os_MessageQueue_nativePollOnce()。其代码如下:
NativeMessageQueue的pollOnce()如下:
【frameworks/base/core/jni/android_os_MessageQueue.cpp】
这里会用到C++层的Looper类,它和Java层的Looper类可是不一样的哩。C++层的Looper类的定义截选如下:
【system/core/include/utils/Looper.h】
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | class Looper : public ALooper, public RefBase { protected : virtual ~Looper(); public : Looper( bool allowNonCallbacks); bool getAllowNonCallbacks() const ; int pollOnce( int timeoutMillis, int * outFd, int * outEvents, void ** outData); . . . . . . int pollAll( int timeoutMillis, int * outFd, int * outEvents, void ** outData); . . . . . . void wake(); int addFd( int fd, int ident, int events, ALooper_callbackFunc callback, void * data); int addFd( int fd, int ident, int events, const sp void * data); int removeFd( int fd); void sendMessage( const sp const Message& message); void sendMessageDelayed(nsecs_t uptimeDelay, const sp const Message& message); void sendMessageAtTime(nsecs_t uptime, const sp const Message& message); void removeMessages( const sp void removeMessages( const sp int what); bool isIdling() const ; static sp int opts); static void setForThread( const sp static sp . . . . . . . . . . . . }; |
C++层的Looper的构造函数如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | Looper::Looper( bool allowNonCallbacks) : mAllowNonCallbacks(allowNonCallbacks), mSendingMessage( false ), mResponseIndex(0), mNextMessageUptime(LLONG_MAX) { int wakeFds[2]; int result = pipe(wakeFds); // 创建一个管道 LOG_ALWAYS_FATAL_IF(result != 0, "Could not create wake pipe. errno=%d" , errno ); mWakeReadPipeFd = wakeFds[0]; // 管道的“读取端” mWakeWritePipeFd = wakeFds[1]; // 管道的“写入端” result = fcntl(mWakeReadPipeFd, F_SETFL, O_NONBLOCK); LOG_ALWAYS_FATAL_IF(result != 0, "Could not make wake read pipe non-blocking. errno=%d" , errno ); result = fcntl(mWakeWritePipeFd, F_SETFL, O_NONBLOCK); LOG_ALWAYS_FATAL_IF(result != 0, "Could not make wake write pipe non-blocking. errno=%d" , errno ); mIdling = false ; // 创建一个epoll mEpollFd = epoll_create(EPOLL_SIZE_HINT); LOG_ALWAYS_FATAL_IF(mEpollFd < 0, "Could not create epoll instance. errno=%d" , errno ); struct epoll_event eventItem; memset (& eventItem, 0, sizeof (epoll_event)); eventItem.events = EPOLLIN; eventItem.data.fd = mWakeReadPipeFd; // 监听管道的read端 result = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, mWakeReadPipeFd, & eventItem); LOG_ALWAYS_FATAL_IF(result != 0, "Could not add wake read pipe to epoll instance. errno=%d" , errno ); } |
可以看到在构造Looper对象时,其内部除了创建了一个管道以外,还创建了一个epoll来监听管道的“读取端”。也就是说,是利用epoll机制来完成阻塞动作的。每当我们向消息队列发送事件时,最终会间接向管道的“写入端”写入数据,这个前文已有叙述,于是epoll通过管道的“读取端”立即就感知到了风吹草动,epoll_wait()在等到事件后,随即进行相应的事件处理。这就是消息循环阻塞并处理的大体流程。当然,因为向管道写数据只是为了通知风吹草动,所以写入的数据是非常简单的“W”字符串。现在大家不妨再看看前文阐述“nativeWake()”的小节,应该能明白了吧。
我们还是继续说消息循环。Looper的pollOnce()函数如下:
【system/core/libutils/Looper.cpp】
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | int Looper::pollOnce( int timeoutMillis, int * outFd, int * outEvents, void ** outData) { int result = 0; for (;;) { . . . . . . if (result != 0) { . . . . . . if (outFd != NULL) *outFd = 0; if (outEvents != NULL) *outEvents = 0; if (outData != NULL) *outData = NULL; return result; } result = pollInner(timeoutMillis); } } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 | int Looper::pollInner( int timeoutMillis) { . . . . . . // 阻塞、等待 int eventCount = epoll_wait( mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis); . . . . . . . . . . . . // 处理所有epoll事件 for ( int i = 0; i < eventCount; i++) { int fd = eventItems[i].data.fd; uint32_t epollEvents = eventItems[i].events; if (fd == mWakeReadPipeFd) { if (epollEvents & EPOLLIN) { awoken(); // 从管道中感知到EPOLLIN,于是调用awoken() } . . . . . . } else { // 如果是除管道以外的其他fd发生了变动,那么根据其对应的request, // 将response先记录进mResponses ssize_t requestIndex = mRequests.indexOfKey(fd); if (requestIndex >= 0) { int events = 0; if (epollEvents & EPOLLIN ) events |= ALOOPER_EVENT_INPUT; if (epollEvents & EPOLLOUT) events |= ALOOPER_EVENT_OUTPUT; if (epollEvents & EPOLLERR) events |= ALOOPER_EVENT_ERROR; if (epollEvents & EPOLLHUP) events |= ALOOPER_EVENT_HANGUP; // 内部会调用 mResponses.push(response); pushResponse(events, mRequests.valueAt(requestIndex)); } . . . . . . } } Done: ; . . . . . . // 调用尚未处理的事件的回调 while (mMessageEnvelopes.size() != 0) { nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC); const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0); if (messageEnvelope.uptime <= now) { { sp Message message = messageEnvelope.message; mMessageEnvelopes.removeAt(0); . . . . . . handler->handleMessage(message); } . . . . . . } else { mNextMessageUptime = messageEnvelope.uptime; break ; } } . . . . . . // 调用所有response记录的回调 for ( size_t i = 0; i < mResponses.size(); i++) { Response& response = mResponses.editItemAt(i); if (response.request.ident == ALOOPER_POLL_CALLBACK) { . . . . . . int callbackResult = response.request.callback->handleEvent(fd, events, data); if (callbackResult == 0) { removeFd(fd); } . . . . . . } } return result; } |
现在我们可以画一张调用示意图,理一下loop()函数的调用关系,如下:
pollInner()调用epoll_wait()时传入的timeoutMillis参数,其实来自于前文所说的MessageQueue的next()函数里的nextPollTimeoutMillis,next()函数里在以下3种情况下,会给nextPollTimeoutMillis赋不同的值:
1)如果消息队列中的下一条消息还要等一段时间才到时的话,那么nextPollTimeoutMillis赋值为Math.min(msg.when - now, Integer.MAX_VALUE),即时间差;
2)如果消息队列已经是空队列了,那么nextPollTimeoutMillis赋值为-1;
3)不管前两种情况下是否已给nextPollTimeoutMillis赋过值了,只要队列中有Idle Handler需要处理,那么在处理完所有Idle Handler之后,会强制将nextPollTimeoutMillis赋值为0。这主要是考虑到在处理Idle Handler时,不知道会耗时多少,而在此期间消息队列的“到时情况”有可能已发生改变。
不管epoll_wait()的超时阀值被设置成什么,只要程序从epoll_wait()中返回,就会尝试处理等到的epoll事件。目前我们的主要关心点是事件机制,所以主要讨论当fd 等于mWakeReadPipeFd时的情况,此时会调用一下awoken()函数。该函数很简单,只是在读取mWakeReadPipeFd而已:
除了感知mWakeReadPipeFd管道的情况以外,epoll还会感知其他一些fd对应的事件。在Looper中有一个mRequests键值向量表(KeyedVector
pollInner()内部还会集中处理所记录的所有C++层的Message。在一个while循环中,不断摘取mMessageEnvelopes向量表的第0个MessageEnvelope,如果消息已经到时,则回调handleMessage()。
C++层的Looper及这个层次的消息链表,再加上对应其他fd的Request和Response,可以形成下面这张示意图:
从我们的分析中可以知道,在Android中,不光是Java层可以发送Message,C++层也可以发送,当然,不同层次的Message是放在不同层次的消息链中的。在Java层,每次尝试从队列中获取一个Message,而后dispatch它。而C++层的消息则尽量在一次pollOnce中集中处理完毕,这是它们的一点不同。
关于Android的消息机制,我们就先说这么多。总体上的而言还是比较简单的,无非是通过Handler向Looper的消息队列中插入Message,而后再由Looper在消息循环里具体处理。因为消息队列本身不具有链表一变动就能马上感知的功能,所以它需要借助管道和epoll机制来监听变动。当外界向消息队列中打入新消息后,就向管道的“写入端”写入简单数据,于是epoll可以立即感知到管道的变动,从何激发从消息队列中摘取消息的动作。这就是Android消息机制的大体情况。
|
来自: jnstyle > 《android高阶》