Android消息机制Looper与VSync的传播

#1 主要内容

本文主要简单记录在native层Looper消息机制的相关内容，主要着手于下面几个问题：
（1）消息机制的原理；
（2）VSync是如何借助消息机制进行传播的；

2 Android消息机制

2.1 应用进程的创建

说起Android的消息机制，先大致的理一下Android应用的运行机制，Android上层是基于消息机制的，首先考虑一个问题，描述如下：Android应用作为运行在Linux平台上的用户进程，是如何保持一致处于运行状态的？也就是如何做到主线程不结束，进程一直存在的？
要想搞清楚这个问题，首先得搞清楚Android应用进程是如何创建的，比如我们点击桌面上的icon，应用进程启动了，然后界面出现了，只要不退出，界面一直存在，这整个的过程是怎么样的呢？下面分几个步骤来说明这个问题：
（1）桌面Launcher应用也是一个Android应用，点击图标启动进程；
（2）ActivityManagerService接收到Activity的启动请求，发现需要启动的Activity所在的进程当前尚未运行，首先需要启动进程；
（3）进程启动后，Activity随之被启动，进入主线程的消息循环，保持“不死状态”；
本文主要讨论消息机制，为保持主题清晰，只对上述问题简单描述：

(网上某位大神画的图，因为是之前下载的，现在找不到作者了，引用一下，说明问题，切莫见怪)

上面的图画的很清楚：
（1）桌面Launcher应用收到点击事件，通过Binder IPC通信调用AMS中的startActivity；
（2）AMS首先调用Process.start()方法，从Zygote进程Fork出一个进程，并将ActivityThread.main函数作为主线程的入口，开始执行；
（3）应用进程启动后，会在ActivityThread.main函数中调用attach函数，该函数会远程调用AMS.attachApplication函数，向AMS注册当前的进程，然后AMS会远程调用应用的ActivityThread.bindApplication函数，创建一些关键的数据结构，后面AMS接收到Idle消息后，经由Binder向应用进程发送LAUNCH_ACTIVITY远程调用，从而开始启动Activity。
上面的最下面的部分，就是应用一直保持运行状态的原因，应用进程主线程里面创建了一个Looper循环，一直在等待消息，没有消息的时候线程会被阻塞住，从而保证主线程一直处于活跃状态。

这个图是Android应用启动后，整个的进程结构，里面包含了上面的图中没有包含的有关Android系统进程的相关内容，有兴趣的可以再研究一下。

2.2 Android消息机制

网上有很多资料，对于Android消息机制已经讲的很清楚，这里就不详细的介绍了，推荐老罗的 http://blog.csdn.net/luoshengyang/article/details/6817933 ，这里简单介绍一下Handler、Looper以及MessageQueue之间的关系，看一下图：

分两种情况来说明整个过程：
情形（1）：应用线程中的MessageQueue中没有消息，线程处于阻塞状态；
情形（2）：应用线程中MessageQueue中有消息，线程处于运行状态；

2.2.1 线程阻塞

线程阻塞的时候，会停止在MessageQueue.next函数中的nativePollOnce里面，超时时间设置成了-1，假设当前线程代号线程A，这时候只能由别的线程(比如线程B)向线程A的MessageQueue中enqueueMessage，看一下这个函数：

boolean enqueueMessage(Message msg, longwhen) {
            Message p = mMessages;
            boolean needWake;
            if (p == null || when == 0 || when < p.when) {
                // New head, wake up the event queue if blocked.
                msg.next = p;
                mMessages = msg;
                needWake = mBlocked;
            } else {
                needWake = mBlocked && p.target == null && msg.isAsynchronous();
                Message prev;
                for (;;) {
                    prev = p;
                    p = p.next;
                    if (p == null || when < p.when) {
                        break;
                    }
                    if (needWake && p.isAsynchronous()) {
                        needWake = false;
                    }
                }
                msg.next = p; // invariant: p == prev.next
                prev.next = msg;
            } 
            if (needWake) {
                nativeWake(mPtr);    //唤醒处于阻塞状态的mPtr所对应的线程
            }
        }
        return true;
    }

如果当前线程处于阻塞状态，会调用到nativeWake函数，该函数会向native层的MessageQueue、Looper对应的pipe管道中写入一个W字符，epoll机制在监听pipe管道读事件的时候收到数据会从上述阻塞的nativePollOnce函数里面返回，返回到java层以后发现MessageQueue里面有未处理的消息，就可以接着处理了。

2.2.2 线程正在运行

一开始以为，如果线程处于运行状态，应该一直处理MessageQueue中的消息，直到全部都处理完，没有消息以后进入阻塞状态，整个的流程应该不会和native层有任何的关系，但是实际上代码不是这样实现的，线程在处理每一个消息的时候，都会执行native函数nativePollOnce，如果当前MessageQueue里面有消息，会将epoll的超时时间设置为0，epoll会立马返回，这时候就可以从nativePollOnce里面返回处理下一个消息，但是像上面的MessageQueue里面没有消息后nativePollOnce在执行的时候，超时时间标记被设置成了-1，在进入epoll之前会用一个很大的时间值来替代-1，从而让epoll机制无法返回，达到阻塞线程的目的。
说明：这个部分，老罗的博客上将的很清楚，实在不想也没有必要去细写了。

3 应用请求VSync同步信号

应用在请求重绘的时候会请求同步信号，而且是重绘一次，请求一次，不重绘的时候是不请求的，也就是正常情况下，若应用的界面不请求重绘，应用是接收不到VSync信号的。应用要想请求同步信号，可以借助Choreographer对象来实现，Choreographer的英文含义是“编舞”，是用来控制节奏的，名字起得确实挺生动的。
看一下Choreographer的定义，该类包含一个FrameDisplayEventReceiver对象，看一下代码：

 //Choreographer.java
   private final class FrameDisplayEventReceiver extends DisplayEventReceiver implements Runnable {
        private boolean mHavePendingVsync;
        private long mTimestampNanos;
        private int mFrame;

        public FrameDisplayEventReceiver(Looper looper) {
            super(looper);
        }

        @Override
        publicvoid onVsync(long timestampNanos, int builtInDisplayId, int frame) {
            .............
            mTimestampNanos = timestampNanos;
            mFrame = frame;
            Messagemsg = Message.obtain(mHandler, this);
            msg.setAsynchronous(true);
            mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
        }

        @Override
        publicvoid run() {
            mHavePendingVsync = false;
            doFrame(mTimestampNanos, mFrame);
        }
    }

