AReplyToken

1.AReplyToken源码

　　下面是安卓N版本AReplyToken源码。

struct AReplyToken : public RefBase {
    AReplyToken(const sp<ALooper> &looper)
        : mLooper(looper),
          mReplied(false) {
    }

private:
    friend struct AMessage;
    friend struct ALooper;
    wp<ALooper> mLooper;
    sp<AMessage> mReply;
    bool mReplied;

    sp<ALooper> getLooper() const {
        return mLooper.promote();
    }
    // if reply is not set, returns false; otherwise, it retrieves the reply and returns true
    bool retrieveReply(sp<AMessage> *reply) {
        if (mReplied) {
            *reply = mReply;
            mReply.clear();
        }
        return mReplied;
    }
    // sets the reply for this token. returns OK or error
    status_t setReply(const sp<AMessage> &reply);
};

　　AReplyToken有一个成员sp<　AMessage　> mReply，这个是用来存放应答消息的引用的。其中辅助判断是否被设置了应答消息的布尔变量bool mReplied，这个值在构造函数被初始化为false。
　　
　　还一个辅助使用的函数setReply，源码如下：
　　

status_t AReplyToken::setReply(const sp<AMessage> &reply) {
    if (mReplied) {
        ALOGE("trying to post a duplicate reply");
        return -EBUSY;
    }
    CHECK(mReply == NULL);
    mReply = reply;
    mReplied = true;
    return OK;
}

　　一旦通过AReplyToken::setReply函数对应答消息mReply完成设置以后就将辅助布尔变量设置为true。

　　与此向对应的还有一个AReplyToken提供的函数retrieveReply，是向外部提供的接口用来返回被设置的应答消息。源码如下：
　　

    bool retrieveReply(sp<AMessage> *reply) {
        if (mReplied) {
            *reply = mReply;
            mReply.clear();
        }
        return mReplied;
    }

　　通过上面的分析知道AReplyToken向外部提供了一个函数接口retrieveReply(sp<　AMessage> *reply)，既然是一个阻塞的消息机制，AReplyToken又是这一机制的桥梁。很显然就是等待应答消息完成设置的一方循环调用retrieveReply(sp<　AMessage> *reply)函数，直到得到应答消息的引用并返回值位true为止，当返回值位true的时候就说明通过retrieveReply函数接口得到了在AReplyToken里设置的应答消息的引用。
　　而对携带AReplyToken对象引用的AMessage消息对象进行处理的一方，需要检查是否含有AReplyToken对象的引用，如果有，就准备好应答消息，然后通过AReplyToken提供的外部接口setReply设置应答消息。

　　对于等待应答消息完成设置的一方的形式是这样的：

    while (!replyToken->retrieveReply(response)) {

    }

　　这样就循环等待，直到应答消息的到来。

2.阻塞消息发送

　　下面贴出一个例子：
　　

==>
status_t NuPlayer::getSelectedTrack(int32_t type, Parcel* reply) const {
    sp<AMessage> msg = new AMessage(kWhatGetSelectedTrack, this);
    msg->setPointer("reply", reply);
    msg->setInt32("type", type);

    sp<AMessage> response;
    status_t err = msg->postAndAwaitResponse(&response);
    if (err == OK && response != NULL) {
        CHECK(response->findInt32("err", &err));
    }
    return err;
}

==>
status_t AMessage::postAndAwaitResponse(sp<AMessage> *response) {
    sp<ALooper> looper = mLooper.promote();
    if (looper == NULL) {
        ALOGW("failed to post message as target looper for handler %d is gone.", mTarget);
        return -ENOENT;
    }

    sp<AReplyToken> token = looper->createReplyToken();
    if (token == NULL) {
        ALOGE("failed to create reply token");
        return -ENOMEM;
    }
    setObject("replyID", token);

    looper->post(this, 0 /* delayUs */);
    return looper->awaitResponse(token, response);
}

　　对于非阻塞的消息来说，也就是异步处理的消息，当消息创建好了就会调用该消息的post函数将该消息发用出去。而阻塞消息，也就是需要同步处理的消息来说，不调用post函数而是调用postAndAwaitResponse。在postAndAwaitResponse函数里间接会调用该消息对象的post函数。
　　在postAndAwaitResponse函数里将创建的AReplyToken对象的引用设置到要发送的消息里。
　　sp<　AReplyToken> token = looper->createReplyToken();创建一个AReplyToken对象，这个AReplyToken对象是实现同步消息的桥梁。setObject(“replyID”, token);将该AReplyToken对象的引用添加到该消息中。
　　
　　然后调用return looper->awaitResponse(token, response);
　　在looper->awaitResponse函数里，是作为等待应答消息完成设置的一方，循环等待，直到获取到应答消息为止。

3.当前进程循环等待应答消息

==>
return looper->awaitResponse(token, response);

==>
status_t ALooper::awaitResponse(const sp<AReplyToken> &replyToken, sp<AMessage> *response) {
    // return status in case we want to handle an interrupted wait
    Mutex::Autolock autoLock(mRepliesLock);
    CHECK(replyToken != NULL);
    while (!replyToken->retrieveReply(response)) {
        {
            Mutex::Autolock autoLock(mLock);
            if (mThread == NULL) {
                return -ENOENT;
            }
        }
        mRepliesCondition.wait(mRepliesLock);
    }
    return OK;
}

