April is your lie

Chromium学习之路(一)----智能指针实现原理分析

2019-03-25T09:07:11.000Z

Chromium和WebKit的智能指针实现原理分析。

智能指针概述

智能指针对于写c艹程序的开发人员来说并不陌生，尤其大一点的程序，也是司空见惯。（容我吐槽一下自己，接触webrtc中也有大量的智能指针，奈何我是个c艹新手）WebKit和Chromium都是C艹开发的，在解决对象释放问题时，要做到在对象不需要时自动释放，因为手动释放会带来忘记释放或者释放后又继续使用的隐患。智能指针是实现对象自动释放的有效技术手段。

之前文章有一篇智能指针简单分析，在Android系统源码里用到了大量的sp和wp相关的代码。sp和wp就是android系统提供的智能指针模版类，前者用来实现强引用，后者用来实现弱饮用。

引用一段对智能指针的描述：

在广义上，智能指针划分为两类。第一类智能指针引用的对象是可以共享的，也就是一个对象可以同时被多个智能指针引用。这类智能指针要求被引用的对象具有计数的功能，数值的大小就表示它目前被多少个智能指针引用。当一个对象的引用计数值等于0的时候，就表示它要被释放了。这类智能指针适合作为函数参数或者返回值在模块之间进行传递，从而实现共享。第二类智能指针不要求被引用对象具有计数的功能。
第二类智能指针引用的对象是独占的，也就是一个对象同一时刻只可以被一个智能指针引用。这类智能指针不要求被引用对象具有计数的功能。只要这类智能指针的生命周期超出了它自己的范围，那么它引用的对象就会被自动销毁。这类智能指针适合在函数或者内部使用，用来自动化释放那些不需要了的对象。

Chromium和WebKit还提供了弱智能指针，就是他们的存在不会影响被引用对象的生命周期。他们适合来解决对象这件存在的循环引用问题。再次饮用一段介绍：

在计算机科学领域中，提供垃圾收集（Garbage Collection）功能的系统框架，即提供对象托管功能的系统框架，例如Java应用程序框架，也是采用上述的引用计数技术方案来实现的，然而，简单的引用计数技术不能处理系统中对象间循环引用的情况。考虑这样的一个场景，系统中有两个对象A和B，在对象A的内部引用了对象B，而在对象B的内部也引用了对象A。当两个对象A和B都不再使用时，垃圾收集系统会发现无法回收这两个对象的所占据的内存的，因为系统一次只能收集一个对象，而无论系统决定要收回对象A还是要收回对象B时，都会发现这个对象被其它的对象所引用，因而就都回收不了，这样就造成了内存泄漏。这样，就要采取另外的一种引用计数技术了，即对象的引用计数同时存在强引用和弱引用两种计数，例如，Apple公司提出的Cocoa框架，当父对象要引用子对象时，就对子对象使用强引用计数技术，而当子对象要引用父对象时，就对父对象使用弱引用计数技术，而当垃圾收集系统执行对象回收工作时，只要发现对象的强引用计数为0，而不管它的弱引用计数是否为0，都可以回收这个对象，但是，如果我们只对一个对象持有弱引用计数，当我们要使用这个对象时，就不直接使用了，必须要把这个弱引用升级成为强引用时，才能使用这个对象，在转换的过程中，如果对象已经不存在，那么转换就失败了，这时候就说明这个对象已经被销毁了，不能再使用了。

因此要分别分析WebKit和Chromium的智能指针，好在Android源码里面都有，都位于external/chromuim_org/下面，之前下过android源码就可以直接查看了。

WebKit智能指针

第一类智能指针

WebKit第一类智能指针由RefPtr实现，它的基类是RefCounted，提供引用计数功能。当一个对象可以被类RefPtr描述的对象引用时，它就必须要从基类RefCounted继承下来。
RefCounted是一个模板类，为了减少编译时的代码膨胀，RefCounted类是从另外一个非模板类RefCountedBase继承下来的。RefCountedBase类才是负责提供计数功能的基类，位于external/chromium_org/third_party/WebKit/Source/wtf/RefCounted.h中：

class WTF_EXPORT RefCountedBase {
public:
    void ref()
    {
#if CHECK_REF_COUNTED_LIFECYCLE
        // Start thread verification as soon as the ref count gets to 2. This
        // heuristic reflects the fact that items are often created on one thread
        // and then given to another thread to be used.
        // FIXME: Make this restriction tigher. Especially as we move to more
        // common methods for sharing items across threads like CrossThreadCopier.h
        // We should be able to add a "detachFromThread" method to make this explicit.
        if (m_refCount == 1)
            m_verifier.setShared(true);
        // If this assert fires, it either indicates a thread safety issue or
        // that the verification needs to change. See ThreadRestrictionVerifier for
        // the different modes.
        ASSERT(m_verifier.isSafeToUse());
        ASSERT(!m_adoptionIsRequired);
#endif
        ASSERT_WITH_SECURITY_IMPLICATION(!m_deletionHasBegun);
        //这才是重点，饮用计数+1
        ++m_refCount;
    }

    bool hasOneRef() const
    {
        ASSERT_WITH_SECURITY_IMPLICATION(!m_deletionHasBegun);
#if CHECK_REF_COUNTED_LIFECYCLE
        ASSERT(m_verifier.isSafeToUse());
#endif
        return m_refCount == 1;
    }

    int refCount() const
    {
#if CHECK_REF_COUNTED_LIFECYCLE
        ASSERT(m_verifier.isSafeToUse());
#endif
        return m_refCount;
    }

protected:
    RefCountedBase()
        : m_refCount(1)//默认创建时候引用计数为1
#if SECURITY_ASSERT_ENABLED
        , m_deletionHasBegun(false)
#endif
#if CHECK_REF_COUNTED_LIFECYCLE
        , m_adoptionIsRequired(true)
#endif
    {
    }

    ~RefCountedBase()
    {
        ASSERT_WITH_SECURITY_IMPLICATION(m_deletionHasBegun);
#if CHECK_REF_COUNTED_LIFECYCLE
        ASSERT(!m_adoptionIsRequired);
#endif
    }

    // Returns whether the pointer should be freed or not.
    bool derefBase()
    {
        ASSERT_WITH_SECURITY_IMPLICATION(!m_deletionHasBegun);
#if CHECK_REF_COUNTED_LIFECYCLE
        ASSERT(m_verifier.isSafeToUse());
        ASSERT(!m_adoptionIsRequired);
#endif

        ASSERT(m_refCount > 0);
        //引用计数-1
        --m_refCount;
        //如果引用计数为0，就return true，为后面的删除对象作出判断
        if (!m_refCount) {
#if SECURITY_ASSERT_ENABLED
            m_deletionHasBegun = true;
#endif
            return true;
        }

#if CHECK_REF_COUNTED_LIFECYCLE
        // Stop thread verification when the ref goes to 1 because it
        // is safe to be passed to another thread at this point.
        if (m_refCount == 1)
            m_verifier.setShared(false);
#endif
        return false;
    }

#if CHECK_REF_COUNTED_LIFECYCLE
    bool deletionHasBegun() const
    {
        return m_deletionHasBegun;
    }
#endif

private:

#if CHECK_REF_COUNTED_LIFECYCLE || SECURITY_ASSERT_ENABLED
    friend void adopted(RefCountedBase*);
#endif

    int m_refCount;//引用计数，核心变量
#if SECURITY_ASSERT_ENABLED
    bool m_deletionHasBegun;
#endif
#if CHECK_REF_COUNTED_LIFECYCLE
    bool m_adoptionIsRequired;
    ThreadRestrictionVerifier m_verifier;
#endif
};

#if CHECK_REF_COUNTED_LIFECYCLE || SECURITY_ASSERT_ENABLED
inline void adopted(RefCountedBase* object)
{
    if (!object)
        return;
    ASSERT_WITH_SECURITY_IMPLICATION(!object->m_deletionHasBegun);
#if CHECK_REF_COUNTED_LIFECYCLE
    object->m_adoptionIsRequired = false;
#endif
}
#endif

忽略其他障眼法，能够看到RefCountedBase类有一个类型为int的成员变量m_refCount，它就是用来描述对象的引用计数的。此外，RefCountedBase类还提供了两个成员函数ref和derefBase，分别用来增加和减少成员变量m_refCount描述的对象引用计数。

调用RefCountedBase类的成员函数derefBase减少一个对象的引用计数时，如果减少后的引用计数等于0，那么它的返回值就等于true，表示该对象应该被释放了，不过这个释放的操作留给子类RefCounted实现。

从RefCountedBase类的构造函数可以看到，一个RefCountedBase类及其子类对象被创建出来的时候，它的引用计数值就已经被初始化为1，这意味着不需要额外调用RefCountedBase类的成员函数ref来增加新创建对象的引用计数。

这是RefCounted的基类，提供了引用计数的基本实现，接下来就看看子类RefCounted，同样位于external/chromium_org/third_party/WebKit/Source/wtf/RefCounted.h中：

template<typename T> class RefCounted : public RefCountedBase {
    WTF_MAKE_NONCOPYABLE(RefCounted);
    WTF_MAKE_FAST_ALLOCATED;

public:
    void deref()
    {
        //调用了父类的derefBase函数
        if (derefBase())//如果返回true，就delete掉这个对象
            delete static_cast<T*>(this);
    }

protected:
#ifdef ENABLE_INSTANCE_COUNTER
    RefCounted()
    {
        incrementInstanceCount<T>(static_cast<T*>(this));
    }

    ~RefCounted()
    {
        decrementInstanceCount<T>(static_cast<T*>(this));
    }
#else
    RefCounted()
    {
    }
#endif
};

RefCounted类有一个成员函数deref，它调用父类RefCountedBase类的成员函数derefBase减少对象的引用计数。当RefCountedBase类的成员函数derefBase的返回值等于true的时候，就表示对象该释放了，因此RefCounted类的成员函数deref就直接将它delete掉。

RefCounted的基类RefCountedBase在增加或者减少引用计数的时候，并没有加锁或者执行原子加减操作。因此，我们就说RefCounted类是线程不安全的。如果我们需要线程安全版本的RefCounted类，WebKit提供了另外一个类ThreadSafeRefCounted，它继承于ThreadSafeRefCountedBase类。ThreadSafeRefCountedBase类位于external/chromium_org/third_party/WebKit/Source/wtf/ThreadSafeRefCounted.h中：

class WTF_EXPORT ThreadSafeRefCountedBase {
    WTF_MAKE_NONCOPYABLE(ThreadSafeRefCountedBase);
    WTF_MAKE_FAST_ALLOCATED;
public:
    ThreadSafeRefCountedBase(int initialRefCount = 1)
        : m_refCount(initialRefCount)
    {
    }

    void ref()
    {
        //原子操作保证线程安全
        atomicIncrement(&m_refCount);
    }

    bool hasOneRef()
    {
        return refCount() == 1;
    }

    int refCount() const
    {
        return static_cast<int const volatile &>(m_refCount);
    }

protected:
    // Returns whether the pointer should be freed or not.
    bool derefBase()
    {
        WTF_ANNOTATE_HAPPENS_BEFORE(&m_refCount);
        //原子操作保证线程安全
        if (atomicDecrement(&m_refCount) <= 0) {
            WTF_ANNOTATE_HAPPENS_AFTER(&m_refCount);
            return true;
        }
        return false;
    }

private:
    int m_refCount;
};

与RefCountedBase类一样，ThreadSafeRefCountedBase类也实现了成员函数ref和derefBase，不过它通过原子操作atomicIncrement和atomicDecrement来分别增加和减少目标对象的引用计数，因此它是线程安全的。 ThreadSafeRefCounted类的实现如下，同样位于external/chromium_org/third_party/WebKit/Source/wtf/ThreadSafeRefCounted.h：

template<class T> class ThreadSafeRefCounted : public ThreadSafeRefCountedBase {
public:
    void deref()
    {
        if (derefBase())
            delete static_cast<T*>(this);
    }

protected:
    ThreadSafeRefCounted()
    {
    }
};

与RefCounted类一样，ThreadSafeRefCounted类也实现了成员函数deref，并且调用父类ThreadSafeRefCountedBase的成员函数derefBase减少对象的引用计数。当对象的引用计数小于等于0时，就会将它delete掉。

有了RefCounted和ThreadSafeRefCounted这两个基类为对象提供计数功能之后，我们就继续分析第一类智能指针RefPtr的实现，位于external/chromium_org/third_party/WebKit/Source/wtf/RefPtr.h：

template<typename T> class RefPtr {
    WTF_DISALLOW_CONSTRUCTION_FROM_ZERO(RefPtr);
    WTF_DISALLOW_ZERO_ASSIGNMENT(RefPtr);
public:
    ALWAYS_INLINE RefPtr() : m_ptr(0) { }
    ALWAYS_INLINE RefPtr(std::nullptr_t) : m_ptr(0) { }
    ALWAYS_INLINE RefPtr(T* ptr) : m_ptr(ptr) { refIfNotNull(ptr); }
    template<typename U> RefPtr(const RawPtr<U>& ptr, EnsurePtrConvertibleArgDecl(U, T)) : m_ptr(ptr.get()) { refIfNotNull(m_ptr); }
    ALWAYS_INLINE explicit RefPtr(T& ref) : m_ptr(&ref) { m_ptr->ref(); }
    ALWAYS_INLINE RefPtr(const RefPtr& o) : m_ptr(o.m_ptr) { refIfNotNull(m_ptr); }
    template<typename U> RefPtr(const RefPtr<U>& o, EnsurePtrConvertibleArgDecl(U, T)) : m_ptr(o.get()) { refIfNotNull(m_ptr); }

    // See comments in PassRefPtr.h for an explanation of why this takes a const reference.
    template<typename U> RefPtr(const PassRefPtr<U>&, EnsurePtrConvertibleArgDecl(U, T));

    // Hash table deleted values, which are only constructed and never copied or destroyed.
    RefPtr(HashTableDeletedValueType) : m_ptr(hashTableDeletedValue()) { }
    bool isHashTableDeletedValue() const { return m_ptr == hashTableDeletedValue(); }

    ALWAYS_INLINE ~RefPtr() { derefIfNotNull(m_ptr); }

    ALWAYS_INLINE T* get() const { return m_ptr; }

    void clear();
    PassRefPtr<T> release() { PassRefPtr<T> tmp = adoptRef(m_ptr); m_ptr = 0; return tmp; }

    T& operator*() const { return *m_ptr; }
    ALWAYS_INLINE T* operator->() const { return m_ptr; }

    bool operator!() const { return !m_ptr; }

    // This conversion operator allows implicit conversion to bool but not to other integer types.
    typedef T* (RefPtr::*UnspecifiedBoolType);
    operator UnspecifiedBoolType() const { return m_ptr ? &RefPtr::m_ptr : 0; }

    RefPtr& operator=(const RefPtr&);
    RefPtr& operator=(T*);
    RefPtr& operator=(const PassRefPtr<T>&);
    RefPtr& operator=(std::nullptr_t) { clear(); return *this; }

    template<typename U> RefPtr<T>& operator=(const RefPtr<U>&);
    template<typename U> RefPtr<T>& operator=(const PassRefPtr<U>&);
    template<typename U> RefPtr<T>& operator=(const RawPtr<U>&);

    void swap(RefPtr&);

    static T* hashTableDeletedValue() { return reinterpret_cast<T*>(-1); }

private:
    T* m_ptr;
};

注意，这里的模板参数T要么是从RefCounted的子类，要么是ThreadSafeRefCounted的子类。

除了参数类型为T&的构造函数之外，RefPtr类的所有其它构造函数都会调用函数refIfNotNull来增加目标对象的引用计数。在参数类型为T&的构造函数中，能够保证参数ref不为NULL，因此就可以直接调用目标对象的成员函数ref来增加其引用计数。

相应地，RefPtr类的析构函数会调用函数derefIfNotNull来减少目标对象的引用计数。这样就可以保证一个智能指针超出其生命周期时，能够自动释放它引用的对象。

为了能够通过智能指针来调用目标对象的成员函数，RefPtr类实现了两个操作符重载成员函数*和->。此外，RefPtr类还实现了一个成员函数get，用来获取一个指向目标对象的裸指针，这样就实现智能指针到裸指针的转换。

函数refIfNotNull和derefIfNotNull的实现如下，位于external/chromium_org/third_party/WebKit/Source/wtf/PassRefPtr.h中：

template<typename T> ALWAYS_INLINE void refIfNotNull(T* ptr)
{
    if (LIKELY(ptr != 0)) {
        requireAdoption(ptr);
        ptr->ref();
    }
}

template<typename T> ALWAYS_INLINE void derefIfNotNull(T* ptr)
{
    if (LIKELY(ptr != 0))
        ptr->deref();
}

函数refIfNotNull和derefIfNotNull分别能过调用参数ptr描述的对象的成员函数ref和deref减少其引用计数。不过在增加和减少参数ptr描述的对象的引用计数之前，会先判断参数ptr的值是否等于0。只有在不等于0的情况下，才会执行增加和减少引用计数的操作。

以上就是WebKit的第一类智能指针RefPtr的实现。

去除无用引用计数

在实际使用中，似乎没有什么问题。但是细心的同学可能会注意到，当智能指针作为参数或者返回值在函数之间传递时，都会执行一次加1的引用计数操作，而当参数或者返回值超出其生命周期时，又会对称地执行一次减1的引用计数操作。这些加1和减1的引用计数操作是否是必须的呢？我们可以看下面的例子：

RefPtr<T2> foo(RefPtr<T1> p2) {
    RefPtr<T2> p3 = new T2();
    
    //......
 
    return p3;
}
 
RefPtr<T1> p1 = new T1();
RefPtr<T2> p4 = foo(p1);

上述过程的引用计数计算如下：

我们先new一个T1对象，并且通过它来构造智能指针p1时，这时候T1对象的引用计数为1，它不会被销毁。
接下来我们以智能指针p1为参数调用函数foo，这时候智能指针p2也引用了T1对象，因此T1对象的引用计数增加为2，它也不会被销毁。
从函数foo返回后，智能指针p2超出了其生命周期范围，因此T1对象的引用计数减少为1，它仍然是不会被销毁。
要等到智能指针p1也超出其生命周期范围时，T1对象的引用计数才会减少为0，从而被释放。

go on：

在函数foo内部，我们先new一个T2对象，并且通过它来构造智能指针p3，这时候T2对象的引用计数为1，它不会被销毁。
接下来函数foo返回智能指针p3给智能指针p4，这时候智能指针p4也引用了T2对象，因此T2对象的引用计数增加为2，它也不会被销毁。
与此同时，智能指针p3超出了其生命周期范围，因此T2对象的引用计数减少为1，它仍然是不会被销毁。
同样是要等到智能指针p4也超出其生命周期范围时，T2对象的引用计数才会减少为0，从而被释放。

很明显，在调用函数foo期间，完全是没有增加和减少T1对象和T2对象的引用计数的，这相当于是做了两次无用功。而且在实际的工程实践中，上述的代码是相当普通的，因此就会充斥着大量的无用功操作。

为了去除上述的无用功，WebKit提供了另外一个智能指针类PassRefPtr，这个类定义在文件external/chromium_org/third_party/WebKit/Source/wtf/PassRefPtr.h中，它的实现如下所示：

   template<typename T> class PassRefPtr {
       WTF_DISALLOW_CONSTRUCTION_FROM_ZERO(PassRefPtr);
   public:
       PassRefPtr() : m_ptr(0) { }
       PassRefPtr(std::nullptr_t) : m_ptr(0) { }
       PassRefPtr(T* ptr) : m_ptr(ptr) { refIfNotNull(ptr); }
       template<typename U> PassRefPtr(const RawPtr<U>& ptr, EnsurePtrConvertibleArgDecl(U, T)) : m_ptr(ptr.get()) { refIfNotNull(m_ptr); }
       explicit PassRefPtr(T& ptr) : m_ptr(&ptr) { m_ptr->ref(); }
       // It somewhat breaks the type system to allow transfer of ownership out of
       // a const PassRefPtr. However, it makes it much easier to work with PassRefPtr
       // temporaries, and we don't have a need to use real const PassRefPtrs anyway.
       //我们是一个PassRefPtr智能指针p1构造另一个PassRefPtr智能指针p2时，
       //或者说将一个PassRefPtr智能指针p1传递给另一个PassRefPtr智能指针p2时，
       //智能指针p1就自动失去了对目标对象的引用，
       //并且这时候目标对象的引用计数没有发生变化。
       PassRefPtr(const PassRefPtr& o) : m_ptr(o.leakRef()) { }
       template<typename U> PassRefPtr(const PassRefPtr<U>& o, EnsurePtrConvertibleArgDecl(U, T)) : m_ptr(o.leakRef()) { }

       ALWAYS_INLINE ~PassRefPtr() { derefIfNotNull(m_ptr); }

       template<typename U> PassRefPtr(const RefPtr<U>&, EnsurePtrConvertibleArgDecl(U, T));

       T* get() const { return m_ptr; }

       T* leakRef() const WARN_UNUSED_RETURN;

       T& operator*() const { return *m_ptr; }
       T* operator->() const { return m_ptr; }

       bool operator!() const { return !m_ptr; }

       // This conversion operator allows implicit conversion to bool but not to other integer types.
       typedef T* (PassRefPtr::*UnspecifiedBoolType);
       operator UnspecifiedBoolType() const { return m_ptr ? &PassRefPtr::m_ptr : 0; }

       friend PassRefPtr adoptRef<T>(T*);

   private:
       enum AdoptRefTag { AdoptRef };
       PassRefPtr(T* ptr, AdoptRefTag) : m_ptr(ptr) { }

       PassRefPtr& operator=(const PassRefPtr&) { COMPILE_ASSERT(!sizeof(T*), PassRefPtr_should_never_be_assigned_to); return *this; }

       mutable T* m_ptr;
   }
template<typename T> template<typename U> inline PassRefPtr<T>::PassRefPtr(const RefPtr<U>& o, EnsurePtrConvertibleArgDefn(U, T))
       : m_ptr(o.get())
   {
       T* ptr = m_ptr;
       refIfNotNull(ptr);
   }
   //leakRef函数回抹去参数指针对象的引用，强行赋值为0（NULL）
   //此时它就就自动失去了对目标对象的引用，但是用于构造另一个只能指针的refCount还不变
   template<typename T> inline T* PassRefPtr<T>::leakRef() const
   {
       T* ptr = m_ptr;
       m_ptr = 0;
       return ptr;
   }

从PassRefPtr类的构造函数可以知道，当它们的参数是T、T&和const RefPtr&时，PassRefPtr类描述的智能指针与RefPtr类描述的智能指针并没有什么区别。*但是当参数为const PassRefPtr&时，也就是我们是一个PassRefPtr智能指针p1构造另一个PassRefPtr智能指针p2时，或者说将一个PassRefPtr智能指针p1传递给另一个PassRefPtr智能指针p2时，神奇的事情就发生了！智能指针p1就自动失去了对目标对象的引用，并且这时候目标对象的引用计数没有发生变化。这是通过PassRefPtr类的成员函数leakRef实现的。

有了PassRefPtr类之后，我们再来改写上面举的例子，如下所示：

PassRefPtr<T2> foo(PassRefPtr<T1> p2) {
    PassRefPtr<T2> p3 = new T2();
    
    ......
 
    return p3;
}
 
PassRefPtr<T1> p1 = new T1();

此时执行上述代码对于引用计数会有稍许变化：
1. T1对象和T2对象在函数foo的调用或者返回前后，它们的引用计数值都始终保持为1。

只有当智能指针p1和智能指针p4超出其生命周期范围时，T1对象和T2对象的引用计数才会减少为0，从而被释放。

这样就可以免去智能指针作为参数或者返回值传递目标对象的增加和减少引用计数操作，从而去掉无用功。

从前面PassRefPtr类的定义可以知道，我们可以将一个RefPtr智能指针传递给一个PassRefPtr智能指针，这时候目标对象的引用计数会增加1。我们还可以另外一种方式将一个RefPtr智能指针传递给一个PassRefPtr智能指针。这种传递方式将会使得目标对象的引用计数不发生变化，并且RefPtr智能指针自动失去对目标对象的引用。这是通过调用RefPtr类的成员函数release实现的，这个函数定义在文件external/chromium_org/third_party/WebKit/Source/wtf/RefPtr.h中：

namespace WTF {
 
    //......
 
    template<typename T> class RefPtr {
        //......
    public:
        //......
 
        PassRefPtr<T> release() { PassRefPtr<T> tmp = adoptRef(m_ptr); m_ptr = 0; return tmp; }
 
        //......
 
    private:
        T* m_ptr;
    };
 
    //......
};

RefPtr类的成员函数release调用函数adoptRef来构造一个PassRefPtr智能指针，这个函数定义在文件external/chromium_org/third_party/WebKit/Source/wtf/PassRefPtr.h中：

namespace WTF {
    //......
 
    template<typename T> inline PassRefPtr<T> adoptRef(T* p)
    {
        //......
        return PassRefPtr<T>(p, PassRefPtr<T>::AdoptRef);
    }
 
    //......
};

函数adoptRef调用以下的PassRefPtr类的构造函数来构造一个PassRefPtr智能指针，这个函数定义在文件external/chromium_org/third_party/WebKit/Source/wtf/PassRefPtr.h中:

namespace WTF {
    //......
 
    template<typename T> class PassRefPtr {
        //......
 
    private:
        enum AdoptRefTag { AdoptRef };
        PassRefPtr(T* ptr, AdoptRefTag) : m_ptr(ptr) { }
 
        //......
 
        mutable T* m_ptr;
    };
 
    //......
};

从这里就可以看到，上述的PassRefPtr类的构造函数并没有增加目标对象的引用计数，因此我们就可以在不改变目标对象的引用计数的前提下，将一个RefPtr智能指针传递给一个PassRefPtr智能指针，相当于就是将一个RefPtr智能指针对目标对象的所有权转移给一个PassRefPtr智能指针。

第二类智能指针

接下来我们再看WebKit的第二类智能指针的实现，它由类OwnPtr实现，这个类定义在文件external/chromium_org/third_party/WebKit/Source/wtf/OwnPtr.h中：

namespace WTF {
 
    //.......
 
    template<typename T> class OwnPtr {
        //......
    public:
        typedef typename RemoveExtent<T>::Type ValueType;
        typedef ValueType* PtrType;
 
        OwnPtr() : m_ptr(0) { }
        OwnPtr(std::nullptr_t) : m_ptr(0) { }
 
        //......
        OwnPtr(const PassOwnPtr<T>&);
        //......
 
#if !COMPILER_SUPPORTS(CXX_RVALUE_REFERENCES)
        //......
        OwnPtr(const OwnPtr&);
#endif
 
        ~OwnPtr()
        {
            OwnedPtrDeleter<T>::deletePtr(m_ptr);
            m_ptr = 0;
        }
 
        //......
 
        PtrType get() const { return m_ptr; }
 
        //......
 
        PassOwnPtr<T> release();
        PtrType leakPtr() WARN_UNUSED_RETURN;
 
        ValueType& operator*() const { ASSERT(m_ptr); return *m_ptr; }
        PtrType operator->() const { ASSERT(m_ptr); return m_ptr; }
 
        //......
 
        OwnPtr& operator=(const PassOwnPtr<T>&);
        //......
 
#if COMPILER_SUPPORTS(CXX_RVALUE_REFERENCES)
        OwnPtr(OwnPtr&&);
        //......
 
        OwnPtr& operator=(OwnPtr&&);
        //......
#endif
 
        //......
 
    private:
#if !COMPILER_SUPPORTS(CXX_RVALUE_REFERENCES)
        // If rvalue references are supported, noncopyable takes care of this.
        OwnPtr& operator=(const OwnPtr&);
#endif
 
        //......
 
        PtrType m_ptr;
    };
 
    //......
 
    template<typename T> inline OwnPtr<T>::OwnPtr(const PassOwnPtr<T>& o)
        : m_ptr(o.leakPtr())
    {
    }
 
    //......
 
    template<typename T> inline PassOwnPtr<T> OwnPtr<T>::release()
    {
        PtrType ptr = m_ptr;
        m_ptr = 0;
        return PassOwnPtr<T>(ptr);
    }
 
    template<typename T> inline typename OwnPtr<T>::PtrType OwnPtr<T>::leakPtr()
    {
        PtrType ptr = m_ptr;
        m_ptr = 0;
        return ptr;
    }
 
    //......
 
    template<typename T> template<typename U> inline OwnPtr<T>& OwnPtr<T>::operator=(const PassOwnPtr<U>& o)
    {
        //......
        PtrType ptr = m_ptr;
        m_ptr = o.leakPtr();
        ASSERT(!ptr || m_ptr != ptr);
        OwnedPtrDeleter<T>::deletePtr(ptr);
        return *this;
    }
 
    //......
 
#if COMPILER_SUPPORTS(CXX_RVALUE_REFERENCES)
    template<typename T> inline OwnPtr<T>::OwnPtr(OwnPtr<T>&& o)
        : m_ptr(o.leakPtr())
    {
    }
 
    //......
 
    template<typename T> inline OwnPtr<T>& OwnPtr<T>::operator=(OwnPtr<T>&& o)
    {
        PtrType ptr = m_ptr;
        m_ptr = o.leakPtr();
        ASSERT(!ptr || m_ptr != ptr);
        OwnedPtrDeleter<T>::deletePtr(ptr);
 
        return *this;
    }
 
    //......
#endif
 
    //......
} // namespace WTF

从OwnPtr类的定义可以看到，OwnPtr智能指针只能通过以下构造函数创建：

template<typename T> inline OwnPtr<T>::OwnPtr(const PassOwnPtr<T>& o)
        : m_ptr(o.leakPtr())
    {
    }

也就是说，我们创建了一个T对象后，只能先用来创建一个PassOwnPtr对象，然后再用该PassOwnPtr对象来创建一个OwnPtr智能指针。

当然，我们也可以使用OwnPtr类的以下构造函数来创建一个没有引用任何目标对象的OwnPtr智能指针：

1 2	OwnPtr() : m_ptr(0) { } OwnPtr(std::nullptr_t) : m_ptr(0) { }

然后，再通过调用操作符重载函数operator=将一个PassOwnPtr对象赋值给OwnPtr智能指针：

template<typename T> template<typename U> inline OwnPtr<T>& OwnPtr<T>::operator=(const PassOwnPtr<U>& o)
    {
        //......
        //对目标对象的引用从PassOwnPtr智能指针转移到了OwnPtr智能指针
        PtrType ptr = m_ptr;
        m_ptr = o.leakPtr();
        //对象与参数o描述的PassOwnPtr智能指针引用的目标对象是不一样的，
        //并且该对象会被释放掉。
        ASSERT(!ptr || m_ptr != ptr);
        OwnedPtrDeleter<T>::deletePtr(ptr);
        return *this;
    }

无论是哪一种方式创建OwnPtr智能指针，都必须先创建一个PassOwnPtr对象。PassOwnPtr类描述的也是一个智能指针，它与OwnPtr的关系有点类似我前面分析的RefPtr与PassRefPtr的关系。也就是说，PassOwnPtr智能指针可以作为函数参数或者函数返回值传递。后面我们再详细分析PassOwnPtr智能指针的创建过程。

PassOwnPtr类有一个成员函数leakPtr，它的作用类似于前面分析的PassRefPtr类的成员函数leakPtr，都是用来放弃一个PassOwnPtr智能指针对目标对象的引用的。在上面描述的两种OwnPtr智能指针创建方式中，被PassOwnPtr智能指针放弃引用的目标对象将被正在创建的OwnPtr智能指针接管。也就是说，对目标对象的引用从PassOwnPtr智能指针转移到了OwnPtr智能指针。

不过对于通过操作符重载函数operator=创建的OwnPtr智能指针，如果它之前有引用其它的目标对象，那么就要求该对象与参数o描述的PassOwnPtr智能指针引用的目标对象是不一样的，并且该对象会被释放掉。也就是说，当一个OwnPtr智能指针要引用新的目标对象时，必须先释放之前引用的旧目标对象。

一个OwnPtr智能指针在超出其生命周期范围之前，如果想要放弃对目标对象的引用，那么可以通过调用OwnPtr类的成员函数release或者leakPtr来实现，如下所示：

template<typename T> inline PassOwnPtr<T> OwnPtr<T>::release()
    {
        PtrType ptr = m_ptr;
        m_ptr = 0;
        return PassOwnPtr<T>(ptr);
    }
 
    template<typename T> inline typename OwnPtr<T>::PtrType OwnPtr<T>::leakPtr()
    {
        PtrType ptr = m_ptr;
        m_ptr = 0;
        return ptr;
    }

OwnPtr类的成员函数release将OwnPtr智能指针放弃引用的目标对象转移给了一个PassOwnPtr智能指针，这意味着可以将一个OwnPtr智能指针转化为一个PassOwnPtr指针，从而使得它引用的目标对象可以作为函数参数或者函数返回值传递。

OwnPtr类的成员函数leakPtr是直接放弃OwnPtr智能指针引用的目标对象，不过它会返回该目标对象的地址值给调用者，也就是将一个指向目标对象的裸指针返回给调用者。

Move语意

我们注意到，OwnPtr类的成员函数leakPtr的返回值类型为OwnPtr::PtrType，它的定义如下所示：

1 2	typedef typename RemoveExtent<T>::Type ValueType; typedef ValueType* PtrType;

RemoveExtent是一个与C++ 11引入的右值引用（Rvalue Reference）有关一个模板类。右值引用通过T&&符号来表示，它主要是用来实现move语意和完美转发（perfect forwarding）。关于右值引用的概念，由于篇幅关系，这里不进行展开，然后强烈建议大家去看看这两篇文章：从4行代码看右值引用和Rvalue Reference Declarator: &&。这里我们只需要知道，ValueType描述的是模板参数T的值类型，而PtrType描述的是模板参数T的裸指针类型，不管我们是使用T、T&还是T&&来推导模板参数。

关于右值引用的move语意，这里值得再解释一下。简单地说，move语意是为了消除临时对象之间的拷贝操作，例如，对于以下表达式来说：

1	string s = string("h") + "e" + "ll" + "o";

string(“h”)会产生一个临时对象。这个临时对象与”e”相加后，又会产生另外一个临时对象。依次类推，直到”o”相加完成之后。而且最后生成的临时对象又会被拷贝给字符串s。这些中间的临时对象都是没有必要生成的，而且字符串s也不需要去拷贝最后生成的临时对象得到。我们完全可以只生成一个临时对象，也就是由string(“h”)产生一个临时对象，此后直接将后面的”e”、”ll”和”o”追加在此临时对象内部的字符缓冲区上，并且最后将该临时对象内部所拥有的字符缓冲区转移给字符串s。这样就可以在一定程度上提高字符串的连接效率，而这就是所谓的move语意，它是与copy意义相对的。

一个类要实现move语意，必须要提供move构造函数和move赋值操作符函数，就好像一个类要实现copy语意，要提供copy构造函数copy赋值操作符函数一样，只不过编译器不会为一个类提供默认的move构造函数和move赋值操作符函数。

我们看到，在编译器支持右值引用的情况下，OwnPtr类实现了move构造函数和move赋值操作符函数，如下所示：

#if COMPILER_SUPPORTS(CXX_RVALUE_REFERENCES)
    template<typename T> inline OwnPtr<T>::OwnPtr(OwnPtr<T>&& o)
        : m_ptr(o.leakPtr())
    {
    }
 
    //......
 
    template<typename T> inline OwnPtr<T>& OwnPtr<T>::operator=(OwnPtr<T>&& o)
    {
        PtrType ptr = m_ptr;
        m_ptr = o.leakPtr();
        ASSERT(!ptr || m_ptr != ptr);
        OwnedPtrDeleter<T>::deletePtr(ptr);
 
        return *this;
    }
 
    //......
#endif

一个类实现的move构造函数和move赋值操作符函数的参数必须是一个右值引用，并且它们的作用是将一个对象拥有的资源转移给另外一个对象。以OwnPtr类为例，一个OwnPtr智能指针拥有的资源就是对目标对象的引用，也就是它的的move构造函数和move赋值操作符函数的作用是将一个OwnPtr智能指针引用的目标对象转移给另外一个OwnPtr智能指针引用。这样就既不违反我们前面说的一个目标对象在同一时刻只能被一个第二类智能指针引用的原则，同时又能够实现OwnPtr类的move语意。

同时，我们也可以看到，在编译器不支持右值引用的情况下，OwnPtr类只是声明了copy构造函数copy赋值操作符函数，但是没有实现它们。这就意味着，我们不能将一个OwnPtr智能指针拷贝给另外一个，因为这会违反我们前面说的一个目标对象在同一时刻只能被一个第二类智能指针引用的原则。

与前面分析的RefPtr和PassRefPtr智能指针类似，OwnPtr智能指针也提供了两个成员操作符重载函数operator*和operator->来直接操作目标对象，例如调用目标对象的成员函数，如下所示：

1 2	ValueType& operator() const { ASSERT(m_ptr); return m_ptr; } PtrType operator->() const { ASSERT(m_ptr); return m_ptr; }

当一个OwnPtr智能指针超出其生命周期范围内时，它所引用的对象就会被释放掉，如下所示：

~OwnPtr()
{
    OwnedPtrDeleter<T>::deletePtr(m_ptr);
    m_ptr = 0;
}

从而就可以起到自动释放不再需要的对象的作用。

从这里可以看到，OwnPtr智能指针是通过模板类OwnedPtrDeleter< T >的成员函数deletePtr来释放目标对象的，这个函数定义在文件external/chromium_org/third_party/WebKit/Source/wtf/OwnPtrCommon.h中，它的实现如下所示：

template <typename T>
struct OwnedPtrDeleter {
    static void deletePtr(T* ptr)
    {
        COMPILE_ASSERT(!IsRefCounted<T>::value, UseRefPtrForRefCountedObjects);
        COMPILE_ASSERT(sizeof(T) > 0, TypeMustBeComplete);
        delete ptr;
    }
};

模板类OwnedPtrDeleter的成员函数deletePtr在编译时会通过宏COMPILE_ASSERT来断言参数ptr描述的对象不是从前面我们分析的RefCountedBase类或者ThreadSafeRefCountedBase继承下来的。这意味着OwnPtr智能指针不能用来引用具有引用计数功能的对象。

这实际上是定义了这样的一个规则：具有引用计数功能的对象，如果要配合智能指针使用，那么就使用RefPtr或者PassRefPtr智能指针；否则的话，就使用OwnPtr或者我们接下来分析的PassOwnPtr智能指针。这个规则要求我们对程序里面实现的类有一个清晰的设计。

宏COMPILE_ASSERT实际上是利用C++ 11引入的static_assert特性来实现的。这个static_assert语句不会对编译后得到的二进制代码有任何影响，纯粹是编译期间使用的，用来在编译期间就能捕捉到错误。

从模板类OwnedPtrDeleter< T >的成员函数deletePtr的实现可以知道，当模板类IsRefCounted的静态成员变量value的值等于true的时候，就说明参数ptr描述的对象是从RefCountedBase类或者ThreadSafeRefCountedBase继承下来的。

模板类IsRefCounted< T >的静态成员变量value的定义如下所示，这个成员变量定义在文件external/chromium_org/third_party/WebKit/Source/wtf/OwnPtrCommon.h中：

template<typename T>
struct IsRefCounted {
    static const bool value = IsSubclass<T, RefCountedBase>::value
        || IsSubclass<T, ThreadSafeRefCountedBase>::value;
};

从这里就可以看到，如果模板参数T是从RefCountedBase类或者ThreadSafeRefCountedBase类继承下来的，那么模板类IsRefCounted< T >的静态成员变量value就会等于true。

判断模板参数T是不是从RefCountedBase类或者ThreadSafeRefCountedBase类继承下来，是通过调用模板类IsSubclass< T >的静态成员变量value来实现的。模板类IsSubclass< T >的静态成员变量value的定义如下所示，这个成员变量定义在文件external/chromium_org/third_party/WebKit/Source/wtf/TypeTraits.h中：


namespace WTF {
    ......
 
    template <typename T, typename U> class IsSubclass {
        typedef char YesType;
        struct NoType {
            char padding[8];
        };
 
        static YesType subclassCheck(U*);
        static NoType subclassCheck(...);
        static T* t;
    public:
        static const bool value = sizeof(subclassCheck(t)) == sizeof(YesType);
    };
 
    //......
}

这里的模板参数U就为RefCountedBase或者ThreadSafeRefCountedBase，判断模板参数T是不是它们的子类用了一个很巧妙方法。

模板类IsSubclass< T >定义了两个版本的静态成员函数subclassCheck，其中一个的参数为U，另一个的参数为可变参数。如果T是从U继承下来的，T就可以自动转化为U，这意味着调用静态成员函数subclassCheck(t)，也就subclassCheck(T)，会自动匹配为参数为U的成员函数subclassCheck。参数为U的成员函数的返回值为YesType，这就意味着参数T是参数U的子类。

注意，sizeof是一个编译器运算符号，当它的参数是一个函数的时候，实际上计算的是该函数的返回值的类型所占据的字节数。由于函数的返回值类型通过声明就可以知道，因此模板类IsSubclass就只是声明了静态成员函数subclassCheck，而没有对应的实现。

前面提到，为了创建OwnPtr智能指针，我们首先要创建PassOwnPtr智能指针。PassOwnPtr智能指针使得OwnPtr智能指针引用的对象也可以作为函数参数或者函数返回值传递，它的定义如下所示，这个类定义在文件external/chromium_org/third_party/WebKit/Source/wtf/PassOwnPtr.h：

namespace WTF {
 
    ......
 
    template<typename T> class PassOwnPtr {
        ......
    public:
        typedef typename RemoveExtent<T>::Type ValueType;
        typedef ValueType* PtrType;
 
        PassOwnPtr() : m_ptr(0) { }
        PassOwnPtr(std::nullptr_t) : m_ptr(0) { }      
 
        ......
  
        PassOwnPtr(const PassOwnPtr& o) : m_ptr(o.leakPtr()) { }
        ......
 
        ~PassOwnPtr() { OwnedPtrDeleter<T>::deletePtr(m_ptr); }
 
        PtrType get() const { return m_ptr; }
 
        PtrType leakPtr() const WARN_UNUSED_RETURN;
 
        ValueType& operator*() const { ASSERT(m_ptr); return *m_ptr; }
        PtrType operator->() const { ASSERT(m_ptr); return m_ptr; }
 
        ......
 
        template<typename U> friend PassOwnPtr<U> adoptPtr(U*);
 
        ......
 
    private:
        explicit PassOwnPtr(PtrType ptr) : m_ptr(ptr) { }
 
        ......
 
        mutable PtrType m_ptr;
    };
 
    ......
 
    template<typename T> inline typename PassOwnPtr<T>::PtrType PassOwnPtr<T>::leakPtr() const
    {
        PtrType ptr = m_ptr;
        m_ptr = 0;
        return ptr;
    }
 
    ......
 
    template<typename T> inline PassOwnPtr<T> adoptPtr(T* ptr)
    {
        return PassOwnPtr<T>(ptr);
    }
 
    ......
};

PassOwnPtr类的实现与OwnPtr类的实现是类似的，最主要的区别在于两点：

PassOwnPtr类提供了一个拷贝构造函数，通过此拷贝构造函数可以用一个PassOwnPtr智能指针构造另外一个PassOwnPtr智能指针，不过这样会导致原来的PassOwnPtr智能指针失去对目标对象的引用，因为目标对象转为被新构造的PassOwnPtr智能指针引用了。这意味着PassOwnPtr智能指针可以用来传递它所引用的目标对象。
PassOwnPtr类有一个友员函数adoptPtr，通过这个友元函数可以调用PassOwnPtr类的一个私有构造函数为一个目标对象创建一个PassOwnPtr智能指针。这意味PassOwnPtr智能指针可以直接引用一个目标对象，而不像OwnPtr智能指针要通过另外一个PassOwnPtr智能指针来引用一个目标对象。

以上就是WebKit实现的第一类智能指针RefPtr/PassRefPtr和第二类智能指针OwnPtr/PassOwnPtr，接下来我们继续分析WebKit实现的弱智能指针。

弱智能指针

WebKit的弱智能指针由WeakPtr类实现，这个类定义在文件external/chromium_org/third_party/WebKit/Source/wtf/WeakPtr.h中，如下所示：

template<typename T>
class WeakPtr {
    ......
public:
    ......
    WeakPtr(PassRefPtr<WeakReference<T> > ref) : m_ref(ref) { }
 
    T* get() const { return m_ref ? m_ref->get() : 0; }
    void clear() { m_ref.clear(); }
 
    ......
 
private:
    RefPtr<WeakReference<T> > m_ref;
};

从WeakPtr类的构造函数可以知道，创建一个WeakPtr弱智能指针需要一个WeakReference对象。这个WeakReference对象就保存在WeakPtr类的成员变量m_ref中。

在使用一个WeakPtr弱智能指针，首先要调用它的成员函数get检查它引用的目标对象是否还存在。如果存在，WeakPtr类的成员函数get就会返回一个指向目标对象的指针给调用者。否则的话，WeakPtr类的成员函数get返回一个空指针。

WeakPtr类的成员函数get又是通过成员变量m_ref描述的一个WeakReference对象的成员函数get检查一个WeakPtr智能指针引用的目标对象是否还存在的。

WeakReference类的实现如下所示，这个类定义在文件external/chromium_org/third_party/WebKit/Source/wtf/WeakPtr.h中：

template<typename T>
class WeakReference : public ThreadSafeRefCounted<WeakReference<T> > {
    ......
public:
    static PassRefPtr<WeakReference<T> > create(T* ptr) { return adoptRef(new WeakReference(ptr)); }
    static PassRefPtr<WeakReference<T> > createUnbound() { return adoptRef(new WeakReference()); }
 
    T* get() const
    {
        ......
        return m_ptr;
    }
 
    void clear()
    {
        ......
        m_ptr = 0;
    }
 
    void bindTo(T* ptr)
    {
        ......
        m_ptr = ptr;
    }
 
private:
    WeakReference() : m_ptr(0) { }
 
    explicit WeakReference(T* ptr)
        : m_ptr(ptr)
          ......
    {
    }
 
    T* m_ptr;
    ......
};

WeakReference类的成员变量m_ptr保存的就是一个WeakPtr弱智能指针所引用的目标对象的地址值。由于WeakPtr弱智能指针所引用的目标对象有可能是已经被销毁了的，因此WeakReference类的成员变量m_ptr保存的可能是一个无效的地址值。

我们可以通过两种方式创建一个WeakReference对象。第一种方式是提供一个目标对象T，然后调用WeakReference类的静态成员函数create来创建。第二种方式是先调用WeakReference类的静态成员函数createUnbound创建一个成员变量m_ptr被初始化0的WeakReference对象，然后再调用该WeakReference对象的成员函数bindTo将成员变量m_ptr指向一个目标对象。

前面提到，一个WeakPtr弱智能指针引用的目标对象有可能是已经被销毁了的。当这种情况发生时，我们需要调用与该WeakPtr弱智能指针与关联的WeakReference对象的成员函数clear，将其成员变量m_ptr的值设置为0。这样以后我们调用该WeakReference对象的成员函数get时，就会得到一个0值。也就是说，当一个WeakPtr弱智能指针引用的目标对象有可能被销毁之后，我们调用它的成员函数get获得的返回值是等于0的。

那么我们是怎么知道一个WeakPtr弱智能指针引用的目标对象正在被销毁的呢？要回答这个问题，我们首先观察WeakPtr弱智能指针是如何使用的。一般来说，如果某一个类的对象可以配合WeakPtr弱智能指针来引用，那么该类在定义时，就需要引入一个类型为WeakPtrFactory的成员变量，如以下的HTMLDocumentParser类所示，external/chromium_org/third_party/WebKit/Source/core/html/parser/HTMLDocumentParser.：

class HTMLDocumentParser :  public ScriptableDocumentParser, private HTMLScriptRunnerHost {
    ......
 
protected:
    ......
 
    HTMLDocumentParser(HTMLDocument&, bool reportErrors);
 
    ......
 
private:
    ......
 
    WeakPtrFactory<HTMLDocumentParser> m_weakFactory;
 
    ......
};

在创建一个HTMLDocumentParser对象的时候，它的成员变量m_weakFactory就会被初始化，如下所示，这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/html/parser/HTMLDocumentParser.cpp中：

HTMLDocumentParser::HTMLDocumentParser(HTMLDocument& document, bool reportErrors)
    : ......
    , m_weakFactory(this)
      ......
{
    ......
}

WeakPtrFactory类的定义如下所示，这个类定义在文件external/chromium_org/third_party/WebKit/Source/wtf/WeakPtr.h中：

template<typename T>
class WeakPtrFactory {
    ......
public:
    explicit WeakPtrFactory(T* ptr) : m_ref(WeakReference<T>::create(ptr)) { }
 
    WeakPtrFactory(PassRefPtr<WeakReference<T> > ref, T* ptr)
        : m_ref(ref)
    {
        m_ref->bindTo(ptr);
    }
 
    ~WeakPtrFactory() { m_ref->clear(); }
 
    // We should consider having createWeakPtr populate m_ref the first time createWeakPtr is called.
    WeakPtr<T> createWeakPtr() { return WeakPtr<T>(m_ref); }
 
    ......
 
private:
    RefPtr<WeakReference<T> > m_ref;
};

回到前面HTMLDocumentParser类的构造函数中，当一个HTMLDocumentParser对象创建时，它的地址值就会作为参数传递给WeakPtrFactory类的以T*为参数的构造函数，以便可以创建一个WeakPtrFactory对象。这个构造函数再以该HTMLDocumentParser对象的地址值为参数，调用WeakReference类的静态成员函数create创建一个WeakReference对象，保存在WeakPtrFactory类的成员变量m_ref中。

当然我们也可以调用WeakPtrFactory类的另外一个构造函数创建一个WeakPtrFactory对象，不过我们需要提供一个WeakReference对象，以及一个目标对象的地址。在这种情况下，WeakPtrFactory类的构造函数除了会将调用者提供的WeakReference对象保存在成员变量m_ref之外，还会将目标对象的地址绑定到调用者提供的WeakReference对象中。

创建好一个WeakPtrFactory对象之后，就可以调用它的成员函数createWeakPtr获取一个WeakPtr弱智能指针了，获取到的WeakPtr弱智能指针是根据WeakPtrFactory对象的成员变量m_ref描述的WeakReference对象创建的。

当一个WeakPtr弱智能指针引用的目标对象被销毁时，例如当一个HTMLDocumentParser对象被销毁时，它的成员变量m_weakFactory描述的WeakPtrFactory对象也会随之销毁，而当一个WeakPtrFactory对象被销毁时，它的析构函数就会被调用，随后这个WeakPtrFactory对象的成员变量m_ref描述的一个WeakReference对象的成员函数clear也会被调用，最后就会导致该WeakReference对象的成员变量m_ptr的值设置为0。这就意味着当一个WeakPtr弱智能指针引用的目标对象被销毁时，与它关联的一个WeakReference对象的成员变量m_ptr的值就会被设置为0，因此这时候调用该WeakPtr弱智能指针的成员函数get，就会获得一个0值。

以上就是WebKit的弱智能指针的实现原理，它的核心就是通过组合方式给目标对象关联一个类型为WeakPtrFactory的成员变量，使得目标对象销毁时，该成员变量指向的WeakPtrFactory对象被析构。一个WeakPtrFactory对象在析构的过程中，又会将其内部的一个WeakReference对象的成员变量m_ptr的值设置为0。由于该WeakReference对象又是与WeakPtr弱智能指针关联的，因此WeakPtr弱智能指针通过该WeakReference对象的成员变量m_ptr就可以知道它所引用的目标是否已经被销毁。

Chromium智能指针

接下来我们继续分析Chromium实现的第一类智能指针和第二类智能指针，以及弱智能指针。

第一类智能指针

Chromium的第一类智能指针由类scoped_refptr实现。由于它要求被引用对象具有计数功能，因此就提供了一个具有计数功能的基类RefCounted。当一个对象可以被类scoped_refptr描述的对象引用时，它就必须要从基类RefCounted继承下来。这一点与WebKit的第一类智能指针RefPtr是类似的。

Chromium的RefCounted类的实现如下所示，这个类定义在文件external/chromium_org/base/memory/ref_counted.h中：

template <class T>
class RefCounted : public subtle::RefCountedBase {
 public:
  RefCounted() {}
 
  void AddRef() const {
    subtle::RefCountedBase::AddRef();
  }
 
  void Release() const {
    if (subtle::RefCountedBase::Release()) {
      delete static_cast<const T*>(this);
    }
  }
 
 ......
};

Chromium的RefCounted类定义了两个成员函数AddRef和Release，分别用来增加和减少目标对象的1个引用计数，并且都是通过调用父类RefCountedBase的成员函数AddRef和Release来实现的。当减少目标对象的1引用计数之后，如果目标对象的引用计数变为0，那么目标对象就会被delete掉。

Chromium的RefCountedBase类的定义如下所示，这个类定义在文件external/chromium_org/base/memory/ref_counted.h中：

class BASE_EXPORT RefCountedBase {
 ......
 protected:
  RefCountedBase()
      : ref_count_(0)
  ......
      {
  }
 
  ......
 
  void AddRef() const {
    ......
    ++ref_count_;
  }
 
  bool Release() const {
    ......
    if (--ref_count_ == 0) {
      ......
      return true;
    }
    return false;
  }
 
 private:
  mutable int ref_count_;
 
  ......
};

Chromium的RefCountedBase类与WebKit的RefCountedBase类也是几乎一样，都是提供了非线程安全版本的计数功能。
Chromium提供的线程安全版本的具有计数功能的基类是RefCountedThreadSafe，它的实现如下所示，这个类定义在文件external/chromium_org/base/memory/ref_counted.h中：

template <class T, typename Traits = DefaultRefCountedThreadSafeTraits<T> >
class RefCountedThreadSafe : public subtle::RefCountedThreadSafeBase {
 public:
  ......
 
  void AddRef() const {
    subtle::RefCountedThreadSafeBase::AddRef();
  }
 
  void Release() const {
    if (subtle::RefCountedThreadSafeBase::Release()) {
      Traits::Destruct(static_cast<const T*>(this));
    }
  }
 
  ......
 
 private:
  friend struct DefaultRefCountedThreadSafeTraits<T>;
  static void DeleteInternal(const T* x) { delete x; }
  ......
};

Chromium的RefCountedThreadSafe类与RefCountedBase类的实现也类似，不过有两点区别：

RefCountedThreadSafe类是从RefCountedThreadSafeBase类继承下来的，后者提供了线程安全版本的计数功能。
RefCountedThreadSafe类可以通过模板参数Traits指定一个类，当它引用的目标对象的引用计数等于0的时候，就会调用该参数Traits指定的类的静态成员函数Destruct来释放目标对象。

第2点是很有用的。比如我们在一个线程创建一个T对象，这个T对象可能会被其它线程引用。当这个T对象的引用计数是在其它线程减少为0时，我们希望它不要在其它线程释放，而是要在创建线程进行释放，那么就可以通过指定参数Traits来实现。

如果没有指定模板参数Traits，那么它的默认值就为DefaultRefCountedThreadSafeTraits。这个DefaultRefCountedThreadSafeTraits类的实现如下所示，这个类定义在文件external/chromium_org/base/memory/ref_counted.h中：

template<typename T>
struct DefaultRefCountedThreadSafeTraits {
  static void Destruct(const T* x) {
    ......
    RefCountedThreadSafe<T,
                         DefaultRefCountedThreadSafeTraits>::DeleteInternal(x);
  }
};

DefaultRefCountedThreadSafeTraits类的静态成员函数Destruct又是通过调用RefCountedThreadSafe类的静态成函数DeleteInternal来释放目标对象的。从RefCountedThreadSafe类的实现可以知道，它的静态成员函数DeleteInternal是直接将目标对象delete掉。

我们再来看RefCountedThreadSafe类的父类RefCountedThreadSafeBase的实现，如下所示，这个类定义在文件external/chromium_org/base/memory/ref_counted.h中：

class BASE_EXPORT RefCountedThreadSafeBase {
 ......
 
 protected:
  ......
 
  void AddRef() const;
 
  // Returns true if the object should self-delete.
  bool Release() const;
 
 private:
  mutable AtomicRefCount ref_count_;
  ......
};

RefCountedThreadSafeBase类提供了两个成员函数AddRef和Release，用来执行线程安全的引用计数加1和减1操作，它们的实现如下所示，这两个函数定义在文件external/chromium_org/base/memory/ref_counted.cc中：

void RefCountedThreadSafeBase::AddRef() const {
  ......
  AtomicRefCountInc(&ref_count_);
}
 
bool RefCountedThreadSafeBase::Release() const {
  ......
  if (!AtomicRefCountDec(&ref_count_)) {
    ......
    return true;
  }
  return false;
}

RefCountedThreadSafeBase类的成员函数AddRef和Release分别通过函数AtomicRefCountInc和AtomicRefCountDec对目标对象的引用计数执行原子性的加1和减1操作，因此它们是线程安全的。

有了RefCounted和ThreadSafeRefCounted这两个基类为对象提供计数功能之后，我们就继续分析Chromium的第一类智能指针scoped_refptr的实现，如下所示，这个类定义在文件external/chromium_org/base/memory/ref_counted.h中。：

template <class T>
class scoped_refptr {
 public:
  typedef T element_type;
 
  scoped_refptr() : ptr_(NULL) {
  }
 
  scoped_refptr(T* p) : ptr_(p) {
    if (ptr_)
      ptr_->AddRef();
  }
 
  scoped_refptr(const scoped_refptr<T>& r) : ptr_(r.ptr_) {
    if (ptr_)
      ptr_->AddRef();
  }
 
  template <typename U>
  scoped_refptr(const scoped_refptr<U>& r) : ptr_(r.get()) {
    if (ptr_)
      ptr_->AddRef();
  }
 
  ~scoped_refptr() {
    if (ptr_)
      ptr_->Release();
  }
 
  T* get() const { return ptr_; }
 
  // Allow scoped_refptr<C> to be used in boolean expression
  // and comparison operations.
  operator T*() const { return ptr_; }
 
  T* operator->() const {
    assert(ptr_ != NULL);
    return ptr_;
  }
 
  scoped_refptr<T>& operator=(T* p) {
    // AddRef first so that self assignment should work
    if (p)
      p->AddRef();
    T* old_ptr = ptr_;
    ptr_ = p;
    if (old_ptr)
      old_ptr->Release();
    return *this;
  }
 
  ......
 
 protected:
  T* ptr_;
};

Chromium的scoped_refptr类的实现与WebKit的RefPtr类的实现几乎是一样的，并且都是要求目标对象是从RefCounted类或者ThreadSafeRefCounted类继承下来的，因此我们就不再详述。

为了方便创建scoped_refptr智能指针，Chromium提供了一个帮助函数make_scoped_refptr，这个函数定义在文件external/chromium_org/base/memory/ref_counted.h中，它的实现如下所示：

template <typename T>
scoped_refptr<T> make_scoped_refptr(T* t) {
  return scoped_refptr<T>(t);
}

函数make_scoped_refptr调用scoped_refptr类的构造函数直接将参数t封装成一个scoped_refptr智能指针，然后返回给调用者。

第二类智能指针

接下来我们再看Chromium的第二类智能指针的实现，它由类scoped_ptr实现，这个类定义在文件external/chromium_org/base/memory/scoped_ptr.h中，如下所示：

template <class T, class D = base::DefaultDeleter<T> >
class scoped_ptr {
  MOVE_ONLY_TYPE_FOR_CPP_03(scoped_ptr, RValue)
 
  COMPILE_ASSERT(base::internal::IsNotRefCounted<T>::value,
                 T_is_refcounted_type_and_needs_scoped_refptr);
 
 public:
  // The element and deleter types.
  typedef T element_type;
  typedef D deleter_type;
 
  // Constructor.  Defaults to initializing with NULL.
  scoped_ptr() : impl_(NULL) { }
 
  // Constructor.  Takes ownership of p.
  explicit scoped_ptr(element_type* p) : impl_(p) { }
 
  // Constructor.  Allows initialization of a stateful deleter.
  scoped_ptr(element_type* p, const D& d) : impl_(p, d) { }
 
  ......
 
  // Constructor.  Move constructor for C++03 move emulation of this type.
  scoped_ptr(RValue rvalue) : impl_(&rvalue.object->impl_) { }
 
  ......
 
  // Accessors to get the owned object.
  // operator* and operator-> will assert() if there is no current object.
  element_type& operator*() const {
    ......
    return *impl_.get();
  }
  element_type* operator->() const  {
    ......
    return impl_.get();
  }
  element_type* get() const { return impl_.get(); }
 
  ......
 
  template <typename PassAsType>
  scoped_ptr<PassAsType> PassAs() {
    return scoped_ptr<PassAsType>(Pass());
  }
 
 private:
  ......
  base::internal::scoped_ptr_impl<element_type, deleter_type> impl_;
 
  ......
};

Chromium的scoped_ptr类与WebKit的OwnPtr类的实现也是类似的：

通过宏COMPILE_ASSERT以及IsNotRefCounted类的静态成员变量value禁止scoped_ptr智能指针引用的目标对象从RefCounted类或者ThreadSafeRefCounted类继承下来，也就是不要求目标对象具有引用计数功能。
通过宏MOVE_ONLY_TYPE_FOR_CPP_03禁止scoped_ptr智能指针的copy语意，但是提供move语意。

不同的地方在于：

可以直接根据目标对象创建scoped_ptr智能指针。WebKit要先根据目标对象创建PassOwnPtr智能指针，再根据PassOwnPtr智能指针创建OwnPtr智能指针。
Chromium不像WebKit一样，单独提供了一个可以用来传递目标对象的PassOwnPtr智能指针，而是直接在scoped_ptr智能指针中集成了该功能，也就是通过scoped_ptr类的成员函数PassAs来实现。
scopedptr类将引用的目标对象间接保存在成员变量impl描述的一个scoped_ptr_impl对象中。

类scoped_ptr_impl的实现如下所示，这个类定义在文件external/chromium_org/base/memory/scoped_ptr.h中：

class scoped_ptr_impl {
 public:
  explicit scoped_ptr_impl(T* p) : data_(p) { }
 
  // Initializer for deleters that have data parameters.
  scoped_ptr_impl(T* p, const D& d) : data_(p, d) {}
 
  template <typename U typename V>
  scoped_ptr_impl(scoped_ptr_impl<U, V>* other)
      : data_(other->release(), other->get_deleter()) {
    ......
  }
 
  ......
 
  ~scoped_ptr_impl() {
    if (data_.ptr != NULL) {
      ......
      static_cast<D&>(data_)(data_.ptr);
    }
  }
 
  ......
 
  T* get() const { return data_.ptr; }
 
  ......
 
  T* release() {
    T* old_ptr = data_.ptr;
    data_.ptr = NULL;
    return old_ptr;
  }
 
  ......
 
 private:
  ......
 
  struct Data : public D {
    explicit Data(T* ptr_in) : ptr(ptr_in) {}
    Data(T* ptr_in, const D& other) : D(other), ptr(ptr_in) {}
    T* ptr;
  };
 
  Data data_;
 
  ......
};

类scoped_ptrimpl将目标对象保存在成员变量data描述的一个Data对象的成员变量ptr中。同时，我们可以通过模板参数D指定一个类，当scoped_ptr_impl智能指针超出其生命周期范围时，目标对象通过调用该类的操作符重载函数operator()来释放。这一点与scoped_refptr智能指针的实现是类似的。

此外，类scoped_ptr_impl还提供了一个release成员函数和一个拷贝构造函数，前者用来释放对目标对象的引用，后者却不是直接将参数描述的scoped_ptr_impl对象拷贝到当前正在构造的scoped_ptr_impl对象，而是将参数描述的scoped_ptr_impl对象引用的目标对象转移给当前构造的scoped_ptr_impl对象，因此这个构造函数实现的实际上是一个move语意的构造函数，而不是一个copy语意的构造函数。

Move语意

接下来，我们继续分析scoped_ptr智能指针是如何通过宏MOVE_ONLY_TYPE_FOR_CPP_03来禁止copy语意和实现move语意义的。

宏MOVE_ONLY_TYPE_FOR_CPP_03的定义如下所示，这个宏定义在文件external/chromium_org/base/move.h中：

#define MOVE_ONLY_TYPE_FOR_CPP_03(type, rvalue_type) \
 private: \
  struct rvalue_type { \
    explicit rvalue_type(type* object) : object(object) {} \
    type* object; \
  }; \
  type(type&); \
  void operator=(type&); \
 public: \
  operator rvalue_type() { return rvalue_type(this); } \
  type Pass() { return type(rvalue_type(this)); } \
  typedef void MoveOnlyTypeForCPP03; \
 private:

因此，scoped_ptr类内部的宏MOVE_ONLY_TYPE_FOR_CPP_03(scoped_ptr, RValue)展开后就得到：

private:
  struct RValue { 
    explicit RValue(scoped_ptr* object) : object(object) {}
    scoped_ptr* object; 
  }; 
  scoped_ptr(scoped_ptr&);
  void operator=(scoped_ptr&);
 public:
  operator RValue() { return RValue(this); }
  scoped_ptr Pass() { return scoped_ptr(RValue(this)); }
  typedef void MoveOnlyTypeForCPP03;
 private:

这意味着在scoped_ptr类的内部，有一个结构体RValue。这个RValue结构体就是用来实现C++ 11的右值引用的，但是这里不是通过T&&关键字来描述右值引用的。这意味着即使是在不支持C++ 11的编译器中，scoped_ptr也能实现move语意。

同时，scoped_ptr类的拷贝构造函数和赋值操作符函数被声明为私有的，并且没有相应的实现。这意味着scoped_ptr智能指针不能拷贝给另外一个scoped_ptr智能指针，因为这样会违反一个目标对象在同一时刻被多个第二类智能指针引用的原则。

此外，scoped_ptr类提供了两个成员函数RValue和Pass。其中，前者用来将一个scoped_ptr智能指针封装成一个RValue结构体，也就是一个右值引用，后者将一个scoped_ptr智能指针引用的目标对象转移给另外一个scoped_ptr智能指针。scoped_ptr类的这两个成员函数以及以const RValue&为参数的构造函数一起实现了scoped_ptr智能指针的move语意。

我们通过以下代码片断说明scoped_ptr智能指针的move语意的实现过程，如下所示：

1 2	scoped_ptr<T> p1(new T()); scoped_ptr<T> p2 = p1.Pass();

首先，scoped_ptr智能指针p1引用了一个目标对象，接着，我们要将scoped_ptr智能指针p1引用的目标对象转移给scoped_ptr智能指针p2。
调用scoped_ptr智能指针p1的成员函数Pass的时候，发生了以下事情：

创建了一个RValue临时对象。
创建了一个scoped_ptr临时对象。

第2步创建的scoped_ptr临时对象接下来被赋值给scoped_ptr智能指针p2，这时候又会发生以下事情：

由于scoped_ptr类的拷贝构造函数被声明为私有的，并且没相应的实现，因此，上述创建的scoped_ptr临时对象不能通过scoped_ptr类的拷贝构造函数来构造scoped_ptr智能指针p2，也就是不能通过scoped_ptr类的拷贝构造函数将scoped_ptr智能指针p1引用的目标对象转移给scoped_ptr智能指针p2。
scoped_ptr类实现了一个以const RValue&为参数的构造函数，因此前面创建的scoped_ptr临时对象首先会被scoped_ptr类的操作符成员函数operator RValue转化为一个临时的RValue对象。

在scoped_ptr类以const RValue&为参数的构造函数的调用过程中又会发生以下事：

参数rvalue描述的RValue对象的成员变量object描述的scoped_ptr智能指针（也就是scopedptr智能指针p1）的成员变量impl将会用来初始化正在构造的智能指针（也就是scopedptr智能指针p2）的成员变量impl，也就是会调用前面分析的scoped_ptr_impl类的拷贝构造函数。
由于scoped_ptr_impl类的拷贝构造函数实现的是move语意的拷贝操作，因此当它执行完成之后，scoped_ptr智能指针p1引用的目标对象将会转移到给scoped_ptr智能指针p2引用，也就是说，scoped_ptr智能指针p1自动放弃了对目标对象的引用。

因此，通过调用scoped_ptr类的成员函数Pass，就能够将一个scoped_ptr智能指针引用的目标对象转移到另外一个scoped_ptr智能指针，也就是实现了scoped_ptr智能指针的move语意。此外，scoped_ptr类还提供了另外一个成员函数PassAs，它的作用与成员函数Pass是一样的。

弱智能指针

接下来我们再看Chromium的弱智能指针的实现，它由类WeakPtr实现。我们首先给出WeakPtr类的关系图，如图1所示：

WeakPtr类继承于WeakPtrBase类。WeakPtrBase类有一个成员变量ref_，它指向一个WeakReference对象。WeakPtr类实现弱智能指针的功能的关键点就在于这个WeakReference对象，那么这个WeakReference对象是怎么来的呢？

一个对象如果需要被弱智能指针引用，那么它所属的类就必须要继承于SupportsWeakPtr类。SupportsWeakPtr类又是继承于SupportsWeakPtrBase类的。SupportsWeakPtrBase类有一个静态成员函数StaticAsWeakPtr，用来将一个间接继承于SupportsWeakPtr类的子类对象封装成一个WeakPtr弱智能指针。

SupportsWeakPtr类有一个成员函数AsWeakPtr，用来将一个SupportsWeakPtr子类对象封装成一个WeakPtr弱智能指针。在封装的过程中，需要用到成员变量weak_referenceowner指向的一个WeakReferenceeOwner对象。

WeakReferenceeOwner类有一个成员变量flag_，它指向一个Flag对象。这个Flag对象有一个布尔类型的成员变量isvalid。当一个WeakReferenceeOwner对象所属的SupportsWeakPtr对象被销毁时，也就是它的析构函数被调用的时候，这个WeakReferenceeOwner对象的成员函数Invalidate就会被调用。WeakReferenceeOwner类的成员函数Invalidate又会进一步调用成员变量flag_指向的一个Flag对象的成员函数Invalidate，将该Flag对象的成员变量isvalid的值设置为false，表示一个相应的SupportsWeakPtr对象被销毁了。

当我们调用SupportsWeakPtr类的成员函数AsWeakPtr来获得一个WeakPtr弱智能指针时，SupportsWeakPtr类的成员函数AsWeakPtr先会调用成员变量weak_referenceowner指向的一个WeakReferenceeOwner对象的成员函数GetRef创建一个WeakReference对象，这个WeakReference对象通过成员变量flag引用了上述的WeakReferenceeOwner对象的成员变量flag指向的一个Flag对象。这意味在图1中，WeakReferenceeOwner类和WeakReference对象的成员变量flag_指向的都是同一个Flag对象。

这相当于就是通过一个共同的Flag对象将一个WeakPtr弱智能指针与它所引用的目标对象关联起来，这样我们需要使用一个WeakPtr弱智能指针所引用的目标对象时，就可以通过上述的共同Flag对象的成员函数IsValid来判断目标对象是否已经被销毁，实际上就是判断该Flag对象的成员变量isvalid是否等于true。

为了更清楚地表达图1所示的WeakPtr类关系图，接下来我们通过代码来分析该类关系图中涉及到的每一个类。

我们首先看SupportsWeakPtrBase类的实现，这个类定义在文件external/chromium_org/base/memory/weak_ptr.h中，如下所示：

class SupportsWeakPtrBase {
 public:
  ......
  template<typename Derived>
  static WeakPtr<Derived> StaticAsWeakPtr(Derived* t) {
    ......
    return AsWeakPtrImpl<Derived>(t, *t);
  }
 
 private:
  ......
  template <typename Derived, typename Base>
  static WeakPtr<Derived> AsWeakPtrImpl(
      Derived* t, const SupportsWeakPtr<Base>&) {
    WeakPtr<Base> ptr = t->Base::AsWeakPtr();
    return WeakPtr<Derived>(ptr.ref_, static_cast<Derived*>(ptr.ptr_));
  }
};

前面提到，一个类如果要配合WeakPtr弱智能指针使用，那么该类必须要从SupportsWeakPtr继承下来，如下所示：

1	class Base : public base::SupportsWeakPtr<Base> {};

这时候如果有一个类Derived又继承了Base类，如下所示：

1	class Derived : public Base {};

这时候如果我们有一个Derived对象，并且想创建一个WeakPtr智能指针引用该Derived对象，那么是不能调用从父类Base继承下来的成员函数AsWeakPtr来创建的，如下所示：

1 2	Derived derived; base::WeakPtr<Derived> ptr = derived.AsWeakPtr();

这是因为SupportsWeakPtr< Base >类的成员函数AsWeakPtr返回的是一个WeakPtr< Base >对象，并且这个WeakPtr< Base >对象不能自动转换为一个WeakPtr< Derived >对象。‘

为了能够实现上述转换，我们要使用到一个AsWeakPtr函数，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.h中，它的实现如下所示：


template <typename Derived>
WeakPtr<Derived> AsWeakPtr(Derived* t) {
  return internal::SupportsWeakPtrBase::StaticAsWeakPtr<Derived>(t);
}

有了这个AsWeakPtr函数之后，就可以通过下面的代码来创建一个WeakPtr< Derived >对象：

1 2	Derived derived; base::WeakPtr<Derived> ptr = base::AsWeakPtr(&derived);

函数AsWeakPtr调用了SupportsWeakPtrBase类的静态成员函数StaticAsWeakPtr，后者又通过调用SupportsWeakPtrBase类的静态成员函数AsWeakPtrImpl创建了一个WeakPtr< Derived >对象。

SupportsWeakPtrBase类的静态成员函数AsWeakPtrImpl首先是调用参数t描述的一个Derived对象从父类Base继承下来的成员函数AsWeakPtr来创建一个WeakPtr< Base >对象。每一个WeakPtr< Base >对象都有一个成员变量ptr_，它保存的就是WeakPtr对象所引用的目标对象的地址值。有了目标对象的地址值之后，就可以将它转化一个Derived指针。这里能够转换成功，是因为Derived类是继承于Base类的。有了这个Derived指针之后，再结合前面获得的WeakPtr对象的成员变量ref_r描述的一个WeakReference对象之后，就可以通过模板类WeakPtr< Derived >的构造函数来创建一个WeakPtr< Derived >对象了，也就是创建一个引用了Derived对象的WeakPtr智能指针了。后面我们分析WeakPtr类的实现时，就会更清楚地理解上述过程。

接着我们看SupportsWeakPtr类的实现，这个类定义在文件external/chromium_org/base/memory/weak_ptr.h中，如下所示：


template <class T>
class SupportsWeakPtr : public internal::SupportsWeakPtrBase {
 public:
  ......
 
  WeakPtr<T> AsWeakPtr() {
    return WeakPtr<T>(weak_reference_owner_.GetRef(), static_cast<T*>(this));
  }
 
  ......
 
 private:
  internal::WeakReferenceOwner weak_reference_owner_;
  ......
};

SupportsWeakPtr类最主要的就是通过成员变量weak_referenceowner引用了一个WeakReferenceOwner对象。

WeakReferenceOwner类的定义如下所示，这个类定义在文件external/chromium_org/base/memory/weak_ptr.h中：

class BASE_EXPORT WeakReferenceOwner {
 public:
  ......
  ~WeakReferenceOwner();
 
  WeakReference GetRef() const;
 
  ......
 
  void Invalidate();
 
 private:
  mutable scoped_refptr<WeakReference::Flag> flag_;
};

WeakReferenceOwner类最主要的就是通过成员变量flag_引用了一个Flag对象。注意，这个成员变量通过scoped_refptr智能指针来引用Flag对象。这意味着Flag类是具有引用计数功能的。

Flag类的定义如下所示，这个类定义在文件external/chromium_org/base/memory/weak_ptr.h中：

class BASE_EXPORT WeakReference {
 public:
  ......
  class BASE_EXPORT Flag : public RefCountedThreadSafe<Flag> {
   public:
    Flag();
 
    void Invalidate();
    bool IsValid() const;
 
   private:
    ......
 
    bool is_valid_;
  };
 
  ......
};

Flag类继承于RefCountedThreadSafe类，因此它就具有引用计数功能，并且在增加和减少引用计数时是线程安全的。

现在我们分析前面列出的SupportsWeakPtr类的成员函数AsWeakPtr的实现，它首先是调用成员变量weak_referenceowner指向的一个WeakReferenceOwner对象的成员函数GetRef获得一个WeakReference对象，然后再通过WeakPtr类的构造函数创建一个WeakPtr弱智能指针。

WeakReferenceOwner类的成员函数GetRef的实现如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

WeakReference WeakReferenceOwner::GetRef() const {
  // If we hold the last reference to the Flag then create a new one.
  if (!HasRefs())
    flag_ = new WeakReference::Flag();
 
  return WeakReference(flag_.get());
}

WeakReferenceOwner类的成员函数GetRef首先是调用成员函数HasRefs判断成员变量flag是否指向了一个Flag对象。如果不是，那么就需要创建一个Flag对象，并且保存在成员变量flag中。

WeakReferenceOwner类的成员函数GetRef接下来再以成员变量flag_指向的Flag对象为参数，创建一个WeakReference对象。

WeakReference类的定义如下所示，这个类定义在文件external/chromium_org/base/memory/weak_ptr.h中：


class BASE_EXPORT WeakReference {
 public:
  ......
 
  explicit WeakReference(const Flag* flag);
  
  ......
 
 private:
  scoped_refptr<const Flag> flag_;
};

WeakReference类以const Flag*为参数的构造函数的实现如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

1 2	WeakReference::WeakReference(const Flag* flag) : flag_(flag) { }

它主要就是用参数flag描述的一个Flag对象来初始化成员变量flag_描述的一个scoped_refptr智能指针。

回到SupportsWeakPtr类的成员函数AsWeakPtr中，得到了一个WeakReference对象之后，就可以创建一个WeakPtr对象了。

WeakPtr类的定义如下所示，这个类定义在文件external/chromium_org/base/memory/weak_ptr.h中：

template <typename T>
class WeakPtr : public internal::WeakPtrBase {
 public:
  ......
 
  template <typename U>
  WeakPtr(const WeakPtr<U>& other) : WeakPtrBase(other), ptr_(other.ptr_) {
  }
 
  T* get() const { return ref_.is_valid() ? ptr_ : NULL; }
 
  T& operator*() const {
    ......
    return *get();
  }
  T* operator->() const {
    ......
    return get();
  }
 
  ......
 
 private:
  ......
 
  WeakPtr(const internal::WeakReference& ref, T* ptr)
      : WeakPtrBase(ref),
        ptr_(ptr) {
  }
 
  .....
  T* ptr_;
};

从这里就可以看到，WeakPtr类是从WeakPtrBase类继承下来的，后者的定义如下所示，这个类定义在文件external/chromium_org/base/memory/weak_ptr.h中：

class BASE_EXPORT WeakPtrBase {
 public:
  ......
 
 protected:
  explicit WeakPtrBase(const WeakReference& ref);
 
  WeakReference ref_;
};

WeakPtrBase类主要就是通过成员变量ref_引用一个WeakReference对象。

当我们调用WeakPtr类的构造函数将一个WeakReference对象和一个目标对象封装成一个WeakPtr对象的时候，WeakPtr类的构造函数会调用父类WeakPtrBase的构造函数将上述WeakReference对象保存在其成员变量ref_中，如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

1
2
3


WeakPtrBase::WeakPtrBase(const WeakReference& ref) : ref_(ref) {
}

再回到WeakPtr类以WeakReference对象和T对象指针为参数的构造函数中，它将WeakReference对象保存在父类WeakPtrBase的成员变量ref之后，还会将T对象指针保存在自己的成员变量ptr中，该成员变量描述的就是一个WeakPtr弱智能指针所引用的目标对象。

这里有一点需要注意的是，WeakPtr类的成员变量ptr_指向的T对象有可能是已经被销毁了的，这是因为弱智能指针不能阻止它所引用的对象被销毁。也就是说，当我们在使用一个WeakPtr弱智能指针的时候，它所引用的目标对象有可能是已经被销毁的。我们可以通过WeakPtr类的成员函数get来判断一个WeakPtr弱智能指针所引用的目标对象是否已经被销毁。

WeakPtr类的成员函数get调用从父类WeakPtrBase继承下来的成员变量ref_指向的一个WeakReference对象的成员函数isvalid判断一个WeakPtr弱智能指针所引用的目标对象是否已经被销毁。如果还没有被销毁，那么就说明WeakPtr类的成员变量ptr描述的对象地址是有效的，因此就将它返回调用者。如果已经被销毁，那么就返回一个NULL值给调用者。

WeakReference类的成员函数is_valid的实现如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

1	bool WeakReference::is_valid() const { return flag_.get() && flag_->IsValid(); }

WeakReference类的成员函数isvalid首先判断成员变量flag是否指向了一个Flag对象。如果指向了一个Flag对象，那么就调用它的成员函数IsValid判断它所关联的一个对象是否还存活。

Flag类的成员函数IsValid的实现如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

bool WeakReference::Flag::IsValid() const {
  ......
  return is_valid_;
}

Flag类的成员函数IsValid直接将成员变量isvalid的值返回给调用者。

从前面分析的WeakReferenceOwner类的成员函数GetRef可以知道，上述的Flag对象即为目标对象通过WeakReferenceOwner类的关联的那个Flag对象，这个Flag对象在创建的时候，它的成员变量isvalid被设置为true，如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

1
2
3

WeakReference::Flag::Flag() : is_valid_(true) {
  ......
}

当一个Flag对象的宿主WeakReferenceOwner对象被析构时，就会将它的成员变量isvalid的值设置为false，如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

1
2
3

WeakReferenceOwner::~WeakReferenceOwner() {
  Invalidate();
}

WeakReferenceOwner类的析构函数调用了另外一个成员函数Invalidate，它的实现如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

void WeakReferenceOwner::Invalidate() {
  if (flag_.get()) {
    flag_->Invalidate();
    flag_ = NULL;
  }
}

WeakReferenceOwner类的成员函数Invalidate首先检查成员变量flag_是否指向了一个Flag对象。如果指向了，那么就调用该Flag对象的成员函数Invalidate将它的成员变量isvalid的值设置为false，如下所示，这个函数定义在文件external/chromium_org/base/memory/weak_ptr.cc中：

void WeakReference::Flag::Invalidate() {
  ......
  is_valid_ = false;
}

那么，一个WeakReferenceOwner对象什么时候会被析构呢？前面提到，SupportsWeakPtr类有一个成员变量weak_referenceowner描述的是一个WeakReferenceOwner对象。这意味着当一个SupportsWeakPtr对象被析构时，它的成员变量weak_referenceowner描述的是一个WeakReferenceOwner对象也会随之析构。

SupportsWeakPtr类是作为一个被WeakPtr弱智能指针引用的目标对象的父类的，因此当一个WeakPtr弱智能指针引用的目标对象被析构时，目标对象的父类SupportsWeakPtr有的成员变量weak_referenceowner描述的是一个WeakReferenceOwner对象就会被析构，随后又会将与该WeakReferenceOwner对象关联的Flag对象的成员变量isvalid的值设置为true，最后WeakPtr弱智能指针就可以通过该Flag对象的成员函数IsValid判断出它所引用的目标对象是否已经被销毁，从而就实现它作为弱智能指针的作用。

以上就是Chromium的弱智能指针的实现原理。与WebKit的弱智能指针的实现原理相比，两者都是通过为目标对象关联一个额外的对象来实现的。这个额外的对象的生命周期比目标对象长，也就是说，即使目标对象不存在，该额外的对象也可以继续存在，直到所有引用了该目标对象的弱智能指针都超出其生命周期范围之后。不过两者也有不同的地方，例如，Chromium的弱智能指针是通过继承方式关联额外的对象的，而WebKit的弱智指针是通过组合方式关联额外的对象的。

总结

至此我们也分析完成了Chromium的智能指针的实现。最后结合Android系统的智能指针（轻量级指针、强指针和弱指针）的实现原理分析这篇文章，我们总结一下WebKit、Chromium和Android的智能指针的实现的主要相同点与不同点：

WebKit和Chromium的智能指针分别提供了线程不安全和线程安全两个版本的具有引用计数功能的基类RefCounted和ThreadSafeRefCounted。这样我们在设计一个类的时候，就需要考虑这个类的对象是否会在多线程环境下被访问。如果是的话，那么需要选择ThreadSafeRefCounted作为基类。否则的话，选择RefCounted作为基类就可以了。由于RefCounted在增加和减少引用计数时，不需要执行原子操作，因此效率就会更高。Android的智能指针只提供了线程安全版本的具有引用计数功能的基类RefBase和LightRefBase。其中，继承了RefBase类的子类的对象可以配合强指针和弱指针使用，而继承了LightRefBase类的子类的对象只可以配合轻量级指针使用。
WebKit和Chromium同时提供了引用计数版本和非引用计数版本的智能指针的实现，即RefPtr和scoped_refptr，以及OwnPtr和scoped_ptr。Android没有提供非引用计数版本的智能指针的实现。
WebKit优化了智能指针作为函数参数和函数返回值传递目标对象的过程，避免对目标对象的引用计数进行频繁的加1和减1操作，这是通过PassRefPtr类和PassOwnPtr类实现的。Chromium和Android没有提供此类智能指针的实现。
WebKit和Chromium的智能指针都实现了move语意，但是Android的智能指针没有实现move语意。
Chromium和Android的弱智能指针是通过继承方式关联一个生命周期比目标对象更长的额外对象来实现的，而WebKit的弱智能指针则是通过组合方式关联一个生命周期比目标对象更长的额外对象来实现的。
WebKit和Chromium在实现一个类的时候，可以选择是否需要同时支持强智能指针和弱智能指针，但是Android在实现一个类的时候，对强智能指针和弱智能指针的支持是整体的，也就是要么同时支持强智能指针和弱智能指针，要么同时不支持强智能指针和弱智能指针。

从上面这6点总结就可以看出，WebKit和Chromium的智能指针设计更加精细化和组件化，开发者在设计一个类的时候，可以根据需要有选择地实现相应的智能指针功能，而Android的智能指针设计相对来说就比较粗略，没有太多可选择的余地。

Chromium学习之路-启动篇

2019-03-19T09:58:11.000Z

深思熟虑之后，觉得有必要学一下UI渲染技术和JS引擎技术，为以后的跨平台实现打下坚实的基础。
本篇是一篇科普，将打开苦逼又刺激的Chromium学习之路。

Google Chrome的历史和指导性原则

Google Chrome最初是2008年下半年作为Windows平台上的一个beta版本发布的。Google还将自己编写的Chrome在BSD许可下进行了开源——称为Chromium。在很多人看来，这一串事件的发生颇为意外：浏览器战争要再次重启了吗？Google真的能做的更好吗？

“它非常优秀让我不得不改变主意……”。埃里克•施密特在谈到他一开始反对开发Google Chrome时这样说道。

答案是，他们能。时至今日，Chrome已经成为使用最广泛的网络浏览器（根据StatCounter的数据，市场份额超过35%），并且兼容Windows、Linux、OS X、Chrome OS多种操作系统，还包括Android和iOS等移动平台。显然，Chrome的特性和功能很对用户的胃口，其很多创新之举还被其他流行的浏览器所吸收和学习。

有一本解释Google Chrome的思想和创新的原版38页漫画书，它很好地概括了Chrome受欢迎背后的思路和设计过程。但这只是开始。最初推动着Chrome开发的那些核心原则仍然是它持续优化的指导性原则：

快速：做出最快的浏览器
安全：为用户提供最安全的环境
稳定：提供有弹性且稳定的网络应用平台
简单：技术精妙蕴含在简单的用户体验中

正如开发团队所看到的那样，我们今天所使用的很多网站都不再仅仅是网页，而是应用程序。这些越来越有野心的应用需要速度、安全和稳定。这些方面，每个都值得单独成文来介绍，不过，因为我们的主题是性能，我们将重点介绍性能。

性能的多个方面

现代浏览器是一个平台，就像你的操作系统一样，Google Chrome也遵循这样的设计理念。在Google Chrome之前，所有主流浏览器都是单进程的应用程序。所有打开的页面共享同一地址空间，争夺同一资源。任何页面或浏览器本身出现bug，整体体验都可能被破坏。

与此相反，Chrome运行于多进程模型，这种模型可以保持进程和内存的隔离性，每个标签页都能拥有一个严密的安全沙盒。随着多核架构的流行，隔绝进程并使各个打开的标签页免受其他出错页面的影响，单是这一点就能证明Chrome在浏览器的竞争中具有显著的性能优势。实际上，我们会发现绝大多数其他浏览器都纷纷效仿Chrome，或者开始转向类似的架构。

分派进程之后，一个Web程序的执行主要包括三项任务：获取资源，页面布局与呈现，以及执行JavaScript。呈现和脚本执行步骤遵循单线程、交错执行的模型——无法对所得到的DOM（文档对象模型）进行并发式的修改。原因之一是JavaScript本身就是单线程的语言。所以，无论是对于应用程序的开发者还是浏览器的开发者来说，优化呈现和脚本执行运行时的协作方式，是极其重要的。

在呈现这一步，Chrome使用的是Blink，这是一种快速、开源、遵守良好标准的布局引擎。在JavaScript这一步，Chrome自带了一个高度优化的V8 JavaScript运行时，它也作为单独开源项目发布，并已经被其他很多流行的项目所吸纳，例如Node.js的运行时。但是如果浏览器的网络连接是阻塞的（等待资源到来），那么优化V8 JavaScript执行或者Blink解析和呈现管道都不会有太大作用。

浏览器优化各项网络资源的次序、优先级和延迟的能力对整体用户体验是最关键的影响因素。你可能没有注意到，毫不夸张地说，Chrome的网络栈每天都会变得更加聪明，尝试着隐藏或减少各项资源的延迟开销：它会学习可能出现的DNS查询，会记住网络的拓扑结构，会预连接可能的目标站点，等等。从外部看来，它展示出的是一种简单的资源获取机制，但是从内部看来则是对如何优化网络性能并带给用户最佳体验的一次详细而精彩的案例学习。

让我们进入正题吧。

什么是现代Web应用？

在我们接触如何优化网络交互的具体细节之前，先来了解我们所面对的这个问题的发展趋势和背景。换句话说就是，“现代网页或者应用是什么样的？”

HTTP Archive目记录了网络的构造过程，可以帮助我们回答这个问题。这个项目并不是为了爬取网页内容，而是周期性地爬取访问量最大的站点，记录和加总各个站点所用资源数量、内容类型、标头和其他元数据的分析数据。2013年1月的数据，可能会令你吃惊。访问量最大前30万个网络站点来看，一个页面平均：

为1280KB大小
由88个资源组成
连接15个以上不同的主机

好好琢磨一下。大小平均超过1MB，包含88个如图片、JavaScript、CSS这样的资源，从15个不同的自有和第三方主机传送出来。而且，这些数字在过去几年还在持续增长，丝毫没有减缓的迹象。这说明，我们所开发的网络应用正变得越来越大，越来越有野心。

根据HTTP Archive的数据，做个简单的算术，我们可知每个资源平均大小为15KB（1280KB/88项资源），这意味着浏览器中大多数的网络传输是短小但突发的。这就造成了一些问题，因为基础传输（TCP）是针对大型、流式下载进行优化的。让我们深入地看一看这些网络请求。

线上资源请求的生命周期

W3C的浏览时序规范（Navigation Timing specification）提供了一个浏览器API，让我们可以看到浏览器中每项请求的生命周期背后的时序和性能数据。让我们看看这些组成部分，每一块都是影响最佳用户体验的关键点：

对于一个网络资源的URL，浏览器首先会检查其本地缓存和应用程序缓存。如果你此前获取过该资源，并且提供了适当的缓存标头（Expires, Cache-Control等），则我们可能被允许使用本地副本来响应原请求——最快的请求就是不请求。或者，如果我们需要重新校验该资源（如果资源已过期），或是我们根本从未获取过该资源，那么就必须发起一个高开销的网络请求。

有了主机名称和资源路径，Chrome首先检查现有的已开启连接中是否有可以重用的——socket按照{scheme, host, port}的格式储存在池中。或者，如果你已经配置了代理，或指定了代理自动配置脚本（PAC），那么Chrome就会通过适当的代理来检查连接。PAC脚本允许基于URL的不同代理或其他指定规则，它们都可以有自己的socket池。最后，如果上述条件都不满足，则请求必须通过将主机名解析为IP地址的方式发起，也称为DNS查询。

如果幸运的话，主机名可能已经在缓存当中了，此时通常只需要一次快速的系统调用就得到响应。如若不然，就必须调度一个DNS查询才能继续下去。DNS查询耗费的时间由网络提供商、站点的热门程度、主机名可能存在过渡缓存中的概率以及该域名的权威服务器的响应时间所决定。换句话说，影响变量有很多，但是耗费数百毫秒来进行一次DNS查询也并非罕见。天啊。

得到了解析后的IP地址，Chrome现在可以打开一个新的与目标站点的TCP连接，这意味着我们需要进行“三次握手”：SYN > SYN-ACK > ACK。这一交换过程又为每个新的TCP连接增加了一个往返延迟——此处没有捷径可走。根据客户端与服务器的距离和所选定的路由路径不同，这可能产生几十、几百甚至几千毫秒的延迟。这些工作和延迟是甚至还没有一个字节的应用程序数据开始传输之前就发生的。

完成了TCP握手之后，如果我们连接的是安全站点（HTTPS），那么还要进行SSL握手。这又增加了客户端和服务器之间两个往返延迟。如果SSL会话进行了缓存，那么可以“免去”其中一次额外的往返延迟。

最后，Chrome要调度HTTP请求（上图中requestStart）。服务器接收到请求之后，会处理该请求，然后通过数据流把响应数据返给客户端。这至少会产生一个往返延迟，还要算上服务器的处理时间。正常情况下这样就结束了，但如果真正的响应是一个HTTP重定向，那么我们可能还需要把整个过程再重走一遍。你的页面上有不必要的重定向吗？那你可能需要重新考虑这个决定了。

你算过这所有的延迟时间了吗？为了便于说明问题，我们假设一个典型的宽带连接的最坏情况：没有本地缓存、相对较快的DNS查询速度（50ms）、TCP握手、SSL协商、相对较快的服务器响应时间（100ms）、80ms的往返延迟（这是美国大陆往返延迟的平均时间）：

DNS需要50ms
TCP握手需要80ms（一次往返延迟）
SSL握手需要160ms（两次往返延迟）
请求传输到服务器需要40ms
服务器处理需要100ms
服务器返回响应需要40ms

这样算下来，单次请求需要470毫秒，与服务器真正处理请求的时间相比，其中80%都是网络延迟开销。实际上，470毫秒都算是一个乐观的估计了：

如果服务器响应不匹配初始的TCP拥塞窗口（4-15KB），还会额外产生一个或多个往返延迟。【注1】
如果我们需要获取缺失证书或者需要执行在线证书状态检查（OCSP），SSL延迟得还会更厉害，因为这两种情况都需要一次全新的TCP连接，这又增加了成百上千毫秒的额外延迟。

“足够快”有多快？

DNS、握手、往返延迟的网络开销是决定前例中总时间的因素——服务器响应时间仅占总延迟的20%。但是，从大局看，这些延迟重要吗？如果你正在阅读本文，你很可能已经知道了答案：不但有影响，而且影响很大。

过去一些用户体验的研究描述了我们作为用户对应用程序（在线或离线）的响应速度作何预期：

Delay	User Reaction
0 - 100 ms	Instant
100 - 300 ms	Small perceptible delay
100 - 300 ms	Small perceptible delay
300 - 1000 ms	Machine is working
1 s+	Mental context switch
10 s+	I’ll come back later…

上表还能够解释网络性能领域中一条不成文的经验法则：如果不能直接呈现页面，至少也要在250毫秒以内提供视觉上的反馈以保持用户不会失去兴趣。其他因素也会影响速度。对Google、Amazon、Microsoft和数千个其他站点的研究显示，额外的延迟会直接影响站点的获利能力：速度快的网站能生成更多的页面请求，用户参与度也更高，从而转化率也更高。

所以，我们知道了，最佳的延迟应该控制在250毫秒，但我们在前例中看到，DNS查询、TCP和SSL握手再加上请求传递的时间总共有370毫秒。我们已经超出50%了，这还是我们没算上服务器处理时间的情况！

对于大多数用户乃至一些网络开发者来说，DNS、TCP和SSL的延迟是完全透明的（无须关心的），它们是在网络层协商的，而我们极少深入到甚至不会去想这个层面的事。但是，这其中的每一步对整体用户体验都是非常关键的，因为每增加额外的网络请求都会增加几十或几百毫秒的延迟。这就是为什么Chrome的网络栈要比一个简单的socket处理器复杂的多得多。

找到了症结所在，我们继续来看一些实现细节。

Chrome的网络栈概览

多进程架构

Chrome的多进程架构对各个网络请求如何在浏览器中进行处理具有重大影响。在底层，Chrome实际上支持四种不同的执行模型用于确定如何进行进程的分配。

默认情况下，桌面上的Chrome浏览器使用“站点对应进程”模型，将不同站点隔离开来，而把同一站点的所有实例分组在同一进程中。不过为了简便起见，我们假设最简单的情况：每个打开的标签页对应一个单独的进程。从网络性能的角度看，这种差别并不重要，但“标签页对应进程”模型要容易理解得多。

这个架构为每个标签页配给一个专用的呈现进程。每个呈现进程包含Blink布局引擎和V8 JavaScript引擎，配合上一些胶水代码把这几个部分（再加上其他一些部分）联系起来。【注2】

这些呈现进程的每一个都在一个沙盒环境内执行，这个环境对用户计算机——包括网络，只有有限的访问权限。要获得访问这些资源的权限，每个呈现进程要与主浏览器进程（或称为内核进程）进行通信，由内核进程负责管理每个呈现器的安全和权限策略。

进程间通信和多进程资源加载

Chrome中呈现器和内核进程之间的所有通信都是通过进程间通信（IPC）完成的。在Linux和OS X上使用的是socketpair，这个方法提供一个命名的管道传输进行异步通信。来自呈现器的每条消息经过序列化处理再传给专用的I/O线程，再由它将其派发给主浏览器进程。在接收端，内核进程提供一个过滤接口，允许Chrome拦截应该由网络栈处理的资源IPC请求（参见ResourceMessageFilter）。

这种架构的一个优点是，所有的资源请求都完全在I/O线程上处理，用户接口产生的活动与网络事件之间互不干扰。资源过滤器运行在浏览器进程中的I/O线程中，截获资源请求消息，并将其转发给浏览器进程中的ResourceDispatcherHost【注3】单例。

这个单例接口允许浏览器控制各个呈现器的网络访问权限，它还能实现高效和一致性的资源共享。一些例子包括：

socket池和连接限制：浏览器能够对每个profile、代理和{scheme, host, port}组所对应的已开启socket数量进行限制（分别为256、32和6个）。注意，按照这个规则，同一{host, port}最多可以进行6个HTTP和6个HTTPS连接。
socket重用：持久性的TCP连接会在请求处理之后在socket池中保留一段时间，以供连接重用，这样能够避免发起新的连接额外带来的DNS、TCP和SSL（如有需要）的启动开销。
socket后期绑定：当socket准备好分派应用程序请求时，请求才与基础的TCP连接绑定起来，这样一来可以获得更好的请求次序优化（例如：当socket在连接中时，更高优先级的请求到达），更大的流量（例如：在现有socket可用而新连接正在打开时，重用“刚使用过”的TCP连接）以及TCP预连接的通用机制和其他一些优化。
一致的会话状态：所有呈现进程的身份鉴证、cookies和缓存数据都是共享的。
全局性资源和网络优化：浏览器可以从所有呈现进程和未完成请求的全局做出决策。例如，对前景标签页发起的请求赋予网络优先级。
预测性优化：通过观测所有的网络流量情况，Chrome能够构建和修正预测性模型提升性能。

就呈现进程而言，它只是通过IPC发送资源请求消息，这个请求被打上对应浏览器进程的唯一请求ID，剩下的部分都是由浏览器内核进程处理的。

跨平台资源获取

跨Linux、Windows、OS X、Chrome OS、Android和iOS等不同平台的可移植性是Chrome网络栈实现中的一个重要问题。要解决这个挑战性的问题，网络栈被实现为一个几乎单线程（有单独的缓存和代理线程）的跨平台库，使Chrome可以重用相同的基础设施并提供相同的性能优化水平，更有机会进行跨平台的优化。

当然，所有的代码都是开源的，可以在src/net子目录中找到。我们不打算详细剖析每个部分，但是代码格局本身就带有很大的信息量，告诉我们它的功能和结构。下表中是一些例子。

组件	描述
net/android	对Android运行时的绑定。
net/base	常用网络工具，如主机解析、cookies、网络变化检测和SSL证书管理。
net/disk_cache	实现网络资源的磁盘和内存缓存。
net/dns	实现异步DNS解析器。
net/http	实现HTTP协议。
net/proxy	代理（SOCKS和HTTP）配置、解析和脚本获取等。
net/socket	TCP socket、SSL流和socket池的跨平台实现。
net/spdy	实现SPDY协议。
net/url_request	实现URLRequest、URLRequestContext和URLRequestJob。
net/websockets	实现WebSockets协议。

这些组件的代码都让人忍不住想好好读一读，它们文档完备，每个组件你都能找到很多的单元测试。

移动平台的架构和性能

移动端浏览器的使用正在以指数级增长，即使按照保守预测，它也会在不远的将来完全取代桌面浏览。所以不言而喻，提供优化的移动端访问体验一直是Chrome团队的首要任务之一。在2012年初，Chrome for Android发布，数月后Chrome for iOS发布。

于Chrome的移动端版本，第一件需要注意的事是，它并不是简单地直接在桌面浏览器基础上做一些调整——那样并不能得到最好的用户体验。从本质讲，移动端环境的资源更加局限，而且有很多根本不同的操作参数：

桌面用户通过鼠标来浏览，可以进行窗口重叠，屏幕更大，几乎没有电量的约束，网络连接通常更稳定，能够访问更大的存储和内存池。
移动端用户使用触摸和手势浏览，屏幕更小，受制于电池和电量的约束，往往使用流量计量的网络，本地存储和内存也较为有限。

此外，并不存在一个“典型移动设备”。不同硬件能力的各种设备五花八门，要提供最佳性能，Chrome必须适应每种设备的操作约束条件。所幸，Chrome有多种执行模型正好可以实现这一点。

在Android设备上，Chrome沿用了桌面版本中相同的多进程架构——即一个浏览器进程多个呈现进程。一个区别是，由于移动设备的内存有限，Chrome可能不能为每个开启的标签页运行专用的呈现器。Chrome是根据可用内存和设备的其他约束条件确定一个最优的呈现进程数量，由多个标签页共享呈现进程。

当只有最少资源可用时，或者Chrome无法运行多进程时，它也可以切换回使用单进程、多线程处理模型。实际上，在iOS设备上，由于基础平台对沙盒的限制，它就是这样实现的——运行多线程的单一进程。

网络性能方面呢？首先，Chrome在Android和iOS上使用和其他版本相同的网络栈。这样保证所有平台都有相同的网络优化，Chrome由此获得显著的性能优势。但是，如推测优化技术、socket超时设定与管理逻辑、缓存大小等这样的变量，是有所不同的并且会根据设备功能和所用网络时时调整。

例如，为了节约电池电量，移动端Chrome可能选择使用闲置socket的懒惰关闭方式——即仅当开启新socket时才关闭旧的，这样来尽可能减少使用广播模组。同样地，因为预呈现（见下文）可能需要大量的网络和处理器资源，所以通常仅当用户使用WiFi时才进行。

优化移动端浏览体验是Chrome开发团队的首要优先任务之一，我们可以期待在未来几个月或几年内看到新的改进。实际上，这是一个值得单独行文介绍的内容——或许在POSA系列的下一版中就会出现。

使用Chrome预测器进行推测优化

Chrome会随着你的使用变得越来越快。这项本领是借助Predictor单例对象实现的，它在浏览器内核进程中被实例化，其唯一职责是观测网络模式，并学习和预测未来可能出现的用户行为。Predictor处理信号的一些例子有：

用户鼠标在一个链接上悬停，很好地预示了接下来可能发生的浏览行为，Chrome可以发起一个推测的目标主机DNS查询，还有可能开始TCP握手，以提升速度。待用户实际点击时，这平均还需要约200毫秒的时间，我们很有可能已经完成了DNS和TCP的步骤，这就为这次浏览减少了数百毫秒的额外延迟时间。
在Omnibox（URL）栏中键入内容将触发高概率建议，也会触发DNS查询、TCP预连接甚至在隐藏的标签页中预呈现该页面。
我们都有一个每天访问的喜爱站点清单。Chrome可以学习这些站点的子资源并推测性地进行预解析，甚至可能预获取这些资源来加速浏览。

Chrome会随着你的使用，逐步学习网络的拓扑结构和你的浏览模式。如果顺利，它可以为每次浏览减少数百毫秒的延迟，让用户更加接近“页面即刻加载”的理想状态。为了实现这一点，Chrome使用了四个核心的优化技术，见下表：

技术	描述
DNS预解析	提前解析主机名，避免DNS延迟
TCP预连接	提前连接目标服务器，避免TCP握手的延迟
资源预获取	提前获取页面上的关键资源，加速页面的呈现
页面预呈现	提前获取整个页面的所有资源，用户触发时立即展示

每个触发这些技术的决定都是在大量约束条件下优化判断的。毕竟，每一项优化都是推测性的，这意味着如果运用失当，可能会导致不必要任务和网络流量，更糟的是，还有可能对用户实际浏览行为的加载时间产生负面效果。

Chrome是如何解决这个问题的呢？预测器会尽可能多地吸收信号，包括用户产生的行为、历史浏览数据以及来自呈现器和网络栈本身的信号。

与ResourceDispatcherHost负责协调Chrome中所有网络活动的情况类似，Predictor对象也在Chrome内部创建了对一些用户和网络产生活动的过滤器：

IPC频道过滤器，监测来自呈现进程的信号
为各个请求添加ConnectInterceptor对象，这样它就能观测每个请求的流量模式并记录成功次数。

下面是一个实际操作的例子，呈现进程可以发出一条带有以下任何提示的消息给浏览器进程，这些提示定义在ResolutionMotivation（url_info.h）中：

enum ResolutionMotivation {
  MOUSE_OVER_MOTIVATED,     // Mouse-over initiated by the user.
  OMNIBOX_MOTIVATED,        // Omnibox suggested resolving this.
  STARTUP_LIST_MOTIVATED,   // This resource is on the top 10 startup list.
  EARLY_LOAD_MOTIVATED,     // In some cases we use the prefetcher to warm up
                            // the connection in advance of issuing the real
                            // request.

  // The following involve predictive prefetching, triggered by a navigation.
  // The referring_url_ is also set when these are used.
  STATIC_REFERAL_MOTIVATED,  // External database suggested this resolution.
  LEARNED_REFERAL_MOTIVATED, // Prior navigation taught us this resolution.
  SELF_REFERAL_MOTIVATED,    // Guess about need for a second connection.

  // <snip> ...
};

收到这样的信号后，预测器的目标是评价其成功的可能性，然后在资源可用的情况下触发相应行为。每条提示可能都有一个成功概率、一个优先级和一个过期时间戳，这组数据可用于维护一个推测优化的内部优先级队列。最后，对于每条从此队列发出的请求，预测器还能够跟踪记录其成功率，这又被用于未来决策的优化中。

Chrome网络架构概要

Chrome使用多进程架构，将呈现进程与浏览器进程隔离开。
Chrome保持资源调度器的一个单一实例，它被所有呈现进程所共享，运行在浏览器内核进程中。
网络栈是一个跨平台、几乎单线程的库。
网络栈使用非阻塞操作来管理所有网络操作。
共享的网络栈可实现高效的资源次序优先化、重用并使浏览器可以在所有运行的进程之间进行全局性的优化。
各个呈现进程通过IPC与资源调度器通信。
资源调度器通过自定义的IPC过滤器截获资源请求。
预测器截获资源请求和响应通信来学习和优化未来的网络请求。
预测器根据所学的浏览模式可能推测性地安排DNS、TCP甚至资源请求的计划，当用户实际发生行为时节省数百毫秒的时间。

浏览器会话的生命周期

有了对Chrome网络栈架构的一个概括性认识后，我们接下来仔细研究一下浏览器内部实施的各种面向用户的优化。具体而言，假设我们刚创建了一个新的Chrome profile，准备好开始了。

优化冷启动体验

当你第一次加载浏览器时，它对你的喜爱站点和浏览模式一无所知。但是，我们中的很多人都会在浏览器冷启动后做同样的事：我们会浏览我们的电邮收件箱、喜爱的新闻站点、社交网站、内网入口等等。具体的站点可能因人而异，但是这些会话的相似之处使Chrome的Predictor可以加速你的冷启动过程。

Chrome会记住用户在浏览器启动后前10个最有可能访问的主机名——注意这并不是前10个全局目标站点，而特指全新开启浏览器之后的目标站点。浏览器加载时，Chrome可以为这些可能的目标站点触发DNS预获取行为。如果你对此感兴趣，可以打开一个新标签页浏览地址chrome://dns，看一看你自己的启动主机名列表。在页面顶端，你会找到你profile的前10个最可能启动站点。

截图是我的Chrome profile的例子。我通常是如何开始浏览的呢，如果我在写文章，比如现在这一篇，可能会频繁访问Google Docs。果不其然，我们在列表中看到很多Google的主机名。

使用Omnibox优化交互过程

Chrome的创新之一是引入了Omnibox，它与此前的地址栏不同，可以处理目标站点URL之外的很多东西。除了记住用户曾经访问过的页面的URL之外，它还提供完整的对历史记录的文本检索功能，与你所选择的搜索引擎的集成性也较好。

随着用户在其中键入内容，Omnibox会自动提供建议的行为，可能是基于你的浏览历史的URL或者是一次检索查询。在后台，每个建议行为都根据查询结果和历史表现进行评分。实际上，Chrome允许我们通过访问chrome://predictors来查看这些数据。

Chrome会维护用户输入前缀、建议行为以及每一记录的命中率的历史记录。在我的profile中，你可以看到当我在Omnibox中输入“g”时，有76%的可能性我是要访问Gmail。而当我加了一个“m”之后（变成“gm”），则置信水平上升到99.8%，实际上，在记录的412次访问中，我只有一次在输入“gm”之后没有访问Gmail。

这与网络栈有什么关系呢？可能备选站点中黄色和绿色的记录也是ResourceDispatcher的重要信号。如果我们有一个可能的备选站点（黄色），Chrome可能为该目标主机触发DNS预获取。如果我们有一个高度确信的备选站点（绿色），那么Chrome可能还会在主机名解析之后触发TCP预连接。最后，如果这两步都做完时用户还没做出最终决定，那么Chrome甚至可能在隐藏的标签页中预呈现整个页面。

另一方面，如果根据过去的浏览历史没有为所输入的前缀找到较好的匹配，那么Chrome预计可能会发生检索请求，会向你的搜索引擎发起DNS预获取和TCP预连接。

一个普通用户需要花费数百毫秒来填写查询内容，评价所给出的自动补全建议。在后台，Chrome能够预获取、预连接，并在某些情况下对页面进行预呈现，这样当用户准备好按下“输入”键时，很多网络延迟已经被消除了。

优化缓存性能

最好最快的请求是不发出请求。当我们说到性能时必然会涉及缓存的问题——你正在为你网页上的所有资源提供Expires、ETag、Last-Modified和Cache-Control这些响应标头，对吧？如果你没有这样做，请立刻去改。我们会等你。

Chrome的内部缓存有两种不同的实现方式：一种是由本地磁盘所支持，另一种是把所有内容存储在内存中。内存实现方式用于匿名浏览模式，当你关闭窗口后会把痕迹清除干净。两种方式都实现相同的内部接口（disk_cache:Backend和disk_cache:Entry），这极大地简化了架构并且——如果你非要坚持的话——允许你很方便地试验你自己的缓存实现。

内部来看，磁盘缓存实现了其自己的数据结构，它们都被存储在你的profile的一个单独的缓存文件夹中。这个文件夹中有索引文件，它们在浏览器启动时进行内存映射，还有数据文件，它们存储了实际数据以及HTTP标头和其他簿记信息【注4】。最后，在缓存回收机制上，磁盘缓存会维护一个最近最少使用（LRU）缓存，它会把访问频度和资源新旧度等排序量化指标考虑进去。

如果你对Chrome的缓存状态很感兴趣，可以打开新标签页访问chrome://net-internals/#httpCache。或者，如果你想看看真实的HTTP元数据以及缓存的响应，也可以访问chrome://cache，其中列示了缓存中当前可用的所有资源。在该页面中，检索一项资源之后可以点击URL查看缓存的标头和响应的具体字节内容。

使用预获取优化DNS

我们已经在一些地方提到过DNS预解析，所以在我们深入介绍它的实现方式之前，先回忆一下哪些情况下为什么会触发它：

运行在呈现进程中的Blink文档解析器，可以提供当前页面上所有链接的主机名清单，Chrome可以从中选择提前解析。
呈现进程会将鼠标悬停和“按下按键”事件作为用户意图进行浏览的前期信号，从而触发预解析。
Omnibox根据高度可能的建议，可能触发解析请求。
Predictor基于过去的浏览和资源请求数据，可能请求主机名解析。
页面所有者可能明确指示Chrome应该预解析哪些主机名。

所有情况下，DNS预解析都被作为提示来处理。Chrome并不保证预解析必然进行，而是综合运用各个信号与其自身的预测器来评估这条提示并动态决策。在“最坏情况”下，如果Chrome未能及时完成主机名预解析，用户就要等待显式DNS解析，接着是TCP连接时间，最后是实际资源获取。但是，如果出现了这种情况，预测器会进行记录并相应调整其未来决策——随着你的持续使用，它会变得更快更聪明。

我们此前没有提到的一项优化是Chrome能够学习每个站点的拓扑结构，并运用这项信息来加速未来的访问过程。具体而言，回忆一下，一个页面平均由88项资源组成，由15个以上不同的主机发送。每一次你进行浏览，Chrome会记录页面上的热门资源的主机名，在以后的访问中，它可能会对其中一些或全部选择触发DNS预解析甚至TCP预连接。

访问chrome://dns并检索你profile对应的热门站点主机名，可以查看Chrome所保存下来的子资源主机名。在上面的例子中，你可以看到Chrome记录了Google+的6个子资源主机名，还统计了DNS预解析触发或TCP预连接执行的次数，还有会由各项处理的请求的估计值。这些内部记录帮助Chrome预测器实现优化。

除了这些内部信号之外，站点的所有者也能在页面中嵌入附加的标记请求浏览器预解析一个主机名：

1	<link rel="dns-prefetch" href="//host_name_to_prefetch.com">

为何不直接依靠浏览器的自动机制呢？有些时候，你可能希望解析一个页面中任何地方都没有提到过的主机名。重定向就是一个典型的例子：链接可能指向一个主机——就如同一项分析追踪服务一样——这个主机再把用户重定向至真正的目标站点。Chrome依靠自身是无法推断出这种模式的，但你可以手动提供一条提示帮助它，让浏览器提前解析真实目标站点的主机名。

这一切在后台是如何实现的呢？和我们讨论过的其他优化手段一样，这个问题的答案也取决于Chrome的版本，因为开发团队一直试验新的、更好的方式来提升性能。但是，不严格地说，Chrome内部的DNS基础设施有两个主要的实现方式。过去，Chrome依靠操作平台无关的系统调用getaddrinfo，并把DNS查询的实际职责交由操作系统完成。但是，这种方式正逐步被Chrome自己实现的异步DNS解析器所替代。

依靠操作系统的原有方式具有其优点：代码少而简单，并能够利用操作系统的DNS缓存。但是，getaddrinfo也是一个阻塞型的系统调用，这意味着Chrome必须创建并维护一个专用的worker线程池，才能够实现多条并行查询。这个未连接池最多只能容纳六个线程，这个上限是基于硬件的最小公分母得出的经验数字——这样并行请求的数量超出的话，有些用户的路由器就会过载。

对于使用worker池的预解析，Chrome就只是调度getaddrinfo调用，这会一直阻塞worker线程，直至响应就绪后马上丢弃所返回的结果，并开始处理下一条预获取请求。结果由操作系统的DNS缓存来存储，未来实际进行getaddrinfo查询时，它会立即返回响应。这种方式简单有效，实践中的表现也不错。

但这还不够好。getaddrinfo调用有很多有用信息不向Chrome公开，比如每条记录的生存时间（TTL）时间戳，以及DNS缓存本身的状态。为了提升性能，Chrome团队决定自己来实现跨平台的异步DNS解析器。

通过把DNS解析放到Chrome内部来处理，新的异步解析器可以实现一些新的优化手段：

更好控制重传计时器，能够并行执行多条查询
记录生存时间的可见性，使得Chrome能提前刷新热点记录
更好的双栈实现（IPv4和IPv6）行为
基于RTT或其他信号的，对不同服务器的故障切换

以上所有以及其他很多想法都是在Chrome内持续试验并优化的。这就必然涉及一个问题：我们如何了解并衡量这些想法的效果呢？很简单，Chrome会为每个profile分别记录详细的网络性能统计数据和直方图。要查看所收集到的DNS统计数据，可以打开新标签页，访问chrome://histograms/DNS（见下图）

上面的直方图显示出了DNS预获取请求延迟的分布情况：大约50%的（最右侧列）预获取查询在20毫秒内完成（最左侧列）。注意，这是基于最近的浏览会话（9869个样本）的统计得到的，并属于用户的隐私数据。如果该用户选择报告Chrome的使用统计数据，则这些数据的摘要会被匿名处理，定期反馈给开发团队，他们就可以看到试验的效果并进行相应的调整。

使用预连接优化TCP连接管理

我们已经预解析了主机名，按照Omnibox或Chrome预测器的估计，我们很有可能即将进行浏览行为。为什么不更进一步，也推测性地预连接到目标主机，在用户发出请求之前完成TCP握手的步骤呢？这样一来，我们又能消除掉一个往返延迟，轻松省去用户数百毫秒的时间。没错，TCP预连接正是这样做的。

打开新标签页访问chrome://dns可以查看已经触发TCP预连接的主机。

首先，Chrome会检查socket池，看看是否有该主机名的可用socket可供重用——存活socket会在池中留存一段时间，以避免TCP握手和慢热启动的惩罚时间。如果没有socket可用，则由其发起TCP握手并放入池中。然后，当用户进行浏览时，HTTP请求就可以立刻调度。

Chrome在chrome://net-internals#sockets中提供了一个工具可以查看Chrome中所有已开启socket的状态。图1.10是相关的截图。

你还可以详细查看每个socket，检查时间线：连接和代理时间，每个包的到达时间等等。最后要说的很重要的一点是：你也可以导出这些数据进行后续分析或报告bug。具有良好的信息统计机制对任何优化都是很关键的，chrome://net-internals就是Chrome中所有功能相互作用的集中展示——如果你还没探索过这个功能，你应该试试！

使用预获取提示优化资源加载

有时，页面的作者能够提供基于其站点结构或布局附加的导航或页面上下文，帮助浏览器优化用户体验。Chrome支持两种这样的提示，可以嵌入页面标记中使用：

1 2	<link rel="subresource" href="/javascript/myapp.js"> <link rel="prefetch" href="/images/big.jpeg">

子资源和预获取看起来非常类似，但是语义完全不同。当链接资源指定其关系为“预获取”时，它是告诉浏览器，这项资源在以后的浏览中可能用到。换言之，这实际上是一个跨页面提示。而当资源指定其关系为“子资源”时，它是提前告诉浏览器该资源会在当前页面中被用到，在该文档后面的部分遇到它之前可以先发起请求。

可以想见，两者的不同语义会导致资源加载器的行为大相径庭。标记预获取的资源会被看做优先级较低，并在当前页面加载完成后由浏览器进行一次下载。标记为子资源的内容一旦遇到就会作为高优先级资源来获取，并与当前页面上的其余资源相互竞争。

这两种提示如果使用得当可以极大地帮助优化你站点的用户体验。最后，还要注意，预获取是HTML5规范的一部分，目前Firefox和Chrome都支持，而子资源目前只限于Chrome。

使用浏览器预刷新优化资源加载

不巧的是，不是所有站点所有者都能够或愿意在标记中为浏览器提供子资源提示。而且，即使他们这样做，我们还是要等待HTML文档从服务器传送过来之后才能解析这些提示，开始获取这些必要的子资源——根据服务器响应时间和客户端与服务器间的延迟，这可能需要耗费数百乃至数千毫秒。

但是，我们前面看到，Chrome已经通过学习常用资源的主机名来执行DNS预获取了。那么，为什么不如法炮制，更进一步：执行DNS查询，使用TCP预连接然后也推测性地预获取资源呢？没错，这就是预刷新的作用：

用户发起对目标URL的请求
Chrome询问预测器其所学习到的与目标URL相关的子资源，并发起DNS预获取、TCP预连接和资源预刷新等一连串行为
如果所学到的子资源在缓存中，则将其从磁盘加载到内存中
如果所学到的子资源缺失，或者已过期，则进行一次网络请求

资源预刷新是展示Chrome中每个试验性优化手段的工作流的绝佳例子——理论上讲，一项优化应该使性能得到提升，但是也涉及很多因素的此消彼长。只有一种方式能够可靠地确定一项优化是不是有效，是不是适合于Chrome：先实现它，并在一些预先发布的渠道（真正的网络、真实浏览模式、真人用户）上进行A/B试验。

在2013年初，Chrome团队还处于讨论这种实现的早期阶段。如果根据所收集的结果它能奏效，我们我们可能会在年内晚些时候在Chrome中看到预刷新。Chrome的网络性能优化从未止步——开发团队一直在试验新的方法、创意和技术。

使用预呈现优化浏览

目前为止我们介绍过的每一项优化都是帮助减少用户进行浏览的直接请求和标签页上呈现最终页面之间的延迟的。但是，要真正得到即刻展示页面的体验，需要什么呢？根据我们之前看到的UX数据，这样的交互时间需要低于100毫秒，这样，留给网络延迟的余地可不算多。我们怎么才能在100毫秒内把呈现好的页面展示出来呢？

当然，你已经知道答案了，因为这是很多用户所用的共同模式：如果你打开多个标签页，标签页间的切换就是即刻的，比在一个前景标签页中浏览同样资源之间的等待要快得多。那么，如果浏览器提供一个API来实现这一点呢？

1	<link rel="prerender" href="http://example.org/index.html">

你可能猜到了，这就是Chrome中的预呈现。不是如“预获取”提示实现的那样只下载单项资源，“预呈现”属性命令Chrome在隐藏标签页中预呈现页面以及所有子资源。隐藏标签页本身对用户不可见，但当用户触发浏览行为时，该标签页就会从后台切换出来实现“即刻体验”。

想看看这是如何实现的吗？可以访问prerender-test.appspot.com上还在开发中的演示版，要查看你的profile的预呈现页面的历史记录和状态，访问：chrome://net-internals/#prerender。

可以预见的是，在隐藏标签页中呈现完整页面可能会耗费CPU和网络的大量资源，所以仅当我们高度确信应该使用隐藏标签页时才应该使用。例如，当你使用Omnibox时，对高度确信的建议可能会触发预呈现。类似地，Google搜索如果估计认为它的第一条检索结果是高度确信的目标站点，有时会在其标记中添加预呈现提示（也称为Google即开页面）。

你还可以为自己的站点添加预呈现提示。在你这样做之前，请先了解并记住预呈现过程具有的以下局限之处：

所有线程总共至多只能有一个预呈现标签页
HTTPS和需要HTTP身份鉴证的页面不能使用
如果所请求资源或其任何子资源需要进行非幂等请求（只允许GET请求），预呈现会被放弃
所有资源都以最低的网络优先级进行获取
该页面以最低的CPU优先级进行呈现
如果内存需求超过100MB则该页面会被放弃
插件初始化被推迟，如果出现了HTML5的多媒体元素则预呈现被放弃

换言之，预呈现不保证一定发生，并只适用于安全的页面。此外，因为JavaScript和其他逻辑可能在隐藏页面中被执行，实践中最好使用页面可见性API来检测一下该页面是否可见——这是你本就应该做的。

Chrome会随着你的使用越来越快

无需多言，Chrome的网络栈绝非一个简单的socket管理器。我们这次走马观花的概述介绍了在网站浏览的背后多层次的透明运行的优化手段。Chrome对网站拓扑结构和你的浏览模式了解越是深入，它的效果就越好。就像魔法一样，Chrome会随着你的使用越来越快。可你知道它并不是魔法，你了解这背后的机制。

最后，还要注意一点，Chrome团队持续试验着优化性能的新想法——这个过程从未停止。在你阅读本文时，就可能有新的试验项目和优化手段正在开发、测试或部署着。也许只有当我们能够对每个站点每个页面都实现即刻加载（小于100毫秒）时，才会停下脚步吧。在那之前，总有工作等着我们去完成。

学习浏览器技术可以得到什么？

浏览器要处理的两个核心对象是HTML和JavaScript。HTML用来实现网页UI，涉及到的最核心技术是UI渲染技术。JavaScript用来实现网页功能，涉及到的最核心技术JavaScript引擎技术。

一切带有屏幕的智能设备，UI都是其所运行系统的一个核心模块，它负责与用户进行交互，以及将交互结果反馈给用户，从而形成一个闭环。用户在使用一个系统的时候，最先接触到的就是它的UI，经常接触的也是它的UI，因此UI的好坏直接就影响到了系统用户体验的好坏。用户体验对一个系统来说是至关重要的，例如，很多人觉得iOS系统比Android系统好用的其中一个原因就是前者的用户体验更好。

衡量一个系统的用户体验好与坏的其中一个重要标准就是UI的流畅与否，其中又以动画的流畅与否为核心，因为一个流畅的动画显示需要的UI渲染速度是60fps。为了达到60fps的渲染速度，各个系统在实现UI模块的时候，可谓是费尽心思、尽其所能。通常都会使用诸如纵向分层、横向分块的渲染策略。

所谓纵向分层，就是在Z轴方向上按层来划分UI，这样带来的好处在渲染UI的每一帧时，不必每一层都进行重绘。这种分层渲染策略使用到了一种称为“绘制-合成”的UI渲染技术。也就是各层负责绘制好自己的UI，然后再由一个单独的模块对它们进行合成。这样在渲染UI的每一个帧时，只有UI发生了变化的层才需要重新进行绘制，没有发生UI变化的层只需要参与合成这一步即可。这种技术可以大大地减少渲染操作，从而获得更流畅的UI体验。

所谓横向分块，就是对于UI的每一个层，按照一定的规则对其进行分块，这样带来的好处就是在渲染UI的每一帧遇到一个需要进行重新绘制的层时，不必对该层的所有内容都进行重新绘制，只需要绘制那些在可视区间的块即可。这样也可以在某种程度上减少渲染操作，从而获得更流畅的UI体验。

现在的智能设备配备的CPU都是多核的。为了能够充分地利用CPU多核特性，一帧UI渲染通常分两步进行：第一步是收集UI绘制命令；第二步是执行UI绘制命令。每一步都是在一个独立的线程完成，因此就可以充分地利用CPU的多核特性：在执行第N帧的UI绘制命令的同时，收集第N+1帧的UI绘制命令。此外，对于第一步收集到的UI绘制命令，还可以做一些额外的优化。当我们收集到一帧UI的所有绘制命令的时候，我们就相当于是知悉了这一帧UI的全貌。知悉了一个UI帧的全貌之后，就可以进行一些优化，例如对某些UI绘制命令进行重排和合并，以及丢弃那些被遮挡的UI相关的绘制命令。这些优化同样是可以减少渲染操作，从而获得更流畅的UI体验。

现在的智能设备，很多都配备了GPU，这意味着我们可以使用GPU进一步提高UI的渲染速度，这就是所谓的硬件加速渲染技术。例如对于我们前面提到的UI层和块，可以直接以GPU的纹理或者FBO来进行绘制和合成。GPU具有成熟和专业的UI渲染技术，因此通过它来渲染UI，可以获得更流畅的UI体验。

以上提及到的所有UI渲染技术，不管是什么系统，我们都可以或多或少地看到它们的影子，因此它们都是通用的、现代化的UI渲染技术。如果掌握了这些UI渲染技术，那么不管以后流行的是什么系统，我们都可以轻松应对。因此，学习浏览器技术可以得到的第一点核心技术就是现代化的先进UI渲染技术。

不知道同学们有没有发现，最近几年时不时都看到有新的编程语言发布，特别是伴随着新系统的发布，其中比较有名的就是Google的Go语言和Apple的Swift语言。我们在惊叹这些编程语言方便好用的同时，有没有想过它们背后是如何设计和实现的呢？如果有考虑过这个问题的话，我们就不得不提到JavaScript这个古老而又流行的编程语言。

JavaScript被视为一个“玩具语言”，据说它只花了2个星期设计，然后被使用了20年。在20年的时间里，大家一边在用它，然后又一边在骂它。这足见大家是有多么的喜欢它，正所谓”骂是爱，打是亲“嘛。JavaScript虽然天生是为操作网页而设计的，但是它并不仅仅是应用在网页前端应用开发上，它还渗透了移动端和服务端应用开发上。

在移动端上，近两三年出现了不少专门针对手机的Web OS，例如Firefox OS、Ubuntu Mobile OS、Tizen OS以及阿里的云OS，都支持运行Web应用，这意味在这些系统上可以使用JavaScript来开发应用。当然，在Android和iOS上也可以开发Web应用，不过它们都是要运行在WebView之上，不是直接在OS层面上得到支持。在服务端上，Node.js就是一个有代表性的框架，它使得我们可以使用JavaScript来开发Web服务器。

除了在移动端和服务端上，JavaScript甚至还应用在MCU（Microcontroller Unit）领域上，也就是俗称的单片机领域上。这些MCU提供了一个JavaScript运行环境，从而使得我们可以使用JavaScript操作它们。

一个本来只是设计用在网页开发的语言，由于它的简洁和易用性，现在不仅渗透到移动端、服务器端开发上，还渗透到了MCU领域上，这足以看到JavaScript是如此广泛地被开发者接受和使用。当然，JavaScript广泛地被开发者接受和使用，并不意味着它是完美的，例如性能就是一个比较突出的问题。但是会不会在以后的某一天，当JavaScript的性能问题被解决之后，所有能够编程的领域，都会被JavaScript代替呢？

不管如何，鉴于现在JavaScript的流行性，作为一个软件开发从业者，我们不仅会使用JavaScript，还需要知道JavaScript在背后是如何运行的，这样才能达到一个更高的境界。JavaScript是一种动态语言，与C/C++、Java这些静态语言一样，在实现上都是涉及到了编译相关的知识，例如语法解析、生成语法树、生成字节码指令、生成本地指令和指令优化等。只不过对于动态语言来说，这些操作发生在应用程序运行时，只对于静态语言来说，这些操作发生应用程序运行前。此外，运行JavaScript的引擎与运行Java字节码的虚拟机一样，在运行时都提供了内存自动管理技术，也就是会执行GC。由此可见，学习JavaScript可以获得很多编译语言相关的知识。这也是学习浏览器技术可以得到的第二点核心技术。

当我们学习的是基于Chromium的浏览器技术的时候，我们就不仅仅是可以获得上面提到的两个核心技术，还可以学习到一个复杂系统的架构，例如它的对象管理技术、多进程架构和多线程编程模型等等。一言蔽之，学习浏览器技术可以使我们获得很多现在和甚至未来都流行的计算机技术。

注释

第10章：《移动网络性能的秘密》详细解释了这个问题。
如果你感兴趣，Chromium的百科页面上有详细的介绍。
Http://code.google.com/searchframe#OAMlx_jo-ck/src/content/public/browser/resource_dispatcher_host.h&exact_package=chromium&q=ResourceDispatcherHost.
16KB以内的资源保存在共享数据块文件中，更大的文件在磁盘上有自己的专用文件。

参考

http://aosabook.org/en/posa/high-performance-networking-in-chrome.html
https://www.cnbeta.com/articles/tech/63690.htm

无题

2018-09-12T09:28:11.000Z

告别魔都，来到杭州，内心没有一丝喜悦，更多的是惋惜和遗憾。

又到了迷茫时间

只身来到杭州，带着一脸不情愿。也许是在大上海呆久了，不喜欢杭州加班成风的氛围，和小家碧玉的格局。论资源，的确上海更胜一筹，体现在方方面面，难怪全国各地的人才都争相流入。很多人说这城市像围城，外面的人想进去，里面的人想出来。但更多的是外面的人进去了，就不想出来了，后来年龄大了，拼不过年轻人了，才不得不出去。
说起来这次工作变更挺悲催的，进了杭州有名的血汗工厂。。。。。。如果996对于上海来说是深恶痛绝的，那么这儿有可能007都是理所当然。我也时常安慰自己，既来之，则安之。但是在时间安排上面还是很难适应，需要一段时间去消化。

艰难的旅程

可能很多人都有感触，应用开发到了一定年头就会出现瓶颈，这时候就面临转型问题。有的人坚持守住一亩三分地，有的人投入专项领域深入研究，也有的人走上层路线打入管理体系。或者遇到对的老大，一人得道，鸡犬升天。树大好乘凉，还有集团利益带来的阵阵凉风，从此一路起飞，直接实现各种自由。当然还有其它情况的，每个人都有不同境遇，结果也是形形色色。这是人生的重大抉择，也是职业难题。
很多人跳不出自己的舒适区，也不愿跳出，毕竟在一个环境呆久了，人就会越来越懒，久而久之，就会形成习惯，很难接受改变。当然，我也是如此。但是有时候大家还是希望能够向内心向往的方向去转变，只是缺少机会。而主动转变的道路又十分艰难，要克服很多苦难，还要克服自己诸多缺点。这对人的意志也是极大的考验，因为稍微一懒惰，就会半途而废，即使偶尔坚持，也是一暴十寒，未见起色，效果微乎其微。

无奈的抉择

我也承认自己是一条咸鱼，工作这么多年，什么也没有积累，倒是心态越来越佛系。多年来一直荣辱不惊，没有翻身的梦想，随遇而安。小时候心很大，长大后心却很小。没有大目标，没有对物质追求的热衷，也没有对名利的追逐的欲望。唯有自己的一点小兴趣，希望能够长久保持。让生活也有一点色彩，不至于过的浑浑噩噩，换句话说，至少证明自己还活着，而不是行尸走肉。

あの日見た花の名前を僕達はまだ知ら

罗嗦了这么多，也该列出今年未来计划了。目前看来，有如下：

Skia
WebRTC
Chromium
Python
FFMpeg
OpenGL
暂定就是这些，肯定学不完，但是也不能放弃呀。路漫漫其修远兮，贵在兴趣方向的坚持。总之就这样吧，期待自己有所改变。

PHOENIX

2018-07-24T09:02:11.000Z

这一拖就是半年，博客几乎要被废弃了。现在重新拾起，为这次归来起一个代号————————————————PHOENIX。

回顾

上一个系列是SurfaceFlinger，距离完结已经过去了半年（其实还有最后一篇关于Fence的内容，但是后来觉得，如果能够顺着这个系列一路踩下去，对于Fence的理解已经完全不用我再出一篇解析了，因此舍弃了续更的想法）。这半半，我的工作和生活发生了翻天覆地的变化。我一度认为已经超出了我个人的承受能力，但是事情来了，还是硬着头皮顶住了。一些事情也没有处理好，我也有反思过，主要还是因为自己责任心不够重。我也一直认为一个人是否成长，就看他的责任心有没有提升。但是提升责任心有一个最大的心里阻碍，就是懒(╯-╰)/众人皆懒，这个很难克服，必须养成良好的习惯才能慢慢改善。

工作的事情真是一波三折，加入这家公司也是机缘巧合，名字就不透漏了。因为年后公司组织架构调整，人员有所变动，我也不例外。调整之后工作这半年，只能说是受尽心酸。博客停更半年先不说了，技术也一直停滞不前。忙的时候经常一天没喝一口水，或者就是早上刚去接了一杯水，晚上十点多下班后还没喝（＋﹏＋）。忙是一方面，另一方面是公司产品线决定的。因为这是一家纯业务公司，并且在集团快速发展的脚步下，部门也随之急剧变动，可想而知，就会有无休止的业务来折腾。但是却有一个致命的弊端，那就是技术积累严重不足。因为迫于集团的压力，平台老板也是卯足了劲的改革，大刀阔斧的进行业务更替，下面大小领导也是人心惶惶。因为经过几年折腾，平台的业绩本身已经在逐年下滑，但是又不能两耳不闻当咸鱼，所以才有了大小团队各种争相表现举动。产品的需求日日更迭先不提，技术团队也是为出成果各种邀功，因此，各个团队，海量的业务库，组件库，监控库，上报库……等等陆续诞生，先不管有么有用，或者是否已经有重复功能的库已，先集成给主应用再说，然后写个wiki，就证明我们组也有输出了，至少kpi有的写了。至于是否影响主应用性能，或者后续是否仍然使用，或者这个库的维护，这个就不是care的点了(一-一)。可以说，有没有很重要，有没有用不重要。对外宣布这些组件库，感觉他们都说自己是这么个情况：

现在主应用已经越来越卡了，crash率也上升了许多，很多用户都投诉了，每天投诉邮件尽是批评和吐槽。用户数和活跃度也在下降，看着各种V的数据折线，仿佛看着A股的走势，的确有些心寒。

因为是纯业务公司，再加上忙的不可开交，因此技术实力不进反退(ノ=Д=)ノ┻━┻这个有公司的原因，也有我的原因。本来我是想在音视频的道路上越走越长，顺路拾一拾图形图像的内容。可惜总是事与愿违啊，工作经历一波三折，一直在折腾，一直没有走到正向，反而越走越远。不过说到业务能力，在工作中也得到了锻炼，因为工作量很大，时间周期又很短，所以工作时候不能闷着头就是干，还要学会思考，比如提升工作效率，还有保证质量和复用性。我一直认为一个人的业务能力应该至少有两年时间去沉淀，具体沉淀的厚度就看个人理解程度了。但是总体来说，我还是觉得倒退了，这是无法回避的事实。

展望

上年提到，以后希望能够在音视频方向有所造诣。不求闻达于业界，但求沉浸于兴趣。因为在这家公司工作初期用到了OpenGL相关知识，因此闲暇之余写了个app——狗头相机。

GitHub传送门如下：

https://github.com/windrunnerlihuan/DogCamera

本来想做成抖音的效果，但是抖音的界面太花了，不利于功能的展示，所以UI设计就抄了VUE，但是会加上抖音的功能（因为工作实在太忙，因此很多功能还没有加上。目前已有拍摄、录制、加滤镜、混音等功能）。
这个app目前还有许多bug，以及很多功能还未添加，后续我都会慢慢完善。如果大家有好的点子，欢迎留言或者提issue～

Android SurfaceFlinger 学习之路(十二)----合成Layer

2018-01-09T09:28:11.000Z

脱更许久，慢慢步入咸鱼阶段。虽非我愿，但事事不如愿。一切尽在不言中，可与言者无一二。
上一节讲了合成Layer之前的准备工作，主要是就算可视化区域和初始化硬件合成环境，本节就讲讲最后的内容，合成Layer。

回顾

上一节讲合成的时候说过，合成分为两种，离线合成和在线合成：

先将所有图层画到一个最终层（FrameBuffer）上，再将FrameBuffer送到LCD显示。由于合成FrameBuffer与送LCD显示一般是异步的（线下生成FrameBuffer，需要时线上的LCD去取），因此叫离线合成。
不使用FrameBuffer，在LCD需要显示某一行的像素时，用显示控制器将所有图层与该行相关的数据取出，合成一行像素送过去。只有一个图层时，又叫Overlay技术。
由于省去合成FrameBuffer时读图层，写FrameBuffer的步骤，大幅降低了内存传输量，减少了功耗，但这个需要硬件支持。

决定Layer的合成方式是在HWC硬件部分决定的，一般上层看不到代码，不过有幸Intel、三星等等开源了一部分我们还能窥一窥源码。

如果是Overlay的图层，直接交给显示器硬件系统去在线合成；如果是FRAME_BUFFER类型的图层，需要经过OpenGL处理，然后交给FrameBuffer送给显示器。

合成流程

我们接着上一节的内容，SurfaceFlinger的handleMessageRefresh函数最后的内容。frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp，我们先来看看doComposition函数：

void SurfaceFlinger::doComposition() {
    ATRACE_CALL();
    //将mRepaintEverything置为0，不用重绘所有区域
    const bool repaintEverything = android_atomic_and(0, &mRepaintEverything);
    //遍历所有的DisplayDevice然后调用doDisplayComposition函数
    for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {
        const sp<DisplayDevice>& hw(mDisplays[dpy]);
        if (hw->isDisplayOn()) {
            // transform the dirty region into this screen's coordinate space
            //获得屏幕的脏区域
            const Region dirtyRegion(hw->getDirtyRegion(repaintEverything));
            //合成，重绘framebuffer
            // repaint the framebuffer (if needed)
            doDisplayComposition(hw, dirtyRegion);
            //清除屏幕脏区域
            hw->dirtyRegion.clear();
            //判断系统是否支持软件部分更新
            hw->flip(hw->swapRegion);
            //清除交换区域
            hw->swapRegion.clear();
        }
        // inform the h/w that we're done compositing
        //通知hwc硬件合成结束
        hw->compositionComplete();
    }
    //主要是调用hwc硬件的set函数
    //此方法将完成各个图层的合成与显示，等效于EGL标准里面的eglSwapBuffers，
    //不过eglSwapBuffers是对OpenGL标准/GPU有效，此方法是对硬件合成器有效
    postFramebuffer();
}

上述代码流程每个模块功能也很清晰，分步骤就是如下：
1）遍历所有的DisplayDevice然后调用合成相关函数；
2）获取每一个屏幕的脏区域；
3）最重要的一步：合成；
4）清除交换区域和屏幕脏区域；
5）通知hwc硬件合成结束；
6）最后主要是调用hwc硬件的set函数。此方法将完成各个图层的合成与显示，等效于EGL标准里面的eglSwapBuffers，不过eglSwapBuffers是对OpenGL标准/GPU有效，此方法是对硬件合成器有效。

其中核心的就是合成步骤。我们先看看其他几个模块：

获取每一个屏幕的脏区域。frameworks/native/services/surfaceflinger/DisplayDevice.cpp中的getDirtyRegion函数：

Region DisplayDevice::getDirtyRegion(bool repaintEverything) const {
    Region dirty;
    if (repaintEverything) {//0
        dirty.set(getBounds());
    } else {
        const Transform& planeTransform(mGlobalTransform);
        dirty = planeTransform.transform(this->dirtyRegion);
        dirty.andSelf(getBounds());
    }
    return dirty;
}

如果需要重绘所有内容，就讲脏区域设为整个屏幕（但事实我们的repaintEverything是0，所以不会）；如果不要重绘所有，先对脏区域作矩阵变换（如果屏幕有过几何变换的transform），然后用脏区域与上屏幕大小，求出脏区域在屏幕上大小。

获取了屏幕的脏区域之后，就开始合成了。

开始合成

我们继续查看doDisplayComposition函数：

void SurfaceFlinger::doDisplayComposition(const sp<const DisplayDevice>& hw,
        const Region& inDirtyRegion)
{
    // We only need to actually compose the display if:
    // 1) It is being handled by hardware composer, which may need this to
    //    keep its virtual display state machine in sync, or
    // 2) There is work to be done (the dirty region isn't empty)
    //以下两种情况我们需要去合成显示：
    //1）需要报保持虚拟显示屏和物理显示屏同步显示的情况；
    //2）SF需要去渲染的脏区域不为空。
    bool isHwcDisplay = hw->getHwcDisplayId() >= 0;
    if (!isHwcDisplay && inDirtyRegion.isEmpty()) {
        return;
    }
    //SF需要渲染的脏区域
    Region dirtyRegion(inDirtyRegion);

    // compute the invalid region
    //需要渲染到硬件帧缓冲区中去的脏区域的
    hw->swapRegion.orSelf(dirtyRegion);

    uint32_t flags = hw->getFlags();
    //在这种情况下，系统在软件上支持部分区域更新功能，
    //同样，这个部分被更新的区域必须要是一个矩形区域。
    if (flags & DisplayDevice::SWAP_RECTANGLE) {
        // we can redraw only what's dirty, but since SWAP_RECTANGLE only
        // takes a rectangle, we must make sure to update that whole
        // rectangle in that case
        dirtyRegion.set(hw->swapRegion.bounds());
    } else {
        //在这种情况下，系统在硬件上直接支持部分区域更新功能，
        //不过，这个部分被更新的区域必须要是一个矩形区域。
        if (flags & DisplayDevice::PARTIAL_UPDATES) {
            // We need to redraw the rectangle that will be updated
            // (pushed to the framebuffer).
            // This is needed because PARTIAL_UPDATES only takes one
            // rectangle instead of a region (see DisplayDevice::flip())
            dirtyRegion.set(hw->swapRegion.bounds());
        } else {
            //在这种情况下，系统不支持部分更新区域，这时候就需要更新整个屏幕的内容
            // we need to redraw everything (the whole screen)
            dirtyRegion.set(hw->bounds());
            hw->swapRegion = dirtyRegion;
        }
    }

    //如果没有开启Daltonize辅助功能（高对比性文字/色彩校正/颜色反转）
    //并且没有颜色矩阵去混合
    if (CC_LIKELY(!mDaltonize && !mHasColorMatrix)) {
        //合成
        if (!doComposeSurfaces(hw, dirtyRegion)) return;
    } else {//需要处理一下高对比性文字/色彩校正/颜色反转功能
        RenderEngine& engine(getRenderEngine());
        mat4 colorMatrix = mColorMatrix;
        if (mDaltonize) {
            colorMatrix = colorMatrix * mDaltonizer();
        }
        engine.beginGroup(colorMatrix);
        doComposeSurfaces(hw, dirtyRegion);
        engine.endGroup();
    }

    // update the swap region and clear the dirty region
    //更新与framebuffer交换的脏区域，并清除应用脏区域
    hw->swapRegion.orSelf(dirtyRegion);

    // swap buffers (presentation)
    //与fb交换脏区域，会调用eglSwapBuffer函数
    //使用egl将egl中的合成好的图像，输出到DisplayDevice的mSurface中 
    hw->swapBuffers(getHwComposer());
}

DisplayDevice类的成员变量swapRegion用来描述SurfaceFlinger服务需要渲染到硬件帧缓冲区中去的脏区域的。前面提到，inDirtyRegion也是用来描述SurfaceFlinger服务需要渲染的脏区域的，不过，它的作用是用来合成系统中各个应用程序窗口的图形缓冲区的，也就是说，当系统中各个应用程序窗口的图形缓冲区被合成之后，这个成员变量所描述的区域就会被清空，swapRegion会一直等到它的内容被渲染到硬件帧缓冲区中去之后，才会被清空。这样就可能会出现这种情况：上一次合成的图形缓冲区还未被渲染到硬件帧缓冲区中去，SurfaceFlinger服务又会执行新一轮的系统中各个应用程序窗口的图形缓冲区的合并操作。在这种情况下，SurfaceFlinger服务就需要将前面两次需要渲染到硬件帧缓冲区中去的区域合并在一起，以便可以正确地反映被刷新的UI。因此，函数在开头的地方，inDirtyRegion所描述的区域组合到成员变量swapRegion所描述的区域中去。

函数接下来调用用来描述系统主显示屏的一个DisplayDevice对象hw的成员函数getFlags来获得系统所支持的渲染方式，并且保存在一个uint32_t变量flags中。接下来，我们就分三种情况来讨论系统所支持的渲染方式：

变量flags的DisplayDevice::SWAP_RECTANGLE位等于1。在这种情况下，系统在软件上支持部分区域更新功能，同样，这个部分被更新的区域必须要是一个矩形区域。
变量flags的DisplayDevice::PARTIAL_UPDATES位等于1。在这种情况下，系统在硬件上直接支持部分区域更新功能，不过，这个部分被更新的区域必须要是一个矩形区域。
变量flags的值等于0。在这种情况下，系统不支持部分更新区域，这时候就需要更新整个屏幕的内容。

在第1种和第2种情况中，由于被更新的区域都必须是一个矩形区域，因此，函数就需要变量inDirtyRegion所描述的一个区域设置为包含了所有脏区域的一个最小矩形区域。在第3种情况中，由于需要更新的是整个屏幕的内容，因此，函数就需要inDirtyRegion所描述的一个区域设置为等于屏幕大小的一个矩形区域。

(在老的版本代码中，比如android2.3，部分更新还支持BUFFER_PRESERVED不规则区域更新。在保留后端图形缓冲区的内容的情况下，系统就可以支持仅仅渲染那些需要更新的脏区域，这些区域可以是不规则的。然而，实现不规则区域部分更新功能是有代价的，因为每次在渲染UI时，都要将后端图形缓冲区的内容拷贝回那些不在那些需要更新的区域中去，这会导致性能低下。因此，系统一般都不支持不规则区域部分更新功能。)

在安卓L版本中，辅助设置中新加了3个功能，分别是高对比性文字，颜色反转，色彩校正。

This information applies only to devices running Android 5.0 and higher.

High contrast makes text easier to read on your device. This feature fixes the text color as either black or white, depending on the original text color.

To enable or disable high contrast text, follow these steps:
Go to Settings > Accessibility.
Select High contrast text.

High-contrast text is currently an experimental feature, so it might not work correctly everywhere on your device.

google说，这个功能就是让文字更容易阅读，也就是有点类似与文字高亮。最后的效果就是，把文字变成白色或黑色，把背景文字背景变成黑色或白色。也就是说，如果你之前的文字是白色，背景是黑色，就不会去应用这个功能。

如果没有开启这个辅助功能，mDaltonize和mHasColorMatrix为null，那么直接调用doComposeSurfaces函数去合成图层；如果开启了辅助功能，那么就需要OpenGL引擎去处理颜色矩阵（高对比性文字主要是修改控件，颜色反转和颜色校正主要是通过操作gpu修改显示效果），这一部分有机会我们以后会研究研究。

那么接下来两部就是合成图层和交换FrameBuffer了，我们逐步分析。

合成图层

doComposeSurfaces

合成图层的函数是doComposeSurfaces，这个函数比较长，我们分段查看：

bool SurfaceFlinger::doComposeSurfaces(const sp<const DisplayDevice>& hw, const Region& dirty)  
{  
    RenderEngine& engine(getRenderEngine());  
    const int32_t id = hw->getHwcDisplayId();  
    HWComposer& hwc(getHwComposer());  
    HWComposer::LayerListIterator cur = hwc.begin(id);  
    const HWComposer::LayerListIterator end = hwc.end(id);  
  
    bool hasGlesComposition = hwc.hasGlesComposition(id);  
    if (hasGlesComposition) {//是否有egl合成  
        //DisplayDevice类的成员函数makeCurrent的实现很简单，
        //它只是通过调用函数eglMakeCurrent来将前面已经创建好的绘图表面以及绘图上下文设置为当前线程的绘图表面以及绘图上下文，
        //即设置为SurfaceFlinger服务的UI渲染线程的绘图表面以及绘图上下文
        if (!hw->makeCurrent(mEGLDisplay, mEGLContext)) {  
            ALOGW("DisplayDevice::makeCurrent failed. Aborting surface composition for display %s",  
                  hw->getDisplayName().string());  
            //如果绑定失败了，就要取消设置OpenGL库在当前线程的绘图表面以及绘图上下文
            eglMakeCurrent(mEGLDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);  
            //那么就要去设置默认屏幕创建好的绘图表面和上下文为当前线程的内容
            if(!getDefaultDisplayDevice()->makeCurrent(mEGLDisplay, mEGLContext)) {  
              ALOGE("DisplayDevice::makeCurrent on default display failed. Aborting.");  
            }  
            return false;  
        }  
  
        // Never touch the framebuffer if we don't have any framebuffer layers  
        const bool hasHwcComposition = hwc.hasHwcComposition(id);  
        if (hasHwcComposition) {//是否有hwc合成  
            // when using overlays, we assume a fully transparent framebuffer  
            // NOTE: we could reduce how much we need to clear, for instance  
            // remove where there are opaque FB layers. however, on some  
            // GPUs doing a "clean slate" clear might be more efficient.  
            // We'll revisit later if needed.  
            //如果使用OverLay硬件合成，就要把FrameBuffer全都清除为透明色
            engine.clearWithColor(0, 0, 0, 0);  
        } else {//是否有OpenGL合成
            //letterbox(信箱模式)
            // we start with the whole screen area  
            const Region bounds(hw->getBounds());  
  
            // we remove the scissor part  
            // we're left with the letterbox region  
            // (common case is that letterbox ends-up being empty) 
            //移除内容区域，只留下大黑边（剪裁区域） 
            const Region letterbox(bounds.subtract(hw->getScissor()));  
  
            // compute the area to clear  
            //计算大黑边区域
            Region region(hw->undefinedRegion.merge(letterbox));  
  
            // but limit it to the dirty region  
            //还要限制到更新的脏区域范围内
            region.andSelf(dirty);  
  
            // screen is already cleared here  
            //对大黑边进行挖洞处理，使用OpenGL填成黑色
            if (!region.isEmpty()) {  
                // can happen with SurfaceView  
                //SurfaceView的实现原理就是打洞覆盖：另起一个图层（即新建一个Surface），
                //并把主图层的相应区域置为透明，然后渲染就发生在新图层中，
                //最终显示效果自然是依赖SurfaceFlinger的叠加
                drawWormhole(hw, region);  
            }  
        }  
        //如果不是主显屏
        if (hw->getDisplayType() != DisplayDevice::DISPLAY_PRIMARY) {  
            // just to be on the safe side, we don't set the  
            // scissor on the main display. It should never be needed  
            // anyways (though in theory it could since the API allows it).  
            //为了安全起见，这个操作不会在主显屏发生
            const Rect& bounds(hw->getBounds());  
            const Rect& scissor(hw->getScissor());  
            if (scissor != bounds) {  
                //如果剪裁区域和屏幕尺寸不匹配，就要清除所有塔之外的内容
                //并且enble GL剪裁器，在我们不需要绘制的地方不绘制任何内容
                // scissor doesn't match the screen's dimensions, so we  
                // need to clear everything outside of it and enable  
                // the GL scissor so we don't draw anything where we shouldn't  
  
                // enable scissor for this frame  
                const uint32_t height = hw->getHeight();  
                engine.setScissor(scissor.left, height - scissor.bottom,  
                        scissor.getWidth(), scissor.getHeight());  
            }  
        }  
    }  
    
//...... 

}

这部分先调用hasGlesComposition函数和hasHwcComposition函数，就是看其对应的DisplayData中是否有hasFbComp和hasOvComp，对应有无OpenGL合成或者OverLay硬件合成。

bool HWComposer::hasGlesComposition(int32_t id) const {  
    if (!mHwc || uint32_t(id)>31 || !mAllocatedDisplayIDs.hasBit(id))  
        return true;  
    return mDisplayData[id].hasFbComp;  
} 
bool HWComposer::hasHwcComposition(int32_t id) const {  
    if (!mHwc || uint32_t(id)>31 || !mAllocatedDisplayIDs.hasBit(id))  
        return false;  
    return mDisplayData[id].hasOvComp;  
}

我们在Android SurfaceFlinger 学习之路(十一)—-合成Layer之准备合成中讲过，而这两个值是在prepare中调用Hwc的prepare函数之后赋值的，具体原理是在Android SurfaceFlinger 学习之路(十一)(PostView)–附：硬件HWC选取合成类型（Intel）中实现的，如果忘记了可以翻翻上一篇的内容。

如果有OpenGL的合成，先调用DisplayDevice类的成员函数makeCurrent，通过调用函数eglMakeCurrent来将前面已经创建好的绘图表面以及绘图上下文设置为当前线程的绘图表面以及绘图上下文，即设置为SurfaceFlinger服务的UI渲染线程的绘图表面以及绘图上下文。如果绑定失败了，就要取消设置OpenGL库在当前线程的绘图表面以及绘图上下文。那么就要去设置默认屏幕创建好的绘图表面和上下文为当前线程的内容。

因为合成有可能是混合合成，所以还要判断是否也有Overlay合成方式。如果有，就要把FrameBuffer全都清除为透明黑色。
如果没有，就是OpenGL单独合成，就要使用信箱模式。
这个只是一种比喻，信箱模式可以查一查资料，比如维基百科)中的解释。我们这里理解为图层的宽高比大于电视的宽高比的情况。从名字来看，letterbox就像邮筒一样，中间是有内容的，上下是没用的。letterbox目标就是保存原有胶片的宽高比，使内容完整的展现在屏幕上。由于内容宽高比较大，所以上下会有黑屏。采用的技术就是：抽调部分扫描线，以满足宽高比，不利的结果就是图像质量下降。

所以对于这种情况，我们需要对大黑边进行处理：
1）移除内容区域，只留下大黑边（剪裁区域）；
2）计算大黑边区域；
3）还要限制到更新的脏区域范围内；
4）对大黑边进行挖洞处理，使用OpenGL填成黑色
SurfaceView的实现原理就是打洞覆盖：另起一个图层（即新建一个Surface），并把主图层的相应区域置为透明，然后渲染就发生在新图层中，最终显示效果自然是依赖SurfaceFlinger的叠加。

最后就是一个特殊处理，对于不是主显屏（为了安全起见，这个操作不会在主显屏发生），如果剪裁区域和屏幕尺寸不匹配，就要清除所有塔之外的内容，并且enble GL剪裁器，在我们不需要绘制的地方不绘制任何内容。

继续往下看：


    /*
     * and then, render the layers targeted at the framebuffer
     */

    const Vector< sp<Layer> >& layers(hw->getVisibleLayersSortedByZ());
    const size_t count = layers.size();
    const Transform& tr = hw->getTransform();
    if (cur != end) {//代表起码有两个以上图层  
        // we're using h/w composer
        for (size_t i=0 ; i<count && cur!=end ; ++i, ++cur) {//遍历图层 
            const sp<Layer>& layer(layers[i]);
            //clip用来描述要绘制的区域，而要绘制的区域即为当前需要指定的裁剪区域
            //就是全部图层的总体脏区域和这个图层的可视区域的交集
            const Region clip(dirty.intersect(tr.transform(layer->visibleRegion)));
            if (!clip.isEmpty()) {
                switch (cur->getCompositionType()) {
                    //overlay不做处理
                    case HWC_CURSOR_OVERLAY:
                    case HWC_OVERLAY: {
                        const Layer::State& state(layer->getDrawingState());
                        if ((cur->getHints() & HWC_HINT_CLEAR_FB)
                                && i
                                && layer->isOpaque(state) && (state.alpha == 0xFF)
                                && hasGlesComposition) {
                            // never clear the very first layer since we're
                            // guaranteed the FB is already cleared
                            //上面说过，如果是Overlay合成，就要清除FrameBuffer
                            //这里以防万一，确保FB要被清除
                            layer->clearWithOpenGL(hw, clip);
                        }
                        break;
                    }
                    //如果是OpenGL合成，就调用Layer的draw函数
                    case HWC_FRAMEBUFFER: {
                        layer->draw(hw, clip);
                        break;
                    }
                    //HWC_FRAMEBUFFER_TARGET是OpenGL合成后使用的目标层，直接就跳了
                    case HWC_FRAMEBUFFER_TARGET: {
                        // this should not happen as the iterator shouldn't
                        // let us get there.
                        ALOGW("HWC_FRAMEBUFFER_TARGET found in hwc list (index=%zu)", i);
                        break;
                    }
                }
            }
            layer->setAcquireFence(hw, *cur);
        }
    } else {//只有一个或者没有图层  就直接使用OpenGL合成，调用Layer的draw
        // we're not using h/w composer
        for (size_t i=0 ; i<count ; ++i) {
            const sp<Layer>& layer(layers[i]);
            const Region clip(dirty.intersect(
                    tr.transform(layer->visibleRegion)));
            if (!clip.isEmpty()) {
                layer->draw(hw, clip);
            }
        }
    }

    // disable scissor at the end of the frame
    engine.disableScissor();
    return true;
}

这一段看注释就知道合成步骤。先根据z-order拿到所有的可视图层，然后分两种情况：
1）起码有两个以上图层：遍历图层，用全部图层的总体脏区域和这个图层的可视区域求交集，计算出clip区域。如果clip区域不为空，根据Layer的合成类型分别进行处理：

overlay不做处理，但是上面说过，如果是Overlay合成，就要清除FrameBuffer，这里以防万一，确保FB要被清除。
如果是OpenGL合成，就调用Layer的draw函数。
HWC_FRAMEBUFFER_TARGET是OpenGL合成后使用的目标层，直接就跳了。

2）只有一个或者没有图层就直接使用OpenGL合成，调用Layer的draw。

所以合成主要是OpenGL处理，Layer的draw函数。

OpenGL处理合成

我们看看Layer的draw函数实现：

1
2
3

void Layer::draw(const sp<const DisplayDevice>& hw, const Region& clip) const {
    onDraw(hw, clip, false);
}

draw内部又调用了onDraw函数，这个函数有一点点小长，我们依然分段查看：

void Layer::onDraw(const sp<const DisplayDevice>& hw, const Region& clip,
        bool useIdentityTransform) const
{
    ATRACE_CALL();
    //在纹理未创建好的情况下，一个应用程序窗口是不应该被渲染的
    if (CC_UNLIKELY(mActiveBuffer == 0)) {
        // the texture has not been created yet, this Layer has
        // in fact never been drawn into. This happens frequently with
        // SurfaceView because the WindowManager can't know when the client
        // has drawn the first time.

        // If there is nothing under us, we paint the screen in black, otherwise
        // we just skip this update.

        // figure out if there is something below us
        //在纹理未创建好的情况下，一个应用程序窗口是不应该被渲染的
        //这种情况频繁的发生在SurfaceView身上，因为WindowManger不知道它第一次绘制的时间
        //如果没有内容在它下面，我们把整个屏幕都画成黑色
        //否则就跳过这次更新
        //所以我们需要计算出在它下面的内容
        Region under;
        const SurfaceFlinger::LayerVector& drawingLayers(
                mFlinger->mDrawingState.layersSortedByZ);
        const size_t count = drawingLayers.size();
        for (size_t i=0 ; i<count ; ++i) {
            const sp<Layer>& layer(drawingLayers[i]);
            if (layer.get() == static_cast<Layer const*>(this))
                break;
            //这时候函数首先将位于当前正在处理的应用程序窗口下面的所有其它应用程序窗口的可见区域组合起来，
            //并且保存在变量under所描述的区域中    
            under.orSelf( hw->getTransform().transform(layer->visibleRegion) );
        }
        // if not everything below us is covered, we plug the holes!
        //由于这时候当前正在处理的应用程序窗口不会被绘制，
        //因此，如果变量under所描述的区域小于参数clip所描述的区域，即变量holes所描述的区域不为空，
        //那么SurfaceFlinger服务所要求缓制的区域clip就会留下一个洞
        Region holes(clip.subtract(under));
        //这个洞会被绘制成黑色，这是通过调用函数clearWithOpenGL来实现的
        if (!holes.isEmpty()) {
            clearWithOpenGL(hw, holes, 0, 0, 0, 1);
        }
        return;
    }

这段代码主要是用来处应用程序窗口的纹理尚未创建好的情况。
在纹理未创建好的情况下，一个应用程序窗口是不应该被渲染的。这时候函数首先将位于当前正在处理的应用程序窗口下面的所有其它应用程序窗口的可见区域组合起来，并且保存在变量under所描述的区域中。由于这时候当前正在处理的应用程序窗口不会被绘制，因此，如果变量under所描述的区域小于参数clip所描述的区域，即变量holes所描述的区域不为空，那么SurfaceFlinger服务所要求缓制的区域clip就会留下一个洞。这个洞会被绘制成黑色，这是通过调用函数clearWithOpenGL来实现的。绘制完成之后，函数就可以直接返回了。
这里mActiveBuffer我们在Android SurfaceFlinger 学习之路(十)—-SurfaceFlinger处理Layer更新里面的更新纹理讲过，会为其赋值。

绑定纹理

接着看onDraw函数：

// Bind the current buffer to the GL texture, and wait for it to be
    // ready for us to draw into.
    status_t err = mSurfaceFlingerConsumer->bindTextureImage();
    if (err != NO_ERROR) {
        ALOGW("onDraw: bindTextureImage failed (err=%d)", err);
        // Go ahead and draw the buffer anyway; no matter what we do the screen
        // is probably going to have something visibly wrong.
    }

这段代码首先，将buffer加入到GL texture，然后等待底层OpenGL调用GPU绘制完成纹理给我们上层返回。
我们看看SurfaceFlingerConsumer的bindTextureImage函数：

status_t SurfaceFlingerConsumer::bindTextureImage()
{
    Mutex::Autolock lock(mMutex);
    return bindTextureImageLocked();
}

又调用了父类的GLConsumer的bindTextureImageLocked函数：

status_t GLConsumer::bindTextureImageLocked() {
    if (mEglDisplay == EGL_NO_DISPLAY) {
        ALOGE("bindTextureImage: invalid display");
        return INVALID_OPERATION;
    }

    GLint error;
    while ((error = glGetError()) != GL_NO_ERROR) {
        ST_LOGW("bindTextureImage: clearing GL error: %#04x", error);
    }
    //绑定一个Texture纹理，如果没有就创建
    glBindTexture(mTexTarget, mTexName);
    if (mCurrentTexture == BufferQueue::INVALID_BUFFER_SLOT &&
            mCurrentTextureImage == NULL) {
        ST_LOGE("bindTextureImage: no currently-bound texture");
        return NO_INIT;
    }
    //创建一个Image绘制
    status_t err = mCurrentTextureImage->createIfNeeded(mEglDisplay,
                                                        mCurrentCrop);
    if (err != NO_ERROR) {
        ST_LOGW("bindTextureImage: can't create image on display=%p slot=%d",
                mEglDisplay, mCurrentTexture);
        return UNKNOWN_ERROR;
    }
    //将Image绑定到Texure
    mCurrentTextureImage->bindToTextureTarget(mTexTarget);

    // In the rare case that the display is terminated and then initialized
    // again, we can't detect that the display changed (it didn't), but the
    // image is invalid. In this case, repeat the exact same steps while
    // forcing the creation of a new image.
    if ((error = glGetError()) != GL_NO_ERROR) {
        glBindTexture(mTexTarget, mTexName);
        status_t err = mCurrentTextureImage->createIfNeeded(mEglDisplay,
                                                            mCurrentCrop,
                                                            true);
        if (err != NO_ERROR) {
            ST_LOGW("bindTextureImage: can't create image on display=%p slot=%d",
                    mEglDisplay, mCurrentTexture);
            return UNKNOWN_ERROR;
        }
        mCurrentTextureImage->bindToTextureTarget(mTexTarget);
        if ((error = glGetError()) != GL_NO_ERROR) {
            ST_LOGE("bindTextureImage: error binding external image: %#04x", error);
            return UNKNOWN_ERROR;
        }
    }

    // Wait for the new buffer to be ready.
    //等待OpenGL处理完成，返回fence
    return doGLFenceWaitLocked();
}

OpenGL绑定纹理需要四步：
1）绑定一个Texture纹理，如果没有就创建；
2）创建一个Image用于绘制；
3）将Image绑定到Texure；
4）等待OpenGL处理完成，返回fence。

我们依然分不查看：
1）绑定纹理：glBindTexture。
这里有一个特别尴尬的地方，就是我们这里的代码也看不到，因为这和GPU硬件相关，厂商不会开放这些代码的ToT。。。之前我们能看看高通、TI、甚至Intel的硬件模块代码实属运气，Google将其也放入了AOSP部分。但是对于GPU的源代码却看不到了，想想就明白了，现在显卡卖的一点都不比CPU便宜，尤其这两年人工智能、机器学习火起来，还有比特币的高涨，挖矿越来越猛烈，这些都需要超高速密集运算硬件支持，所以GPU价值和价格也有水涨船高之势头。所以指望这些厂商开发源代码实属异想天开=。=
虽然硬件代码看不到，但是我们可以曲线救国，从软件实现去分析功能。软件实现位于/frameworks/native/opengl/libagl/texture.cpp：

void glBindTexture(GLenum target, GLuint texture)
{
    ogles_context_t* c = ogles_context_t::get();
    if (target != GL_TEXTURE_2D && target != GL_TEXTURE_EXTERNAL_OES) {
        ogles_error(c, GL_INVALID_ENUM);
        return;
    }

    // Bind or create a texture
    //绑定或创建一个纹理
    sp<EGLTextureObject> tex;
    if (texture == 0) {
        // 0 is our local texture object
        //0表示是本地的纹理对象
        tex = c->textures.defaultTexture;
    } else {
        tex = c->surfaceManager->texture(texture);
        if (ggl_unlikely(tex == 0)) {
            //创建一个纹理
            tex = c->surfaceManager->createTexture(texture);
            if (tex == 0) {
                ogles_error(c, GL_OUT_OF_MEMORY);
                return;
            }
        }
    }
    bindTextureTmu(c, c->textures.active, texture, tex);
}
void bindTextureTmu(
    ogles_context_t* c, int tmu, GLuint texture, const sp<EGLTextureObject>& tex)
{
    if (tex.get() == c->textures.tmu[tmu].texture)
        return;

    // free the reference to the previously bound object
    //释放对之前纹理对象的引用
    texture_unit_t& u(c->textures.tmu[tmu]);
    if (u.texture)
        u.texture->decStrong(c);

    // bind this texture to the current active texture unit
    // and add a reference to this texture object
    //绑定这个纹理对象到当前活跃的纹理单元
    //并且增加引用计数
    u.texture = tex.get();
    u.texture->incStrong(c);
    u.name = texture;
    invalidate_texture(c, tmu);
}
static
void invalidate_texture(ogles_context_t* c, int tmu, uint8_t flags = 0xFF) {
    c->textures.tmu[tmu].dirty = flags;
}

软件实现也是先创建一个纹理texture对象，然后释放掉对之前纹理对象的引用，然后将引用指向新得纹理，再将引用计数加一，这样完成对当前纹理的绑定操作。

2）创建一个Image用于绘制：
mCurrentTextureImage是一个 EglImage，我们在Android SurfaceFlinger 学习之路(十)—-SurfaceFlinger处理Layer更新里面的更新纹理讲过，acquireBuffer时候会创建一个EglImage。所以这里调用EglImage的createIfNeeded函数：

status_t GLConsumer::EglImage::createIfNeeded(EGLDisplay eglDisplay,
                                              const Rect& cropRect,
                                              bool forceCreation) {
    // If there's an image and it's no longer valid, destroy it.
    //如果之前的image不在有效了，就要销毁它
    bool haveImage = mEglImage != EGL_NO_IMAGE_KHR;
    bool displayInvalid = mEglDisplay != eglDisplay;
    bool cropInvalid = hasEglAndroidImageCrop() && mCropRect != cropRect;
    if (haveImage && (displayInvalid || cropInvalid || forceCreation)) {
        if (!eglDestroyImageKHR(mEglDisplay, mEglImage)) {
           ALOGE("createIfNeeded: eglDestroyImageKHR failed");
        }
        mEglImage = EGL_NO_IMAGE_KHR;
        mEglDisplay = EGL_NO_DISPLAY;
    }

    // If there's no image, create one.
    //如果没有image，就要创建一个
    if (mEglImage == EGL_NO_IMAGE_KHR) {
        mEglDisplay = eglDisplay;
        mCropRect = cropRect;
        mEglImage = createImage(mEglDisplay, mGraphicBuffer, mCropRect);
    }

    // Fail if we can't create a valid image.
    //创建失败了，就只能GG了
    if (mEglImage == EGL_NO_IMAGE_KHR) {
        mEglDisplay = EGL_NO_DISPLAY;
        mCropRect.makeInvalid();
        const sp<GraphicBuffer>& buffer = mGraphicBuffer;
        ALOGE("Failed to create image. size=%ux%u st=%u usage=0x%x fmt=%d",
            buffer->getWidth(), buffer->getHeight(), buffer->getStride(),
            buffer->getUsage(), buffer->getPixelFormat());
        return UNKNOWN_ERROR;
    }

    return OK;
}

如果之前的image不在有效了，就要销毁它；如果没有image，就要创建一个；创建失败了，就只能GG了。
我们可以继续看createImage函数，如何去创建一个image：

EGLImageKHR GLConsumer::EglImage::createImage(EGLDisplay dpy,
        const sp<GraphicBuffer>& graphicBuffer, const Rect& crop) {
    EGLClientBuffer cbuf = (EGLClientBuffer)graphicBuffer->getNativeBuffer();
    EGLint attrs[] = {
        EGL_IMAGE_PRESERVED_KHR,        EGL_TRUE,
        EGL_IMAGE_CROP_LEFT_ANDROID,    crop.left,
        EGL_IMAGE_CROP_TOP_ANDROID,     crop.top,
        EGL_IMAGE_CROP_RIGHT_ANDROID,   crop.right,
        EGL_IMAGE_CROP_BOTTOM_ANDROID,  crop.bottom,
        EGL_NONE,
    };
    if (!crop.isValid()) {
        // No crop rect to set, so terminate the attrib array before the crop.
        attrs[2] = EGL_NONE;
    } else if (!isEglImageCroppable(crop)) {
        // The crop rect is not at the origin, so we can't set the crop on the
        // EGLImage because that's not allowed by the EGL_ANDROID_image_crop
        // extension.  In the future we can add a layered extension that
        // removes this restriction if there is hardware that can support it.
        attrs[2] = EGL_NONE;
    }
    /*此句为创建Image的代码*/
    EGLImageKHR image = eglCreateImageKHR(dpy, EGL_NO_CONTEXT,
            EGL_NATIVE_BUFFER_ANDROID, cbuf, attrs);
    if (image == EGL_NO_IMAGE_KHR) {
        EGLint error = eglGetError();
        ALOGE("error creating EGLImage: %#x", error);
    }
    return image;
}

上面创建Image主要代码就是eglCreateImageKHR函数，不过依然很悲催，还是和GPU相关的硬件代码。我们只能继续曲线救国了，查看软件创建Image的实现，位于/frameworks/native/opengl/libagl/egl.cpp：

EGLImageKHR eglCreateImageKHR(EGLDisplay dpy, EGLContext ctx, EGLenum target,
        EGLClientBuffer buffer, const EGLint* /*attrib_list*/)
{
    if (egl_display_t::is_valid(dpy) == EGL_FALSE) {
        return setError(EGL_BAD_DISPLAY, EGL_NO_IMAGE_KHR);
    }
    if (ctx != EGL_NO_CONTEXT) {
        return setError(EGL_BAD_CONTEXT, EGL_NO_IMAGE_KHR);
    }
    if (target != EGL_NATIVE_BUFFER_ANDROID) {
        return setError(EGL_BAD_PARAMETER, EGL_NO_IMAGE_KHR);
    }
    //这个buffer还是我们上层acquireBuffer时候获取的图形缓冲区buffer
    ANativeWindowBuffer* native_buffer = (ANativeWindowBuffer*)buffer;

    if (native_buffer->common.magic != ANDROID_NATIVE_BUFFER_MAGIC)
        return setError(EGL_BAD_PARAMETER, EGL_NO_IMAGE_KHR);

    if (native_buffer->common.version != sizeof(ANativeWindowBuffer))
        return setError(EGL_BAD_PARAMETER, EGL_NO_IMAGE_KHR);

    switch (native_buffer->format) {
        case HAL_PIXEL_FORMAT_RGBA_8888:
        case HAL_PIXEL_FORMAT_RGBX_8888:
        case HAL_PIXEL_FORMAT_RGB_888:
        case HAL_PIXEL_FORMAT_RGB_565:
        case HAL_PIXEL_FORMAT_BGRA_8888:
            break;
        default:
            return setError(EGL_BAD_PARAMETER, EGL_NO_IMAGE_KHR);
    }

    native_buffer->common.incRef(&native_buffer->common);
    return (EGLImageKHR)native_buffer;
}

说是创建一个EGLImageKHR，其实还是对我们上层acquireBuffer时候获取的图形缓冲区buffer，进行一些处理包装。因为这是软件实现，所以参考价值不大吧。

3）将Image绑定到Texure：

1
2
3

void GLConsumer::EglImage::bindToTextureTarget(uint32_t texTarget) {
    glEGLImageTargetTexture2DOES(texTarget, (GLeglImageOES)mEglImage);
}

这次就真尴尬了，别说没硬件实现了，连软件都没得看了。。。。。。曲线救国没戏了，大清要亡啊。。。。。
中华民国到来，学医救不了中国。。。。。。java救不了中国，但是php能=。=
沦落到看模拟器实现绑定，看看goldfish的实现，位于device/generic/goldfish/opengl/system/GLESv2/gl2.cpp：

//GL extensions
void glEGLImageTargetTexture2DOES(void * self, GLenum target, GLeglImageOES image)
{
    DBG("glEGLImageTargetTexture2DOES v2 target=%#x img=%p\n", target, image);
    //TODO: check error - we don't have a way to set gl error
    android_native_buffer_t* native_buffer = (android_native_buffer_t*)image;

    if (native_buffer->common.magic != ANDROID_NATIVE_BUFFER_MAGIC) {
        return;
    }

    if (native_buffer->common.version != sizeof(android_native_buffer_t)) {
        return;
    }

    GET_CONTEXT;
    DEFINE_AND_VALIDATE_HOST_CONNECTION();
    //openGL的context上下文覆盖纹理坐标
    ctx->override2DTextureTarget(target);
    //然后用渲染引擎绑定Image的缓冲区引用
    rcEnc->rcBindTexture(rcEnc, ((cb_handle_t *)(native_buffer->handle))->hostHandle);
    //然后恢复纹理
    ctx->restore2DTextureTarget();

    return;
}

看代码核心也是三步：openGL的context上下文覆盖纹理坐标；然后用渲染引擎绑定Image的缓冲区引用；然后恢复纹理。

4）等待OpenGL处理完成，返回fence：
上一节更新纹理时候讲过，里面调用acquireBufferLocked，buffer状态迁移到acquire，获得要显示出来的Buffer。这里会创建一个Fence，目前acquire fencefd还没使用，因为还未去合成这个layer，没到用layer中数据的时候。
如果到了合成步骤，这个Fence才是使用的时机，就是接下来第四部做的操作：

// 等待生产者的acquire fence触发
status_t GLConsumer::doGLFenceWaitLocked() const {

    EGLDisplay dpy = eglGetCurrentDisplay();
    EGLContext ctx = eglGetCurrentContext();

    if (mEglDisplay != dpy || mEglDisplay == EGL_NO_DISPLAY) {
        ST_LOGE("doGLFenceWait: invalid current EGLDisplay");
        return INVALID_OPERATION;
    }

    if (mEglContext != ctx || mEglContext == EGL_NO_CONTEXT) {
        ST_LOGE("doGLFenceWait: invalid current EGLContext");
        return INVALID_OPERATION;
    }
     //等待生产者的acquire fence触发，
    if (mCurrentFence->isValid()) {
        //检查EGL库是否支持EGL_ANDROID_native_fence_sync或者EGL_KHR_fence_sync属性的fence
        if (SyncFeatures::getInstance().useWaitSync()) {
            // Create an EGLSyncKHR from the current fence.
            //dup一份上层传来的fence
            int fenceFd = mCurrentFence->dup();
            if (fenceFd == -1) {
                ST_LOGE("doGLFenceWait: error dup'ing fence fd: %d", errno);
                return -errno;
            }
            EGLint attribs[] = {
                EGL_SYNC_NATIVE_FENCE_FD_ANDROID, fenceFd,
                EGL_NONE
            };
            //创建一个GPU的fence
            EGLSyncKHR sync = eglCreateSyncKHR(dpy,
                    EGL_SYNC_NATIVE_FENCE_ANDROID, attribs);
            if (sync == EGL_NO_SYNC_KHR) {
                close(fenceFd);
                ST_LOGE("doGLFenceWait: error creating EGL fence: %#x",
                        eglGetError());
                return UNKNOWN_ERROR;
            }

            // XXX: The spec draft is inconsistent as to whether this should
            // return an EGLint or void.  Ignore the return value for now, as
            // it's not strictly needed.
            //GPU的fence等待，绘制完成会唤醒
            eglWaitSyncKHR(dpy, sync, 0);
            EGLint eglErr = eglGetError();
            //唤醒后移除fence围栏
            eglDestroySyncKHR(dpy, sync);
            if (eglErr != EGL_SUCCESS) {
                ST_LOGE("doGLFenceWait: error waiting for EGL fence: %#x",
                        eglErr);
                return UNKNOWN_ERROR;
            }
        } else {//不支持则上层fence去wait，一般都是-1
            status_t err = mCurrentFence->waitForever(
                    "GLConsumer::doGLFenceWaitLocked");
            if (err != NO_ERROR) {
                ST_LOGE("doGLFenceWait: error waiting for fence: %d", err);
                return err;
            }
        }
    }

    return NO_ERROR;
}

等待逻辑步骤如下：
1）这里会先等待生产者的acquire fence触发，检查这个Fence是否生效；
2）然后查询EGL库是否支持EGL_ANDROID_native_fence_sync或者EGL_KHR_fence_sync属性的fence，这些都是从OpenGL相关的so库中获取，我们看看实现，位于frameworks/native/libs/gui/SyncFeatures.cpp：

SyncFeatures::SyncFeatures() : Singleton<SyncFeatures>(),
        mHasNativeFenceSync(false),
        mHasFenceSync(false),
        mHasWaitSync(false) {
    EGLDisplay dpy = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    // This can only be called after EGL has been initialized; otherwise the
    // check below will abort.
    const char* exts = eglQueryStringImplementationANDROID(dpy, EGL_EXTENSIONS);
    LOG_ALWAYS_FATAL_IF(exts == NULL, "eglQueryStringImplementationANDROID failed");
    if (strstr(exts, "EGL_ANDROID_native_fence_sync")) {
        // This makes GLConsumer use the EGL_ANDROID_native_fence_sync
        // extension to create Android native fences to signal when all
        // GLES reads for a given buffer have completed.
        mHasNativeFenceSync = true;
    }
    if (strstr(exts, "EGL_KHR_fence_sync")) {
        mHasFenceSync = true;
    }
    if (strstr(exts, "EGL_KHR_wait_sync")) {
        mHasWaitSync = true;
    }
    mString.append("[using:");
    if (useNativeFenceSync()) {
        mString.append(" EGL_ANDROID_native_fence_sync");
    }
    if (useFenceSync()) {
        mString.append(" EGL_KHR_fence_sync");
    }
    if (useWaitSync()) {
        mString.append(" EGL_KHR_wait_sync");
    }
    mString.append("]");
}
bool SyncFeatures::useNativeFenceSync() const {
    // EGL_ANDROID_native_fence_sync is not compatible with using the
    // EGL_KHR_fence_sync extension for the same purpose.
    return mHasNativeFenceSync;
}
bool SyncFeatures::useFenceSync() const {
#ifdef DONT_USE_FENCE_SYNC
    // on some devices it's better to not use EGL_KHR_fence_sync
    // even if they have it
    return false;
#endif
    // currently we shall only attempt to use EGL_KHR_fence_sync if
    // USE_FENCE_SYNC is set in our makefile
    return !mHasNativeFenceSync && mHasFenceSync;
}
bool SyncFeatures::useWaitSync() const {
    return (useNativeFenceSync() || useFenceSync()) && mHasWaitSync;
}

查询GPU相关属性在eglQueryStringImplementationANDROID函数，不过这次我们曲线救国都没用了，中华民国也GG了=。=想想也是，Fence实现每家GPU都不同，并且也算比较重要的技术，肯定不会给我们开放的。。。

3）如果支持硬件Fence围栏，那么就用上层传入的fence去dup一份copy，然后根据这个copy创建一个GPU的fence。eglCreateSyncKHR依然GG，php也救不了中国～

4）GPU的fence等待，绘制完成会唤醒。等待操作GG。。。唤醒后就要销毁这个fence，放开栅栏；

5）fence的合法性验证为是否为-1，如果上层使用OpenGL绘制，那么fence就不为-1，下层也需要OpenGL绘制纹理；如果上层使用canvas绘制，那么fence就为-1，则gpu不等待，直接合成ok。

这就是OpenGL绑定纹理的操作，其中比较重要的是Fence在中间穿插的作用，这里只是简单分析，如果有机会，我会抽出一章专门分析一下。

drawWithOpenGL

我们继续回到Layer的onDraw函数，继续分析合成步骤。
继续看下一部分：

//这个Layer是否是受保护的，比如截屏的Layer
bool blackOutLayer = isProtected() || (isSecure() && !hw->isSecure());

    RenderEngine& engine(mFlinger->getRenderEngine());
    //不是受保护的Layer
    if (!blackOutLayer) {
        // TODO: we could be more subtle with isFixedSize()
        //是否是规则的形状，或者上层应用程序有能力确认缓冲区的有效性
        //如果isFixedSize为true，那么就很容易处理图形的变换
        const bool useFiltering = getFiltering() || needsFiltering(hw) || isFixedSize();

        // Query the texture matrix given our current filtering mode.
        float textureMatrix[16];
        mSurfaceFlingerConsumer->setFilteringEnabled(useFiltering);
        mSurfaceFlingerConsumer->getTransformMatrix(textureMatrix);
        //如果这个图形缓冲区之前曾经被旋转过，例如，被水平翻转或者垂直翻转过，
        //那么在对它进行合并之前，还需要将它的旋转方向恢复回来
        if (mSurfaceFlingerConsumer->getTransformToDisplayInverse()) {

            /*
             * the code below applies the display's inverse transform to the texture transform
             */

            // create a 4x4 transform matrix from the display transform flags
            const mat4 flipH(-1,0,0,0,  0,1,0,0, 0,0,1,0, 1,0,0,1);
            const mat4 flipV( 1,0,0,0, 0,-1,0,0, 0,0,1,0, 0,1,0,1);
            const mat4 rot90( 0,1,0,0, -1,0,0,0, 0,0,1,0, 1,0,0,1);

            mat4 tr;
            uint32_t transform = hw->getOrientationTransform();
            if (transform & NATIVE_WINDOW_TRANSFORM_ROT_90)
                tr = tr * rot90;
            if (transform & NATIVE_WINDOW_TRANSFORM_FLIP_H)
                tr = tr * flipH;
            if (transform & NATIVE_WINDOW_TRANSFORM_FLIP_V)
                tr = tr * flipV;

            // calculate the inverse
            //对它进行合并之前，还需要将它的旋转方向恢复回来
            //所以需要反转变换矩阵
            tr = inverse(tr);

            // and finally apply it to the original texture matrix
            //然后将它应用到纹理中
            const mat4 texTransform(mat4(static_cast<const float*>(textureMatrix)) * tr);
            memcpy(textureMatrix, texTransform.asArray(), sizeof(textureMatrix));
        }

        // Set things up for texturing.
        //将上面对纹理的配置设置进来
        mTexture.setDimensions(mActiveBuffer->getWidth(), mActiveBuffer->getHeight());
        mTexture.setFiltering(useFiltering);
        mTexture.setMatrix(textureMatrix);

        engine.setupLayerTexturing(mTexture);
    } else {
        engine.setupLayerBlackedOut();
    }

我们处理合成的Layer一般都是不受保护的Layer，如果是截屏或者其他被保护的Layer，blackOutLayer就为true。
这里再说一下isFixedSize，这个在讲Android SurfaceFlinger 学习之路(九)—-SurfaceFlinger事务处理的时候提到过，我们再复习一下。
Layer类的成员变量mFixedSize是一个布尔变量，它的值可以通过Layer类的成员函数isFixedSize来获得。从前面Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface可以知道，当Android应用程序请求SurfaceFlinger服务分配一块图形缓冲区时，Android应用程序会传递两个参数reqWidth和reqHeight过来，表示请求分配的图形缓冲区的宽度和高度。这两个参数是可以同时等于0的，表示使用默认的宽度和高度值来创建所请求的图形缓冲区。这两个默认的宽度和高度值即等于当前所处理的应用程序窗口的宽度和高度值，而后者的宽度和高度值是在其创建的时候指定的。
Layer类的成员函数requestBuffer的参数reqWidth和reqHeight的值等于0意味着什么呢？从前面Android SurfaceFlinger 学习之路(八)—-Surface管理图形缓冲区可以知道，Android应用程序在请求SurfaceFlinger服务分配一块图形缓冲区之前，会通过在Surface类内部来检查当前所处理的应用程序窗口的大小是否发生了变化。如果发生了变化，那么Android应用程序就会忽略掉缓存自己一侧的图形缓冲区，而去SurfaceFlinger服务请求新的图形缓冲区，因为那些缓存的图形缓冲区由于与它们所关联的应用程序窗口大小发生了变化而变为无效了。但是有一种特殊情况，在Android应用程序这一侧，用来描述应用程序窗口的Surface类可以不维护应用程序窗口的大小值。在这种情况下，Surface类就会将与它所关联的应用程序窗口的大小值设置为0，这意味着Android应用程序每次为这个应用程序窗口向SurfaceFlinger服务请求分配图形缓冲区之前，都认为这个应用程序窗口的大小值没有发生变化，同时传递给Layer类的参数reqWidth和reqHeight的值会等于0。事实上，一个应用程序窗口的大小是随时都可以发生变化的，比如，我们可以通过调用用来在Android应用程序和SurfaceFlinger服务建立连接的一个类型为Client的Binder对象的成员函数setState来改变一个应用程序窗口的大小，而一旦一个应用程序窗口的大小发生了变化，Layer类的成员函数doTransaction就会被调用。
Layer类的成员函数doTransaction在处理应用程序窗口大小变化时，需要考虑Android应用程序每次在为该应用程序窗口向SurfaceFlinger服务请求分配图形缓冲区之前，是否有能力去判断之前为该应用程序窗口缓存的图形缓冲区的有效性。如果没有的话，那么Layer类的成员函数doTransaction就需要将为该应用程序窗口缓存的图形缓冲区设置为无效，以便以后Android应用程序可以请求SurfaceFlinger服务分配新的、大小正确的图形缓冲区。从前面的分析还可以知道，当Android应用程序没有能力去判断之前为一个应用程序窗口所缓存的图形缓冲区的有效性时，那么之前在请求分配这些图形缓冲区时，传递给Layer类的的参数reqWidth和reqHeight的值就会等于0，这时候Layer类就会将Layer类的成员变量mFixedSize的值设置为false。
当Layer类的成员变量mFixedSize的值等于false时，由于Android应用程序没有能力去判断之前为一个应用程序窗口所缓存的图形缓冲区的有效性，因此，Layer类的成员函数doTransaction除了会调用外一个成员函数setBuffers来将新的应用程序窗口大小记录下来之外，还会通知BufferQueueProducer将当前正在处理的应用程序窗口所缓存的图形缓冲区设置为无效。
当Layer类的成员变量mFixedSize的值等于false时，Layer类的成员函数doTransaction还会提前将成员变量mCurrentState所描述的一个State对象的成员变量requested_w和requested_h的值保存到成员变量mDrawingState所描述的一个State对象的成员变量requested_w和requested_h中去，这是为了避免后面调用父类Layer的成员函数doTransaction时，会返回一个Layer::eVisibleRegion位不等于0的标志值给前面，而这将会导致SurfaceFlinger服务马上重新计算各个应用程序窗口的可见区域。现在不返回一个Layer::eVisibleRegion位不等于0的标志值给前面，就会等到下次渲染当前正在处理的应用程序窗口时再重新计算各个应用程序窗口的可见区域。

太长了，跳过~
GLConsumer的构造函数中mFilteringEnabled(true)，所以filter为true。filter参数是OpenGL中使用纹理坐标映射到纹素数组，比如我们在doTransatin时候提到的线性滤波方法(linear filtering)。要理解这个也是需要OpenGL基础啊，奈何我也是小白=。=不过我们知道这里就是打开了滤波设置。

接下来代码用来检查当前正在处理的应用程序窗口的图形缓冲区是否是一个可以跳过合成阶段的图形缓冲区。本来这种图形缓冲区是可以直接渲染到硬件帧缓冲区中去的，但是由于它不是全屏显示的，因此就需要与其它应用程序窗口的图形缓冲区进行合并操作。如果这个图形缓冲区之前曾经被旋转过，例如，被水平翻转或者垂直翻转过，那么在对它进行合并之前，还需要将它的旋转方向恢复回来。
当用来描述一个图形缓冲区的一个GraphicBuffer对象的成员变量transform的值不等于0时，那么就说明这个图形缓冲区是被旋转过的，这时候函数就会对这个成员变量的值的NATIVE_WINDOW_TRANSFORM_FLIP_H位或者NATIVE_WINDOW_TRANSFORM_FLIP_V位进行取反，目的就是为了恢复它之前的旋转方向。

然后进入最后一部分，drawWithOpenGL：

1 2	drawWithOpenGL(hw, clip, useIdentityTransform); engine.disableTexturing();

drawWithOpenGL来将这个图形缓冲区的内容绘制在系统的主显示屏的指定区域上来，这个图形缓冲区的内容是使用mesh对象来描述的，包括顶点缓冲,索引缓冲,纹理对象等，而指定的主显示屏区域是由参数clip来描述的。


void Layer::drawWithOpenGL(const sp<const DisplayDevice>& hw,
        const Region& /* clip */, bool useIdentityTransform) const {
    const uint32_t fbHeight = hw->getHeight();
    const State& s(getDrawingState());

    computeGeometry(hw, mMesh, useIdentityTransform);

    /*
     * NOTE: the way we compute the texture coordinates here produces
     * different results than when we take the HWC path -- in the later case
     * the "source crop" is rounded to texel boundaries.
     * This can produce significantly different results when the texture
     * is scaled by a large amount.
     *
     * The GL code below is more logical (imho), and the difference with
     * HWC is due to a limitation of the HWC API to integers -- a question
     * is suspend is whether we should ignore this problem or revert to
     * GL composition when a buffer scaling is applied (maybe with some
     * minimal value)? Or, we could make GL behave like HWC -- but this feel
     * like more of a hack.
     */
    const Rect win(computeBounds());

    float left   = float(win.left)   / float(s.active.w);
    float top    = float(win.top)    / float(s.active.h);
    float right  = float(win.right)  / float(s.active.w);
    float bottom = float(win.bottom) / float(s.active.h);

    // TODO: we probably want to generate the texture coords with the mesh
    // here we assume that we only have 4 vertices
    Mesh::VertexArray<vec2> texCoords(mMesh.getTexCoordArray<vec2>());
    texCoords[0] = vec2(left, 1.0f - top);
    texCoords[1] = vec2(left, 1.0f - bottom);
    texCoords[2] = vec2(right, 1.0f - bottom);
    texCoords[3] = vec2(right, 1.0f - top);

    RenderEngine& engine(mFlinger->getRenderEngine());
    engine.setupLayerBlending(mPremultipliedAlpha, isOpaque(s), s.alpha);
    engine.drawMesh(mMesh);
    engine.disableBlending();
}

这个我们也是分步查看：

    //主显示屏高度
    const uint32_t fbHeight = hw->getHeight();
    //当前正在处理的应用程序窗口状态的一个State对象s
    const State& s(getDrawingState());
    computeGeometry(hw, mMesh, useIdentityTransform);

/*-----------------*/
void Layer::computeGeometry(const sp<const DisplayDevice>& hw, Mesh& mesh,
        bool useIdentityTransform) const
{
    const Layer::State& s(getDrawingState());
    //上一步反转后的变换transform
    const Transform tr(useIdentityTransform ?
            hw->getTransform() : hw->getTransform() * s.transform);
    const uint32_t hw_h = hw->getHeight();
    Rect win(s.active.w, s.active.h);
    if (!s.active.crop.isEmpty()) {
        win.intersect(s.active.crop, &win);
    }
    // subtract the transparent region and snap to the bounds
    //应用程序窗口减去透明区域
    win = reduce(win, s.activeTransparentRegion);
    //获取纹理的位置坐标
    Mesh::VertexArray<vec2> position(mesh.getPositionArray<vec2>());
    position[0] = tr.transform(win.left,  win.top);
    position[1] = tr.transform(win.left,  win.bottom);
    position[2] = tr.transform(win.right, win.bottom);
    position[3] = tr.transform(win.right, win.top);
    for (size_t i=0 ; i<4 ; i++) {
        position[i].y = hw_h - position[i].y;
    }
}

这段代码首先得到主显示屏的高度fbHeight、要绘制的区域mesh的位置坐标，以及用来描述当前正在处理的应用程序窗口状态的一个State对象s。

接着往下看：

 const Rect win(computeBounds());

    float left   = float(win.left)   / float(s.active.w);
    float top    = float(win.top)    / float(s.active.h);
    float right  = float(win.right)  / float(s.active.w);
    float bottom = float(win.bottom) / float(s.active.h);

    // TODO: we probably want to generate the texture coords with the mesh
    // here we assume that we only have 4 vertices
    Mesh::VertexArray<vec2> texCoords(mMesh.getTexCoordArray<vec2>());
    texCoords[0] = vec2(left, 1.0f - top);
    texCoords[1] = vec2(left, 1.0f - bottom);
    texCoords[2] = vec2(right, 1.0f - bottom);
    texCoords[3] = vec2(right, 1.0f - top);
/*-----------------*/
Rect Layer::computeBounds() const {
    const Layer::State& s(getDrawingState());
    Rect win(s.active.w, s.active.h);
    if (!s.active.crop.isEmpty()) {
        win.intersect(s.active.crop, &win);
    }
    // subtract the transparent region and snap to the bounds
    return reduce(win, s.activeTransparentRegion);
}

上面是根据mesh的位置计算出纹理顶点的坐标。
如果Android应用程序没有指定一个窗口的纹理坐标，那么这个窗口的纹理坐标的默认值就使用要绘制的纹理的四个角的坐标来描述。注意，在计算纹理坐标的时候，还要考虑纹理的大小，以及纹理本身所设置的缩放因子，以便可以正确地将纹理绘制在应用程序窗口中。

继续往下，先看看这一步：

1 2	RenderEngine& engine(mFlinger->getRenderEngine()); engine.setupLayerBlending(mPremultipliedAlpha, isOpaque(s), s.alpha);

Android在此新增一个RenderEngine类，用来屏蔽OpenGL ES1.0、1.1和2.0的用法差异。基本用法和opengl是一样的，没有简化太多。
这一步是对颜色的处理，我们看看OpenGL E2.0的实现，位于frameworks/native/services/surfaceflinger/RenderEngine/GLES20RenderEngine.cpp：

void GLES20RenderEngine::setupDimLayerBlending(int alpha) {
    mState.setPlaneAlpha(1.0f);
    mState.setPremultipliedAlpha(true);
    mState.setOpaque(false);
    mState.setColor(0, 0, 0, alpha/255.0f);
    mState.disableTexture();

    if (alpha == 0xFF) {
        glDisable(GL_BLEND);
    } else {
        glEnable(GL_BLEND);
        glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);
    }
}

这里是设定图层混合的模式（mPremultipliedAlpha表示该图层是否已经做过预乘处理，Opaque表示该图层像素是否无视本图层的透明度，s.alpha表示该图层的整体透明度）。是否需要以混合模式来绘制，这是通过调用函数glEnable(GL_BLEND)来实现的。在需要混合模式来绘制纹理texture的情况下，还需要调用函数glBlendFunc来指定混合函数。
当前正在处理的应用程序窗口的Alpha通道的值小于0xFF，即State对象s的成员变量alpha的值小于0xFF，这表明该窗口的背景是半透明的。此时就需要使用混合模式来绘制纹理。

我们看最后一部分：

    engine.drawMesh(mMesh);
    engine.disableBlending();

/*---------GLES20RenderEngine.cpp---------*/
void GLES20RenderEngine::drawMesh(const Mesh& mesh) {

    ProgramCache::getInstance().useProgram(mState);
    //指定要绘制的顶点数组
    if (mesh.getTexCoordsSize()) {
        glEnableVertexAttribArray(Program::texCoords);
        glVertexAttribPointer(Program::texCoords,
                mesh.getTexCoordsSize(),
                GL_FLOAT, GL_FALSE,
                mesh.getByteStride(),
                mesh.getTexCoords());
    }
    //指定要绘制的纹理坐标
    glVertexAttribPointer(Program::position,
            mesh.getVertexSize(),
            GL_FLOAT, GL_FALSE,
            mesh.getByteStride(),
            mesh.getPositions());
    //绘制前面指定的顶点数组以及纹理
    glDrawArrays(mesh.getPrimitive(), 0, mesh.getVertexCount());

    if (mesh.getTexCoordsSize()) {
        glDisableVertexAttribArray(Program::texCoords);
    }
}
void GLES20RenderEngine::disableBlending() {
    glDisable(GL_BLEND);
}

分别调用函数glVertexPointer和glTexCoordPointer来指定要绘制的顶点数组以及纹理坐标。设置好要绘制的顶点数组以及纹理坐标之后，最后调用函数glDrawArrays来绘制前面指定的顶点数组以及纹理。
其中这三个函数依然让我们曲线救国失败啊，大清彻底亡了=。=

doComposeSurfaces流程就分析完了，我们回到SF的doDisplayComposition函数继续。

到此合成流程就完了，接下来到了和FB交换buffer。

交换合成缓冲区

沿着上面到了doDisplayComposition的最后一步。与fb交换脏区域，会调用eglSwapBuffer函数，使用egl将egl中的合成好的图像，输出到DisplayDevice的mSurface中。
继续查看，调用DisplayDevice的swapBuffers函数：

void DisplayDevice::swapBuffers(HWComposer& hwc) const {
    // We need to call eglSwapBuffers() if:
    //  (1) we don't have a hardware composer, or
    //  (2) we did GLES composition this frame, and either
    //    (a) we have framebuffer target support (not present on legacy
    //        devices, where HWComposer::commit() handles things); or
    //    (b) this is a virtual display
    //当以下几种情况我们会调用eglSwapBuffers：
    //1.没有硬件合成器
    //2.使用OpenGL合成这一帧时候，以下两种情况之一
    //a.有FRAME_BUFFER_TARGET支持（overlay合成时候还有遗留的设备）
    //b.这是一个虚拟显屏
    if (hwc.initCheck() != NO_ERROR ||
            (hwc.hasGlesComposition(mHwcDisplayId) &&
             (hwc.supportsFramebufferTarget() || mType >= DISPLAY_VIRTUAL))) {
        //调用OpenGL库中的函数eglSwapBuffers来将系统的UI渲染到系统的主绘图表面上去的
        EGLBoolean success = eglSwapBuffers(mDisplay, mSurface);
        if (!success) {
            EGLint error = eglGetError();
            if (error == EGL_CONTEXT_LOST ||
                    mType == DisplayDevice::DISPLAY_PRIMARY) {
                LOG_ALWAYS_FATAL("eglSwapBuffers(%p, %p) failed with 0x%08x",
                        mDisplay, mSurface, error);
            } else {
                ALOGE("eglSwapBuffers(%p, %p) failed with 0x%08x",
                        mDisplay, mSurface, error);
            }
        }
    }

    status_t result = mDisplaySurface->advanceFrame();
    if (result != NO_ERROR) {
        ALOGE("[%s] failed pushing new frame to HWC: %d",
                mDisplayName.string(), result);
    }
}

调用OpenGL库中的函数eglSwapBuffers来将系统的UI渲染到系统的主绘图表面上去的，即渲染到系统的硬件帧缓冲区上去的。
这里天不亡大清~~继续曲线救国，我们看看软件的实现，位于frameworks/native/opengl/libagl/egl.cpp：

EGLBoolean eglSwapBuffers(EGLDisplay dpy, EGLSurface draw)
{
    if (egl_display_t::is_valid(dpy) == EGL_FALSE)
        return setError(EGL_BAD_DISPLAY, EGL_FALSE);
    //将EGLSurface 强转为egl_surface_t结构体指针
    egl_surface_t* d = static_cast<egl_surface_t*>(draw);
    if (!d->isValid())
        return setError(EGL_BAD_SURFACE, EGL_FALSE);
    if (d->dpy != dpy)
        return setError(EGL_BAD_DISPLAY, EGL_FALSE);

    // post the surface
    //然后调用swapBuffers完成交换操作
    d->swapBuffers();

    // if it's bound to a context, update the buffer
    if (d->ctx != EGL_NO_CONTEXT) {
        d->bindDrawSurface((ogles_context_t*)d->ctx);
        // if this surface is also the read surface of the context
        // it is bound to, make sure to update the read buffer as well.
        // The EGL spec is a little unclear about this.
        egl_context_t* c = egl_context_t::context(d->ctx);
        if (c->read == draw) {
            d->bindReadSurface((ogles_context_t*)d->ctx);
        }
    }

    return EGL_TRUE;
}

先将将EGLSurface 强转为egl_surface_t结构体指针，这里为什么能强转，我们下面一个小节会讲到。接着调用swapBuffers无参函数完成交换。同样位于frameworks/native/opengl/libagl/egl.cpp下：

EGLBoolean egl_window_surface_v2_t::swapBuffers()
{
    if (!buffer) {
        return setError(EGL_BAD_ACCESS, EGL_FALSE);
    }
    
    /*
     * Handle eglSetSwapRectangleANDROID()
     * We copyback from the front buffer 
     */
     //如果合成区域的脏区域不为空
    if (!dirtyRegion.isEmpty()) {
        //首先通过andSelf（）函数，算出在buffer中的dirtyRegion的区域
        dirtyRegion.andSelf(Rect(buffer->width, buffer->height));
        //如果上一次buffer不为空
        if (previousBuffer) {
            // This was const Region copyBack, but that causes an
            // internal compile error on simulator builds
            //然后调用subtract将oldDirtyRegion中去掉了dirtyRegion区域，
            //然后见这块区域从previousBuffer拷贝到当前的buffer中。
            /*const*/ Region copyBack(Region::subtract(oldDirtyRegion, dirtyRegion));
            if (!copyBack.isEmpty()) {
                void* prevBits;
                if (lock(previousBuffer, 
                        GRALLOC_USAGE_SW_READ_OFTEN, &prevBits) == NO_ERROR) {
                    // copy from previousBuffer to buffer
                    copyBlt(buffer, bits, previousBuffer, prevBits, copyBack);
                    unlock(previousBuffer);
                }
            }
        }
        //将新的脏区域赋值给oldDirtyRegion
        oldDirtyRegion = dirtyRegion;
    }
    //将少之前buffer的对gralloc的引用
    if (previousBuffer) {
        previousBuffer->common.decRef(&previousBuffer->common); 
        previousBuffer = 0;
    }
    
    unlock(buffer);
    //完成buffer内容的填充，然后将previousBuffer指向buffer
    previousBuffer = buffer;
    //这里的nativeWindow是egl_window_surface_v2_t结构体的成员变量
    //是一个ANativeWindow*类型
    //在DisplayDevice构造函数里调用eglCreateWindowSurface创建egl_window_surface_v2_t实例时候，
    //new了一个Surface传入的
    //这里还调用了Surface的queueBuffer函数
    //从之前将Surface管理缓冲区得知，这会回调consumer的onFrameAvailable函数
    //调用surface的queueBuffer，agl的实现fencefd输入为-1
    //硬件平台不为-1，比如抓高通的log
    //肯定在前面先创建了fence同步对象，经过merge后肯定不再为-1了
    nativeWindow->queueBuffer(nativeWindow, buffer, -1);
    buffer = 0;

    // dequeue a new buffer
    int fenceFd = -1;
    //然后dequeue一个新的buffer，并等待fence
    ///第一次被申请的buffer slot。返回-1
    //假设不是。有release fence，则会dup该fencefd
    if (nativeWindow->dequeueBuffer(nativeWindow, &buffer, &fenceFd) == NO_ERROR) {
        sp<Fence> fence(new Fence(fenceFd));
        //wait，等待release fence触发
        //如果fence超时，就把buffer cancel掉。
        if (fence->wait(Fence::TIMEOUT_NEVER)) {
            nativeWindow->cancelBuffer(nativeWindow, buffer, fenceFd);
            return setError(EGL_BAD_ALLOC, EGL_FALSE);
        }

        // reallocate the depth-buffer if needed
        //按需重新计算buffer
        if ((width != buffer->width) || (height != buffer->height)) {
            // TODO: we probably should reset the swap rect here
            // if the window size has changed
            width = buffer->width;
            height = buffer->height;
            if (depth.data) {
                free(depth.data);
                depth.width   = width;
                depth.height  = height;
                depth.stride  = buffer->stride;
                depth.data    = (GGLubyte*)malloc(depth.stride*depth.height*2);
                if (depth.data == 0) {
                    setError(EGL_BAD_ALLOC, EGL_FALSE);
                    return EGL_FALSE;
                }
            }
        }

        // keep a reference on the buffer
        buffer->common.incRef(&buffer->common);

        // finally pin the buffer down
        if (lock(buffer, GRALLOC_USAGE_SW_READ_OFTEN |
                GRALLOC_USAGE_SW_WRITE_OFTEN, &bits) != NO_ERROR) {
            ALOGE("eglSwapBuffers() failed to lock buffer %p (%ux%u)",
                    buffer, buffer->width, buffer->height);
            return setError(EGL_BAD_ACCESS, EGL_FALSE);
            // FIXME: we should make sure we're not accessing the buffer anymore
        }
    } else {
        return setError(EGL_BAD_CURRENT_SURFACE, EGL_FALSE);
    }

    return EGL_TRUE;
}

软件实现大致如下：
1）如果合成区域的脏区域不为空，首先通过andSelf（）函数，算出在buffer中的dirtyRegion的区域，然后调用subtract将oldDirtyRegion中去掉了dirtyRegion区域，然后见这块区域从previousBuffer拷贝到当前的buffer中。这一部分和我门之前讲Android SurfaceFlinger 学习之路(八)—-Surface管理图形缓冲区中Surface申请图形缓冲区过程类似，也是没有变化的区域就用copyBlt拷贝像素。
2）将新的脏区域赋值给oldDirtyRegion，将少之前buffer的对gralloc的引用（这个我们在讲Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现中提到过，这是C语言中的一种继承方式），完成buffer内容的填充，然后将previousBuffer指向buffer。
3）接着调用调用nativeBuffer变量的queueBuffer。这里的nativeWindow是egl_window_surface_v2_t结构体的成员变量，是一个ANativeWindow*类型。在DisplayDevice构造函数里调用eglCreateWindowSurface创建egl_window_surface_v2_t实例时候，new了一个Surface传入的。之前Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface讲过，Surface间接继承与ANativeWindow。
从之前将Surface管理缓冲区得知，这会回调consumer的onFrameAvailable函数，后面会讲到，这会触发FrameBufferSurface的onFrameAvailable函数回调。
调用surface的queueBuffer，agl的实现fencefd输入为-1。硬件平台不为-1，比如抓高通的log，肯定在前面先创建了fence同步对象，经过merge后肯定不再为-1了。
4）Dequeue一块新的buffer，并wait，等待release fence触发。如果等待超时，就将buffer cancel掉。第一次被申请的buffer slot，返回-1。假设不是。有release fence，则会dup该fencefd。
5）按需重新计算buffer。

既然提到交换缓冲区，就是讲生产者的内容post到消费者去，所以我们应该关注nativeWindow的queueBuffer过程。在讲这一部分之前，我们要看看之前讲到的DisplayDevice和FrameBufferSurface关系，还要引入一点OpenGL相关的内容。

OpenGL环境创建

使用OpenGL标准，用GPU把图层画到统一的FrameBuffer上，然后送显。毫无疑问这是离线合成的一种。EGL标准下，OpenGL环境创建的一般流程如下图所示：

这部分工作在SurfaceFlinger::init函数完成，也即服务初起之时。我们在讲Android SurfaceFlinger 学习之路(五)—-VSync 工作原理时候提到过这一部分：

// initialize EGL for the default display
mEGLDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY);
eglInitialize(mEGLDisplay, NULL, NULL);

//初始化硬件合成器（这个和3D合成无关）
mHwc = new HWComposer(this,
        *static_cast<HWComposer::EventHandler *>(this));

//创建渲染引擎，主要是选择EGL配置，选择OpenGL版本，创建OpenGL上下文
mRenderEngine = RenderEngine::create(mEGLDisplay, mHwc->getVisualID());
// retrieve the EGL context that was selected/created
mEGLContext = mRenderEngine->getEGLContext();

LOG_ALWAYS_FATAL_IF(mEGLContext == EGL_NO_CONTEXT,
        "couldn't create EGLContext");

//创建OpenGL的渲染目标Surface
for (size_t i=0 ; i<DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES ; i++) {
    DisplayDevice::DisplayType type((DisplayDevice::DisplayType)i);
    // set-up the displays that are already connected
    if (mHwc->isConnected(i) || type==DisplayDevice::DISPLAY_PRIMARY) {
        // All non-virtual displays are currently considered secure.
        bool isSecure = true;
        createBuiltinDisplayLocked(type);
        wp<IBinder> token = mBuiltinDisplays[i];

        sp<IGraphicBufferProducer> producer;
        sp<IGraphicBufferConsumer> consumer;
        BufferQueue::createBufferQueue(&producer, &consumer,
                new GraphicBufferAlloc());
        /*创建窗口Surface所需要的window句柄，注意这里面window句柄是FramebufferSurface*/
        sp<FramebufferSurface> fbs = new FramebufferSurface(*mHwc, i,
                consumer);
        int32_t hwcId = allocateHwcDisplayId(type);
        /*在构造函数中，调用 eglCreateSurface 创建了OpenGL渲染的目标Surface*/
        sp<DisplayDevice> hw = new DisplayDevice(this,
                type, hwcId, mHwc->getFormat(hwcId), isSecure, token,
                fbs, producer,
                mRenderEngine->getEGLConfig());
        if (i > DisplayDevice::DISPLAY_PRIMARY) {
            // FIXME: currently we don't get blank/unblank requests
            // for displays other than the main display, so we always
            // assume a connected display is unblanked.
            ALOGD("marking display %zu as acquired/unblanked", i);
            hw->setPowerMode(HWC_POWER_MODE_NORMAL);
        }
        mDisplays.add(token, hw);
    }
}

// make the GLContext current so that we can create textures when creating Layers
// (which may happens before we render something)
/*绑定上下文和Surface，以便绘制，这一步在调用OpenGL的drawcall之前就可以，这里调一次貌似是没必要的*/
getDefaultDisplayDevice()->makeCurrent(mEGLDisplay, mEGLContext);

对使用opengl合成的layer将合成结果放置到HWC_FRAMEBUFFER_TARGET layer中，然后再交给HWComposer处理。在surfaceflinger的init函数中，定义了HWC_FRAMEBUFFER_TARGET layer合成时相应的生成者和消费者，每一个display相应有一个DisplayDevice作为生产者(opengl合成数据)，而FramebufferSurface是相应的消费者(注意这个消费者仅仅是处理opengl合成相关的，overlay全然由HAL层的hwcomposer处理)。
注意到，创建的窗口是FramebufferSurface。为了更直观的查看Surface创建流程，我们再把DisplayDevice构造函数贴出来：

DisplayDevice::DisplayDevice(
        const sp<SurfaceFlinger>& flinger,
        DisplayType type,
        int32_t hwcId,
        bool isSecure,
        const wp<IBinder>& displayToken,
        const sp<DisplaySurface>& displaySurface,
        const sp<IGraphicBufferProducer>& producer,
        EGLConfig config)
    : mFlinger(flinger),
      mType(type), mHwcDisplayId(hwcId),
      mDisplayToken(displayToken),
      mDisplaySurface(displaySurface),
      mDisplay(EGL_NO_DISPLAY),
      mSurface(EGL_NO_SURFACE),
      mDisplayWidth(), mDisplayHeight(), mFormat(),
      mFlags(),
      mPageFlipCount(),
      mIsSecure(isSecure),
      mSecureLayerVisible(false),
      mScreenAcquired(false),
      mLayerStack(NO_LAYER_STACK),
      mOrientation()
{
    //利用bq创建surface
    mNativeWindow = new Surface(producer, false);
    ANativeWindow* const window = mNativeWindow.get();

    int format;
    window->query(window, NATIVE_WINDOW_FORMAT, &format);

    // Make sure that composition can never be stalled by a virtual display
    // consumer that isn't processing buffers fast enough. We have to do this
    // in two places:
    // * Here, in case the display is composed entirely by HWC.
    // * In makeCurrent(), using eglSwapInterval. Some EGL drivers set the
    //   window's swap interval in eglMakeCurrent, so they'll override the
    //   interval we set here.
    if (mType >= DisplayDevice::DISPLAY_VIRTUAL)
        window->setSwapInterval(window, 0);

    /*
     * Create our display's surface
     */
    // 利用EGL创建本地opengl环境，要用opengl 合成layer
    EGLSurface surface;
    EGLint w, h;
    EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    //调用eglCreateWindowSurface创建EGLSurface
    surface = eglCreateWindowSurface(display, config, window, NULL);
    eglQuerySurface(display, surface, EGL_WIDTH,  &mDisplayWidth);
    eglQuerySurface(display, surface, EGL_HEIGHT, &mDisplayHeight);

    mDisplay = display;
    mSurface = surface;
    mFormat  = format;
    mPageFlipCount = 0;
    mViewport.makeInvalid();
    mFrame.makeInvalid();

    // virtual displays are always considered enabled
    mScreenAcquired = (mType >= DisplayDevice::DISPLAY_VIRTUAL);

    // Name the display.  The name will be replaced shortly if the display
    // was created with createDisplay().
    switch (mType) {
        case DISPLAY_PRIMARY:
            mDisplayName = "Built-in Screen";
            break;
        case DISPLAY_EXTERNAL:
            mDisplayName = "HDMI Screen";
            break;
        default:
            mDisplayName = "Virtual Screen";    // e.g. Overlay #n
            break;
    }
}

在DisplayDevice构造函数里，利用从SF的init 函数里传入的BufferQueueProducer构造了一个Surface，然后调用eglCreateWindowSurface创建EGLSurface。
我们知道surface继承了RefBase，所以get()实际上RefBase提供的函数。返回了surface的对象引用。而surface继承了ANativeObjectBase模版，通过ANativeObjectBase模版，可以理解成surface类也继承了AnativeWindow和RefBase。那么surface.get()作为AnativeWindow的类型参数传递给CreateWindowSurface也就好理解咯。也就是window本质上就是surface。
为了解决上面留下的迷惑，我们看看eglCreateWindowSurface的实现。依然需要曲线救国，看看软件实现，位于frameworks/native/opengl/libagl/egl.cpp：

EGLSurface eglCreateWindowSurface(  EGLDisplay dpy, EGLConfig config,
                                    NativeWindowType window,
                                    const EGLint *attrib_list)
{
    return createWindowSurface(dpy, config, window, attrib_list);
}

static EGLSurface createWindowSurface(EGLDisplay dpy, EGLConfig config,
        NativeWindowType window, const EGLint* /*attrib_list*/)
{
    /*------前面都是一些错误检查------*/
    if (egl_display_t::is_valid(dpy) == EGL_FALSE)
        return setError(EGL_BAD_DISPLAY, EGL_NO_SURFACE);
    if (window == 0)
        return setError(EGL_BAD_MATCH, EGL_NO_SURFACE);

    EGLint surfaceType;
    if (getConfigAttrib(dpy, config, EGL_SURFACE_TYPE, &surfaceType) == EGL_FALSE)
        return EGL_FALSE;

    if (!(surfaceType & EGL_WINDOW_BIT))
        return setError(EGL_BAD_MATCH, EGL_NO_SURFACE);

    if (static_cast<ANativeWindow*>(window)->common.magic !=
            ANDROID_NATIVE_WINDOW_MAGIC) {
        return setError(EGL_BAD_NATIVE_WINDOW, EGL_NO_SURFACE);
    }
        
    EGLint configID;
    if (getConfigAttrib(dpy, config, EGL_CONFIG_ID, &configID) == EGL_FALSE)
        return EGL_FALSE;

    int32_t depthFormat;
    int32_t pixelFormat;
    if (getConfigFormatInfo(configID, pixelFormat, depthFormat) != NO_ERROR) {
        return setError(EGL_BAD_MATCH, EGL_NO_SURFACE);
    }

    // FIXME: we don't have access to the pixelFormat here just yet.
    // (it's possible that the surface is not fully initialized)
    // maybe this should be done after the page-flip
    //if (EGLint(info.format) != pixelFormat)
    //    return setError(EGL_BAD_MATCH, EGL_NO_SURFACE);

    egl_surface_t* surface;
    //egl_surface_t的详细实现为egl_window_surface_v2_t
    surface = new egl_window_surface_v2_t(dpy, config, depthFormat,
            static_cast<ANativeWindow*>(window));

    if (!surface->initCheck()) {
        // there was a problem in the ctor, the error
        // flag has been set.
        delete surface;
        surface = 0;
    }
    return surface;
}

前面都是一些错误检测，最后面new了一个egl_window_surface_v2_t结构体实现，egl_surface_t的详细实现为egl_window_surface_v2_t。
我们再看看这个结构体部分内容：


struct egl_window_surface_v2_t : public egl_surface_t
{
    egl_window_surface_v2_t(
            EGLDisplay dpy, EGLConfig config,
            int32_t depthFormat,
            ANativeWindow* window);

    ~egl_window_surface_v2_t();
private:
    status_t lock(ANativeWindowBuffer* buf, int usage, void** vaddr);
    status_t unlock(ANativeWindowBuffer* buf);
    ANativeWindow*   nativeWindow;
    ANativeWindowBuffer*   buffer;
    ANativeWindowBuffer*   previousBuffer;
    gralloc_module_t const*    module;
    int width;
    int height;
    void* bits;
    GGLFormat const* pixelFormatTable;

};
egl_window_surface_v2_t::egl_window_surface_v2_t(EGLDisplay dpy,
        EGLConfig config,
        int32_t depthFormat,
        ANativeWindow* window)
    : egl_surface_t(dpy, config, depthFormat), 
    nativeWindow(window), buffer(0), previousBuffer(0), module(0),
    bits(NULL)
{
    hw_module_t const* pModule;
    hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &pModule);
    module = reinterpret_cast<gralloc_module_t const*>(pModule);

    pixelFormatTable = gglGetPixelFormatTable();
    
    // keep a reference on the window
    nativeWindow->common.incRef(&nativeWindow->common);
    nativeWindow->query(nativeWindow, NATIVE_WINDOW_WIDTH, &width);
    nativeWindow->query(nativeWindow, NATIVE_WINDOW_HEIGHT, &height);
}

上面提到了，这里的nativeWindow是egl_window_surface_v2_t结构体的成员变量，是一个ANativeWindow*类型。在DisplayDevice构造函数里调用eglCreateWindowSurface创建egl_window_surface_v2_t实例时候，new了一个Surface传入的。
然后就是上面调用Surface的dequeueBuffer，忘了的话可以往上翻=。=

前面提到过。eglSwapBuffers会触发DisplayDevice这个producer去dequeue buffer和queue buffer。这里的opengl合成和上层的opengl画图相似，在queuebuffer中就会为该buffer设置一个acquire buffer，传递给消费者consumer。从SF的init函数中得知，创建的窗口是FramebufferSurface，这个FrameBufferSurface包了一个BufferQueueConsumer，就像我们在Android SurfaceFlinger 学习之路(八)—-Surface管理图形缓冲区中讲到上层绘制通知SF消费时候的SurfaceFlingerConsumer类的功能一样。所以最后queue buffer会触发FramebufferSurface::onFrameAvailable()。
FrameBufrerSurface的类图如下：

我们再看看FrameBufferSurface的构造函数，位于frameworks/native/services/surfaceflinger/DisplayHardware/FramebufferSurface.cpp：


#ifndef NUM_FRAMEBUFFER_SURFACE_BUFFERS
#define NUM_FRAMEBUFFER_SURFACE_BUFFERS (2)
#endif
FramebufferSurface::FramebufferSurface(HWComposer& hwc, int disp,
        const sp<IGraphicBufferConsumer>& consumer) :
    ConsumerBase(consumer),
    mDisplayType(disp),
    mCurrentBufferSlot(-1),
    mCurrentBuffer(0),
    mHwc(hwc)
{
    mName = "FramebufferSurface";
    mConsumer->setConsumerName(mName);
    mConsumer->setConsumerUsageBits(GRALLOC_USAGE_HW_FB |
                                       GRALLOC_USAGE_HW_RENDER |
                                       GRALLOC_USAGE_HW_COMPOSER);
    mConsumer->setDefaultBufferFormat(mHwc.getFormat(disp));
    mConsumer->setDefaultBufferSize(mHwc.getWidth(disp),  mHwc.getHeight(disp));
    mConsumer->setDefaultMaxBufferCount(NUM_FRAMEBUFFER_SURFACE_BUFFERS);
}

我们注意到mConsumer的setConsumerUsageBits函数中设置的标志位：GRALLOC_USAGE_HW_FB | GRALLOC_USAGE_HW_RENDER | GRALLOC_USAGE_HW_COMPOSER。从之前的Android SurfaceFlinger 学习之路(八)—-Surface管理图形缓冲区讲过，如果是上层应用程序申请图形缓冲区，应用程序进程使用的图形缓冲区一般都是在匿名共享内存里面分配的，这个图形缓冲区填好数据之后，就会再交给SurfaceFlinger服务来合成到硬件帧缓冲区上去渲染。因此，从前面传过来给函数gralloc_alloc的参数usage的GRALLOC_USAGE_HW_FB位会被设置为0，以便可以在匿名共享内存中分配一个图形缓冲区。
而这里使用的标志位不同，GRALLOC_USAGE_HW_FB | GRALLOC_USAGE_HW_RENDER | GRALLOC_USAGE_HW_COMPOSER，从之前Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现可以得知，FrameBufferSurface类使用的图形缓冲区是直接在硬件帧缓冲区分配的，并且它可以直接将这些图形缓冲区渲染到硬件帧缓冲区中去。要从硬件帧缓冲区中分配和渲染图形缓冲区，就必须要将HAL层中的Gralloc模块加载到当前的进程空间来，并且打开里面的gralloc设备和fb设备，其中，gralloc设备用来分配图形缓冲区，而fb设备用来渲染图形缓冲区。

还有一个注意点就是consumer的setDefaultMaxBufferCount函数，设置大小为NUM_FRAMEBUFFER_SURFACE_BUFFERS，为2。硬件帧缓冲区能够提供的图形缓冲区的个数等于2，这意味着Android系统可以使用双缓冲区技术来渲染系统的UI。
这里有个误区，上面说的双缓冲并不是指4.1之后的Triple Buffer。三缓冲是对于Producer这一侧的生产者来说，我们在Layer的onFirstRef函数中有设置过，在Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface中也分析过，回顾一下：

void Layer::onFirstRef() {
    // Creates a custom BufferQueue for SurfaceFlingerConsumer to use
    sp<IGraphicBufferProducer> producer;
    sp<IGraphicBufferConsumer> consumer;
    //BufferQueue创建图形缓冲区管理成员，我们以后分析图形缓冲区管理会讲到
    BufferQueue::createBufferQueue(&producer, &consumer);
    //mProducer 不为空了，赋值
    mProducer = new MonitoredProducer(producer, mFlinger);
    //mSurfaceFlingerConsumer 不为空了，赋值
    mSurfaceFlingerConsumer = new SurfaceFlingerConsumer(consumer, mTextureName);
    //设置消费者相关设置
    mSurfaceFlingerConsumer->setConsumerUsageBits(getEffectiveUsage(0));
    mSurfaceFlingerConsumer->setContentsChangedListener(this);
    mSurfaceFlingerConsumer->setName(mName);
    
// TARGET_DISABLE_TRIPLE_BUFFERING为false，所以使用了三缓冲，project butter计划嘛
#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);
}

根据“黄油计划”定义了三缓冲。因为Producer定义了三缓冲，为了避免junk现象，让屏幕始终有一块buffer拉去离屏渲染。所以在producer这一侧，一块给cpu调度，一块给gpu绘制，看看谁有空闲的送给显示屏。如果默认的cpu调度和gpu性能都没有问题，在一个vsync周期内都能完成各自工作，那么以前仅有两块buffer情况下都不会出问题，因为，等他们用完后，总会空出一块buffer送给显示屏。但是如果其中任何一个出了问题，占用时间周期超过了一个vsync，或者更严重，两个都拖堂了，那么显示屏就没有空闲buffer拉取了，就会有很严重的掉帧。所以从4.1之后又加了一块buffer在producer这一侧，保证出问题时候还有一块buffer送显屏幕，即使从时间周期的pipeline来看，就这一个出问题的帧多显示了一下，但是后续的都显示正常，虽然仅仅延时了一帧，但是整体不会像以前那样严重的连续掉下帧。
这就是triple buffer的简单概述，如果有机会，后面专门讲讲。如果我理解有问题，也欢迎大家指正。

因为对于屏幕显示器来说，上层app和SF都是属于producer生产者，而自己display才是消费者。屏幕是双缓冲显示，一块back buffer作为离屏渲染，一块front buffer作为在线显示，然后用完了又回到后台拉去producer送显的内容作为离屏渲染，同时之前的back buffer交换到前台作为front buffer在线显示，这样周而复始不挺循环。

这里扯的有点多，如果有误请轻喷，欢迎指出，我会在第一时间修改。

触发渲染

继续回到上面内容，由eglSwapBuffers触发queueBuffer，进而触发FramebufferSurface中的onFrameAvailable方法：

void FramebufferSurface::onFrameAvailable() {
    sp<GraphicBuffer> buf;
    sp<Fence> acquireFence;
    /*acquireBuffer，取得一块生产完成（OpenGL合成好）的Buffer*/
    status_t err = nextBuffer(buf, acquireFence);
    if (err != NO_ERROR) {
        ALOGE("error latching nnext FramebufferSurface buffer: %s (%d)",
                strerror(-err), err);
        return;
    }
    /*最终调用 gralloc 模块中的 post方法，该此Buffer送显*/
    err = mHwc.fbPost(mDisplayType, acquireFence, buf);
    if (err != NO_ERROR) {
        ALOGE("error posting framebuffer: %d", err);
    }
}

我们先看看nextBuffer函数，取得一块生产完成（OpenGL合成好）的Buffer。（由于surfaceflinger是用opengl合成HWC_FRAMEBUFFER_TARGET layer的，所以有可能“合成”这个生产还未完毕）：


status_t FramebufferSurface::nextBuffer(sp<GraphicBuffer>& outBuffer, sp<Fence>& outFence) {
    Mutex::Autolock lock(mMutex);

    BufferQueue::BufferItem item;
    //通过acquireBufferLocked获取BufferItem，其中的mBuf就是buffer了
    //acquireBufferLocked由之前父类传入的BufferQueueConsumer调用
    status_t err = acquireBufferLocked(&item, 0);
    if (err == BufferQueue::NO_BUFFER_AVAILABLE) {
        outBuffer = mCurrentBuffer;
        return NO_ERROR;
    } else if (err != NO_ERROR) {
        ALOGE("error acquiring buffer: %s (%d)", strerror(-err), err);
        return err;
    }

    // If the BufferQueue has freed and reallocated a buffer in mCurrentSlot
    // then we may have acquired the slot we already own.  If we had released
    // our current buffer before we call acquireBuffer then that release call
    // would have returned STALE_BUFFER_SLOT, and we would have called
    // freeBufferLocked on that slot.  Because the buffer slot has already
    // been overwritten with the new buffer all we have to do is skip the
    // releaseBuffer call and we should be in the same state we'd be in if we
    // had released the old buffer first.
    //把老的buffer先release掉，还给BufferQueue，release时肯定得加入个release fence
    //如果在acquireBuffer之前调用releaseBuffer，就会返回一个STALE_BUFFER_SLOT状态，就不得不调用freeBufferLocked释放掉那个过时的buffer回到slot中。
    //为了避免获老的buffer被新的buffer内容覆盖，就要先acquire新的buffer然后release旧的buffer
    if (mCurrentBufferSlot != BufferQueue::INVALID_BUFFER_SLOT &&
        item.mBuf != mCurrentBufferSlot) {
        // Release the previous buffer.
        err = releaseBufferLocked(mCurrentBufferSlot, mCurrentBuffer,
                EGL_NO_DISPLAY, EGL_NO_SYNC_KHR);
        if (err < NO_ERROR) {
            ALOGE("error releasing buffer: %s (%d)", strerror(-err), err);
            return err;
        }
    }
    mCurrentBufferSlot = item.mBuf;
    mCurrentBuffer = mSlots[mCurrentBufferSlot].mGraphicBuffer;
    outFence = item.mFence;
    outBuffer = mCurrentBuffer;
    return NO_ERROR;
}

获取一块合成好的buffer，就是之前HWC_FRAMEBUFFER标志的所有layer合成到HWC_FRAMEBUFFER_TARGET这个图层（有可能还没有合成好）。通过acquireBufferLocked获取BufferItem，其中的mBuf就是buffer了，acquireBufferLocked由之前父类传入的BufferQueueConsumer调用。
然后把老的buffer先release掉，还给BufferQueue，release时肯定得加入个release fence。如果在acquireBuffer之前调用releaseBuffer，就会返回一个STALE_BUFFER_SLOT状态，就不得不调用freeBufferLocked释放掉那个过时的buffer回到slot中。为了避免获老的buffer被新的buffer内容覆盖，就要先acquire新的buffer然后release旧的buffer。这个我们在Android SurfaceFlinger 学习之路(十)—-SurfaceFlinger处理Layer更新讲过。

继续回到剩下的内容，最终调用 gralloc 模块中的 post方法，该此Buffer送显。这一部分可以参考Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现，其中的图形缓冲区的渲染过程模块。

到这里万里长征终于快到尽头了，doDisplayComposition函数流程分析完了。合成和送显示差不多完成了，还剩下最后一点杂物。

硬件模块渲染过程

我们回到SF的doComposition函数，查看剩下内容：

            //清除屏幕脏区域
            hw->dirtyRegion.clear();
            //判断系统是否支持软件部分更新
            hw->flip(hw->swapRegion);
            //清除交换区域
            hw->swapRegion.clear();
        }
        // inform the h/w that we're done compositing
        //通知hwc硬件合成结束
        hw->compositionComplete();
    }
    //主要是调用hwc硬件的set函数
    //此方法将完成各个图层的合成与显示，等效于EGL标准里面的eglSwapBuffers，
    //不过eglSwapBuffers是对OpenGL标准/GPU有效，此方法是对硬件合成器有效
    postFramebuffer();
}

主要就三个功能：
1）判断系统是否支持软件部分更新；
2）通知hwc硬件合成结束；
3）调用hwc硬件的set函数，各个overlay图层的合成与显示。

老规矩，分步骤分析：
1）判断系统是否支持软件部分更新。调用了DisplayDevice的flip函数，参数时要交换的合成区域：

void DisplayDevice::flip(const Region& dirty) const
{
    mFlinger->getRenderEngine().checkErrors();

    EGLDisplay dpy = mDisplay;
    EGLSurface surface = mSurface;

#ifdef EGL_ANDROID_swap_rectangle
    if (mFlags & SWAP_RECTANGLE) {
        const Region newDirty(dirty.intersect(bounds()));
        const Rect b(newDirty.getBounds());
        eglSetSwapRectangleANDROID(dpy, surface,
                b.left, b.top, b.width(), b.height());
    }
#else
    (void) dirty; // Eliminate unused parameter warning
#endif

    mPageFlipCount++;
}

这段代码主要用来检查系统的主绘图表面是否支持EGL_ANDROID_swap_rectangle扩展属性。如果支持的话，那么每次在调用函数eglSwapBuffers来渲染UI时，都会使用软件的方式来支持部分更新区域功能，即：先得到不在新脏区域里面的那部分旧脏区域的内容，然后再将得到的这部分旧脏区域的内容拷贝回到要渲染的新图形缓冲区中去，这要求每次在渲染UI时，都要将被渲染的图形缓冲区以及对应的脏区域保存下来。
函数会首先判断系统的主绘图表面是否支持EGL_ANDROID_swap_rectangle扩展属性。如果支持EGL_ANDROID_swap_rectangle扩展属性，即DisplayDevice类的成员变量mFlags的SWAP_RECTANGLE位等于1，那么就需要调用函数eglSetSwapRectangleANDROID来设置要渲染的区域，以便在渲染UI时，可以通过软件的方式来支持部分更新。
不过从上一段选择部分更新的内容来看，是直接在硬件上支持部分更新，因而性能会更好。这一段软件的eglSetSwapRectangleANDROID就不看了曲线救国了，大清亡就亡了=。=

2）通知hwc硬件合成结束。go on：

1
2
3

status_t DisplayDevice::compositionComplete() const {
    return mDisplaySurface->compositionComplete();
}

之前从SF的init函数和DisplayDevice的构造函数得知，mDisplaySurface是一个FrameBufferSurface对象，所以我们继续看看它的compositionComplete函数：

status_t FramebufferSurface::compositionComplete()
{
    return mHwc.fbCompositionComplete();
}

它又调用了HWComposer的fbCompositionComplete函数：

int HWComposer::fbCompositionComplete() {
    //如果支持HWC硬件1.1版本，就不用通知任何消息
    if (mHwc && hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1))
        return NO_ERROR;
    //否则通知FrameBuffer驱动FrameBufferTarget合成结束
    if (mFbDev->compositionComplete) {
        return mFbDev->compositionComplete(mFbDev);
    } else {
        return INVALID_OPERATION;
    }
}

如果支持HWC硬件1.1版本，就不用通知任何消息，否则通知FrameBuffer驱动FrameBufferTarget合成结束。

3）调用hwc硬件的set函数，各个overlay图层的合成与显示。这一步是postFramebuffer函数内完成的，我们看看实现：

void SurfaceFlinger::postFramebuffer()
{
    ATRACE_CALL();

    const nsecs_t now = systemTime();
    mDebugInSwapBuffers = now;

    HWComposer& hwc(getHwComposer());
    if (hwc.initCheck() == NO_ERROR) {
        if (!hwc.supportsFramebufferTarget()) {
            // EGL spec says:
            //   "surface must be bound to the calling thread's current context,
            //    for the current rendering API."
            getDefaultDisplayDevice()->makeCurrent(mEGLDisplay, mEGLContext);
        }
        //调用HWComposer的commit函数
        hwc.commit();
    }

    // make the default display current because the VirtualDisplayDevice code cannot
    // deal with dequeueBuffer() being called outside of the composition loop; however
    // the code below can call glFlush() which is allowed (and does in some case) call
    // dequeueBuffer().
    //为了虚拟显示屏做的规避
    getDefaultDisplayDevice()->makeCurrent(mEGLDisplay, mEGLContext);

    for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {
        sp<const DisplayDevice> hw(mDisplays[dpy]);
        const Vector< sp<Layer> >& currentLayers(hw->getVisibleLayersSortedByZ());
        //完毕了framebuffertarget layer的swapbuffers。
        hw->onSwapBuffersCompleted(hwc);
        const size_t count = currentLayers.size();
        int32_t id = hw->getHwcDisplayId();
        if (id >=0 && hwc.initCheck() == NO_ERROR) {
            HWComposer::LayerListIterator cur = hwc.begin(id);
            const HWComposer::LayerListIterator end = hwc.end(id);
            for (size_t i = 0; cur != end && i < count; ++i, ++cur) {
                //最后回调每个Layer的onLayerDisplayed函数
                currentLayers[i]->onLayerDisplayed(hw, &*cur);
            }
        } else {
            for (size_t i = 0; i < count; i++) {
                currentLayers[i]->onLayerDisplayed(hw, NULL);
            }
        }
    }

    mLastSwapBufferTime = systemTime() - now;
    mDebugInSwapBuffers = 0;

    uint32_t flipCount = getDefaultDisplayDevice()->getPageFlipCount();
    if (flipCount % LOG_FRAME_STATS_PERIOD == 0) {
        logFrameStats();
    }
}

也是三部操作：1）调用调用HWComposer的commit函数完成OverLay合成；2）完毕了framebuffertarget layer的swapbuffers；3）最后回调每个Layer的onLayerDisplayed函数。
我们先看第一步：

status_t HWComposer::commit() {
    int err = NO_ERROR;
    if (mHwc) {
        if (!hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1)) {
            // On version 1.0, the OpenGL ES target surface is communicated
            // by the (dpy, sur) fields and we are guaranteed to have only
            // a single display.
            mLists[0]->dpy = eglGetCurrentDisplay();
            mLists[0]->sur = eglGetCurrentSurface(EGL_DRAW);
        }

        for (size_t i=VIRTUAL_DISPLAY_ID_BASE; i<mNumDisplays; i++) {
            DisplayData& disp(mDisplayData[i]);
            if (disp.outbufHandle) {
                mLists[i]->outbuf = disp.outbufHandle;
                mLists[i]->outbufAcquireFenceFd =
                        disp.outbufAcquireFence->dup();
            }
        }
        //主要是调用hwc硬件的set函数
        //此方法将完成各个图层的合成与显示，等效于EGL标准里面的eglSwapBuffers，
        //不过eglSwapBuffers是对OpenGL标准/GPU有效，此方法是对硬件合成器有效
        err = mHwc->set(mHwc, mNumDisplays, mLists);

        for (size_t i=0 ; i<mNumDisplays ; i++) {
            DisplayData& disp(mDisplayData[i]);
            disp.lastDisplayFence = disp.lastRetireFence;
            disp.lastRetireFence = Fence::NO_FENCE;
            if (disp.list) {
                if (disp.list->retireFenceFd != -1) {
                    disp.lastRetireFence = new Fence(disp.list->retireFenceFd);
                    disp.list->retireFenceFd = -1;
                }
                disp.list->flags &= ~HWC_GEOMETRY_CHANGED;
            }
        }
    }
    return (status_t)err;
}

主要是调用hwc硬件的set函数，此方法将完成各个图层的合成与显示，等效于EGL标准里面的eglSwapBuffers，不过eglSwapBuffers是对OpenGL标准/GPU有效，此方法是对硬件合成器有效。
不过这是hwc硬件的实现，我们也看不到代码。感兴趣的同学可以搜一搜AOSP里qcom、boardcom、ti、intel、samsung等公司开源出来的实现。

后两部都是和Fence相关，这里不是重点：
第二步是完毕了framebuffertarget layer的swapbuffers，调用DisplayDevice的onSwapBuffersCompleted函数：

void DisplayDevice::onSwapBuffersCompleted(HWComposer& hwc) const {
    if (hwc.initCheck() == NO_ERROR) {
        mDisplaySurface->onFrameCommitted();
    }
}

依然调用FrameBufferSurface的onFrameCommitted函数：

void FramebufferSurface::onFrameCommitted() {
    sp<Fence> fence = mHwc.getAndResetReleaseFence(mDisplayType);
    if (fence->isValid() &&
            mCurrentBufferSlot != BufferQueue::INVALID_BUFFER_SLOT) {
        status_t err = addReleaseFence(mCurrentBufferSlot,
                mCurrentBuffer, fence);
        ALOGE_IF(err, "setReleaseFenceFd: failed to add the fence: %s (%d)",
                strerror(-err), err);
    }
}
sp<Fence> HWComposer::getAndResetReleaseFence(int32_t id) {
    if (uint32_t(id)>31 || !mAllocatedDisplayIDs.hasBit(id))
        return Fence::NO_FENCE;

    int fd = INVALID_OPERATION;
    if (mHwc && hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1)) {
        const DisplayData& disp(mDisplayData[id]);
        // 这里的disp.framebufferTarget->releaseFenceFd应该就是底层hwcomposer设置的 
        if (disp.framebufferTarget) {
            fd = disp.framebufferTarget->releaseFenceFd;
            disp.framebufferTarget->acquireFenceFd = -1;
            disp.framebufferTarget->releaseFenceFd = -1;
        }
    }
    return fd >= 0 ? new Fence(fd) : Fence::NO_FENCE;
}

onFrameCommitted主要就是获取hwcomposer设置的release fence，然后设置到slot中。

第三部回调Layer的onLayerDisplayed函数：

void Layer::onLayerDisplayed(const sp<const DisplayDevice>& hw,
        HWComposer::HWCLayerInterface* layer) {
    if (layer) {
        //HWCLayerVersion1的onDisplayed函数，位于HWComposer.cpp中
        layer->onDisplayed();
        //将fence设置到slot中
        mSurfaceFlingerConsumer->setReleaseFence(layer->getAndResetReleaseFence());
    }
}
/*----------- HWCLayerVersion1 ----------*/
virtual sp<Fence> getAndResetReleaseFence() {
        //获取layer的releaseFenceFd
        int fd = getLayer()->releaseFenceFd;
        getLayer()->releaseFenceFd = -1;
        //new 一个Fence
        return fd >= 0 ? new Fence(fd) : Fence::NO_FENCE;
}
virtual void onDisplayed() {
        hwc_region_t& visibleRegion = getLayer()->visibleRegionScreen;
        SharedBuffer const* sb = SharedBuffer::bufferFromData(visibleRegion.rects);
        if (sb) {
            sb->release();
            // not technically needed but safer
            visibleRegion.numRects = 0;
            visibleRegion.rects = NULL;
        }

        getLayer()->acquireFenceFd = -1;
}

而对overlay相应的layer而言，前面仅仅设置了acquire fence，在hwcomposer HAL处理后肯定会给加入一个release fence，而这一部分代码我们看不到实现。

到此硬件模块渲染过程就分析完了。SF的doComposition函数的流程就结束了。

更新SW Vsync误差

最后一部分就是SF中handleMessageRefresh最后一部，postComposition。主要用于调试，调Layer的onPostComposition方法。我们看看实现：

void SurfaceFlinger::postComposition()
{
    const LayerVector& layers(mDrawingState.layersSortedByZ);
    const size_t count = layers.size();
    for (size_t i=0 ; i<count ; i++) {
        //调Layer的onPostComposition方法
        layers[i]->onPostComposition();
    }
    // 通过 HWComposer 获得 Fence
    const HWComposer& hwc = getHwComposer();
    sp<Fence> presentFence = hwc.getDisplayFence(HWC_DISPLAY_PRIMARY);
    //注意，如果硬件vsync已经被打开了，那么fence是无效了，只有它在关闭的情况下，它才有效
    //矫正更新Vsync，是否打开或关闭vsync信号
    if (presentFence->isValid()) {
        if (mPrimaryDispSync.addPresentFence(presentFence)) {
            enableHardwareVsync();
        } else {
            disableHardwareVsync(false);
        }
    }

    if (kIgnorePresentFences) {
        const sp<const DisplayDevice> hw(getDefaultDisplayDevice());
        if (hw->isDisplayOn()) {
            enableHardwareVsync();
        }
    }
    //动画相关
    if (mAnimCompositionPending) {
        mAnimCompositionPending = false;

        if (presentFence->isValid()) {
            mAnimFrameTracker.setActualPresentFence(presentFence);
        } else {
            // The HWC doesn't support present fences, so use the refresh
            // timestamp instead.
            nsecs_t presentTime = hwc.getRefreshTimestamp(HWC_DISPLAY_PRIMARY);
            mAnimFrameTracker.setActualPresentTime(presentTime);
        }
        mAnimFrameTracker.advanceFrame();
    }
}
/*--------Layer.cpp--------*/
void Layer::onPostComposition() {
    if (mFrameLatencyNeeded) {
        nsecs_t desiredPresentTime = mSurfaceFlingerConsumer->getTimestamp();
        mFrameTracker.setDesiredPresentTime(desiredPresentTime);

        sp<Fence> frameReadyFence = mSurfaceFlingerConsumer->getCurrentFence();
        if (frameReadyFence->isValid()) {
            mFrameTracker.setFrameReadyFence(frameReadyFence);
        } else {
            // There was no fence for this frame, so assume that it was ready
            // to be presented at the desired present time.
            mFrameTracker.setFrameReadyTime(desiredPresentTime);
        }

        const HWComposer& hwc = mFlinger->getHwComposer();
        sp<Fence> presentFence = hwc.getDisplayFence(HWC_DISPLAY_PRIMARY);
        if (presentFence->isValid()) {
            mFrameTracker.setActualPresentFence(presentFence);
        } else {
            // The HWC doesn't support present fences, so use the refresh
            // timestamp instead.
            nsecs_t presentTime = hwc.getRefreshTimestamp(HWC_DISPLAY_PRIMARY);
            mFrameTracker.setActualPresentTime(presentTime);
        }

        mFrameTracker.advanceFrame();
        mFrameLatencyNeeded = false;
    }
}

postComposition函数中比较重要的是更新SW Vsync的误差值。注意，如果硬件vsync已经被打开了，那么fence是无效了，只有它在关闭的情况下，它才有效。当更新SW Vsync模型后，就会关闭硬件Vsync信号，这时候Fence就有效了。所以我们进入第一个if条件内部，查看DispSync的addPresentFence函数：

bool DispSync::addPresentFence(const sp<Fence>& fence) {
    Mutex::Autolock lock(mMutex);

   // 将当前硬件vsync的fence保存在 mPresentFences里, 目的是为了计算偏移
  // mPresentFences 最多保存8个硬件 偏移
    mPresentFences[mPresentSampleOffset] = fence;
    mPresentTimes[mPresentSampleOffset] = 0; 
    mPresentSampleOffset = (mPresentSampleOffset + 1) % NUM_PRESENT_SAMPLES;
    mNumResyncSamplesSincePresent = 0; // 将 mNumResyncSamplesSincePresent 置为0，

    for (size_t i = 0; i < NUM_PRESENT_SAMPLES; i++) {
        const sp<Fence>& f(mPresentFences[i]);
        if (f != NULL) {  //这里 f 是有可能为NULL, 即只有一个 硬件 vsync 偏移时
            nsecs_t t = f->getSignalTime();  //猜测这个就是硬件 vsync的时间
            if (t < INT64_MAX) {
                mPresentFences[i].clear();
              //将每个vsync时间戳记录在 mPresentTimes 里，这里 kPresentTimeOffset是可以配置的，即可调的
                mPresentTimes[i] = t + kPresentTimeOffset;
            }
        }
    }
   //更新错误信息
    updateErrorLocked();

    // 这里，一般的情况是 mModelUpdated 已经被更新了，然后硬件vsync被disable了，
    // 所以这里只需要看SW vsync的真实的硬件vsync的误差是否在可
    // 允许的范围内即可
    return !mModelUpdated || mError > kErrorThreshold;
}

ddPresentFence最后的返回, mError是方差，见下面分析，当方差大于 kErrorThreshold后就返回true：

void DispSync::updateErrorLocked() {
    if (!mModelUpdated) {
        return;
    }

    // Need to compare present fences against the un-adjusted refresh period,
    // since they might arrive between two events.
    
    //得到真实的 period, 具体见 5.2.4 updateModelLocked 里的分析
    nsecs_t period = mPeriod / (1 + mRefreshSkipCount);

    int numErrSamples = 0;
    nsecs_t sqErrSum = 0;

   //这里的 mReferenceTime 是第一个硬件vsync的时间戳 见 addResyncSample里的 mReferenceTime
    for (size_t i = 0; i < NUM_PRESENT_SAMPLES; i++) {
        nsecs_t sample = mPresentTimes[i] - mReferenceTime;
       // 这里 sample 一般来说是大于偏移的
        if (sample > mPhase) {
            nsecs_t sampleErr = (sample - mPhase) % period;
            if (sampleErr > period / 2) {
                sampleErr -= period;
            }
            //记录 偏移差的平方和
            sqErrSum += sampleErr * sampleErr;
            numErrSamples++;
        }
    }

     // 说到底mError就是方差
    if (numErrSamples > 0) {
        mError = sqErrSum / numErrSamples;
    } else {
        mError = 0;
    }

    if (kTraceDetailedInfo) {
        ATRACE_INT64("DispSync:Error", mError);
    }
}

如果 addPresentFence返回true, 那么就说明SW vsync和硬件Vsync的误差已经无法接受了，那么这时就得重新打开硬件Vsync，来重新调节SW vsync模型了。

合成全部流程到此结束，打完收工~~

小结

合成流程中比较重要的就是Layer与纹理，我们贴两幅图，一张是GraphicBuffer上传为纹理，一张为更新纹理：

GraphicBuffer上传为纹理

更新纹理

合成流程是整个SurfaceFlinger中最重要的环节，这个大山我们推到之后，对于Android显示系统的理解豁然开朗。后面我们有机会继续研究研究其他内容，比如Fence相关的东西（可能没有时间=。=）
细数2017年每一件事，真是事事不如意。这一年，也是我整个人生中最动荡的一年，尝遍酸甜苦辣，受尽世态炎凉ToT~
希望2018年能对我好一点。。。。。。

Android SurfaceFlinger 学习之路(十一)(PostView)--附：硬件HWC选取合成类型（Intel）

2017-12-19T10:31:11.000Z

这里说点题外话，高通最近势头正猛啊，回拒了博通的恶意收购，又出了骁龙835进军PC市场，拉着AMD一起干英特尔。英特尔在移动设备市场上面还是没有ARM老谋深算，人家简单指令集一路走到底，授权卖指令集或者自己出公版，得到了苹果、三星、高通、MTK等许多大厂的青睐（苹果、高通、三星等厂商都是向ARM买指令集，再自己设计电路，大概是嫌ARM自己的芯片效能不够；然而联发科和其他几家厂商买的是IP（公版）来兜自己的芯片，不自己从头设计电路），细水长流，进过多年顺风打野，最后打出一身神装出来carry。
反观intel，执着于自己x86架构，也用复杂指令集芯片打入过移动市场，奈何功耗扛不住啊，（充电两小时，装逼5分钟，只是个夸张比喻，勿当真）虽然后来又出了Atom的低功耗处理器，奈何市场已被ARM吞食大半，自己名气也没有打出，最后只能默默凉凉了。
intel在PC市场上霸主这么多年，实力肯定不是盖的，所以我们这次选个intel在hwc模块的实现来看看（其实是因为TI、高通的实现有些复杂，比较晦涩，三星也倒是比较容易看懂，但是也没有intel代码这么人性化=。=）

HWC选取合成类型

上面讲到mHwc->prepare(mHwc, mNumDisplays, mLists);对所有显示屏中所有Layer作合成准备（此时也可以开始发送合成的命令码下去，启动硬件合成，但不需要等待完成），hwcomposer需要正确汇报每个Layer的composetype，以告知SurfaceFlinger是否需要额外处理。

实现位于/hardware/intel/img/hwcomposer/common/base/Hwcomposer.cpp，我们找一个公共模块：

bool Hwcomposer::prepare(size_t numDisplays,
                          hwc_display_contents_1_t** displays)
{
    bool ret = true;

    RETURN_FALSE_IF_NOT_INIT();
    ALOGTRACE("display count = %d", numDisplays);

    if (!numDisplays || !displays) {
        ELOGTRACE("invalid parameters");
        return false;
    }
    //检查显示屏相关信息，处理热插拔消息
    mDisplayAnalyzer->analyzeContents(numDisplays, displays);

    // disable reclaimed planes
    //disable掉所有回收的显示平面
    mPlaneManager->disableReclaimedPlanes();

    // reclaim all allocated planes if possible
    //如果可能，回首所有已经申请过的显示平面
    for (size_t i = 0; i < numDisplays; i++) {
        if (i >= mDisplayDevices.size()) {
            continue;
        }
        IDisplayDevice *device = mDisplayDevices.itemAt(i);
        if (!device) {
            VLOGTRACE("device %d doesn't exist", i);
            continue;
        }
        //检查显示屏几何区域是否有变化
        device->prePrepare(displays[i]);
    }

    for (size_t i = 0; i < numDisplays; i++) {
        if (i >= mDisplayDevices.size()) {
            continue;
        }
        IDisplayDevice *device = mDisplayDevices.itemAt(i);
        if (!device) {
            VLOGTRACE("device %d doesn't exist", i);
            continue;
        }
        //最重要的一行：更新HwcLayer，选择合成类型
        ret = device->prepare(displays[i]);
        if (ret == false) {
            ELOGTRACE("failed to do prepare for device %d", i);
            continue;
        }
    }

    return ret;
}

上述就是选取合成类型的步骤：
1）检查显示屏相关信息，处理热插拔消息；
2）disable掉所有回收的显示平面；
3）检查显示屏几何区域是否有变化；
4）最重要的一行：更新HwcLayer，选择合成类型。

流程细节

我们分步查看：
1）检查显示屏相关信息，处理热插拔消息。位于hardware/intel/img/hwcomposer/common/base/DisplayAnalyzer.cpp：

void DisplayAnalyzer::analyzeContents(
        size_t numDisplays, hwc_display_contents_1_t** displays)
{
    // cache and use them only in this context during analysis
    mCachedNumDisplays = numDisplays;
    mCachedDisplays = displays;
    //处理pending的事件
    handlePendingEvents();
}
void DisplayAnalyzer::handlePendingEvents()
{
    // handle one event per analysis to avoid blocking surface flinger
    // some event may take lengthy time to process
    Event e;
    if (!getEvent(e)) {
        return;
    }

    switch (e.type) {
    case HOTPLUG_EVENT:
        //处理热插拔
        handleHotplugEvent(e.bValue);
        break;
    }
}
void DisplayAnalyzer::handleHotplugEvent(bool connected)
{
    if (connected) {
        for (int i = 0; i < mCachedNumDisplays; i++) {
            //将合成类型设置成HWC_FRAMEBUFFER
            setCompositionType(i, HWC_FRAMEBUFFER, true);
        }
    }
}

这就是处理热插拔消息，然后将cache的显示屏合成类型设置成HWC_FRAMEBUFFER，表示用Open GL合成。

2）disable掉所有回收的显示平面。位于hardware/intel/img/hwcomposer/common/planes/DisplayPlaneManager.cpp：

void DisplayPlaneManager::disableReclaimedPlanes()
{
    int i, j;
    bool ret;

    RETURN_VOID_IF_NOT_INIT();

    for (i = 0; i < DisplayPlane::PLANE_MAX; i++) {
        // disable reclaimed planes
        if (mReclaimedPlanes[i]) {
            for (j = 0; j < mPlaneCount[i]; j++) {
                int bit = (1 << j);
                if (mReclaimedPlanes[i] & bit) {
                    DisplayPlane* plane = mPlanes[i].itemAt(j);
                    // check plane state first
                    ret = plane->isDisabled();
                    // reset plane
                    if (ret)
                        ret = plane->reset();
                    if (ret) {
                        // only merge into free bitmap if it is successfully disabled and reset
                        // otherwise, plane will be disabled and reset again.
                        mFreePlanes[i] |=bit;
                        mReclaimedPlanes[i] &= ~bit;
                    }
                }
            }
        }
    }
}

disable所有已经回收planes，检查plane是否已经disable，然后将其reset，如果成功了，就合并进入空闲的bitmap，如果没有就要重新disabled and reset。

3）检查显示屏几何区域是否有变化，遍历每一个显示屏，调用device->prePrepare(displays[i]);我们看一下物理屏幕，位于hardware/intel/img/hwcomposer/common/devices/PhysicalDevice.cpp：

bool PhysicalDevice::prePrepare(hwc_display_contents_1_t *display)
{
    RETURN_FALSE_IF_NOT_INIT();

    // for a null list, delete hwc list
    if (!mConnected || !display || mBlank) {
        if (mLayerList) {
            DEINIT_AND_DELETE_OBJ(mLayerList);
        }
        return true;
    }

    // check if geometry is changed, if changed delete list
    if ((display->flags & HWC_GEOMETRY_CHANGED) && mLayerList) {
        DEINIT_AND_DELETE_OBJ(mLayerList);
    }
    return true;
}

如果是一个空的hwc list，就将其删除；然后检查几何区域是否变化，如果变了，也要删除hwc list。

4）最重要的一行：更新HwcLayer，选择合成类型。依然是遍历每一个显示屏，然后调用prepare函数，依然位于hardware/intel/img/hwcomposer/common/devices/PhysicalDevice.cpp：

bool PhysicalDevice::prepare(hwc_display_contents_1_t *display)
{
    RETURN_FALSE_IF_NOT_INIT();

    if (!mConnected || !display || mBlank)
        return true;

    // check if geometry is changed
    if (display->flags & HWC_GEOMETRY_CHANGED) {
        //上一步处理了几何区域变化，上出了hwc list，这一步重新创建
        onGeometryChanged(display);
    }
    if (!mLayerList) {
        WLOGTRACE("null HWC layer list");
        return true;
    }

    // update list with new list
    //更新hwc list使用重新new的，选取合成类型
    return mLayerList->update(display);
}

void PhysicalDevice::onGeometryChanged(hwc_display_contents_1_t *list)
{
    if (!list) {
        ELOGTRACE("list is NULL");
        return;
    }

    ALOGTRACE("disp = %d, layer number = %d", mType, list->numHwLayers);

    // NOTE: should NOT be here
    if (mLayerList) {
        WLOGTRACE("mLayerList exists");
        DEINIT_AND_DELETE_OBJ(mLayerList);
    }

    // create a new layer list
    //上一步处理了几何区域变化，上出了hwc list，这一步重新创建
    mLayerList = new HwcLayerList(list, mType);
    if (!mLayerList) {
        WLOGTRACE("failed to create layer list");
    }
}

上一步处理了几何区域变化，上出了hwc list，这一步重新创建，在onGeometryChanged函数中得以体现。

更新HwcLayerList

那么选取合成类型就位于mLayerList->update(display);，位于hardware/intel/img/hwcomposer/common/base/HwcLayerList.cpp：

bool HwcLayerList::update(hwc_display_contents_1_t *list)
{
    bool ret;

    // basic check to make sure the consistance
    if (!list) {
        ELOGTRACE("null layer list");
        return false;
    }

    if ((int)list->numHwLayers != mLayerCount) {
        ELOGTRACE("layer count doesn't match (%d, %d)", list->numHwLayers, mLayerCount);
        return false;
    }

    // update list
    mList = list;

    bool ok = true;
    // update all layers, call each layer's update()
    for (int i = 0; i < mLayerCount; i++) {
        HwcLayer *hwcLayer = mLayers.itemAt(i);
        if (!hwcLayer) {
            ELOGTRACE("no HWC layer for layer %d", i);
            continue;
        }
        //更新layer，如果更新返回false，则需要fallback回GLES去合成
        if (!hwcLayer->update(&list->hwLayers[i])) {
            ok = false;
            hwcLayer->setCompositionType(HWC_FORCE_FRAMEBUFFER);
        }
    }

    if (!ok) {
        //如果上一步update有返回false的，就要把它fallback回GLES合成
        ILOGTRACE("overlay fallback to GLES. flags: %#x", list->flags);
        for (int i = 0; i < mLayerCount - 1; i++) {
            HwcLayer *hwcLayer = mLayers.itemAt(i);
            if (hwcLayer->getPlane() &&
                (hwcLayer->getCompositionType() == HWC_OVERLAY ||
                hwcLayer->getCompositionType() == HWC_CURSOR_OVERLAY)) {
                hwcLayer->setCompositionType(HWC_FRAMEBUFFER);
            }
        }
        //最后一个layer是HWC_FRAMEBUFFER_TARGET合成目标，上面讲过
        mLayers.itemAt(mLayerCount - 1)->setCompositionType(HWC_FRAMEBUFFER_TARGET);
        //反初始化
        deinitialize();
        mList = list;
        //初始化LayerList每一项
        initialize();

        // update all layers again after plane re-allocation
        //再次更新所有的layer，在plane重新申请之后
        for (int i = 0; i < mLayerCount; i++) {
            HwcLayer *hwcLayer = mLayers.itemAt(i);
            if (!hwcLayer) {
                ELOGTRACE("no HWC layer for layer %d", i);
                continue;
            }

            if (!hwcLayer->update(&list->hwLayers[i])) {
                DLOGTRACE("fallback to GLES update failed on layer[%d]!\n", i);
            }
        }
    }
    //建立只能合成选项，即选择OverLay还是FB
    setupSmartComposition();
    return true;
}

更新HwcLayer

这里依然要分步查看：
Part.1：我们可以看到，选取合成类型为Overlay还是FB就在hwcLayer->update函数，如果返回false，就要fallback回GLES，剩余的都是OverLay。我们看看这个实现，位于hardware/intel/img/hwcomposer/common/base/HwcLayer.cpp：

bool HwcLayer::update(hwc_layer_1_t *layer)
{
    // update layer
    mLayer = layer;
    //创建基本属性，从DataBuffer获取，也可是说是GraphicBuffer
    setupAttributes();

    // if not a FB layer & a plane was attached update plane's data buffer
    //如果不是一个FB layer并且plane已经被连接到更新data buffer
    if (mPlane) {
        //设置position位置信息
        mPlane->setPosition(layer->displayFrame.left,
                            layer->displayFrame.top,
                            layer->displayFrame.right - layer->displayFrame.left,
                            layer->displayFrame.bottom - layer->displayFrame.top);
        //设置sourceCrop区域                    
        mPlane->setSourceCrop(layer->sourceCropf.left,
                              layer->sourceCropf.top,
                              layer->sourceCropf.right - layer->sourceCropf.left,
                              layer->sourceCropf.bottom - layer->sourceCropf.top);
        //设置矩阵变换                      
        mPlane->setTransform(layer->transform);
        //透明度
        mPlane->setPlaneAlpha(layer->planeAlpha, layer->blending);
        //将layer的句柄设置给plane
        bool ret = mPlane->setDataBuffer((uint32_t)layer->handle);
        if (ret == true) {
            return true;
        }
        DLOGTRACE("failed to set data buffer, reset handle to 0!!");
        mHandle = 0;
        if (!mIsProtected) {//如果不是被保护的buffer
            //典型的例子：旋转的buffer没有准备好或者句柄为null，就不能用OverLay
            // typical case: rotated buffer is not ready or handle is null
            return false;
        } else {
            //被保护的视频需要使用overlay去渲染，return true
            // protected video has to be rendered using overlay.
            // if buffer is not ready overlay will still be attached to this layer
            // but rendering needs to be skipped.
            WLOGTRACE("ignoring result of data buffer setting for protected video");
            return true;
        }
    }

    return true;
}

先创建基本属性，从DataBuffer获取，也可是说是GraphicBuffer，我们看看setupAttributes函数：

void HwcLayer::setupAttributes()
{   //如果如下属性发生改变，将mUpdated 置为true
    if ((mLayer->flags & HWC_SKIP_LAYER) ||
        mTransform != mLayer->transform ||
        mSourceCropf != mLayer->sourceCropf ||
        mDisplayFrame != mLayer->displayFrame ||
        mHandle != (uint32_t)mLayer->handle ||
        DisplayQuery::isVideoFormat(mFormat)) {
        // TODO: same handle does not mean there is always no update
        mUpdated = true;
    }

    // update handle always as it can become "NULL"
    // if the given layer is not ready
    //如果指定的layer没有准备好，那么handle句柄就会变成null，所以要更新句柄的值
    mTransform = mLayer->transform;
    mSourceCropf = mLayer->sourceCropf;
    mDisplayFrame = mLayer->displayFrame;
    mHandle = (uint32_t)mLayer->handle;
    //其实属性已经被设置，return
    if (mFormat != DataBuffer::FORMAT_INVALID) {
        // other attributes have been set.
        return;
    }
    //句柄为null，return
    if (mLayer->handle == NULL) {
        VLOGTRACE("invalid handle");
        return;
    }
    //获取BufferManager
    BufferManager *bm = Hwcomposer::getInstance().getBufferManager();
    if (bm == NULL) {
        // TODO: this check is redundant
        return;
    }
    //锁定图形缓冲区
    DataBuffer *buffer = bm->lockDataBuffer((uint32_t)mLayer->handle);
     if (!buffer) {
         ELOGTRACE("failed to get buffer");
     } else {//获取图形缓冲区属性，并设置给全局变量
        mFormat = buffer->getFormat();
        mWidth = buffer->getWidth();
        mHeight = buffer->getHeight();
        mStride = buffer->getStride();
        mPriority = (mSourceCropf.right - mSourceCropf.left) * (mSourceCropf.bottom - mSourceCropf.top);
        mPriority <<= LAYER_PRIORITY_SIZE_OFFSET;
        mPriority |= mIndex;
        GraphicBuffer *gBuffer = (GraphicBuffer*)buffer;
        mUsage = gBuffer->getUsage();
        mIsProtected = GraphicBuffer::isProtectedBuffer((GraphicBuffer*)buffer);
        if (mIsProtected) {
            mPriority |= LAYER_PRIORITY_PROTECTED;
        } else if (PlaneCapabilities::isFormatSupported(DisplayPlane::PLANE_OVERLAY, this)) {
            mPriority |= LAYER_PRIORITY_OVERLAY;
        }
        //获取完之后释放
        bm->unlockDataBuffer(buffer);
    }
}

这段代码要是参考之前Gralloc模块应该有点印象，就是锁定图形缓冲区，获取图形缓冲区属性，并设置给全局变量，获取完之后释放。
回到HwcLayer::update，之后判断如果不是一个FB layer并且plane已经被连接到更新data buffer，就要设置position位置信息、设置sourceCrop区域、设置矩阵变换、透明度。

映射过程

然后将layer的句柄设置给plane，我们看看这个实现，位于hardware/intel/img/hwcomposer/common/planes/DisplayPlane.cpp：

bool DisplayPlane::setDataBuffer(uint32_t handle)
{
    DataBuffer *buffer;
    BufferMapper *mapper;
    ssize_t index;
    bool ret;
    bool isCompression;
    //获取buffermanager
    BufferManager *bm = Hwcomposer::getInstance().getBufferManager();

    RETURN_FALSE_IF_NOT_INIT();
    ALOGTRACE("handle = %#x", handle);

    if (!handle) {
        WLOGTRACE("invalid buffer handle");
        return false;
    }

    // do not need to update the buffer handle
    //如果不是当前保存句柄，加上CHANGE标签
    if (mCurrentDataBuffer != handle)
        mUpdateMasks |= PLANE_BUFFER_CHANGED;

    // if no update then do Not need set data buffer
    if (!mUpdateMasks)
        return true;
    //锁定缓冲区
    buffer = bm->lockDataBuffer(handle);
    if (!buffer) {
        ELOGTRACE("failed to get buffer");
        return false;
    }

    mIsProtectedBuffer = GraphicBuffer::isProtectedBuffer((GraphicBuffer*)buffer);
    isCompression = GraphicBuffer::isCompressionBuffer((GraphicBuffer*)buffer);

    // map buffer if it's not in cache
    //如果映射区域不在缓存cache中，就要重新映射
    index = mDataBuffers.indexOfKey(buffer->getKey());
    if (index < 0) {
        VLOGTRACE("unmapped buffer, mapping...");
        //映射buffer，并加入缓存
        mapper = mapBuffer(buffer);
        if (!mapper) {
            ELOGTRACE("failed to map buffer %#x", handle);
            bm->unlockDataBuffer(buffer);
            return false;
        }
    } else {
        VLOGTRACE("got mapper in saved data buffers and update source Crop");
        mapper = mDataBuffers.valueAt(index);
    }

    // always update source crop to mapper
    //更新crop区域
    mapper->setCrop(mSrcCrop.x, mSrcCrop.y, mSrcCrop.w, mSrcCrop.h);

    mapper->setIsCompression(isCompression);

    // unlock buffer after getting mapper
    //映射区域之后释放缓冲区
    bm->unlockDataBuffer(buffer);
    buffer = NULL;
    //将映射区域设置给plane
    ret = setDataBuffer(*mapper);
    if (ret) {//如果成功了，就将handle赋给mCurrentDataBuffer ，并且更新活跃的buffer
        mCurrentDataBuffer = handle;
        // update active buffers
        updateActiveBuffers(mapper);
    }
    return ret;
}

核心就是获取显示屏的BufferManager，然后锁定图形缓冲区，然后映射buffer，并加入缓存，映射区域之后释放缓冲区，将映射区域设置给plane。
映射实现如下：

BufferMapper* DisplayPlane::mapBuffer(DataBuffer *buffer)
{
    BufferManager *bm = Hwcomposer::getInstance().getBufferManager();

    // invalidate buffer cache  if cache is full
    //cache满了就要清除
    if ((int)mDataBuffers.size() >= mCacheCapacity) {
        invalidateBufferCache();
    }
    //映射plane内存区域
    BufferMapper *mapper = bm->map(*buffer);
    if (!mapper) {
        ELOGTRACE("failed to map buffer");
        return NULL;
    }

    // add it to data buffers
    //映射成功后就将这个句柄加入缓存
    ssize_t index = mDataBuffers.add(buffer->getKey(), mapper);
    if (index < 0) {
        ELOGTRACE("failed to add mapper");
        bm->unmap(mapper);
        return NULL;
    }

    return mapper;
}
void DisplayPlane::invalidateBufferCache()
{
    BufferManager *bm = Hwcomposer::getInstance().getBufferManager();
    BufferMapper* mapper;

    RETURN_VOID_IF_NOT_INIT();

    for (size_t i = 0; i < mDataBuffers.size(); i++) {
        mapper = mDataBuffers.valueAt(i);
        bm->unmap(mapper);
    }

    mDataBuffers.clear();
    // reset current buffer
    mCurrentDataBuffer = 0;
}

之后将映射区域设置给plane，如果成功了，就将handle赋给mCurrentDataBuffer ，并且更新活跃的buffer：

void DisplayPlane::updateActiveBuffers(BufferMapper *mapper)
{
    BufferManager *bm = Hwcomposer::getInstance().getBufferManager();

    // unmap the first entry (oldest buffer)
    if (mActiveBuffers.size() >= MIN_DATA_BUFFER_COUNT) {
        BufferMapper *oldest = mActiveBuffers.itemAt(0);
        bm->unmap(oldest);
        mActiveBuffers.removeAt(0);
    }

    // queue it to active buffers
    if (!isActiveBuffer(mapper)) {
        mapper->incRef();
        mActiveBuffers.push_back(mapper);
    }
}

也就是移除最老的映射buffer，然后新增加一个最新的。

如果设置给plane不成功，即没有可用的内存区域或者不匹配，则不能使用OverLay合成，返回false，就要是OpenGL了。

初始化和反初始化

回到上面HwcLayerList::update，继续往下走。

然后就是先反初始化deinitialize：

void HwcLayerList::deinitialize()
{
    if (mLayerCount == 0) {
        return;
    }

    DisplayPlaneManager *planeManager = Hwcomposer::getInstance().getPlaneManager();
    for (int i = 0; i < mLayerCount; i++) {
        HwcLayer *hwcLayer = mLayers.itemAt(i);
        if (hwcLayer) {
            DisplayPlane *plane = hwcLayer->detachPlane();
            if (plane) {
                planeManager->reclaimPlane(mDisplayIndex, *plane);
            }
        }
        delete hwcLayer;
    }

    mLayers.clear();
    mFBLayers.clear();
    mOverlayCandidates.clear();
    mSpriteCandidates.clear();
    mCursorCandidates.clear();
    mZOrderConfig.clear();
    mFrameBufferTarget = NULL;
    mLayerCount = 0;
}

反初始化就是清除一些变量。然后是初始化initialize：

bool HwcLayerList::initialize()
{
    if (!mList || mList->numHwLayers == 0) {
        ELOGTRACE("invalid hwc list");
        return false;
    }
    //设置一些变量
    mLayerCount = (int)mList->numHwLayers;
    mLayers.setCapacity(mLayerCount);
    mFBLayers.setCapacity(mLayerCount);
    mSpriteCandidates.setCapacity(mLayerCount);
    mOverlayCandidates.setCapacity(mLayerCount);
    mCursorCandidates.setCapacity(mLayerCount);
    mZOrderConfig.setCapacity(mLayerCount);
    Hwcomposer& hwc = Hwcomposer::getInstance();

    PriorityVector rgbOverlayLayers;
    rgbOverlayLayers.setCapacity(mLayerCount);
    //根据不同合成类型设置hwcLayer的type
    for (int i = 0; i < mLayerCount; i++) {
        hwc_layer_1_t *layer = &mList->hwLayers[i];
        if (!layer) {
            DEINIT_AND_RETURN_FALSE("layer %d is null", i);
        }

        HwcLayer *hwcLayer = new HwcLayer(i, layer);
        if (!hwcLayer) {
            DEINIT_AND_RETURN_FALSE("failed to allocate hwc layer %d", i);
        }

        if (layer->compositionType == HWC_FRAMEBUFFER_TARGET) {//HWC_FRAMEBUFFER_TARGET
            hwcLayer->setType(HwcLayer::LAYER_FRAMEBUFFER_TARGET);
            mFrameBufferTarget = hwcLayer;
        } else if (layer->compositionType == HWC_OVERLAY){
            // skipped layer, filtered by Display Analyzer
            hwcLayer->setType(HwcLayer::LAYER_SKIPPED);
        } else if (layer->compositionType == HWC_FORCE_FRAMEBUFFER) {//HWC_FORCE_FRAMEBUFFER
            layer->compositionType = HWC_FRAMEBUFFER;
            hwcLayer->setType(HwcLayer::LAYER_FORCE_FB);
            // add layer to FB layer list for zorder check during plane assignment
            mFBLayers.add(hwcLayer);
        } else  if (layer->compositionType == HWC_FRAMEBUFFER) {//HWC_FRAMEBUFFER
            // by default use GPU composition
            //默认由GPU合成
            hwcLayer->setType(HwcLayer::LAYER_FB);
            mFBLayers.add(hwcLayer);
            //检查是否支持cursor overlay
            if (checkCursorSupported(hwcLayer)) {
                mCursorCandidates.add(hwcLayer);
            } else if (checkRgbOverlaySupported(hwcLayer)) {//检查是否支持rgb overlay
                rgbOverlayLayers.add(hwcLayer);
            } else if (checkSupported(DisplayPlane::PLANE_SPRITE, hwcLayer)) {//检查是否支持PLANE_SPRITE
                mSpriteCandidates.add(hwcLayer);
            } else if (checkSupported(DisplayPlane::PLANE_OVERLAY, hwcLayer)) {//是否支持PLANE_OVERLAY
                mOverlayCandidates.add(hwcLayer);
            } else {
                // noncandidate layer
            }
        } else if (layer->compositionType == HWC_SIDEBAND){//HWC_SIDEBAND
            hwcLayer->setType(HwcLayer::LAYER_SIDEBAND);
        } else {
            DEINIT_AND_RETURN_FALSE("invalid composition type %d", layer->compositionType);
        }
        // add layer to layer list
        mLayers.add(hwcLayer);
    }

    if (mFrameBufferTarget == NULL) {
        ELOGTRACE("no frame buffer target?");
        return false;
    }

    // If has layer besides of FB_Target, but no FBLayers, skip plane allocation
    // Note: There is case that SF passes down a layerlist with only FB_Target
    // layer; we need to have this FB_Target to be flipped as well, otherwise it
    // will have the buffer queue blocked. (The buffer hold by driver cannot be
    // released if new buffers' flip is skipped).
    if ((mFBLayers.size() == 0) && (mLayers.size() > 1)) {
        VLOGTRACE("no FB layers, skip plane allocation");
        return true;
    }

    bool hasOverlay = mOverlayCandidates.size() != 0;
    while (rgbOverlayLayers.size()) {
        HwcLayer *hwcLayer = rgbOverlayLayers.top();
        if (hasOverlay) {
            mSpriteCandidates.add(hwcLayer);
        } else {
            mOverlayCandidates.add(hwcLayer);
        }
        rgbOverlayLayers.removeItemsAt(0);
    }

    if (!DisplayQuery::forceFbScaling(mDisplayIndex)) {
        allocatePlanes();
    } else {
        // force GLES composition on all layers, then use GPU or hardware
        // overlay to scale buffer to match display resolution
        assignPrimaryPlane();
    }

    //dump();
    return true;
}

这一段核心就是根据不同合成类型设置hwcLayer的type，合成类型有HWC_FRAMEBUFFER_TARGET、HWC_FORCE_FRAMEBUFFER、HWC_FRAMEBUFFER、HWC_SIDEBAND，又在HWC_FRAMEBUFFER检测：检查是否支持cursor overlay、检查是否支持rgb overlay、检查是否支持PLANE_SPRITE、是否支持PLANE_OVERLAY，如果支持就要加入OverLay合成。

开始智能合成

继续回到上面，进行最后一步setupSmartComposition，建立只能合成选项，即选择OverLay还是FB：

void HwcLayerList::setupSmartComposition()
{
    //默认都是HWC_OVERLAY
    uint32_t compositionType = HWC_OVERLAY;
    HwcLayer *hwcLayer = NULL;

    // setup smart composition only there's no update on all FB layers
    //如果所有的FB layer没有更新了就开始建立智能合成
    for (size_t i = 0; i < mFBLayers.size(); i++) {
        hwcLayer = mFBLayers.itemAt(i);
        if (hwcLayer->isUpdated()) {
            compositionType = HWC_FRAMEBUFFER;
        }
    }

    VLOGTRACE("smart composition enabled %s",
           (compositionType == HWC_OVERLAY) ? "TRUE" : "FALSE");
    //开始只能合成，当compositionType == HWC_OVERLAY就是硬件合成，否则其他都是FB模式       
    for (size_t i = 0; i < mFBLayers.size(); i++) {
        hwcLayer = mFBLayers.itemAt(i);
        switch (hwcLayer->getType()) {
        case HwcLayer::LAYER_FB:
        case HwcLayer::LAYER_FORCE_FB:
            hwcLayer->setCompositionType(compositionType);
            break;
        default:
            ELOGTRACE("Invalid layer type %d", hwcLayer->getType());
            break;
        }
    }
}

上面就是开始智能合成，当compositionType == HWC_OVERLAY就是硬件合成，否则其他都是FB模式。

小结

上述就是hwc硬件选取合成类型的模块，流程分析比较粗略，估计有好多不正确的地方，欢迎大家指正，我好在第一时间修改。

Android SurfaceFlinger 学习之路(十一)----合成Layer之准备合成

2017-12-01T06:31:11.000Z

上一篇我们主要分析了计算Layer的脏区域流程，其中涉及了Buffer状态迁移的后两个步骤：ACQUIRED、RELEADED。本届开始就是正式的合成步骤——REFRESH。但是这个步骤比较复杂，所以先分析合成前的准备工作：重建Layer栈与初始化硬件合成器。

合成准备

当Vsync到来时候，SF会处理MessageQueue的INVALIDATE消息，消息最后一部再次触发REFRESH消息，进入合成阶段。
这个流程在SF的handleMessageRefresh函数，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp中：

void SurfaceFlinger::handleMessageRefresh() {
    ATRACE_CALL();
    /*调Layer的onPreComposition方法，主要是标志一下Layer已经被用于合成*/
    preComposition();
    /*若Layer的位置/先后顺序/可见性发生变化，重新计算Layer的目标合成区域和先后顺序*/
    rebuildLayerStacks();
    /*配置硬件合成器，调hwc的prepare方法*/
    setUpHWComposer();
    /*当打开开发者选项中的“显示Surface刷新”时，额外为产生变化的图层绘制闪烁动画*/
    doDebugFlashRegions();//ignore
    /*执行合成主体，对3D合成而言，调opengl的drawcall，对硬件合成而言，调hwc的set方法*/
    doComposition();
    /*主要用于调试，调Layer的onPostComposition方法*/
    postComposition();
}

这个函数每一步的功能都很清晰，看起来简单粗暴。综合上面几节，流程图如下：

每一部的功能，我们会在接下来每一步详细分析。

流程分析

preComposition

调Layer的onPreComposition方法，主要是标志一下Layer已经被用于合成。我们看看preComposition函数：

void SurfaceFlinger::preComposition()
{
    bool needExtraInvalidate = false;
    const LayerVector& layers(mDrawingState.layersSortedByZ);
    const size_t count = layers.size();
    for (size_t i=0 ; i<count ; i++) {
        if (layers[i]->onPreComposition()) {
            needExtraInvalidate = true;
        }
    }
    if (needExtraInvalidate) {
        signalLayerUpdate();
    }
}

代码很简单，一共就三步：
1）获取全部经过z-order排序的layer；
2）每个layer调用onPrecomposition判断是否需要触发vsync更新；
3）Layer update。
我们看看第二步的判断逻辑，Layer的onPrecomposition函数，位于frameworks/native/services/surfaceflinger/Layer.cpp：


bool Layer::onPreComposition() {
    mRefreshPending = false;//标志一下Layer已经被用于合成
    //当layer里存放被queue的frame以后，就会出发layer update
    return mQueuedFrames > 0 || mSidebandStreamChanged;
}

我们在Android SurfaceFlinger 学习之路(八)—-Surface管理图形缓冲区中讲过，当Buffer被queue回BufferQueue，状态迁移到QUEUED，就会回调Layer的onFrameAvailable函数，将mQueuedFrames自动+1。所以当vsync到来时候，就会根据这个判断时候更新layer。

rebuildLayerStacks

若Layer的位置/先后顺序/可见性发生变化，重新计算Layer的目标合成区域和先后顺序。我们要看看rebuildLayerStacks函数：

void SurfaceFlinger::rebuildLayerStacks() {
    // rebuild the visible layer list per screen
    //系统显示屏以及各个应用程序窗口的属性变化时
    if (CC_UNLIKELY(mVisibleRegionsDirty)) {
        ATRACE_CALL();
        mVisibleRegionsDirty = false;
        //将mHwWorkListDirty 标记为true
        invalidateHwcGeometry();
        //获取当前应用程序所有按照z-order排列的layer
        const LayerVector& layers(mDrawingState.layersSortedByZ);
        //遍历每一个显示屏
        for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {
            Region opaqueRegion;//全局不透明区域
            Region dirtyRegion;//需要重新render的脏区域
            Vector< sp<Layer> > layersSortedByZ;
            const sp<DisplayDevice>& hw(mDisplays[dpy]);
            const Transform& tr(hw->getTransform());
            const Rect bounds(hw->getBounds());
            if (hw->isDisplayOn()) {
                //计算当前显示屏各个应用程序的可见区域
                SurfaceFlinger::computeVisibleRegions(layers,
                        hw->getLayerStack(), dirtyRegion, opaqueRegion);

                const size_t count = layers.size();
                for (size_t i=0 ; i<count ; i++) {
                    const sp<Layer>& layer(layers[i]);
                    const Layer::State& s(layer->getDrawingState());
                    if (s.layerStack == hw->getLayerStack()) {
                        //可见不透明的区域
                        Region drawRegion(tr.transform(
                                layer->visibleNonTransparentRegion));
                        drawRegion.andSelf(bounds);
                        if (!drawRegion.isEmpty()) {
                            //添加进入z-order排列的layer
                            layersSortedByZ.add(layer);
                        }
                    }
                }
            }
            //z-order排列的layer
            hw->setVisibleLayersSortedByZ(layersSortedByZ);
            //显示屏大小
            hw->undefinedRegion.set(bounds);
            //减去不透明区域
            hw->undefinedRegion.subtractSelf(tr.transform(opaqueRegion));
            //累加脏区域
            hw->dirtyRegion.orSelf(dirtyRegion);
        }
    }
}

void SurfaceFlinger::invalidateHwcGeometry()
{
    mHwWorkListDirty = true;
}

流程如下：
1）从上一节的内容可以知道，当SurfaceFlinger服务在处理系统显示屏以及各个应用程序窗口的属性变化时，如果发现需要重新计算各个应用程序窗口的可见区域，那么就会将SurfaceFlinger类的成员变量mVisibleRegionsDirty的值设置为true。
进入判断逻辑之后，将成员变量mVisibleRegionsDirty的值设置为false了，因为这时候系统中各个应用程序窗口的可见区域开始计算了。
2）函数接下来通过SurfaceFlinger类的成员变量mDrawingState所描述的一个State对象的成员变量layersSortedByZ来获得系统当前所有的应用程序窗口，并且保存在一个类型为LayerVector的向量layers中。
3）SurfaceFlinger类的成员函数computeVisibleRegions在计算完成各个应用程序窗口的可见区域之后，会得到一个全局不透明区域，保存在输出参数opaqueRegion中。这个全局不透明区域就是接下来需要渲染的，一般情况下，它的大小就应该等于显示屏的大小，即变量hw->getBounds()所描述的区域。在异常情况下，可能会导致显示屏区域bounds大于全局不透明区域opaqueRegion，这时候前者减去后者就可以得到一些称为“虫洞”的区域。由于这些虫洞区域不会被各个应用程序窗口覆盖，因此，SurfaceFlinger服务需要对它们进行特殊处理，即以一种特殊的方式来渲染它们。在后面的部分内容中，我们就会看到SurfaceFlinger服务是通过调用SurfaceFlinger类的成员函数drawWormhole来渲染这些虫洞的。
4）dirtyRegion是需要被刷新的。 opaqueRegion 不透明区域，layer是按Z-order排序的，左右排在前面的opaqueRegion 会挡住后面的layer。Region drawRegion(tr.transform( layer->visibleNonTransparentRegion));程序需要进一步得出每个layer 绘制的区域。
5）将结果保存到hw中。

所以上述流程的重点就是computeVisibleRegions就算过程，我们详细分析这个流程。

再计算可见区域之前，我们要了解一些概念。

computeVisibleRegions

computeVisibleRegions代码有点长，我们分段阅读：

void SurfaceFlinger::computeVisibleRegions(
        const LayerVector& currentLayers, uint32_t layerStack,
        Region& outDirtyRegion, Region& outOpaqueRegion)
{
    ATRACE_CALL();

    Region aboveOpaqueLayers;
    Region aboveCoveredLayers;
    Region dirty;

    outDirtyRegion.clear();

这段代码定义了另外两个区域aboveOpaqueLayers，分别用来描述上层覆盖完全不透明区域（Above Opaque Layers）和上层覆盖区域（Above Covered Layers），上面讲过，这两个计算累加的结果。
我们接着往下阅读代码：

size_t i = currentLayers.size();
    while (i--) {
        const sp<Layer>& layer = currentLayers[i];

        // start with the whole surface at its current location
        const Layer::State& s(layer->getDrawingState());

        // only consider the layers on the given layer stack
        if (s.layerStack != layerStack)
            continue;

这段代码是一个while循环的前面几行。系统中所有需要计算可见区域的应用程序窗口都保存在参数currentLayers所描述的一个向量中。这段代码的while循环就是用来逐个地这些应用程序窗口的可见区域的。注意，这个while是先计算是按照从上到下的顺序来计算系统中各个应用程序窗口的可见区域的。
然后获得用来描述当前正在处理的应用程序窗口的当前渲染状态的一个State对象s，然后判断是否是当前应用程序的layerStack，否则就continue。
我们继续往下阅读代码：

/*
 * opaqueRegion: area of a surface that is fully opaque.
 */
Region opaqueRegion;

/*
 * visibleRegion: area of a surface that is visible on screen
 * and not fully transparent. This is essentially the layer's
 * footprint minus the opaque regions above it.
 * Areas covered by a translucent surface are considered visible.
 */
Region visibleRegion;

/*
 * coveredRegion: area of a surface that is covered by all
 * visible regions above it (which includes the translucent areas).
 */
Region coveredRegion;

/*
 * transparentRegion: area of a surface that is hinted to be completely
 * transparent. This is only used to tell when the layer has no visible
 * non-transparent regions and can be removed from the layer list. It
 * does not affect the visibleRegion of this layer or any layers
 * beneath it. The hint may not be correct if apps don't respect the
 * SurfaceView restrictions (which, sadly, some don't).
 */
Region transparentRegion;

接着再定义了四个Region对象opaqueRegion、visibleRegion、coveredRegion和transparentRegion，分别用来描述当前正在处理的应用程序窗口的完全不透明区域、可见区域、被覆盖区域和透明区域。这四个区域的含义和作用如前所述。
go on:

// handle hidden surfaces by setting the visible region to empty
       if (CC_LIKELY(layer->isVisible())) {
           //是否是半透明
           const bool translucent = !layer->isOpaque(s);
           //layer的可见区域
           Rect bounds(s.transform.transform(layer->computeBounds()));
           //以便可以得到当前正在处理的应用程序窗口的初始可见区域visibleRegion
           visibleRegion.set(bounds);
           if (!visibleRegion.isEmpty()) {//计算透明区域
               // Remove the transparent area from the visible region
               if (translucent) {
                   //当前渲染状态的一个State对象s的成员变量transform指向的也是一个变换矩阵
                   //用来描述当前正在处理的应用程序窗口的位置、旋转方向和缩放因子等
                   const Transform tr(s.transform);
                   //函数接着判断当前正在处理的应用程序窗口是否被旋转过或者被缩放过
                   if (tr.transformed()) {
                       //判断当前正在处理的应用程序窗口是否被旋转和缩放得不规则
                       if (tr.preserveRects()) {
                           // transform the transparent region
                           transparentRegion = tr.transform(s.activeTransparentRegion);
                       } else {
                           //即当当前正在处理的应用程序窗口被旋转和缩放得不规则时，
                           //这时候对应用程序窗口的透明区域进行旋转或者缩放就会很复杂，
                           //于是函数就干脆将它的透明区域忽略掉
                           // transformation too complex, can't do the
                           // transparent region optimization.
                           transparentRegion.clear();
                       }
                   } else {//如果没有经过矩阵变换处理
                       transparentRegion = s.activeTransparentRegion;
                   }
               }

               // compute the opaque region
               //当当前正在处理的应用程序窗口是完全不透明，并且旋转方向也是规则时，
               //那么它的完全不透明区域opaqueRegion就等于前面计算所得到的可见区域visibleRegion
               const int32_t layerOrientation = s.transform.getOrientation();
               if (s.alpha==255 && !translucent &&
                       ((layerOrientation & Transform::ROT_INVALID) == false)) {
                   // the opaque region is the layer's footprint
                   opaqueRegion = visibleRegion;
               }
           }
       }

这段代码用来计算当前正在处理的应用程序窗口的可见区域和完全不透明区域。只有在当前正在处理的应用程序窗口处于可见状态，并且它不是完全透明时，才需要计算这两个区域。我们看看Layer的isVisible函数，位于frameworks/native/services/surfaceflinger/Layer.cpp：


bool Layer::isVisible() const {
    const Layer::State& s(mDrawingState);
    return !(s.flags & layer_state_t::eLayerHidden) && s.alpha
            && (mActiveBuffer != NULL || mSidebandStream != NULL);
}

当State对象s的成员变量flags的ISurfaceComposer::eLayerHidden位等于0时，就说明当前正在处理的应用程序窗口是处于可见状态的，而当它的另外一个成员变量alpha的值不等于0的时候，就说明当前正在处理的应用程序窗口不是完全透明的。
回到上面部分，接着计算透明区域。用来描述当前正在处理的应用程序窗口的当前渲染状态的一个State对象s的成员变量transform指向的也是一个变换矩阵，用来描述当前正在处理的应用程序窗口的位置、旋转方向和缩放因子等。
函数接着判断当前正在处理的应用程序窗口是否被旋转过或者被缩放过。如果是的话，那么前面调用变换矩阵tr的成员函数transformed的返回值就会等于true，即变量transformed的等于true。在这种情况下，函数就要相应地对当前正在处理的应用程序窗口的透明区域进行旋转或者缩放。但是有一种特殊情况，即当当前正在处理的应用程序窗口被旋转和缩放得不规则时，这时候对应用程序窗口的透明区域进行旋转或者缩放就会很复杂，于是函数就干脆将它的透明区域忽略掉。判断当前正在处理的应用程序窗口是否被旋转和缩放得不规则是通过调用变换矩阵tr的成员函数preserveRects来实现的，当它的返回值等于true的时候，就说明当前正在处理的应用程序窗口是否被旋转和缩放之后还是规则，否则就是不规则的。
当前正在处理的应用程序窗口的透明区域保存在State对象s的成员变量transparentRegion中，按照上述原理，函数按照以下规则来对它进行处理：
1）当变量transformed的等于false时，说明当前正在处理的应用程序窗口的透明区域就不需要进行旋转或者缩放，这时候就可以将这个透明区域保存在变量transparentRegionScreen中。
2）当变量transformed的等于true，并且变换矩阵tr的成员函数preserveRects的返回值也等于true时，那么就说明当前正在处理的应用程序窗口的透明区域需要进行旋转或者缩放，这时候通过调用变换矩阵tr的成员函数transform来实现的。最终得到的透明区域同样是保存在变量transparentRegionScreen中。
3）当变量transformed的等于true，并且变换矩阵tr的成员函数preserveRects的返回值等于false时，那么就说明需要忽略掉当前正在处理的应用程序窗口的透明区域，通过成员函数clear来实现的。

我们接着来看当前正在处理的应用程序窗口的完全不透明区域的计算过程。
当当前正在处理的应用程序窗口是完全不透明，并且旋转方向也是规则时，那么它的完全不透明区域opaqueRegion就等于前面计算所得到的可见区域visibleRegion。当当前正在处理的应用程序窗口的Alpha通道等于255，即当State对象s的成员变量alpha的值等于255，并且变量translucent的值等于false时，就说明它是完全不透明的，而当当前正在处理的应用程序窗口的旋转方向layerOrientation的Transform::ROT_INVALID位等于0的时候，就说明它的旋转方向是规则的。

go on：

// Clip the covered region to the visible region
        coveredRegion = aboveCoveredLayers.intersect(visibleRegion);

        // Update aboveCoveredLayers for next (lower) layer
        aboveCoveredLayers.orSelf(visibleRegion);

        // subtract the opaque region covered by the layers above us
        visibleRegion.subtractSelf(aboveOpaqueLayers);

这段代码用来计算当前正在处理的应用程序窗口的被覆盖区域，以及再进一步计算它的可见区域，主要考虑是否被上层的不透明区域覆盖了。
变量aboveCoveredLayers用来描述当前正在处理的应用程序窗口的所有上层应用程序窗口所组成的可见区域，将这个区域与当前正在处理的应用程序窗口的可见区域visibleRegion相交，就可以得到当前正在处理的应用程序窗口的被覆盖区域coveredRegion，而将这个区域与当前正在处理的应用程序窗口的可见区域visibleRegion相或一下，就可以得到下一个应用程序窗口的所有上层应用程序窗口所组成的可见区域aboveCoveredLayers。
变量aboveOpaqueLayers用来描述当前正在处理的应用程序窗口的所有上层应用程序窗口所组成的完全不透明区域，这个区域从当前正在处理的应用程序窗口的可见区域visibleRegion减去后，就可以得到当前正在处理的应用程序窗口的最终可见区域visibleRegion。

go on:

// compute this layer's dirty region
       if (layer->contentDirty) {
           // we need to invalidate the whole region
           dirty = visibleRegion;
           // as well, as the old visible region
           dirty.orSelf(layer->visibleRegion);
           layer->contentDirty = false;
       } else {
           /* compute the exposed region:
            *   the exposed region consists of two components:
            *   1) what's VISIBLE now and was COVERED before
            *   2) what's EXPOSED now less what was EXPOSED before
            *
            * note that (1) is conservative, we start with the whole
            * visible region but only keep what used to be covered by
            * something -- which mean it may have been exposed.
            *
            * (2) handles areas that were not covered by anything but got
            * exposed because of a resize.
            */
           const Region newExposed = visibleRegion - coveredRegion;
           const Region oldVisibleRegion = layer->visibleRegion;
           const Region oldCoveredRegion = layer->coveredRegion;
           const Region oldExposed = oldVisibleRegion - oldCoveredRegion;
           dirty = (visibleRegion&oldCoveredRegion) | (newExposed-oldExposed);
       }
       dirty.subtractSelf(aboveOpaqueLayers);

       // accumulate to the screen dirty region
       outDirtyRegion.orSelf(dirty);

这段代码用来计算屏幕的脏区域。我们首先解释一下屏幕的脏区域是如何计算的。将所有应用程序窗口的脏区域都组合起来，就可以得到屏幕的脏区域，这个脏区域就是需要重新执行渲染操作的。因此，为了得到屏幕的脏区域，我们要知道当前正在处理的应用程序窗口的脏区域，以及之前已经处理了的应用程序窗口脏区域组合。前者使用变量dirty来描述，而后者使用输出参数outDirtyRegion来描述。

我们首先来看当前正在处理的应用程序窗口的脏区域dirty是如何计算的。我们分两种情况来考虑。
1）首先考虑当前正在处理的应用程序窗口上一次的状态还未来得及处理的情况，即它当前的内容是脏的。在这种情况下，layer的成员变量contentDirty的值就会等于true。这时候我们就需要将该应用程序窗口的上一次可见区域，以及当前的可见区域合并起来，形成一个大的脏区域，这样就可以将两次渲染操作合并成一次来执行。当前正在处理的应用程序窗口的上一次可见区域保存在layer的成员变量visibleRegion中，而它前的可见区域保存在变量visibleRegion中。将这两者相或一下，就可以得到当前正在处理的应用程序窗口的脏区域dirty。
2）接着考虑当前正在处理的应用程序窗口上一次的状态已经处理了的情况，即它当前的内容不是脏的，这意味着它所要显示的内容没有发生变化。在这种情况下，就不需要重新渲染所有的可见区域。那么那些区域是需要重新渲染的呢？第一部分区域是之前是被覆盖的，现在不被覆盖了，第二部分是由于窗口大小变化而引发的新增不被覆盖区域。接下来，我们就来看看这两部分区域是如何计算的。
将一个应用程序窗口的当前可见区域减去被覆盖区域，就可以它的当前不被覆盖的区域newExposed，按照同样的方法，我们可以也可以得到它的上一次不被覆盖的区域oldExposed。注意，一个应用程序窗口的上一次可见区域和被覆盖区域分别保存与它相对应的一个Layer对象的成员变量visibleRegion和coveredRegion中。这样，将一个应用程序窗口的当前不被覆盖的区域newExposed减去它的上一次不被覆盖的区域oldExposed，就可以得到新增的不被覆盖区域，即可以得到第二部分需要重新渲染的区域。另一方面，将一个应用程序窗口的当前可见区域visibleRegion与它的上一次被覆盖区域oldCoveredRegion相交，就可以得到之前是被覆盖的而现在不被覆盖了的区域，即可以得到第一部分需要重新渲染的区域。将第一部分和第二部分需要重新渲染的区域组合起来，就可以得到当前正在处理的应用程序窗口的脏区域dirty。
得到了当前正在处理的应用程序窗口的脏区域dirty，接下来的事情就好办了。首先从该脏区域dirty减去上层的完全不透明区域，因为后者的渲染不需要当前应用程序窗口来参与，接着最将得到的新的脏区域dirty累加到输出参数outDirtyRegion中去，这样就可以得到目前为止，SurfaceFlinger服务需要渲染的脏区域。

go on:

  // Update aboveOpaqueLayers for next (lower) layer
        aboveOpaqueLayers.orSelf(opaqueRegion);

        // Store the visible region in screen space
        layer->setVisibleRegion(visibleRegion);
        layer->setCoveredRegion(coveredRegion);
        layer->setVisibleNonTransparentRegion(
                visibleRegion.subtract(transparentRegion));
    }

    outOpaqueRegion = aboveOpaqueLayers;
}

这段代码是前面的while循环的几行结束代码，主要用来做三件事情。
第一件事情是计算到目前为止所得到的上层应用程序窗口的完全不透明区域，这是通过组合当前正在处理的应用程序窗口的完全不透明区域与位于它上面的的所有应用程序窗口的完全不透明区域aboveOpaqueLayers来得到的，并且最终结果保存在变量aboveOpaqueLayers中。
第二件事情是调用layer的成员函数setVisibleRegion、setCoveredRegion和setVisibleNonTransparentRegion来保存当前正在处理的应用程序窗口的可见区域、被覆盖区域和没有透明区域的可见区域。
第三件事情是，函数还将前面所有的应用程序窗口组成的完全不透明区域aboveOpaqueLayers保存在输出参数opaqueRegion，以便可以返回给调用者使用。

这就是计算Layer可视区域的所有流程，只要理解了里面每个变量代表对应含义区域的意义，就不难分析。这里我们rebuildLayerStacks流程就分析完了。我们继续往下走，分析下一步。

setUpHWComposer

合成步骤的下一步就是setUpHWComposer函数调用，配置硬件合成器。

回顾HWC

我们之前在Android SurfaceFlinger 学习之路(二)—-SurfaceFlinger概述讲过，用于合成surface的功能模块可以有2个，OpenGL ES & HWC，它的管理实在HWC里面实现的。
官网也给出了一些解释，https://source.android.google.cn/devices/graphics/arch-sf-hwc ，不过中文翻译的不是很好，最好看看英文：
Hardware Composer HAL (HWC) 是在 Android 3.0 中推出的，并且多年来一直都在不断演进。它主要是用来确定通过可用硬件来合成缓冲区的最有效方法。作为 HAL，其实现是特定于设备的，而且通常由显示设备硬件原始设备制造商 (OEM) 完成。
当考虑叠加平面时，很容易发现这种方法的好处。它的目的是在显示硬件（而不是 GPU）中将多个缓冲区合成在一起。例如，假设有一部处于纵向模式的普通 Android 手机，其状态栏在顶部，导航栏在底部，其他地方为应用内容。每个层的内容都在单独的缓冲区中。您可以使用以下任一方法处理合成：

将应用内容渲染到暂存缓冲区中，然后在其上渲染状态栏，再在其上渲染导航栏，最后将暂存缓冲区传送到显示硬件。
将三个缓冲区全部传送到显示硬件，并告知它从不同的缓冲区读取屏幕不同部分的数据。

后一种方法可以显著提高效率。
上面两种合成分别叫离线合成和在线合成。

离线合成：先将所有图层画到一个最终层（FrameBuffer）上，再将FrameBuffer送到LCD显示。由于合成FrameBuffer与送LCD显示一般是异步的（线下生成FrameBuffer，需要时线上的LCD去取），因此叫离线合成。
在线合成：不使用FrameBuffer，在LCD需要显示某一行的像素时，用显示控制器将所有图层与该行相关的数据取出，合成一行像素送过去。只有一个图层时，又叫Overlay技术。
由于省去合成FrameBuffer时读图层，写FrameBuffer的步骤，大幅降低了内存传输量，减少了功耗，但这个需要硬件支持。

效率对比：大部分情况下，在线合成比起离线合成有很明显的优势，大幅降低了内存带宽的消耗。不过对于多屏显示，静态场景（仅限LCD不带缓存的情况），离线合成会有优势，做下简单的计算不难推得。

显示处理器功能差异很大。overlay的数量（无论层是否可以旋转或混合）以及对定位和叠加的限制很难通过 API 表达。HWC 会尝试通过一系列决策来适应这种多样性：

SurfaceFlinger给HWC提供layer list，询问如何处理这些layer；
HWC将每个layer标记为overlay或者GLES composition，然后回馈给SurfaceFlinger；
SurfaceFlinger需要去处理那些GLES的合成，而不用去管overlay的合成，最后将overlay的layer和GLES合成后的buffer发送给HWC处理。

用之前一幅图表示：

屏幕上的内容没有变化时，overlay的效率可能会低于 GL 合成。当overlay内容具有透明像素且overlay混合在一起时，尤其如此。在此类情况下，HWC 可以选择为部分或全部层请求 GLES 合成，并保留合成的缓冲区。如果 SurfaceFlinger 返回要求合成同一组缓冲区，HWC 可以继续显示先前合成的暂存缓冲区。这可以延长闲置设备的电池续航时间。
运行 Android 4.4 或更高版本的设备通常支持 4 个overlay。尝试合成多于overlay的层会导致系统对其中一些层使用 GLES 合成，这意味着应用使用的层数会对功耗和性能产生重大影响。

关于HWC HAL有更详细的解释，官网在置如此：https://source.android.google.cn/devices/graphics/implement-hwc ，中文翻译的依旧有些别扭：

Hardware Composer HAL (HWC) 由 SurfaceFlinger 用来将 Surface 合成到屏幕。HWC 可以抽象出叠加层和 2D 位块传送器等对象，有助于分载通常使用 OpenGL 完成的一些工作。
Android 7.0 包含新版本的 HWC (HWC2)，由 SurfaceFlinger 用来与专门的窗口合成硬件进行通信。SurfaceFlinger 包含使用 3D 图形处理器 (GPU) 执行窗口合成任务的备用路径，但由于以下几个原因，此路径并不理想：

通常，GPU 未针对此用例进行过优化，因此能耗可能要大于执行合成所需的能耗。
每次 SurfaceFlinger 使用 GPU 进行合成时，应用都无法使用处理器进行自我渲染，因此应尽可能使用专门的硬件而不是 GPU 进行合成。

由于 Hardware Composer 抽象层后的物理显示设备硬件可因设备而异，因此很难就具体功能提供建议。一般来说，请遵循以下准则：

HWC 应至少支持 4 个叠加层（状态栏、系统栏、应用和壁纸/背景）。
层可以大于屏幕，因此 HWC 应能处理大于显示屏的层（例如壁纸）。
应同时支持预乘每像素 Alpha 混合和每平面 Alpha 混合。
HWC 应能消耗 GPU、相机和视频解码器生成的相同缓冲区，因此支持以下某些属性很有帮助：
- RGBA 打包顺序
- YUV 格式
- 平铺、重排和步幅属性
为了支持受保护的内容，必须提供受保护视频播放的硬件路径。

常规建议是首先实现非运行的 HWC；在结构完成后，实现一个简单的算法，以将合成委托给 HWC（例如，仅将前 3 个或前 4 个 Surface 委托给 HWC 的叠加硬件）。

专注于优化，例如智能地选择要发送到叠加硬件的 Surface，以最大限度提高从 GPU 移除的负载。另一种优化是检测屏幕是否正在更新；如果不是，则将合成委托给 OpenGL 而不是 HWC，以节省电量。当屏幕再次更新时，继续将合成分载到 HWC。
为常见用例做准备，如：

纵向和横向模式下的全屏游戏
带有字幕和播放控件的全屏视频
主屏幕（合成状态栏、系统栏、应用窗口和动态壁纸）
受保护的视频播放
多显示设备支持

这些用例应针对常规可预测的用途，而不是很少遇到的边缘用例（否则，优化将收效甚微）。实现必须平衡动画流畅性和交互延迟时间这两个相互矛盾的目标。

根据这些Google定义的这些准则，我们能够更好地分析配置硬件合成器的步骤。

准备工作

在分析setUpHWComposer函数之前，我们要回顾一下Android SurfaceFlinger 学习之路(五)—-VSync 工作原理中的硬件加载的部分，初始化显示设备和HWComposer设备的内容。

从上一部分得知，比如使用3D合成，需要大面积的像素混合计算和大量的内存传输（GPU读写GraphicBuffer所需），对GPU和DDR来说是一个巨大的负担。在GPU/DDR重度使用的场景（比如玩游戏），会造成发热、卡顿等。
为了提升性能，减少功耗，可以将合成这个过程交由另一个芯片完成，减轻GPU负担。进一步，直接让这个芯片连LCD，在LCD需要显示某一行时在线合成。
HwComposer便是这一个/多个专用合成芯片的驱动HAL层。
驱动由集成芯片系统的厂商自行设计，但需要遵循一定的标准，这个标准就是Android规定的HwComposer接口。

hwcomposer的接口定义位于此文件：
hardware/libhardware/include/hardware/hwcomposer.h
其中部分宏定义在：
hardware/libhardware/include/hardware/hwcomposer_defs.h

Layer

在SurfaceFlinger中，Layer对应于window表示一个Buffer循环体系，对HwComposer而言，Layer仅指代当前Buffer，也即SurfaceFlinger中的Layer的当前帧。

typedef struct hwc_layer_1 {
    int32_t compositionType;//合成类型，SurfaceFlinger将合成目标Framebuffer的合成类型设为HWC_FRAMEBUFFER_TARGET，其他hwcomposer在prepare时根据实际情况修改
    //在(*prepare)()调用前，需要复位HWC_BACKGROUND or HWC_FRAMEBUFFER，需要设置HWC_GEOMETRY_CHANGED的标志符，并在(*prepare)()过程中保持，
    /*
     * HWC_BACKGROUND：(*prepare)()调用前设置，表明这是个特殊的"background"的层，backgroundColor是无效的，HWC向HWC_FRAMEBUFFER切换此值，并表示无法使用backgroundColor。
     * HWC_FRAMEBUFFER_TARGET：在prepare前设置此值，此值表明此层是framebuffersurface层，作为OpenGLEScomposition的对象，如果HWC设置其他层为HWC_OVERLAY或则为HWC_BACKGROUND，则在set（）过程中opengles则什么都不干。
     * 此标志仅仅用在版本至少为HWC_DEVICE_API_VERSION_1_1，在老版本的过程中，OpenGLES target 与（dpy, sur)通信，在HWC实现的过程中此值不能设置。
     * 该Layer是3D合成的目标Layer
     * HWC_FRAMEBUFFER：在(*prepare)()调用前设置，仅仅在HWC_GEOMETRY_CHANGED flag 也在设置的时候设置，并表明此层将使用opengles画进framebuffer中。HWC可以切换此值到HWC_OVERLAY表明其将要管理此层。
     * hwcomposer无法处理此Layer，该Layer需要走3D合成流程，用OpenGL绘制
     * HWC_OVERLAY：在(*prepare)()过程中，通过HWC设置，表明此层由HWC设置，不能通过OpenGLES 合成。
     * 该Layer为硬件合成器所处理，不需要OpenGLES去渲染
     * HWC_SIDEBAND：在(*prepare)()前设置，此值表明此层的内容来自于边带视频流，此流在适当的时间（去同步多媒体流），与其他层当前内容进行合成，显示结果图片。此现象依赖于正常的prepare/set周期。prepare/set调用仅仅发生在其他层的改变，或则是边带视频流的位置或则大小的改变。
假如h/w composer 无法管理层由于边带视频流的原因（unsupportedscaling/blending/rotation, or too many sideband layers)，其可以在(*prepare)()设置合成类型为HWC_FRAMEBUFFER。但是，这样做显示维实体颜色，因为平台无法使用GPU进行合成边带视频层。这个问题在未来的平台版本中将得到改善。
     * 该Layer为视频的边频带，需要硬件合成器作特殊处理，若不支持，OpenGL方式只能以一个色块替代，这个标志是外界（应用/驱动）调用窗口系统的perform方法配置的
     * HWC_CURSOR_OVERLAY：在(*prepare)()期间，设置HWC实现，这个值意味着此层的合成将要被HWC的管理，另外，客户端在屏幕上可以异步刷新，这个层的位置可以使用setCursorPositionAsync() api。
     * 该Layer可通过setCursorPositionAsync 方法改变坐标
     */

    uint32_t hints;//hwcomposer设置，通知SurfaceFlinger需要修改的配置
    /*
    HWC_HINT_TRIPLE_BUFFER  = 0x00000001：表示需要SurfaceFlinger将此Layer改成3Buffer循环
    HWC_HINT_CLEAR_FB       = 0x00000002：要求SurfaceFlinger清空该Layer位置的FrameBuffer数据（即置0）
    */

    uint32_t flags;//SurfaceFlinger设置，hwcomposer作处理
    /*
    HWC_SKIP_LAYER = 0x00000001：此Layer不参与合成，应当忽略
    HWC_IS_CURSOR_LAYER = 0x00000002：此Layer建议设定为一个CURSOR_LAYER，hwcomposer能处理的话将其合成类型改为HWC_CURSOR_OVERLAY
    */

    /*该Layer的颜色/Buffer信息*/
    union {
        hwc_color_t backgroundColor;//背景颜色，适用于纯色Layer，hwc_color_t 为一个 argb 结构体

        struct {
            union {
                buffer_handle_t handle;//此即之间提到的GraphicBuffer
                const native_handle_t* sidebandStream;//HWC_SIDEBAND类型Layer的buffer
            };

            uint32_t transform;//该Layer所需要作的变换，具体为：
            /*
        HWC_TRANSFORM_FLIP_H = HAL_TRANSFORM_FLIP_H//水平翻转
        HWC_TRANSFORM_FLIP_V = HAL_TRANSFORM_FLIP_V//垂直翻转
        HWC_TRANSFORM_ROT_90 = HAL_TRANSFORM_ROT_90,//需要旋转90度
        HWC_TRANSFORM_ROT_180 = HAL_TRANSFORM_ROT_180,//需要旋转180度
        HWC_TRANSFORM_ROT_270 = HAL_TRANSFORM_ROT_270,//需要旋转270度
            */

            int32_t blending;//当前Layer绘制时，和底色/目标色的混合方式
            //HWC_BLENDING_NONE = 0x100：不混合，直接覆盖
            //HWC_BLENDING_PREMULT = 0x105：该Layer的颜色已经做过alpha预乘，因此混合方式为 src + (1-src.a)*dst
            //HWC_BLENDING_COVERAGE = 0x405：该Layer的颜色未做过预乘，按 src.a * src + (1-src.a) * dst 的方式混合

            union {
                // crop rectangle in integer (pre HWC_DEVICE_API_VERSION_1_3)
                hwc_rect_t sourceCropi;
                hwc_rect_t sourceCrop; // just for source compatibility
                // crop rectangle in floats (as of HWC_DEVICE_API_VERSION_1_3)
                hwc_frect_t sourceCropf;
            };//该Layer取哪一个区域进行合成

            hwc_rect_t displayFrame;//该Layer合成的目标区域

            hwc_region_t visibleRegionScreen;//该Layer的可见区域，该区域必然是displayFrame的子集。这个区域由SurfaceFlinger计算而得，用于提示hwcomposer不去合成该Layer的不可见区域，hwcomposer中应当以这个为基准，对应计算该Layer相应的sourcecrop。

            int acquireFenceFd;//由Buffer生产者创建，SurfaceFlinger传递进来，hwcomposer在使用该Layer的Buffer之前，需要等这个fence
            int releaseFenceFd;//由hwcomposer创建，生产者在使用该Buffer之前需要等此fence

            uint8_t planeAlpha;//整个Layer的alpha值，在取Layer的像素作运算之前，需要先乘 planeAlpha/255。

            /* Pad to 32 bits */
            uint8_t _pad[3];//用于结构体对齐，占位用

            hwc_region_t surfaceDamage;//记录相对上一次合成而言，发生了改变的source区域
        };
    };

//保留位，用于驱动层自行设计
#ifdef __LP64__
    uint8_t reserved[120 - 112];
#else
    uint8_t reserved[96 - 84];
#endif

} hwc_layer_1_t;

这里面最难理解和最易出错的是 SourceCrop、DisplayFrame和VisibleRegion，在处理SOC上的显示问题时，这往往是首先考虑的因素：

如图所示，该Layer的显示区域部分被L2完全挡住，source crop 为该Layer参与合成的范围，display frame 为该Layer合成的目标区域，visibleRegion为该Layer被挡住后，剩余的可见区域集。

这里我用了我的渣渣小米5，在Home页面，然后进入调试模式，输入adb shell dumpsys SurfaceFlinger ：

截取出这段信息，这段信息是SurfaceFlinger告知硬件合成器如何进行合成的。最后一个FramebufferTarget是目标层，不算进去，参与合成的图层是三个，分别是 :

com.android.systemui.ImageWallpaper
com.miui.home/com.miui.home.launcher.Launcher
StatusBar

其他参数对比我们上面的hwc_layer_1_t结构体，就能理解这些参数的意义。

Display

typedef struct hwc_display_contents_1 {
    /* hwcomposer设置，surfaceflinger去等的fence。对于物理屏(实际上是使用在线合成方式的物理屏），对于虚拟屏/离线合成，此fence在离线合成的目标buffer完成全部写入后解除。
     */
    int retireFenceFd;

    union {
        struct {
            /* HWC_DEVICE_VERSION_1_0 使用，dpy和sur对应于EGLDisplay 和 EGLSurface
             */
            hwc_display_t dpy;
            hwc_surface_t sur;
        };//HWC_DEVICE_VERSION_1_0

        struct {
            /*HWC_DEVICE_VERSION_1_3 之后支持 hwcomposer合成多屏，这里是指虚拟屏的输出buffer和对应的fence*/
            buffer_handle_t outbuf;
            int outbufAcquireFenceFd;
        };
    };

    /*合成该显示屏的所有Layer*/
    uint32_t flags;
    size_t numHwLayers;
    hwc_layer_1_t hwLayers[0];

} hwc_display_contents_1_t;

物理显示屏表示连接实际的显示仪器如LCD，目的是产生显示效果，可以使用在线合成。
虚拟显示屏表示目的是合成一个Buffer，不需要理会这个Buffer后续如何产生显示效果，这时需要把所有图层合成到指定的Buffer上。这种情况下必须离线合成。典型场景是手机连WFD/hdmi，手机合成好的Buffer通过wifi/hdmi传输到电视上显示。

Device

最后是device的函数指针定义

typedef struct hwc_composer_device_1 {
    struct hw_device_t common;
    //这种方式相当于C语言的继承实现，理解为 hwc_composer_device_1 继承于 hw_device_t 就可以了。
    //hw_device_t 包含一个基本信息 version（版本号），下面会提到

    /*对所有显示屏中所有Layer作合成准备（此时也可以开始发送合成的命令码下去，启动硬件合成，但不需要等待完成），hwcomposer需要正确汇报每个Layer的composetype，以告知SurfaceFlinger是否需要额外处理。
    version 为 1.0 的驱动，只支持一个显示屏
    version 为 1.1 的驱动，只支持物理显示屏
    version 为 1.3 及以上的驱动，支持物理和虚拟显示屏*/
    int (*prepare)(struct hwc_composer_device_1 *dev,
                    size_t numDisplays, hwc_display_contents_1_t** displays);

    /*此方法将完成各个图层的合成与显示，等效于EGL标准里面的eglSwapBuffers，不过eglSwapBuffers是对OpenGL标准/GPU有效，此方法是对硬件合成器有效*/
    int (*set)(struct hwc_composer_device_1 *dev,
                size_t numDisplays, hwc_display_contents_1_t** displays);

    /*这个接口一般只用于开启hwcomposer的vsync，在线合成触发vsync的机制较离线合成的设计会麻烦一些*/
    int (*eventControl)(struct hwc_composer_device_1* dev, int disp,
            int event, int enabled);

    //控制屏幕状态的方法
    union {
        /* HWC 1.3及之前版本，采用 blank 方式，开关某个显示屏 */
        int (*blank)(struct hwc_composer_device_1* dev, int disp, int blank);

        /* HWC 1.4及之后，提供更精细的 setPowerMode ，支持显示屏以较低功耗（但不关）的状态显示*/
        int (*setPowerMode)(struct hwc_composer_device_1* dev, int disp,
                int mode);
    };

    /*查询Hwcomposer的信息*/
    int (*query)(struct hwc_composer_device_1* dev, int what, int* value);

    /*注册
    *invalidate：屏幕刷新时触发
    *vsync：hwcomopser中的vsync事件产生时触发
    *hotplug：显示屏连接/断开时触发
    * 三个回调函数*/
    void (*registerProcs)(struct hwc_composer_device_1* dev,
            hwc_procs_t const* procs);

    /*打印信息，调试用*/
    void (*dump)(struct hwc_composer_device_1* dev, char *buff, int buff_len);

    /*获取显示屏配置、属性*/
    int (*getDisplayConfigs)(struct hwc_composer_device_1* dev, int disp,
            uint32_t* configs, size_t* numConfigs);
    int (*getDisplayAttributes)(struct hwc_composer_device_1* dev, int disp,
            uint32_t config, const uint32_t* attributes, int32_t* values);
    int (*getActiveConfig)(struct hwc_composer_device_1* dev, int disp);
    /*配置属性，index表示有效属性的编号*/
    int (*setActiveConfig)(struct hwc_composer_device_1* dev, int disp,
            int index);

    /*更改游标层的坐标*/
    int (*setCursorPositionAsync)(struct hwc_composer_device_1 *dev, int disp, int x_pos, int y_pos);

    /*自行添加的保留函数*/
    void* reserved_proc[1];

} hwc_composer_device_1_t;

实现

然后我们看看setUpHWComposer的实现。这个函数有点长，但是每个步骤都比较清晰，我们分步骤查看：

void SurfaceFlinger::setUpHWComposer() {
    for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {
        bool dirty = !mDisplays[dpy]->getDirtyRegion(false).isEmpty();
        bool empty = mDisplays[dpy]->getVisibleLayersSortedByZ().size() == 0;
        bool wasEmpty = !mDisplays[dpy]->lastCompositionHadVisibleLayers;

        // If nothing has changed (!dirty), don't recompose.
        // If something changed, but we don't currently have any visible layers,
        //   and didn't when we last did a composition, then skip it this time.
        // The second rule does two things:
        // - When all layers are removed from a display, we'll emit one black
        //   frame, then nothing more until we get new layers.
        // - When a display is created with a private layer stack, we won't
        //   emit any black frames until a layer is added to the layer stack.
        //如果没有改变（！dirty），不重新合成
        //如果有变化，但是当前没有可见的layers，并且上次合成过，那么这次跳过
        //有两个规则如下：
        //1.当所有的layers从显示屏移除，我们发射一个黑的frame，在来到新的layer之前都是黑的
        //2.当一个显示屏被创建时候带着一个私有的layer栈，我们直到新的layer被添加到这个layer stack时，
        //才发射黑的frame
        bool mustRecompose = dirty && !(empty && wasEmpty);

        ALOGV_IF(mDisplays[dpy]->getDisplayType() == DisplayDevice::DISPLAY_VIRTUAL,
                "dpy[%zu]: %s composition (%sdirty %sempty %swasEmpty)", dpy,
                mustRecompose ? "doing" : "skipping",
                dirty ? "+" : "-",
                empty ? "+" : "-",
                wasEmpty ? "+" : "-");
        //DisplayDevice的beginFrame函数，调用FrameBufferSurface的beginFrame函数，返回NO_ERROR
        mDisplays[dpy]->beginFrame(mustRecompose);

        if (mustRecompose) {
            mDisplays[dpy]->lastCompositionHadVisibleLayers = !empty;
        }
    }

这一步检查每个显示的dirty区域是否改变了，如果是就要Recompose。DisplayDevice的beginFrame函数，调用FrameBufferSurface的beginFrame函数，返回NO_ERROR。如果需要重新合成，将DisplayDevice的lastCompositionHadVisibleLayers标志只为true（！empty）。
这一步作用不大，可以忽略。

go on：

HWComposer& hwc(getHwComposer());  
    if (hwc.initCheck() == NO_ERROR) {  
        // build the h/w work list  
        if (CC_UNLIKELY(mHwWorkListDirty)) {  
            mHwWorkListDirty = false;  
            for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {//遍历mDisplays  
                sp<const DisplayDevice> hw(mDisplays[dpy]); 
                //以前我们讲过，这个id就是不同display的type，比如0，1，2 
                const int32_t id = hw->getHwcDisplayId();  
                if (id >= 0) {  
                    const Vector< sp<Layer> >& currentLayers(//遍历DisplayDevice所有可见layer  
                        hw->getVisibleLayersSortedByZ());  
                    const size_t count = currentLayers.size();  
                    if (hwc.createWorkList(id, count) == NO_ERROR) {//根据layer数量调用createWorkList创建hwc_layer_list_t列表  
                        HWComposer::LayerListIterator cur = hwc.begin(id);  
                        const HWComposer::LayerListIterator end = hwc.end(id);  
                        for (size_t i=0 ; cur!=end && i<count ; ++i, ++cur) {  
                            const sp<Layer>& layer(currentLayers[i]);
                            //设置HWC每一个帧hwc_layer_1_t的Geometry信息
                            //如transform/orientation/alpha等
                            layer->setGeometry(hw, *cur);  
                            if (mDebugDisableHWC || mDebugRegion || mDaltonize || mHasColorMatrix) {  
                                cur->setSkip(true);  
                            }  
                        }  
                    }  
                }  
            }  
        }

这一步主要工作有：
1）遍历mDisplays，在所有显示屏信息中，遍历DisplayDevice所有可见layer；
2）根据layer数量调用createWorkList创建hwc_layer_list_t列表；
3）设置HWC每一个帧hwc_layer_1_t的Geometry信息，如transform/orientation/alpha等。

我们先来看下HWComposer的createWorkList函数实现：

status_t HWComposer::createWorkList(int32_t id, size_t numLayers) {
    if (uint32_t(id)>31 || !mAllocatedDisplayIDs.hasBit(id)) {
        return BAD_INDEX;
    }

    if (mHwc) {
        DisplayData& disp(mDisplayData[id]);
        if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1)) {
            // we need space for the HWC_FRAMEBUFFER_TARGET
            //当支持Open GL合成时候，会把numLayer数目+1，
            //这个多余的1就是合成目标HWC_FRAMEBUFFER_TARGET
            //之前从dumpsys SurfaceFlinger中能看到最后一个是HWC_FRAMEBUFFER_TARGET
            numLayers++;
        }
        ////当DisplayData中的list为空，我们就要malloc  
        if (disp.capacity < numLayers || disp.list == NULL) {
            //整个申请内存长度，hwc_display_contents_1_t结构体本身的长度加上后面hwc_layer_1_t个数的长度  
            size_t size = sizeof(hwc_display_contents_1_t)
                    + numLayers * sizeof(hwc_layer_1_t);
            free(disp.list);
            disp.list = (hwc_display_contents_1_t*)malloc(size);
            disp.capacity = numLayers;
        }
        if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1)) {
            disp.framebufferTarget = &disp.list->hwLayers[numLayers - 1];
            //DisplayData的framebufferTarget清0 
            memset(disp.framebufferTarget, 0, sizeof(hwc_layer_1_t));
            const DisplayConfig& currentConfig =
                    disp.configs[disp.currentConfig];
            const hwc_rect_t r = { 0, 0,
                    (int) currentConfig.width, (int) currentConfig.height };
            disp.framebufferTarget->compositionType = HWC_FRAMEBUFFER_TARGET;
            disp.framebufferTarget->hints = 0;
            disp.framebufferTarget->flags = 0;
            disp.framebufferTarget->handle = disp.fbTargetHandle;
            disp.framebufferTarget->transform = 0;
            disp.framebufferTarget->blending = HWC_BLENDING_PREMULT;
            //framebufferTarget的sourceCrop初始化
            if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_3)) {
                disp.framebufferTarget->sourceCropf.left = 0;
                disp.framebufferTarget->sourceCropf.top = 0;
                disp.framebufferTarget->sourceCropf.right =
                        currentConfig.width;
                disp.framebufferTarget->sourceCropf.bottom =
                        currentConfig.height;
            } else {
                disp.framebufferTarget->sourceCrop = r;
            }
            //framebufferTarget的displayFrame初始化
            disp.framebufferTarget->displayFrame = r;
            disp.framebufferTarget->visibleRegionScreen.numRects = 1;
            disp.framebufferTarget->visibleRegionScreen.rects =
                &disp.framebufferTarget->displayFrame;
            disp.framebufferTarget->acquireFenceFd = -1;
            disp.framebufferTarget->releaseFenceFd = -1;
            disp.framebufferTarget->planeAlpha = 0xFF;
        }
        disp.list->retireFenceFd = -1;
        disp.list->flags = HWC_GEOMETRY_CHANGED;
        disp.list->numHwLayers = numLayers;
    }
    return NO_ERROR;
}

当支持Open GL合成时候，会把numLayer数目+1，这个多余的1就是合成目标HWC_FRAMEBUFFER_TARGET，之前从dumpsys SurfaceFlinger中能看到最后一个是HWC_FRAMEBUFFER_TARGET。
然后就是为DisplayData的list申请内存，这个内存要先hwc_display_contents_1_t结构体本身的长度加上后面hwc_layer_1_t个数的长度。
后面用DisplayData中list中hwLayers最后一个作为DisplayData中的framebufferTarget。
最后就是framebufferTarget的一些初始化操作。

关于DisplayData结构体，可以回顾Android SurfaceFlinger 学习之路(五)—-VSync 工作原理中的硬件加载的部分，初始化显示设备和HWComposer设备的内容，这里先贴出来结构体内容：

struct DisplayData {  
    DisplayData();  
    ~DisplayData();  
    Vector<DisplayConfig> configs;  
    size_t currentConfig;  
    uint32_t format;    // pixel format from FB hal, for pre-hwc-1.1  
    bool connected;  
    bool hasFbComp;  
    bool hasOvComp;  
    size_t capacity;  
    //上面构造Worklist，并且给DisplayData:list 申请空间
    hwc_display_contents_1* list;  
    //DisplayData中list中hwLayers最后一个作为DisplayData中的framebufferTarget
    hwc_layer_1* framebufferTarget;  
    buffer_handle_t fbTargetHandle;  
    sp<Fence> lastRetireFence;  // signals when the last set op retires  
    sp<Fence> lastDisplayFence; // signals when the last set op takes  
                                // effect on screen  
    buffer_handle_t outbufHandle;  
    sp<Fence> outbufAcquireFence;  
  
    // protected by mEventControlLock  
    int32_t events;  
};

DisplayData 结构体的成员list是一个hwc_display_contents_1指针，这个hwc_display_contents_1结构体我们上面讲过。里面有个联合体union，联合体里面又有两个结构体。

第一个结构体是HWC_DEVICE_VERSION_1_0 使用，dpy和sur对应于EGLDisplay 和 EGLSurface，这是EGL使用的
第二个结构体是HWC_DEVICE_VERSION_1_3 之后支持 hwcomposer合成多屏，这里是指虚拟屏的输出buffer和对应的fence

hwc_display_contents_1后面成员保存了后面还保存了layer的个数和hwc_layer_1_t 数组的起始地址hwLayers[0]。

DisplayData 结构体的成员framebufferTarget是一个hwc_layer_1指针，这个hwc_layer_1我们上面也贴出来了。相关成员可以参考上面的内容，包括上面提到的 SourceCrop、DisplayFrame和VisibleRegion。其主要数据在buffer_handle_t handle中，buffer_handle_t 其实就是native_handle_t之前分析过，里面有共享内存的fd和地址。关于buffer_handle_t可以回顾之前申请GraphicBuffer的内容。

然后就是设置HWC每一个帧hwc_layer_1_t的Geometry信息，如transform/orientation/alpha等。不过这之前我们要先看看HWComposer的begin和end函数，还有相关类或者结构体。

先看下HWComposer中的begin函数：

HWComposer::LayerListIterator HWComposer::begin(int32_t id) {
    return getLayerIterator(id, 0);
}

HWComposer::LayerListIterator HWComposer::getLayerIterator(int32_t id, size_t index) {
    if (uint32_t(id)>31 || !mAllocatedDisplayIDs.hasBit(id)) {//pass
        return LayerListIterator();
    }
    const DisplayData& disp(mDisplayData[id]);
    if (!mHwc || !disp.list || index > disp.list->numHwLayers) {//pass
        return LayerListIterator();
    }
    //go to
    return LayerListIterator(new HWCLayerVersion1(mHwc, disp.list->hwLayers), index);
}

这里不走前两个if，最后新建一个LayerListIterator对象，构造函数中传入HWCLayerVersion1对象，和index，为0。我们贴出来LayerListIterator类结构：


/*
 * Iterator through a HWCLayer list.
 * This behaves more or less like a forward iterator.
 */
class LayerListIterator {
    friend struct HWComposer;
    HWCLayer* const mLayerList;
    size_t mIndex;

    LayerListIterator() : mLayerList(NULL), mIndex(0) { }

    LayerListIterator(HWCLayer* layer, size_t index)
        : mLayerList(layer), mIndex(index) { }

    // we don't allow assignment, because we don't need it for now
    LayerListIterator& operator = (const LayerListIterator& rhs);

public:
    // copy operators
    LayerListIterator(const LayerListIterator& rhs)
        : mLayerList(HWCLayer::copy(rhs.mLayerList)), mIndex(rhs.mIndex) {
    }

    ~LayerListIterator() { delete mLayerList; }

    // pre-increment
    LayerListIterator& operator++() {
        mLayerList->setLayer(++mIndex);
        return *this;
    }

    // dereference
    HWCLayerInterface& operator * () { return *mLayerList; }
    HWCLayerInterface* operator -> () { return mLayerList; }

    // comparison
    bool operator == (const LayerListIterator& rhs) const {
        return mIndex == rhs.mIndex;
    }
    bool operator != (const LayerListIterator& rhs) const {
        return !operator==(rhs);
    }
};

这里要留意一下后面几个运算符重载，后面会用到。
这里面HWCLayerVersion1就是mLayerList， index就是mIndex。HWCLayerVersion1的结构如下：

/*
 * Concrete implementation of HWCLayer for HWC_DEVICE_API_VERSION_1_0.
 * This implements the HWCLayer side of HWCIterableLayer.
 */
class HWCLayerVersion1 : public Iterable<HWCLayerVersion1, hwc_layer_1_t> {
    struct hwc_composer_device_1* mHwc;
public:
    HWCLayerVersion1(struct hwc_composer_device_1* hwc, hwc_layer_1_t* layer)
        : Iterable<HWCLayerVersion1, hwc_layer_1_t>(layer), mHwc(hwc) { }

//ignore

构造函数中传入了mHwc和disp.list->hwLayers，就是HWC Device HAL层指针和上面我们分析的合成该显示屏的所有Layer。

而我们再来看看下HWComposer中的end函数：

HWComposer::LayerListIterator HWComposer::end(int32_t id) {
    size_t numLayers = 0;
    if (uint32_t(id) <= 31 && mAllocatedDisplayIDs.hasBit(id)) {
        const DisplayData& disp(mDisplayData[id]);
        if (mHwc && disp.list) {
            numLayers = disp.list->numHwLayers;//获取到list中laye的个数  
            if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1)) {
                // with HWC 1.1, the last layer is always the HWC_FRAMEBUFFER_TARGET,
                // which we ignore when iterating through the layer list.
                ALOGE_IF(!numLayers, "mDisplayData[%d].list->numHwLayers is 0", id);
                if (numLayers) {
                    numLayers--;//变成最后一个用于合成的layer，因为本来最后一个是HWC_FRAMEBUFFER_TARGET
                }
            }
        }
    }
    return getLayerIterator(id, numLayers);//和上面一样，只是传入的index不一样。
}

end函数和begin很像只是在调用getLayerIterator的时候，begin传入0，end传入layer的最后一位，变成最后一个用于合成的layer，因为本来最后一个是HWC_FRAMEBUFFER_TARGET。最后就是mIndex成员变量不一样。

接着我们回到上面setUpHWComposer函数，第二部第三个步骤，layer->setGeometry(hw, （星号，解引用，MD语法转义了这个符号）cur);这里layer是Layer对象，hw是DisplayDevice对象，cur是HWComposer::LayerListIterator对象。我们上面强调了一定要注意LayerListIterator类内部的运算符重载，这里用到了（星号，解引用，MD语法转义了这个符号）运算符：

1	HWCLayerInterface& operator * () { return *mLayerList; }

而上面的mLayerList就是HWCLayerVersion1对象。所以我们继续查看Layer的setGeometry函数：

void Layer::setGeometry(
    const sp<const DisplayDevice>& hw,
        HWComposer::HWCLayerInterface& layer)
{
    layer.setDefaultState();

    // enable this layer
    layer.setSkip(false);
    //受安全保护的layer，不可以在进程间传入，所以合成时候跳过
    if (isSecure() && !hw->isSecure()) {
        layer.setSkip(true);
    }

    // this gives us only the "orientation" component of the transform
    const State& s(getDrawingState());
    //半透明颜色处理
    if (!isOpaque(s) || s.alpha != 0xFF) {
        layer.setBlending(mPremultipliedAlpha ?
                HWC_BLENDING_PREMULT :
                HWC_BLENDING_COVERAGE);
    }

    // apply the layer's transform, followed by the display's global transform
    // here we're guaranteed that the layer's transform preserves rects
    //处理displayFrame，sourceCrop，还有透明度
    Rect frame(s.transform.transform(computeBounds()));
    frame.intersect(hw->getViewport(), &frame);
    const Transform& tr(hw->getTransform());
    layer.setFrame(tr.transform(frame));
    layer.setCrop(computeCrop(hw));
    layer.setPlaneAlpha(s.alpha);

    /*
     * Transformations are applied in this order:
     * 1) buffer orientation/flip/mirror
     * 2) state transformation (window manager)
     * 3) layer orientation (screen orientation)
     * (NOTE: the matrices are multiplied in reverse order)
     */

    const Transform bufferOrientation(mCurrentTransform);
    Transform transform(tr * s.transform * bufferOrientation);
    //如果这个图形缓冲区之前曾经被旋转过，例如，被水平翻转或者垂直翻转过，那么在对它进行合并之前，还需要将它的旋转方向恢复回来。
    if (mSurfaceFlingerConsumer->getTransformToDisplayInverse()) {
        /*
         * the code below applies the display's inverse transform to the buffer
         */
        uint32_t invTransform = hw->getOrientationTransform();
        uint32_t t_orientation = transform.getOrientation();
        // calculate the inverse transform
        if (invTransform & NATIVE_WINDOW_TRANSFORM_ROT_90) {
            invTransform ^= NATIVE_WINDOW_TRANSFORM_FLIP_V |
                    NATIVE_WINDOW_TRANSFORM_FLIP_H;
            // If the transform has been rotated the axis of flip has been swapped
            // so we need to swap which flip operations we are performing
            bool is_h_flipped = (t_orientation & NATIVE_WINDOW_TRANSFORM_FLIP_H) != 0;
            bool is_v_flipped = (t_orientation & NATIVE_WINDOW_TRANSFORM_FLIP_V) != 0;
            if (is_h_flipped != is_v_flipped) {
                t_orientation ^= NATIVE_WINDOW_TRANSFORM_FLIP_V |
                        NATIVE_WINDOW_TRANSFORM_FLIP_H;
            }
        }
        // and apply to the current transform
        transform = Transform(t_orientation) * Transform(invTransform);
    }

    // this gives us only the "orientation" component of the transform
    const uint32_t orientation = transform.getOrientation();
    if (orientation & Transform::ROT_INVALID) {
        // we can only handle simple transformation
        layer.setSkip(true);
    } else {
        layer.setTransform(orientation);
    }
}

上面就是设置Layer的Geometry信息：
1）受安全保护的layer，不可以在进程间传入，所以合成时候跳过。界面受到安全保护的应用程序窗口的内容是不可以在进程间传输的，这个属性主要是应用在屏幕截图中。例如，如果系统中存在一个界面受到安全保护的应用程序窗口，那么我们就不可以请求SurfaceFlinger服务执行截屏功能，因为SurfaceFlinger服务截取下来的屏幕会被传输给请求的进程使用。
2）处理displayFrame，sourceCrop，还有透明度。
3）如果这个图形缓冲区之前曾经被旋转过，例如，被水平翻转或者垂直翻转过，那么在对它进行合并之前，还需要将它的旋转方向恢复回来。

这样我们setUpHWComposer第二部就完了，go on：


// set the per-frame data
for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {
    sp<const DisplayDevice> hw(mDisplays[dpy]);
    const int32_t id = hw->getHwcDisplayId();
    if (id >= 0) {
        const Vector< sp<Layer> >& currentLayers(
            hw->getVisibleLayersSortedByZ());
        const size_t count = currentLayers.size();
        HWComposer::LayerListIterator cur = hwc.begin(id);
        const HWComposer::LayerListIterator end = hwc.end(id);
        for (size_t i=0 ; cur!=end && i<count ; ++i, ++cur) {
            /*
             * update the per-frame h/w composer data for each layer
             * and build the transparent region of the FB
             */
             //将layer的mActiveBuffer设置到HWComposer中去  
            const sp<Layer>& layer(currentLayers[i]);
            layer->setPerFrameData(hw, *cur);
        }
    }
}

有了上面的基础，我们先留意上面强调过，注意LayerListIterator类内部的运算符重载，这里需要用到的是++的重载：

LayerListIterator& operator++() {  
    mLayerList->setLayer(++mIndex);  
    return *this;  
}  
virtual status_t setLayer(size_t index) {  
    mCurrentLayer = &mLayerList[index];  
    return NO_ERROR;  
}

会调用mLayerList->setLayer函数,setLayer会从mLayerList中设置当前的mCurrentLayer，通过mLayerList, 这个变量就是disp.list->hwLayers。
这样准备工作就好了，我们再来分析Layer的setPerFrameData函数：


void Layer::setPerFrameData(const sp<const DisplayDevice>& hw,
        HWComposer::HWCLayerInterface& layer) {
    // we have to set the visible region on every frame because
    // we currently free it during onLayerDisplayed(), which is called
    // after HWComposer::commit() -- every frame.
    // Apply this display's projection's viewport to the visible region
    // before giving it to the HWC HAL.
    const Transform& tr = hw->getTransform();
    Region visible = tr.transform(visibleRegion.intersect(hw->getViewport()));
    layer.setVisibleRegionScreen(visible);

    if (mSidebandStream.get()) {
        layer.setSidebandStream(mSidebandStream);
    } else {
        // NOTE: buffer can be NULL if the client never drew into this
        // layer yet, or if we ran out of memory
        layer.setBuffer(mActiveBuffer);
    }
}

主要就是调用了HWCLayerVersion1的setBuffer函数:

virtual void setBuffer(const sp<GraphicBuffer>& buffer) {
       if (buffer == 0 || buffer->handle == 0) {
           getLayer()->compositionType = HWC_FRAMEBUFFER;
           getLayer()->flags |= HWC_SKIP_LAYER;
           getLayer()->handle = 0;
       } else {
           if (getLayer()->compositionType == HWC_SIDEBAND) {
               // If this was a sideband layer but the stream was removed, reset
               // it to FRAMEBUFFER. The HWC can change it to OVERLAY in prepare.
               getLayer()->compositionType = HWC_FRAMEBUFFER;
           }
           getLayer()->handle = buffer->handle;
       }
   }
   //
   inline HWCTYPE* getLayer() { return mCurrentLayer; }

用getLayer函数设置其handle，而getLayer就是mCurrentLayer。之前mCurrentLayer会一个个遍历各个Layer,这样就把所有的layer都设置其handle，就是hwc_layer_1_t中的handle。这样就把GraphicBuffer和hwc_layer_1_t关联起来了。

go on：ignore // If possible, attempt to use the cursor overlay on each display.
go on：

 //将使用哪种合成报告给HWC
 status_t err = hwc.prepare();
        ALOGE_IF(err, "HWComposer::prepare failed (%s)", strerror(-err));

        for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {
            sp<const DisplayDevice> hw(mDisplays[dpy]);
            //return NO_ERROR
            hw->prepareFrame(hwc);
        }
    }
}

最后会调用HWComposer的prepare函数，将使用哪种合成报告给HWC，我们再来看下这个函数：

status_t HWComposer::prepare() {
    for (size_t i=0 ; i<mNumDisplays ; i++) {
        DisplayData& disp(mDisplayData[i]);
        if (disp.framebufferTarget) {//这里其实就是disp.list中最后一个layer 
            // make sure to reset the type to HWC_FRAMEBUFFER_TARGET
            // DO NOT reset the handle field to NULL, because it's possible
            // that we have nothing to redraw (eg: eglSwapBuffers() not called)
            // in which case, we should continue to use the same buffer.
            LOG_FATAL_IF(disp.list == NULL);
            disp.framebufferTarget->compositionType = HWC_FRAMEBUFFER_TARGET;
        }
        if (!disp.connected && disp.list != NULL) {
            ALOGW("WARNING: disp %zu: connected, non-null list, layers=%zu",
                  i, disp.list->numHwLayers);
        }
        mLists[i] = disp.list;//DisplayData的list就是mList的一个组员,hwc_display_contents_1* 
        if (mLists[i]) {
            //HWC_DEVICE_VERSION_1_3 之后支持 hwcomposer合成多屏，这里是指虚拟屏的输出buffer和对应的fence
            if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_3)) {
                mLists[i]->outbuf = disp.outbufHandle;
                mLists[i]->outbufAcquireFenceFd = -1;
            } else if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1)) {// HWC_DEVICE_VERSION_1_0 使用，dpy和sur对应于EGLDisplay 和 EGLSurface
                // garbage data to catch improper use
                mLists[i]->dpy = (hwc_display_t)0xDEADBEEF;
                mLists[i]->sur = (hwc_surface_t)0xDEADBEEF;
            } else {
                mLists[i]->dpy = EGL_NO_DISPLAY;
                mLists[i]->sur = EGL_NO_SURFACE;
            }
        }
    }
     /*对所有显示屏中所有Layer作合成准备（此时也可以开始发送合成的命令码下去，启动硬件合成，但不需要等待完成），hwcomposer需要正确汇报每个Layer的composetype，以告知SurfaceFlinger是否需要额外处理。
    version 为 1.0 的驱动，只支持一个显示屏
    version 为 1.1 的驱动，只支持物理显示屏
    version 为 1.3 及以上的驱动，支持物理和虚拟显示屏*/
    int err = mHwc->prepare(mHwc, mNumDisplays, mLists);
    ALOGE_IF(err, "HWComposer: prepare failed (%s)", strerror(-err));

    if (err == NO_ERROR) {
        // here we're just making sure that "skip" layers are set
        // to HWC_FRAMEBUFFER and we're also counting how many layers
        // we have of each type.
        //
        // If there are no window layers, we treat the display has having FB
        // composition, because SurfaceFlinger will use GLES to draw the
        // wormhole region.
        for (size_t i=0 ; i<mNumDisplays ; i++) {
            DisplayData& disp(mDisplayData[i]);
            disp.hasFbComp = false;
            disp.hasOvComp = false;
            if (disp.list) {
                //下面就是根据hwc汇报的composetype来设置相关属性
                for (size_t i=0 ; i<disp.list->numHwLayers ; i++) {
                    hwc_layer_1_t& l = disp.list->hwLayers[i];

                    //ALOGD("prepare: %d, type=%d, handle=%p",
                    //        i, l.compositionType, l.handle);

                    if (l.flags & HWC_SKIP_LAYER) {
                        l.compositionType = HWC_FRAMEBUFFER;
                    }
                    if (l.compositionType == HWC_FRAMEBUFFER) {
                        disp.hasFbComp = true;
                    }
                    if (l.compositionType == HWC_OVERLAY) {
                        disp.hasOvComp = true;
                    }
                    if (l.compositionType == HWC_CURSOR_OVERLAY) {
                        disp.hasOvComp = true;
                    }
                }
                if (disp.list->numHwLayers == (disp.framebufferTarget ? 1 : 0)) {
                    disp.hasFbComp = true;
                }
            } else {
                disp.hasFbComp = true;
            }
        }
    }
    return (status_t)err;
}

1）遍历每一个显示屏，先取出framebufferTarget进行设置；
2）填充mList，DisplayData的list就是mList的一个组员,hwc_display_contents_1*，上面createWorkList讲过；
3）根据hwc版本初始化dpy和surface，或者outbuf；
4）调用hwc_composer_device_1 的set函数，对所有显示屏中所有Layer作合成准备（此时也可以开始发送合成的命令码下去，启动硬件合成，但不需要等待完成），hwcomposer需要正确汇报每个Layer的composetype，以告知SurfaceFlinger是否需要额外处理。
5）下面就是根据hwc汇报的composetype来设置相关属性，关于不同type再次贴一遍：

/*
    * HWC_FRAMEBUFFER_TARGET：该Layer是3D合成的目标Layer
    * HWC_FRAMEBUFFER：hwcomposer无法处理此Layer，该Layer需要走3D合成流程，用OpenGL绘制
    * HWC_OVERLAY：该Layer为硬件合成器所处理，不需要OpenGLES去渲染
    * HWC_SIDEBAND：该Layer为视频的边频带，需要硬件合成器作特殊处理，若不支持，OpenGL方式只能以一个色块替代，这个标志是外界（应用/驱动）调用窗口系统的perform方法配置的
    * HWC_CURSOR_OVERLAY：该Layer可通过setCursorPositionAsync 方法改变坐标
    */

这就是最后一步，提交hwc，然后获得合成类型的步骤。

小结

这就是本节内容，太晚了，不想写总结了，先睡了~

Android SurfaceFlinger 学习之路(十)----SurfaceFlinger处理Layer更新

2017-11-09T09:11:11.000Z

上次我们分析了SurfaceFlinger的事务处理，对合成前接受上层改变SF和Layer的状态的事务做了统一处理，这节就沿着上次的末尾，继续分析Layer的更新流程。（又断了很久了，实在惭愧，很多事情总是身不由己～）

更新Layer Buffer

前几节分析Vsync信号还没有分析完，这一节顺着处理事务的尾巴，处理Layer中Buffer的更新。顺着代码走的，就到了SurfaceFlinger的handlePageFlip函数。

handlePageFlip函数

page flip是翻页的意思，就是说翻过所有的页面，检查每个Layer的更新。依然位于frameworks/native/serivice/surfaceflinger/SurfaceFlinger.cpp中：

void SurfaceFlinger::handlePageFlip()
{
    Region dirtyRegion;

    bool visibleRegions = false;
    const LayerVector& layers(mDrawingState.layersSortedByZ);

    // Store the set of layers that need updates. This set must not change as
    // buffers are being latched, as this could result in a deadlock.
    // Example: Two producers share the same command stream and:
    // 1.) Layer 0 is latched
    // 2.) Layer 0 gets a new frame
    // 2.) Layer 1 gets a new frame
    // 3.) Layer 1 is latched.
    // Display is now waiting on Layer 1's frame, which is behind layer 0's
    // second frame. But layer 0's second frame could be waiting on display.
    Vector<Layer*> layersWithQueuedFrames;
    //检查Layer是否需要更新
    for (size_t i = 0, count = layers.size(); i<count ; i++) {
        const sp<Layer>& layer(layers[i]);
        //该Layer是否有 QUEUED buffer，上上一篇讲过，
        //每当有queued buffer，Layer的onFrameAvailable函数会回调，然后将mQueuedFrames加1
        if (layer->hasQueuedFrame())
            //将需要更新的Layer存入这个数组
            layersWithQueuedFrames.push_back(layer.get());
    }
    //遍历每一个需要更新的Layer，
    //调用Layer的latchBuffer函数计算Layer的脏区域，
    //最后修改Layer所在的Display上的脏区域
    for (size_t i = 0, count = layersWithQueuedFrames.size() ; i<count ; i++) {
        Layer* layer = layersWithQueuedFrames[i];
        const Region dirty(layer->latchBuffer(visibleRegions));
        const Layer::State& s(layer->getDrawingState());
        invalidateLayerStack(s.layerStack, dirty);
    }

    mVisibleRegionsDirty |= visibleRegions;
}

只看这个函数还是挺简单的：
1）检查每个Layer，找出需要更新Layer的，并存入数组。我们在Android SurfaceFlinger 学习之路(八)—-Surface管理图形缓冲区中讲过，当把Graphic Buffer 在app侧绘制完后会queue给BufferQueue，此时buffer状态为QUEUED，同时会通知Layer的onFrameAvailable回调去通知SF消费。Layer的onFrameAvailable函数如下，位于rameworks/native/services/surfaceflinger/Layer.cpp：

void Layer::onFrameAvailable() {
    android_atomic_inc(&mQueuedFrames);//会将mQueuedFrames加1
    mFlinger->signalLayerUpdate();
}

相应的Layer的hasQueuedFrame函数位于frameworks/native/services/surfaceflinger/Layer.h中：

/*
 * Returns if a frame is queued.
 */
bool hasQueuedFrame() const { return mQueuedFrames > 0 || mSidebandStreamChanged; }

因此可以找出需要更新的Layer，然后存入layersWithQueuedFrames这个数组中。

2）遍历每一个需要更新的Layer，用Layer的latchBuffer函数计算Layer的脏区域。这一步是核心，我们接下来会仔细分析。

3）最后修改Layer所在的Display上的脏区域。这一步调用了invalidateLayerStack函数：

void SurfaceFlinger::invalidateLayerStack(uint32_t layerStack,
        const Region& dirty) {
    for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {
        const sp<DisplayDevice>& hw(mDisplays[dpy]);
        if (hw->getLayerStack() == layerStack) {
            hw->dirtyRegion.orSelf(dirty);
        }
    }
}

先遍历所有的设备，然后找到和Layer的layerstack一样的设备，然后通过“或“运算，将Layer的更新区域加到DisplayDevice的dirtyRegion区域上。

所以这个函数的核心就是Layer的latchBuffer函数调用，计算需要更新的苍区域。

计算Layer的脏区域

latchBuffer函数比较长，我们分部查看：

Part.1 处理SidebandStream

Region Layer::latchBuffer(bool& recomputeVisibleRegions)
{
    ATRACE_CALL();
    //如果sideband surface改变了，表该Layer为视频的边频带，需要硬件合成器作特殊处理，
    //然后将 mSidebandStreamChanged置为false
    if (android_atomic_acquire_cas(true, false, &mSidebandStreamChanged) == 0) {
        // mSidebandStreamChanged was true
        mSidebandStream = mSurfaceFlingerConsumer->getSidebandStream();
        // sideband的情况，需要重新 计算可视区域
        recomputeVisibleRegions = true;

        const State& s(getDrawingState());
        return s.transform.transform(Region(Rect(s.active.w, s.active.h)));
    }

    Region outDirtyRegion;
    //如果Layer中有QUEUED帧
    if (mQueuedFrames > 0) {

        // if we've already called updateTexImage() without going through
        // a composition step, we have to skip this layer at this point
        // because we cannot call updateTeximage() without a corresponding
        // compositionComplete() call.
        // we'll trigger an update in onPreComposition().
        if (mRefreshPending) {
            return outDirtyRegion;
        }

        // Capture the old state of the layer for comparisons later
        //注意这里使用的是DrawingState
        const State& s(getDrawingState());
        const bool oldOpacity = isOpaque(s);
        sp<GraphicBuffer> oldActiveBuffer = mActiveBuffer;

        //。。。。。。

}

这一部分处理了如果是sidebandstream的逻辑，该Layer为视频的边频带，需要硬件合成器作特殊处理，若不支持，OpenGL方式只能以一个色块替代，这个标志是外界（应用/驱动）调用窗口系统的perform方法配置的。

Part.2 定义Reject结构体

struct Reject : public SurfaceFlingerConsumer::BufferRejecter {
            Layer::State& front;//drawingState
            Layer::State& current;//currentState
            bool& recomputeVisibleRegions;
            bool stickyTransformSet;
            Reject(Layer::State& front, Layer::State& current,
                    bool& recomputeVisibleRegions, bool stickySet)
                : front(front), current(current),
                  recomputeVisibleRegions(recomputeVisibleRegions),
                  stickyTransformSet(stickySet) {
            }

            virtual bool reject(const sp<GraphicBuffer>& buf,
                    const IGraphicBufferConsumer::BufferItem& item) {
                if (buf == NULL) {
                    return false;
                }

                uint32_t bufWidth  = buf->getWidth();
                uint32_t bufHeight = buf->getHeight();

                // check that we received a buffer of the right size
                // (Take the buffer's orientation into account)
                //旋转90度
                if (item.mTransform & Transform::ROT_90) {
                    swap(bufWidth, bufHeight);
                }

                bool isFixedSize = item.mScalingMode != NATIVE_WINDOW_SCALING_MODE_FREEZE;
                if (front.active != front.requested) {
                    //当app请求SF分配图形缓冲区时候，会传入requestWidth和requestHeight
                    //如果请求的w和h为0，则isFixedSize为true，此时就要用窗口的大小
                    //或者请求的w／h和传入的buffer的w／h相等
                    if (isFixedSize ||
                            (bufWidth == front.requested.w &&
                             bufHeight == front.requested.h))
                    {
                        // Here we pretend the transaction happened by updating the
                        // current and drawing states. Drawing state is only accessed
                        // in this thread, no need to have it locked
                        //我们假设事务已经提交更新了，current已经赋值给drawing，
                        //所以我们不用再去给DrawingState加锁
                        //将request的Geometry区域赋值给active
                        front.active = front.requested;

                        // We also need to update the current state so that
                        // we don't end-up overwriting the drawing state with
                        // this stale current state during the next transaction
                        //
                        // NOTE: We don't need to hold the transaction lock here
                        // because State::active is only accessed from this thread.
                        //下一次事务提交更新时候，还会讲下一次的current与drawing交换赋值，
                        //所以本次我们这里不终止用对这次drawing state对current的覆盖
                        current.active = front.active;

                        // recompute visible region
                        //重新计算可视区域
                        recomputeVisibleRegions = true;
                    }

                    //打印些许log
                //如果传入了请求的w／h，并且不是粘性的（往后一直遗留的）转换    
                if (!isFixedSize && !stickyTransformSet) {
                    //但是请求的w/h和传入buffer的w/hb不一致
                    //那么就需要拒绝掉这个buffer
                    if (front.active.w != bufWidth ||
                        front.active.h != bufHeight) {
                        // reject this buffer
                        ALOGE("rejecting buffer: bufWidth=%d, bufHeight=%d, front.active.{w=%d, h=%d}",
                                bufWidth, bufHeight, front.active.w, front.active.h);
                        return true;
                    }
                }

                // if the transparent region has changed (this test is
                // conservative, but that's fine, worst case we're doing
                // a bit of extra work), we latch the new one and we
                // trigger a visible-region recompute.
                //如果透明区域也改变了，也需要更新current的透明区域region，原因同上
                if (!front.activeTransparentRegion.isTriviallyEqual(
                        front.requestedTransparentRegion)) {
                    front.activeTransparentRegion = front.requestedTransparentRegion;

                    // We also need to update the current state so that
                    // we don't end-up overwriting the drawing state with
                    // this stale current state during the next transaction
                    //
                    // NOTE: We don't need to hold the transaction lock here
                    // because State::active is only accessed from this thread.
                    current.activeTransparentRegion = front.activeTransparentRegion;

                    // recompute visible region
                    //重新计算可视区域
                    recomputeVisibleRegions = true;
                }

                return false;
            }
        };

Reject结构体的定义，reject方法判断是否拒绝掉传入的buffer，详细都在注释中写道。
核心就是如果请求的w／h和传入buffer的w／h不一致，就会拒绝掉这个buffer。
如果不拒绝，就更新current和drawing的状态，方便下一次transation处理状态更新，左后将recomputeVisibleRegions置为true，表示重新计算可视区域。

Part.3 更新纹理并处理结果

//创建一个Reject对象
Reject r(mDrawingState, getCurrentState(), recomputeVisibleRegions,
                getProducerStickyTransform() != 0);
        //更新纹理
        status_t updateResult = mSurfaceFlingerConsumer->updateTexImage(&r,
                mFlinger->mPrimaryDispSync);
        //延迟显示        
        if (updateResult == BufferQueue::PRESENT_LATER) {
            // Producer doesn't want buffer to be displayed yet.  Signal a
            // layer update so we check again at the next opportunity.
            //延迟显示，触发下一个VSYNC， 即Buffer显示的时间还没到
            mFlinger->signalLayerUpdate();
            return outDirtyRegion;
        }

        // Decrement the queued-frames count.  Signal another event if we
        // have more frames pending.
        //减少mQueuedFrames的值 
        //如果还有Queued的Buffer，那么通知 SurfaceFlinger在下一个VSYNC时进行更新
        if (android_atomic_dec(&mQueuedFrames) > 1) {
            mFlinger->signalLayerUpdate();
        }
        //发生了异常
        if (updateResult != NO_ERROR) {
            // something happened!
            recomputeVisibleRegions = true;
            return outDirtyRegion;
        }

        // update the active buffer
        //mActiveBuffer表示马上要显示的buffer
        //更新mActiveBuffer，得到现在需要输出的图像数据
        mActiveBuffer = mSurfaceFlingerConsumer->getCurrentBuffer();
        if (mActiveBuffer == NULL) {
            ／／异常发生
            // this can only happen if the very first buffer was rejected.
            return outDirtyRegion;
        }
        //即将进入 refresh的阶段
        mRefreshPending = true;
        mFrameLatencyNeeded = true;
        //如果是第一次接收到Buffer, 需要重新计算可视区域
        if (oldActiveBuffer == NULL) {
             // the first time we receive a buffer, we need to trigger a
             // geometry invalidation.
            recomputeVisibleRegions = true;
         }

        Rect crop(mSurfaceFlingerConsumer->getCurrentCrop());
        const uint32_t transform(mSurfaceFlingerConsumer->getCurrentTransform());
        const uint32_t scalingMode(mSurfaceFlingerConsumer->getCurrentScalingMode());
        if ((crop != mCurrentCrop) ||
            (transform != mCurrentTransform) ||
            (scalingMode != mCurrentScalingMode))
        {
            //保存最新的 crop 与transform 这些变量
            mCurrentCrop = crop;
            mCurrentTransform = transform;
            mCurrentScalingMode = scalingMode;
            recomputeVisibleRegions = true;
        }
        //最新的buffer和上一个渲染的buffer的尺寸不一样的，这时需要重新计算可视化区域
        if (oldActiveBuffer != NULL) {
            uint32_t bufWidth  = mActiveBuffer->getWidth();
            uint32_t bufHeight = mActiveBuffer->getHeight();
            if (bufWidth != uint32_t(oldActiveBuffer->width) ||
                bufHeight != uint32_t(oldActiveBuffer->height)) {
                recomputeVisibleRegions = true;
            }
        }
        //透明度相关
        mCurrentOpacity = getOpacityForFormat(mActiveBuffer->format);
        if (oldOpacity != isOpaque(s)) {
            recomputeVisibleRegions = true;
        }

        // FIXME: postedRegion should be dirty & bounds
        //计算出脏区域
        Region dirtyRegion(Rect(s.active.w, s.active.h));

        // transform the dirty region to window-manager space
        outDirtyRegion = (s.transform.transform(dirtyRegion));
    }
    return outDirtyRegion;
}

part3最核心的就是更新纹理，之后就是对于返回结果的处理。所以步骤就分两步：
1）updateTexImage更新纹理。这一步比较重要，我们接下来单独分析。
2）处理更新纹理的结果。
延迟显示，触发下一个VSYNC，即Buffer显示的时间还没到；减少mQueuedFrames的值，如果还有Queued的Buffer，那么通知 SurfaceFlinger在下一个VSYNC时进行更新。
如果更新纹理发生了异常、第一次接收到buffer、crop和transform区域发生改变、最新的buffer和上一个渲染的buffer的尺寸不一样的、透明度区域发生改变，都需要重新可视化区域。
最后返回计算出的脏区域。

更新纹理

我们单独分析更新纹理，SurfaceFlingerConsumer的updateTexImage函数，位于frameworks/native/services/surfaceflinger/SurfaceFlingerConsumer.cpp:


status_t SurfaceFlingerConsumer::updateTexImage(BufferRejecter* rejecter,
        const DispSync& dispSync)
{
    ATRACE_CALL();
    ALOGV("updateTexImage");
    Mutex::Autolock lock(mMutex);

    if (mAbandoned) {//EGL没有初始化
        ALOGE("updateTexImage: GLConsumer is abandoned!");
        return NO_INIT;
    }

    // Make sure the EGL state is the same as in previous calls.
    //检查EGL的状态是否ok
    status_t err = checkAndUpdateEglStateLocked();
    if (err != NO_ERROR) {
        return err;
    }

    BufferQueue::BufferItem item;

    // Acquire the next buffer.
    // In asynchronous mode the list is guaranteed to be one buffer
    // deep, while in synchronous mode we use the oldest buffer.
    //获得要显示出来的Buffer
    //a, 如果上层canvas绘图，获取到的fencefd为-1
    //b, 上层opengl绘图，获取到的fencefd不为-1
    err = acquireBufferLocked(&item, computeExpectedPresent(dispSync));
    //处理获取buffer异常的状况
    if (err != NO_ERROR) {
        if (err == BufferQueue::NO_BUFFER_AVAILABLE) {
            err = NO_ERROR;
        } else if (err == BufferQueue::PRESENT_LATER) {
            // return the error, without logging
        } else {
            ALOGE("updateTexImage: acquire failed: %s (%d)",
                strerror(-err), err);
        }
        return err;
    }


    // We call the rejecter here, in case the caller has a reason to
    // not accept this buffer.  This is used by SurfaceFlinger to
    // reject buffers which have the wrong size
    int buf = item.mBuf;
    // 检查是否需要 reject buffer，如果尺寸大小不对，就拒绝掉这个buffer
    if (rejecter && rejecter->reject(mSlots[buf].mGraphicBuffer, item)) {
        //如果拒绝了这个buffer，就要释放它
        releaseBufferLocked(buf, mSlots[buf].mGraphicBuffer, EGL_NO_SYNC_KHR);
        return NO_ERROR;
    }

    // Release the previous buffer.
    // 每次只能处理一个graphic buffer，要将上一次对应的buffer先release了，供别人使用
    //首先创建一个release fence，
    //将release fence传递给BufferQueue中的slot对应的mSlots[slot]的mFence
    // 创建GLConsumer里新的EGLImage
    err = updateAndReleaseLocked(item);
    if (err != NO_ERROR) {
        return err;
    }
    //4.4和以后已经不走这个if了，会在Layer::onDraw中去创建纹理
    if (!SyncFeatures::getInstance().useNativeFenceSync()) {
        // Bind the new buffer to the GL texture.
        //
        // Older devices require the "implicit" synchronization provided
        // by glEGLImageTargetTexture2DOES, which this method calls.  Newer
        // devices will either call this in Layer::onDraw, or (if it's not
        // a GL-composited layer) not at all.
        //绑定EglImage到GL texture
        err = bindTextureImageLocked();
    }

    return err;
}

在这里面会去acquire buffer，然后acquire到的buffer就会去用来合成。主要做的事情：
1）acquire一个新的buffer；
2）将上一次对应的buffer先release了，并为上次的buffer创建一个release fence，将该release fence传递给BufferQueue中的slot对应的mSlots[slot]的mFence；
3）更新mCurrentTexture和mCurrentTextureBuf为这次acquire到的buffer以及slot。
目前acquire fencefd还没使用，因为还未去合成这个layer，没到用layer中数据的时候。

这里有几个重要的步骤，我们分模块分析。

获取buffer

之前我们讲过buffer的状态迁移，又如下一幅图：

之前讲buffer queued进入BufferQueue，然后等等待SF消费。所以SF本次acquire buffer，buffer状态迁移为ACQUIRED。

顺着上面的步骤，查看acquireBufferLocked函数。不过之前我们先看看参数中computeExpectedPresent函数计算下一次vsync信号到来的时间：

nsecs_t SurfaceFlingerConsumer::computeExpectedPresent(const DispSync& dispSync)
{
    // The HWC doesn't currently have a way to report additional latency.
    // Assume that whatever we submit now will appear right after the flip.
    // For a smart panel this might be 1.  This is expressed in frames,
    // rather than time, because we expect to have a constant frame delay
    // regardless of the refresh rate.
    const uint32_t hwcLatency = 0;

    // Ask DispSync when the next refresh will be (CLOCK_MONOTONIC).
    //调用DispSync的dispSync.computeNextRefresh计算下一次刷新时间
    const nsecs_t nextRefresh = dispSync.computeNextRefresh(hwcLatency);

    // The DispSync time is already adjusted for the difference between
    // vsync and reported-vsync (PRESENT_TIME_OFFSET_FROM_VSYNC_NS), so
    // we don't need to factor that in here.  Pad a little to avoid
    // weird effects if apps might be requesting times right on the edge.
    nsecs_t extraPadding = 0;
    if (VSYNC_EVENT_PHASE_OFFSET_NS == 0) {
        extraPadding = 1000000;        // 1ms (6% of 60Hz)
    }

    return nextRefresh + extraPadding;
}

计算下一次vsync_sf时间，位于frameworks/native/services/surfaceflinger/DispSync.cpp中：

nsecs_t DispSync::computeNextRefresh(int periodOffset) const {
    Mutex::Autolock lock(mMutex);
    nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
    return (((now - mPhase) / mPeriod) + periodOffset + 1) * mPeriod + mPhase;
}

就是一个屏幕刷新周期之后的时间。

获得了这个实参，然后就查看获取buffer的函数acquireBufferLocked：

status_t SurfaceFlingerConsumer::acquireBufferLocked(
        BufferQueue::BufferItem *item, nsecs_t presentWhen) {
    status_t result = GLConsumer::acquireBufferLocked(item, presentWhen);
    if (result == NO_ERROR) {
        mTransformToDisplayInverse = item->mTransformToDisplayInverse;
    }
    return result;
}

这里调用了GLConsumer的acquireBufferLocked函数，位于frameworks/native/libs/gui/GLConsumer.cpp：

status_t GLConsumer::acquireBufferLocked(BufferQueue::BufferItem *item,
        nsecs_t presentWhen) {
    //调用ConsumerBase的acquireBufferLocked函数
    status_t err = ConsumerBase::acquireBufferLocked(item, presentWhen);
    if (err != NO_ERROR) {
        return err;
    }

    // If item->mGraphicBuffer is not null, this buffer has not been acquired
    // before, so any prior EglImage created is using a stale buffer. This
    // replaces any old EglImage with a new one (using the new buffer).
    //如果这个buffer已经被acquired，它的图形缓冲区buffer不为空，
    //那么一些以前的EglImage就会使用过时的buffer
    //因此创建GLConsumer里新的EGLImage
    if (item->mGraphicBuffer != NULL) {
        int slot = item->mBuf;
        mEglSlots[slot].mEglImage = new EglImage(item->mGraphicBuffer);
    }

    return NO_ERROR;
}

这里又调用ConsumerBase的acquireBufferLocked函数去获取buffer。之后，如果这个buffer已经被acquired，它的图形缓冲区buffer不为空，那么一些以前的EglImage就会使用过时的buffer，因此创建GLConsumer里新的EGLImage。
我们继续查看ConsumerBase的acquireBufferLocked函数，位于rameworks/native/libs/gui/ConsumerBase.cpp：

status_t ConsumerBase::acquireBufferLocked(BufferQueue::BufferItem *item,
        nsecs_t presentWhen) {
    //又通过binder IPC调用了BufferQueueConsumer的acquireBuffer函数
    status_t err = mConsumer->acquireBuffer(item, presentWhen);
    if (err != NO_ERROR) {
        return err;
    }
    //获取到buffer之后，然后赋值给对应mSlots数组中index的BufferSlot
    if (item->mGraphicBuffer != NULL) {
        mSlots[item->mBuf].mGraphicBuffer = item->mGraphicBuffer;
    }

    mSlots[item->mBuf].mFrameNumber = item->mFrameNumber;
    mSlots[item->mBuf].mFence = item->mFence;

    CB_LOGV("acquireBufferLocked: -> slot=%d/%" PRIu64,
            item->mBuf, item->mFrameNumber);

    return OK;
}

这里又通过binder IPC调用了BufferQueueConsumer的acquireBuffer函数，位于frameworks/native/libs/gui/BufferQueueConsumer.cpp:

status_t BufferQueueConsumer::acquireBuffer(BufferItem* outBuffer,
        nsecs_t expectedPresent) {
    ATRACE_CALL();
    Mutex::Autolock lock(mCore->mMutex);

    // Check that the consumer doesn't currently have the maximum number of
    // buffers acquired. We allow the max buffer count to be exceeded by one
    // buffer so that the consumer can successfully set up the newly acquired
    // buffer before releasing the old one.
    //统计mActiveBuffers中已经是 ACQUIRED 的Frame 个数
    int numAcquiredBuffers = 0;
    for (int s = 0; s < BufferQueueDefs::NUM_BUFFER_SLOTS; ++s) {
        //是否已经是 ACQUIRED 的Buffer
        if (mSlots[s].mBufferState == BufferSlot::ACQUIRED) {
            ++numAcquiredBuffers;
        }
    }
    //异常检测 
    if (numAcquiredBuffers >= mCore->mMaxAcquiredBufferCount + 1) {
        BQ_LOGE("acquireBuffer: max acquired buffer count reached: %d (max %d)",
                numAcquiredBuffers, mCore->mMaxAcquiredBufferCount);
        return INVALID_OPERATION;
    }

    // Check if the queue is empty.
    // In asynchronous mode the list is guaranteed to be one buffer deep,
    // while in synchronous mode we use the oldest buffer.
    if (mCore->mQueue.empty()) {
        return NO_BUFFER_AVAILABLE;
    }
    //queue中的第一个 buffer
    BufferQueueCore::Fifo::iterator front(mCore->mQueue.begin());

    // If expectedPresent is specified, we may not want to return a buffer yet.
    // If it's specified and there's more than one buffer queued, we may want
    // to drop a buffer.
    if (expectedPresent != 0) {
        //一秒作为选择显示的buffer的范围条件
        const int MAX_REASONABLE_NSEC = 1000000000ULL; // 1 second

        // The 'expectedPresent' argument indicates when the buffer is expected
        // to be presented on-screen. If the buffer's desired present time is
        // earlier (less) than expectedPresent -- meaning it will be displayed
        // on time or possibly late if we show it as soon as possible -- we
        // acquire and return it. If we don't want to display it until after the
        // expectedPresent time, we return PRESENT_LATER without acquiring it.
        //expectedPresent参数表示的是buffer被我们期望的显示时间。
        //如果buffer自己的渴望显示时间早于被期望的时间，意味着它可以按自己渴望时间显示，
        //但是也会迟到，比如我们获取了它去迅速返回了，这时候它显示就要迟到了，
        //此时我们就要返回一个PRESENT_LATER标志让它在下一次vsync信号去处理。
        //
        // To be safe, we don't defer acquisition if expectedPresent is more
        // than one second in the future beyond the desired present time
        // (i.e., we'd be holding the buffer for a long time).
        //安全起见，我们就不推迟采集被期望的时间大于buffer渴望显示时间超过1秒的buffer了，
        //例如，我们长时间持有一个buffer不释放，就会让expectedPresent很大
        //
        // NOTE: Code assumes monotonic time values from the system clock
        // are positive.

        // Start by checking to see if we can drop frames. We skip this check if
        // the timestamps are being auto-generated by Surface. If the app isn't
        // generating timestamps explicitly, it probably doesn't want frames to
        // be discarded based on them.
        // 检查后面的 Queue, 找到最近需要显示的Buffer
        while (mCore->mQueue.size() > 1 && !mCore->mQueue[0].mIsAutoTimestamp) {
            // If entry[1] is timely, drop entry[0] (and repeat). We apply an
            // additional criterion here: we only drop the earlier buffer if our
            // desiredPresent falls within +/- 1 second of the expected present.
            // Otherwise, bogus desiredPresent times (e.g., 0 or a small
            // relative timestamp), which normally mean "ignore the timestamp
            // and acquire immediately", would cause us to drop frames.
            //如果entry[1]是及时的，就出drop掉entry[0]的buffer，然后继续往后面选。
            //我们额外应用一个准则在这里：如果entry[1]的buffer的 desired time落在期望显示时间误差1秒内，那么我们drop掉entry[0]
            //
            // We may want to add an additional criterion: don't drop the
            // earlier buffer if entry[1]'s fence hasn't signaled yet.
            //还有一个准则：如果entry[1]的fence还没有到来，不drop entry[1]的buffer
            const BufferItem& bufferItem(mCore->mQueue[1]);
            nsecs_t desiredPresent = bufferItem.mTimestamp;
            //如果这个buffer显示的时间在expected之后（garbage），或者将来的1s内会，那么不drop掉上一个. 
                // break掉直接显示上一个buffer
            if (desiredPresent < expectedPresent - MAX_REASONABLE_NSEC ||
                    desiredPresent > expectedPresent) {
                // This buffer is set to display in the near future, or
                // desiredPresent is garbage. Either way we don't want to drop
                // the previous buffer just to get this on the screen sooner.
                BQ_LOGV("acquireBuffer: nodrop desire=%" PRId64 " expect=%"
                        PRId64 " (%" PRId64 ") now=%" PRId64,
                        desiredPresent, expectedPresent,
                        desiredPresent - expectedPresent,
                        systemTime(CLOCK_MONOTONIC));
                break;
            }

            BQ_LOGV("acquireBuffer: drop desire=%" PRId64 " expect=%" PRId64
                    " size=%zu",
                    desiredPresent, expectedPresent, mCore->mQueue.size());
            //如果上一个需要drop的buffer仍然在slots中，那么标记他为FREE状态        
            if (mCore->stillTracking(front)) {
                // Front buffer is still in mSlots, so mark the slot as free
                mSlots[front->mSlot].mBufferState = BufferSlot::FREE;
            }
            //上一个已经没有必要显示了, 重新找一个显示的
            mCore->mQueue.erase(front);
            front = mCore->mQueue.begin();
        }

        // See if the front buffer is due
        buffer要显示的时间还没到，那么标记为PRESENT_LATER，下一帧处理
        nsecs_t desiredPresent = front->mTimestamp;
        if (desiredPresent > expectedPresent &&
                desiredPresent < expectedPresent + MAX_REASONABLE_NSEC) {
            BQ_LOGV("acquireBuffer: defer desire=%" PRId64 " expect=%" PRId64
                    " (%" PRId64 ") now=%" PRId64,
                    desiredPresent, expectedPresent,
                    desiredPresent - expectedPresent,
                    systemTime(CLOCK_MONOTONIC));
            return PRESENT_LATER;
        }

        BQ_LOGV("acquireBuffer: accept desire=%" PRId64 " expect=%" PRId64 " "
                "(%" PRId64 ") now=%" PRId64, desiredPresent, expectedPresent,
                desiredPresent - expectedPresent,
                systemTime(CLOCK_MONOTONIC));
    }

    int slot = front->mSlot;
    *outBuffer = *front;
    ATRACE_BUFFER_INDEX(slot);

    BQ_LOGV("acquireBuffer: acquiring { slot=%d/%" PRIu64 " buffer=%p }",
            slot, front->mFrameNumber, front->mGraphicBuffer->handle);
    // If the front buffer is still being tracked, update its slot state
    //即将要显示的Buffer没有过期，就要更新状态变为 ACQUIRED
    if (mCore->stillTracking(front)) {
        mSlots[slot].mAcquireCalled = true;//BUFFER的状态已经是 ACQUIRED 的了
        mSlots[slot].mNeedsCleanupOnRelease = false;
        mSlots[slot].mBufferState = BufferSlot::ACQUIRED;
        mSlots[slot].mFence = Fence::NO_FENCE;
    }

    // If the buffer has previously been acquired by the consumer, set
    // mGraphicBuffer to NULL to avoid unnecessarily remapping this buffer
    // on the consumer side
    //如果buffer之前已经被获取了，设置mGraphicBuffer变量为NULL，避免consumer不必要的二次映射
    if (outBuffer->mAcquireCalled) {
        outBuffer->mGraphicBuffer = NULL;
    }
    //将Buffer从 BufferQueueCore列队里移除
    mCore->mQueue.erase(front);

    // We might have freed a slot while dropping old buffers, or the producer
    // may be blocked waiting for the number of buffers in the queue to
    // decrease.
    //我们在第七节讲过，当dequeue buffer时候，slots有可能没有free的buffer可用，
    //因此会在producer那儿等待，所以我们这里释放一个slot时候就要去唤醒那儿的lock
    mCore->mDequeueCondition.broadcast();

    ATRACE_INT(mCore->mConsumerName.string(), mCore->mQueue.size());

    return NO_ERROR;
}

这也就是我们Buffer迁移状态中ACQUIRED状态的流程，Acquire一个需要处理的Buffer。根据前面对Buffer状态迁移的分析，当消费者想处理一块buffer时，它首先要向BufferQueue做acquire申请。那么BufferQueue怎么知道当前要处理哪一个Buffer呢？这是因为其内部维护有一个Fifo先入先出队列。一旦有buffer被enqueue后，就会压入队尾;每次acquire就从队头取最前面的元素进行处理，完成之后就将其从队列移除。
代码流程如下：
1）统计mActiveBuffers中已经是 ACQUIRED 的Frame 个数，并且检测异常；
2）queue中的第一个 buffer，一秒作为选择显示的buffer的范围条件。如果这个entry[1]显示的时间在expected之后（garbage），或者将来的1s内会，那么不drop掉上一个，直接break掉，显示entry[0]；
3）如果entry[1]是及时的，就出drop掉entry[0]的buffer，然后继续往后面选；
4）buffer要显示的时间还没到，那么标记为PRESENT_LATER，下一帧处理；
5）更新buffer状态，并从队列中移除。

释放buffer并更新状态

Acquire到的buffer封装在BufferItem中，item.mBuf代表它在BufferSlot中的序号。正常情况下item.mGraphicBuffer都不为空，我们将它记录到mEGLSlots[buf].mGraphicBuffer中，以便后续操作。
消费者一旦处理完Buffer后，就可以将其release了。此后这个buffer就又恢复FREE状态，以供生产者再次dequeue使用。
那么我们就看看这个释放过程，更新纹理中释放过程，updateAndReleaseLocked函数，实现位于GLConsumer中：


status_t GLConsumer::updateAndReleaseLocked(const BufferQueue::BufferItem& item)
{
    status_t err = NO_ERROR;
    //招呼slot
    int buf = item.mBuf;

    if (!mAttached) {//Open GL ES 是否attach
        ST_LOGE("updateAndRelease: GLConsumer is not attached to an OpenGL "
                "ES context");
        releaseBufferLocked(buf, mSlots[buf].mGraphicBuffer,
                mEglDisplay, EGL_NO_SYNC_KHR);
        return INVALID_OPERATION;
    }

    // Confirm state.
    //检测EGL状态
    err = checkAndUpdateEglStateLocked();
    if (err != NO_ERROR) {
        releaseBufferLocked(buf, mSlots[buf].mGraphicBuffer,
                mEglDisplay, EGL_NO_SYNC_KHR);
        return err;
    }

    // Ensure we have a valid EglImageKHR for the slot, creating an EglImage
    // if nessessary, for the gralloc buffer currently in the slot in
    // ConsumerBase.
    // We may have to do this even when item.mGraphicBuffer == NULL (which
    // means the buffer was previously acquired).
    //创建 EGLImage ，此时 mEglImage 已经有了
    //acquireBufferLocked中找到的即将要显示的 BufferItem 的 GraphicBuffer
    err = mEglSlots[buf].mEglImage->createIfNeeded(mEglDisplay, item.mCrop);
    if (err != NO_ERROR) {
        ST_LOGW("updateAndRelease: unable to createImage on display=%p slot=%d",
                mEglDisplay, buf);
        releaseBufferLocked(buf, mSlots[buf].mGraphicBuffer,
                mEglDisplay, EGL_NO_SYNC_KHR);
        return UNKNOWN_ERROR;
    }

    // Do whatever sync ops we need to do before releasing the old slot.
    // 在释放老的buffer前，先给添加一个release fence，有可能还在使用
    err = syncForReleaseLocked(mEglDisplay);
    if (err != NO_ERROR) {
        // Release the buffer we just acquired.  It's not safe to
        // release the old buffer, so instead we just drop the new frame.
        // As we are still under lock since acquireBuffer, it is safe to
        // release by slot.
        releaseBufferLocked(buf, mSlots[buf].mGraphicBuffer,
                mEglDisplay, EGL_NO_SYNC_KHR);
        return err;
    }

    ST_LOGV("updateAndRelease: (slot=%d buf=%p) -> (slot=%d buf=%p)",
            mCurrentTexture, mCurrentTextureImage != NULL ?
                    mCurrentTextureImage->graphicBufferHandle() : 0,
            buf, mSlots[buf].mGraphicBuffer->handle);

    // release old buffer
    // 先把老的buffer，release了
    // 如果是第一次为mCurrentTexture为BufferQueue::INVALID_BUFFER_SLOT，-1
    // 将release fence传递给BufferQueue中的slot对应的mSlots[slot]的mFence
    if (mCurrentTexture != BufferQueue::INVALID_BUFFER_SLOT) {
        //释放buffer  
        status_t status = releaseBufferLocked(
                mCurrentTexture, mCurrentTextureImage->graphicBuffer(),
                mEglDisplay, mEglSlots[mCurrentTexture].mEglFence);
        if (status < NO_ERROR) {
            ST_LOGE("updateAndRelease: failed to release buffer: %s (%d)",
                   strerror(-status), status);
            err = status;
            // keep going, with error raised [?]
        }
    }

    // Update the GLConsumer state.
    // 更新 GLConsumer 状态
    //更新这次acquire到的buffer到mCurrentTexture和mCurrentTextureImage
    mCurrentTexture = buf;
    mCurrentTextureImage = mEglSlots[buf].mEglImage;
    mCurrentCrop = item.mCrop;
    mCurrentTransform = item.mTransform;
    mCurrentScalingMode = item.mScalingMode;
    mCurrentTimestamp = item.mTimestamp;
    mCurrentFence = item.mFence;
    mCurrentFrameNumber = item.mFrameNumber;
    //对当前的buffer进行矩阵变换处理
    computeCurrentTransformMatrixLocked();

    return err;
}

updateAndReleaseLocked这个函数释放了buffer，然后更新了mCurrentTexture mCurrentTextureImage等。步骤如下：
1）检测Open GL是否连接，EGL状态是否OK；
2）创建 EGLImage （此时 mEglImage 已经有了，acquireBufferLocked中找到的即将要显示的 BufferItem 的 GraphicBuffer）；
3）释放老的buffer前，先给添加一个release fence，有可能还在使用（我们本届不讨论Fence相关内容，以后有机会会仔细研究）；
4）释放buffer（这个接下来仔细分析）；
5）更新 GLConsumer 状态，更新这次acquire到的buffer到mCurrentTexture和mCurrentTextureImage。

核心是释放buffer，因此我们看看releaseBufferLocked函数：

status_t GLConsumer::releaseBufferLocked(int buf,
        sp<GraphicBuffer> graphicBuffer,
        EGLDisplay display, EGLSyncKHR eglFence) {
    // release the buffer if it hasn't already been discarded by the
    // BufferQueue. This can happen, for example, when the producer of this
    // buffer has reallocated the original buffer slot after this buffer
    // was acquired.
    status_t err = ConsumerBase::releaseBufferLocked(
            buf, graphicBuffer, display, eglFence);
    mEglSlots[buf].mEglFence = EGL_NO_SYNC_KHR;
    return err;
}

这里又调用了ConsumerBase的releaseBufferLocked函数：

status_t ConsumerBase::releaseBufferLocked(
        int slot, const sp<GraphicBuffer> graphicBuffer,
        EGLDisplay display, EGLSyncKHR eglFence) {
    // If consumer no longer tracks this graphicBuffer (we received a new
    // buffer on the same slot), the buffer producer is definitely no longer
    // tracking it.
    if (!stillTracking(slot, graphicBuffer)) {
        return OK;
    }

    CB_LOGV("releaseBufferLocked: slot=%d/%" PRIu64,
            slot, mSlots[slot].mFrameNumber);
    //release 老buffer的时候，会传入一个mSlots[slot].mFence,即release fence
    ／／调用BufferQueueConsumer的releaseBuffer函数
    status_t err = mConsumer->releaseBuffer(slot, mSlots[slot].mFrameNumber,
            display, eglFence, mSlots[slot].mFence);
    //如果buffer已经过时了但还位于slot中，那么释放他        
    if (err == IGraphicBufferConsumer::STALE_BUFFER_SLOT) {
        freeBufferLocked(slot);
    }

    mSlots[slot].mFence = Fence::NO_FENCE;

    return err;
}

void ConsumerBase::freeBufferLocked(int slotIndex) {
    CB_LOGV("freeBufferLocked: slotIndex=%d", slotIndex);
    mSlots[slotIndex].mGraphicBuffer = 0;
    mSlots[slotIndex].mFence = Fence::NO_FENCE;
    mSlots[slotIndex].mFrameNumber = 0;
}

继而又调用了BufferQueueConsumer的releaseBuffer函数：

status_t BufferQueueConsumer::releaseBuffer(int slot, uint64_t frameNumber,
        const sp<Fence>& releaseFence, EGLDisplay eglDisplay,
        EGLSyncKHR eglFence) {
    ATRACE_CALL();
    ATRACE_BUFFER_INDEX(slot);

    if (slot < 0 || slot >= BufferQueueDefs::NUM_BUFFER_SLOTS ||
            releaseFence == NULL) {
        return BAD_VALUE;
    }

    sp<IProducerListener> listener;
    { // Autolock scope
        Mutex::Autolock lock(mCore->mMutex);

        // If the frame number has changed because the buffer has been reallocated,
        // we can ignore this releaseBuffer for the old buffer
        //如果frameNumber改变了，意味着buffer被重新申请了，
        //所以我们要要标记这个老的buffer为STABLE，然后释放掉老的buffer
        if (frameNumber != mSlots[slot].mFrameNumber) {
            return STALE_BUFFER_SLOT;
        }

        // Make sure this buffer hasn't been queued while acquired by the consumer
        //当consumer去acquire buffer时候，确保这个buffer不在BufferQueue当中
        BufferQueueCore::Fifo::iterator current(mCore->mQueue.begin());
        while (current != mCore->mQueue.end()) {
            if (current->mSlot == slot) {
                BQ_LOGE("releaseBuffer: buffer slot %d pending release is "
                        "currently queued", slot);
                return BAD_VALUE;
            }
            ++current;
        }
        //如果这个buffer被Acquired过了，那么释放他为FREE
        if (mSlots[slot].mBufferState == BufferSlot::ACQUIRED) {
            mSlots[slot].mEglDisplay = eglDisplay;
            mSlots[slot].mEglFence = eglFence;
            mSlots[slot].mFence = releaseFence;
            mSlots[slot].mBufferState = BufferSlot::FREE;
            listener = mCore->mConnectedProducerListener;
            BQ_LOGV("releaseBuffer: releasing slot %d", slot);
        } else if (mSlots[slot].mNeedsCleanupOnRelease) {//如果还存于slot中，是旧的buffer，那么释放他
            BQ_LOGV("releaseBuffer: releasing a stale buffer slot %d "
                    "(state = %d)", slot, mSlots[slot].mBufferState);
            mSlots[slot].mNeedsCleanupOnRelease = false;
            return STALE_BUFFER_SLOT;
        } else {//异常
            BQ_LOGV("releaseBuffer: attempted to release buffer slot %d "
                    "but its state was %d", slot, mSlots[slot].mBufferState);
            return BAD_VALUE;
        }
        //同上面逻辑，dequeue buffer时候可能会wait，这里唤醒wait锁
        mCore->mDequeueCondition.broadcast();
    } // Autolock scope

    // Call back without lock held
    //回调onBufferReleased函数，调用ConsumerBase::onBuffersReleased
    if (listener != NULL) {
        listener->onBufferReleased();
    }

    return NO_ERROR;
}

释放buffer的逻辑如下：
1）异常检测。slot 的index是否合法，是否因为reallocate buffer导致frameNumber改变，当consumer去acquire buffer时候它是否在不在BufferQueue当中；
2）释放buffer。如果这个buffer被Acquired过了，那么释放他为FREE；如果还存于slot中，是旧的buffer，那么释放他；异常或者状态异常；
3）唤醒dequeue buffer时候的wait lock，回调ConsumerBase::onBuffersReleased，通知buffer释放。

以上就释放buffer的流程。

结合上一节内容，经过handleTransaction handlePageFlip两个函数处理，SurfaceFlinger中无论是Layer属性的变化还是图像的变化都处理好了，只等VSync信号到来就可以输出了。
Layer更新中比较重要的就是Buffer状态的迁移，本节主要涉及了Buffer的ACQUIRED和RELEASED状态，这也正好完善了下图的剩下两个流程。

本节内容画一幅时序图如下：

小结

本节主要处理Layer的更新逻辑，先计算layer的脏区域，再更新纹理。更新纹理又包含获取了buffer状态迁移的剩下两环：ACQUIRED、RELEADED。
至此，处理Vsync信号到来时候的前两环已经处理完结了，即SurfaceFlinger中onMessageReceived回调函数的INVALIDATE CASE。下一节开始就是真正的合成阶段——REFRESH，这是个很复杂的流程，我们仍然会一一分析。

（不如意事常八九，可与语人无二三。）

Android SurfaceFlinger 学习之路(九)----SurfaceFlinger事务处理

2017-10-24T08:27:02.000Z

荒废三个月，终于更新了~这期间事情巨多，一言难尽~不过对SurfaceFlinger的研究不能停啊，还是要一点一点钻研。
这次继续顺着上次末尾，分析一下SurfaceFlinger事务处理。

事务概述

Transaction是“事务”的意思。在我脑海中，关于事务的知识来自于数据库。在数据库操作中，事务意味着一次可以提交多个SQL语句，然后一个commit就可让它们集中执行，而且数据库中的事务还可以回滚，即恢复到事务提交前的状态。
SurfaceFlinger为什么需要事务呢？从上面对数据库事务的描述来看，是不是意味着一次执行多个请求呢？我们从数据库事务概念大致可以看出一点端倪, 它的其中一个很重要的信息就是说”将一组相关操作组合成一个单元去处理“。这个思路也运用在了SurfaceFlinger中。我们先举个没有事务的例子，再一个Vsync周期里，Layer的属性改变了很多，比如有大小、位置、透明度、z-order都改变了，并且还不是一个Layer变了，如果每个都改变了，那么如果我们没改变一个属性就去触发相关操作，让SurfaceFlinger去重新合成，这样他岂不是累死了？所以正确的做法是，每当Layer属性改变，先记下来，将所有改变何如一条事务当中，最后在合成前handleTransaction 一次处理掉，这样就省事多了。

事务标志

我们之前分析java层Surface创建的时候，使用过SurfaceControl这个类，它里面有两个方法，openTransaction和closeTransaction，这就是对Surface操作开事务的方法。不过我们这里先不分析这个，我们先看看C++层这一侧的事务。
事务的标志有以下几种，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.h中：

enum {
    eTransactionNeeded        = 0x01,//Layer的属性发生变化了，表示需要处理事务
    eTraversalNeeded          = 0x02,//遍历的是SurfaceFlinger中所有的Layer
    eDisplayTransactionNeeded = 0x04,//这个是显示器相关的事务,如显示器hotplug
    eTransactionMask          = 0x07//掩码
};

事务标志也可以是多种组合，也很好理解，十六进制位，每种标志占一位，掩码占全位。
每种的意义在注释写的比较清楚。

设置和处理flags

mTransactionFlags是surface flinger中的一个成员，注意在layer中也存在一个同名的mTransactionFlags，通过下面的函数设置该flag，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp中：

uint32_t SurfaceFlinger::setTransactionFlags(uint32_t flags) {
    //或返回的是mTransactionFlags旧的值
    uint32_t old = android_atomic_or(flags, &mTransactionFlags);
    //如果旧值和flags没有bit是相同的?
    if ((old & flags)==0) { // wake the server up,触发一次invalidate
        signalTransaction();
    }
    return old;
}

在surfaceflinger中，

createLayer()，removeLayer()，setClientStateLocked都会去设置事务flag为eTransactionNeeded；
setClientStateLocked()会去设置eTraversalNeeded；
createDisplay()，destroyDisplay()，onHotplugReceived()，setDisplayStateLocked()会去设置eDisplayTransactionNeeded。

然后就是调用SurfaceFlinger的signalTransaction，我们看看它：

1
2
3

void SurfaceFlinger::signalTransaction() {
    mEventQueue.invalidate();
}

这个我们之前分析过，调用MessageQueue的invalidate函数，位于frameworks/native/services/surfaceflinger/MessageQueue.cpp中：

#define INVALIDATE_ON_VSYNC 1

void MessageQueue::invalidate() {
// INVALIDATE_ON_VSYNC宏默认为true
#if INVALIDATE_ON_VSYNC
    mEvents->requestNextVsync();
#else
    mHandler->dispatchInvalidate();
#endif
}

mEvents就是EventThread类中的Connection类，第五篇分析vsync的时候介绍过，位于frameworks/native/services/surfaceflinger/EventThread.cpp中：

void EventThread::Connection::requestNextVsync() {
    mEventThread->requestNextVsync(this);
}
// 关于Connection中的count，当为0时为一次性的事件，即触发一次sync信号
// 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
void EventThread::requestNextVsync(
        const sp<EventThread::Connection>& connection) {
    Mutex::Autolock _l(mLock);
    if (connection->count < 0) {
        connection->count = 0;
        mCondition.broadcast();
    }
}

这里将mCondition wait的地方释放，在Android SurfaceFlinger 学习之路(五)—-VSync 工作原理我们分析过，各种事务都会去触发一次vsync，前面文章分析过，在每次vsync信号到来时，处理这个vsync事件会去调用SurfaceFlinger的onMessageReceived函数，我们看看它的实现:

void SurfaceFlinger::onMessageReceived(int32_t what) {
    ATRACE_CALL();
    switch (what) {
    case MessageQueue::TRANSACTION:
        handleMessageTransaction();
        break;
        //我们走的是这个case
    case MessageQueue::INVALIDATE:
        handleMessageTransaction();
        handleMessageInvalidate();
        signalRefresh();
        break;
    case MessageQueue::REFRESH:
        handleMessageRefresh();
        break;
    }
}

我们走的是第二个case。这里先分析这个case第一个函数调用，后面的部分是SurfaceFlinger合成步骤，我们后续在分析。进而调用handleMessageTransaction，根据mTransactionFlags中设置的bit值做相应的处理。

void SurfaceFlinger::handleMessageTransaction() {
    uint32_t transactionFlags = peekTransactionFlags(eTransactionMask);
    if (transactionFlags) {
        handleTransaction(transactionFlags);
    }
}

这样就回到我们今天的主题了，对事务的处理，我们接下来会逐步分析。

SurfaceFlinger处理事务

我们首先要看SurfaceFlinger几个重要的变量：

State mCurrentState
SurfaceFlinger下一帧的状态，即表示即将绘制的下一帧的状态。
State mDrawingState
当前正在绘制的状态，即表示上一帧处理完事务后更新出来的状态，是最终的状态。
mVisibleRegionsDirty
表示当前可见区域是否脏了，如果脏了的话，比如(layer added/removed, Display added/remove相关)在最后合成的时候会对每个屏幕重建layer stack, 但是一般都为false。

这两个状态是SurfaceFlinger中的State，在Layer当中也有一个State，我们后面会讲到，我们看看这个State的定义，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.h：

struct State {
    LayerVector layersSortedByZ;//SurfaceFlinger中所有的按照Z order排序的 Layer
    DefaultKeyedVector< wp<IBinder>, DisplayDeviceState> displays;//外接的显示屏
};

前者是上一次“drawing”时的状态，而后者则是当前状态。这样我们只要通过对比这两个State，就知道系统中发生了什么变化，然后采取相应的措施。它们内部都包含了一个LayerVector类型的layersSortedByZ成员变量，从变量名可以看出是所有layers按照Z-order顺序排列的Vector。
所以我们可以从mCurrentState.layersSortedByZ来访问到所有layer，然后对有需要执行transaction的图层再调用内部的doTransaction()。显然，并不是每个layer在每次handleTransactionLocked中都需要调用doTransaction，判断的标准就是Layer::getTransactionFlags返回的标志中是否要求了eTransactionNeeded。大家要注意SurfaceFlinger和各Layer都有一个mTransactionFlags变量，不过含义不同。另外，Layer中也同样有mCurrentState和mDrawingState，虽然它们也分别表示上一次和当前的状态，但所属的State结构体是完全不同的。

handleTransaction

我们顺着上一节末位，处理vsync信号之后要去合成，之前先处理事务。因此走到了SurfaceFlinger的handleTransaction函数：

void SurfaceFlinger::handleTransaction(uint32_t transactionFlags)
{
    ATRACE_CALL();

    // here we keep a copy of the drawing state (that is the state that's
    // going to be overwritten by handleTransactionLocked()) outside of
    // mStateLock so that the side-effects of the State assignment
    // don't happen with mStateLock held (which can cause deadlocks).
    //保存mDrawingState，但是却没有使用，are you kidding me？
    State drawingState(mDrawingState);

    Mutex::Autolock _l(mStateLock);
    const nsecs_t now = systemTime();
    mDebugInTransaction = now;

    // Here we're guaranteed that some transaction flags are set
    // so we can call handleTransactionLocked() unconditionally.
    // We call getTransactionFlags(), which will also clear the flags,
    // with mStateLock held to guarantee that mCurrentState won't change
    // until the transaction is committed.
    ////获得SurfaceFlinger中的Transaction标志位
    transactionFlags = getTransactionFlags(eTransactionMask);
    //在这里处理Transaction
    handleTransactionLocked(transactionFlags);

    mLastTransactionTime = systemTime() - now;
    mDebugInTransaction = 0;
    invalidateHwcGeometry();
    // here the transaction has been committed
}

先获取了SurfaceFlinger的transactionFlags ，然后调用handleTransactionLocked处理这些事务。这个函数很长，我们需要分步查看。

Part.1 遍历所有的Layer, 让Layer去执行自己的事务

void SurfaceFlinger::handleTransactionLocked(uint32_t transactionFlags)
{
    //获取当前所有Layer
    const LayerVector& currentLayers(mCurrentState.layersSortedByZ);
    const size_t count = currentLayers.size();

    /*
     * Traversal of the children
     * (perform the transaction for each of them if needed)
     */
    //先判断有没有eTraversalNeeded标志位
    if (transactionFlags & eTraversalNeeded) {
        //然后遍历所有Layer,让Layer去执行自己的事务
        for (size_t i=0 ; i<count ; i++) {
            const sp<Layer>& layer(currentLayers[i]);
            //获取Layer的transaction flags
            uint32_t trFlags = layer->getTransactionFlags(eTransactionNeeded);
            if (!trFlags) continue;
            // Layer处理自己的事务
            const uint32_t flags = layer->doTransaction(0);
            //如果Layer的可见区域改变了，则SurfaceFlinger就标注出当前可视区域改变了
            if (flags & Layer::eVisibleRegion)
                mVisibleRegionsDirty = true;
        }
    }

    ......
}

先获取下一帧状态State所有的Layer,然后判断SF有没有eTraversalNeeded标志位，如果有，则遍历所有的Layer，让Layer去执行自己的事务，如果Layer的可见区域改变了，则SurfaceFlinger就标注出当前可视区域改变了，将mVisibleRegionsDirty 置为true。

Part.2 处理显示屏相关事务

void SurfaceFlinger::handleTransactionLocked(uint32_t transactionFlags)
{
    ...Part.1...
    
    /*
     * Perform display own transactions if needed
     */
    //如果有eDisplayTransactionNeeded标志位
    if (transactionFlags & eDisplayTransactionNeeded) {
        // here we take advantage of Vector's copy-on-write semantics to
        // improve performance by skipping the transaction entirely when
        // know that the lists are identical
        //当我们知道上一次绘制状态和当前需要去绘制状态的显示屏信息相同时，
        //通过完全跳过事务，我们利用Vector的copy-on-write的特点去提高性能
        
        //下一帧State的显示屏信息
        const KeyedVector<  wp<IBinder>, DisplayDeviceState>& curr(mCurrentState.displays);
        //上一次绘制状态State的显示屏信息
        const KeyedVector<  wp<IBinder>, DisplayDeviceState>& draw(mDrawingState.displays);
        //如果下一帧State的显示屏信息和上一次绘制状态State的显示屏信息不同
        if (!curr.isIdenticalTo(draw)) {
            //表示当前可见区域脏了
            mVisibleRegionsDirty = true;
            //下一帧需要显示状态
            const size_t cc = curr.size();
                  //上一帧绘制状态
                  size_t dc = draw.size();

            // find the displays that were removed
            // (ie: in drawing state but not in current state)
            // also handle displays that changed
            // (ie: displays that are in both lists)
            //对比上一帧绘制状态，找到我们移除的显示屏
            for (size_t i=0 ; i<dc ; i++) {
                const ssize_t j = curr.indexOfKey(draw.keyAt(i));
                //移除显示屏的index
                if (j < 0) {
                    // in drawing state but not in current state
                    //移除的不是主显示屏
                    if (!draw[i].isMainDisplay()) {
                        // Call makeCurrent() on the primary display so we can
                        // be sure that nothing associated with this display
                        // is current.
                        //主显示屏调用makeCurrent函数确保移除的显示屏和它没有联系了
                        const sp<const DisplayDevice> defaultDisplay(getDefaultDisplayDevice());
                        defaultDisplay->makeCurrent(mEGLDisplay, mEGLContext);
                        sp<DisplayDevice> hw(getDisplayDevice(draw.keyAt(i)));
                        //断开连接
                        if (hw != NULL)
                            hw->disconnect(getHwComposer());
                        if (draw[i].type < DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES)
                            //并回调热插拔接口onHotplugReceived，用于触发下一次vsync信号相应事件
                            mEventThread->onHotplugReceived(draw[i].type, false);
                        mDisplays.removeItem(draw.keyAt(i));
                    } else {
                        ALOGW("trying to remove the main display");
                    }
                } else {
                    //如果这个显示屏没有被移除，看看它是否改变了
                    // this display is in both lists. see if something changed.
                    const DisplayDeviceState& state(curr[j]);
                    const wp<IBinder>& display(curr.keyAt(j));
                    if (state.surface->asBinder() != draw[i].surface->asBinder()) {
                        // changing the surface is like destroying and
                        // recreating the DisplayDevice, so we just remove it
                        // from the drawing state, so that it get re-added
                        // below.
                        //如果显示屏是销毁又重建的，所以没有被移除，
                        //那么我们要移除并重新添加他
                        sp<DisplayDevice> hw(getDisplayDevice(display));
                        if (hw != NULL)
                            hw->disconnect(getHwComposer());
                        mDisplays.removeItem(display);
                        mDrawingState.displays.removeItemsAt(i);
                        dc--; i--;
                        // at this point we must loop to the next item
                        continue;
                    }

                    const sp<DisplayDevice> disp(getDisplayDevice(display));
                    //查看显示屏信息是否改变了，如果变了，
                    //就要重新将drawing信息赋值为current
                    if (disp != NULL) {
                        //z-order排布的layer层改变了
                        if (state.layerStack != draw[i].layerStack) {
                            disp->setLayerStack(state.layerStack);
                        }
                        //方向、视角、帧结构改变了
                        if ((state.orientation != draw[i].orientation)
                                || (state.viewport != draw[i].viewport)
                                || (state.frame != draw[i].frame))
                        {
                            disp->setProjection(state.orientation,
                                    state.viewport, state.frame);
                        }
                        //大小改变了
                        if (state.width != draw[i].width || state.height != draw[i].height) {
                            disp->setDisplaySize(state.width, state.height);
                        }
                    }
                }
            }

            // find displays that were added
            // (ie: in current state but not in drawing state)
            //找到我们新增加的显示屏信息
            for (size_t i=0 ; i<cc ; i++) {
                if (draw.indexOfKey(curr.keyAt(i)) < 0) {
                    const DisplayDeviceState& state(curr[i]);
                    //新增显示屏，需要一些变量属性：
                    //FrameBufferSurface、BufferQueueProducer、
                    //BufferQueueConsumer等
                    sp<DisplaySurface> dispSurface;
                    sp<IGraphicBufferProducer> producer;
                    sp<IGraphicBufferProducer> bqProducer;
                    sp<IGraphicBufferConsumer> bqConsumer;
                    BufferQueue::createBufferQueue(&bqProducer, &bqConsumer,
                            new GraphicBufferAlloc());

                    int32_t hwcDisplayId = -1;
                    //如果是虚拟设备
                    if (state.isVirtualDisplay()) {
                        // Virtual displays without a surface are dormant:
                        // they have external state (layer stack, projection,
                        // etc.) but no internal state (i.e. a DisplayDevice).
                        if (state.surface != NULL) {

                            hwcDisplayId = allocateHwcDisplayId(state.type);
                            sp<VirtualDisplaySurface> vds = new VirtualDisplaySurface(
                                    *mHwc, hwcDisplayId, state.surface,
                                    bqProducer, bqConsumer, state.displayName);

                            dispSurface = vds;
                            producer = vds;
                        }
                    } else {
                        //如果不是虚拟设备
                        ALOGE_IF(state.surface!=NULL,
                                "adding a supported display, but rendering "
                                "surface is provided (%p), ignoring it",
                                state.surface.get());
                        //申请设备id
                        hwcDisplayId = allocateHwcDisplayId(state.type);
                        // for supported (by hwc) displays we provide our
                        // own rendering surface
                        //创建FrameBufferSurface用于渲染显示
                        dispSurface = new FramebufferSurface(*mHwc, state.type,
                                bqConsumer);
                        producer = bqProducer;
                    }

                    const wp<IBinder>& display(curr.keyAt(i));
                    //设置显示屏相关属性
                    if (dispSurface != NULL) {
                        //创建显示屏信息
                        sp<DisplayDevice> hw = new DisplayDevice(this,
                                state.type, hwcDisplayId,
                                mHwc->getFormat(hwcDisplayId), state.isSecure,
                                display, dispSurface, producer,
                                mRenderEngine->getEGLConfig());
                        hw->setLayerStack(state.layerStack);
                        hw->setProjection(state.orientation,
                                state.viewport, state.frame);
                        hw->setDisplayName(state.displayName);
                        mDisplays.add(display, hw);
                        if (state.isVirtualDisplay()) {
                            if (hwcDisplayId >= 0) {
                                mHwc->setVirtualDisplayProperties(hwcDisplayId,
                                        hw->getWidth(), hw->getHeight(),
                                        hw->getFormat());
                            }
                        } else {
                            mEventThread->onHotplugReceived(state.type, true);
                        }
                    }
                }
            }
        }
    }
    
    ......

}

代码虽然多，但是逻辑很清晰，做的事情主要如下：
1）对比上一帧绘制状态，找到我们移除的显示屏。如果找到移除的就要断开连接，并且remove；如果没有移除，则判断是否为destroy-recreate的，如果是，则要移除重新add进来，如果不是，则看看是否状态发生改变，然后设置current状态；
2）找到我们新增加的显示屏信息。新增显示屏，则要创建DisplayDevice描述对象，构建这个对象又需要FrameBufferSurface用于渲染显示，构建FrameBufferSurface又需要BufferQueue一套对象，因此一一创建。

Part.3 找到Layer所在显示屏并更新旋转方向

void SurfaceFlinger::handleTransactionLocked(uint32_t transactionFlags)
{
    ...Part.1...
    ...Part.2...

    if (transactionFlags & (eTraversalNeeded|eDisplayTransactionNeeded)) {
        // The transform hint might have changed for some layers
        // (either because a display has changed, or because a layer
        // as changed).
        //
        // Walk through all the layers in currentLayers,
        // and update their transform hint.
        //
        // If a layer is visible only on a single display, then that
        // display is used to calculate the hint, otherwise we use the
        // default display.
        //
        // NOTE: we do this here, rather than in rebuildLayerStacks() so that
        // the hint is set before we acquire a buffer from the surface texture.
        //
        // NOTE: layer transactions have taken place already, so we use their
        // drawing state. However, SurfaceFlinger's own transaction has not
        // happened yet, so we must use the current state layer list
        // (soon to become the drawing state list).
        //
        sp<const DisplayDevice> disp;
        uint32_t currentlayerStack = 0;
        for (size_t i=0; i<count; i++) {
            // NOTE: we rely on the fact that layers are sorted by
            // layerStack first (so we don't have to traverse the list
            // of displays for every layer).
            const sp<Layer>& layer(currentLayers[i]);
            uint32_t layerStack = layer->getDrawingState().layerStack;
            
            //通过遍历所有的Display来找到Layer所在的显示屏
            if (i==0 || currentlayerStack != layerStack) {
                currentlayerStack = layerStack;
                // figure out if this layerstack is mirrored
                // (more than one display) if so, pick the default display,
                // if not, pick the only display it's on.
                disp.clear();
                for (size_t dpy=0 ; dpy<mDisplays.size() ; dpy++) {
                    sp<const DisplayDevice> hw(mDisplays[dpy]);
                    if (hw->getLayerStack() == currentlayerStack) {
                        if (disp == NULL) {
                            disp = hw;
                        } else {
                            disp = NULL;
                            break;
                        }
                    }
                }
            }
            if (disp == NULL) {
                // NOTE: TEMPORARY FIX ONLY. Real fix should cause layers to
                // redraw after transform hint changes. See bug 8508397.

                // could be null when this layer is using a layerStack
                // that is not visible on any display. Also can occur at
                // screen off/on times.
                disp = getDefaultDisplayDevice();
            }
            //更新Layer的旋转方向，最终会体现在 BufferQueueCore中的mTransformHint变量
            layer->updateTransformHint(disp);
        }
    }

    ......

}

Part3做的事情主要是找到Layer所在显示屏并更新旋转方向，也是layer的事务。

Part.4 处理Layer移除逻辑

void SurfaceFlinger::handleTransactionLocked(uint32_t transactionFlags)
{
    ...Part.1...
    ...Part.2...
    ...Part.3...

    /*
     * Perform our own transaction if needed
     */
    //如果需要合成的layer小于上一次绘制状态的layer个数，
    //则有Layer需要去移除
    const LayerVector& layers(mDrawingState.layersSortedByZ);
    if (currentLayers.size() > layers.size()) {
        // layers have been added
        mVisibleRegionsDirty = true;
    }

    // some layers might have been removed, so
    // we need to update the regions they're exposing.
    //下面有layer移除的情况
    if (mLayersRemoved) {
        mLayersRemoved = false;
        mVisibleRegionsDirty = true;
        const size_t count = layers.size();
        for (size_t i=0 ; i<count ; i++) {
            const sp<Layer>& layer(layers[i]);
            //找到移除的layer
            if (currentLayers.indexOf(layer) < 0) {
                // this layer is not visible anymore
                // TODO: we could traverse the tree from front to back and
                //       compute the actual visible region
                // TODO: we could cache the transformed region
                const Layer::State& s(layer->getDrawingState());
                //获得移除的Layer的可见区域, 这块可见区域就是dirty的
                Region visibleReg = s.transform.transform(
                        Region(Rect(s.active.w, s.active.h)));
                //找到被移除掉的Layer所在的Display, 然后更新Diplay的dirty 区域，也就是对region做或运算
                invalidateLayerStack(s.layerStack, visibleReg);
            }
        }
    }
    //提交事务
    commitTransaction();
    //更新显示屏中的光标
    updateCursorAsync();
}

这一段主要处理Layer的移除逻辑。如果需要合成的layer小于上一次绘制状态的layer个数，则有layer需要去移除。找到需要移除的Layer，获得可见区域，然后更新Display的dirty区域，也就是对region做或运算。

提交事务

剩下就是提交事务和更新显示屏的光标了，我们看看提交事务。

void SurfaceFlinger::commitTransaction()
{
    //mLayersPendingRemoval是保存的是pending 着需要移除的Layer. 
    //比如APP调用destroySurface
    if (!mLayersPendingRemoval.isEmpty()) {
        // Notify removed layers now that they can't be drawn from
        for (size_t i = 0; i < mLayersPendingRemoval.size(); i++) {
            mLayersPendingRemoval[i]->onRemoved();
        }
        mLayersPendingRemoval.clear();
    }

    // If this transaction is part of a window animation then the next frame
    // we composite should be considered an animation as well.
    mAnimCompositionPending = mAnimTransactionPending;
    //更新 mDrawingState
    mDrawingState = mCurrentState;
    mTransactionPending = false;
    mAnimTransactionPending = false;
    //释放mTransactionCV, 如果SurfaceFlinger正在处理事务，
    //而这时如果调用setTransactionState就可能会一直等着mTransactionCV, 
    //因为setTransactionState可能会改变SurfaceFlinger的Transaction标志位，导致前后不一致
    mTransactionCV.broadcast();
}

这就是提交事务的操作，先处理pendingRemove的layer，回调onRemove接口；然后更新mDrawingState状态；最后释放mTransactionCV条件锁。

以上就是SurfaceFlinger处理事务的流程，接下来我们分析Layer怎么处理事务。

Layer处理事务

在handleTransactionLocked函数中的Part1中，我们我们简要分析了layer处理自己事务的流程，接下来我们详细分析这个过程。

Layer的重要变量

我们在Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface中提到过，每一个Layer都有很多属性。

Each Layer has：

Z-order
Alpha value from 0 to 255
visibleRegion
crop region
transformation: rotate 0, 90, 180, 270: flip H, V: scale

当多个Layer进行合成的时候，并不是整个Layer的空间都会被完全显示，根据这个Layer最终的显示效果，一个Layer可以被划分成很多的Region, Android SurfaceFlinger 定义了以下一些Region类型：

TransparantRegion：完全透明的区域，在它之下的区域将被显示出来。
OpaqueRegion: 完全不透明的区域，是否显示取决于它上面是否有遮挡或是否透明。
VisibleRegion: 可见区域，包括完全不透明无遮挡区域或半透明区域。
visibleRegion = Region - above OpaqueRegion.
CoveredRegion: 被遮挡区域，在它之上，有不透明或半透明区域。
DirtyRegion: 可见部分改变区域，包括新的被遮挡区域，和新的露出区域。

我们这里先看看以下几个重要属性：

State mCurrentState;
表示Layer下一帧的属性状态，当某个属性变化时，直接操作该变量
State mDrawingState;
表示当前正在绘制的帧的属性状态。Layer处理完事务后，最终的用于绘制的状态

我们再次看看Layer::State结构体的定义：

struct State {
    Geometry active;//当前Layer的可见区域
    Geometry requested;//请求的Layer的可见区域, 在Layer做doTransaction时会将 requested赋值给active. setSize/setMatrix/setPosition
    uint32_t z;//z-order
    uint32_t layerStack;//layerStack指明当前Layer属于哪个Display，Display的layer stack可以用 hw->getLayerStack获得
    uint8_t alpha;
    uint8_t flags;
    uint8_t reserved[2];
    ////当Layer的属性变化时， sequence就会加1
    int32_t sequence; // changes when visible regions can change
    //更新region的传输矩阵
    Transform transform;
    // the transparentRegion hint is a bit special, it's latched only
    // when we receive a buffer -- this is because it's "content"
    // dependent.
    Region activeTransparentRegion;
    Region requestedTransparentRegion;
};

doTransaction

我们继续分析Layer处理事务的逻辑，看看Layer的doTransaction函数。

uint32_t Layer::doTransaction(uint32_t flags) {// 0
    ATRACE_CALL();
    //上一次绘制状态
    const Layer::State& s(getDrawingState());
    //下一帧状态
    const Layer::State& c(getCurrentState());
    //如果requested的可见区域与旧的可见区域不同了，则size changed
    const bool sizeChanged = (c.requested.w != s.requested.w) ||
                             (c.requested.h != s.requested.h);

    if (sizeChanged) {
        // the size changed, we need to ask our client to request a new buffer
        
        //省略一些log信息

        // record the new size, form this point on, when the client request
        // a buffer, it'll get the new size.
                // 如果size changed, 把新的 w|h 设置到 BufferQueueCore中的 mDefaultWidth|mDefaultHeight中去
        mSurfaceFlingerConsumer->setDefaultBufferSize(
                c.requested.w, c.requested.h);
    }

    //如果新的请求的 w|h 与新的原本要显示的区域不同，表明是  resize了
    if (!isFixedSize()) {

        const bool resizePending = (c.requested.w != c.active.w) ||
                                   (c.requested.h != c.active.h);

        if (resizePending) {
            //resize只发生在非固定模式下
            // don't let Layer::doTransaction update the drawing state
            // if we have a pending resize, unless we are in fixed-size mode.
            // the drawing state will be updated only once we receive a buffer
            // with the correct size.
            //
            // in particular, we want to make sure the clip (which is part
            // of the geometry state) is latched together with the size but is
            // latched immediately when no resizing is involved.
            //如果resize了，则打上eDontUpdateGeometryState的flag
            flags |= eDontUpdateGeometryState;
        }
    }

    // always set active to requested, unless we're asked not to
    // this is used by Layer, which special cases resizes.
    if (flags & eDontUpdateGeometryState)  {//skip
    } else {
        //这里是允许更新 可见区域
        Layer::State& editCurrentState(getCurrentState());
        editCurrentState.active = c.requested;
    }
    //如果可见区域发生改变，刷新并重新计算可见区域
    if (s.active != c.active) {
        // invalidate and recompute the visible regions if needed
        flags |= Layer::eVisibleRegion;
    }

    // 只要Layer有属性发生变化了，sequence就会加1,
    //这样可以很直观判断是否当前的state和旧的state是否发生变化了
    // 但是这样并不能保证sequence相同，但是属性变化的这种情况
    if (c.sequence != s.sequence) {
        // invalidate and recompute the visible regions if needed
        flags |= eVisibleRegion;
        this->contentDirty = true;

        // we may use linear filtering, if the matrix scales us
        const uint8_t type = c.transform.getType();
        mNeedsFiltering = (!c.transform.preserveRects() ||
                (type >= Transform::SCALE));
    }

    // Commit the transaction
    //提交事务
    commitTransaction();
    return flags;
}

这个函数长度还行，看着也不负责，流程如下：
1）如果requested的可见区域与旧的可见区域不同了，则size changed。如果size changed, 把新的 w|h 设置到 BufferQueueCore中的 mDefaultWidth|mDefaultHeight中去。
这里mSurfaceFlingerConsumer->setDefaultBufferSize去设置变化后的大小，我们在Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface分析过mSurfaceFlingerConsumer的创建，位于Layer的onFirstRef函数中。
2）如果可见区域发生改变，刷新并重新计算可见区域。
3）sequence发生改变，重新获取大小。Sequence是个什么东西？当Layer的position，Zorder，alpha,matrix,transparent region,flags,crops.等发生变化的时候，sequence就会自增。也就是，当这些属性发生变化是，页面在Vsync信号触发的时候，根据sequence来判断是否需要属性页面。
4）提交事务。主要就是同步2个state，将current state赋值给drawing state。看看代码如下：

1
2
3

void Layer::commitTransaction() {
    mDrawingState = mCurrentState;
}

以上就是SurfaceFlinger和Layer处理事务的逻辑。通俗的奖就是三句话：

新增layer，对比2个state中的layer队列，就可以知道新增的layer。
移除layer，也是比较2个layer队列，就可以找到移除的layer。
提交transaction，主要就是同步2个state。然后currentstate继续跟踪layer变化，如此往复。

贴个时序图就是下面的逻辑。

小结

以上就是SurfaceFlinger处理事务的简要流程。回顾开始的内容，我们说过SurfaceControl的openTransation和closeTransaction底层实现也是SurfaceFlinger处理事务的操作，不过这个我们以后在分析。下一篇就应该去讲Layer的合成了，也是个十分复杂的过程。
断更三个月，期间也是尝尽辛酸苦辣，痛苦和悔恨只能自己默默下咽。只希望以后能够少点折腾，多一些安逸。

Android SurfaceFlinger 学习之路(八)----Surface管理图形缓冲区

2017-07-03T07:12:29.000Z

本节我们学习一下上层app创建Surface到底层Surface管理图形缓冲区的简要过程，详细的从Activity到WMS最后至底层SurfaceFlinger消费surface我们以后再分析。

上层概述

Surface概述

Surface也是个很复杂的系统，通过之前的学习，我们知道Surface相关的内容主要有两点：

应用程序和Surface的关系
Surface和SurfaceFlinger之间的关系

通过之前对SurfaceFlinger系统的概述，大概用如下图表示：

(右图合成不止有OpenGL，还有HWC硬件，这个我们图中没有画出)
先看左图。可以发现，不论是使用Skia绘制二维图像，还是用OpenGL绘制三维图像，最终Application都要和Surface交互。Surface就像是UI的画布，而App则像是在Surface上作画。
再看右图。Surface和SurfaceFlinger的关系，Surface向SurfaceFlinger提供数据，而SurfaceFlinger则混合数据。其实就是调用OpenGL ES库中的EGL去合成（或者HWC硬件），然后在FrameBuffer上渲染。

简述Activity显示

(这一部分我们以后会详细分析，这里因为后面分析surface需要用到，所以简单提一下)

一般来说，应用程序的外表是通过Activity来展示的。那么，Activity是如何完成界面绘制工作的呢？根据前面所讲的知识，应用程序的显示和Surface有关，那么具体到Activity上，它和Surface又是什么关系呢？因为我们只是提一下，所以用两幅巨图来表示：

Android 应用程序是怎么创建出来的，大概的流程是 ActivityManagerService -> Zygote -> Fork App,。一个新的应用被fork完后，第一个调用的方法就是 ActivityThread的main()，这个函数主要做的事情就是创建一个ActivityThread线程，然后调用loop()开始等待。当收到来自 ActivityManager 的 LAUNCH_ACTIVITY 消息后，Activity开始了他的显示之旅。下图描绘的是Activity在显示前的准备流程：

我们可以说，一个应用可以有多个Activity，每个 Activity 一个Window(PhoneWindow)，每个Window 有一个DecorView, 一个ViewRootImpl, 对应在WindowManagerService 里有一个Window(WindowState)。我们再看另一幅巨图：

ViewRootImpl 在整个Android的GUI系统中占据非常重要的位置，如果把Activity和View 看作 ‘MVC’ 中的V, 把各种后台服务看作Modal，ViewRootImpl 则是’MVC’ 中的’C’ - Controller. Controller在MVC架构里承担着承上启下的作用，一般来说它的逻辑最为复杂。从下图可以看到，ViewRootImpl 与用户输入系统(接收用户按键，触摸屏输入), 窗口系统（复杂窗口的布局，刷新，动画），显示合成系统（包括定时器Choreograph, SurfaceFlinger), 乃至Audio系统（音效输出）等均有密切的关联。

关于创建一Surface的简要时序图可以如下表示：

应用层创建Surface上面时序图已经列出了，即：ViewRootImpl通过Session向WindowMangerService简历通信回话，然后请求WindowManagerService调用relayoutWindow方法，在方法内部通过WindowStateAnimator创建一个SurfaceControl，然后将ViewRootImpl中的无参构造的Surface通过调用copyFrom在JNI层创建一个Surface，并返回句柄给java层。（只是简述，后面章节在分析）相关方法如下：

/*WindowManagerService的relayoutWindow方法*/
public int relayoutWindow(Session session, IWindow client, int seq,
            WindowManager.LayoutParams attrs, int requestedWidth,
            int requestedHeight, int viewVisibility, int flags,
            Rect outFrame, Rect outOverscanInsets, Rect outContentInsets,
            Rect outVisibleInsets, Rect outStableInsets, Configuration outConfig,
            Surface outSurface) {
            //这个最后的参数outSurface就是ViewRootImpl的无参构造方法创建的对象
            //private final Surface mSurface = new Surface();
            ......
            
//调用WindowStateAnimator的createSurfaceLocked方法创建一个SurfaceControl
SurfaceControl surfaceControl = winAnimator.createSurfaceLocked();
                    if (surfaceControl != null) {
                        //调用Surface的copyFrom方法，在JNI层构造一个Surface
                        outSurface.copyFrom(surfaceControl);
                        if (SHOW_TRANSACTIONS) Slog.i(TAG,
                                "  OUT SURFACE " + outSurface + ": copied");
                    } else {
                        // For some reason there isn't a surface.  Clear the
                        // caller's object so they see the same state.
                        outSurface.release();
                    }
            ......       
}

SurfaceControl createSurfaceLocked() {
    ...省略其他步骤...
    //这个构造方法第一个参数SurfaceSession就是SurfaceComposerClient在java层的代表
    mSurfaceControl = new SurfaceControl(
                        mSession.mSurfaceSession,
                        attrs.getTitle().toString(),
                        width, height, format, flags);
    ...省略其他步骤...
    return mSurfaceControl;
}

我们从Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface得知应用层创建Surface对应在SurfaceFlinger这边就是一个Layer，而这个Layer是由SurfaceFlinger创建的。所以我们上面创建java层Surface也需要拿到SurfaceFlinger服务的客户端代理才行。这个代理就是SurfaceSession类对象，mSession.mSurfaceSession。
它的创建是构造ViewRootImpl时候，调用WindowManagerGlobal的getWindowSession方法，通过WMS的代理创建openSession创建一个Session回话。然后ViewRootImpl的setView方法，方法内通过WMS代理调用WMS的addWindow方法，里面利用Session对象调用windowAddedLocked方法创建一个SurfaceSession。这就是它的流程，我们仅仅简单描述。

上面就是Activity创建Surface的java层简要过程。
关于绘制这个流程很复杂，我们后续章节在分析。这里我们因为要分析Surface机制，所以只分析ViewRootImpl的draw流程。（如果开启了硬件加速功能，则会使用hwui硬件绘制功能，这里我们忽略这个，使用默认的软件绘制流程drawSoftware）位于frameworks/base/core/java/android/view/ViewRootImpl.java：


private final Surface mSurface = new Surface();

private boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff, int yoff,
        boolean scalingRequired, Rect dirty) {

    // Draw with software renderer.
    final Canvas canvas;
    try {
        final int left = dirty.left;
        final int top = dirty.top;
        final int right = dirty.right;
        final int bottom = dirty.bottom;

        canvas = mSurface.lockCanvas(dirty);

        ......

        mView.draw(canvas);
        ......
        surface.unlockCanvasAndPost(canvas); 
    }
    return true;
}

我们核心就是这三行代码，这里中间的mView.draw(canvas);这个是调用skia图形库的绘制流程。我们暂时不分析，因为我们不关注这个绘制流程。

我们主要分析canvas = mSurface.lockCanvas(dirty);和surface.unlockCanvasAndPost(canvas);的流程。这两个关系到我们下面的图形缓冲区的管理。

Surface的JNI调用

我们分别分析Surface的构建还有lockCanvas还有unlockCanvasAndPost方法。

Surface的构造

其实看到上面代码，让我们想起来java层构建Surface和在Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface分析的native层创建Surface流程基本一样，也是先创建一个SurfaceControl，然后利用SurfaceControl创建Surface。我们分部查看这个过程。

1）因为创建SurfaceControl，在native层需要SurfaceFlinger服务，所以我们看看java层如何获取SurfaceFlinger服务。所以我们看看上面讲到的创建SurfaceSession，位于frameworks/base/core/java/android/view/SurfaceSession.java：


// Note: This field is accessed by native code.
private long mNativeClient; // SurfaceComposerClient*
private static native long nativeCreate();
/** Create a new connection with the surface flinger. */
public SurfaceSession() {
    mNativeClient = nativeCreate();
}

对于JNI层位于frameworks/base/core/jni/android_view_SurfaceSession.cpp：

static jlong nativeCreate(JNIEnv* env, jclass clazz) {
    //SurfaceComposerClient专门用来和surfaceflinger建立connection（ISurfaceComposerClient）
    SurfaceComposerClient* client = new SurfaceComposerClient();
    client->incStrong((void*)nativeCreate);
    return reinterpret_cast<jlong>(client);
}

SurfaceComposerClient专门用来和surfaceflinger建立connection（ISurfaceComposerClient），SurfaceComposerClient是client，而surface flinger中的server为Client，SurfaceSession就是SurfaceComposerClient在java层的代表，其mNativeClient 成员就是native层的SurfaceComposerClient对象的指针。这一部分可以查看Android SurfaceFlinger 学习之路(四)—-SurfaceFlinger服务的启动与连接过程。

2）然后我们该看看java层SurfaceControl的创建了，位于frameworks/native/libs/gui/SurfaceControl.java：

public SurfaceControl(SurfaceSession session,
        String name, int w, int h, int format, int flags)
                throws OutOfResourcesException {
    ......
    mName = name;
    //调用nativeCreate本地方法
    mNativeObject = nativeCreate(session, name, w, h, format, flags);
    ......
}
private final String mName;
long mNativeObject; // package visibility only for Surface.java access
private static native long nativeCreate(SurfaceSession session, String name,
        int w, int h, int format, int flags)
        throws OutOfResourcesException;

nativeCreate方法对应于JNI层位于frameworks/base/core/jni/android_view_SurfaceControl.cpp：

static jlong nativeCreate(JNIEnv* env, jclass clazz, jobject sessionObj,
        jstring nameStr, jint w, jint h, jint format, jint flags) {
    ScopedUtfChars name(env, nameStr);
    sp<SurfaceComposerClient> client(android_view_SurfaceSession_getClient(env, sessionObj));
    sp<SurfaceControl> surface = client->createSurface(
            String8(name.c_str()), w, h, format, flags);
    if (surface == NULL) {
        jniThrowException(env, OutOfResourcesException, NULL);
        return 0;
    }
    surface->incStrong((void *)nativeCreate);
    return reinterpret_cast<jlong>(surface.get());
}

这里在JNI层调用上面创建的SurfaceComposerClient对象的createSurface函数，请求SurfaceFlinger去创建一个Layer，然后将这些信息封装成一个SurfaceControl。这一部分我们之前讲过，可以参考Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface。

3）最后就是Surface的copyFrom方法，从SurfaceControl获取Surface信息。位于frameworks/base/core/java/android/view/Surface.java：

public void copyFrom(SurfaceControl other) {
    if (other == null) {
        throw new IllegalArgumentException("other must not be null");
    }

    long surfaceControlPtr = other.mNativeObject;
    if (surfaceControlPtr == 0) {
        throw new NullPointerException(
                "SurfaceControl native object is null. Are you using a released SurfaceControl?");
    }
    long newNativeObject = nativeCreateFromSurfaceControl(surfaceControlPtr);

    synchronized (mLock) {
        if (mNativeObject != 0) {
            nativeRelease(mNativeObject);
        }
        setNativeObjectLocked(newNativeObject);
    }
}

对应的JNI层调用位于frameworks/base/core/jni/android_view_Surface.cpp：

static jlong nativeCreateFromSurfaceControl(JNIEnv* env, jclass clazz,
        jlong surfaceControlNativeObj) {
    /*
     * This is used by the WindowManagerService just after constructing
     * a Surface and is necessary for returning the Surface reference to
     * the caller. At this point, we should only have a SurfaceControl.
     */

    sp<SurfaceControl> ctrl(reinterpret_cast<SurfaceControl *>(surfaceControlNativeObj));
    //调用SurfaceControl的getSurface函数
    sp<Surface> surface(ctrl->getSurface());
    if (surface != NULL) {
        surface->incStrong(&sRefBaseOwner);
    }
    return reinterpret_cast<jlong>(surface.get());
}

先从java层保存c++层SurfaceControl的long型句柄，获取C++层SurfaceControl，然后调用其getSurface函数创建一个Surface，最后将这个Surface的句柄通过JNI回传给java层保存。这个getSurface函数我们以前讲过，可以查看Android SurfaceFlinger 学习之路(六)—-SurfaceFlinger创建Surface。

至此我们的Surface的创建就完成了。

lockCanvas

我们接着回到ViewRootImpl的drawSoftware方法，按步骤来，先卡看Surface的lockCanvas方法，位于frameworks/base/core/java/android/view/Surface.java：

//mCanvas 变量直接赋值
private final Canvas mCanvas = new CompatibleCanvas();

public Canvas lockCanvas(Rect inOutDirty)
        throws Surface.OutOfResourcesException, IllegalArgumentException {
    synchronized (mLock) {
        checkNotReleasedLocked();
        if (mLockedObject != 0) {
            // Ideally, nativeLockCanvas() would throw in this situation and prevent the
            // double-lock, but that won't happen if mNativeObject was updated.  We can't
            // abandon the old mLockedObject because it might still be in use, so instead
            // we just refuse to re-lock the Surface.
            throw new IllegalArgumentException("Surface was already locked");
        }
        mLockedObject = nativeLockCanvas(mNativeObject, mCanvas, inOutDirty);
        return mCanvas;
    }
}

老路子，继续查看JNI代码，位于frameworks/base/core/jni/android_view_Surface.cpp：

static jlong nativeLockCanvas(JNIEnv* env, jclass clazz,
        jlong nativeObject, jobject canvasObj, jobject dirtyRectObj) {
    //获取java层的Surface保存的long型句柄
    sp<Surface> surface(reinterpret_cast<Surface *>(nativeObject));

    if (!isSurfaceValid(surface)) {
        doThrowIAE(env);
        return 0;
    }

    Rect dirtyRect;
    Rect* dirtyRectPtr = NULL;
    //获取java层dirty Rect的位置大小信息
    if (dirtyRectObj) {
        dirtyRect.left   = env->GetIntField(dirtyRectObj, gRectClassInfo.left);
        dirtyRect.top    = env->GetIntField(dirtyRectObj, gRectClassInfo.top);
        dirtyRect.right  = env->GetIntField(dirtyRectObj, gRectClassInfo.right);
        dirtyRect.bottom = env->GetIntField(dirtyRectObj, gRectClassInfo.bottom);
        dirtyRectPtr = &dirtyRect;
    }

    ANativeWindow_Buffer outBuffer;
    //调用Surface的lock方法,将申请的图形缓冲区赋给outBuffer
    status_t err = surface->lock(&outBuffer, dirtyRectPtr);
    if (err < 0) {
        const char* const exception = (err == NO_MEMORY) ?
                OutOfResourcesException :
                "java/lang/IllegalArgumentException";
        jniThrowException(env, exception, NULL);
        return 0;
    }

    // Associate a SkCanvas object to this surface
    //给java层的Canvas对象的mSurfaceFormat变量赋值。
    //Java的Surface对象构造的时候会创建一个CompatibleCanvas
    env->SetIntField(canvasObj, gCanvasClassInfo.mSurfaceFormat, outBuffer.format);
    //创建一个SkImageInfo ，用于下面创建SkBitmap 
    SkImageInfo info = SkImageInfo::Make(outBuffer.width, outBuffer.height,
                                         convertPixelFormat(outBuffer.format),
                                         kPremul_SkAlphaType);
    if (outBuffer.format == PIXEL_FORMAT_RGBX_8888) {
        info.fAlphaType = kOpaque_SkAlphaType;
    }

    SkBitmap bitmap;//创建一个SkBitmap 
    //图形缓冲区每一行像素大小
    ssize_t bpr = outBuffer.stride * bytesPerPixel(outBuffer.format);
    然后填充SkBitmap相关变量
    bitmap.setInfo(info, bpr);
    if (outBuffer.width > 0 && outBuffer.height > 0) {
        //outBuffer.bits指向一块存储区域
        bitmap.setPixels(outBuffer.bits);
    } else {
        // be safe with an empty bitmap.
        bitmap.setPixels(NULL);
    }
    //调用Java层Canvas的setNativeBitmap方法，保存JNI层构建的SkBitmap
    env->CallVoidMethod(canvasObj, gCanvasClassInfo.setNativeBitmap,
                        reinterpret_cast<jlong>(&bitmap));

    if (dirtyRectPtr) {
        //剪裁出dirty区域大小
        SkCanvas* nativeCanvas = GraphicsJNI::getNativeCanvas(env, canvasObj);
        nativeCanvas->clipRect( SkRect::Make(reinterpret_cast<const SkIRect&>(dirtyRect)) );
    }

    if (dirtyRectObj) {
        //将剪裁位置大小信息赋给java层Canvas对象
        env->SetIntField(dirtyRectObj, gRectClassInfo.left,   dirtyRect.left);
        env->SetIntField(dirtyRectObj, gRectClassInfo.top,    dirtyRect.top);
        env->SetIntField(dirtyRectObj, gRectClassInfo.right,  dirtyRect.right);
        env->SetIntField(dirtyRectObj, gRectClassInfo.bottom, dirtyRect.bottom);
    }

    // Create another reference to the surface and return it.  This reference
    // should be passed to nativeUnlockCanvasAndPost in place of mNativeObject,
    // because the latter could be replaced while the surface is locked.
    sp<Surface> lockedSurface(surface);
    lockedSurface->incStrong(&sRefBaseOwner);
    return (jlong) lockedSurface.get();
}

这段代码逻辑主要如下：
1）获取java层dirty 的Rect大小和位置信息；
2）调用Surface的lock方法,将申请的图形缓冲区赋给outBuffer；
3）创建一个Skbitmap，填充它用来保存申请的图形缓冲区，并赋值给Java层的Canvas对象；
4）将剪裁位置大小信息赋给java层Canvas对象。

我们关注的核心就是在第二步申请图形缓冲区，这个我们下面会分析到。

unlockCanvasAndPost

我们跳过draw过程，不分析这个，所以到了最后一步，Surface绘制完毕后，unlockCanvasAndPost操作。

public void unlockCanvasAndPost(Canvas canvas) {
    if (canvas != mCanvas) {
        throw new IllegalArgumentException("canvas object must be the same instance that "
                + "was previously returned by lockCanvas");
    }

    synchronized (mLock) {
        checkNotReleasedLocked();
        if (mNativeObject != mLockedObject) {
            Log.w(TAG, "WARNING: Surface's mNativeObject (0x" +
                    Long.toHexString(mNativeObject) + ") != mLockedObject (0x" +
                    Long.toHexString(mLockedObject) +")");
        }
        if (mLockedObject == 0) {
            throw new IllegalStateException("Surface was not locked");
        }
        try {
            nativeUnlockCanvasAndPost(mLockedObject, canvas);
        } finally {
            nativeRelease(mLockedObject);
            mLockedObject = 0;
        }
    }
}

依然查看JNI层代码，位于frameworks/base/core/jni/android_view_Surface.cpp：

static void nativeUnlockCanvasAndPost(JNIEnv* env, jclass clazz,
        jlong nativeObject, jobject canvasObj) {
    //获取java层的Surface保存的long型句柄
    sp<Surface> surface(reinterpret_cast<Surface *>(nativeObject));
    if (!isSurfaceValid(surface)) {
        return;
    }

    // detach the canvas from the surface
    //接触java层对native层SkBitmap的引用
    env->CallVoidMethod(canvasObj, gCanvasClassInfo.setNativeBitmap, (jlong)0);

    // unlock surface
    //调用native层Surface的unlockAndPost函数
    status_t err = surface->unlockAndPost();
    if (err < 0) {
        doThrowIAE(env);
    }
}

这个代码依然很简单，核心就是调用native层Surface的unlockAndPost函数。我们接下来会分析。

综上这个流程大概是如下图：

Surface管理图形缓冲区

Surface申请图形缓冲区

我们上边分析到了申请图形缓冲区，用到了Surface的lock函数，我们继续查看，位于frameworks/native/libs/gui/Surface.cpp：

status_t Surface::lock(
        ANativeWindow_Buffer* outBuffer, ARect* inOutDirtyBounds)
{
    if (mLockedBuffer != 0) {//还没有lock
        ALOGE("Surface::lock failed, already locked");
        return INVALID_OPERATION;
    }

    if (!mConnectedToCpu) {//false
        //调用connect函数完成一些初始化
        int err = Surface::connect(NATIVE_WINDOW_API_CPU);
        if (err) {
            return err;
        }
        // we're intending to do software rendering from this point
        //设置GRALLOC_USAGE_SW_READ_OFTEN 和GRALLOC_USAGE_SW_WRITE_OFTEN标志位，
        //表示打算使用软件渲染
        setUsage(GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_OFTEN);
    }

    ANativeWindowBuffer* out;
    int fenceFd = -1;
    //调用dequeueBuffer函数，申请图形缓冲区
    status_t err = dequeueBuffer(&out, &fenceFd);
    ALOGE_IF(err, "dequeueBuffer failed (%s)", strerror(-err));
    if (err == NO_ERROR) {
        //获取图形缓冲区区域大小,赋给后备缓冲区变量backBuffer
        sp<GraphicBuffer> backBuffer(GraphicBuffer::getSelf(out));
        const Rect bounds(backBuffer->width, backBuffer->height);

        Region newDirtyRegion;
        if (inOutDirtyBounds) {
            //如果上层指定乐刷新脏矩形区域，则用这个区域和缓冲区区域求交集，
            //然后将交集的结果设给需要去刷新的新区域
            newDirtyRegion.set(static_cast<Rect const&>(*inOutDirtyBounds));
            //与运算，求交集
            newDirtyRegion.andSelf(bounds);
        } else {
            //如果上层没有指定脏矩形区域，所以刷新整个图形缓冲区
            newDirtyRegion.set(bounds);
        }

        // figure out if we can copy the frontbuffer back
        //上一次绘制的信息保存在mPostedBuffer中，而这个mPostedBuffer则要在unLockAndPost函数中设置
        const sp<GraphicBuffer>& frontBuffer(mPostedBuffer);
        const bool canCopyBack = (frontBuffer != 0 &&
                backBuffer->width  == frontBuffer->width &&
                backBuffer->height == frontBuffer->height &&
                backBuffer->format == frontBuffer->format);

        if (canCopyBack) {//如果后备缓冲区大小和上次绘制缓冲区大小一样，则不用更新整个buffer
            // copy the area that is invalid and not repainted this round
            //将需要更新的dirty区域剪裁出来，剩余的不需要更新的区域我们不用重绘
            //附注：mDirtyRegion变量命名在老版本Android是mOldDirtyRegion，指的是上一次绘制的dirty区域
            const Region copyback(mDirtyRegion.subtract(newDirtyRegion));
            if (!copyback.isEmpty())
                //这里把mPostedBuffer中的旧数据拷贝到BackBuffer中。
                //后续的绘画只要更新脏区域就可以了，这会节约不少资源
                copyBlt(backBuffer, frontBuffer, copyback);
        } else {
            // if we can't copy-back anything, modify the user's dirty
            // region to make sure they redraw the whole buffer
            //如果两次图形缓冲区大小不一致，我们就要修改用户指定的dirty区域大小为整个缓冲区大小，
            //然后去更新整个缓冲区
            newDirtyRegion.set(bounds);
            mDirtyRegion.clear();
            Mutex::Autolock lock(mMutex);
            for (size_t i=0 ; i<NUM_BUFFER_SLOTS ; i++) {
                mSlots[i].dirtyRegion.clear();
            }
        }


        { // scope for the lock
            Mutex::Autolock lock(mMutex);
            //得到此次后备缓冲器的bufferSlot在mSlots里面的index
            int backBufferSlot(getSlotFromBufferLocked(backBuffer.get()));
            if (backBufferSlot >= 0) {
                //将新的dirty赋给这个bufferslot
                Region& dirtyRegion(mSlots[backBufferSlot].dirtyRegion);
                mDirtyRegion.subtract(dirtyRegion);
                dirtyRegion = newDirtyRegion;
            }
        }
        //然后再加上新的dirty区域，或运算，相叠加
        mDirtyRegion.orSelf(newDirtyRegion);
        if (inOutDirtyBounds) {
            *inOutDirtyBounds = newDirtyRegion.getBounds();
        }

        void* vaddr;
        //lock和unlock分别用来锁定和解锁一个指定的图形缓冲区，在访问一块图形缓冲区的时候，
        //例如，向一块图形缓冲写入内容的时候，需要将该图形缓冲区锁定，用来避免访问冲突,
        //锁定之后，就可以获得由参数参数l、t、w和h所圈定的一块缓冲区的起始地址，保存在输出参数vaddr中
        status_t res = backBuffer->lockAsync(
                GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_OFTEN,
                newDirtyRegion.bounds(), &vaddr, fenceFd);

        ALOGW_IF(res, "failed locking buffer (handle = %p)",
                backBuffer->handle);

        if (res != 0) {
            err = INVALID_OPERATION;
        } else {
            //相关赋值
            mLockedBuffer = backBuffer;
            outBuffer->width  = backBuffer->width;
            outBuffer->height = backBuffer->height;
            outBuffer->stride = backBuffer->stride;
            outBuffer->format = backBuffer->format;
            outBuffer->bits   = vaddr;
        }
    }
    return err;
}

Surface的lock函数用来申请图形缓冲区和一些操作，方法不长，大概工作有：
1）调用connect函数完成一些初始化；
2）调用dequeueBuffer函数，申请图形缓冲区；
3）计算需要绘制的新的dirty区域，旧的区域原样copy数据。
在大部分情况下，UI只有一小部分会发生变化（例如一个按钮被按下去，导致颜色发生变化），这一小部分UI只对应整个GraphicBuffer中的一小块存储（就是在前面代码中见到的dirtyRegion），如果整块存储都更新，则会极大地浪费资源。怎么办？
这就需要将变化的图像和没有发生变化的图像进行叠加。上一次绘制的信息保存在mPostedBuffer中，而这个mPostedBuffer则要在unLockAndPost函数中设置。这里将根据需要，把mPostedBuffer中的旧数据拷贝到BackBuffer中。后续的绘画只要更新脏区域就可以了，这会节约不少资源。
4）lock和unlock分别用来锁定和解锁一个指定的图形缓冲区，在访问一块图形缓冲区的时候，例如，向一块图形缓冲写入内容的时候，需要将该图形缓冲区锁定，用来避免访问冲突,锁定之后，就可以获得由参数参数l、t、w和h所圈定的一块缓冲区的起始地址，保存在输出参数vaddr中。另一方面，在访问完成一块图形缓冲区之后，需要解除这块图形缓冲区的锁定。

其他步骤都已经在注释里说明了，我们主要看看那第二步，dequeueBuffer函数：

int Surface::dequeueBuffer(android_native_buffer_t** buffer, int* fenceFd) {
    ATRACE_CALL();
    ALOGV("Surface::dequeueBuffer");

    int reqW;
    int reqH;
    bool swapIntervalZero;
    uint32_t reqFormat;
    uint32_t reqUsage;

    {
        Mutex::Autolock lock(mMutex);

        reqW = mReqWidth ? mReqWidth : mUserWidth;
        reqH = mReqHeight ? mReqHeight : mUserHeight;

        swapIntervalZero = mSwapIntervalZero;
        reqFormat = mReqFormat;
        reqUsage = mReqUsage;
    } // Drop the lock so that we can still touch the Surface while blocking in IGBP::dequeueBuffer

    int buf = -1;
    sp<Fence> fence;
    //申请图形缓冲区，我们上一节分析过这个过程
    status_t result = mGraphicBufferProducer->dequeueBuffer(&buf, &fence, swapIntervalZero,
            reqW, reqH, reqFormat, reqUsage);

    if (result < 0) {
        ALOGV("dequeueBuffer: IGraphicBufferProducer::dequeueBuffer(%d, %d, %d, %d, %d)"
             "failed: %d", swapIntervalZero, reqW, reqH, reqFormat, reqUsage,
             result);
        return result;
    }

    Mutex::Autolock lock(mMutex);
    //根据index获取缓冲区
    sp<GraphicBuffer>& gbuf(mSlots[buf].buffer);

    // this should never happen
    ALOGE_IF(fence == NULL, "Surface::dequeueBuffer: received null Fence! buf=%d", buf);
    //上一篇分析过，如果所有状态buffer的个数大于64，就要释放所有超过64的buffer，并贴上RELEASE_ALL_BUFFERS标志位
    if (result & IGraphicBufferProducer::RELEASE_ALL_BUFFERS) {
        freeAllBuffers();
    }
    //增加BUFFER_NEEDS_REALLOCATION标志，已重新分配GraphicBuffer
    if ((result & IGraphicBufferProducer::BUFFER_NEEDS_REALLOCATION) || gbuf == 0) {
        //由于申请的内存是在surfaceflinger进程中，
        //BufferQueue中的图形缓冲区也是通过匿名共享内存和binder传递描述符映射过去的，
        //Surface通过调用requestBuffer将图形缓冲区映射到Surface所在进程
        result = mGraphicBufferProducer->requestBuffer(buf, &gbuf);
        if (result != NO_ERROR) {
            ALOGE("dequeueBuffer: IGraphicBufferProducer::requestBuffer failed: %d", result);
            mGraphicBufferProducer->cancelBuffer(buf, fence);
            return result;
        }
    }

    if (fence->isValid()) {
        *fenceFd = fence->dup();
        if (*fenceFd == -1) {
            ALOGE("dequeueBuffer: error duping fence: %d", errno);
            // dup() should never fail; something is badly wrong. Soldier on
            // and hope for the best; the worst that should happen is some
            // visible corruption that lasts until the next frame.
        }
    } else {
        *fenceFd = -1;
    }
    //获取这个这个buffer对象的指针内容
    *buffer = gbuf.get();
    return OK;
}

首先调用BufferQueueProducer的dequeueBuffer函数申请一块图形缓冲区，这个我们上一节讲过，Android SurfaceFlinger 学习之路(七)—-创建图形缓冲区GraphicBuffer。
先在mSlot数组中查找FREE状态的slot，如果找到了就返回这个slot中的index。这个操作是调用了waitForFreeSlotThenRelock函数。如果没有找到，就要从匿名共享内存中重新分配。重新分配返回的flag会加上BUFFER_NEEDS_REALLOCATION标志位。
如果是在匿名共享内存中重新分配的，就要根据index调用BufferQueueProducer的requestBuffer去获取mSlots数组中的bufferSlot，然后取出slot中的buffer。
最后就是将取到的Buffer返回。

我们上一篇没有分析BufferQueueProducer的requestBuffer，也是通过IPC Binder调用远程接口，省去这个过程，直接看实现，位于frameworks/native/libs/gui/BufferQueueProducer.cpp：

status_t BufferQueueProducer::requestBuffer(int slot, sp<GraphicBuffer>* buf) {
    ATRACE_CALL();
    BQ_LOGV("requestBuffer: slot %d", slot);
    Mutex::Autolock lock(mCore->mMutex);

    if (mCore->mIsAbandoned) {
        BQ_LOGE("requestBuffer: BufferQueue has been abandoned");
        return NO_INIT;
    }
    //check index and state
    if (slot < 0 || slot >= BufferQueueDefs::NUM_BUFFER_SLOTS) {
        BQ_LOGE("requestBuffer: slot index %d out of range [0, %d)",
                slot, BufferQueueDefs::NUM_BUFFER_SLOTS);
        return BAD_VALUE;
    } else if (mSlots[slot].mBufferState != BufferSlot::DEQUEUED) {
        BQ_LOGE("requestBuffer: slot %d is not owned by the producer "
                "(state = %d)", slot, mSlots[slot].mBufferState);
        return BAD_VALUE;
    }
    //将slot的mRequestBufferCalled 标志位置为true，并返回指定index的slot的Graphicbuffer
    mSlots[slot].mRequestBufferCalled = true;
    *buf = mSlots[slot].mGraphicBuffer;
    return NO_ERROR;
}

这个比较简单，还是很好理解的额，就是根据指定index取出mSlots中的slot中的buffer。

匿名共享内存 OR 帧缓冲区

我们上边在注释中说了，申请的图形缓冲区是在匿名共享内存中申请的，不是直接在帧缓冲区。这个是有原因，我们下面分析一下。

之前在Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现中我们讲过：

图形缓冲区可以从系统帧缓冲区分配也可以从内存中分配，分配一个图形缓冲区后还需要将该图形缓冲区映射到分配该buffer的进程地址空间来，在Android系统中，图形缓冲区的管理由SurfaceFlinger服务来负责。在系统帧缓冲区中分配的图形缓冲区是在SurfaceFlinger服务中使用，而在内存中分配的图形缓冲区既可以在SurfaceFlinger服务中使用，也可以在其它的应用程序中使用。当其它的应用程序需要使用图形缓冲区的时候，它们就会请求SurfaceFlinger服务为它们分配并将SurfaceFlinger服务返回来的图形缓冲区映射到应用程序进程地址空间。在从内存中分配buffer时，已经将分配的buffer映射到了SurfaceFlinger服务进程地址空间，如果该buffer是应用程序请求SurfaceFlinger服务为它们分配的，那么还需要将SurfaceFlinger服务返回来的图形缓冲区映射到应用程序进程地址空间。

我们这里是应用请求SurfaceFlinger去分配图形缓冲，在匿名共享内存当中。我们要去验证一下。
首先在Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现中讲到，用户空间的应用程序用到的图形缓冲区是由Gralloc模块中的函数gralloc_alloc来分配的，这个函数实现在文件hardware/libhardware/modules/gralloc/gralloc.cpp中：

static int gralloc_alloc(alloc_device_t* dev,
        int w, int h, int format, int usage,
        buffer_handle_t* pHandle, int* pStride)
{
    if (!pHandle || !pStride)
        return -EINVAL;

    size_t size, stride;

    int align = 4;
    int bpp = 0;
    switch (format) {
        case HAL_PIXEL_FORMAT_RGBA_8888:
        case HAL_PIXEL_FORMAT_RGBX_8888:
        case HAL_PIXEL_FORMAT_BGRA_8888:
            bpp = 4;
            break;
        case HAL_PIXEL_FORMAT_RGB_888:
            bpp = 3;
            break;
        case HAL_PIXEL_FORMAT_RGB_565:
        case HAL_PIXEL_FORMAT_RAW_SENSOR:
            bpp = 2;
            break;
        default:
            return -EINVAL;
    }
    size_t bpr = (w*bpp + (align-1)) & ~(align-1);
    size = bpr * h;
    stride = bpr / bpp;

    int err;
    if (usage & GRALLOC_USAGE_HW_FB) {
        err = gralloc_alloc_framebuffer(dev, size, usage, pHandle);
    } else {
        err = gralloc_alloc_buffer(dev, size, usage, pHandle);
    }

    if (err < 0) {
        return err;
    }

    *pStride = stride;
    return 0;
}

参数usage用来描述要分配的图形缓冲区的用途。如果是用来在系统帧缓冲区中渲染的，即参数usage的GRALLOC_USAGE_HW_FB位等于1，那么就必须要系统帧缓冲区中分配，否则的话，就在内存中分配。注意，在内存中分配的图形缓冲区，最终是需要拷贝到系统帧缓冲区去的，以便可以将它所描述的图形渲染出来。

而这个usage是由上层app然后到SurfaceFlinger一系列过程增减标志位的，所以我们从下往上，看看标志是怎么设置的。
同事我们回顾Android SurfaceFlinger 学习之路(七)—-创建图形缓冲区GraphicBuffer的内容。标志位设置在一下几个地方：
1）创建Layer时候，在onFirstRef函数中：

void Layer::onFirstRef() {
    //这里getEffectiveUsage获取一些标志位
    mSurfaceFlingerConsumer->setConsumerUsageBits(getEffectiveUsage(0));

}

这里getEffectiveUsage获取一些标志位，我们继续查看：

uint32_t Layer::getEffectiveUsage(uint32_t usage) const
{
    // TODO: should we do something special if mSecure is set?
    if (mProtectedByApp) {//// application requires protected path to external sink
        // need a hardware-protected path to external video sink
        usage |= GraphicBuffer::USAGE_PROTECTED;
    }
    if (mPotentialCursor) {//// This layer can be a cursor on some displays.
        usage |= GraphicBuffer::USAGE_CURSOR;
    }
    usage |= GraphicBuffer::USAGE_HW_COMPOSER;
    return usage;
}

如果mProtectedByApp为true，则设置GraphicBuffer::USAGE_PROTECTED标志位，默认为false；如果mPotentialCursor为true，设置USAGE_CURSOR标志位，默认为false。这两个注释已经说明了。
最后设置GraphicBuffer::USAGE_HW_COMPOSER，表示使用HWC硬件合成。

2）在上面Surface的lock方法中，设置了setUsage(GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_OFTEN);we’re intending to do software rendering from this point，打算使用软件绘制。

3）Surface的lock方法中，锁定图形缓冲区的函数调用处：status_t res = backBuffer->lockAsync(
GRALLOC_USAGE_SW_READ_OFTEN | GRALLOC_USAGE_SW_WRITE_OFTEN,
newDirtyRegion.bounds(), &vaddr, fenceFd);函数就会将参数usage的值修改为(GraphicBuffer::USAGE_SW_READ_OFTEN | GraphicBuffer::USAGE_SW_WRITE_OFTEN)，目的是防止该Surface的图形缓冲区直接在硬件帧缓冲区上分配。
4）上层app在WindowStateAnimator的createSurfaceLocked构建java层SurfaceControl时也仅仅设置了几个变量：

SurfaceControl createSurfaceLocked() {
            ......
            int flags = SurfaceControl.HIDDEN;
            final WindowManager.LayoutParams attrs = w.mAttrs;

            if ((attrs.flags&WindowManager.LayoutParams.FLAG_SECURE) != 0) {
                flags |= SurfaceControl.SECURE;
            }

            if (mService.isScreenCaptureDisabledLocked(UserHandle.getUserId(mWin.mOwnerUid))) {
                flags |= SurfaceControl.SECURE;
            }

            ......
            if (!PixelFormat.formatHasAlpha(attrs.format)
                        && attrs.surfaceInsets.left == 0
                        && attrs.surfaceInsets.top == 0
                        && attrs.surfaceInsets.right == 0
                        && attrs.surfaceInsets.bottom  == 0) {
                    flags |= SurfaceControl.OPAQUE;
                }
            ......
            mSurfaceControl = new SurfaceControl(
                mSession.mSurfaceSession,
                attrs.getTitle().toString(),
                width, height, format, flags);
            ......

}

也是简单的flag，影响不大。

我们找了这么多，也没有GRALLOC_USAGE_HW_FB标志位。我们再看看这些标志位的定义，位于hardware/libhardware/include/hardware/Gralloc.h：

enum {
    /* buffer is never read in software */
    GRALLOC_USAGE_SW_READ_NEVER         = 0x00000000,
    /* buffer is rarely read in software */
    GRALLOC_USAGE_SW_READ_RARELY        = 0x00000002,
    /* buffer is often read in software */
    GRALLOC_USAGE_SW_READ_OFTEN         = 0x00000003,
    /* mask for the software read values */
    GRALLOC_USAGE_SW_READ_MASK          = 0x0000000F,
    
    /* buffer is never written in software */
    GRALLOC_USAGE_SW_WRITE_NEVER        = 0x00000000,
    /* buffer is rarely written in software */
    GRALLOC_USAGE_SW_WRITE_RARELY       = 0x00000020,
    /* buffer is often written in software */
    GRALLOC_USAGE_SW_WRITE_OFTEN        = 0x00000030,
    /* mask for the software write values */
    GRALLOC_USAGE_SW_WRITE_MASK         = 0x000000F0,

    /* buffer will be used as an OpenGL ES texture */
    GRALLOC_USAGE_HW_TEXTURE            = 0x00000100,
    /* buffer will be used as an OpenGL ES render target */
    GRALLOC_USAGE_HW_RENDER             = 0x00000200,
    /* buffer will be used by the 2D hardware blitter */
    GRALLOC_USAGE_HW_2D                 = 0x00000400,
    /* buffer will be used by the HWComposer HAL module */
    GRALLOC_USAGE_HW_COMPOSER           = 0x00000800,
    /* buffer will be used with the framebuffer device */
    GRALLOC_USAGE_HW_FB                 = 0x00001000,
    /* buffer will be used with the HW video encoder */
    GRALLOC_USAGE_HW_VIDEO_ENCODER      = 0x00010000,
    /* buffer will be written by the HW camera pipeline */
    GRALLOC_USAGE_HW_CAMERA_WRITE       = 0x00020000,
    /* buffer will be read by the HW camera pipeline */
    GRALLOC_USAGE_HW_CAMERA_READ        = 0x00040000,
    /* buffer will be used as part of zero-shutter-lag queue */
    GRALLOC_USAGE_HW_CAMERA_ZSL         = 0x00060000,
    /* mask for the camera access values */
    GRALLOC_USAGE_HW_CAMERA_MASK        = 0x00060000,
    /* mask for the software usage bit-mask */
    GRALLOC_USAGE_HW_MASK               = 0x00071F00,

    /* buffer will be used as a RenderScript Allocation */
    GRALLOC_USAGE_RENDERSCRIPT          = 0x00100000,

    /* buffer should be displayed full-screen on an external display when
     * possible
     */
    GRALLOC_USAGE_EXTERNAL_DISP         = 0x00002000,

    /* Must have a hardware-protected path to external display sink for
     * this buffer.  If a hardware-protected path is not available, then
     * either don't composite only this buffer (preferred) to the
     * external sink, or (less desirable) do not route the entire
     * composition to the external sink.
     */
    GRALLOC_USAGE_PROTECTED             = 0x00004000,

    /* buffer may be used as a cursor */
    GRALLOC_USAGE_CURSOR                = 0x00008000,

    /* implementation-specific private usage flags */
    GRALLOC_USAGE_PRIVATE_0             = 0x10000000,
    GRALLOC_USAGE_PRIVATE_1             = 0x20000000,
    GRALLOC_USAGE_PRIVATE_2             = 0x40000000,
    GRALLOC_USAGE_PRIVATE_3             = 0x80000000,
    GRALLOC_USAGE_PRIVATE_MASK          = 0xF0000000,
};

由于整个系统在硬件上就只有一个帧缓冲区，它是由SurfaceFlinger服务来统一管理的，即只有SurfaceFlinger服务使用的图形缓冲区才可以在上面分配，否则的话，随便一个应用程序进程都可以在上面分配图形缓冲区来使用，这个帧缓冲区的管理就乱套了。应用程序进程使用的图形缓冲区一般都是在匿名共享内存里面分配的，这个图形缓冲区填好数据之后，就会再交给SurfaceFlinger服务来合成到硬件帧缓冲区上去渲染。因此，从前面传过来给函数gralloc_alloc的参数usage的GRALLOC_USAGE_HW_FB位会被设置为0，以便可以在匿名共享内存中分配一个图形缓冲区。

图形缓冲区入队

我们前面讲了，省略了第二步绘制流程，因此我们这里分析第三部，绘制完毕后再queueBuffer。

同样，调用了Surface的unlockCanvasAndPost函数，我们查看它的实现：

status_t Surface::unlockAndPost()
{
    if (mLockedBuffer == 0) {
        ALOGE("Surface::unlockAndPost failed, no locked buffer");
        return INVALID_OPERATION;
    }

    int fd = -1;
    //解锁图形缓冲区，和前面的lockAsync成对出现
    status_t err = mLockedBuffer->unlockAsync(&fd);
    ALOGE_IF(err, "failed unlocking buffer (%p)", mLockedBuffer->handle);
    //queueBuffer去归还图形缓冲区
    err = queueBuffer(mLockedBuffer.get(), fd);
    ALOGE_IF(err, "queueBuffer (handle=%p) failed (%s)",
            mLockedBuffer->handle, strerror(-err));
    //将绘制buffer赋值给mPostedBuffer ，在lock函数里提到了
    mPostedBuffer = mLockedBuffer;
    //最后将mLockedBuffer 置为0
    mLockedBuffer = 0;
    return err;
}

这里也比较简单，核心也是分两步：
1）解锁图形缓冲区，和前面的lockAsync成对出现；
2）queueBuffer去归还图形缓冲区；

所以我们还是重点分析第二步，查看queueBuffer的实现：

int Surface::queueBuffer(android_native_buffer_t* buffer, int fenceFd) {
    ATRACE_CALL();
    ALOGV("Surface::queueBuffer");
    Mutex::Autolock lock(mMutex);
    int64_t timestamp;
    bool isAutoTimestamp = false;
    if (mTimestamp == NATIVE_WINDOW_TIMESTAMP_AUTO) {
        timestamp = systemTime(SYSTEM_TIME_MONOTONIC);
        isAutoTimestamp = true;
        ALOGV("Surface::queueBuffer making up timestamp: %.2f ms",
            timestamp / 1000000.f);
    } else {
        timestamp = mTimestamp;
    }
    //获取图形缓冲区的slot在mSlots中的index
    int i = getSlotFromBufferLocked(buffer);
    if (i < 0) {
        return i;
    }


    // Make sure the crop rectangle is entirely inside the buffer.
    确保剪裁的区域完全位于图形缓冲区内部
    Rect crop;
    mCrop.intersect(Rect(buffer->width, buffer->height), &crop);

    sp<Fence> fence(fenceFd >= 0 ? new Fence(fenceFd) : Fence::NO_FENCE);
    //创建in、out两个栈对象，用于填充数据
    IGraphicBufferProducer::QueueBufferOutput output;
    IGraphicBufferProducer::QueueBufferInput input(timestamp, isAutoTimestamp,
            crop, mScalingMode, mTransform ^ mStickyTransform, mSwapIntervalZero,
            fence, mStickyTransform);
    //调用BufferQueueProducer的queueBuffer归还缓冲区
    status_t err = mGraphicBufferProducer->queueBuffer(i, input, &output);
    if (err != OK)  {
        ALOGE("queueBuffer: error queuing buffer to SurfaceTexture, %d", err);
    }
    uint32_t numPendingBuffers = 0;
    uint32_t hint = 0;
    //解析赋值给全局变量
    output.deflate(&mDefaultWidth, &mDefaultHeight, &hint,
            &numPendingBuffers);

    // Disable transform hint if sticky transform is set.
    if (mStickyTransform == 0) {
        mTransformHint = hint;
    }

    mConsumerRunningBehind = (numPendingBuffers >= 2);

    return err;
}

这里创建了QueueBufferOutput、QueueBufferInput 两个栈对象用来传输数据，这两个我们在下面的附件内容会讲到，有一些关于结构体的知识。

上述的核心就是调用BufferQueueProducer的queueBuffer归还缓冲区，j将绘制后的图形缓冲区queue回去。我们依然省略IPC Binder过程，直接看实现：


status_t BufferQueueProducer::queueBuffer(int slot,
        const QueueBufferInput &input, QueueBufferOutput *output) {
    ATRACE_CALL();
    ATRACE_BUFFER_INDEX(slot);

    int64_t timestamp;
    bool isAutoTimestamp;
    Rect crop;
    int scalingMode;
    uint32_t transform;
    uint32_t stickyTransform;
    bool async;
    sp<Fence> fence;
    //从传入的QueueBufferInput ，解析填充一些变量
    input.deflate(&timestamp, &isAutoTimestamp, &crop, &scalingMode, &transform,
            &async, &fence, &stickyTransform);

    ......
    
    sp<IConsumerListener> listener;
    { // Autolock scope
        Mutex::Autolock lock(mCore->mMutex);

        ...省略一些错误判断逻辑...
        
        //获取入队的GraphicBuffer的区域大小
        const sp<GraphicBuffer>& graphicBuffer(mSlots[slot].mGraphicBuffer);
        Rect bufferRect(graphicBuffer->getWidth(), graphicBuffer->getHeight());
        Rect croppedRect;
        crop.intersect(bufferRect, &croppedRect);
        if (croppedRect != crop) {
            BQ_LOGE("queueBuffer: crop rect is not contained within the "
                    "buffer in slot %d", slot);
            return BAD_VALUE;
        }
        //改变入队的slot的状态为QUEUED
        mSlots[slot].mFence = fence;
        mSlots[slot].mBufferState = BufferSlot::QUEUED;
        //每次推进来，mFrameCounter都加1，
        //上一篇讲分配缓冲区返回最老的FREE状态buffer，就是用这个mFrameCounter最小值判断
        ++mCore->mFrameCounter;
        mSlots[slot].mFrameNumber = mCore->mFrameCounter;
        //创建一个BufferItem来描述GraphicBuffer
        BufferItem item;
        item.mAcquireCalled = mSlots[slot].mAcquireCalled;
        item.mGraphicBuffer = mSlots[slot].mGraphicBuffer;
        item.mCrop = crop;
        item.mTransform = transform & ~NATIVE_WINDOW_TRANSFORM_INVERSE_DISPLAY;
        item.mTransformToDisplayInverse =
                bool(transform & NATIVE_WINDOW_TRANSFORM_INVERSE_DISPLAY);
        item.mScalingMode = scalingMode;
        item.mTimestamp = timestamp;
        item.mIsAutoTimestamp = isAutoTimestamp;
        item.mFrameNumber = mCore->mFrameCounter;//每次加1，最小的肯定是最早推进去的
        item.mSlot = slot;
        item.mFence = fence;
        item.mIsDroppable = mCore->mDequeueBufferCannotBlock || async;

        mStickyTransform = stickyTransform;

        if (mCore->mQueue.empty()) {//如果mQueue队列为空，则直接push进入这个mQueue，不用考虑阻塞
            // When the queue is empty, we can ignore mDequeueBufferCannotBlock
            // and simply queue this buffer
            mCore->mQueue.push_back(item);
            listener = mCore->mConsumerListener;
        } else {
            // When the queue is not empty, we need to look at the front buffer
            // state to see if we need to replace it
            //如果这个mQueue队列不为空，我们要看看它的队头的状态，然后判断是否替换它
            BufferQueueCore::Fifo::iterator front(mCore->mQueue.begin());
            if (front->mIsDroppable) {//如果队头可以丢弃
                // If the front queued buffer is still being tracked, we first
                // mark it as freed
                //如果已经出队的buffer对应的slot依然保留在mSlots数组中，就要释放他，变为FREE状态
                if (mCore->stillTracking(front)) {
                    mSlots[front->mSlot].mBufferState = BufferSlot::FREE;
                    // Reset the frame number of the freed buffer so that it is
                    // the first in line to be dequeued again
                    mSlots[front->mSlot].mFrameNumber = 0;
                }
                // Overwrite the droppable buffer with the incoming one
                //然后队头插入新入队的BufferItem
                *front = item;
            } else {
                //如果队头不能丢弃，则直接将新的Item入队
                mCore->mQueue.push_back(item);
                //将BufferQueueCore的mConsumerListener赋给listener，这个我们上一节讲过
                listener = mCore->mConsumerListener;
            }
        }

        mCore->mBufferHasBeenQueued = true;//入队后mBufferHasBeenQueued 置为true
        //上一篇讲了，没有空闲buffer去dequeue，则要等待，这里解除等待
        mCore->mDequeueCondition.broadcast();

        output->inflate(mCore->mDefaultWidth, mCore->mDefaultHeight,
                mCore->mTransformHint, mCore->mQueue.size());

        ATRACE_INT(mCore->mConsumerName.string(), mCore->mQueue.size());
    } // Autolock scope

    // Call back without lock held
    //然后通知SurfaceFlinger去消费，这个我们上一篇讲过，下面会在分析
    if (listener != NULL) {
        listener->onFrameAvailable();
    }

    return NO_ERROR;
}

queueBuffer方法也挺长的，但是我们分部查看，每一步也不难：
1）从传入的QueueBufferInput ，解析填充一些变量；
2）改变入队Slot的状态为QUEUED，每次推进来，mFrameCounter都加1。这里的slot，上一篇讲分配缓冲区返回最老的FREE状态buffer，就是用这个mFrameCounter最小值判断，就是上一篇LRU算法的判断；
3）创建一个BufferItem来描述GraphicBuffer，用mSlots[slot]中的slot填充BufferItem；
4）将BufferItem塞进mCore的mQueue队列，依照指定规则；
5）然后通知SurfaceFlinger去消费，这个我们上一篇讲过，这个我们下面会讲到。

上述lockCanvas和unlockCanvasAndPost可以用下图来总结一下：

通知SF消费合成

上面讲到，当绘制完毕的GraphicBuffer入队之后，会通知SurfaceFlinger去消费，就是BufferQueueProducer的queueBuffer函数的最后几行，listener->onFrameAvailable()。
这个listener赋值为mCore->mConsumerListener，我们上一篇Android SurfaceFlinger 学习之路(七)—-创建图形缓冲区GraphicBuffer在讲到Consumer时候，得知这个listener最终通过回调，会回到Layer当中，所以最终调用Layer的onFrameAvailable接口，我们看看它的实现：

void Layer::onFrameAvailable() {
    android_atomic_inc(&mQueuedFrames);
    mFlinger->signalLayerUpdate();
}

这里又调用SurfaceFlinger的signalLayerUpdate函数，继续查看：

1
2
3

void SurfaceFlinger::signalLayerUpdate() {
    mEventQueue.invalidate();
}

这里又调用MessageQueue的invalidate函数：

void MessageQueue::invalidate() {
#if INVALIDATE_ON_VSYNC  //1
    mEvents->requestNextVsync();
#else
    mHandler->dispatchInvalidate();
#endif
}

到这里就比较熟悉了，就是们讲Vsync信号的时候内容了，可以查看Android SurfaceFlinger 学习之路(五)—-VSync 工作原理。
其实上面和下面执行的逻辑都一样，最种结果都会走到SurfaceFlinger的vsync信号接收逻辑，即SurfaceFlinger的onMessageReceived函数，走的case是INVALIDATE：

void SurfaceFlinger::onMessageReceived(int32_t what) {
    ATRACE_CALL();
    switch (what) {
    case MessageQueue::TRANSACTION:
        handleMessageTransaction();
        break;
    case MessageQueue::INVALIDATE:
        handleMessageTransaction();
        handleMessageInvalidate();
        signalRefresh();
        break;
    case MessageQueue::REFRESH:
        handleMessageRefresh();
        break;
    }
}

SurfaceFlinger就去消费这块图形缓冲，然后合成图像，送给FrameBuffer，显示设备读取FrameBuffer内容去显示。这个我们以后再讲。

附：结构体对齐

我们上面讲Surface的queueBuffer时候，会创建QueueBufferOutput、QueueBufferInput 两个栈对象用来传输数据。他们定义位于frameworks/native/include/gui/IGraphicBufferProducer.h：

struct QueueBufferInput : public Flattenable<QueueBufferInput> {
    friend class Flattenable<QueueBufferInput>;
    inline QueueBufferInput(const Parcel& parcel);
    // timestamp - a monotonically increasing value in nanoseconds
    // isAutoTimestamp - if the timestamp was synthesized at queue time
    // crop - a crop rectangle that's used as a hint to the consumer
    // scalingMode - a set of flags from NATIVE_WINDOW_SCALING_* in <window.h>
    // transform - a set of flags from NATIVE_WINDOW_TRANSFORM_* in <window.h>
    // async - if the buffer is queued in asynchronous mode
    // fence - a fence that the consumer must wait on before reading the buffer,
    //         set this to Fence::NO_FENCE if the buffer is ready immediately
    // sticky - the sticky transform set in Surface (only used by the LEGACY
    //          camera mode).
    inline QueueBufferInput(int64_t timestamp, bool isAutoTimestamp,
            const Rect& crop, int scalingMode, uint32_t transform, bool async,
            const sp<Fence>& fence, uint32_t sticky = 0)
    : timestamp(timestamp), isAutoTimestamp(isAutoTimestamp), crop(crop),
      scalingMode(scalingMode), transform(transform), stickyTransform(sticky),
      async(async), fence(fence) { }
    inline void deflate(int64_t* outTimestamp, bool* outIsAutoTimestamp,
            Rect* outCrop, int* outScalingMode, uint32_t* outTransform,
            bool* outAsync, sp<Fence>* outFence,
            uint32_t* outStickyTransform = NULL) const {
        *outTimestamp = timestamp;
        *outIsAutoTimestamp = bool(isAutoTimestamp);
        *outCrop = crop;
        *outScalingMode = scalingMode;
        *outTransform = transform;
        *outAsync = bool(async);
        *outFence = fence;
        if (outStickyTransform != NULL) {
            *outStickyTransform = stickyTransform;
        }
    }

    // Flattenable protocol
    size_t getFlattenedSize() const;
    size_t getFdCount() const;
    status_t flatten(void*& buffer, size_t& size, int*& fds, size_t& count) const;
    status_t unflatten(void const*& buffer, size_t& size, int const*& fds, size_t& count);

private:
    int64_t timestamp;
    int isAutoTimestamp;
    Rect crop;
    int scalingMode;
    uint32_t transform;
    uint32_t stickyTransform;
    int async;
    sp<Fence> fence;
};

// QueueBufferOutput must be a POD structure
struct __attribute__ ((__packed__)) QueueBufferOutput {
    inline QueueBufferOutput() { }
    // outWidth - filled with default width applied to the buffer
    // outHeight - filled with default height applied to the buffer
    // outTransformHint - filled with default transform applied to the buffer
    // outNumPendingBuffers - num buffers queued that haven't yet been acquired
    //                        (counting the currently queued buffer)
    inline void deflate(uint32_t* outWidth,
            uint32_t* outHeight,
            uint32_t* outTransformHint,
            uint32_t* outNumPendingBuffers) const {
        *outWidth = width;
        *outHeight = height;
        *outTransformHint = transformHint;
        *outNumPendingBuffers = numPendingBuffers;
    }
    inline void inflate(uint32_t inWidth, uint32_t inHeight,
            uint32_t inTransformHint, uint32_t inNumPendingBuffers) {
        width = inWidth;
        height = inHeight;
        transformHint = inTransformHint;
        numPendingBuffers = inNumPendingBuffers;
    }
private:
    uint32_t width;
    uint32_t height;
    uint32_t transformHint;
    uint32_t numPendingBuffers;
};

这两个结构体，一个用来填充数据，一个用来解析数据。

我们先看看结构字节对齐。

结构体字节对齐

在用sizeof运算符求算某结构体所占空间时，并不是简单地将结构体中所有元素各自占的空间相加，这里涉及到内存字节对齐的问题。从理论上讲，对于任何变量的访问都可以从任何地址开始访问，但是事实上不是如此，实际上访问特定类型的变量只能在特定的地址访问，这就需要各个变量在空间上按一定的规则排列，而不是简单地顺序排列，这就是内存对齐。

内存对齐的原因：

某些平台只能在特定的地址处访问特定类型的数据；
提高存取数据的速度。比如有的平台每次都是从偶地址处读取数据，对于一个int型的变量，若从偶地址单元处存放，则只需一个读取周期即可读取该变量；但是若从奇地址单元处存放，则需要2个读取周期读取该变量。

对齐策略：

结构体变量的首地址能够被其最宽数据类型成员的大小整除。编译器在为结构体变量开辟空间时，首先找到结构体中最宽的数据类型，然后寻找内存地址能被该数据类型大小整除的位置，这个位置作为结构体变量的首地址。而将最宽数据类型的大小作为对齐标准。
结构体每个成员相对结构体首地址的偏移量(offset)都是每个成员本身大小的整数倍，如有需要会在成员之间填充字节。编译器在为结构体成员开辟空间时，首先检查预开辟空间的地址相对于结构体首地址的偏移量是否为该成员大小的整数倍，若是，则存放该成员；若不是，则填充若干字节，以达到整数倍的要求。
结构体变量所占空间的大小必定是最宽数据类型大小的整数倍。如有需要会在最后一个成员末尾填充若干字节使得所占空间大小是最宽数据类型大小的整数倍。

下面看一下sizeof在计算结构体大小的时候具体是怎样计算的：
1）test1 空结构体


typedef struct node
{
     
}S;

则sizeof(S)=1;或sizeof(S)=0;
在C++中占1字节，而在C中占0字节。

2）test2

typedef struct node1
{
    int a;
    char b;
    short c;
}S1;

则sizeof(S1)=8。这是因为结构体node1中最长的数据类型是int，占4个字节，因此以4字节对齐，则该结构体在内存中存放方式为:
|--------int--------| 4字节
|char|----|--short--| 4字节
总共占8字节

3）test3


typedef struct node2
{
    char a;
    int b;
    short c;
}S2;

则siezof(S3)=12.最长数据类型为int，占4个字节。因此以4字节对齐，其在内存空间存放方式如下:
|char|----|----|----| 4字节
|--------int--------| 4字节
|--short--|----|----| 4字节
总共占12个字节

4）test4 含有静态数据成员

typedef struct node3
{
    int a;
    short b;
    static int c;
}S3;

则sizeof(S3)=8。这里结构体中包含静态数据成员，而静态数据成员的存放位置与结构体实例的存储地址无关(注意只有在C++中结构体中才能含有静态数据成员，而C中结构体中是不允许含有静态数据成员的)。其在内存中存储方式如下：
|--------int--------| 4字节
|--short--|----|----| 4字节
而变量c是单独存放在静态数据区的，因此用siezof计算其大小时没有将c所占的空间计算进来。

5）test5 结构体中含有结构体

typedef struct node4
{
    bool a;
    S1 s1;
    short b;
}S4;

数据成员包含另一个结构体变量s1的话，则取s1中最长数据类型与其他数据成员比较，取最长的作为对齐标准，但是s1存放时看做一个单位存放，只需看其他成员即可。
则sizeof(S4)=16。是因为s1占8字节，而s1中最长数据类型为int，占4个字节，bool类型1个字节，short占2字节，因此以4字节对齐，则存储方式为：
|-------bool--------| 4字节
|-------s1----------| 8字节
|-------short-------| 4字节

6）test6

typedef struct node5
{
    bool a;
    S1 s1;
    double b;
    int c;
}S5;

则sizeof(S5)=32。是因为s1占8字节，而s1中最长数据类型为int，占4字节，而double占8字节，因此以8字节对齐，则存放方式为：
|--------bool--------| 8字节
|---------s1---------| 8字节
|--------double------| 8字节
|----int----|--------| 8字节

总结一下，在计算sizeof时主要注意一下几点：

若为空结构体，则只占1个字节的单元;
若结构体中所有数据类型都相同，则其所占空间为成员数据类型长度×成员个数；若结构体中数据类型不同，则取最长数据类型成员所占的空间为对齐标准，数据成员包含另一个结构体变量t的话，则取t中最长数据类型与其他数据成员比较，取最长的作为对齐标准，但是t存放时看做一个单位存放，只需看其他成员即可。

attribute 关键字(双下划线相连并紧贴attribute)

上面的结构体对齐只是普通情况，但是如果对于指定了 attribute (由于MarkDown文本原因，打出来双下划线相连并紧贴attribute有问题，因此先这么表示)关键字，就不痛了。例如我们上面定义 QueueBufferOutput结构体也用了（ attribute (( packed ))）。

1） attribute 关键字主要是用来在函数或数据声明中设置其属性。给函数赋给属性的主要目的在于让编译器进行优化。函数声明中的 attribute ((noreturn))，就是告诉编译器这个函数不会返回给调用者，以便编译器在优化时去掉不必要的函数返回代码。

GNU C的一大特色就是 attribute 机制。 attribute 可以设置函数属性（Function Attribute）、变量属性（Variable Attribute）和类型属性（Type Attribute）。

attribute 书写特征是： attribute 前后都有两个下划线，并且后面会紧跟一对括弧，括弧里面是相应的 attribute 参数。
attribute 语法格式为： attribute ((attribute-list)) 其位置约束：放于声明的尾部“；”之前。
函数属性（Function Attribute）：函数属性可以帮助开发者把一些特性添加到函数声明中，从而可以使编译器在错误检查方面的功能更强大。 attribute 机制也很容易同非GNU应用程序做到兼容之功效。

GNU CC需要使用 –Wall编译器来击活该功能，这是控制警告信息的一个很好的方式。

2） attribute ((packed)) 的作用就是告诉编译器取消结构在编译过程中的优化对齐,按照实际占用字节数进行对齐，是GCC特有的语法。这个功能是跟操作系统没关系，跟编译器有关，gcc编译器不是紧凑模式的，我在windows下，用vc的编译器也不是紧凑的，用tc的编译器就是紧凑的。例如：

在TC下：struct my{ char ch; int a;} sizeof(int)=2;sizeof(my)=3;（紧凑模式）
在GCC下：struct my{ char ch; int a;} sizeof(int)=4;sizeof(my)=8;（非紧凑模式）
在GCC下：struct my{ char ch; int a;} attrubte ((packed)) sizeof(int)=4;sizeof(my)=5

packed属性：使用该属性可以使得变量或者结构体成员使用最小的对齐方式，即对变量是一字节对齐，对域（field）是位对齐。

3）若使用了 attribute ((aligned(n)))命令强制对齐标准，则取n和结构体中最长数据类型占的字节数两者之中的小者作为对齐标准。内存对齐，往往是由编译器来做的，如果你使用的是gcc，可以在定义变量时，添加 attribute ，来决定是否使用内存对齐，或是内存对齐到几个字节，以上面面的结构体为例：


typedef struct __attribute__ ((aligned(4))) node5
{
    bool a;
    S1 s1;
    double b;
    int c;
}S5;

则sizeof(S5)=24。因为强制以4字节对齐，而S5中最长数据类型为double，占8字节，因此以4字节对齐。在内存中存放方式为：
|-----------a--------| 4字节
|--------s1----------| 4字节
|--------s1----------| 4字节
|--------b-----------| 4字节
|--------b-----------| 4字节
|---------c----------| 4字节

参考

http://www.unixwiz.net/techtips/gnu-c-attributes.html
http://www.cnblogs.com/dolphin0520/archive/2011/09/17/2179466.html

小结

本篇我们讲了Surface对图形缓冲区的管理，前面从Activity到Surface创建过程我们只大概提了下，这个放在以后有空会分析的。下一篇我们讲讲SurfaceFlinger消费图形缓冲区，还有合成等等操作。

唉，有一件特别悲催的事情，就是我失业了ToT，所以估计有一段时间不能更新了，望大家见谅。

Android SurfaceFlinger 学习之路(七)----创建图形缓冲区GraphicBuffer

2017-06-22T14:33:29.000Z

在上一篇SurfaceFlinger创建Surface流程中，我们会关联到BufferQueue对GraphicBuffer的管理机制，我们这次就来分析一下它的原理。

角色扮演

Android应用的UI显示到Display的过程中，SurfaceFlinger扮演的角色只是“Flinger”，就是定于检查Layer更新，然后计算DirtyRegion，然后将结果推送给底层显示驱动进行显示。但是在App端，Surface的内容绘制却由应用层来承担。应用层绘制UI内容都需要一个GraphicBuffer，那么Surface对GraphicBuffer的申请、绘制完毕交给SurfaceFlinger去合成然后显示，这个工作也需要一套机制去管理。所以对于GraphicBuffer的管理，Android也设计了一套机制：BufferQueue，作为SurfaceFlinger管理和消费surface的中介。

生产-消费模型

回顾Android SurfaceFlinger 学习之路(二)—-SurfaceFlinger概述，我们可以用这副简图表示App、BufferQueue和SurfaceFlinger的关系。

虽说是三者的关系，但是他们所属的层却只有两个，app属于Java层，BufferQueue/SurfaceFlinger属于native层。也就是说BufferQueue也是隶属SurfaceFlinger，所有工作围绕SurfaceFlinger展开。

生产者模型

这里IGraphicBufferProducer就是app和BufferQueue重要桥梁，GraphicBufferProducer承担着单个应用进程中的UI显示需求，与BufferQueue打交道的就是它。
根据上一篇Surface的创建流程，我们从Surface类图分析了GraphicBufferProducer在Surface中的位置，下图也可以表示：

BpGraphicBufferProducer是GraphicBufferProducer在客户端这边的代理对象，负责和SF交互，GraphicBufferProducer通过gbp（IGraphicBufferProducer类对象）向BufferQueue获取buffer，然后进行填充UI信息，当填充完毕会通知SF，SF知道后就对该Buffer进行下一步操作。典型的生产-消费者模式。

消费者模型

BufferQueue和SurfaceFlinger之间的通信模式如下：

也是有一对BpGraphicBufferConsumer/BnGraphicBufferConsumer支持他们之间的信息传输。

模型实现

上一篇创建Surface流程中，当创建Layer时候，在onFirstRef里面创建了一个生产者和消费者，并对两者进行了包装：

void Layer::onFirstRef() {
    // Creates a custom BufferQueue for SurfaceFlingerConsumer to use
    sp<IGraphicBufferProducer> producer;//生产者
    sp<IGraphicBufferConsumer> consumer;//消费者
    BufferQueue::createBufferQueue(&producer, &consumer);//创建生产者和消费者
    mProducer = new MonitoredProducer(producer, mFlinger);//包装生产者
    mSurfaceFlingerConsumer = new SurfaceFlingerConsumer(consumer, mTextureName);//包装消费者
    //设置消费者相关回调
    mSurfaceFlingerConsumer->setConsumerUsageBits(getEffectiveUsage(0));
    mSurfaceFlingerConsumer->setContentsChangedListener(this);
    mSurfaceFlingerConsumer->setName(mName);

    ......
}

MonitoredProducer对象，这个对象只是一个代理，真正实是BufferQueueProducer类，这个对象和BufferQueueCore有关联，可以管理最多达64块的缓冲区。
SurfaceFlingerConsumer构造函数将BufferQueueConsumer传入，并设置相关回调，以便生产者填充完GraphicBuffer然后通知Consumer消费。

Core

所以创建生产者和消费者就是由BufferQueue来创建，我们可以看看BufferQueue的createBufferQueue函数，位于frameworks/native/libs/gui/BufferQueue.cpp：

void BufferQueue::createBufferQueue(sp<IGraphicBufferProducer>* outProducer,
        sp<IGraphicBufferConsumer>* outConsumer,
        const sp<IGraphicBufferAlloc>& allocator) {//allocator == NULL
    ......
    //创建一个BufferQueueCore，她是核心
    sp<BufferQueueCore> core(new BufferQueueCore(allocator));
    ......
    //用BufferQueueCore创建生产者
    sp<IGraphicBufferProducer> producer(new BufferQueueProducer(core));
    ......
    //用core创建消费者
    sp<IGraphicBufferConsumer> consumer(new BufferQueueConsumer(core));
    ......
    //向外面传入指针赋值
    *outProducer = producer;
    *outConsumer = consumer;
}

所以核心都是这个BufferQueueCore，他是管理图形缓冲区的中枢。这里举一个SurfaceTexture的例子，来看看他们之间的关系：

可以认为BufferQueueCore是一个服务中心，生产者、消费者都要通过它来管理buffer。

里面有一个重要的成员数组：BufferQueueDefs::SlotsType mSlots;
这个BufferSlot中有一个成员变量：sp< GraphicBuffer >mGraphicBuffer;记录这个slot所涉及的缓冲区；
另一个变量BufferState mBufferState;用于跟踪这个缓冲区的状态。

1）在BufferQueueCore类中定义了一个64项的数据mSlots，framework/native/libs/gui/BufferQueueCore.h：

// mSlots is an array of buffer slots that must be mirrored on the producer
// side. This allows buffer ownership to be transferred between the producer
// and consumer without sending a GraphicBuffer over Binder. The entire
// array is initialized to NULL at construction time, and buffers are
// allocated for a slot when requestBuffer is called with that slot's index.
BufferQueueDefs::SlotsType mSlots;

我们看看这个mSlot定义所在的位置，位于frameworks/native/include/gui/BufferQueueDefs.h中：

namespace BufferQueueDefs {
        // BufferQueue will keep track of at most this value of buffers.
        // Attempts at runtime to increase the number of buffers past this
        // will fail.
        enum { NUM_BUFFER_SLOTS = 64 };

        typedef BufferSlot SlotsType[NUM_BUFFER_SLOTS];
    } // namespace BufferQueueDefs

我们可以看到这是一个容量大小为64的数组，因此BufferQueueCore可以管理最多64块的GraphicBuffer。

我们可以帖一幅图表示Slot的角色：

2）BufferSlot的定义位于frameworks/native/include/gui/BufferSlot.h中：

struct BufferSlot {

    BufferSlot()
    : mEglDisplay(EGL_NO_DISPLAY),
      mBufferState(BufferSlot::FREE),
      mRequestBufferCalled(false),
      mFrameNumber(0),
      mEglFence(EGL_NO_SYNC_KHR),
      mAcquireCalled(false),
      mNeedsCleanupOnRelease(false),
      mAttachedByConsumer(false) {
    }
    // mGraphicBuffer points to the buffer allocated for this slot or is NULL
    // if no buffer has been allocated.
    sp<GraphicBuffer> mGraphicBuffer;
    // BufferState represents the different states in which a buffer slot
    // can be.  All slots are initially FREE.
    enum BufferState {
        // FREE indicates that the buffer is available to be dequeued
        // by the producer.  The buffer may be in use by the consumer for
        // a finite time, so the buffer must not be modified until the
        // associated fence is signaled.
        //
        // The slot is "owned" by BufferQueue.  It transitions to DEQUEUED
        // when dequeueBuffer is called.
        FREE = 0,

        // DEQUEUED indicates that the buffer has been dequeued by the
        // producer, but has not yet been queued or canceled.  The
        // producer may modify the buffer's contents as soon as the
        // associated ready fence is signaled.
        //
        // The slot is "owned" by the producer.  It can transition to
        // QUEUED (via queueBuffer) or back to FREE (via cancelBuffer).
        DEQUEUED = 1,

        // QUEUED indicates that the buffer has been filled by the
        // producer and queued for use by the consumer.  The buffer
        // contents may continue to be modified for a finite time, so
        // the contents must not be accessed until the associated fence
        // is signaled.
        //
        // The slot is "owned" by BufferQueue.  It can transition to
        // ACQUIRED (via acquireBuffer) or to FREE (if another buffer is
        // queued in asynchronous mode).
        QUEUED = 2,

        // ACQUIRED indicates that the buffer has been acquired by the
        // consumer.  As with QUEUED, the contents must not be accessed
        // by the consumer until the fence is signaled.
        //
        // The slot is "owned" by the consumer.  It transitions to FREE
        // when releaseBuffer is called.
        ACQUIRED = 3
    };

    // mBufferState is the current state of this buffer slot.
    BufferState mBufferState;
}

mGraphicBuffer代表一块图形缓冲区GraphicBuffer，用于应用绘制UI。
mBufferState类型为BufferState ，BufferState 的定义也位于其中，代表图形缓冲区的几种状态：

FREE：buffer当前可用，可以被生产者dequeued，此时owner是BufferQueueCore，当dequeuebuffer调用时，状态可以转为dequeued。
DEQUEUED：buffer已经被dequeued，还没被queue或canceld，此时owner是producer。
QUEUED：buffer已经被生产者填充，并被queued，此时的owner是bufferQueueCore。
ACQUIRED：buffer已经被消费者获得，此时的owner是consumer。

一般的buffer大致会经过FREE->DEQUEUED->QUEUED->ACQUIRED->FREE这个流程，我们下面会讲到它。

3）在BufferQueueCore创建时候，还会创建一个GraphicBufferAlloc，并将它赋值给BufferQueueCore的mAllocator成员变量。我们可以看看BufferQueueCore的构造函数，位于framework/native/libs/gui/BufferQueueCore.cpp：

BufferQueueCore::BufferQueueCore(const sp<IGraphicBufferAlloc>& allocator) ://allocator为NULL
    mAllocator(allocator),
    mMutex(),
    mIsAbandoned(false),
    mConsumerControlledByApp(false),
    mConsumerName(getUniqueName()),
    mConsumerListener(),
    mConsumerUsageBits(0),
    mConnectedApi(NO_CONNECTED_API),
    mConnectedProducerListener(),
    mSlots(),
    mQueue(),
    mOverrideMaxBufferCount(0),
    mDequeueCondition(),
    mUseAsyncBuffer(true),
    mDequeueBufferCannotBlock(false),
    mDefaultBufferFormat(PIXEL_FORMAT_RGBA_8888),
    mDefaultWidth(1),
    mDefaultHeight(1),
    mDefaultMaxBufferCount(2),
    mMaxAcquiredBufferCount(1),
    mBufferHasBeenQueued(false),
    mFrameCounter(0),
    mTransformHint(0),
    mIsAllocating(false),
    mIsAllocatingCondition()
{
    if (allocator == NULL) {//NULL
        sp<ISurfaceComposer> composer(ComposerService::getComposerService());
        //请求SurfaceFlinger创建GraphicBufferAlloc
        mAllocator = composer->createGraphicBufferAlloc();
        if (mAllocator == NULL) {
            BQ_LOGE("createGraphicBufferAlloc failed");
        }
    }
}

然后回去请求SurfaceFlinger创建一个GraphicBufferAlloc，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp中：

sp<IGraphicBufferAlloc> SurfaceFlinger::createGraphicBufferAlloc()
{
    //创建一个GraphicBufferAlloc对象，并赋给强指针
    sp<GraphicBufferAlloc> gba(new GraphicBufferAlloc());
    return gba;
}

因为BufferQueueCore的mAllocator 类型为IGraphicBufferAlloc，继承于IInterface，所以又是跨进程调用创建。我们下面会分析到它的。

Producer

BufferQueueProducer是生产者的实现，需要实现IGraphicBufferProducer接口，相关方法如下：

/*
 * This class defines the Binder IPC interface for the producer side of
 * a queue of graphics buffers.  It's used to send graphics data from one
 * component to another.  For example, a class that decodes video for
 * playback might use this to provide frames.  This is typically done
 * indirectly, through Surface.
 *
 * The underlying mechanism is a BufferQueue, which implements
 * BnGraphicBufferProducer.  In normal operation, the producer calls
 * dequeueBuffer() to get an empty buffer, fills it with data, then
 * calls queueBuffer() to make it available to the consumer.
 *
 * This class was previously called ISurfaceTexture.
 */
class IGraphicBufferProducer : public IInterface
{
public:
    ......
    virtual status_t requestBuffer(int slot, sp<GraphicBuffer>* buf) = 0;
    virtual status_t dequeueBuffer(int* slot, sp<Fence>* fence, bool async,
            uint32_t w, uint32_t h, uint32_t format, uint32_t usage) = 0;
    virtual status_t queueBuffer(int slot,
            const QueueBufferInput& input, QueueBufferOutput* output) = 0;
    virtual void cancelBuffer(int slot, const sp<Fence>& fence) = 0;  
    ......      
}

这几个函数的注释写的很清楚，但是限于篇幅，没有贴出来。

BufferQueueProducer的dequeueBuffer函数用来向BufferQueueCore申请一个空闲的slot，这个slot可能已经有缓冲区，也可能没有，如果没有缓冲区，dequeueBuffer函数会分配一块新的缓冲区。得到空闲的slot后，还需要调用requestBuffer函数来取出一块缓冲区，也是从BufferQueueCore中的mSlots数组根据index获取这个位置的slot。得到缓冲区，如果不需要了，可以使用cancelBuffer函数来释放这个slot。调用dequeueBuffer函数之后，缓冲区的拥有者是生产者，缓冲区处于DEQUEUED状态。一旦缓冲区复制数据完成，通过queueBuffer函数把缓冲区的控制权交还给BufferQueueCore，这时候缓冲区将处于QUEUED状态。这些函数的使用之处我们下面会讲到。
BufferQueueProducer类图结构如下：

Consumer

同样，BufferQueueConsumer是消费者的实现，需要实现IGraphicBufferConsumer接口，相关方法如下：

class IGraphicBufferConsumer : public IInterface {
public:
    ......
    virtual status_t acquireBuffer(BufferItem* buffer, nsecs_t presentWhen) = 0;
    virtual status_t releaseBuffer(int buf, uint64_t frameNumber,
            EGLDisplay display, EGLSyncKHR fence,
            const sp<Fence>& releaseFence) = 0;
    ......        
}

注释写的很清晰，但是限于篇幅。。。

BufferQueueConsumer类是接口IGraphicBufferComsumer的实现，是一个回调接口，如果BufferQueue中有数据准备好了通知消费者取走数据。取走数据的时候，需要调用acquireBuffer函数，将缓冲区状态变成ACQUIRED，使用完之后调用releaseBuffer函数可以吧缓冲区数据归还给BufferQueueCore，这样缓冲区就变成FREE。

当一块buffer就绪后，消费者就开始工作了，consumer对buffer的处理是被动的，它必须要等到一块buffer填充好才能工作，那consumer怎么知道一块buffer已经填充好了？

所以我们顺着Layer的onFirstRef函数，里面还有一个对于消费者的封装：SurfaceFlingerConsumer。为了方便，我再贴一遍Layer的onFirstRef函数：

void Layer::onFirstRef() {
    // Creates a custom BufferQueue for SurfaceFlingerConsumer to use
    sp<IGraphicBufferProducer> producer;
    sp<IGraphicBufferConsumer> consumer;
    BufferQueue::createBufferQueue(&producer, &consumer);
    mProducer = new MonitoredProducer(producer, mFlinger);
    //创建一个SurfaceFlingerConsumer用于通知消费者消费
    mSurfaceFlingerConsumer = new SurfaceFlingerConsumer(consumer, mTextureName);
    mSurfaceFlingerConsumer->setConsumerUsageBits(getEffectiveUsage(0));
    //给消费者设置监听者
    mSurfaceFlingerConsumer->setContentsChangedListener(this);
    mSurfaceFlingerConsumer->setName(mName);

}

为了方便起见，我们将BufferQueueConsumer和SurfaceFlingerConsumer的类图都贴出来：

为了通知消费消费GraphicBuffer，这里提供了另外一个类ConsumerListener，位于frameworks/native/include/gui/IConsumerListener.h：

    ConsumerListener() { }
    virtual ~ConsumerListener() { }

    // onFrameAvailable is called from queueBuffer each time an additional
    // frame becomes available for consumption. This means that frames that
    // are queued while in asynchronous mode only trigger the callback if no
    // previous frames are pending. Frames queued while in synchronous mode
    // always trigger the callback.
    //
    // This is called without any lock held and can be called concurrently
    // by multiple threads.
    virtual void onFrameAvailable() = 0; /* Asynchronous */

    // onBuffersReleased is called to notify the buffer consumer that the
    // BufferQueue has released its references to one or more GraphicBuffers
    // contained in its slots.  The buffer consumer should then call
    // BufferQueue::getReleasedBuffers to retrieve the list of buffers
    //
    // This is called without any lock held and can be called concurrently
    // by multiple threads.
    virtual void onBuffersReleased() = 0; /* Asynchronous */

    // onSidebandStreamChanged is called to notify the buffer consumer that the
    // BufferQueue's sideband buffer stream has changed. This is called when a
    // stream is first attached and when it is either detached or replaced by a
    // different stream.
    virtual void onSidebandStreamChanged() = 0; /* Asynchronous */
};

两个纯虚函数，当一块buffer可以被消费时，onFrameAvailable会被调用；当BufferQueue通知consumer它已经释放其mSlot中的一个或多个GraphicBuffer的引用时，会调用onBuffersReleased。

那么什么时候注册的这个监听呢？我们需要跟随一下SurfaceFlingerConsumer 的构造函数，位于frameworks/native/services/surfaceflinger/SurfaceFlingerConsumer.h中：

SurfaceFlingerConsumer(const sp<IGraphicBufferConsumer>& consumer,
        uint32_t tex)
    //调用了GLConsumer的构造函数
    : GLConsumer(consumer, tex, GLConsumer::TEXTURE_EXTERNAL, false, false),
      mTransformToDisplayInverse(false)
{}

我们需要继续查看GLConsumer的构造函数，位于frameworks/native/libs/gui/GLConsumer.cpp：

GLConsumer::GLConsumer(const sp<IGraphicBufferConsumer>& bq, uint32_t tex,
        uint32_t texTarget, bool useFenceSync, bool isControlledByApp) :
    ConsumerBase(bq, isControlledByApp), //有调用了ConsumerBase的构造函数，猫腻应该在这里
    mCurrentTransform(0),
    mCurrentScalingMode(NATIVE_WINDOW_SCALING_MODE_FREEZE),
    mCurrentFence(Fence::NO_FENCE),
    mCurrentTimestamp(0),
    mCurrentFrameNumber(0),
    mDefaultWidth(1),
    mDefaultHeight(1),
    mFilteringEnabled(true),
    mTexName(tex),
    mUseFenceSync(useFenceSync),
    mTexTarget(texTarget),
    mEglDisplay(EGL_NO_DISPLAY),
    mEglContext(EGL_NO_CONTEXT),
    mCurrentTexture(BufferQueue::INVALID_BUFFER_SLOT),
    mAttached(true)
{
    ST_LOGV("GLConsumer");

    memcpy(mCurrentTransformMatrix, mtxIdentity,
            sizeof(mCurrentTransformMatrix));

    mConsumer->setConsumerUsageBits(DEFAULT_USAGE_FLAGS);
}

又调用了ConsumerBase的构造函数，猫腻应该在这里，我们继续查看ConsumerBase的构造函数，位于frameworks/native/libs/gui/ConsumerBase.cpp中：

ConsumerBase::ConsumerBase(const sp<IGraphicBufferConsumer>& bufferQueue, bool controlledByApp) :
        mAbandoned(false),
        mConsumer(bufferQueue) {
    // Choose a name using the PID and a process-unique ID.
    mName = String8::format("unnamed-%d-%d", getpid(), createProcessUniqueId());

    // Note that we can't create an sp<...>(this) in a ctor that will not keep a
    // reference once the ctor ends, as that would cause the refcount of 'this'
    // dropping to 0 at the end of the ctor.  Since all we need is a wp<...>
    // that's what we create.
    //创建监听者对象
    wp<ConsumerListener> listener = static_cast<ConsumerListener*>(this);
    //包装成一个代理
    sp<IConsumerListener> proxy = new BufferQueue::ProxyConsumerListener(listener);
    //mConsumer调用consumerConnect函数，通过mConsumer，把consumerListener注册到服务者类bufferQueuecore中
    status_t err = mConsumer->consumerConnect(proxy, controlledByApp);
    if (err != NO_ERROR) {
        CB_LOGE("ConsumerBase: error connecting to BufferQueue: %s (%d)",
                strerror(-err), err);
    } else {
        mConsumer->setConsumerName(mName);
    }
}

上面代码主要工作有：
1）创建监听者对象；
2）包装成一个代理；
3）mConsumer调用consumerConnect函数，通过mConsumer，把consumerListener注册到服务者类bufferQueuecore中。
那么注册操作就在于第三部。这里BufferQueueConsumer调用consumerConnect函数，位于frameworks/native/libs/gui/BufferQueueConsumer.h中：

virtual status_t consumerConnect(const sp<IConsumerListener>& consumer,
        bool controlledByApp) {
    return connect(consumer, controlledByApp);
}

在头文件里定义了consumerConnect函数，调用connect函数，位于frameworks/native/libs/gui/BufferQueueConsumer.cpp中：

status_t BufferQueueConsumer::connect(
        const sp<IConsumerListener>& consumerListener, bool controlledByApp) {
    ATRACE_CALL();

    if (consumerListener == NULL) {
        BQ_LOGE("connect(C): consumerListener may not be NULL");
        return BAD_VALUE;
    }

    BQ_LOGV("connect(C): controlledByApp=%s",
            controlledByApp ? "true" : "false");

    Mutex::Autolock lock(mCore->mMutex);

    if (mCore->mIsAbandoned) {
        BQ_LOGE("connect(C): BufferQueue has been abandoned");
        return NO_INIT;
    }
    //这里把consumerListener注册到服务者类bufferQueuecore中
    mCore->mConsumerListener = consumerListener;
    mCore->mConsumerControlledByApp = controlledByApp;

    return NO_ERROR;
}

connect连接，经过层层调用，把listener监听注册到bufferQueuecore中，
这样bufferQueuecore就可以利用这个监听通知到具体的消费者。

接着就是设置监听者：mSurfaceFlingerConsumer->setContentsChangedListener(this);我们可以看看他的操作：

void SurfaceFlingerConsumer::setContentsChangedListener(
        const wp<ContentsChangedListener>& listener) {
    //调用了ConsumerBase的setFrameAvailableListener函数
    setFrameAvailableListener(listener);
    Mutex::Autolock lock(mMutex);
    mContentsChangedListener = listener;
}
/**ConsumerBase的setFrameAvailableListener函数**/
void ConsumerBase::setFrameAvailableListener(
        const wp<FrameAvailableListener>& listener) {
    CB_LOGV("setFrameAvailableListener");
    Mutex::Autolock lock(mMutex);
    mFrameAvailableListener = listener;
}

这样就构成了完整的监听者模式了，有Observer，也有Observable。

这样就清楚了buffer的生产者，消费者，管理者之间的关系。

所以稍微总结一下BufferQueue机制，借助Chris Simmonds老爷子的话，就是如下内容：

Mechanism for passing GraphicBuffers to SurfaceFlinger
Contains an array of between 2 and 64 GraphicBuffers
Uses interface IGraphicBufferAlloc to allocate buffers (see later)
Provides two Binder interfaces：
- IGraphicBufferProducer for the client (Activity)
- IGraphicBufferConsumer for the consumer (SurfaceFlinger)
Buffers cycle between producer and consumer

分配图形缓冲区

首先buffer是共享缓冲区，故肯定会涉及到互斥锁，所以buffer的状态也有很多种，一般buffer大致会经过FREE->DEQUEUED->QUEUED->ACQUIRED->FREE这个过程。如果所示：

或者这样表示这个过程：

申请图形缓冲区

前面看到，bufferqueuecore中mSlots数组管理缓冲区，最大容量是64，这个mSlots一开始静态分配了64个bufferslot大小的空间，但是其中的数据缓冲区不是一次性分配的，不然就太浪费空间了，所以缓冲区的空间分配是动态的，具体就是producer在dequeuebuffer时，如果没有获取到可用的缓冲区，那就要重新分配空间了。

分配图形缓冲区，即GraphicBuffer，我们需要查看BufferQueueProducer的dequeuebuffer函数：

status_t BufferQueueProducer::dequeueBuffer(int *outSlot,
        sp<android::Fence> *outFence, bool async,
        uint32_t width, uint32_t height, uint32_t format, uint32_t usage) {
    ATRACE_CALL();
    { // Autolock scope
        Mutex::Autolock lock(mCore->mMutex);
        mConsumerName = mCore->mConsumerName;
    } // Autolock scope

    BQ_LOGV("dequeueBuffer: async=%s w=%u h=%u format=%#x, usage=%#x",
            async ? "true" : "false", width, height, format, usage);
    //宽高不正常，则返回失败
    if ((width && !height) || (!width && height)) {
        BQ_LOGE("dequeueBuffer: invalid size: w=%u h=%u", width, height);
        return BAD_VALUE;
    }
    //一些变量赋初值
    status_t returnFlags = NO_ERROR;
    EGLDisplay eglDisplay = EGL_NO_DISPLAY;
    EGLSyncKHR eglFence = EGL_NO_SYNC_KHR;
    bool attachedByConsumer = false;

    { // Autolock scope
        Mutex::Autolock lock(mCore->mMutex);
        //如果正在申请Grabuffer，则要wait。里面是一个mIsAllocating标志位判断，如果为true则要等待
        mCore->waitWhileAllocatingLocked();
        //如果format为0，则赋为初值PIXEL_FORMAT_RGBA_8888
        if (format == 0) {
            format = mCore->mDefaultBufferFormat;
        }

        // Enable the usage bits the consumer requested
        usage |= mCore->mConsumerUsageBits;

        int found;//先在mSlot数组中查找FREE状态的slot，如果找到了就返回这个slot中的index。
        status_t status = waitForFreeSlotThenRelock("dequeueBuffer", async,
                &found, &returnFlags);
        if (status != NO_ERROR) {
            return status;
        }

        // This should not happen
        //这种情况一般不会发生，因为如何found是INVALID_BUFFER_SLOT状态，上面的status就不会是NO_Error,就不会走到这里
        if (found == BufferQueueCore::INVALID_BUFFER_SLOT) {
            BQ_LOGE("dequeueBuffer: no available buffer slots");
            return -EBUSY;
        }
        //将找到的slot的index赋给外面传入的outSlot指向内容
        *outSlot = found;
        ATRACE_BUFFER_INDEX(found);

        attachedByConsumer = mSlots[found].mAttachedByConsumer;

        const bool useDefaultSize = !width && !height;
        if (useDefaultSize) {
            width = mCore->mDefaultWidth;
            height = mCore->mDefaultHeight;
        }
        //改变BufferState状态为DEQUEUED
        mSlots[found].mBufferState = BufferSlot::DEQUEUED;
        //然后将返回index的slot的Graphicbuffer赋给buffer变量
        const sp<GraphicBuffer>& buffer(mSlots[found].mGraphicBuffer);
        //判断这个GraphicBuffer是否需要重新分配空间，判断条件就是buffer为空，因为它初始值是null，第一次使用它需要分配空间，
        //如果不为null，但是buffer的width、height、format、usage属性跟要求的不一致，也要重新分配
        if ((buffer == NULL) ||
                (static_cast<uint32_t>(buffer->width) != width) ||
                (static_cast<uint32_t>(buffer->height) != height) ||
                (static_cast<uint32_t>(buffer->format) != format) ||
                ((static_cast<uint32_t>(buffer->usage) & usage) != usage))
        {
            //如果需要重新分配GraphicBuffer，先初始化这些变量
            mSlots[found].mAcquireCalled = false;
            mSlots[found].mGraphicBuffer = NULL;
            mSlots[found].mRequestBufferCalled = false;
            mSlots[found].mEglDisplay = EGL_NO_DISPLAY;
            mSlots[found].mEglFence = EGL_NO_SYNC_KHR;
            mSlots[found].mFence = Fence::NO_FENCE;
            //增加BUFFER_NEEDS_REALLOCATION标志，已重新分配GraphicBuffer
            returnFlags |= BUFFER_NEEDS_REALLOCATION;
        }

        if (CC_UNLIKELY(mSlots[found].mFence == NULL)) {
            BQ_LOGE("dequeueBuffer: about to return a NULL fence - "
                    "slot=%d w=%d h=%d format=%u",
                    found, buffer->width, buffer->height, buffer->format);
        }
        //给一些临时变量赋值
        eglDisplay = mSlots[found].mEglDisplay;
        eglFence = mSlots[found].mEglFence;
        *outFence = mSlots[found].mFence;
        //给fence变量赋初值
        mSlots[found].mEglFence = EGL_NO_SYNC_KHR;
        mSlots[found].mFence = Fence::NO_FENCE;
    } // Autolock scope
    //如果需要重新分配GraphicBuffer
    if (returnFlags & BUFFER_NEEDS_REALLOCATION) {
        status_t error;
        BQ_LOGV("dequeueBuffer: allocating a new buffer for slot %d", *outSlot);
        //需要重新分配，调用BufferQueueCore中的GraphicBufferAlloc中函数createGraphicBuffer，生成一个newGraphicBuffer
        sp<GraphicBuffer> graphicBuffer(mCore->mAllocator->createGraphicBuffer(
                    width, height, format, usage, &error));
        if (graphicBuffer == NULL) {
            BQ_LOGE("dequeueBuffer: createGraphicBuffer failed");
            return error;
        }

        { // Autolock scope
            Mutex::Autolock lock(mCore->mMutex);

            if (mCore->mIsAbandoned) {
                BQ_LOGE("dequeueBuffer: BufferQueue has been abandoned");
                return NO_INIT;
            }
            ////新分配的buffer，将slot的mFrameNumber 置为最大。mFrameNumber 用于LRU排序
            mSlots[*outSlot].mFrameNumber = UINT32_MAX;
            //将分配的buffer赋给slot中的mGraphicBuffer 
            mSlots[*outSlot].mGraphicBuffer = graphicBuffer;
        } // Autolock scope
    }

    if (attachedByConsumer) {
        returnFlags |= BUFFER_NEEDS_REALLOCATION;
    }
    //如果eglFence不等于EGL_NO_SYNC_KHR。Fence我们后面会讲到，一种围栏机制
    if (eglFence != EGL_NO_SYNC_KHR) {
        //等待Buffer状态就绪，然后fence围栏放行
        EGLint result = eglClientWaitSyncKHR(eglDisplay, eglFence, 0,
                1000000000);
        // If something goes wrong, log the error, but return the buffer without
        // synchronizing access to it. It's too late at this point to abort the
        // dequeue operation.
        if (result == EGL_FALSE) {
            BQ_LOGE("dequeueBuffer: error %#x waiting for fence",
                    eglGetError());
        } else if (result == EGL_TIMEOUT_EXPIRED_KHR) {
            BQ_LOGE("dequeueBuffer: timeout waiting for fence");
        }
        eglDestroySyncKHR(eglDisplay, eglFence);
    }

    BQ_LOGV("dequeueBuffer: returning slot=%d/%" PRIu64 " buf=%p flags=%#x",
            *outSlot,
            mSlots[*outSlot].mFrameNumber,
            mSlots[*outSlot].mGraphicBuffer->handle, returnFlags);

    return returnFlags;
}

代码虽然多，但是逻辑不复杂，我们分步查看：

1）先在mSlot数组中查找FREE状态的slot，如果找到了就返回这个slot中的index。这个操作是调用了waitForFreeSlotThenRelock函数，我们看看这个函数的实现：

status_t BufferQueueProducer::waitForFreeSlotThenRelock(const char* caller,
        bool async, int* found, status_t* returnFlags) const {
    bool tryAgain = true;//默认是true
    while (tryAgain) {
        if (mCore->mIsAbandoned) {//如果没有初始化，BufferQueue被abandoned
            BQ_LOGE("%s: BufferQueue has been abandoned", caller);
            return NO_INIT;
        }
        //getMaxBufferCountLocked returns the maximum number of buffers that can be allocated at once
        //注释还有一些，不贴了。就是获取一次申请的buffer的最大值。查看了代码，就是所有状态的buffer个数。
        const int maxBufferCount = mCore->getMaxBufferCountLocked(async);
        //如果async为true，即异步操作，并且mOverrideMaxBufferCount不为0
        //（一般mOverrideMaxBufferCount是在BufferQueueProducer调用setBufferCount函数改变，
        //这个函数会更新mSlot中所有Slot的状态为未分配的，并把ower还给BufferQueue）
        if (async && mCore->mOverrideMaxBufferCount) {
            // FIXME: Some drivers are manually setting the buffer count
            // (which they shouldn't), so we do this extra test here to
            // handle that case. This is TEMPORARY until we get this fixed.
            //因为是异步的关系，一些驱动会修改buffer count，但是返回不及时，所以这两个值可能不相等
            if (mCore->mOverrideMaxBufferCount < maxBufferCount) {
                BQ_LOGE("%s: async mode is invalid with buffer count override",
                        caller);
                return BAD_VALUE;
            }
        }
        
        // Free up any buffers that are in slots beyond the max buffer count
        //释放所有超出buffer数组最大数64的buffer
        for (int s = maxBufferCount; s < BufferQueueDefs::NUM_BUFFER_SLOTS; ++s) {
            assert(mSlots[s].mBufferState == BufferSlot::FREE);
            if (mSlots[s].mGraphicBuffer != NULL) {
                mCore->freeBufferLocked(s);
                *returnFlags |= RELEASE_ALL_BUFFERS;
            }
        }

        // Look for a free buffer to give to the client
        //开始查找FREE状态的Buffer，并返回
        *found = BufferQueueCore::INVALID_BUFFER_SLOT;
        int dequeuedCount = 0;
        int acquiredCount = 0;
        for (int s = 0; s < maxBufferCount; ++s) {
            switch (mSlots[s].mBufferState) {
                case BufferSlot::DEQUEUED:
                    ++dequeuedCount;//DEQUEUED + 1
                    break;
                case BufferSlot::ACQUIRED:
                    ++acquiredCount;//ACQUIRED + 1
                    break;
                case BufferSlot::FREE:
                    // We return the oldest of the free buffers to avoid
                    // stalling the producer if possible, since the consumer
                    // may still have pending reads of in-flight buffers
                    //返回最老的FREE buffer，为了避免当consumer还在等待消费pending的正在起飞的buffer时候，producer突然GG了
                    if (*found == BufferQueueCore::INVALID_BUFFER_SLOT ||//第一次找到FREE buffer，会将found指针指向这个index
                            //下次来的FREE buffer，就和上此找到的buffer对比slot的mFrameNumber ，找到mFrameNumber 最小的。
                            //这个就是根绝mFrameNumber 的大小进行LRU排序，最新的就是mFrameNumber 最大的，最老的就是mFrameNumber 最小的
                            mSlots[s].mFrameNumber < mSlots[*found].mFrameNumber) {
                        *found = s;
                    }
                    break;
                default:
                    break;
            }
        }

        // Producers are not allowed to dequeue more than one buffer if they
        // did not set a buffer count
        //Producers 如果没有调用setBufferCount是不允许dequeue buffer的
        if (!mCore->mOverrideMaxBufferCount && dequeuedCount) {
            BQ_LOGE("%s: can't dequeue multiple buffers without setting the "
                    "buffer count", caller);
            return INVALID_OPERATION;
        }

        // See whether a buffer has been queued since the last
        // setBufferCount so we know whether to perform the min undequeued
        // buffers check below
        //在queueBuffer调用后，mBufferHasBeenQueued会置为true
        //如果在上次setBufferCount调用后，当buffer被queue进入BufferQueue，
        //这时候需要检查undequeue的数量是否大于最小的临界值
        if (mCore->mBufferHasBeenQueued) {
            // Make sure the producer is not trying to dequeue more buffers
            // than allowed
            //总count - dequeue的count = undequeue的count
            const int newUndequeuedCount =
                maxBufferCount - (dequeuedCount + 1);
            const int minUndequeuedCount =
                mCore->getMinUndequeuedBufferCountLocked(async);
            if (newUndequeuedCount < minUndequeuedCount) {
                BQ_LOGE("%s: min undequeued buffer count (%d) exceeded "
                        "(dequeued=%d undequeued=%d)",
                        caller, minUndequeuedCount,
                        dequeuedCount, newUndequeuedCount);
                return INVALID_OPERATION;
            }
        }

        // If we disconnect and reconnect quickly, we can be in a state where
        // our slots are empty but we have many buffers in the queue. This can
        // cause us to run out of memory if we outrun the consumer. Wait here if
        // it looks like we have too many buffers queued up.
        //如果我们调用disconnect后迅速的reconnect，会出现mSlot数组为空但是mQueue队列中的BufferItem不为空
        //所以这样会造成内存耗尽的后果
        //就是判断放入mQueue中BufferItem的个数是否大于mSlot中的个数
        //mQueue是用来存放申请的缓冲区的，是一个Vector
        bool tooManyBuffers = mCore->mQueue.size()
                            > static_cast<size_t>(maxBufferCount);
        if (tooManyBuffers) {
            BQ_LOGV("%s: queue size is %zu, waiting", caller,
                    mCore->mQueue.size());
        }

        // If no buffer is found, or if the queue has too many buffers
        // outstanding, wait for a buffer to be acquired or released, or for the
        // max buffer count to change.
        //如果没有找到FREE的buffer，或者mQueue中有太多buffer占据内存未释放
        //那么等待buffer被acquired or released；
        //或者等待最大buffer个数改变
        tryAgain = (*found == BufferQueueCore::INVALID_BUFFER_SLOT) ||
                   tooManyBuffers;
        if (tryAgain) {
            // Return an error if we're in non-blocking mode (producer and
            // consumer are controlled by the application).
            // However, the consumer is allowed to briefly acquire an extra
            // buffer (which could cause us to have to wait here), which is
            // okay, since it is only used to implement an atomic acquire +
            // release (e.g., in GLConsumer::updateTexImage())
            if (mCore->mDequeueBufferCannotBlock &&
                    (acquiredCount <= mCore->mMaxAcquiredBufferCount)) {
                return WOULD_BLOCK;
            }
            //等待有buffer可以返回
            mCore->mDequeueCondition.wait(mCore->mMutex);
        }
    } // while (tryAgain)

    return NO_ERROR;
}

代码虽然多，但是大多数都是处理特殊情况的。核心就是从现存maxBufferCount找出FREE状态的slot，然后根据LRU匹配，取出最老的slot，然后返回index给found指针内容。
这样取出来FREE的slot（如果能找到）。
如果所有的buffer都不是free的，则等待。

2）将找到的buf所对应的状态修改为DEQUEUED；

3）然后将上面查询mSlot中返回index的slot的Graphicbuffer赋给buffer变量；

4）判断这个GraphicBuffer是否需要重新分配空间，判断条件就是buffer为空，因为它初始值是null，第一次使用它需要分配空间；如果不为null，但是buffer的width、height、format、usage属性跟要求的不一致，也要重新分配，并打上BUFFER_NEEDS_REALLOCATION标志位。

5）如果上面的buffer为null，则需要重新分配GraphicBuffer，调用BufferQueueCore中的GraphicBufferAlloc中函数createGraphicBuffer，生成一个new GraphicBuffer。

6）等待eglFence状态就绪。Fence机制我们以后会讲到。

创建图形缓冲区

GraphicBuffer创建

所以上述流程的核心是GraphicBuffer的分配，我们需要沿着上面继续分析。因此最后BufferQueueProducer中的dequeueBuffer函数中调用mCore->mAllocator的createGraphicBuffer函数就是调用了GraphicBufferAlloc的createGraphicBufferAlloc函数。mAllocator的类型为sp< IGraphicBufferAlloc >，要跨进程调用SurfaceFlinger的createGraphicBufferAlloc函数，上面讲过了。

上面刚刚说mAllocator的类型为sp< IGraphicBufferAlloc >，所以创建GraphicBuffer的函数createGraphicBuffer也需要Bp/Bn 的IPC跨进程调用过程。GraphicBuffer通过Binder传递对象是Parcel类型可序列化的，所以他要从模板类Flattenable派生。因为这个牵扯到内存缓冲区的fd传递到客户进程，所以我们放到后面讲。

所以我们先忽略IPC过程，直接查看生成结果，位于frameworks/native/libs/gui/GraphicBufferAlloc.cpp中：

sp<GraphicBuffer> GraphicBufferAlloc::createGraphicBuffer(uint32_t w, uint32_t h,
        PixelFormat format, uint32_t usage, status_t* error) {
    //创建一个GraphicBuffer对象
    sp<GraphicBuffer> graphicBuffer(new GraphicBuffer(w, h, format, usage));
    status_t err = graphicBuffer->initCheck();
    *error = err;
    if (err != 0 || graphicBuffer->handle == 0) {
        if (err == NO_MEMORY) {
            GraphicBuffer::dumpAllocationsToSystemLog();
        }
        ALOGE("GraphicBufferAlloc::createGraphicBuffer(w=%d, h=%d) "
             "failed (%s), handle=%p",
                w, h, strerror(-err), graphicBuffer->handle);
        return 0;
    }
    return graphicBuffer;
}

上面创建一个GraphicBuffer对象，我们看看GraphicBuffer的构造函数，位于frameworks/native/libs/ui/GraphicBuffer.cpp：

GraphicBuffer::GraphicBuffer(uint32_t w, uint32_t h, 
        PixelFormat reqFormat, uint32_t reqUsage)
    : BASE(), mOwner(ownData), mBufferMapper(GraphicBufferMapper::get()),
      mInitCheck(NO_ERROR), mId(getUniqueId())
{
    width  = 
    height = 
    stride = 
    format = 
    usage  = 0;
    handle = NULL;
    //这里调用了initSize函数
    mInitCheck = initSize(w, h, reqFormat, reqUsage);
}

构造函数给一些变量赋了初值，并调用了initSize函数，我们看看这个函数：

status_t GraphicBuffer::initSize(uint32_t w, uint32_t h, PixelFormat format,
        uint32_t reqUsage)
{
    //获取一个GraphicBufferAllocator对象，它是个单例
    GraphicBufferAllocator& allocator = GraphicBufferAllocator::get();
    //调用allocator 的alloc函数
    status_t err = allocator.alloc(w, h, format, reqUsage, &handle, &stride);
    if (err == NO_ERROR) {
        this->width  = w;
        this->height = h;
        this->format = format;
        this->usage  = reqUsage;
    }
    return err;
}

先创建一个GraphicBufferAllocator的单例对象，我们先看看它的构造函数，位于frameworks/native/libs/ui/GraphicBufferAllocator.cpp中：


alloc_device_t  *mAllocDev;

GraphicBufferAllocator::GraphicBufferAllocator()
    : mAllocDev(0)
{
    hw_module_t const* module;
    //加载gralloc设备
    int err = hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module);
    ALOGE_IF(err, "FATAL: can't find the %s module", GRALLOC_HARDWARE_MODULE_ID);
    if (err == 0) {
        //打开gralloc设备
        gralloc_open(module, &mAllocDev);
    }
}

GraphicBufferAllocator构造函数里主要是加载了gralloc设备，然后打开它，因此mAllocDev指向了Gralloc模块。这一部分可以查看Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现，Gralloc模块的加载过程、Gralloc设备的打开过程。

加载完Gralloc模块，并打开之后，接着就是分配图形缓冲区了。我们可以继续往下看看是不是，查看GraphicBufferAllocator的alloc函数：

status_t GraphicBufferAllocator::alloc(uint32_t w, uint32_t h, PixelFormat format,
        int usage, buffer_handle_t* handle, int32_t* stride)
{
    ATRACE_CALL();
    // make sure to not allocate a N x 0 or 0 x N buffer, since this is
    // allowed from an API stand-point allocate a 1x1 buffer instead.
    if (!w || !h)
        w = h = 1;

    // we have a h/w allocator and h/w buffer is requested
    status_t err; 
    //这里内部是调用Gralloc模块中的函数gralloc_alloc来分配一块图形缓冲区
    err = mAllocDev->alloc(mAllocDev, w, h, format, usage, handle, stride);

    ALOGW_IF(err, "alloc(%u, %u, %d, %08x, ...) failed %d (%s)",
            w, h, format, usage, err, strerror(-err));
    
    if (err == NO_ERROR) {
        Mutex::Autolock _l(sLock);
        KeyedVector<buffer_handle_t, alloc_rec_t>& list(sAllocList);
        int bpp = bytesPerPixel(format);
        if (bpp < 0) {
            // probably a HAL custom format. in any case, we don't know
            // what its pixel size is.
            bpp = 0;
        }
        alloc_rec_t rec;
        rec.w = w;
        rec.h = h;
        rec.s = *stride;
        rec.format = format;
        rec.usage = usage;
        rec.size = h * stride[0] * bpp;
        list.add(*handle, rec);
    }

    return err;
}

这里调用alloc分配了一块共享的内存缓冲区，就是我们的图形缓冲区。内部是调用Gralloc模块中的函数gralloc_alloc，可以产查看Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现，分配图形缓冲区。

这样我们GraphicBuffer的创建工作就完成了。

既然GraphicBuffer中的缓冲区是共享内存，我们知道使用共享内存需要传递共享内存的句柄fd。下面我们看看是如何传到客户进程的，填掉我们上面的坑。

内存缓冲区映射到应用进程

GraphicBuffer类是从模板类Flattenable派生，这个派生类可以通过Parcel传递，通常派生类需要重载flatten和unflatten方法，用于对象的序列化和反序列化。

为了方便分析，我们可以看看GraphicBuffer的类图：

上面说到mAllocator的类型为sp< IGraphicBufferAlloc >，它的创建GraphicBuffer的函数createGraphicBuffer也需要Bp/Bn 的IPC跨进程调用过程，序列化传递和反序列话取出这里用于IPC传递数据，我们可以在这里看看客户端和服务端的工作流程。
我们先看看客户端Bp端，位于frameworks/native/libs/gui/IGraphicBufferAlloc.cpp中：

class BpGraphicBufferAlloc : public BpInterface<IGraphicBufferAlloc>
{
public:
    BpGraphicBufferAlloc(const sp<IBinder>& impl)
        : BpInterface<IGraphicBufferAlloc>(impl)
    {
    }
    //客户端创建图形缓冲区函数
    virtual sp<GraphicBuffer> createGraphicBuffer(uint32_t w, uint32_t h,
            PixelFormat format, uint32_t usage, status_t* error) {
        Parcel data, reply;
        data.writeInterfaceToken(IGraphicBufferAlloc::getInterfaceDescriptor());
        data.writeInt32(w);
        data.writeInt32(h);
        data.writeInt32(format);
        data.writeInt32(usage);
        //通过binder驱动，执行服务端对应函数。这里服务端是将创建的GraphicBuffer序列化后，塞给replay
        remote()->transact(CREATE_GRAPHIC_BUFFER, data, &reply);
        sp<GraphicBuffer> graphicBuffer;
        status_t result = reply.readInt32();
        if (result == NO_ERROR) {
            //创建一个空壳子
            graphicBuffer = new GraphicBuffer();
            //然后客户端从服务端（SurfaceFlinger）返回的序列化后的replay，
            //反序列化出Graphicbuffer，放入空壳子中
            result = reply.read(*graphicBuffer);
            // reply.readStrongBinder();
            // here we don't even have to read the BufferReference from
            // the parcel, it'll die with the parcel.
        }
        *error = result;
        return graphicBuffer;
    }
};

客户端这里主要通过binder驱动，取出从服务端返回的序列化后的对象replay，然后自己造一个空壳子，然后读取replay信息，反序列化出GraphicBuffer。

那么服务端（SurfaceFlinger）创建GraphicBuffer并反序列化就在Bn端，我们看看Bn端实现，同样位于位于frameworks/native/libs/gui/IGraphicBufferAlloc.cpp中：

status_t BnGraphicBufferAlloc::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
    // codes that don't require permission check

    /* BufferReference just keeps a strong reference to a
     * GraphicBuffer until it is destroyed (that is, until
     * no local or remote process have a reference to it).
     */
    class BufferReference : public BBinder {
        sp<GraphicBuffer> buffer;
    public:
        BufferReference(const sp<GraphicBuffer>& buffer) : buffer(buffer) { }
    };


    switch(code) {
        case CREATE_GRAPHIC_BUFFER: {
            CHECK_INTERFACE(IGraphicBufferAlloc, data, reply);
            uint32_t w = data.readInt32();
            uint32_t h = data.readInt32();
            PixelFormat format = data.readInt32();
            uint32_t usage = data.readInt32();
            status_t error;
            //调用GraphicBufferAlloc的createGraphicBuffer函数，创建一个GraphicBuffer实例
            sp<GraphicBuffer> result =
                    createGraphicBuffer(w, h, format, usage, &error);
            reply->writeInt32(error);
            if (result != 0) {
                ////GraphicBuffer进行序列化，传给client
                reply->write(*result);
                // We add a BufferReference to this parcel to make sure the
                // buffer stays alive until the GraphicBuffer object on
                // the other side has been created.
                // This is needed so that the buffer handle can be
                // registered before the buffer is destroyed on implementations
                // that do not use file-descriptors to track their buffers.
                reply->writeStrongBinder( new BufferReference(result) );
            }
            return NO_ERROR;
        } break;
        default:
            return BBinder::onTransact(code, data, reply, flags);
    }
}

GraphicBufferAlloc的createGraphicBuffer函数我们上面分析过了。这样就将创建的GraphicBuffer实例序列化后，在通过binder驱动传给client。

我们知道，一个对象要在进程间传输必须继承于Flattenable类，并且实现flatten和unflatten方法，flatten方法用于序列化该对象，unflatten方法用于反序列化对象。

上面说到GraphicBuffer中的缓冲区是共享内存，使用共享内存需要传递共享内存的句柄fd，那么这个fd的传递就应该在GraphicBuffer的序列化/反序列化中，我们就来看看这个过程。

这里我先回顾一下Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现的内容：

图形缓冲区可以从系统帧缓冲区分配也可以从内存中分配，分配一个图形缓冲区后还需要将该图形缓冲区映射到分配该buffer的进程地址空间来，在Android系统中，图形缓冲区的管理由SurfaceFlinger服务来负责。在系统帧缓冲区中分配的图形缓冲区是在SurfaceFlinger服务中使用，而在内存中分配的图形缓冲区既可以在SurfaceFlinger服务中使用，也可以在其它的应用程序中使用。当其它的应用程序需要使用图形缓冲区的时候，它们就会请求SurfaceFlinger服务为它们分配并将SurfaceFlinger服务返回来的图形缓冲区映射到应用程序进程地址空间。在从内存中分配buffer时，已经将分配的buffer映射到了SurfaceFlinger服务进程地址空间，如果该buffer是应用程序请求SurfaceFlinger服务为它们分配的，那么还需要将SurfaceFlinger服务返回来的图形缓冲区映射到应用程序进程地址空间。

GraphicBuffer类从模板类Flattenable派生，这个派生类可以通过Parcel传递，通常派生类需要重载flatten和unflatten方法，用于对象的序列化和反序列化。

1）将一个对象写入到Parcel中，需要使用flatten函数序列化该对象，我们先来看下flatten函数：

status_t GraphicBuffer::flatten(void*& buffer, size_t& size, int*& fds, size_t& count) const {
    size_t sizeNeeded = GraphicBuffer::getFlattenedSize();
    if (size < sizeNeeded) return NO_MEMORY;

    size_t fdCountNeeded = GraphicBuffer::getFdCount();
    if (count < fdCountNeeded) return NO_MEMORY;

    int32_t* buf = static_cast<int32_t*>(buffer);
    buf[0] = 'GBFR';
    buf[1] = width;
    buf[2] = height;
    buf[3] = stride;
    buf[4] = format;
    buf[5] = usage;
    buf[6] = static_cast<int32_t>(mId >> 32);
    buf[7] = static_cast<int32_t>(mId & 0xFFFFFFFFull);
    buf[8] = 0;
    buf[9] = 0;

    if (handle) {
        buf[8] = handle->numFds;
        buf[9] = handle->numInts;
        native_handle_t const* const h = handle;
        //把handle中的data复制到fds中 
        memcpy(fds,     h->data,             h->numFds*sizeof(int));
        memcpy(&buf[10], h->data + h->numFds, h->numInts*sizeof(int));
    }

    buffer = reinterpret_cast<void*>(static_cast<int*>(buffer) + sizeNeeded);
    size -= sizeNeeded;
    if (handle) {
        fds += handle->numFds;
        count -= handle->numFds;
    }

    return NO_ERROR;
}

这个handle类型为native_handle_t ，且typedef成了buffer_handle_t，如果忘记了这一部分，可以查看Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现。我们贴一下它的定义：

typedef struct native_handle  
{  
    int version; //设置为结构体native_handle_t的大小，用来标识结构体native_handle_t的版本  
    int numFds;  //表示结构体native_handle_t所包含的文件描述符的个数，这些文件描述符保存在成员变量data所指向的一块缓冲区中。  
    int numInts; //表示结构体native_handle_t所包含的整数值的个数，这些整数保存在成员变量data所指向的一块缓冲区中。  
    int data[0]; //指向的一块缓冲区中  
} native_handle_t;

所以我们回到flatten函数中，fds参数用来传递文件句柄，函数把handle中的表示指向图形缓冲区文件描述符句柄复制到fds中，因此这些句柄就能通过binder传递到目标进程中去。

2）在应用程序读取来自服务进程的GraphicBuffer对象时，也就是result = reply.read(*p)，会调用GraphicBuffer类的unflatten函数进行反序列化过程：

status_t GraphicBuffer::unflatten(
        void const*& buffer, size_t& size, int const*& fds, size_t& count) {
    if (size < 8*sizeof(int)) return NO_MEMORY;

    int const* buf = static_cast<int const*>(buffer);
    if (buf[0] != 'GBFR') return BAD_TYPE;

    const size_t numFds  = buf[8];
    const size_t numInts = buf[9];

    const size_t sizeNeeded = (10 + numInts) * sizeof(int);
    if (size < sizeNeeded) return NO_MEMORY;

    size_t fdCountNeeded = 0;
    if (count < fdCountNeeded) return NO_MEMORY;

    if (handle) {
        // free previous handle if any
        free_handle();
    }

    if (numFds || numInts) {
        width  = buf[1];
        height = buf[2];
        stride = buf[3];
        format = buf[4];
        usage  = buf[5];
        //创建一个native_handle对象
        native_handle* h = native_handle_create(numFds, numInts);
        //将fds复制到native_handle对象的data中，和flatten操作相反
        memcpy(h->data,          fds,     numFds*sizeof(int));
        memcpy(h->data + numFds, &buf[10], numInts*sizeof(int));
        handle = h;
    } else {
        width = height = stride = format = usage = 0;
        handle = NULL;
    }

    mId = static_cast<uint64_t>(buf[6]) << 32;
    mId |= static_cast<uint32_t>(buf[7]);

    mOwner = ownHandle;

    if (handle != 0) {
        //使用GraphicBufferMapper将服务端创建的图形缓冲区映射到当前进程地址空间  
        status_t err = mBufferMapper.registerBuffer(handle);
        if (err != NO_ERROR) {
            width = height = stride = format = usage = 0;
            handle = NULL;
            ALOGE("unflatten: registerBuffer failed: %s (%d)",
                    strerror(-err), err);
            return err;
        }
    }

    buffer = reinterpret_cast<void const*>(static_cast<int const*>(buffer) + sizeNeeded);
    size -= sizeNeeded;
    fds += numFds;
    count -= numFds;

    return NO_ERROR;
}

调用unflatten函数时，共享区的文件句柄已经准备好了，但是内存还没有进行映射，调用了mBufferMapper.registerBuffer函数来进行内存映射。
GraphicBufferMapper是单例的模板类派生的，mBufferMapper对象在GraphicBuffer的构造函数中初始化赋值了，上面我们列出过了。我们看看GraphicBufferMapper的构造函数，位于frameworks/native/libs/ui/GraphicBufferMapper.cpp：

GraphicBufferMapper::GraphicBufferMapper()
    : mAllocMod(0)
{
    hw_module_t const* module;
    //加载gralloc模块
    int err = hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module);
    ALOGE_IF(err, "FATAL: can't find the %s module", GRALLOC_HARDWARE_MODULE_ID);
    if (err == 0) {
        ////将hw_module_t的指针转换为gralloc_module_t类型指针 
        mAllocMod = (gralloc_module_t const *)module;
    }
}

这里根据模块ID加载Gralloc模块，并得到Gralloc模块的HMI符号首地址，并强制转换为gralloc_module_t类型指针。

我们接着看下GraphicBufferMapper::registerBuffer函数：

status_t GraphicBufferMapper::registerBuffer(buffer_handle_t handle)
{
    ATRACE_CALL();
    status_t err;
    //将服务端创建的图形缓冲区映射到当前进程地址空间
    err = mAllocMod->registerBuffer(mAllocMod, handle);

    ALOGW_IF(err, "registerBuffer(%p) failed %d (%s)",
            handle, err, strerror(-err));
    return err;
}

调用了mAllocMod的registerBuffer函数，mAllocMod同样是指向了Gralloc模块的指针，因此实际是调用了Gralloc模块的gralloc_register_buffer函数。这个函数就是调用了mmap来进行共享内存的映射。
这一部分仍然可以查看Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现。我们仍然回顾一下以前的内容：

registerBuffer和unregisterBuffer分别用来注册和注销一个指定的图形缓冲区，所谓注册图形缓冲区，实际上就是将一块图形缓冲区映射到一个进程的地址空间去，而注销图形缓冲区就是执行相反的操作。lock和unlock分别用来锁定和解锁一个指定的图形缓冲区，在访问一块图形缓冲区的时候，例如，向一块图形缓冲写入内容的时候，需要将该图形缓冲区锁定，用来避免访问冲突。在锁定一块图形缓冲区的时候，可以指定要锁定的图形绘冲区的位置以及大小，这是通过参数l、t、w和h来指定的，其中，参数l和t指定的是要访问的图形缓冲区的左上角位置，而参数w和h指定的是要访问的图形缓冲区的宽度和长度。锁定之后，就可以获得由参数参数l、t、w和h所圈定的一块缓冲区的起始地址，保存在输出参数vaddr中。另一方面，在访问完成一块图形缓冲区之后，需要解除这块图形缓冲区的锁定。

这就是内存缓冲区映射到应用进程的过程。因为需要映射共享内存，所以必须要序列化和反序列Pracel对象。如下图：

这里我们创建GraphicBuffer流程就分析完了。

小结

本节主要分析GraphicBuffer的创建过程，下一节我们分析对它的管理流程。

Android SurfaceFlinger 学习之路(六)----SurfaceFlinger创建Surface

2017-06-17T11:57:29.000Z

这次需要了解一下SurfaceFlinger创建Surface的流程，可能比较短，因为后面GraphicBuffer管理可能会比较多。另外，应用层创建Surface以后会继续学习，并且流畅会比较长，因为设计到了WMS等等。

图层分析

在分析Android应用程序请求SurfaceFlinger创建Surface之前，我们首先了解一下Surface是由什么组成的。我们可以将Surface理解为一个绘图表面，Android应用程序负责往这个绘图表面上填内容，而SurfaceFlinger服务负责将这个绘图表面的内容取出来，并且渲染在显示屏上。

猜测

每个应用程序对应着一个或者多个图形界面，而每一个界面我们称之为surface，或者说是window，如下图：

上图我们可以看到三个surface，在这里我们需要弄明白的问题是：

每个surface在屏幕上有它的位置、大小，然后每个surface 里面还有要显示的内容，内容、大小、位置这些元素，在我们改变应用程序的时候都可能会改变，改变时应该如何处理？
然后就各个surface 之间可能有重叠，比如说在上面的简略图中，灰色覆盖了橙色，绿色覆盖了橙色，而且还具有一定透明度。这种层之间的关系应该如何描述？

对于第一个问题，我们需要一个结构来记录应用程序界面的位置，大小，以及一个buffer 来记录需要显示的内容，所以这就是我们surface 的概念，surface 实际我们可以把它理解成一个容器，这个容器记录着应用程序界面的控制信息，比如说大小啊，位置啊，而它还有buffer 来专门存储需要显示的内容。
对于第二个问题，我们可以想象在屏幕平面的垂直方向还有一个Z 轴，所有的surface 根据在Z 轴上的坐标来确定前后，这样就可以描述各个surface 之间的上下覆盖关系了，而这个在Z 轴上的顺序，图形上有个专业术语叫Z-order 。

在这里还存在一个问题，那就是当存在图形重合的时候应该如何处理呢，而且可能有些surface 还带有透明信息，这里就是我们SurfaceFlinger 需要解决问题，它要把各个surface 组合(compose/merge) 成一个main Surface ，最后将Main Surface 的内容发送给FB，这样屏幕上就能看到我们想要的效果。

概述

在Android中，Window与Surface一一对应。如果说Window关心的是层次和布局，是从设计者角度定义的类，Surface则从实现角度出发，是工程师关系和考虑的类。Window的内容是变化的，Surface需要有空间来记录每个时刻Window的内容。在Android的SurfaceFlinger实现里，通常一个Surface有两块 Buffer, 一块用于绘画，一块用于显示，两个Buffer按照固定的频率进行交换，从而实现Window的动态刷新。

但是，在SurfaceFlinger服务这一侧，绘图表面使用Layer类来描述。Layer是SurfaceFlinger 进行合成的基本操作单元。Layer在应用请求创建Surface的时候在SurfaceFlinger内部创建，因此一个Surface对应一个 Layer, 但注意，Surface不一定对应于Window，Android中有些Surface并不跟某个Window相关，而是有程序直接创建，比如说 StrictMode，一块红色的背景，用于提示示Java代码中的一些异常, 还有SurfaceView, 用于显示有硬件输出的视频内容等。

Each Layer has：

Z order
Alpha value from 0 to 255
visibleRegion
crop region
transformation: rotate 0, 90, 180, 270: flip H, V: scale

TransparantRegion：完全透明的区域，在它之下的区域将被显示出来。
OpaqueRegion: 完全不透明的区域，是否显示取决于它上面是否有遮挡或是否透明。
VisibleRegion: 可见区域，包括完全不透明无遮挡区域或半透明区域。 visibleRegion = Region - above OpaqueRegion.
CoveredRegion: 被遮挡区域，在它之上，有不透明或半透明区域。
DirtyRegion: 可见部分改变区域，包括新的被遮挡区域，和新的露出区域。

Android 系统支持多种显示设备，比如说，输出到手机屏幕，或者通过WiFi 投射到电视屏幕。Android用DisplayDevice类来表示这样的设备。不是所有的Layer都会输出到所有的Display, 比如说，我们可以只将Video Layer投射到电视，而非整个屏幕。LayerStack 就是为此设计，LayerStack 是一个Display 对象的一个数值，而类Layer里成员State结构体也有成员变量mLayerStack，只有两者的mLayerStack 值相同，Layer才会被输出到给该Display设备。所以LayerStack 决定了每个Display设备上可以显示的Layer数目。

SurfaceFlinger的工作内容，就是定期检查所有Layer的参数更新（LayerStack等），计算新的DirtyRegion，然后将结果推送给底层显示驱动进行显示。这里面有很多的细节，我们将在后续会专门研究。

上面描述的几个概念，均是针对于显示这个层面，更多是涉及到中下层模块，应用层并不参与也无需关心。对于应用而言，它关心的是如何将内容画出来。Canvas 是Java层定义的一个类，它对应与Surface上的某个区域并提供了很多的2D绘制函数（借助于底层的Skia或OpenGL)。应用只需通过 LockCanvas() 来获取一个Canvas对象，并调用它的绘画方法，然后 unLockCanvasAndPost（）来通知底层将更新内容进行显示。当然，并不是所有应用程序都需要直接操作Canva，事实上只有少量应用需要直接操作Canvas, Android提供了很多封装好的控件 Widget，应用只需提供素材，如文字，图片，属性等等，这些控件会调用Canvas提供的接口帮用户完成绘制工作。

SurfaceFlinger 是一个独立的Service，它接收所有Window的Surface作为输入，根据Z-Order，透明度，大小，位置等参数，计算出每个Surface在最终合成图像中的位置，然后交由HWComposer或OpenGL生成最终的显示Buffer, 然后显示到特定的显示设备上。

Surface创建流程

SurfaceFlinger服务侧Layer创建

上面我们提，到在SurfaceFlinger服务这一侧，绘图表面使用Layer类来描述。

Layer类内部定义了两个结构体Geometry、State，位于frameworks/native/services/surfaceflinger/Layer.h中：

struct Geometry {
    uint32_t w;
    uint32_t h;
    Rect crop;
    inline bool operator ==(const Geometry& rhs) const {
        return (w == rhs.w && h == rhs.h && crop == rhs.crop);
    }
    inline bool operator !=(const Geometry& rhs) const {
        return !operator ==(rhs);
    }
};

struct State {
    Geometry active;
    Geometry requested;
    uint32_t z;
    uint32_t layerStack;
    uint8_t alpha;
    uint8_t flags;
    uint8_t reserved[2];
    int32_t sequence; // changes when visible regions can change
    Transform transform;
    // the transparentRegion hint is a bit special, it's latched only
    // when we receive a buffer -- this is because it's "content"
    // dependent.
    Region activeTransparentRegion;
    Region requestedTransparentRegion;
};

用变量mCurrentState和mDrawingState连个类型为State的成员变量保存当前和上一次的绘制状态，记录大小、可视区域、透明度、标志位、z-order等信息。

我们可以回顾一下以前 Android SurfaceFlinger 学习之路(三)—-Android开机动画流程简述，开机动画中创建surface流程位于BootAnimation.cpp的readyToRun函数，位于frameworks/base/cmds/bootanimation/BootAnimation.cpp中：

status_t BootAnimation::readyToRun() {
    ......
    // create the native surface
    sp<SurfaceControl> control = session()->createSurface(String8("BootAnimation"),
            dinfo.w, dinfo.h, PIXEL_FORMAT_RGB_565);

    SurfaceComposerClient::openGlobalTransaction();
    control->setLayer(0x40000000);
    SurfaceComposerClient::closeGlobalTransaction();

    sp<Surface> s = control->getSurface();
   
    ......
}

sp<SurfaceComposerClient> BootAnimation::session() const {
    return mSession;
}
BootAnimation::BootAnimation() : Thread(false), mZip(NULL)
{
    mSession = new SurfaceComposerClient();
}

这里session函数返回一个SurfaceComposerClient对象，在Android SurfaceFlinger 学习之路(四)—-SurfaceFlinger服务的启动与连接过程一文中，我们已经看到过SurfaceComposerClient类的作用了，Android应用程序主要就是通过它来和SurfaceFlinger服务建立连接的，连接的结果就是得到一个类型为Client的Binder代理对象，保存它的成员变量mClient中。

我们查看SurfaceComposerClient的createSurface函数，位于frameworks/native/libs/gui/SurfaceComposerClient.cpp中：

sp<SurfaceControl> SurfaceComposerClient::createSurface(
        const String8& name,
        uint32_t w,
        uint32_t h,
        PixelFormat format,
        uint32_t flags)
{
    sp<SurfaceControl> sur;
    if (mStatus == NO_ERROR) {
        sp<IBinder> handle;
        sp<IGraphicBufferProducer> gbp;
        //我们先分析这里，里面有创建Layer的部分
        status_t err = mClient->createSurface(name, w, h, format, flags,
                &handle, &gbp);
        ALOGE_IF(err, "SurfaceComposerClient::createSurface error %s", strerror(-err));
        if (err == NO_ERROR) {
            sur = new SurfaceControl(this, handle, gbp);
        }
    }
    return sur;
}

因此又要到Client的createSurface函数中，位于frameworks/native/services/surfaceflinger/Client.cpp中：

status_t Client::createSurface(
        const String8& name,
        uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,
        sp<IBinder>* handle,
        sp<IGraphicBufferProducer>* gbp)
{
    /*
     * createSurface must be called from the GL thread so that it can
     * have access to the GL context.
     */

    class MessageCreateLayer : public MessageBase {
        SurfaceFlinger* flinger;
        Client* client;
        sp<IBinder>* handle;
        sp<IGraphicBufferProducer>* gbp;
        status_t result;
        const String8& name;
        uint32_t w, h;
        PixelFormat format;
        uint32_t flags;
    public:
        MessageCreateLayer(SurfaceFlinger* flinger,
                const String8& name, Client* client,
                uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,
                sp<IBinder>* handle,
                sp<IGraphicBufferProducer>* gbp)
            : flinger(flinger), client(client),
              handle(handle), gbp(gbp),
              name(name), w(w), h(h), format(format), flags(flags) {
        }
        status_t getResult() const { return result; }
        virtual bool handler() {
            //给SurfaceFlinger的MessageQueue发送同步消息，createLayer函数被调用
            result = flinger->createLayer(name, client, w, h, format, flags,
                    handle, gbp);
            return true;
        }
    };

    sp<MessageBase> msg = new MessageCreateLayer(mFlinger.get(),
            name, this, w, h, format, flags, handle, gbp);
    mFlinger->postMessageSync(msg);
    return static_cast<MessageCreateLayer*>( msg.get() )->getResult();
}

给SurfaceFlinger的MessageQueue发送同步消息，createLayer函数被调用，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp中：

status_t SurfaceFlinger::createLayer(
        const String8& name,
        const sp<Client>& client,
        uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,
        sp<IBinder>* handle, sp<IGraphicBufferProducer>* gbp)
{
    //ALOGD("createLayer for (%d x %d), name=%s", w, h, name.string());
    if (int32_t(w|h) < 0) {
        ALOGE("createLayer() failed, w or h is negative (w=%d, h=%d)",
                int(w), int(h));
        return BAD_VALUE;
    }

    status_t result = NO_ERROR;

    sp<Layer> layer;

    switch (flags & ISurfaceComposerClient::eFXSurfaceMask) {
        case ISurfaceComposerClient::eFXSurfaceNormal:
            //创建普通的Layer
            result = createNormalLayer(client,
                    name, w, h, flags, format,
                    handle, gbp, &layer);
            break;
        case ISurfaceComposerClient::eFXSurfaceDim:
            ////创建模糊的Layer
            result = createDimLayer(client,
                    name, w, h, flags,
                    handle, gbp, &layer);
            break;
        default:
            result = BAD_VALUE;
            break;
    }

    if (result == NO_ERROR) {
        //将创建的Layer按顺序添加进list中，我们以后讲z-order会讲
        addClientLayer(client, *handle, *gbp, layer);
        //修改标志位
        setTransactionFlags(eTransactionNeeded);
    }
    return result;
}

这里会根据传进来的flag判断创建什么类型的Layer，一个是普通的，一个是模糊的Layer。这里我们只看看普通的Layer，createNormalLayer函数。

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:
        format = PIXEL_FORMAT_RGBX_8888;
        break;
    }
    //创建一个Layer对象
    *outLayer = new Layer(this, client, name, w, h, flags);
    //调用Layer的setBuffers函数，这只一些变量
    status_t err = (*outLayer)->setBuffers(w, h, format, flags);
    if (err == NO_ERROR) {
        //给成员变量handle和gbp赋值
        *handle = (*outLayer)->getHandle();
        *gbp = (*outLayer)->getProducer();
    }

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

这里创建了一个Layer对象，我们可以看看Layer的构造函数，位于frameworks/native/services/surfaceflinger/Layer.cpp中：

Layer::Layer(SurfaceFlinger* flinger, const sp<Client>& client,
        const String8& name, uint32_t w, uint32_t h, uint32_t flags)
    :   contentDirty(false),
        sequence(uint32_t(android_atomic_inc(&sSequence))),
        mFlinger(flinger),
        mTextureName(-1U),
        mPremultipliedAlpha(true),
        mName("unnamed"),
        mDebug(false),
        mFormat(PIXEL_FORMAT_NONE),
        mTransactionFlags(0),
        mQueuedFrames(0),
        mSidebandStreamChanged(false),
        mCurrentTransform(0),
        mCurrentScalingMode(NATIVE_WINDOW_SCALING_MODE_FREEZE),
        mCurrentOpacity(true),
        mRefreshPending(false),
        mFrameLatencyNeeded(false),
        mFiltering(false),
        mNeedsFiltering(false),
        mMesh(Mesh::TRIANGLE_FAN, 4, 2, 2),
        mSecure(false),
        mProtectedByApp(false),
        mHasSurface(false),
        mClientRef(client),
        mPotentialCursor(false)
{
    mCurrentCrop.makeInvalid();
    mFlinger->getRenderEngine().genTextures(1, &mTextureName);
    mTexture.init(Texture::TEXTURE_EXTERNAL, mTextureName);

    uint32_t layerFlags = 0;
    if (flags & ISurfaceComposerClient::eHidden)
        layerFlags |= layer_state_t::eLayerHidden;
    if (flags & ISurfaceComposerClient::eOpaque)
        layerFlags |= layer_state_t::eLayerOpaque;

    if (flags & ISurfaceComposerClient::eNonPremultiplied)
        mPremultipliedAlpha = false;

    mName = name;

    mCurrentState.active.w = w;
    mCurrentState.active.h = h;
    mCurrentState.active.crop.makeInvalid();
    mCurrentState.z = 0;
    mCurrentState.alpha = 0xFF;
    mCurrentState.layerStack = 0;
    mCurrentState.flags = layerFlags;
    mCurrentState.sequence = 0;
    mCurrentState.transform.set(0, 0);
    mCurrentState.requested = mCurrentState.active;

    // drawing state & current state are identical
    mDrawingState = mCurrentState;

    nsecs_t displayPeriod =
            flinger->getHwComposer().getRefreshPeriod(HWC_DISPLAY_PRIMARY);
    mFrameTracker.setDisplayRefreshPeriod(displayPeriod);
}

Layer的构造函数中就是给一些变量赋了初值，事情不多。
我们从上面的类图看到Layer间接继承于RefBase类，所以对象第一次被赋值给强指针会调用onFirstRef函数，我们看看它里面做了那些事情：

void Layer::onFirstRef() {
    // Creates a custom BufferQueue for SurfaceFlingerConsumer to use
    sp<IGraphicBufferProducer> producer;
    sp<IGraphicBufferConsumer> consumer;
    //BufferQueue创建图形缓冲区管理成员，我们以后分析图形缓冲区管理会讲到
    BufferQueue::createBufferQueue(&producer, &consumer);
    //mProducer 不为空了，赋值
    mProducer = new MonitoredProducer(producer, mFlinger);
    //mSurfaceFlingerConsumer 不为空了，赋值
    mSurfaceFlingerConsumer = new SurfaceFlingerConsumer(consumer, mTextureName);
    //设置消费者相关设置
    mSurfaceFlingerConsumer->setConsumerUsageBits(getEffectiveUsage(0));
    mSurfaceFlingerConsumer->setContentsChangedListener(this);
    mSurfaceFlingerConsumer->setName(mName);
    
// TARGET_DISABLE_TRIPLE_BUFFERING为false，所以使用了三缓冲，project butter计划嘛
#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);
}

onFirstRef函数中做的事情主要是创建图形缓冲区管理成员相关，这个我们后面会讲到。
然后就是根据“黄油计划”定义了三缓冲，以及显示器方向的调整。

Layer对象创建完后，就调用Layer的setBuffers函数：

status_t Layer::setBuffers( uint32_t w, uint32_t h,
                            PixelFormat format, uint32_t flags)
{
    uint32_t const maxSurfaceDims = min(
            mFlinger->getMaxTextureSize(), mFlinger->getMaxViewportDims());

    // never allow a surface larger than what our underlying GL implementation
    // can handle.
    if ((uint32_t(w)>maxSurfaceDims) || (uint32_t(h)>maxSurfaceDims)) {
        ALOGE("dimensions too large %u x %u", uint32_t(w), uint32_t(h));
        return BAD_VALUE;
    }

    mFormat = format;

    mPotentialCursor = (flags & ISurfaceComposerClient::eCursorWindow) ? true : false;
    mSecure = (flags & ISurfaceComposerClient::eSecure) ? true : false;
    mProtectedByApp = (flags & ISurfaceComposerClient::eProtectedByApp) ? true : false;
    mCurrentOpacity = getOpacityForFormat(format);

    mSurfaceFlingerConsumer->setDefaultBufferSize(w, h);
    mSurfaceFlingerConsumer->setDefaultBufferFormat(format);
    mSurfaceFlingerConsumer->setConsumerUsageBits(getEffectiveUsage(0));

    return NO_ERROR;
}

这里也是一些变量的设置，东西不多。
然后就是给gbp和handle赋值。gbp已经不为空了，我们在onFirstRef函数中对它付了值。那么我们看看给handle赋值，Layer的getHandle函数：

sp<IBinder> Layer::getHandle() {
    Mutex::Autolock _l(mLock);

    LOG_ALWAYS_FATAL_IF(mHasSurface,
            "Layer::getHandle() has already been called");

    mHasSurface = true;

    /*
     * The layer handle is just a BBinder object passed to the client
     * (remote process) -- we don't keep any reference on our side such that
     * the dtor is called when the remote side let go of its reference.
     *
     * LayerCleaner ensures that mFlinger->onLayerDestroyed() is called for
     * this layer when the handle is destroyed.
     */

    class Handle : public BBinder, public LayerCleaner {
        wp<const Layer> mOwner;
    public:
        Handle(const sp<SurfaceFlinger>& flinger, const sp<Layer>& layer)
            : LayerCleaner(flinger, layer), mOwner(layer) {
        }
    };

    return new Handle(mFlinger, this);
}

只是新建一个Handle，而这个Handle只是一个Binder的实现，就是标识Surface的全局唯一性，没有什么实际的内容。

上述就是Layer的创建，是基于SurfaceFlinger服务端这一侧。

应用侧Surface创建

我们继续回到上面的SurfaceComposerClient的createSurface函数，为了不往上翻我再贴一遍：

sp<SurfaceControl> SurfaceComposerClient::createSurface(
        const String8& name,
        uint32_t w,
        uint32_t h,
        PixelFormat format,
        uint32_t flags)
{
    sp<SurfaceControl> sur;
    if (mStatus == NO_ERROR) {
        sp<IBinder> handle;
        sp<IGraphicBufferProducer> gbp;
        //上面分析完了SurfaceFlinger创建完了一个Layer
        status_t err = mClient->createSurface(name, w, h, format, flags,
                &handle, &gbp);
        ALOGE_IF(err, "SurfaceComposerClient::createSurface error %s", strerror(-err));
        if (err == NO_ERROR) {
            //根据上面创建Layer时创建的handle和gbp再创建一个SurfaceControl，并返回
            sur = new SurfaceControl(this, handle, gbp);
        }
    }
    return sur;
}

上面分析完了SurfaceFlinger创建完了一个Layer，接着根据上面创建Layer时创建的handle和gbp再创建一个SurfaceControl，并返回。

SurfaceControl创建

在Android应用程序这一侧，每一个绘图表面都使用一个Surface对象来描述，每一个Surface对象都是由一个SurfaceControl对象来创建的。Surface类和SurfaceControl类的关系以及实现如图所示：

SurfaceControl类的成员变量mClient是一个类型为SurfaceComposerClient对象，在Android SurfaceFlinger 学习之路(四)—-SurfaceFlinger服务的启动与连接过程一文中，我们已经看到过SurfaceComposerClient类的作用了，Android应用程序主要就是通过它来和SurfaceFlinger服务建立连接的，连接的结果就是得到一个类型为Client的Binder代理对象，保存它的成员变量mClient中。

SurfaceControl类的成员变量mHandle是指向的就是我们上面分析的创建Layer时，最后将Layer和SurfaceFlinger作为构造函数的参数创建一个Handle对象，这个Handle是一个Binder的实现，就是标识Surface的全局唯一性。当Android应用程序请求SurfaceFlinger服务创建一个绘图表面的时候，SurfaceFlinger服务就会在内部创建一个Layer对象，然后将Layer和SurfaceFlinger包装成一个Handle的一个Binder代理对象返回来给Android应用程序，然后Android应用程序再将这个Binder代理对象保存在一个SurfaceControl对象的成员变量mHandle中。

SurfaceControl类的成员变量mSurfaceData是一个类型为Surface的强指针，它指向了一个Surface对象。

SurfaceControl的构造函数也比较简单，位于frameworks/native/libs/gui/SurfaceControl.cpp中：

SurfaceControl::SurfaceControl(
        const sp<SurfaceComposerClient>& client,
        const sp<IBinder>& handle,
        const sp<IGraphicBufferProducer>& gbp)
    : mClient(client), mHandle(handle), mGraphicBufferProducer(gbp)
{
}

SurfaceControl类创建就到这里。

附：这是native层的SurfaceControl，对于java层，也有一个SurfaceControl，Android 4.3 里新引进的类。Google从之前的Surface类里拆出部分接口，变成SurfaceControl，为什么要这样？为了让结构更清晰，WindowManagerService 只能对Surface进行控制，但并不更新Surface里的内容，分拆之后，WindowManagerService 只能访问SurfaceControl，它主要控制Surface的创建，销毁，Z-order，透明度，显示或隐藏，等等。而真正的更新者，View会通过Canvas的接口将内容画到Surface上。那View怎么拿到WMService创建的Surface，答案是outSurface.copyFrom(surfaceControl)；，surfaceControl 被转换成一个Surface对象，然后传回给ViewRoot, 前面创建的空的Surface现在有了实质内容。Surface通过这种方式被创建出来，Surface对应的Buffer 也相应的在SurfaceFlinger内部通过HAL层模块（GRAlloc)分配并维护在SurfaceFlinger 内部，Canvas() 通过dequeueBuffer（）接口拿到Surface的一个Buffer，绘制完成后通过queueBuffer（）还给SurfaceFlinger进行绘制。（这一部分我们后期学习WMS时候再分析）

Surface创建

从上面的类图，可以看到Surface类的成员变量mGraphicBufferProducer指向一个sp< IGraphicBufferProducer > 类型的对象，在Layer的onFirstRef函数中，mProducer复制后，类型为MonitoredProducer，将它有传给了Surface中。我们注意MonitoredProducer构造函数的一个参数producer，事实上MonitoredProducer只是一个代理类，真正的实现在这个producer参数。它是在BufferQueue::createBufferQueue中创造的。这个我们下一篇会分析这个。

Surface类继承了ANativeObjectBase类，而ANativeObjectBase类又继承了ANativeWindow类。我们知道，Android系统是通过OpenGL库来绘制UI的。OpenGL库在绘制UI的时候，需要底层的系统提供一个本地窗口给它，以便它可以将UI绘制在这个本地窗口上。Android系统为OpenGL库定提供的本地窗口使用ANativeWindow类来描述，Surface类通过ANativeObjectBase类间接地继承了ANativeWindow类，因此，Surface类也是用来描述OpenGL绘图所需要的一个本地窗口的。从这个角度出发，我们可以将Surface类看作OpenGL库与Android的UI系统之间的一个桥梁。

创建Surface的函数也很简单，查看SurfaceControl的getSurface函数：

sp<Surface> SurfaceControl::getSurface() const
{
    Mutex::Autolock _l(mLock);
    if (mSurfaceData == 0) {
        // This surface is always consumed by SurfaceFlinger, so the
        // producerControlledByApp value doesn't matter; using false.
        mSurfaceData = new Surface(mGraphicBufferProducer, false);
    }
    return mSurfaceData;
}

以及看看Surface的构造函数，位于frameworks/native/libs/gui/Surface.cpp：

Surface::Surface(
        const sp<IGraphicBufferProducer>& bufferProducer,
        bool controlledByApp)
    : mGraphicBufferProducer(bufferProducer)
{
    // Initialize the ANativeWindow function pointers.
    ANativeWindow::setSwapInterval  = hook_setSwapInterval;
    ANativeWindow::dequeueBuffer    = hook_dequeueBuffer;
    ANativeWindow::cancelBuffer     = hook_cancelBuffer;
    ANativeWindow::queueBuffer      = hook_queueBuffer;
    ANativeWindow::query            = hook_query;
    ANativeWindow::perform          = hook_perform;

    ANativeWindow::dequeueBuffer_DEPRECATED = hook_dequeueBuffer_DEPRECATED;
    ANativeWindow::cancelBuffer_DEPRECATED  = hook_cancelBuffer_DEPRECATED;
    ANativeWindow::lockBuffer_DEPRECATED    = hook_lockBuffer_DEPRECATED;
    ANativeWindow::queueBuffer_DEPRECATED   = hook_queueBuffer_DEPRECATED;

    const_cast<int&>(ANativeWindow::minSwapInterval) = 0;
    const_cast<int&>(ANativeWindow::maxSwapInterval) = 1;

    mReqWidth = 0;
    mReqHeight = 0;
    mReqFormat = 0;
    mReqUsage = 0;
    mTimestamp = NATIVE_WINDOW_TIMESTAMP_AUTO;
    mCrop.clear();
    mScalingMode = NATIVE_WINDOW_SCALING_MODE_FREEZE;
    mTransform = 0;
    mStickyTransform = 0;
    mDefaultWidth = 0;
    mDefaultHeight = 0;
    mUserWidth = 0;
    mUserHeight = 0;
    mTransformHint = 0;
    mConsumerRunningBehind = false;
    mConnectedToCpu = false;
    mProducerControlledByApp = controlledByApp;
    mSwapIntervalZero = false;
}

主要是设置了一些钩子方法，用于创建GraphicBuffer等等。还有一些变量的初始化。所以重点应该在这些钩子方法当中，我们下一节会分析。

小结

本节我们主要讲了SurfaceFlinger创建Surface的过程，文章末尾我们我发现管理图形缓冲区的一个重要工具：BufferQueue。我们下一节会分析这个。

Android SurfaceFlinger 学习之路(五)----VSync 工作原理

2017-05-25T08:27:02.000Z

VSync信号的科普我们上一篇已经介绍过了，这篇我们要分析在SurfaceFlinger中的作用。（愈发觉得做笔记对自己记忆模块巩固有很多帮助，整理文章不一定是用来给别人看的，但一定是为加强自己记忆的~）

流程基础

从上一篇得知，Android 4.1一个很大的更新是Project Butter，黄油计划，为了解决用户交互体验差的问题(Jelly Bean is crazy fast)。Project Butter对Android Display系统进行了重构，引入了三个核心元素，即VSYNC、Triple Buffer和Choreographer。

硬件加载

上上一节我们初略分析了SurfaceFlinger的启动流程，从SurfaceFlinger类的初始化流程得知，其init方法初始化了很多参数。我们分析Vsync流程需要这些信息，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp中。

显示设备

SurfaceFlinger中需要显示的图层（layer）将通过DisplayDevice对象传递到OpenGLES中进行合成，合成之后的图像再通过HWComposer对象传递到Framebuffer中显示。DisplayDevice对象中的成员变量mVisibleLayersSortedByZ保存了所有需要显示在本显示设备中显示的Layer对象，同时DisplayDevice对象也保存了和显示设备相关的显示方向、显示区域坐标等信息。

DisplayDevice是显示设备的抽象，定义了3中类型的显示设备。引用枚举类位于frameworks/native/services/surfaceflinger/DisplayDevice.h中，定义枚举位于hardware/libhardware/include/hardware/Hwcomposer_defs.h中：

    //DisplayDevice.h
    enum DisplayType {
        DISPLAY_ID_INVALID = -1,
        DISPLAY_PRIMARY     = HWC_DISPLAY_PRIMARY,
        DISPLAY_EXTERNAL    = HWC_DISPLAY_EXTERNAL,
        DISPLAY_VIRTUAL     = HWC_DISPLAY_VIRTUAL,
        NUM_BUILTIN_DISPLAY_TYPES = HWC_NUM_PHYSICAL_DISPLAY_TYPES,
    };

    //Hwcomposer_defs.h
    /* Display types and associated mask bits. */
    enum {
    HWC_DISPLAY_PRIMARY     = 0,
    HWC_DISPLAY_EXTERNAL    = 1,    // HDMI, DP, etc.
    HWC_DISPLAY_VIRTUAL     = 2,

    HWC_NUM_PHYSICAL_DISPLAY_TYPES = 2,
    HWC_NUM_DISPLAY_TYPES          = 3,
};

DISPLAY_PRIMARY：主显示设备，通常是LCD屏
DISPLAY_EXTERNAL：扩展显示设备。通过HDMI输出的显示信号
DISPLAY_VIRTUAL：虚拟显示设备，通过WIFI输出信号

这三种设备，第一种就是我们手机、电视的主显示屏，另外两种需要硬件扩展。

初始化显示设备模块位于SurfaceFlinger中的init函数：

void SurfaceFlinger::init() {
   
    ......
    //初始化HWComposer硬件设备，我们下面会讲到
    // actual hardware composer underneath.
    mHwc = new HWComposer(this,
            *static_cast<HWComposer::EventHandler *>(this));

    
    //初始化物理显示设备
    // initialize our non-virtual displays
    //物理设备类型总数为2
    for (size_t i=0 ; i<DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES ; i++) {
        DisplayDevice::DisplayType type((DisplayDevice::DisplayType)i);
        // set-up the displays that are already connected
        //先调用了HWComposer的isConnected来检查显示设备是否已连接，
        //只有和显示设备连接的DisplayDevice对象才会被创建出来。
        //即使没有任何物理显示设备被检测到，
        //SurfaceFlinger都需要一个DisplayDevice对象才能正常工作，
        //因此，DISPLAY_PRIMARY类型的DisplayDevice对象总是会被创建出来。
        if (mHwc->isConnected(i) || type==DisplayDevice::DISPLAY_PRIMARY) {
            // All non-virtual displays are currently considered secure.
            bool isSecure = true;
            ////给显示设备分配一个token,一般都是一个binder
            createBuiltinDisplayLocked(type);
            wp<IBinder> token = mBuiltinDisplays[i];
            //然后会调用createBufferQueue函数创建一个producer和consumer
            sp<IGraphicBufferProducer> producer;
            sp<IGraphicBufferConsumer> consumer;
            BufferQueue::createBufferQueue(&producer, &consumer,
                    new GraphicBufferAlloc());
            //然后又创建了一个FramebufferSurface对象，把consumer参数传入代表是一个消费者。
            sp<FramebufferSurface> fbs = new FramebufferSurface(*mHwc, i,
                    consumer);
            int32_t hwcId = allocateHwcDisplayId(type);
            //创建DisplayDevice对象，代表一类显示设备
            sp<DisplayDevice> hw = new DisplayDevice(this,
                    type, hwcId, mHwc->getFormat(hwcId), isSecure, token,
                    fbs, producer,
                    mRenderEngine->getEGLConfig());
            //如果不是主屏幕        
            if (i > DisplayDevice::DISPLAY_PRIMARY) {
                // FIXME: currently we don't get blank/unblank requests
                // for displays other than the main display, so we always
                // assume a connected display is unblanked.
                ALOGD("marking display %zu as acquired/unblanked", i);
                //通常我们不会在次屏幕获得熄灭/点亮LCD的请求，
                //所以我们总是认为次显屏是点亮的

                //设置PowerMode为HWC_POWER_MODE_NORMAL
                hw->setPowerMode(HWC_POWER_MODE_NORMAL);
            }
            mDisplays.add(token, hw);
        }
    }

    ......
}

上述过程就是初始化显示设备，我们分部查看。

1）检查设备连接：
所有显示设备的输出都要通过HWComposer对象完成，因此上面这段代码先调用了HWComposer的isConnected来检查显示设备是否已连接，只有和显示设备连接的DisplayDevice对象才会被创建出来。即使没有任何物理显示设备被检测到，SurfaceFlinger都需要一个DisplayDevice对象才能正常工作，因此，DISPLAY_PRIMARY类型的DisplayDevice对象总是会被创建出来。

createBuiltinDisplayLocked函数就是为显示设备对象创建一个BBinder类型的Token：

void SurfaceFlinger::createBuiltinDisplayLocked(DisplayDevice::DisplayType type) {
    ALOGW_IF(mBuiltinDisplays[type],
            "Overwriting display token for display type %d", type);
    //一般这种token之类的东西，都是一个binder
    mBuiltinDisplays[type] = new BBinder();
    DisplayDeviceState info(type);
    // All non-virtual displays are currently considered secure.
    info.isSecure = true;
    mCurrentState.displays.add(mBuiltinDisplays[type], info);
}

一般这种token之类的东西，都是一个binder，就像我们创建window需要一个token，也是new一个binder然后在WindowManagerService里注册。

2）初始化GraphicBuffer相关内容：（这一部分我们后续分析GraphicBuffer管理相关会仔细分析它，这里只是粗略介绍）
然后会调用createBufferQueue函数创建一个producer和consumer。然后又创建了一个FramebufferSurface对象。这里我们看到在新建FramebufferSurface对象时把consumer参数传入了代表是一个消费者。
而在DisplayDevice的构造函数中（下面会讲到），会创建一个Surface对象传递给底层的OpenGL ES使用，而这个Surface是一个生产者。在OpenGl ES中合成好了图像之后会将图像数据写到Surface对象中，这将触发consumer对象的onFrameAvailable函数被调用。
这就是Surface数据好了就通知消费者来拿数据做显示用，在onFrameAvailable函数汇总，通过nextBuffer获得图像数据，然后调用HWComposer对象mHwc的fbPost函数输出。

FramebufferSurface类位于frameworks/native/services/surfaceflinger/displayhardware/FramebufferSurface.cpp中，我们查看它的的onFrameAvailable函数：

// Overrides ConsumerBase::onFrameAvailable(), does not call base class impl.
void FramebufferSurface::onFrameAvailable() {
    sp<GraphicBuffer> buf;
    sp<Fence> acquireFence;
    //通过nextBuffer获得图像数据
    status_t err = nextBuffer(buf, acquireFence);
    if (err != NO_ERROR) {
        ALOGE("error latching nnext FramebufferSurface buffer: %s (%d)",
                strerror(-err), err);
        return;
    }
    //调用HWComposer的fbPost函数输出图像，fbPost函数最后通过调用Gralloc模块的post函数来输出图像
    err = mHwc.fbPost(mDisplayType, acquireFence, buf);
    if (err != NO_ERROR) {
        ALOGE("error posting framebuffer: %d", err);
    }
}

这个流程我们下几节会仔细分析，这里我们粗略过个流程：
通过nextBuffer获得图像数据；
然后调用HWComposer对象mHwc的fbPost函数输出，fbPost函数最后通过调用Gralloc模块的post函数来输出图像。这一部分我们在Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现分析过了，可以查看这个链接。

3）创建DisplayDevice对象，用来描述显示设备：
我们再来看看DisplayDevice的构造函数，位于frameworks/native/services/surfaceflinger/DisplayDevice.cpp中：

/*
 * Initialize the display to the specified values.
 *
 */

DisplayDevice::DisplayDevice(
        const sp<SurfaceFlinger>& flinger,
        DisplayType type,
        int32_t hwcId,
        int format,
        bool isSecure,
        const wp<IBinder>& displayToken,
        const sp<DisplaySurface>& displaySurface,
        const sp<IGraphicBufferProducer>& producer,
        EGLConfig config)
    : lastCompositionHadVisibleLayers(false),
      mFlinger(flinger),
      mType(type), mHwcDisplayId(hwcId),
      mDisplayToken(displayToken),
      mDisplaySurface(displaySurface),
      mDisplay(EGL_NO_DISPLAY),
      mSurface(EGL_NO_SURFACE),
      mDisplayWidth(), mDisplayHeight(), mFormat(),
      mFlags(),
      mPageFlipCount(),
      mIsSecure(isSecure),
      mSecureLayerVisible(false),
      mLayerStack(NO_LAYER_STACK),
      mOrientation(),
      mPowerMode(HWC_POWER_MODE_OFF),
      mActiveConfig(0)
{
    //创建surface，传递给底层的OpenGL ES使用，而这个Surface是一个生产者
    mNativeWindow = new Surface(producer, false);
    ANativeWindow* const window = mNativeWindow.get();

    /*
     * Create our display's surface
     */
    //在OpenGl ES中合成好了图像之后会将图像数据写到Surface对象中
    EGLSurface surface;
    EGLint w, h;
    EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    if (config == EGL_NO_CONFIG) {
        config = RenderEngine::chooseEglConfig(display, format);
    }
    surface = eglCreateWindowSurface(display, config, window, NULL);
    eglQuerySurface(display, surface, EGL_WIDTH,  &mDisplayWidth);
    eglQuerySurface(display, surface, EGL_HEIGHT, &mDisplayHeight);

    // Make sure that composition can never be stalled by a virtual display
    // consumer that isn't processing buffers fast enough. We have to do this
    // in two places:
    // * Here, in case the display is composed entirely by HWC.
    // * In makeCurrent(), using eglSwapInterval. Some EGL drivers set the
    //   window's swap interval in eglMakeCurrent, so they'll override the
    //   interval we set here.
    ////虚拟设备不支持图像合成  
    if (mType >= DisplayDevice::DISPLAY_VIRTUAL)
        window->setSwapInterval(window, 0);

    mConfig = config;
    mDisplay = display;
    mSurface = surface;
    mFormat  = format;
    mPageFlipCount = 0;
    mViewport.makeInvalid();
    mFrame.makeInvalid();

    // virtual displays are always considered enabled
    //虚拟设备屏幕认为是不关闭的 
    mPowerMode = (mType >= DisplayDevice::DISPLAY_VIRTUAL) ?
                  HWC_POWER_MODE_NORMAL : HWC_POWER_MODE_OFF;

    // Name the display.  The name will be replaced shortly if the display
    // was created with createDisplay().
    //根据显示设备类型赋名称
    switch (mType) {
        case DISPLAY_PRIMARY:
            mDisplayName = "Built-in Screen";
            break;
        case DISPLAY_EXTERNAL:
            mDisplayName = "HDMI Screen";
            break;
        default:
            mDisplayName = "Virtual Screen";    // e.g. Overlay #n
            break;
    }

    // initialize the display orientation transform.
    //调整显示设备视角的大小、位移、旋转等参数
    setProjection(DisplayState::eOrientationDefault, mViewport, mFrame);
}

DisplayDevice的构造函数初始化了一些参数，但是最重要的是：创建了一个Surface对象mNativeWindow，同时用它作为参数创建EGLSurface对象，这个EGLSurface对象是OpenGL ES中绘图需要的。

这样，在DisplayDevice中就建立了一个通向Framebuffer的通道，只要向DisplayDevice的mSurface写入数据。就会到消费者FrameBufferSurface的onFrameAvailable函数，然后到HWComposer在到Gralloc模块，最后输出到显示设备。

附（以后会讲到）：DisplayDevice有个函数swapBuffers。swapBuffers函数将内部缓冲区的图像数据刷新到显示设备的Framebuffer中，它通过调用eglSwapBuffers函数来完成缓冲区刷新工作：

void DisplayDevice::swapBuffers(HWComposer& hwc) const {
    // We need to call eglSwapBuffers() if:
    //  (1) we don't have a hardware composer, or
    //  (2) we did GLES composition this frame, and either
    //    (a) we have framebuffer target support (not present on legacy
    //        devices, where HWComposer::commit() handles things); or
    //    (b) this is a virtual display
    if (hwc.initCheck() != NO_ERROR ||
            (hwc.hasGlesComposition(mHwcDisplayId) &&
             (hwc.supportsFramebufferTarget() || mType >= DISPLAY_VIRTUAL))) {
        EGLBoolean success = eglSwapBuffers(mDisplay, mSurface);
        if (!success) {
            EGLint error = eglGetError();
            if (error == EGL_CONTEXT_LOST ||
                    mType == DisplayDevice::DISPLAY_PRIMARY) {
                LOG_ALWAYS_FATAL("eglSwapBuffers(%p, %p) failed with 0x%08x",
                        mDisplay, mSurface, error);
            } else {
                ALOGE("eglSwapBuffers(%p, %p) failed with 0x%08x",
                        mDisplay, mSurface, error);
            }
        }
    }

    status_t result = mDisplaySurface->advanceFrame();
    if (result != NO_ERROR) {
        ALOGE("[%s] failed pushing new frame to HWC: %d",
                mDisplayName.string(), result);
    }
}

但是注意调用swapBuffers输出图像是在显示设备不支持硬件composer的情况下。

HWComposer设备

通过上一篇文章得知，Android通过VSync机制来提高显示效果，那么VSync是如何产生的？通常这个信号是由显示驱动产生，这样才能达到最佳效果。但是Android为了能运行在不支持VSync机制的设备上，也提供了软件模拟产生VSync信号的手段。
在SurfaceFlinger中，是通过HWComposer类来表示硬件设备。我们继续产看init函数：

void SurfaceFlinger::init() {
    ......
    // Initialize the H/W composer object.  There may or may not be an
    // actual hardware composer underneath.
    mHwc = new HWComposer(this,
            *static_cast<HWComposer::EventHandler *>(this));
    ......
}

我们继续查看HWComposer的构造函数，位于frameworks/native/services/surfaceflinger/displayhardware/HWComposer.cpp中：

// ---------------------------------------------------------------------------

HWComposer::HWComposer(
        const sp<SurfaceFlinger>& flinger,
        EventHandler& handler)
    : mFlinger(flinger),
      mFbDev(0), mHwc(0), mNumDisplays(1),
      mCBContext(new cb_context),//这里直接new了一个设备上下文对象
      mEventHandler(handler),
      mDebugForceFakeVSync(false)
{
    
    ......
    
    bool needVSyncThread = true;

    // Note: some devices may insist that the FB HAL be opened before HWC.
    //装载FrameBuffer的硬件模块 
    int fberr = loadFbHalModule();
    //装载HWComposer的硬件模块,这个函数中会将mHwc置为true
    loadHwcModule();
    
    //如果有FB和HWC，并且也有pre-1.1 HWC，就要先关闭FB设备
    //但这个是暂时的，直到HWC准备好
    if (mFbDev && mHwc && hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1)) {
        // close FB HAL if we don't needed it.
        // FIXME: this is temporary until we're not forced to open FB HAL
        // before HWC.
        framebuffer_close(mFbDev);
        mFbDev = NULL;
    }

    // If we have no HWC, or a pre-1.1 HWC, an FB dev is mandatory.
    //如果我们没有HWC硬件支持，或者之前的pre-1.1 HWC，如hwc 1.0,那么FrameBuffer就是必须的
    if ((!mHwc || !hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1))
            && !mFbDev) {
        //如果没有framebuffer，就退出gg
        ALOGE("ERROR: failed to open framebuffer (%s), aborting",
                strerror(-fberr));
        abort();
    }

    // these display IDs are always reserved
    for (size_t i=0 ; i<NUM_BUILTIN_DISPLAYS ; i++) {
        mAllocatedDisplayIDs.markBit(i);
    }

    //硬件vsync信号
    if (mHwc) {
        ALOGI("Using %s version %u.%u", HWC_HARDWARE_COMPOSER,
              (hwcApiVersion(mHwc) >> 24) & 0xff,
              (hwcApiVersion(mHwc) >> 16) & 0xff);
        if (mHwc->registerProcs) {
            //HWComposer设备上下文变量mCBContext赋值
            mCBContext->hwc = this;
            //函数指针钩子函数hook_invalidate放入上下文
            mCBContext->procs.invalidate = &hook_invalidate;
            //vsync钩子函数放入上下文
            mCBContext->procs.vsync = &hook_vsync;
            if (hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1))
                //hotplug狗子函数放入上下文
                mCBContext->procs.hotplug = &hook_hotplug;
            else
                mCBContext->procs.hotplug = NULL;
            memset(mCBContext->procs.zero, 0, sizeof(mCBContext->procs.zero));
            //将钩子函数注册进硬件设备，硬件驱动回调这些钩子函数
            mHwc->registerProcs(mHwc, &mCBContext->procs);
        }

        // don't need a vsync thread if we have a hardware composer
        //如果有硬件vsync信号， 则不需要软件vsync实现
        needVSyncThread = false;
        
        ......
    }
    
    if (mFbDev) {//如果mFbDev为不为null，情况为：没有hwc或者hwc是1.0老的版本
        ALOG_ASSERT(!(mHwc && hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1)),
                "should only have fbdev if no hwc or hwc is 1.0");

        DisplayData& disp(mDisplayData[HWC_DISPLAY_PRIMARY]);
        disp.connected = true;
        disp.format = mFbDev->format;
        DisplayConfig config = DisplayConfig();
        config.width = mFbDev->width;
        config.height = mFbDev->height;
        config.xdpi = mFbDev->xdpi;
        config.ydpi = mFbDev->ydpi;
        config.refresh = nsecs_t(1e9 / mFbDev->fps);
        disp.configs.push_back(config);
        disp.currentConfig = 0;
    } else if (mHwc) {//如果mFbDev为null，情况为：fb打开失败，或者暂时关闭(上面逻辑分析了)。打开了hwc
        // here we're guaranteed to have at least HWC 1.1
        //这里我们至少有HWC 1.1，上面分析过了。NUM_BUILTIN_DISPLAYS 为2
        for (size_t i =0 ; i<NUM_BUILTIN_DISPLAYS ; i++) {
            //获取显示设备相关属性
            queryDisplayProperties(i);
        }
    }


    ......
    //如果没有硬件vsync，则需要用使用软件vsync模拟
    if (needVSyncThread) {
        // we don't have VSYNC support, we need to fake it
        mVSyncThread = new VSyncThread(*this);
    }
}

构造函数主要做了以下几件事情：

1）加载FrameBuffer硬件驱动：
调用loadFbHalModule函数实现，我们继续查看：

// Load and prepare the FB HAL, which uses the gralloc module.  Sets mFbDev.
int HWComposer::loadFbHalModule()
{
    hw_module_t const* module;
    //hal层封装的hal函数，参数GRALLOC_HARDWARE_MODULE_ID，加载gralloc模块
    int err = hw_get_module(GRALLOC_HARDWARE_MODULE_ID, &module);
    if (err != 0) {
        ALOGE("%s module not found", GRALLOC_HARDWARE_MODULE_ID);
        return err;
    }
    //打开fb设备
    return framebuffer_open(module, &mFbDev);
}

hw_get_module函数是HAL层框架中封装的加载gralloc的函数，这个我们之前讲过，可以查看Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现中的Gralloc模块的加载过程部分。

framebuffer_open函数同上，是用来打开fb设备，同样查看fb设备的打开过程模块。

2）装载HWComposer的硬件模块：
调用loadHwcModule函数来加载HWC模块，我们继续查看：

// Load and prepare the hardware composer module.  Sets mHwc.
void HWComposer::loadHwcModule()
{
    hw_module_t const* module;
    //同样是HAL层封装的函数，参数是HWC_HARDWARE_MODULE_ID，加载hwc模块
    if (hw_get_module(HWC_HARDWARE_MODULE_ID, &module) != 0) {
        ALOGE("%s module not found", HWC_HARDWARE_MODULE_ID);
        return;
    }
    //打开hwc设备
    int err = hwc_open_1(module, &mHwc);
    if (err) {
        ALOGE("%s device failed to initialize (%s)",
              HWC_HARDWARE_COMPOSER, strerror(-err));
        return;
    }

    if (!hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_0) ||
            hwcHeaderVersion(mHwc) < MIN_HWC_HEADER_VERSION ||
            hwcHeaderVersion(mHwc) > HWC_HEADER_VERSION) {
        ALOGE("%s device version %#x unsupported, will not be used",
              HWC_HARDWARE_COMPOSER, mHwc->common.version);
        hwc_close_1(mHwc);
        mHwc = NULL;
        return;
    }
}

同样是借助hw_get_module这个HAL函数，不过参数是HWC_HARDWARE_MODULE_ID，加载HWC模块；然后hwc_open_1函数打开hwc设备。

3）FB和HWC相关逻辑判断(1)：
如果有FB和HWC，并且也有pre-1.1 HWC，就要先关闭FB设备。这个是暂时的，直到HWC准备好；
如果我们没有HWC硬件支持，或者之前的pre-1.1 HWC,，如HWC 1.0，那么FrameBuffer就是必须的。如果脸FB都没有，那就GG。

4）硬件设备打开成功：
如果硬件设备打开成功，则将钩子函数hook_invalidate、hook_vsync和hook_hotplug注册进硬件设备，作为回调函数。这三个都是硬件产生事件信号，通知上层SurfaceFlinger的回调函数，用于处理这个信号。

因为我们本节是Vsync信号相关，所以我们只看看hook_vsync钩子函数。这里指定了vsync的回调函数是hook_vsync，如果硬件中产生了VSync信号，将通过这个函数来通知上层，看看它的代码：

void HWComposer::hook_vsync(const struct hwc_procs* procs, int disp,
        int64_t timestamp) {
    cb_context* ctx = reinterpret_cast<cb_context*>(
            const_cast<hwc_procs_t*>(procs));
    ctx->hwc->vsync(disp, timestamp);
}

hook_vsync钩子函数会调用vsync函数，我们继续看：

void HWComposer::vsync(int disp, int64_t timestamp) {
    if (uint32_t(disp) < HWC_NUM_PHYSICAL_DISPLAY_TYPES) {
        {
            Mutex::Autolock _l(mLock);

            // There have been reports of HWCs that signal several vsync events
            // with the same timestamp when turning the display off and on. This
            // is a bug in the HWC implementation, but filter the extra events
            // out here so they don't cause havoc downstream.
            if (timestamp == mLastHwVSync[disp]) {
                ALOGW("Ignoring duplicate VSYNC event from HWC (t=%" PRId64 ")",
                        timestamp);
                return;
            }

            mLastHwVSync[disp] = timestamp;
        }

        char tag[16];
        snprintf(tag, sizeof(tag), "HW_VSYNC_%1u", disp);
        ATRACE_INT(tag, ++mVSyncCounts[disp] & 1);
        //这里调用EventHandler类型变量mEventHandler就是SurfaceFlinger，
        //所以调用了SurfaceFlinger的onVSyncReceived函数
        mEventHandler.onVSyncReceived(disp, timestamp);
    }
}

mEventHandler对象类型为EventHandler，我们在SurfaceFlinger的init函数创建HWComposer类实例时候讲SurfaceFlinger强转为EventHandler作为构造函数的参数传入其中。再者SurfaceFlinger继承HWComposer::EventHandler，所以这里没毛病，老铁~所以最终会调用SurfaceFlinger的onVSyncReceived函数。这就是硬件vsync信号的产生，关于vsync信号流程工作我们下面马上会讲到。

5）FB和HWC相关逻辑判断(2)：
如果mFbDev为不为null，情况为：没有hwc或者hwc是1.0老的版本。此时就要设置一些FB的属性了，从主屏幕获取；
如果mFbDev为null，情况为：fb打开失败，或者暂时关闭(上面逻辑分析了)。仅仅打开了hwc，这里我们至少有HWC 1.1，上面分析过了。此时我们要获取显示设备相关属性，进入else if逻辑判断，里面的NUM_BUILTIN_DISPLAYS 为2，则只有主屏幕和扩展屏幕需要查询显示设备属性，调用queryDisplayProperties函数，我们可以产看这个函数：

status_t HWComposer::queryDisplayProperties(int disp) {

    LOG_ALWAYS_FATAL_IF(!mHwc || !hwcHasApiVersion(mHwc, HWC_DEVICE_API_VERSION_1_1));

    // use zero as default value for unspecified attributes
    int32_t values[NUM_DISPLAY_ATTRIBUTES - 1];
    memset(values, 0, sizeof(values));

    const size_t MAX_NUM_CONFIGS = 128;
    uint32_t configs[MAX_NUM_CONFIGS] = {0};
    size_t numConfigs = MAX_NUM_CONFIGS;
    //hwc设备获取显屏配置信息，都是HAL层封装的函数，并保存在这些指针指向内容中
    status_t err = mHwc->getDisplayConfigs(mHwc, disp, configs, &numConfigs);
    //如果一个不可插入的显屏没有连接，则将connected赋值为false
    if (err != NO_ERROR) {
        // this can happen if an unpluggable display is not connected
        mDisplayData[disp].connected = false;
        return err;
    }

    mDisplayData[disp].currentConfig = 0;
    //获取显示相关属性
    for (size_t c = 0; c < numConfigs; ++c) {
        err = mHwc->getDisplayAttributes(mHwc, disp, configs[c],
                DISPLAY_ATTRIBUTES, values);
        if (err != NO_ERROR) {
            // we can't get this display's info. turn it off.
            mDisplayData[disp].connected = false;
            return err;
        }
        //获取成功后，创建一个config对象，用于保存这些属性
        DisplayConfig config = DisplayConfig();
        for (size_t i = 0; i < NUM_DISPLAY_ATTRIBUTES - 1; i++) {
            switch (DISPLAY_ATTRIBUTES[i]) {
                case HWC_DISPLAY_VSYNC_PERIOD://屏幕刷新率
                    config.refresh = nsecs_t(values[i]);
                    break;
                case HWC_DISPLAY_WIDTH://屏幕宽
                    config.width = values[i];
                    break;
                case HWC_DISPLAY_HEIGHT://屏幕高
                    config.height = values[i];
                    break;
                case HWC_DISPLAY_DPI_X://DPI像素X
                    config.xdpi = values[i] / 1000.0f;
                    break;
                case HWC_DISPLAY_DPI_Y://DPI像素Y
                    config.ydpi = values[i] / 1000.0f;
                    break;
                default:
                    ALOG_ASSERT(false, "unknown display attribute[%zu] %#x",
                            i, DISPLAY_ATTRIBUTES[i]);
                    break;
            }
        }
        //如果没有获取到DPI则给个默认的，跟进去是213或者320
        if (config.xdpi == 0.0f || config.ydpi == 0.0f) {
            float dpi = getDefaultDensity(config.width, config.height);
            config.xdpi = dpi;
            config.ydpi = dpi;
        }
        //将每个设备的显示信息存起来
        mDisplayData[disp].configs.push_back(config);
    }

    // FIXME: what should we set the format to?
    //像素编码都为ARGB_8888
    mDisplayData[disp].format = HAL_PIXEL_FORMAT_RGBA_8888;
    //这里讲connected复制为true
    mDisplayData[disp].connected = true;
    return NO_ERROR;
}

queryDisplayProperties查询每个显示设备的属性，主要有以下几步：

hwc设备获取显屏配置信息，都是HAL层封装的函数，并保存在这些指针指向内容中;
获取显示先关属性，并保存起来。

这一部分注释写的比较清晰，可以查看注释。

6）软件VSync信号产生：
如果硬件设备打开失败，则需要软件vsync信号，因此needVSyncThread为true，会进入最后一个if条件判断逻辑，则会创建一个VSyncThread类实例，用来模拟软件vsync信号。

所以我们看看VSyncThread这个类，它集成与Thread，又是一个线程，定义位于HWComposer.h中：

// this class is only used to fake the VSync event on systems that don't
// have it.
class VSyncThread : public Thread {
    HWComposer& mHwc;
    mutable Mutex mLock;
    Condition mCondition;
    bool mEnabled;
    mutable nsecs_t mNextFakeVSync;
    nsecs_t mRefreshPeriod;
    virtual void onFirstRef();
    virtual bool threadLoop();
public:
    VSyncThread(HWComposer& hwc);
    void setEnabled(bool enabled);
};

构造函数位于HWComposer.cpp中：

HWComposer::VSyncThread::VSyncThread(HWComposer& hwc)
    : mHwc(hwc), mEnabled(false),//false
      mNextFakeVSync(0),//0
      mRefreshPeriod(hwc.getRefreshPeriod(HWC_DISPLAY_PRIMARY))//获取主屏幕刷新率
{
}

构造函数中初始化了mEnable变量为false，mNextFakeVSync为0。还有获取了主屏幕的刷新率，并保存在mRefreshPeriod。屏幕刷新率我们在上一篇VSync信号已经科普过了。
我们看看屏幕刷新率的获取，hwc.getRefreshPeriod(HWC_DISPLAY_PRIMARY)函数：

nsecs_t HWComposer::getRefreshPeriod(int disp) const {
    size_t currentConfig = mDisplayData[disp].currentConfig;
    return mDisplayData[disp].configs[currentConfig].refresh;
}

这里获取的屏幕刷新率refresh就是我们之前queryDisplayProperties函数里获取的。其实queryDisplayProperties不止在HWComposer构造函数里调用，还会在钩子函数hook_hotplug里调用，我们查看hotplug函数：

void HWComposer::hotplug(int disp, int connected) {
    if (disp == HWC_DISPLAY_PRIMARY || disp >= VIRTUAL_DISPLAY_ID_BASE) {
        ALOGE("hotplug event received for invalid display: disp=%d connected=%d",
                disp, connected);
        return;
    }
    queryDisplayProperties(disp);
    mEventHandler.onHotplugReceived(disp, bool(connected));
}

如果是主屏幕或者虚拟设备则不会查询设备属性。
我猜测是插入扩展屏幕后，会重新再查询一下屏幕信息，从硬件发出的信号。

好了我们继续回到上面，因为VSyncThread对象付给了一个强指针，所以会调用onFirstRef函数：

1
2
3

void HWComposer::VSyncThread::onFirstRef() {
    run("VSyncThread", PRIORITY_URGENT_DISPLAY + PRIORITY_MORE_FAVORABLE);
}

这样这个软件vsync产生线程就运行起来了，因此我们需要查看threadLoop函数：

bool HWComposer::VSyncThread::threadLoop() {
    { // scope for lock
        Mutex::Autolock _l(mLock);
        while (!mEnabled) {//这个是false，在构造函数里赋值
            //因此会阻塞在这里
            mCondition.wait(mLock);
        }
    }

    const nsecs_t period = mRefreshPeriod;//屏幕刷新率
    const nsecs_t now = systemTime(CLOCK_MONOTONIC);//now
    nsecs_t next_vsync = mNextFakeVSync;//下一次vsync时间，初始值为0
    nsecs_t sleep = next_vsync - now;//距离下次vsync信号中间的睡眠时间
    if (sleep < 0) {//如果sleep小于0，比如第一次进来mNextFakeVSync为0；或者错过n次vsync信号
        // we missed, find where the next vsync should be
        //如果错过了，则重新计算下一次vsync的偏移时间
        sleep = (period - ((now - next_vsync) % period));
        next_vsync = now + sleep;
    }
    //偏移时间加上刷新率周期时间
    mNextFakeVSync = next_vsync + period;

    struct timespec spec;
    spec.tv_sec  = next_vsync / 1000000000;
    spec.tv_nsec = next_vsync % 1000000000;

    int err;
    do {
        //然后睡眠等待下次vsync信号的时间
        err = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &spec, NULL);
    } while (err<0 && errno == EINTR);

    if (err == 0) {//睡眠ok后，则去驱动SurfaceFlinger函数触发
        mHwc.mEventHandler.onVSyncReceived(0, next_vsync);
    }

    return true;
}

上面的代码，我们需要注意两个地方：

mEnabled默认为false，mCondition在这里阻塞，直到有人调用了signal()，同时mEnabled为true；
如果阻塞解开，则会定期休眠，然后去驱动SF，这就相当于产生了持续的Vsync信号。

这个函数会间隔模拟产生VSync的信号的原理是在固定时间发送消息给HWCompoer的消息对象mEventHandler，这个其实就到SurfaceFlinger的onVSyncReceived函数了。用软件模拟VSync信号在系统比较忙的时候可能会丢失一些信号，所以才有中间的sleep小于0的情况。

到目前为止，HWC中新建了一个线程VSyncThread，阻塞中，下面我们看下打开Vsync开关的闸刀是如何建立的，以及何处去开闸刀。

VSync 信号闸刀控制

上面我分析了Vsync软件和硬件信号的产生过程，但是HWC中新建的线程VSyncThread是处于阻塞当中，因此我们需要一个闸刀去控制这个开关。

Vsync信号开关

这个闸刀还是在SurfaceFlinger的init函数中建立的，我们查看这个位置：

void SurfaceFlinger::init() {

    ......
    mEventControlThread = new EventControlThread(this);
    mEventControlThread->run("EventControl", PRIORITY_URGENT_DISPLAY);
    ......
}

这是一个Thread线程类，因此都会实现threadLoop函数。不过我们先看看它的构造函数：

EventControlThread::EventControlThread(const sp<SurfaceFlinger>& flinger):
        mFlinger(flinger),
        mVsyncEnabled(false) {
}

比较简单，将SurfaceFlinger对象传了进来，并且将mVsyncEnabled标志初始为false。
然后我们看看他的threadLoop线程函数：

bool EventControlThread::threadLoop() {
    Mutex::Autolock lock(mMutex);

    bool vsyncEnabled = mVsyncEnabled;//初始为false
    //先调用一遍SurfaceFlinger的eventControl函数
    mFlinger->eventControl(HWC_DISPLAY_PRIMARY, SurfaceFlinger::EVENT_VSYNC,
            mVsyncEnabled);
    //这里是个死循环
    while (true) {
        status_t err = mCond.wait(mMutex);//会阻塞在这里
        if (err != NO_ERROR) {
            ALOGE("error waiting for new events: %s (%d)",
                strerror(-err), err);
            return false;
        }
        //vsyncEnabled 开始和mVsyncEnabled都为false，如果有其他地方改变了mVsyncEnabled,
        //会去调用SF的eventControl函数
        if (vsyncEnabled != mVsyncEnabled) {
            mFlinger->eventControl(HWC_DISPLAY_PRIMARY,
                    SurfaceFlinger::EVENT_VSYNC, mVsyncEnabled);
            vsyncEnabled = mVsyncEnabled;
        }
    }

    return false;
}

threadLoop函数主要逻辑分两步：
1.进来时候在mCond处阻塞，可以看到外面是个死循环，所以如果有其他地方对这个mCond调用了signal，执行完下面的代码又会阻塞；
2.解除阻塞后，如果vsyncEnabled != mVsyncEnabled，也就是开关状态不同，由开到关和由关到开，都回去调用mFlinger->eventControl，调用完成后把这次的开关状态保存，vsyncEnabled = mVsyncEnabled;，与下次做比较。
从上面我们能明显认识到EventControlThread线程，其实就起到了个闸刀的作用，等待着别人去开、关。

所以这个开关操作就在SurfaceFlinger的eventControl函数，我们看看它怎么实现：

void SurfaceFlinger::eventControl(int disp, int event, int enabled) {
    ATRACE_CALL();
    getHwComposer().eventControl(disp, event, enabled);
}

它又会调用HWComposer的eventControl函数，我们继续查看：

void HWComposer::eventControl(int disp, int event, int enabled) {
    //如果是没有申请注册的设备，GG
    if (uint32_t(disp)>31 || !mAllocatedDisplayIDs.hasBit(disp)) {
        ALOGD("eventControl ignoring event %d on unallocated disp %d (en=%d)",
              event, disp, enabled);
        return;
    }
    //不是EVENT_VSYNC事件，GG
    if (event != EVENT_VSYNC) {
        ALOGW("eventControl got unexpected event %d (disp=%d en=%d)",
              event, disp, enabled);
        return;
    }
    status_t err = NO_ERROR;
    //如果是硬件Vsync闸刀，并且不是调试软件vsync
    if (mHwc && !mDebugForceFakeVSync) {
        // NOTE: we use our own internal lock here because we have to call
        // into the HWC with the lock held, and we want to make sure
        // that even if HWC blocks (which it shouldn't), it won't
        // affect other threads.
        Mutex::Autolock _l(mEventControlLock);
        const int32_t eventBit = 1UL << event;
        const int32_t newValue = enabled ? eventBit : 0;
        const int32_t oldValue = mDisplayData[disp].events & eventBit;
        if (newValue != oldValue) {
            ATRACE_CALL();
            //硬件vsync闸刀控制开关
            err = mHwc->eventControl(mHwc, disp, event, enabled);
            if (!err) {
                int32_t& events(mDisplayData[disp].events);
                events = (events & ~eventBit) | newValue;

                char tag[16];
                snprintf(tag, sizeof(tag), "HW_VSYNC_ON_%1u", disp);
                ATRACE_INT(tag, enabled);
            }
        }
        // error here should not happen -- not sure what we should
        // do if it does.
        ALOGE_IF(err, "eventControl(%d, %d) failed %s",
                event, enabled, strerror(-err));
    }
    //如果没有硬件Vsync支持，则调用软件vsync信号闸刀
    if (err == NO_ERROR && mVSyncThread != NULL) {
        mVSyncThread->setEnabled(enabled);
    }
}

这里可以看到还是分软件闸刀和硬件闸刀：

硬件闸刀控制就到了HAL层函数了，调用了mHwc->eventControl(mHwc, disp, event, enabled)这个逻辑；
如果没有硬件Vsync支持，则会调用软件闸刀控制手段，VsyncThread的setEnable函数。

硬件就不用了看，反正也看不到代码。。。我们看看软件Vsync闸刀控制，即VsyncThread的setEnable函数：

void HWComposer::VSyncThread::setEnabled(bool enabled) {
    Mutex::Autolock _l(mLock);
    if (mEnabled != enabled) {
        mEnabled = enabled;
        mCondition.signal();
    }
}

将软件模拟线程VSyncThread的mCondition释放，这时候VSyncThread就会定期产生“信号”，去驱动SF了。

EventControlThread开关

但是我们上边漏了东西，就是EventControlThread本身的闸刀，它自己还在mCond.wait(mMutex)这里阻塞呢。那么EventControlThread这个闸刀到底在哪儿打开呢？

所以我们还得的查看SurfaceFlinger的init函数，再这里它有一处逻辑：

void SurfaceFlinger::init() {

......
    // set initial conditions (e.g. unblank default device)
    initializeDisplays();
......

}

我们查看initializeDisplays函数：

void SurfaceFlinger::initializeDisplays() {
    class MessageScreenInitialized : public MessageBase {
        SurfaceFlinger* flinger;
    public:
        MessageScreenInitialized(SurfaceFlinger* flinger) : flinger(flinger) { }
        virtual bool handler() {
            flinger->onInitializeDisplays();
            return true;
        }
    };
    sp<MessageBase> msg = new MessageScreenInitialized(this);
    postMessageAsync(msg);  // we may be called from main thread, use async message
}

这里放了一个消息给SF的MessageQueue，然后消息回调onInitializeDisplays函数，我们继续查看：

void SurfaceFlinger::onInitializeDisplays() {
    // reset screen orientation and use primary layer stack
    //重置屏幕方向，并使用主屏幕图层
    Vector<ComposerState> state;
    Vector<DisplayState> displays;
    DisplayState d;
    d.what = DisplayState::eDisplayProjectionChanged |
             DisplayState::eLayerStackChanged;
    d.token = mBuiltinDisplays[DisplayDevice::DISPLAY_PRIMARY];
    d.layerStack = 0;
    d.orientation = DisplayState::eOrientationDefault;
    d.frame.makeInvalid();
    d.viewport.makeInvalid();
    d.width = 0;
    d.height = 0;
    displays.add(d);
    //重设屏幕Transaction状态
    setTransactionState(state, displays, 0);
    //我们要找到闸刀开关在这个里面
    setPowerModeInternal(getDisplayDevice(d.token), HWC_POWER_MODE_NORMAL);
    //主显示器刷新率
    const nsecs_t period =
            getHwComposer().getRefreshPeriod(HWC_DISPLAY_PRIMARY);
    mAnimFrameTracker.setDisplayRefreshPeriod(period);
}

其它都不重要，重要在setPowerModeInternal函数，我们继续查看：

void SurfaceFlinger::setPowerModeInternal(const sp<DisplayDevice>& hw,
        int mode) {//HWC_POWER_MODE_NORMAL
    ALOGD("Set power mode=%d, type=%d flinger=%p", mode, hw->getDisplayType(),
            this);
    int32_t type = hw->getDisplayType();//DISPLAY_PRIMARY
    int currentMode = hw->getPowerMode();//HWC_POWER_MODE_OFF

    if (mode == currentMode) {//skip
        ALOGD("Screen type=%d is already mode=%d", hw->getDisplayType(), mode);
        return;
    }

    hw->setPowerMode(mode);
    if (type >= DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES) {
        ALOGW("Trying to set power mode for virtual display");
        return;
    }

    if (currentMode == HWC_POWER_MODE_OFF) {//会走到这里
        getHwComposer().setPowerMode(type, mode);
        if (type == DisplayDevice::DISPLAY_PRIMARY) {
            // FIXME: eventthread only knows about the main display right now
            //EventThread是后面讲到VSync工作流程的部分，后面讲，这里影响不大
            mEventThread->onScreenAcquired();
            //这里才是重点，是打开闸刀的地方
            resyncToHardwareVsync(true);
        }

        mVisibleRegionsDirty = true;
        repaintEverything();
    } else if (mode == HWC_POWER_MODE_OFF) {//不会到这里
        if (type == DisplayDevice::DISPLAY_PRIMARY) {
            disableHardwareVsync(true); // also cancels any in-progress resync

            // FIXME: eventthread only knows about the main display right now
            mEventThread->onScreenReleased();
        }

        getHwComposer().setPowerMode(type, mode);
        mVisibleRegionsDirty = true;
        // from this point on, SF will stop drawing on this display
    } else {//也不会到这儿
        getHwComposer().setPowerMode(type, mode);
    }
}

上面逻辑也不难，只要我们记住以前赋值的变量时多少就行了。
我们获取主显屏的信息，因为是灭的HWC_POWER_MODE_OFF模式，所以进入这个if判断里面，然后调用resyncToHardwareVsync函数。我们继续查看它：

void SurfaceFlinger::resyncToHardwareVsync(bool makeAvailable) {//true
    Mutex::Autolock _l(mHWVsyncLock);
    //true
    if (makeAvailable) {
        mHWVsyncAvailable = true;
    } else if (!mHWVsyncAvailable) {
        ALOGE("resyncToHardwareVsync called when HW vsync unavailable");
        return;
    }
    //主屏幕硬件刷新率
    const nsecs_t period =
            getHwComposer().getRefreshPeriod(HWC_DISPLAY_PRIMARY);
    //设置硬件刷新率
    mPrimaryDispSync.reset();
    mPrimaryDispSync.setPeriod(period);

    if (!mPrimaryHWVsyncEnabled) {//false,进入
        mPrimaryDispSync.beginResync();
        //eventControl(HWC_DISPLAY_PRIMARY, SurfaceFlinger::EVENT_VSYNC, true);
        //打开闸刀
        mEventControlThread->setVsyncEnabled(true);
        mPrimaryHWVsyncEnabled = true;
    }
}

先将mHWVsyncAvailable 标志位置为true，然后设置硬件刷新周期，最后打开mEventControlThread闸刀，我们可以查看它的setVsyncEnabled函数：

void EventControlThread::setVsyncEnabled(bool enabled) {
    Mutex::Autolock lock(mMutex);
    mVsyncEnabled = enabled;
    mCond.signal();
}

可以看到，在这里释放了前面的mCond，让EventControlThread去调用mFlinger->eventControl()函数，从而去HWC中打开Vsync开关。

VSync信号构成

本来我们应该继续顺着代码去跟踪vsync信号的分发过程，但是在这之前我们有必要了解一下vsync信号的构成，以便我们后续分析没有盲点。

我们知道Android是用Vsync来驱动系统的画面更新包括APPview draw ,surfaceflinger 画面的合成,display把surfaceflinger合成的画面呈现在LCD上。要分析Vsync信号的组成，可以了解一下systrace工具。

Systrace简介

Systrace是Android4.1中新增的性能数据采样和分析工具。它可帮助开发者收集Android关键子系统（如surfaceflinger、WindowManagerService等Framework部分关键模块、服务，View系统等）的运行信息，从而帮助开发者更直观的分析系统瓶颈，改进性能。

systrace的使用可以查看官网，或者问娘问哥。
官网使用教程如下：
https://developer.android.com/studio/profile/systrace-walkthru.html

命令行使用方式：
https://developer.android.com/studio/profile/systrace-commandline.html

生成html分析：
https://developer.android.com/studio/profile/systrace.html

分析systrace生成文件，要在eng版本rom，其他的要么无法生成，要么没有权限。

下面我抄一个例子分析。

VSync的构成

就挑一个相册这个应用，是系统自带的system app，包名是com.android.gallery3d。

在systrace中,我们经常可以看到如上图的信息。

红色框1是与Vsync相关event信息.这些Vsync event构成了android系统画面更新基础；
红色框2和红色框3是Vsync-app的信息.我们可以看到红色框2比红色框3稀疏.我们将会在本文说明其原因；
红色框4和红色框5是Vsync-sf的信息.我们可以看到红色框4比红色框5稀疏.我们将会在本文说明其原因。

从上图可以看出来，VSync信号由HW_VSYNC_ON_0,HW_VSYNC_0, Vsync-app和Vsync-sf四部分构成：

HW_VSYNC_ON_0：代表PrimaryDisplay的VSync被enable或disable。0这个数字代表的是display的编号, 0是PrimaryDisplay,如果是Externalmonitor,就会是HW_VSYNC_ON_1。当SF要求HWComposer将Display的VSync打开或关掉时,这个event就会记录下来；
HW_VSYNC_0：代表PrimaryDisplay的VSync发生时间点, 0同样代表display编号。其用来调节Vsync-app和Vsync-sfevent的输出；
Vsync-app：App,SystemUI和systemserver 等viewdraw的触发器；
Vsync-sf：Surfaceflinger合成画面的触发器。

通常为了避免Tearing的现象，画面更新(Flip)的动作通常会在VSync开始的时候才做，因为在VSync开始到它结束前，Display不会把framebuffer资料显示在display上，所以在这段时间做Flip可以避免使用者同时看到前后两个部份画面的现象。目前user看到画面呈现的过程是这样的，app更新它的画面后，它需要透过BufferQueue通知SF，SF再将更新过的app画面与其它的App或SystemUI组合后，再显示在User面前。在这个过程里,有3个component牵涉进来，分别是App、SF、与Display。以目前Android的设计，这三个Component都是在VSync发生的时候才开始做事。我们将它们想成一个有3个stage的pipeline，这个pipeline的clock就LCD的TE信号(60HZ)也即HW_VSYNC_0。

我们来看看android draw的pipeline，如下：

T = 0时, App正在画N, SF与Display都没内容可用
T = 1时, App正在画N+1, SF组合N, Display没Buffer可显示
T = 2时, App正在画N+2, SF组合N+1, Display显示N
T = 3时, App正在画N, SF组合N+2, Display显示N+1
……

如果按照这个步骤，当user改变一个画面时，要等到2个VSync后，画面才会显示在user面前，latency大概是33ms (2个frame的时间)。但是对大部份的操作来讲，可能app加SF画的时间一个frame(16.6ms)就可以完成。因此，Android就从HW_VSYNC_0中产生出两个VSync信号，VSYNC-app是给App用的，VSYNC-sf是给SF用的， Display则是使用HW_VSYNC_0。VSYNC-app与VSYNC-sf可以分别给定一个phase，简单的说：

VSYNC-app = HW_VSYNC_0 + phase_app
VSYNC-sf =HW_VSYNC_0 + phase_sf

从而使App draw和surfaceflinger的合成，错开时间运行。这样就有可能整个系统draw的pipeline更加有效率，从而提高用户体验。

也就是说，如果phase_app与phase_sf设定的好的话，可能大部份user使用的状况， App+SF可以在一个frame里完成，然后在下一个HW_VSYNC_0来的时候,显示在display上。

理论上透过VSYNC-sf与VSYNC-app的确是可以有机会在一个frame里把App+SF做完，但是实际上不是一定可以在一个frame里完成。因为有可能因为CPU调度，GPUperformance不够，以致App或SF没办法及时做完。但是即便如此，把app，surfaceflinger和displayVsync分开也比用一个Vsync来trigger appdraw，surfaceflinger合成，display在LCD上draw的性能要好很多(FPS更高)。因为如果放在同一时间，CPU调度压力更大，可能会卡顿、延迟。

那么是否我们收到LCD的Vsync event就会触发Vsync-app和Vsync-SF呢？如果是这样我们就不会看到本文开头的Vsync-app和Vsync-SF的节奏不一致的情况(红色框2比红色框3稀疏)。事实上，在大多数情况下，APP的画面并不需要一直更新。比如我们看一篇文章，大部份时间，画面是维持一样的，如果我们在每个LCD的VSYNC来的时候都触发SF或APP，就会浪费时间和Power。可是在画面持续更新的情况下，我们又需要触发SF和App的Vsync event。例如玩game或播影片时。就是说我们需要根据是否有内容的更新来选择Vsync event出现的机制。
Vsync event 的触发需要按需出现。所以在Android里，HW_VSYNC_0，Vsync-sf和Vsync-app都会按需出现。HW_VSYNC_0是根据是否需要调节sf和app的Vsync event而出现，而SF和App则会call requestNextVsync()来告诉系统我要在下一个VSYNC需要被trigger。也是虽然系统每秒有60个HW VSYNC，但不代表APP和SF在每个VSYNC都要更新画面。因此，在Android里，是根据SoftwareVSYNC(Vsync-sf，Vsync-app)来更新画面。Software VSYNC是根据HWVSYNC过去发生的时间，推测未来会发生的时间。因此，当APP或SF利用requestNextVsync时，Software VSYNC才会触发VSYNC-sf或VSYNC-app。

下面我们就继续跟着代码，分析VSync信号工作流程。

VSync工作流程

整体概述

我们知道Vsync是android display系统的重要基石,其驱动android display系统不断的更新App侧的绘画,并把相关内容及时的更新到LCD上.其包含的主要代码如下:
frameworks\native\services\surfaceflinger\DispSync.cpp
frameworks\native\services\surfaceflinger\SurfaceFlinger.cpp
frameworks\native\services\surfaceflinger\SurfaceFlinger.cpp$DispSyncSource
frameworks\native\services\surfaceflinger\EventThread.cpp
frameworks\native\services\surfaceflinger\MessageQueue.cpp
frameworks\native\libs\gui\BitTube.cpp
frameworks\native\libs\gui\BufferQueueProducer.cpp

DispSync.cpp：这个class包含了DispSyncThread，是SW-SYNC的心脏，所有的SW-SYNCevent均由其产生。在Android系统中,只有一个DispSync；
SurfaceFlinger.cpp：这个类主要处理layer的合成，它合成好相关的layer后发送command给HW display进行进行显示；
DispSyncSource：Vsync source 在Android系统中有两个instance，一是Vsync-app，另一个Vsync-sf。当SW-SYNC发生时，Vsyncsource会callback到其相应的EventThread，并且会在Systrace上显示出Vsync-sf和Vsync-app的跳变；
EventThread.cpp：Vsync event处理线程，在系统中有两个EventThread，一个用于Vsync-app，另一个用于Vsync-sf。其记录App和SurfaceFlinger的requestnextVsync()请求，当SW-VSYNCevent触发时，EventThread线程通过BitTube通知App或SurfaceFlinger，App开始drawview，SurfaceFlinger 开始合成 dirty layer；
MessageQueue.cpp：MessageQueue 主要处理surfaceflinger的Vsync请求和发生Vsync事件给surfaceFlinger；
BitTube.cpp：Vsync 事件的传输通道。App或Surfaceflinger首先与EventThread建立DisplayEventConnection(EventThread::Connection::Connection,Connection 是BnDisplayEventConnection子类，BitTube是其dataChannel)。App或surfaceFlinger通过call DisplayEventConnection::requestNextVsync()(binder 通信)向EventThread请求Vsync event，当EventThread收到SW-VSYNCevent时，其通过BitTube把Vsync evnet发送给App或SufaceFlinger；
BufferQueueProducer.cpp：在Vsync架构中，其主要作用是向EventThread请求Vsync-sfevent。当App画完一个frame后，其会把画完的buffer放到bufferqueue中通过call BufferQueueProducer::queueBuffer()，进而surfaceflinger进程会通过call DisplayEventConnection:: requestNextVsync()向EventThread请求Vsync event。

Vsyncevent产生的示意图如下：

App需要draw一个frame时，其会向EventThread(appEventThread)请求Vysncevent，当EventThread收到Vsync event时，EventThread通过BitTueb把Vsync event通知到App，同时跳变systrace中的Vsync-app。App收到Vsync-app，开始draw frame。当App画完一个frame后，把画好的内容放到bufferqueue中，就会要求一个Vsync-sf event，以便surfaceflinger在收到Vsync-sf event时合成相关的dirty的内容并通知DisplayHW。Display HW 会在下一个HWvsync时间点，把相关的内容更新到LCD上完成内容的更新。

下面是其大概的流程图：

(SF-1)APP 画完一个frame以后,就会把其绘画的buffer放到buffer queue中.从生产者和消费者的关系来看,App是生产者,surfaceflinger进程是消费者.
(SF-2)在SurfaceFlinger 进程内,当收到有更新的可用的frame时(需要render到LCD ),就会向EventThread请求Vsync event(requestNextVsync()).EventThread会记录下此请求,当下次Vsync event到来时,便会triggerVsync-sf event.
DispSync 不断产生SW-VSYNCEVENT.当SW-VSYNCEVENT产生时,会检查是否有EventListener关心该event(SF和APP请求Vsync 时会在DispSync中创建EventListener并把其相应的DispSyncSource作为EventListener的callback),如有则调用EventListenercallback(DispSyncSource)的onDispSyncEvent.(callbacks[i].mCallback->onDispSyncEvent(callbacks[i].mEventTime)).
DispSyncSource会引起Vsync-sf或Vsync-app跳变,当onDispSyncEvent()被调用时,并且会直接调用EventThread的onVSyncEvent().
EventThread会把Vsync-sf或Vsync-app event通知到App或surfaceFlinger当Vsync-sfevent产生时(callonDispSyncEvent),surfaceflinger进程合成dirty layer的内容(SF-5)并通知Display HW把相关的更新到LCD上.App则在Vsync-ap时开始drawview.
Display HW 便会在HW 的vsync 到来时,更新LCD 的内容(SF-6).
如果有Layer 的内容需要更新,surfaceflinger 便会把相关内容合成在一起,并且通知DisplayHW ,有相关的更新内容.

程序实现

我们来看看其代码的实现，继续回到SurfaceFlinger.cpp中的init函数：

void SurfaceFlinger::init() {

......
    // start the EventThread
    sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync,
            vsyncPhaseOffsetNs, true, "app");
    mEventThread = new EventThread(vsyncSrc);
    sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync,
            sfVsyncPhaseOffsetNs, true, "sf");
    mSFEventThread = new EventThread(sfVsyncSrc);
    mEventQueue.setEventThread(mSFEventThread);

    mEventControlThread = new EventControlThread(this);
    mEventControlThread->run("EventControl", PRIORITY_URGENT_DISPLAY);

    // set a fake vsync period if there is no HWComposer
    if (mHwc->initCheck() != NO_ERROR) {
        mPrimaryDispSync.setPeriod(16666667);
    }

......

}

当surfaceFlinger初始化时，其创建了两个DispSyncSource和两个EventThread，一个用于APP，而另一个用于SurfaceFlinger本身。我们知道DispSyncSource和DispSync协同工作，共同完成Vsyncevent的fire。而EventThread会trigger App draw frame和surfaceFlinger合成”dirty” layer在SW-VSYNCevent产生时。

上面图形是Vsync信号从产生到驱动SF去工作的一个过程，其中绿色部分是HWC中的Vsync信号软件模拟进程，其他都是SF中的：
其中包含4个线程，EventControlThread，就像是Vsync信号产生的闸刀，当然闸刀肯定需要人去打开和关闭，这个人就是SF；
VsyncThread，下面的代码只介绍软件模拟的Vsync信号，这个线程主要工作就是循环定期产生信号，然后调用SF中的函数，这就相当于触发了；
DispSyncThread，是Vsync信号的模型，VsyncThread首先触发DispSyncThread，然后DispSyncThread再去驱动其他事件，它就是Vsync在SF中的代表；
EventThread，具体的事件线程，由DispSyncThread去驱动。

我们接下来根据Vsync-sf先关分析一下流程。

DispSync和DispSyncThread

从上面SurfaceFlinger的init函数中，在构造DispSyncSource会传入一个mPrimaryDispSync的引用，它是SF类中有一个field为DispSync mPrimaryDispSync，因此在SF类创建时会在栈上生成这个对象。我们首先看看这个类的构造函数：

DispSync::DispSync() :
        mRefreshSkipCount(0),
        mThread(new DispSyncThread()) {
    //创建DispSyncThread线程，并运行
    mThread->run("DispSync", PRIORITY_URGENT_DISPLAY + PRIORITY_MORE_FAVORABLE);
    //清除一些变量为0
    reset();
    beginResync();

    ......
}

在DispSync 构造函数中，创建了DispSyncThread线程，并运行。DispSyncThread实现也位于DispSync.cpp中：

DispSyncThread():
        mStop(false),
        mPeriod(0),
        mPhase(0),
        mWakeupLatency(0) {
}

这里面将mStop设置为false，mPeriod设置为0，还有其他的也置为0。因为DispSyncThread是Thread派生的，所以我们需要看看它的线程函数：

virtual bool threadLoop() {
    status_t err;
    nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
    nsecs_t nextEventTime = 0;

    while (true) {
        Vector<CallbackInvocation> callbackInvocations;

        nsecs_t targetTime = 0;

        { // Scope for lock
            Mutex::Autolock lock(mMutex);

            if (mStop) {//false
                return false;
            }

            if (mPeriod == 0) {//0
                //mCond阻塞，当signal，同时mPeriod 不为0时，继续往下执行，
                err = mCond.wait(mMutex);
                if (err != NO_ERROR) {
                    ALOGE("error waiting for new events: %s (%d)",
                            strerror(-err), err);
                    return false;
                }
                continue;
            }
            //计算下一次vsync信号时间时间
            nextEventTime = computeNextEventTimeLocked(now);
            targetTime = nextEventTime;

            bool isWakeup = false;
            //如果还没到下一次vsync时间，则等待中间间隔时间
            if (now < targetTime) {
                err = mCond.waitRelative(mMutex, targetTime - now);
                //等待超时，则唤醒
                if (err == TIMED_OUT) {
                    isWakeup = true;
                } else if (err != NO_ERROR) {
                    ALOGE("error waiting for next event: %s (%d)",
                            strerror(-err), err);
                    return false;
                }
            }
            
            now = systemTime(SYSTEM_TIME_MONOTONIC);
            //唤醒触发
            if (isWakeup) {
                //如果唤醒了，则计算Latency，如果Latency大于500000则强制Latency为500000
                mWakeupLatency = ((mWakeupLatency * 63) +
                        (now - targetTime)) / 64;
                if (mWakeupLatency > 500000) {
                    // Don't correct by more than 500 us
                    mWakeupLatency = 500000;
                }
                if (kTraceDetailedInfo) {
                    ATRACE_INT64("DispSync:WakeupLat", now - nextEventTime);
                    ATRACE_INT64("DispSync:AvgWakeupLat", mWakeupLatency);
                }
            }
            //gatherCallbackInvocationsLocked函数获取本次VSync信号的回调函数列表
            //些回调函数是通过DispSync类的addEventListener函数加入的
            callbackInvocations = gatherCallbackInvocationsLocked(now);
        }
        //接着就调用fireCallbackInvocations来依次调用列表中所有对象的onDispSyncEvent函数
        if (callbackInvocations.size() > 0) {
            fireCallbackInvocations(callbackInvocations);
        }
    }

    return false;
}

DispSyncThread的threadLoop函数，主要这个函数比较计算时间来决定是否要发送信号。主要工作如下：
1. 模型线程DispSyncThread阻塞在mCond，等待别人给mPeriod 赋值和signal；
2. gatherCallbackInvocationsLocked函数获取本次VSync信号的回调函数列表，这些回调函数是通过DispSync类的addEventListener函数加入的；
3. 接着就调用fireCallbackInvocations来依次调用列表中所有对象的onDispSyncEvent函数。

新建的DispSyncThread线程，目前被阻塞，先不管，我们先看模型DispSync和要驱动的事件(DispSyncSource，EventThread等)是如何联系起来的。

DispSyncSource和EventThread

在SF的init函数中，有如下代码，涉及到了DispSync，DispSyncSource，EventThread和mEventQueue的纠缠关系。我们可以看到在驱动事件DispSyncSource的构造中，我们输入了模型DispSync，这样就为回调创造了机会，下面看具体如何实现的。

void SurfaceFlinger::init() {
    ......
        // start the EventThread
        //把模型mPrimaryDispSync(DispSync)保存在DispSyncSource中
    sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync,
            vsyncPhaseOffsetNs, true, "app");
    mEventThread = new EventThread(vsyncSrc);
    sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync,
            sfVsyncPhaseOffsetNs, true, "sf");
    mSFEventThread = new EventThread(sfVsyncSrc);
    mEventQueue.setEventThread(mSFEventThread);
    ......
}

这个我们分布分析：
1）先看下DispSyncSource对象的建立，其实这个对象从名字上看就是模型所驱动的事件。我们看看它的构造函数，也位于SurfaceFlinger.cpp中：

DispSyncSource(DispSync* dispSync, nsecs_t phaseOffset, bool traceVsync,
    const char* label) :
        mValue(0),
        mPhaseOffset(phaseOffset),
        mTraceVsync(traceVsync),
        mVsyncOnLabel(String8::format("VsyncOn-%s", label)),
        mVsyncEventLabel(String8::format("VSYNC-%s", label)),
        mDispSync(dispSync) {}

构造函数中主要设置了模型mDispSync(dispSync)，以及触发时间的偏移量mPhaseOffset(phaseOffset)。这个实参vsyncPhaseOffsetNs和sfVsyncPhaseOffsetNs定义如下，也位于SurfaceFlinger.cpp中：

// This is the phase offset in nanoseconds of the software vsync event
// relative to the vsync event reported by HWComposer.  The software vsync
// event is when SurfaceFlinger and Choreographer-based applications run each
// frame.
//
// This phase offset allows adjustment of the minimum latency from application
// wake-up (by Choregographer) time to the time at which the resulting window
// image is displayed.  This value may be either positive (after the HW vsync)
// or negative (before the HW vsync).  Setting it to 0 will result in a
// minimum latency of two vsync periods because the app and SurfaceFlinger
// will run just after the HW vsync.  Setting it to a positive number will
// result in the minimum latency being:
//
//     (2 * VSYNC_PERIOD - (vsyncPhaseOffsetNs % VSYNC_PERIOD))
//
// Note that reducing this latency makes it more likely for the applications
// to not have their window content image ready in time.  When this happens
// the latency will end up being an additional vsync period, and animations
// will hiccup.  Therefore, this latency should be tuned somewhat
// conservatively (or at least with awareness of the trade-off being made).
static const int64_t vsyncPhaseOffsetNs = VSYNC_EVENT_PHASE_OFFSET_NS;

// This is the phase offset at which SurfaceFlinger's composition runs.
static const int64_t sfVsyncPhaseOffsetNs = SF_VSYNC_EVENT_PHASE_OFFSET_NS;

这个phase就是用来调节vsync信号latency 时间，其定义我也是搜了整个工程才找到如下定义：

generic版本中phase-app为0，phase-sf为5000000。（不知道对不对=。=）

2）我们继续往下看，mSFEventThread = new EventThread(sfVsyncSrc);先看看EventThread的构造函数：

EventThread::EventThread(const sp<VSyncSource>& src)
    : mVSyncSource(src),
      mUseSoftwareVSync(false),//软vsync初始为false
      mVsyncEnabled(false),//vsync使能初始为false
      mDebugVsyncEnabled(false),
      mVsyncHintSent(false) {
    //i<2,只遍历主屏幕和扩展屏幕
    for (int32_t i=0 ; i<DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES ; i++) {
        mVSyncEvent[i].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
        mVSyncEvent[i].header.id = 0;
        mVSyncEvent[i].header.timestamp = 0;
        mVSyncEvent[i].vsync.count =  0;
    }
    struct sigevent se;
    se.sigev_notify = SIGEV_THREAD;
    se.sigev_value.sival_ptr = this;
    se.sigev_notify_function = vsyncOffCallback;
    se.sigev_notify_attributes = NULL;
    timer_create(CLOCK_MONOTONIC, &se, &mTimerId);
}

EventThread是Thread的派生类，还是RefBase的间接派生类，所以我们需要产看它的onFirstRef函数：

1
2
3

void EventThread::onFirstRef() {
    run("EventThread", PRIORITY_URGENT_DISPLAY + PRIORITY_MORE_FAVORABLE);
}

将这个线程启动了起来，那么我们需要看下线程循环函数：

bool EventThread::threadLoop() {
    DisplayEventReceiver::Event event;
    Vector< sp<EventThread::Connection> > signalConnections;
    //等待事件到来
    signalConnections = waitForEvent(&event);

    // dispatch events to listeners...
    //把事件分发给listener
    const size_t count = signalConnections.size();
    for (size_t i=0 ; i<count ; i++) {
        const sp<Connection>& conn(signalConnections[i]);
        // now see if we still need to report this event
        //然后调用每个连接的postEvent来发送Event
        status_t err = conn->postEvent(event);
        if (err == -EAGAIN || err == -EWOULDBLOCK) {
            // The destination doesn't accept events anymore, it's probably
            // full. For now, we just drop the events on the floor.
            // FIXME: Note that some events cannot be dropped and would have
            // to be re-sent later.
            // Right-now we don't have the ability to do this.
            ALOGW("EventThread: dropping event (%08x) for connection %p",
                    event.header.type, conn.get());
        } else if (err < 0) {
            // handle any other error on the pipe as fatal. the only
            // reasonable thing to do is to clean-up this connection.
            // The most common error we'll get here is -EPIPE.
            removeDisplayEventConnection(signalConnections[i]);
        }
    }
    return true;
}

这个线程函数里面主要做了三件事：
1. 调用waitForEvent等待事件到来；
2. 把事件分发给listener；
3. 然后调用每个连接的postEvent来发送Event。

我们分部查看，先看看waitForEvent实现：

     
// This will return when (1) a vsync event has been received, and (2) there was
// at least one connection interested in receiving it when we started waiting.
Vector< sp<EventThread::Connection> > EventThread::waitForEvent(
        DisplayEventReceiver::Event* event)
{
    Mutex::Autolock _l(mLock);
    Vector< sp<EventThread::Connection> > signalConnections;

    do {
        bool eventPending = false;
        bool waitForVSync = false;

        size_t vsyncCount = 0;
        nsecs_t timestamp = 0;
        //上面初始化EventThread时候，都是0
        for (int32_t i=0 ; i<DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES ; i++) {
            timestamp = mVSyncEvent[i].header.timestamp;
            if (timestamp) {
                // we have a vsync event to dispatch
                *event = mVSyncEvent[i];
                mVSyncEvent[i].header.timestamp = 0;
                vsyncCount = mVSyncEvent[i].vsync.count;
                break;
            }
        }

        if (!timestamp) {//0
            // no vsync event, see if there are some other event
            eventPending = !mPendingEvents.isEmpty();
            if (eventPending) {//初始时候为false
                // we have some other event to dispatch
                *event = mPendingEvents[0];
                mPendingEvents.removeAt(0);
            }
        }

        // find out connections waiting for events
        //// 初始也是空的 SortedVector< wp<Connection> > mDisplayEventConnections;
        size_t count = mDisplayEventConnections.size();
        for (size_t i=0 ; i<count ; i++) {
            sp<Connection> connection(mDisplayEventConnections[i].promote());
            if (connection != NULL) {
                bool added = false;
                if (connection->count >= 0) {
                    // we need vsync events because at least
                    // one connection is waiting for it
                    waitForVSync = true;
                    if (timestamp) {
                        // we consume the event only if it's time
                        // (ie: we received a vsync event)
                        if (connection->count == 0) {
                            // fired this time around
                            connection->count = -1;
                            signalConnections.add(connection);
                            added = true;
                        } else if (connection->count == 1 ||
                                (vsyncCount % connection->count) == 0) {
                            // continuous event, and time to report it
                            signalConnections.add(connection);
                            added = true;
                        }
                    }
                }

                if (eventPending && !timestamp && !added) {
                    // we don't have a vsync event to process
                    // (timestamp==0), but we have some pending
                    // messages.
                    signalConnections.add(connection);
                }
            } else {
                // we couldn't promote this reference, the connection has
                // died, so clean-up!
                mDisplayEventConnections.removeAt(i);
                --i; --count;
            }
        }

        // Here we figure out if we need to enable or disable vsyncs
        if (timestamp && !waitForVSync) {
            // we received a VSYNC but we have no clients
            // don't report it, and disable VSYNC events
            disableVSyncLocked();
        } else if (!timestamp && waitForVSync) {
            // we have at least one client, so we want vsync enabled
            // (TODO: this function is called right after we finish
            // notifying clients of a vsync, so this call will be made
            // at the vsync rate, e.g. 60fps.  If we can accurately
            // track the current state we could avoid making this call
            // so often.)
            enableVSyncLocked();
        }

        // note: !timestamp implies signalConnections.isEmpty(), because we
        // don't populate signalConnections if there's no vsync pending
        if (!timestamp && !eventPending) {
            // wait for something to happen
            if (waitForVSync) {
                // This is where we spend most of our time, waiting
                // for vsync events and new client registrations.
                //
                // If the screen is off, we can't use h/w vsync, so we
                // use a 16ms timeout instead.  It doesn't need to be
                // precise, we just need to keep feeding our clients.
                //
                // We don't want to stall if there's a driver bug, so we
                // use a (long) timeout when waiting for h/w vsync, and
                // generate fake events when necessary.
                bool softwareSync = mUseSoftwareVSync;
                nsecs_t timeout = softwareSync ? ms2ns(16) : ms2ns(1000);
                if (mCondition.waitRelative(mLock, timeout) == TIMED_OUT) {
                    if (!softwareSync) {
                        ALOGW("Timed out waiting for hw vsync; faking it");
                    }
                    // FIXME: how do we decide which display id the fake
                    // vsync came from ?
                    mVSyncEvent[0].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
                    mVSyncEvent[0].header.id = DisplayDevice::DISPLAY_PRIMARY;
                    mVSyncEvent[0].header.timestamp = systemTime(SYSTEM_TIME_MONOTONIC);
                    mVSyncEvent[0].vsync.count++;
                }
            } else {
                // Nobody is interested in vsync, so we just want to sleep.
                // h/w vsync should be disabled, so this will wait until we
                // get a new connection, or an existing connection becomes
                // interested in receiving vsync again.
                //所以EventThread初始的时候会在这阻塞
                mCondition.wait(mLock);
            }
        }
    } while (signalConnections.isEmpty());
    //因为mCondition有可能异常返回，所以要看下这个while，就知道何时mCondition被正常的signal
    //如果signalConnections不为空了，这时候就会从while中退出来
    //也就是上面的mDisplayEventConnections有东西了
    // here we're guaranteed to have a timestamp and some connections to signal
    // (The connections might have dropped out of mDisplayEventConnections
    // while we were asleep, but we'll still have strong references to them.)
    return signalConnections;
}

waitForEvent函数中下面代码段，timestamp为0表示没有时间，waitForSync为true表示至少有一个客户和EventThread建立了连接。这段代码一旦有客户连接，就调用enableVSyncLocked接收DispSyncSource的VSync信号。如果在接受信号中，所有客户都断开了连接，则调用disableVSyncLocked函数停止接受DispSyncSource对象的信号。

虽然代码量有些多，但是我们是初始化时候，所以省去了很多判断逻辑。因此主要工作就不多了，主要如下：
①初始的时候，mCondition会阻塞；
② 因为mCondition有可能异常返回，所以要看下外围的while循环，就知道何时mCondition会被signal。即使mCondition异常返回，也会再去判断signalConnections是否为空。空的话继续阻塞，如果signalConnections不为空了，这时候就会从while中退出来，也就是上面的mDisplayEventConnections有东西了。所以mDisplayEventConnections需要留意何时赋值啦。

至此，创建了一个mSFEventThread = new EventThread(sfVsyncSrc);，也阻塞着了。。

至于下面的 2. 把事件分发给listener；3. 然后调用每个连接的postEvent来发送Event。这两个步骤我们下面会讲到，这里先不看它。

3）从上面得知在DsipSync里面创建的DispSyncThread线程阻塞等待着；还有上面的EventThread线程，也阻塞等待了。
下面我们继续看mEventQueue.setEventThread(mSFEventThread);会不会解除阻塞。这里EventThread和SF主线程的MessageQueue又纠缠到了一起：

void MessageQueue::setEventThread(const sp<EventThread>& eventThread)
{
    mEventThread = eventThread;
    //SF与EventThread建立连接
    mEvents = eventThread->createEventConnection();
    //创建通信通道
    mEventTube = mEvents->getDataChannel();
    //Looper连接通道，进行消息循环
    mLooper->addFd(mEventTube->getFd(), 0, Looper::EVENT_INPUT,
            MessageQueue::cb_eventReceiver, this);
}

我们依然分部查看：
1. 首先， eventThread->createEventConnection()，新建了一个Connection对象：

1
2
3

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

Connection对象如下图所示:

Connection中保存了了一个EventThread对象，和一个生成的BitTube对象mChannel，下面看下Connection的构造函数：

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

调用了BitTube的无参构造函数：

BitTube::BitTube()
    : mSendFd(-1), mReceiveFd(-1)
{
    init(DEFAULT_SOCKET_BUFFER_SIZE, DEFAULT_SOCKET_BUFFER_SIZE);
}

构造函数里调用了init函数：

void BitTube::init(size_t rcvbuf, size_t sndbuf) {
    int sockets[2];
    if (socketpair(AF_UNIX, SOCK_SEQPACKET, 0, sockets) == 0) {
        size_t size = DEFAULT_SOCKET_BUFFER_SIZE;
        setsockopt(sockets[0], SOL_SOCKET, SO_RCVBUF, &rcvbuf, sizeof(rcvbuf));
        setsockopt(sockets[1], SOL_SOCKET, SO_SNDBUF, &sndbuf, sizeof(sndbuf));
        // sine we don't use the "return channel", we keep it small...
        setsockopt(sockets[0], SOL_SOCKET, SO_SNDBUF, &size, sizeof(size));
        setsockopt(sockets[1], SOL_SOCKET, SO_RCVBUF, &size, sizeof(size));
        fcntl(sockets[0], F_SETFL, O_NONBLOCK);
        fcntl(sockets[1], F_SETFL, O_NONBLOCK);
        mReceiveFd = sockets[0];
        mSendFd = sockets[1];
    } else {
        mReceiveFd = -errno;
        ALOGE("BitTube: pipe creation failed (%s)", strerror(-mReceiveFd));
    }
}

建立一个域套接字，用fcntl设置成非阻塞模式，然后两个fd，一个读一个写，mSendFd和mReceiveFd。

我们上面创建一个Connection，但是又是一个sp指针，所以就得看看它的onFirstRef函数：

void EventThread::Connection::onFirstRef() {
    // NOTE: mEventThread doesn't hold a strong reference on us
    mEventThread->registerDisplayEventConnection(this);
}

这里又调用EventThread的registerDisplayEventConnection函数，我们继续查看：

status_t EventThread::registerDisplayEventConnection(
        const sp<EventThread::Connection>& connection) {
    Mutex::Autolock _l(mLock);
    //把connection添加到mDisplayEventConnections
    mDisplayEventConnections.add(connection);
    //mCondition解除
    mCondition.broadcast();
    return NO_ERROR;
}

前面提到，EventThread一直阻塞在waitForEvent中，正是这个mCondition，这里也对mDisplayEventConnections添加了东西，不为空了。
为了方便分析，我们再把前面的waitForEvent函数列出来，这次就是另一套逻辑了：

// This will return when (1) a vsync event has been received, and (2) there was
// at least one connection interested in receiving it when we started waiting.
Vector< sp<EventThread::Connection> > EventThread::waitForEvent(
        DisplayEventReceiver::Event* event)
{
    Mutex::Autolock _l(mLock);
    Vector< sp<EventThread::Connection> > signalConnections;

    do {
        bool eventPending = false;
        bool waitForVSync = false;

        size_t vsyncCount = 0;
        nsecs_t timestamp = 0;
        for (int32_t i=0 ; i<DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES ; i++) {
            timestamp = mVSyncEvent[i].header.timestamp;
            if (timestamp) {
                // we have a vsync event to dispatch
                *event = mVSyncEvent[i];
                mVSyncEvent[i].header.timestamp = 0;
                vsyncCount = mVSyncEvent[i].vsync.count;
                break;
            }
        }

        if (!timestamp) {//这次这里还是0
            // no vsync event, see if there are some other event
            eventPending = !mPendingEvents.isEmpty();
            if (eventPending) {
                // we have some other event to dispatch
                *event = mPendingEvents[0];
                mPendingEvents.removeAt(0);
            }
        }

        // find out connections waiting for events
        //有东西了，就是保存的Connection
        size_t count = mDisplayEventConnections.size();
        for (size_t i=0 ; i<count ; i++) {
            sp<Connection> connection(mDisplayEventConnections[i].promote());
            if (connection != NULL) {
                bool added = false;
                if (connection->count >= 0) {
                    // we need vsync events because at least
                    // one connection is waiting for it
                    waitForVSync = true;
                    if (timestamp) {
                        // we consume the event only if it's time
                        // (ie: we received a vsync event)
                        if (connection->count == 0) {
                            // fired this time around
                            connection->count = -1;
                            signalConnections.add(connection);
                            added = true;
                        } else if (connection->count == 1 ||
                                (vsyncCount % connection->count) == 0) {
                            // continuous event, and time to report it
                            signalConnections.add(connection);
                            added = true;
                        }
                    }
                }

                if (eventPending && !timestamp && !added) {
                    // we don't have a vsync event to process
                    // (timestamp==0), but we have some pending
                    // messages.
                    signalConnections.add(connection);
                }
            } else {
                // we couldn't promote this reference, the connection has
                // died, so clean-up!
                mDisplayEventConnections.removeAt(i);
                --i; --count;
            }
        }

        // Here we figure out if we need to enable or disable vsyncs
        if (timestamp && !waitForVSync) {//0 true
            // we received a VSYNC but we have no clients
            // don't report it, and disable VSYNC events
            disableVSyncLocked();
        } else if (!timestamp && waitForVSync) {//所以走到了这里
            // we have at least one client, so we want vsync enabled
            // (TODO: this function is called right after we finish
            // notifying clients of a vsync, so this call will be made
            // at the vsync rate, e.g. 60fps.  If we can accurately
            // track the current state we could avoid making this call
            // so often.)
            //这次走到了这里
            enableVSyncLocked();
        }

        // note: !timestamp implies signalConnections.isEmpty(), because we
        // don't populate signalConnections if there's no vsync pending
        if (!timestamp && !eventPending) {//0 false
            // wait for something to happen
            if (waitForVSync) {//true
                // This is where we spend most of our time, waiting
                // for vsync events and new client registrations.
                //
                // If the screen is off, we can't use h/w vsync, so we
                // use a 16ms timeout instead.  It doesn't need to be
                // precise, we just need to keep feeding our clients.
                //
                // We don't want to stall if there's a driver bug, so we
                // use a (long) timeout when waiting for h/w vsync, and
                // generate fake events when necessary.
                bool softwareSync = mUseSoftwareVSync;
                nsecs_t timeout = softwareSync ? ms2ns(16) : ms2ns(1000);
                if (mCondition.waitRelative(mLock, timeout) == TIMED_OUT) {
                    if (!softwareSync) {
                        ALOGW("Timed out waiting for hw vsync; faking it");
                    }
                    // FIXME: how do we decide which display id the fake
                    // vsync came from ?
                    mVSyncEvent[0].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
                    mVSyncEvent[0].header.id = DisplayDevice::DISPLAY_PRIMARY;
                    mVSyncEvent[0].header.timestamp = systemTime(SYSTEM_TIME_MONOTONIC);
                    mVSyncEvent[0].vsync.count++;
                }
            } else {
                // Nobody is interested in vsync, so we just want to sleep.
                // h/w vsync should be disabled, so this will wait until we
                // get a new connection, or an existing connection becomes
                // interested in receiving vsync again.
                mCondition.wait(mLock);//这个之前的wait已经解开了
            }
        }
    } while (signalConnections.isEmpty());

    // here we're guaranteed to have a timestamp and some connections to signal
    // (The connections might have dropped out of mDisplayEventConnections
    // while we were asleep, but we'll still have strong references to them.)
    return signalConnections;
}

所以在waitEvent里，这次的逻辑和上次不同了，主要是一下几点：
①建立Connection后，mCondition返回了；
②这里timestamp 还是0 ;
③mDisplayEventConnections非空了，将waitForVSync = true;
④所以会执行到enableVSyncLocked();。

那么我们看看enableVSyncLocked函数：

void EventThread::enableVSyncLocked() {
    if (!mUseSoftwareVSync) {//false
        // never enable h/w VSYNC when screen is off
        if (!mVsyncEnabled) {//false
            mVsyncEnabled = true;//将mVsyncEnabled 置为true
            //DispSyncSource的setCallback，把mCallback设置为EventThread
            mVSyncSource->setCallback(static_cast<VSyncSource::Callback*>(this));
            //调用DispSyncSource的setVSyncEnabled
            mVSyncSource->setVSyncEnabled(true);
        }
    }
    mDebugVsyncEnabled = true;
    sendVsyncHintOnLocked();
}

这个也分两步：
①将mVsyncEnabled 设为true，调用mVSyncSource->setCallback(static_cast(this));，this为EventThread，既是调用DispSyncSource的setCallback，把mCallback设置为EventThread：

virtual void setCallback(const sp<VSyncSource::Callback>& callback) {
    Mutex::Autolock lock(mMutex);
    mCallback = callback;
}

②调用mVSyncSource->setVSyncEnabled(true);，既是调用DispSyncSource的setVSyncEnabled：

virtual void setVSyncEnabled(bool enable) {//true
    // Do NOT lock the mutex here so as to avoid any mutex ordering issues
    // with locking it in the onDispSyncEvent callback.
    if (enable) {
        ////在硬件模型mDispSync中添加addEventListener，一个参数为偏移量，一个为DispSyncSource
        status_t err = mDispSync->addEventListener(mPhaseOffset,
                static_cast<DispSync::Callback*>(this));
        if (err != NO_ERROR) {
            ALOGE("error registering vsync callback: %s (%d)",
                    strerror(-err), err);
        }
        //ATRACE_INT(mVsyncOnLabel.string(), 1);
    } else {
        status_t err = mDispSync->removeEventListener(
                static_cast<DispSync::Callback*>(this));
        if (err != NO_ERROR) {
            ALOGE("error unregistering vsync callback: %s (%d)",
                    strerror(-err), err);
        }
        //ATRACE_INT(mVsyncOnLabel.string(), 0);
    }
}

从上面的代码可以看出，这里是将驱动事件DispSyncSource和硬件模型mDispSync建立起关系。既然调用了DispSync的addEventListener，那么我们就继续查看：

//DispSync的addEventListener
status_t DispSync::addEventListener(nsecs_t phase,
        const sp<Callback>& callback) {

    Mutex::Autolock lock(mMutex);
    return mThread->addEventListener(phase, callback);
}
    //DispSyncThread的addEventListener
    status_t addEventListener(nsecs_t phase, const sp<DispSync::Callback>& callback) {
        Mutex::Autolock lock(mMutex);

        for (size_t i = 0; i < mEventListeners.size(); i++) {
            if (mEventListeners[i].mCallback == callback) {
                return BAD_VALUE;
            }
        }

        EventListener listener;
        listener.mPhase = phase;
        listener.mCallback = callback;

        // We want to allow the firstmost future event to fire without
        // allowing any past events to fire.  Because
        // computeListenerNextEventTimeLocked filters out events within a half
        // a period of the last event time, we need to initialize the last
        // event time to a half a period in the past.
        listener.mLastEventTime = systemTime(SYSTEM_TIME_MONOTONIC) - mPeriod / 2;
        ////把listener放到mEventListeners中
        mEventListeners.push(listener);
        ////释放mCond
        mCond.signal();

        return NO_ERROR;
    }

这里可以看出，驱动事件DispSyncSource是硬件模型DispSync的“listener”，监听者，把两者联系了起来。并把DispSyncThread线程中的阻塞mCond解除，但是，前面我们分析过，还要mPeriod 非0。我们可以回顾一下上面的代码片段，DispSyncThread的threadLoop函数：

virtual bool threadLoop() {
    ......
    while(true){
    ......
    if (mPeriod == 0) {
                    err = mCond.wait(mMutex);
                    if (err != NO_ERROR) {
                        ALOGE("error waiting for new events: %s (%d)",
                                strerror(-err), err);
                        return false;
                    }
                    continue;
                }
    ......
    }
    ......
}

那么哪里给mPeriod 赋值呢？我们上面讲EventControlThread闸刀控制线程的时候，initializeDisplays()函数会被调用，最终会调用resyncToHardwareVsync函数，这个里面会获取mPeriod屏幕刷新率，然后给mPeriod 赋值：

void SurfaceFlinger::resyncToHardwareVsync(bool makeAvailable) {
......
    const nsecs_t period =
            getHwComposer().getRefreshPeriod(HWC_DISPLAY_PRIMARY);

    mPrimaryDispSync.reset();
    mPrimaryDispSync.setPeriod(period);
......
}

然后调用DispSync的setPeriod函数：

void DispSync::setPeriod(nsecs_t period) {
    Mutex::Autolock lock(mMutex);
    mPeriod = period;//mPeriod 赋值后，已经不为0
    mPhase = 0;
    //调用线程的更新模型函数
    mThread->updateModel(mPeriod, mPhase);
}

mPeriod 赋值后，已经不为0；然后调用线程的更新模型函数updateModel：

void updateModel(nsecs_t period, nsecs_t phase) {
    Mutex::Autolock lock(mMutex);
    mPeriod = period;
    mPhase = phase;
    //mCond阻塞解除
    mCond.signal();
}

至此，DispSync中设置了监听者DispSyncSource，mPeriod 也不为0，硬件模型线程不再阻塞，不阻塞就会去处理vsync事件，这个我们后面会讲。

经过调用mEvents = eventThread->createEventConnection();完成了一下几个功能：
①MessageQueue中保存了一个Connection，mEvents ；
②EventThread中保存了这个Connection，mDisplayEventConnections.add(connection);
③mVSyncSource->setCallback 把mCallback = callback 设置为EventThread；
④在mDispSync中注册listener，放到DispSyncthread的mEventListeners中，这个listener的callback就是mVSyncSource。

2. 然后就是创建通信通道。接着继续MessageQueue::setEventThread()函数，调用mEventTube = mEvents->getDataChannel()。
mEvents类型为sp< IDisplayEventConnection > ;在上一步mEvents = eventThread->createEventConnection();返回的直接是Connection对象。Connection继承于BnDisplayEventConnection，BnDisplayEventConnection继承于BnInterface< IDisplayEventConnection >。因此我们找到bp端的getDataChannel函数，位于BpDisplayEventConnection类当中，继承于BpInterface< IDisplayEventConnection >位于frameworks/native/libs/gui/IDisplayEventConnection.cpp：

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

相应的bn端位onTransact方法于也位于IDisplayEventConnection.cpp：

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());//这个getDataChannel是Connection类的函数
            channel->writeToParcel(reply);
            return NO_ERROR;
        } break;
        ......
    }
    return BBinder::onTransact(code, data, reply, flags);
}

上面那个getDataChannel是Connection类的函数，我们看看Connection的getDataChannel函数：

1
2
3

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

mChannel就是我们在构造函数里面的new BitTube()。
这样mEventTube 中只包含了读fd，而mEvents这个connection中的mChannel只剩下写fd，两个依然是一对读写，，但是分开了，如下图所示：

3. 继续调用，这里就是把mEventTube这个读tube注册到SF主线程的Looper中去，回调函数为MessageQueue::cb_eventReceiver：

1 2	mLooper->addFd(mEventTube->getFd(), 0, ALOOPER_EVENT_INPUT, MessageQueue::cb_eventReceiver, this);

这里用到了Android消息处理零散分析的内容，如果忘记了，可以翻一翻。
因为注册了回调事件，因此我们需要查看MessageQueue::cb_eventReceiver函数：

int MessageQueue::cb_eventReceiver(int fd, int events, void* data) {
    MessageQueue* queue = reinterpret_cast<MessageQueue *>(data);
    return queue->eventReceiver(fd, events);
}

然后是eventReceiver函数：

int MessageQueue::eventReceiver(int /*fd*/, int /*events*/) {
    ssize_t n;
    DisplayEventReceiver::Event buffer[8];
    while ((n = DisplayEventReceiver::getEvents(mEventTube, buffer, 8)) > 0) {
        for (int i=0 ; i<n ; i++) {
            if (buffer[i].header.type == DisplayEventReceiver::DISPLAY_EVENT_VSYNC) {
#if INVALIDATE_ON_VSYNC //1
                mHandler->dispatchInvalidate();
#else
                mHandler->dispatchRefresh();
#endif
                break;
            }
        }
    }
    return 1;
}

这里会从MessageQueue的读BitTube中读出event，然后调用mHandler->dispatchInvalidate():

void MessageQueue::Handler::dispatchInvalidate() {
    if ((android_atomic_or(eventMaskInvalidate, &mEventMask) & eventMaskInvalidate) == 0) {
        mQueue.mLooper->sendMessage(this, Message(MessageQueue::INVALIDATE));
    }
}

接收消息就是handleMessage函数：

void MessageQueue::Handler::handleMessage(const Message& message) {
    switch (message.what) {
        case INVALIDATE:
            android_atomic_and(~eventMaskInvalidate, &mEventMask);
            mQueue.mFlinger->onMessageReceived(message.what);
            break;
        case REFRESH:
            android_atomic_and(~eventMaskRefresh, &mEventMask);
            mQueue.mFlinger->onMessageReceived(message.what);
            break;
        case TRANSACTION:
            android_atomic_and(~eventMaskTransaction, &mEventMask);
            mQueue.mFlinger->onMessageReceived(message.what);
            break;
    }
}

进而去调用SF的onMessageReceived函数，最终每次Vsync信号来了，SF都会去执行handleMessageTransaction()等函数。

void SurfaceFlinger::onMessageReceived(int32_t what) {
    ATRACE_CALL();
    switch (what) {
    case MessageQueue::TRANSACTION:
        handleMessageTransaction();
        break;
    case MessageQueue::INVALIDATE:
        handleMessageTransaction();
        handleMessageInvalidate();
        signalRefresh();
        break;
    case MessageQueue::REFRESH:
        handleMessageRefresh();
        break;
    }
}

至此我们对于vsync消息的准备逻辑工作都做完了。但是细心的读者应该发现了，我们还没有按正常流程处理一遍vsync信号，就是当vsync产生后，SurfaceFlinger的回调函数onVSyncReceived处理过程。接下来我们就分析一下这个过程。

VSync信号处理

矫正VSync时间

我们再次借助上面那幅Vsync event产生的示意图：

这里HW_VSYNC就是HW_VSYNC_0。

当SF从HWComposer收到VSYNC(HW_VSYNC_0)时，会调用onVSyncReceived函数处理：

void SurfaceFlinger::onVSyncReceived(int type, nsecs_t timestamp) {
    bool needsHwVsync = false;

    { // Scope for the lock
        Mutex::Autolock _l(mHWVsyncLock);
        if (type == 0 && mPrimaryHWVsyncEnabled) {//将新的VSYNC时间交给DispSync
            needsHwVsync = mPrimaryDispSync.addResyncSample(timestamp);
        }
    }

    if (needsHwVsync) {//是否还需要vsync
        enableHardwareVsync();
    } else {
        disableHardwareVsync(false);
    }
}

它会利用DispSync::addResyncSample将新的VSYNC时间交给DispSync。addResyncSample决定是否还需要HW_VSYNC的输入,如果不需要,就会将HW_VSYNC关掉。

然后我们继续查看DispSync::addResyncSample：

bool DispSync::addResyncSample(nsecs_t timestamp) {
    Mutex::Autolock lock(mMutex);
    //MAX_RESYNC_SAMPLES = 32
    size_t idx = (mFirstResyncSample + mNumResyncSamples) % MAX_RESYNC_SAMPLES;
    mResyncSamples[idx] = timestamp;

    if (mNumResyncSamples < MAX_RESYNC_SAMPLES) {
        mNumResyncSamples++;
    } else {
        mFirstResyncSample = (mFirstResyncSample + 1) % MAX_RESYNC_SAMPLES;
    }
    //这个函数很重要，用来计算SW_VSYNC的值，直到误差小于threshold
    updateModelLocked();
    //MAX_RESYNC_SAMPLES_WITHOUT_PRESENT = 12
    if (mNumResyncSamplesSincePresent++ > MAX_RESYNC_SAMPLES_WITHOUT_PRESENT) {
        resetErrorLocked();
    }

    if (kIgnorePresentFences) {
        // If we don't have the sync framework we will never have
        // addPresentFence called.  This means we have no way to know whether
        // or not we're synchronized with the HW vsyncs, so we just request
        // that the HW vsync events be turned on whenever we need to generate
        // SW vsync events.
        return mThread->hasAnyEventListeners();
    }

    return mPeriod == 0 || mError > kErrorThreshold;
}

DispSync是利用HW_VSYNC和PresentFence来判断是否需要开启HW_VSYNC。HW_VSYNC最少要3个，最多是32个，实际上要用几个则不一定，DispSync拿到3个HW_VSYNC后就会计算出SW_VSYNC，只要收到的PresentFence没有超过误差，则HW_VSYNC就会关掉，以便节省功耗.不然会继续开启HW_VSYNC计算SW_VSYNC的值，直到误差小于threshold。其计算的方法是DispSync::updateModelLocked()：

void DispSync::updateModelLocked() {
    if (mNumResyncSamples >= MIN_RESYNC_SAMPLES_FOR_UPDATE) {
        nsecs_t durationSum = 0;
        for (size_t i = 1; i < mNumResyncSamples; i++) {
            size_t idx = (mFirstResyncSample + i) % MAX_RESYNC_SAMPLES;
            size_t prev = (idx + MAX_RESYNC_SAMPLES - 1) % MAX_RESYNC_SAMPLES;
            durationSum += mResyncSamples[idx] - mResyncSamples[prev];
        }

        mPeriod = durationSum / (mNumResyncSamples - 1);

        double sampleAvgX = 0;
        double sampleAvgY = 0;
        double scale = 2.0 * M_PI / double(mPeriod);
        for (size_t i = 0; i < mNumResyncSamples; i++) {
            size_t idx = (mFirstResyncSample + i) % MAX_RESYNC_SAMPLES;
            nsecs_t sample = mResyncSamples[idx];
            double samplePhase = double(sample % mPeriod) * scale;
            sampleAvgX += cos(samplePhase);
            sampleAvgY += sin(samplePhase);
        }

        sampleAvgX /= double(mNumResyncSamples);
        sampleAvgY /= double(mNumResyncSamples);

        mPhase = nsecs_t(atan2(sampleAvgY, sampleAvgX) / scale);

        if (mPhase < 0) {
            mPhase += mPeriod;
        }

        if (kTraceDetailedInfo) {
            ATRACE_INT64("DispSync:Period", mPeriod);
            ATRACE_INT64("DispSync:Phase", mPhase);
        }

        // Artificially inflate the period if requested.
        mPeriod += mPeriod * mRefreshSkipCount;

        mThread->updateModel(mPeriod, mPhase);
    }
}

基本思想如下:

计算目前收到HW_VSYNC间隔,取平均值(AvgPeriod) HW_VSYNC;
将每个收到的VSYNC时间与AvgPeriod算出误差. (Delta = Time %AvgPeriod);
将Delta转换成角度(DeltaPhase),如果AvgPeriod是360度,DeltaPhase = 2PIDelta/AvgPeriod;
从DeltaPhase可以得到DeltaX与DeltaY (DeltaX =cos(DeltaPhase), DeltaY = sin(DeltaPhase));
将每个收到的VSYNC的DeltaX与DeltaY取平均,可以得到AvgX与AvgY;
利用atan与AvgX, AvgY可以得到平圴的phase (AvgPhase);
AvgPeriod + AvgPhase就是SW_VSYNC。

当DispSync收到addPresentFence时(最多记录8个sample)，每一个fence的时间算出(Time% AvgPeriod)的平方当作误差，将所有的Fence误差加总起来如果大于某个Threshold，就表示需要校正(DispSync::updateErrorLocked)。校正的方法是呼叫DispSync::beginResync()将所有的HW_VSYNC清掉,开启HW_VSYNC。等至少3个HW_VSYNC再重新计算。

处理VSync消息

消息处理流程依然需要分步骤：
1）我们继续回到DispSync的threadLoop函数中，回顾上面的内容，因为在这里我们需要搜集vsync触发事件：

virtual bool threadLoop() {
......
        while (true) {
            Vector<CallbackInvocation> callbackInvocations;
            ......
            callbackInvocations = gatherCallbackInvocationsLocked(now);
                        }

            if (callbackInvocations.size() > 0) {
                fireCallbackInvocations(callbackInvocations);
            }
        }    
......
}

mPeriod 不为0，也有signal，DispSyncThread线程不阻塞了，执行gatherCallbackInvocationsLocked(now)和fireCallbackInvocations(callbackInvocations)。我们先查看gatherCallbackInvocationsLocked函数：

Vector<CallbackInvocation> gatherCallbackInvocationsLocked(nsecs_t now) {
    Vector<CallbackInvocation> callbackInvocations;
    nsecs_t ref = now - mPeriod;
    //这里的mEventListeners[i].mCallback都是驱动的事件DispSyncSource
    for (size_t i = 0; i < mEventListeners.size(); i++) {
        nsecs_t t = computeListenerNextEventTimeLocked(mEventListeners[i],
                ref);

        if (t < now) {
            CallbackInvocation ci;
            ci.mCallback = mEventListeners[i].mCallback;
            ci.mEventTime = t;
            callbackInvocations.push(ci);
            mEventListeners.editItemAt(i).mLastEventTime = t;
        }
    }

    return callbackInvocations;
}

然后发送事件，fireCallbackInvocations函数：

void fireCallbackInvocations(const Vector<CallbackInvocation>& callbacks) {
    for (size_t i = 0; i < callbacks.size(); i++) {
        //这里的callbacks[i].mCallback，就是驱动的事件DispSyncSource
        callbacks[i].mCallback->onDispSyncEvent(callbacks[i].mEventTime);
    }
}

这里会回调DispSyncSource的onDispSyncEvent函数：

virtual void onDispSyncEvent(nsecs_t when) {
    sp<VSyncSource::Callback> callback;
    {
        Mutex::Autolock lock(mMutex);
        callback = mCallback;

        if (mTraceVsync) {
            mValue = (mValue + 1) % 2;
            ATRACE_INT(mVsyncEventLabel.string(), mValue);
        }
    }
    ////这里的callback为EventThread
    if (callback != NULL) {
        callback->onVSyncEvent(when);
    }
}

继续调用，这里已经从驱动事件，转化到驱动事件的线程EventThread中，填充EventThread的mVSyncEvent，因此我们查看onVSyncEvent函数：

void EventThread::onVSyncEvent(nsecs_t timestamp) {
    Mutex::Autolock _l(mLock);
    mVSyncEvent[0].header.type = DisplayEventReceiver::DISPLAY_EVENT_VSYNC;
    mVSyncEvent[0].header.id = 0;
    mVSyncEvent[0].header.timestamp = timestamp;
    mVSyncEvent[0].vsync.count++;
    mCondition.broadcast();
}

这里将mVSyncEvent事件相关属性复制，且threadLoop等待阻塞唤醒，以便往下继续执行。

2）EventThread的waitForEvent()，返回signalConnections，就是开始建立的Connection，这个Connection里面有个BitTube的写fd，另外的读fd在MessageQueue中。

此时我们回到上面没有讲的，当waitForEvent返回后，2. 把事件分发给listener；3. 然后调用每个连接的postEvent来发送Event。这两个步骤。
waitForEvent返回，调用conn->postEvent(event)，我们查看Connection的postEvent函数：

status_t EventThread::Connection::postEvent(
        const DisplayEventReceiver::Event& event) {
    ssize_t size = DisplayEventReceiver::sendEvents(mChannel, &event, 1);
    return size < 0 ? status_t(size) : status_t(NO_ERROR);
}
//位于frameworks/native/libs/gui/DisplayEventReceiver.cpp中
ssize_t DisplayEventReceiver::sendEvents(const sp<BitTube>& dataChannel,
        Event const* events, size_t count)
{
    return BitTube::sendObjects(dataChannel, events, count);
}

也就是通过Connection的写fd将event发送给MessageQueue。
这时候MessageQueue的looper epoll返回，最终会去调用response.request.callback->handleEvent，最终调用的是mCallback(fd, events, data);而这个mCallback，既是MessageQueue::cb_eventReceiver。这一步可以查看Android消息处理零散分析的内容，如果忘记了，可以翻一翻。
所以最终还是回到了MessageQueue::cb_eventReceiver：

int MessageQueue::cb_eventReceiver(int fd, int events, void* data) {
    MessageQueue* queue = reinterpret_cast<MessageQueue *>(data);
    return queue->eventReceiver(fd, events);
}

这个步骤上面分析过了。最终去调用SF的onMessageReceived函数，最终每次Vsync信号来了，SF都会去执行handleMessageTransaction()等函数。

void SurfaceFlinger::onMessageReceived(int32_t what) {
    ATRACE_CALL();
    switch (what) {
    case MessageQueue::TRANSACTION:
        handleMessageTransaction();
        break;
    case MessageQueue::INVALIDATE:
        handleMessageTransaction();
        handleMessageInvalidate();
        signalRefresh();
        break;
    case MessageQueue::REFRESH:
        handleMessageRefresh();
        break;
    }
}

这就是vsync信号的处理过程，和上面章节的结合在了一起。

VSync实例

重要点小结

我们列出了EventThread的重要function.下面一一说明其功能：

EventThread::Connection::Connection()：Connection的构造函数.用于进程间的通信by BitTube..在此处主要是搭建一个通路(BitTube)来完成client(App或SurfaceFlinger)对Vsync event事件的请求(通过requestNextVsync())和EventThread把SW-Vsync event callback到其感兴趣的client。需要注意的是App是通过SurfaceFlinger::createDisplayEventConnection()创建此连接的，而sufaceflinge是在其初始化时call EventQueue.setEventThread(mSFEventThread)创建的。所以对App 的EventThread 来说可能有多个connection ,也有可能没有，而对sufaceflinger目前来说有且只有一个；
spEventThread::createEventConnection()：创建 Connection连接；
status_tEventThread::registerDisplayEventConnection()：如其名所描述.其功能是把创建的Connection注册到一个容器中。当SW-VSYNCevent发生时，EventThread会从Connection注册的容器中，找到那些对SW-VSYNC event感兴趣的connection并把vsyncevent通过BitTube传到client；
void EventThread::requestNextVsync()：Clinet 端通过Connection call 这函数通知EventThread，其对SW-SYNCevent的请求；
voidEventThread::onVSyncEvent(nsecs_t timestamp)：SW-VSYNCEVENT 发生时，DispSyncSource 会call此函数，告知EventThread，Vsync event已经发生，如果此时有connect对Vsync感兴趣，EventThread便会通过connect->postEvent(event)把Vsync事件发送到client端(App或surfaceflinger)；
bool EventThread::threadLoop()：线程的主体函数.其完成两件事，一是把对SW-VSYNC event有请求并且还没有处理的connect找出来，二是把Vsyncevent通过connect通知到client；
Vector< sp> EventThread::waitForEvent()：EventThread 的主要功能都在此函数里，此函数由threadLoop()调用。EventThread在大部分时间里是sleep的，如果系统的性能比较好，那么其sleep的节奏是和SW-VSYNC event的节奏一致，即16.6mssleep一次。然而由于其App或surfaceflinger没有Vsync的请求，其sleep的时间为更长。此函数的名为waitForEvent，其到底在等什么event？原来此函数在等待的event就是Dispsync产生的SW-SYNC event，其功能check所有的connect是否有Vsync事件请求根据不同的情况做如下处理。

所有的connect都没有Vsync请求，则其通过disableVSyncLocked()，disableVsync event，那么此EventThread将不会收到SW-SYNCevent，一直sleep直到有connect有Vsync请求为止。
在所有的connect中，有SW-SYNC event请求，但是当其请求SW-SYNCevent时，SW-SYNCevent还没有fire，则其通过enableVSyncLocked() enable Vsync并进入sleep。当下一个SW-SYNCevent来到时，便把所有有SW-SYNCevent请求的connection返回给threadLoop。

下图是整个流程的大图：

我们接下来依然以gallery3d（相册）为例子，分析Vsync-app和Vsync-sf的工作流程。

Vsync-app实例

App 通过Connection向EventThread请求SW-VSYNCevent(最终并且通过callEventThread::requestNextVsync()).一般来说App是通过Choreographer.doScheduleVsync()来请求Vsyncevent.
DispSync 产生SW-VSYNC event并call DispSyncSource的onDispSyncEvent().
DispSyncSource产生VSYNC-app信号跳变.
同时DispSyncSource使EventThread(app)的waitForEvent()结束sleep,并把VSYNC-app通知到App进程(gallery3d).
Gallery3d 进程收到VSYNC-app信号,在其main线程(UI Thread)中开始draw一个frame(发送draw command给GL thread).
GL Thread 开始draw view.
当GL thread 线程Draw 完一frame后,把draw buffer放到buffer queue中.
SufaceView中画好的buffer 数据增加为1.这个buffer 将被surfaceflinger 在适当的时候合成.

Vsync-sf实例

App draw 完一个frame (SurfaceView) 并且把此frame通过调用BufferQueueProducer::queueBuffer()放到 bufferqueue中,并且通过call EventThread::requestNextVsync(),请求SW-VSYNCevent.此时由于DispSync没有fireSW-Sync event所以EventThread在EventThread::waitForEvent()中sleep.
DispSync触发SW-SYNC event信号并且call DispSyncSource::onDispSyncEvent().
在DispSyncSource::onDispSyncEvent()中首先引起Vsync-sf跳变,然后在call EventThread::onVSyncEvent(nsecs_ttimestamp).
在EventThread::onVSyncEvent(nsecs_ttimestamp)中,会唤醒EventThread::waitForEvent()中的sleep,从而发送消息到Surfaceflinger.
SurfaceFlinger收到EventThread发过来的Vsync-sf跳变信息,开始合成dirty layer, 本例是SurfaceView.合成完以后发送更新的消息到DisplayHW.
Display HW 收到更新的消息时,HW vsync event还没有来,因此DisplayHW sleep了一段事件.当HWvsync event到来时,DisplayHW 便更新其LCD的内容.把最新的内容显示在LCD上.

自此我们完成了Vsync子系统的分析。

性能影响

回到系统性能上,我们可以看出系统的性能(FPS)可能于如下因素有关：

DispSync的调度. DispSync是Vsync系统的心脏,如果DispSync来不及调度,则有可能由于去SW-SYNC event的产生不及时而影响系统的性能.
View Draw 花费了过多的时间也会引性能问题, 如果其不能在一个SW-SYNC时间内完成, 那么此应用就会有一个Janks.由于现在的Androd系统都采用了HWUI,viewdraw往往是GPU直接draw,所以很多时候是GPUperformance问题.
HW display 的性能问题.LCD 上所绘画的内容, 最终需要HW display在HW vsync触发是把其内容显示在LCD上.
Binder 的调度问题, 我们可以看到无论是requestNextVsync () 还是queueBuffer()都是App通过binder与surfaceflinger进程通信的.而这些binder在大多数时间是sleep的.如果binder由于CPU调度而错过了一个Vsync跳变点,那么就有一个frame发生Janks.

结语

对于VSync信号的学习就到这里，我们可以看到还是十分复杂的。

VSync信号

2017-05-21T05:02:22.000Z

在我们详细分析SurfaceFlinger之前要了解一下VSync信号，为下一节分析Vsync工作原理打下基础。

VSync信号相关

首先我们要了解以下几个概念：

屏幕刷新率

即 Refresh Rate 或 Scanning Frequency，单位赫兹/Hz，是指设备刷新屏幕的频率，该值对于特定的设备来说是个常量，如 60hz。

每一台CRT显示器都有自己的刷新率，其单位是Hz，其数值是显示器每秒钟更新画面的次数。不同的显示器支持再不同分辨率下的不同刷新率。它的范围可以从低到60高到100。注意它不是你游戏中所提到的那个FPS。如果你设置了一个特定的刷新率，显示器将一直按照这个速率刷新画面。甚至画面没有任何的改变。
液晶显示器就不同了。LCD的每个像素在被告知改变的时候将一直是亮着的。他们不需要刷新。但是因为VGA(或是DVI)的工作原理，LCD不得不从显示卡那里按一定的速率得到新的新画面。这就是虽然LCD不必要更新，但是他还是有自己的刷新率。

如下图，屏幕的刷新过程是每一行从左到右（行刷新，水平刷新，Horizontal Scanning），从上到下（屏幕刷新，垂直刷新，Vertical Scanning）。当整个屏幕刷新完毕，即一个垂直刷新周期完成，会有短暂的空白期，此时发出 VSync 信号。所以，VSync 中的 V 指的是垂直刷新中的垂直/Vertical。
(显示器的扫描方式分为“逐行扫描”和“隔行扫描”两种。逐行扫描比隔行扫描拥有列稳定显示效果。早期的显示器因为成本所限，使用逐行扫描方式的产品要比隔行扫描的贵许多，但随着技术进步，隔行扫描显示器现在已经被淘汰。我们可以翻一翻《电视原理》)

对于一个特定的设备，帧率和刷新频率没有必然的大小关系。

帧率

即 Frame Rate，单位 fps，是指 gpu 生成帧的速率，如 33 fps，60fps，越高越好。

我想这里的每一人都明白FPS。它显示显示卡在每秒钟可以描画多少画面。这显然是越高越好。但是对于快速变化的游戏而言，你的FPS很难一直保持同样的数值，他会随着你所看到的显示卡所要描画的画面的复杂程度而变化。

VSync

安卓系统中有 2 种 VSync 信号：屏幕产生的硬件 VSync 和由 SurfaceFlinger 将其转成的软件 Vsync 信号。后者经由 Binder 传递给 Choreographer。
硬件 VSync 是一个脉冲信号，起到开关或触发某种操作的作用。

显示器参数

TFT LCD 有 vsync,hsync,hspw,hbpd,hfpd, vspw,vbpd, vfpd 等参数，这些参数都是由以前的 CRT(阴极射线显像管)带过来的, 而 TFT 液晶跟 CRT 显示方法根本不同, 至于为什么这些参数也会引入到 TFT 中,大概是因为VGA(或是DVI)工作原理，上文提到过。
这网站有更权威的描述 http://www.linux-fbdev.org/HOWTO/2.html ，然后是英文。。。

CRT 侧面看是个漏斗状的真空的东东, 根部就是电子枪, 打出的电子撞击前面的玻璃面上的荧光物质, 荧光物发光. 控制电子枪按规律射出电子, 逐行的打到荧光物质上, 打完一行(也即扫描完一行), 就回头扫描下一行….. 扫描完一个显示屏所有的行后, 就是一幅完整的画面了, 称为一帧(frame), 扫描过程如果非常快, 人眼看到是一幅完整画面, 但实际是一个个点发不同光组成的. 扫描得慢时, 就会觉得闪烁了(以前听老师讲课, 说在他们的年代, 能明显看到一行一行刷过的壮观场景)。
一帧扫描完, 再回头从第一行开始继续扫描, 重复过程. 看到的就是持续在显示的画面了(实际上, 电子的运动轨迹是由磁场控制的, 电子枪没有机械的运动, 为好理解, 就当是电子枪做了机械运动吧)。

描述方式多数显示器选择从左上角开始, 从左至右, 到了右边界, 再偏转到左边界的下一行, 这是所谓的”Z”型扫描。类似地扫描完最后一帧时, 要偏转回左上角起始处, 准备扫描下一帧。这个上面那一幅图描述过了。

(科普一下，ignore it。start------)

HSYNC 信号用于告诉电子枪该扫描下一行了, 即要转到下一行起始处了；
VSYNC 信号告诉电子枪该显示下一帧了, 即该转回左上角起始处了；

H for Horizontal, V for vertical。在这里 Hsync, Vsync 两者各表示一种信号, 分别由 HSPW 及 VSPW 两个参数确定信号持续时间, 也就是脉冲的宽度.

在扫描一行中, 首先

HSYNC 脉冲信号为高电平, 一发出此信号, 电子枪迅速移回左边界, 期间电子枪不发射电子.
在 HSYNC 信号持续时间上的某点, 电子枪开始再次向右扫描了, 等 HSYNC 信号结束, 表示该开始显示下一行的数据了, 电子枪又要开始发射电子.
在HSYNC 信号结束与开始显示数据之间, 可以插入一段延时(由 HBPD 参数控制)让显示屏仍然不显示有效数据(效果就是黑色), 是为显示屏左边框.
到 HFPD 结束, 电子枪才可以发射电子, 显示该行的有效数据.
显示完毕. 又该开始发出 HSYNC 信号了. 在一行中有效数据扫描完毕与 HSYNC 信号发出之间也插入一段延时 HFPD, 是为显示屏右边框,之后, 就是重复过程了.

因此, 显示一行时序为： HSPW -> HBPD -> 扫描数据 -> HFPD .

类似地, 垂直扫描一帧的时序：VSPW -> VBPD -> 扫描有效行 -> VFPD .

为什么要有边框(vbpd, vfpd, hbpd, hfpd)? 按上边贴出网页的说法:
Usually, one doesn’t use that feature nowadays, as we have tunable monitors that allow stretching the mode to the physical limits of the monitor.
我的理解是:确实是以前的显示器调整显示屏边界用的,而新的显示有调整能力了, 所以不再需要刻意关注了,但术语被保留了下来.

举个栗子

对于 TFT LCD, 但这些参数作用是同样的. 但如何确定 ? TFT 的 LCD 的 datasheet 中一定得标有。
如型号 WXCAT35-TG3 3.5 寸的液晶中有表如下:

对照下边的时序图(注: 时序图的 Vsync, Hsync 信号(红框圈出的)跟上边讲的有点出入, 信号都是低电平, 而非高电平, 因此编程时要设置信号反相, 如s3c244a 的 LCDCON5的INVLINE 及 INVFRAME 即是干这活的):

tvp 即 VSPW
tvb 即 VBPD
tvf 即 VFPD
thp 即 HSPW
thb 即 HBPD
thf 即 HFPD

参考的时钟就是 CLK, 一个 CLK 时钟, 完成一个像素点的显示。

计算帧频率(刷新频率)的方法就是所有的像素点跟边沿(边框,hbpd 之类),同步脉冲的时间相加, 结果就是显示完整一帧所需时间, 其倒数即是帧频率。

Linux 的 LCD 驱动

LCD 驱动主要得完成两部分, 一是跟 framebuffer 注册驱动；二是设置 LCD 控制器的寄存器, 以适配 LCD。
struct fb_info 是关键, 有显示驱动的所有信息, 要拿此结构跟 framebuffer 注册, 代表着本驱动, 该结构定义在 ,在驱动程序中, 主体部分就是实现 struct fb_info .
在Android SurfaceFlinger 学习之路(一)—-Android图形显示之HAL层Gralloc模块实现中提到过这一部分。
在该结构中, 以下定义的三个字段也是比较重要的, 要填一些数据入去:

1
2
3

struct fb_var_screeninfo var;   /* Current var */
struct fb_fix_screeninfo fix;   /* Current fix */
struct fb_ops *fbops;

struct fb_fix_screeninfo 里定义的 pixclock 是像素点的周期, 单位是皮秒, 数值等于像素点显示频率的倒数. 如上图贴出的表格中, Dclk 那行中, 6.4 Mhz 就是频率, 频率倒数即为周期, 换算出来为 156250 ps, 约为表中给出的 156 ns.

驱动具体的实现, 要看开发板对应的驱动源码文件, 一般位于 kernel_src/drivers/video/ 下,我们以前下的Android源码，找到对应设备分支下的，应为位于kernel/{branch}/drivers/video/吧。

简单描述

在手机平台，LCD,Camera，TV的接线上，都会用到PCLK，VSYNC和HSYNC这三个信号。可见这三个信号和显示关系非常大。首先我们先看这三个信号的作用：

PCLK：有些方案给他起名字叫：DotCLK。是像素点同步时钟信号。也就是每个PCLK对应一个像素点。
VSYNC：是场同步信号。以高电平有效为例，VSYNC置高直到被拉低，这个区段所输出的所有影像数据组成一个frame。
HSYNC：是行同步信号。就是在告诉接收端：“HSYNC”有效时段内接收端接收到的所有的信号输出属同一行。

若要显示一个640x480的画面，显示不正确的时候，若量PCLK，VSYNC和HSYNC这三个信号，就可以知道这三个信号配置是否有问题，一般来讲，这种情况是有公式的：

VSync = HSYNC x 320；
Hsync = PCLK x 640；

sensor的同步信号可以简单的理解为sensor向其信号接收端所发送的宣告信号。比如HSYNC，就是sensor这告诉接收端：“HSYNC”有效时段内sensor所有的信号输出属同一行。VSYNC同理，以高电平有效为例，VSYNC置高直到被拉低，这个区段sensor所输出的所有影像数据组成一个frame。同步信号的频率决定于pixel clock，比如一行有640个pixel，那么HSYNC的频率为：PCLK/(640+dummy);Vsync同理。

(科普结束，ignore it，too。end------)

VSync 信号的作用

tearing 画面撕裂

首先，我们来看下，没有引入 VSync 时，屏幕显示图像的工作流程。

如上图，CPU/GPU 向 Buffer 中生成图像，屏幕从 Buffer 中取图像、刷新后显示。这是一个典型的生产者——消费者模型。理想的情况是帧率和刷新频率相等，每绘制一帧，屏幕显示一帧。而实际情况是，二者之间没有必然的大小关系，如果没有锁来控制同步，很容易出现问题。

所谓”撕裂”就是一种画面分离的现象，就象你照一张照片，在旋转哪怕一度再照一张照片，然后把两张照片的从中间裁开，用一张照片的上半部与另一张的下半部对接起来。这样得到的画像虽然相似但是上半部和下半部确实明显的不同。这就被称之为视觉现实上的撕裂。它不会一直从中间分开，它可能靠近上面也可能下面，分离点可能在屏幕上下移动，也可能在两点间前后移动。（译者：原文的作者实在是啰嗦，其实就是画面移动较快的时候，画面看上去是两截。这种现象恐怕打游戏的都看到过，最好玩过PS2游戏的，用模拟器，在比较差的显卡和CPU上面，撕裂现象更为明显）。

为什么会发生这种现象呢？让我们举一个特定的例子。让我们假定你的显示器的刷新率是75Hz, 你真在玩你最喜欢的游戏，而且你现在有100的FPS.这就意味着你的显示器每秒更新75次画面，而你的显示卡每秒更新100次，比你的显示器快33%。这就意味着在你的显示器更新画面的时间里，显示卡描画了1+1/3的画面。这样在画面显示的时候，那个1/3的画面就会覆盖那个完整画面上部的1/3。在下次的图像刷新的时候，显示卡会描画剩下来得2/3和新的2/3的画面。这样，因为屏幕的更新只能跟上画面更新的2/3，这样图像的上部的1/3或是下部的1/3就会和剩下的画面合不上。如果画面的变化不大可能不太会注意到这一点，但是如果你快速的环顾四周那就会非常的明显。

Double Buffer 双缓冲

现在，一个很普遍的误解就产生了。一些人认为解决这个问题的方法就是简单设置一个FPS的限制让FPS不超过显示器的刷新率，这样显示卡就不会超过75FPS,这样就可以了。真的吗？错！

在我解释为什么之前，让我来讲一下双倍缓冲。双倍缓冲一种用来减轻撕裂问题，虽然不是很完全。基本上来说你有一个显示缓冲和一个后备缓冲。当显示器要显示画面的时候，就会从显示缓冲里“推出”显示画面。显示卡则在后备缓冲里描画另外一个新画面，当描画完成后则将新画面考入显示缓冲里。但是这个过程需要时间，如果显示器的刷新在拷贝过程中进行的话，显示器上显示的仍然是个”撕裂”的画面。

VSync 通过建立一个不让在显示器刷新前将后备缓冲中的画面拷贝到显示缓冲中的规定来解决这个问题。如果FPS高于刷新率的话，没有问题。后备缓冲的更新完成后，系统处于等待状态。当显示器刷新后，后备缓存考入显示缓存，显示卡则可以在后备缓存里描画新的画面，这样就很有效的将你的FPS限制在显示器的刷新率的范围内。

为了解决单缓存的“tearing”问题，双缓存和 VSync 应运而生。双重缓存模型如下图：

两个缓存区分别为 Back Buffer 和 Frame Buffer。GPU 向 Back Buffer 中写数据，屏幕从 Frame Buffer 中读数据。VSync 信号负责调度从 Back Buffer 到 Frame Buffer 的复制操作，可认为该复制操作在瞬间完成。其实，该复制操作是等价后的效果，实际上双缓冲的实现方式是交换 Back Buffer 和 Frame Buffer 的名字，更具体的说是交换内存地址（有没有联想到那道经典的笔试题目：“有两个整型数，如何用最优的方法交换二者的值？”），通过二进制运算“异或”即可完成，所以可认为是瞬间完成。(《数字电路技术》当中有一章节应该讲过运算器还是控制器来着，可以设计一个异或电路。忘了，回去翻一翻~)

附加小福利：
假设两个数x和y，则有：
方法1，算术运算（加减）：
x=x+y; //x暂存两数之和
y=x-y; //y为两数之和减去y，即原来的x
x=x-y; //x为两数之和减去现在的y（原来的x），变成原来的y
方法2，逻辑运算（异或）：
x^=y; //x先存x和y两者的信息
y^=x; //保持x不变，利用x异或反转y的原始值使其等于x的原始值
x^=y; //保持y不变，利用x异或反转y的原始值使其等于y的原始值

双缓冲的模型下，工作流程这样的：
在某个时间点，一个屏幕刷新周期完成，进入短暂的刷新空白期。此时，VSync 信号产生，先完成复制操作，然后通知 CPU/GPU 绘制下一帧图像。复制操作完成后屏幕开始下一个刷新周期，即将刚复制到 Frame Buffer 的数据显示到屏幕上。

在这种模型下，只有当 VSync 信号产生时，CPU/GPU 才会开始绘制。这样，当帧率大于刷新频率时，帧率就会被迫跟刷新频率保持同步，从而避免“tearing”现象。

Jank 掉帧

注意，当 VSync 信号发出时，如果 GPU/CPU 正在生产帧数据，此时不会发生复制操作。屏幕进入下一个刷新周期时，从 Frame Buffer 中取出的是“老”数据，而非正在产生的帧数据，即两个刷新周期显示的是同一帧数据。这是我们称发生了“掉帧”（Dropped Frame，Skipped Frame，Jank）现象。

让我们来看一个另外一个不同的例子。让我们假定你已经玩到了你最喜欢的游戏的最后一关，这个游戏有很好的图像.你显示器的刷新率还是在75。但是你的FPS现在只有50了，比刷新率要低33%.这就意味着每次显示器刷新图像，你的显示卡只能画出下一桢画面的2/3。让我们看看它是如何工作的。

显示器刚刚更新，第一桢的画面已经拷贝到显示缓冲，第二桢的画面的2/3被写入后备缓冲。
这时显示器重新刷新，它会第一次从显示缓冲里提取第一桢的画面。然后显示卡开始完成的第二桢剩下的部分。但是它必须等待，应为再下一次刷新之前它是不会上传的。
显示器再次刷新，显示器不得不第二次从显示缓冲里提取第一桢的画面，然后第二桢的画面被写入显示缓冲。显示卡在后备缓冲中写入第三桢的2/3。
等到显示器刷新，第一次从显示缓冲里提取第二桢的画面，显示卡开始完成的第三桢剩下的部分。然后又是第二次从显示缓冲里提取第二桢的画面，然后第三桢的画面被写入显示缓冲。

如此类推。这样4次显示器刷新，我们只能的到2桢的画面。如果刷新率是75的话，我们只能得到35的FPS.很明显这个数值要低于显示卡可以带到的50FPS.这主要就是应为显示卡不得不在描画后备缓冲上浪费时间。而在此过程中，后备缓冲上的画面是不能被拷贝到显示缓冲。理论上讲，双缓冲的VSync,FPS将是一组不连续的整数，其等于刷新率/n,n是正整数。也就是说，如果你的刷新率是60hz,你能得到的FPS只能是 60，30，20，15，12，10 等等。你可以注意到60到30是一个相当大的差距。只要的显示卡的FPS在60到30之间，你说得到的真实FPS都将只能等于30！

如下图，A、B 和 C 都是 Buffer。蓝色代表 CPU 生成 Display List，绿色代表 GPU 执行 Display List 中的命令从而生成帧，黄色代表生成帧完成。

现在，你明白为什么有人不喜欢它了。让我们回到一开始的那个例子。你在玩你最喜欢的游戏，刷新率是75HZ,100FPS。你打开VSync.游戏就被限制在75FPS,没有问题，没有撕裂图像，看起来不错。你到了一个图像特别复杂的地方，在不用VSync的时候，你的FPS下降到了60左右。但是你打开了VSync，你的FPS实际就只有37.5。这样你的游戏突然从75FPS变成了37.5FPS,不管37.5仍然很流畅但是你一定会注意到刷新率突然减少了一半。当让如果以下变到25FPS的话，实际的现实率可能就只有17.5。本来还可以玩的游戏，就变成了幻灯片。这就是大家不喜欢它的原因。

如果你的游戏的FPS可以一直稳定的大于显示器的刷新率，VSync是个不错的东西。但是如果FPS忽大忽小。VSync就是让人烦的东西。如果你的游戏FPS一直都小于刷新率的话，实际的FPS要远远小于显示卡可以显示的FPS.看上去就象是VSync降低了你的FPS,但是从技术角度讲，不是应为图像太复杂，而是因为VSync就是这样工作的。

Triple Buffer 三缓冲

双重缓存的缺陷在于：当 CPU/GPU 绘制一帧的时间超过 16 ms 时，会产生 Jank。更要命的是，产生 Jank 的那一帧的显示期间，GPU/CPU 都是在闲置的。

也不是说所有的希望都没有了。现在的triple-buffering技术可以用来解决这个问题。让我们再来看刷新率75。FPS50的例子。

第一桢在显示缓冲，第二桢的2/3在后备缓冲。
显示器刷新第一桢第一次被显示，在后备缓冲里描画第二桢的剩下的1/3，在第二后备缓冲里描画第三桢的1/3(因为我们有三级缓冲了)。
显示器再次刷新第一桢第二次被显示，第二桢放入在显示缓冲，第三桢的的1/3放入后备缓冲，第二后备缓冲里描画第三桢剩下的2/3。
接下来显示器再次刷新的时候，第二桢被显示，第三桢就可以放入显示缓冲，这样我们就可以在3次刷新中得到2桢的画面。

也就是刷新率的2/3,也就是50FPS.triple-buffering理论上讲可以避免缓冲写入是带来的延迟现象，这样就不会浪费时间。但是triple-buffering并不是适用于所有的游戏。实际上它并不是普及(这个文章可能写的太早，现在triple-buffering已经很普及了)，而且它也会影响显示卡的性能，应为它需要更多的显示内存，需要更多时间在内存之间降数据拷贝来拷贝去。但是triple-buffering确实是一个很好的方法，既可以消除撕裂画面又可以不像普通VSync一样影响你的FPS.

如果有第三个 Buffer 能让 CPU/GPU 在这个时候继续工作，那就完全可以避免第二个 Jank 的发生了！

于是就有了三缓存：

工作原理同双缓冲类似，只是多了一个 Back Buffer。
需要注意的是，第三个缓存并不是总是存在的，只要当需要的时候才会创建。之所以这样，是因为三缓存会显著增加用户输入到显示的延迟时间。如上图，帧 C 是在第 2 个刷新周期产生的，但却是在第 4 个周期显示的。最坏的情况下，你会同时遇到输入延迟和卡顿现象。

三缓冲局限

我希望这篇文章是有用的，可以帮出你理解VSync的工作原理。（特别是不再犹豫是否打开VSync）总之，如果没有triple-buffering的情况下，如何权衡Vsync的FPS限制和消除撕裂画面带来的视觉感受，那将完全取决于你个人的喜好。
译者按：如果这篇文章的机理是正确的。triple-buffering也不是万能的，实际上就是把减少1/2变成了减少1/3而已，如果是FPS恰好卡到了一定的数值的时候没有问题，一旦没有，那就绝对要损失FPS.所以对于那种FPS刚刚超过24的游戏，不管有没有triple-buffering，都应该关.

所以一定会有人问：液晶显示器的刷新频率为何不能调高？
这里有一个误解。
原来我们使用的是CRT技术的显示器,为保证长时间地注视屏幕而眼睛不疲劳,我们一般都会把刷新率调到75H甚至是85Hz,这是由于CRT技术的特性决定的,刷新率越高也就意味着图像越清楚、越稳定。但是对于LCD来说,由于液晶板本身并不发光,只是液晶分子控制光线的偏转或通过,发光的是背光源,即荧光灯管,在使用的时候即使把刷新率调到60Hz你也不会感到屏幕在闪烁,“刷新率”对LCD来说已经没有多大意义了,所以在使用液晶显示器的时候,我们是不必过于苛求刷新率的高低的。

参考

Getting To Know Android 4.1, Part 3: Project Butter - How It Works And What It Added
http://www.androidpolice.com/2012/07/12/getting-to-know-android-4-1-part-3-project-butter-how-it-works-and-what-it-added/

总结

本篇科普一下VSync，下一节开始分析它在SurfaceFlinger中的工作流程。

Android SurfaceFlinger 学习之路(四)----SurfaceFlinger服务的启动与连接过程

2017-05-13T06:45:23.000Z

上一篇我们分析了Android的开机动画启动流程，这一篇我们基于上一篇的基础，分析一下SurfaceFlinger的启动，还有连接它的过程。

SurfaceFlinger的启动

启动概述

SurfaceFlinger服务是一个独立进程，并且负责统一管理设备的帧缓冲区。通过上一篇开机动画流程分析，我们可以在init.rc中找到SurfaceFlinger服务配置的地方，位于system/core/rootdir/Init.rc中：

service surfaceflinger /system/bin/surfaceflinger
    class core
    user system
    group graphics drmrpc
    onrestart restart zygote

在硬件设备/system/bin/下，可以找到SurfaceFlinger的应用程序。我们查看源码frameworks/native/services/surfaceflinger/Android.mk文件：

###############################################################
# build surfaceflinger's executable
include $(CLEAR_VARS)

LOCAL_CFLAGS:= -DLOG_TAG=\"SurfaceFlinger\"
# SurfaceFlinger启动文件
LOCAL_SRC_FILES:= \
    main_surfaceflinger.cpp 

LOCAL_SHARED_LIBRARIES := \
    libsurfaceflinger \
    libcutils \
    liblog \
    libbinder \
    libutils
    
# SurfaceFlinger是个动态库
LOCAL_MODULE:= surfaceflinger

ifdef TARGET_32_BIT_SURFACEFLINGER
LOCAL_32_BIT_ONLY := true
endif

include $(BUILD_EXECUTABLE)

从Makefile文件可以看出，相关依赖和主文件会被编译成libsurfaceflinger.so，然后SurfaceFlinger是对库的一个“封装调用”，里面有个main_surfaceflinger.cpp，我们可以沿着它的main函数往下分析。

启动流程大概如下图，我才刚刚学了时序图，不知道画的对不对。。。。

启动过程

SurfaceFlinger的main函数在framework/native/services/surfaceflinger/main_surfaceflinger.cpp中：

int main(int, char**) {
    // When SF is launched in its own process, limit the number of
    // binder threads to 4.
    //在该进程设置了binder线程池最大数为4
    ProcessState::self()->setThreadPoolMaxThreadCount(4);

    // start the thread pool
    //这里其实只是将当前线程加入到这个Binder线程池中去
    sp<ProcessState> ps(ProcessState::self());
    ps->startThreadPool();

    // instantiate surfaceflinger
    //创建一个SurfaceFlinger强引用对象
    sp<SurfaceFlinger> flinger = new SurfaceFlinger();

#if defined(HAVE_PTHREADS)
    setpriority(PRIO_PROCESS, 0, PRIORITY_URGENT_DISPLAY);
#endif
    set_sched_policy(0, SP_FOREGROUND);

    // initialize before clients can connect
    //调用SurfaceFlinger的init函数
    flinger->init();

    // publish surface flinger
    //把SurfaceFlinger服务注册到ServiceManager中
    sp<IServiceManager> sm(defaultServiceManager());
    sm->addService(String16(SurfaceFlinger::getServiceName()), flinger, false);

    // run in this thread
    //运行这个UI渲染流程
    flinger->run();

    return 0;
}

main函数包含以下几件事情：

调用当前进程中的ProcessState单例的成员函数startThreadPool来启动一个Binder线程池，将线程池最大数量设为4，并且调用当前线程中的IPCThreadState单例来将当前线程加入到前面所启动的Binder线程池中去；
创建一个SurfaceFlinger的对象，并赋给他的强引用指针；
执行SurfaceFlinger的init函数；
将SurfaceFlinger服务注册到ServiceManager当中；
运行SurfaceFlinger的UI渲染流程。

比较重要的步骤就是创建SurfaceFlinger对象，执行init函数，和运行UI渲染流程。我们逐个分析。

创建SurfaceFlinger对象

new一个SurfaceFlinger对象，并赋给强引用指针。我们先看看它的构造函数，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp中：

SurfaceFlinger::SurfaceFlinger()
    :   BnSurfaceComposer(),
        mTransactionFlags(0),
        mTransactionPending(false),
        mAnimTransactionPending(false),
        mLayersRemoved(false),
        mRepaintEverything(0),
        mRenderEngine(NULL),
        mBootTime(systemTime()),
        mVisibleRegionsDirty(false),
        mHwWorkListDirty(false),
        mAnimCompositionPending(false),
        mDebugRegion(0),
        mDebugDDMS(0),
        mDebugDisableHWC(0),
        mDebugDisableTransformHint(0),
        mDebugInSwapBuffers(0),
        mLastSwapBufferTime(0),
        mDebugInTransaction(0),
        mLastTransactionTime(0),
        mBootFinished(false),
        mPrimaryHWVsyncEnabled(false),//主显屏硬件VSync信号关闭
        mHWVsyncAvailable(false),
        mDaltonize(false),
        mHasColorMatrix(false)
{
    ALOGI("SurfaceFlinger is starting");
    //一些调试变量，忽略一下内容
    // debugging stuff...
    char value[PROPERTY_VALUE_MAX];

    property_get("ro.bq.gpu_to_cpu_unsupported", value, "0");
    mGpuToCpuSupported = !atoi(value);

    property_get("debug.sf.showupdates", value, "0");
    mDebugRegion = atoi(value);

    property_get("debug.sf.ddms", value, "0");
    mDebugDDMS = atoi(value);
    if (mDebugDDMS) {
        if (!startDdmConnection()) {
            // start failed, and DDMS debugging not enabled
            mDebugDDMS = 0;
        }
    }
    ALOGI_IF(mDebugRegion, "showupdates enabled");
    ALOGI_IF(mDebugDDMS, "DDMS debugging enabled");
}

构造函数中主要初始化一系列变量，没什么重要信息。SurfaceFlinger类继承了BnSurfaceComposer类，而后者是一个实现了ISurfaceComposer接口的Binder本地对象类。

由于Service Manager的Binder代理对象的成员函数addService的第二个参数是一个类型为IBinder的强指针引用。当一个对象第一次被一个强指针引用时，那么这个对象的成员函数onFirstRef就会被调用。因此，接下来前面所创建的SurfaceFlinger实例的成员函数onFirstRef就会被调用，以便可以继续执行初始化操作。我们继续查看：

// mEventQueue在SurfaceFlinger.h中定义
// these are thread safe
mutable MessageQueue mEventQueue;

void SurfaceFlinger::onFirstRef()
{
    mEventQueue.init(this);
}

MessageQueue 类在frameworks/native/services/surfaceflinger/MessageQueue.h中定义，实现位于frameworks/native/services/surfaceflinger/MessageQueue.cpp中，init函数如下：

void MessageQueue::init(const sp<SurfaceFlinger>& flinger)
{
    mFlinger = flinger;
    mLooper = new Looper(true);
    mHandler = new Handler(*this);
}

调用MessageQueue的init，在MessageQueue中建了一个Looper和Handler，注意不是Java中的，native实现的。到后面就可以看到SF的核心就是接收消息，处理消息。对于消息处理，可以参考之前的一片文章Android消息处理零散分析。

调用init函数

回到SurfaceFlinger.cpp中，继续分析init函数：

void SurfaceFlinger::init() {
    ALOGI(  "SurfaceFlinger's main thread ready to run. "
            "Initializing graphics H/W...");

    status_t err;
    Mutex::Autolock _l(mStateLock);
    
    //初始化OpenGL 图形库相关配置
    // initialize EGL for the default display 将EGL初始化成默认的显示，默认是主屏幕，编号为0
    mEGLDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    eglInitialize(mEGLDisplay, NULL, NULL);

    //创建显示设备的抽象代表，负责和显示设备打交道
    // Initialize the H/W composer object.  There may or may not be an
    // actual hardware composer underneath.
    mHwc = new HWComposer(this,
            *static_cast<HWComposer::EventHandler *>(this));
            
    // get a RenderEngine for the given display / config (can't fail)
    mRenderEngine = RenderEngine::create(mEGLDisplay, mHwc->getVisualID());

    // retrieve the EGL context that was selected/created
    mEGLContext = mRenderEngine->getEGLContext();

    LOG_ALWAYS_FATAL_IF(mEGLContext == EGL_NO_CONTEXT,
            "couldn't create EGLContext");

    // initialize our non-virtual displays
    //创建显示设备对象
    for (size_t i=0 ; i<DisplayDevice::NUM_BUILTIN_DISPLAY_TYPES ; i++) {
        DisplayDevice::DisplayType type((DisplayDevice::DisplayType)i);
        // set-up the displays that are already connected
        if (mHwc->isConnected(i) || type==DisplayDevice::DISPLAY_PRIMARY) {
            // All non-virtual displays are currently considered secure.
            bool isSecure = true;
            createBuiltinDisplayLocked(type);
            wp<IBinder> token = mBuiltinDisplays[i];

            sp<IGraphicBufferProducer> producer;
            sp<IGraphicBufferConsumer> consumer;
            BufferQueue::createBufferQueue(&producer, &consumer,
                    new GraphicBufferAlloc());

            sp<FramebufferSurface> fbs = new FramebufferSurface(*mHwc, i,
                    consumer);
            int32_t hwcId = allocateHwcDisplayId(type);
            sp<DisplayDevice> hw = new DisplayDevice(this,
                    type, hwcId, mHwc->getFormat(hwcId), isSecure, token,
                    fbs, producer,
                    mRenderEngine->getEGLConfig());
            if (i > DisplayDevice::DISPLAY_PRIMARY) {
                // FIXME: currently we don't get blank/unblank requests
                // for displays other than the main display, so we always
                // assume a connected display is unblanked.
                ALOGD("marking display %zu as acquired/unblanked", i);
                hw->setPowerMode(HWC_POWER_MODE_NORMAL);
            }
            mDisplays.add(token, hw);
        }
    }

    // make the GLContext current so that we can create textures when creating Layers
    // (which may happens before we render something)
    getDefaultDisplayDevice()->makeCurrent(mEGLDisplay, mEGLContext);

    // start the EventThread
    //启动EventThread。监听和处理SurfaceFlinger中的事件
    //app的VSync信号
    sp<VSyncSource> vsyncSrc = new DispSyncSource(&mPrimaryDispSync,
            vsyncPhaseOffsetNs, true, "app");
    mEventThread = new EventThread(vsyncSrc);
    //SF的VSync信号
    sp<VSyncSource> sfVsyncSrc = new DispSyncSource(&mPrimaryDispSync,
            sfVsyncPhaseOffsetNs, true, "sf");
    mSFEventThread = new EventThread(sfVsyncSrc);
    //SF的VSync信号控制逻辑也要放入mEventQueue消息队列
    mEventQueue.setEventThread(mSFEventThread);
    //VSync信号闸刀控制线程
    mEventControlThread = new EventControlThread(this);
    mEventControlThread->run("EventControl", PRIORITY_URGENT_DISPLAY);

    // set a fake vsync period if there is no HWComposer
    //如果硬件设备检测有问题，或者没有硬件设备驱动提供Vsync信号，则设置软件VSync信号
    if (mHwc->initCheck() != NO_ERROR) {
        mPrimaryDispSync.setPeriod(16666667);
    }

    // initialize our drawing state
    mDrawingState = mCurrentState;

    // set initial conditions (e.g. unblank default device)
    //初始化显示设备，调用initializeDisplays完成
    initializeDisplays();

    // start boot animation
    //启动开机动画，调用了startBootAnim函数，只是设置了两个属性，其中一个ctl.start是启动了bootanim进程
    startBootAnim();
}

init函数主要做了以下事情：

初始化OpenGL ES图形库；
创建显示设备的抽象代表，负责和显示设备打交道；
创建显示设备对象；
启动EventThread。监听和处理SurfaceFlinger中的事件；
设置软件VSync信号周期；
初始化显示设备，调用initializeDisplays完成；
启动开机动画，调用了startBootAnim函数，只是设置了两个属性，其中一个ctl.start是启动了bootanim进程。

其中初始化OpenGL ES可以参考Android SurfaceFlinger 学习之路(二)—-SurfaceFlinger概述，后期如果有机会再次会细讲。创建显示设备我们后面分析管理图形缓冲区时候会细讲。还有VSync信号，后面会单独开章节分析。这里我们大概过一个流程。

执行run函数

然后继续往下看，执行SurfaceFlinger的run函数：

void SurfaceFlinger::run() {
    do {
        waitForEvent();
    } while (true);
}

void SurfaceFlinger::waitForEvent() {
    mEventQueue.waitMessage();
}

run函数非常简单，但却是SF的核心，是个while循环，循环处理消息等。
然后又调用了EventQueue的waitMessage方法，记住这里是在主线程中循环调用的。

void MessageQueue::waitMessage() {
    do {
        //flushCommands主要是清理工作的
        IPCThreadState::self()->flushCommands();
        //pollOnce是消息机制，主要调用了epoll_wait函数，会阻塞，阻塞完了会分发消息队列中的消息
        int32_t ret = mLooper->pollOnce(-1);
        switch (ret) {
            case Looper::POLL_WAKE:
            case Looper::POLL_CALLBACK:
                continue;
            case Looper::POLL_ERROR:
                ALOGE("Looper::POLL_ERROR");
            case Looper::POLL_TIMEOUT:
                // timeout (should not happen)
                continue;
            default:
                // should not happen
                ALOGE("Looper::pollOnce() returned unknown status %d", ret);
                continue;
        }
    } while (true);
}

我们来看下waitMessage方法，flushCommands主要是清理工作的，和Binder驱动的交互关了。而pollOnce是消息机制，主要调用了epoll_wait函数，会阻塞，阻塞完了会分发消息队列中的消息。这里的消息只有自己在Handler中发的消息，还有在setEventThread中自己添加的fd。

消息处理

给SurfaceFlinger发送消息

我们以SurfaceFlinger与客户端通信创建Surface为例，看看如何给SurfaceFlinger发送消息。这个我们下面会讲到，这里先举个栗子。

从上一篇开机动画的简述流程可以得知，BootAnimation的readyToRun函数中有一句：

1
2
3

// create the native surface
//调用SurfaceComposerClient对象mSession的成员函数createSurface可以获得一个SurfaceControl对象control
sp<SurfaceControl> control = session()->createSurface(String8("BootAnimation"),

BootAnimation类的成员函数session用来返回BootAnimation类的成员变量mSession所描述的一个SurfaceComposerClient对象。通过调用SurfaceComposerClient对象mSession的成员函数createSurface可以获得一个SurfaceControl对象control。
SurfaceComposerClient类的成员函数createSurface首先调用内部的Binder代理对象mClient(frameworks/native/services/surfaceflinger/Client.cpp)来请求SurfaceFlinger返回一个类型为(class Handle : public BBinder, public LayerCleaner)Binder代理对象（封装了SurfaceFlinger的sp指针和Layer对象）handle，和一个IGraphicBufferProducer的sp指针（封装了SurfaceFlinger的sp指针）gbp，接着再使用这两个对象来创建一个SurfaceControl对象。创建出来的SurfaceControl对象的成员变量handle就指向了从SurfaceFlinger返回来的类型为Handle 的Binder代理对象。有了这个Binder代理对象之后，SurfaceControl对象就可以和SurfaceFlinger服务通信了。

我们关注的就是Client的createSurface函数，frameworks/native/services/surfaceflinger/Client.cpp：

status_t Client::createSurface(
        const String8& name,
        uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,
        sp<IBinder>* handle,
        sp<IGraphicBufferProducer>* gbp)
{
    /*
     * createSurface must be called from the GL thread so that it can
     * have access to the GL context.
     */

    class MessageCreateLayer : public MessageBase {
        SurfaceFlinger* flinger;
        Client* client;
        sp<IBinder>* handle;
        sp<IGraphicBufferProducer>* gbp;
        status_t result;
        const String8& name;
        uint32_t w, h;
        PixelFormat format;
        uint32_t flags;
    public:
        MessageCreateLayer(SurfaceFlinger* flinger,
                const String8& name, Client* client,
                uint32_t w, uint32_t h, PixelFormat format, uint32_t flags,
                sp<IBinder>* handle,
                sp<IGraphicBufferProducer>* gbp)
            : flinger(flinger), client(client),
              handle(handle), gbp(gbp),
              name(name), w(w), h(h), format(format), flags(flags) {
        }
        status_t getResult() const { return result; }
        //handler是执行消息动作的地方
        virtual bool handler() {
            result = flinger->createLayer(name, client, w, h, format, flags,
                    handle, gbp);
            return true;
        }
    };
    //首先封装消息
    sp<MessageBase> msg = new MessageCreateLayer(mFlinger.get(),
            name, this, w, h, format, flags, handle, gbp);
    //调用SF的postMessageSync发送同步消息
    mFlinger->postMessageSync(msg);
    return static_cast<MessageCreateLayer*>( msg.get() )->getResult();
}

类MessageBase就是封装了类似于一个Handler，里面有个Barrier，我们能够猜到，这个Barrier 肯定是用来进行同步发送消息的，利用Barrier 去等待”wait”。位于framework/native/services/surfaceflinger/MessageQueue.h中:

class MessageBase : public MessageHandler
{
public:
    MessageBase();
    
    // return true if message has a handler
    virtual bool handler() = 0;

    // waits for the handler to be processed
    void wait() const { barrier.wait(); }

protected:
    virtual ~MessageBase();

private:
    virtual void handleMessage(const Message& message);

    mutable Barrier barrier;
};

MessageBase的handleMessage函数，可以看到MessageBase的handler()函数是真正消息处理的地方，执行完成后，调用barrier.open();，打开barrier，这样调用barrier.wait()的地方就能退出了。实现位于framework/native/services/surfaceflinger/MessageQueue.cpp中：

void MessageBase::handleMessage(const Message&) {
    this->handler();
    barrier.open();
};

接着分析mFlinger->postMessageSync(msg);，这是给SF发同步消息的入口，当然也可以发异步消息，实现是类似的:

status_t SurfaceFlinger::postMessageSync(const sp<MessageBase>& msg,
        nsecs_t reltime, uint32_t /* flags */) {
    //向mEventQueue，即MessageQueue中发送消息
    status_t res = mEventQueue.postMessage(msg, reltime);
    //这里等着，同步就在同步函数中等着
    if (res == NO_ERROR) {
        msg->wait();
    }
    return res;
}

可以看到在同步发送消息中，barrier在postMessageSync函数中一直等着呢（wait），等待SF调用handleMessage()函数去将barrier这个栅栏打开(open)。

SurfaceFlinger处理消息

从上面waitMessage得知，消息处理都位于里面无限循环处的的int32_t ret = mLooper->pollOnce(-1);我们追寻到Looper中的pollOnce函数，位于system/core/libutils/Looper.cpp中：

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {
    int result = 0;
    for (;;) {
        
        ......

        result = pollInner(timeoutMillis);
    }
}

函数中，而pollOnce又会调用pollInner：

int Looper::pollInner(int timeoutMillis) {
  // Invoke pending message callbacks.
    mNextMessageUptime = LLONG_MAX;
    while (mMessageEnvelopes.size() != 0) {
        nsecs_t now = systemTime(SYSTEM_TIME_MONOTONIC);
        const MessageEnvelope& messageEnvelope = mMessageEnvelopes.itemAt(0);
        if (messageEnvelope.uptime <= now) {
            // Remove the envelope from the list.
            // We keep a strong reference to the handler until the call to handleMessage
            // finishes.  Then we drop it so that the handler can be deleted *before*
            // we reacquire our lock.
            { // obtain handler
                sp<MessageHandler> handler = messageEnvelope.handler;
                Message message = messageEnvelope.message;
                //把头删除啊
                mMessageEnvelopes.removeAt(0);
                mSendingMessage = true;
                mLock.unlock();

#if DEBUG_POLL_AND_WAKE || DEBUG_CALLBACKS
                ALOGD("%p ~ pollOnce - sending message: handler=%p, what=%d",
                        this, handler.get(), message.what);
#endif          
                //处理消息啊
                handler->handleMessage(message);
            } // release handler

            mLock.lock();
            mSendingMessage = false;
            result = ALOOPER_POLL_CALLBACK;
        } else {
            // The last message left at the head of the queue determines the next wakeup time.
            mNextMessageUptime = messageEnvelope.uptime;
            break;
        }
    }
}

从上面代码可以看到，发给SF的消息被封装在MessageEnvelope结构中，SF一直在mMessageEnvelopes队列中从头部取出消息，然后执行，即handler->handleMessage(message)，这个即是我们上面提到的framework/native/services/surfaceflinger/MessageQueue.cpp中：

void MessageBase::handleMessage(const Message&) {
    this->handler();
    //打开栅栏
    barrier.open();
};

调用handleMessage执行handler()，所以SurfaceFlinger创建Surface的核心代码就是SurfaceFlinger的createLayer函数，回到刚才的createSurface函数中的片段：

1 2	result = flinger->createLayer(name, client, w, h, format, flags, handle, gbp);

执行完成后，打开barrier。

这个只是个简单例子，我们后续会详细讲解它的消息处理流程。

SurfaceFlinger服务连接过程

概述

第一篇文章描述Android应用程序和SurfaceFlinger服务的关系时提到，每一个有UI的Android应用程序都需要与SurfaceFlinger服务建立一个连接，以便可以通过这个连接来请求SurfaceFlinger服务为它创建和渲染Surface。我们将以Android系统的开机动画应用程序为例，详细描述Android应用程序是如何与SurfaceFlinger服务建立连接的。

从从上一篇文章可以知道，Android系统的开机动画是主要一个BootAnimation对象来实现，这个BootAnimation对象在构造的时候，会在内部创建一个SurfaceComposerClient对象来负责创建一个到SurfaceFlinger服务的连接。

BootAnimation类的构造函数实现在文件frameworks/base/cmds/bootanimation/BootAnimation.cpp中：

BootAnimation::BootAnimation() : Thread(false), mZip(NULL)
{
    mSession = new SurfaceComposerClient();
}

mSession是BootAnimation类的成员变量，它是一个类型为SurfaceComposerClient的强指针，即sp < SurfaceComposerClient > 。在SurfaceComposerClient类内部，有一个类型为sp< ISurfaceComposerClient >的成员变量mClient，如下图：

SurfaceComposerClient类的成员变量mClient指向的实际上是一个类型为BpSurfaceComposerClient的Binder代理对象，而这个类型为BpSurfaceComposerClient的Binder代理对象引用的是一个类型为Client的Binder本地对象，位于frameworks/native/services/surfaceflinger/Client.cpp。类型为Client的Binder本地对象是由SurfaceFlinger服务来负责创建的，并且运行在SurfaceFlinger服务中，用来代表使用SurfaceFlinger服务的一个客户端，即一个与UI相关的Android应用程序。

由于Client类和BpSurfaceComposerClient类分别是一个Binder本地对象类和一个Binder代理对象类，它们都是根据Android系统在应用程序框架层提供的Binder进程间通信库来实现的。类图如下：

Client类的实现结构图

BpSurfaceComposerClient类的实现结构图

Client类和BpSurfaceComposerClient类均实现了类型为ISurfaceComposerClient的Binder接口。ISurfaceComposerClient接口有个createSurface接口，它们定义在文件frameworks/base/include/surfaceflinger/ISurfaceComposerClient.h中，如下所示：

class ISurfaceComposerClient : public IInterface
{
/*
     * Requires ACCESS_SURFACE_FLINGER permission
     */
    virtual status_t createSurface(
            const String8& name, uint32_t w, uint32_t h,
            PixelFormat format, uint32_t flags,
            sp<IBinder>* handle,
            sp<IGraphicBufferProducer>* gbp) = 0;

}

在接下来的文章中，我们再详细分析ISurfaceComposerClient接口的成员函数createSurface的实现。

理解了SurfaceComposerClient、Client以及BpSurfaceComposerClient这三个类的关系之后，接下来我们就可以分析Android系统的开机动画应用程序bootanimation是如何与SurfaceFlinger服务建立连接的。

SurfaceComposerClient类继承了RefBase类，因此，当BootAnimation类在构造函数创建了一个SurfaceComposerClient对象，并且将这个对象赋值给类型为sp< SurfaceComposerClient >的智能指针mSession时，就会导致SurfaceComposerClient类的成员函数onFirstRef被调用，而SurfaceComposerClient类的成员函数onFirstRef在调用的过程中，就会在应用程序bootanimation与SurfaceFlinger服务建立一个连接。这个流程如下：

接下来，我们就详细分析每一个步骤。

获取SurfaceFlinger服务代理接口

进入frameworks/native/libs/gui/SurfaceComposerClient.cpp中，找到onFristRef函数：

void SurfaceComposerClient::onFirstRef() {
    sp<ISurfaceComposer> sm(ComposerService::getComposerService());
    if (sm != 0) {
        sp<ISurfaceComposerClient> conn = sm->createConnection();
        if (conn != 0) {
            mClient = conn;
            mStatus = NO_ERROR;
        }
    }
}

SurfaceComposerClient类的成员函数getComposerService用来获得SurfaceFlinger服务的一个代理接口，它的实现同样位于frameworks/native/libs/gui/SurfaceComposerClient.cpp中：

/*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;
}

ComposerService类是单例模式，当我们第一次调用它的静态函数getInstance的时候，它就会在构造函数中获得SurfaceFlinger服务的一个代理接口，并且保存在它的成员变量mComposerService中，如下所示：

ComposerService::ComposerService()
: Singleton<ComposerService>() {
    Mutex::Autolock _l(mLock);
    connectLocked();
}

void ComposerService::connectLocked() {
    const String16 name("SurfaceFlinger");
    while (getService(name, &mComposerService) != NO_ERROR) {
        usleep(250000);
    }
    assert(mComposerService != NULL);

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

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

在ComposerService类的构造函数中，会获得SurfaceFlinger服务的代理接口。

连接SurfaceFlinger服务

回到SurfaceComposerClient类的成员函数onFirstRef中，由于SurfaceFlinger服务实现了ISurfaceComposer接口，因此，我们可以将前面获得的SurfaceFlinger服务的代理接口赋值给一个类型为ISurfaceComposer的强指针sm，并且调用它的成员函数createConnection来请求SurfaceFlinger服务创建一个连接，即创建一个类型为Client的Binder对象，并且将这个Binder对象的一个代理接口conn返回来。SurfaceComposerClient类获得了SurfaceFlinger服务返回来的Client代理接口conn之后，就将它保存自己的成员变量mClient中，这样开机动画应用程序bootanimation后续就可以通过它来请求SurfaceFlinger创建和渲染Surface了。

接下来，我们就继续分析SurfaceFlinger服务的成员函数createConnection的实现，以便可以了解它是如何为Android应用程序创建一个连接的。

进入SurfaceFlinger.cpp中查看createConnection函数：

sp<ISurfaceComposerClient> SurfaceFlinger::createConnection()
{
    sp<ISurfaceComposerClient> bclient;
    sp<Client> client(new Client(this));
    status_t err = client->initCheck();
    if (err == NO_ERROR) {
        bclient = client;
    }
    return bclient;
}

它的实现很简单，只是创建了一个类型为Client的Binder对象client，并且获得它的一个ISurfaceComposerClient接口，最后将这个ISurfaceComposerClient接口，即一个Client代理对象，返回给开机动画应用程序bootanimation。

接下来，我们再继续分析Client对象的创建过程,，即Client类的构造函数的实现：

Client::Client(const sp<SurfaceFlinger>& flinger)
    : mFlinger(flinger)
{
}

这个很简单，就是保存了SurfaceFlinger的强引用对象。
回到SurfaceFlinger类的成员函数createConnection中，它将一个指向了一个Client对象的ISurfaceComposerClient接口返回到开机动画应用程序bootanimation之后，开机动画应用程序bootanimation就可以将它封装成一个类型为BpSurfaceComposerClient的Binder代理对象。

类型为BpSurfaceComposerClient的Binder代理对象的封装过程实现在SurfaceFlinger服务的Binder代理对象类BpSurfaceComposer的成员函数createConnection中，位于frameworks/native/libs/gui/ISurfaceCompose.cpp中：

class BpSurfaceComposer : public BpInterface<ISurfaceComposer>
{
public:

 ......
 virtual sp<ISurfaceComposerClient> createConnection()
    {
        uint32_t n;
        Parcel data, reply;
        data.writeInterfaceToken(ISurfaceComposer::getInterfaceDescriptor());
        remote()->transact(BnSurfaceComposer::CREATE_CONNECTION, data, &reply);
        return interface_cast<ISurfaceComposerClient>(reply.readStrongBinder());
    }
......
}

interface_cast是一个模板函数，它定义在framework/native/include/binder/IInterface.h文件中：

template<typename INTERFACE>
inline sp<INTERFACE> interface_cast(const sp<IBinder>& obj)
{
    return INTERFACE::asInterface(obj);
}

从这里就可以看出，当模板参数为ISurfaceComposerClient的时候，模板函数interface_cast实际就是通过调用ISurfaceComposerClient类的静态成员函数asInterface来将参数obj所描述的一个Binder代理对象，即一个BpBinder对象，封装成一个BpSurfaceComposerClient对象。

ISurfaceComposerClient类的静态成员函数asInterface是由frameworks/native/libs/gui/ISurfaceComposerClient.cpp文件中的IMPLEMENT_META_INTERFACE宏来定义的，如下所示：

1	IMPLEMENT_META_INTERFACE(SurfaceComposerClient, "android.ui.ISurfaceComposerClient");

IMPLEMENT_META_INTERFACE宏展开后，得到ISurfaceComposerClient类的静态成员函数asInterface的实现如下所示：

android::sp<ISurfaceComposerClient> ISurfaceComposerClient::asInterface(const android::sp<android::IBinder>& obj)       {                                                                                         
    android::sp<ISurfaceComposerClient> intr;                                                        
        
    if (obj != NULL) {                                                                         
        intr = static_cast<ISurfaceComposerClient*>(                                                      
                    obj->queryLocalInterface(ISurfaceComposerClient::descriptor).get());    
            
        if (intr == NULL) {                    
            intr = new BpSurfaceComposerClient(obj);                                            
        }                                              
    ｝    
    return intr;                                      
}

参数obj是从BpSurfaceComposer类的成员函数createConnection传进来的，它指向的实际上是一个BpBinder对象。当我们调用一个BpBinder对象的成员函数queryLocalInterface时，获得的是一个NULL指针，因此，ISurfaceComposerClient类的静态成员函数asInterface最后就会将参数obj所指向的一个BpBinder对象封装成一个BpSurfaceComposerClient对象，并且返回给调用者。

至此，开机动画应用程序bootanimation就通过SurfaceComposerClient类来与SurfaceFlinger服务建立一个连接了。

小结

本篇主要学习了SurfaceFlinger的启动和连接过程，应该算不太难的部分。下几节我们将逐步分析消息处理、创建surface、管理GraphicBuffer、VSync信号、Fence机制等等内容。

Android SurfaceFlinger 学习之路(三)----Android开机动画流程简述

2017-05-02T09:28:11.000Z

在详细分析SurfaceFlinger模块之前要先看看Android的开机动画，因为这个BootAnimation是一个C++应用程序，需要使用SurfaceFlinger服务来创建和渲染自己的Surface，并且不涉及与用户进行交互，所以能以最简洁的方式体现Android与SurfaceFlinger服务的关系。

开机动画的启动

第一个开机画面是在内核启动的过程中出现的，它是一个静态的画面。第二个开机画面是在init进程启动的过程中出现的，它也是一个静态的画面。第三个开机画面BootAnimation是在系统服务启动的过程中出现的，它是一个动态的画面。无论是哪一个画面，它们都是在一个称为帧缓冲区（frame buffer，简称fb）的硬件设备上进行渲染的。接下来，我们就分别分析第三个画面是如何在fb上显示的。

bootanimation的启动过程

第三个开机动画使用应用程序BootAnimation来负责显示的，它在启动脚本init.rc中被配置成了一个服务，位于system/core/rootdir/Init.rc：

......
service bootanim /system/bin/bootanimation
    class core
    user graphics //用户
    group graphics audio //用户组
    disabled //init进程启动时，不会自动启动bootanimation
    oneshot
......

应用程序bootanimation的用户和用户组名称分别被设置为graphics。注意，用来启动应用程序bootanimation的服务是disable的，即init进程在启动的时候，不会主动将应用程序bootanimation启动起来。
当SurfaceFlinger服务启动的时候，它会通过修改系统属性ctl.start的值来通知init进程启动应用程序bootanimation，以便可以显示第三个开机画面。

在早期的Android版本中，SurfaceFlinger服务是由SystemServer启动的。但在Android5.0中，该服务是init进程启动过程中就启动了。在init.rc中能看到对该服务的描述：

......
service surfaceflinger /system/bin/surfaceflinger
    class core
    user system
    group graphics drmrpc
    onrestart restart zygote
......

SurfaceFlinger服务的源码路径位于framework/native/services/surfaceflinger/下面，服务的入口在下面的main_surfaceflinger.cpp中，我们查看它的main函数：

int main(int, char**) {
    // When SF is launched in its own process, limit the number of
    // binder threads to 4.
    ProcessState::self()->setThreadPoolMaxThreadCount(4);

    // start the thread pool
    sp<ProcessState> ps(ProcessState::self());
    ps->startThreadPool();

    // instantiate surfaceflinger
    sp<SurfaceFlinger> flinger = new SurfaceFlinger();

#if defined(HAVE_PTHREADS)
    setpriority(PRIO_PROCESS, 0, PRIORITY_URGENT_DISPLAY);
#endif
    set_sched_policy(0, SP_FOREGROUND);

    // initialize before clients can connect
    flinger->init(); //我们主要看这里，其他忽略

    // publish surface flinger
    sp<IServiceManager> sm(defaultServiceManager());
    sm->addService(String16(SurfaceFlinger::getServiceName()), flinger, false);

    // run in this thread
    flinger->run();

    return 0;
}

主要工作就是新建一个SurfaceFlinger对象，然后调用其中的init函数，最后调用run函数。我们的重点在init方法，位于framework/native/services/surfaceflinger/SurfaceFlinger.cpp中：

void SurfaceFlinger::init() {
...省略大量代码...
    // start boot animation
    startBootAnim();
}

最后一行调用了startBootAnim函数，我们继续往下看：

void SurfaceFlinger::startBootAnim() {
    // start boot animation
    property_set("service.bootanim.exit", "0");
    property_set("ctl.start", "bootanim");
}

这里讲系统属性”service.bootanim.exit”设置为”0”，并将”ctl.start”设置为”bootanim”。重点是第二个。

当系统属性发生改变时，init进程就会接收到一个系统属性变化通知，这个通知最终是由在init进程中的函数handle_property_set_fd来处理的。我们可以查看init进程的入口main函数，位于system/core/init/Init.c中：

int main(int argc, char **argv){
...省略大量代码...
    for(;;) {
        int nr, i, timeout = -1;

        ...省略一些代码...
        //poll函数用来轮询事件
        nr = poll(ufds, fd_count, timeout);
        if (nr <= 0)
            continue;

        for (i = 0; i < fd_count; i++) {
            if (ufds[i].revents & POLLIN) {
                //我们关注这里，当系统属性值被修改时，得到该事件，会执行handle_property_set_fd函数
                if (ufds[i].fd == get_property_set_fd())
                    handle_property_set_fd();
                else if (ufds[i].fd == get_keychord_fd())
                    handle_keychord();
                else if (ufds[i].fd == get_signal_fd())
                    handle_signal();
            }
        }
    }

    return 0;
}

可以看到，init进程会使用poll机制来轮询事件，其中一个事件是系统属性值被修改。得到该事件后，会执行handle_property_set_fd()，位于system/core/init/Property_service.c中：

void handle_property_set_fd()
{
    prop_msg msg; //init进程是通过一个socket来接收系统属性变化事件的
    int s;
    int r;
    int res;
    struct ucred cr;
    struct sockaddr_un addr;
    socklen_t addr_size = sizeof(addr);
    socklen_t cr_size = sizeof(cr);
    char * source_ctx = NULL;
    struct pollfd ufds[1];
    const int timeout_ms = 2 * 1000;  /* Default 2 sec timeout for caller to send property. */
    int nr;
    //接收TCP连接 服务端阻塞？等待客户端连接
    if ((s = accept(property_set_fd, (struct sockaddr *) &addr, &addr_size)) < 0) {
        return;
    }

    /* Check socket options here */
    //取出socket的可选内容，可能包括客户端进程的权限等属性 
    if (getsockopt(s, SOL_SOCKET, SO_PEERCRED, &cr, &cr_size) < 0) {
        close(s); 
        ERROR("Unable to receive socket options\n");
        return;
    }

    ufds[0].fd = s;
    ufds[0].events = POLLIN;
    ufds[0].revents = 0;
    //轮询客户端事件
    nr = TEMP_FAILURE_RETRY(poll(ufds, 1, timeout_ms));
    //轮询事件超时
    if (nr == 0) {
        ERROR("sys_prop: timeout waiting for uid=%d to send property message.\n", cr.uid);
        close(s);
        return;
    //等待错误
    } else if (nr < 0) {
        ERROR("sys_prop: error waiting for uid=%d to send property message. err=%d %s\n", cr.uid, errno, strerror(errno));
        close(s);
        return;
    }
    //接收socket的主体数据 
    r = TEMP_FAILURE_RETRY(recv(s, &msg, sizeof(msg), MSG_DONTWAIT));
    //接收事件不匹配，return
    if(r != sizeof(prop_msg)) {
        ERROR("sys_prop: mis-match msg size received: %d expected: %zu errno: %d\n",
              r, sizeof(prop_msg), errno);
        close(s);
        return;
    }
    //开始条件判断接收事件
    switch(msg.cmd) {
    case PROP_MSG_SETPROP: //如果是属性发生变化
        msg.name[PROP_NAME_MAX-1] = 0;
        msg.value[PROP_VALUE_MAX-1] = 0;
        //检查属性名，不能有特殊字符，或者两个点..这样的名字
        if (!is_legal_property_name(msg.name, strlen(msg.name))) {
            ERROR("sys_prop: illegal property name. Got: \"%s\"\n", msg.name);
            close(s);
            return;
        }
        
        getpeercon(s, &source_ctx);
/* 
        如果是ctl开头的消息，则认为是控制消息，控制消息用来执行一些命令，例如用adb shell登录后，输入setprop ctl.start bootanim就可以查看开机动画了;输入setprop service.bootanim.exit 1就可以退出开机动画了
    */  
        if(memcmp(msg.name,"ctl.",4) == 0) {
            // Keep the old close-socket-early behavior when handling
            // ctl.* properties.
            close(s);
            //改变系统属性是需要权限,所以需要减产是否有权限
            if (check_control_mac_perms(msg.value, source_ctx)) {
                //通过了权限检查之后，另外一个函数handle_control_message就会被调用，以便可以执行一个名称为“bootanim”的命令
                handle_control_message((char*) msg.name + 4, (char*) msg.value);
            } else {
                ERROR("sys_prop: Unable to %s service ctl [%s] uid:%d gid:%d pid:%d\n",
                        msg.name + 4, msg.value, cr.uid, cr.gid, cr.pid);
            }
        } else {
         /* 
            不是ctl开头的属性，则首先检查其权限。例如，设置net.开头的属性需要AID_SYSTEM权限，log.开头的属性需要AID_SHELL属性等。 
        */ 
            if (check_perms(msg.name, source_ctx)) {
            // 最后通过property_set函数设置客户端需要设置的属性  
                property_set((char*) msg.name, (char*) msg.value);
            } else {
                ERROR("sys_prop: permission denied uid:%d  name:%s\n",
                      cr.uid, msg.name);
            }

            // Note: bionic's property client code assumes that the
            // property server will not close the socket until *AFTER*
            // the property is written to memory.
            close(s);
        }
        freecon(source_ctx);
        break;

    default:
        close(s);
        break;
    }
}

init进程是通过一个socket来接收系统属性变化事件的。每一个系统属性变化事件的内容都是通过一个prop_msg对象来描述的。在prop_msg对象对，成员变量name用来描述发生变化的系统属性的名称，而成员变量value用来描述发生变化的系统属性的值。系统属性分为两种类型，一种是普通类型的系统属性，另一种是控制类型的系统属性（属性名称以“ctl.”开头）。控制类型的系统属性在发生变化时，会触发init进程执行一个命令，而普通类型的系统属性就不具有这个特性。注意，改变系统属性是需要权限，因此，函数handle_property_set_fd在处理一个系统属性变化事件之前，首先会检查修改系统属性的进程是否具有相应的权限，这是通过调用函数check_control_perms或者check_perms来实现的。

从前面的调用过程可以知道，当前发生变化的系统属性的名称为“ctl.start”，它的值被设置为“bootanim”。由于这是一个控制类型的系统属性，因此，在通过了权限检查之后，另外一个函数handle_control_message就会被调用，以便可以执行一个名称为“bootanim”的命令。

函数handle_control_message实现在system/core/init/Init.c中，如下所示：

void handle_control_message(const char *msg, const char *arg)
{
    if (!strcmp(msg,"start")) {//所以进入了这里
        msg_start(arg);//arg是bootanimation
    } else if (!strcmp(msg,"stop")) {
        msg_stop(arg);
    } else if (!strcmp(msg,"restart")) {
        msg_restart(arg);
    } else {
        ERROR("unknown control msg '%s'\n", msg);
    }
}

控制类型的系统属性的名称是以”ctl.”开头，并且是以“start”或者“stop”结尾的，其中，“start”表示要启动某一个服务，而“stop”表示要停止某一个服务，它们是分别通过函数msg_start和msg_stop来实现的。由于当前发生变化的系统属性是以“start”来结尾的，因此，接下来就会调用函数msg_start来启动一个名称为“bootanim”的服务。

函数msg_start实现在文件system/core/init/Init.c中，如下所示：

static void msg_start(const char *name)//bootanim
{
    struct service *svc = NULL;
    char *tmp = NULL;
    char *args = NULL;

    if (!strchr(name, ':'))//into
        //查找init.rc中配置的service列表
        svc = service_find_by_name(name);
    else {
        tmp = strdup(name);
        if (tmp) {
            args = strchr(tmp, ':');
            *args = '\0';
            args++;

            svc = service_find_by_name(tmp);
        }
    }

    if (svc) {//如果在列表中找到了bootanim，则启动它
        service_start(svc, args);
    } else {
        ERROR("no such service '%s'\n", name);
    }
    if (tmp)
        free(tmp);
}

该函数首先调用service_find_by_name()，从service_list中查询要启动的服务是否有存在，若存在，返回服务的相关信息。因为init.rc中有bootanimation的定义，因此在init进程执行parse_config()时，会将该服务添加到service_list中，所以bootanimation应用是存在的。然后，如果找到了该服务，就调用service_start启动服务。

到此，bootanimation应用就启动了。

开机动画显示

从前面的内容可以知道，名称等于“bootanim”的服务所对应的应用程序为/system/bin/bootanimation，这个应用程序实现在frameworks/base/cmds/bootanimation目录中，其中，应用程序入口函数main是实现在frameworks/base/cmds/bootanimation/Bootanimation_main.cpp中的，如下所示：


int main(int argc, char** argv)
{
#if defined(HAVE_PTHREADS)
    setpriority(PRIO_PROCESS, 0, ANDROID_PRIORITY_DISPLAY);
#endif

    char value[PROPERTY_VALUE_MAX];
    property_get("debug.sf.nobootanimation", value, "0");
    int noBootAnimation = atoi(value);
    ALOGI_IF(noBootAnimation,  "boot animation disabled");
    if (!noBootAnimation) {//检查系统属性“debug.sf.nobootnimaition”的值是否不等于0
        //启动一个Binder线程池
        sp<ProcessState> proc(ProcessState::self());
        ProcessState::self()->startThreadPool();

        // create the boot animation object
        //创建一个BootAnimation对象
        sp<BootAnimation> boot = new BootAnimation();

        IPCThreadState::self()->joinThreadPool();

    }
    return 0;
}

这个函数首先检查系统属性“debug.sf.nobootnimaition”的值是否不等于0。如果不等于的话，那么接下来就会启动一个Binder线程池，并且创建一个BootAnimation对象。这个BootAnimation对象就是用来显示第三个开机画面的。由于BootAnimation对象在显示第三个开机画面的过程中，需要与SurfaceFlinger服务通信，因此，应用程序bootanimation就需要启动一个Binder线程池。

接着我们看看BootAnimation类的声明，位于frameworks/base/cmds/bootanimation/BootAnimation.h中：

class BootAnimation : public Thread, public IBinder::DeathRecipient  
{  
public:  
                BootAnimation();  
    virtual     ~BootAnimation();    
    .......  
private:  
    virtual bool        threadLoop();  
    virtual status_t    readyToRun();  
    virtual void        onFirstRef();  
    virtual void        binderDied(const wp<IBinder>& who);  
   
    status_t initTexture(Texture* texture, AssetManager& asset, const char* name);  
    status_t initTexture(const Animation::Frame& frame);  
    bool android();  
    bool readFile(const char* name, String8& outString);  
    bool movie();  
    ......  
};

BootAnimation类继承了Thread类和IBinder::DeathRecipient类，其中几个重要的函数说明如下：

onFirstRef() —– 属于其父类RefBase，该函数在强引用sp新增引用计数時调用，就是当有sp包装的类初始化的时候调用；
binderDied() —– 当对象死掉或者其他情况导致该Binder结束时，就会回调binderDied()方法;
readyToRun() —– Thread执行前的初始化工作；
threadLoop() —– 每个线程类都要实现的，在这里定义thread的执行内容。这个函数如果返回true，且没有requestExist()没有被调用，则该函数会再次执行；如果返回false，则threadloop中的内容仅仅执行一次，线程就会退出。
其他主要函数的说明如下：
android() —– 显示系统默认的开机画面；
movie() —– 显示用户自定义的开机动画。

BootAnimation类成员函数的实现位于frameworks/base/cmds/bootanimation/BootAnimation.cpp。

BootAnimation类间接地继承了RefBase类，并且重写了RefBase类的成员函数onFirstRef，因此，当一个BootAnimation对象第一次被智能指针引用的时，这个BootAnimation对象的成员函数onFirstRef就会被调用：

void BootAnimation::onFirstRef() {
    status_t err = mSession->linkToComposerDeath(this);
    ALOGE_IF(err, "linkToComposerDeath failed (%s) ", strerror(-err));
    if (err == NO_ERROR) {
        run("BootAnimation", PRIORITY_DISPLAY);
    }
}

mSession是BootAnimation类的一个成员变量，它的类型为SurfaceComposerClient，是用来和SurfaceFlinger执行Binder进程间通信的，它是在BootAnimation类的构造函数中创建的，如下所示：

BootAnimation::BootAnimation() : Thread(false), mZip(NULL)
{
    mSession = new SurfaceComposerClient();
}

SurfaceComposerClient类内部有一个实现了ISurfaceComposerClient接口的Binder代理对象mClient，这个Binder代理对象引用了SurfaceFlinger服务，SurfaceComposerClient类就是通过它来和SurfaceFlinger服务通信的。这个我们后面章节会详细分析。

回到BootAnimation类的成员函数onFirstRef中，由于BootAnimation类引用了SurfaceFlinger服务，因此，当SurfaceFlinger服务意外死亡时，BootAnimation类就需要得到通知，这是通过调用成员变量mSession的成员函数linkToComposerDeath来注册SurfaceFlinger服务的死亡接收通知来实现的。

BootAnimation类继承了Thread类，因此，当BootAnimation类的成员函数onFirstRef调用了父类Thread的成员函数run之后，系统就会创建一个线程，这个线程在第一次运行之前，会调用BootAnimation类的成员函数readyToRun来执行一些初始化工作，后面再调用BootAnimation类的成员函数htreadLoop来显示第三个开机画面。

BootAnimation类的成员函数readyToRun的实现如下所示：

status_t BootAnimation::readyToRun() {
    mAssets.addDefaultAssets();
    //检查显示屏信息是否正确
    sp<IBinder> dtoken(SurfaceComposerClient::getBuiltInDisplay(
            ISurfaceComposer::eDisplayIdMain));
    DisplayInfo dinfo;
    status_t status = SurfaceComposerClient::getDisplayInfo(dtoken, &dinfo);
    if (status)
        return -1;

    // create the native surface
    //调用SurfaceComposerClient对象mSession的成员函数createSurface可以获得一个SurfaceControl对象control
    sp<SurfaceControl> control = session()->createSurface(String8("BootAnimation"),
            dinfo.w, dinfo.h, PIXEL_FORMAT_RGB_565);

    SurfaceComposerClient::openGlobalTransaction();
    control->setLayer(0x40000000);
    SurfaceComposerClient::closeGlobalTransaction();
    //调用SurfaceControl对象control的成员函数getSurface会返回一个Surface对象s
    sp<Surface> s = control->getSurface();

    // initialize opengl and egl
    //初始化OPENEGL和EGL
    const EGLint attribs[] = {
            EGL_RED_SIZE,   8,
            EGL_GREEN_SIZE, 8,
            EGL_BLUE_SIZE,  8,
            EGL_DEPTH_SIZE, 0,
            EGL_NONE
    };
    EGLint w, h, dummy;
    EGLint numConfigs;
    EGLConfig config;
    EGLSurface surface;
    EGLContext context;

    EGLDisplay display = eglGetDisplay(EGL_DEFAULT_DISPLAY);

    eglInitialize(display, 0, 0);
    eglChooseConfig(display, attribs, &config, 1, &numConfigs);
    surface = eglCreateWindowSurface(display, config, s.get(), NULL);
    context = eglCreateContext(display, config, NULL, NULL);
    eglQuerySurface(display, surface, EGL_WIDTH, &w);
    eglQuerySurface(display, surface, EGL_HEIGHT, &h);

    if (eglMakeCurrent(display, surface, surface, context) == EGL_FALSE)
        return NO_INIT;

    mDisplay = display;
    mContext = context;
    mSurface = surface;
    mWidth = w;
    mHeight = h;
    mFlingerSurfaceControl = control;
    mFlingerSurface = s;

    // If the device has encryption turned on or is in process
    // of being encrypted we show the encrypted boot animation.
    //如果设备加密功能开启了，就要显示加密的开机动画
    char decrypt[PROPERTY_VALUE_MAX];
    property_get("vold.decrypt", decrypt, "");
    
    bool encryptedAnimation = atoi(decrypt) != 0 || !strcmp("trigger_restart_min_framework", decrypt);
    //选取动画文件
    ZipFileRO* zipFile = NULL;
    if ((encryptedAnimation &&
            (access(SYSTEM_ENCRYPTED_BOOTANIMATION_FILE, R_OK) == 0) &&
            ((zipFile = ZipFileRO::open(SYSTEM_ENCRYPTED_BOOTANIMATION_FILE)) != NULL)) ||

            ((access(OEM_BOOTANIMATION_FILE, R_OK) == 0) &&
            ((zipFile = ZipFileRO::open(OEM_BOOTANIMATION_FILE)) != NULL)) ||

            ((access(SYSTEM_BOOTANIMATION_FILE, R_OK) == 0) &&
            ((zipFile = ZipFileRO::open(SYSTEM_BOOTANIMATION_FILE)) != NULL))) {
        mZip = zipFile;
    }

    return NO_ERROR;
}

readyToRun主要做了如下工作：

1）BootAnimation类的成员函数session用来返回BootAnimation类的成员变量mSession所描述的一个SurfaceComposerClient对象。通过调用SurfaceComposerClient对象mSession的成员函数createSurface可以获得一个SurfaceControl对象control。

SurfaceComposerClient类的成员函数createSurface首先调用内部的Binder代理对象mClient(frameworks/native/services/surfaceflinger/Client.cpp)来请求SurfaceFlinger返回一个类型为(class Handle : public BBinder, public LayerCleaner)Binder代理对象（封装了SurfaceFlinger的sp指针和Layer对象）handle，和一个IGraphicBufferProducer的sp指针（封装了SurfaceFlinger的sp指针）gbp，接着再使用这两个对象来创建一个SurfaceControl对象。创建出来的SurfaceControl对象的成员变量handle就指向了从SurfaceFlinger返回来的类型为Handle 的Binder代理对象。有了这个Binder代理对象之后，SurfaceControl对象就可以和SurfaceFlinger服务通信了。(下一章节会分析)

调用SurfaceControl对象control的成员函数getSurface会返回一个Surface对象s。这个Surface对象s内部也有一个类型为IGraphicBufferProducer的sp指针mGraphicBufferProducer，这个sp指针与前面所创建的SurfaceControl对象control的内部的sp指针（封装了SurfaceFlinger的sp指针）gbp引用的是同一个对象。这样，Surface对象s也可以通过其内部的sp指针mGraphicBufferProducer来和SurfaceFlinger服务通信。（下一章节会分析）

Surface类继承了ANativeWindow类。ANativeWindow类是连接OpenGL和Android窗口系统的桥梁，即OpenGL需要通过ANativeWindow类来间接地操作Android窗口系统。这种桥梁关系是通过EGL库来建立的，所有以egl为前缀的函数名均为EGL库提供的接口。

2）为了能够在OpenGL和Android窗口系统之间的建立一个桥梁，我们需要一个EGLDisplay对象display，一个EGLConfig对象config，一个EGLSurface对象surface，以及一个EGLContext对象context，其中，EGLDisplay对象display用来描述一个EGL显示屏，EGLConfig对象config用来描述一个EGL帧缓冲区配置参数，EGLSurface对象surface用来描述一个EGL绘图表面，EGLContext对象context用来描述一个EGL绘图上下文（状态），它们是分别通过调用egl库函数eglGetDisplay、eglChooseConfig、eglCreateWindowSurface和eglCreateContext来获得的。注意，EGLConfig对象config、EGLSurface对象surface和EGLContext对象context都是用来描述EGLDisplay对象display的。有了这些对象之后，就可以调用函数eglMakeCurrent来设置当前EGL库所使用的绘图表面以及绘图上下文。

还有另外一个地方需要注意的是，每一个EGLSurface对象surface有一个关联的ANativeWindow对象。这个ANativeWindow对象是通过函数eglCreateWindowSurface的第三个参数来指定的。在我们这个场景中，这个ANativeWindow对象正好对应于前面所创建的 Surface对象s。每当OpenGL需要绘图的时候，它就会找到前面所设置的绘图表面，即EGLSurface对象surface。有了EGLSurface对象surface之后，就可以找到与它关联的ANativeWindow对象，即Surface对象s。有了Surface对象s之后，就可以通过其内部的sp指针mGraphicBufferProducer来请求SurfaceFlinger服务返回帧缓冲区硬件设备的一个图形访问接口。这样，OpenGL最终就可以将要绘制的图形渲染到帧缓冲区硬件设备中去，即显示在实际屏幕上。屏幕的大小，即宽度和高度，可以通过函数eglQuerySurface来获得。

3）动画文件的读取是按顺序进行的，如果读取成功，则不再读取后续的文件，如果失败，则读取下一个文件。顺序如下：

如果设备的加密功能已经开启，或者设备正在进行加密，则读取加密开机动画文件，路径为：
1
#define SYSTEM_ENCRYPTED_BOOTANIMATION_FILE "/system/media/bootanimation-encrypted.zip"

OEM厂商指定的开机动画，路径为：

1	#define OEM_BOOTANIMATION_FILE "/oem/media/bootanimation.zip"

系统开机动画，路径为：

1	#define SYSTEM_BOOTANIMATION_FILE "/system/media/bootanimation.zip"

这一步执行完成之后，用来显示第三个开机画面的线程的初始化工作就执行完成了，接下来，就会执行这个线程的主体函数，即BootAnimation类的成员函数threadLoop。
BootAnimation类的成员函数threadLoop的实现如下所示：

bool BootAnimation::threadLoop()
{
    bool r;
    // We have no bootanimation file, so we use the stock android logo
    // animation.
    if (mZip == NULL) {
        r = android();
    } else {
        r = movie();
    }

    eglMakeCurrent(mDisplay, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT);
    eglDestroyContext(mDisplay, mContext);
    eglDestroySurface(mDisplay, mSurface);
    mFlingerSurface.clear();
    mFlingerSurfaceControl.clear();
    eglTerminate(mDisplay);
    IPCThreadState::self()->stopProcess();
    return r;
}

这个函数流程比较简单，首先判断自定义的开机动画文件mZip是否存在，如果存在就调用movie()完成自定义开机画面的显示；如果不存在，调用android()完成系统默认开机画面的显示。然后进行开机动画显示后的销毁、释放工作，主要就是readyToRun中初始化的一些EGL对象。最后终止线程，并return。注意，movie()和android()的返回值都是false，因此线程结束也会返回false。threadLoop()函数如果返回值为false，则该函数中的内容只会执行一次；如果返回true，则会不停的执行。这里返回false，因此只会执行一次。

接下来，我们就分别分析BootAnimation类的成员函数android和movie的实现。

系统默认开机动画android()

BootAnimation类的成员函数android的实现如下所示：

bool BootAnimation::android()
{
    //读取开机动画默认图片，根据图片创建两个纹理对象
    //"android"字样图片
    initTexture(&mAndroid[0], mAssets, "images/android-logo-mask.png");
    //闪光图片
    initTexture(&mAndroid[1], mAssets, "images/android-logo-shine.png");

    // clear screen
    //清理屏幕
    glShadeModel(GL_FLAT);
    glDisable(GL_DITHER);
    glDisable(GL_SCISSOR_TEST);
    glClearColor(0,0,0,1);
    glClear(GL_COLOR_BUFFER_BIT);
    eglSwapBuffers(mDisplay, mSurface);

    glEnable(GL_TEXTURE_2D);
    glTexEnvx(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
    //图片在屏幕中现实位置
    const GLint xc = (mWidth  - mAndroid[0].w) / 2;
    const GLint yc = (mHeight - mAndroid[0].h) / 2;
    const Rect updateRect(xc, yc, xc + mAndroid[0].w, yc + mAndroid[0].h);

    glScissor(updateRect.left, mHeight - updateRect.bottom, updateRect.width(),
            updateRect.height());

    // Blend state
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
    glTexEnvx(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);

    const nsecs_t startTime = systemTime();
    do {
        //计算每次偏移时间，然后计算出偏移位置
        nsecs_t now = systemTime();
        double time = now - startTime;
        float t = 4.0f * float(time / us2ns(16667)) / mAndroid[1].w;
        GLint offset = (1 - (t - floorf(t))) * mAndroid[1].w;
        GLint x = xc - offset;

        glDisable(GL_SCISSOR_TEST);
        glClear(GL_COLOR_BUFFER_BIT);

        glEnable(GL_SCISSOR_TEST);
        glDisable(GL_BLEND);
        //绘制闪光图片，这个会根据上面计算的位置来显示
        glBindTexture(GL_TEXTURE_2D, mAndroid[1].name);
        glDrawTexiOES(x,                 yc, 0, mAndroid[1].w, mAndroid[1].h);
        glDrawTexiOES(x + mAndroid[1].w, yc, 0, mAndroid[1].w, mAndroid[1].h);

        glEnable(GL_BLEND);
        //绘制Android字样的图片，这个不动
        glBindTexture(GL_TEXTURE_2D, mAndroid[0].name);
        glDrawTexiOES(xc, yc, 0, mAndroid[0].w, mAndroid[0].h);
        //交换缓冲区，以显示到屏幕
        EGLBoolean res = eglSwapBuffers(mDisplay, mSurface);
        if (res == EGL_FALSE)
            break;

        // 12fps: don't animate too fast to preserve CPU
        const nsecs_t sleepTime = 83333 - ns2us(systemTime() - now);
        if (sleepTime > 0)
            usleep(sleepTime);
        //最后执行checkExit函数，判断是否退出了
        checkExit();
    } while (!exitPending());

    glDeleteTextures(1, &mAndroid[0].name);
    glDeleteTextures(1, &mAndroid[1].name);
    return false;
}

一共有以下几个步骤：
1） Android系统默认的开机动画是由两张图片android-logo-mask.png和android-logo-shine.png中。这两张图片保存在frameworks/base/core/res/assets/images目录中，它们最终会被编译在framework-res模块（frameworks/base/core/res）中，即编译在framework-res.apk文件中。编译在framework-res模块中的资源文件可以通过AssetManager类来访问。

BootAnimation类的成员函数android首先调用另外一个成员函数initTexture来将根据图片android-logo-mask.png和android-logo-shine.png的内容来分别创建两个纹理对象，这两个纹理对象就分别保存在BootAnimation类的成员变量mAndroid所描述的一个数组中。通过混合渲染这两个纹理对象，我们就可以得到一个开机动画，这是通过中间的while循环语句来实现的。

2）图片android-logo-mask.png用作动画前景，它是一个镂空的“ANDROID”图像。图片android-logo-shine.png用作动画背景，它的中间包含有一个高亮的呈45度角的条纹。在每一次循环中，图片android-logo-shine.png被划分成左右两部分内容来显示。左右两个部分的图像宽度随着时间的推移而此消彼长，这样就可以使得图片android-logo-shine.png中间高亮的条纹好像在移动一样。另一方面，在每一次循环中，图片android-logo-mask.png都作为一个整体来渲染，而且它的位置是恒定不变的。由于它是一个镂空的“ANDROID”图像，因此，我们就可以通过它的镂空来看到它背后的图片android-logo-shine.png的条纹一闪一闪地划过。这个while循环语句会一直被执行，直到应用程序/system/bin/bootanimation被结束为止。

3）在循环语句最后会执行checkExit()函数：

void BootAnimation::checkExit() {
    // Allow surface flinger to gracefully request shutdown
    char value[PROPERTY_VALUE_MAX];
    property_get(EXIT_PROP_NAME, value, "0");
    int exitnow = atoi(value);
    if (exitnow) {
        requestExit();
        if (mAudioPlayer != NULL) {
            mAudioPlayer->requestExit();
        }
    }
}

首先调用property_get获取属性EXIT_PROP_NAME的值:

1	#define EXIT_PROP_NAME "service.bootanim.exit"

然后判断该值，如果为1，则调用requestExit（）要求退出当前线程，该函数是异步的。位于system/core/libutils/Thread.cpp中：

void Thread::requestExit()
{
    Mutex::Autolock _l(mLock);
    //这里将mExitPending 赋值为true
    mExitPending = true;
}

回到android()代码：

1	} while (!exitPending());

调用exitPending()，改函数判断requestExit（）是否被调用过，如果调用过则返回true，否则为false。依然位于system/core/libutils/Thread.cpp中：

bool Thread::exitPending() const
{
    Mutex::Autolock _l(mLock);
    //上面我们在requestExit赋过值了
    return mExitPending;
}

这样，当属性“service.bootanim.exit”值被设为”1”时，android()就会调用requestExit()，exitPending()返回值为true。于是do…while()循环就会退出，开机动画绘制就会结束。
至于什么时候是哪个服务将属性“service.bootanim.exit”的值设置为1的，我们后面讲开机动画的停止的时候会提到。

自定义开机动画movie()

BootAnimation类的成员函数movie的实现比较长，我们分段来阅读：
Part.1：

bool BootAnimation::movie(){
String8 desString;
    //读取desc.txt文件内容
    if (!readFile("desc.txt", desString)) {
        return false;
    }
    char const* s = desString.string();

    // Create and initialize an AudioPlayer if we have an audio_conf.txt file
    //如果存在audio_conf.txt文件，则会创建一个AudioPlayer，并根据读取的字符串初始化
    //ignore it
    String8 audioConf;
    if (readFile("audio_conf.txt", audioConf)) {
        mAudioPlayer = new AudioPlayer;
        if (!mAudioPlayer->init(audioConf.string())) {
            ALOGE("mAudioPlayer.init failed");
            mAudioPlayer = NULL;
        }
    }

    ......
}

从前面BootAnimation类的成员函数readyToRun的实现可以知道，如果目标设备上存在压缩文件/system/media/bootanimation.zip(另外两种我们忽略)，那么BootAnimation类的成员变量mZip就会指向它，这段代码作用是读取开机动画文件mZip中的描述文件“desc.txt”。每个动画文件压缩包中必须要包含一个desc.txt，该文件用来描述开机动画如何显示。下面以一个示例来分析一下该文件：

480 640 20  
p 1 0 folder1  
p 2 20 folder2  
c 0 0 folder3  
c 1 0 folder4

Part.2：
第1行用来描述开机动画在屏幕显示的大小及速度。具体为：开机动画的宽度为480个像素，高度为640个像素，显示频率为每秒20帧，即每帧显示1/20秒。

下面的每一行代表一个片段，显示的时候会按照顺序从上到下依次显示。第1个字符为片段类型，有’c’和’p’两种，两者的区别后面会结合代码说明。

第2个数字为该片段重复显示的次数，如果为‘0’，表示会无限重复显示；第3个数字为两次显示之间的间隔，单位为第一行中定义的每帧显示的时间；第4个字符串为该片段所在的文件夹，一个片段可以由多个png图片组成，都存放在folder文件夹中。

“p 1 0 folder1”代表该片段显示1次，与下一个片段间隔0s，该片段的显示图片路径为bootanimation.zip/folder1。
“p 2 20 folder2”代表该片段显示2次，且两次之间显示的间隔为20(1/20)=1s，与下一个片段间隔20(1/20)=1s，该片段的显示图片路径为bootanimation.zip/folder2。
“c 0 0 folder3”代表该片段无限循环显示，且两次显示的间隔为0s，与下一个片段间隔0s，该片段的显示图路径为bootanimation.zip/folder3。
“c 1 10 folder4”代表该片段显示1次，显示后暂停10*(1/20)=0.5s，该片段的显示图路径为bootanimation.zip/folder4。


bool BootAnimation::movie(){

    ...Part.1...
    Animation animation;

    // Parse the description file
    for (;;) {
        const char* endl = strstr(s, "\n");//检测首次出现换行符的地址
        if (!endl) break;
        //每次读取一行
        String8 line(s, endl - s);
        const char* l = line.string();
        int fps, width, height, count, pause;
        char path[ANIM_ENTRY_NAME_MAX];
        char color[7] = "000000"; // default to black if unspecified

        char pathType;
        if (sscanf(l, "%d %d %d", &width, &height, &fps) == 3) {//每行如果有三个字符串，则依次是宽、高、帧率
            // ALOGD("> w=%d, h=%d, fps=%d", width, height, fps);
            animation.width = width;
            animation.height = height;
            animation.fps = fps;
        }
        //如果是大于等于四个字符串，则依次是显示类型、显示次数、与下一次间隔时间、显示颜色
        else if (sscanf(l, " %c %d %d %s #%6s", &pathType, &count, &pause, path, color) >= 4) {
            // ALOGD("> type=%c, count=%d, pause=%d, path=%s, color=%s", pathType, count, pause, path, color);
            Animation::Part part;
            part.playUntilComplete = pathType == 'c';
            part.count = count;
            part.pause = pause;
            part.path = path;
            part.audioFile = NULL;
            if (!parseColor(color, part.backgroundColor)) {
                ALOGE("> invalid color '#%s'", color);
                part.backgroundColor[0] = 0.0f;
                part.backgroundColor[1] = 0.0f;
                part.backgroundColor[2] = 0.0f;
            }
            animation.parts.add(part);
        }

        s = ++endl;
    }
    ......
}

上面的for循环语句分析完成desc.txt文件的内容后，就得到了开机动画的显示大小、速度以及片断信息。这些信息都保存在Animation对象animation中，其中，每一个动画片断都使用一个Animation::Part对象来描述，并且保存在Animation对象animation的成员变量parts所描述的一个片断列表中。

Part.3：

bool BootAnimation::movie(){

    ...Part.1...
    ...Part.2...

    // read all the data structures
    //开始读取zip文件
    const size_t pcount = animation.parts.size();
    void *cookie = NULL;
    if (!mZip->startIteration(&cookie)) {
        return false;
    }

    ZipEntryRO entry;
    char name[ANIM_ENTRY_NAME_MAX];
    //开始循环遍历每一个文件
    while ((entry = mZip->nextEntry(cookie)) != NULL) {
        const int foundEntryName = mZip->getEntryFileName(entry, name, ANIM_ENTRY_NAME_MAX);
        if (foundEntryName > ANIM_ENTRY_NAME_MAX || foundEntryName == -1) {
            ALOGE("Error fetching entry file name");
            continue;
        }

        const String8 entryName(name);
        const String8 path(entryName.getPathDir());
        const String8 leaf(entryName.getPathLeaf());
        if (leaf.size() > 0) {
            for (size_t j=0 ; j<pcount ; j++) {
                if (path == animation.parts[j].path) {
                    int method;
                    // supports only stored png files
                    if (mZip->getEntryInfo(entry, &method, NULL, NULL, NULL, NULL, NULL)) {
                        if (method == ZipFileRO::kCompressStored) {
                            FileMap* map = mZip->createEntryFileMap(entry);
                            if (map) {
                                Animation::Part& part(animation.parts.editItemAt(j));
                                if (leaf == "audio.wav") {
                                    // a part may have at most one audio file
                                    part.audioFile = map;
                                } else {
                                    Animation::Frame frame;
                                    frame.name = leaf;
                                    frame.map = map;
                                    part.frames.add(frame);
                                }
                            }
                        }
                    }
                }
            }
        }
    }

    mZip->endIteration(cookie);

    ......
}

接下来，BootAnimation类的成员函数movie再断续将每一个片断所对应的png图片读取出来。每一个png图片都表示一个动画帧，使用一个Animation::Frame对象来描述，并且保存在对应的Animation::Part对象的成员变量frames所描述的一个帧列表中。

Part.4：

bool BootAnimation::movie(){

    ...Part.1...
    ...Part.2...
    ...Part.3...

    // clear screen
    glShadeModel(GL_FLAT);
    glDisable(GL_DITHER);
    glDisable(GL_SCISSOR_TEST);
    glDisable(GL_BLEND);
    glClearColor(0,0,0,1);
    glClear(GL_COLOR_BUFFER_BIT);

    eglSwapBuffers(mDisplay, mSurface);

    glBindTexture(GL_TEXTURE_2D, 0);
    glEnable(GL_TEXTURE_2D);
    glTexEnvx(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_REPLACE);
    glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
    glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
    glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
    glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

    const int xc = (mWidth - animation.width) / 2;
    const int yc = ((mHeight - animation.height) / 2);
    nsecs_t lastFrame = systemTime();
    nsecs_t frameDuration = s2ns(1) / animation.fps;

    Region clearReg(Rect(mWidth, mHeight));
    clearReg.subtractSelf(Rect(xc, yc, xc+animation.width, yc+animation.height));

    ......
}

前面的一系列gl函数首先用来清理屏幕，接下来的一系列gl函数用来设置OpenGL的纹理显示方式。
变量xc和yc的值用来描述开机动画的显示位置，即需要在屏幕中间显示开机动画，另外一个变量frameDuration的值用来描述每一帧的显示时间，它是以纳秒为单位的。
Region对象clearReg用来描述屏幕中除了开机动画之外的其它区域，它是用整个屏幕区域减去开机动画所点据的区域来得到的。

Part.5：

bool BootAnimation::movie(){

    ...Part.1...
    ...Part.2...
    ...Part.3...
    ...Part.4...

    //第一层for循环用来显示每一个动画片断
    for (size_t i=0 ; i<pcount ; i++) {
        const Animation::Part& part(animation.parts[i]);
        const size_t fcount = part.frames.size();
        glBindTexture(GL_TEXTURE_2D, 0);
        //第二层的for循环用来循环显示每一个动画片断
        for (int r=0 ; !part.count || r<part.count ; r++) {
            // Exit any non playuntil complete parts immediately
            if(exitPending() && !part.playUntilComplete)
                break;

            // only play audio file the first time we animate the part
            if (r == 0 && mAudioPlayer != NULL && part.audioFile) {
                mAudioPlayer->playFile(part.audioFile);
            }

            glClearColor(
                    part.backgroundColor[0],
                    part.backgroundColor[1],
                    part.backgroundColor[2],
                    1.0f);
            //第三层的for循环用来显示每一个动画片断所对应的png图片
            //可以看到，如果exitPending()返回值为true且part.playUntilComplete=false，则会break。
            //即：当SurfaceFlinger服务要求bootanimation停止显示动画时，以‘p’标识的片段会停止，
            //而以'c'标识的片段会继续显示。这就是两者之间的主要区别。 
            for (size_t j=0 ; j<fcount && (!exitPending() || part.playUntilComplete) ; j++) {
                const Animation::Frame& frame(part.frames[j]);
                nsecs_t lastFrame = systemTime();

                if (r > 0) {
                    glBindTexture(GL_TEXTURE_2D, frame.tid);
                } else {//如果一个动画片断的循环显示次数不等于1，那么就说明这个动画片断中的png图片需要重复地显示在屏幕中
                    //第一次显示一个png图片的时候，会调用函数glGenTextures来为这个png图片创建一个纹理对象,
                    //并且将这个纹理对象的名称保存在对应的Animation::Frame对象的成员变量tid中
                    if (part.count != 1) {
                        glGenTextures(1, &frame.tid);
                        glBindTexture(GL_TEXTURE_2D, frame.tid);
                        glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
                        glTexParameterx(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
                    }
                    initTexture(frame);
                }
                // 如果Region对象clearReg所包含的区域不为空,首先要将它所包含的区域裁剪掉，避免开机动画可以显示在指定的位置以及大小中
                if (!clearReg.isEmpty()) {
                    Region::const_iterator head(clearReg.begin());
                    Region::const_iterator tail(clearReg.end());
                    glEnable(GL_SCISSOR_TEST);
                    while (head != tail) {
                        const Rect& r(*head++);
                        glScissor(r.left, mHeight - r.bottom,
                                r.width(), r.height());
                        glClear(GL_COLOR_BUFFER_BIT);
                    }
                    glDisable(GL_SCISSOR_TEST);
                }
                glDrawTexiOES(xc, yc, 0, animation.width, animation.height);
                eglSwapBuffers(mDisplay, mSurface);

                nsecs_t now = systemTime();
                nsecs_t delay = frameDuration - (now - lastFrame);
                //ALOGD("%lld, %lld", ns2ms(now - lastFrame), ns2ms(delay));
                lastFrame = now;
                //调用函数usleep函数来让线程睡眠一下，以保证每一个png图片，即每一帧动画都按照预先指定好的速度来显示
                if (delay > 0) {
                    struct timespec spec;
                    spec.tv_sec  = (now + delay) / 1000000000;
                    spec.tv_nsec = (now + delay) % 1000000000;
                    int err;
                    do {
                        err = clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &spec, NULL);
                    } while (err<0 && errno == EINTR);
                }

                checkExit();
            }
            //每当循环显示完成一个片断时，需要调用usleep函数来使得线程睡眠part.pause * ns2us(frameDuration)毫秒，以便可以按照预先设定的节奏来显示开机动画。
            usleep(part.pause * ns2us(frameDuration));

            // For infinite parts, we've now played them at least once, so perhaps exit
            //如果无限循环，则检查是否有退出消息来了，上面android()函数分析过了
            if(exitPending() && !part.count)
                break;
        }

        // free the textures for this part
        //最后一个if语句判断一个动画片断是否是循环显示的，即循环次数不等于1。
        //如果是的话，那么就说明前面为它所对应的每一个png图片都创建过一个纹理对象。
        //现在既然这个片断的显示过程已经结束了，因此，就需要释放前面为它所创建的纹理对象。
        if (part.count != 1) {
            for (size_t j=0 ; j<fcount ; j++) {
                const Animation::Frame& frame(part.frames[j]);
                glDeleteTextures(1, &frame.tid);
            }
        }
    }

    return false;
}

1）第一层for循环用来显示每一个动画片断，第二层的for循环用来循环显示每一个动画片断，第三层的for循环用来显示每一个动画片断所对应的png图片。这些png图片以纹理的方式来显示在屏幕中。

2）注意，如果一个动画片断的循环显示次数不等于1，那么就说明这个动画片断中的png图片需要重复地显示在屏幕中。由于每一个png图片都需要转换为一个纹理对象之后才能显示在屏幕中，因此，为了避免重复地为同一个png图片创建纹理对象，第三层的for循环在第一次显示一个png图片的时候，会调用函数glGenTextures来为这个png图片创建一个纹理对象，并且将这个纹理对象的名称保存在对应的Animation::Frame对象的成员变量tid中，这样，下次再显示相同的图片时，就可以使用前面已经创建好了的纹理对象，即调用函数glBindTexture来指定当前要操作的纹理对象。

3）如果Region对象clearReg所包含的区域不为空，那么在调用函数glDrawTexiOES和eglSwapBuffers来显示每一个png图片之前，首先要将它所包含的区域裁剪掉，避免开机动画可以显示在指定的位置以及大小中。

4）每当显示完成一个png图片之后，都要将变量frameDuration的值从纳秒转换为毫秒。如果转换后的值大小于，那么就需要调用函数usleep函数来让线程睡眠一下，以保证每一个png图片，即每一帧动画都按照预先指定好的速度来显示。注意，函数usleep指定的睡眠时间只能精确到毫秒，因此，如果预先指定的帧显示时间小于1毫秒，那么BootAnimation类的成员函数movie是无法精确地控制地每一帧的显示时间的。

5）还有另外一个地方需要注意的是，每当循环显示完成一个片断时，需要调用usleep函数来使得线程睡眠part.pause * ns2us(frameDuration)毫秒，以便可以按照预先设定的节奏来显示开机动画。

6）最后一个if语句判断一个动画片断是否是循环显示的，即循环次数不等于1。如果是的话，那么就说明前面为它所对应的每一个png图片都创建过一个纹理对象。现在既然这个片断的显示过程已经结束了，因此，就需要释放前面为它所创建的纹理对象。

附注：
可以看到，如果exitPending()返回值为true且part.playUntilComplete=false，则会break。即：当SurfaceFlinger服务要求bootanimation停止显示动画时，以‘p’标识的片段会停止，而以’c’标识的片段会继续显示。这就是两者之间的主要区别。我猜想”c”标识的意思是continue，即：即使SurfaceFlinger要求bootanimation停止动画，bootanimation也不会立刻停止动画，它会等c标识片段都显示完毕后，再停止。

至此，第三个开机画面的显示过程就分析完成了。

开机动画的停止

接下来，我们再继续分析第三个开机画面是如何停止显示的。

当System进程将系统中的关键服务启动起来之后，就会将Launcher启动起来。Android应用程序的启动过程实际上就是它的根Activity组件的启动过程。对于应用程序Launcher来说，它的根Activity组件即为Launcher组件。

一个Activity组件在启动起来之后，就会被记录起来，等到它所运行在的主线程空闲的时候，这个主线程就会向ActivityManagerService发送一个Activity组件空闲的通知。由于应用程序Launcher是系统中第一个被启动的应用程序，即它的根Activity组件是系统中第一个被启动的Activity组件，因此，当ActivityManagerService接收到它的空闲通知的时候，就可以知道系统是刚刚启动起来的。在这种情况下，ActivityManagerService就会停止显示开机动画，以便可以在屏幕中显示应用程序Lancher的界面。

如果一个线程想要在空闲的时候处理一些事务，那么就必须要向这个线程的消息队列注册一个空闲消息处理器。自定义的空闲消息处理器灯必须要从MessageQueue.IdleHandler类继承下来，并且重写成员函数queueIdle。当一个线程空闲的时候，即消息队列中没有新的消息需要处理的时候，那些注册了的空闲消息处理器的成员函数queueIdle就会被调用。

应用程序的主线程是通过ActivityThread类来描述的，它实现在文件frameworks/base/core/Java/android/app/ActivityThread.java中。每当有一个新的Activity组件启动起来的时候，ActivityThread类都会向它所描述的应用程序主线程的消息队列注册一个类型为Idler的空闲消息处理器。这样一个应用程序的主线程就可以在空闲的时候，向ActivityManagerService发送一个Activity组件空闲通知，相当于是通知ActivityManagerService，一个新的Activity组件已经准备就绪了。

Idler类定义在frameworks/base/core/java/android/app/ActivityThread.java中，它的成员函数queueIdle的实现如下所示：

private class Idler implements MessageQueue.IdleHandler {
    @Override
    public final boolean queueIdle() {
        ActivityClientRecord a = mNewActivities;
        ......
        if (a != null) {
            mNewActivities = null;
            IActivityManager am = ActivityManagerNative.getDefault();
            ActivityClientRecord prev;
            do {
                .....
                if (a.activity != null && !a.activity.mFinished) {
                    try {
                        am.activityIdle(a.token, a.createdConfig, stopProfiling);
                        a.createdConfig = null;
                    } catch (RemoteException ex) {
                        // Ignore
                    }
                }
                prev = a;
                a = a.nextIdle;
                prev.nextIdle = null;
            } while (a != null);
        }
        ......
        return false;
    }
}

ActivityThread类有一个类型为ActivityClientRecord的成员变量mNewActivities，用来描述所有在当前应用程序主线程中新启动起来的Activity组件。这些新启动起来的Activity组件通过ActivityClientRecord类的成员变量nextIdle连接在一起。一旦当前应用程序主线程向ActivityManagerService发送了这些新启动的Activity组件的空闲通知之后，这些新启动起来的Activity组件就不会再被保存在ActivityThread类的成员变量mNewActivities中了，即每一个新启动的Activity组件只有一次机会向ActivityManagerService发送一个空闲通知。

向ActivityManagerService发送一个Activity组件空闲通知是通过调用ActivityManagerService代理对象的成员函数activityIdle来实现的，而ActivityManagerService代理对象可以通过调用ActivityManagerNative类的静态成员函数getDefault来获得。

ActivityManagerService代理对象的类型为ActivityManagerProxy，它的成员函数activityIdle实现在文件frameworks/base/core/java/android/app/ActivityManagerNative.java中，如下所示：

class ActivityManagerProxy implements IActivityManager  
{  
    ......  
  
    public void activityIdle(IBinder token, Configuration config) throws RemoteException  
    {  
        Parcel data = Parcel.obtain();  
        Parcel reply = Parcel.obtain();  
        data.writeInterfaceToken(IActivityManager.descriptor);  
        data.writeStrongBinder(token);  
        if (config != null) {  
            data.writeInt(1);  
            config.writeToParcel(data, 0);  
        } else {  
            data.writeInt(0);  
        }  
        mRemote.transact(ACTIVITY_IDLE_TRANSACTION, data, reply, IBinder.FLAG_ONEWAY);  
        reply.readException();  
        data.recycle();  
        reply.recycle();  
    }  
  
    ......  
}

ActivityManagerProxy类的成员函数activityIdle实际上是向ActivityManagerService发送一个类型为ACTIVITY_IDLE_TRANSACTION的Binder进程间通信请求，其中，参数token用来描述与这个进程间通信请求所关联的一个Activity组件，在我们这个场景中，这个Activity组件即为应用程序Launcher的根Activity组件Launcher。

类型为ACTIVITY_IDLE_TRANSACTION的Binder进程间通信请求是由ActivityManagerService类的成员函数activityIdle来处理的，如下所示：

public final class ActivityManagerService extends ActivityManagerNative  
        implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {  
    ......  
  
    @Override
    public final void activityIdle(IBinder token, Configuration config, boolean stopProfiling) {
        final long origId = Binder.clearCallingIdentity();
        synchronized (this) {
            ActivityStack stack = ActivityRecord.getStackLocked(token);
            if (stack != null) {
                ActivityRecord r =
                        mStackSupervisor.activityIdleInternalLocked(token, false, config);
                if (stopProfiling) {
                    if ((mProfileProc == r.app) && (mProfileFd != null)) {
                        try {
                            mProfileFd.close();
                        } catch (IOException e) {
                        }
                        clearProfilerLocked();
                    }
                }
            }
        }
        Binder.restoreCallingIdentity(origId);
    }
 
  
    ......  
}

ActivityManagerService有一个类型为ActivityStackSupervisor的成员变量mStackSupervisor，Run all ActivityStacks through this，运行所有的ActivityStacks 通过这个，它的成员函数activityIdleInternalLocked如下：

// Checked.
final ActivityRecord activityIdleInternalLocked(final IBinder token, boolean fromTimeout,
        Configuration config) {
    ......
    boolean booting = false;
    boolean enableScreen = false;
    boolean activityRemoved = false;

    ActivityRecord r = ActivityRecord.forToken(token);
    if (r != null) {
        ......
        if (isFrontStack(r.task.stack) || fromTimeout) {
            booting = mService.mBooting;
            mService.mBooting = false;
            if (!mService.mBooted) {
                mService.mBooted = true;
                enableScreen = true;
            }
        }
    }
    ......

    if (booting || enableScreen) {
        mService.postFinishBooting(booting, enableScreen);
    }

    ......

    return r;
}

所以进入if判断中，将booting置为true，mService.mBooted和enableScreen也为true，进入下面的if判断，ActivityManagerService调用postFinishBooting方法完成系统启动。我们进入往下看：

void postFinishBooting(boolean finishBooting, boolean enableScreen) {
    mHandler.sendMessage(mHandler.obtainMessage(FINISH_BOOTING_MSG,
            finishBooting? 1 : 0, enableScreen ? 1 : 0));
}
final MainHandler mHandler;

final class MainHandler extends Handler {

    @Override
    public void handleMessage(Message msg) {

        ......
        case FINISH_BOOTING_MSG: {
            if (msg.arg1 != 0) {
                finishBooting();
            }
            if (msg.arg2 != 0) {
                enableScreenAfterBoot();
            }
            break;
        }
        ......
    }
}

这里最后调用enableScreenAfterBoot方法，以便可以将屏幕让出来显示应用程序Launcher的界面：

void enableScreenAfterBoot() {
    EventLog.writeEvent(EventLogTags.BOOT_PROGRESS_ENABLE_SCREEN,
            SystemClock.uptimeMillis());
    mWindowManager.enableScreenAfterBoot();

    synchronized (this) {
        updateEventDispatchingLocked();
    }
}

ActivityManagerService类的成员变量mWindowManager指向了系统中的Window管理服务WindowManagerService，ActivityManagerService服务通过调用它的成员函数enableScreenAfterBoot来停止显示开机动画。

WindowManagerService类的成员函数enableScreenAfterBoot的实现如下所示：

public void enableScreenAfterBoot() {
    synchronized(mWindowMap) {
        if (DEBUG_BOOT) {
            RuntimeException here = new RuntimeException("here");
            here.fillInStackTrace();
            Slog.i(TAG, "enableScreenAfterBoot: mDisplayEnabled=" + mDisplayEnabled
                    + " mForceDisplayEnabled=" + mForceDisplayEnabled
                    + " mShowingBootMessages=" + mShowingBootMessages
                    + " mSystemBooted=" + mSystemBooted, here);
        }
        if (mSystemBooted) {
            return;
        }
        mSystemBooted = true;
        hideBootMessagesLocked();
        // If the screen still doesn't come up after 30 seconds, give
        // up and turn it on.
        mH.sendEmptyMessageDelayed(H.BOOT_TIMEOUT, 30*1000);
    }

    mPolicy.systemBooted();

    performEnableScreen();
}

WindowManagerService类的成员变量mSystemBooted用来记录系统是否已经启动完成的。如果已经启动完成的话，那么这个成员变量的值就会等于true，这时候WindowManagerService类的成员函数enableScreenAfterBoot什么也不做就返回了，否则的话，WindowManagerService类的成员函数enableScreenAfterBoot首先将这个成员变量的值设置为true，接着再调用另外一个成员函数performEnableScreen来执行停止显示开机动画的操作。
WindowManagerService类的成员函数performEnableScreen的实现如下所示：

public void performEnableScreen() {
    synchronized(mWindowMap) {
        ......
        if (mDisplayEnabled) {
            return;
        }
        if (!mSystemBooted && !mShowingBootMessages) {
            return;
        }

        // Don't enable the screen until all existing windows have been drawn.
        if (!mForceDisplayEnabled && checkWaitingForWindowsLocked()) {
            return;
        }

        if (!mBootAnimationStopped) {
            // Do this one time.
            try {
                IBinder surfaceFlinger = ServiceManager.getService("SurfaceFlinger");
                if (surfaceFlinger != null) {
                    //Slog.i(TAG, "******* TELLING SURFACE FLINGER WE ARE BOOTED!");
                    Parcel data = Parcel.obtain();
                    data.writeInterfaceToken("android.ui.ISurfaceComposer");
                    surfaceFlinger.transact(IBinder.FIRST_CALL_TRANSACTION, // BOOT_FINISHED
                            data, null, 0);
                    data.recycle();
                }
            } catch (RemoteException ex) {
                Slog.e(TAG, "Boot completed: SurfaceFlinger is dead!");
            }
            mBootAnimationStopped = true;
        }

        ......
}

WindowManagerService类的另外一个成员变量mDisplayEnabled用来描述WindowManagerService是否已经初始化过系统的屏幕了，只有当它的值等于false，并且系统已经完成启动，即WindowManagerService类的成员变量mSystemBooted等于true的情况下，WindowManagerService类的成员函数performEnableScreen才通知SurfaceFlinger服务停止显示开机动画。

注意，WindowManagerService类的成员函数performEnableScreen是通过一个类型为IBinder.FIRST_CALL_TRANSACTION的进程间通信请求来通知SurfaceFlinger服务停止显示开机动画的。

在SurfaceFlinger服务，类型为IBinder.FIRST_CALL_TRANSACTION的进程间通信请求被定义为停止显示开机动画的请求，位于frameworks/native/include/gui/ISurfaceComposer.h中：

class BnSurfaceComposer : public BnInterface<ISurfaceComposer>  
{  
public:  
    enum {  
        // Note: BOOT_FINISHED must remain this value, it is called from  
        // Java by ActivityManagerService.  
        BOOT_FINISHED = IBinder::FIRST_CALL_TRANSACTION,  
        ......  
    };  
  
    virtual status_t    onTransact( uint32_t code,  
                                    const Parcel& data,  
                                    Parcel* reply,  
                                    uint32_t flags = 0);  
};

BnSurfaceComposer类它是SurfaceFlinger服务所要继承的Binder本地对象类，其中。当SurfaceFlinger服务接收到类型为IBinder::FIRST_CALL_TRANSACTION，即类型为BOOT_FINISHED的进程间通信请求时，它就会将该请求交给它的成员函数bootFinished来处理。

SurfaceFlinger服务的成员函数bootFinished实现在文件frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp中，如下所示：

void SurfaceFlinger::bootFinished()
{
    const nsecs_t now = systemTime();
    const nsecs_t duration = now - mBootTime;
    ALOGI("Boot is finished (%ld ms)", long(ns2ms(duration)) );
    mBootFinished = true;

    // wait patiently for the window manager death
    const String16 name("window");
    sp<IBinder> window(defaultServiceManager()->getService(name));
    if (window != 0) {
        window->linkToDeath(static_cast<IBinder::DeathRecipient*>(this));
    }

    // stop boot animation
    // formerly we would just kill the process, but we now ask it to exit so it
    // can choose where to stop the animation.
    property_set("service.bootanim.exit", "1");
}

可以看到，该函数将属性“service.bootanim.exit”设置为”1”。在第2节分析android()代码的时候，我们讲到：当属性“service.bootanim.exit”值被设为”1”时，android()就会退出，开机动画显示自然也就结束了。由于android()退出且返回值为false，BootAnimation::threadLoop()线程也就结束了。再回到BootAnimation.cpp的main()函数中，threadLoop()线程结束，main函数也就结束，至此，bootanimaiton进程就自行结束，开机动画的显示完成了。

至此，Android系统的三个开机画面的显示过程就分析完成了。

小结

本文的目的并不是单纯为了介绍Android系统的开机画面，而是希望能够以Android系统的开机画面来作为切入点来分析SurfaceFlinger。后续文章我们会详细分析SurfaceFlinger的每个模块和功能。没图了，等过一阵子再去拍一波~

Android SurfaceFlinger 学习之路(二)----SurfaceFlinger概述

2017-04-27T09:28:11.000Z

因为还有很多烦人的事情需要处理，所以暂时没有离职，也挺忙的。最近一段时间稍微轻松些，所以更新一下这个进度。

前言

Android的Graphic系统是设计的很精妙，但是也很复杂。SurfaceFlinger也是Graphic系统中十分重要的组成部分，要从正面分析不是一件容易的事情。所以我们先从侧面窥视它的重要模块，积累起足够的模块基础，再统一分析，就会一目了然。

GUI框架

图形显示过程

一般应用开发都要将UI数据使用Activity这个载体去展示，典型的Activity显示流程为：

startActivity启动Activity；
为Activity创建一个window(PhoneWindow)，并在WindowManagerService中注册这个window；
切换到前台显示时，WindowManagerService会要求SurfaceFlinger为这个window创建一个surface用来绘图。SurfaceFlinger创建一个”layer”（surface）。（以想象一下C/S架构，SF对应Server，对应Layer；App对应Client，对应Surface）,这个layer的核心即是一个BufferQueue，这时候app就可以在这个layer上render了；
将所有的layer进行合成，显示到屏幕上。

一般app而言，在任何屏幕上起码有三个layer：屏幕顶端的status bar，屏幕下面的navigation bar，还有就是app的UI部分。一些特殊情况下，app的layer可能多余或者少于3个，例如对全屏显示的app就没有status bar，而对launcher，还有个为了wallpaper显示的layer。status bar和navigation bar是由系统进行去render，因为不是普通app的组成部分嘛。而app的UI部分对应的layer当然是自己去render，所以就有了第4条中的所有layer进行“合成”。

GUI框架

SurfaceFlinger：每当用户程序刷新UI的时候，会中介BufferQueue申请一个buffer（dequeueBuffer），然后把UI的信息填入，丢给SurfaceFlinger，SurfaceFlinger通过计算多重计算合成visibleRegion之后，丢给openGL层处理，处理之后送到显示器display上显示。

根据整个Android系统的GUI设计理念，我们不难猜想到至少需要两种本地窗口：

面向管理者(SurfaceFlinger)：既然SurfaceFlinger扮演了系统中所有UI界面的管理者，那么它无可厚非地需要直接或间接地持有“本地窗口”，这个窗口就是FramebufferNativeWindow
面向应用程序：这类窗口是Surface（这里和以前版本出入比较大，之前的版本本地窗口是SurfaceTextureClient）

第二种窗口是能直接显示在终端屏幕上的——它使用了帧缓冲区，而第一种Window实际上是从内存缓冲区分配的空间。当系统中存在多个应用程序时，这能保证它们都可以获得一个“本地窗口”，并且这些窗口最终也能显示到屏幕上——SurfaceFlinger会收集所有程序的显示需求，对它们做统一的图像混合操作。

Render过程

android提供了两种方式：Canvas ，OpenGL ES。这两种方式在我认为都应该算是标准，提供了一套固定的API，实现和平台无关。Java中类似于给你提供了一个interface接口，这个接口你可以用任何方式去实现，只要满足功能要求即可。不同的人可以有不同的实现方式，对10个数进行排序，A可以用冒泡法，B可以用选择法，最终结果只要保证把这10个数排好序了，唯一差别就是实现难度和效率问题。

Canvas

android提供了Canvas 2D API用来进行普通图形的绘制的，类似TextView这种应该都是用Canvas API来完成的。而Canvas这个”标准”的具体实现是由/external/skia库来完成的，真正干活的是skia。上层Canvas调用的API到下层其实封装了skia的实现。

OpenGL ES

OpenGL ES相关的API是为了3D图形的绘制而准备的。
android上有个EGL库，EGL和OpenGL ES是什么关系？代码在frameworks\native\opengl\libs\，我们查看frameworks\native\opengl\libs\Android.mk中：

......
LOCAL_SHARED_LIBRARIES += libcutils libutils liblog libGLES_trace
#编译的库文件为/system/lib/libEGL.so
LOCAL_MODULE:= libEGL
LOCAL_LDFLAGS += -Wl,--exclude-libs=ALL
LOCAL_SHARED_LIBRARIES += libdl
# we need to access the private Bionic header <bionic_tls.h>
LOCAL_C_INCLUDES += bionic/libc/private
......

SurfaceFlinger这个非常重要的系统服务依赖EGL库，包含了EGL头文件，使用了EGL中的函数，查看frameworks/native/services/surfaceflinger/Android.mk：

......
LOCAL_SHARED_LIBRARIES := \
    libcutils \
    liblog \
    libdl \
    libhardware \
    libutils \
    libEGL \
    libGLESv1_CM \
    libGLESv2 \
    libbinder \
    libui \
    libgui \
    libpowermanager

LOCAL_MODULE:= libsurfaceflinger

include $(BUILD_SHARED_LIBRARY)
......

在SurfaceFlinger::init()中，调用了egl开头的函数，位于frameworks/native/services/surfaceflinger/SurfaceFlinger.cpp中：

void SurfaceFlinger::init() {
    ALOGI(  "SurfaceFlinger's main thread ready to run. "
            "Initializing graphics H/W...");

    status_t err;
    Mutex::Autolock _l(mStateLock);

    // initialize EGL for the default display
    //#define EGL_DEFAULT_DISPLAY       ((EGLNativeDisplayType)0)
    mEGLDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY);
    eglInitialize(mEGLDisplay, NULL, NULL);
    ......
}

在eglGetDisplay()中调用了egl_init_drivers()，位于frameworks/native/opengl/libs/egl/eglApi.cpp：

EGLDisplay eglGetDisplay(EGLNativeDisplayType display)
{
    clearError();

    uintptr_t index = reinterpret_cast<uintptr_t>(display);
    if (index >= NUM_DISPLAYS) {
        return setError(EGL_BAD_PARAMETER, EGL_NO_DISPLAY);
    }
    //egl_init_drivers函数载入OpenGL ES相关库
    if (egl_init_drivers() == EGL_FALSE) {
        return setError(EGL_BAD_PARAMETER, EGL_NO_DISPLAY);
    }

    EGLDisplay dpy = egl_display_t::getFromNativeDisplay(display);
    return dpy;
}

关于egl_init_drivers()函数，载入OpenGL ES相关库，限于本篇只是简单介绍，所以不详细分析。相关文件如下：

frameworks/native/opengl/libs/egl/Egl.cpp
frameworks/native/opengl/libs/egl/Loader.cpp

代码也不多，主要做的事情：

1. 首先在frameworks\native\opengl\libs\EGL\egl_entries.in中保存了EGL的相关API，函数都是以egl开头；在frameworks\native\opengl\libs\entries.in中保存了OpenGL ES相关API，函数都是以gl开头。函数egl_init_drivers()需要做的就是找到EGL和OpenGL ES本地的实现，然后对这些函数进行赋值。可以查看frameworks/native/opengl/libs/egl/Egl.cpp：

char const * const gl_names[] = {
    #include "../entries.in"
    NULL
};

char const * const egl_names[] = {
    #include "egl_entries.in"
    NULL
};

2. 在/vendor/lib/egl或/system/lib/egl下(不是/system/lib/下)，寻找libGLES.so，如果未找到，则寻找libGLES_*.so，上面两种库只要找到一个，则打开库，这个库里包含了EGL和OpenGL ES具体实现的库，然后“取出”库中具体的函数实现进行赋值。
但是较新版本的android已经不使用软件实现，即libagl，所以即使找到libGLES_android.so也不会去用。位于frameworks/native/opengl/libs/egl/Loader.cpp中load_driver函数实现：

void *Loader::load_driver(const char* kind,
        egl_connection_t* cnx, uint32_t mask)
{
 ......
 if (!strcmp(e->d_name, "libGLES_android.so")) {
                        // always skip the software renderer
                        continue;
                    }
 ......                   
}

如果libGLES.so和libGLES_.so都未找到，需要分别去加载/vendor/lib/egl或/system/lib/egl下libEGL.so, libGLESv1CM.so, libGLESv2.so这三个库或者libEGL.so, libGLESv1CM.so, libGLESv2_.so，然后分别对EGL、OpenGL ES V1、OpenGL ES V2的具体实现去赋值(那意思是libGLES_*.so中其实囊括了三个库所有的具体实现)。至此，就将OpenGL ES“标准”和“实现”挂钩了。

所以android中OpenGL ES的实现方式有2种：

一种是软件实现，用cpu去绘图，这就是所谓的agl(libGLES_android.so)，代码路径在frameworks/native/opengl/libagl，即the software OpenGL ES library；
另一种是硬件厂商根据自己GPU提供的实现，一般都不开放源代码，就是上面介绍的需要去/vendor/lib/egl或/system/lib/egl找的几个库，但是只要把API 函数赋值上正确的实现函数即可。

此外由于OpenGL ES的实现是系统无关的，所以EGL库的另一个作用就是将OpenGL ES和本地窗口系统结合起来，举个例子好理解，如果你要画个纹理多边形，调用OpenGL ES接口，如果要把图形render到屏幕，需要调用EGL接口。例如在使用OpenGL ES前首先需要调用EGL的相关函数去搭建好OpenGL ES的本地环境等，EGL是android使用OpenGL ES API绘图的助手！

hardware-accelerated Canvas

从android 4.0开始，支持了硬件加速的Canvas，应该就是修改了Canvas的具体实现，不用skia了，而改调用EGL和OpenGL ES API了。

android的封装

那么我们平时写app时为何不用调用上面的Canvas和OpenGL ES，也能出现漂亮的UI呢？因为我们使用的都是android上层封装好的类，例如TextView就是用了Canvas，而GLSurfaceView就是使用了OpenGL ES，android已经帮我们做了大部分的工作。当然完全可以不用调用上层的Java类，而用c++/c去直接调用Canvas和OpenGL ES。

如何去合成

首先介绍个概念，hardware overlay，来自维基百科。

From Wikipedia, the free encyclopedia
In computing, hardware overlay, a type of video overlay, provides a method of rendering an image to a display screen with a dedicated memory buffer inside computer video hardware. The technique aims to improve the display of a fast-moving video image — such as a computer game, a DVD, or the signal from a TV card. Most video cards manufactured since about 1998 and most media players support hardware overlay.[1]

The overlay is a dedicated buffer into which one app can render (typically video), without incurring the significant performance cost of checking for clipping and overlapping rendering by other apps. The framebuffer has hardware support for importing and rendering the buffer contents without going through the GPU.[citation needed]

hardware overlay 是提供一种机制，直接render到display screen的硬件内存中，提高显示效率吧。
而android对layer的合成主要包括2部分：在GPU中合成和在display的硬件中进行buffer的合成。
在GPU中进行合成，既是利用OpenGL ES进行合成，需要注意，画图的时候我们用了OpenGL ES，这里合成时也用了，功能真是强大，开始一直奇怪为何SurfaceFlinger也要去调用EGL的函数，原来是需要用OpenGL ES去合成layer；在display的硬件中进行合成，也就是hardware overlay机制。

Hardware Composer

那么android是如何使用这两种合成机制的呢？这里就是Hardware Composer的功劳。处理流程为：

1.SurfaceFlinger给HWC提供layer list，询问如何处理这些layer；
2.HWC将每个layer标记为overlay或者GLES composition，然后回馈给SurfaceFlinger；
3.SurfaceFlinger需要去处理那些GLES的合成，而不用去管overlay的合成，最后将overlay的layer和GLES合成后的buffer发送给HWC处理。

借用google一张图说明，可以将上面讲的很多概念展现，很清晰。地址位于 https://source.android.com/devices/graphics/

在我认为使用overlay后，可以将SurfaceFlinger的工作减轻，即少一些GLES的合成，HWC承担了部分OpenGL ES 和GPU的工作，从而减少了功耗。

注：如果屏幕上的画面基本不变化，这时候用GLES 合成的效率要高于overlay(overlay主要是为了render快速变化的图形等)；android 4.4往上支持4个oveylay，如果要合成超过4个layer，系统就会对剩余的使用GLES合成，所以app的layer个数对手机的功耗影响挺大。

SurfaceFlinger和BufferQueue

生产模型

一个UI完全显示到diplay的过程，SurfaceFlinger扮演着重要的角色但是它的职责是“Flinger”，即把系统中所有应用程序的最终的“绘图结果”进行“混合”，然后统一显示到物理屏幕上，而其他方面比如各个程序的绘画过程，就由其他东西来担任了。这个光荣的任务自然而然地落在了BufferQueue的肩膀上，它是每个应用程序“一对一”的辅导老师，指导着UI程序的“画板申请”、“作画流程”等一系列细节。下面的图描述了这三者的关系：

虽说是三者的关系，但是他们所属的层却只有两个，app属于Java层，BufferQueue/SurfaceFlinger属于native层。也就是说BufferQueue也是隶属SurfaceFlinger，所有工作围绕SurfaceFlinger展开。
这里IGraphicBufferProducer就是app和BufferQueue重要桥梁，GraphicBufferProducer承担着单个应用进程中的UI显示需求，与BufferQueue打交道的就是它。它的工作流程如下：

工作流程

接下来具体说明客户端（producer）和服务端SurfaceFlinger（consumer）工作的模式：
首先这里的buffer是共享缓冲区，故肯定会涉及到互斥锁，所以buffer的状态也会有多种，一般的buffer大致会经过FREE->DEQUEUED->QUEUED->ACQUIRED->FREE这个流程，如下图：

BufferQueue：可以认为BufferQueue是一个服务中心，其它两个owner必须要通过它来管理buffer。比如说当producer想要获取一个buffer时，它不能越过BufferQueue直接与consumer进行联系，反之亦然。
Producer：生产者就是“填充”buffer空间的人，通常情况下当然就是应用程序。因为应用程序不断地刷新UI，从而将产生的显示数据源源不断地写到buffer中。当Producer需要使用一块buffer时，它首先会向中介BufferQueue发起dequeue申请，然后才能对指定的缓冲区进行操作。这种情况下buffer就属于producer一个人的了，它可以对buffer进行任何必要的操作，而其它owner此刻绝不能擅自插手。
当生产者认为一块buffer已经写入完成后，它进一步调用BufferQueue的queue。从字面上看这个函数是“入列”的意思，形象地表达了buffer此时的操作——把buffer归还到BufferQueue的队列中。一旦queue成功后，owner也就随之改变为BufferQueue了。

Consumer：消费者是与生产者相对应的，它的操作同样受到BufferQueue的管控。当一块buffer已经就绪后，Consumer就可以开始工作了。这里需要特别留意的是，从各个对象所扮演的角色来看，BufferQueue是中介机构，属于服务提供方;Producer属于buffer内容的产出方，它对缓冲区的操作是一个“主动”的过程;反之，Consumer对buffer的处理则是“被动”的、“等待式”的——它必须要等到一块buffer填充完成后才能做工作。在这样的模型下，我们怎么保证Consumer可以及时的处理buffer呢？换句话说，当一块buffer数据ready后，应该怎么告知Consumer来操作呢？
仔细观察的话，可以看到BufferQueue里还同时提供了一个特别的类，名称为ProxyConsumerListener，其中的函数接口包括：

classProxyConsumerListener : public BnConsumerListener {  
  
public:       
  
 //省略构造函数  
  
        virtual void onFrameAvailable();/*当一块buffer可以被消费时，这个函数会被调用，特别注意此时没有共享锁的保护*/  
  
        virtual voidonBuffersReleased();/*BufferQueue通知consumer它已经释放其slot中的一个或多个 GraphicBuffer引用*/  
  
    private:  
  
   wp<ConsumerListener>mConsumerListener;  
  
}

这样子就很清楚了，当有一帧数据准备就绪后，BufferQueue就会调用onFrameAvailable()来通知Consumer进行消费。

消费模型

BufferQueue和SurfaceFlinger之间的通信模式如下：

也是有一对BpGraphicBufferConsumer/BnGraphicBufferConsumer支持他们之间的信息传输。

结语

本篇只是简单科普一下SurfaceFlinger的轮廓，我们从下一篇开始详细分析每个流程。
突然觉得上一篇开头太中二了=。= 唉，事情太多了，有点烦，感觉没了以前那份心若冰清的沉稳和奋不顾身的勇气了，唉(第二次唉)，慢慢来，需要时间去消化。

Android性能优化之内存优化实战

2017-04-07T11:10:11.000Z

事情依旧很多，生活的、工作的，成长总是需要代价的。一直憧憬童年和大学，那是两种异曲同工的生活态度。假装自己是个孩子，一直不想长大，被自己小小的愿望襁褓着，不去理会外面世界的沧海桑田。白驹过隙，岁月在脸上留下了痕迹，不再隐瞒早已不年轻的事实。伴随着时光点滴流逝，心也在渐渐老去。也许成长就是一种淡然吧，从锋芒毕露到心如止水，从棱角分明到不露声色。少了昔日偶尔破釜沉舟的勇气，更多的是经常瞻前顾后的思虑。时光荏苒，没有留下刻骨铭心的记忆，更多的是平淡、安静。我渐渐喜欢这种感觉，岁月静好，没有跌宕起伏的生活剧情，没有扣人心弦的情景环节，一切安好，便是生活最美好的恩赐。
记忆渐渐模糊，没有留下印记。没有选择性忘记，但却真实在一点一点消逝。那些旧照片也没能留下，早已不见了踪影，那些故人，都逐渐失去了联系，那些雨天泥泞的小路，还有路边在儿时植树节时新栽的小树，也都变得那么陌生。只有那些花儿，却开的愈加鲜艳茂密。就像一颗顽强的心，一颗不服输的心，在抗拒随波逐流的人生。
多年之前，我们都还是个孩子。经过岁月的洗礼，也许会变得更加沉稳，也会变得更加冷静，亦或者是……冷漠。回忆往昔，这一路走来，还是渐渐变成了孩时最讨厌的自己，一个冷漠的自己，一个绝情的自己。安静也许是一个借口，一种掩饰，透过镜子，终于看清了真实的自己，那个自私的自己。有人说，社会会逼着一个人成长，是啊，虽然不愿承认，但是至少褪去了青年时怕事嫌烦表选出来的虚伪，获得更多的是学会了处事不惊的态度，和勇于承担责任的勇气。如果选择对生活妥协，是不会答应的，即使没了追梦赤子心，至少还有追逐本心的动力。不忘初心，坚持自己的初衷。青春即使如同《老男孩》的歌词唱的那样：”青春如同奔流的江河,一去不回来不及道别,只剩下麻木的我,没有了当年的热血……”即便如此，依然要做不一样的我，一个不退缩、不妥协的我，一个默默前行的我，一个坚持本心的我————“我就是我，是颜色不一样的烟火，天空海阔，要做最坚强的泡沫，我喜欢我，让蔷薇开出一种结果，孤独的沙漠里一样盛放的赤裸裸”

这次带来一篇性能优化的文章，内容来自APP架构师,我稍微修改了一些部分，加了一些内容。

Memory Leak

内存泄漏：对于Java来说，就是new出来的Object 放在Heap上无法被GC回收（内存中存在无法被回收的对象）；内存泄漏发生时的主要表现为内存抖动，可用内存慢慢变少。

Memory Monitor

AndroidStudio自带的Memory Monitor可以方便的观察堆内存的分配情况，并且可以粗略的观察有没有Memory Leak。

频繁的内存抖动，可能存在内存泄漏

A：initiate GC 手动触发GC操作；
B：Dump Java Heap 获取当前的堆栈信息，生成一个.hprof文件，AndroidStudip会自动使用HeapViewer打开；一般用于操作之后检测内存泄漏的情况；
C：Start Allocation Tracking 内存分配追踪工具，用于追踪一段时间的内存分配使用情况，能够知道执行一些列操作后，有哪些对象被分配空间。一般用于追踪某项操作之后的内存分配，调整相关的方法调用来优化app性能与内存使用；
D：剩余可用内存；
E：已经使用的内存。

点击Memory Monitor的Dump Java Heap，会生成一个.hprof文件，位于工程名/captures/文件夹下。AndroidStudio会自动使用HeapViewer打开。

左面板说明：

Total Count 该类的实例个数
Heap Count 选定的Heap中实例的个数
Sizeof 每个实例占用的内存大小
Shallow Size 所有该类的实例占用的内存大小
Retained Size 该类的所有实例可支配的内存大小

右面板说明：

Instance 该类的所有实例对象（左侧Total Count为15，此处就有15个对象）
Depth 深度, GC Root点到该实例的最短链路数
Dominating Size 该实例可支配的内存大小

此处可以看出MainActivity存在了15个示例对象，怀疑此处有问题。

附：Android Device Monitor抓取：（可忽略，直接跳过）

1. 首先打开AS中的Android Device Monitor工具，Tools—>Android—>Android Device Monitor,打开如下：

2. 先选中你要检测的应用的包名，然后点击下图画圈的地方，会在程序包名后标记一个图标

3. 接下来要做的就是操作我们的app 。之后点击下图的图标就可导出hprof文件进行分析了

MAT

上述只是可以粗略的看出是不是有问题，而要知道问题出在哪里就需要借助MAT了。

打开MAT工具，如果没有可以在下面网址下载：
MAT工具下载地址

打开我们先前导出的hprof文件，不出意外会报下面的错误 :

这是因为MAT是用来分析Java程序的hprof文件的与Android导出的hprof有一定的格式区别，因此我们需要把导出的hprof文件转换一下，sdk中提供给我们转换的工具 hprof-conv.exe 在下图的位置

我们看到adb.exe和hprof-conv.exe在同一个目录，这就比较幸运了，因为我们一般都会把adb路径加入环境变量，所以这个hprof-conv也会位于环境变量当中，因此我们不用cd进入这个目录去敲命令了，直接随便哪个控制台路径都可以。比如我们利用AS自带的Terminal。

将生成的.hprof文件进行转换

格式转换命令：hprof-conv 原文件路径转换后文件路径

然后用MAT打开转换后的.hprof文件

注意下面的Actions：

Histogram可以列出内存中每个对象的名字、数量以及大小。
Dominator Tree会将所有内存中的对象按大小进行排序，并且我们可以分析对象之间的引用结构。

一般使用最多的也是这两个功能。

Retained Heap表示这个对象以及它所持有的其它引用（包括直接和间接）所占的总内存

使用Histogram：
点击Histogram并在顶部的Regex中输入MainActivity会进行正则匹配，会将包含“MainActivity”的所有对象全部列出了出来，其中第一行就是MainActivity的实例。

对着想查看的对象点击右键 -> List objects -> with incoming references 查看具体MainActivity实例。

对想要查看的对象实例点击右键-> Path To Gc Roots -> exclude weak reference（排除掉软引用）。

注意：
this$0前面的图标的左下角有个圆圈，这代表这个引用可以被Gc Roots引用到，由于MainActivity$LeakClass能被GC Roots访问到导致其不能被回收，从而它所持有的其它引用也无法被回收了，包括MainActivity，也包括MainActivity中所包含的其它资源。

此时我们就找到了内存泄漏的原因。

使用Dominator Tree

使用上面Histogram的操作方式也可以找到泄漏的具体原因，此处不再累述。
注意：每个对象前的图标的圆圈，并不代表一定是导致内存泄漏的原因，有些对象就是需要在内存中存活的，需要区别对待。

LeakCanary

LeakCanary是square出品的一个检测内存泄漏的库，集成到App之后便无需关心，在发生内存泄漏之后会Toast、通知栏弹出等方式提示，可以指出泄漏的引用路径，而且可以抓取当前的堆栈信息供详细分析。

Out Of Memory

Android OOM

Android系统的每个进程都有一个最大内存限制，如果申请的内存资源超过这个限制，系统就会抛出OOM错误。

Android 2.x系统，当dalvik allocated + external allocated + 新分配的大小 >= dalvik heap 最大值时候就会发生OOM。其中bitmap是放于external中。
Android 4.x系统，废除了external的计数器，类似bitmap的分配改到dalvik的java heap中申请，只要allocated + 新分配的内存 >= dalvik heap 最大值的时候就会发生OOM（art运行环境的统计规则还是和dalvik保持一致）
内存溢出是程序运行到某一阶段的最终结果，直接原因是剩余的内存不能满足内存的申请，但是再分析间接原因内存为什么没有了：
内存泄漏的存在可能导致可用内存越来越少；
内存申请的峰值超过了系统时间点剩余的内存；(例如：某手机单个进程可用最大内存为192M，目前分配内存80M，此时申请5M内存，但是当前时间点整个系统可用内存只有3M，此时没有超出单个进程可用最大内存，但是OOM也会发生)

Avoid Android OOM

除了避免内存泄漏之外，根据《Manage Your App’s Memory》，我们可以对内存的状态进行监听，在Activity中覆写此方法，根据不同的case进行不同的处理：

@Override
    public void onTrimMemory(int level) {        
        super.onTrimMemory(level);
    }

TRIM_MEMORY_RUNNING_MODERATE：你的应用正在运行并且不会被列为可杀死的。但是设备此时正运行于低内存状态下，系统开始触发杀死LRU Cache中的Process的机制。
TRIM_MEMORY_RUNNING_LOW：你的应用正在运行且没有被列为可杀死的。但是设备正运行于更低内存的状态下，你应该释放不用的资源用来提升系统性能。
TRIM_MEMORY_RUNNING_CRITICAL：你的应用仍在运行，但是系统已经把LRU Cache中的大多数进程都已经杀死，因此你应该立即释放所有非必须的资源。如果系统不能回收到足够的RAM数量，系统将会清除所有的LRU缓存中的进程，并且开始杀死那些之前被认为不应该杀死的进程，例如那个包含了一个运行态Service的进程。
当应用进程退到后台正在被Cached的时候，可能会接收到从onTrimMemory()中返回的下面的值之一：
TRIM_MEMORY_BACKGROUND： 系统正运行于低内存状态并且你的进程正处于LRU缓存名单中最不容易杀掉的位置。尽管你的应用进程并不是处于被杀掉的高危险状态，系统可能已经开始杀掉LRU缓存中的其他进程了。你应该释放那些容易恢复的资源，以便于你的进程可以保留下来，这样当用户回退到你的应用的时候才能够迅速恢复。
TRIM_MEMORY_MODERATE：系统正运行于低内存状态并且你的进程已经已经接近LRU名单的中部位置。如果系统开始变得更加内存紧张，你的进程是有可能被杀死的。
TRIM_MEMORY_COMPLETE：系统正运行于低内存的状态并且你的进程正处于LRU名单中最容易被杀掉的位置。你应该释放任何不影响你的应用恢复状态的资源。

Memory Churn

Memory Churn内存抖动：大量的对象被创建又在短时间内马上被释放。
瞬间产生大量的对象会严重占用Young Generation的内存区域，当达到阀值，剩余空间不够的时候，也会触发GC。系统花费在GC上的时间越多，进行界面绘制或流音频处理的时间就越短。即使每次分配的对象占用了很少的内存，但是他们叠加在一起会增加Heap的压力，从而触发更多其他类型的GC。这个操作有可能会影响到帧率，并使得用户感知到性能问题。

常见的可能引发内存抖动的情形：

循环中创建临时对象；
onDraw中创建Paint或Bitmap对象等；

例如之前使用过的有些下拉刷新控件的实现方式，在onDraw中创建Bitmap等多个临时大对象会导致内存抖动。

Bitmap

Bitmap的处理也是Android中的一个难点，当然使用第三方框架的话就屏蔽掉了这个难点。

Bitmap的内存模型；
Bitmap的加载、压缩、缓存等策略；
版本的兼容等；

关于Bitmap之后会写专门的一篇文章来介绍，此处可以参考《Handling Bitmaps》。也可以查看我之前的一片文章：浅析Bitmap占据内存大小。

Program Advice

节制地使用Service

内存管理最大的错误之一就是让Service一直运行。在后台使用service时，除非它需要被触发并执行一个任务，否则其他时候Service都应该是停止状态。另外需要注意Service工作完毕之后需要被停止，以免造成内存泄漏。

系统会倾向于保留有Service所在的进程，这使得进程的运行代价很高，因为系统没有办法把Service所占用的RAM空间腾出来让给其他组件，另外Service还不能被Paged out。这减少了系统能够存放到LRU缓存当中的进程数量，它会影响应用之间的切换效率，甚至会导致系统内存使用不稳定，从而无法继续保持住所有目前正在运行的service。

建议使用JobScheduler，而尽量避免使用持久性的Service。还有建议使用IntentService，它会在处理完交代给它的任务之后尽快结束自己。

使用优化过的集合

Android API当中提供了一些优化过后的数据集合工具类，如SparseArray，SparseBooleanArray，以及LongSparseArray等，使用这些API可以让我们的程序更加高效。传统Java API中提供的HashMap工具类会相对比较低效，因为它需要为每一个键值对都提供一个对象入口，而SparseArray就避免掉了基本数据类型转换成对象数据类型的时间。

谨慎对待面向抽象

开发者经常把抽象作为好的编程实践，因为抽象能够提升代码的灵活性与可维护性。然而，抽象会导致一个显著的开销：面向抽象需要额外的代码（不会被执行到），同样会被咨映射到内存中，耗费了更多的时间以及内存空间。因此如果面向抽象对你的代码没有显著的收益，那你应该避免使用。
例如：使用枚举通常会比使用静态常量要消耗两倍以上的内存，在Android开发当中我们应当尽可能地不使用枚举。

使用nano protobufs序列化数据

Protocol buffers是Google为序列化数据设计的一种语言无关、平台无关、具有良好扩展性的数据描述语言，与XML类似，但是更加轻量、快速、简单。如果使用protobufs来实现数据的序列化及反序列化，建议在客户端使用nano protobufs，因为通常的protobufs会生成冗余代码，会导致可用内存减少，Apk体积变大，运行速度减慢。

避免内存抖动

垃圾回收通常不会影响应用的表现，但是短时间内多次的垃圾回收会消耗掉界面绘制的时间。系统花费在GC上的时间越多，进行界面绘制或流音频处理的时间就越短。通常内存抖动会导致多次的GC，实践中内存抖动代表了一段时间内分配了临时对象。
例如：在For循环中分配了多个临时对象，或在onDraw()方法中创建了Paint、Bitmap对象，应用产生了大量的对象；这会很快耗尽young generation的可用内存，导致GC发生。
使用Analyze your RAM usage中的工具找出代码里内存抖动的地方。考虑把操作移出内部循环，或者将其移动到基于工厂的分配结构中。

移除消耗内存的库、缩减Apk的大小

查看Apk的大小，包括三方库和内嵌的资源，这些都会影响应用消耗的内存。通过减少冗余、非必须或大的组件、库、图片、资源、动画等，都可以改善应用的内存消耗。

使用Dagger 2进行依赖注入

如果您打算在应用程序中使用依赖注入框架，请考虑使用Dagger 2。 Dagger不使用反射来扫描应用程序的代码。 Dagger的编译时注解技术实现意味着它不需要不必要的运行时成本。而使用反射的其它依赖注入框架通常通过扫描代码来初始化过程。此过程可能需要显着更多的CPU周期和RAM，并可能导致应用程序启动时明显的卡顿。
备注：之前的文档是不建议使用依赖注入框架，因为实现原理是使用反射，而进化为编译时注解之后，就不再有反射带来的影响了。

谨慎使用第三方库

很多开源的library代码都不是为移动端而编写的，如果运用在移动设备上，并不一定适合。即使是针对Android而设计的library，也需要特别谨慎，特别是在你不知道引入的library具体做了什么事情的时候。例如，其中一个library使用的是nano protobufs, 而另外一个使用的是micro protobufs。这样一来，在你的应用里面就有2种protobuf的实现方式。这样类似的冲突还可能发生在输出日志，加载图片，缓存等等模块里面。另外不要为了1个或者2个功能而导入整个library，如果没有一个合适的库与你的需求相吻合，你应该考虑自己去实现，而不是导入一个大而全的解决方案。

Other

谨慎使用LargeHeap属性

可以通过在manifest的application标签下添加largeHeap=true的属性来为应用声明一个更大的heap空间(可以通过getLargeMemoryClass()来获取到这个更大的heap size阈值)。然而，声明得到更大Heap阈值的本意是为了一小部分会消耗大量RAM的应用(例如一个大图片的编辑应用)。不要轻易的因为你需要使用更多的内存而去请求一个大的Heap Size。只有当你清楚的知道哪里会使用大量的内存并且知道为什么这些内存必须被保留时才去使用large heap，使用额外的内存空间会影响系统整体的用户体验，并且会使得每次gc的运行时间更长。在任务切换时，系统的性能会大打折扣。另外, large heap并不一定能够获取到更大的heap。在某些有严格限制的机器上，large heap的大小和通常的heap size是一样的。

谨慎使用多进程

多进程确实是一种可以帮助我们节省和管理内存的高级技巧。如果你要使用它的话一定要谨慎使用，因为绝大多数的应用程序都不应该在多个进程当中运行的，一旦使用不当，它甚至会增加额外的内存而不是帮我们节省内存；同时需要知晓多进程带来的缺点。这个技巧比较适用于那些需要在后台去完成一项独立的任务，和前台的功能是可以完全区分开的场景。

这里举一个比较适合去使用多进程技巧的场景，比如说我们正在做一个音乐播放器软件，其中播放音乐的功能应该是一个独立的功能，它不需要和UI方面有任何关系，即使软件已经关闭了也应该可以正常播放音乐。如果此时我们只使用一个进程，那么即使用户关闭了软件，已经完全由Service来控制音乐播放了，系统仍然会将许多UI方面的内存进行保留。在这种场景下就非常适合使用两个进程，一个用于UI展示，另一个则用于在后台持续地播放音乐。

实现方式可能存在的问题：例如启动页闪屏图，show完毕之后应该释放掉Bitmap。

一些实现方式看起来没有问题实现了功能但是实际上可能对内存造成了影响。我在使用Heap Viewer查看Bitmap对象时发现了一张只需下载不应该被加载的图。

使用HeapViewer可直接查看Bitmap

内存中出现的不应该被加载的图

通过查阅代码，发现问题出在：此处下载图片作为另一个模块的使用图，但是下载的方法竟然是使用图片加载器加载出来Bitmap然后再保存到本地；而且保存之后也没有将Bitmap对象释放掉。
与之类似的还有：首页闪屏图展示之后，Bitmap对象应该及时释放掉。

使用try catch进行捕获

对高风险OOM代码块如展示高清大图等进行try catch，在catch块加载非高清的图片并做相应内存回收的处理。注意OOM是OutOfMemoryError，不能使用Exception进行捕获。

Summary

内存优化的套路：
1. 解决所有的内存泄漏

集成LeakCanary，可以方便的定位出90%的内存泄漏问题；
通过反复进出可疑界面，观察内存增减的情况，Dump Java Heap获取当前堆栈信息使用MAT进行分析。
内存泄漏的常见情形可参照《Android 内存泄漏分析心得》

2. 避免内存抖动

避免在循环中创建临时对象；
避免在onDraw中创建Paint、Bitmap对象等。

3. Bitmap的使用

使用三方库加载图片一般不会出内存问题，但是需要注意图片使用完毕的释放，而不是被动等待释放。

4. 使用优化过的数据结构

5. 使用onTrimMemory根据不同的内存状态做相应处理

6. Library的使用

去掉无用的Library，对生成的Apk进行反编译查看使用到的Library，避免出现无用的Lib仍然被打进Apk；
避免引入巨大的Library；
使用Proguard进行混淆、压缩。

参考：

小结

最近还是很忙，主要是生活上有多多事情需要处理，所以没空闲时间更新博客了，唉。。。。。。本篇没有妹子，见谅~~

Android SurfaceFlinger 学习之路(一)----Android图形显示之HAL层Gralloc模块实现

2017-03-12T12:10:11.000Z

好久没更新了，主要是因为年前和年后太忙了，尤其是年后这一段时间，忙得把身体都忙坏了。。。。。。终于在我GG之前，提交了离职，总算赢得了一些空闲时间，赶紧养养身体。。。现在处于即将待业状态，正好有时间研究一下年前就想了解的surfaceflinger模块。。。不过最近我也看了下，surfaceflinger内容太多太复杂了，也许这个系列我坚持不了多久，不能像上一个MediaPlayer系列那样。。。。。。同时，因为目前我处于即将待业状况，所以求好心HR或者大牛带我入新坑，感激不尽(~ToT~)

下载内核代码(准备工作)

因为接下来分析需要用到部分kernel代码，所有我们需要先把kernel代码下载下来。

更换hosts文件

因为天朝GFW的原因，所以不能直接访问google放置android source code的网站 https://source.android.com/ 。这个上面有很详细的教程，教大家下载、编译源码，和其他变动相关的知识。所以我们需要Fan Qiang。

如果买了VPN的土豪；找到免费vpn（GreenVPN、FreeVPN、hideVPN、rssVPN等等，好多都失效了）；还有可以去亚马逊申请一个免费服务器（一年），可以搭建自己的FQ服务器（这个需要绑定一张VISA信用卡，银联的不行），这里有个教程，我上传到了自己博客服务器，大家可以下载下来；或者有稳定且流量大的FQ软件（比如赛风、自由门、蓝灯、畅游无限浏览器、影梭等）；或者有靠谱的hosts文件的，可以跳过这一步。

因为要拉kernel代码，文件比较大，所以我推荐更换hosts文件。这里推荐老D hosts，地址是 https://laod.cn/hosts/2017-google-hosts.html 。都是傻瓜式教程，应该都会。

下载kernel代码

更换完hosts文件后，进入android源码官网，然后找到里面的Explore the Source标题下面描述里面的AOSP repository，点击进入源码仓库 https://android.googlesource.com/ 。
1) 因为我们要下kernel源码，所以选择kenrnel/common,下载这一个通用代码；
2) 用git下载代码：git clone https://android.googlesource.com/kernel/common ；
3) 切换分支，我选了一个release版本：android-4.4-n-release，所以要git checkout -b android-4.4-n-release remotes/origin/android-4.4-n-release，然后pull一下，common文件夹下就有代码了。
4) 最后将下载好的代码导入source insight，这一步就不用细说了。

初识Gralloc模块

Gralloc模块简介

Android设备的显示屏被抽象为一个帧缓冲区，而Android系统中的SurfaceFlinger服务就是通过向这个帧缓冲区写入内容来绘制应用程序的用户界面的。Android系统在硬件抽象层中提供了一个Gralloc模块，封装了对帧缓冲区的所有访问操作。
Linux内核在启动的过程中会创建一个类别和名称分别为“graphics”和“fb0”的设备，用来描述系统中的第一个帧缓冲区，即第一个显示屏，其中，数字0表示从设备号。注意，系统中至少要存在一个显示屏，因此，名称为“fb0”的设备是肯定会存在的，否则的话，就是出错了。
init进程在启动的过程中，会启动另外一个进程ueventd来管理系统的设备文件。当ueventd进程启动起来之后，会通过netlink接口来Linux内核通信，以便可以获得内核中的硬件设备变化通知。而当ueventd进程发现内核中创建了一个类型和名称分别为“graphics”和“fb0”的设备的时候，就会这个设备创建一个/dev/graphics/fb0设备文件。这样，用户空间的应用程序就可以通过设备文件/dev/graphics/fb0来访问内核中的帧缓冲区，即在设备的显示屏中绘制指定的画面。注意，用户空间的应用程序一般是通过内存映射的方式来访问设备文件/dev/graphics/fb0的。
Android系统在硬件抽象层中提供了一个Gralloc模块，封装了对帧缓冲区的所有访问操作。用户空间的应用程序在使用帧缓冲区之间，首先要加载Gralloc模块，并且获得一个gralloc设备和一个fb设备。有了gralloc设备之后，用户空间中的应用程序就可以申请分配一块图形缓冲区，并且将这块图形缓冲区映射到应用程序的地址空间来，以便可以向里面写入要绘制的画面的内容。最后，用户空间中的应用程序就通过fb设备来将已经准备好了的图形缓冲区渲染到帧缓冲区中去，即将图形缓冲区的内容绘制到显示屏中去。相应地，当用户空间中的应用程序不再需要使用一块图形缓冲区的时候，就可以通过gralloc设备来释放它，并且将它从地址空间中解除映射。

代码结构

Gralloc模块实现源码位于：hardware/libhardware/modules/gralloc ：

功能分析

接下来，我们就按照上述使用情景来分析Gralloc模块的实现。

Gralloc模块的加载过程

每一个HAL模块都有一个ID值，以这些ID值为参数来调用硬件抽象层提供的函数hw_get_module就可以将指定的模块加载到内存来，并且获得一个hw_module_t接口来打开相应的设备。
Gralloc模块的ID值定义在hardware/libhardware/include/hardware/gralloc.h文件中，如下所示：

/**
 * The id of this module
 */
#define GRALLOC_HARDWARE_MODULE_ID "gralloc"

函数hw_get_module实现在hardware/libhardware/hardware.c文件中，如下所示：

int hw_get_module(const char *id, const struct hw_module_t **module)
{
    return hw_get_module_by_class(id, NULL, module);//调用hw_get_module_by_class函数
}
//hw_get_module_by_class函数实现
int hw_get_module_by_class(const char *class_id, const char *inst,
                           const struct hw_module_t **module)
{
    int i;
    char prop[PATH_MAX];
    char path[PATH_MAX];
    char name[PATH_MAX]; //PATH_MAX为256
    char prop_name[PATH_MAX];

    if (inst)//NULL
        snprintf(name, PATH_MAX, "%s.%s", class_id, inst);
    else
        strlcpy(name, class_id, PATH_MAX);//字符串拷贝

    /*
     * Here we rely on the fact that calling dlopen multiple times on
     * the same .so will simply increment a refcount (and not load
     * a new copy of the library).
     * We also assume that dlopen() is thread-safe.
     */
     //我们依赖的事实是，调用dlopen方法多次打开相同的so库会简单的增加引用计数(而不会重复加载多次库的拷贝)
     //我们认为dlopen方法是线程安全的

    /* First try a property specific to the class and possibly instance */
    //先查找确定系统属性的值是否为空
    snprintf(prop_name, sizeof(prop_name), "ro.hardware.%s", name);
    if (property_get(prop_name, prop, NULL) > 0) {
        //如果不为空，则找到属性对应的so库是否存在
        if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
            goto found;
        }
    }

    /* Loop through the configuration variants looking for a module */
    //如果上面没找到指定的so库，则循环遍历指定数组里的属性，然后找到第一个存在的so并跳出
    for (i=0 ; i<HAL_VARIANT_KEYS_COUNT; i++) {
        if (property_get(variant_keys[i], prop, NULL) == 0) {
            continue;
        }
        if (hw_module_exists(path, sizeof(path), name, prop) == 0) {
            goto found;
        }
    }

    /* Nothing found, try the default */
    //如果第二步查找也没找到，就用默认的default属性
    if (hw_module_exists(path, sizeof(path), name, "default") == 0) {
        goto found;
    }

    return -ENOENT;

found:
    /* load the module, if this fails, we're doomed, and we should not try
     * to load a different variant. */
    //如果我们找到了相关so，则加载它
    return load(class_id, path, module);
}

/**
 * There are a set of variant filename for modules. The form of the filename
 * is "<MODULE_ID>.variant.so" so for the led module the Dream variants 
 * of base "ro.product.board", "ro.board.platform" and "ro.arch" would be:
 *
 * led.trout.so
 * led.msm7k.so
 * led.ARMV6.so
 * led.default.so
 */
static const char *variant_keys[] = {
    "ro.hardware",  /* This goes first so that it can pick up a different
                       file on the emulator. */
    "ro.product.board",
    "ro.board.platform",
    "ro.arch"
};

上面流程我们分步来看：

查询对应动态库

1）先查找确定系统属性的值是否为空，property_get函数到系统属性，可以在shell环境下用getprop ro.hardware.%s找到ro.hardware.%s属性，最后一个字符串自己指定；然后调用hw_module_exists函数顺着/system/lib/hw和/vendor/lib/hw或者/system/lib64/hw和/vendor/lib64/hw查找相应so库是否存在，我们看看hw_module_exists函数：

/*
 * Check if a HAL with given name and subname exists, if so return 0, otherwise
 * otherwise return negative.  On success path will contain the path to the HAL.
 */
 //检查HAL层给的文件名是否存在，如果存在返回0，否则返回负无穷
 //如果成功了，会把这个路径包含进HAL
static int hw_module_exists(char *path, size_t path_len, const char *name,
                            const char *subname)
{
    snprintf(path, path_len, "%s/%s.%s.so",
             HAL_LIBRARY_PATH2, name, subname);
    if (access(path, R_OK) == 0)
        return 0;

    snprintf(path, path_len, "%s/%s.%s.so",
             HAL_LIBRARY_PATH1, name, subname);
    if (access(path, R_OK) == 0)
        return 0;

    return -ENOENT;
}

/** Base path of the hal modules */
//主要在下面目录下找相关so库
#if defined(__LP64__)
#define HAL_LIBRARY_PATH1 "/system/lib64/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib64/hw"
#else
#define HAL_LIBRARY_PATH1 "/system/lib/hw"
#define HAL_LIBRARY_PATH2 "/vendor/lib/hw"
#endif

2）如果第一步GG了，就进入第二步，则循环遍历指定数组里的属性，然后找到第一个存在的so并跳出。
函数hw_get_module依次在目录/system/lib/hw和/vendor/lib/hw中(或64位对应目录)查找一个名称为”.variant.so”的文件，其中，< MODULE_ID >是一个模块ID，而variant表示”ro.hardware”、”ro.product.board”、”ro.board.platform”和”ro.arch”四个系统属性值之一。例如，对于Gralloc模块来说，函数hw_get_module依次在目录/system/lib/hw和/vendor/lib/hw中检查是否存在以下四个文件：

gralloc.< ro.hardware >.so
gralloc.< ro.product.board >.so
gralloc.< ro.board.platform >.so
gralloc.< ro.arch >.so

只要其中的一个文件存在，函数hw_get_module就会停止查找过程，并且调用另外一个函数load来将这个文件加载到内存中来。

3）如果第二步也GG了，就进入第三步，如果第二步查找也没找到，就用默认的default属性。如果在/system/lib/hw和/vendor/lib/hw中均不存这些文件，那么函数hw_get_module就会在目录/system/lib/hw中查找是否存在一个名称为gralloc.default.so的文件。如果存在的话，那么也会调用函数load将它加载到内存中来。

4）找到对应的so库后，就要调用load函数将他加载到内存中。

加载对应动态库

函数load也是实现在文件hardware/libhardware/hardware.c文件中，如下所示：

/**
 * Load the file defined by the variant and if successful
 * return the dlopen handle and the hmi.
 * @return 0 = success, !0 = failure.
 */
static int load(const char *id,
        const char *path,
        const struct hw_module_t **pHmi)
{
    int status;
    void *handle;
    struct hw_module_t *hmi;

    /*
     * load the symbols resolving undefined symbols before
     * dlopen returns. Since RTLD_GLOBAL is not or'd in with
     * RTLD_NOW the external symbols will not be global
     */
    handle = dlopen(path, RTLD_NOW);//用dlopen函数将对应so库加载到内存中
    if (handle == NULL) {
        char const *err_str = dlerror();
        ALOGE("load: module=%s\n%s", path, err_str?err_str:"unknown");
        status = -EINVAL;
        goto done;
    }

    /* Get the address of the struct hal_module_info. */
    //调用函数dlsym来获得它所导出的符号HMI
    const char *sym = HAL_MODULE_INFO_SYM_AS_STR;
    hmi = (struct hw_module_t *)dlsym(handle, sym);
    if (hmi == NULL) {
        ALOGE("load: couldn't find symbol %s", sym);
        status = -EINVAL;
        goto done;
    }

    /* Check that the id matches */
    //检查id是否匹配
    if (strcmp(id, hmi->id) != 0) {
        ALOGE("load: id=%s != hmi->id=%s", id, hmi->id);
        status = -EINVAL;
        goto done;
    }

    hmi->dso = handle;

    /* success */
    status = 0;

    done:
    if (status != 0) {
        hmi = NULL;
        if (handle != NULL) {
            dlclose(handle);
            handle = NULL;
        }
    } else {
        ALOGV("loaded HAL id=%s path=%s hmi=%p handle=%p",
                id, path, *pHmi, handle);
    }

    *pHmi = hmi;

    return status;
}

在Linux系统中，后缀名为”so”的文件为动态链接库文件，可能通过函数dlopen来加载到内存中。硬件抽象层模块编写规范规定每一个硬件抽象层模块都必须导出一个符号名称为HAL_MODULE_INFO_SYM_AS_STR的符号，而且这个符号必须是用来描述一个类型为hw_module_t的结构体的。
HAL_MODULE_INFO_SYM_AS_STR是一个宏，定义在文件hardware/libhardware/include/hardware/hardware.h文件中，如下所示：

/**
 * Name of the hal_module_info as a string
 */
#define HAL_MODULE_INFO_SYM_AS_STR  "HMI"

将Gralloc模块加载到内存中来之后，就可以调用函数dlsym来获得它所导出的符号HMI。由于这个符号指向的是一个hw_module_t结构体，因此，最后函数load就可以强制地将这个符号转换为一个hw_module_t结构体指针，并且保存在输出参数pHmi中返回给调用者。调用者获得了这个hw_module_t结构体指针之后，就可以创建一个gralloc设备或者一个fb设备。

数据结构定义

模块Gralloc实现在目录hardware/libhardware/modules/gralloc中，它导出的符号HMI定义在文件hardware/libhardware/modules/gralloc/gralloc.cpp文件中，如下所示：

static struct hw_module_methods_t gralloc_module_methods = {
        .open = gralloc_device_open
};

struct private_module_t HAL_MODULE_INFO_SYM = {
    .base = {
        .common = {
            .tag = HARDWARE_MODULE_TAG,
            .version_major = 1,
            .version_minor = 0,
            .id = GRALLOC_HARDWARE_MODULE_ID,
            .name = "Graphics Memory Allocator Module",
            .author = "The Android Open Source Project",
            .methods = &gralloc_module_methods
        },
        .registerBuffer = gralloc_register_buffer,
        .unregisterBuffer = gralloc_unregister_buffer,
        .lock = gralloc_lock,
        .unlock = gralloc_unlock,
    },
    .framebuffer = 0,
    .flags = 0,
    .numBuffers = 0,
    .bufferMask = 0,
    .lock = PTHREAD_MUTEX_INITIALIZER,
    .currentBuffer = 0,
};

HAL_MODULE_INFO_SYM也是一个宏，它的值是与宏HAL_MODULE_INFO_SYM_AS_STR对应的，它也是定义在文件hardware/libhardware/include/hardware/hardware.h文件中，如下所示：

/**
 * Name of the hal_module_info
 */
#define HAL_MODULE_INFO_SYM         HMI

符号HAL_MODULE_INFO_SYM的类型为private_module_t。前面提到，符号HAL_MODULE_INFO_SYM必须指向一个hw_module_t结构体，但是这里它指向的却是一个private_module_t结构体，是不是有问题呢？为了弄清楚这个问题，我们首先了解一下结构体private_module_t的定义，如下图：

结构体private_module_t的第一个成员变量base指向一个gralloc_module_t结构体，而gralloc_module_t结构体的第一个成员变量common又指向了一个hw_module_t结构体，这意味着，指向一个private_module_t结构体的指针同时可以用作一个gralloc_module_t或者hw_module_t结构体提针来使用。事实上，这是使用C语言来实现的一种继承关系，等价于结构体private_module_t继承结构体gralloc_module_t，而结构体gralloc_module_t继承hw_module_t结构体。这样，我们就可以把在Gralloc模块中定义的符号HAL_MODULE_INFO_SYM看作是一个hw_module_t结构体。

hw_module_t结构体有一个重要的成员变量methods，它的类型为hw_module_methods_t，它用来描述一个HAL模块的操作方法列表。结构体hw_module_methods_t只定义有一个操作方法open，用来打开一个指定的设备。在Gralloc模块中，用来打开指定设备的函数被指定为gralloc_device_open，通过这个函数就可以打开Gralloc模块中的gralloc或者fb设备，后面我们再详细分析。

1）结构体gralloc_module_t定义在文件hardware/libhardware/include/hardware/gralloc.h中，它主要是定义了四个用来操作图形缓冲区的成员函数，如下所示：

typedef struct gralloc_module_t {  
　　struct hw_module_t common;  
　　//映射一块图形缓冲区到一个进程的地址空间去  
　　int (*registerBuffer)(struct gralloc_module_t const* module,buffer_handle_t handle);  
　　//取消映射一块图形缓冲区到一个进程的地址空间去  
　　int (*unregisterBuffer)(struct gralloc_module_t const* module,buffer_handle_t handle);  
　　//锁定一个指定的图形缓冲区  
    int (*lock)(struct gralloc_module_t const* module,buffer_handle_t handle, int usage,  
            int l, int t, int w, int h,void** vaddr);  
    //解锁一个指定的图形缓冲区  
　　int (*unlock)(struct gralloc_module_t const* module,buffer_handle_t handle);  
    int (*perform)(struct gralloc_module_t const* module,int operation, ... );  
    void* reserved_proc[3];  
} gralloc_module_t;

成员函数registerBuffer和unregisterBuffer分别用来注册和注销一个指定的图形缓冲区，这个指定的图形缓冲区使用一个buffer_handle_t句柄来描述。所谓注册图形缓冲区，实际上就是将一块图形缓冲区映射到一个进程的地址空间去，而注销图形缓冲区就是执行相反的操作。
成员函数lock和unlock分别用来锁定和解锁一个指定的图形缓冲区，这个指定的图形缓冲区同样是使用一个buffer_handle_t句柄来描述。在访问一块图形缓冲区的时候，例如，向一块图形缓冲写入内容的时候，需要将该图形缓冲区锁定，用来避免访问冲突。在锁定一块图形缓冲区的时候，可以指定要锁定的图形绘冲区的位置以及大小，这是通过参数l、t、w和h来指定的，其中，参数l和t指定的是要访问的图形缓冲区的左上角位置，而参数w和h指定的是要访问的图形缓冲区的宽度和长度。锁定之后，就可以获得由参数参数l、t、w和h所圈定的一块缓冲区的起始地址，保存在输出参数vaddr中。另一方面，在访问完成一块图形缓冲区之后，需要解除这块图形缓冲区的锁定。
在Gralloc模块中，符号HAL_MODULE_INFO_SYM指向的gralloc结构体的成员函数registerBuffer、unregisterBuffer、lock和unlock分别被指定为函数gralloc_register_buffer、gralloc_unregister_buffer、gralloc_lock和gralloc_unlock，后面我们再详细分析它们的实现。

2）结构体private_module_t定义在文件hardware/libhardware/modules/gralloc/gralloc_priv.h中，它主要是用来描述帧缓冲区的属性，如下所示：

struct private_module_t {  
    gralloc_module_t base;  
    private_handle_t* framebuffer; //指向系统帧缓冲区的句柄  
    uint32_t flags; //用来标志系统帧缓冲区是否支持双缓冲  
    uint32_t numBuffers;//表示系统帧缓冲区包含有多少个图形缓冲区  
    uint32_t bufferMask; //记录系统帧缓冲区中的图形缓冲区的使用情况  
    pthread_mutex_t lock; //一个互斥锁，用来保护结构体private_module_t的并行访问  
    buffer_handle_t currentBuffer; //用来描述当前正在被渲染的图形缓冲区  
    int pmem_master;  
    void* pmem_master_base;  
    struct fb_var_screeninfo info; //保存设备显示屏的动态属性信息  
    struct fb_fix_screeninfo finfo; ////保存设备显示屏的固定属性信息  
    float xdpi; //描述设备显示屏在宽度  
    float ydpi; //描述设备显示屏在高度  
    float fps; //用来描述显示屏的刷新频率  
};

成员变量framebuffer的类型为private_handle_t，它是一个指向系统帧缓冲区的句柄，后面我们再分析结构体private_handle_t的定义。
成员变量flags用来标志系统帧缓冲区是否支持双缓冲。如果支持的话，那么它的PAGE_FLIP位就等于1，否则的话，就等于0。
成员变量numBuffers表示系统帧缓冲区包含有多少个图形缓冲区。一个帧缓冲区包含有多少个图形缓冲区是与它的可视分辨率以及虚拟分辨率的大小有关的。例如，如果一个帧缓冲区的可视分辨率为800 x 600，而虚拟分辨率为1600 x 600，那么这个帧缓冲区就可以包含有两个图形缓冲区。
成员变量bufferMask用来记录系统帧缓冲区中的图形缓冲区的使用情况。例如，假设系统帧缓冲区有两个图形缓冲区，这时候成员变量bufferMask就有四种取值，分别是二进制的00、01、10和11，其中，00分别表示两个图缓冲区都是空闲的，01表示第1个图形缓冲区已经分配出去，而第2个图形缓冲区是空闲的，10表示第1个图形缓冲区是空闲的，而第2个图形缓冲区已经分配出去，11表示两个图缓冲区都已经分配出去。
成员变量lock是一个互斥锁，用来保护结构体private_module_t的并行访问。
成员变量currentBuffer的类型为buffer_handle_t，用来描述当前正在被渲染的图形缓冲区，后面我们再分析它的定义。
成员变量pmem_master和pmem_master_base目前没有使用。
成员变量info和finfo的类型分别为fb_var_screeninfo和fb_fix_screeninfo，它们用来保存设备显示屏的属性信息，其中，成员变量info保存的属性信息是可以动态设置的，而成员变量finfo保存的属性信息是只读的。这两个成员变量的值可以通过IO控制命令FBIOGET_VSCREENINFO和FBIOGET_FSCREENINFO来从帧缓冲区驱动模块中获得。
成员变量xdpi和ydpi分别用来描述设备显示屏在宽度和高度上的密度，即每英寸有多少个像素点。
成员变量fps用来描述显示屏的刷新频率，它的单位的fps，即每秒帧数。

3）接下来，我们再分析结构体buffer_handle_t的定义。结构体buffer_handle_t定义在文件hardware/libhardware/include/hardware/gralloc.h文件中，如下所示：
1
typedef const native_handle* buffer_handle_t;

它是一个类型为native_handle_t的指针，而结构体native_handle_t用来描述一个本地句柄值，它定义在系统运行时层的文件system/core/include/cutils/native_handle.h文件中，如下所示：

typedef struct native_handle  
{  
    int version; //设置为结构体native_handle_t的大小，用来标识结构体native_handle_t的版本  
    int numFds;  //表示结构体native_handle_t所包含的文件描述符的个数，这些文件描述符保存在成员变量data所指向的一块缓冲区中。  
    int numInts; //表示结构体native_handle_t所包含的整数值的个数，这些整数保存在成员变量data所指向的一块缓冲区中。  
    int data[0]; //指向的一块缓冲区中  
} native_handle_t;

成员变量version的大小被设置为结构体native_handle_t的大小，用来标识结构体native_handle_t的版本。
成员变量numFds和numInts表示结构体native_handle_t所包含的文件描述符以及整数值的个数，这些文件描述符和整数保存在成员变量data所指向的一块缓冲区中。

4）我们一般不直接使用native_handle_t结构体来描述一个本地句柄值，而是通过它的子类来描述一个具体的本地句柄值。接下来我们就通过结构体private_handle_t的定义来说明native_handle_t结构体的用法。
结构体private_handle_t用来描述一块图形缓冲区，这块图形缓冲区可能是在帧缓冲区中分配的，也可能是在内存中分配的，视具体情况而定，它定义在文件hardware/libhardware/modules/gralloc/gralloc_priv.h文件中，如下所示：


#ifdef __cplusplus  
struct private_handle_t : public native_handle {  
#else  
struct private_handle_t {  
    struct native_handle nativeHandle;  
#endif  
  
    enum {  
        PRIV_FLAGS_FRAMEBUFFER = 0x00000001  
    };  
  
    // file-descriptors  
    int     fd;  ////指向一个文件描述符，这个文件描述符要么指向帧缓冲区设备，要么指向一块匿名共享内存 
    // ints  
    int     magic;  //指向一个魔数，它的值由静态成员变量sMagic来指定，用来标识一个private_handle_t结构
    int     flags;  //用来描述一个缓冲区的标志，它的值要么等于0，要么等于PRIV_FLAGS_FRAMEBUFFER  
    int     size;   //用来描述一个缓冲区的大小。 
    int     offset; //用来描述一个缓冲区的偏移地址。
  
    // FIXME: the attributes below should be out-of-line  
    int     base;  //用来描述一个缓冲区的实际地址，它是通过成员变量offset来计算得到的。 
    int     pid;   //用来描述一个缓冲区的创建者的PID。  
  
#ifdef __cplusplus  
    static const int sNumInts = 6;  //包含有6个整数
    static const int sNumFds = 1;   //包含有1个文件描述符 
    static const int sMagic = 0x3141592;  
  
    private_handle_t(int fd, int size, int flags) :  
        fd(fd), magic(sMagic), flags(flags), size(size), offset(0),  
        base(0), pid(getpid())  
    {  
        version = sizeof(native_handle);  
        numInts = sNumInts;  
        numFds = sNumFds;  
    }  
    ~private_handle_t() {  
        magic = 0;  
    }  
  
    static int validate(const native_handle* h) {  
        const private_handle_t* hnd = (const private_handle_t*)h;  
        if (!h || h->version != sizeof(native_handle) ||  
                h->numInts != sNumInts || h->numFds != sNumFds ||  
                hnd->magic != sMagic)  
        {  
            LOGE("invalid gralloc handle (at %p)", h);  
            return -EINVAL;  
        }  
        return 0;  
    }  
#endif  
};

为了方便描述，我们假设我们是在C++环境中编译文件gralloc_priv.h，即编译环境定义有宏__cplusplus。这样，结构体private_handle_t就是从结构体native_handle_t继承下来的，它包含有1个文件描述符以及6个整数，以及三个静态成员变量。

成员变量fd指向一个文件描述符，这个文件描述符要么指向帧缓冲区设备，要么指向一块匿名共享内存，取决于它的宿主结构体private_handle_t描述的一个图形缓冲区是在帧缓冲区分配的，还是在内存中分配的。
成员变量magic指向一个魔数，它的值由静态成员变量sMagic来指定，用来标识一个private_handle_t结构体。
成员变量flags用来描述一个图形缓冲区的标志，它的值要么等于0，要么等于PRIV_FLAGS_FRAMEBUFFER。当一个图形缓冲区的标志值等于PRIV_FLAGS_FRAMEBUFFER的时候，就表示它是在帧缓冲区中分配的。
成员变量size用来描述一个图形缓冲区的大小。
成员变量offset用来描述一个图形缓冲区的偏移地址。例如，当一个图形缓冲区是在一块内存中分块的时候，假设这块内存的地址为start，那么这个图形缓冲区的起始地址就为start + offset。
成员变量base用来描述一个图形缓冲区的实际地址，它是通过成员变量offset来计算得到的。例如，上面计算得到的start + offset的值就保存在成员变量base中。
成员变量pid用来描述一个图形缓冲区的创建者的PID。例如，如果一个图形缓冲区是在ID值为1000的进程中创建的，那么用来描述这个图形缓冲区的private_handle_t结构体的成员变量pid的值就等于1000。

结构体private_handle_t的静态成员变量sMagic前面已经描述过了，另外两个静态成员变量sNumInts和sNumFds的值分别等于1和6，表示结构体private_handle_t包含有1个文件描述符和6个整数，它们是用来初始化结构体private_handle_t的父类native_handle_t的成员变量numInts和numFds的，如结构体private_handle_t的构造函数所示。从这里就可以看出，结构体private_handle_t的父类native_handle_t的成员变量data所指向的缓冲区就是由结构体private_handle_t的成员变量fds、magic、flags、size、offset、base和pid所占用的连续内存块来组成的，一共包含有7个整数。
结构体private_handle_t还定义了一个静态成员函数validate，用来验证一个native_handle_t指针是否指向了一个private_handle_t结构体。

至此，Gralloc模块的加载过程以及相关的数据结构体就介绍到这里，接下来我们分别分析定义在Gralloc模块中的gralloc和fb设备的打开过程。

Gralloc设备的打开过程

在Gralloc模块中，gralloc设备的ID值定义为GRALLOC_HARDWARE_GPU0。GRALLOC_HARDWARE_GPU0是一个宏，定义在文件hardware/libhardware/include/hardware/gralloc.h中，如下所示：

/**
 * Name of the graphics device to open
 */

#define GRALLOC_HARDWARE_GPU0 "gpu0"

gralloc设备使用结构体alloc_device_t 来描述。结构体alloc_device_t有两个成员函数alloc和free，分别用来分配和释放图形缓冲区。
结构体alloc_device_t 也是定义在文件hardware/libhardware/include/hardware/gralloc.h中，如下所示：

typedef struct alloc_device_t {  
    struct hw_device_t common;  
  
    int (*alloc)(struct alloc_device_t* dev,  
            int w, int h, int format, int usage,  
            buffer_handle_t* handle, int* stride);  
  
    int (*free)(struct alloc_device_t* dev,  
            buffer_handle_t handle);  
  
} alloc_device_t;

Gralloc模块在在文件hardware/libhardware/include/hardware/gralloc.h中定义了一个帮助函数gralloc_open，用来打开gralloc设备，如下所示：

/** convenience API for opening and closing a supported device */

static inline int gralloc_open(const struct hw_module_t* module, 
        struct alloc_device_t** device) {
    return module->methods->open(module, 
            GRALLOC_HARDWARE_GPU0, (struct hw_device_t**)device);
}

参数module指向的是一个用来描述Gralloc模块的hw_module_t结构体，它的成员变量methods所指向的一个hw_module_methods_t结构体的成员函数open指向了Gralloc模块中的函数gralloc_device_open。

函数gralloc_device_open定义在文件hardware/libhardware/modules/gralloc/gralloc.cpp文件中，如下所示：

struct gralloc_context_t {  
    alloc_device_t  device;  
    /* our private data here */  
};  
  
......  
  
int gralloc_device_open(const hw_module_t* module, const char* name,  
        hw_device_t** device)  
{  
    int status = -EINVAL;  
    if (!strcmp(name, GRALLOC_HARDWARE_GPU0)) {  
        gralloc_context_t *dev;  
        dev = (gralloc_context_t*)malloc(sizeof(*dev));  
  
        /* initialize our state here */  
        memset(dev, 0, sizeof(*dev));  
  
        /* initialize the procs */  
        dev->device.common.tag = HARDWARE_DEVICE_TAG;  
        dev->device.common.version = 0;  
        dev->device.common.module = const_cast<hw_module_t*>(module);  
        dev->device.common.close = gralloc_close;  
  
        dev->device.alloc   = gralloc_alloc;  
        dev->device.free    = gralloc_free;  
  
        *device = &dev->device.common;  
        status = 0;  
    }   
    ......  
  
    return status;  
}

这个函数主要是用来创建一个gralloc_context_t结构体，并且对它的成员变量device进行初始化。结构体gralloc_context_t的成员变量device的类型为gralloc_device_t，它用来描述一个gralloc设备。前面提到，gralloc设备是用来分配和释放图形缓冲区的，这是通过调用它的成员函数alloc和free来实现的。从这里可以看出，函数gralloc_device_open所打开的gralloc设备的成员函数alloc和free分别被设置为Gralloc模块中的函数gralloc_alloc和gralloc_free，后面我们再详细分析它们的实现。

至此，gralloc设备的打开过程就分析完成了，接下来我们继续分析fb设备的打开过程。

fb设备的打开过程

在Gralloc模块中，fb设备的ID值定义为GRALLOC_HARDWARE_FB0。GRALLOC_HARDWARE_FB0是一个宏，定义在文件hardware/libhardware/include/hardware/fb.h中，如下所示：

1	#define GRALLOC_HARDWARE_FB0 "fb0"

fb设备使用结构体framebuffer_device_t 来描述。结构体framebuffer_device_t是用来描述系统帧缓冲区的信息，它定义在文件hardware/libhardware/include/hardware/fb.h中，如下所示：

typedef struct framebuffer_device_t {  
    struct hw_device_t common;  
  
    /* flags describing some attributes of the framebuffer */  
    const uint32_t  flags;  
  
    /* dimensions of the framebuffer in pixels */  
    const uint32_t  width;  
    const uint32_t  height;  
  
    /* frambuffer stride in pixels */  
    const int       stride;  
  
    /* framebuffer pixel format */  
    const int       format;  
  
    /* resolution of the framebuffer's display panel in pixel per inch*/  
    const float     xdpi;  
    const float     ydpi;  
  
    /* framebuffer's display panel refresh rate in frames per second */  
    const float     fps;  
  
    /* min swap interval supported by this framebuffer */  
    const int       minSwapInterval;  
  
    /* max swap interval supported by this framebuffer */  
    const int       maxSwapInterval;  
  
    int reserved[8];  
  
    int (*setSwapInterval)(struct framebuffer_device_t* window,  
            int interval);  
  
    int (*setUpdateRect)(struct framebuffer_device_t* window,  
            int left, int top, int width, int height);  
  
    int (*post)(struct framebuffer_device_t* dev, buffer_handle_t buffer);  
  
    int (*compositionComplete)(struct framebuffer_device_t* dev);  
  
    void* reserved_proc[8];  
  
} framebuffer_device_t;

成员变量flags用来记录系统帧缓冲区的标志，目前没有使用这成员变量，它的值被设置为0。
成员变量width和height分别用来描述设备显示屏的宽度和高度，它们是以像素为单位的。
成员变量stride用来描述设备显示屏的一行有多少个像素点。
成员变量format用来描述系统帧缓冲区的像素格式，支持的像素格式主要有HAL_PIXEL_FORMAT_RGBX_8888和HAL_PIXEL_FORMAT_RGB_565两种。HAL_PIXEL_FORMAT_RGBX_8888表示一个像素使用32位来描述，R、G和B分别占8位，另外8位未使用。HAL_PIXEL_FORMAT_RGB_565表示一个像素使用16位来描述，R、G和B分别占5、6和5位。
成员变量xdpi和ydpi分别用来描述设备显示屏在宽度和高度上的密度，即每英寸有多少个像素点。
成员变量fps用来描述设备显示屏的刷新频率，它的单位是帧每秒。
成员变量minSwapInterval和maxSwapInterval用来描述帧缓冲区交换前后两个图形缓冲区的最小和最大时间间隔。
成员变量reserved是保留给将来使用的。
成员函数setSwapInterval用来设置帧缓冲区交换前后两个图形缓冲区的最小和最大时间间隔。
成员函数setUpdateRect用来设置帧缓冲区的更新区域。
成员函数post用来将图形缓冲区buffer的内容渲染到帧缓冲区中去，即显示在设备的显示屏中去。
成员函数compositionComplete用来通知fb设备device，图形缓冲区的组合工作已经完成，目前没有使用这个成员函数。
成员变量reserved是一个函数指针数组，它们是保留给将来使用的。

在结构体framebuffer_device_t的一系列成员函数中，post是最重要的一个成员函数，用户空间的应用程序通过调用这个成员函数就可以在设备的显示屏中渲染指定的画面，后面我们将详细讲这个函数的实现。

Gralloc模块在在文件hardware/libhardware/include/hardware/fb.h中定义了一个帮助函数framebuffer_open，用来打开fb设备，如下所示：

/** convenience API for opening and closing a supported device */

static inline int framebuffer_open(const struct hw_module_t* module,
        struct framebuffer_device_t** device) {
    return module->methods->open(module,
            GRALLOC_HARDWARE_FB0, (struct hw_device_t**)device);
}

参数module指向的是一个用来描述Gralloc模块的hw_module_t结构体，前面提到，它的成员变量methods所指向的一个hw_module_methods_t结构体的成员函数open指向了Gralloc模块中的函数gralloc_device_open，这个函数打开fb设备的代码段如下所示：

int gralloc_device_open(const hw_module_t* module, const char* name,  
        hw_device_t** device)  
{  
    int status = -EINVAL;  
    if (!strcmp(name, GRALLOC_HARDWARE_GPU0)) {  
        ......  
    } else {  
        status = fb_device_open(module, name, device);  
    }  
    return status;  
}

参数name的值等于GRALLOC_HARDWARE_FB0，因此，函数gralloc_device_open接下来会调用另外一个函数fb_device_open来执行打开fb设备的操作。

函数fb_device_open定义在文件hardware/libhardware/modules/gralloc/framebuffer.cpp中，如下所示：

struct fb_context_t {  
    framebuffer_device_t  device;  
};  
  
......  
  
int fb_device_open(hw_module_t const* module, const char* name,  
        hw_device_t** device)  
{  
    int status = -EINVAL; 
    //判断打开的是fb设备  
    if (!strcmp(name, GRALLOC_HARDWARE_FB0)) {  
        alloc_device_t* gralloc_device;  
        //打开gpu设备 
        status = gralloc_open(module, &gralloc_device);  
        if (status < 0)  
            return status;  
  
        /* initialize our state here */  
        //创建一个fb_context_t对象，用来描述fb设备上下文  
        fb_context_t *dev = (fb_context_t*)malloc(sizeof(*dev));  
        memset(dev, 0, sizeof(*dev));  
  
        /* initialize the procs */  
        //初始化fb_context_t对象  
        dev->device.common.tag = HARDWARE_DEVICE_TAG;  
        dev->device.common.version = 0;  
        dev->device.common.module = const_cast<hw_module_t*>(module);  
        //注册fb设备的操作函数 
        dev->device.common.close = fb_close;  
        dev->device.setSwapInterval = fb_setSwapInterval;  
        dev->device.post            = fb_post;  
        dev->device.setUpdateRect = 0;  
  
        private_module_t* m = (private_module_t*)module;  
        //将fb映射到当前进程地址空间 
        status = mapFrameBuffer(m);  
        if (status >= 0) {  
            int stride = m->finfo.line_length / (m->info.bits_per_pixel >> 3);  
            int format = (m->info.bits_per_pixel == 32)  
                         ? HAL_PIXEL_FORMAT_RGBX_8888  
                         : HAL_PIXEL_FORMAT_RGB_565;  
#ifdef NO_32BPP  
            format = HAL_PIXEL_FORMAT_RGB_565;  
#endif  
            const_cast<uint32_t&>(dev->device.flags) = 0;  
            const_cast<uint32_t&>(dev->device.width) = m->info.xres;  
            const_cast<uint32_t&>(dev->device.height) = m->info.yres;  
            const_cast<int&>(dev->device.stride) = stride;  
            const_cast<int&>(dev->device.format) = format;  
            const_cast<float&>(dev->device.xdpi) = m->xdpi;  
            const_cast<float&>(dev->device.ydpi) = m->ydpi;  
            const_cast<float&>(dev->device.fps) = m->fps;  
            const_cast<int&>(dev->device.minSwapInterval) = 1;  
            const_cast<int&>(dev->device.maxSwapInterval) = 1;  
            *device = &dev->device.common;  
        }  
    }  
    return status;  
}

1）这个函数主要是用来创建一个fb_context_t结构体，并且对它的成员变量device进行初始化。结构体fb_context_t的成员变量device的类型为framebuffer_device_t，前面提到，它是用来描述fb设备的。fb设备主要是用来渲染图形缓冲区的，这是通过调用它的成员函数post来实现的。从这里可以看出，函数fb_device_open所打开的fb设备的成员函数post被设置为Gralloc模块中的函数fb_post，后面我们再详细分析它的实现。

2）函数fb_device_open在打开fb设备的过程中，会调用另外一个函数mapFrameBuffer来获得系统帧缓冲区的信息，并且将这些信息保存在参数module所描述的一个private_module_t结构体的各个成员变量中。有了系统帧缓冲区的信息之后，函数fb_device_open接下来就可以对前面所打开的一个fb设备的各个成员变量进行初始化。这些成员变量的含义可以参考前面对结构体framebuffer_device_t的介绍。接下来我们只简单介绍一下结构体framebuffer_device_t的成员变量stride和format的初始化过程。

3）变量m的成员变量finfo的类型为fb_fix_screeninfo，它是在函数mapFrameBuffer中被始化的。fb_fix_screeninfo是在内核中定义的一个结构体，用来描述设备显示屏的固定属性信息，其中，它的成员变量line_length用来描述显示屏一行像素总共所占用的字节数。
变量m的另外一个成员变量info的类型为fb_var_screeninfo，它也是在函数mapFrameBuffer中被始化的。fb_var_screeninfo也是内核中定义的一个结构体，用来描述可以动态设置的显示屏属性信息，其中，它的成员变量bits_per_pixel用来描述显示屏每一个像素所占用的位数。
这样，我们将m->info.bits_per_pixel的值向右移3位，就可以得到显示屏每一个像素所占用的字节数。用显示屏每一个像素所占用的字节数去除显示屏一行像素总共所占用的字节数m->finfo.line_length，就可以得到显示屏一行有多少个像素点。这个值最终就可以保存在前面所打开的fb设备的成员变量stride中。
当显示屏每一个像素所占用的位数等于32的时候，那么前面所打开的fb设备的像素格式format就会被设置为HAL_PIXEL_FORMAT_RGBX_8888，否则的话，就会被设置为HAL_PIXEL_FORMAT_RGB_565。另一方面，如果在编译的时候定义了NO_32BPP宏，即不要使用32位来描述一个像素，那么函数fb_device_open就会强制将前面所打开的fb设备的像素格式format设置为HAL_PIXEL_FORMAT_RGB_565。

3）函数mapFrameBuffer除了用来获得系统帧缓冲区的信息之外，还会将系统帧缓冲区映射到当前进程的地址空间来。在Android系统中，Gralloc模块中的fb设备是由SurfaceFlinger服务来负责打开和管理的，而SurfaceFlinger服是运行System进程中的，因此，系统帧缓冲区实际上是映射到System进程的地址空间中的。

函数mapFrameBuffer实现在文件hardware/libhardware/modules/gralloc/framebuffer.cpp，如下所示：

static int mapFrameBuffer(struct private_module_t* module)
{
    pthread_mutex_lock(&module->lock);
    int err = mapFrameBufferLocked(module);
    pthread_mutex_unlock(&module->lock);
    return err;
}

这个函数调用了同一个文件中的另外一个函数mapFrameBufferLocked来初始化参数module以及将系统帧缓冲区映射到当前进程的地址空间来。

映射内存过程

函数mapFrameBufferLocked的实现比较长，我们分段来阅读：
Part.1：

int mapFrameBufferLocked(struct private_module_t* module)  
{  
    // already initialized...  
    if (module->framebuffer) {  
        return 0;  
    }  
  
    char const * const device_template[] = {  
            "/dev/graphics/fb%u",  
            "/dev/fb%u",  
            0 };  
  
    int fd = -1;  
    int i=0;  
    char name[64];  
  
    while ((fd==-1) && device_template[i]) {  
        snprintf(name, 64, device_template[i], 0);  
        fd = open(name, O_RDWR, 0);  
        i++;  
    }  
    if (fd < 0)  
        return -errno;

    ...... 
}

这段代码在首先在系统中检查是否存在设备文件/dev/graphics/fb0或者/dev/fb0。如果存在的话，那么就调用函数open来打开它，并且将得到的文件描述符保存在变量fd中。这样，接下来函数mapFrameBufferLocked就可以通过文件描述符fd来与内核中的帧缓冲区驱动程序交互。

Part.2：

int mapFrameBufferLocked(struct private_module_t* module)
{
    ...Part.1...
    
    struct fb_fix_screeninfo finfo;
    if (ioctl(fd, FBIOGET_FSCREENINFO, &finfo) == -1)
        return -errno;

    struct fb_var_screeninfo info;
    if (ioctl(fd, FBIOGET_VSCREENINFO, &info) == -1)
        return -errno;

    ......
}

这几行代码分别通过IO控制命令FBIOGET_FSCREENINFO和FBIOGET_VSCREENINFO来获得系统帧缓冲区的信息，分别保存在fb_fix_screeninfo结构体finfo和fb_var_screeninfo结构体info中。

Part.3：

int mapFrameBufferLocked(struct private_module_t* module)
{
    ...Part.1...
    ...Part.2...
    
    info.reserved[0] = 0;
    info.reserved[1] = 0;
    info.reserved[2] = 0;
    info.xoffset = 0;
    info.yoffset = 0;
    info.activate = FB_ACTIVATE_NOW;

    /*
     * Request NUM_BUFFERS screens (at lest 2 for page flipping)
     */
    info.yres_virtual = info.yres * NUM_BUFFERS;


    uint32_t flags = PAGE_FLIP;
#if USE_PAN_DISPLAY  // 0
    if (ioctl(fd, FBIOPAN_DISPLAY, &info) == -1) {
        ALOGW("FBIOPAN_DISPLAY failed, page flipping not supported");
#else
    if (ioctl(fd, FBIOPUT_VSCREENINFO, &info) == -1) {
        ALOGW("FBIOPUT_VSCREENINFO failed, page flipping not supported");
#endif
        info.yres_virtual = info.yres;
        flags &= ~PAGE_FLIP;
    }

    if (info.yres_virtual < info.yres * 2) {
        // we need at least 2 for page-flipping
        info.yres_virtual = info.yres;
        flags &= ~PAGE_FLIP;
        ALOGW("page flipping not supported (yres_virtual=%d, requested=%d)",
                info.yres_virtual, info.yres*2);
    }

    ......
}

这段代码主要是用来设置设备显示屏的虚拟分辨率。结构体fb_var_screeninfo的成员变量xres和yres用来描述显示屏的可视分辨率，而成员变量xres_virtual和yres_virtual用来描述显示屏的虚拟分辨率。这里保持可视分辨率以及虚拟分辨率的宽度值不变，而将虚拟分辨率的高度值设置为可视分辨率的高度值的NUM_BUFFERS倍。NUM_BUFFERS是一个宏，它的值被定义为2。这样，我们就可以将系统帧缓冲区划分为两个图形缓冲区来使用，即可以通过硬件来实现双缓冲技术。
在结构体fb_var_screeninfo中，与显示屏的可视分辨率和虚拟分辨率相关的另外两个成员变量是xoffset和yoffset，它们用来告诉帧缓冲区当前要渲染的图形缓冲区是哪一个。

这段代码最终是通过IO控制命令FBIOPUT_VSCREENINFO来设置设备显示屏的虚拟分辨率以及像素格式的。如果设置失败，即调用函数ioctl的返回值等于-1，那么很可能是因为系统帧缓冲区在硬件上不支持双缓冲，因此，接下来的代码就会重新将显示屏的虚拟分辨率的高度值设置为可视分辨率的高度值，并且将变量flags的PAGE_FLIP位置为0。
另一方面，如果调用函数ioctl成功，但是最终获得的显示屏的虚拟分辨率的高度值小于可视分辨率的高度值的2倍，那么也说明系统帧缓冲区在硬件上不支持双缓冲。在这种情况下，接下来的代码也会重新将显示屏的虚拟分辨率的高度值设置为可视分辨率的高度值，并且将变量flags的PAGE_FLIP位置为0。

Part.4：

int mapFrameBufferLocked(struct private_module_t* module)
{
    ...Part.1...
    ...Part.2...
    ...Part.3...
    
if (ioctl(fd, FBIOGET_VSCREENINFO, &info) == -1)  
    return -errno;  
  
uint64_t  refreshQuotient =  
(  
        uint64_t( info.upper_margin + info.lower_margin + info.yres )  
        * ( info.left_margin  + info.right_margin + info.xres )  
        * info.pixclock  
);  
  
/* Beware, info.pixclock might be 0 under emulation, so avoid a 
 * division-by-0 here (SIGFPE on ARM) */  
int refreshRate = refreshQuotient > 0 ? (int)(1000000000000000LLU / refreshQuotient) : 0;  
  
if (refreshRate == 0) {  
    // bleagh, bad info from the driver  
    refreshRate = 60*1000;  // 60 Hz  
}  

    ......
}

这段代码再次通过IO控制命令FBIOGET_VSCREENINFO来获得系统帧缓冲区的可变属性信息，并且保存在fb_var_screeninfo结构体info中，接下来再计算设备显示屏的刷新频率。

显示屏的刷新频率与显示屏的扫描时序相关。显示屏的扫描时序可以参考Kernel代码目录下的Documentation/fb/framebuffer.txt文件。我们结合这个txt文件中的一幅图来简单说明上述代码是如何计算显示屏的刷新频率的：

中间由xres和yres组成的区域即为显示屏的图形绘制区，在绘制区的上、下、左和右分别有四个边距upper_margin、lower_margin、left_margin和right_margin。此外，在显示屏的最右边以及最下边还有一个水平同步区域hsync_len和一个垂直同步区域vsync_len。电子枪按照从左到右、从上到下的顺序来显示屏中打点，从而可以将要渲染的图形显示在屏幕中。前面所提到的区域信息分别保存在fb_var_screnninfo结构体info的成员变量xres、yres、upper_margin、lower_margin、left_margin、right_margin、hsync_len和vsync_len。

电子枪每在xres和yres所组成的区域中打一个点所花费的时间记录在fb_var_screnninfo结构体info的成员变量pixclock，单位为pico seconds，即10E-12秒。

电子枪从左到右扫描完成一行之后，都会处理关闭状态，并且会重新折回到左边去。由于电子枪在从右到左折回的过程中不需要打点，因此，这个过程会比从左到右扫描屏幕的过程要快，这个折回的时间大概就等于在xres和yres所组成的区域扫描（left_margin+right_margin）个点的时间。这样，我们就可以认为每渲染一行需要的时间为（xres + left_margin + right_margin）* pixclock。

同样，电子枪从上到下扫描完成显示屏之后，需要从右下角折回到左上角去，折回的时间大概等于在xres和yres所组成的区域中扫描（upper_margin + lower_margin）行所需要的时间。这样，我们就可以认为每渲染一屏图形所需要的时间等于在xres和yres所组成的区域中扫描（yres + upper_margin + lower_margin）行所需要的时间。由于在xres和yres所组成的区域中扫描一行所需要的时间为（xres + left_margin + right_margin） pixclock，因此，每渲染一屏图形所需要的总时间就等于（yres + upper_margin + lower_margin） （xres + left_margin + right_margin）* pixclock。

每渲染一屏图形需要的总时间经过计算之后，就保存在变量refreshQuotient中。注意，变量refreshQuotient所描述的时间的单位为1E-12秒。这样，将变量refreshQuotient的值倒过来，就可以得到设备显示屏的刷新频率。将这个频率值乘以10E15次方之后，就得到一个单位为10E-3 HZ的刷新频率，保存在变量refreshRate中。

当Android系统在模拟器运行的时候，保存在fb_var_screnninfo结构体info的成员变量pixclock中的值可能等于0。在这种情况下，前面计算得到的变量refreshRate的值就会等于0。在这种情况下，接下来的代码会将变量refreshRate的值设置为60 1000 10E-3 HZ，即将显示屏的刷新频率设置为60HZ。

Part.5：

int mapFrameBufferLocked(struct private_module_t* module)
{
    ...Part.1...
    ...Part.2...
    ...Part.3...
    ...Part.4...
    
if (int(info.width) <= 0 || int(info.height) <= 0) {  
    // the driver doesn't return that information  
    // default to 160 dpi  
    info.width  = ((info.xres * 25.4f)/160.0f + 0.5f);  
    info.height = ((info.yres * 25.4f)/160.0f + 0.5f);  
}  
  
float xdpi = (info.xres * 25.4f) / info.width;  
float ydpi = (info.yres * 25.4f) / info.height;  
float fps  = refreshRate / 1000.0f; 

    ......
}

这段代码首先计算显示屏的密度，即每英寸有多少个像素点，分别宽度和高度两个维度，分别保存在变量xdpi和ydpi中。注意，fb_var_screeninfo结构体info的成员变量width和height用来描述显示屏的宽度和高度，它们是以毫米（mm）为单位的。
这段代码接着再将前面计算得到的显示屏刷新频率的单位由10E-3 HZ转换为HZ，即帧每秒，并且保存在变量fps中。

Part.6：

int mapFrameBufferLocked(struct private_module_t* module)
{
    ...Part.1...
    ...Part.2...
    ...Part.3...
    ...Part.4...
    ...Part.5...
    
if (ioctl(fd, FBIOGET_FSCREENINFO, &finfo) == -1)  
    return -errno;  
  
if (finfo.smem_len <= 0)  
    return -errno;  
  
  
module->flags = flags;  
module->info = info;  
module->finfo = finfo;  
module->xdpi = xdpi;  
module->ydpi = ydpi;  
module->fps = fps;  

    ......
}

这段代码再次通过IO控制命令FBIOGET_FSCREENINFO来获得系统帧缓冲区的固定信息，并且保存在fb_fix_screeninfo结构体finfo中，接下来再使用fb_fix_screeninfo结构体finfo以及前面得到的系统帧缓冲区的其它信息来初始化参数module所描述的一个private_module_t结构体。

Part.7：

int mapFrameBufferLocked(struct private_module_t* module)
{
    ...Part.1...
    ...Part.2...
    ...Part.3...
    ...Part.4...
    ...Part.5...
    ...Part.6...
    
    /* 
     * map the framebuffer 
     */  
  
    int err;  
    size_t fbSize = roundUpToPageSize(finfo.line_length * info.yres_virtual);  
    module->framebuffer = new private_handle_t(dup(fd), fbSize, 0);  
  
    module->numBuffers = info.yres_virtual / info.yres;  
    module->bufferMask = 0;  
  
    void* vaddr = mmap(0, fbSize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);  
    if (vaddr == MAP_FAILED) {  
        LOGE("Error mapping the framebuffer (%s)", strerror(errno));  
        return -errno;  
    }  
    module->framebuffer->base = intptr_t(vaddr);  
    memset(vaddr, 0, fbSize);  
    return 0;  
}

表达式finfo.line_length * info.yres_virtual计算的是整个系统帧缓冲区的大小，它的值等于显示屏行数（虚拟分辨率的高度值，info.yres_virtual）乘以每一行所占用的字节数（finfo.line_length）。函数roundUpToPageSize用来将整个系统帧缓冲区的大小对齐到页面边界。对齐后的大小保存在变量fbSize中。

表达式finfo.yres_virtual / info.yres计算的是整个系统帧缓冲区可以划分为多少个图形缓冲区来使用，这个数值保存在参数module所描述的一个private_module_t结构体的成员变量nmBuffers中。参数module所描述的一个private_module_t结构体的另外一个成员变量bufferMask的值接着被设置为0，表示系统帧缓冲区中的所有图形缓冲区都是处于空闲状态，即它们可以分配出去给应用程序使用。

系统帧缓冲区是通过调用函数mmap来映射到当前进程的地址空间来的。映射后得到的地址空间使用一个private_handle_t结构体来描述，这个结构体的成员变量base保存的即为系统帧缓冲区在当前进程的地址空间中的起始地址。这样，Gralloc模块以后就可以从这块地址空间中分配图形缓冲区给当前进程使用。

至此，fb设备的打开过程就分析完成了。在打开fb设备的过程中，Gralloc模块还完成了对系统帧缓冲区的初始化工作。接下来我们继续分析Gralloc模块是如何分配图形缓冲区给用户空间的应用程序使用的。

分配图形缓冲区

前面提到，用户空间的应用程序用到的图形缓冲区是由Gralloc模块中的函数gralloc_alloc来分配的，这个函数实现在文件hardware/libhardware/modules/gralloc/gralloc.cpp中，如下所示：

static int gralloc_alloc(alloc_device_t* dev,
        int w, int h, int format, int usage,
        buffer_handle_t* pHandle, int* pStride)
{
    if (!pHandle || !pStride)
        return -EINVAL;

    size_t size, stride;

    int align = 4;
    int bpp = 0;
    switch (format) {
        case HAL_PIXEL_FORMAT_RGBA_8888:
        case HAL_PIXEL_FORMAT_RGBX_8888:
        case HAL_PIXEL_FORMAT_BGRA_8888:
            bpp = 4;
            break;
        case HAL_PIXEL_FORMAT_RGB_888:
            bpp = 3;
            break;
        case HAL_PIXEL_FORMAT_RGB_565:
        case HAL_PIXEL_FORMAT_RAW_SENSOR:
            bpp = 2;
            break;
        default:
            return -EINVAL;
    }
    size_t bpr = (w*bpp + (align-1)) & ~(align-1);
    size = bpr * h;
    stride = bpr / bpp;

    int err;
    if (usage & GRALLOC_USAGE_HW_FB) {
        err = gralloc_alloc_framebuffer(dev, size, usage, pHandle);
    } else {
        err = gralloc_alloc_buffer(dev, size, usage, pHandle);
    }

    if (err < 0) {
        return err;
    }

    *pStride = stride;
    return 0;
}

参数format用来描述要分配的图形缓冲区的颜色格式。当format值等于HAL_PIXEL_FORMAT_RGBA_8888、HAL_PIXEL_FORMAT_RGBX_8888或者HAL_PIXEL_FORMAT_BGRA_8888的时候，一个像素需要使用32位来表示，即4个字节。当format值等于HAL_PIXEL_FORMAT_RGB_888的时候，一个像素需要使用24位来描述，即3个字节。当format值等于HAL_PIXEL_FORMAT_RGB_565、HAL_PIXEL_FORMAT_RGBA_5551或者HAL_PIXEL_FORMAT_RGBA_4444的时候，一个像需要使用16位来描述，即2个字节。最终一个像素需要使用的字节数保存在变量bpp中。
参数w表示要分配的图形缓冲区所保存的图像的宽度，将它乘以bpp，就可以得到保存一行像素所需要使用的字节数。我们需要将这个字节数对齐到4个字节边界，最后得到一行像素所需要的字节数就保存在变量bpr中。
参数h表示要分配的图形缓冲区所保存的图像的高度，将它乘以bpr，就可以得到保存整个图像所需要使用的字节数。
将变量bpr的值除以变量bpp的值，就得到要分配的图形缓冲区一行包含有多少个像素点，这个结果需要保存在输出参数pStride中，以便可以返回给调用者。
参数usage用来描述要分配的图形缓冲区的用途。如果是用来在系统帧缓冲区中渲染的，即参数usage的GRALLOC_USAGE_HW_FB位等于1，那么就必须要系统帧缓冲区中分配，否则的话，就在内存中分配。注意，在内存中分配的图形缓冲区，最终是需要拷贝到系统帧缓冲区去的，以便可以将它所描述的图形渲染出来。
函数gralloc_alloc_framebuffer用来在系统帧缓冲区中分配图形缓冲区，而函数gralloc_alloc_buffer用来在内存在分配图形缓冲区，接下来我们就分别分析这两个函数的实现。

系统帧缓冲区中分配图形缓冲区

函数gralloc_alloc_framebuffer实现在文件hardware/libhardware/modules/gralloc/gralloc.cpp中，如下所示：

static int gralloc_alloc_framebuffer(alloc_device_t* dev,
        size_t size, int usage, buffer_handle_t* pHandle)
{
    private_module_t* m = reinterpret_cast<private_module_t*>(
            dev->common.module);
    pthread_mutex_lock(&m->lock);
    int err = gralloc_alloc_framebuffer_locked(dev, size, usage, pHandle);
    pthread_mutex_unlock(&m->lock);
    return err;
}

这个函数调用了另外一个函数gralloc_alloc_framebuffer_locked来分配图形缓冲区。函数gralloc_alloc_framebuffer_locked也是实现在文件hardware/libhardware/modules/gralloc/gralloc.cpp中，如下所示：

static int gralloc_alloc_framebuffer_locked(alloc_device_t* dev,
        size_t size, int usage, buffer_handle_t* pHandle)
{
    private_module_t* m = reinterpret_cast<private_module_t*>(
            dev->common.module);

    // allocate the framebuffer
    if (m->framebuffer == NULL) {
        // initialize the framebuffer, the framebuffer is mapped once
        // and forever.
        int err = mapFrameBufferLocked(m);
        if (err < 0) {
            return err;
        }
    }

    const uint32_t bufferMask = m->bufferMask;
    const uint32_t numBuffers = m->numBuffers;
    const size_t bufferSize = m->finfo.line_length * m->info.yres;
    if (numBuffers == 1) {
        // If we have only one buffer, we never use page-flipping. Instead,
        // we return a regular buffer which will be memcpy'ed to the main
        // screen when post is called.
        int newUsage = (usage & ~GRALLOC_USAGE_HW_FB) | GRALLOC_USAGE_HW_2D;
        return gralloc_alloc_buffer(dev, bufferSize, newUsage, pHandle);
    }

    if (bufferMask >= ((1LU<<numBuffers)-1)) {
        // We ran out of buffers.
        return -ENOMEM;
    }

    // create a "fake" handles for it
    intptr_t vaddr = intptr_t(m->framebuffer->base);
    private_handle_t* hnd = new private_handle_t(dup(m->framebuffer->fd), size,
            private_handle_t::PRIV_FLAGS_FRAMEBUFFER);

    // find a free slot
    for (uint32_t i=0 ; i<numBuffers ; i++) {
        if ((bufferMask & (1LU<<i)) == 0) {
            m->bufferMask |= (1LU<<i);
            break;
        }
        vaddr += bufferSize;
    }
    
    hnd->base = vaddr;
    hnd->offset = vaddr - intptr_t(m->framebuffer->base);
    *pHandle = hnd;

    return 0;
}

在系统帧缓冲区分配图形缓冲区之前，首先要对系统帧缓冲区进行过初始化，即这里的变量m所指向的一个private_module_t结构体的成员变量framebuffer的值不能等于NULL。如果等于NULL的话，那么就必须要调用另外一个函数mapFrameBufferLocked来初始化系统帧缓冲区。初始化系统帧缓冲区的过程可以参考前面的内容。

变量bufferMask用来描述系统帧缓冲区的使用情况，而变量numBuffers用来描述系统帧缓冲区可以划分为多少个图形缓冲区来使用，另外一个变量bufferSize用来描述设备显示屏一屏内容所占用的内存的大小。

如果系统帧缓冲区只有一个图形缓冲区大小，即变量numBuffers的值等于1，那么这个图形缓冲区就始终用作系统主图形缓冲区来使用。在这种情况下，我们就不能够在系统帧缓冲区中分配图形缓冲区来给用户空间的应用程序使用，因此，这时候就会转向内存中来分配图形缓冲区，即调用函数gralloc_alloc_buffer来分配图形缓冲区。注意，这时候分配的图形缓冲区的大小为一屏内容的大小，即bufferSize。

如果bufferMask的值大于等于((1LU<<numBuffers)-1)的值，那么就说明系统帧缓冲区中的图形缓冲区全部都分配出去了，这时候分配图形缓冲区就失败了。例如，假设图形缓冲区的个数为2，那么((1LU<<numBuffers)-1)的值就等于3，即二制制0x11。如果这时候bufferMask的值也等于0x11，那么就表示第一个和第二个图形缓冲区都已经分配出去了。因此，这时候就不能再在系统帧缓冲区中分配图形缓冲区。

假设此时系统帧缓冲区中尚有空闲的图形缓冲区的，接下来函数就会创建一个private_handle_t结构体hnd来描述这个即将要分配出去的图形缓冲区。注意，这个图形缓冲区的标志值等于PRIV_FLAGS_FRAMEBUFFER，即表示这是一块在系统帧缓冲区中分配的图形缓冲区。

接下来的for循环从低位到高位检查变量bufferMask的值，并且找到第一个值等于0的位，这样就可以知道在系统帧缓冲区中，第几个图形缓冲区的是空闲的。注意，变量vadrr的值开始的时候指向系统帧缓冲区的基地址，在下面的for循环中，每循环一次它的值都会增加bufferSize。从这里就可以看出，每次从系统帧缓冲区中分配出去的图形缓冲区的大小都是刚好等于显示屏一屏内容大小的。

最后分配出去的图形缓冲区的开始地址就保存在前面所创建的private_handle_t结构体hnd的成员变量base中，这样，用户空间的应用程序就可以直接将要渲染的图形内容拷贝到这个地址上去，这就相当于是直接将图形渲染到系统帧缓冲区中去。

在将private_handle_t结构体hnd返回给调用者之前，还需要设置它的成员变量offset，以便可以知道它所描述的图形缓冲区的起始地址相对于系统帧缓冲区的基地址的偏移量。

至此，在系统帧缓冲区中分配图形缓冲区的过程就分析完成了，接下来我们再分析在内存在分析图形缓冲区的过程，即分析函数gralloc_alloc_buffer的实现。

内存中分配图形缓冲区

函数gralloc_alloc_buffer也是实现在文件hardware/libhardware/modules/gralloc/gralloc.cpp中，如下所示：

 static int gralloc_alloc_buffer(alloc_device_t* dev,  
        size_t size, int usage, buffer_handle_t* pHandle)  
{  
    int err = 0;  
    int fd = -1;  
  
    size = roundUpToPageSize(size);  
  
    fd = ashmem_create_region("gralloc-buffer", size);  
    if (fd < 0) {  
        LOGE("couldn't create ashmem (%s)", strerror(-errno));  
        err = -errno;  
    }  
  
    if (err == 0) {  
        private_handle_t* hnd = new private_handle_t(fd, size, 0);  
        gralloc_module_t* module = reinterpret_cast<gralloc_module_t*>(  
                dev->common.module);  
        err = mapBuffer(module, hnd);  
        if (err == 0) {  
            *pHandle = hnd;  
        }  
    }  
  
    LOGE_IF(err, "gralloc failed err=%s", strerror(-err));  
  
    return err;  
}

这个函数的实现很简单，它首先调用函数ashmem_create_region来创建一块匿名共享内存，接着再在这块匿名共享内存上分配一个图形缓冲区。注意，这个图形缓冲区也是使用一个private_handle_t结构体来描述的，不过这个图形缓冲区的标志值等于0，以区别于在系统帧缓冲区中分配的图形缓冲区。匿名共享内存的知识还没有入坑，以后再看。。。。。。

从匿名共享内存中分配的图形缓冲区还需要映射到进程的地址空间来，然后才可以使用，这是通过调用函数mapBuffer来实现的。

函数mapBuffer实现在文件hardware/libhardware/modules/gralloc/mapper.cpp中，如下所示：

int mapBuffer(gralloc_module_t const* module,
        private_handle_t* hnd)
{
    void* vaddr;
    return gralloc_map(module, hnd, &vaddr);
}

它通过调用另外一个函数gralloc_map来将参数hnd所描述的一个图形缓冲区映射到当前进程的地址空间来。后面在分析图形缓冲区的注册过程时，我们再分析函数gralloc_map的实现。

注意，在Android系统中，在系统帧缓冲区中分配的图形缓冲区是在SurfaceFlinger服务中使用的，而在内存中分配的图形缓冲区既可以在SurfaceFlinger服务中使用，也可以在其它的应用程序中使用。当其它的应用程序需要使用图形缓冲区的时候，它们就会请求SurfaceFlinger服务为它们分配，因此，对于其它的应用程序来说，它们只需要将SurfaceFlinger服务返回来的图形缓冲区映射到自己的进程地址空间来使用就可以了，这就是后面我们所要分析的图形缓冲区的注册过程。

至此，图形缓冲区的分配过程就分析完成了，接下来我们继续分析图形缓冲区的释放过程。

图形缓冲区的释放过程

前面提到，用户空间的应用程序用到的图形缓冲区是由Gralloc模块中的函数gralloc_free来释放的，这个函数实现在文件hardware/libhardware/modules/gralloc/gralloc.cpp中，如下所示：

static int gralloc_free(alloc_device_t* dev,
        buffer_handle_t handle)
{
    if (private_handle_t::validate(handle) < 0)
        return -EINVAL;

    private_handle_t const* hnd = reinterpret_cast<private_handle_t const*>(handle);
    if (hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER) {
        // free this buffer
        private_module_t* m = reinterpret_cast<private_module_t*>(
                dev->common.module);
        const size_t bufferSize = m->finfo.line_length * m->info.yres;
        int index = (hnd->base - m->framebuffer->base) / bufferSize;
        m->bufferMask &= ~(1<<index); 
    } else { 
        gralloc_module_t* module = reinterpret_cast<gralloc_module_t*>(
                dev->common.module);
        terminateBuffer(module, const_cast<private_handle_t*>(hnd));
    }

    close(hnd->fd);
    delete hnd;
    return 0;
}

要释放的图形缓冲区使用参数handle来描述。前面提到，从Gralloc模块中分配的图形缓冲区是使用private_handle_t结构体来描述的，因此，这里的参数handle应该指向一个private_handle_t结构体，这是通过调用private_handle_t类的静态成员函数validate来验证的。private_handle_t类的静态成员函数validate的实现可以参考前面的内容。

要释放的图形缓冲区有可能是在系统帧缓冲区分配的，也有可能是在内存中分配的，这可以通过检查它的标志值flags的PRIV_FLAGS_FRAMEBUFFER位是否等于1来确认。

如果要释放的图形缓冲区是在系统帧缓冲区中分配的，那么首先要知道这个图形缓冲区是系统帧缓冲区的第index个位置，接着再将变量m所描述的一个private_module_t结构体的成员变量bufferMask的第index位重置为0即可。我们只需要将要释放的图形缓冲区的开始地址减去系统帧缓冲区的基地址，再除以一个图形缓冲区的大小，就可以知道要释放的图形缓冲区是系统帧缓冲区的第几个位置。这个过程刚好是在系统帧缓冲区中分配图形缓冲区的逆操作。

如果要释放的图形缓冲区是内存中分配的，那么只需要调用另外一个函数terminateBuffer来解除要释放的图形缓冲区在当前进程的地址空间中的映射。

最后，这个函数还会将用来描述要释放的图形缓冲区的private_handle_t结构体所占用的内存释放掉，并且将要要释放的图形缓冲区所在的系统帧缓冲区或者匿名共享内存的文件描述符关闭掉。

函数terminateBuffer实现在文件hardware/libhardware/modules/gralloc/mapper.cpp中，如下所示：

int terminateBuffer(gralloc_module_t const* module,  
        private_handle_t* hnd)  
{  
    if (hnd->base) {  
        // this buffer was mapped, unmap it now  
        gralloc_unmap(module, hnd);  
    }  
  
    return 0;  
}

它通过调用另外一个函数gralloc_unmap来解除参数hnd所描述的一个图形缓冲区在当前进程的地址空间中的映射。后面在分析图形缓冲区的注销过程时，我们再详细分析函数gralloc_unmap的实现。

至此，图形缓冲区的释放过程就分析完成了，接下来我们继续分析图形缓冲区的注册过程。

图形缓冲区的注册过程

前面提到，在Android系统中，所有的图形缓冲区都是由SurfaceFlinger服务分配的，而当一个图形缓冲区被分配的时候，它会同时被映射到请求分配的进程的地址空间去，即分配的过程同时也包含了注册的过程。但是对用户空间的其它的应用程序来说，它们所需要的图形缓冲区是在由SurfaceFlinger服务分配的，因此，当它们得到SurfaceFlinger服务分配的图形缓冲区之后，还需要将这块图形缓冲区映射到自己的地址空间来，以便可以使用这块图形缓冲区。这个映射的过程即为我们接下来要分析的图形缓冲区注册过程。

前面还提到，注册图形缓冲区的操作是由Gralloc模块中的函数gralloc_register_buffer来实现的，这个函数实现在文件hardware/libhardware/modules/gralloc/mapper.cpp中，如下所示：

int gralloc_register_buffer(gralloc_module_t const* module,  
        buffer_handle_t handle)  
{  
    if (private_handle_t::validate(handle) < 0)  
        return -EINVAL;  
  
    // if this handle was created in this process, then we keep it as is.  
    int err = 0;  
    private_handle_t* hnd = (private_handle_t*)handle;  
    if (hnd->pid != getpid()) {  
        void *vaddr;  
        err = gralloc_map(module, handle, &vaddr);  
    }  
    return err;  
}

这个函数首先验证参数handle指向的一块图形缓冲区的确是由Gralloc模块分配的，方法是调用private_handle_t类的静态成员函数validate来验证，即如果参数handle指向的是一个private_handle_t结构体，那么它所指向的一块图形缓冲区就是由Gralloc模块分配的。

通过了上面的检查之后，函数gralloc_register_buffer还需要检查当前进程是否就是请求Gralloc模块分配图形缓冲区hnd的进程。如果是的话，那么当前进程在请求Gralloc模块分配图形缓冲区hnd的时候，就已经将图形缓冲区hnd映射进自己的地址空间来了，因此，这时候就不需要重复在当前进程中注册这个图形缓冲区。

真正执行注册图形缓冲区的操作是由函数gralloc_map来实现的，这个函数也是实现文件hardware/libhardware/modules/gralloc/mapper.cpp中，如下所示：

static int gralloc_map(gralloc_module_t const* module,  
        buffer_handle_t handle,  
        void** vaddr)  
{  
    private_handle_t* hnd = (private_handle_t*)handle;  
    if (!(hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER)) {  
        size_t size = hnd->size;  
        void* mappedAddress = mmap(0, size,  
                PROT_READ|PROT_WRITE, MAP_SHARED, hnd->fd, 0);  
        if (mappedAddress == MAP_FAILED) {  
            LOGE("Could not mmap %s", strerror(errno));  
            return -errno;  
        }  
        hnd->base = intptr_t(mappedAddress) + hnd->offset;  
        //LOGD("gralloc_map() succeeded fd=%d, off=%d, size=%d, vaddr=%p",  
        //        hnd->fd, hnd->offset, hnd->size, mappedAddress);  
    }  
    *vaddr = (void*)hnd->base;  
    return 0;  
}

由于在系统帧缓冲区中分配的图形缓冲区只在SurfaceFlinger服务中使用，而SurfaceFlinger服务在初始化系统帧缓冲区的时候，已经将系统帧缓冲区映射到自己所在的进程中来了，因此，函数gralloc_map如果发现要注册的图形缓冲区是在系统帧缓冲区分配的时候，那么就不需要再执行映射图形缓冲区的操作了。

如果要注册的图形缓冲区是在内存中分配的，即它的标志值flags的PRIV_FLAGS_FRAMEBUFFER位等于1，那么接下来就需要将它映射到当前进程的地址空间来了。由于要注册的图形缓冲区是在文件描述符hnd->fd所描述的一块匿名共享内存中分配的，因此，我们只需要将文件描述符hnd->fd所描述的一块匿名共享内存映射到当前进程的地址空间来，就可以将参数hnd所描述的一个图形缓冲区映射到当前进程的地址空间来。

由于映射文件描述符hnd->fd得到的是一整块匿名共享内存在当前进程地址空间的基地址，而要注册的图形缓冲区可能只占据这块匿名共享内存的某一小部分，因此，我们还需要将要注册的图形缓冲区的在被映射的匿名共享内存中的偏移量hnd->offset加上被映射的匿名共享内存的基地址hnd->base，才可以得到要注册的图形缓冲区在当前进程中的访问地址，这个地址最终又被写入到hnd->base中去。

注册图形缓冲区的过程就是这么简单，接下来我们再分析图形缓冲区的注销过程。

图形缓冲区的注销过程

图形缓冲区使用完成之后，就需要从当前进程中注销。前面提到，注销图形缓冲区是由Gralloc模块中的函数gralloc_unregister_buffer来实现的，这个函数实现在文件hardware/libhardware/modules/gralloc/mapper.cpp中，如下所示：

int gralloc_unregister_buffer(gralloc_module_t const* module,  
        buffer_handle_t handle)  
{  
    if (private_handle_t::validate(handle) < 0)  
        return -EINVAL;  
  
    // never unmap buffers that were created in this process  
    private_handle_t* hnd = (private_handle_t*)handle;  
    if (hnd->pid != getpid()) {  
        if (hnd->base) {  
            gralloc_unmap(module, handle);  
        }  
    }  
    return 0;  
}

这个函数同样是首先调用private_handle_t类的静态成员函数validate来验证参数handle指向的一块图形缓冲区的确是由Gralloc模块分配的，接着再将将参数handle指向的一块图形缓冲区转换为一个private_handle_t结构体hnd来访问。

一块图形缓冲区只有被注册过，即被Gralloc模块中的函数gralloc_register_buffer注册过，才需要注销，而由函数gralloc_register_buffer注册的图形缓冲区都不是由当前进程分配的，因此，当前进程在注销一个图形缓冲区的时候，会检查要注销的图形缓冲区是否是由自己分配的。如果是由自己分配的话，那么它什么也不做就返回了。

假设要注销的图形缓冲区hnd不是由当前进程分配的，那么接下来就会调用另外一个函数galloc_unmap来注销图形缓冲区hnd。函数galloc_unmap也是实现在文件hardware/libhardware/modules/gralloc/mapper.cpp中，如下所示：

static int gralloc_unmap(gralloc_module_t const* module,  
        buffer_handle_t handle)  
{  
    private_handle_t* hnd = (private_handle_t*)handle;  
    if (!(hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER)) {  
        void* base = (void*)hnd->base;  
        size_t size = hnd->size;  
        //LOGD("unmapping from %p, size=%d", base, size);  
        if (munmap(base, size) < 0) {  
            LOGE("Could not unmap %s", strerror(errno));  
        }  
    }  
    hnd->base = 0;  
    return 0;  
}

这个函数的实现与前面所分析的函数gralloc_map的实现是类似的，只不过它执行的是相反的操作，即将解除一个指定的图形缓冲区在当前进程的地址空间中的映射，从而完成对这个图形缓冲区的注销工作。

这样，图形缓冲区的注销过程就分析完成了，接下来我们再继续分析一个图形缓冲区是如何被渲染到系统帧缓冲区去的，即它的内容是如何绘制在设备显示屏中的。

图形缓冲区的渲染过程

用户空间的应用程序将画面内容写入到图形缓冲区中去之后，还需要将图形缓冲区渲染到系统帧缓冲区中去，这样才可以把画面绘制到设备显示屏中去。前面提到，渲染图形缓冲区是由Gralloc模块中的函数fb_post来实现的，这个函数实现在文件hardware/libhardware/modules/gralloc/framebuffer.cpp中，如下所示：

static int fb_post(struct framebuffer_device_t* dev, buffer_handle_t buffer)  
{  
    if (private_handle_t::validate(buffer) < 0)  
        return -EINVAL;  
  
    fb_context_t* ctx = (fb_context_t*)dev;  
  
    private_handle_t const* hnd = reinterpret_cast<private_handle_t const*>(buffer);  
    private_module_t* m = reinterpret_cast<private_module_t*>(  
            dev->common.module);  
  
    if (hnd->flags & private_handle_t::PRIV_FLAGS_FRAMEBUFFER) {  
        const size_t offset = hnd->base - m->framebuffer->base;  
        m->info.activate = FB_ACTIVATE_VBL;  
        m->info.yoffset = offset / m->finfo.line_length;  
        if (ioctl(m->framebuffer->fd, FBIOPUT_VSCREENINFO, &m->info) == -1) {  
            LOGE("FBIOPUT_VSCREENINFO failed");  
            m->base.unlock(&m->base, buffer);  
            return -errno;  
        }  
        m->currentBuffer = buffer;  
  
    } else {  
        // If we can't do the page_flip, just copy the buffer to the front   
        // FIXME: use copybit HAL instead of memcpy  
  
        void* fb_vaddr;  
        void* buffer_vaddr;  
  
        m->base.lock(&m->base, m->framebuffer,  
                GRALLOC_USAGE_SW_WRITE_RARELY,  
                0, 0, m->info.xres, m->info.yres,  
                &fb_vaddr);  
  
        m->base.lock(&m->base, buffer,  
                GRALLOC_USAGE_SW_READ_RARELY,  
                0, 0, m->info.xres, m->info.yres,  
                &buffer_vaddr);  
  
        memcpy(fb_vaddr, buffer_vaddr, m->finfo.line_length * m->info.yres);  
  
        m->base.unlock(&m->base, buffer);  
        m->base.unlock(&m->base, m->framebuffer);  
    }  
  
    return 0;  
}

1）参数buffer用来描述要渲染的图形缓冲区，它指向的必须要是一个private_handle_t结构体，这是通过调用private_handle_t类的静态成员函数validate来验证的。验证通过之后，就可以将参数buffer所描述的一个buffer_handle_t结构体转换成一个private_handle_t结构体hnd。

参数*dev用来描述在Gralloc模块中的一个fb设备。从前面的内容可以知道，在打开fb设备的时候，Gralloc模块返回给调用者的实际上是一个fb_context_t结构体，因此，这里就可以将参数dev所描述的一个framebuffer_device_t结构体转换成一个fb_context_t结构体ctx。

参数dev的成员变量common指向了一个hw_device_t结构体，这个结构体的成员变量module指向了一个Gralloc模块。从前面的内容可以知道，一个Gralloc模块是使用一个private_module_t结构体来描述的，因此，我们可以将dev->common.moudle转换成一个private_module_t结构体m。

2）由于private_handle_t结构体hnd所描述的图形缓冲区可能是在系统帧缓冲区分配的，也有可能是内存中分配的，因此，我们分两种情况来讨论图形缓冲区渲染过程。

当private_handle_t结构体hnd所描述的图形缓冲区是在系统帧缓冲区中分配的时候，即这个图形缓冲区的标志值flags的PRIV_FLAGS_FRAMEBUFFER位等于1的时候，我们是不需要将图形缓冲区的内容拷贝到系统帧缓冲区去的，因为我们将内容写入到图形缓冲区的时候，已经相当于是将内容写入到了系统帧缓冲区中去了。虽然在这种情况下，我们不需要将图形缓冲区的内容拷贝到系统帧缓冲区去，但是我们需要告诉系统帧缓冲区设备将要渲染的图形缓冲区作为系统当前的输出图形缓冲区，这样才可以将要渲染的图形缓冲区的内容绘制到设备显示屏来。例如，假设系统帧缓冲区有2个图形缓冲区，当前是以第1个图形缓冲区作为输出图形缓冲区的，这时候如果我们需要渲染第2个图形缓冲区，那么就必须告诉系统帧绘冲区设备，将第2个图形缓冲区作为输出图形缓冲区。

设置系统帧缓冲区的当前输出图形缓冲区是通过IO控制命令FBIOPUT_VSCREENINFO来进行的。IO控制命令FBIOPUT_VSCREENINFO需要一个fb_var_screeninfo结构体作为参数。从前面的内容可以知道，private_module_t结构体m的成员变量info正好保存在我们所需要的这个fb_var_screeninfo结构体。有了个m->info这个fb_var_screeninfo结构体之后，我们只需要设置好它的成员变量yoffset的值（不用设置成员变量xoffset的值是因为所有的图形缓冲区的宽度是相等的），就可以将要渲染的图形缓冲区设置为系统帧缓冲区的当前输出图形缓冲区。fb_var_screeninfo结构体的成员变量yoffset保存的是当前输出图形缓冲区在整个系统帧缓冲区的纵向偏移量，即Y偏移量。我们只需要将要渲染的图形缓冲区的开始地址hnd->base的值减去系统帧缓冲区的基地址m->framebuffer->base的值，再除以图形缓冲区一行所占据的字节数m->finfo.line_length，就可以得到所需要的Y偏移量。

在执行IO控制命令FBIOPUT_VSCREENINFO之前，还会将作为参数的fb_var_screeninfo结构体的成员变量activate的值设置FB_ACTIVATE_VBL，表示要等到下一个垂直同步事件出现时，再将当前要渲染的图形缓冲区的内容绘制出来。这样做的目的是避免出现屏幕闪烁，即避免前后两个图形缓冲区的内容各有一部分同时出现屏幕中。

成功地执行完成IO控制命令FBIOPUT_VSCREENINFO之后，函数还会将当前被渲染的图形缓冲区保存在private_module_t结构体m的成员变量currentBuffer中，以便可以记录当前被渲染的图形缓冲区是哪一个。

当private_handle_t结构体hnd所描述的图形缓冲区是在内存中分配的时候，即这个图形缓冲区的标志值flags的PRIV_FLAGS_FRAMEBUFFER位等于0的时候，我们就需要将它的内容拷贝到系统帧缓冲区中去了。这个拷贝的工作是通过调用函数memcpy来完成的。在拷贝之前，我们需要三个参数。第一个参数是要渲染的图形缓冲区的起址地址，这个地址保存在参数buffer所指向的一个private_handle_t结构体中。第二个参数是要系统帧缓冲区的基地址，这个地址保存在private_module_t结构体m的成员变量framebuffer所指向的一个private_handle_t结构体中。第三个参数是要拷贝的内容的大小，这个大小就刚好是一个屏幕像素所占据的内存的大小。屏幕高度由m->info.yres来描述，而一行屏幕像素所占用的字节数由m->finfo.line_length来描述，将这两者相乘，就可以得到一个屏幕像素所占据的内存的大小。

3）在将一块内存缓冲区的内容拷贝到系统帧缓冲区中去之前，需要对这两块缓冲区进行锁定，以保证在拷贝的过程中，这两块缓冲区的内容不会被修改。这个锁定的工作是由Gralloc模块中的函数gralloc_lock来实现的。从前面第1部分的内容可以知道，Gralloc模块中的函数gralloc_lock的地址正好就保存在private_module_t结构体m的成员变量base所描述的一个gralloc_module_t结构体的成员函数lock中。

在调用函数gralloc_lock来锁定一块缓冲区之后，还可以通过最后一个输出参数来获得被锁定的缓冲区的开始地址，因此，通过调用函数gralloc_lock来锁定要渲染的图形缓冲区以及系统帧缓冲区，就可以得到前面所需要的第一个和第二个参数。

将要渲染的图形缓冲区的内容拷贝到系统帧缓冲区之后，就可以解除前面对它们的锁定了，这个解锁的工作是由Gralloc模块中的函数gralloc_unlock来实现的。从前面第1部分的内容可以知道，Gralloc模块中的函数gralloc_unlock的地址正好就保存在private_module_t结构体m的成员变量base所描述的一个gralloc_module_t结构体的成员函数unlock中。

这样，一个图形缓冲区的渲染过程就分析完成了。

图形缓冲区的锁定和解锁

为了完整性起见，最后我们再简要分析函数gralloc_lock和gralloc_unlock的实现，以便可以了解一个图形缓冲区的锁定和解锁操作是如何实现的。

1）图形缓冲区的锁定：
函数gralloc_lock实现在文件hardware/libhardware/modules/gralloc/mapper.cpp文件中，如下所示：

int gralloc_lock(gralloc_module_t const* module,  
        buffer_handle_t handle, int usage,  
        int l, int t, int w, int h,  
        void** vaddr)  
{  
    // this is called when a buffer is being locked for software  
    // access. in thin implementation we have nothing to do since  
    // not synchronization with the h/w is needed.  
    // typically this is used to wait for the h/w to finish with  
    // this buffer if relevant. the data cache may need to be  
    // flushed or invalidated depending on the usage bits and the  
    // hardware.  
  
    if (private_handle_t::validate(handle) < 0)  
        return -EINVAL;  
  
    private_handle_t* hnd = (private_handle_t*)handle;  
    *vaddr = (void*)hnd->base;  
    return 0;  
}

从这里可以看出，函数gralloc_lock其实并没有执行锁定参数handle所描述的一个缓冲区的操作，它只简单地将要锁定的缓冲区的开始地址返回给调用者。

理论上来说，函数gralloc_lock应该检查参数handle所描述的一个缓冲区是否正在被其进程或者线程使用。如果是的话，那么函数gralloc_lock就必须要等待，直到要锁定的缓冲区被其它进程或者线程使用结束为止，以便接下来可以独占它。由于函数gralloc_lock实际上并没有作这些操作，因此，就必须要由调用者来保证要锁定的缓冲区当前是没有被其它进程或者线程使用的。

2）图形缓冲区的解锁：
函数gralloc_unlock也是实现在文件hardware/libhardware/modules/gralloc/mapper.cpp文件中，如下所示：

int gralloc_unlock(gralloc_module_t const* module,  
        buffer_handle_t handle)  
{  
    // we're done with a software buffer. nothing to do in this  
    // implementation. typically this is used to flush the data cache.  
  
    if (private_handle_t::validate(handle) < 0)  
        return -EINVAL;  
    return 0;  
}

函数gralloc_unlock执行的操作本来是刚好与函数gralloc_lock相反的，但是由于函数gralloc_lock并没有真实地锁定参数handle所描述的一个缓冲区的，因此，函数gralloc_unlock是不需要执行实际的解锁工作的。

小结

至此，我们就分析完成Android帧缓冲区硬件抽象层模块Gralloc的实现原理了。从分析的过程可以知道，为了在屏幕中绘制一个指定的画面，我们需要：

分配一个匹配屏幕大小的图形缓冲区
将分配好的图形缓冲区注册（映射）到当前进程的地址空间来
将要绘制的画面的内容写入到已经注册好的图形缓冲区中去，并且渲染（拷贝）到系统帧缓冲区中去
为了实现以上三个操作，我们还需要：
加载Gralloc模块
打开Gralloc模块中的gralloc设备和fb设备

其中，gralloc设备负责分配图形缓冲区，Gralloc模块负责注册图形缓冲区，而fb设备负责渲染图形缓冲区。

这个系列内容还是太多了，我估计坚持不了多久。。。。。另外，求HR或者大神带我入坑，妹子图敬上~

April is your lie

Chromium学习之路(一)----智能指针实现原理分析

智能指针概述

WebKit智能指针

第一类智能指针

去除无用引用计数

第二类智能指针

Move语意

弱智能指针

Chromium智能指针

第一类智能指针

第二类智能指针

Move语意

弱智能指针

总结

Chromium学习之路-启动篇

Google Chrome的历史和指导性原则

性能的多个方面

什么是现代Web应用？

线上资源请求的生命周期

“足够快”有多快？

Chrome的网络栈概览

多进程架构

进程间通信和多进程资源加载

跨平台资源获取

移动平台的架构和性能

使用Chrome预测器进行推测优化

Chrome网络架构概要

浏览器会话的生命周期

优化冷启动体验

使用Omnibox优化交互过程

优化缓存性能

使用预获取优化DNS

使用预连接优化TCP连接管理

使用预获取提示优化资源加载

使用浏览器预刷新优化资源加载

使用预呈现优化浏览

Chrome会随着你的使用越来越快

学习浏览器技术可以得到什么？

注释

参考

无题

又到了迷茫时间

艰难的旅程

无奈的抉择

あの日見た花の名前を僕達はまだ知ら

PHOENIX

回顾

展望

Android SurfaceFlinger 学习之路(十二)----合成Layer

回顾

合成流程

开始合成

合成图层

doComposeSurfaces

OpenGL处理合成

绑定纹理

drawWithOpenGL

交换合成缓冲区

OpenGL环境创建

触发渲染

硬件模块渲染过程

更新SW Vsync误差

小结

Android SurfaceFlinger 学习之路(十一)(PostView)--附：硬件HWC选取合成类型（Intel）

HWC选取合成类型

流程细节

更新HwcLayerList

更新HwcLayer

映射过程

初始化和反初始化

开始智能合成

小结

Android SurfaceFlinger 学习之路(十一)----合成Layer之准备合成

合成准备

流程分析

preComposition

rebuildLayerStacks

相关区域概述

computeVisibleRegions

生产-消费模型