Android framework : UI刷新机制：Vsync and Choreographer

慕课网 剖析framework 笔记

6-1 说说android的UI刷新机制

 

这个和界面优化有关系，卡顿会影响用户体验，

理解UI刷新机制对解决问题有帮助的

 

问题：

1，丢帧是什么原因引起的？

2，Android的刷新频率是60帧/s,是每隔16ms就调用onDraw绘制一次？

3，onDraw之后屏幕会马上刷新吗？

4，如果界面没有重绘，还会每隔16ms刷新屏幕嘛》？

5，如果屏幕块刷新时才去onDraw绘制，会丢帧吗?

 

AP从系统拿到buffer，画完后返回给系统，

系统服务把buffer写到缓冲区，屏幕以一定频率刷新，每次刷新读缓冲区并显示，

如果缓冲区没有新数据，屏幕就一直使用老的数据。

 

 

屏幕的图像缓存不只有一个，如果只有一个，一边读一边写，会导致tearing，一般第一帧，一半第二帧，

所以一般有2个或者以上，一直swap就行了

 

下个问题，AP端什么时候开始绘制

屏幕每次收到vsync就从buffer拿数据显示，

绘制 是AP端发起的，随时可能发起，

所以1st脉冲显示0帧图像，2nd脉冲显示1st帧图像，

第三个时钟周期还是显示1st帧，因为2nd帧还没有画完，没画完不是因为它画的时间长，是因为它画的太晚了，vsync快来才画。

如果这种现象发生的非常频繁，用户就能感觉到，界面非常卡顿。

 

 

优化：

如果绘制也和显示一个节奏就行了，

每帧图像的绘制都控制在16ms以内，就行了，

但是有一个问题，AP层的View的重绘调RequestLayout，

这个函数什么时刻都可以调用。，怎么控制它真正绘制的时机？？ ： Choreographer

 

 

Android怎么处理的、？关键是一个类：Choreographer，舞蹈指导，

你往里发一个消息，它最快也要下一个vsync来的时候触发，

如，绘制随时发起，封装一个Runnable，丢个Choreographer，下个vsync来，处理这个消息，开始界面重绘。

相当于绘制节奏完全由Choreographer控制，

 

看看Choreographer的原理：

从requestLayout说起，它我们比较熟，是用来发起UI重绘的，

public void requestLayout(){
    ...
    scheduleTraversals();
}


void scheduleTraversals(){
    //它没直接绘制，做了2件事情，
    //1，往线程消息队列插了一个syncBarrier
    mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
    //2，往Choreographer消息队列插了一个callback
    mChoreographer.postCallback(Choregrapher.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
    .....
}

 

1，syncBarrier就是一个屏障，把屏障插入消息队列，屏障后面的普通消息就要等着，屏障撤出才可以处理，

但是屏障对异步消息没有作用，这么做的原因：

因为有些类型的消息非常紧急，要马上处理。如果消息队列里面普通消息过多，耽误事，所以插了屏障，优先处理异步消息。

这里往Choreographer丢的Runnnable就是一个异步消息，

下个 Vsync来的时候，异步消息是要紧急处理的。

 

2，Choreographer，是和ViewRootImpl一起创建的，

创建：

//有getInstance，是单例吗？不是
public static Choreographer getInstance(){
    //他是一个ThreadLocal，ThreadLocal<Choreographer>
    //也就是说在不同的线程调用getInstance返回的是不同的Choreographer对象
    return SThreadInstance.get();
}

 

 

假如有人一口气调用了10次requestLayout，那么下次vsync到来前，会引发10次UI重绘吗？

不会

 

void scheduleTraversals(){
    //每次判bool变量，是false才进，什么时候置的false？在mTraversalRunnable => doTraversal
    if(!mTraversalScheduled){
        mTraversalScheduled = true;
        mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        ....
    }
}
//下次vsync来的时候执行doTraversal，里面会给bool置flase
void doTraservsal(){
    if(mTraversalScheduled){
        mTraversalScheduled = false;
        performTraversals();
    }
}

 

看看这个callback是怎么加入到Choreographer的

private void postCallbackDelayedInternal(int callback Type, ...){
    ....
    //Choreographer里面有一个数组叫mCallBackQueues，数组里每个元素都是一个callback单链表
    //一方面要根据callback类型插入对应的单链表
    //另一方面要根据callback要执行的时间顺序排序，dueTime，越是马上发生的callback越放到链表的前面
    mCallbackQueue[callbackType].addCallbackLocked(dueTime, ...);
    ....
    scheduleFrameLocked(now);
}

private void scheduleFramelocked(long now){
    //如果当前线程就是Choreographer的工作线程，直接调shceduleVsyncLocked
    if(isRunningOnLooperThreadLocked()){
        scheduleVsyncLocked();
    }else{
        //否则要发消息到Choreographer的工作线程里面去，
        Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_VSYNC);
        //消息是异步消息，不受到屏障的影响，
        msg.setAsynchronous(true);
        //消息要插入到消息队列的头，非常紧急，
        //因为要告诉SF，下一个vsync来时，第一时间通知我们，因为如果错过这个vysnc，就又要等一个周期
        mHandler.sendMessageAtFrontOfQueue(msg);
    }
}

 

