Android中的sp和wp指针

  经常会在android的framework代码中发现sp<xxx>和wp<xxx>这样的指针,一直没有整明的，最近花了点时间，仔细啃了一下代码，终于明白了一些，把所懂的记下来，当作笔记。

     sp wp的经典用法如下：

frameworks\av\media\mediaserver\main_mediaserver.cpp

int main(int argc __unused, char **argv __unused)
{
    signal(SIGPIPE, SIG_IGN);

    sp<ProcessState> proc(ProcessState::self());
    sp<IServiceManager> sm(defaultServiceManager());
    ALOGI("ServiceManager: %p", sm.get());
    InitializeIcuOrDie();
    MediaPlayerService::instantiate();
    ResourceManagerService::instantiate();
    registerExtensions();
    ProcessState::self()->startThreadPool();
    IPCThreadState::self()->joinThreadPool();
｝

解析如下：

第一句：signal(SIGPIPE, SIG_IGN) 信号处理相关，暂时不分析。

第二句：sp<ProcessState>proc(ProcessState::self());
这是个strong pointer的声明，初始化用了copy constructor，查看 sp 的构造函数返回的是参数typename(ProcessState::self() 返回 ProcessState对象)的引用， 所以平时看的时候都把他当成一个普通的引用（相当于C语言的指针），但proc后面的代码都没有用。为什么这么做？
这里使用的copy constructor能增加引用计数。计数大于0的强指针不会自动消失。这里的关键还不在于强指针，而在于ProcessState的构造函数执行时，有很多副作用，其中之一就是打开binder设备，取得文件描述符，并为此fd做mmap，获得内存空间以存放事务数据结构。此外，ProcessState是个比较纯粹的封装，把跟进程／线程有关的内容全放这了。

第三句：sp<IServiceManager> sm =defaultServiceManager();
这句同样引入了一个强指针，指向默认的ServiceManager，同样是个单体，以后用着方便。
看一下实现：
gDefaultServiceManager =interface_cast<IServiceManager>(ProcessState::self()->getContextObject(NULL));
注意这里的interface_cast从IBinder取得IServiceManager接口。
具体怎么取得ContextObject得看binder的驱动。

第四句：LOGI("ServiceManager: %p", sm.get());
记录。这句话彻底搞明白，得看log驱动程序，此处从略。

第五句：不分析

第六 和第七句： MediaPlayerService::instantiate();
                             ResourceManagerService::instantiate();
这句话似乎是实例化MediaPlayerService，instantiate函数就一句话：
defaultServiceManager()->addService(String16("SurfaceFlinger"),new MediaPlayerService());
defaultServiceManager已经有了，到这就省点事，直接调用addService函数。
addService函数复杂一些：
virtual status_t addService(const String16& name,const sp<IBinder>&service)
 

    {
              Parcel data, reply;
              data.writeInterfaceToken(IServiceManager::getInterfaceDescriptor());
              data.writeString16(name);
              data.writeStrongBinder(service);
              status_t err =remote()->transact(ADD_SERVICE_TRANSACTION, data,&reply);
              return err == NO_ERROR ? reply.readInt32() : err;
      }
这里要做的，简单地说，就是注册MediaPlayerService服务，以使得后来的请求知道找谁了。注意addService的第二个参数接收的是个IBinder对象，这具体说得涉及到binder实现的细节。

第八句： 没有执行代码：
第九句：ProcessState::self()->startThreadPool();
这句比较奇怪。因为startThreadPool函数调用spawnPooledThread，后者调用PoolThread，后者返回一个Thread对象，接着会调用这个对象的run函数。Thread的run函数run的什么呢？
run的内容是threadLoop函数，后者就一句话：
IPCThreadState::self()->joinThreadPool(mIsMain);
此时mIsMain是true，语义是进入looper。虽说创建了一个pool，但pool里只有一个线程。程序到这里应该是进入binder事务循环了。
在do循环里，需要从binder驱动获得请求，就是ioctl的BINDER_WRITE_READ操作的结果，根据此返回数据，来执行规定动作（executeCommand调用）。后者是binder协议的目的所在，执行对用户有用的动作，这有用的动作，通过IBinder接口的transact函数。目标对象或者是注册的服务，或者是defaultServiceManager。

第十句：IPCThreadState::self()->joinThreadPool();
这句也比较奇怪。此句和第五句最终效果是一样，都是调用IPCThreadState的joinThreadPool函数，默认参数是true，同样是进入looper的意思。为什么同样的事做两遍？大概上一句是让创建的线程干活，而本句是主线程直接干活。

通过上面代码，在执行sp<ProcessState> proc(ProcessState::self());， 调用了sp的构造函数，定位到sp的类声明文件，

StrongPointer.h： system\core\include\utils

RefBase.h： system\core\include\utils

RefBase.cpp：system\core\libutils

查看sp的几个构造有几个方式，现分析上面调用的那个复制构造函数，

template<typename T>
sp<T>& sp<T>::operator =(sp<T>&& other) {
    if (m_ptr)
        m_ptr->decStrong(this);
    m_ptr = other.m_ptr;
    other.m_ptr = nullptr;
    return *this;
}




最后只调用typename 的incStrong()函数，但是查看ProcessState没有这个方法，继续查看ProcessState类，是继承RefBase，RefBase有相关方法。也就是如果一个类想使用智能指针，那么必须满足下面两个条件：

    a. 该类是虚基类RefBase的子类或间接子类
    b. 该类必须定义虚构造函数。如virtual ~MyClass();

以下博客地址：Android中的sp和wp指针

构造函数中调用了incStrong()，在析构函数中调用的decStrong()，显然是管理引用计数的函数，但是sp类的中并没有定义这两个函数，这两个函数是在RefBase类中定义的，由此可以得出结论：

RefBase的静态关系如下：

 

 

 

 其中weakref_type是RefBase的内嵌类，weakref_impl则是weakref_type的子类，RefBase的大部分工作都是交由weakref_impl类来完成，通过RefBase的成员变量weakref_impl* const mRefs。查看其中一个sp的构造函数：

 

[c-sharp] view plain copy

1. template<typename T>  
2. sp<T>::sp(T* other)  
3.     : m_ptr(other)  
4. {  
5.     if (other) other->incStrong(this);  
6. }  

 

建立sp<xxx>的动态关系如下：

sp<T>

  --> RefBase : incStrong()

  -->weakref_impl : addStrongRef()

  -->android_atomic_inc(&refs->mStrong)

 

可见当一个普通指针变成一个sp指针后，将会由RefBase类维护该指针的引用计数，当引用为零时则自动释放该指针指向的内存：

[c-sharp] view plain copy

1. void RefBase::decStrong(const void* id) const  
2. {  
3.     weakref_impl* const refs = mRefs;  
4.     refs->removeStrongRef(id);  
5.     const int32_t c = android_atomic_dec(&refs->mStrong);  
6.     if (c == 1) {  
7.         const_cast<RefBase*>(this)->onLastStrongRef(id);  
8.         if ((refs->mFlags&OBJECT_LIFETIME_WEAK) != OBJECT_LIFETIME_WEAK) {  
9.             delete this;    //引用为0，销毁  
10.         }  
11.     }  
12.     refs->removeWeakRef(id);  
13.     refs->decWeak(id);  
14. }  

 

 wp<xxx>是怎么一回事？

wp其实是弱指针的意思，wp<T>类型不能直接对类型T进行操作，要想对T进行某种操作，必需把wp升级为sp指针，使用promote()来实现升级：

        wp<T> weakp= new T();

        sp<T> t = weakp.promote();

wp可能会在弱引用计数不为0的情况下被销毁，执行如下代码：

 

[c-sharp] view plain copy

1. class WPTest : public RefBase {  
2. public:  
3.     WPTest(){  
4.         LOGD("WPTest constructor");  
5.     }  
6.     virtual ~WPTest() {  
7.         LOGD("WPTest destructor");  
8.     }  
9.   
10.     virtual void onFirstRef() {  
11.         LOGD("first weak ptr ref callback");  
12.     }  
13.   
14.     virtual void onLastStrongRef(const void* id) {  
15.         LOGD("last strong ptr ref callback");  
16.     }  
17.   
18.     virtual void onLastWeakRef(const void* id) {  
19.         LOGD("last weak ptr ref callback");  
20.     }  
21. };  
22.   
23.   
24. int main()  
25. {  
26.     WPTest *T = new WPTest();  
27.     {  
28.         wp<WPTest> weakp(T);  
29.   
30.         {  
31.             LOGD("promote to strong ptr.../n");  
32.   
33.             sp<WPTest> strongp = weakp.promote();  
34.   
35.             LOGD("strong ptr's lifetime is just about to finish .../n");  
36.         }  
37.   
38.         LOGD("weak ptr's lifetime is just about to finish .../n");  
39.     }  
40.   
41.     LOGD("weak ptr is out of scope./n");  
42.   
43.     return 0;  
44. }  

程序打印的结果是：

D/sp-wp-sample(  225): WPTest constructor
D/sp-wp-sample(  225): promote to strong ptr...
D/sp-wp-sample(  225): first weak ptr ref callback
D/sp-wp-sample(  225): strong ptr's lifetime is just about to finish ...
D/sp-wp-sample(  225): last strong ptr ref callback
D/sp-wp-sample(  225): WPTest destructor
D/sp-wp-sample(  225): weak ptr's lifetime is just about to finish ...
D/sp-wp-sample(  225): weak ptr is out of scope.

由此可见虽然wp<WPTest >的生命周期还没有结束，但是因为升级为sp<WPTest >后，sp<WPTest >的强引用计数为0，导致WPTest 被销毁，当强引用为0而弱引用不为0时，WPTest 销毁时，基类RefBase的mRefs指向的weakref_impl类并没有释放，从而保证了弱引用可以继续起作用，这点可以从RefBase的析构函数中看出来：

[c-sharp] view plain copy

1. RefBase::~RefBase()  
2. {  
3. //    LOGV("Destroying RefBase %p (refs %p)/n", this, mRefs);  
4.     if (mRefs->mWeak == 0) {  
5. //        LOGV("Freeing refs %p of old RefBase %p/n", mRefs, this);  
6.         delete mRefs;  
7.     }  
8. }  

 

不过也可以改变这一行为，我们修改一下WPTest的构造函数：

[c-sharp] view plain copy

1. WPTest(){  
2.         LOGD("WPTest constructor");  
3.         extendObjectLifetime(OBJECT_LIFETIME_WEAK);  
4.     }  

 

这时的打印结果是：

D/sp-wp-sample(  217): WPTest constructor
D/sp-wp-sample(  217): promote to strong ptr...
D/sp-wp-sample(  217): first weak ptr ref callbac
D/sp-wp-sample(  217): strong ptr's lifetime is j
D/sp-wp-sample(  217): last strong ptr ref callba
D/sp-wp-sample(  217): weak ptr's lifetime is j
D/sp-wp-sample(  217): last weak ptr ref callback
D/sp-wp-sample(  217): WPTest destructor
D/sp-wp-sample(  217): weak ptr is out of scope.

 

可以看出现在只有当强引用和弱引用的计数都为0时，WPTest对象才会被销毁。