PDF版的可以从以下网址下载：
http://download.csdn.net/source/3578482
第5章 深入理解常见类 本章涉及的源代码文件名称及位置 下面是本章分析的源码文件名和它的位置。 RefBase.h(framework/base/include/utils/RefBase.h) RefBase.cpp(framework/base/libs/utils/RefBase.cpp) Thread.cpp(framework/base/libs/utils/Thread.cpp) Thread.h(framework/base/include/utils/Thread.h) Atomic.h(system/core/include/cutils/Atomic.h) AndroidRuntime.cpp(framework/base/core/jni/AndroidRuntime.cpp) Looper.java(framework/base/core/Java/Android/os/Looper.java) Handler.java(framework/base/core/Java/Android/os/ Handler.java) HandlerThread.java(framework/base/core/Java/Android/os/ HandlerThread.java) 5.1 概述 初次接触Android源码时，见到最多的一定是sp和wp。即使你只是沉迷于Java世界的编码，那么Looper和Handler也是避不开的。本章的目的，就是把经常碰到的这些内容中的“拦路虎”一网打尽，将它们彻底搞懂。至于弄明白它们有什么好处，就仁者见仁，智者见智了。个人觉得Looper和Handler相对会更实用一些。 5.2 以“三板斧”揭秘RefBase、sp和wp RefBase是Android中所有对象的始祖，类似于MFC中的CObject及Java中的Object对象。在Android中，RefBase结合sp和wp，实现了一套通过引用计数的方法来控制对象生命周期的机制。就如我们想像的那样，这三者的关系非常暧昧。初次接触Android源码的人往往会被那个随处可见的sp和wp搞晕了头。 什么是sp和wp呢？其实，sp并不是我开始所想的smart pointer（C++语言中有这个东西），它真实的意思应该是strong pointer，而wp则是weak pointer的意思。我认为，Android推出这一套机制可能是模仿Java，因为Java世界中有所谓weak reference之类的东西。sp和wp的目的，就是为了帮助健忘的程序员回收new出来的内存。 说明 我还是喜欢赤裸裸地管理内存的分配和释放。不过，目前sp和wp的使用已经深入到Android系统的各个角落，想把它去掉真是不太可能了。 这三者的关系比较复杂，都说程咬金的“三板斧”很厉害，那么我们就借用这三板斧，揭密其间的暧昧关系。 5.2.1 第一板斧—初识影子对象 我们的“三板斧”，其实就是三个例子。相信这三板斧劈下去，你会很容易理解它们。 [-->例子1] //类A从RefBase派生,RefBase是万物的始祖。 class A：public RefBase { //A没有任何自己的功能。 } int main() { A* pA = new A; { //注意我们的sp、wp对象是在{}中创建的，下面的代码先创建sp，然后创建wp。 sp spA(pA); wp wpA(spA); //大括号结束前，先析构wp，再析构sp。 } } 例子够简单吧？但也需一步一步分析这斧子是怎么劈下去的。 1. RefBase和它的影子 类A从RefBase中派生。使用的是RefBase构造函数。代码如下所示： [-->RefBase.cpp] RefBase::RefBase() : mRefs(new weakref_impl(this))//注意这句话 { //mRefs是RefBase的成员变量，类型是weakref_impl，我们暂且叫它影子对象。 //所以A有一个影子对象。 } mRefs是引用计数管理的关键类，需要进一步观察。它是从RefBase的内部类weakref_type中派生出来的。 先看看它的声明： class RefBase::weakref_impl : public RefBase::weakref_type //从RefBase的内部类weakref_type派生。 由于Android频繁使用C++内部类的方法，所以初次阅读Android代码时可能会有点不太习惯，C++的内部类和Java的内部类相似，但有一点不同，即它需要一个显式的成员指向外部类对象，而Java的内部类对象有一个隐式的成员指向外部类对象的。 说明 内部类在C++中的学名叫nested class（内嵌类）。 [-->RefBase.cpp::weakref_imple构造] weakref_impl(RefBase* base) : mStrong(INITIAL_STRONG_VALUE) //强引用计数，初始值为0x1000000。 , mWeak(0) //弱引用计数，初始值为0。 , mBase(base)//该影子对象所指向的实际对象。 , mFlags(0) , mStrongRefs(NULL) , mWeakRefs(NULL) , mTrackEnabled(!!DEBUG_REFS_ENABLED_BY_DEFAULT) , mRetain(false) { } 如你所见，new了一个A对象后，其实还new了一个weakref_impl对象，这里称它为影子对象，另外我们称A为实际对象。 这里有一个问题：影子对象有什么用？ 可以仔细想一下，是不是发现影子对象成员中有两个引用计数？一个强引用，一个弱引用。如果知道引用计数和对象生死有些许关联的话，就容易想到影子对象的作用了。 说明 按上面的分析来看，在构造一个实际对象的同时，还会悄悄地构造一个影子对象，在嵌入式设备的内存不是很紧俏的今天，这个影子对象的内存占用已经不成问题了。 2.sp上场 程序继续运行，现在到了： sp spA(pA); 请看sp的构造函数，它的代码如下所示（注意，sp是一个模板类，对此不熟悉的读者可以去翻翻书，或者干脆把所有出现的T都换成A）： [-->RefBase.h::sp(T* other)] template
//操作影子对象，先增加弱引用计数。 refs->addWeakRef(id); refs->incWeak(id); ...... 先来看看影子对象的这两个weak函数都干了些什么。 （1）眼见而心不烦 下面看看第一个函数addWeakRef，代码如下所示： [-->RefBase.cpp] void addWeakRef(const void* /*id*/) { } 呵呵，addWeakRef啥都没做，因为这是release版走的分支。调试版的代码我们就不讨论了，它是给创造RefBase、 sp，以及wp的人调试用的。 说明 调试版分支的代码很多，看来创造它们的人也在为不理解它们之间的暧昧关系痛苦不已。 总之，一共有这么几个不用考虑的函数，下面都已列出来了。以后再碰见它们，干脆就直接跳过去： void addStrongRef(const void* /*id*/) { } void removeStrongRef(const void* /*id*/) { } void addWeakRef(const void* /*id*/) { } void removeWeakRef(const void* /*id*/) { } void printRefs() const { } void trackMe(bool, bool) { } 继续我们的征程。再看incWeak函数，代码如下所示： [-->RefBase.cpp] void RefBase::weakref_type::incWeak(const void* id) { weakref_impl* const impl = static_cast
//原子减1，返回旧值，c=2，而弱引用计数从2变为1。 const int32_t c = android_atomic_dec(&impl->mWeak); if (c != 1) return; //c=2，直接返回。 //如果c为1，则弱引用计数为0，这说明没用弱引用指向实际对象，需要考虑是否释放内存。 // OBJECT_LIFETIME_XXX和生命周期有关系，我们后面再说。 if ((impl->mFlags&OBJECT_LIFETIME_WEAK) != OBJECT_LIFETIME_WEAK) { if (impl->mStrong == INITIAL_STRONG_VALUE) delete impl->mBase; else { delete impl; } } else { impl->mBase->onLastWeakRef(id); if ((impl->mFlags&OBJECT_LIFETIME_FOREVER) != OBJECT_LIFETIME_FOREVER) { delete impl->mBase; } } } 在例1中，wp析构后，弱引用计数减1。但由于此时强引用计数和弱引用计数仍为1，所以没有对象被干掉，即没有释放实际对象和影子对象占据的内存。 （5）sp析构的影响 下面进入sp的析构。 [-->RefBase.h] template
//调用前影子对象的弱引用计数为1，强引用计数为0，调用结束后c=1，弱引用计数为0。 const int32_t c = android_atomic_dec(&impl->mWeak); if (c != 1) return; //这次弱引用计数终于变为0了，并且mFlags为0， mStrong也为0。 if ((impl->mFlags&OBJECT_LIFETIME_WEAK) != OBJECT_LIFETIME_WEAK) { if (impl->mStrong == INITIAL_STRONG_VALUE) delete impl->mBase; else { delete impl; //impl就是this，把影子对象也就是自己干掉。 } } else { impl->mBase->onLastWeakRef(id); if ((impl->mFlags&OBJECT_LIFETIME_FOREVER) != OBJECT_LIFETIME_FOREVER) { delete impl->mBase; } } } 好，第一板斧劈下去了！来看看它的结果是什么。 3.第一板斧的结果 第一板斧过后，来总结一下刚才所学的知识： RefBase中有一个隐含的影子对象，该影子对象内部有强弱引用计数。 sp化后，强弱引用计数各增加1，sp析构后，强弱引用计数各减1。 wp化后，弱引用计数增加1，wp析构后，弱引用计数减1。 完全彻底地消灭RefBase对象，包括让实际对象和影子对象灭亡，这些都是由强弱引用计数控制的，另外还要考虑flag的取值情况。当flag为0时，可得出如下结论： 强引用为0将导致实际对象被delete。 弱引用为0将导致影子对象被delete。 5.2.2 第二板斧—由弱生强 再看第二个例子，代码如下所示： [-->例子2] int main() { A *pA = new A(); wp wpA(pA); sp spA = wpA.promote();//通过promote函数，得到一个sp。 } 对A的wp化，不再做分析了。按照前面所讲的知识，wp化后仅会使弱引用计数加1，所以此处wp化的结果是： 影子对象的弱引用计数为1，强引用计数仍然是初始值0x1000000。 wpA的promote函数是从一个弱对象产生一个强对象的重要函数，试看— 1. 由弱生强的方法 代码如下所示： [-->RefBase.h] template
m_ptr = pTemp; */ } 2.成败在此一举 由弱生强的关键函数是attemptIncStrong，它的代码如下所示： [-->RefBase.cpp] bool RefBase::weakref_type::attemptIncStrong(const void* id) { incWeak(id); //增加弱引用计数，此时弱引用计数变为2。 weakref_impl* const impl = static_cast
//允许由弱生强，强引用计数要增加1，而弱引用计数已经增加过了。 curCount = android_atomic_inc(&impl->mStrong); if (curCount > 0 && curCount < INITIAL_STRONG_VALUE) { impl->mBase->onLastStrongRef(id); } } impl->addWeakRef(id); impl->addStrongRef(id);//两个函数调用没有作用。 if (curCount == INITIAL_STRONG_VALUE) { //强引用计数变为1。 android_atomic_add(-INITIAL_STRONG_VALUE, &impl->mStrong); //调用onFirstRef，通知该对象第一次被强引用。 impl->mBase->onFirstRef(); } return true; //由弱生强成功。 } 3. 第二板斧的结果 promote完成后，相当于增加了一个强引用。根据上面所学的知识可知： 由弱生强成功后，强弱引用计数均增加1。所以现在影子对象的强引用计数为1，弱引用计数为2。 5.2.3 第三板斧—破解生死魔咒 1. 延长生命的魔咒 RefBase为我们提供了一个这样的函数： extendObjectLifetime(int32_t mode) 另外还定义了一个枚举： enum { OBJECT_LIFETIME_WEAK = 0x0001, OBJECT_LIFETIME_FOREVER = 0x0003 }; 注意：FOREVER的值是3，用二进制表示是B11，而WEAK的二进制是B01，也就是说FOREVER包括了WEAK的情况。 上面这两个枚举值，是破除强弱引用计数作用的魔咒。先观察flags为OBJECT_LIFETIME_ WEAK的情况，见下面的例子。 [-->例子3] class A：public RefBase { public A() { extendObjectLifetime(OBJECT_LIFETIME_WEAK);//在构造函数中调用。 } } int main() { A *pA = new A(); wp wpA(pA);//弱引用计数加1。 { sp spA(pA) //sp后，结果是强引用计数为1，弱引用计数为2。 } .... } sp的析构将直接调用RefBase的decStrong，它的代码如下所示： [-->RefBase.cpp] void RefBase::decStrong(const void* id) const { weakref_impl* const refs = mRefs; refs->removeStrongRef(id); const int32_t c = android_atomic_dec(&refs->mStrong); if (c == 1) { //上面进行原子操作后，强引用计数为0 const_cast
#if HAVE_ANDROID_OS self->mTid = gettid(); #endif
bool first = true;
do { bool result; if (first) { first = false; //self代表继承Thread类的对象，第一次进来时将调用readyToRun，看看是否准备好。 self->mStatus = self->readyToRun(); result = (self->mStatus == NO_ERROR);
if (result && !self->mExitPending) { result = self->threadLoop(); } } else { /* 调用子类实现的threadLoop函数，注意这段代码运行在一个do-while循环中。 这表示即使我们的threadLoop返回了，线程也不一定会退出。 */ result = self->threadLoop(); } /* 线程退出的条件： 1）result 为false。这表明，如果子类在threadLoop中返回false，线程就可以 退出。这属于主动退出的情况，是threadLoop自己不想继续干活了，所以返回false。 读者在自己的代码中千万别写错threadLoop的返回值。 2）mExitPending为true，这个变量可由Thread类的requestExit函数设置，这种 情况属于被动退出，因为由外界强制设置了退出条件。 */ if (result == false || self->mExitPending) { self->mExitPending = true; self->mLock.lock(); self->mRunning = false; self->mThreadExitedCondition.broadcast(); self->mLock.unlock(); break; } strong.clear(); strong = weak.promote(); } while(strong != 0); return 0; } 关于_threadLoop，我们就介绍到这里。请读者务必注意下面一点： threadLoop运行在一个循环中，它的返回值可以决定是否退出线程。 5.3.2 常用同步类 同步，是多线程编程中不可回避的话题，同时也是一个非常复杂的问题。这里只简单介绍一下Android提供的同步类。这些类，只对系统提供的多线程同步函数（这种函数我们称为Raw API）进行了面向对象的封装，读者必须先理解Raw API，然后才能真正掌握其具体用法。 提示 要了解Windows下的多线程编程，有很多参考资料，而有关Linux下完整系统阐述多线程编程的书籍目前较少，这里推荐一本含金量较高的著作《Programming with POSIX Thread》（本书只有英文版，由Addison-Wesley出版）。 Android提供了两个封装好的同步类，它们是Mutex和Condition。这是重量级的同步技术，一般内核都会有对应的支持。另外，OS还提供了简单的原子操作，这些也算是同步技术中的一种。下面分别来介绍这三种东西。 1. 互斥类—Mutex Mutex是互斥类，用于多线程访问同一个资源的时候，保证一次只有一个线程能访问该资源。在《Windows核心编程》①一书中，对于这种互斥访问有一个很形象的比喻：想象你在飞机上如厕，这时卫生间的信息牌上显示“有人”，你必须等里面的人出来后才可进去。这就是互斥的含义。 下面来看Mutex的实现方式，它们都很简单。 （1）Mutex介绍 其代码如下所示： [-->Thread.h::Mutex的声明和实现] inline Mutex::Mutex(int type, const char* name) { if (type == SHARED) { //type如果是SHARED，则表明这个Mutex支持跨进程的线程同步。 //以后我们在Audio系统和Surface系统中会经常见到这种用法。 pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED); pthread_mutex_init(&mMutex, &attr); pthread_mutexattr_destroy(&attr); } else { pthread_mutex_init(&mMutex, NULL); } } inline Mutex::~Mutex() { pthread_mutex_destroy(&mMutex); } inline status_t Mutex::lock() { return -pthread_mutex_lock(&mMutex); } inline void Mutex::unlock() { pthread_mutex_unlock(&mMutex); } inline status_t Mutex::tryLock() { return -pthread_mutex_trylock(&mMutex); } 关于Mutex的使用，除了初始化外，最重要的是lock和unlock函数的使用，它们的用法如下： 要想独占卫生间，必须先调用Mutex的lock函数。这样，这个区域就被锁住了。如果这块区域之前已被别人锁住，lock函数则会等待，直到可以进入这块区域为止。系统保证一次只有一个线程能lock成功。 当你“方便”完毕，记得调用Mutex的unlock以释放互斥区域。这样，其他人的lock才可以成功返回。 另外，Mutex还提供了一个trylock函数，该函数只是尝试去锁住该区域，使用者需要根据trylock的返回值来判断是否成功锁住了该区域。 注意 以上这些内容都和Raw API有关，不了解它的读者可自行学习相关知识。在Android系统中，多线程也是常见和重要的编程手段，务必请大家重视。 Mutex类确实比Raw API方便好用，不过还是稍显麻烦。 （2）AutoLock介绍 AutoLock类是定义在Mutex内部的一个类，它其实是一帮“懒人”搞出来的，为什么这么说呢？先来看看使用Mutex有多麻烦： 显示调用Mutex的lock。 在某个时候记住要调用该Mutex的unlock。 以上这些操作都必须一一对应，否则会出现“死锁”！在有些代码中，如果判断分支特别多，你会发现unlock这句代码被写得比比皆是，如果稍有不慎，在某处就会忘了写它。有什么好办法能解决这个问题吗？终于有人想出来一个好办法，就是充分利用了C++的构造和析构函数，只需看一看AutoLock的定义就会明白。代码如下所示： [-->Thread.h Mutex::Autolock声明和实现] class Autolock { public: //构造的时候调用lock。 inline Autolock(Mutex& mutex) : mLock(mutex) { mLock.lock(); } inline Autolock(Mutex* mutex) : mLock(*mutex) { mLock.lock(); } //析构的时候调用unlock。 inline ~Autolock() { mLock.unlock(); } private: Mutex& mLock; }; AutoLock的用法很简单： 先定义一个Mutex，如 Mutex xlock。 在使用xlock的地方，定义一个AutoLock，如 AutoLock autoLock（xlock）。 由于C++对象的构造和析构函数都是自动被调用的，所以在AutoLock的生命周期内，xlock的lock和unlock也就自动被调用了，这样就省去了重复书写unlock的麻烦，而且lock和unlock的调用肯定是一一对应的，这样就绝对不会出错。 2. 条件类—Condition 多线程同步中的条件类对应的是下面这种使用场景： 线程A做初始化工作，而其他线程比如线程B、C必须等到初始化工作完后才能工作，即线程B、C在等待一个条件，我们称B、C为等待者。 当线程A完成初始化工作时，会触发这个条件，那么等待者B、C就会被唤醒。触发这个条件的A就是触发者。 上面的使用场景非常形象，而且条件类提供的函数也非常形象，它的代码如下所示： [-->Thread.h:: Condition的声明和实现] class Condition { public: enum { PRIVATE = 0, SHARED = 1 };
Condition(); Condition(int type);//如果type是SHARED，表示支持跨进程的条件同步 ~Condition(); //线程B和C等待事件，wait这个名字是不是很形象呢？ status_t wait(Mutex& mutex); //线程B和C的超时等待，B和C可以指定等待时间，当超过这个时间，条件却还不满足，则退出等待。 status_t waitRelative(Mutex& mutex, nsecs_t reltime); //触发者A用来通知条件已经满足，但是B和C只有一个会被唤醒。 void signal(); //触发者A用来通知条件已经满足，所有等待者都会被唤醒。 void broadcast();
private: #if defined(HAVE_PTHREADS) pthread_cond_t mCond; #else void* mState; #endif } 声明很简单，定义也很简单，代码如下所示： inline Condition::Condition() { pthread_cond_init(&mCond, NULL); } inline Condition::Condition(int type) { if (type == SHARED) {//设置跨进程的同步支持。 pthread_condattr_t attr; pthread_condattr_init(&attr); pthread_condattr_setpshared(&attr, PTHREAD_PROCESS_SHARED); pthread_cond_init(&mCond, &attr); pthread_condattr_destroy(&attr); } else { pthread_cond_init(&mCond, NULL); } } inline Condition::~Condition() { pthread_cond_destroy(&mCond); } inline status_t Condition::wait(Mutex& mutex) { return -pthread_cond_wait(&mCond, &mutex.mMutex); } inline status_t Condition::waitRelative(Mutex& mutex, nsecs_t reltime) { #if defined(HAVE_PTHREAD_COND_TIMEDWAIT_RELATIVE) struct timespec ts; ts.tv_sec = reltime/1000000000; ts.tv_nsec = reltime%1000000000; return -pthread_cond_timedwait_relative_np(&mCond, &mutex.mMutex, &ts); ...... //有些系统没有实现POSIX的相关函数，所以不同的系统需要调用不同的函数。 #endif } inline void Condition::signal() { pthread_cond_signal(&mCond); } inline void Condition::broadcast() { pthread_cond_broadcast(&mCond); } 可以看出，Condition的实现全是凭借调用了Raw API的pthread_cond_xxx函数。这里要重点说明的是，Condition类必须配合Mutex来使用。什么意思？ 在上面的代码中，不论是wait、waitRelative、signal还是broadcast的调用，都放在一个Mutex的lock和unlock范围中，尤其是wait和waitRelative函数的调用，这是强制性的。 来看一个实际的例子，加深一下对Condition类和Mutex类的印象。这个例子是Thread类的requestExitAndWait，目的是等待工作线程退出，代码如下所示： [-->Thread.cpp] status_t Thread::requestExitAndWait() { ...... requestExit(); //设置退出变量mExitPending为true。 Mutex::Autolock _l(mLock);//使用Autolock，mLock被锁住。 while (mRunning == true) { /* 条件变量的等待，这里为什么要通过while循环来反复检测mRunning？ 因为某些时候即使条件类没有被触发，wait也会返回。关于这个问题，强烈建议读者阅读 前面推荐的《Programming with POSIX Thread》一书。 */ mThreadExitedCondition.wait(mLock); }
mExitPending = false; //退出前，局部变量Mutex::Autolock _l的析构会被调用，unlock也就会被自动调用。 return mStatus; } 那么，什么时候会触发这个条件呢？是在工作线程退出前。其代码如下所示： [-->Thread.cpp] int Thread::_threadLoop(void* user) { Thread* const self = static_cast (user); sp strong(self->mHoldSelf); wp weak(strong); self->mHoldSelf.clear();
do { ...... result = self->threadLoop();//调用子类的threadLoop函数。 ...... //如果mExitPending为true，则退出。 if (result == false || self->mExitPending) { self->mExitPending = true; //退出前触发条件变量，唤醒等待者。 self->mLock.lock();//lock锁住。 //mRunning的修改位于锁的保护中。如果你阅读了前面推荐的书，这里也就不难理解了。 self->mRunning = false; self->mThreadExitedCondition.broadcast(); self->mLock.unlock();//释放锁。 break;//退出循环，此后该线程函数会退出。 } ...... } while(strong != 0); return 0; } 关于Android多线程的同步类，暂时介绍到此吧。当然，这些类背后所隐含的知识及技术是读者需要倍加重视的。 提示 希望我们能养成一种由点及面的学习方法。以我们的同步类为例，假设你是第一次接触多线程编程，也学会了如何使用Mutex和Condition这两个类，不妨以这两个类代码中所传递的知识作为切入点，把和多线程相关的所有知识（这个知识不仅仅是函数的使用，还包括多线程的原理，多线程的编程模型，甚至是现在很热门的并行多核编程）普遍了解一下。只有深刻理解并掌握了原理等基础和框架性的知识后，才能以不变应万变，才能做到游刃有余。 3. 原子操作函数介绍 什么是原子操作？所谓原子操作，就是该操作绝不会在执行完毕前被任何其他任务或事件打断，也就说，原子操作是最小的执行单位。 上面这句话放到代码中是什么意思？请看一个例子： [-->例子] static int g_flag = 0; //全局变量g_flag static Mutex lock ;//全局的锁 //线程1执行thread1。 void thread1() { //g_flag递减,每次操作前锁住。 lock.lock(); g_flag--; lock.unlock(); } //线程2中执行thread2函数。 void thread2() { lock.lock(); g_flag++; //线程2对g_flag进行递增操作，每次操作前要取得锁。 lock.unlock(); } 为什么需要Mutex来帮忙呢？因为g_flags++或g_flags--操作都不是原子操作。从汇编指令的角度看，C/C++中的一条语句对应了数条汇编指令。以g_flags++操作为例，它生成的汇编指令可能就是以下三条： 从内存中取数据到寄存器。 对寄存器中的数据进行递增操作，结果还在寄存器中。 寄存器的结果写回内存。 这三条汇编指令，如果按正常的顺序连续执行是没有问题的，但在多线程时就不能保证了。例如，线程1在执行第一条指令后，线程2由于调度的原因，抢在线程1之前连续执行完了三条指令。这样，线程1继续执行指令时，它所使用的值就不是线程2更新后的值，而是之前的旧值。再对这个值进行操作便没有意义了。 在一般情况下，处理这种问题可以使用Mutex来加锁保护，但Mutex的使用方法比它所要保护的内容还要复杂，例如，锁的使用将导致从用户态转入内核态，有较大的浪费。那么，有没有简便些的办法让这些加、减等操作不被中断呢？ 答案是肯定的，但这需要CPU的支持。在X86平台上，一个递增操作可以用下面的内嵌汇编语句来实现： #define LOCK "lock;" INT32 InterlockedIncrement(INT32* lpAddend) { /* 这是我们在Linux平台上实现Windows API时使用的方法。 其中在SMP系统上，LOCK定义成"lock;"表示锁总线，这样同一时刻就只能有一个CPU访问总线了。 非SMP系统，LOCK定义成空。由于InterlockedIncrement要返回递增前的旧值，所以我们 使用了xaddl指令，它先交换源和目的的操作数，再进行递增操作。 */ INT32 i = 1; __asm__ __volatile__( LOCK "xaddl %0, %1" :"+r" (i), "+m" (*lpAddend) : : "memory"); return *lpAddend; } Android提供了相关的原子操作函数。这里有必要介绍一下各个函数的作用。 [-->Atomic.h]，注意该文件位于system/core/include/cutils目录中。 //原子赋值操作，结果是*addr=value。 void android_atomic_write(int32_t value, volatile int32_t* addr); //下面所有函数的返回值都是操作前的旧值。 //原子加1和原子减1。 int32_t android_atomic_inc(volatile int32_t* addr); int32_t android_atomic_dec(volatile int32_t* addr); //原子加法操作，value为被加数。 int32_t android_atomic_add(int32_t value, volatile int32_t* addr); //原子“与”和“或”操作。 int32_t android_atomic_and(int32_t value, volatile int32_t* addr); int32_t android_atomic_or(int32_t value, volatile int32_t* addr); /* 条件交换的原子操作。只有在oldValue等于*addr时，才会把newValue赋值给*addr。 这个函数的返回值须特别注意。返回值非零，表示没有进行赋值操作。返回值为零，表示 进行了原子操作。 */ int android_atomic_cmpxchg(int32_t oldvalue, int32_t newvalue, volatile int32_t* addr); 有兴趣的话，读者可以对上述函数的实现进行深入研究，其中： X86平台的实现在system/core/libcutils/Atomic.c中，注意其代码在#elif defined(__i386__) || defined(__x86_64__)所包括的代码段内。 ARM平台的实现在system/core/libcutils/atomic-android-arm.S汇编文件中。 原子操作的最大好处在于避免了锁的使用，这对整个程序运行效率的提高有很大帮助。目前，在多核并行编程中，最高境界就是完全不使用锁。当然，它的难度可想而知是巨大的。 5.4 Looper和Handler类分析 就应用程序而言，Android系统中Java的应用程序和其他系统上相同，都是靠消息驱动来工作的，它们大致的工作原理如下： 有一个消息队列，可以往这个消息队列中投递消息。 有一个消息循环，不断从消息队列中取出消息，然后处理。 我们用图5-1来展示这个工作过程：
图5-1 线程和消息处理的原理图 从图中可以看出： 事件源把待处理的消息加入到消息队列中，一般是加至队列尾，一些优先级高的消息也可以加至队列头。事件源提交的消息可以是按键、触摸屏等物理事件产生的消息，也可以是系统或应用程序本身发出的请求消息。 处理线程不断从消息队列头中取出消息并处理，事件源可以把优先级高的消息放到队列头，这样，优先级高的消息就会首先被处理。 在Android系统中，这些工作主要由Looper和Handler来实现： Looper类，用于封装消息循环，并且有一个消息队列。 Handler类，有点像辅助类，它封装了消息投递、消息处理等接口。 Looper类是其中的关键。先来看看它是怎么做的。 5.4.1 Looper类分析 我们以Looper使用的一个常见例子来分析这个Looper类。 [-->例子1] //定义一个LooperThread。 class LooperThread extends Thread { public Handler mHandler; public void run() { //① 调用prepare。 Looper.prepare(); ...... //② 进入消息循环。 Looper.loop(); } } //应用程序使用LooperThread。 { ...... new LooperThread().start();//启动新线程，线程函数是run } 上面的代码一共有两个关键调用（即①和②），我们对其逐一进行分析。 1. 准备好了吗 第一个调用函数是Looper的prepare函数。它会做什么工作呢？其代码如下所示： [-->Looper.java] public static final void prepare() { //一个Looper只能调用一次prepare。 if (sThreadLocal.get() != null) { throw new RuntimeException("Only _disibledevent=>Looper.java] private Looper(){ //构造一个消息队列。 mQueue = new MessageQueue(); mRun = true; //得到当前线程的Thread对象。 mThread = Thread.currentThread(); } prepare函数很简单，它主要干了一件事： 在调用prepare的线程中，设置了一个Looper对象，这个Looper对象就保存在这个调用线程的TLV中。而Looper对象内部封装了一个消息队列。 也就是说，prepare函数通过ThreadLocal机制，巧妙地把Looper和调用线程关联在一起了。要了解这样做的目的是什么，需要再看第二个重要函数。 2.Looper循环 代码如下所示： [-->Looper.java] public static final void loop() { Looper me = myLooper();//myLooper返回保存在调用线程TLV中的Looper对象。 //取出这个Looper的消息队列。 MessageQueue queue = me.mQueue; while (true) { Message msg = queue.next(); //处理消息，Message对象中有一个target，它是Handler类型。 //如果target为空，则表示需要退出消息循环。 if (msg != null) { if (msg.target == null) { return; } //调用该消息的Handler，交给它的dispatchMessage函数处理。 msg.target.dispatchMessage(msg); msg.recycle(); } } } //myLooper函数返回调用线程的线程局部变量，也就是存储在其中的Looper对象。 public static final Looper myLooper() { return (Looper)sThreadLocal.get(); } 通过上面的分析会发现，Looper的作用是： 封装了一个消息队列。 Looper的prepare函数把这个Looper和调用prepare的线程（也就是最终的处理线程）绑定在一起了。 处理线程调用loop函数，处理来自该消息队列的消息。 当事件源向这个Looper发送消息的时候，其实是把消息加到这个Looper的消息队列里了。那么，该消息就将由和Looper绑定的处理线程来处理。可事件源又是怎么向Looper消息队列添加消息的呢？来看下一节。 3.Looper、Message和Handler的关系 Looper、Message和Handler之间也存在暧昧关系，不过要比RefBase那三个简单得多，用两句话就可以说清楚： Looper中有一个Message队列，里面存储的是一个个待处理的Message。 Message中有一个Handler，这个Handler是用来处理Message的。 其中，Handler类封装了很多琐碎的工作。先来认识一下这个Handler。 5.4.2 Handler分析 1.初识Handler Handler中所包括的成员： [-->Handler.java] final MessageQueue mQueue;//Handler中也有一个消息队列。 final Looper mLooper;//也有一个Looper。 final Callback mCallback;//有一个回调用的类。 这几个成员变量是怎么使用的呢？这首先得分析Handler的构造函数。Handler一共有四个构造函数，它们主要的区别是在对上面三个重要成员变量的初始化上。我们试对其进行逐一的分析。 [-->Handler.java] //构造函数1 public Handler() { //获得调用线程的Looper。 mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException(......); } //得到Looper的消息队列。 mQueue = mLooper.mQueue; //无callback设置。 mCallback = null; } //构造函数2 public Handler(Callback callback) { mLooper = Looper.myLooper(); if (mLooper == null) { throw new RuntimeException(......); } //和构造函数1类似，只不过多了一个设置callback。 mQueue = mLooper.mQueue; mCallback = callback; } //构造函数3 public Handler(Looper looper) { mLooper = looper; //looper由外部传入，是哪个线程的Looper不确定。 mQueue = looper.mQueue; mCallback = null; } //构造函数4，和构造函数3类似，只不过多了callback设置。 public Handler(Looper looper, Callback callback) { mLooper = looper; mQueue = looper.mQueue; mCallback = callback; } 在上述构造函数中，Handler中的消息队列变量最终都会指向Looper的消息队列，Handler为何要如此做？ 2. Handler的真面目 根据前面的分析可知，Handler中的消息队列实际就是某个Looper的消息队列，那么，Handler如此安排的目的何在？ 在回答这个问题之前，我先来问一个问题： 怎么往Looper的消息队列插入消息？ 如果不知道Handler，这里有一个很原始的方法可解决上面这个问题： 调用Looper的myQueue，它将返回消息队列对象MessageQueue。 构造一个Message，填充它的成员，尤其是target变量。 调用MessageQueue的enqueueMessage，将消息插入消息队列。 这种原始方法的确很麻烦，且极容易出错。但有了Handler后，我们的工作就变得异常简单了。Handler更像一个辅助类，帮助我们简化编程的工作。 （1）Handler和Message Handler提供了一系列函数，帮助我们完成创建消息和插入消息队列的工作。这里只列举其中一二。要掌握详细的API，则需要查看相关的文档。 //查看消息队列中是否有消息码是what的消息。 final boolean hasMessages(int what) //从Handler中创建一个消息码是what的消息。 final Message obtainMessage(int what) //从消息队列中移除消息码是what的消息。 final void removeMessages(int what) //发送一个只填充了消息码的消息。 final boolean sendEmptyMessage(int what) //发送一个消息，该消息添加到队列尾。 final boolean sendMessage(Message msg) //发送一个消息，该消息添加到队列头，所以优先级很高。 final boolean sendMessageAtFrontOfQueue(Message msg) 只需对上面这些函数稍作分析，就能明白其他的函数。现以sendMessage为例，其代码如下所示： [-->Handler.java] public final boolean sendMessage(Message msg) { return sendMessageDelayed(msg, 0); //调用sendMessageDelayed } [-->Handler.java] // delayMillis是以当前调用时间为基础的相对时间 public final boolean sendMessageDelayed(Message msg, long delayMillis) { if (delayMillis < 0) { delayMillis = 0; } //调用sendMessageAtTime，把当前时间算上 return sendMessageAtTime(msg,SystemClock.uptimeMillis() + delayMillis); } [-->Handler.java] //uptimeMillis 是绝对时间，即sendMessageAtTime函数处理的是绝对时间 public boolean sendMessageAtTime(Message msg, long uptimeMillis){ boolean sent = false; MessageQueue queue = mQueue; if (queue != null) { //把Message的target设置为自己，然后加入到消息队列中 msg.target = this; sent = queue.enqueueMessage(msg, uptimeMillis); } return sent; } 看到上面这些函数我们可以预见，如果没有Handler的辅助，当我们自己操作MessageQueue的enqueueMessage时，得花费多大工夫！ Handler把Message的target设为自己，是因为Handler除了封装消息添加等功能外还封装了消息处理的接口。 （2）Handler的消息处理 刚才，我们往Looper的消息队列中加入了一个消息，按照Looper的处理规则，它在获取消息后会调用target的dispatchMessage函数，再把这个消息派发给Handler处理。Handler在这块是如何处理消息的呢？ [-->Handler.java] public void dispatchMessage(Message msg) { //如果Message本身有callback，则直接交给Message的callback处理 if (msg.callback != null) { handleCallback(msg); } else { //如果本Handler设置了mCallback，则交给mCallback处理 if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } //最后才是交给子类处理 handleMessage(msg); } } dispatchMessage定义了一套消息处理的优先级机制，它们分别是： Message如果自带了callback处理，则交给callback处理。 Handler如果设置了全局的mCallback，则交给mCallback处理。 如果上述都没有，该消息则会被交给Handler子类实现的handleMessage来处理。当然，这需要从Handler派生并重载handleMessage函数。 在通常情况下，我们一般都是采用第三种方法，即在子类中通过重载handleMessage来完成处理工作的。 至此，Handler知识基本上讲解完了，可是在实际编码过程中还有一个重要问题需要警惕，下一节内容就会谈及此问题。 5.4.3 Looper和Handler的同步关系 Looper和Handler会有什么同步关系呢？它们之间确实有同步关系，而且如果不注意此关系，定会铸成大错！ 同步关系肯定与多线程有关，我们来看下面的一个例子： [-->例子2] //先定义一个LooperThread类 class LooperThread extends Thread { public Looper myLooper = null;//定义一个public的成员myLooper，初值为空。 public void run() { //假设run在线程2中执行 Looper.prepare(); // myLooper必须在这个线程中赋值 myLooper = Looper.myLooper(); Looper.loop(); } } //下面这段代码在线程1中执行，并且会创建线程2 { LooperThread lpThread= new LooperThread; lpThread.start();//start后会创建线程2 Looper looper = lpThread.myLooper;//<======注意 // thread2Handler和线程2的Looper挂上钩 Handler thread2Handler = new Handler(looper); //sendMessage发送的消息将由线程2处理 threadHandler.sendMessage(...) } 上面这段代码的目的很简单： 线程1中创建线程2，并且线程2通过Looper处理消息。 线程1中得到线程2的Looper，并且根据这个Looper创建一个Handler，这样发送给该Handler的消息将由线程2处理。 但很可惜，上面的代码是有问题的。如果我们熟悉多线程，就会发现标有“注意”的那行代码存在着严重问题。myLooper的创建是在线程2中，而looper的赋值在线程1中，很有可能此时线程2的run函数还没来得及给myLooper赋值，这样线程1中的looper将取到myLooper的初值，也就是looper等于null。另外， Handler thread2Handler = new Handler(looper) 不能替换成 Handler thread2Handler = new Handler(Looper.myLooper()) 这是因为，myLooper返回的是调用线程的Looper，即Thread1的Looper，而不是我们想要的Thread2的Looper。 对这个问题，可以采用同步的方式进行处理。你是不是有点迫不及待地想完善这个例子了？其实Android早就替我们想好了，它提供了一个HandlerThread来解决这个问题。 5.4.4 HandlerThread介绍 HandlerThread完美地解决了myLooper可能为空的问题。下面来看看它是怎么做的，代码如下所示： [-->HandlerThread] public class HandlerThread extends Thread{ //线程1调用getLooper来获得新线程的Looper public Looper getLooper() { ...... synchronized (this) { while (isAlive() && mLooper == null) { try { wait();//如果新线程还未创建Looper，则等待 } catch (InterruptedException e) { } } } return mLooper; } //线程2运行它的run函数，looper就是在run线程里创建的。 public void run() { mTid = Process.myTid(); Looper.prepare(); //创建这个线程上的Looper synchronized (this) { mLooper = Looper.myLooper(); notifyAll();//通知取Looper的线程1，此时Looper已经创建好了。 } Process.setThreadPriority(mPriority); _disibledevent=>
最新评论