scheduleVsyncLocked后会发生什么？

是告诉SF，我们要关注下一个vsync信号了，

当下个vsync信号发生，SF通知我们，然后回调到FrameDisplayEventReciver里面的onVsync()

class FrameDisplayEventReceiver extends DisplayEventReciver implements Runnable{
    @Override
    //timestamNanos是vsync信号的时间戳
    public void onVsync(long timestampNanos, int builtInDisplayId, int frame){
        ....
        mTimestampNanos = timestampNanos;
        mFrame = frame;
        //这个消息this其实是一个runnable，就是后面的run()
        Message msg = Message.obtain(mHandler.this);
        mgs.setAsynchronous(true);
        //发了一个消息到Choreographer的工作线程里面去了，
        //封装一个消息丢出去干嘛？它不是切换工作线程，因为onVsync本身就是调到Choreographer里面的，
        //这个mHandler也是，这里发消息丢出去，它带了一个时间戳，表示消息要触发的时间，这样就可以按照时间戳顺序处理消息。
        mHandler.sendMessageAtTime(msg, timestampNanos/TimeUils.NANOS_PER_MS);
    }
    
    @Overide
    public void run(){
        //到时间了，消息被处理，就是执行doFrame
        doFrame(mTimestampNanos, mFrame);
    }
}

 

doFrame分两个阶段

 

//阶段1
//frameTimeNanos是这帧的时间戳
void doFrame(long frameTimeNanos, int frame){
    long intendedFrameTimeNanos = frameTimeNanos;
    long startNanos = System.nanoTime();
    //当前时间和时间戳间隔越大，这帧处理的延迟越大
    final long jitterNanos = startNanos - frameTimeNanos;
    //延迟大到超过一个周期，
    if(jitterNanos >= mFrameIntervalNanos){
        //算算延迟了几个周期
        final long skippedFrames = jitterNanos/mFrameIntervalNanos;
        //如果跳过的帧数大于这个常量，就会打印这个很熟悉的日志
        //主线程做的事情太多了，绘制都做不了，跳帧太多
        if(skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT){
            Log.i(TAG, "Skipped" + skippedFrames + "frames! " + "the appliction may be doing too much work on main thread");
        }
        .....
    }
}


//阶段2，处理callback，
//calback有4中类型，每种对应一个callback链表
void doFrame(long frameTimeNanos， int frame){
    ....
    doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
    doCallbacks(CHoreographer.CALBACK_ANIMATION, frameTImeNanos);
    doCAllbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
    doCallBacks(Choreographer.CALLLBACK_COMMIT, frameTimeNanos);'
}

//执行对应的doCallbacks，
//callback有时间戳，到了时间才执行回调
void doCallbacks(int callbackType, long frameTimeNanos){
    CallbackRecord callbacks;
    //extractDueCallback作用就是从callbackQueue取出到了时间的callbacks，
    callbacks = mCallbackQueues[callbackType].extractDueCallbacksLocked(...);
    //for循环执行链表中的callback的run函数
    for(CallbackRecode c = callbacks; c != null, c = c.next){
        c.run(frameTimeNanos)
    }
}

 

看看scheduleTraversals的时候传的callback是什么样的

//准备绘制，
void scheduleTraversals(){
    if(!mTraversalScheduled){
        mTraversalScheduled = true;
        mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        ....
    }
}

//mTraversalRunnable，最后调的就是doTraversal() => performTraversals()
final class TraversalRunnbale implements Runnable{
    @Override
    public void run(){
        doTraversal(); // => performTraversals，真正绘制的地方
    }
}

 

总结：

1，AP层的View调用requestLayout要求重绘，