FrameDisplayEventReceiver这个类比较简单，主要的工作都在基类DisplayEventReceiver里面完成了，DisplayEventReceiver类里面有两个比较重要的函数，一个是构造器，还有一个就是scheduleVsync函数：

//DisplayEventReceiver.java
public abstract class DisplayEventReceiver {
    private final CloseGuard mCloseGuard = CloseGuard.get(); 
    private long mReceiverPtr; 
    // We keep a reference message queue object here so that it is not
    // GC'd while the native peer of the receiver is using them.
    private MessageQueue mMessageQueue; 
    /**
     * Creates a display event receiver.
     * @param looper The looper to use when invoking callbacks.
     */
    public DisplayEventReceiver(Looper looper) {
        if (looper == null) {
            thrownew IllegalArgumentException("looper must not be null");
        } 
        mMessageQueue = looper.getQueue();
        mReceiverPtr = nativeInit(this, mMessageQueue); 
        mCloseGuard.open("dispose");
    }
    /**
     * Schedules a single vertical sync pulse to be delivered when the next
     * display frame begins.
     */
    public void scheduleVsync() {
        if (mReceiverPtr == 0) {
            Log.w(TAG, "Attempted to schedule a vertical sync pulse but the display event "
                    + "receiver has already been disposed.");
        } else {
            nativeScheduleVsync(mReceiverPtr);
        }
    }
}

该类是一个abstract类，构造器里面调用了nativeInit函数，当应用需要同步信号的时候，最终会调用到scheduleVsync函数，里面调用到了nativeScheduleVsync函数，这两个函数步骤比较多，下面分别来分析。

3.1 nativeInit

函数定义在android_view_DisplayEventReceiver.cpp里面：

static jlong nativeInit(JNIEnv* env, jclass clazz, jobject receiverObj, jobject messageQueueObj) {
    sp messageQueue = android_os_MessageQueue_getMessageQueue(env, messageQueueObj);
    if (messageQueue == NULL) {
        jniThrowRuntimeException(env, "MessageQueue is not initialized.");
        return 0;
    }
    sp receiver = new NativeDisplayEventReceiver(env, receiverObj, messageQueue);
    status_t status = receiver->initialize();
    if (status) {
        String8 message;
        message.appendFormat("Failed to initialize display event receiver.  status=%d", status);
        jniThrowRuntimeException(env, message.string());
        return 0;
    } 
    receiver->incStrong(gDisplayEventReceiverClassInfo.clazz); // retain a reference for the object
    returnreinterpret_cast(receiver.get());
}

（1）获取与当前应用主线程相关联的native层的MessageQueue对象；
（2）创建一个NativeDisplayEventReceiver对象；
（3）调用NativeDisplayEventReceiver.initialize函数;
下面逐个分析上面的2、3两个步骤。

3.1.1 NativeDisplayEventReceiver

该类定义在android_view_DisplayEventReceiver.cpp文件中，看一下定义：

class NativeDisplayEventReceiver : public LooperCallback {
public:
    NativeDisplayEventReceiver(JNIEnv* env, jobject receiverObj, const sp& messageQueue);
    status_t initialize();
    void dispose();
    status_t scheduleVsync();
protected:
    virtual ~NativeDisplayEventReceiver(); 
private:
    jobject mReceiverObjGlobal;
    sp mMessageQueue;
    DisplayEventReceiver mReceiver;
    bool mWaitingForVsync;

    virtual int handleEvent(int receiveFd, int events, void* data);
    bool processPendingEvents(nsecs_t* outTimestamp, int32_t* id, uint32_t* outCount);
    void dispatchVsync(nsecs_t timestamp, int32_t id, uint32_t count);
    void dispatchHotplug(nsecs_t timestamp, int32_t id, bool connected);
};

该类包含一个DisplayEventReceiver成员变量，在创建NativeDisplayEventReceiver对象时会创建DisplayEventReceiver对象，看一下DisplayEventReceiver对象的构造函数：

//DisplayEventReceiver.cpp
DisplayEventReceiver::DisplayEventReceiver() {
    sp<ISurfaceComposer> sf(ComposerService::getComposerService());
    if (sf != NULL) {
        mEventConnection = sf->createDisplayEventConnection();
        if (mEventConnection != NULL) {
            mDataChannel = mEventConnection->getDataChannel();
        }
    }
}

上面几行代码是应用进程与SurfaceFlinger进程通信的连接建立的关键函数。逐个函数进行分析，先看ComposerService::getComposerService()：

// Get a connection to the Composer Service.  This will block until
// a connection is established. 
//注释很重要  这是一个static方法获取单例模式下的BpSurfaceComposer(new BpBinder(handle))对象
/*static*/ sp<ISurfaceComposer> ComposerService::getComposerService() {
    ComposerService& instance = ComposerService::getInstance();
    Mutex::Autolock _l(instance.mLock);
    if (instance.mComposerService == NULL) { 
       //------------------重要---------------------------
        ComposerService::getInstance().connectLocked(); 
        assert(instance.mComposerService != NULL);
        ALOGD("ComposerService reconnected");
    }
    return instance.mComposerService;
}

该函数是一个static函数，ComposerService是一个单例模式，想到单例就应该想到是进程内唯一，首先创建对象ComposerService，然后调用该对象的connectLocked()函数：

