先上效果图：

在开发中，很多时候都要适应设计给出的文本样式，文本样式丰富多彩，如果掌握了富文本化的方法，灵活运用，就能应对各种审美要求。可供自定义的属性非常之多，该篇博文主要针对一些比较常用的属性进行解说。

初始化字符串：

NSString *str = @"欢迎关注黄飞的csdn博客，探讨技术，研究理论，一起学习，一起进步。最怕你医生碌碌无为，还安慰自己平凡可贵。";
NSMutableAttributedString *attrStr = [[NSMutableAttributedString alloc] initWithString:str];

设置文字大小

[attrStr addAttribute:NSFontAttributeName
                    value:[UIFont systemFontOfSize:30.0f]
                    range:NSMakeRange(0, 10)];

设置文字颜色

[attrStr addAttribute:NSForegroundColorAttributeName
                    value:[UIColor redColor]
                    range:NSMakeRange(15, 10)];

添加下划线

NSStrikethroughStyleAttributeName的value: （1~7单线,依次加粗， 9~15:双线,依次加粗）

[attrStr addAttribute:NSUnderlineStyleAttributeName
                    value:[NSNumber numberWithInteger:NSUnderlineStyleSingle]
                    range:NSMakeRange(27, 10)];
[attrStr addAttribute:NSUnderlineColorAttributeName
                    value:[UIColor yellowColor]
                    range:NSMakeRange(27, 10)];

添加删除线

NSStrikethroughStyleAttributeName的value:（1~7单线,依次加粗， 9~15:双线,依次加粗）

[attrStr addAttribute:NSStrikethroughStyleAttributeName
                    value:@(5)
                    range:NSMakeRange(37, 10)];
[attrStr addAttribute:NSStrikethroughColorAttributeName
                    value:[UIColor greenColor]
                    range:NSMakeRange(37, 10)];

添加阴影

NSShadow *shadow = [[NSShadow alloc] init];
shadow.shadowColor = [UIColor purpleColor];
shadow.shadowOffset = CGSizeMake(5, 5);
shadow.shadowBlurRadius = 2.0;
[attrStr addAttribute:NSShadowAttributeName
                    value:shadow
                    range:NSMakeRange(48, 5)];

添加段落设置

NSMutableParagraphStyle *paragraph = [[NSMutableParagraphStyle alloc] init];
//行间距
paragraph.lineSpacing = 10;
//段落间距
paragraph.paragraphSpacing = 20;
//对齐方式
paragraph.alignment = NSTextAlignmentLeft;
//指定段落开始的缩进像素
paragraph.firstLineHeadIndent = 30;
//调整全部文字的缩进像素
paragraph.headIndent = 10;

[attrStr addAttribute:NSParagraphStyleAttributeName
                    value:paragraph
                    range:NSMakeRange(0, [str length])];

最后添加Label，并设置富文本属性

UILabel *label = [[UILabel alloc] initWithFrame:CGRectMake(60, 100, 200, 0)];
label.backgroundColor = [UIColor lightGrayColor];
//自动换行
label.numberOfLines = 0;
//设置label的富文本
label.attributedText = attrStr;
//label高度自适应
[label sizeToFit];
[self.view addSubview:label];

关于富文本还有其他很多属性可供自定义，此处不一一罗列，上述所列的方法已经可以应对大多数UI设计。如有需求，后续会继续完善！

这是一个自定义的周历,月历,以及时间布局的demo

此项目不适合直接放到自己的项目中,需要自己改动部分代码去适合自己的业务逻辑
主要业务逻辑在weekCalendarEventview 中

github地址

效果图

功能包含

• 周历月历联动
• 当前时间的红线展示
• 过去时间置灰展示
• 事件区域事件的回调的监听
• 空白可以点击的区域的时间回调监听
• 选择开始和结束时间并返回

代码的结构

src

main

java

cn.yky.calendarview

activity 时间日历控件界面

adapter 周历,月历,周历事件控件的适配器

anims 周历和月历上下滑动的动画切换

bean 存放的数据模型

inter 周历,月历的点击选中事件的回调监听

utils 存放的日期,集合,数据和字符串的工具类

view 存放的自定义控件

res

values

attrs 存放的自定义属性

需要用到的知识点
* 自定义view滑动
* 自定义控件画布的切割
* 自定义控件的联调滑动
* ….

联系方式

本人技术有限,还有很多不完美的地方,欢迎指出.(写作不易,谢谢您的star支持)
* QQ:152046273
* Email:yukuoyuan@hotmail.com
* CSDN博客地址
* Github博客地址

Android HttpClient请求过程解析

前言：很久没有写源码解析相关的文章了，所谓“三天不写，上房揭瓦”，这都仨月啦！前段时间忙着发版，经理有别的事情忙，就把管理发版的事情丢给我了，这事确实很麻烦啊，要关注的人事物都很多，虽然对于技术的提升很小，不过也加深了我对整个产品的理解和视野的开阔，对于时间安排与发展规划都有了更深的理解。每次的前言都是自己胡说八道的废话。好了，言归正传，这次的博客就是对于android的HttpClient进行请求数据的流程解析。

综述

总体来说http请求包括三个步骤，分别是域名解析、建立连接、发送请求。