2，其中是new了一个Runnable丢到Choreographer的消息队列，

3，Choreographer没马上处理消息，它是通过requestNextVsync向SurfaceFlinger请求下一个vSync信号，

4，SF会在下个vsync来的时候，通过postSyncEvent向choreographer发送一个通知，

5，choreographer收到通知之后就会处理消息队列里面的消息

6，之前的requestLayhout对应的Runnable里面执行的就是performTraversal，真正的执行绘制

 

 

 

下面看看scheduleVsync的实现

private void scheduleVsyncLocked(){
    //会调到native的DisplayEventReceiver的shceduleVsync函数
    mDisplayEventReceiver.scheduleVsync();
}

status_t NativeDisplayEventReceiver::scheuleVsync(){
    status_t status = mReceiver.requestNextVsync();
}

status_t DisplayEventReceiver::requestNextVsync(){
    //requestNextVsync，请求下一个vsync，
    //mEventConnection对象怎么创建的？在DisplayEventRecevier的构造函数创建的
    mEventConnection->requestNextVsync();
}

DisplayEventReceiver::DisplayEventReceiver(){
    //拿到SF的binder句柄：ISurfaceComposer
    sp<ISurfaceComposer> sf(ComposerService::getComposerService());
    if(sf != NULL){
        //得到mEventConnection，这是另外一个binder句柄，
        //这种套路很常见，拿到系统服务binder句柄后，要么openSeesion，要么CreateConnection，总之要单独弄一个通道。
        mEventConnection = sf->createDisplayEventConnection();
        //Channel是connection创建时new的一个BitTube对象
        mDataChannel = mEventConnection->getDataChannel();
    }
}

sp<BitTube> EventThread::Connection::getDataChannel() const{
    return mChannel;
}

//这种套路很常见，拿到系统服务binder句柄后，要么openSeesion，要么CreateConnection，总之要单独弄一个通道。

//Channel是connection创建时new的一个BitTube对象

 

BitTube其实就是两个描述符，通过socketpair创建

mSendFd

mReceiverFd

机制：

和管道有点像，如果有个人拿到了读Fd-ReceiverFd，阻塞在这里，另一个人拿到SendFd 写Fd时，ReceiverFd就会被唤醒。

socketpair(AF_UNIX, SOCK_SEQPACKET, 0, sockets)

 

 

看看connection如何创建的

//它的实现在SF进程里面
sp<IDisplayEventConnection> SurfaceFlinger::createDisplayEventConnection(){
    //eventThread是一个线程：等待、处理event
    return mEventThread->createEventConnection();
}

sp<EventThread::Connection> EventThread::createEventConnection() const{
    //new Connection and return
    return new Connection(const_cast<EventThread*>(this));
}

EventThread::Connection::Connection(const sp<EventThread>&eventThread)
    //new BitTube
    :count(-1), mEventThread(eventThread),mChannel(new BitTube()){}
    
void EventThread::Connection::onFirstRef(){
    //向EventThread注册自己，这样EventThread有event的时候，就可以分发connection，
    //connection又调到我们应用进程里面
    mEventThread->registerDisplayEventConnection(this);
}    

//看看connection是怎么注册到eventThread的
status_t EventThread::registerDisplayEventConnection(const sp<EventThread::Connection> & connection){
    //把conection add到DisplayEventConnection列表
    mDisplayEventConnections.add(connection);
    //发广播，类似java的notifyAll，对应的有wait才对，
    //wait是在eventThread里面。
    mCondition.broadcast();  //notifyAll
}

 

看看EventThread是在哪里创建的

void SurfaceFlinger::init(){
    //vysnc信号源，传给了EventThread
    sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync,..);
    //创建EventThread
    mEventThread = new EventThread(vsyncSrc);
    ...
}
//thread启动后不停的执行threadLoop
bool EventThread::threadLoop(){
    DisplayEventReceiver::Event event;
    Vector< sp<EventThread::Connection >signalConnections;
    //等待事件，返回Connection列表，里面都是event
    signalConnections = waitForEvent(&event);
    
    const size_t count = signalConnections.size();
    //遍历connection
    for(size_t i=0; i<count; i++){
        const sp<Connection> & conn(signalConnections[i]);
        //通过postEvent分发事件，典型的如vsync事件
        conn->postEvent(event);
    }
}

 

看看waitForEvent函数，这个函数很长，细节很多