void ComposerService::connectLocked() {
    const String16 name("SurfaceFlinger"); 
    /*
    (1) sp mComposerService;
    这里getService将mComposerService实例化成一个BpSurfaceComposer对象,定义在ISurfaceComposer.cpp中
    其中这里的BpSurfaceComposer已经获得了SurfaceFlinger的service的在binder驱动中的handle值
    mComposerService是一个 BpSurfaceComposer(new BpBinder(handle))对象 
    (2) 这里的getService作用很明显，是从ServiceManager进程中查找"SurfaceFlinger"的Binder对应的handle值，
    返回的out型参数mComposerService对应的就是"SurfaceFlinger" binder 服务端的客户端Binder对象，通过这个
    mComposerService就可以和"SurfaceFlinger"进行通信
    */
    while (getService(name, &mComposerService) != NO_ERROR) {
        usleep(250000);
    }
    assert(mComposerService != NULL);

    // Create the death listener.
    classDeathObserver : public IBinder::DeathRecipient {
        ComposerService& mComposerService;
        virtualvoidbinderDied(const wp& who) {
            ALOGW("ComposerService remote (surfaceflinger) died [%p]",
                  who.unsafe_get());
            mComposerService.composerServiceDied();
        }
     public:
        DeathObserver(ComposerService& mgr) : mComposerService(mgr) { }
    };

    mDeathObserver = new DeathObserver(*const_cast(this));
    IInterface::asBinder(mComposerService)->linkToDeath(mDeathObserver);
}

上面调用了getService函数，该函数是一个模板函数，因此定义在头文件IServiceManager.h里面:

template
status_t getService(const String16& name, sp* outService)
{
    const sp sm = defaultServiceManager();
    if (sm != NULL) {
        *outService = interface_cast(sm->getService(name));
        if ((*outService) != NULL) return NO_ERROR;
    }
    return NAME_NOT_FOUND;
}

1 defaultServiceManager返回的进程范围内唯一的BpServiceManager,相当于是 sm = new BpServiceManager(new BpBinder(0));
2 sm->getService(name): 会调用BpServiceManager中的getService函数，经过binder驱动程序和service_manager守护进程进行通信，得到service名称为name的service的handle值,返回的是一个BpBinder(handle)
3 interface_cast(new BpBinder(handle))会创建一个BpINTERFACE对象，
sm返回的是一个BpServiceManager对象，该对象是一个Binder的客户端，也就是Service_Manager服务守护进程的Bp客户端，相当于是BpServiceManager(new BpBinder(0))，根据前面的服务名称”SurfaceFlinger”，最终outService返回的是一个BpSurfaceComposer对象，再看一下SurfaceFlinger的声明：

class SurfaceFlinger : public BnSurfaceComposer,
                       private IBinder::DeathRecipient,
                       private HWComposer::EventHandler{.....}

根据上面的分析可知，ComposerService::getComposerService()返回的是一个与SurfaceFlinger进程建立Binder进程通信的客户端，服务端就SurfaceFlinger对象本身，接下来看DisplayEventReceiver构造函数中的：

 mEventConnection = sf->createDisplayEventConnection(); //BpSurfaceComposer->createDisplayEventConnection()

该函数定义在ISurfaceComposer.cpp文件中：

    virtual sp<IDisplayEventConnection> createDisplayEventConnection()
    {
        Parcel data, reply;
        sp<IDisplayEventConnection> result;
        int err = data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());
        if (err != NO_ERROR) {
            return result;
        }
        err = remote()->transact(BnSurfaceComposer::CREATE_DISPLAY_EVENT_CONNECTION, data, &reply);
        if (err != NO_ERROR) {
            ALOGE("ISurfaceComposer::createDisplayEventConnection: error performing "
                    "transaction: %s (%d)", strerror(-err), -err);
            return result;
        }
        result = interface_cast<IDisplayEventConnection>(reply.readStrongBinder());
        return result;
    }

该函数经由BnSurfaceComposer.onTransact函数辗转调用到SurfaceFlinger.createDisplayEventConnection函数：

sp<IDisplayEventConnection> SurfaceFlinger::createDisplayEventConnection() {
    return mEventThread->createEventConnection();
}

出现了熟悉的面孔mEventThread，该对象是一个EventThread对象，该对象在SurfaceFlinger.init函数里面创建，但是创建运行以后，貌似还没有进行任何的动作，这里调用createEventConnection函数：

sp EventThread::createEventConnection() const {
    return new Connection(const_cast(this));
}

有创建了一个EventThread::Connection对象，前面分析到，Connection的构造函数会创建一个BitTube对象，BitTube对象中包含一对互联的socket，一端发送另一端就能收到。并将BitTube对象存储在EventThread::Connection.mChannel里面。返回到上面DisplayEventReceiver构造函数中的mEventConnection是一个BpDisplayEventConnection对象，看一下EventThread::Connection的定义可以知道Connection是一个BnDisplayEventConnection对象，又是一对Binder客户端和服务器，接下来再看mEventConnection->getDataChannel()函数，该函数调用链：
（1）BpDisplayEventConnection.getDataChannel() //DisplayEventConnection.cpp
（2）BnDisplayEventConnection.onTransact //DisplayEventConnection.cpp
（3）EventThread::Connection.getDataChannel() //EventThread.cpp
先看BnDisplayEventConnection.onTransact函数，该函数先调用Connection.getDataChannel()函数返回前面创建的BitTube对象：

status_t BnDisplayEventConnection::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    switch(code) {
        case GET_DATA_CHANNEL: {
            CHECK_INTERFACE(IDisplayEventConnection, data, reply);
            sp<BitTube> channel(getDataChannel());

            channel->writeToParcel(reply);
            return NO_ERROR;
        }
    }
    return BBinder::onTransact(code, data, reply, flags);
}

上面的channel是一个指向BitTube对象的指针，值得注意的是后面调用了BitTube.writeToParcel函数：

status_t BitTube::writeToParcel(Parcel* reply) const
{    if (mReceiveFd < 0)return -EINVAL; 
    status_t result = reply->writeDupFileDescriptor(mReceiveFd);
    close(mReceiveFd);
    mReceiveFd = -1;
    return result;
}

