關於android sp和wp的實現原理，網上很多介紹的。但是為何android為何要設計這兩個智慧指標？使用過程中需要注意什麼？

為何設計智慧指標

首先sp和wp是針對c++而設計的，因為Java根本就沒有指標的概念，替使用者減少了很多不必要的麻煩。在指標的使用過程中，如果處理不妥當，甚至會出現程式的崩潰：
1. 指標沒有初始化；
2. new了物件後沒有delete；
3. ptr1 和 ptr2同時指向了物件A，當釋放了ptr1，同時ptr1=NULL後，ptr2並不知道它所指向的物件不存在了。
關於物件存在多個引用的問題， android設計了兩個引用計數相關的類，LightRefBase和RefBase。我們能夠想到物件的引用計數應該是儲存在物件中的，所以我們在使用引用計數類時，只需要讓普通類去繼承LightRefBase和RefBase即可，這樣普通類產生的物件中就自然而然擁有了引用計數。
首先是LightRefBase，使用mCount作為引用計數。

template <class T>
class LightRefBase
{
    //引用計數原子+1
   inline void incStrong(__attribute__((unused)) const void* id) const {
        android_atomic_inc(&mCount);
    }
    //引用計數原子-1，當引用計數為0時，銷燬物件
    inline void decStrong(__attribute__((unused)) const void* id) const {
        if (android_atomic_dec(&mCount) == 1
 
) {
            delete static_cast<const T*>(this);
        }
    }
private:
    //引用計數
    mutable volatile int32_t mCount;
}

考慮另外一種情況，迴圈引用，父類中儲存了子類的物件，子類中儲存了父類的物件，這樣就是一個“死迴圈”，父類和子類的引用計數永遠不會為0，所以這種情況下單純使用”mCount”就解決不了這個問題，所以有了RefBase。
對RefBase，沒有使用int作為引用計數，而是使用了類weakref_impl* const mRefs;這個類中同時儲存了強引用計數和弱引用計數，也就牽扯出了sp和wp，強智慧指標和弱智慧指標。並且定義了三種普通物件的生命週期，

class RefBase::weakref_impl : public RefBase::weakref_type
{
public:
    volatile int32_t    mStrong;
    volatile int32_t    mWeak;
}

    enum {
    //物件的生命週期受強指標控制
        OBJECT_LIFETIME_STRONG  = 0x0000,
        //物件的生命週期受弱指標控制
        OBJECT_LIFETIME_WEAK    = 0x0001,
        OBJECT_LIFETIME_MASK    = 0x0001
    };

如果一個普通物件的生命週期受強指標控制，當強引用計數為0時，普通物件就可以被銷燬，但是RefBase中的mRefs物件的銷燬由弱引用計數決定。在這種情況下，父子物件可以一個使用強指標，一個使用弱指標，解決迴圈引用的問題。
同時規定：弱指標必須先升級為強指標，才能去訪問智慧指標所指向的真實物件。

使用中需要注意的問題

onFirstRef函式

在frameworks中有部分類都實現了onFirstRef函式（需要使用智慧指標的類重寫了父類RefBase的onFirstRef函式），這個非常有用，當強指標在第一次引用的時候，會去呼叫這個函式，

void RefBase::incStrong(const void* id) const
{
    weakref_impl* const refs = mRefs;
    refs->incWeak(id);

    refs->addStrongRef(id);
    const int32_t c = android_atomic_inc(&refs->mStrong);
    ALOG_ASSERT(c > 0, "incStrong() called on %p after last strong ref", refs);
#if PRINT_REFS
    ALOGD("incStrong of %p from %p: cnt=%d\n", this, id, c);
#endif
    if (c != INITIAL_STRONG_VALUE)  {
        return;
    }
    //第一次incStrong的時候，mStrong就是INITIAL_STRONG_VALUE，會呼叫refs->mBase->onFirstRef()
    android_atomic_add(-INITIAL_STRONG_VALUE, &refs->mStrong);
    refs->mBase->onFirstRef();
}

下面是SurfaceFlinger中建立Layer的例子，