首先写一个简单的HttpClient请求的android代码。

       HttpClienthttpClient = new DefaultHttpClient();//1、获取默认客户端

       HttpGethttpGet = new HttpGet(“http://www.baidu.com/”); //2、创建HttpGet请求

       try{

              HttpResponseresponse = httpClient.execute(httpGet);//3、通过客户端发送请求获取数据

       }catch (Exception e) {

              e.printStackTrace();

       }

二、获取默认客户端

首先创建了一个默认的httpClient，其中的调用流程如下：

1、创建DefaultHttpClient对象，其代码位于external\apache-http\src\org\apache\http\impl\client\DefaultHttpClient.java

public DefaultHttpClient() {

super(null,null);

}

2、调用父类，进行构造函数，代码位于external\apache-http\src\org\apache\http\impl\client\AbstractHttpClient.java

/**

    * Creates a new HTTP client.

    *

    * @param conman    the connectionmanager

    * @param params    the parameters

    */

   protected AbstractHttpClient(

           final ClientConnectionManager conman,

           final HttpParams params) {

       defaultParams        = params;

       connManager          = conman;

} // constructor

好的，这里构造了一个空的HttpClient对象

三、创建HttpGet请求

然后创建了一个HttpGet请求，其中的调用流程如下：

1、创建HttpGet对象，其代码位于external\apache-http\src\org\apache\http\client\methods\HttpGet.java

/**

* @throws IllegalArgumentException if theuri is invalid.      

*/

public HttpGet(final String uri) {

super();

setURI(URI.create(uri));

}

2、父类位于external\apache-http\src\org\apache\http\client\methods\HttpRequestBase.java

public HttpRequestBase() {

super();

this.abortLock =new ReentrantLock();

}

3、父类的父类位于external\apache-http\src\org\apache\http\message\AbstractHttpMessage.java

protected AbstractHttpMessage(finalHttpParams params) {

       super();

       this.headergroup = new HeaderGroup();

       this.params = params;

    }

   protected AbstractHttpMessage() {

       this(null);

    }

四、通过客户端发送请求获取数据

放流程图

然后开始正式的解析并获取数据

1、 执行我们看到的execute函数，其代码位于src\org\apache\http\impl\client\AbstractHttpClient.java’

其通过两次调用重载的重名函数，跳到了

       publicfinal HttpResponse execute(HttpUriRequest request,

                                     HttpContext context)

       throws IOException, ClientProtocolException {

       if (request == null) {

           throw new IllegalArgumentException

                ("Request must not benull.");

       }

       returnexecute(determineTarget(request), request, context);

}

没啥可说的，首先判断了request的null异常，就再次进行了内部跳转，其中有一个determineTarget函数

private HttpHostdetermineTarget(HttpUriRequest request) {

        // A null target may be acceptable ifthere is a default target.

        // Otherwise, the null target isdetected in the director.

        HttpHost target = null;

        URI requestURI = request.getURI();

              //如果URI可以获取到请求类型，则直接新建HttpHost

        if (requestURI.isAbsolute()) {

            target = new HttpHost(

                    requestURI.getHost(),

                    requestURI.getPort(),

                    requestURI.getScheme());

        }

        return target;

    }

2、 接下来依然是调用了不同参数的execute函数

// non-javadoc,see interface HttpClient

    public final HttpResponse execute(HttpHosttarget, HttpRequest request,

                                     HttpContext context)

        throws IOException,ClientProtocolException {

        if (request == null) {

            throw new IllegalArgumentException

                ("Request must not benull.");

        }

        // a null target may be acceptable,this depends on the route planner

        // a null context is acceptable,default context created below

        HttpContext execContext = null;

        RequestDirector director = null;

        // Initialize the request executioncontext making copies of

        // all shared objects that arepotentially threading unsafe.

        synchronized (this) {

            HttpContext defaultContext =createHttpContext();

            if (context == null) {

                execContext = defaultContext;

            } else {

                execContext = newDefaultedHttpContext(context, defaultContext);

            }

            // Create a director for thisrequest

            director =createClientRequestDirector(

                    getRequestExecutor(),

                    getConnectionManager(),

                   getConnectionReuseStrategy(),

                   getConnectionKeepAliveStrategy(),

                    getRoutePlanner(),

                    getHttpProcessor().copy(),

                   getHttpRequestRetryHandler(),

                    getRedirectHandler(),

                    getTargetAuthenticationHandler(),

                   getProxyAuthenticationHandler(),

                    getUserTokenHandler(),

                    determineParams(request));

        }

        try {

            return director.execute(target,request, execContext);

        } catch(HttpException httpException) {

            throw newClientProtocolException(httpException);

        }

} // execute

这个函数比较长，其实主要也就三步，第一步创建一个http信息上下文HttpContext，第二步创建一个对于请求的操作者RequestDirector，第三部通过RequestDirector执行请求。RequestDirector的参数比较多，这里先不一一分析，将他的create函数放上来：

       protectedRequestDirector createClientRequestDirector(

           final HttpRequestExecutor requestExec,

           final ClientConnectionManager conman,

           final ConnectionReuseStrategy reustrat,

           final ConnectionKeepAliveStrategy kastrat,

           final HttpRoutePlanner rouplan,

           final HttpProcessor httpProcessor,

           final HttpRequestRetryHandler retryHandler,

           final RedirectHandler redirectHandler,

            final AuthenticationHandlertargetAuthHandler,

           final AuthenticationHandler proxyAuthHandler,

           final UserTokenHandler stateHandler,

           final HttpParams params) {

       return new DefaultRequestDirector(

               requestExec,

                conman,

                reustrat,

                kastrat,

                rouplan,

                httpProcessor,

                retryHandler,

                redirectHandler,

                targetAuthHandler,

               proxyAuthHandler,

                stateHandler,

                params);

    }

3、 执行RequestDirector的execute函数，相关代码文件位于src\org\apache\http\client\ RequestDirector.java

实际上调用了DefaultRequestDirector的execute函数，其位置位于src\org\apache\http\impl\client\DefaultRequestDirector.java

首先贴出代码，非常巨大的一个函数：

  // non-javadoc, see interfaceClientRequestDirector

    public HttpResponse execute(HttpHosttarget, HttpRequest request,

                                HttpContextcontext)

        throws HttpException, IOException {

        HttpRequest orig = request;

        //打包请求

        RequestWrapper origWrapper = wrapRequest(orig);

        //设置参数

        origWrapper.setParams(params);

        //路由定向，不管是做为本地路由还是中转路由

        HttpRoute origRoute =determineRoute(target, origWrapper, context);

        RoutedRequest roureq = newRoutedRequest(origWrapper, origRoute);

        long timeout =ConnManagerParams.getTimeout(params);

        int execCount = 0;

        boolean reuse = false;

        HttpResponse response = null;

        boolean done = false;

        try {

            while (!done) {

                // In this loop, theRoutedRequest may be replaced by a

                // followup request and route.The request and route passed

                // in the method arguments willbe replaced. The original

                // request is still availablein 'orig'.

                RequestWrapper wrapper =roureq.getRequest();

                HttpRoute route =roureq.getRoute();

                // See if we have a user tokenbound to the execution context

                Object userToken = context.getAttribute(ClientContext.USER_TOKEN);

                // Allocate connection ifneeded

                if (managedConn == null) {

                    ClientConnectionRequestconnRequest = connManager.requestConnection(

                            route, userToken);

                    if (orig instanceofAbortableHttpRequest) {

                        ((AbortableHttpRequest)orig).setConnectionRequest(connRequest);

                    }

                    try {

                        managedConn =connRequest.getConnection(timeout, TimeUnit.MILLISECONDS);

                    }catch(InterruptedException interrupted) {

                        InterruptedIOExceptioniox = new InterruptedIOException();

                        iox.initCause(interrupted);

                        throw iox;

                    }

                             //如果提交检查前需要测试是否可用，则在android当中先关闭连接

                    if(HttpConnectionParams.isStaleCheckingEnabled(params)) {

                        // validate connection

                       this.log.debug("Stale connection check");

                        if(managedConn.isStale()) {

                           this.log.debug("Stale connection detected");

                            // BEGINandroid-changed

                            try {

                               managedConn.close();

                            } catch(IOException ignored) {

                                // SSLSocket'swill throw IOException

                                // because theycan't send a "close

                                // notify"protocol message to the

                                // server. Justsupresss any

                                // exceptionsrelated to closing the

                                // stale connection.

                            }

                            // ENDandroid-changed

                        }

                    }

                }

                if (orig instanceofAbortableHttpRequest) {

                    ((AbortableHttpRequest)orig).setReleaseTrigger(managedConn);

                }

                // Reopen connection if needed

                if (!managedConn.isOpen()) {

                    managedConn.open(route,context, params);

                }

                // BEGIN android-added

                else {

                    // b/3241899 set the perrequest timeout parameter on reused connections

                   managedConn.setSocketTimeout(HttpConnectionParams.getSoTimeout(params));

                }

                // END android-added

                try {

                             //建立路由跳转连接

                    establishRoute(route,context);

                } catch (TunnelRefusedExceptionex) {

                    if(this.log.isDebugEnabled()) {

                       this.log.debug(ex.getMessage());

                    }

                    response =ex.getResponse();

                    break;

                }

                // Reset headers on the requestwrapper

                wrapper.resetHeaders();

                // Re-write request URI ifneeded

                rewriteRequestURI(wrapper,route);

                // Use virtual host if set

                target = (HttpHost)wrapper.getParams().getParameter(

                        ClientPNames.VIRTUAL_HOST);

                if (target == null) {

                    target =route.getTargetHost();

                }

                HttpHost proxy =route.getProxyHost();

                // Populate the executioncontext

               context.setAttribute(ExecutionContext.HTTP_TARGET_HOST,

                        target);

               context.setAttribute(ExecutionContext.HTTP_PROXY_HOST,

                        proxy);

               context.setAttribute(ExecutionContext.HTTP_CONNECTION,

                        managedConn);

               context.setAttribute(ClientContext.TARGET_AUTH_STATE,

                        targetAuthState);

                context.setAttribute(ClientContext.PROXY_AUTH_STATE,

                        proxyAuthState);

                // Run request protocolinterceptors

                requestExec.preProcess(wrapper,httpProcessor, context);

                context.setAttribute(ExecutionContext.HTTP_REQUEST,

                        wrapper);

                boolean retrying = true;

                while (retrying) {

                    // Increment total execcount (with redirects)

                    execCount++;

                    // Increment exec count forthis particular request

                   wrapper.incrementExecCount();

                    if (wrapper.getExecCount()> 1 && !wrapper.isRepeatable()) {

                        throw newNonRepeatableRequestException("Cannot retry request " +

                                "with anon-repeatable request entity");

                    }

                    try {

                        if(this.log.isDebugEnabled()) {

                           this.log.debug("Attempt " + execCount + " to executerequest");

                        }

                                    //执行请求

                        response =requestExec.execute(wrapper, managedConn, context);

                        retrying = false;

                    } catch (IOException ex) {

                       this.log.debug("Closing the connection.");

                        managedConn.close();

                        if(retryHandler.retryRequest(ex, execCount, context)) {

                            if(this.log.isInfoEnabled()) {

                               this.log.info("I/O exception ("+ ex.getClass().getName() +

                                        ")caught when processing request: "

                                        + ex.getMessage());

                            }

                            if(this.log.isDebugEnabled()) {

                               this.log.debug(ex.getMessage(), ex);

                            }

                            this.log.info("Retryingrequest");

                        } else {

                            throw ex;

                        }

                        // If we have a directroute to the target host

                        // just re-open connectionand re-try the request

                        if (route.getHopCount()== 1) {

                           this.log.debug("Reopening the direct connection.");

                           managedConn.open(route, context, params);

                        } else {

                            // otherwise giveup

                            throw ex;

                        }

                    }

                }

                // Run response protocol interceptors

                response.setParams(params);

               requestExec.postProcess(response, httpProcessor, context);

                // The connection is in or canbe brought to a re-usable state.

                      // 是否是一个长连接

                reuse = reuseStrategy.keepAlive(response,context);

                if(reuse) {

                    // Set the idle duration ofthis connection

                    long duration =keepAliveStrategy.getKeepAliveDuration(response, context);

                    managedConn.setIdleDuration(duration,TimeUnit.MILLISECONDS);

                }

                RoutedRequest followup =handleResponse(roureq, response, context);

                if (followup == null) {

                    done = true;

                } else {

                    if (reuse) {

                       this.log.debug("Connection kept alive");

                        // Make sure theresponse body is fully consumed, if present

                        HttpEntity entity =response.getEntity();

                        if (entity != null) {

                           entity.consumeContent();

                        }

                        // entity consumedabove is not an auto-release entity,

                        // need to mark theconnection re-usable explicitly

                       managedConn.markReusable();

                    } else {

                        managedConn.close();

                    }

                    // check if we can use the same connectionfor the followup

                    if(!followup.getRoute().equals(roureq.getRoute())) {

                        releaseConnection();

                    }

                    roureq = followup;

                }

                userToken =this.userTokenHandler.getUserToken(context);

               context.setAttribute(ClientContext.USER_TOKEN, userToken);

                if (managedConn != null) {

                    managedConn.setState(userToken);

                }

            } // while not done

            // check for entity, releaseconnection if possible

            if ((response == null) ||(response.getEntity() == null) ||

               !response.getEntity().isStreaming()) {

                // connection not needed and(assumed to be) in re-usable state

                if (reuse)

                    managedConn.markReusable();

                releaseConnection();

            } else {

                // install an auto-release entity

                HttpEntity entity =response.getEntity();

                entity = newBasicManagedEntity(entity, managedConn, reuse);

                response.setEntity(entity);

            }

            return response;

        } catch (HttpException ex) {

            abortConnection();

            throw ex;

        } catch (IOException ex) {

            abortConnection();

            throw ex;

        } catch (RuntimeException ex) {

            abortConnection();

            throw ex;

        }

    } // execute

4、未完待续

Given a linked list, determine if it has a cycle in it.

还是linked list中的简单题，需要判断一个链表是否成环。成环的条件显然就是中途有节点指向前面的几点了，所以我们将遍历到的节点放到一个集合中，然后后面遍历的节点都在这个集合中查找一下，找到的话就说明成环了，否则不成环。

class Solution {
public:
    bool hasCycle(ListNode *head) {
        unordered_set<ListNode*> nodes;
        while(head) {
            if(nodes.count(head)==1) {
                return true;
            } else {
                nodes.insert(head);
            }
            head = head->next;
        }
        return false;
    }
};

要破解移动版的网络限制你的手机需要有以下几个准备，1.官方的emui4.1系统，最高到198；2.系统必须root；3.recovery必须是官方的。步骤是：系统---解锁---刷第三方recovery---root---刷官方recovery---全网通助手
具体过程我来一步一步讲。

1.有很多人升级到了5.0，那么我们用华为官方自带的助手，系统更新里面，有一个其他版本，就是4.1版本，插上手机直接搞就行，这一步很简单。
2.解锁；大家知道，华为这两年出的机器都是锁boot的，所以要root必须先解锁，华为必须要申请解锁码或者通过非官方途径获得解锁码来解锁即1，华为用户开启云服务，等14天，然后官方申请。（解锁教程：http://club.huawei.com/thread-11020470-1-1.html）；2，花10-20块钱，淘宝搞定。得到解锁码之后，用华为工具箱解锁。（所有工具下载地址：http://download.csdn.net/download/chaoyu168/9984901）。

3.解锁了以后就可以刷第三方recovery了，有人要问为什么？因为root必须要第三方recovery。附件里有，我也是在网上找的，也是插上手机，然后一键刷第三方recovery。（刷recovery教程：http://www.huaweirom.com/guide/4081.html）

4.root，有了第三方recovery就可以root了，具体教程（http://www.huaweirom.com/meihua/4790.html）；

5.好了root完了之后，用刷第三方recovery的那个重新刷官方的recovery，刷完之后，有可能进系统的时候会让你恢复固件，你点返回还是取消，应该就可以进系统了，并且是已经root了的。

6.上网下载全网通助手（http://www.234g.net.cn/），解锁码需要加WX，找人家买，29.9一个，毕竟是人家的技术，买来之后，输入进去，然后手机让你重新恢复系统，你恢复就是了，这个时候，你会发现，你的移动定制机变成了移动联通双4g版。

自定义View系列教程00–推翻自己和过往，重学自定义View
自定义View系列教程01–常用工具介绍
自定义View系列教程02–onMeasure源码详尽分析
自定义View系列教程03–onLayout源码详尽分析
自定义View系列教程04–Draw源码分析及其实践
自定义View系列教程05–示例分析
自定义View系列教程06–详解View的Touch事件处理
自定义View系列教程07–详解ViewGroup分发Touch事件
自定义View系列教程08–滑动冲突的产生及其处理

探索Android软键盘的疑难杂症
深入探讨Android异步精髓Handler
详解Android主流框架不可或缺的基石
站在源码的肩膀上全解Scroller工作机制

Android多分辨率适配框架（1）— 核心基础
Android多分辨率适配框架（2）— 原理剖析
Android多分辨率适配框架（3）— 使用指南

版权声明

• 本文原创作者：谷哥的小弟
• 作者博客地址：http://blog.csdn.net/lfdfhl

引子

做Android开发的童鞋都知晓目前在开发中最流行的套餐RxJava+Retrofit。嗯哼，前两天和同事吃饭，他无意间提起一个异步的问题；我说：可以用RxJava试试。这个哥们放下筷子，一本正经地告诉我：别用那玩意，不好用。

“不好用？”我疑惑地问到
“嗯”
“怎么不好用了？”
“反正就是感觉有点怪，一会儿观察，一会儿被观察，搞不清楚”

嗯嗯，听他说完这些，我大概明白了：他对RxJava的困惑其实是源于对观察者模式的陌生。没事儿，我们按照以往的套路来一起学习观察者模式。

观察者模式详细示例

在正式进入该设计模式之前，我想问一下：你们平常都用微信干什么呢？

“聊天”
“发朋友圈”
“逛微店”
“约…..”

好了，打住，我知道你想说什么了；再说下去我就要打马赛克了。你想想还有别的么？

“别的？除了这些，我还看微信公众号，关注自己喜欢的内容”

好嘞，就从微信公众号入手！平常我们关注一个微信公众号，当它推送新内容时，手机界面上就会出现一个红色的小点提醒我们查看详细内容。换句话说：我们订阅了公众号，当它有新消息时就会自动告知我们。再说得通俗点：相当于我们自己是观察者，在观察微信公众号，公众号就是被观察者。现在，我们用代码来模拟这个过程：

package cn.com;

/**
 * 原创作者：谷哥的小弟
 * 博客地址：http://blog.csdn.net/lfdfhl
 */

public interface Subscription {
    public void addUserAccount(UserAccount userAccount);
    public void deleteUserAccount(UserAccount userAccount);
    public void sendMessage(String message);
}

建立抽象的被观察者

package cn.com;

import java.util.ArrayList;

/**
 * 原创作者：谷哥的小弟
 * 博客地址：http://blog.csdn.net/lfdfhl
 */

public class SubscriptionAccount implements Subscription{
    private ArrayList<UserAccount> userAccountArrayList;

    public SubscriptionAccount(){
        userAccountArrayList=new ArrayList<>();
    }

    @Override
    public void addUserAccount(UserAccount userAccount) {
        if (userAccount!=null){
            userAccountArrayList.add(userAccount);
        }
    }

    @Override
    public void deleteUserAccount(UserAccount userAccount) {
        if (userAccount!=null){
            userAccountArrayList.remove(userAccount);
        }
    }

    @Override
    public void sendMessage(String message) {
        if(message!=null){
            for(UserAccount userAccount:userAccountArrayList){
                userAccount.receiveMessage(message);
            }
        }
    }
}

具体的被观察者，也就是刚才提到的微信公众号实现抽象被观察者。在此模拟微信公众号几个常用的方法：添加用户，删除用户，发送消息。

package cn.com;

/**
 * 原创作者：谷哥的小弟
 * 博客地址：http://blog.csdn.net/lfdfhl
 */

public interface User {
    public void receiveMessage(String message);
}

抽象观察者。

package cn.com;

/**
 * 原创作者：谷哥的小弟
 * 博客地址：http://blog.csdn.net/lfdfhl
 */

public class UserAccount implements User{

    private String name;

    public UserAccount(String name){
        this.name=name;
    }
    @Override
    public void receiveMessage(String message) {
        System.out.println(name+"，收到消息："+message);
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

具体的观察者实现抽象观察者，也就是微信公众号的订阅者，比如我们自己。好了，现在微信公众号有了，用户也有了，我们来测试一把：

package cn.com;
/**
 * 原创作者：谷哥的小弟
 * 博客地址：http://blog.csdn.net/lfdfhl
 */
public class Test {

    public static void main(String[] args) {
          SubscriptionAccount subscriptionAccount=new SubscriptionAccount();
            UserAccount userAccount1=new UserAccount("老王");
            UserAccount userAccount2=new UserAccount("小弟");
            UserAccount userAccount3=new UserAccount("包包");
            subscriptionAccount.addUserAccount(userAccount1);
            subscriptionAccount.addUserAccount(userAccount2);
            subscriptionAccount.addUserAccount(userAccount3);
            subscriptionAccount.sendMessage("有心课堂新课程上线啦");

    }

}

• 创建三个用户，老王，小弟，包包
• 微信公众号添加这三个用户
• 微信公众号发布消息

请看，控制台输出日志：

老王，收到消息：有心课堂新课程上线啦
小弟，收到消息：有心课堂新课程上线啦
包包，收到消息：有心课堂新课程上线啦

嗯哼，看到了么？三个微信用户都收到了微信公众号发布的消息。我们平常订阅微信公众号的本质是：微信公众号记录下我们的微信账号。所以，当它有新消息推送时瞅瞅自己的小本子上记录了谁就发送给谁。

看完这个小例子，我们再来梳理一下观察者模式。

• 该模式中存在观察者和被观察者
• 观察者和被观察者通过订阅发生关联关系
• 当被观察者发出消息后，所有观察者均会收到消息

OK，当你看完了这个例子，再看RxJava的代码：

observable.subscribe(observer);

是不是就反应过来了呢？很多初学者看到这句代码的时候都会抓狂：怎么会是被观察者订阅了观察者？！！不该是观察者订阅被观察者么？！！其实，不必过于纠结文字表述的细节，重要的是明白其中的思想，它和我们刚才的：

  subscriptionAccount.addUserAccount(userAccount);

难道不一样么？就是同一回事！没啥不同的。我们在思考问题的时候，不能单纯地只站在生活的角度来看，也不能光从计算机的角度来考虑；而是要把两者结合起来，不要钻牛角尖，认死理。

小感悟

很多刚开始做开发的童鞋喜欢拿着一本厚厚的设计模式在角落里默默地啃。学习的劲头很足，态度也很端正，配得上10086个赞。在此，我也想提醒一下小伙伴们：学习态度和努力程度固然非常重要，但是我们也要注意学习方法。抛开实际应用和业务逻辑单纯地看设计模式是很难理解其精髓的。我们不妨将设计模式和自己的实际工作结合起来学习，比如做Android开发的小伙伴可结合Android源码或者非常流行的第三方库来深入地研究设计模式，在此推荐一篇《Retrofit分析-漂亮的解耦套路》供大家学习参考

参考资料

• Head First设计模式

• Android架构设计方法、技巧与实践

• Retrofit架构分享

• Java应用架构设计：模块化模式与OSGi

因为自己的应用程序运行的时候需要保持屏幕常亮，可以加入以下语句：
(1)如果是在Xcode中做开发：

[ [ UIApplication sharedApplication] setIdleTimerDisabled:YES ] ;

设置为YES保持屏幕常亮.

(2)iOS5中,可以调节亮度了,我没有试过,大家试试看

[[UIScreen mainScreen]setBrightness:0.5f];

取值范围从0.0到1.0

(3)如果使用私有API,iOS5以下也可以做到，不过你的应用程序也会被Apple reject的

[[UIApplication sharedApplication]setBacklightLevel:1.0f];

1、效果展示

2、效果分析

3、Item布局

3、实现Adapter

4、监听滑动

5、回弹效果

6、总结一下

联系我

视图动画

 视图动画共有四种，分别为透明度，旋转，平移，缩放动画，如同名字所说一样，它是一种视图上的动画，改变的只是视觉上的效果，实际上View的属性如位置，大小，透明度等并没有受到动画的影响。下面将演示四种视图动画的代码及xml定义使用。

代码定义：

public void alpha(View v){
    AlphaAnimation alphaAnimation = new AlphaAnimation(1,0);
    alphaAnimation.setDuration(3000);
    imageView.startAnimation(alphaAnimation);*/
}

public void rotate(View v){
    RotateAnimation rotateAnimation = new RotateAnimation(0,360,imageView.getWidth()/2,imageView.getHeight()/2);
    rotateAnimation.setDuration(3000);
    imageView.startAnimation(rotateAnimation);
}

public void translate(View v){
    TranslateAnimation translateAnimation = new TranslateAnimation(0,imageView.getWidth(),0,imageView.getHeight());
    translateAnimation.setDuration(3000);
    imageView.startAnimation(translateAnimation);
}

public void scale(View v){
    ScaleAnimation scaleAnimation = new ScaleAnimation(1f,0.5f,1f,0.5f,imageView.getWidth()/2,imageView.getHeight()/2);
    scaleAnimation.setDuration(3000);
    imageView.startAnimation(scaleAnimation);
}

演示xml

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical" android:layout_width="match_parent"
    android:layout_height="match_parent">

    <ImageView
        android:id="@+id/image"
        android:layout_width="wrap_content"
        android:src="@mipmap/test"
        android:layout_marginTop="30dp"
        android:layout_gravity="center"
        android:layout_height="wrap_content" />

    <LinearLayout
        android:layout_width="match_parent"
        android:orientation="horizontal"
        android:padding="10dp"
        android:layout_height="wrap_content">

        <Button
            android:layout_width="0dp"
            android:layout_weight="1"
            android:text="alpha"
            android:onClick="alpha"
            android:layout_margin="10dp"
            android:layout_height="wrap_content" />

        <Button
            android:layout_width="0dp"
            android:layout_weight="1"
            android:text="rotate"
            android:onClick="rotate"
            android:layout_margin="10dp"
            android:layout_height="wrap_content" />
    </LinearLayout>

    <LinearLayout
        android:layout_width="match_parent"
        android:orientation="horizontal"
        android:padding="10dp"
        android:layout_height="wrap_content">

        <Button
            android:layout_width="0dp"
            android:layout_weight="1"
            android:text="translate"
            android:onClick="translate"
            android:layout_margin="10dp"
            android:layout_height="wrap_content" />

        <Button
            android:layout_width="0dp"
            android:layout_weight="1"
            android:text="scale"
            android:onClick="scale"
            android:layout_margin="10dp"
            android:layout_height="wrap_content" />
    </LinearLayout>
</LinearLayout>

效果图：

上面的效果同样可以通过定义动画xml文件来实现，如：

alpha.xml

<?xml version="1.0" encoding="utf-8"?>
<alpha xmlns:android="http://schemas.android.com/apk/res/android"
    android:fromAlpha="1"
    android:duration="3000"
    android:toAlpha="0">
</alpha>

rotate.xml

<?xml version="1.0" encoding="utf-8"?>
<rotate xmlns:android="http://schemas.android.com/apk/res/android"
    android:fromDegrees="0"
    android:toDegrees="360"
    android:pivotX="50%"
    android:duration="3000"
    android:pivotY="50%">

</rotate>

translate.xml

<?xml version="1.0" encoding="utf-8"?>
<translate xmlns:android="http://schemas.android.com/apk/res/android"
    android:fromXDelta="0"
    android:toXDelta="100%"
    android:duration="3000"
    android:fromYDelta="0"
    android:toYDelta="100%">

</translate>

scale.xml

<?xml version="1.0" encoding="utf-8"?>
<scale xmlns:android="http://schemas.android.com/apk/res/android"
    android:pivotX="50%"
    android:pivotY="50%"
    android:fromXScale="100%"
    android:toXScale="0%"
    android:duration="3000"
    android:fromYScale="100%"
    android:toYScale="0%">

</scale>

然后在代码中使用AnimationUtils.loadAnimation(this,R.anim.alpha)加载动画执行即可，如：

public void alpha(View v){
    imageView.startAnimation(AnimationUtils.loadAnimation(this,R.anim.alpha));
}

上面的视图动画除了可以单独执行外，往往需要组合来实现炫酷的动画效果，这时我们可以通过AnimationSet来组合上面四种视图动画，如：

public void set(View v){
    AnimationSet animationSet = new AnimationSet(true);
    animationSet.addAnimation(AnimationUtils.loadAnimation(this,R.anim.alpha));
    animationSet.addAnimation(AnimationUtils.loadAnimation(this,R.anim.rotate));
    animationSet.addAnimation(AnimationUtils.loadAnimation(this,R.anim.translate));
    animationSet.addAnimation(AnimationUtils.loadAnimation(this,R.anim.scale));
    animationSet.setDuration(3000);
    imageView.startAnimation(animationSet);
}

效果图:

除了动画的组合外，有时候我们需要对动画进行监听，如动画的开始，结束等以便完成相应的业务逻辑，我们可以调用setAnimationListener来给动画添加监听，如：

animationSet.setAnimationListener(new Animation.AnimationListener() {
    @Override
    public void onAnimationStart(Animation animation) {
        // 动画开始
    }

    @Override
    public void onAnimationEnd(Animation animation) {
        // 动画结束
    }

    @Override
    public void onAnimationRepeat(Animation animation) {
        // 动画重复
    }
});

学会了以上关于视图动画后基本上对于一些普通效果的动画制作及相关业务逻辑处理也就没什么问题了，不过视图动画并不能真实地改变View的大小，位置，透明度等等。要想真正地通过动画改变View的大小，位置，透明度等属性需要使用属性动画。

（adb shell am start -n 包名/包名＋类名）

adb shell am start -n com.android.fcc.espressif/com.android.fcc_app.MainActivity

查看activity名：

（1）启动要查看的程序；

（2）命令行输入：adb shell dumpsys window w |findstr \/ |findstr name=

补充：使用adb shell dumpsys window | findstr mCurrentFocus  命令查看当前运行的包名和Activity更清晰一些。

跳转第三方activity：

Intent intent = new Intent(Intent.ACTION_MAIN);  
intent.addCategory(Intent.CATEGORY_LAUNCHER);              
ComponentName cn = new ComponentName(packageName, className);              
intent.setComponent(cn);  
startActivity(intent);  

和一般的入门教程不太一样，本篇主要分享一些入门 Ruby 以及脚本编写过程中的一些心得和体会，不包含 Ruby 的基础内容。希望能给同样想入坑 Ruby 的童鞋一些帮助，如果有错误的地方，也求各位大佬指正。

Ruby 入门

Ruby 官方入门教程

推荐一个 Ruby 官方的入门教程，可以在线边学习边实践：http://tryruby.org/levels/1/challenges/0

bundler

bundler 是用于管理 ruby gem 的工具。跟 cocoapods 非常像，看看下面的例子：

source 'http://ruby.taobao.org'

gem 'cocoapods', '~>0.37.2'
gem 'fastlane', '~>1.4.0'

��一模一样，让人害怕。

安装和执行的指令也是，高度一致：

sudo gem install bundler

bundle install

而且 bundle install 之后同样会生成 Gemfile.lock 文件。

Ruby 静态代码分析

既然已经决定写 Ruby 了，当然也要学会科学的写代码，经过灯塔左 @Draveness 的教育，知道了 rubocop，这个工具会分析出不符合规范的 Ruby 代码，功能类似 OCLint。

安装

gem install rubocop

配置

在项目的 Gemfile 中加入下面一行即可。

gem 'rubocop', '~> 0.49.1', require: false

检测

进入工程根目录，然后执行 rubocop 指令即可。

自动修复

除了能检测 Ruby 代码中不符合规范的部分，rubocop 还能通过 robocop -a 指令修复部分不符合规范的代码。

作为一个小菜鸡，先简单用用吧。

IDE

IDE 我们选择用 Atom，因为目前只用过 Atom，所以也分析不出它和其他 Ruby 编辑器的优劣势，主要分享几个我觉得比较好用的插件吧。

sync-settings

这个插件由@霜神推荐，主要用于同步 Atom 的配置信息，只需要做简单的几个配置，就可以快速的在一台新电脑上部署自己熟悉的开发环境。

关于 sync-settings 的使用，可以参考这篇文章：http://www.jianshu.com/p/bd006b349d03，内容很完整。

platformio-ide-terminal

这个插件可以让你在 Atom 中直接运行 terminal。

面向对象的 Ruby

对于入门 Ruby 的童鞋，有一个个人觉得很重要的点：不要用写 Shell 脚本的方式来写 Ruby，一定要用面向对象的思维方式来设计。

辅助脚本编写

根据之前在iOS 工程自动化 - 思路整理一文中整理的内容，目前已经完成了一键新建 feature、一键切换调试模式以及一键切换提交模式三个功能，并开源在 BigKeeper 上，设计的思路和实现大家可以通过代码直接看到，所以我就不赘述了。这些脚本目前也在持续完善的过程中，存在问题的地方欢迎大家直接在评论中进行指正，感谢～

下面主要分享一些我在脚本编写过程中的收获。

一些收获

git 增强库：git-flow

上篇文章中讲到，开发过程我们遵循 git-flow 的标准，所以我们在编写这些辅助脚本的时候需要找一个 git-flow 支持库。这里我们用 nvie 的库：https://github.com/nvie/gitflow。

安装

使用 Homebrew。

brew install git-flow

基本用法

初始化 git-flow 仓库

git flow init [-d]

展示／开始／结束 feature

git flow feature
git flow feature start <name> [<base>]
git flow feature finish <name>

注意：<base> 参数必须是 develop 分支的一个 commit 记录。

push feature 分支到远端仓库／从远端仓库 pull feature 分支

git flow feature publish <name>
git flow feature pull <remote> <name>

展示／开始／结束 release

git flow release
git flow release start <release> [<base>]
git flow release finish <release>

注意：<base> 参数必须是 develop 分支的一个 commit 记录。

展示／开始／结束 hotfix

git flow hotfix
git flow hotfix start <release> [<base>]
git flow hotfix finish <release>

注意：<base> 参数必须是 master 分支的一个 commit 记录。

展示／开始 support

git flow support
git flow support start <release> <base>

注意：<base> 参数必须是 master 分支的一个 commit 记录。

命令行参数解析库 - OptionParser

一个用于命令行参数解析的库，只需要简单几行代码，即可完成命令提示、解析、报错等功能。下面是我写的一个例子：

def switch_to_debug_parser
  params = {}
  OptionParser.new do |opts|
    opts.banner = 'Here is help messages of the switch to debug command.'
    params[:mainpath] = './'
    opts.on('-m',
            '--mainpath=MainPath',
            'Path of the main project, end with /') do |main_path|
      params[:main_path] = main_path
    end
    opts.on('-n',
            '--modulename=ModuleName',
            'Name of the module in Podfile') do |module_name|
      params[:module_name] = module_name
    end
    opts.on('-p',
            '--modulepath=ModulePath',
            'Path of the module project') do |module_path|
      params[:module_path] = module_path
    end
  end.parse!

  # 如果必填参数没有则抛出异常
  raise OptionParser::MissingArgument if params[:module_name].nil?
  raise OptionParser::MissingArgument if params[:module_path].nil?

  params
end

字符串拼接

当字符串中本身存在 ' 和 " 两种字符时，我们可以用 %q 或者 %Q 的方式来拼接字符串，这样就不需要在 ' 和 " 前面加 \ 了，如下：

%Q(  pod #{module_name}, :git => '#{source.base}', :branch => '#{source.addition}')

执行 Shell 指令

Ruby 执行 Shell 的方式有很多种，我选择的是 IO 的方式：

IO.popen(%Q(cd #{path}; git flow feature start #{feature_name})) { |f| puts f.gets }

这里有个坑，当执行的 Shell 指令的输出是多行时，需要注意 IO 管道提前关闭的情况，用下面的方式来输出 Shell 指令输出的内容。

IO.popen(%Q(pod install --project-directory=#{main_path})) { |io|
  io.each do |line|
    puts line
  end
}

文件内容查找和修改

如果我们需要对文件进行按行查找和内容替换，这里会有一个小小的坑：如果我们直接在当前文件直接进行操作，当更新的内容不是一行时，file.each_line do |line| 会出现异常。就像我们遍历数组插入或者删除中间的元素一样，我们通过引入临时文件的方式来解决这个问题。如下：

def find_and_replace(podfile, module_name, module_type, source)
  temp_file = Tempfile.new('.Podfile.tmp')

  begin
    File.open(podfile, 'r') do |file|
      file.each_line do |line|
        if line.include?module_name
          temp_file.puts generate_module_config(module_name, module_type, source)
        else
          temp_file.puts line
        end
      end
    end
    temp_file.close
    FileUtils.mv(temp_file.path, podfile)
  ensure
    temp_file.close
    temp_file.unlink
  end
end

相对路径转绝对路径

Ruby 自带这个功能，使用 File.expand_path 方法即可。

参考资料

Atom 使用教程：http://wiki.jikexueyuan.com/project/atom/basis.html

ATOM同步插件和配置，使用sync-settings：http://www.jianshu.com/p/bd006b349d03

Android字体属性及测量（FontMetrics）

• 字体的几个参数，以Android API文档定义为尊，见下图
  

要点如下：

1. 基准点是baseline
2. Ascent是baseline之上至字符最高处的距离
3. Descent是baseline之下至字符最低处的距离
4. Leading文档说的很含糊，其实是上一行字符的descent到下一行的ascent之间的距离
5. Top指的是指的是最高字符到baseline的值，即ascent的最大值
6. bottom指的是最下字符到baseline的值，即descent的最大值

为了帮助理解，我特此搜索了不同的示意图。对照示意图，会很容易理解FontMetrics的参数。

图1

图2

图3

图4

图5

图6

• 测试
  我们使用自定义的View和Textview里的字符串作为研究对象

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:background="#000000"
    android:orientation="vertical"
    >
    <!--PaintView画字体-->
   <video.ketu.com.fontmeasure.PaintView
       android:id="@+id/v_fontview"
       android:layout_width="match_parent"
       android:layout_height="1dp"
       android:layout_weight="1"
       />
   <!--Textview设置文字-->
   <TextView
       android:id="@+id/tv_fontview1"
       android:layout_width="match_parent"
       android:layout_height="wrap_content"
       android:text="中国话fgiqÃÇŸŒú"
       android:textColor="@android:color/white"
       android:textSize="80px"
       android:layout_weight="1"/>
</LinearLayout>

MainActivity.class

public class MainActivity extends AppCompatActivity {
    TextView textView;
    View paintView;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        paintView = findViewById(R.id.v_fontview);
        textView = (TextView) findViewById(R.id.tv_fontview1);
        //String text = "中国话fgiqÃÇŸŒúcqazweyghnhgd;lc,kjssnhjjomoomcod";
        String text = "中国话fgiqÃÇŸŒú";
        /*设置字体带下80px*/
        textView.setTextSize(TypedValue.COMPLEX_UNIT_PX,80);
        textView.setText(text);
        Paint.FontMetrics fontMetrics = textView.getPaint().getFontMetrics();
        Log.d("textView", "fontMetrics.top        is:" + fontMetrics.top);
        Log.d("textView", "fontMetrics.ascent     is:" + fontMetrics.ascent);
        Log.d("textView", "fontMetrics.descent    is:" + fontMetrics.descent);
        Log.d("textView", "fontMetrics.bottom     is:" + fontMetrics.bottom);
        Log.d("textView", "fontMetrics.leading    is:" + fontMetrics.leading);
    }
}

PaintView.class

public class PaintView extends View {
    private Paint mPaint = new Paint();
    public PaintView(Context context) {
        super(context);
    }
    public PaintView(Context context, AttributeSet attrs) {
        super(context, attrs);
    }
    public PaintView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }
    @Override
    protected void onDraw(Canvas canvas) {
        // TODO Auto-generated method stub
        mPaint.reset();
        mPaint.setColor(Color.WHITE);
        /*设置字体带下80px*/
        mPaint.setTextSize(80);
        //设置字体为斜体
        //mPaint.setTypeface(Typeface.create("", Typeface.ITALIC));
        // FontMetrics对象
        Paint.FontMetrics fontMetrics = mPaint.getFontMetrics();
        String text = "中国话fgiqÃÇŸŒú";
        // 计算每一个坐标
        float textWidth = mPaint.measureText(text);
        float baseX = 0;
        float baseY = 100;
        float topY = baseY + fontMetrics.top;
        float ascentY = baseY + fontMetrics.ascent;
        float descentY = baseY + fontMetrics.descent;
        float bottomY = baseY + fontMetrics.bottom;
        float leading = baseY + fontMetrics.leading;

        Log.d("paintview", "baseX    is:" + baseX);
        Log.d("paintview", "baseY    is:" + baseY);

        Log.d("paintview", "fontMetrics.top        is:" + fontMetrics.top);
        Log.d("paintview", "fontMetrics.ascent     is:" + fontMetrics.ascent);
        Log.d("paintview", "fontMetrics.descent    is:" + fontMetrics.descent);
        Log.d("paintview", "fontMetrics.bottom     is:" + fontMetrics.bottom);
        Log.d("paintview", "fontMetrics.leading    is:" + fontMetrics.leading);

        Log.d("paintview", "topY     is:" + topY);
        Log.d("paintview", "ascentY  is:" + ascentY);
        Log.d("paintview", "descentY is:" + descentY);
        Log.d("paintview", "bottomY  is:" + bottomY);

截面图

PaintView结果

TextView结果

public class MainActivity extends AppCompatActivity {
    TextView textView;
    View paintView;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        paintView = findViewById(R.id.v_fontview);
        textView = (TextView) findViewById(R.id.tv_fontview1);
        String text = "中国话fgiqÃÇŸŒúcqazweyghnhgd;lc,kjssnhjjomoomcod";
        //String text = "中国话fgiqÃÇŸŒú";
        /*设置字体带下80px*/
        textView.setTextSize(TypedValue.COMPLEX_UNIT_PX,80);
        textView.setText(text);

        Paint.FontMetrics fontMetrics = textView.getPaint().getFontMetrics();

        Log.d("textView", "fontMetrics.top        is:" + fontMetrics.top);
        Log.d("textView", "fontMetrics.ascent     is:" + fontMetrics.ascent);
        Log.d("textView", "fontMetrics.descent    is:" + fontMetrics.descent);
        Log.d("textView", "fontMetrics.bottom     is:" + fontMetrics.bottom);
        Log.d("textView", "fontMetrics.leading    is:" + fontMetrics.leading);
    }

<TextView
       android:id="@+id/tv_fontview1"
       android:layout_width="match_parent"
       android:layout_height="wrap_content"
       android:text="中国话fgiqÃÇŸŒúcqazweyghnhgd;lc,kjssnhjjomoomcod"
       android:textColor="@android:color/white"
       android:lineSpacingExtra="5px"
       android:textSize="80px"
       android:layout_weight="1"/>

截面图

结果Log

Note：显然，即使是多行,并且设置5px行距的情况下，仍不能获得leading。

Okhttp设置User-Agent你可能没遇到的坑

• Http Header之User-Agent
     User-Agent中文名为用户代理，是Http协议中的一部分，属于头域的组成部分，User Agent页简称UA。她是一个特殊字符串头，是一种想访问网站提供你说使用的浏览器类型和版本，操作系统和版本，浏览器内核等信息的标识，用户所访问的网站可以显示不同的排版，而为用户提供更好的体验或者进行信息统计

• 获取OkHttp正确的User-Agent

   Okhttp走的并不是原生的http请求，因此他在header里面并没有真正的User-Agent，而是”okhttp/版本号”这样的字符串，因此后台需要统计信息，要求传入正确的User-Agent,那么我们如何User-Agent并设置给Okhttp？

    /**
     * 返回正确的UserAgent
     * @return
     */
    private  static String getUserAgent(){
        String userAgent = "";
        StringBuffer sb = new StringBuffer();
        userAgent = System.getProperty("http.agent");//Dalvik/2.1.0 (Linux; U; Android 6.0.1; vivo X9L Build/MMB29M)

        for (int i = 0, length = userAgent.length(); i < length; i++) {
            char c = userAgent.charAt(i);
            if (c <= '\u001f' || c >= '\u007f') {
                sb.append(String.format("\\u%04x", (int) c));
            } else {
                sb.append(c);
            }
        }

        LogUtils.v("User-Agent","User-Agent: "+ sb.toString());
        return sb.toString();
    }

• 给Okhttp设置User-Agent:

new Request.Builder().url(url).headers(headers2).put(body).removeHeader("User-Agent").addHeader("User-Agent",getUserAgent()).build();

在平时的开发过程中，难免会遇到这样那样的难题，或者一些繁琐且不想纯手工完成的功能，对于这些问题，解决的姿势有很多种，可以通过同事间的交流、上网查资料、去官网找文档等，随着开源的推动和完善，寻找合适的开源项目支持，绝对是一个很好的方法。

如今市面上的开源项目鱼龙混在，并且有一些项目早已停止更新维护，跑demo的时候，怎么用怎么正确，已放入项目，却发现哪哪都不合适，比如低版本下才适合，高版本删去一些方法，再或者与一些新技术的包冲突等，在众多开源项目中，我们应该以何种姿势去选择最佳方案，本内容讲根据以下几项展开分析：

1. 正确理解、确定需求
2. 兼容性
3. 健全性
4. 实现原理
5. 性能
6. 功能与扩展
7. 集成性

四年多实际开发经验，多个项目的积累，在代码中经历了太多的喜怒哀乐，阅读过多个开源框架，对于第三方集成有很深的体会，一切尽在本次的gitchat中与你分享，^_^

微信扫描下面二维码

自定义水平和圆形ProgressBar样式

1.自定义水平ProgressBar样式

• ProgressBar分为两种，我们能明确看到进度，不确定的就是不清楚、不确定一个操作需要多长时间来完成，这个时候就需要用的不确定的ProgressBar了。
• ProgressBar（Horizontal　才有，无进度的没有）有两个进度，一个是android:progress，另一个是android:secondaryProgress。后者主要是为缓存需要所涉及的，比如在看网络视频时候都会有一个缓存的进度条以及还要一个播放的进度，在这里缓存的进度就可以是android:secondaryProgress，而播放进度就是android:progress，有了secondProgress，可以很方便定制ProgressBar。

1.ProgressBar的样式设定其实有两种方式，在API文档中说明的方式如下：

• Widget.ProgressBar.Horizontal
• Widget.ProgressBar.Small
• Widget.ProgressBar.Large
• Widget.ProgressBar.Inverse
• Widget.ProgressBar.Small.Inverse
• Widget.ProgressBar.Large.Inverse

使用的时候可以这样：style=”@android:style/Widget.ProgressBar.Horizontal”
另外还有一种方式就是使用系统的attr，下面的方式是系统的style：

• style=”?android:attr/progressBarStyle”
• style=”?android:attr/progressBarStyleHorizontal”
• style=”?android:attr/progressBarStyleInverse”
• style=”?android:attr/progressBarStyleLarge”
• style=”?android:attr/progressBarStyleLargeInverse”
• style=”?android:attr/progressBarStyleSmall”
• style=”?android:attr/progressBarStyleSmallInverse”
• style=”?android:attr/progressBarStyleSmallTitle”

比如：

<ProgressBar
    android:id="@+id/progressBar"
    style="@android:style/Widget.ProgressBar.Horizontal"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

ProgressBar
    android:id="@+id/progressBar"
    style="?android:attr/progressBarStyleHorizontal"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

我们去看看style=”@android:style/Widget.ProgressBar.Horizontal”　的源码

 <style name="Widget.ProgressBar.Horizontal">
        <item name="indeterminateOnly">false</item>
        <!-- 进度条的背景，progress ,secondaryProgress 的颜色-->
        <item name="progressDrawable">@drawable/progress_horizontal</item>
        <item name="indeterminateDrawable">@drawable/progress_indeterminate_horizontal</item>
        <item name="minHeight">20dip</item>
        <item name="maxHeight">20dip</item>
        <item name="mirrorForRtl">true</item>
    </style>

下面看@android:drawable/progress_horizontal的源码

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (C) 2008 The Android Open Source Project

     Licensed under the Apache License, Version 2.0 (the "License");
     you may not use this file except in compliance with the License.
     You may obtain a copy of the License at

          http://www.apache.org/licenses/LICENSE-2.0

     Unless required by applicable law or agreed to in writing, software
     distributed under the License is distributed on an "AS IS" BASIS,
     WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
     See the License for the specific language governing permissions and
     limitations under the License.
-->

<layer-list xmlns:android="http://schemas.android.com/apk/res/android">
    <!--背景色-->
    <item android:id="@android:id/background">
        <shape>
            <corners android:radius="5dip" />
            <gradient
                    android:startColor="#ff9d9e9d"
                    android:centerColor="#ff5a5d5a"
                    android:centerY="0.75"
                    android:endColor="#ff747674"
                    android:angle="270"
            />
        </shape>
    </item>
      <!--第二进度条颜色-->
    <item android:id="@android:id/secondaryProgress">
        <clip>
            <shape>
                <corners android:radius="5dip" />
                <gradient
                        android:startColor="#80ffd300"
                        android:centerColor="#80ffb600"
                        android:centerY="0.75"
                        android:endColor="#a0ffcb00"
                        android:angle="270"
                />
            </shape>
        </clip>
    </item>
      <!--第一进度条颜色-->
    <item android:id="@android:id/progress">
        <clip>
            <shape>
                <corners android:radius="5dip" />
                <gradient
                        android:startColor="#ffffd300"
                        android:centerColor="#ffffb600"
                        android:centerY="0.75"
                        android:endColor="#ffffcb00"
                        android:angle="270"
                />
            </shape>
        </clip>
    </item>   
</layer-list>

三个条目，对应了background，progress，secondaryProgress。所以只需要修改对应项就可以了，如下在drawable文件中创建一个　progressbar_horizontal_custom.xml
所以其实我们要修改样式的话只需要修改android:progressDrawable”对应的资源就可以

<item name="android:progressDrawable">@drawable/progressbar_horizontal</item><!-- progress_horizontal -->

video_view_bottom_progressbar_background.xml

<?xml version="1.0" encoding="utf-8"?>
<layer-list xmlns:android="http://schemas.android.com/apk/res/android">

    <item android:id="@android:id/background"
        android:height="2dp"
        android:gravity="center">
        <shape>
            <size android:height="2dp"/>
            <corners android:radius="1dp" />
            <solid android:color="#dcdcdc"/>

        </shape>
    </item>

    <item android:id="@android:id/secondaryProgress"
        android:height="2dp"
        android:gravity="center">
        <clip >
            <shape>
                <size android:height="2dp"/>
                <corners android:radius="5dp" />
                <solid android:color="@android:color/darker_gray"/><!--darker_gray-->
            </shape>
        </clip>
    </item>

    <item android:id="@android:id/progress"
        android:height="2dp"
        android:gravity="center">
        <clip >
            <shape>
                <size android:height="2dp"/>
                <corners android:radius="5dp" />
                <solid android:color="#FF455B"/>
            </shape>
        </clip>
    </item>
</layer-list>

在布局文件xml中使用：

<ProgressBar
        android:id="@+id/pb_video_bottom_progress"
        style="@android:style/Widget.ProgressBar.Horizontal"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_gravity="bottom"
        android:max="100"
        android:maxHeight="2dp"
        android:minHeight="2dp"
        android:progressDrawable="@drawable/video_view_bottom_progressbar_background"
        android:visibility="visible" />

总结：

1. 使用style=”@android:style/Widget.ProgressBar.Horizontal”
2. 重新自自定android:progressDrawable

2.自定义圆形ProgressBar样式

比如

<ProgressBar
    android:id="@+id/progressBar"
    style="@android:style/Widget.ProgressBar.Small"
    android:layout_gravity="center_vertical"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

我们先看Widget.Progress的源码：

<style name="Widget.ProgressBar.Small">
        <!--圆形背景-->
        <item name="indeterminateDrawable">@drawable/progress_small_white</item>
        <item name="minWidth">16dip</item>
        <item name="maxWidth">16dip</item>
        <item name="minHeight">16dip</item>
        <item name="maxHeight">16dip</item>
    </style>

@drawable/progress_small_white的源码：

<animated-rotate 
   xmlns:android="http://schemas.android.com/apk/res/android"
   android:drawable="@drawable/spinner_white_48"
   android:pivotX="50%"
   android:pivotY="50%"
   android:framesCount="12"
   android:frameDuration="100" />

发现其实就是一个不断重复的旋转动画是spinner_white_48的图片，所以我们只需要自定义name=”indeterminateDrawable”的属性，自定义自己的drawable使用animated-rotate 标签即可
总结：
1.修改indeterminateDrawable属性，编写animated-rotate 标签的drawable，替换系统的

原来的项目在Xcode 8.3.3下行为正常,不过今天用Xcode 9.0打开后噩梦开始了,在代码中只要输入任何文字,哪怕是注释,Xcode都会立马编译项目,还顺带编译storyboard.这样一来结果就是:卡成狗了!

尝试重启Xcode,Mac均无效,难道要退回Xcode 8.3.3去?

经过一番搜索,原因却是出乎寻常的简单:在Storyboard里开启了自动刷新,并且你在某个视图中使用了IB_DESIGNABLE特性.

解决很简单,只要官关闭Storyboard中的自动刷新视图选项即可,不过在原来的Xcode 8.3.3里该选项貌似也是打开的,但并没有这个问题.

如果需要在IB中即时看到IB_DESIGNABLE的效果,你可以临时开启这一选项或手动刷新视图.

RecyclerView中EditText和ImageView的ViewHolder复用坑

RecyclerView作为ListView的升级版，目前来讲讲开发过程遇到的坑。

• RecyclerView 中使用 EditText 滚动后数据消失，错乱
  场景：RecyclerView中的每个Item的ViewHolder布局中为都有EditText控件，且ViewHolder实现文本改变监听器TextWatcher，用来在用户输入后将数据取出写入到 列表数据中。
  添加文本后，上下滑动RecyclerView且将Item划出屏幕。如：填写此EditText为1后，滑出屏幕滑回，文本可能变成0后或其他
  结果：对应位置上的EditText未能显示Adapter数据集中对应位置的Text

  /*recyclerview优化的holder*/
    public static abstract class BaseViewHolder<Data> extends RecyclerView.ViewHolder{

        /**
         * 构造
         *
         * @param itemView 初始化根布局
         */
        public BaseViewHolder(View itemView) {
            super(itemView);
             /*不设置，itemview不会铺满屏幕*/
            itemView.setLayoutParams(new RecyclerView.LayoutParams(RecyclerView.LayoutParams.MATCH_PARENT,RecyclerView.LayoutParams.WRAP_CONTENT));
        }

        /**
         * 适配器刷新子项回调
         * @param data
         */
        public abstract void onRefreshView(Data data,int position);

        public final <T> T findViewById(int resId){
            return (T) itemView.findViewById(resId);
        }
    }

    /*ViewHolder*/
    public class ViewHolderContentText extends RecyclerViewBaseAdapter.BaseViewHolder<ArticleContentBean> implements
            TextWatcher,    
    {
        private static final int VIEW_TYPE=3;
        /*编辑框*/
        public EditText contentText;
        public ViewHolderContentText(View itemView) {
            super(itemView);
            contentText= (EditText) itemView.findViewById(R.id.et_text);
            quoteLine=itemView.findViewById(R.id.v_quote_line);
            /*设置文本改变监听器*/
            contentText.addTextChangedListener(this);

        }

        @Override
        public void onRefreshView(ArticleContentBean articleContentBean, int position){
           /*刷新数据*/
             String text=textBean.getContentText();
             contentText.setText(text);
       }
        @Override
        public void beforeTextChanged(CharSequence s, int start, int count, int after) {

        }

        @Override
        public void onTextChanged(CharSequence s, int start, int before, int count) {

        }

        @Override
        public void afterTextChanged(Editable s) {
           /*将写入EditText的文本保存到Adapter的DataList中*/

        }
}

原因：
    乍一看这段代码没有什么问题，但实际上这里有一个很大的坑。通过在 afterTextChanged 方法上增加 Log 记录可以发现，该方法会被多次的调用，其根本原因是因为 EditText 的被重新复用，并且重新绘制！当重绘之后 该回调函数没有获取到填充的数据,还是原来复用的数据。

解决办法：每次填充数据之前先移除 TextWatcher 监听器，然后为 EditText 填充数据 ，最后在为 EditText 添加 TextWatcher 监听器，

/*ViewHolder*/
    public class ViewHolderContentText extends RecyclerViewBaseAdapter.BaseViewHolder<ArticleContentBean> implements
            TextWatcher,    
    {
        private static final int VIEW_TYPE=3;
        /*编辑框*/
        public EditText contentText;
        public ViewHolderContentText(View itemView) {
            super(itemView);
            contentText= (EditText) itemView.findViewById(R.id.et_text);
            quoteLine=itemView.findViewById(R.id.v_quote_line);
            /*设置文本改变监听器*/
            //contentText.addTextChangedListener(this);

        }

        @Override
        public void onRefreshView(ArticleContentBean articleContentBean, int position){
            /**
             * recyclerview中使用editext导致数据混乱情况：必须这样设置TextWatcher
             * 
             */

            //1,为了避免TextWatcher在第2步被调用，提前将他移除
            if (contentText.getTag(R.id.tag_textWatcher_data) instanceof TextWatcher){
                contentText.removeTextChangedListener(this);
            }
            //2,移除TextWatcher之后，设置EditText的Text。
             String text=textBean.getContentText();
             contentText.setText(text);
            //3，重新添加 TextWatcher 监听器
            contentText.addTextChangedListener(this);
            //4,将TextWatcher绑定到EditText
            contentText.setTag(R.id.tag_textWatcher_data,this);
       }
        @Override
        public void beforeTextChanged(CharSequence s, int start, int count, int after) {

        }

        @Override
        public void onTextChanged(CharSequence s, int start, int before, int count) {

        }

        @Override
        public void afterTextChanged(Editable s) {
           /*将写入EditText的文本保存到Adapter的DataList中*/
        }
}

• RecyclerView 中使用 ImageView滚动后图片闪烁，图片切换明显

未完待续…

参考链接：
1.踩坑记-在 RecyclerView 中使用 EditText 滚动后数据消失
2. RecyclerView中使用EditText
3.小心！Listview结合EditText使用实例中遇到的那些坑

       Chromium为网页的<embed>标签创建了Plugin之后，Plugin就负责渲染<embed>标签的内容。Chromium为Plugin提供了OpenGL接口，使得Plugin可在网页上渲染3D内容。当然，我们也可通过WebGL接口在网页上渲染3D内容。不过，前者渲染效率会更高些，因为它是Native接口，后者是JavaScript接口。本文接下来就详细分析Plugin执行3D渲染的过程。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

       我们分析Plugin执行3D渲染的过程，更多的是为了理解Chromium与Plugin的交互过程，包括Chromium操作Plugin的过程，以及Plugin调用Chromium提供的接口的过程。接下来我们就以Chromium插件（Plugin）机制简要介绍和学习计划一文提到的GLES2 Example为例，分析Plugin执行3D渲染的过程。

       从前面Chromium网页加载过程简要介绍和学习计划这个系列的文章可以知道，WebKit会将网页抽象为一个DOM Tree。网页中的每一个<embed>标签在这个DOM Tree中都会有一个对应的节点。从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章又可以知道，网页的DOM Tree又会被Chromium转化为一个CC Layer Tree。其中，DOM Tree中的<embed>节点将对应于CC Layer Tree中的一个Texture Layer，如图1所示：

图1 DOM Tree中的<embed>标签与CC Layer Tree中的Texture Layer

       Plugin在调用Chromium提供的OpenGL接口的时候，实际上是将<embed>标签的内容渲染在它在CC Layer Tree中对应的Texture Layer上。当Chromium对网页的CC Layer Tree进行绘制的时候，它内部的Texture Layer的内容就会显示在屏幕上。Texture Layer描述的实际上是一个纹理。在前面Chromium硬件加速渲染的UI合成过程分析一文中，我们提到，网页的canvas标签在CC Layer Tree同样是对应有一个Texture Layer。因此，<embed>标签对应的Texture Layer与canvas标签对应的Texture Layer显示在屏幕上的过程是一样的。这一点可以参考前面Chromium硬件加速渲染的UI合成过程分析一文。

       在Android平台上，Chromium提供给Plugin调用的OpenGL接口称为PPB_OPENGLES2_INTERFACE接口。PPB_OPENGLES2_INTERFACE接口提供了一系列的函数，每一个函数都对应于一个glXXX接口，如图2所示：

图2 Plugin调用OpenGL接口的过程

       在调用PPB_OPENGLES2_INTERFACE接口提供的函数时，GLES2Implementation类的相应成员函数会被调用。例如，当PPB_OPENGLES2_INTERFACE接口提供的函数ActiveTexture被调用时，GLES2Implementation类的成员函数ActiveTexture。GLES2Implementation类的成员函数会将要执行的GPU命令写入到一个缓冲区中去，然后通过一个PpapiCommandBufferProxy对象通知Render进程执行缓冲区中的GPU命令。Render进程又会通过一个CommandBufferProxyImpl对象将要执行的GPU命令转发给GPU进程中的一个GpuCommandBufferStub处理。这意味Plugin最终是通过GPU进程执行GPU命令的。关于GLES2Implementation、CommandBufferProxyImpl和GpuCommandBufferStub这三类执行GPU命令的过程，可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

       Plugin在通过PPB_OPENGLES2_INTERFACE接口执行OpenGL函数（GPU命令）之前，首先要初始化一个OpenGL环境。这个初始化操作发生在Plugin第一次知道自己的视图大小时，也就是知道它对应的<embed>标签的视图大小时。初始化过程如图3所示：

图3 Plugin的OpenGL环境初始化过程

       Plugin的视图大小是由WebKit计算出来的。计算出来之后，WebKit会通过运行在Render进程中的Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象，向运行Plugin进程中的Plugin Instance发出通知。Plugin Instance获得了这个通知之后，就可以初始化一个OpenGL环境了。

       Plugin Instance Proxy是通过调用PPP_INSTANCE_INTERFACE_1_1接口提供的一个函数DidChangeView向Plugin Instance发出通知的，后者又是通过向目标Plugin进程发送一个类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息发出该通知的。

       类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息携带了一个参数PpapiMsg_PPPInstance_DidChangeView。这个参数描述的是一个Routing ID，表示Plugin进程要将类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息交给一个PPP_Instance_Proxy对象处理。这个PPP_Instance_Proxy对象获得该消息后，又会在当前Plugin进程中获得一个PPP_INSTANCE_INTERFACE_1_1接口，并且调用该接口提供的函数DidChangeView。该函数会找到目标Plugin Instance，并且调用它的成员函数DidChangeView。这样，Plugin Instance就可以初始化OpenGL环境了。以我们在前面Chromium插件（Plugin）机制简要介绍和学习计划一文提到的GLES2 Example为例，它的成员函数DidChangeView就通过调用另外一个成员函数InitGL初始化OpenGL环境的。

       Plugin在初始化OpenGL环境的过程中，有两件重要的事情要做。第一件事情是创建一个OpenGL上下文，过程如图4所示：

图4 Plugin的OpenGL上文创建过程

       在Plugin进程中，OpenGL上下文通过Graphics3D类描述。因此，创建OpenGL上下文意味着是创建一个Graphics3D对象。这个Graphics3D对象在创建的过程中，会调用PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的一个函数Create。该函数又会通过一个APP_ID_RESOURCE_CREATION接口向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息。在Plugin进程中，APP_ID_RESOURCE_CREATION接口是通过一个ResourceCreationProxy对象实现的，因此，Plugin进程实际上是通过ResourceCreationProxy类向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息的。

       Plugin进程在向Render进程发送类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息时，会指定一个参数APP_ID_PPB_GRAPHICS_3D，表示Render进程在接收到该消息后，要将其分发给一个PPB_Graphics3D_Proxy对象处理。这个PPB_Graphics3D_Proxy对象又会通过调用PPB_Graphics3D_Impl类的静态成员函数CreateRaw创建一个PPB_Graphics3D_Impl对象。这个PPB_Graphics3D_Impl对象在Render进程描述的就是一个OpenGL上下文。

       Plugin在初始化OpenGL环境的过程中做的第二件事情就是将刚刚创建出来的OpenGL上下文指定为当前要使用的OpenGL上下文。这个过程称为OpenGL上下文绑定，如图5所示：

图5 Plugin绑定OpenGL上下文的过程

       Plugin是通过调用PPB_INSTANCE_INTERFACE_1_0接口提供的函数BindGraphics进行OpenGL上下文绑定的。该函数又会通过一个APP_ID_PPB_INSTANCE接口向Render进程发送一个类型为PpapiHostMsg_PPBIntance_BindGraphics的IPC消息。在Plugin进程中，APP_ID_PPB_INSTANCE接口是通过一个PPB_Instance_Proxy对象实现的，因此，Plugin进程实际上是通过PPB_Instance_Proxy类向Render进程发送一个类型为PpapiHostMsg_PPBIntance_BindGraphics的IPC消息的。

       Plugin进程在向Render进程发送类型为PpapiHostMsg_PPBIntance_BindGraphics的IPC消息时，会指定一个参数APP_ID_PPB_INSTANCE，表示Render进程在接收到该消息后，要将其分发给一个PPB_Instance_Proxy对象处理。这个PPB_Instance_Proxy对象又会找到目标Plugin Instance在Render进程中对应的Proxy，也就是一个PepperPluginInstanceImpl对象，并且调用该PepperPluginInstanceImpl对象的成员函数BindGraphics。

       PepperPluginInstanceImpl类的成员函数BindGraphics在执行的过程中，会将指定的OpenGL上下文，也就是前面创建一个PPB_Graphics3D_Impl对象标记为被绑定，这样它接下来就会作为Plugin当前使用的OpenGL上下文了。

       OpenGL环境初始化完成之后，Plugin就可以使用图2所示的PPB_OPENGLES2_INTERFACE接口来执行3D渲染了。一帧渲染完毕，Plugin需要交换当前使用的OpenGL上下文的前后两个缓冲区，也就是执行一个SwapBuffers操作。这个操作的执行过程如图6所示：

图6 Plugin执行SwapBuffers操作的过程

      前面提到，在Plugin进程中，OpenGL上下文是通过一个Graphics3D对象描述的。这个Graphics3D对象可以通过PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的成员函数SwapBuffers完成SwapBuffers操作。

      PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的成员函数SwapBuffers在执行的过程中，会向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_SwapBuffers的IPC消息。这个消息携带了一个参数API_ID_PPB_GRAPHICS_3D，表示Render进程需要将该消息分发给一个PPB_Graphics3D_Proxy对象处理。这个PPB_Graphics3D_Proxy对象会找到Plugin当前绑定的OpenGL上下文，也就是一个PPB_Graphics3D_Impl对象，并且调用该PPB_Graphics3D_Impl对象的成员函数DoSwapBuffers。这时候就可以完成一个SwapBuffers操作，从而也完成一个帧的渲染流程。

      接下来，我们就从WebKit通知Plugin视图大小开始，分析Plugin执行3D渲染的完整流程。从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，WebKit为<embed>标签创建了一个Plugin Instance之后，会将其放在一个由WebPluginContainerImpl类描述的Plugin View中。当<embed>标签的视图大小发生变化时，WebPluginContainerImpl类的成员函数reportGeometry就会被调用，它的实现如下所示：

void WebPluginContainerImpl::reportGeometry()
{
    ......

    IntRect windowRect, clipRect;
    Vector<IntRect> cutOutRects;
    calculateGeometry(frameRect(), windowRect, clipRect, cutOutRects);

    m_webPlugin->updateGeometry(windowRect, clipRect, cutOutRects, isVisible());

    ......
}

       WebPluginContainerImpl类的成员函数reportGeometry首先是调用成员函数calulateGeometry计算<embed>标签的视图大小，然后再将计算得到的信息告知Content层，这是通过成员变量m_webPlugin指向的一个PepperWebPluginImpl对象的成员函数updateGeometry实现的。这个PepperWebPluginImpl对象的创建过程可以参考前面Chromium的Plugin进程启动过程分析一文。

       接下来我们继续分析PepperWebPluginImpl类的成员函数updateGeometry的实现，以便了解Render进程通知Plugin它描述的<embed>标签的大小的过程，如下所示：

void PepperWebPluginImpl::updateGeometry(
    const WebRect& window_rect,
    const WebRect& clip_rect,
    const WebVector<WebRect>& cut_outs_rects,
    bool is_visible) {
  plugin_rect_ = window_rect;
  if (!instance_->FlashIsFullscreenOrPending()) {
    std::vector<gfx::Rect> cut_outs;
    for (size_t i = 0; i < cut_outs_rects.size(); ++i)
      cut_outs.push_back(cut_outs_rects[i]);
    instance_->ViewChanged(plugin_rect_, clip_rect, cut_outs);
  }
}

       PepperWebPluginImpl类的成员变量instance_指向的是一个PepperPluginInstanceImpl对象。从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，这个PepperPluginInstanceImpl对象是用来在Render进程中描述一个Plugin Instance Proxy的。

       PepperWebPluginImpl类的成员函数updateGeometry首先调用上述PepperPluginInstanceImpl对象的成员函数FlashIsFullscreenOrPending判断当前正在处理的Plugin是否是一个Flash Plugin。如果是一个Flash Plugin，并且它当前处于全屏状态或者即将进入全屏状态，那么PepperWebPluginImpl类的成员函数updateGeometry就不会通知Plugin它描述的<embed>标签的视图大小发生了变化。

       我们假设当前正在处理的Plugin不是一个Flash Plugin。这时候PepperWebPluginImpl类的成员函数updateGeometry就会调用上述PepperPluginInstanceImpl对象的成员函数ViewChanged通知Plugin它描述的<embed>标签的视图大小发生了变化。

       PepperPluginInstanceImpl类的成员函数ViewChanged的实现如下所示：

void PepperPluginInstanceImpl::ViewChanged(
    const gfx::Rect& position,
    const gfx::Rect& clip,
    const std::vector<gfx::Rect>& cut_outs_rects) {
  ......

  view_data_.rect = PP_FromGfxRect(position);
  view_data_.clip_rect = PP_FromGfxRect(clip);
  ......

  SendDidChangeView();
}

       PepperPluginInstanceImpl类的成员函数ViewChanged首先将当前正在处理的Plugin描述的<embed>标签的视图大小信息保存在成员变量view_data_描述的一个ppapi::ViewData对象中，然后再调用另外一个成员函数SendDidChangeView向运行在Plugin进程中的Plugin Instance发送一个视图大小变化通知。

       PepperPluginInstanceImpl类的成员函数SendDidChangeView的实现如下所示：

void PepperPluginInstanceImpl::SendDidChangeView() {
  ......

  ScopedPPResource resource(
      ScopedPPResource::PassRef(),
      (new PPB_View_Shared(ppapi::OBJECT_IS_IMPL, pp_instance(), view_data_))
          ->GetReference());
  ......

  if (instance_interface_) {
    instance_interface_->DidChangeView(
        pp_instance(), resource, &view_data_.rect, &view_data_.clip_rect);
  }
}

       这个函数定义在文件external/chromium_org/content/renderer/pepper/pepper_plugin_instance_impl.cc中。

       PepperPluginInstanceImpl类的成员函数SendDidChangeView首先是将成员变量view_data_描述的ppapi::ViewData对象封装在一个PPB_View_Shared对象。从前面的分析可以知道，被封装的ppapi::ViewData对象描述的当前正在处理的Plugin描述的<embed>标签的视图大小信息。封装得到的PPB_View_Shared对象接下来会传递给PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidChangeView使用。

       从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，PepperPluginInstanceImpl类的成员变量instance_interface_指向的是一个PPP_Instance_Combined对象。这个PPP_Instance_Combined对象描述的是一个PPP_INSTANCE_INTERFACE_1_1接口。运行在Render进程中的Plugin Instance Proxy可以通过这个接口与运行在Plugin进程中的Plugin Instance通信。

       PepperPluginInstanceImpl类的成员函数SendDidChangeView主要就是调用上述PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidChangeView通知运行在Plugin进程中的Plugin Instance，它描述的<embed>标签的视图大小发生了变化，也就是通过调用成员变量instance_interface_指向的PPP_Instance_Combined对象的成员函数DidChangeView进行通知。

       PPP_Instance_Combined类的成员函数DidChangeView的实现如下所示：

void PPP_Instance_Combined::DidChangeView(PP_Instance instance,
                                          PP_Resource view_changed_resource,
                                          const struct PP_Rect* position,
                                          const struct PP_Rect* clip) {
  if (instance_1_1_.DidChangeView) {
    CallWhileUnlocked(
        instance_1_1_.DidChangeView, instance, view_changed_resource);
  } 

  ......
}

       从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，PPP_Instance_Combined类的成员变量instance_1_1_描述的是一个PPP_Instance_1_1对象。这个PPP_Instance_1_1对象描述的就是上述的PPP_INSTANCE_INTERFACE_1_1接口。PPP_Instance_Combined类的成员函数DidChangeView通过一个帮助函数CallWhilleUnlocked调用这个PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidChangeView，以便向运行在Plugin进程中的Plugin Instance发出一个视图大小变化通知。

       从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文还可以知道，上述PPP_INSTANCE_INTERFACE_1_1接口提供的函数DidChangeView实现在ppp_instance_proxy.cc文件中，如下所示：

void DidChangeView(PP_Instance instance, PP_Resource view_resource) {
  HostDispatcher* dispatcher = HostDispatcher::GetForInstance(instance);

  EnterResourceNoLock<PPB_View_API> enter_view(view_resource, false);
  ......

  dispatcher->Send(new PpapiMsg_PPPInstance_DidChangeView(
      API_ID_PPP_INSTANCE, instance, enter_view.object()->GetData(),
      flash_fullscreen));
}

       参数instance的类型为PP_Instance。PP_Instance描述的实际上是一个32位的有符号整数。这个32位的有符号整数是用来描述一个Plugin的ID。通过这个ID，运行在Render进程中的Plugin Instance Proxy与运行在Plugin进程中的Plugin Instance就能一一对应起来的。

       函数DidChangeView首先通过调用HostDispatcher类的静态成员函数GetForInstance获得一个HostDispatcher对象。从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，每一个Plugin进程在Render进程中都有一个对应的HostDispatcher对象。这个HostDispatcher对象就是用来与它对应的Plugin进程通信的。给出一个PP_Instance，HostDispatcher类的静态成员函数GetForInstance就可以获得这个PP_Instance描述的Plugin Instance所运行在的Plugin进程对应的HostDispatcher对象。

       获得了目标Plugin进程对应的HostDispatcher对象之后，就可以向它发送一个类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息。这个IPC消息携带了四个参数：

       1. API_ID_PPP_INSTANCE，要求Plugin进程将该IPC消息分发给API_ID_PPP_INSTANCE接口处理。

       2. instance，表示目标Plugin Instance。

       3. ppapi::ViewData，表示目标Plugin Instance的当前视图大小。

       4. flash_fullscreen，表示目标Plugin Instance是否处于全屏状态。

       其中，第3个参数描述的ppapi::ViewData对象来自于前面在PepperPluginInstanceImpl类的成员函数SendDidChangeView中封装的PPB_View_Shared对象。这个PPB_View_Shared对象对象是通过函数DidChangeView的第2个参数view_resource传递进来的。

       函数DidChangeView首先将上述PPB_View_Shared对象封装在一个EnterResourceNoLock<PPB_View_API>对象中。接下来通过调用这个EnterResourceNoLock<PPB_View_API>对象的成员函数object就可以获得它封装的PPB_View_Shared对象。再调用这个PPB_View_Shared对象的成员函数GetData即可以获得它内部封装的一个ppapi::ViewData对象。这个ppapi::ViewData对象内部保存了目标Plugin Instance的当前视图大小信息，因此可以作为上述IPC消息的第3个参数。

       从前面Chromium的Plugin进程启动过程分析一文可以知道，每一个Plugin进程都存在一个PluginDispatcher对象。Plugin进程将会通过这个PluginDispatcher对象的成员函数OnMessageReceived接收Render进程发送过来的IPC消息。这意味着前面从Render进程发送过来的类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息是通过PluginDispatcher类的成员函数OnMessageReceived接收的。

       PluginDispatcher类的成员函数OnMessageReceived是从父类Dispatcher继承下来的，它的实现如下所示：

bool Dispatcher::OnMessageReceived(const IPC::Message& msg) {  
  ......  
  
  InterfaceProxy* proxy = GetInterfaceProxy(  
      static_cast<ApiID>(msg.routing_id()));  
  ......  
  
  return proxy->OnMessageReceived(msg);  
}  

       从前面的分析可以知道，此时参数msg指向的Message对象描述的是一个类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息，该消息的Routing ID为API_ID_PPP_INSTANCE，表示要将该消息分发给一个API_ID_PPP_INSTANCE接口处理。这个API_ID_PPP_INSTANCE接口可以通过调用调用另外一个成员函数GetInterfaceProxy获得。

       在前面Chromium插件（Plugin）实例（Instance）创建过程分析一文中，我们已经分析过Dispatcher类的成员函数GetInterfaceProxy的实现，因此这里不再复述。再结合前面Chromium插件（Plugin）模块（Module）加载过程分析一文，我们可以知道，在Plugin进程中，API_ID_PPP_INSTANCE接口是由一个PPP_Instance_Proxy对象实现的，Dispatcher类的成员函数GetInterfaceProxy接下来会将参数msg描述的类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息分发给它处理，也就是调用它的成员函数OnMessageReceived。

       PPP_Instance_Proxy类的成员函数OnMessageReceived的实现如下所示：

bool PPP_Instance_Proxy::OnMessageReceived(const IPC::Message& msg) {
  ......

  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPP_Instance_Proxy, msg)
    ......
    IPC_MESSAGE_HANDLER(PpapiMsg_PPPInstance_DidChangeView,
                        OnPluginMsgDidChangeView)
    ......
    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}

       从这里可以看到，PPP_Instance_Proxy类的成员函数OnMessageReceived将类型为PpapiMsg_PPPInstance_DidChangeView的IPC消息分发给另外一个成员函数OnPluginMsgDidChangeView处理，如下所示：

void PPP_Instance_Proxy::OnPluginMsgDidChangeView(
    PP_Instance instance,
    const ViewData& new_data,
    PP_Bool flash_fullscreen) {
  ......

  combined_interface_->DidChangeView(instance, resource,
                                     &new_data.rect,
                                     &new_data.clip_rect);
}

       这个函数定义在文件external/chromium_org/ppapi/proxy/ppp_instance_proxy.cc中。

       从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，PPP_Instance_Proxy类的成员变量combined_interface_指向的是一个PPP_Instance_Combined对象。PPP_Instance_Proxy类的成员函数OnPluginMsgDidChangeView主要是调用这个PPP_Instance_Combined对象的成员函数DidChangeView通知参数instance描述的Plugin Instance，它的视图大小发生了变化。

       PPP_Instance_Combined类的成员函数DidChangeView的实现如下所示：

void PPP_Instance_Combined::DidChangeView(PP_Instance instance,
                                          PP_Resource view_changed_resource,
                                          const struct PP_Rect* position,
                                          const struct PP_Rect* clip) {
  if (instance_1_1_.DidChangeView) {
    CallWhileUnlocked(
        instance_1_1_.DidChangeView, instance, view_changed_resource);
  } 
  ......
}

       从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，PPP_Instance_Combined类的成员变量instance_1_1_指向的是一个PPP_Instance对象。这个PPP_Instance对象的成员变量DidChangeView是一个函数指针，它指向的函数为Instance_DidChangeView。PPP_Instance_Combined类的成员函数DidCreate主要是调用这个函数通知参数instance描述的Plugin Instance，它的视图大小发生了变化。

       函数Instance_DidChangeView的实现，如下所示：

void Instance_DidChangeView(PP_Instance pp_instance,
                            PP_Resource view_resource) {
  Module* module_singleton = Module::Get();
  ......
  Instance* instance = module_singleton->InstanceForPPInstance(pp_instance);
  ......
  instance->DidChangeView(View(view_resource));
}

       函数Instance_DidChangeView首先调用Module类的静态成员函数Get获得当前Plugin进程中的一个pp::Module单例对象。从前面Chromium插件（Plugin）模块（Module）加载过程分析一文可以知道，这个pp::Module单例对象描述的就是在当前Plugin进程中加载的Plugin Module。

       从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，一个Plugin Module创建的所有Plugin Instance都会以它们的ID为键值，保存在一个std::map中。因此，函数Instance_DidChangeView可以在这个std::map中找到与参数pp_instance对应的Plugin Instance，即一个pp::Instance对象。这个通过调用前面获得的pp::Module单例对象的成员函数InstanceForPPInstance实现的。获得了目标pp::Instance对象之后，就可以调用它的成员函数DidChangeView，以便通知它视图大小发生了变化。

       我们在开发一个Plugin的时候，会自定义一个pp::Instance类。例如，在前面Chromium插件（Plugin）机制简要介绍和学习计划一文提到的GLES2 Example，它自定义的pp::Instance类为GLES2DemoInstance。自定义的GLES2DemoInstance类是从pp::Instance类继承下来的，并且会重写成员函数DidChangeView。这意味着接下来GLES2DemoInstance类的成员函数DidChangeView会被调用。

       GLES2DemoInstance类的成员函数DidChangeView的实现如下所示：

void GLES2DemoInstance::DidChangeView(
    const pp::Rect& position, const pp::Rect& clip_ignored) {
  ......
  plugin_size_ = position.size();

  // Initialize graphics.
  InitGL(0);
}

       参数position描述的一个pp::Rect对象记录了当前正在处理的Plugin Instance的当前视图大小。GLES2DemoInstance类的成员函数DidChangeView首先将这个视图大小记录在成员变量plugin_size_中，接下来又调用另外一个成员函数InitGL初始化一个OpenGL环境。

       GLES2DemoInstance类的成员函数InitGL的实现如下所示：

void GLES2DemoInstance::InitGL(int32_t result) {
  ......

  if (context_) {
    context_->ResizeBuffers(plugin_size_.width(), plugin_size_.height());
    return;
  }
  int32_t context_attributes[] = {
    PP_GRAPHICS3DATTRIB_ALPHA_SIZE, 8,
    PP_GRAPHICS3DATTRIB_BLUE_SIZE, 8,
    PP_GRAPHICS3DATTRIB_GREEN_SIZE, 8,
    PP_GRAPHICS3DATTRIB_RED_SIZE, 8,
    PP_GRAPHICS3DATTRIB_DEPTH_SIZE, 0,
    PP_GRAPHICS3DATTRIB_STENCIL_SIZE, 0,
    PP_GRAPHICS3DATTRIB_SAMPLES, 0,
    PP_GRAPHICS3DATTRIB_SAMPLE_BUFFERS, 0,
    PP_GRAPHICS3DATTRIB_WIDTH, plugin_size_.width(),
    PP_GRAPHICS3DATTRIB_HEIGHT, plugin_size_.height(),
    PP_GRAPHICS3DATTRIB_NONE,
  };
  context_ = new pp::Graphics3D(this, context_attributes);
  ......
  assert(BindGraphics(*context_));

  ......

  FlickerAndPaint(0, true);
}

       初始化Plugin的OpenGL环境需要执行两个操作：

       1. 创建一个OpenGL上下文。这个OpenGL上下文用一个pp::Graphics3D对象描述。

       2. 将创建出来的OpenGL上下文与Plugin进行绑定，也就是将它指定为Plugin当前使用的OpenGL上下文。这可以通过调用父类pp::Instance继承下来的成员函数BindGraphics来完成。

       GLES2DemoInstance类的成员变量context_就是用来描述Plugin当前使用的OpenGL上下文。如果这个OpenGL上下文还没有创建，那么GLES2DemoInstance类的成员函数InitGL就会根据Plugin当前的视图大小进行创建。否则的话，就只会改变这个OpenGL上下文描述的绘图缓冲区的大小。

       完成以上两个操作之后，GLES2DemoInstance类的成员函数InitGL就会调用另外一个成员函数FlickerAndPaint渲染Plugin的视图。渲染出来的内容最后就会合成在网页的UI中显示出来。

       接下来我们先分析OpenGL上下文的创建过程，也就是一个pp::Graphics3D对象的创建过程，我们pp::Graphics3D类的构造函数开始分析，它的实现如下所示：

Graphics3D::Graphics3D(const InstanceHandle& instance,
                       const int32_t attrib_list[]) {
  if (has_interface<PPB_Graphics3D_1_0>()) {
    PassRefFromConstructor(get_interface<PPB_Graphics3D_1_0>()->Create(
        instance.pp_instance(), 0, attrib_list));
  }
}

       pp::Graphics3D类的构造函数首行调用模板函数has_interface<PPB_Graphics3D_1_0>检查在当前Plugin进程中加载的Plugin Module是否支持PPB_GRAPHICS_3D_INTERFACE_1_0。如果支持的话，那么就会再调用另外一个模板函数get_interface<PPB_Graphics3D_1_0>获得这个PPB_GRAPHICS_3D_INTERFACE_1_0接口。获得了PPB_GRAPHICS_3D_INTERFACE_1_0接口之后，就可以调用它提供的函数Create请求Render进程创建一个OpenGL上下文了。

       从后面的分析我们可以知道，PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的函数Create创建出来的OpenGL上下文用一个proxy::proxy::Graphics3D对象描述，不过它返回给调用者的是分配给proxy::proxy::Graphics3D对象的一个资源ID。pp::Graphics3D类的构造函数会调用从父类pp::Resource继承下来的成员函数PassRefFromConstructor将这个资源ID保存在成员变量pp_resource_中，如下所示：

void Resource::PassRefFromConstructor(PP_Resource resource) {
  PP_DCHECK(!pp_resource_);
  pp_resource_ = resource;
}

       以后通过调用pp::Resource类的成员函数pp_resource即可以获得这个资源ID，如下所示：

class Resource {
 public:
  ......

  PP_Resource pp_resource() const { return pp_resource_; }

  ......
};

       回到 pp::Graphics3D类的构造函数中，接下来我们首先分析PPB_GRAPHICS_3D_INTERFACE_1_0接口的获取过程，也就是模板函数get_interface<PPB_Graphics3D_1_0>的实现，如下所示：

template <typename T> inline T const* get_interface() {
  static T const* funcs = reinterpret_cast<T const*>(
      pp::Module::Get()->GetBrowserInterface(interface_name<T>()));
  return funcs;
}

       这里的模板参数T为PPB_Graphics3D_1_0，展开后得到模板函数get_interface<PPB_Graphics3D_1_0>的具体实现为：

inline PPB_Graphics3D_1_0 const* get_interface() {
  static PPB_Graphics3D_1_0 const* funcs = reinterpret_cast<PPB_Graphics3D_1_0 const*>(
      pp::Module::Get()->GetBrowserInterface(interface_name<PPB_Graphics3D_1_0>()));
  return funcs;
}

       我们首先分析模板函数interface_name<PPB_Graphics3D_1_0>的实现，以便知道要获取的接口名称是什么，如下所示：

template <> const char* interface_name<PPB_Graphics3D_1_0>() {
  return PPB_GRAPHICS_3D_INTERFACE_1_0;
}

       从这里可以看到，要获取的接口名称为PPB_GRAPHICS_3D_INTERFACE_1_0，也就我们要获取的是PPB_GRAPHICS_3D_INTERFACE_1_0接口。这个接口可以通过调用前面获得的pp::Module单例对象的GetBrowserInterface获得。

       在前面Chromium插件（Plugin）模块（Module）加载过程分析一文中，我们已经分析过了pp::Module类的GetBrowserInterface的实现，并且我们也知道，在Plugin进程中，PPB_GRAPHICS_3D_INTERFACE_1_0接口是由一个PPB_Graphics3D_1_0对象实现的。这个PPB_Graphics3D_1_0对象的定义如下所示：

const PPB_Graphics3D_1_0 g_ppb_graphics3d_thunk_1_0 = {  
  &GetAttribMaxValue,  
  &Create,  
  &IsGraphics3D,  
  &GetAttribs,  
  &SetAttribs,  
  &GetError,  
  &ResizeBuffers,  
  &SwapBuffers  
};  

      这个PPB_Graphics3D_1_0对象的成员变量Create是一个函数指针。这个函数指针指向了函数Create。这个函数也是定义在文件ppb_graphics_3d_thunk.cc中。

      回到Graphics3D类的构造函数中，现在我们就可以知道，它实际上是通过调用上述函数Create请求Render进程为当前正在处理的Plugin创建一个OpenGL上下文的，如下所示：

PP_Resource Create(PP_Instance instance,
                   PP_Resource share_context,
                   const int32_t attrib_list[]) {
  ......
  EnterResourceCreation enter(instance);
  ......
  return enter.functions()->CreateGraphics3D(instance,
                                             share_context,
                                             attrib_list);
}

       OpenGL上下文属于一种资源。在Plugin中，创建资源要使用到接口API_ID_RESOURCE_CREATION。函数Create通过构造一个EnterResourceCreation对象来封装对接口API_ID_RESOURCE_CREATION的调用。封装过程如下所示：

EnterResourceCreation::EnterResourceCreation(PP_Instance instance)
    : EnterBase(),
      functions_(PpapiGlobals::Get()->GetResourceCreationAPI(instance)) {
  ......
}

       在Plugin进程中，存在一个PluginGlobals单例对象。这个PluginGlobals单例对象可以通过调用PpapiGlobals类的静态成员函数获得。注意，PluginGlobals类是从PpapiGlobals继承下来的。

       获得上述PluginGlobals单例对象之后，EnterResourceCreation类的构造函数就调用它的成员函数GetResourceCreationAPI获得一个API_ID_RESOURCE_CREATION接口，如下所示：

thunk::ResourceCreationAPI* PluginGlobals::GetResourceCreationAPI(
    PP_Instance instance) {
  PluginDispatcher* dispatcher = PluginDispatcher::GetForInstance(instance);
  if (dispatcher)
    return dispatcher->GetResourceCreationAPI();
  return NULL;
}

       从前面Chromium的Plugin进程启动过程分析一文可以知道，在Plugin进程中加载的Plugin Module对应有一个PluginDispatcher对象。这个PluginDispatcher对象与运行在Render进程中的HostDispatcher对象对应。所有属于该Plugin Module的Instance都使用相同的PluginDispatcher对象与Render进程通信。

       PluginGlobals类的成员函数GetResourceCreationAPI首先调用PluginDispatcher类的静态成员函数GetForInstance获得与参数instance描述的Plugin Instance对应的PluginDispatcher对象。有了这个PluginDispatcher对象之后，就可以调用它的成员函数GetResourceCreationAPI获得一个API_ID_RESOURCE_CREATION接口，如下所示：

thunk::ResourceCreationAPI* PluginDispatcher::GetResourceCreationAPI() {
  return static_cast<ResourceCreationProxy*>(
      GetInterfaceProxy(API_ID_RESOURCE_CREATION));
}

       PluginDispatcher类的成员函数GetResourceCreationAPI调用另外一个成员函数GetInterfaceProxy获得一个API_ID_RESOURCE_CREATION接口。PluginDispatcher类的成员函数GetInterfaceProxy是从父类Dispatcher继承下来的，在前面Chromium插件（Plugin）实例（Instance）创建过程分析一文中，我们已经分析过它的实现了。

       结合前面Chromium插件（Plugin）模块（Module）加载过程分析一文，我们可以知道，在Plugin进程中，API_ID_RESOURCE_CREATION接口被指定为ResourceCreationProxy类的静态成员函数Create，Dispatcher类的成员函数GetInterfaceProxy将会调用这个函数创建一个ResourceCreationProxy对象，如下所示：

InterfaceProxy* ResourceCreationProxy::Create(Dispatcher* dispatcher) {
  return new ResourceCreationProxy(dispatcher);
}

       参数dispatcher指向的是一个PluginDispatcher对象。这个PluginDispatcher对象就是在前面分析的PluginGlobals类的成员函数GetResourceCreationAPI中获取的PluginDispatcher对象。ResourceCreationProxy类的静态成员函数Create使用该PluginDispatcher对象创建了一个ResourceCreationProxy对象，并且返回给最初的调用者，也就是EnterResourceCreation类的构造函数。EnterResourceCreation类的构造函数又会将这个ResourceCreationProxy对象保存在成员变量functions_中。

       这一步执行完成后，回到前面分析的函数Create中。这时候就它构造了一个EnterResourceCreation对象，并且这个EnterResourceCreation对象的成员变量functions_指向了一个ResourceCreationProxy对象。

       函数Create接下来会调用上述EnterResourceCreation对象的成员函数functions它的成员变量functions_指向的ResourceCreationProxy对象。有了这个ResourceCreationProxy对象之后，就可以调用它的成员函数CreateGraphics3D请求Render进程为当前正在处理的Plugin Instance创建一个OpenGL上下文了。

       ResourceCreationProxy类的成员函数CreateGraphics3D的实现如下所示：

PP_Resource ResourceCreationProxy::CreateGraphics3D(
    PP_Instance instance,
    PP_Resource share_context,
    const int32_t* attrib_list) {
  return PPB_Graphics3D_Proxy::CreateProxyResource(
      instance, share_context, attrib_list);
}

       ResourceCreationProxy类的成员函数CreateGraphics3D调用PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource请求Render进程为当前正在处理的Plugin Instance创建一个OpenGL上下文，如下所示：

PP_Resource PPB_Graphics3D_Proxy::CreateProxyResource(
    PP_Instance instance,
    PP_Resource share_context,
    const int32_t* attrib_list) {
  PluginDispatcher* dispatcher = PluginDispatcher::GetForInstance(instance);
  ......

  HostResource share_host;
  gpu::gles2::GLES2Implementation* share_gles2 = NULL;
  if (share_context != 0) {
    EnterResourceNoLock<PPB_Graphics3D_API> enter(share_context, true);
    if (enter.failed())
      return PP_ERROR_BADARGUMENT;

    PPB_Graphics3D_Shared* share_graphics =
        static_cast<PPB_Graphics3D_Shared*>(enter.object());
    share_host = share_graphics->host_resource();
    share_gles2 = share_graphics->gles2_impl();
  }

  std::vector<int32_t> attribs;
  if (attrib_list) {
    for (const int32_t* attr = attrib_list;
         attr[0] != PP_GRAPHICS3DATTRIB_NONE;
         attr += 2) {
      attribs.push_back(attr[0]);
      attribs.push_back(attr[1]);
    }
  }
  attribs.push_back(PP_GRAPHICS3DATTRIB_NONE);

  HostResource result;
  dispatcher->Send(new PpapiHostMsg_PPBGraphics3D_Create(
      API_ID_PPB_GRAPHICS_3D, instance, share_host, attribs, &result));
  ......

  scoped_refptr<Graphics3D> graphics_3d(new Graphics3D(result));
  if (!graphics_3d->Init(share_gles2))
    return 0;
  return graphics_3d->GetReference();
}

       PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource首先调用PluginDispatcher类的静态成员函数GetForInstance获得与参数instance描述的Plugin Instance对应的一个PluginDispatcher对象。后面将会通过这个PluginDispatcher对象向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息，用来请求Render进程创建一个OpenGL上下文了。

       类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息传递了4个参数给Render进程，分别是：

       1. API_ID_PPB_GRAPHICS_3D，表示Render进程要将该IPC消息分发给API_ID_PPB_GRAPHICS_3D接口处理。

       2. instance，描述要创建OpenGL上下文的Plugin Instance。

       3. share_host，描述另外一个OpenGL上下文，新创建的OpenGL上下文要与它在同一个共享组中。

       4. attribs，描述新创建的OpenGL上下文应具有的属性。

       Render进程根据要求为目标Plugin Instance创建了一个OpenGL上下文之后，会为该OpenGL上下文分配一个ID，并且会将该ID返回给Plugin进程。Plugin进程再将这个ID封装在一个HostResource对象，然后将这个HostResource对象返回给PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource。

       PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource再根据获得的HostResource对象创建一个ppapi::proxy::Graphics3D对象，并且调用它的成员函数Init对它进行初始化，相当于是对新创建的OpenGL上下文进行初始化。初始化完成后，就可以进行使用了。

       新创建的Graphics3D对象初始化完成之后，PPB_Graphics3D_Proxy类的静态成员函数CreateProxyResource再调用它的成员函数GetReference获得一个类型为PP_Resource的引用。以后通过这个引用就可以使用该Graphics3D对象，也就是新创建的OpenGL上下文。

       接下来，我们首先分析Render进程为目标Plugin Instance创建OpenGL上下文的过程，即处理类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息的过程，然后再分析新创建的OpenGL上下文在Plugin进程的初始化过程。

       前面提到，Render进程会将类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息分发给API_ID_PPB_GRAPHICS_3D接口处理。从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文可以知道，在Render进程中，API_ID_PPB_GRAPHICS_3D接口是由一个PPB_Graphics3D_Proxy对象实现的，也就是Render进程会将类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息分发给该PPB_Graphics3D_Proxy对象处理，这是通过调用它的成员函数OnMessageReceived实现的。

       类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息在Render进程中的分发过程类似我们在前面Chromium插件（Plugin）实例（Instance）创建过程分析一文提到的类型为PpapiMsg_PPPInstance_DidCreate的IPC消息在Plugin进程中的分发过程，因此这里不再详细描述。

       接下来我们继续分析PPB_Graphics3D_Proxy类的成员函数OnMessageReceived处理类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息的过程，如下所示：

bool PPB_Graphics3D_Proxy::OnMessageReceived(const IPC::Message& msg) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPB_Graphics3D_Proxy, msg)
#if !defined(OS_NACL)
    IPC_MESSAGE_HANDLER(PpapiHostMsg_PPBGraphics3D_Create,
                        OnMsgCreate)
    ......
#endif  // !defined(OS_NACL)

    ......
    IPC_MESSAGE_UNHANDLED(handled = false)

  IPC_END_MESSAGE_MAP()
  // FIXME(brettw) handle bad messages!
  return handled;
}

       从这里可以看到，PPB_Graphics3D_Proxy类的成员函数OnMessageReceived将类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息分发给另外一个成员函数OnMsgCreate处理，如下所示：

void PPB_Graphics3D_Proxy::OnMsgCreate(PP_Instance instance,
                                       HostResource share_context,
                                       const std::vector<int32_t>& attribs,
                                       HostResource* result) {
  ......

  thunk::EnterResourceCreation enter(instance);

  if (enter.succeeded()) {
    result->SetHostResource(
      instance,
      enter.functions()->CreateGraphics3DRaw(instance,
                                             share_context.host_resource(),
                                             &attribs.front()));
  }
}

      参数instance要描述的是要创建OpenGL上下文的Plugin Instance在Render进程中对应的Proxy，也就是一个PepperPluginInstanceImpl对象。PPB_Graphics3D_Proxy类的成员函数OnMsgCreate首先是使用它构造一个EnterResourceCreation对象。前面提到，EnterResourceCreation类是用来封装资源创建接口API_ID_RESOURCE_CREATION的。因此，有了前面构造的EnterResourceCreation对象之后，PPB_Graphics3D_Proxy类的成员函数OnMsgCreate就可以使用API_ID_RESOURCE_CREATION接口来为参数instance描述的Plugin Instance创建一个OpenGL上下文了。

       EnterResourceCreation对象在Render进程的构造过程与在Plugin进程的构造过程是不一样的。前面我们已经分析过EnterResourceCreation对象在Plugin进程的构造过程，接下来我们继续分析EnterResourceCreation对象在Render进程的构造过程，以便了解Render进程是如何实现API_ID_RESOURCE_CREATION接口的。

       我们从EnterResourceCreation类的构造函数开始分析EnterResourceCreation对象在Render进程的构造过程，它的实现如下所示：

EnterResourceCreation::EnterResourceCreation(PP_Instance instance)
    : EnterBase(),
      functions_(PpapiGlobals::Get()->GetResourceCreationAPI(instance)) {
  ......
}

       在Render进程中，存在一个HostGlobals单例对象。这个HostGlobals单例对象可以通过调用PpapiGlobals类的静态成员函数Get获得。HostGlobals类与前面提到的PluginGlobals类一样，都是从PpapiGlobals类继承下来的。

       获得上述HostGlobals单例对象之后，EnterResourceCreation类的构造函数就调用它的成员函数GetResourceCreationAPI获得一个API_ID_RESOURCE_CREATION接口，如下所示：

ppapi::thunk::ResourceCreationAPI* HostGlobals::GetResourceCreationAPI(
    PP_Instance pp_instance) {
  PepperPluginInstanceImpl* instance = GetInstance(pp_instance);
  if (!instance)
    return NULL;
  return &instance->resource_creation();
}

       HostGlobals类的成员函数GetResourceCreationAPI首先调用成员函数GetInstance获得参数pp_instance描述的一个Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象。有了这个PepperPluginInstanceImpl对象之后，就可以调用它的成员函数resource_creation获得一个API_ID_RESOURCE_CREATION接口，如下所示：

class CONTENT_EXPORT PepperPluginInstanceImpl
    : public base::RefCounted<PepperPluginInstanceImpl>,
      public NON_EXPORTED_BASE(PepperPluginInstance),
      public ppapi::PPB_Instance_Shared,
      public NON_EXPORTED_BASE(cc::TextureLayerClient),
      public RenderFrameObserver {
 public:
  ......

  ppapi::thunk::ResourceCreationAPI& resource_creation() {
    return *resource_creation_.get();
  }

  ......

 private:
  ......

  scoped_ptr<ppapi::thunk::ResourceCreationAPI> resource_creation_;

  ......
};

       PepperPluginInstanceImpl类的成员变量resource_creation_指向的是一个PepperInProcessResourceCreation对象。PepperPluginInstanceImpl类的成员函数resource_creation将这个PepperInProcessResourceCreation对象返回给调用者。这意味在Render进程中，API_ID_RESOURCE_CREATION接口是通过PepperInProcessResourceCreation类实现的。

       这一步执行完成后，回到前面分析的PPB_Graphics3D_Proxy类的成员函数OnMsgCreate中。这时候就它构造了一个EnterResourceCreation对象，并且这个EnterResourceCreation对象的成员变量functions_指向了一个PepperInProcessResourceCreation对象。

       PPB_Graphics3D_Proxy类的成员函数OnMsgCreate接下来会调用上述EnterResourceCreation对象的成员函数functions它的成员变量functions_指向的PepperInProcessResourceCreation对象。有了这个PepperInProcessResourceCreation对象之后，就可以调用它的成员函数CreateGraphics3DRaw为参数pp_instance描述的Plugin Instance创建一个OpenGL上下文。

       PepperInProcessResourceCreation类的成员函数CreateGraphics3DRaw是从父类ResourceCreationImpl继承下来的，它的实现如下所示：

PP_Resource ResourceCreationImpl::CreateGraphics3DRaw(
    PP_Instance instance,
    PP_Resource share_context,
    const int32_t* attrib_list) {
  return PPB_Graphics3D_Impl::CreateRaw(instance, share_context, attrib_list);
}

      ResourceCreationImpl类的成员函数CreateGraphics3DRaw调用PPB_Graphics3D_Impl类的静态成员函数CreateRaw为参数pp_instance描述的Plugin Instance创建一个OpenGL上下文，如下所示：

PP_Resource PPB_Graphics3D_Impl::CreateRaw(PP_Instance instance,
                                           PP_Resource share_context,
                                           const int32_t* attrib_list) {
  PPB_Graphics3D_API* share_api = NULL;
  if (share_context) {
    EnterResourceNoLock<PPB_Graphics3D_API> enter(share_context, true);
    if (enter.failed())
      return 0;
    share_api = enter.object();
  }
  scoped_refptr<PPB_Graphics3D_Impl> graphics_3d(
      new PPB_Graphics3D_Impl(instance));
  if (!graphics_3d->InitRaw(share_api, attrib_list))
    return 0;
  return graphics_3d->GetReference();
}

       在Render进程中，Plugin使用的OpenGL上下文通过一个PPB_Graphics3D_Impl对象描述。因此，PPB_Graphics3D_Impl类的静态成员函数CreateRaw会创建一个PPB_Graphics3D_Impl对象，并且调用它的成员函数InitRaw对它进行初始化，也就是对它描述的OpenGL上下文进行初始化。初始化完成后，就会获得它的一个PP_Resource引用。这个引用将会返回给Plugin进程。Plugin进程以后就可以通过这个引用来使用前面创建出来的OpenGL上下文了。

       接下来我们继续分析Render进程为Plugin创建的OpenGL上下文的初始化过程，也就是PPB_Graphics3D_Impl类的成员函数InitRaw的实现，如下所示：

bool PPB_Graphics3D_Impl::InitRaw(PPB_Graphics3D_API* share_context,
                                  const int32_t* attrib_list) {
  ......

  RenderThreadImpl* render_thread = RenderThreadImpl::current();
  ......

  channel_ = render_thread->EstablishGpuChannelSync(
      CAUSE_FOR_GPU_LAUNCH_PEPPERPLATFORMCONTEXT3DIMPL_INITIALIZE);
  ......

  command_buffer_ = channel_->CreateOffscreenCommandBuffer(
      surface_size, share_buffer, attribs, GURL::EmptyGURL(), gpu_preference);
  ......

  return true;
}

       PPB_Graphics3D_Impl类的成员函数InitRaw首先调用RenderThreadImpl类的静态成员函数current获得一个RenderThreadImpl对象。这个RenderThreadImpl对象描述的是当前Render进程的Render线程。有了这个RenderThreadImpl对象之后，就可以调用它的成员函数EstablishGpuChannelSync创建一个GPU通道，也就是一个GpuChannelHost对象。这个GPU通道的详细创建过程，可以参考前面Chromium的GPU进程启动过程分析一文。

       PPB_Graphics3D_Impl类的成员函数InitRaw接下来又会调用前面创建出来的GpuChannelHost对象的成员函数CreateOffscreenCommandBuffer请求GPU进程为其创建一个离屏渲染类型的OpenGL上下文。这个离屏渲染类型的OpenGL上下文是通过一个CommandBufferProxyImpl对象描述的。Render进程请求GPU进程创建OpenGL上下文的过程，可以参考前面Chromium硬件加速渲染的OpenGL上下文创建过程分析一文。以后Plugin执行GPU命令时，将会作用在上述离屏渲染的OpenGL上下文中。

       这一步执行完成后，Render进程就为Plugin创建了一个OpenGL上下文。这个OpenGL上下文通过一个PPB_Graphics3D_Impl对象描述。这个PPB_Graphics3D_Impl对象会被分配一个ID，并且这个ID会返回给Plugin进程。如前所述，Plugin进程获得了这个ID之后，就会将其封装在一个Graphics3D对象中。这个Graphics3D对象是用来Plugin进程描述一个OpenGL上下文的。

       回到前面分析的PPB_Graphics3D_Proxy类的成员函数CreateProxyResource中，这时候它就获得了一个OpenGL上下文之后。这个OpenGL上下文在Plugin进程中同样需要进行初始化。如前所述，这是通过调用ppapi::proxy::Graphics3D类的成员函数Init实现的。接下我们就继续分析Plugin进程初始化一个OpenGL上下文的过程，也就是分析ppapi::proxy::Graphics3D类的成员函数Init的实现，如下所示：

bool Graphics3D::Init(gpu::gles2::GLES2Implementation* share_gles2) {
  ......

  command_buffer_.reset(
      new PpapiCommandBufferProxy(host_resource(), dispatcher));

  return CreateGLES2Impl(kCommandBufferSize, kTransferBufferSize,
                         share_gles2);
}

       ppapi::proxy::Graphics3D类的成员函数Init首先会创建一个PpapiCommandBufferProxy对象。这个PpapiCommandBufferProxy对象是用来与前面在Render进程中创建的CommandBufferProxyImpl对象通信的，也就是前者会将提交给它的GPU命令转发给后者处理，后者又会将接收到的GPU命令发送给GPU进程执行。

       ppapi::proxy::Graphics3D类的成员函数Init接下来又会调用成员函数CreateGLES2Impl根据上述PpapiCommandBufferProxy对象创建一个Command Buffer GL接口。有了这个Command Buffer GL接口之后，Plugin就可以调用它提供的OpenGL函数执行3D渲染了。

       ppapi::proxy::Graphics3D类的成员函数CreateGLES2Impl是从父类PPB_Graphics3D_Shared继承下来的，它的实现如下所示：

bool PPB_Graphics3D_Shared::CreateGLES2Impl(
    int32 command_buffer_size,
    int32 transfer_buffer_size,
    gpu::gles2::GLES2Implementation* share_gles2) {
  gpu::CommandBuffer* command_buffer = GetCommandBuffer();
  DCHECK(command_buffer);

  // Create the GLES2 helper, which writes the command buffer protocol.
  gles2_helper_.reset(new gpu::gles2::GLES2CmdHelper(command_buffer));
  if (!gles2_helper_->Initialize(command_buffer_size))
    return false;

  // Create a transfer buffer used to copy resources between the renderer
  // process and the GPU process.
  const int32 kMinTransferBufferSize = 256 * 1024;
  const int32 kMaxTransferBufferSize = 16 * 1024 * 1024;
  transfer_buffer_.reset(new gpu::TransferBuffer(gles2_helper_.get()));
  ......

  // Create the object exposing the OpenGL API.
  gles2_impl_.reset(new gpu::gles2::GLES2Implementation(
      gles2_helper_.get(),
      share_gles2 ? share_gles2->share_group() : NULL,
      transfer_buffer_.get(),
      bind_creates_resources,
      lose_context_when_out_of_memory,
      GetGpuControl()));

  if (!gles2_impl_->Initialize(
           transfer_buffer_size,
           kMinTransferBufferSize,
           std::max(kMaxTransferBufferSize, transfer_buffer_size),
           gpu::gles2::GLES2Implementation::kNoLimit)) {
    return false;
  }

  ......

  return true;
}

       这个函数定义在文件external/chromium_org/ppapi/shared_impl/ppb_graphics_3d_shared.cc。

       在Chromium中，Command Buffer GL接口是通过GLES2Implementation类描述的。因此，PPB_Graphics3D_Shared类的成员函数CreateGLES2Impl将会创建一个GLES2Implementation对象，并且保存在成员变量gles2_impl_中。

       创建这个GLES2Implementation对象需要一个Command Buffer和一个Transfer Buffer。前者通过一个GLES2CmdHelper对象描述，后者通过一个TransferBuffer对象描述的。在创建GLES2CmdHelper对象的过程中，又需要用到前面创建的一个PpapiCommandBufferProxy对象，以便可以将Plugin要执行的GPU命令转发给Render进程处理。这个PpapiCommandBufferProxy对象可以通过调用PPB_Graphics3D_Shared类的成员函数GetCommandBuffer获得。关于Command Buffer GL接口的创建和使用，可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

       这一步执行完成后，回到前面分析的GLES2DemoInstance类的成员函数InitGL中，这时候它就创建了一个OpenGL上下文，并且这个OpenGL上下文已经初始化完成。接下来，GLES2DemoInstance类的成员函数InitGL会将前面创建出来的OpenGL上下文绑定到当前正在处理的Plugin Instance中去。执行了这个操作之后，Plugin Instance才可以在该OpenGL上下文中执行GPU命令。

       给一个Plugin Instance绑定OpenGL上下文是通过调用pp::Instance类的成员函数BindGraphics实现的，如下所示：

bool Instance::BindGraphics(const Graphics3D& graphics) {
  if (!has_interface<PPB_Instance_1_0>())
    return false;
  return PP_ToBool(get_interface<PPB_Instance_1_0>()->BindGraphics(
      pp_instance(), graphics.pp_resource()));
}

       pp::Instance类的成员函数BindGraphics需要通过PPB_INSTANCE_INTERFACE_1_0接口为当前正在处理的Plugin Instance绑定一个OpenGL上下文。这个OpenGL上下文由参数graphics指向的一个Graphics3D对象描述。

       因此，pp::Instance类的成员函数BindGraphics首先会检查当前的Plugin进程是否支持PPB_INSTANCE_INTERFACE_1_0接口。如果支持的话，那么就会通过一个模板函数get_interface<PPB_Instance_1_0>获得该PPB_INSTANCE_INTERFACE_1_0接口，如下所示：

template <typename T> inline T const* get_interface() {
  static T const* funcs = reinterpret_cast<T const*>(
      pp::Module::Get()->GetBrowserInterface(interface_name<T>()));
  return funcs;
}

       这里的模板参数T为PPB_Instance_1_0，展开后得到模板函数get_interface<PPB_Instance_1_0>的具体实现为：

inline PPB_Instance_1_0 const* get_interface() {
  static PPB_Instance_1_0 const* funcs = reinterpret_cast<PPB_Instance_1_0 const*>(
      pp::Module::Get()->GetBrowserInterface(interface_name<PPB_Instance_1_0>()));
  return funcs;
}

      我们首先分析模板函数interface_name<PPB_Instance_1_0>的实现，以便知道要获取的接口名称是什么，如下所示：

template <> const char* interface_name<PPB_Instance_1_0>() {
  return PPB_INSTANCE_INTERFACE_1_0;
}

       从这里可以看到，要获取的接口名称为PPB_INSTANCE_INTERFACE_1_0，也就我们要获取的是PPB_INSTANCE_INTERFACE_1_0接口。这个接口可以通过调用前面获得的pp::Module单例对象的GetBrowserInterface获得。

       在前面Chromium插件（Plugin）模块（Module）加载过程分析一文中，我们已经分析过了pp::Module类的GetBrowserInterface的实现，并且我们也知道，在Plugin进程中，PPB_INSTANCE_INTERFACE_1_0接口是由一个PPB_Instance_1_0对象实现的。这个PPB_Graphics3D_1_0对象的定义如下所示：

const PPB_Instance_1_0 g_ppb_instance_thunk_1_0 = {
  &BindGraphics,
  &IsFullFrame
};

       这个PPB_Instance_1_0对象的成员变量BindGraphics是一个函数指针。这个函数指针指向了函数BindGraphics。这个函数也是定义在文件ppb_instance_thunk.cc中。

       回到pp::Instance类的成员函数BindGraphics中，现在我们就可以知道，它实际上是通过调用上述函数BindGraphics请求Render进程为当前正在处理的Plugin绑定一个OpenGL上下文的，如下所示：

PP_Bool BindGraphics(PP_Instance instance, PP_Resource device) {
  ......
  EnterInstance enter(instance);
  ......
  return enter.functions()->BindGraphics(instance, device);
}

       这个函数定义在文件external/chromium_org/ppapi/thunk/ppb_instance_thunk.cc中。

       函数BindGraphics需要通过另外一个接口API_ID_PPB_INSTANCE向Render进程发送一个IPC消息，以便请求后者为参数instance描述的Plugin Instance绑定另外一个参数device描述的OpenGL上下文。

       函数BindGraphics是通过EnterInstance类来使用接口API_ID_RESOURCE_CREATION，因此它首先会构造一个EnterInstance对象，如下所示：

EnterInstance::EnterInstance(PP_Instance instance)
    : EnterBase(),
      functions_(PpapiGlobals::Get()->GetInstanceAPI(instance)) {
  ......
}

       前面提到，在Plugin进程中，存在一个PluginGlobals单例对象。这个PluginGlobals单例对象可以通过调用PpapiGlobals类的静态成员函数获得。获得了这个PluginGlobals单例对象之后，EnterInstance类的构造函数就调用它的成员函数GetInstanceAPI获得一个API_ID_PPB_INSTANCE接口，如下所示：

thunk::PPB_Instance_API* PluginGlobals::GetInstanceAPI(PP_Instance instance) {
  PluginDispatcher* dispatcher = PluginDispatcher::GetForInstance(instance);
  if (dispatcher)
    return dispatcher->GetInstanceAPI();
  return NULL;
}

       PluginGlobals类的成员函数GetInstanceAPI首先调用PluginDispatcher类的静态成员函数GetForInstance获得一个与参数instance描述的Plugin Instance对应的PluginDispatcher对象。有了这个PluginDispatcher对象之后，再调用它的成员函数GetInstanceAPI获得一个API_ID_PPB_INSTANCE接口，如下所示：

thunk::PPB_Instance_API* PluginDispatcher::GetInstanceAPI() {
  return static_cast<PPB_Instance_Proxy*>(
      GetInterfaceProxy(API_ID_PPB_INSTANCE));
}

       PluginDispatcher类的成员函数GetInstanceAPI调用另外一个成员函数GetInterfaceProxy获得一个API_ID_PPB_INSTANCE接口。PluginDispatcher类的成员函数GetInterfaceProxy是从父类Dispatcher继承下来的。Dispatcher类的成员函数GetInterfaceProxy的实现，可以参考前面Chromium插件（Plugin）实例（Instance）创建过程分析一文中。

       再结合前面Chromium插件（Plugin）模块（Module）加载过程分析一文，我们可以知道，在Plugin进程中，API_ID_PPB_INSTANCE接口被指定为模板函数ProxyFactory<PPB_Instance_Proxy>。Dispatcher类的成员函数GetInterfaceProxy将会调用这个函数创建一个PPB_Instance_Proxy对象。这意味着在Plugin进程中，API_ID_PPB_INSTANCE接口是通过一个PPB_Instance_Proxy对象实现的。这个PPB_Instance_Proxy对象会返回给EnterInstance类的构造函数。

       回到前面分析的函数BindGraphics，这时候就它构造了一个EnterInstance对象，并且这个EnterInstance对象的成员变量functions_指向了一个PPB_Instance_Proxy对象。这个PPB_Instance_Proxy对象可以通过调用上述构造的EnterInstance对象的成员函数functions获得。有了这个PPB_Instance_Proxy对象之后，函数BindGraphics就可以调用它的成员函数BindGraphics向Render进程发送一个IPC消息，以便请求它为当前正在处理的Plugin绑定一个OpenGL上下文，如下所示：

PP_Bool PPB_Instance_Proxy::BindGraphics(PP_Instance instance,
                                         PP_Resource device) {
  // If device is 0, pass a null HostResource. This signals the host to unbind
  // all devices.
  HostResource host_resource;
  PP_Resource pp_resource = 0;
  if (device) {
    Resource* resource =
        PpapiGlobals::Get()->GetResourceTracker()->GetResource(device);
    if (!resource || resource->pp_instance() != instance)
      return PP_FALSE;
    host_resource = resource->host_resource();
    pp_resource = resource->pp_resource();
  } else {
    // Passing 0 means unbinding all devices.
    dispatcher()->Send(new PpapiHostMsg_PPBInstance_BindGraphics(
        API_ID_PPB_INSTANCE, instance, 0));
    return PP_TRUE;
  }

  // We need to pass different resource to Graphics 2D and 3D right now.  Once
  // 3D is migrated to the new design, we should be able to unify this.
  EnterResourceNoLock<PPB_Compositor_API> enter_compositor(device, false);
  EnterResourceNoLock<PPB_Graphics2D_API> enter_2d(device, false);
  EnterResourceNoLock<PPB_Graphics3D_API> enter_3d(device, false);
  if (enter_compositor.succeeded() || enter_2d.succeeded()) {
    dispatcher()->Send(new PpapiHostMsg_PPBInstance_BindGraphics(
        API_ID_PPB_INSTANCE, instance, pp_resource));
    return PP_TRUE;
  } else if (enter_3d.succeeded()) {
    dispatcher()->Send(new PpapiHostMsg_PPBInstance_BindGraphics(
        API_ID_PPB_INSTANCE, instance, host_resource.host_resource()));
    return PP_TRUE;
  }
  return PP_FALSE;
}

       PPB_Instance_Proxy类的成员函数BindGraphics首先判断参数device的值是否不等于NULL。如果不等于NULL，那么它描述的就是一个OpenGL上下文，并且这个OpenGL上下文要与参数instance描述的Plugin Instance进行绑定。否则的话，就说明要将参数instance描述的Plugin Instance当前使用的OpenGL上下文设置为NULL。

       在我们这个情景中，参数device的值不等于NULL。在这种情况下，PPB_Instance_Proxy类的成员函数BindGraphics首先会根据这个参数获得一个Resource对象。这个Resource对象描述的就是一个OpenGL上下文。这个OpenGL上下文可能是用来执行2D渲染的，也可能是用来执行3D渲染的。PPB_Instance_Proxy类的成员函数BindGraphics会对这两种情况进行区别，不过最终都会向Render进程发送一个类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息。这个IPC消息携带了3个参数：

       1. API_ID_PPB_INSTANCE，要求Render进程将该IPC消息分发给API_ID_PPB_INSTANCE接口处理。

       2. instance，表示目标Plugin Instance。

       3. 通过参数device获得一个PP_Resource对象，描述的是一个要与目标Plugin Instance进行绑定的OpenGL上下文。

       Render进程接收类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息的过程与前面分析的类型为PpapiHostMsg_PPBGraphics3D_Create的IPC消息是类似的，只不过前者最后会分发给API_ID_PPB_INSTANCE接口处理，而后者会分发给API_ID_PPB_GRAPHICS_3D接口处理。它们在Render进程的分发过程都可以参考在前面Chromium插件（Plugin）实例（Instance）创建过程分析一文提到的类型为PpapiMsg_PPPInstance_DidCreate的IPC消息在Plugin进程的分发过程。

       从前面Chromium插件（Plugin）实例（Instance）创建过程分析一文还可以知道，在Render进程中，API_ID_PPB_INSTANCE接口是由一个PPB_Instance_Proxy对象实现的，也就是Render进程会将类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息分发给该PPB_Instance_Proxy对象处理，这是通过调用它的成员函数OnMessageReceived实现的，如下所示：

bool PPB_Instance_Proxy::OnMessageReceived(const IPC::Message& msg) {
  ......

  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPB_Instance_Proxy, msg)
#if !defined(OS_NACL)
    ......
    IPC_MESSAGE_HANDLER(PpapiHostMsg_PPBInstance_BindGraphics,
                        OnHostMsgBindGraphics)
    ......
#endif  // !defined(OS_NACL)

    ......

    IPC_MESSAGE_UNHANDLED(handled = false)
  IPC_END_MESSAGE_MAP()
  return handled;
}

      从这里可以看到，PPB_Instance_Proxy类的成员函数OnMessageReceived会将类型为PpapiHostMsg_PPBInstance_BindGraphics的IPC消息分发给另外一个成员函数OnHostMsgBindGraphics处理，如下所示：

void PPB_Instance_Proxy::OnHostMsgBindGraphics(PP_Instance instance,
                                               PP_Resource device) {
  // Note that we ignroe the return value here. Otherwise, this would need to
  // be a slow sync call, and the plugin side of the proxy will have already
  // validated the resources, so we shouldn't see errors here that weren't
  // already caught.
  EnterInstanceNoLock enter(instance);
  if (enter.succeeded())
    enter.functions()->BindGraphics(instance, device);
}

       参数instance要描述的是要绑定OpenGL上下文的Plugin Instance在Render进程中对应的Proxy，也就是一个PepperPluginInstanceImpl对象。PPB_Instance_Proxy类的成员函数OnHostMsgBindGraphics首先是使用它构造一个EnterInstanceNoLock对象。这个EnterInstanceNoLock对象是用来封装一个Instance API的。这个Instance API可以用来给一个Plugin Instance Proxy绑定一个OpenGL上下文。

       接下来我们从EnterInstanceNoLock类的构造函数开始分析一个EnterInstanceNoLock对象的构造过程，如下所示：

EnterInstanceNoLock::EnterInstanceNoLock(PP_Instance instance)
    : EnterBase(),
      functions_(PpapiGlobals::Get()->GetInstanceAPI(instance)) {
  ......
}

       前面提到，在Render进程中，存在一个HostGlobals单例对象。这个HostGlobals单例对象可以通过调用PpapiGlobals类的静态成员函数Get获得。获得了这个HostGlobals单例对象之后，EnterInstanceNoLock类的构造函数就调用它的成员函数GetInstanceAPI获得一个Instance API，如下所示：

ppapi::thunk::PPB_Instance_API* HostGlobals::GetInstanceAPI(
    PP_Instance instance) {
  // The InstanceAPI is just implemented by the PluginInstance object.
  return GetInstance(instance);
}

       HostGlobals类的成员函数GetInstanceAPI调用另外一个成员函数GetInstance获得参数instance描述的一个Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象，如下所示：

PepperPluginInstanceImpl* HostGlobals::GetInstance(PP_Instance instance) {
  ......
  InstanceMap::iterator found = instance_map_.find(instance);
  if (found == instance_map_.end())
    return NULL;
  return found->second;
}

       在Render进程中，每一个Plugin Instance Proxy都会以分配给它的ID保存在HostGlobals类的成员变量instance_map_描述的一个std::map中。因此，给出一个ID，就可以在这个std::map中找到它对应的Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象。

       在Render进程中，Instance API是通过PPB_Instance_API类描述的。PepperPluginInstanceImpl类又是从PPB_Instance_API类继承下来的。因此，一个PepperPluginInstanceImpl对象可以当作一个Instance API使用。这个PepperPluginInstanceImpl对象将会返回给EnterInstanceNoLock类的构造函数，并且保存在EnterInstanceNoLock类的成员变量functions_中。

       这一步执行完成后，回到前面分析的PPB_Instance_Proxy类的成员函数OnMessageReceived中。这时候就它构造了一个EnterInstanceNoLock对象，并且这个EnterInstanceNoLock对象的成员变量functions_指向了一个PepperInProcessResourceCreation对象。注意，这个PepperPluginInstanceImpl对象在用作Instance API的同时，也是即将要绑定OpenGL上下文的Plugin Instance Proxy。这个绑定操作是通过调用它的成员函数BindGraphics实现的，如下所示：

PP_Bool PepperPluginInstanceImpl::BindGraphics(PP_Instance instance,
                                               PP_Resource device) {
  ......

  scoped_refptr<ppapi::Resource> old_graphics = bound_graphics_3d_.get();
  if (bound_graphics_3d_.get()) {
    bound_graphics_3d_->BindToInstance(false);
    bound_graphics_3d_ = NULL;
  }
  if (bound_graphics_2d_platform_) {
    bound_graphics_2d_platform_->BindToInstance(NULL);
    bound_graphics_2d_platform_ = NULL;
  }
  if (bound_compositor_) {
    bound_compositor_->BindToInstance(NULL);
    bound_compositor_ = NULL;
  }

  ......

  const ppapi::host::PpapiHost* ppapi_host =
      RendererPpapiHost::GetForPPInstance(instance)->GetPpapiHost();
  ppapi::host::ResourceHost* host = ppapi_host->GetResourceHost(device);
  PepperGraphics2DHost* graphics_2d = NULL;
  PepperCompositorHost* compositor = NULL;
  if (host) {
    if (host->IsGraphics2DHost()) {
      graphics_2d = static_cast<PepperGraphics2DHost*>(host);
    } else if (host->IsCompositorHost()) {
      compositor = static_cast<PepperCompositorHost*>(host);
    } 
    ......
  }

  EnterResourceNoLock enter_3d(device, false);
  PPB_Graphics3D_Impl* graphics_3d =
      enter_3d.succeeded()
          ? static_cast(enter_3d.object())
          : NULL;
  
  if (compositor) {
    if (compositor->BindToInstance(this)) {
      bound_compositor_ = compositor;
      ......
      return PP_TRUE;
    }
  } else if (graphics_2d) {
    if (graphics_2d->BindToInstance(this)) {
      bound_graphics_2d_platform_ = graphics_2d;
      ......
      return PP_TRUE;
    }
  } else if (graphics_3d) {
    // Make sure graphics can only be bound to the instance it is
    // associated with.
    if (graphics_3d->pp_instance() == pp_instance() &&
        graphics_3d->BindToInstance(true)) {
      bound_graphics_3d_ = graphics_3d;
      ......
      return PP_TRUE;
    }
  }

  // The instance cannot be bound or the device is not a valid resource type.
  return PP_FALSE;
}

       Plugin Instance不仅可以将UI渲染在一个2D上下文或者一个3D上下文中，还可以渲染在一个Compositor上下文中。一个2D上下文和一个3D上下文描述的都只是一个Layer，而一个Compositor上下文可以描述多个Layer。也就是说，Plugin Instance可以通过Compositor上下文将自己的UI划分为多个Layer进行渲染。Chromium提供了一个PPB_COMPOSITOR_INTERFACE_0_1接口，Plugin Instance可以通过这个接口为自己创建一个Compositor上下文。

       其中，2D上下文通过一个PepperGraphics2DHost类描述，3D上下文通过PPB_Graphics3D_Impl类描述，而Compositor上下文通过PepperCompositorHost类描述。PepperPluginInstanceImpl类分别通过bound_graphics_2d_platform_、bound_graphics_3d_和bound_compositor_三个成员变量描述上述三种不同的绘图上下文。

       PepperPluginInstanceImpl类的成员函数BindGraphics主要做的工作就是将参数device描述的绘图上下文绑定为当前正在处理的Plugin Instance Proxy的绘图上下文。如果当前正在处理的Plugin Instance Proxy以前绑定过其它的绘图上下文，那么PepperPluginInstanceImpl类的成员函数BindGraphics就会先解除对它们的绑定。

       PepperPluginInstanceImpl类的成员函数BindGraphics接下来再判断参数device描述的绘图上下文是2D上下文、3D上下文，还是Compositor上下文，并且获取它所对应的PepperGraphics2DHost对象、PPB_Graphics3D_Impl对象和PepperCompositorHost对象，然后保存在对应的成员变量中。这样，当前正在处理的Plugin Instance Proxy就知道了自己最新绑定的绘图上下文是什么。最后，这些获得的PepperGraphics2DHost对象、PPB_Graphics3D_Impl对象和PepperCompositorHost对象的成员函数BindToInstance也会被调用，表示它们当前处于被绑定状态。

       在我们这个情景中，参数device描述的绘图上下文是一个3D上下文，也就是一个3D的OpenGL上下文。因此， PepperPluginInstanceImpl类的成员函数BindGraphics最终会获得一个PPB_Graphics3D_Impl对象，并且保存在成员变量bound_graphics_3d_中。最后，这个PPB_Graphics3D_Impl对象的成员函数BindToInstance会被调用，表示它当前处于被绑定的状态，如下所示：

bool PPB_Graphics3D_Impl::BindToInstance(bool bind) {
  bound_to_instance_ = bind;
  return true;
}

      从前面的调用过程可以知道，参数bind的值等于true。这时候PPB_Graphics3D_Impl类的成员变量bound_to_instance_的值也会被设置为true，表示当前正在处理的PPB_Graphics3D_Impl对象描述的3D上下文处于被绑定状态。

      这一步执行完成后，GLES2DemoInstance类就通过PPB_GRAPHICS_3D_INTERFACE_1_0和PPB_INSTANCE_INTERFACE_1_0这两个接口创建和绑定了一个OpenGL上下文，也就是初始化好一个OpenGL环境。接下来，GLES2DemoInstance类就可以通过PPB_OPENGLES2_INTERFACE接口进行3D渲染了。这个PPB_OPENGLES2_INTERFACE接口是在GLES2DemoInstance类的构造函数中获取的，如下所示：

GLES2DemoInstance::GLES2DemoInstance(PP_Instance instance, pp::Module* module)
    : pp::Instance(instance), pp::Graphics3DClient(this),
      callback_factory_(this),
      module_(module),
      context_(NULL),
      fullscreen_(false) {
  assert((gles2_if_ = static_cast<const PPB_OpenGLES2*>(
      module->GetBrowserInterface(PPB_OPENGLES2_INTERFACE))));
  ......
}

       这个函数定义在文件external/chromium_org/ppapi/examples/gles2/gles2.cc中。

       GLES2DemoInstance类的构造函数是通过调用参数module指向的一个pp::Module对象的成员函数GetBrowserInterface获取PPB_OPENGLES2_INTERFACE接口的。在前面Chromium插件（Plugin）模块（Module）加载过程分析一文中，我们已经分析过了pp::Module类的GetBrowserInterface的实现，并且我们也知道，在Plugin进程中，PPB_OPENGLES2_INTERFACE接口是由一个PPB_OpenGLES2对象实现的。这个PPB_OpenGLES2对象的定义如下所示：

  static const struct PPB_OpenGLES2 ppb_opengles2 = {  
      &ActiveTexture,                       &AttachShader,  
      &BindAttribLocation,                  &BindBuffer,  
      &BindFramebuffer,                     &BindRenderbuffer,  
      &BindTexture,                         &BlendColor,  
      &BlendEquation,                       &BlendEquationSeparate,  
      &BlendFunc,                           &BlendFuncSeparate,  
      &BufferData,                          &BufferSubData,  
      &CheckFramebufferStatus,              &Clear,  
      ......  
      &UseProgram,                          &ValidateProgram,  
      &VertexAttrib1f,                      &VertexAttrib1fv,  
      &VertexAttrib2f,                      &VertexAttrib2fv,  
      &VertexAttrib3f,                      &VertexAttrib3fv,  
      &VertexAttrib4f,                      &VertexAttrib4fv,  
      &VertexAttribPointer,                 &Viewport}; 

       从这里我们就可以看到PPB_OPENGLES2_INTERFACE接口提供的函数，例如函数Clear，就相当于是OpenGL函数glClear。

       有了这个PPB_OPENGLES2_INTERFACE接口之后，GLES2DemoInstance类就会在成员函数FlickerAndPaint中调用它提供的函数进行3D渲染，如下所示：

void GLES2DemoInstance::FlickerAndPaint(int32_t result, bool paint_blue) {
  ......

  float r = paint_blue ? 0 : 1;
  float g = 0;
  float b = paint_blue ? 1 : 0;
  float a = 0.75;
  gles2_if_->ClearColor(context_->pp_resource(), r, g, b, a);
  gles2_if_->Clear(context_->pp_resource(), GL_COLOR_BUFFER_BIT);
  ......

  context_->SwapBuffers(cb);
  ......
}

       GLES2DemoInstance类的成员函数FlickerAndPaint执行的3D渲染很简单，仅仅是调用PPB_OPENGLES2_INTERFACE接口提供的函数ClearColor和Clear绘制一个背景色，相当于是调用了OpenGL函数glClearColor和glClear绘制一个背景色。在实际开发中，我们可以调用PPB_OPENGLES2_INTERFACE接口提供的其它函数完成更复杂的3D渲染效果。

       从前面的分析可以知道，GLES2DemoInstance类的成员变量context_指向的是一个pp::Graphics3D对象。这个Graphics3D描述的是一个OpenGL上下文。每完成一帧渲染，GLES2DemoInstance类的成员函数FlickerAndPaint都需要调用这个pp::Graphics3D对象的成员函数SwapBuffers，用来交换当前使用的OpenGL上下文的前后两个缓冲区，相当于是调用了EGL函数eglSwapBuffers。

       接下来，我们就以PPB_OPENGLES2_INTERFACE接口提供的函数Clear的执行过程为例，分析Plugin是如何通过PPB_OPENGLES2_INTERFACE接口执行3D渲染操作的，它的实现如下所示：

void Clear(PP_Resource context_id, GLbitfield mask) {
  Enter3D enter(context_id, true);
  if (enter.succeeded()) {
    ToGles2Impl(&enter)->Clear(mask);
  }
}

      Enter3D定义为一个thunk::EnterResource<thunk::PPB_Graphics3D_API>类，如下所示：

typedef thunk::EnterResource<thunk::PPB_Graphics3D_API> Enter3D;

      回到函数Clear中， 它的参数context_id描述的是一个OpenGL上下文资源ID。函数Clear首先将这个资源ID封装在一个EnterResource<thunk::PPB_Graphics3D_API>对象中，如下所示：

template<typename ResourceT, bool lock_on_entry = true>
class EnterResource
    : public subtle::LockOnEntry<lock_on_entry>,  // Must be first; see above.
      public subtle::EnterBase {
 public:
  EnterResource(PP_Resource resource, bool report_error)
      : EnterBase(resource) {
    Init(resource, report_error);
  }
  ......
};

       EnterResource<thunk::PPB_Graphics3D_API>类的构造函数首先会调用父类EnterBase的构造函数。在调用的时候，会将参数resource描述的资源ID传递进去。EnterBase的构造函数通过这个资源ID获得对应的资源对象，保存在成员变量resource_中，如下所示：

EnterBase::EnterBase(PP_Resource resource)
    : resource_(GetResource(resource)),
      retval_(PP_OK) {
  PpapiGlobals::Get()->MarkPluginIsActive();
}

       从前面的分析可以知道，这个资源对象实际上就是一个ppapi::proxy::Graphics3D对象。与此同时，EnterBase的构造函数会通过调用Plugin进程的一个PluginGlobals单例对象的成员函数MarkPluginIsActive将当前正在执行3D渲染操作的Plugin标记为Active状态。

       回到EnterResource<thunk::PPB_Graphics3D_API>类的构造函数中，它接下来又会调用另外一个成员函数Init执行其它的初始化工作，如下所示：

template<typename ResourceT, bool lock_on_entry = true>
class EnterResource
    : public subtle::LockOnEntry<lock_on_entry>,  // Must be first; see above.
      public subtle::EnterBase {
 public:
  .......

  ResourceT* object() { return object_; }
  ......

 private:
  void Init(PP_Resource resource, bool report_error) {
    if (resource_)
      object_ = resource_->GetAs<ResourceT>();
    ......
  }

  ResourceT* object_;

  ......
};

       EnterResource<thunk::PPB_Graphics3D_API>类的成员函数Init主要是将从父类EnterBase继承下来的成员变量resource_指向的ppapi::proxy::Graphics3D对象转换为一个thunk::PPB_Graphics3D_API对象，并且保存在成员变量object_中。这个thunk::PPB_Graphics3D_API对象以后可以通过调用EnterResource<thunk::PPB_Graphics3D_API>类的成员函数object获得。

       注意，ppapi::proxy::Graphics3D类是从ppapi::PPB_Graphics3D_Shared类继承下来的，ppapi::PPB_Graphics3D_Shared类又是从thunk::PPB_Graphics3D_API类继承下来的，因此，我们可以将ppapi::proxy::Graphics3D对象转换为一个thunk::PPB_Graphics3D_API对象。

       这一步执行完成后，回到前面分析的函数函数Clear中，这时候它就构造了一个EnterResource<thunk::PPB_Graphics3D_API>对象，并且这个EnterResource<thunk::PPB_Graphics3D_API>对象的成员变量object_指向了一个thunk::PPB_Graphics3D_API对象。函数Clear接下来又会调用另外一个函数ToGles2Impl从前面构造的EnterResource<thunk::PPB_Graphics3D_API>对象中获得一个GLES2Implementation对象，如下所示：

gpu::gles2::GLES2Implementation* ToGles2Impl(Enter3D* enter) {
  ......
  return static_cast<PPB_Graphics3D_Shared*>(enter->object())->gles2_impl();
}

       函数ToGles2Impl首先调用参数enter指向的EnterResource<thunk::PPB_Graphics3D_API>对象的成员函数object获得它的成员变量object_所指向的一个thunk::PPB_Graphics3D_API对象。

       前面提到，由于EnterResource<thunk::PPB_Graphics3D_API>类的成员变量object_指向的实际上是一个ppapi::proxy::Graphics3D对象，并且ppapi::proxy::Graphics3D类是从ppapi::PPB_Graphics3D_Shared类继承下来的。因此函数ToGles2Impl又可以将它获得的thunk::PPB_Graphics3D_API对象转换为一个ppapi::PPB_Graphics3D_Shared对象。

       有了这个ppapi::PPB_Graphics3D_Shared对象之后，函数ToGles2Impl就可以调用它的成员函数gles2_impl获得它内部维护的一个GLES2Implementation对象。这个GLES2Implementation对象就是在前面分析的ppapi::proxy::Graphics3D类的成员函数CreateGLES2Impl中创建的。

       函数ToGles2Impl最后会将获得的GLES2Implementation对象返回给函数Clear。函数Clear获得了这个GLES2Implementation对象之后，就会调用它的成员函数Clear给参数context_id描述的OpenGL上下文设置一个背景色。

       从前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文可以知道，当我们调用GLES2Implementation类的成员函数执行GPU命令时，这些GPU命令实际上只是写入到了一个Command Buffer中。这个Command Buffer在合适的时候将会调用它的成员函数WaitForGetOffsetInRange通知GPU进程执行它里面的GPU命令。

       从前面的分析可以知道，为Plugin创建的GLES2Implementation对象所用的Command Buffer是通过一个PpapiCommandBufferProxy对象描述的。当这个WaitForGetOffsetInRange对象的成员函数WaitForGetOffsetInRange被调用的时候，它实际上只是向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange的IPC消息，如下所示：

void PpapiCommandBufferProxy::WaitForTokenInRange(int32 start, int32 end) {
  ......

  bool success;
  gpu::CommandBuffer::State state;
  if (Send(new PpapiHostMsg_PPBGraphics3D_WaitForTokenInRange(
          ppapi::API_ID_PPB_GRAPHICS_3D,
          resource_,
          start,
          end,
          &state,
          &success)))
    UpdateState(state, success);
}

       这个类型为PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange的IPC消息携带了一个参数ppapi::API_ID_PPB_GRAPHICS_3D，表示Render进程接收到这个IPC消息之后，要分发一个API_ID_PPB_GRAPHICS_3D接口处理。

       前面提到，在Render进程中，API_ID_PPB_GRAPHICS_3D接口是由一个PPB_Graphics3D_Proxy对象实现的，也就是Render进程会将类型为PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange的IPC消息分发给该PPB_Graphics3D_Proxy对象处理，这是通过调用它的成员函数OnMessageReceived实现的，如下所示：

bool PPB_Graphics3D_Proxy::OnMessageReceived(const IPC::Message& msg) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPB_Graphics3D_Proxy, msg)
#if !defined(OS_NACL)
    ......
    IPC_MESSAGE_HANDLER(PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange,
                        OnMsgWaitForGetOffsetInRange)
    ......
#endif  // !defined(OS_NACL)

    ......
    IPC_MESSAGE_UNHANDLED(handled = false)

  IPC_END_MESSAGE_MAP()
  // FIXME(brettw) handle bad messages!
  return handled;
}

       从这里可以看到，PPB_Graphics3D_Proxy类的成员函数OnMessageReceived会将类型为PpapiHostMsg_PPBGraphics3D_WaitForGetOffsetInRange的IPC消息分发给另外一个成员函数OnMsgWaitForGetOffsetInRange处理，如下所示：

void PPB_Graphics3D_Proxy::OnMsgWaitForGetOffsetInRange(
    const HostResource& context,
    int32 start,
    int32 end,
    gpu::CommandBuffer::State* state,
    bool* success) {
  EnterHostFromHostResource<PPB_Graphics3D_API> enter(context);
  ......
  *state = enter.object()->WaitForGetOffsetInRange(start, end);
  *success = true;
}

       从前面的分析可以知道，参数context描述的OpenGL上下文在Render进程中用一个PPB_Graphics3D_Impl对象描述。PPB_Graphics3D_Proxy类的成员函数OnMsgWaitForGetOffsetInRange会通过构造一个EnterHostFromHostResource<PPB_Graphics3D_API>对象来获得这个PPB_Graphics3D_Impl对象，并且会调用这个PPB_Graphics3D_Impl对象的成员函数WaitForGetOffsetInRange，用来通知它将Plugin写入在Command Buffer中的GPU命令发送给GPU进程处理。

        PPB_Graphics3D_Impl类的成员函数WaitForGetOffsetInRange的实现如下所示：

gpu::CommandBuffer::State PPB_Graphics3D_Impl::WaitForGetOffsetInRange(
    int32_t start,
    int32_t end) {
  GetCommandBuffer()->WaitForGetOffsetInRange(start, end);
  return GetCommandBuffer()->GetLastState();
}

       PPB_Graphics3D_Impl类的成员函数WaitForGetOffsetInRange首先调用成员函数GetCommandBuffer获得一个CommandBuffer对象，如下所示：

gpu::CommandBuffer* PPB_Graphics3D_Impl::GetCommandBuffer() {
  return command_buffer_;
}

       PPB_Graphics3D_Impl类的成员函数GetCommandBuffer返回的是成员变量command_buffer_指向的一个CommandBuffer对象。从前面的分析可以知道，这个CommandBuffer对象实现上是一个CommandBufferProxyImpl对象，它是在前面分析的PPB_Graphics3D_Impl类的成员函数InitRaw中创建的。

       回到PPB_Graphics3D_Impl类的成员函数WaitForGetOffsetInRange中，它获得了一个CommandBufferProxyImpl对象之后，就会调用它的成员函数WaitForGetOffsetInRange通知GPU进程执行Plugin写入在Command Buffer中的GPU命令。这个通知过程可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

       这一步执行完成后，回到前面分析的GLES2DemoInstance类的成员函数FlickerAndPaint中，它通过PPB_OPENGLES2_INTERFACE接口提供的函数渲染好一帧后，就会调用其成员变量context_指向的一个pp::Graphics3D对象的成员函数SwapBuffers交换Plugin当前使用的OpenGL上下文的前后两个缓冲区，也就是相当于是执行EGL函数eglSwapBuffers。

       接下来，我们就从pp::Graphics3D类的成员函数SwapBuffers开始，分析Plugin交换当前使用的OpenGL上下文的前后两个缓冲区的过程，如下所示：

int32_t Graphics3D::SwapBuffers(const CompletionCallback& cc) {
  ......

  return get_interface<PPB_Graphics3D_1_0>()->SwapBuffers(
      pp_resource(),
      cc.pp_completion_callback());
}

       pp::Graphics3D类的成员函数SwapBuffers首先调用我们前面分析过的模板函数get_interface<PPB_Graphics3D_1_0>获得一个PPB_GRAPHICS_3D_INTERFACE_1_0接口。获得了PPB_GRAPHICS_3D_INTERFACE_1_0接口之后，再调用它提供的函数SwapBuffers请求Render进程交换正在处理的pp::Graphics3D对象描述的OpenGL上下文的前后缓冲区。

       PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的函数SwapBuffers的实现如下所示：

int32_t SwapBuffers(PP_Resource context,
                    struct PP_CompletionCallback callback) {
  ......
  EnterResource<PPB_Graphics3D_API> enter(context, callback, true);
  if (enter.failed())
    return enter.retval();
  return enter.SetResult(enter.object()->SwapBuffers(enter.callback()));
}

       与前面分析的PPB_OPENGLES2_INTERFACE接口提供的函数Clear类似，PPB_GRAPHICS_3D_INTERFACE_1_0接口提供的函数SwapBuffers也是通过构造一个EnterResource<thunk::PPB_Graphics3D_API>对象来获得参数context描述的一个OpenGL上下文资源对象，也就是一个ppapi::proxy::Graphics3D对象。有了这个ppapi::proxy::Graphics3D对象之后，就可以调用它的成员函数SwapBuffers请求Render进程交换它描述的OpenGL上下文的前后缓冲区了。

       ppapi::proxy::Graphics3D类的成员函数SwapBuffers是从父类ppapi::PPB_Graphics3D_Shared继承下来的，它的实现如下所示：

int32_t PPB_Graphics3D_Shared::SwapBuffers(
    scoped_refptr<TrackedCallback> callback) {
  ......
  return DoSwapBuffers();
}

       ppapi::proxy::Graphics3D类的成员函数SwapBuffers又会调用由子类实现的成员函数DoSwapBuffers请求Render进程交换当前正在处理的ppapi::proxy::Graphics3D对象描述的OpenGL上下文的前后缓冲区。

       在我们这个情景中，这个子类即为ppapi::proxy::Graphics3D，因此接下来ppapi::proxy::Graphics3D类的成员函数DoSwapBuffers会被调用，它的实现如下所示：

int32 Graphics3D::DoSwapBuffers() {
  gles2_impl()->SwapBuffers();
  IPC::Message* msg = new PpapiHostMsg_PPBGraphics3D_SwapBuffers(
      API_ID_PPB_GRAPHICS_3D, host_resource());
  msg->set_unblock(true);
  PluginDispatcher::GetForResource(this)->Send(msg);

  return PP_OK_COMPLETIONPENDING;
}

      ppapi::proxy::Graphics3D类的成员函数DoSwapBuffers首先是通过调用成员函数gles2_impl获得前面为Plugin创建的一个Command Buffer GL接口。有了这个Command Buffer GL接口之后，就可以调用它的成员函数SwapBuffers向Command Buffer写入一个gles2::cmds::SwapBuffers命令。GPU进程在执行这个命令的时候，就会交换当前正在处理的ppapi::proxy::Graphics3D对象描述的OpenGL上下文的前后缓冲区。

      ppapi::proxy::Graphics3D类的成员函数DoSwapBuffers接下来又会调用PluginDispatcher类的静态成员函数GetForResource获得与当前正在处理的Plugin对应的一个PluginDispatcher对象，并且通过这个PluginDispatcher对象向Render进程发送一个类型为PpapiHostMsg_PPBGraphics3D_SwapBuffers的IPC消息，用来通知Render进程更新当前正在处理的Plugin在网页上的视图。这个IPC消息包含两个参数：

      1. API_ID_PPB_GRAPHICS_3D，表示Render进程要将该IPC消息分发给API_ID_PPB_GRAPHICS_3D接口处理。

      2. 通过调用成员函数host_resource获得的一个HostResource对象，这个HostResource对象描述的就是要交换前面缓冲区的OpenGL上下文。

      前面提到，在Render进程中，API_ID_PPB_GRAPHICS_3D接口是由一个PPB_Graphics3D_Proxy对象实现的，也就是Render进程会将类型为PpapiHostMsg_PPBGraphics3D_SwapBuffers的IPC消息分发给该PPB_Graphics3D_Proxy对象处理，这是通过调用它的成员函数OnMessageReceived实现的，如下所示：

bool PPB_Graphics3D_Proxy::OnMessageReceived(const IPC::Message& msg) {
  bool handled = true;
  IPC_BEGIN_MESSAGE_MAP(PPB_Graphics3D_Proxy, msg)
#if !defined(OS_NACL)
    ......
    IPC_MESSAGE_HANDLER(PpapiHostMsg_PPBGraphics3D_SwapBuffers,
                        OnMsgSwapBuffers)
    ......
#endif  // !defined(OS_NACL)

    ......
    IPC_MESSAGE_UNHANDLED(handled = false)

  IPC_END_MESSAGE_MAP()
  // FIXME(brettw) handle bad messages!
  return handled;
}

       从这里可以看到，PPB_Graphics3D_Proxy类的成员函数OnMessageReceived会将类型为PpapiHostMsg_PPBGraphics3D_SwapBuffers的IPC消息分发给另外一个成员函数OnMsgSwapBuffers处理，如下所示：

void PPB_Graphics3D_Proxy::OnMsgSwapBuffers(const HostResource& context) {
  EnterHostFromHostResourceForceCallback<PPB_Graphics3D_API> enter(
      context, callback_factory_,
      &PPB_Graphics3D_Proxy::SendSwapBuffersACKToPlugin, context);
  if (enter.succeeded())
    enter.SetResult(enter.object()->SwapBuffers(enter.callback()));
}

       参数context描述的是一个要交换前后缓冲区的OpenGL上下文。从前面的分析可以知道，在Render进程中，这个OpenGL上下文是通过一个PPB_Graphics3D_Impl对象描述的。PPB_Graphics3D_Proxy类的成员函数OnMsgSwapBuffers通过构造一个EnterHostFromHostResourceForceCallback<PPB_Graphics3D_API>来获得这个PPB_Graphics3D_Impl对象，并且调用这个PPB_Graphics3D_Impl对象的成员函数SwapBuffers更新当前正在处理的Plugin在网页上的视图。

       PPB_Graphics3D_Impl类的成员函数SwapBuffers是从父类ppapi::PPB_Graphics3D_Shared继承下来的。前面我们已经分析过ppapi::PPB_Graphics3D_Shared类的成员函数SwapBuffers的实现了，它最终会调用由子类实现的成员函数DoSwapBuffers，即PPB_Graphics3D_Impl类的成员函数DoSwapBuffers。

       PPB_Graphics3D_Impl类的成员函数DoSwapBuffers的实现如下所示：

int32 PPB_Graphics3D_Impl::DoSwapBuffers() {
  ......

  if (bound_to_instance_) {
    // If we are bound to the instance, we need to ask the compositor
    // to commit our backing texture so that the graphics appears on the page.
    // When the backing texture will be committed we get notified via
    // ViewFlushedPaint().
    //
    // Don't need to check for NULL from GetPluginInstance since when we're
    // bound, we know our instance is valid.
    HostGlobals::Get()->GetInstance(pp_instance())->CommitBackingTexture();
    commit_pending_ = true;
  } 

  ......

  return PP_OK_COMPLETIONPENDING;
}

       从前面的分析可以知道，当前正在处理的PPB_Graphics3D_Impl对象描述的OpenGL上下文此时处于绑定状态，也就是它的成员变量bound_to_instance_的值等于true。在这种情况下，PPB_Graphics3D_Impl类的成员函数DoSwapBuffers首先会通过HostGlobals类的静态成员函数Get获得当前Render进程中的一个HostGlobals单例对象。有了这个HostGlobals单例对象之后，就可以调用它的成员函数GetInstance获得与当前正在处理的PPB_Graphics3D_Impl对象进行绑定的一个Plugin Instance Proxy，也就是一个PepperPluginInstanceImpl对象。

      有了上述PepperPluginInstanceImpl对象之后，PPB_Graphics3D_Impl类的成员函数DoSwapBuffers就可以调用它的成员函数CommitBackingTexture更新它在网页上的视图，如下所示：

void PepperPluginInstanceImpl::CommitBackingTexture() {
  ......
  gpu::Mailbox mailbox;
  uint32 sync_point = 0;
  bound_graphics_3d_->GetBackingMailbox(&mailbox, &sync_point);
  ......
  texture_layer_->SetTextureMailboxWithoutReleaseCallback(
      cc::TextureMailbox(mailbox, GL_TEXTURE_2D, sync_point));
  texture_layer_->SetNeedsDisplay();
}

       从前面的分析可以知道，PepperPluginInstanceImpl类的成员变量bound_graphics_3d_指向的是一个PPB_Graphics3D_Impl对象。这个PPB_Graphics3D_Impl对象描述的是一个OpenGL上下文。这个OpenGL上下文就是当前正在处理的PepperPluginInstanceImpl对象绑定的OpenGL上下文。

       PepperPluginInstanceImpl类的另外一个成员变量texture_layer_指向的是一个cc::TextureLayer对象。前面提到，网页中的每一个<embed>标签在网页的CC Layer Tree中都对应有一个Texture Layer。这个Texture Layer就是通过上述cc::TextureLayer对象描述的。

       有了上述PPB_Graphics3D_Impl对象之后，PepperPluginInstanceImpl类的成员函数CommitBackingTexture就可以调用它的成员函数GetBackingMailbox获得已经被交换到后端的缓冲区。这个缓冲区实际上是一个纹理缓冲区。这个纹理缓冲区将会作为<embed>标签的内容，因此PepperPluginInstanceImpl类的成员函数CommitBackingTexture就会将它设置上述cc::TextureLayer对象所要绘制的内容。这是通过调用该cc::TextureLayer对象的成员函数SetTextureMailboxWithoutReleaseCallback实现的。

       最后，PepperPluginInstanceImpl类的成员函数CommitBackingTexture调用上述cc::TextureLayer对象的成员函数SetNeedsDisplay将自己标记为需要更新。这样在下一个VSync信号到来的时候，前面设置为它的内容的纹理缓冲区就会被渲染和合成在网页的UI上。这个渲染和合成过程可以参考前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章。

       这样，我们就分析完成了Plugin执行3D渲染的过程，也就是Plugin为<embed>标签绘制3D视图的过程，这是通过调用Chromium提供的PPB_OPENGLES2_INTERFACE接口完成的。从这个过程我们就可以看到Plugin和Chromium的交互过程，也就是它们可以互相调用对方提供的接口，从而使得Plugin可以像我们在前面Chromium扩展（Extension）机制简要介绍和学习计划这个系列的文章提到的Extension一样，增强网页的功能。

       至此，我们也分析完成了Chromium的Plugin机制。重新学习可以参考前面Chromium插件（Plugin）机制简要介绍和学习计划一文。更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

       我们通常会在App的UI中嵌入WebView，用来实现某些功能的动态更新。在4.4版本之前，Android WebView基于WebKit实现。不过，在4.4版本之后，Android WebView就换成基于Chromium的实现了。基于Chromium实现，使得WebView可以更快更流畅地显示网页。本文接下来就介绍Android WebView基于Chromium的实现原理，以及制定学习计划。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！

       通过前面几个系列文章的学习，我们知道，Chromium的实现是相当复杂的。这种复杂可以体现在编译出来的动态库的大小上，带符号版本1.3G左右，去掉符号后还有27M左右。编译过AOSP源码的都知道，在整个编译过程中，Chromium库占用了大部分的时间，尤其是在生成上述1.3G文件时，电脑几乎卡住了。因此，在使用Chromium实现WebView时，第一个要解决的问题就是它的动态库加载问题。

       Android系统的动态库是ELF文件结构。ELF文件由ELF Header、Program Header Table、Section以及Section Header Table组成。ELF Header位于文件的开头，它同时描述了Program Header Table和Section Header Table在文件中的偏移位置。Section Header Table描述了动态库由哪些Section组成，典型的Section有.text、.data、.bss和.rodata等。这些Section描述的要么是程序代码，要么是程序数据。Program Header Table描述了动态库由哪些Segment组成。一个Segment又是由一个或者若干个Section组成的。Section信息是在程序链接期间用到的，而Segment信息是在程序加载期间用到的。关于ELF文件格式的更详细描述，可以参考Executable and Linkable Format。

       对于动态库来说，它的程序代码是只读的。这意味着一个动态库不管被多少个进程加载，它的程序代码都是只有一份。但是，动态库的程序数据，链接器在加载的时候，会为每一个进程都独立加载一份。对于Chromium动态库来说，它的程序代码占据了95%左右的大小，也就是25.65M左右。剩下的5%，也就是1.35M，是程序数据。假设有N个App使用了WebView，并且这个N个App的进程都存在系统中，那么系统就需要为Chromium动态库分配（25.65 + 1.35 × N）M内存。这意味着，N越大，Chromium动态库就占用越多的系统内存。

       在Chromium动态库1.35M的程序数据中，大概有1.28M在加载后经过一次重定位操作之后就不会发生变化。这些数据包含C++虚函数表，以及所有指针类型的常量。它们会被链接器放在一个称为GNU_RELRO Section中，如图1所示：

图1 App进程间不共享GNU_RELRO Section

       如果我们将Chromium动态库的GNU_RELRO Section看成是普通的程序数据，那么Android系统就需要为每一个使用了WebView的App进程都分配1.28M的内存。这将会造成内存浪费。如果我们能App进程之间共享Chromium动态库的GNU_RELRO Section，那么不管有多少个App进程使用了WebView，它占用的内存大小都是1.28M，如图2所示：

图2 App进程间共享GNU_RELRO Section

       这是有可能做到的，毕竟它与程序代码类似，在运行期间都是只读的。不同的地方在于，程序代码在加载后自始至终都不用修改，而GNU_RELRO Section的内容在重定位期间，是需要进行一次修改的，之后才是只读的。但是修改的时候，Linux的COW（Copy On Write）机制就会使得它不能再在各个App进程之间实现共享。

       为了使得Chromium动态库能在不同的App进程之间共享，Android系统执行了以下操作：

       1. Zygote进程在启动的过程中，为Chromium动态库保留了一段足够加载它的虚拟地址内间。我们假设这个虚拟地址空间的起始地址为gReservedAddress，大小为gReservedSize。

       2. System进程在启动的过程中，会请求Zygote进程fork一个子进程，并且在上述保留的虚拟地址空间[gReservedAddress, gReservedAddress + gReservedSize)中加载Chromium动态库。Chromium动态库的Program Header指定了它的GNU_RELRO Section的加载位置。这个位置是相对基地址gReservedAddress的一个偏移量。我们假设这个偏移量为gRelroOffset。上述子进程完成Chromium动态库的GNU_RELRO Section的重定位操作之后，会将它的内容写入到一个RELRO文件中去。

       3. App进程在创建WebView的时候，Android系统也会在上述保留的虚拟地址空间[gReservedAddress, gReservedAddress + gReservedSize)中加载Chromium动态库，并且会直接将第2步得到的RELRO文件内存映射到虚拟地址空间[gReservedAddress + gRelroOffset,  gReservedAddress + gRelroOffset + 1.28)去。

       关于Zygote进程、System进程和App进程的启动过程，可以参考Android系统进程Zygote启动过程的源代码分析和Android应用程序进程启动过程的源代码分析这两篇文章。

       Android 5.0的Linker提供了一个新的动态库加载函数android_dlopen_ext。这个函数不仅可以将一个动态库加载在指定的虚拟地址空间中，还可以在该动态库重定位操作完成后，将其GNU_RELRO Section的内容写入到指定的RELRO文件中去，同时还可以在加载一个动态库时，使用指定的RELRO文件内存映射为它的GNU_RELRO Section。因此，上述的第2步和第3步可以实现。函数android_dlopen_ext还有另外一个强大的功能，它可以从一个指定的文件描述符中读入要加载的动态库内容。通常我们是通过文件路径指定要加载的动态库，有了函数android_dlopen_ext之后，我们就不再受限于从本地文件加载动态库了。

       接下来，我们进一步分析为什么上述3个操作可以使得Chromium动态库能在不同的App进程之间共享。

       首先，第2步的子进程、第3步的App进程都是由第1步的Zygote进程fork出来的，因此它们都具有一段保留的虚拟地址空间[gReservedAddress, gReservedAddress + gReservedSize)。

       其次，第2步的子进程和第3步的App进程，都是将Chromium动态库加载在相同的虚拟地址空间中，因此，可以使用前者生成的RELRO文件内存映射为后者的GNU_RELRO Section。

       第三，所有使用了WebView的App进程，都将相同的RELRO文件内存映射为自己加载的Chromium动态库的GNU_RELRO Section，因此就实现了共享。

       App进程加载了Chromium动态库之后，就可以启动Chromium渲染引擎了。Chromium渲染引擎实际上是由Browser进程、Render进程和GPU进程组成的。其中，Browser进程负责将网页的UI合成在屏幕上，Render进程负责加载和渲染网页的UI，GPU进程负责执行Browser进程和Render进程发出的GPU命令。由于Chromium也支持单进程架构（在这种情况下，它的Browser进程、Render进程和GPU进程都是通过线程模拟的），因此接下来我们将它的Browser进程、Render进程和GPU进程统称为Browser端、Render端和GPU端。相应地，启动Chromium渲染引擎，就是要启动它的Browser端、Render端和GPU端。

       对于Android WebView来说，它启动Chromium渲染引擎的过程如图3所示：

图3 Android WebView启动Chromium渲染引擎的过程

       当我们在App的UI中嵌入一个WebView时，WebView内部会创建一个WebViewChromium对象。从名字就可以看出，WebViewChromium是基于Chromium实现的WebView。Chromium里面有一个android_webview模块。这个模块提供了两个类AwBrowserProcess和AwContents，分别用来封装Chromium的Content层提供的两个类BrowserStartupController和ContentViewCore。

       从前面Chromium硬件加速渲染的OpenGL上下文绘图表面创建过程分析一文可以知道，通过Chromium的Content层提供的BrowserStartupController类，可以启动Chromium的Browser端。不过，对于Android WebView来说，它并没有单独的Browser进程，它的Browser端是通过App进程的主线程（即UI线程）实现的。      

       Chromium的Content层会通过BrowserStartupController类在App进程的UI线程中启动一个Browser Main Loop。以后需要请求Chromium的Browser端执行某一个操作时，就向这个Browser Main Loop发送一个Task即可。这个Browser Main Loop最终会在App进程的UI线程中执行请求的Task。

       从前面Chromium网页Frame Tree创建过程分析一文可以知道，通过Chromium的Content层提供的ContentViewCore类，可以创建一个Render进程，并且在这个Render进程中加载指定的网页。不过，对于Android WebView来说，它是一个单进程架构，也就是它没有单独的Render进程用来加载网页。这时候ContentViewCore类将会创建一个线程来模拟Render进程。也就是说，Android WebView的Render端是通过在App进程中创建的一个线程实现的。这个线程称为In-Process Renderer Thread。

       现在，Android WebView具有Browser端和Render端了，它还需要有一个GPU端。从前面Chromium的GPU进程启动过程分析一文可以知道，在Android平台上，Chromium的GPU端是通过在Browser进程中创建一个GPU线程实现的。不过，对于Android WebView来说，它并没有一个单独的GPU线程。那么，Chromium的GPU命令由谁来执行呢？

       我们知道，从Android 3.0开始，App的UI就支持硬件加速渲染了，也就是支持通过GPU来渲染。到了Android 4.0，App的UI默认就是硬件加速渲染了。这时候App的UI线程就是一个OpenGL线程，也就是它可以用来执行GPU命令。再到Android 5.0，App的UI线程只负责收集UI渲染操作，也就是构建一个Display List。保存在这个Display List中的操作，最终会交给一个Render Thread执行。Render Thread又是通过GPU来执行这些渲染操作的。这时候App的UI线程不再是一个OpenGL线程，Render Thread才是。Android WebView的GPU命令就是由这个Render Thread执行的。当然，在Android 4.4时，Android WebView的GPU命令还是由App的UI线程执行的。这里我们只讨论Android 5.0的情况，具体可以参考Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章。

       Chromium在android_webview模块中提供了一个DeferredGpuCommandService服务。当Android WebView的Render端需要通过GPU命令绘制网页UI时，它就会通过DeferredGpuCommandService服务提供的RequestProcessGL接口向App的Display List增加一个类型为DrawFunctorOp的操作。当Display List从UI线程同步给Render Thread的时候，它里面包含的DrawFunctorOp操作就会被执行。这时候Android WebView的Render端请求的GPU命令就会在App的Render Thread中得到执行了。

       Android WebView的Browser端在合成网页UI时，是运行在App的Render Thread中的。这时候它仍然是通过DeferredGpuCommandService服务提供的RequestProcessGL接口请求执行GPU命令。不过，DeferredGpuCommandService会检测到它当前运行在App的Render Thread中，因此，就会直接执行它请求的GPU命令。

       Chromium为Android WebView独特的GPU命令执行方式（既不是在单独的GPU进程中执行，也不是在单独的GPU线程中执行）提供了一个称为In-Process Command Buffer GL的接口。顾名思义，In-Process Command Buffer GL与Command Buffer GL接口一样，要执行的GPU命令都是先写入到一个Command Buffer中。然而，这个Command Buffer会提交给App的Render Thread进程执行，过程如图4所示：

图4 Android WebView通过In-Process Command Buffer GL接口执行GPU命令的过程

       In-Process Command Buffer GL接口与前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文分析的Command Buffer GL接口一样，都是通过GLES2Implementation类描述的，区别在于前者通过一个InProcessCommandBuffer对象执行GPU命令，而后者通过一个CommandBufferProxyImpl对象执行GPU命令。更具体来说，就是CommandBufferProxyImpl对象会将要执行的GPU命令提交给Chromium的GPU进程/线程处理，而InProcessCommandBuffer对象会将要执行的GPU命令提交给App的Render Thread处理。

       GLES2Implementation类是通过InProcessCommandBuffer类的成员函数Flush请求它处理已经写入在Command Buffer中的GPU命令的。InProcessCommandBuffer类的成员函数Flush又会请求前面提到的DeferredGpuCommandService服务调度一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread，意思就是说要在App的Render Thread线程中调用InProcessCommandBuffer类的成员函数FlushOnGpuThread。InProcessCommandBuffer类的成员函数FlushOnGpuThread在调用的过程中，就会执行已经写入在Command Buffer中的GPU命令。

       DeferredGpuCommandService服务接收到调度Task的请求之后，会判断当前线程是否允许执行GL操作，实际上就是判断当前线程是否就是App的Render Thread。如果是的话，那么就会直接调用请求调度的Task绑定的InProcessCommandBuffer类的成员函数FlushOnGpuThread。这种情况发生在Browser端合成网页UI的过程中。Browser端合成网页UI的操作是由App的Render Thread主动发起的，因此这个合成操作就可以在当前线程中直接执行。

       另一方面，DeferredGpuCommandService服务接收到调度Task的请求之后，如果发现当前不允许执行GL操作，那么它就会将该Task保存在内部一个Task队列中，并且通过调用Java层的DrawGLFunctor类的成员函数requestDrawGL请求App的UI线程调度执行一个GL操作。这种情况发生在两个场景中。

       第一个场景发生在前面描述的Render端绘制网页UI的过程中。绘制网页UI相当于就是绘制Android WebView的UI。Android WebView属于App的UI里面一部分，因此它的绘制操作是由App的UI线程发起的。Android WebView在App的UI线程中接收到绘制的请求之后，它就会要求Render端的Compositor线程绘制网页的UI。这个Compositor线程不是一个OpenGL线程，它不能直接执行GL的操作，因此就要请求App的UI线程调度执行GL操作。

       从前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章可以知道，App的UI线程主要是负责收集当前UI的渲染操作，并且通过一个DisplayListRenderer将这些渲染操作写入到一个Display List中去。这个Display List最终会同步到App的Render Thread中去。App的Render Thread获得了这个Display List之后，就会通过调用相应的OpenGL函数执行这些渲染操作，也就是通过GPU来执行这些渲染操作。这个过程称为Replay（重放） Display List。重放完成之后，就可以生成App的UI了。

       DrawGLFunctor类的成员函数requestDrawGL请求App的UI线程调度执行的GL操作是一个特殊的渲染操作，它对应的是一个GL函数，而一般的渲染操作是指绘制一个Circle、Rect或者Bitmap等基本操作。GL函数在执行期间，可以执行任意的GPU命令。这个GL操作封装在一个DrawGLFunctor对象。App的UI线程又会进一步将这个rawGLFunctor对象封装成一个DrawFunctionOp操作。这个DrawFunctionOp操作会通过DisplayListRenderer类的成员函数callDrawGLFunction写入到App UI的Display List中。当这个Display List被App的Render Thread重放时，它里面包含的DrawFunctionOp操作就会被OpenGLRenderer类的成员函数callDrawGLFunction执行。

       OpenGLRenderer类的成员函数callDrawGLFunction在执行DrawFunctionOp操作时，就会通知与它关联的DrawGLFunctor对象。这个DrawGLFunctor对象又会调用Chromium的android_webview模块提供的一个GL函数。这个GL函数又会找到一个HardwareRenderer对象。这个HardwareRenderer对象是Android WebView的Browser端用来合成网页的UI的。有了这个HardwareRenderer对象之后，上述GL函数就会调用它的成员函数DrawGL，以便请求前面提到的DeferredGpuCommandService服务执行保存在它内部的Task，这是通过调用它的成员函数PerformIdleTask实现的。

       DeferredGpuCommandService类的成员函数PerformIdleTask会依次执行保存在内部Task队列的每一个Task。从前面的分析可以知道，这时候Task队列中存在一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。因此，这时候InProcessCommandBuffer类的成员函数FlushOnGpuThread就会在当前线程中被调用，也就是在App的Render Thread中被调用。

       前面提到，InProcessCommandBuffer类的成员函数FlushOnGpuThread在调用的过程中，会执行之前通过In-Process Command Buffer GL接口写入在Command Buffer中的GPU命令。InProcessCommandBuffer类的成员函数FlushOnGpuThread又是通过内部的一个GpuScheduler对象和一个GLES2Decoder对象执行这些GPU命令的。其中，GpuScheduler对象负责将GPU命令调度在它们对应的OpenGL上下文中执行，而GLES2Decoder对象负责将GPU命令翻译成OpenGL函数执行。关于GpuScheduler类和GLES2Decoder类执行GPU命令的过程，可以参考前面前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

       第二个场景发生Render端光栅化网页UI的过程中。从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章可以知道，Render端通过GPU光栅化网页UI的操作也是发生在Compositor线程中的。这时候它请求App的Render Thread执行GPU命令的大概流程相同，也是将要执行的GPU操作封装在一个DrawGLFunctor对象中。不过，这个DrawGLFunctor对象不会进一步被封装成DrawFunctionOp操作写入到App UI的Display List中，而是直接被App的UI线程放入到App的Render Thread中，App的Render Thread再通知它执行所请求的GPU操作。DrawGLFunctor对象获得执行GPU操作的通知后，后流的流程就与前面描述的第一个场景一致了。

       通过以上描述的方式，Android WebView的Browser端和Render端就可以执行任意的GPU命令了。其中，Render端执行GPU命令是为了绘制网页UI，而Browser端执行GPU命令是为了将Render端渲染出来的网页UI合成在App的UI中，以便最后可以显示在屏幕中。这个过程就是Android WebView硬件加速渲染网页的过程，如图5所示：

图5 Android WebView硬件加速渲染网页过程

       从前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章可以知道，App从接收到VSync信号开始渲染一帧UI。两个VSync信号时间间隔由屏幕刷新频率决定。一般的屏幕刷新频率是60fps，这意味着每一个VSync信号到来时，App有16ms的时间绘制自己的UI。

       这16ms时间又划分为三个阶段。第一阶段用来构造App UI的Display List。这个构造工作由App的UI线程执行，表现为各个需要更新的View的成员函数onDraw会被调用。第二阶段App的UI线程会将前面构造的Display List同步给Render Thread。这个同步操作由App的Render Thread执行，同时App的UI线程会被阻塞，直到同步操作完成为止。第三阶段是绘制App UI的Display List。这个绘制操作由App的Render Thread执行。

       由于Android WebView是嵌入在App的UI里面的，因此它每一帧的渲染也是按照上述三个阶段进行的。从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章可以知道，网页的UI最终是通过一个CC Layer Tree描述的，也就是Android WebView的Render端会创建一个CC Layer Tree来描述它正在加载的网页的UI。与此同时，Android WebView还会为Render端创建一个Synchronous Compositor，用来将网页的UI渲染在一个Synchronous Compositor Output Surface上。渲染得到的最终结果通过一个Compositor Frame描述。这意味网页的每一帧都是通过一个Compositor Frame描述的。

       Android WebView的Browser端负责合成Render端渲染出来的UI。为了完成这个合成操作，它同样会创建一个CC Layer Tree。这个CC Layer Tree只有两个节点，一个是根节点，另外一个是根节点的子节点，称为Delegated Renderer Layer。这个Delegated Renderer Layer的内容来自于Render端的渲染结果，也就是一个Compositor Frame。与此同时，Android WebView会为Browser端创建一个Hardware Renderer，用来将它的CC Layer Tree渲染在一个Parent Output Surface上，实际上就是将网页的UI合成在App的窗口上。

       在第一阶段，Android WebView的成员函数onDraw会在App的UI线程中被调用。在调用期间，它又会调用为Render端创建的Synchronous Compositor的成员函数DemandDrawHw，用来渲染Render端的CC Layer Tree。渲染完成后，为Render端创建的Synchronous Compositor Output Surface的成员函数SwapBuffers就会被调用，并且交给它一个Compositor Frame。这个Compositor Frame描述的就是网页当前的UI，它最终会被保存在一个SharedRendererState对象中。这个SharedRendererState对象是用来描述网页的状态的。

       在第二阶段，保存在上述SharedRendererState对象中的Compositor Frame会被提取出来，并且同步给Browser端的CC Layer Tree，也就是设置为该CC Layer Tree的Delegated Renderer Layer的内容。

       在第三阶段，Android WebView为Browser端创建的Hardware Renderer的成员函数DrawGL会在App的Render Thread中被调用，用来渲染Browser端的CC Layer Tree。渲染完成后，为Browser端创建的Parent Output Surface的成员函数SwapBuffers就会被调用，这时候它就会将得到的网页UI绘制在App的窗口上。

       以上就是Android WebView以硬件加速方式将网页UI渲染在App窗口的过程。当然，Android WebView也可用软件方式将网页UI渲染在App窗口。不过，在这个系列的文章中，我们只要关注硬件加速渲染方式，因为这种渲染方式效率会更高，而且Android系统从4.0版本之后，默认已经是使用硬件加速方式渲染App的UI了。

       接下来，我们就结合源码，按照以下四个情景，详细分析Android WebView硬件加速渲染网页UI的过程：

       1. Android WebView加载Chromium动态库的过程；

       2. Android WebView启动Chromium渲染引擎的过程；

       3. Android WebView执行OpenGL命令的过程；

       4. Android WebView硬件加速渲染网页UI的过程。

       分析了这四个情景之后，我们就可以对Android WebView的实现有深刻的认识了。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。