这里将前面创建BitTube对象时建立的互联的socket的mReceiveFd接收端的描述符传递给了对应的Binder客户端，也就是步骤(1)中的BpDisplayEventConnection中，同时关闭了Binder服务端的接收端描述符，也就是对应的Bn服务端只负责往Connection的socket中写入数据，客户端负责接收数据，在继续看BpDisplayEventConnection.getDataChannel函数之前，先理一下思路：
（1）应用程序创建了一个Choreographer对象；
（2）Choreographer对象创建了一个FrameDisplayEventReceiver对象，该类继承了DisplayEventReceiver类；
（3）创建DisplayEventReceiver对象的过程中，调用nativeInit函数，创建了native层对象NativeDisplayEventReceiver；
（4）NativeDisplayEventReceiver对象的成员变量mReceiver是一个DisplayEventReceiver对象；
（5）在创建DisplayEventReceiver对象的过程中，通过Service_Manager进程建立了与SurfaceFlinger进程之间的连接，
（6）通过SurfaceFlinger的mEventThread在SurfaceFlinger进程中创建了EventThread::Connection对象，该对象创建了一个BitTube对象，该对象包含一对互联的socket，并返回了Binder客户端BpDisplayEventConnection对象；
（7）经由返回的BpDisplayEventConnection对象，获取步骤6中创建的SurfaceFlinger服务端对象EventThread::Connection中BitTube对象的接收端socket描述符；
接下来看一下对应的BpDisplayEventConnection.getDataChannel函数：

    virtual sp<BitTube> getDataChannel() const {
        Parcel data, reply;
        data.writeInterfaceToken(IDisplayEventConnection::getInterfaceDescriptor());
        remote()->transact(GET_DATA_CHANNEL, data, &reply);
        returnnew BitTube(reply);
    }

该函数调用了BpDisplayEventConnection客户端的transact函数，最终根据返回的Parcel数据创建了一个客户端的BitTube对象，看一下BitTube的对应的构造函数：

BitTube::BitTube(const Parcel& data) : mSendFd(-1), mReceiveFd(-1){
    mReceiveFd = dup(data.readFileDescriptor());
}

该构造函数从Parcel中读取前面在SurfaceFlinger进程中写入的socket接收端的描述符。
到这里native层的NativeDisplayEventReceiver对象已经创建结束，这时候客户端进程已经有了一个和SurfaceFlinger服务端相连的socket接收端描述符。

3.1.2 NativeDisplayEventReceiver.initialize

直接看代码：

status_t NativeDisplayEventReceiver::initialize() {
    status_t result = mReceiver.initCheck();
    if (result) {
        ALOGW("Failed to initialize display event receiver, status=%d", result);
        return result;
    }
    int rc = mMessageQueue->getLooper()->addFd(mReceiver.getFd(), 0, Looper::EVENT_INPUT, this, NULL);
    if (rc < 0) {
        return UNKNOWN_ERROR;
    }
    return OK;
}

这里的主要代码是mMessageQueue->getLooper()->addFd()这一行，其中的参数mReceiver.getFd()返回的是在创建NativeDisplayEventReceiver时从SurfaceFlinger服务端接收回来的socket接收端描述符，前面分析到
mMessageQueue是与当前应用线程关联的java层的MessageQueue对应的native层的MessageQueue对象，下面看一下Looper.addFd这个函数，上面调用时传进来的this指针对应的是一个NativeDisplayEventReceiver对象，该类继承了LooperCallback：

int Looper::addFd(int fd, int ident, int events, Looper_callbackFunc callback, void* data) {
    return addFd(fd, ident, events, callback ? new SimpleLooperCallback(callback) : NULL, data);
}
int Looper::addFd(int fd, int ident, int events, const sp& callback, void* data) { 
    int epollEvents = 0;
    if (events & EVENT_INPUT) epollEvents |= EPOLLIN;
    if (events & EVENT_OUTPUT) epollEvents |= EPOLLOUT;

    { // acquire lock
        AutoMutex _l(mLock);

        Request request;
        request.fd = fd;
        request.ident = ident;
        request.callback = callback;
        request.data = data;

        struct epoll_event eventItem;
        memset(& eventItem, 0, sizeof(epoll_event)); // zero out unused members of data field union
        eventItem.events = epollEvents;
        eventItem.data.fd = fd;

        ssize_t requestIndex = mRequests.indexOfKey(fd);
        if (requestIndex < 0) {
            int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, fd, & eventItem);
            if (epollResult < 0) {
            }
            mRequests.add(fd, request);
        } else {
            int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_MOD, fd, & eventItem);
            if (epollResult < 0) {
                return -1;
            }
            mRequests.replaceValueAt(requestIndex, request);
        }
    } // release lock
    return 1;
}

首先将上面传进来的NativeDisplayEventReceiver对象封装成一个SimpleLooperCallback对象，调用下面的addFd函数的时候主要步骤如下：
（1）创建一个struct epoll_event结构体对象，将对应的内存全部用清0，并作对应的初始化；
（2）查询通过addFd方法已经添加到epoll中监听的文件描述符；
（3）查询不到的话，则调用epoll_ctl方法设置EPOLL_CTL_ADD属性将对应的文件描述符添加到epoll监听的描述符中；
（4）根据前面addFd传入的参数EVENT_INPUT，说明当前应用线程的native层的Looper对象中的epoll机制已经开始监听来自于SurfaceFlinger服务端socket端的写入事件。
分析到这里，大概可以猜测，SurfaceFlinger端的垂直同步信号分发到客户端进程应该适合当前的这个socket又密切的关系。

3.2 nativeScheduleVsync

该函数经由下面的调用路径调用到：
（1）Choreographer.scheduleVsyncLocked
（2）NativeDisplayEventReceiver.scheduleVsync —-> DisplayEventReceiver.scheduleVsync
看一下nativeScheduleVsync函数，该函数定义在android_view_DisplayEventReceiver.cpp文件中：