Vector<sp<EvenThread::Connection>> EventThread::waitForEvent(..){
    Vector<sp<EventThead::Connection>>signalConnections;
    do{
        //看是否已经有vysnc信号来了，(不用关心vysnc怎么来，只关心怎么分发到应用层))
        //有，就准备connection列表返回
        //没有，等待vysnc
    }while(signalConnections.isEmpty());
    return signalConnctions;
}

//注意
void EventThread::requestNextVsync(const sp<EventThead>::Connection>&connection){
    //connection里面有一个字段count，当count>=0时，才表示connection关注vsyncEvent，
    //所以应用端调用requestNextVsync就是把count从-1变成0，
    if(connection->count < 0){
        connection->count = 0;
        mCondition.broadcast();
    }
}

 

当我们把connection加会signalConnections列表时，它有把count设置为-1.

这样你想接受下个vsync，就又要调一次requestNextVsync，把它重新置0

 

再看看事件如何分发出去

status_t EventThread::Connection::postEvent(const DispplayEeventReceiver::Event& event){
    ssize_t size = DIslayEventReceiver::sendEvents(mChannel, &event, 1);
    return size < 0 ? statuc_t(size):status_t(NO_ERROR);
}

ssize_t DisplayEventReceiver::sendEvnets(const sp<BitTube>&dataChannel, Event const* events, size_t count){
    return BitTube::sendObjects(dataChannel, events, count);
}

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

 

BitTube就是socket管道，有两个fb，w/r，write就是写，那读的一端就会收到通知。

BitTube的描述符是在SF端创建的，写的一端是在SF进程，

1，那读的一端是如何传给应用进程的？

2，应用进程如何监听读FD的？

 

解答他们要看DislayEventRecevier的构造函数

DisplayEventRecevier::DisplayEventRecevier(){
    sp<ISurfaceComposer> sf(ComposerService::getComposerService());
    mEventConnection = sf->createDisplayEventConnection();
    //得到mDataChannel，它就是BitTube
    mDataChannel = mEventConnection->getDataCannel();
}

//看看BitTube如何跨进程传递
//应用端拿到Connection的proxy端，getDataCannel把请求transact出去，
virtual sp<BitTube> getDataChannel() const {
    Parcel data, reply;
    data.writeInterfaceToken(IDisplayEventConnection::getInterfaceDescriptor());
    remote()->trascat(GET_DATA_CHANNEL, data, &reply);
    //BitTube根据reply把描述符还原出来，
    return new BitTube(reply);
}

//SF收到getDataChannel请求，会返回mChannel，Channel就是bitTube，
//Channel放到parcel，跨进程传递给应用进程，放到reply里面
sp<BitTube> EventThread::Connection::getDataChannel() const{
    return mChannel;
}

 

问题2，AP进程如何监听BitTube读事件？

要从Choreographer的构造函数说起，

private Choreographer(Looper looper){
    ...
    //如果用vsync信号，就会创建DisplayEventReceiver，FrameDisplayEventReceiver继承了DisplayEventReceiver，
    mDisplayEventReceiver = new FrameDisplayEventReceiver(looper);
}

public DisplayEventReceiver(Looper looper){
    ....
    //构造函数调到了nativeInit函数，它是native的函数，
    mRecevierPtr = nativeInit(new WeakReference<DisplayEventReceiver>(this),...);
}

static jlong nativeInit(JNIEnv* env, jclass clazz, jobject recevierWeak,...){
    ....
    //native层，创建一个NativeDisplayEventReceiver对象
    sp<NativeDisplayEventReceiver> recevier = new  NativeDisplayEventRecevier(...);
    //看看initialize
    status_t status = recevier->initialize();
    return reinterpret_cast<jlong.(receiver.get());
 }
 
 status_t NativeDisplayEventReceiver::initialize(){
     //往Looper里添加了一个fd，是要Looper监听fd的事情， 
     //EVENT_INPUT表示读事件，
     //参数this，是回调，表示如果FD有可读事件，就触发回调，后面讲，
     //fd是mRecevier的getFd，就是返回了DataChannel的getFd
     mMessageQueue->getLooper()->addFd(mRecevier.getFd(), 0, Looper::EVENT_INPUT, this, NULL);
     return OK;
 }
 
 DisplayEventReceiver::DisplayEventReceiver(){
    //拿到SF的binder句柄：ISurfaceComposer
    sp<ISurfaceComposer> sf(ComposerService::getComposerService());
    if(sf != NULL){
        //得到mEventConnection，这是另外一个binder句柄，
        //这种套路很常见，拿到系统服务binder句柄后，要么openSeesion，要么CreateConnection，总之要单独弄一个通道。
        mEventConnection = sf->createDisplayEventConnection();
        //Channel是connection创建时new的一个BitTube对象
        mDataChannel = mEventConnection->getDataChannel();
    }
}