status_t SurfaceFlinger::createNormalLayer(const sp<Client>& client,
        const String8& name, uint32_t w, uint32_t h, uint32_t flags, PixelFormat& format,
        sp<IBinder>* handle, sp<IGraphicBufferProducer>* gbp, sp<Layer>* outLayer)
{
    // initialize the surfaces
    switch (format) {
    case PIXEL_FORMAT_TRANSPARENT:
    case PIXEL_FORMAT_TRANSLUCENT:
        format = PIXEL_FORMAT_RGBA_8888;
        break;
    case PIXEL_FORMAT_OPAQUE:
#ifdef NO_RGBX_8888
        format = PIXEL_FORMAT_RGB_565;
#else
        format = PIXEL_FORMAT_RGBX_8888;
#endif
        break;
    }

#ifdef NO_RGBX_8888
    if (format == PIXEL_FORMAT_RGBX_8888)
        format = PIXEL_FORMAT_RGBA_8888;
#endif

    *outLayer = new Layer(this, client, name, w, h, flags);
    status_t err = (*outLayer)->setBuffers(w, h, format, flags);
    if (err == NO_ERROR) {
        *handle = (*outLayer)->getHandle();
        *gbp = (*outLayer)->getBufferQueue();
    }

    ALOGE_IF(err, "createNormalLayer() failed (%s)", strerror(-err));
    return err;
}

*outLayer = new Layer(this, client, name, w, h, flags);建立一個Layer物件，賦值給outLayer ，這時候會增加強引用計數，同時會去呼叫Layer的onFirstRef()函式。

void Layer::onFirstRef() {
    // Creates a custom BufferQueue for SurfaceFlingerConsumer to use
    mBufferQueue = new SurfaceTextureLayer(mFlinger);
    mSurfaceFlingerConsumer = new SurfaceFlingerConsumer(mBufferQueue, mTextureName);
    mSurfaceFlingerConsumer->setConsumerUsageBits(getEffectiveUsage(0));
    mSurfaceFlingerConsumer->setFrameAvailableListener(this);
    mSurfaceFlingerConsumer->setName(mName);

#ifdef TARGET_DISABLE_TRIPLE_BUFFERING
#warning "disabling triple buffering"
    mSurfaceFlingerConsumer->setDefaultMaxBufferCount(2);
#else
    mSurfaceFlingerConsumer->setDefaultMaxBufferCount(3);
#endif

    const sp<const DisplayDevice> hw(mFlinger->getDefaultDisplayDevice());
    updateTransformHint(hw);
}

wp無法操作真實物件

sp中過載了*和->運算子，返回真實物件，所以可以利用sp去操作真實物件。

    //m_ptr是真實物件的指標
    inline  T&      operator* () const  { return *m_ptr; }
    inline  T*      operator-> () const { return m_ptr;  }

對於wp中沒有過載*和->運算子，無法操作真實物件，需要先promote為強指標才能去操作。這種情況就適合於解決如果真實物件已經被delete了，還去操作指標的操作，下面是android中找的例子：
首先在ProxyConsumerListener中定義了一個wp，wp<ConsumerListener> mConsumerListener;

class ProxyConsumerListener : public BnConsumerListener {
    public:
        ProxyConsumerListener(const wp<ConsumerListener>& consumerListener);
        virtual ~ProxyConsumerListener();
        virtual void onFrameAvailable();
        virtual void onBuffersReleased();
    private:
        // mConsumerListener is a weak reference to the IConsumerListener.  This is
        // the raison d'etre of ProxyConsumerListener.
        wp<ConsumerListener> mConsumerListener;
    };

在使用時，首先對wp需要promote，返回sp後才能去操作真實物件(呼叫方法嘛)，返回為null，則說明沒有真實物件的存在。

void BufferQueue::ProxyConsumerListener::onFrameAvailable() {
    sp<ConsumerListener> listener(mConsumerListener.promote());
    if (listener != NULL) {
        listener->onFrameAvailable();
    }
}

真實物件是在哪存在的？
將sp<IConsumerListener>& consumerListener賦值給wp，這時候wp可以成功promote。

status_t BufferQueue::consumerConnect(const sp<IConsumerListener>& consumerListener,
        bool controlledByApp) {
    ST_LOGV("consumerConnect controlledByApp=%s",
            controlledByApp ? "true" : "false");
    Mutex::Autolock lock(mMutex);

    if (mAbandoned) {
        ST_LOGE("consumerConnect: BufferQueue has been abandoned!");
        return NO_INIT;
    }
    if (consumerListener == NULL) {
        ST_LOGE("consumerConnect: consumerListener may not be NULL");
        return BAD_VALUE;
    }

    mConsumerListener = consumerListener;
    mConsumerControlledByApp = controlledByApp;
    mFrameLost = 0;

    return NO_ERROR;
}