　　循环等待应答消息直到成功获取到应答消息的引用，应答消息的引用由sp<　AMessage> *response传回。

4.阻塞消息处理

　　下面贴出应对上一个例子的处理：
　　

        case kWhatGetSelectedTrack:
        {
            status_t err = INVALID_OPERATION;
            if (mSource != NULL) {
                err = OK;

                int32_t type32;
                CHECK(msg->findInt32("type", (int32_t*)&type32));
                media_track_type type = (media_track_type)type32;
                ssize_t selectedTrack = mSource->getSelectedTrack(type);

                Parcel* reply;
                CHECK(msg->findPointer("reply", (void**)&reply));
                reply->writeInt32(selectedTrack);
            }

            sp<AMessage> response = new AMessage;
            response->setInt32("err", err);

            sp<AReplyToken> replyID;
            CHECK(msg->senderAwaitsResponse(&replyID));
            response->postReply(replyID);
            break;
        }

　　首先准备好我们要回应的消息：
　　

    sp<AMessage> response = new AMessage;
    response->setInt32("err", err);

　　然后从消息中获取到阻塞消息处理的桥梁AReplyToken对象，是通过消息对象msg的senderAwaitsResponse(&replyID)函数来完成的：
　　

==>
     sp<AReplyToken> replyID;
     CHECK(msg->senderAwaitsResponse(&replyID));

==>
bool AMessage::senderAwaitsResponse(sp<AReplyToken> *replyToken) {
    sp<RefBase> tmp;
    bool found = findObject("replyID", &tmp);

    if (!found) {
        return false;
    }

    *replyToken = static_cast<AReplyToken *>(tmp.get());
    tmp.clear();
    setObject("replyID", tmp);
    // TODO: delete Object instead of setting it to NULL

    return *replyToken != NULL;
}

==>
    bool found = findObject("replyID", &tmp);

==>
    setObject("replyID", tmp);

　　获取到AReplyToken对象的引用后，调用准好的应答消息对象提供的外部函数postReply来完成应答消息的设置。
　　源码如下：
　　

==>
response->postReply(replyID);

==>
status_t AMessage::postReply(const sp<AReplyToken> &replyToken) {
    if (replyToken == NULL) {
        ALOGW("failed to post reply to a NULL token");
        return -ENOENT;
    }
    sp<ALooper> looper = replyToken->getLooper();
    if (looper == NULL) {
        ALOGW("failed to post reply as target looper is gone.");
        return -ENOENT;
    }
    return looper->postReply(replyToken, this);
}

==>
status_t ALooper::postReply(const sp<AReplyToken> &replyToken, const sp<AMessage> &reply) {
    Mutex::Autolock autoLock(mRepliesLock);
    status_t err = replyToken->setReply(reply);
    if (err == OK) {
        mRepliesCondition.broadcast();
    }
    return err;
}

==>
status_t AReplyToken::setReply(const sp<AMessage> &reply) {
    if (mReplied) {
        ALOGE("trying to post a duplicate reply");
        return -EBUSY;
    }
    CHECK(mReply == NULL);
    mReply = reply;
    mReplied = true;
    return OK;
}

　　通过调用AReplyToken对象的getLooper()函数得到的是AReplyToken对象含有的ALooper对象的引用，这个引用是在阻塞消息调用postAndAwaitResponse时，该阻塞消息含有的ALooper对象的引用调用createReplyToken传递给AReplyToken构造函数的，也就是说，阻塞消息对象和对应的AReplyToken对象同时都拥有ALooper对象的引用。

　　小结：
　　循环等待应答消息一方：
　　1.创建好阻塞消息msg。
　　2.调用阻塞消息msg的postAndAwaitResponse函数。
　　3.在msg的postAndAwaitResponse函数里调用该消息msg的成员变量mLooper的createReplyToken函数创建AReplyToken对象。
　　4.将创建好的AReplyToken对象的引用添加到msg消息里。
　　5.调用该消息msg的成员变量mLooper的post函数将携带有AReplyToken对象引用的消息发送出去。
　　6.调用消息msg的成员变量mLooper的awaitResponse函数循环等待应答消息成功被设置。

　　处理阻塞消息msg的一方：
　　1.创建好应答消息response。
　　2.调用消息msg的enderAwaitsResponseALooper函数用于得到阻塞消息含有的AReplyToken对象的引用。
　　3.调用应答消息response的postReply(const sp<　AReplyToken> &replyToken, const sp<　AMessage> &reply)函数完成后续的应答消息的设置。

　　其实总得来说阻塞消息设计并不复杂，设计的原理是生产者－消费者关系。消费者循环等待直到生产者生产出了自己需要的产品。中间的BUFFER，在这里是AReplyToken对象。对于安卓N版本阻塞消息处理机制设计繁琐，不够清晰，希望在后续的版本能够完善设计。让阻塞消息机制的设计看起来更加自然，使用起来也更加便捷。