static void nativeScheduleVsync(JNIEnv* env, jclass clazz, jlong receiverPtr) {
    sp receiver = reinterpret_cast(receiverPtr);
    status_t status = receiver->scheduleVsync();
    if (status) {
        String8 message;
        message.appendFormat("Failed to schedule next vertical sync pulse.  status=%d", status);
        jniThrowRuntimeException(env, message.string());
    }
}

首先根据java层传进来的native层NativeDisplayEventReceiver对象的指针，该native对象就是前面在调用nativeInit函数时创建的对象，看函数的名称，应该是java层想要请求同步信号，这里面就有一个问题：同步信号是周期性的，那么应用请求同步信号是只请求一次呢？还是多次？
调用到NativeDisplayEventReceiver::scheduleVsync函数：

status_t NativeDisplayEventReceiver::scheduleVsync() {
    if (!mWaitingForVsync) {
        ALOGV("receiver %p ~ Scheduling vsync.", this);
        // Drain all pending events.
        nsecs_t vsyncTimestamp;
        int32_t vsyncDisplayId;
        uint32_t vsyncCount;
        processPendingEvents(&vsyncTimestamp, &vsyncDisplayId, &vsyncCount);
        status_t status = mReceiver.requestNextVsync();
        if (status) {
            ALOGW("Failed to request next vsync, status=%d", status);
            return status;
        } 
        mWaitingForVsync = true;
    }
    return OK;
}

先跳过这里的processPendingEvents函数，后面再分析，先分析DisplayEventReceiver.requestNextVsync函数：

status_t DisplayEventReceiver::requestNextVsync() {
    if (mEventConnection != NULL) {
        mEventConnection->requestNextVsync();
        return NO_ERROR;
    }
    return NO_INIT;
}

这里的mEventConnection也是前面创建native层对象NativeDisplayEventReceiver时创建的，实际对象是一个BpDisplayEventConnection对象，也就是一个Binder客户端，对应的Binder服务端BnDisplayEventConnection是一个EventThread::Connection对象，对应的BpDisplayEventConnection.requestNextVsync函数和BnDisplayEventConnection.onTransact(REQUEST_NEXT_VSYNC)函数没有进行特别的处理，下面就调用到EventThread::Connection.requestNextVsync函数，从BnDisplayEventConnection.onTransact(REQUEST_NEXT_VSYNC)开始已经从用户进程将需要垂直同步信号的请求发送到了SurfaceFlinger进程，下面的函数调用开始进入SF进程：

void EventThread::Connection::requestNextVsync() {
    mEventThread->requestNextVsync(this);
}

辗转调用到EventThread.requestNextVsync函数，注意里面传了参数this，也就是当前的EventThread::Connection对象，需要明确的是，这里的mEventThread对象是创建EventThread::Connection对象的时候保存的，对应的是SurfaceFlinger对象的里面的mEventThread成员，该对象是一个在SurfaceFlinger.init里面创建并启动的线程对象，可见设计的时候就专门用这个SurfaceFlinger.mEventThread线程来接收来自应用进程的同步信号请求，每来一个应用进程同步信号请求，就通过SurfaceFlinger.mEventThread创建一个EventThread::Connection对象，并通过EventThread.registerDisplayEventConnection函数将创建的EventThread::Connection对象保存到EventThread.mDisplayEventConnections里面，上面有调用到了EventThread.requestNextVsync函数：

void EventThread::requestNextVsync(const sp<EventThread::Connection>& connection) {
    Mutex::Autolock _l(mLock);
    if (connection->count < 0) {
        connection->count = 0;
        mCondition.broadcast();
    }
}

传进来的是一个前面创建的EventThread::Connection对象，里面判断到了EventThread::Connection.count成员变量，看一下EventThread::Connection构造函数中初始变量的值：

EventThread::Connection::Connection(const sp<EventThread>& eventThread)
    : count(-1), mEventThread(eventThread), mChannel(new BitTube()){
}

可以看到初始值是-1，这个值就是前面那个问题的关键，EventThread::Connection.count标示了这次应用进程的垂直同步信号的请求是一次性的，还是多次重复的，看一下注释里面对于这个变量的说明：

        // count >= 1 : continuous event. count is the vsync rate
        // count == 0 : one-shot event that has not fired
        // count ==-1 : one-shot event that fired this round / disabled
        int32_t count;

很清楚的说明了，count = 0说明当前的垂直同步信号请求是一个一次性的请求，并且还没有被处理。上面EventThread::requestNextVsync里面将count设置成0，同时调用了mCondition.broadcast()唤醒所有正在等待mCondition的线程，这个会触发EventThread.waitForEvent函数从：

    mCondition.wait(mLock);

中醒来，醒来之后经过一轮do…while循环就会返回，返回以后调用序列如下：
（1）EventThread::Connection.postEvent(event)
（2）DisplayEventReceiver::sendEvents(mChannel, &event, 1)，mChannel参数就是前面创建DisplayEventReceiver是创建的BitTube对象
（3）BitTube::sendObjects(dataChannel, events, count)，static函数，通过dataChannel指向BitTube对象
最终调用到BitTube::sendObjects函数：

ssize_t BitTube::sendObjects(const sp& tube, void const* events, size_t count, size_t objSize){
    const char* vaddr = reinterpret_cast<const char*>(events);
    ssize_t size = tube->write(vaddr, count*objSize);
    return size < 0 ? size : size / static_cast(objSize);
}

继续调用到BitTube::write函数：

ssize_t BitTube::write(void const* vaddr, size_t size){
    ssize_t err, len;
    do {
        len = ::send(mSendFd, vaddr, size, MSG_DONTWAIT | MSG_NOSIGNAL);
        // cannot return less than size, since we're using SOCK_SEQPACKET
        err = len < 0 ? errno : 0;
    } while (err == EINTR);
    return err == 0 ? len : -err;
}