int DisplayEventRecevier::getFd() const{
    //前面讨论过，DataChannel就是BitTube
    return mDataChannel->getFd();
}

//BitTube有两个描述符，发送和接收，这里返回的是接收的，
//发送的Fd在SurfaceFlinger，
int BitTube::getFd() const{
    return mReceiveFd;
}

 

看看getlooer()->addFd，Fd如何添加到looper的，

int Looper::addFd(int fd, int ident, int events, ...){
    Request request;
    request.fd = fd;
    ....
    //new了epoll_event，加入epoll
    struct epoll_event eventItem;
    request.initEventItem(&eventItem);
    
    int epollResult = epoll_ctl(mEpollFd, EPOLL_CTL_ADD, fd, &eventItem);
    //把request加到mRequest列表
    mRequests.add(fd, request);
}

 

看看Looper如何检测FD的读事件

int Looper::pollnner(int timeoutMillis){
    ...
    //epoll_wait返回后在for里处理事件
    int eventCount = epoll_wait(mEpollFd, eventItems,...);
    
    //有两种事件，
    for(int i = 0; i< eventCount; i++){
        int fd = eventItems[i].data.fd;
        uint32_t epollEvents = eventItems[i].events;
        //1,消息队列的事件
        if(fb == mWakeEventFd){
            ...
        }else{//2，其他fd事件，
            if(epollEvents & EPOLLIN) events |= EVENT_INPUT；
            //放到response列表，for结束后，统一处理responses
            pushResponse(events, mRequestl.valueAt(requestIndex));
        }
    }
    //统一处理Responses
    for(size_t i = 0 ; i < mResponses.size(); i++){
        Response& response = mResponsese.editItemAt(i);
        int fd = response.request.fd;
        intevents = response.evdnts;
        void *data = responose.request.data;
        //调用callback的handleEvent，返回值很重要，
        int callbackResult = response.request.callback->handleEvent(fd, events, data);
        if(callbackResult == 0){
            //返回0则删除这个fd
            removeFd(fd, response.request.seq);
        }
        response.request.callback.clear();
        result = POLL_CALLBACK;
    }
    
    return result;
}

我们添加的BitTube的Fd的回调是什么？

int NativeDisplayEventRecevier::handleEvent(int receiveFd, int events,...){
    //把SF发的event读进来，
    if(processPendingEvents(&vsyncTimestamp, &vsyncDisplayId, ...)){
        mWaitingForVsync = false;
        //分发vysnc，
        dispatchVsync(vsyncTimestamp, vsyncDisplayId, vysncCount);
    }
    //返回1，Fd会一直被Looper监听，不会删除掉。
    return 1;
}

void NatvieDisplayEventRecevier::dispatchVsync(nsecs_t timestamp,...){
    //jni调用，调到java层的dispatchVysnc
    env->CallVoidMethod(recevierObj.get()),gDisplayEventReceiverClassInfo.dispatchVsync, timestamp,...);
}

void displatchVsync(long timestampNanos, int builtInDisplayId, int frame){
    //前面讲过，是处理Choreographer的callback的
    onVysnc(timestampNanos, builtInDisplayId, frame);
}

 

回到问题：

1，丢帧原因？ mainthread有耗时操作，耽误了View的绘制

2，android的刷新频率是60帧/s，那每隔10ms调onDraw绘制一次？

60是vsync的频率，但不是每个vsync都发起绘制，需要AP端主动发起重绘，才会向SF请求接收Vsync信号，才会再下个vsync来的时候绘制。

3.onDraw后屏幕立刻刷新？ 不是，下一个vsync来的时候花心

4，如果界面没有重绘，还会每隔17ms刷新屏幕？ 会的，只是数据一直用的旧的

5，如果快刷新时才绘制会丢帧吗？

View重绘不会被马上执行，都是下个vsync来才开始的，所以何时发起重绘没什么关系

 

总结，述说Android的UI刷新机制，如何回答：

1，vsync的原理

2，Choreographer的原理

3，UI刷新的大致流程，应用和SurfaceFlinger的通信过程。