5.2.1 第一板斧–初识影子对象
最后更新于：2022-04-02 05:49:42
我们的“三板斧”，其实就是三个例子。相信这三板斧劈下去，你会很容易理解它们。
**例子1**
~~~
/类A从RefBase派生,RefBase是万物的始祖
class A：public RefBase
{
//A没有任何自己的功能
}
int main()
{
A* pA =new A;
{
//注意我们的sp，wp对象是在{}中创建的，下面的代码先创建sp，然后创建wp
spspA(A);
wpwpA(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(A);
~~~
请看sp的构造函数，它的代码如下所示：（注意，sp是一个模板类，对此不熟悉的读者可以去翻翻书，或者干脆把所有出现的T都换成A。）
**RefBase.h::sp(T*other)**
~~~
template
sp::sp(T* other) //这里的other就是刚才创建的pA
:m_ptr(other)// sp保存了pA的指针
{
if(other) other->incStrong(this);//调用pA的incStrong
}
~~~
OK，战场转到RefBase的incStrong中。它的代码如下所示：
**RefBase.cpp**
~~~
void RefBase::incStrong(const void* id) const
{
//mRefs就是刚才RefBase构造函数中new出来的影子对象
weakref_impl*const refs = mRefs;
//操作影子对象，先增加弱引用计数
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(this);
impl->addWeakRef(id); //上面说了，非调试版什么都不干
const int32_tc = android_atomic_inc(&impl->mWeak);
//原子操作，影子对象的弱引用计数加1
//千万记住影子对象的强弱引用计数的值，这是彻底理解sp和wp的关键
}
~~~
好，我们再回到incStrong，继续看代码：
**RefBase.cpp**
~~~
......
//刚才增加了弱引用计数
//再增加强引用计数
refs->addStrongRef(id);//非调试版这里什么都不干
//下面函数为原子加1操作，并返回旧值。所以c=0x1000000，而mStrong变为0x1000001
const int32_t c =android_atomic_inc(&refs->mStrong);
if (c!= INITIAL_STRONG_VALUE) {
//如果c不是初始值，则表明这个对象已经被强引用过一次了
return;
}
//下面这个是原子加操作，相当于执行refs->mStrong +（-0x1000000），最终mStrong=1
android_atomic_add(-INITIAL_STRONG_VALUE,&refs->mStrong);
/*
如果是第一次引用，则调用onFirstRef，这个函数很重要，派生类可以重载这个函数，完成一些
初始化工作。
*/
const_cast(this)->onFirstRef();
}
~~~
说明：android_atomic_xxx是Android平台提供的原子操作函数，原子操作函数是多线程编程中的常见函数，读者可以学习原子操作函数知识，本章后面将对其做介绍。
（2）sp构造的影响
sp构造完后，它给这个世界带来了什么？
- 那就是RefBase中影子对象的强引用计数变为1，弱引用计数也变为1。
更准确的说法是，sp的出生导致影子对象的强引用计数加1，弱引用计数加1。
（3）wp构造的影响
继续看wp，例子中的调用方式如下：
~~~
wp wpA(spA)
~~~
wp有好几个构造函数，原理都一样。来看这个最常见的：
**RefBase.h::wp(constsp& other)**
~~~
template
wp::wp(const sp& other)
:m_ptr(other.m_ptr) //wp的成员变量m_ptr指向实际对象
{
if(m_ptr) {
//调用pA的createWeak,并且保存返回值到成员变量m_refs中
m_refs = m_ptr->createWeak(this);
}
}
~~~
**RefBase.cpp**
~~~
RefBase::weakref_type* RefBase::createWeak(constvoid* id) const
{
//调用影子对象的incWeak，这个我们刚才讲过了，将导致影子对象的弱引用计数增加1
mRefs->incWeak(id);
returnmRefs; //返回影子对象本身
}
~~~
我们可以看到，wp化后，影子对象的弱引用计数将增加1，所以现在弱引用计数为2，而强引用计数仍为1。另外，wp中有两个成员变量，一个保存实际对象，另一个保存影子对象。sp只有一个成员变量用来保存实际对象，但这个实际对象内部已包含了对应的影子对象。
OK，wp创建完了，现在开始进入wp的析构。
（4）wp析构的影响
wp进入析构函数，这表明它快要离世了。
**RefBase.h**
~~~
template
wp::~wp()
{
if(m_ptr) m_refs->decWeak(this); //调用影子对象的decWeak，由影子对象的基类实现
}
~~~
**RefBase.cpp**
~~~
void RefBase::weakref_type::decWeak(const void*id)
{
//把基类指针转换成子类（影子对象）的类型，这种做法有些违背面向对象编程的思想
weakref_impl*const impl = static_cast(this);
impl->removeWeakRef(id);//非调试版不做任何事情
//原子减1，返回旧值，c=2，而弱引用计数从2变为1
constint32_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;
}
}
}
~~~
OK，在例1中，wp析构后，弱引用计数减1。但由于此时强引用计数和弱引用计数仍为1，所以没有对象被干掉，即没有释放实际对象和影子对象占据的内存。
（5）sp析构的影响
下面进入sp的析构。
**RefBase.h**
~~~
template
sp::~sp()
{
if(m_ptr) m_ptr->decStrong(this); //调用实际对象的decStrong。由RefBase实现
}
~~~
**RefBase.cpp**
~~~
void RefBase::decStrong(const void* id) const
{
weakref_impl* const refs = mRefs;
refs->removeStrongRef(id);//调用影子对象的removeStrongRef，啥都不干
//注意，此时强弱引用计数都是1，下面函数调用的结果是c=1，强引用计数为0
constint32_t c = android_atomic_dec(&refs->mStrong);
if (c== 1) { //对于我们的例子， c为1
//调用onLastStrongRef，表明强引用计数减为0，对象有可能被delete
const_cast(this)->onLastStrongRef(id);
//mFlags为0，所以会通过delete this把自己干掉
//注意，此时弱引用计数仍为1
if((refs->mFlags&OBJECT_LIFETIME_WEAK) != OBJECT_LIFETIME_WEAK) {
delete this;
}
......
}
~~~
先看delete this的处理，它会导致A的析构函数被调用；再看A的析构函数，代码如下所示：
**例子1::~A()**
~~~
//A的析构直接导致进入RefBase的析构。
RefBase::~RefBase()
{
if(mRefs->mWeak == 0) { //弱引用计数不为0，而是1
delete mRefs;
}
}
~~~
RefBase的delete this自杀行为没有把影子对象干掉，但我们还在decStrong中，可接着从delete this往下看：
**RefBase.cpp**
~~~
....//接前面的delete this
if ((refs->mFlags&OBJECT_LIFETIME_WEAK)!= OBJECT_LIFETIME_WEAK) {
delete this;
}
//注意，实际数据对象已经被干掉了，所以mRefs也没有用了，但是decStrong刚进来
//的时候就保存mRefs到refs了，所以这里的refs指向影子对象
refs->removeWeakRef(id);
refs->decWeak(id);//调用影子对象decWeak
}
~~~
**RefBase.cpp**
~~~
void RefBase::weakref_type::decWeak(const void*id)
{
weakref_impl*const impl = static_cast(this);
impl->removeWeakRef(id);//非调试版不做任何事情
//调用前影子对象的弱引用计数为1，强引用计数为0，调用结束后c=1，弱引用计数为0
constint32_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。
';