这里调用到了::send函数，::是作用域描述符，如果前面没有类名之类的，代表的就是全局的作用域，也就是调用全局函数send，这里很容易就能想到这是一个socket的写入函数，也就是将event事件数据写入到BitTube中互联的socket中，这样在另一端马上就能收到写入的数据，前面分析到这个BitTube的socket的两端连接着SurfaceFlinger进程和应用进程，也就是说通过调用BitTube::write函数，将最初由SurfaceFlinger捕获到的垂直信号事件经由BitTube中互联的socket从SurfaceFlinger进程发送到了应用进程中BitTube的socket接收端。
下面就要分析应用进程是如何接收并使用这个垂直同步信号事件的。

3.3 应用进程接收VSync

3.3.1 解析VSync事件

VSync同步信号事件已经发送到用户进程中的socket接收端，在上面（3.1.2）NativeDisplayEventReceiver.initialize中分析到应用进程端的socket接收描述符已经被添加到Choreographer所在线程的native层的Looper机制中，在epoll中监听EPOLLIN事件，当socket收到数据后，epoll会马上返回，下面分步骤看一下Looper.pollInner函数：
（1）epoll_wait

    struct epoll_event eventItems[EPOLL_MAX_EVENTS];
    int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);

在监听到描述符对应的事件后，epoll_wait会马上返回，并将产生的具体事件类型写入到参数eventItems里面，最终返回的eventCount是监听到的事件的个数
（2）事件分析

    for (int i = 0; i < eventCount; i++) {
        int fd = eventItems[i].data.fd;
        uint32_t epollEvents = eventItems[i].events;
        if (fd == mWakeReadPipeFd) {   //判断是不是pipe读管道的事件   这里如果是EventThread,这里就是一个socket的描述符,而不是mWakeReadPipeFd
            if (epollEvents & EPOLLIN) {
                awoken(); // 清空读管道中的数据
            } else {
                ALOGW("Ignoring unexpected epoll events 0x%x on wake read pipe.", epollEvents);
            }
        } else {
           //EventThread接收到同步信号走的这里
            ssize_t requestIndex = mRequests.indexOfKey(fd);
            if (requestIndex >= 0) {
                int events = 0;
                if (epollEvents & EPOLLIN) events |= EVENT_INPUT;
                if (epollEvents & EPOLLOUT) events |= EVENT_OUTPUT;
                if (epollEvents & EPOLLERR) events |= EVENT_ERROR;
                if (epollEvents & EPOLLHUP) events |= EVENT_HANGUP;
                pushResponse(events, mRequests.valueAt(requestIndex));
            } else {
                ALOGW("Ignoring unexpected epoll events 0x%x on fd %d that is "
                        "no longer registered.", epollEvents, fd);
            }
        }
    }

Looper目前了解到的主要监听的文件描述符种类有两种：
1）消息事件，epoll_wait监听pipe管道的接收端描述符mWakeReadPipeFd
2）与VSync信号，epoll_wait监听socket接收端描述符，并在addFd的过程中将相关的信息封装在一个Request结构中，并以fd为key存储到了mRequests中，具体可以回过头看3.1.2关于addFd的分析；
因此，上面走的是else的分支，辨别出当前的事件类型后，调用pushResponse：

void Looper::pushResponse(int events, const Request& request) {
    Response response;
    response.events = events;
    response.request = request;  //复制不是引用，调用拷贝构造函数
    mResponses.push(response);
}

该函数将Request和events封装在一个Response对象里面，存储到了mResponses里面，也就是mResponses里面放的是“某某fd上接收到了类别为events的时间”记录，继续向下看Looper.pollInner函数
（3）事件分发处理

    // Invoke all response callbacks.
    for (size_t i = 0; i < mResponses.size(); i++) {
        Response& response = mResponses.editItemAt(i);
        if (response.request.ident == POLL_CALLBACK) {
            int fd = response.request.fd;
            int events = response.events;
            void* data = response.request.data;
            int callbackResult = response.request.callback->handleEvent(fd, events, data);
            if (callbackResult == 0) {
                removeFd(fd);
            }
            // Clear the callback reference in the response structure promptly because we
            // will not clear the response vector itself until the next poll.
            response.request.callback.clear();
            result = POLL_CALLBACK;
        }
    }

这里的response.request是从pushResponse里面复制过来的，里面的request对应的Request对象是在addFd的时候创建的，ident成员就是POLL_CALLBACK，所以继续走到response.request.callback->handleEvent这个函数，回忆一下3.1.2里面的addFd函数，这里的callback实际上是一个SimpleLooperCallback（定义在Looper.cpp中）对象，看一下里面的handleEvent函数：

int SimpleLooperCallback::handleEvent(int fd, int events, void* data) {
    return mCallback(fd, events, data);
}

这里的mCallback就是当时在addFd的时候传进来的callBack参数，实际上对应的就是NativeDisplayEventReceiver对象本身，因此最终就将垂直同步信号事件分发到了NativeDisplayEventReceiver.handleEvent函数中。

3.3.2 分发VSync事件

调用到NativeDisplayEventReceiver.handleEvent函数，该函数定义在android_view_DisplayEventReceiver.cpp中，直接列出该函数：

int NativeDisplayEventReceiver::handleEvent(int receiveFd, int events, void* data) {
    if (events & (Looper::EVENT_ERROR | Looper::EVENT_HANGUP)) {
        ALOGE("Display event receiver pipe was closed or an error occurred.  "
                "events=0x%x", events);
        return 0; // remove the callback
    } 
    if (!(events & Looper::EVENT_INPUT)) {
        ALOGW("Received spurious callback for unhandled poll event.  "
                "events=0x%x", events);
        return 1; // keep the callback
    } 
    // Drain all pending events, keep the last vsync.
    nsecs_t vsyncTimestamp;
    int32_t vsyncDisplayId;
    uint32_t vsyncCount;
    if (processPendingEvents(&vsyncTimestamp, &vsyncDisplayId, &vsyncCount)) {
        ALOGV("receiver %p ~ Vsync pulse: timestamp=%" PRId64 ", id=%d, count=%d",
                this, vsyncTimestamp, vsyncDisplayId, vsyncCount);
        mWaitingForVsync = false;
        dispatchVsync(vsyncTimestamp, vsyncDisplayId, vsyncCount);
    }
    return 1; // keep the callback
}

