Boost和Loki是应用比较广泛的引用计数方案，Android提供了另外一个引用计数方案，就是sp、wp和Refbase组合。
强引用和弱引用区别
在Android里面，sp是强引用，它是应用最多的引用形式，而且后面的分析，我们将知道，强引用直接管理着对象的销毁；wp是弱引用，弱引用的用途是能够对某个对象进行引用，但是即使该对象弱引用还存在，这个对象也可能会被销毁。弱引用看上去更复杂一些，以下是在网上摘录的一句话，“弱引用适合那些数据成员特别多，而且重新创建又相对容易的类，也就是俗称的胖子类，建立弱引用可以引用对象，但也不阻止其被垃圾回收，在内存的使用方面取得一定的平衡”。还是看看实际的例子比较好，如Android Framework/base/services/camera/libcamera/cameraservice.cpp中的一段代码：
sp<Client> client; if (cameraId < 0 || cameraId >= mNumberOfCameras) { LOGE("CameraService::connect X (pid %d) rejected (invalid cameraId %d).", callingPid, cameraId); return NULL; } Mutex::Autolock lock(mServiceLock); if (mClient[cameraId] != 0) { client = mClient[cameraId].promote(); if (client != 0) { if (cameraClient->asBinder() == client->getCameraClient()->asBinder()) { LOG1("CameraService::connect X (pid %d) (the same client)", callingPid); return client; } else { LOGW("CameraService::connect X (pid %d) rejected (existing client).", callingPid); return NULL; } } mClient[cameraId].clear(); }代码说明该代码是函数connect的一部分，connect函数是客户端camera.cpp连接cameraservice以获得获得服务。Android的cameraservice机制是可以支持多个摄像头同时供多个客户端使用，并且，每个摄像头可能会被多个客户端轮流使用（你可以想象，在不关闭摄像头的情况下，两个应用程序交替显示一个摄像头的图像，如果帧数足够多，那么这个摄像头采集的数据就可以同时供两个应用程序顺畅显示）。那么应用程序A和B是如何交替使用呢，就是分别调用service提供的connect函数，而mClient数组就是service部分将具体的某个摄像头和某个具体的应用程序挂钩的变量（该变量就是CameraService::Client类对象），从这也可以看出，一个时间点，一个摄像头只能同时供一个应用程序使用。所以，在交替切换过程中，就伴随着CameraService::Client类对象的创建和销毁。
这个时候之所以使用弱引用更方便，是因为如果程序A正在使用摄像头，如果按照强引用，程序B是无法从程序A抢到摄像头的；而如果是弱引用，即使程序A占用摄像头，程序B依然可以将程序A在CameraService的资源释放，然后创建自己的资源，然后将建立自己的弱引用。这确实很巧妙。
所以弱引用适合用在资源可以被多个程序同时交替使用，时刻可能被其他程序抢走资源的情况，而且资源可以自己负责，也可以自己不负责的情况。
sp如何管理强引用计数
sp指的是对象的强引用，一般定义如下，sp<Camera> mCamera，那么，mCamera对应的实际对象就交由sp进行管理了，当引用计数为0时，该实际对象就会被销毁。那么在什么情况要增加引用计数，在什么情况要减少引用计数呢？
以下是增加引用计数的情况：
1. 指针赋值拷贝
如：
sp<Camera> mCamera = new camera();
这是一个用得非常多的情况，当new一个对象时，就将该对象的指针交由sp进行管理了，那么这个时候sp就应该增加这个new对象的引用计数，当然这个时候应该是1；
Camera* c = new camera();
sp<Camera> mCamera = c;
该情况是将一个已经new好了的对象指针赋值给mCamera，那么这个时候sp就应该增加这个new对象的引用计数。
sp相应代码如下：
template<typename T>sp<T>& sp<T>::operator = (T* other){ if (other) other->incStrong(this); if (m_ptr) m_ptr->decStrong(this); m_ptr = other; return *this;}其中m_ptr是对象的指针，该代码的逻辑如下# 如果被复制的对象存在，即other不为NULL，那么就将该对象的引用计数加1；
# 如果原来m_ptr已经指向了某个对象，那么就将某个对象的引用计数减1；
# 然后将other赋值给m_ptr，从此，m_ptr就指向了刚刚设置的对象；
2. 引用赋值拷贝
如：
sp<Camera> c = new camera();
sp<Camera> mCamera = c;
将一个对象c赋值给mCamera，sp对应代码如下：template<typename T>sp<T>& sp<T>::operator = (const sp<T>& other) { T* otherPtr(other.m_ptr); if (otherPtr) otherPtr->incStrong(this); if (m_ptr) m_ptr->decStrong(this); m_ptr = otherPtr; return *this;}# 将被赋值对象other的对象引用计数加1；
# 将sp对应对象的引用计数减1；
# 将sp的对象改为other对象；
3. 指针构造拷贝
如：
sp<Camera> mCamera(new camera());
sp相应代码如下：template<typename T>sp<T>::sp(T* other) : m_ptr(other){ if (other) other->incStrong(this);}# 将被赋值对象other的对象指针m_ptr赋值给当前sp的m_ptr；# 如果被赋值对象other的对象存在，则将该对象的引用计数加1；
4. 引用构造拷贝
如：
sp<Camera> c = new camera();
sp<Camera> mCamera(c);
sp相应代码如下：template<typename T>sp<T>::sp(const sp<T>& other) : m_ptr(other.m_ptr){ if (m_ptr) m_ptr->incStrong(this);}# 将被赋值对象other的对象指针m_ptr赋值给当前sp的m_ptr；
# 如果被赋值对象other的对象存在，则将该对象的引用计数加1；
1. sp析构
如：
{
sp<Camera> c = new camera();
/* do something*/
}
由于c是局部变量，那么，在大括号结束前，c将被析构。
sp对应代码如下：
template<typename T>sp<T>::~sp(){ if (m_ptr) m_ptr->decStrong(this);}# 析构并不代表对象真的销毁，因为可能将该对象赋值给了其他sp管理，所以，析构函数只是将对象的引用计数减1；2. 指针赋值拷贝和引用赋值拷贝
在上面的增加引用计数已经介绍，重新设置sp管理的对象，必须将现在管理的对象的引用计数减1
3. 清除
如：
sp<Camera> mCamera = new camera();
mCamera.clear();
意思设置mCamera不再管理任何对象。
sp代码如下：
template<typename T>void sp<T>::clear(){ if (m_ptr) { m_ptr->decStrong(this); m_ptr = 0; }}# 将管理的对象引用计数减1；# 将m_ptr置空；
wp如何管理弱引用计数
对于wp的处理和sp基本相同，代码部分就不做细致分析了。
我们可以记住，弱引用计数可以通过promote函数升级为强引用。
Refbase机制
我们在上面一节可以看到，sp和wp就是调用Refbase提供的incStrong、decStrong、incWeak和decWeak设置对象的引用计数，那么Refbase是如何实现的呢，以及什么情况下才会将对象销毁呢？
如：
{
sp<Camera> mCamera = new camera();
}
上面如此简单的代码，sp先将camera对象的引用计数加1，然后由于作用域结束，所以mCamera被析构，析构时会将camera对象的引用计数减1，那么这个时候，这个对象的引用计数恰好是0，那么这个时候对象会被销毁吗？我们还是看看Refbase是如何被构造，如何管理引用计数，如何管理对象的。
构造
RefBase::RefBase() : mRefs(new weakref_impl(this)){// LOGV("Creating refs %p with RefBase %p\n", mRefs, this);}很简单，只是又创建了一个weakref_impl，从这个名字就可以看出它是处理弱引用的类，其实除了弱引用，它还处理强引用。我们还是根据《心得 - 如何读大型代码和写代码》所描述的方法，我们只需要从宏观上了解weakref_impl的作用，我们现在正在研究Refbase，所以，只要在调用weakref_impl的地方，我们只要能够猜出它完成了什么功能即可，不进行深入分析。# 创建了weakref_impl对象，并将this指针传递过去，看来weakref_impl对象要通过this指针来回调Refbase的某些方法；
增加强引用计数
mCamera指针赋值拷贝时会增加引用计数，代码如下：
void RefBase::incStrong(const void* id) const{ weakref_impl* const refs = mRefs; refs->addWeakRef(id); refs->incWeak(id); refs->addStrongRef(id); const int32_t c = android_atomic_inc(&refs->mStrong); LOG_ASSERT(c > 0, "incStrong() called on %p after last strong ref", refs);#if PRINT_REFS LOGD("incStrong of %p from %p: cnt=%d\n", this, id, c);#endif if (c != INITIAL_STRONG_VALUE) { return; } android_atomic_add(-INITIAL_STRONG_VALUE, &refs->mStrong); const_cast<RefBase*>(this)->onFirstRef();}# 增加弱引用，可见，使用强引用时，还伴随着一个弱引用；# 增加强引用；
# 如果是第一次增加强引用计数，那么就会调用onFirstRef函数，我们在代码经常会看到onFirstRef函数，通过该函数，经常会做些初始化方面的工作；
减少强引用计数
当mCamera析构时就会减少强引用计数，代码如下：
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 PRINT_REFS LOGD("decStrong of %p from %p: cnt=%d\n", this, id, c);#endif LOG_ASSERT(c >= 1, "decStrong() called on %p too many times", refs); if (c == 1) { const_cast<RefBase*>(this)->onLastStrongRef(id); if ((refs->mFlags&OBJECT_LIFETIME_WEAK) != OBJECT_LIFETIME_WEAK) { delete this; } } refs->removeWeakRef(id); refs->decWeak(id);}# 减小强引用计数；
# 销毁对象，如果减小强引用计数之前，强引用计数是1，也就是减小后，强引用计数是0，那么这个时候就delete this了；
# 减小弱引用计数，看来弱引用计数和对象实际存不存在没有必然的关系；
weakref_type功能
我们通过Refbase看出，weakref_type实际管理着强引用和弱引用两个计数。
构造
weakref_impl(RefBase* base) : mStrong(INITIAL_STRONG_VALUE) , mWeak(0) , mBase(base) , mFlags(0) { }# 初始化，mStrong（强引用计数）、mWeak（弱引用计数）、mBase（管理的Refbase）另外，和构造函数一起的还有
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) { }
它们什么都没有做。
增加弱引用计数
void RefBase::weakref_type::incWeak(const void* id){ weakref_impl* const impl = static_cast<weakref_impl*>(this); impl->addWeakRef(id); const int32_t c = android_atomic_inc(&impl->mWeak); LOG_ASSERT(c >= 0, "incWeak called on %p after last weak ref", this);}# 通过原子操作增加mWeak； 减少弱引用计数
void RefBase::weakref_type::decWeak(const void* id){ weakref_impl* const impl = static_cast<weakref_impl*>(this); impl->removeWeakRef(id); const int32_t c = android_atomic_dec(&impl->mWeak); LOG_ASSERT(c >= 1, "decWeak called on %p too many times", this); if (c != 1) return; if ((impl->mFlags&OBJECT_LIFETIME_WEAK) != OBJECT_LIFETIME_WEAK) { if (impl->mStrong == INITIAL_STRONG_VALUE) delete impl->mBase; else {// LOGV("Freeing refs %p of old RefBase %p\n", this, impl->mBase); delete impl; } } else { impl->mBase->onLastWeakRef(id); if ((impl->mFlags&OBJECT_LIFETIME_FOREVER) != OBJECT_LIFETIME_FOREVER) { delete impl->mBase; } }}# 通过原子操作减少弱引用计数# 当弱引用计数为0时，那么就会根据某种条件delete this或者delete Refbase
我们在减少强引用和弱引用，看到了OBJECT_LIFETIME_FOREVER和OBJECT_LIFETIME_WEAK两个标志位，那么他们是干什么的呢。
OBJECT_LIFETIME_FOREVER可能代码里面没有设置为这个标识符的类，而OBJECT_LIFETIME_WEAK只有Binder设置了，我们从名字上看出，OBJECT_LIFETIME_FOREVER指的是对象的生命是永远，而OBJECT_LIFETIME_WEAK可能是生命时间按照弱引用计数来决定（一般都是通过强引用计数来决定）。
由于用得很少，所以，这两个标志位对我们的应用而言没有多大关系，但是，我们还是看看代码怎么特殊处理这两个标志位。
在decStrong函数中，
if ((refs->mFlags&OBJECT_LIFETIME_WEAK) != OBJECT_LIFETIME_WEAK) {
delete this;
}
意思是当标志位不是OBJECT_LIFETIME_WEAK时，才会销毁对象。也就是如果标志位是OBJECT_LIFETIME_WEAK，那么如果强引用为0时，也不会销毁对象，看来销毁对象的任务交给其他地方执行了。
还是看上面的decWeak函数，当标志位是OBJECT_LIFETIME_WEAK时，只有当标志位不是OBJECT_LIFETIME_FOREVER才会销毁对象；当标志不是OBJECT_LIFETIME_WEAK时，如果强引用计数也为0，那么就将对象销毁，否则，将weakref_impl销毁。