首先判断事件是不是正确的Looper::EVENT_INPUT事件，然后调用到NativeDisplayEventReceiver.processPendingEvents函数：

bool NativeDisplayEventReceiver::processPendingEvents(nsecs_t* outTimestamp, int32_t* outId, uint32_t* outCount) {
    bool gotVsync = false;
    DisplayEventReceiver::Event buf[EVENT_BUFFER_SIZE];
    ssize_t n;
    while ((n = mReceiver.getEvents(buf, EVENT_BUFFER_SIZE)) > 0) {
        for (ssize_t i = 0; i < n; i++) {
            const DisplayEventReceiver::Event& ev = buf[i];
            switch (ev.header.type) {
            case DisplayEventReceiver::DISPLAY_EVENT_VSYNC:
                // Later vsync events will just overwrite the info from earlier
                // ones. That's fine, we only care about the most recent.
                gotVsync = true;
                *outTimestamp = ev.header.timestamp;
                *outId = ev.header.id;
                *outCount = ev.vsync.count;
                break;
            case DisplayEventReceiver::DISPLAY_EVENT_HOTPLUG:
                dispatchHotplug(ev.header.timestamp, ev.header.id, ev.hotplug.connected);
                break;
            default:
                ALOGW("receiver %p ~ ignoring unknown event type %#x", this, ev.header.type);
                break;
            }
        }
    }
    if (n < 0) {
        ALOGW("Failed to get events from display event receiver, status=%d", status_t(n));
    }
    return gotVsync;
}

这里的mReceiver也就是前面创建NativeDisplayEventReceiver对象是创建的成员变量对象DisplayEventReceiver，下面调用到DisplayEventReceiver.getEvents函数，应该是要从出现同步信号事件的socket中读取数据，上面Looper机制中epoll中监听到socket以后，返回到NativeDisplayEventReceiver.handleEvent里面，但是socket里面的数据还没有读取，下面的调用流程为：
（1）mReceiver.getEvents(buf, EVENT_BUFFER_SIZE) —-> DisplayEventReceiver::getEvents(DisplayEventReceiver::Event* events, size_t count)
（2）BitTube::recvObjects(dataChannel, events, count) —-> BitTube::recvObjects(const sp& tube, void* events, size_t count, size_t objSize)
看一下这个recvObjects函数：

ssize_t BitTube::recvObjects(const sp& tube, void* events, size_t count, size_t objSize)
{
    char* vaddr = reinterpret_cast<char*>(events);
    ssize_t size = tube->read(vaddr, count*objSize);
    return size < 0 ? size : size / static_cast(objSize);
}

这里在NativeDisplayEventReceiver中创建了一个缓冲区，并在recvObjects中将socket中的Event数据读到这个缓冲区中，这个Event.header.type一般都是DISPLAY_EVENT_VSYNC，因此在上面的processPendingEvents函数中会将Event数据保存在outCount所指向的内存中，并返回true。 接下来返回到NativeDisplayEventReceiver.handleEvent后会调用到dispatchVsync函数：

void NativeDisplayEventReceiver::dispatchVsync(nsecs_t timestamp, int32_t id, uint32_t count) {
    JNIEnv* env = AndroidRuntime::getJNIEnv();
    env->CallVoidMethod(mReceiverObjGlobal, gDisplayEventReceiverClassInfo.dispatchVsync, timestamp, id, count);
    mMessageQueue->raiseAndClearException(env, "dispatchVsync");
}

这里的处理很直接，直接调用mReceiverObjGlobal对象在gDisplayEventReceiverClassInfo.dispatchVsync中指定的函数，将后面的timestamp（时间戳） id（设备ID） count（经过的同步信号的数量，一般没有设置采样频率应该都是1），下面分别看一下mReceiverObjGlobal以及gDisplayEventReceiverClassInfo.dispatchVsync代表的是什么？
（1）mReceiverObjGlobal

NativeDisplayEventReceiver::NativeDisplayEventReceiver(JNIEnv* env, jobject receiverObj, const sp& messageQueue) :
        mReceiverObjGlobal(env->NewGlobalRef(receiverObj)), mMessageQueue(messageQueue), mWaitingForVsync(false) {
    ALOGV("receiver %p ~ Initializing input event receiver.", this);
}

可以看到mReceiverObjGlobal是创建NativeDisplayEventReceiver对象时传进来的第二个参数，该对象是在nativeInit函数中创建：
sp receiver = new NativeDisplayEventReceiver(env, receiverObj, messageQueue);
进一步的，receiverObj是调用nativeInit函数时传进来的第一个参数（第一个参数env是系统用于连接虚拟机时自动加上的），nativeInit函数又是在Choreographer中创建FrameDisplayEventReceiver对象时，在基类DisplayEventReceiver构造器中调用的，因此这里的mReceiverObjGlobal对应的就是Choreographer中的FrameDisplayEventReceiver成员mDisplayEventReceiver。
（2）gDisplayEventReceiverClassInfo.dispatchVsync
在JNI中有很多这样的类似的结构体对象，这些对象都是全局结构体对象，这里的gDisplayEventReceiverClassInfo就是这样的一个对象，里面描述了一些在整个文件内可能会调用到的java层的相关类以及成员函数的相关信息，看一下gDisplayEventReceiverClassInfo：

static struct {
    jclass clazz; 
    jmethodID dispatchVsync;
    jmethodID dispatchHotplug;
} gDisplayEventReceiverClassInfo;

看一下里面的变量名称就能知道大致的含义，clazz成员代表的是某个java层的类的class信息，dispatchVsync和dispatchHotplug代表的是java层类的方法的方法信息，看一下该文件中注册JNI函数的方法：

int register_android_view_DisplayEventReceiver(JNIEnv* env) {
    int res = RegisterMethodsOrDie(env, "android/view/DisplayEventReceiver", gMethods, NELEM(gMethods)); 
    jclass clazz = FindClassOrDie(env, "android/view/DisplayEventReceiver");
    gDisplayEventReceiverClassInfo.clazz = MakeGlobalRefOrDie(env, clazz); 
    gDisplayEventReceiverClassInfo.dispatchVsync = GetMethodIDOrDie(env, gDisplayEventReceiverClassInfo.clazz, "dispatchVsync", "(JII)V");
    gDisplayEventReceiverClassInfo.dispatchHotplug = GetMethodIDOrDie(env, gDisplayEventReceiverClassInfo.clazz, "dispatchHotplug", "(JIZ)V");
    return res;
}

RegisterMethodsOrDie调用注册了java层调用native方法时链接到的函数的入口，下面clazz对应的就是java层的“android/view/DisplayEventReceiver.java”类，gDisplayEventReceiverClassInfo.dispatchVsync里面保存的就是clazz类信息中与dispatchVsync方法相关的信息，同样dispatchHotplug也是。
分析到这里，就知道应用进程native接收到同步信号事件后，会调用Choreographer中的FrameDisplayEventReceiver成员mDisplayEventReceiver的dispatchVsync方法。

3.3.3 应用接收Vsync

看一下FrameDisplayEventReceiver.dispatchVsync方法，也就是DisplayEventReceiver.dispatchVsync方法(Choreographer.java)：

    // Called from native code.   
    @SuppressWarnings("unused")
    private void dispatchVsync(long timestampNanos, int builtInDisplayId, int frame) {
        onVsync(timestampNanos, builtInDisplayId, frame);
    }
    注释表明这个方法是从native代码调用的，该函数然后会调用FrameDisplayEventReceiver.onVsync方法：
        @Override
        public void onVsync(long timestampNanos, int builtInDisplayId, int frame) {
            // Ignore vsync from secondary display.
            // This can be problematic because the call to scheduleVsync() is a one-shot.
            // We need to ensure that we will still receive the vsync from the primary
            // display which is the one we really care about.  Ideally we should schedule
            // vsync for a particular display.
            // At this time Surface Flinger won't send us vsyncs for secondary displays
            // but that could change in the future so let's log a message to help us remember
            // that we need to fix this.
            //注释：忽略来自非主显示器的Vsync信号，但是我们前面调用的scheduleVsync函数只能请求到一次Vsync信号，因此需要重新调用scheduleVsync函数
            //请求来自主显示设备的Vsync信号
            if (builtInDisplayId != SurfaceControl.BUILT_IN_DISPLAY_ID_MAIN) {
                Log.d(TAG, "Received vsync from secondary display, but we don't support "
                        + "this case yet.  Choreographer needs a way to explicitly request "
                        + "vsync for a specific display to ensure it doesn't lose track "
                        + "of its scheduled vsync.");
                scheduleVsync();
                return;
            }

            // Post the vsync event to the Handler.
            // The idea is to prevent incoming vsync events from completely starving
            // the message queue.  If there are no messages in the queue with timestamps
            // earlier than the frame time, then the vsync event will be processed immediately.
            // Otherwise, messages that predate the vsync event will be handled first.
            long now = System.nanoTime();
            if (timestampNanos > now) {
                Log.w(TAG, "Frame time is " + ((timestampNanos - now) * 0.000001f)
                        + " ms in the future!  Check that graphics HAL is generating vsync "
                        + "timestamps using the correct timebase.");
                timestampNanos = now;
            }

            if (mHavePendingVsync) {
                Log.w(TAG, "Already have a pending vsync event.  There should only be "
                        + "one at a time.");
            } else {
                mHavePendingVsync = true;
            }

            mTimestampNanos = timestampNanos;  //同步信号时间戳
            mFrame = frame;                //同步信号的个数，理解就是从调用scheduleVsync到onVsync接收到信号之间经历的同步信号的个数，一般都是1
            Message msg = Message.obtain(mHandler, this);
            msg.setAsynchronous(true);
            mHandler.sendMessageAtTime(msg, timestampNanos / TimeUtils.NANOS_PER_MS);
        }

貌似这里的处理只是往Choreographer对象中的mHandler对应的线程Looper中发送一个消息，消息的内容有两个特点：
（1）将this，也就是当前的FrameDisplayEventReceiver对象作为参数，后面会回调到FrameDisplayEventReceiver.run方法；
（2）为Message设置FLAG_ASYNCHRONOUS属性；
发送这个FLAG_ASYNCHRONOUS消息后，后面会回调到FrameDisplayEventReceiver.run方法，至于为什么，后面再写文章结合View.invalidate方法的过程分析，看一下FrameDisplayEventReceiver.run方法：

        @Override
        public void run() {
            mHavePendingVsync = false;
            doFrame(mTimestampNanos, mFrame);
        }

调用Choreographer.doFrame方法，如果是重绘事件doFrame方法会最终调用到ViewRootImpl.performTraversals方法进入实际的绘制流程。经过上面的分析可以知道，调用一次Choreographer.scheduleVsyncLocked只会请求一次同步信号，也就是回调一次FrameDisplayEventReceiver.onVsync方法，在思考一个问题，一个应用进程需要多次请求Vsync同步信号会不会使用同样的一串对象？多个线程又是怎么样的？
答：一般绘制操作只能在主线程里面进行，因此一般来说只会在主线程里面去请求同步信号，可以认为不会存在同一个应用的多个线程请求SF的Vsync信号，Choreographer是一个线程内的单例模式，存储在了 ThreadLocal sThreadInstance对象里面，所以主线程多次请求使用的是同一个Choreographer对象，所以后面的一串对象应该都是可以复用的。