Android WebView使用的Chromium引擎，虽然没有自己的GPU进程或者线程，但是却可以执行GPU命令。原来，Android WebView会给它提供一个In-Process Command Buffer GL接口。通过这个接口，Chromium引擎就可以将GPU命令提交给App的Render Thread执行。本文接下来就详细分析Android WebView执行GPU命令的过程。

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

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

       从前面Chromium硬件加速渲染的OpenGL命令执行过程分析这篇文章可以知道，Chromium渲染引擎在有自己的GPU进程或者线程的情况下，是通过一个Command Buffer GL接口执行GPU命令的。这个Command Buffer GL接口通过一个GLES2Implementation类描述。Android WebView给Chromium引擎提供的In-Process Command Buffer GL接口，同样是通过GLES2Implementation类描述的。这样，Chromium渲染引擎就不用关心它发出的GPU命令是如何执行的。

       在Chromium渲染引擎中，需要执行GPU命令的是Render端和Browser端。Render端执行GPU命令是为渲染网页的UI，而Browser端执行GPU命令是为了将Render端渲染的网页UI合成显示在屏幕上。对Android WebView来说，它的Render端会将网页抽象成一个CC Layer Tree，然后使用一个Synchronous Compositor将它渲染在一个Synchronous Compositor Output Surface上，如图1所示：

图1 Android WebView的Render端渲染网页UI的示意图

       Android WebView的Browser端同样会将自己要合成的UI抽象为一个CC Layer Tree，然后使用一个Hardware Renderer将它渲染在一个Parent Output Surface上，如图2所示：

图2 Android WebView的Browser端合成网页UI的示意图

       Browser端的CC Layer Tree比较特别，它只有两个节点。一个是根节点，另一个是根节点的子节点，称为Delegated Render Layer，它要渲染的内容来自于Render端的渲染输出。从前面Chromium硬件加速渲染的UI合成过程分析一文可以知道，Render端的渲染输出是一系列的Render Pass。每一个Render Pass都包含了若干个纹理。这些纹理是在Render端光栅化网页时产生的。Browser端的Hardware Renderer所要做的事情就是将这些纹理渲染在屏幕上。这个过程也就是Browser端合成网页UI的过程。

       不管是Render端，还是Browser端，当它们执行GPU命令的时候，都是通过GLES2Implementation类描述的一个In-Process Command Buffer GL接口写入到一个Command Buffer中去的。只不过在Android WebView的情况下，这些GPU命令会被一个DeferredGpuCommandService服务提交给App的Render Thread执行，如图3所示：

图3 Android WebView执行GPU命令的过程

       Render端和Browser端将要执行的GPU命令写入到Command Buffer之后，就会请求DeferredGpuCommandService服务在App的Render Thread中调度执行一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。InProcessCommandBuffer类的成员函数FlushOnGpuThread又是通过一个Gpu Scheduler按照上下文来执行请求的GPU命令，并且这些GPU命令在执行之前，先要经过一个GLES2 Decoder进行解码。这个过程可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

       对于Browser端来说，它本来就是在App的Render Thread中请求执行GPU命令的。这时候DeferredGpuCommandService服务会直接在当前线程中调用InProcessCommandBuffer类的成员函数FlushOnGpuThread，以便执行请求的GPU命令。

       对于Render端来说，它在两种情景下需要请求执行GPU命令。第一种情景是光栅化网页的UI，第二种情景是绘制网页的UI。这两种情景都是发生在Render端的Compositor线程中。关于Render端的Compositor线程，以及网页UI的光栅化和绘制操作，可以参考前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章。

       上述两种情景都会将要执行的GPU操作抽象为一个DrawGLFunctor对象。对于第一个情景，DrawGLFunctor对象会通过App的UI线程直接提交给App的Render Thread。App的Render Thread再通知该DrawGLFunctor对象执行GPU操作。

       对于第二个情景，DrawGLFunctor对象会被App的UI线程封装为一个DrawFunctorOp操作，并且写入到App UI的Display List中。 接下来App的UI线程会将Display List同步给App的Render Thread。随后这个Display List就会被App的Render Thread通过一个OpenGL Renderer进行Replay，这时候Display List中包含的DrawFunctorOp操作就会被执行。在执行的过程中，与它关联的DrawGLFunctor对象获得通知。DrawGLFunctor对象获得通知以后就会执行之前Render端请求的GPU操作了。

       DrawGLFunctor对象在执行GPU操作的时候，会调用到一个DrawGL函数。这个DrawGL函数是Android WebView在启动Chromium渲染引擎时注册的。它在执行的过程中，就会通过Browser端的Hardware Renderer通知DeferredGpuCommandService服务执行此前请求调度的Task。这时候InProcessCommandBuffer类的成员函数FlushOnGpuThread就会被调用，这时候Render端之前请求的GPU命令就会被执行。

       接下来，我们就结合源码，分析Chromium渲染引擎的Render端和Browser端创建In-Process Command Buffer GL接口的过程，以及以Render端使用GPU光栅化网页的过程为例，分析Chromium渲染引擎通过In-Process Command Buffer GL接口执行GPU命令的过程。不过，在分析这些过程之前，我们首先分析Android WebView向Chromium渲染引擎注册DrawGL函数的过程。这个过程发生在Android WebView启动Chromium渲染引擎的Browser端的过程中。

       从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，Android WebView在启动Chromium渲染引擎的Browser端的过程中，会调用到WebViewChromiumFactoryProvider类的成员函数startChromiumLocked，如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    private void startChromiumLocked() {
        ......

        initPlatSupportLibrary();
        AwBrowserProcess.start(ActivityThread.currentApplication());
    
        ......
    }

    ......
}

       在调用AwBrowserProcess类的静态成员函数start动Chromium渲染引擎的Browser端之前，WebViewChromiumFactoryProvider类的成员函数startChromiumLocked先会调用成员函数initPlatSupportLibrary向Chromium渲染引擎注册一个DrawGL函数，如下所示：

public class WebViewChromiumFactoryProvider implements WebViewFactoryProvider {
    ......

    private void initPlatSupportLibrary() {
        DrawGLFunctor.setChromiumAwDrawGLFunction(AwContents.getAwDrawGLFunction());
        ......
    }

    ......
}

       这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/WebViewChromiumFactoryProvider.java中。

       WebViewChromiumFactoryProvider类的成员函数startChromiumLocked首先会调用AwContents类的静态成员函数getAwDrawGLFunction获得要注册的DrawGL函数，然后再调用DrawGLFunctor类的静态成员函数setChromiumAwDrawGLFunction将它注册到Chromium渲染引擎中。

       接下来，我们首先分析AwContents类的静态成员函数getAwDrawGLFunction获取要注册的DrawGL函数的过程，然后再分析DrawGLFunctor类的静态成员函数setChromiumAwDrawGLFunction注册DrawGL函数到Chromium渲染引擎的过程。

       AwContents类的静态成员函数getAwDrawGLFunction的实现如下所示：

public class AwContents {
    ......

    public static long getAwDrawGLFunction() {
        return nativeGetAwDrawGLFunction();
    }

    ......
}

       AwContents类的静态成员函数getAwDrawGLFunction调用另外一个静态成员函数AwContents类的静态成员函数获取要注册的的DrawGL函数的过程。

       AwContents类的静态成员函数AwContents类的静态成员函数是一个JNI方法，它由C++层的函数Java_com_android_org_chromium_android_1webview_AwContents_nativeGetAwDrawGLFunction实现，如下所示：

__attribute__((visibility("default")))
jlong
    Java_com_android_org_chromium_android_1webview_AwContents_nativeGetAwDrawGLFunction(JNIEnv*
    env, jclass jcaller) {
  return GetAwDrawGLFunction(env, jcaller);
}

       函数Java_com_android_org_chromium_android_1webview_AwContents_nativeGetAwDrawGLFunction又通过调用另外一个函数GetAwDrawGLFunction获取要注册的DrawGL函数，如下所示：

static jlong GetAwDrawGLFunction(JNIEnv* env, jclass) {
  return reinterpret_cast<intptr_t>(&DrawGLFunction);
}

      函数GetAwDrawGLFunction返回的是定义在同文件中的函数DrawGLFunction。这个函数的地址将会返回到前面分析的WebViewChromiumFactoryProvider类的成员函数initPlatSupportLibrary向Chromium，后者再调用DrawGLFunctor类的静态成员函数setChromiumAwDrawGLFunction将它注册到Chromium渲染引擎中，如下所示：

class DrawGLFunctor {
    ......

    public static void setChromiumAwDrawGLFunction(long functionPointer) {
        nativeSetChromiumAwDrawGLFunction(functionPointer);
    }

    ......
}

       DrawGLFunctor类的静态成员函数setChromiumAwDrawGLFunction调用另外一个静态成员函数nativeSetChromiumAwDrawGLFunction将前面获得的函数DrawGLFunction注册在Chromium渲染引擎中。

       DrawGLFunctor类的静态成员函数nativeSetChromiumAwDrawGLFunction是一个JNI方法，它由C++层的函数SetChromiumAwDrawGLFunction实现，如下所示：

AwDrawGLFunction* g_aw_drawgl_function = NULL;

......

void SetChromiumAwDrawGLFunction(JNIEnv*, jclass, jlong draw_function) {
  g_aw_drawgl_function = reinterpret_cast<AwDrawGLFunction*>(draw_function);
}

      函数SetChromiumAwDrawGLFunction将参数draw_function描述的函数DrawGLFunction的地址保存在全局变量g_aw_drawgl_function中。这样，Android WebView就在启动Chromium渲染引擎的Browser端的过程中，向Chromium渲染引擎注册了一个DrawGL函数。

      接下来，我们分析Chromium渲染引擎为Render端创建In-Process Command Buffer GL接口的过程。Chromium渲染引擎为Render端创建的In-Process Command Buffer GL接口是封装在绘图表面（Output Surface）里面的。在Chromium中，每一个网页都关联一个Output Surface。在分析Render端的In-Process Command Buffer GL接口的创建之前，我们首先分析网页的Output Surface的创建过程。

      从前面Chromium网页绘图表面（Output Surface）创建过程分析和Chromium的GPU进程启动过程分析这两篇文章可以知道，Render端在加载了网页之后，会为网页创建一个绘图表面，即一个Output Surface，最终是通过调用RenderWidget类的成员函数CreateOutputSurface进行创建的，如下所示：

scoped_ptr<cc::OutputSurface> RenderWidget::CreateOutputSurface(bool fallback) {
  ......

#if defined(OS_ANDROID)
  if (SynchronousCompositorFactory* factory =
      SynchronousCompositorFactory::GetInstance()) {
    return factory->CreateOutputSurface(routing_id());
  }
#endif

  ......
}

       在Android平台上，RenderWidget类的成员函数CreateOutputSurface首先会调用SynchronousCompositorFactory类的静态成员函数GetInstance检查当前进程是否存在一个用来创建Output Surface的工厂对象。如果存在，那么就会调用它的成员函数CreateOutputSurface为当前加载的网页创建一个Output Surface。

       SynchronousCompositorFactory类的静态成员函数GetInstance的实现如下所示：

SynchronousCompositorFactory* g_instance = NULL;

......

void SynchronousCompositorFactory::SetInstance(
    SynchronousCompositorFactory* instance) {
  ......

  g_instance = instance;
}

SynchronousCompositorFactory* SynchronousCompositorFactory::GetInstance() {
  return g_instance;
}

       这两个函数定义在文件external/chromium_org/content/renderer/android/synchronous_compositor_factory.cc。

       SynchronousCompositorFactory类的静态成员函数GetInstance返回的是全局变量g_instance指向的一个SynchronousCompositorFactoryImpl对象。这个SynchronousCompositorFactoryImpl对象是通过SynchronousCompositorFactory类的静态成员数SetInstance设置给全局变量g_instance的。

       这个SynchronousCompositorFactoryImpl对象是什么时候设置给全局变量g_instance的呢？回忆前面Android WebView启动Chromium渲染引擎的过程分析一文，Android WebView在启动Chromium渲染引擎的过程，会创建一个DeferredGpuCommandService服务，并且将这个DeferredGpuCommandService服务保存在一个SynchronousCompositorFactoryImpl对象的成员变量service_中。这个SynchronousCompositorFactoryImpl对象在创建的过程中，就会通过调用SynchronousCompositorFactory类的静态成员数SetInstance将自己保存在上述全局变量g_instance中，如下所示：

SynchronousCompositorFactoryImpl::SynchronousCompositorFactoryImpl()
    : record_full_layer_(true),
      num_hardware_compositors_(0) {
  SynchronousCompositorFactory::SetInstance(this);
}

      回到前面分析的RenderWidget类的成员函数CreateOutputSurface中，这时候它调用SynchronousCompositorFactory类的静态成员函数GetInstance就会获得一个SynchronousCompositorFactoryImpl对象。有了这个SynchronousCompositorFactoryImpl对象之后，RenderWidget类的成员函数CreateOutputSurface就会调用它的成员函数CreateOutputSurface为当前正在加载的网页创建一个Output Surface，如下所示：

scoped_ptr<cc::OutputSurface>
SynchronousCompositorFactoryImpl::CreateOutputSurface(int routing_id) {
  scoped_ptr<SynchronousCompositorOutputSurface> output_surface(
      new SynchronousCompositorOutputSurface(routing_id));
  return output_surface.PassAs<cc::OutputSurface>();
}

      SynchronousCompositorFactoryImpl类的成员函数CreateOutputSurface创建一个类型为Synchronous Compositor的Output Surface返回给调用者。从前面Chromium网页绘图表面（Output Surface）创建过程分析一文可以知道，这个Synchronous Compositor Output Surface将会返回给ThreadProxy类的成员函数CreateAndInitializeOutputSurface，如下所示：

void ThreadProxy::CreateAndInitializeOutputSurface() {  
  ......    
  
  scoped_ptr<OutputSurface> output_surface =  
      layer_tree_host()->CreateOutputSurface();  
  
  if (output_surface) {  
    Proxy::ImplThreadTaskRunner()->PostTask(  
        FROM_HERE,  
        base::Bind(&ThreadProxy::InitializeOutputSurfaceOnImplThread,  
                   impl_thread_weak_ptr_,  
                   base::Passed(&output_surface)));  
    return;  
  }  
  
  ......  
}  

       ThreadProxy类的成员函数CreateAndInitializeOutputSurface又会将这个Synchronous Compositor Output Surface传递给Render端的Compositor线程，让后者对它进行初始化。这个初始化操作是通过在Render端的Compositor线程中调用ThreadProxy类的成员函数InitializeOutputSurfaceOnImplThread实现的。

       从前面Chromium网页绘图表面（Output Surface）创建过程分析一文可以知道，ThreadProxy类的成员函数InitializeOutputSurfaceOnImplThread在初始化Synchronous Compositor Output Surface的过程中，会调用它的成员函数BindToClient，表示它已经被设置给一个网页使用。

       SynchronousCompositorOutputSurface类的成员函数BindToClient的实现如下所示：

bool SynchronousCompositorOutputSurface::BindToClient(
    cc::OutputSurfaceClient* surface_client) {
  ......

  SynchronousCompositorOutputSurfaceDelegate* delegate = GetDelegate();
  if (delegate)
    delegate->DidBindOutputSurface(this);

  return true;
}

       SynchronousCompositorOutputSurface类的成员函数BindToClient会调用另外一个成员函数GetDelegate获得一个Delegate对象，如下所示：

SynchronousCompositorOutputSurfaceDelegate*
SynchronousCompositorOutputSurface::GetDelegate() {
  return SynchronousCompositorImpl::FromRoutingID(routing_id_);
}

       SynchronousCompositorOutputSurface类的成员函数GetDelegate通过调用SynchronousCompositorImpl类的静态成员函数FromRoutingID获得一个Delegate对象，如下所示：

SynchronousCompositorImpl* SynchronousCompositorImpl::FromRoutingID(
    int routing_id) {
  return FromID(GetInProcessRendererId(), routing_id);
}

       SynchronousCompositorImpl类的静态成员函数FromRoutingID首先会调用静态成员函数GetInProcessRendererId获得当前正在处理的Render端的ID。有了这个ID之后，连同参数routing_id描述的网页ID，传递给SynchronousCompositorImpl类的另外一个静态成员函数FromID，如下所示：

SynchronousCompositorImpl* SynchronousCompositorImpl::FromID(int process_id,
                                                             int routing_id) {
  ......
  RenderViewHost* rvh = RenderViewHost::FromID(process_id, routing_id);
  ......
  WebContents* contents = WebContents::FromRenderViewHost(rvh);
  ......
  return FromWebContents(contents);
}

       SynchronousCompositorImpl类的静态成员函数FromID首先通过调用RenderViewHost类的静态成员函数FromID获得与参数process_id和routing_id对应的一个RenderViewHost对象。这个RenderViewHost对象用来在Browser端描述的一个网页。这个网页就是当前正在Android WebView中加载的网页。

       获得了与当前正在加载的网页对应的RenderViewHost对象之后，就可以调用WebContents类的静态成员函数FromRenderViewHost获得一个WebContents对象。在Chromium中，每一个网页在Content层又都是通过一个WebContents对象描述的。这个WebContents对象的创建过程可以参考前面Android WebView启动Chromium渲染引擎的过程分析一文。

       获得了用来描述当前正在加载的网页的WebContents对象之后，SynchronousCompositorImpl类的静态成员函数FromID就可以调用另外一个静态成员函数FromWebContents获得一个SynchronousCompositorImpl对象。这个SynchronousCompositorImpl对象的创建过程可以参考前面Android WebView启动Chromium渲染引擎的过程分析一文，它是负责用来渲染在Android WebView中加载的网页的UI的。

       SynchronousCompositorImpl类的静态成员函数FromID最后会将获得的SynchronousCompositorImpl对象返回给调用者，也就是前面分析的SynchronousCompositorOutputSurface类的成员函数BindToClient。SynchronousCompositorOutputSurface类的成员函数BindToClient接下来会调用这个SynchronousCompositorImpl对象的成员函数DidBindOutputSurface，表示它现在已经与一个Synchronous Compositor Output Surface建立了绑定关系，这样以后它就可以将网页的UI渲染在这个Synchronous Compositor Output Surface之上。

       SynchronousCompositorImpl类的成员函数DidBindOutputSurface的实现如下所示：

void SynchronousCompositorImpl::DidBindOutputSurface(
      SynchronousCompositorOutputSurface* output_surface) {
  ......
  output_surface_ = output_surface;
  if (compositor_client_)
    compositor_client_->DidInitializeCompositor(this);
}

       SynchronousCompositorImpl类的成员函数DidBindOutputSurface首先将参数output_surface描述的Synchronous Compositor Output Surface保存在成员变量output_surface_中。

       从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，SynchronousCompositorImpl类的成员变量compositor_client_指向的是一个BrowserViewRenderer对象。SynchronousCompositorImpl类的成员函数DidBindOutputSurface最后会调用这个BrowserViewRenderer对象的成员函数DidInitializeCompositor，表示Chromium渲染引擎已经为它创建了一个用来渲染网页UI的Synchronous Compositor，如下所示：

void BrowserViewRenderer::DidInitializeCompositor(
    content::SynchronousCompositor* compositor) {
  ......

  compositor_ = compositor;
}

       BrowserViewRenderer类的成员函数DidInitializeCompositor会将参数compositor指向的一个SynchronousCompositorImpl对象保存在成员变量compositor_中。

       这一步执行完成之后，Chromium渲染引擎就为在Render端加载的网页创建了一个Synchronous Compositor Output Surface，并且会将这个Synchronous Compositor Output Surface设置给一个Synchronous Compositor。这个Synchronous Compositor又会设置给一个BrowserViewRenderer对象。这个BrowserViewRenderer对象负责绘制Android WebView的UI。

       接下来我们就开始分析Chromium渲染引擎为Render端创建In-Process Command Buffer GL接口的过程。这个In-Process Command Buffer GL接口是在Android WebView第一次执行硬件加速渲染之前创建的。从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，Android WebView每次被绘制时，它在Chromium的android_webview模块中对应的AwContents对象的成员函数OnDraw都会被调用，如下所示：

bool AwContents::OnDraw(JNIEnv* env,
                        jobject obj,
                        jobject canvas,
                        jboolean is_hardware_accelerated,
                        jint scroll_x,
                        jint scroll_y,
                        jint visible_left,
                        jint visible_top,
                        jint visible_right,
                        jint visible_bottom) {
  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
  if (is_hardware_accelerated)
    InitializeHardwareDrawIfNeeded();
  return browser_view_renderer_.OnDraw(
      canvas,
      is_hardware_accelerated,
      gfx::Vector2d(scroll_x, scroll_y),
      gfx::Rect(visible_left,
                visible_top,
                visible_right - visible_left,
                visible_bottom - visible_top));
}

      如果执行的是硬件加速渲染，那么AwContents类的成员函数OnDraw首先会调用另外一个成员函数InitializeHardwareDrawIfNeeded检查当前是否已经创建了一个DeferredGpuCommandService服务。如果还没有创建，那么就会进行创建。这个DeferredGpuCommandService服务的创建过程可以参考前面Android WebView启动Chromium渲染引擎的过程分析一文。

      AwContents类的成员函数OnDraw接下来会调用成员变量browser_view_renderer_描述的一个BrowserViewRenderer对象的成员函数OnDraw执行硬件加速渲染，如下所示：

bool BrowserViewRenderer::OnDraw(jobject java_canvas,
                                 bool is_hardware_canvas,
                                 const gfx::Vector2d& scroll,
                                 const gfx::Rect& global_visible_rect) {
  ......

  if (is_hardware_canvas && attached_to_window_)
    return OnDrawHardware(java_canvas);
  // Perform a software draw
  return OnDrawSoftware(java_canvas);
}

       在执行硬件加速渲染的情况下，BrowserViewRenderer对象的成员函数OnDraw会调用成员函数OnDrawHardware对Android WebView进行绘制，如下所示：

bool BrowserViewRenderer::OnDrawHardware(jobject java_canvas) {
  ......

  if (!hardware_enabled_) {
    hardware_enabled_ = compositor_->InitializeHwDraw();
    ......
  }

  ......

  scoped_ptr<DrawGLInput> draw_gl_input(new DrawGLInput);
  ......

  scoped_ptr<cc::CompositorFrame> frame =
      compositor_->DemandDrawHw(surface_size,
                                gfx::Transform(),
                                viewport,
                                clip,
                                viewport_rect_for_tile_priority,
                                transform_for_tile_priority);
  ......

  shared_renderer_state_->SetDrawGLInput(draw_gl_input.Pass());
  ......
  return client_->RequestDrawGL(java_canvas, false);
}

       当BrowserViewRenderer类的成员变量hardware_enabled_的值等于false时，表示Android WebView是第一次启用硬件加速渲染。在这种情况下，BrowserViewRenderer类的函数OnDraw首先会初始化一个硬件加速渲染环境，然后再对Android WebView进行绘制。

       从前面的分析可以知道，BrowserViewRenderer类的成员变量compositor_指向的是一个SynchronousCompositorImpl对象。BrowserViewRenderer类的函数OnDraw就是通过调用这个SynchronousCompositorImpl对象的成员函数InitializeHwDraw初始化一个硬件加速渲染环境的。在初始化这个硬件加速渲染环境的过程中，就会创建一个In-Process Command Buffer GL接口。

       接下来，我们就继续分析SynchronousCompositorImpl类的成员函数InitializeHwDraw初始化创建In-Process Command Buffer GL接口的过程。在接下来一篇文章中，我们再分析BrowserViewRenderer类的函数OnDraw绘制Android WebView的过程。

       SynchronousCompositorImpl类的成员函数InitializeHwDraw的实现如下所示：

base::LazyInstance<SynchronousCompositorFactoryImpl>::Leaky g_factory =
    LAZY_INSTANCE_INITIALIZER;

......

bool SynchronousCompositorImpl::InitializeHwDraw() {
  ......

  scoped_refptr<cc::ContextProvider> onscreen_context =
      g_factory.Get().CreateOnscreenContextProviderForCompositorThread();

  bool success = output_surface_->InitializeHwDraw(onscreen_context);

  ......
  return success;
}

       全局变量指向的就是前面提到的用来为网页创建Output Surface的SynchronousCompositorFactoryImpl对象。SynchronousCompositorImpl类的成员函数InitializeHwDraw调用这个SynchronousCompositorFactoryImpl对象的成员函数CreateOnscreenContextProviderForCompositorThread创建一个硬件加速渲染环境。

       创建出来的硬件加速渲染环境是通过一个ContextProviderInProcess对象描述的。这个ContextProviderInProcess对象又会设置给SynchronousCompositorImpl类的成员变量output_surface_描述的一个Synchronous Compositor Output Surface。Synchronous Compositor Output Surface有了硬件加速渲染环境之后，就可以执行GPU命令了。

       接下来，我们首先分析SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread创建硬件加速渲染环境的过程，如下所示：

scoped_refptr<cc::ContextProvider> SynchronousCompositorFactoryImpl::
    CreateOnscreenContextProviderForCompositorThread() {
  ......
  return webkit::gpu::ContextProviderInProcess::Create(
      WrapContext(CreateContext(service_, share_context_.get())),
      "Child-Compositor");
}

       SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread首先调有函数CreateContext创建一个In-Process Command Buffer GL接口，然后再调用另外一个函数WrapContext将这个In-Process Command Buffer GL接口封装在一个WebGraphicsContext3DInProcessCommandBufferImpl对象，最后调用ContextProviderInProcess类的静态成员函数Create将该WebGraphicsContext3DInProcessCommandBufferImpl对象封装在一个ContextProviderInProcess对象中。

       从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，SynchronousCompositorFactoryImpl类的成员变量service_指向的就是一个DeferredGpuCommandService服务。函数CreateContext在创建In-Process Command Buffer GL接口的时候，会使用到这个DeferredGpuCommandService服务，如下所示：

scoped_ptr<gpu::GLInProcessContext> CreateContext(
    scoped_refptr<gpu::InProcessCommandBuffer::Service> service,
    gpu::GLInProcessContext* share_context) {
  ......

  scoped_ptr<gpu::GLInProcessContext> context(
      gpu::GLInProcessContext::Create(service,
                                      NULL /* surface */,
                                      false /* is_offscreen */,
                                      gfx::kNullAcceleratedWidget,
                                      gfx::Size(1, 1),
                                      share_context,
                                      false /* share_resources */,
                                      in_process_attribs,
                                      gpu_preference));
  return context.Pass();
}

       函数调用GLInProcessContext类的静态成员函数Create创建了一个In-Process Command Buffer GL接口，如下所示：

GLInProcessContext* GLInProcessContext::Create(
    scoped_refptr<gpu::InProcessCommandBuffer::Service> service,
    scoped_refptr<gfx::GLSurface> surface,
    bool is_offscreen,
    gfx::AcceleratedWidget window,
    const gfx::Size& size,
    GLInProcessContext* share_context,
    bool use_global_share_group,
    const GLInProcessContextAttribs& attribs,
    gfx::GpuPreference gpu_preference) {
  ......

  scoped_ptr<GLInProcessContextImpl> context(new GLInProcessContextImpl());
  if (!context->Initialize(surface,
                           is_offscreen,
                           use_global_share_group,
                           share_context,
                           window,
                           size,
                           attribs,
                           gpu_preference,
                           service))
    return NULL;

  return context.release();
}

       GLInProcessContext类的静态成员函数Create首先创建了一个GLInProcessContextImpl对象，然后调用这个GLInProcessContextImpl对象的成员函数Initialize对其进行初始化。在初始化的过程中，就会创建一个In-Process Command Buffer GL接口，如下所示：

bool GLInProcessContextImpl::Initialize(
    scoped_refptr<gfx::GLSurface> surface,
    bool is_offscreen,
    bool use_global_share_group,
    GLInProcessContext* share_context,
    gfx::AcceleratedWidget window,
    const gfx::Size& size,
    const GLInProcessContextAttribs& attribs,
    gfx::GpuPreference gpu_preference,
    const scoped_refptr<InProcessCommandBuffer::Service>& service) {
  ......

  command_buffer_.reset(new InProcessCommandBuffer(service));
  ......

  if (!command_buffer_->Initialize(surface,
                                   is_offscreen,
                                   window,
                                   size,
                                   attrib_vector,
                                   gpu_preference,
                                   wrapped_callback,
                                   share_command_buffer)) {
    ......
    return false;
  }

  // Create the GLES2 helper, which writes the command buffer protocol.
  gles2_helper_.reset(new gles2::GLES2CmdHelper(command_buffer_.get()));
  ......

  // Create the object exposing the OpenGL API.
  gles2_implementation_.reset(new gles2::GLES2Implementation(
      gles2_helper_.get(),
      share_group,
      transfer_buffer_.get(),
      bind_generates_resources,
      attribs.lose_context_when_out_of_memory > 0,
      command_buffer_.get()));
  ......

  return true;
}

       GLInProcessContextImpl类的成员函数Initialize创建In-Process Command Buffer GL接口的过程与前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文提到的Command Buffer GL接口的创建过程是类似的。首先是创建一个Command Buffer，然后再将该Command Buffer封装在一个GLES2CmdHelper对象中。以后通过个GLES2CmdHelper对象就可以将要执行的GPU命令写入到它封装的Command Buffer中去。最后又会使用前面封装得到的GLES2CmdHelper对象创建一个GLES2Implementation对象。这个GLES2Implementation对象就用来描述的一个In-Process Command Buffer GL或者Command Buffer GL接口。

       In-Process Command Buffer GL接口与Command Buffer GL接口的最大区别就在于它们使用了不同的Command Buffer。In-Process Command Buffer GL使用的Command Buffer是一个In-Process Command Buffer，而Command Buffer GL接口使用的Command Buffer是一个Command Buffer Proxy。In-Process Command Buffer会将要执行的GPU命令发送给App的Render Thread处理，而Command Buffer Proxy会将要执行的GPU命令发送给Chromium的GPU进程/线程处理。

       接下来，我们就重点分析In-Process Command Buffer的创建过程，以便后面可以更好地理解它是怎么将要执行的GPU命令发送给App的Render Thread处理的。

       从前面的调用过程可以知道，参数service描述的是一个DeferredGpuCommandService服务。这个DeferredGpuCommandService服务将会用来创建In-Process Command Buffer，如下所示：

InProcessCommandBuffer::InProcessCommandBuffer(
    const scoped_refptr<Service>& service)
    : ......,
      service_(service.get() ? service : GetDefaultService()),
      ...... {
  ......
}

       在创建In-Process Command Buffer的过程中，如果指定了一个Service，那么以后就会通过这个Service执行GPU命令。在我们这个情景中，指定的Service即为一个DeferredGpuCommandService服务。因此，这时候InProcessCommandBuffer类的成员变量service_指向的是一个DeferredGpuCommandService服务。

       如果在创建In-Process Command Buffer的过程中，没有指定一个Service，那么InProcessCommandBuffer的构造函数就会通过调用另外一个成员函数GetDefaultService获得一个默认的Service，用来执行GPU命令。这个默认的Service实际上就是一个自行创建的GPU线程。

       回到GLInProcessContextImpl类的成员函数Initialize中，它创建了一个In-Process Command Buffer之后，接下来还会调用这个InProcessCommandBuffer类的成员函数Initialize对它进行初始化，如下所示：

bool InProcessCommandBuffer::Initialize(
    scoped_refptr<gfx::GLSurface> surface,
    bool is_offscreen,
    gfx::AcceleratedWidget window,
    const gfx::Size& size,
    const std::vector<int32>& attribs,
    gfx::GpuPreference gpu_preference,
    const base::Closure& context_lost_callback,
    InProcessCommandBuffer* share_group) {
  ......

  gpu::Capabilities capabilities;
  InitializeOnGpuThreadParams params(is_offscreen,
                                     window,
                                     size,
                                     attribs,
                                     gpu_preference,
                                     &capabilities,
                                     share_group);

  base::Callback<bool(void)> init_task =
      base::Bind(&InProcessCommandBuffer::InitializeOnGpuThread,
                 base::Unretained(this),
                 params);

  base::WaitableEvent completion(true, false);
  bool result = false;
  QueueTask(
      base::Bind(&RunTaskWithResult<bool>, init_task, &result, &completion));
  completion.Wait();

  ......
  return result;
}

       InProcessCommandBuffer类的成员函数Initialize所做的事情就是通过成员变量service_指向的DeferredGpuCommandService服务请求在App的Render Thread中调用InProcessCommandBuffer类的成员函数InitializeOnGpuThread，以便对当前正在创建的In-Process Command Buffer进行初始化。

       后面分析Render端执行的GPU命令的过程时，我们就会清楚地看到DeferredGpuCommandService服务是如何请求在App的Render Thread执行一个操作的。现在我们主要关注In-Process Command Buffer的初始化过程，也就是InProcessCommandBuffer类的成员函数InitializeOnGpuThread的实现，如下所示：

bool InProcessCommandBuffer::InitializeOnGpuThread(
    const InitializeOnGpuThreadParams& params) {
  ......

  scoped_ptr<CommandBufferService> command_buffer(
      new CommandBufferService(transfer_buffer_manager_.get()));
  command_buffer->SetPutOffsetChangeCallback(base::Bind(
      &InProcessCommandBuffer::PumpCommands, gpu_thread_weak_ptr_));
  ......

  decoder_.reset(gles2::GLES2Decoder::Create(
      params.context_group
          ? params.context_group->decoder_->GetContextGroup()
          : new gles2::ContextGroup(NULL,
                                    NULL,
                                    NULL,
                                    service_->shader_translator_cache(),
                                    NULL,
                                    bind_generates_resource)));

  gpu_scheduler_.reset(
      new GpuScheduler(command_buffer.get(), decoder_.get(), decoder_.get()));
  ......
  command_buffer_ = command_buffer.Pass();

  decoder_->set_engine(gpu_scheduler_.get());

  ......
}

       InProcessCommandBuffer类的成员函数InitializeOnGpuThread首先是创建了一个Command Buffer Service，并且保存在成员变量command_buffer_中。这个Command Buffer Service负责管理Command Buffer的状态，例如第一个等待执行的GPU命令的位置，以及最新写入的GPU命令的位置，等等。

       InProcessCommandBuffer类的成员函数InitializeOnGpuThread创建了一个Command Buffer Service，会调用它的成员函数SetPutOffsetChangeCallback，用来设置一个Put Offset Change Callback，如下所示：

void CommandBufferService::SetPutOffsetChangeCallback(
    const base::Closure& callback) {
  put_offset_change_callback_ = callback;
}

       这个Callback指定为当前正在创建的In-Process Command Buffer的成员函数PumpCommands。当我们往Command Buffer写入了新的GPU命令时，这个Callback就会被执行，也就是InProcessCommandBuffer类的成员函数PumpCommands会被调用。

       InProcessCommandBuffer类的成员函数PumpCommands在调用的过程中，就会通过一个Gpu Scheduler和一个GLES2 Decoder执行新写入到Command Buffer中的GPU命令。Gpu Scheduler在执行一个GPU命令之前，会将当前的OpenGL上下文切换至该GPU命令所属的OpenGL上下文，这样它就可以同时支持多个OpenGL上下文。GLES2 Decoder负责从Command Buffer中解析出每一个待执行的GPU命令及其携带的参数，这样就可以通过调用对应的OpenGL函数执行它们。关于Gpu Scheduler和一个GLES2 Decoder执行GPU命令的过程，可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

       回到前面分析的InProcessCommandBuffer类的成员函数InitializeOnGpuThread中，上述Gpu Scheduler和GLES2 Decoder也是在InProcessCommandBuffer类的成员函数InitializeOnGpuThread中创建的。创建出来之后，就分别保存在InProcessCommandBuffer类的成员变量gpu_scheduler_和decoder_中。

       这一步执行完成后，回到前面分析的SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread中，这时候它就获得了一个In-Process Command Buffer GL接口。这个In-Process Command Buffer GL接口是封装在一个GLInProcessContextImpl对象中的。这个GLInProcessContextImpl对象接下来又会通过函数WrapContext封装在一个WebGraphicsContext3DInProcessCommandBufferImpl对象中，如下所示：

scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl> WrapContext(
    scoped_ptr<gpu::GLInProcessContext> context) {
  ......

  return scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl>(
      WebGraphicsContext3DInProcessCommandBufferImpl::WrapContext(
          context.Pass(), GetDefaultAttribs()));
}

       函数WrapContext通过调用WebGraphicsContext3DInProcessCommandBufferImpl类的静态成员函数WrapContext将一个GLInProcessContextImpl对象封装在一个WebGraphicsContext3DInProcessCommandBufferImpl对象中，如下所示：

scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl>
WebGraphicsContext3DInProcessCommandBufferImpl::WrapContext(
    scoped_ptr< ::gpu::GLInProcessContext> context,
    const blink::WebGraphicsContext3D::Attributes& attributes) {
  bool lose_context_when_out_of_memory = false;  // Not used.
  bool is_offscreen = true;                      // Not used.
  return make_scoped_ptr(new WebGraphicsContext3DInProcessCommandBufferImpl(
      context.Pass(),
      attributes,
      lose_context_when_out_of_memory,
      is_offscreen,
      gfx::kNullAcceleratedWidget /* window. Not used. */));
}

       WebGraphicsContext3DInProcessCommandBufferImpl类的构造函数会将要封装的GLInProcessContextImpl对象保存在成员变量context_中，如下所示：

WebGraphicsContext3DInProcessCommandBufferImpl::
    WebGraphicsContext3DInProcessCommandBufferImpl(
        scoped_ptr< ::gpu::GLInProcessContext> context,
        const blink::WebGraphicsContext3D::Attributes& attributes,
        bool lose_context_when_out_of_memory,
        bool is_offscreen,
        gfx::AcceleratedWidget window)
    : ......,
      context_(context.Pass()) {
  ......
}

       这一步执行完成后，继续回到前面分析的SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread中，这时候它就获得了一个WebGraphicsContext3DInProcessCommandBufferImpl对象。这个WebGraphicsContext3DInProcessCommandBufferImpl对象通过一个GLInProcessContextImpl对象间接地保存了前面创建的In-Process Command Buffer GL接口

       SynchronousCompositorFactoryImpl类的成员函数CreateOnscreenContextProviderForCompositorThread最后又会调用ContextProviderInProcess类的静态成员函数Create将上述WebGraphicsContext3DInProcessCommandBufferImpl对象封装在一个ContextProviderInProcess对象中，如下所示：

scoped_refptr<ContextProviderInProcess> ContextProviderInProcess::Create(
    scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl> context3d,
    const std::string& debug_name) {
  ......
  return new ContextProviderInProcess(context3d.Pass(), debug_name);
}

       ContextProviderInProcess对象会将要封装的WebGraphicsContext3DInProcessCommandBufferImpl对象保存在成员变量context_中，如下所示：

ContextProviderInProcess::ContextProviderInProcess(
    scoped_ptr<WebGraphicsContext3DInProcessCommandBufferImpl> context3d,
    const std::string& debug_name)
    : context3d_(context3d.Pass()),
      ...... {
  ......
}

      这一步执行完成后，SynchronousCompositorImpl类的成员函数InitializeHwDraw，这时候它就是初始化了一个硬件加速渲染环境。这个硬件加速渲染环境就是通过前面创建的ContextProviderInProcess对象描述。这个ContextProviderInProcess对象接来会设置给SynchronousCompositorImpl类的成员变量output_surface_描述的一个Synchronous Compositor Output Surface。这是通过调用SynchronousCompositorOutputSurface类的成员函数InitializeHwDraw实现的，如下所示：

bool SynchronousCompositorOutputSurface::InitializeHwDraw(
    scoped_refptr<cc::ContextProvider> onscreen_context_provider) {
  ......

  return InitializeAndSetContext3d(onscreen_context_provider);
}

       SynchronousCompositorOutputSurface类的成员函数InitializeHwDraw会调用另外一个成员函数InitializeAndSetContext3d将参数onscreen_context_provider指向的ContextProviderInProcess对象保存在内部。以后通过这个ContextProviderInProcess对象，就可以获得前面创建的In-Process Command Buffer GL接口了。

       SynchronousCompositorOutputSurface类的成员函数InitializeAndSetContext3d是从父类OutputSurface继承下来的，它的实现如下所示：

bool OutputSurface::InitializeAndSetContext3d(
    scoped_refptr<ContextProvider> context_provider) {
  ......

  bool success = false;
  if (context_provider->BindToCurrentThread()) {
    context_provider_ = context_provider;
    ......
    success = true;
  }

  ......

  return success;
}

       OutputSurface类的成员函数InitializeAndSetContext3d首先会调用参数context_provider指向的ContextProviderInProcess对象的成员函数BindToCurrentThread将其引用的In-Process Command Buffer GL接口设置为当前线程所使用的GL接口。当前线程即为Render端的Compositor线程。有了这个GL接口之后，Render端的Compositor线程就可以执行GPU操作了。

       成功将参数context_provider指向的ContextProviderInProcess对象引用的In-Process Command Buffer GL接口设置为当前线程所使用的GL接口之后，该ContextProviderInProcess对象就会保存在OutputSurface类的成员变量context_provider_中。

       接下来我们继续分析ContextProviderInProcess类的成员函数BindToCurrentThread为当前线程设置Process Command Buffer GL接口的过程，如下所示：

bool ContextProviderInProcess::BindToCurrentThread() {
  ......

  if (!context3d_->makeContextCurrent())
    return false;

  ......
  return true;
}

       从前面的分析可以知道，ContextProviderInProcess类的成员变量context3d_指向的是一个WebGraphicsContext3DInProcessCommandBufferImpl对象。ContextProviderInProcess类的成员函数BindToCurrentThread会调用这个WebGraphicsContext3DInProcessCommandBufferImpl对象的成员函数makeContextCurrent将前面创建的In-Process Command Buffer GL接口设置为当前线程所使用的GL接口，如下所示：

bool WebGraphicsContext3DInProcessCommandBufferImpl::makeContextCurrent() {
  if (!MaybeInitializeGL())
    return false;
  ::gles2::SetGLContext(GetGLInterface());
  return context_ && !isContextLost();
}

       WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数makeContextCurrent首先调用成员函数MaybeInitializeGL检查是否已经为当前线程初始化过GL接口了。如果还没有初始化，那么就会进行初始化，如下所示：

bool WebGraphicsContext3DInProcessCommandBufferImpl::MaybeInitializeGL() {
  if (initialized_)
    return true;
  ......

  real_gl_ = context_->GetImplementation();
  setGLInterface(real_gl_);

  ......

  initialized_ = true;
  return true;
}

       当WebGraphicsContext3DInProcessCommandBufferImpl类的成员变量initialized_的值等于true的时候，就表示当前线程初始化过GL接口了。另一方面，如果当前线程还没有初始化过GL接口，那么WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数MaybeInitializeGL就会进行初始化。

       从前面的分析可以知道，WebGraphicsContext3DInProcessCommandBufferImpl类的成员变量context_指向的是一个GLInProcessContextImpl对象。调用这个GLInProcessContextImpl对象的成员函数可以获得它内部封装一个GLES2Implementation对象。这个GLES2Implementation对象描述的就是一个In-Process Command Buffer GL接口。

       WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数MaybeInitializeGL获得了上述In-Process Command Buffer GL接口之后，会调用另外一个成员函数setGLInterface将其保存起来。

       WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数setGLInterface是从父类WebGraphicsContext3DImpl继承下来的，它的实现如下所示：

class WEBKIT_GPU_EXPORT WebGraphicsContext3DImpl  
    : public NON_EXPORTED_BASE(blink::WebGraphicsContext3D) {  
 public:  
  ......  
  
  ::gpu::gles2::GLES2Interface* GetGLInterface() {  
    return gl_;  
  }  
  
 protected:  
  ......  
  
  void setGLInterface(::gpu::gles2::GLES2Interface* gl) {  
    gl_ = gl;  
  }  
  
  ......  
  
  ::gpu::gles2::GLES2Interface* gl_;  
  ......  
};  

       WebGraphicsContext3DImpl类的成员函数setGLInterface将参数描述的In-Process Command Buffer GL接口保存在成员变量gl_中。这个In-Process Command Buffer GL接口可以通过调用WebGraphicsContext3DImpl类的另外一个成员函数GetGLInterface获得。

       这一步执行完成后，回到前面分析的WebGraphicsContext3DInProcessCommandBufferImpl类的成员函数makeContextCurrent，它接下来又会调用从父类WebGraphicsContext3DImpl继承下来的成员函数GetGLInterface获得前面所保存的In-Process Command Buffer GL接口，并且将该In-Process Command Buffer GL接口设置为当前线程的GL接口，也就是OpenGL调用接口。这是通过调用函数gles2::SetGLContext实现的，如下所示：

static gpu::ThreadLocalKey g_gl_context_key;   

......
 
gpu::gles2::GLES2Interface* GetGLContext() {  
  return static_cast<gpu::gles2::GLES2Interface*>(  
    gpu::ThreadLocalGetValue(g_gl_context_key));  
}
 
void SetGLContext(gpu::gles2::GLES2Interface* context) {  
  gpu::ThreadLocalSetValue(g_gl_context_key, context);  
}  

       参数context描述的In-Process Command Buffer GL接口将被保存在全局变量g_gl_context_key所描述的一个线程局部储存中，作为当前线程所使用的OpenGL接口。以后通过调用另外一个函数gles2::GetGLContext就可以获得保存在这个线程局部储存中的In-Process Command Buffer GL接口。

       这一步执行完成后，以后Render端的Compositor线程直接调用OpenGL函数glXXX时，就会通过In-Process Command Buffer GL接口执行指定的GPU的操作。从OpenGL函数glXXX调用到In-Process Command Buffer GL接口的原理可以参考前面Chromium网页GPU光栅化原理分析一文。

       Render端的Compositor线程除了可以通过OpenGL函数glXXX使用In-Process Command Buffer GL接口，还可以通过它为网页创建的Synchronous Compositor Output Surface使用In-Process Command Buffer GL接口。接下来，我们就以Render端的Compositor线程执行GPU光栅化操作为例，说明它执行GPU命令的过程。

       从前面Chromium网页GPU光栅化原理分析一文可以知道，当Render端的Compositor线程是通过一个Skia Canvas对网页UI进行GPU光栅化操作的。这个Skia Canvas又是通过一个类型为SkSurface_Gpu的Skia Surface获得的。这个类型为SkSurface_Gpu的Skia Surface是通过调用DirectRasterBuffer类的成员函数CreateSurface创建的，如下所示：

skia::RefPtr<SkSurface> ResourceProvider::DirectRasterBuffer::CreateSurface() {  
  skia::RefPtr<SkSurface> surface;  
  switch (resource()->type) {  
    case GLTexture: {  
      ......  
      class GrContext* gr_context = resource_provider()->GrContext();  
      if (gr_context) {  
        GrBackendTextureDesc desc;  
        ......
 
        skia::RefPtr<GrTexture> gr_texture =  
            skia::AdoptRef(gr_context->wrapBackendTexture(desc));  
        ......
  
        surface = skia::AdoptRef(SkSurface::NewRenderTargetDirect(  
            gr_texture->asRenderTarget(), text_render_mode));  
      }  
      break;  
    }  
    ......
  }  
  return surface;  
}

       DirectRasterBuffer类的成员函数CreateSurface的详细实现可以参考前面Chromium网页GPU光栅化原理分析一文。这里我们所关注的重点是它通过调用ResourceProvider类的成员函数GrContext获得一个In-Process Command Buffer GL接口的过程。这个In-Process Command Buffer GL接口会传递给这里所创建的类型为SkSurface_Gpu的Skia Surface。有了In-Process Command Buffer GL接口之后，类型为SkSurface_Gpu的Skia Surface就可以通过GPU对网页的UI进行光栅化了。

       DirectRasterBuffer类的成员函数CreateSurface首先是调用成员函数resource_provider获得一个ResourceProvider对象。这个ResourceProvider对象负责管理网页在渲染过程中所要使用到的资源。有这个ResourceProvider对象之后，就可以调用它的成员函数GrContext获得一个In-Process Command Buffer GL接口，如下所示：

class GrContext* ResourceProvider::GrContext() const {
  ContextProvider* context_provider = output_surface_->context_provider();
  return context_provider ? context_provider->GrContext() : NULL;
}

      ResourceProvider类的成员变量output_surface_指向的就是一个SynchronousCompositorOutputSurface对象。ResourceProvider类的成员函数GrContext会调用这个SynchronousCompositorOutputSurface对象的成员函数context_provider获得一个Context Provider。

      SynchronousCompositorOutputSurface对象的成员函数context_provider是从父类OutputSurface继承下来的，它的实现如下所示：

class CC_EXPORT OutputSurface {
  ......

  scoped_refptr<ContextProvider> context_provider() const {
    return context_provider_.get();
  }

  ......
};

       从前面的分析可以知道，此时OutputSurface类的成员变量context_provider_指向的是一个ContextProviderInProcess对象。OutputSurface类的成员函数context_provider将这个ContextProviderInProcess对象返回给调用者。

       回到前面分析的ResourceProvider类的成员函数GrContext中，这时候它就获得了一个ContextProviderInProcess对象。接下来它继续调用这个ContextProviderInProcess对象的成员函数GrContext获得一个GrContextForWebGraphicsContext3D对象，如下所示：

class GrContext* ContextProviderInProcess::GrContext() {
  ......

  if (gr_context_)
    return gr_context_->get();

  gr_context_.reset(
      new webkit::gpu::GrContextForWebGraphicsContext3D(context3d_.get()));
  return gr_context_->get();
}

       ContextProviderInProcess类的成员函数GrContext首先判断成员变量gr_context_是否指向了一个GrContextForWebGraphicsContext3D对象。如果已经指向，那么就会将该GrContextForWebGraphicsContext3D对象返回给调用者。

       另一方面，如果ContextProviderInProcesGrContextForWebGraphicsContext3Ds类的成员变量gr_context_还没有指向一个GrContextForWebGraphicsContext3D对象，那么ContextProviderInProcess类的成员函数GrContext就会先创建该GrContextForWebGraphicsContext3D对象，然后再将它返回给调用者。

       在创建GrContextForWebGraphicsContext3D对象的时候，会使用到ContextProviderInProcess类的成员变量context3d_。从前面的分析可以知道，ContextProviderInProcess类的成员变量context3d_指向的是一个WebGraphicsContext3DInProcessCommandBufferImpl对象。这个WebGraphicsContext3DInProcessCommandBufferImpl对象内部封装了一个In-Process Command Buffer GL接口。

       因此，ContextProviderInProcess类的成员函数GrContext创建出来的GrContextForWebGraphicsContext3D对象也会间接地引用了一个In-Process Command Buffer GL接口。前面创建的类型为SkSurface_Gpu的Skia Surface在光栅化网页UI的时候，就会使用到这个In-Process Command Buffer GL接口，也就是会将要执行的GPU命令写入到一个In-Process Command Buffer中去。

       写入到In-Process Command Buffer中的命令会被周期性地提交给DeferredGpuCommandService服务处理。这是通过调用InProcessCommandBuffer类的成员函数Flush实现的。或者我们也可以主动地调用In-Process Command Buffer GL接口提供的成员函数Flush将写入在In-Process Command Buffer中的命令会被周期性地提交给DeferredGpuCommandService服务。这个主动提交的操作最终也是通过调用InProcessCommandBuffer类的成员函数Flush实现的。这一点可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

       接下来，我们就从InProcessCommandBuffer类的成员函数Flush开始，分析Render端在使用GPU光栅化网页UI的过程中，是如何执行GPU命令的，如下所示：

void InProcessCommandBuffer::Flush(int32 put_offset) {
  ......

  last_put_offset_ = put_offset;
  base::Closure task = base::Bind(&InProcessCommandBuffer::FlushOnGpuThread,
                                  gpu_thread_weak_ptr_,
                                  put_offset);
  QueueTask(task);
}

       参数put_offset表示最新写入的GPU命令在In-Process Command Buffer中的位置。InProcessCommandBuffer类的成员函数Flush首先将这个位置记录在成员变量last_put_offset_中。

       InProcessCommandBuffer类的成员函数Flush接下来创建了一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。接下来这个Task会被提交给DeferredGpuCommandService服务处理。这是通过调用InProcessCommandBuffer类的成员函数QueueTask实现的，如下所示：

class GPU_EXPORT InProcessCommandBuffer : public CommandBuffer,
                                          public GpuControl {
 ......

 private:
  ......

  void QueueTask(const base::Closure& task) { service_->ScheduleTask(task); }

  ......
}

      从前面的分析可以知道，InProcessCommandBuffer类的成员变量service_描述的就是一个DeferredGpuCommandService服务。InProcessCommandBuffer类的成员函数QueueTask通过调用这个DeferredGpuCommandService服务的成员函数ScheduleTask调度执行参数task描述的Task。

      DeferredGpuCommandService类的成员函数ScheduleTask的实现如下所示：

void DeferredGpuCommandService::ScheduleTask(const base::Closure& task) {
  {
    base::AutoLock lock(tasks_lock_);
    tasks_.push(task);
  }
  if (ScopedAllowGL::IsAllowed()) {
    RunTasks();
  } else {
    RequestProcessGL();
  }
}

       DeferredGpuCommandService类的成员函数ScheduleTask首先将参数task描述的Task保存在成员变量tasks_描述的一个std::queue中。

       DeferredGpuCommandService类的成员函数ScheduleTask接下来通过调用ScopedAllowGL类的静态成员函数IsAllowed判断当前线程是否允许直接执行GPU命令，也就是当前线程是否是一个GPU线程。如果是的话，那么就会调用成员函数RunTasks执行参数task描述的Task，如下所示：

void DeferredGpuCommandService::RunTasks() {
  bool has_more_tasks;
  {
    base::AutoLock lock(tasks_lock_);
    has_more_tasks = tasks_.size() > 0;
  }

  while (has_more_tasks) {
    base::Closure task;
    {
      base::AutoLock lock(tasks_lock_);
      task = tasks_.front();
      tasks_.pop();
    }
    task.Run();
    {
      base::AutoLock lock(tasks_lock_);
      has_more_tasks = tasks_.size() > 0;
    }
  }
}

       DeferredGpuCommandService类的成员函数RunTasks会依次执行保存在成员变量tasks_描述的std::queue中的每一个Task。从前面的分析可以知道，这个std::queue保存了一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。因此，当该Task被执行的时候，InProcessCommandBuffer类的成员函数FlushOnGpuThread就会被调用。在调用的过程中，就会执行那些新写入到In-Process Command Buffer的GPU命令。

       DeferredGpuCommandService类的成员函数ScheduleTask可以直接调用成员函数RunTasks执行GPU命令的情况发生在Browser端合成网页UI的过程中。这时候Browser端运行在App的Render Thread中，并且它会通过ScopedAllowGL类标记App的Render Thread可以执行GPU命令。这样DeferredGpuCommandService类的成员函数ScheduleTask就可以知道它可以直接执行GPU命令了。

       在我们这个情景中，正在执行的是网页UI的光栅化操作。这个操作是发生在Render端的Compositor线程中的。Render端的Compositor线程不是一个GPU线程，因此这时候DeferredGpuCommandService类的成员函数ScheduleTask就不能直接调用成员函数RunTasks执行GPU命令，而是要通过调用另外一个成员函数RequestProcessGL请求App的Render Thread执行。

       另外一个情景，也就是Render端绘制网页UI的情景，也是发生在Render端的Compositor线程。这时候DeferredGpuCommandService类的成员函数ScheduleTask也需要调用成员函数RequestProcessGL请求App的Render Thread执行绘制网页UI所需要执行的GPU命令。

       接下来，我们就继续分析DeferredGpuCommandService类的成员函数RequestProcessGL，以便了解它请求App的Render Thread执行GPU命令的过程，如下所示：

void DeferredGpuCommandService::RequestProcessGL() {
  SharedRendererState* renderer_state =
      GLViewRendererManager::GetInstance()->GetMostRecentlyDrawn();
  ......
  renderer_state->ClientRequestDrawGL();
}

       我们在前面Android WebView启动Chromium渲染引擎的过程分析一文中提到，在Chromium渲染引擎中，存在一个GLViewRendererManager单例对象。这个GLViewRendererManager单例对象记录了当前有哪些WebView是采用硬件加速方式绘制的。通过调用这个GLViewRendererManager对象的成员函数GetMostRecentlyDrawn可以获得一个SharedRendererState对象。这个SharedRendererState对象的创建过程可以参考前面Android WebView启动Chromium渲染引擎的过程分析一文，它记录了当前正在绘制的Android WebView的状态。

       获得了与当前正在绘制的Android WebView关联的一个SharedRendererState对象之后，DeferredGpuCommandService类的成员函数RequestProcessGL就可以调用它的成员函数ClientRequestDrawGL请求App的Render Thread执行GPU命令，如下所示：

void SharedRendererState::ClientRequestDrawGL() {
  if (ui_loop_->BelongsToCurrentThread()) {
    ......
    ClientRequestDrawGLOnUIThread();
  } else {
    ......
    base::Closure callback;
    {
      base::AutoLock lock(lock_);
      callback = request_draw_gl_closure_;
    }
    ui_loop_->PostTask(FROM_HERE, callback);
  }
}

       从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，SharedRendererState类的成员变量ui_loop_描述的就是Chromium的Browser端的Native UI Message Loop。通过这个Native UI Message Loop可以判断当前线程是否就是App的UI线程。如果是的话，那么SharedRendererState类的成员函数ClientRequestDrawGL就会直接调用另外一个成员函数ClientRequestDrawGLOnUIThread请求App的Render Thread执行GPU命令。

       如果当前线程不是App的UI线程，那么SharedRendererState类的成员函数ClientRequestDrawGL就会向Chromium的Browser端的Native UI Message Loop发送一个Task。这个Task由SharedRendererState类的成员变量request_draw_gl_closure_描述，它绑定的函数为SharedRendererState类的成员函数ClientRequestDrawGLOnUIThread。这样做的目的是让SharedRendererState类的成员函数ClientRequestDrawGLOnUIThread运行在App的UI线程中，以便可以通过App的UI线程来请求App的Render Thread执行GPU命令。

       SharedRendererState类的成员函数ClientRequestDrawGLOnUIThread的实现如下所示：

void SharedRendererState::ClientRequestDrawGLOnUIThread() {
  ......

  if (!client_on_ui_->RequestDrawGL(NULL, false)) {
    ......
  }
}

       从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，SharedRendererState类的成员变量client_on_ui_指向的是一个Native层的AwContents对象。SharedRendererState类的成员函数ClientRequestDrawGLOnUIThread通过调用这个AwContents对象的成员函数RequestDrawGL请求App的Render Thread执行GPU命令，如下所示：

bool AwContents::RequestDrawGL(jobject canvas, bool wait_for_completion) {
  ......
  JNIEnv* env = AttachCurrentThread();
  ScopedJavaLocalRef<jobject> obj = java_ref_.get(env);
  .......
  return Java_AwContents_requestDrawGL(
      env, obj.obj(), canvas, wait_for_completion);
}

       从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，每一个Native层的AwContents对象在Java层都有一个对应的AwContents对象。这个Java层的AwContents对象就保存在Native层的AwContents对象的成员变量java_ref_中。AwContents类的成员函数RequestDrawGL通过JNI方法Java_AwContents_requestDrawGL调用上述的Java层AwContents对象的成员函数requestDrawGL，用来请求App的Render Thread执行GPU命令。

       Java层的AwContents类的成员函数requestDrawGL的实现如下所示：

public class AwContents {
    ......

    @CalledByNative
    private boolean requestDrawGL(Canvas canvas, boolean waitForCompletion) {
        return mNativeGLDelegate.requestDrawGL(canvas, waitForCompletion, mContainerView);
    }

    ......
}

      从前面Android WebView启动Chromium渲染引擎的过程分析一文可以知道，AwContents类的成员变量mNativeGLDelegate指向的是一个WebViewNativeGLDelegate对象。AwContents类的成员函数requestDrawGL调用这个WebViewNativeGLDelegate对象的成员函数requestDrawGL请求App的Render Thread执行GPU命令，如下所示：

class WebViewChromium implements WebViewProvider,
          WebViewProvider.ScrollDelegate, WebViewProvider.ViewDelegate {
    ......

    private DrawGLFunctor mGLfunctor;
    ......

    private class WebViewNativeGLDelegate implements AwContents.NativeGLDelegate {
        @Override
        public boolean requestDrawGL(Canvas canvas, boolean waitForCompletion,
                View containerView) {
            if (mGLfunctor == null) {
                mGLfunctor = new DrawGLFunctor(mAwContents.getAwDrawGLViewContext());
            }
            return mGLfunctor.requestDrawGL(
                    (HardwareCanvas) canvas, containerView.getViewRootImpl(), waitForCompletion);
        }

        ......
    }

    ......
}

       WebViewNativeGLDelegate类的成员函数requestDrawGL首先判断外部类WebViewChromium的成员变量mGLFunctor是否指向了一个DrawGLFunctor对象。如果指向了，那么就会调用它的成员函数requestDrawGL请求App的Render Thread执行GPU命令。

       另一方面，如果WebViewChromium类的成员变量mGLFunctor还没有指向一个DrawGLFunctor对象，那么WebViewNativeGLDelegate类的成员函数requestDrawGL就会创建这个DrawGLFunctor对象。创建过程如下所示：

class DrawGLFunctor {
    ......

    public DrawGLFunctor(long viewContext) {
        mDestroyRunnable = new DestroyRunnable(nativeCreateGLFunctor(viewContext));
        ......
    }

    ......
}

      DrawGLFunctor类的构造函数首先会调用成员函数nativeCreateGLFunctor获得一个Native层的DrawGLFunctor对象，然后再使用这个Native层的DrawGLFunctor对象创建一个DestroyRunnable对象，如下所示：

class DrawGLFunctor {
    ......

    private static final class DestroyRunnable implements Runnable {
        ......
        long mNativeDrawGLFunctor;
        DestroyRunnable(long nativeDrawGLFunctor) {
            mNativeDrawGLFunctor = nativeDrawGLFunctor;
        }

        ......
    }

    ......
}

      DestroyRunnable类的构造函数主要就是将参数nativeDrawGLFunctor描述的Native层DrawGLFunctor对象保存在成员变量mNativeDrawGLFunctor中。

      接下来我们继续分析Native层的DrawGLFunctor对象的创建过程，也就是DrawGLFunctor类的成员函数nativeCreateGLFunctor的实现。wGLFunctor类的成员函数nativeCreateGLFunctor是一个JNI方法，它由C++层的函数CreateGLFunctor实现，如下所示：

jlong CreateGLFunctor(JNIEnv*, jclass, jlong view_context) {
  RaiseFileNumberLimit();
  return reinterpret_cast<jlong>(new DrawGLFunctor(view_context));
}

      从这里可以看到，函数CreateGLFunctor创建的是一个Native层的DrawGLFunctor对象。这个DrawGLFunctor对象是用来描述Chromium渲染引擎请求App的Render Thread执行的GPU操作集合。

      这一步执行完成后，回到前面分析的WebViewNativeGLDelegate类的成员函数requestDrawGL中，接下来我们继续分析它调用外部类WebViewChromium类的成员变量mGLFunctor指向一个Java层的DrawGLFunctor对象的成员函数requestDrawGL请求App的Render Thread执行GPU命令，如下所示：

class DrawGLFunctor {
    ......

    public boolean requestDrawGL(HardwareCanvas canvas, ViewRootImpl viewRootImpl,
            boolean waitForCompletion) {
        ......

        if (canvas == null) {
            viewRootImpl.invokeFunctor(mDestroyRunnable.mNativeDrawGLFunctor, waitForCompletion);
            return true;
        }

        canvas.callDrawGLFunction(mDestroyRunnable.mNativeDrawGLFunctor);
        ......

        return true;
    }

    ......
}

       这个函数定义在文件frameworks/webview/chromium/java/com/android/webview/chromium/DrawGLFunctor.java中。

       从前面的调用过程可以知道，参数canvas的值为null，另外一个参数waitForCompletion的值等于false。

       当参数canvas的值为null的时候，表示Chromium渲染引擎直接请求App的Render Thread执行GPU命令。这种情况一般就是发生在Render端光栅化网页UI的过程中。

       当参数canvas的值不等于null时，它指向一个Hardware Canvas，表示Chromium渲染引擎请求App的UI线程先将要执行的GPU命令记录在App UI的Display List中。等到该Display List同步给App的Render Thread，并且被App的Render Thread重放的时候，再执行请求的GPU命令。这种情况发生在Render端绘制网页UI的过程中。

       另外一个参数waitForCompletion表示App的UI线程是否需要同步等待App的Render Thread执行完成请求的GPU命令。

       在我们这个情景中，DrawGLFunctor类的成员函数requestDrawGL将会直接请求App的Render Thread执行GPU命令。这是通过调用参数viewRootImpl指向的一个ViewRootImpl对象的成员函数invokeFunctor实现的，如下所示：

public final class ViewRootImpl implements ViewParent,
        View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks {
    ......

    public void invokeFunctor(long functor, boolean waitForCompletion) {
        ThreadedRenderer.invokeFunctor(functor, waitForCompletion);
    }

    ......
}

       ViewRootImpl类的成员函数invokeFunctor会调用ThreadedRenderer类的静态成员函数invokeFunctor请求App的Render Thread执行GPU命令，如下所示：

public class ThreadedRenderer extends HardwareRenderer {
    ......

    static void invokeFunctor(long functor, boolean waitForCompletion) {
        nInvokeFunctor(functor, waitForCompletion);
    }

    ......
}

       ThreadedRenderer类的静态成员函数invokeFunctor调用另外一个静态成员函数nInvokeFunctor请求App的Render Thread执行GPU命令。

       ThreadedRenderer类的静态成员函数nInvokeFunctor是一个JNI方法，它由C++层的函数android_view_ThreadedRenderer_invokeFunctor实现，如下所示：

static void android_view_ThreadedRenderer_invokeFunctor(JNIEnv* env, jobject clazz,
        jlong functorPtr, jboolean waitForCompletion) {
    Functor* functor = reinterpret_cast<Functor*>(functorPtr);
    RenderProxy::invokeFunctor(functor, waitForCompletion);
}

       从前面的分析可以知道，参数functorPtr描述的是一个Native层的DrawGLFunctor对象。这个DrawGLFunctor对象是从Functor类继承下来的，因此函数android_view_ThreadedRenderer_invokeFunctor可以将它转换为一个Functor对象。这个Functor对象会通过RenderProxy类的静态成员函数invokeFunctor提交给App的Render Thread处理，如下所示：

CREATE_BRIDGE2(invokeFunctor, RenderThread* thread, Functor* functor) {
    CanvasContext::invokeFunctor(*args->thread, args->functor);
    return NULL;
}

void RenderProxy::invokeFunctor(Functor* functor, bool waitForCompletion) {
    ATRACE_CALL();
    RenderThread& thread = RenderThread::getInstance();
    SETUP_TASK(invokeFunctor);
    args->thread = &thread;
    args->functor = functor;
    if (waitForCompletion) {
        // waitForCompletion = true is expected to be fairly rare and only
        // happen in destruction. Thus it should be fine to temporarily
        // create a Mutex
        Mutex mutex;
        Condition condition;
        SignalingRenderTask syncTask(task, &mutex, &condition);
        AutoMutex _lock(mutex);
        thread.queue(&syncTask);
        condition.wait(mutex);
    } else {
        thread.queue(task);
    }
}

       App的Render Thread可以通过调用RenderThread类的静态成员函数getInstance获得。获得了App的Render Thread之后，RenderProxy类的静态成员函数invokeFunctor就可以往它的消息队列发送一个Task。这个Task封装参数funtor描述的一个Native层的DrawGLFunctor对象，并且它绑定了由宏CREATE_BRIDGE2定义的函数invokeFunctor。

       这意味着当上述Task被App的Render Thread调度执行的时候，函数invokeFunctor就会在App的Render Thread中执行，它主要就是通过调用CanvasContext类的静态成员函数invokeFunctor通知参数参数funtor描述的Native层DrawGLFunctor对象，现在可以执行GPU命令了。

       从前面的调用过程可以知道，参数waitForCompletion的值等于false，表示当前线程（也就是App的UI线程）不用等待App的Render Thread执行完成请求的GPU命令，于是它就可以马上返回。

       接下来我们就继续分析CanvasContext类的静态成员函数invokeFunctor的实现，如下所示：

void CanvasContext::invokeFunctor(RenderThread& thread, Functor* functor) {
    ATRACE_CALL();
    DrawGlInfo::Mode mode = DrawGlInfo::kModeProcessNoContext;
    if (thread.eglManager().hasEglContext()) {
        thread.eglManager().requireGlContext();
        mode = DrawGlInfo::kModeProcess;
    }

    thread.renderState().invokeFunctor(functor, mode, NULL);
}

       CanvasContext类的静态成员函数invokeFunctor主要就是通过调用一个RenderState对象的成员函数invokeFunctor通知参数funtor描述的一个Native层DrawGLFunctor对象执行GPU命令。这个RenderState对象记录了App的Render Thread的当前渲染状态，它可以通过调用参数thread描述的一个RenderThread对象的成员函数renderState获得。

       如果此时App的Render Thread已经初始化好了OpenGL环境，那么RenderState类的成员函数invokeFunctor将会通知参数funtor描述的Native层DrawGLFunctor对象以DrawGlInfo::kModeProcess的模式执行GPU命令。否则的话，就以DrawGlInfo::kModeProcessNoContext的模式行。由于App的Render Thread一开始就会初始化OpenGL环境，因此我们将认为RenderState类的成员函数invokeFunctor将会通知参数funtor描述的Native层DrawGLFunctor对象以DrawGlInfo::kModeProcess的模式执行GPU命令。

       RenderState类的成员函数invokeFunctor的实现如下所示：

void RenderState::invokeFunctor(Functor* functor, DrawGlInfo::Mode mode, DrawGlInfo* info) {
    interruptForFunctorInvoke();
    (*functor)(mode, info);
    resumeFromFunctorInvoke();
}

       RenderState类的成员函数invokeFunctor主要就是调用了参数functor描述的一个Native层DrawGLFunctor对象的重载操作符函数()，用来通知它执行GPU命令，如下所示：

AwDrawGLFunction* g_aw_drawgl_function = NULL;

class DrawGLFunctor : public Functor {
 public:
  ......

  // Functor
  virtual status_t operator ()(int what, void* data) {
    ......

    AwDrawGLInfo aw_info;
    aw_info.version = kAwDrawGLInfoVersion;
    switch (what) {
      case DrawGlInfo::kModeDraw: {
        aw_info.mode = AwDrawGLInfo::kModeDraw;
        ......
        break;
      }
      case DrawGlInfo::kModeProcess:
        aw_info.mode = AwDrawGLInfo::kModeProcess;
        break;
      case DrawGlInfo::kModeProcessNoContext:
        aw_info.mode = AwDrawGLInfo::kModeProcessNoContext;
        break;
      case DrawGlInfo::kModeSync:
        aw_info.mode = AwDrawGLInfo::kModeSync;
        break;
      default:
        ALOGE("Unexpected DrawGLInfo type %d", what);
        return DrawGlInfo::kStatusDone;
    }

    // Invoke the DrawGL method.
    g_aw_drawgl_function(view_context_, &aw_info, NULL);

    return DrawGlInfo::kStatusDone;
  }

  ......
};

       DrawGLFunctor类的重载操作符函数()主要就是调用全局变量g_aw_drawgl_function描述的一个DrawGL函数执行GPU命令，并且告知该DrawGL函数，App的Render Thread当前处于什么状态。这个状态由参数what描述的GPU执行模式决定。

       App的Render Thread有四种状态：

       1. AwDrawGLInfo::kModeDraw：表示App的Render Thread正在重放App UI的Display List。

       2. DrawGlInfo::kModeProcess：表示App的Render Thread正在执行外界请求的GPU命令，并且App的Render Thread当前具有OpenGL上下文。

       3. AwDrawGLInfo::kModeProcessNoContext：表示App的Render Thread正在执行外界请求的GPU命令，但是App的Render Thread当前没有OpenGL上下文。

       4, AwDrawGLInfo::kModeSync：表示App的Render Thread正在同步的App的UI线程的Display List。

       在我们这个情景中，App的Render Thread正处于第2种状态。第3种状态几乎不会出现，我们不予考虑。第1种和第4种状态我们在接下来一篇文章分析Android WebView渲染网页UI的过程中再详细分析。

       从前面的分析可以知道，全局变量g_aw_drawgl_function描述的DrawGL函数是由Android WebView在启动Chromium渲染引擎时注册的，它指向的函数为DrawGLFunction，它的实现如下所示：

static void DrawGLFunction(long view_context,
                           AwDrawGLInfo* draw_info,
                           void* spare) {
  // |view_context| is the value that was returned from the java
  // AwContents.onPrepareDrawGL; this cast must match the code there.
  reinterpret_cast<android_webview::AwContents*>(view_context)
      ->DrawGL(draw_info);
}

      参数view_context描述的是一个Native层的AwContents对象。函数DrawGLFunction主要就是调用这个AwContents对象的成员函数DrawGL执行GPU命令，如下所示：

void AwContents::DrawGL(AwDrawGLInfo* draw_info) {
  if (draw_info->mode == AwDrawGLInfo::kModeSync) {
    if (hardware_renderer_)
      hardware_renderer_->CommitFrame();
    return;
  }

  ......

  ScopedAllowGL allow_gl;
  ......

  if (draw_info->mode != AwDrawGLInfo::kModeDraw) {
    ......
    return;
  }

  if (!hardware_renderer_) {
    hardware_renderer_.reset(new HardwareRenderer(&shared_renderer_state_));
    hardware_renderer_->CommitFrame();
  }

  hardware_renderer_->DrawGL(state_restore.stencil_enabled(),
                             state_restore.framebuffer_binding_ext(),
                             draw_info);
  ......
}

       这个函数定义在文件external/chromium_org/android_webview/native/aw_contents.cc中。

       AwContents类的成员函数DrawGL根据App的Render Thread的当前不同的状态执行不同的操作。在分析这些操作之前，我们首先介绍AwContents类的成员变量hardware_renderer_。如果它的值不等于NULL，那么它就是指向一个HardwareRenderer对象。这个HardwareRenderer对象是Browser端用来合成网页UI的。

       如果App的Render Thread的当前状态是AwDrawGLInfo::kModeSync，并且当前AwContents类的成员变量hardware_renderer_指向了一个HardwareRenderer对象，那么AwContents类的成员函数DrawGL就会调用这个HardwareRenderer对象的成员函数CommitFrame将Render端上一次绘制出来的网页UI同步到Browser端。

       如果App的Render Thread的当前状态是AwDrawGLInfo::kModeProcess，那么AwContents类的成员函数DrawGL就会构造一个ScopedAllowGL对象。这个ScopedAllowGL对象在构造的过程中，就会通知DeferredGpuCommandService服务执行Render端之前请求执行的GPU命令。

       如果App的Render Thread的当前状态是AwDrawGLInfo::kModeDraw，那么AwContents类的成员函数DrawGL同样先通过上述构造的ScopedAllowGL对象通知DeferredGpuCommandService服务执行Render端之前请求执行的GPU命令。此外，AwContents类的成员函数DrawGL还会调用成员变量hardware_renderer_指向了一个HardwareRenderer对象的成员函数DrawGL将从Render端同步过来的网页UI合成显示在屏幕中。如果这个HardwareRenderer对象还没有创建，那么就会进行创建，并且会在创建后将Render端上一次绘制出来的网页UI同步到Browser端来，以便接下来可以将它合成显示在屏幕中。

       从前面的分析可以知道，App的Render Thread的当前状态是AwDrawGLInfo::kModeProcess，因此接下来AwContents类的成员函数DrawGL就会通过构造一个ScopedAllowGL对象来通知DeferredGpuCommandService服务执行Render端之前请求执行的GPU命令。这些GPU命令是用来光栅化网页的UI的。

       ScopedAllowGL对象的构造过程如下所示：

base::LazyInstance<scoped_refptr<DeferredGpuCommandService> >
    g_service = LAZY_INSTANCE_INITIALIZER;
......

base::LazyInstance<base::ThreadLocalBoolean> ScopedAllowGL::allow_gl;
......

bool ScopedAllowGL::IsAllowed() {
  return allow_gl.Get().Get();
}

ScopedAllowGL::ScopedAllowGL() {
  DCHECK(!allow_gl.Get().Get());
  allow_gl.Get().Set(true);

  if (g_service.Get())
    g_service.Get()->RunTasks();
}

       ScopedAllowGL类的构造函数首先是通过ScopedAllowGL类的静态成员变量allow_gl描述的一个线程局存储将当前线程标记为一个GPU线程，这样当前线程就可以直接执行GPU命令了。

       全局变量g_service描述的就是一个DeferredGpuCommandService服务。ScopedAllowGL类的构造函数接下来就会调用这个DeferredGpuCommandService服务的成员函数RunTasks调度执行保存在它内部的一个Task队列中的Task了。DeferredGpuCommandService类的成员函数RunTasks我们在前面已经分析过了，这里不再复述。

       从前面的分析可以知道，DeferredGpuCommandService服务内部的Task队列保存了一个Task。这个Task绑定了InProcessCommandBuffer类的成员函数FlushOnGpuThread。这意味着接下来InProcessCommandBuffer类的成员函数FlushOnGpuThread会在App的Render Thread中调用，它的实现如下所示：

void InProcessCommandBuffer::FlushOnGpuThread(int32 put_offset) {
  ......

  command_buffer_->Flush(put_offset);

  ......
}

       从前面的分析可以知道，InProcessCommandBuffer类的成员变量command_buffer_指向的是一个CommandBufferService对象。InProcessCommandBuffer类的成员函数FlushOnGpuThread调用这个CommandBufferService对象的成员函数Flush执行GPU命令，如下所示：

void CommandBufferService::Flush(int32 put_offset) {
  ......

  put_offset_ = put_offset;

  if (!put_offset_change_callback_.is_null())
    put_offset_change_callback_.Run();
}

       参数表示put_offset表示最新写入的GPU命令在Command Buffer中的位置。CommandBufferService类的成员函数Flush首先将这个位置记录在成员变量put_offset_中。

       CommandBufferService类的成员函数Flush接下来又会检查成员变量put_offset_change_callback_是否指向了一个Callback。如果指向了一个Callback，那么就会调用它所绑定的函数来执行GPU命令。

       从前面的分析可以知道，CommandBufferService类的成员变量put_offset_change_callback_指向了一个Callback。这个Callback绑定的函数为InProcessCommandBuffer类的成员函数PumpCommands。因此，接下来InProcessCommandBuffer类的成员函数PumpCommands会被调用。在调用期间，就会执行前面写入在Command Buffer中的GPU命令，如下所示：

void InProcessCommandBuffer::PumpCommands() {
  ......

  gpu_scheduler_->PutChanged();
}

       从前面的分析可以知道，InProcessCommandBuffer类的成员变量gpu_scheduler_描述的是一个Gpu Scheduler。InProcessCommandBuffer类的成员函数PumpCommands调用这个Gpu Scheduler的成员函数PutChanged，用来通知它Command Buffer有新的GPU命令需要处理。这个Gpu Scheduler获得这个通知后，就会从Command Buffer中读出新写入的GPU命令，并且调用相应的OpenGL函数进行处理。这个处理过程可以参考前面Chromium硬件加速渲染的OpenGL命令执行过程分析一文。

       这样，我们就以Render端使用GPU光栅化网页UI的情景为例，分析了Android WebView的Render端执行GPU命令的过程。其它的情景，Render端也是通过In-Process Command Buffer GL接口请求App的Render Thread来执行GPU命令。

       最后，我们分析Android WebView为Browser端创建In-Process Command Buffer GL接口的过程。有了In-Process Command Buffer GL接口之后，Browser端就可以像Render端一样，在App的Render Thread中执行GPU命令了。

       Android WebView的Browser端的主要任务是将网页的UI合成在屏幕中。为了完成这个任务，Browser端会创建一个Hardware Renderer。Hardware Renderer又会为Browser端创建一个CC Layer Tree，目的是为了可以使用Chromium的CC模块来完成合成网页UI的任务。

      Hardware Renderer会将它为Browser端创建的CC Layer Tree绘制在一个Parent Output Surface上。这个Parent Output Surface内部封装了一个In-Process Command Buffer GL接口。以后Chromium的CC模块就会通过这个In-Process Command Buffer GL接口合成网页的UI。

      接下来，我们就从Browser端创建Hardware Renderer的过程开始，分析Browser端用来合成网页UI的In-Process Command Buffer GL接口的创建过程。

      前面分析，App的Render Thread在AwContents类的成员函数DrawGL时提到，当App的Render Thread的处于AwDrawGLInfo::kModeDraw状态时，会检查Android WebView的Browser端是否已经创建了一个Hardware Renderer。如果还没有创建，那么就会进行创建。创建过程如下所示：

HardwareRenderer::HardwareRenderer(SharedRendererState* state)
    : ......,
      root_layer_(cc::Layer::Create()),
      ...... {
  ......

  layer_tree_host_ =
      cc::LayerTreeHost::CreateSingleThreaded(this, this, NULL, settings);
  layer_tree_host_->SetRootLayer(root_layer_);
  ......
}

       HardwareRenderer类的构造函数主要就是为Browser端创建一个LayerTreeHost对象，并且保存成员变量layer_tree_host_中。这个LayerTreeHost对象描述的就是一个CC Layer Tree。这个CC Layer Tree是通过调用LayerTreeHost类的静态成员函数CreateSingleThreaded创建的，并且会将这个CC Layer Tree的Client指定为当前正在创建的Hardware Renderer，如下所示：

scoped_ptr<LayerTreeHost> LayerTreeHost::CreateSingleThreaded(
    LayerTreeHostClient* client,
    LayerTreeHostSingleThreadClient* single_thread_client,
    SharedBitmapManager* manager,
    const LayerTreeSettings& settings) {
  scoped_ptr<LayerTreeHost> layer_tree_host(
      new LayerTreeHost(client, manager, settings));
  layer_tree_host->InitializeSingleThreaded(single_thread_client);
  return layer_tree_host.Pass();
}

       LayerTreeHost类的静态成员函数CreateSingleThreaded首先是创建了一个LayerTreeHost对象。这个LayerTreeHost对象描述的就是一个CC Layer Tree，它的创建过程如下所示：

LayerTreeHost::LayerTreeHost(LayerTreeHostClient* client,
                             SharedBitmapManager* manager,
                             const LayerTreeSettings& settings)
    : ......,
      client_(client),
      ...... {
  ......
}

       LayerTreeHost类的构造函数主要是将参数client描述的一个HardwareRenderer对象保存成员变量client_中，作为当前正在创建的CC Layer Tree的Client。以后当前正在创建的CC Layer Tree将会通过这个Client为自己创建一个Output Surface。

       回到前面分析的LayerTreeHost类的静态成员函数CreateSingleThreaded中，它接下来又会调用前面创建的LayerTreeHost对象的成员函数InitializeSingleThreaded，用来执行初始化工作，如下所示：

void LayerTreeHost::InitializeSingleThreaded(
    LayerTreeHostSingleThreadClient* single_thread_client) {
  InitializeProxy(SingleThreadProxy::Create(this, single_thread_client));
}

       LayerTreeHost类的成员函数InitializeSingleThreaded首先是调用SingleThreadProxy类的静态成员函数Create创建了一个SingleThreadProxy对象，如下所示：

scoped_ptr<Proxy> SingleThreadProxy::Create(
    LayerTreeHost* layer_tree_host,
    LayerTreeHostSingleThreadClient* client) {
  return make_scoped_ptr(
      new SingleThreadProxy(layer_tree_host, client)).PassAs<Proxy>();
}

       从这里可以看到，SingleThreadProxy类的静态成员函数Create创建的是一个SingleThreadProxy对象。这个SingleThreadProxy对象在创建的过程中，会将参数layer_tree_host指向的一个LayerTreeHost对象保存在自己的成员变量layer_tree_host_中，如下所示：

SingleThreadProxy::SingleThreadProxy(LayerTreeHost* layer_tree_host,
                                     LayerTreeHostSingleThreadClient* client)
    : Proxy(NULL),
      layer_tree_host_(layer_tree_host),
      ...... {
  ......
}

       回到前面分析的LayerTreeHost类的成员函数InitializeSingleThreaded中，它获得了一个SingleThreadProxy对象之后，就会调用另外一个成员函数InitializeProxy对该SingleThreadProxy进行初始化，如下所示：

void LayerTreeHost::InitializeProxy(scoped_ptr<Proxy> proxy) {
  ......

  proxy_ = proxy.Pass();
  proxy_->Start();
}

      LayerTreeHost类的成员函数InitializeProxy首先将参数proxy指向的一个SingleThreadProxy对象保存在成员变量proxy_中，然后再调用这个SingleThreadProxy对象的成员函数
Start创建一个LayerTreeHostImpl对象，如下所示：

void SingleThreadProxy::Start() {
  ......
  layer_tree_host_impl_ = layer_tree_host_->CreateLayerTreeHostImpl(this);
}

       从前面的分析可以知道，SingleThreadProxy类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象。SingleThreadProxy类的成员函数
Start调用这个LayerTreeHost对象的成员函数CreateLayerTreeHostImpl创建了一个LayerTreeHostImpl对象，并且保存在成员变量layer_tree_host_impl_。

       从前面的分析就可以知道，Hardware Renderer在为Browser端创建CC Layer Tree的过程中，一共创建了LayerTreeHost、SingleThreadProxy和LayerTreeHostImpl三个对象。这三个对象一起描述了一个CC Layer Tree。

       从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章可以知道，Render端的CC Layer Tree是通过调用LayerTreeHost类的静态成员函数CreateThreaded创建的。在创建的过程中，同样会创建一个LayerTreeHost对象和一个LayerTreeHostImpl对象。不过，它不会创建一个SingleThreadProxy对象，而是一个ThreadProxy对象。这三个对象同样是描述了一个CC Layer Tree。

       ThreadProxy类和SingleThreadProxy类都是从Proxy类继承下来的。它们的最大区别在于前者描述的CC Layer Tree在绘制的过程中，会使用到两个线程。一个称为Main线程，另一个称为Compositor线程。这两个线程通过一个CC调度器进行协作，完成绘制网页UI的任务。后者描述的CC Layer Tree在绘制的过程中，只会使用一个线程，因此它不需要使用到CC调度器。

       从前面Chromium网页渲染机制简要介绍和学习计划这个系列的文章可以知道，对于复杂的UI来说，使用两个线程绘制效率会更高。不过，对Android WebView的Browser端来说，它的UI结构是非常简单的（CC Layer Tree只包含两个节点），因此，它就不需要使用两个线程来绘制了。

       回到前面分析的HardwareRenderer类的构造函数中，它除了为Browser端创建一个CC Layer Tree，还会调用Layer类的静态成员函数Create0创建一个CC Layer。这个CC Layer就作为Browser端的CC Layer Tree的根节点。

       确保Android WebView的Browser端已经具有一个Hardware Renderer之后，前面分析的AwContents类的成员函数DrawGL就会调用这个Hardware Renderer的成员函数DrawGL来合成网页的UI，如下所示：

void HardwareRenderer::DrawGL(bool stencil_enabled,
                              int framebuffer_binding_ext,
                              AwDrawGLInfo* draw_info) {
  ......

  {
    ......
    layer_tree_host_->Composite(gfx::FrameTime::Now());
  }
  
  ......
}

       从前面的分析可以知道，HardwareRenderer类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象。HardwareRenderer类的成员函数DrawGL调用这个LayerTreeHost对象的成员函数Composite合成网页的UI，如下所示：

void LayerTreeHost::Composite(base::TimeTicks frame_begin_time) {
  ......
  SingleThreadProxy* proxy = static_cast<SingleThreadProxy*>(proxy_.get());

  if (output_surface_lost_)
    proxy->CreateAndInitializeOutputSurface();
  ......

  proxy->CompositeImmediately(frame_begin_time);
}

        LayerTreeHost类的成员变量output_surface_lost_是一个布尔变量。当它的值等于true的时候，就表示CC模块还没有为当前正在处理的LayerTreeHost对象描述的CC Layer Tree创建过Output Surface，或者以前创建过，但是现在失效了。在这种情况下，LayerTreeHost类的成员函数Composite合成网页UI之前，先创建创建一个Output Surface。

       从前面的分析可以知道，LayerTreeHost类的成员变量proxy_指向的是一个SingleThreadProxy对象。LayerTreeHost类的成员函数Composite就是通过调用这个SingleThreadProxy对象的成员函数CreateAndInitializeOutputSurface为当前正在处理的LayerTreeHost对象描述的CC Layer Tree创建Output Surface的。

       有了Output Surface之后，LayerTreeHost类的成员函数Composite再调用上述SingleThreadProxy对象的成员函数CompositeImmediately合成网页的UI。这个过程我们在接下来一篇文章中再详细分析。

       接下来，我们继续分析SingleThreadProxy类的成员函数CreateAndInitializeOutputSurface为Browser端的CC Layer Tree创建Output Surface的过程。在创建的过程中，就会创建一个In-Process Command Buffer GL接口，如下所示：

void SingleThreadProxy::CreateAndInitializeOutputSurface() {
  ......

  scoped_ptr<OutputSurface> output_surface =
      layer_tree_host_->CreateOutputSurface();

  ......
}

       从前面的分析可以知道，SingleThreadProxy类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象。SingleThreadProxy类的成员函数CreateAndInitializeOutputSurface调用这个LayerTreeHost对象的成员函数CreateOutputSurface为Browser端的CC Layer Tree创建一个Output Surface，如下所示：

scoped_ptr<OutputSurface> LayerTreeHost::CreateOutputSurface() {
  return client_->CreateOutputSurface(num_failed_recreate_attempts_ >= 4);
}

       从前面的分析可以知道，LayerTreeHost类的成员变量client_指向的是一个HardwareRenderer对象。LayerTreeHost类的成员函数CreateOutputSurfaceBrowser调用这个HardwareRenderer对象的成员函数CreateOutputSurface为Browser端的CC Layer Tree创建一个Output Surface，如下所示：

scoped_ptr<cc::OutputSurface> HardwareRenderer::CreateOutputSurface(
    bool fallback) {
  ......

  scoped_refptr<cc::ContextProvider> context_provider =
      CreateContext(gl_surface_,
                    DeferredGpuCommandService::GetInstance(),
                    shared_renderer_state_->GetSharedContext());
  scoped_ptr<ParentOutputSurface> output_surface_holder(
      new ParentOutputSurface(context_provider));
  output_surface_ = output_surface_holder.get();
  return output_surface_holder.PassAs<cc::OutputSurface>();
}

       HardwareRenderer类的成员函数CreateOutputSurface为Browser端的CC Layer Tree创建的是一个Parent Output Surface。相应地，Render端的CC Layer Tree使用的Synchronous Compositor Output Surface也称为Child Output Surface。之所以将Render端的CC Layer Tree的Output Surface称为Child，而将Browser端的CC Layer Tree创建的是一个Parent，是因为Render端的CC Layer Tree的绘制结果会输出为Browser端的CC Layer Tree的一个节点的内容。这一点我们在接下来一篇文章分析Android WebView渲染网页UI的过程就会清楚地看到。

       HardwareRenderer类的成员函数CreateOutputSurface在为Browser端的CC Layer Tree创建Parent Output Surface的时候，需要用到一个ContextProvider对象。这个ContextProvider对象是通过调用函数CreateContext创建的，如下所示：

scoped_refptr<cc::ContextProvider> CreateContext(
    scoped_refptr<gfx::GLSurface> surface,
    scoped_refptr<gpu::InProcessCommandBuffer::Service> service,
    gpu::GLInProcessContext* share_context) {
  ......

  scoped_ptr<gpu::GLInProcessContext> context(
      gpu::GLInProcessContext::Create(service,
                                      surface,
                                      surface->IsOffscreen(),
                                      gfx::kNullAcceleratedWidget,
                                      surface->GetSize(),
                                      share_context,
                                      false /* share_resources */,
                                      in_process_attribs,
                                      gpu_preference));
  ......

  return webkit::gpu::ContextProviderInProcess::Create(
      WebGraphicsContext3DInProcessCommandBufferImpl::WrapContext(
          context.Pass(), attributes),
      "Parent-Compositor");
}

       函数ContextProvider首先是调用GLInProcessContext类的静态成员函数Create创建了一个In-Process Command Buffer GL接口。

       上述In-Process Command Buffer GL接口又会通过WebGraphicsContext3DInProcessCommandBufferImpl类的静态成员函数WrapContext封装在一个WebGraphicsContext3DInProcessCommandBufferImpl对象中。

       最后，前面得到的WebGraphicsContext3DInProcessCommandBufferImpl对象又会通过ContextProviderInProcess类的静态成员函数Create封装在一个ContextProviderInProcess对象中返回给调用者。调用者有了这个ContextProviderInProcess对象之后，就可以创建一个Output Surface了。

       GLInProcessContext类的静态成员函数Create、WebGraphicsContext3DInProcessCommandBufferImpl类的静态成员函数WrapContext和ContextProviderInProcess类的静态成员函数Create的实现，前面在分析Render端的CC Layer Tree使用的Synchronous Compositor Output Surface的创建过程时，已经分析过了，这里就不再复述。

       这样，我们就可以知道，Browser端的CC Layer Tree使用的Output Surface里面包含了一个In-Process Command Buffer GL接口。CC模块在绘制Browser端的CC Layer Tree时，就会通过这个In-Process Command Buffer GL接口来执行GPU命令。这与我们前面分析的Render端执行GPU命令的过程是一致的。

       至此，我们就分析了Android WebView为Render端和Browser端创建In-Process Command Buffer GL接口的过程，并且以Render端光栅化网页UI的情景为例，分析了Render端通过In-Process Command Buffer GL接口请求App的Render Thread执行GPU命令的过程。Browser端执行GPU命令的过程与Render端也是类似的。一旦Render端和Browser可以执行GPU命令，它们就可以使用硬件加速的方式渲染网页的UI。在接下来一篇文章中，我们就详细分析Android WebView使用硬件加速方式渲染网页UI的过程。敬请关注！更多的信息也可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

      Android WebView作为App UI的一部分，当App UI以硬件加速方式渲染时，它也是以硬件加速方式渲染的。Android WebView的UI来自于网页，是通过Chromium渲染的。Chromium渲染网页UI的机制与Android App渲染UI的机制是不一样的。不过，它们会一起协作完成网页UI的渲染。本文接下来就详细分析Android WebView硬件加速渲染网页UI的过程。

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

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

      从前面Android应用程序UI硬件加速渲染技术简要介绍和学习计划这个系列的文章可以知道，Android App在渲染UI一帧的过程中，经历以下三个阶段：

      1. 在UI线程中构建一个Display List，这个Display List包含了每一个View的绘制命令。

      2. 将前面构建的Display List同步给Render Thread。

      3. Render Thread对同步得到的Display List进行渲染，也就是使用GPU执行Display List的绘制命令。

      上述三个阶段如果能够在16ms内完成，那么App的UI给用户的感受就是流畅的。为了尽量地在16ms内渲染完成App的一帧UI，Android使用了以上方式对App的UI进行渲染。这种渲染机制的好处是UI线程和Render Thread可以并发执行，也就是Render Thread在渲染当前帧的Display List的时候，UI线程可以准备下一帧的Display List。它们唯一需要同步的地方发生第二阶段。不过，这个阶段是可以很快完成的。因此，UI线程和Render Thread可以认为是并发执行的。

      Android WebView既然是App UI的一部分，也就是其中的一个View，它的渲染也是按照上述三个阶段进行的，如下所示：

图1 Android WebView硬件加速渲染网页UI的过程

       在第一阶段，Android WebView会对Render端的CC Layer Tree进行绘制。这个CC Layer Tree描述的就是网页的UI，它会通过一个Synchronous Compositor绘制在一个Synchronous Compositor Output Surface上，最终得到一个Compositor Frame。这个Compositor Frame会保存在一个SharedRendererState对象中。

       在第二阶段，保存在上述SharedRendererState对象中的Compositor Frame会同步给Android WebView会对Browser端的CC Layer Tree。Browser端的CC Layer Tree只有两个节点。一个是根节点，另一个是根节点的子节点，称为一个Delegated Renderer Layer。Render端绘制出来的Compositor Frame就是作为这个Delegated Renderer Layer的输入的。

       在第三阶段，Android WebView会通过一个Hardware Renderer将Browser端的CC Layer Tree渲染在一个Parent Output Surface上，实际上就是通过GPU命令将Render端绘制出来的UI合成显示在App的UI窗口中。

       接下来，我们就按照以上三个阶段分析Android WebView硬件加速渲染网页UI的过程。

       从前面Android应用程序UI硬件加速渲染的Display List构建过程分析一文可以知道，在App渲染UI的第一阶段，Android WebView的成员函数onDraw会被调用。从前面Android WebView执行GPU命令的过程分析一文又可以知道，Android WebView在Native层有一个BrowserViewRenderer对象。当Android WebView的成员函数onDraw被调用时，并且App的UI以硬件加速方式渲染时，这个Native层BrowserViewRenderer对象的成员函数OnDrawHardware会被调用，如下所示：

bool BrowserViewRenderer::OnDrawHardware(jobject java_canvas) {   
  ......  
  
  scoped_ptr<DrawGLInput> draw_gl_input(new DrawGLInput);  
  ......  
  
  scoped_ptr<cc::CompositorFrame> frame =  
      compositor_->DemandDrawHw(surface_size,  
                                gfx::Transform(),  
                                viewport,  
                                clip,  
                                viewport_rect_for_tile_priority,  
                                transform_for_tile_priority);  
  ......  

  frame->AssignTo(&draw_gl_input->frame);
  ......
  shared_renderer_state_->SetDrawGLInput(draw_gl_input.Pass()); 
 
  ......  
  return client_->RequestDrawGL(java_canvas, false);  
}  

       从前面Android WebView执行GPU命令的过程分析一文可以知道，BrowserViewRenderer类的成员变量compositor_指向的是一个SynchronousCompositorImpl对象。BrowserViewRenderer对象的成员函数OnDrawHardware会调用这个SynchronousCompositorImpl对象的成员函数DemandDrawHw对网页的UI进行绘制。

       绘制的结果是得到一个Compositor Frame。这个Compositor Frame会保存在一个DrawGLInput对象中。这个DrawGLInput对象又会保存在BrowserViewRenderer类的成员变量shared_renderer_state_指向的一个SharedRendererState对象中。这是通过调用SharedRendererState类的成员函数SetDrawGLInput实现的。

       BrowserViewRenderer类的成员变量client_指向的是一个AwContents对象。BrowserViewRenderer对象的成员函数OnDrawHardware最后会调用这个AwContents对象的成员函数RequestDrawGL请求在参数java_canvas描述的一个Hardware Canvas中增加一个DrawFunctorOp操作。这个DrawFunctorOp操作最终会包含在App的UI线程构建的Display List中。

       接下来，我们首先分析SynchronousCompositorImpl类的成员函数DemandDrawHw绘制网页的UI的过程，如下所示：

scoped_ptr<cc::CompositorFrame> SynchronousCompositorImpl::DemandDrawHw(
    gfx::Size surface_size,
    const gfx::Transform& transform,
    gfx::Rect viewport,
    gfx::Rect clip,
    gfx::Rect viewport_rect_for_tile_priority,
    const gfx::Transform& transform_for_tile_priority) {
  ......

  scoped_ptr<cc::CompositorFrame> frame =
      output_surface_->DemandDrawHw(surface_size,
                                    transform,
                                    viewport,
                                    clip,
                                    viewport_rect_for_tile_priority,
                                    transform_for_tile_priority);
  ......
  return frame.Pass();
}

      从前面Android WebView执行GPU命令的过程分析一文可以知道，SynchronousCompositorImpl类的成员变量output_surface_指向的是一个SynchronousCompositorOutputSurface对象。SynchronousCompositorImpl类的成员函数DemandDrawHw调用这个SynchronousCompositorOutputSurface对象的成员函数DemandDrawHw绘制网页的UI，如下所示：

scoped_ptr<cc::CompositorFrame>
SynchronousCompositorOutputSurface::DemandDrawHw(
    gfx::Size surface_size,
    const gfx::Transform& transform,
    gfx::Rect viewport,
    gfx::Rect clip,
    gfx::Rect viewport_rect_for_tile_priority,
    const gfx::Transform& transform_for_tile_priority) {
  ......

  InvokeComposite(transform,
                  viewport,
                  clip,
                  viewport_rect_for_tile_priority,
                  transform_for_tile_priority,
                  true);

  return frame_holder_.Pass();
}

       SynchronousCompositorOutputSurface类的成员函数DemandDrawHw调用另外一个成员函数InvokeComposite绘制网页的UI。绘制完成后，就会得到一个Compositor Frame。这个Compositor Frame保存在SynchronousCompositorOutputSurface类的成员变量frame_holder_中。因此，SynchronousCompositorOutputSurface类的成员函数DemandDrawHw可以将这个成员变量frame_holder_指向的Compositor Frame返回给调用者。

       SynchronousCompositorOutputSurface类的成员函数InvokeComposite的实现如下所示：

void SynchronousCompositorOutputSurface::InvokeComposite(
    const gfx::Transform& transform,
    gfx::Rect viewport,
    gfx::Rect clip,
    gfx::Rect viewport_rect_for_tile_priority,
    gfx::Transform transform_for_tile_priority,
    bool hardware_draw) {
  ......

  client_->BeginFrame(cc::BeginFrameArgs::CreateForSynchronousCompositor());

  ......
}

       SynchronousCompositorOutputSurface类的成员变量client_是从父类OutputSurface继承下来的。从前面Chromium网页绘图表面（Output Surface）创建过程分析一文可以知道，它指向的是一个LayerTreeHostImpl对象。SynchronousCompositorOutputSurface类的成员函数InvokeComposite调用这个LayerTreeHostImpl对象的成员函数BeginFrame绘制网页的UI。 

       从前面Chromium网页渲染调度器（Scheduler）实现分析一文可以知道，当LayerTreeHostImpl类的成员函数BeginFrame被调用时，它就会CC模块的调度器执行一个BEGIN_IMPL_FRAME操作，也就是对网页的CC Layer Tree进行绘制。绘制的过程可以参考Chromium网页Layer Tree绘制过程分析、Chromium网页Layer Tree同步为Pending Layer Tree的过程分析和Chromium网页Pending Layer Tree激活为Active Layer Tree的过程分析这三篇文章。

       由于Android WebView的Render端使用的是Synchronous Compositor，当前线程（也就是App的UI线程）会等待Render端的Compositor线程绘制完成网页的CC Layer Tree。从前面Chromium硬件加速渲染的UI合成过程分析一文可以知道，Compositor线程在绘制完成网页的CC Layer Tree的时候，会调用网页的Output Surface的成员函数SwapBuffers。

       在我们这个情景中，网页的Output Surface是一个Synchronous Compositor Output Surface。这意味着当Compositor线程在绘制完成网页的CC Layer Tree时，会调用SynchronousCompositorOutputSurface类的成员函数SwapBuffers，如下所示：

void SynchronousCompositorOutputSurface::SwapBuffers(
    cc::CompositorFrame* frame) {
  ......

  frame_holder_.reset(new cc::CompositorFrame);
  frame->AssignTo(frame_holder_.get());

  ......
}

       参数frame指向的Compositor Frame描述的就是网页的绘制结果。从前面Chromium硬件加速渲染的UI合成过程分析一文可以知道，这个Compositor Frame包含了一系列的Render Pass。每一个Render Pass都包含了若干个纹理，以及每一个纹理的绘制参数。这些纹理是在Render端光栅化网页时产生的。Browser端的Hardware Renderer所要做的事情就是将这些纹理渲染在屏幕上。这个过程也就是Browser端合成网页UI的过程。

       SynchronousCompositorOutputSurface类的成员函数SwapBuffers会将参数frame描述的Compositor Frame的内容拷贝一份到一个新创建的Compositor Frame中去。这个新创建的Compositor Frame会保存在SynchronousCompositorOutputSurface类的成员变量frame_hodler_中。因此，前面分析的SynchronousCompositorOutputSurface类的成员函数InvokeComposite返回给调用者的就是当前绘制的网页的内容。

       这一步执行完成后，回到前面分析的BrowserViewRenderer类的成员函数OnDrawHardware中，这时候它就获得了一个Render端绘制网页的结果，也就是一个Compositor Frame。这个Compositor Frame会保存在一个DrawGLInput对象中。这个DrawGLInput对象又会保存在BrowserViewRenderer类的成员变量shared_renderer_state_指向的一个SharedRendererState对象中。这是通过调用SharedRendererState类的成员函数SetDrawGLInput实现的，如下所示：

void SharedRendererState::SetDrawGLInput(scoped_ptr<DrawGLInput> input) {
  ......
  draw_gl_input_ = input.Pass();
}

      SharedRendererState类的成员函数SetDrawGLInput将参数input指向的一个DrawGLInput对象保存成员变量draw_gl_input_中。

      这一步执行完成后，再回到前面分析的BrowserViewRenderer类的成员函数OnDrawHardware中，接下来它会调用成员变量client_指向的一个Native层AwContents对象的成员函数RequestDrawGL请求在参数java_canvas描述的一个Hardware Canvas中增加一个DrawFunctorOp操作，如下所示：

bool AwContents::RequestDrawGL(jobject canvas, bool wait_for_completion) {
  ......

  JNIEnv* env = AttachCurrentThread();
  ScopedJavaLocalRef<jobject> obj = java_ref_.get(env);
  if (obj.is_null())
    return false;
  return Java_AwContents_requestDrawGL(
      env, obj.obj(), canvas, wait_for_completion);
}

       在前面Android WebView执行GPU命令的过程分析一文中，我们已经分析过Native层AwContents类的成员函数RequestDrawGL的实现了，它主要就是调用Java层的AwContents类的成员函数requestDrawGL请求在参数canvas描述的Hardware Canvas中增加一个DrawFunctorOp操作。

       Java层的AwContents类的成员函数requestDrawGL最终会调用到DrawGLFunctor类的成员函数requestDrawGL在参数canvas描述的Hardware Canvas中增加一个DrawFunctorOp操作，如下所示：

class DrawGLFunctor {
    ......

    public boolean requestDrawGL(HardwareCanvas canvas, ViewRootImpl viewRootImpl,
            boolean waitForCompletion) {
        ......

        if (canvas == null) {
            viewRootImpl.invokeFunctor(mDestroyRunnable.mNativeDrawGLFunctor, waitForCompletion);
            return true;
        }

        canvas.callDrawGLFunction(mDestroyRunnable.mNativeDrawGLFunctor);
        ......

        return true;
    }

    ......
}

       在前面Android WebView执行GPU命令的过程分析一文中，DrawGLFunctor类的成员函数requestDrawGL是在Render端光栅化网页UI的过程中调用的。这时候参数canvas的值等于null，因此DrawGLFunctor类的成员函数requestDrawGL会通过调用参数viewRootImpl指向的一个ViewRootImpl对象的成员函数invokeFunctor直接请求App的Render Thread执行GPU命令。

       现在，当DrawGLFunctor类的成员函数requestDrawGL被调用时，它的参数canvas的值不等于null，指向了一个Hardware Canvas。在这种情况下，DrawGLFunctor类的成员函数requestDrawGL将会调用这个Hardware Canvas的成员函数callDrawGLFunction，将一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作，写入到它描述一个Display List中去。

       被封装的Native层DrawGLFunctor对象，保存在Java层DrawGLFunctor类的成员变量mDestroyRunnable指向的一个DestroyRunnable对象的成员变量mNativeDrawGLFunctor中。这一点可以参考前面Android WebView执行GPU命令的过程分析一文。

       从前面Android应用程序UI硬件加速渲染的Display List渲染过程分析一文可以知道，参数canvas描述的Hardware Canvas是通过一个GLES20Canvas对象描述的，因此接下来它的成员函数callDrawGLFunction会被调用，用来将一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作写入它描述一个Display List中去，如下所示：

class GLES20Canvas extends HardwareCanvas {
    ......

    @Override
    public int callDrawGLFunction(long drawGLFunction) {
        return nCallDrawGLFunction(mRenderer, drawGLFunction);
    }

    ......
}

       GLES20Canvas类的成员函数callDrawGLFunction调用另外一个成员函数nCallDrawGLFunction将参数drawGLFunction描述的一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作写入到当前正在处理的GLES20Canvas对象描述一个Display List中去。

       GLES20Canvas类的成员函数nCallDrawGLFunction是一个JNI方法，它由C++层的函数android_view_GLES20Canvas_callDrawGLFunction实现，如下所示：

static jint android_view_GLES20Canvas_callDrawGLFunction(JNIEnv* env, jobject clazz,
        jlong rendererPtr, jlong functorPtr) {
    DisplayListRenderer* renderer = reinterpret_cast<DisplayListRenderer*>(rendererPtr);
    Functor* functor = reinterpret_cast<Functor*>(functorPtr);
    android::uirenderer::Rect dirty;
    return renderer->callDrawGLFunction(functor, dirty);
}

       参数rendererPtr描述的是一个Native层的DisplayListRenderer对象。这个DisplayListRenderer对象负责构造App UI的Display List。函数android_view_GLES20Canvas_callDrawGLFunction所做的事情就是调用这个DisplayListRenderer对象的成员函数callDrawFunction将参数functionPtr描述的一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作写入到App UI的Display List中去，如下所示：

status_t DisplayListRenderer::callDrawGLFunction(Functor *functor, Rect& dirty) {
    // Ignore dirty during recording, it matters only when we replay
    addDrawOp(new (alloc()) DrawFunctorOp(functor));
    mDisplayListData->functors.add(functor);
    return DrawGlInfo::kStatusDone; // No invalidate needed at record-time
}

       DisplayListRenderer类的成员变量mDisplayListData指向的是一个DisplayListData对象。这个DisplayListData对象描述的就是App UI的Display List。因此，DisplayListRenderer对象的成员函数callDrawFunction就会将参数functor描述的一个Native层DrawGLFunctor对象封装成一个DrawFunctorOp操作写入到它里面去。

       这一步执行完成后，Android WebView就在App渲染一个帧的第一个阶段通知Render端绘制完成了网页的UI，并且往App UI的Display List写入了一个DrawFunctorOp操作。在第二阶段，App UI的Display List就会从App的UI线程同步给App的Render Thread。从前面Android应用程序UI硬件加速渲染的Display List渲染过程分析一文可以知道，在同步的过程中，RenderNode类的成员函数pushStagingDisplayListChanges地被调用，如下所示：

void RenderNode::pushStagingDisplayListChanges(TreeInfo& info) {
    if (mNeedsDisplayListDataSync) {
        mNeedsDisplayListDataSync = false;
        ......
        if (mDisplayListData) {
            for (size_t i = 0; i < mDisplayListData->functors.size(); i++) {
                (*mDisplayListData->functors[i])(DrawGlInfo::kModeSync, NULL);
            }
        }
        ......
    }
}

       这时候包含在App UI的Display List中的每一个DrawFunctorOp操作关联的Native层DrawGLFunctor对象的重载操作符函数()都会被调用，目的是让它执行一些同步操作。在我们这个情景中，就是将Render端绘制出来的UI同步到给Browser端。

       在前面Android WebView执行GPU命令的过程分析一文中，我们已经分析过Native层DrawGLFunctor对象的重载操作符函数()的实现了，它最终会调用到Native层的AwContents类DrawGL将Render端绘制出来的UI同步到给Browser端，如下所示：

void AwContents::DrawGL(AwDrawGLInfo* draw_info) {
  if (draw_info->mode == AwDrawGLInfo::kModeSync) {
    if (hardware_renderer_)
      hardware_renderer_->CommitFrame();
    return;
  }

  ......
}

      这时候App的Render Thread处于AwDrawGLInfo::kModeSync状态，因此AwContents类的成员函数DrawGL接下来将会调用成员变量hardware_renderer_指向的一个HardwareRenderer对象的成员函数CommitFrame将Render端绘制出来的UI同步到给Browser端，如下所示：

void HardwareRenderer::CommitFrame() {
  scoped_ptr<DrawGLInput> input = shared_renderer_state_->PassDrawGLInput();
  ......

  if (!frame_provider_ || size_changed) {
    ......

    frame_provider_ = new cc::DelegatedFrameProvider(
        resource_collection_.get(), input->frame.delegated_frame_data.Pass());

    delegated_layer_ = cc::DelegatedRendererLayer::Create(frame_provider_);
    ......

    root_layer_->AddChild(delegated_layer_);
  } else {
    frame_provider_->SetFrameData(input->frame.delegated_frame_data.Pass());
  }
}

      从前面的分析可以知道，Render端在第一阶段已经将绘制出来的网页UI，保存在一个DrawGLInput对象中。这个DrawGLInput又保存在一个SharedRendererState对象中。HardwareRenderer类的成员变量shared_renderer_state_描述的就是这个SharedRendererState对象。因此，HardwareRenderer类的成员函数CommitFrame可以通过调用这个SharedRendererState对象的成员函数PassDrawGLInput获得保存在它内部的DrawGLInput对象，如下所示：

scoped_ptr<DrawGLInput> SharedRendererState::PassDrawGLInput() {
  base::AutoLock lock(lock_);
  return draw_gl_input_.Pass();
}

      从前面的分析可以知道，用来描述Render端在第一阶段绘制出来的网页UI的DrawGLInput对象就保存在SharedRendererState类的成员变量draw_gl_input_中，因此SharedRendererState类的成员函数PassDrawGLInput就可以将这个员变量draw_gl_input_指向的DrawGLInput对象返回给调用者。

       回到前面分析的HardwareRenderer类的成员函数CommitFrame中，这时候它获得了一个Render端在第一阶段绘制出来的UI，也就是一个DrawGLInput对象，接下来它就会判断之前是否已经为Browser端的CC Layer Tree创建过一个Delegated Renderer Layer。

       如果还没有创建，或者以前创建过，但是现在Android WebView的大小发生了变化，那么HardwareRenderer类的成员函数CommitFrame就会创建用前面获得的DrawGLInput对象创建一个Delegated Renderer Layer，并且作为Browser端的CC Layer Tree的根节点的子节点。

       另一方面，如果已经创建，并且Android WebView的大小没有发生变化，那么HardwareRenderer类的成员函数CommitFrame就会使用前面获得的DrawGLInput对象更新Delegated Renderer Layer的内容。

       这一步执行完成后，Android WebView就在App渲染一个帧的第二个阶段将Render端绘制出来的网页UI同步给了Browser端。在第三阶段，Browser端就会将网页的UI合成在App的窗口中，这样就可以显示在屏幕中了。

       从前面Android应用程序UI硬件加速渲染的Display List渲染过程分析一文可以知道，App的Render Thread在第三阶段会通过一个OpenGL Renderer渲染从App的UI线程同步过来的Display List，也就是执行它里面包含的渲染操作。从前面的分析可以知道，Android WebView在第一阶段往这个Display List写入了一个DrawFunctorOp操作，OpenGL Renderer会通过调用它的成员函数callDrawGLFunction执行这个操作，如下所示：

status_t OpenGLRenderer::callDrawGLFunction(Functor* functor, Rect& dirty) {
    ......

    mRenderState.invokeFunctor(functor, DrawGlInfo::kModeDraw, &info);
    ......

    return DrawGlInfo::kStatusDrew;
}

      参数funtor描述的就是与当前要执行的DrawFunctorOp操作关联的Native层DrawGLFunctor对象。OpenGLRenderer类的成员函数callDrawGLFunction会通过调用成员变量mRenderState指向的一个RenderState对象的成员函数invokeFunctor调用这个Native层DrawGLFunctor对象的重载操作符函数()，告知它App的Render Thread当前处于第三阶段，也就是DrawGlInfo::kModeDraw状态，它可以执行相应的GPU命令。

      在前面Android WebView执行GPU命令的过程分析一文中，我们已经分析过RenderState类的成员函数invokeFunctor的实现了，它最终会调用到Native层的AwContents类DrawGL将绘制Browser端的CC Layer Tree，如下所示：

void AwContents::DrawGL(AwDrawGLInfo* draw_info) {
  if (draw_info->mode == AwDrawGLInfo::kModeSync) {
    ......
    return;
  }

  ......

  if (draw_info->mode != AwDrawGLInfo::kModeDraw) {
    ......
    return;
  }

  ......

  hardware_renderer_->DrawGL(state_restore.stencil_enabled(),
                             state_restore.framebuffer_binding_ext(),
                             draw_info);
  ......
}

       由于当前App的Render Thread处于AwDrawGlInfo::kModeDraw状态，因此AwContents类DrawGL会调用成员变量hardware_renderer_指向的一个HardwareRenderer对象的成员函数DrawGL，用来绘制Browser端的CC Layer Tree，如下所示：

void HardwareRenderer::DrawGL(bool stencil_enabled,
                              int framebuffer_binding_ext,
                              AwDrawGLInfo* draw_info) {
  ......

  {
    ......
    layer_tree_host_->Composite(gfx::FrameTime::Now());
  }

  ......
}

      从前面Android WebView执行GPU命令的过程分析一文可以知道，HardwareRenderer类的成员变量layer_tree_host_指向的是一个LayerTreeHost对象。这个LayerTreeHost对象描述的就是Browser端的CC Layer Tree。HardwareRenderer类的成员函数DrawGL将会调用这个LayerTreeHost对象的成员函数Composite，以便绘制Browser端的CC Layer Tree，如下所示：

void LayerTreeHost::Composite(base::TimeTicks frame_begin_time) {
  ......
  SingleThreadProxy* proxy = static_cast<SingleThreadProxy*>(proxy_.get());

  .....

  proxy->CompositeImmediately(frame_begin_time);
}

      从前面Android WebView执行GPU命令的过程分析一文可以知道，当前正在处理的LayerTreeHost对象的成员变量proxy_指向的是一个SingleThreadProxy对象，LayerTreeHost类的成员函数Composite调用这个SingleThreadProxy对象的成员函数CompositeImmediately绘制Browser端的CC Layer Tree，如下所示：

void SingleThreadProxy::CompositeImmediately(base::TimeTicks frame_begin_time) {
  ......

  LayerTreeHostImpl::FrameData frame;
  if (DoComposite(frame_begin_time, &frame)) {
    {
      ......
    }
    ......
  }
}

       SingleThreadProxy类的成员函数CompositeImmediately主要是调用另外一个成员函数DoComposite绘制Browser端的CC Layer Tree，如下所示：

bool SingleThreadProxy::DoComposite(
    base::TimeTicks frame_begin_time,
    LayerTreeHostImpl::FrameData* frame) {
  ......

  bool lost_output_surface = false;
  {
    ......

    if (!layer_tree_host_impl_->IsContextLost()) {
      layer_tree_host_impl_->PrepareToDraw(frame);
      layer_tree_host_impl_->DrawLayers(frame, frame_begin_time);
      ......
    }
    
    ......
  }

  ......
} 

       从前面Android WebView执行GPU命令的过程分析一文可以知道，SingleThreadProxy类的成员变量layer_tree_host_impl_指向的是一个LayerTreeHostImpl对象。SingleThreadProxy类的成员函数DoComposite主要是调用这个LayerTreeHostImpl对象的成员函数PrepareToDraw和DrawLayers绘制Browser端的CC Layer Tree。

       LayerTreeHostImpl类的成员函数PrepareToDraw和DrawLayers绘制CC Layer Tree的过程可以参考前面Chromium硬件加速渲染的UI合成过程分析一文。从前面Chromium硬件加速渲染的UI合成过程分析一文我们还可以知道，Chromium的Browser端在内部是通过一个Direct Renderer绘制CC Layer Tree的，而Render端是通过一个Delegated Renderer绘制CC Layer Tree的。Delegated Renderer并不是真的绘制CC Layer Tree，而只是将CC Layer Tree的绘制命令收集起来，放在一个Compositor Frame中。这个Compositor Frame最终会交给Browser端的Direct Renderer处理。Direct Renderer直接调用OpenGL函数执行保存在Compositor Frame的绘制命令。因此，当Browser端绘制完成自己的CC Layer Tree之后，加载在Android WebView中的网页UI就会合成显示在App的窗口中了。

      至此，我们就分析完成了Android WebView硬件加速渲染网页UI的过程，也完成了对Android基于Chromium实现的WebView的学习。重新学习可以参考Android WebView简要介绍和学习计划一文。更多的学习信息可以关注老罗的新浪微博：http://weibo.com/shengyangluo。

       上个月，在花了一年半时间之后，写了55篇文章，分析完成了Chromium在Android上的实现，以及Android基于Chromium实现的WebView。学到了很多东西，不过也挺累的，平均不到两个星期一篇文章。本来想休息一段时间后，再继续分析Chromium使用的JS引擎V8。不过某天晚上，躺在床上睡不着，鬼使神差想着去创建一个个人站点，用来连载《Android系统源代码情景分析》一书的内容。

       事情是这样的，躺在床上睡不着，就去申请了一个域名，0xcc0xcd.com。域名申请到了，总不能不用吧。用来做什么呢？想起我写的那本书《Android系统源代码情景分析》，从2012年10月出版至今，也有四年多的时间了，得到了大家的厚受。不过网络上也逐渐的出现了一些盗版PDF。不用说，质量肯定很差。干脆我把这本书的内容在我的个人站点上放出来吧。后面征得了出版社的同意，就着手开始干了。

       网站名称为“进击的程序员”，主要是为了配合0xcc0xcd.com这个域名。从Windows时代过来的老司机可能一眼就能看出这个域名是什么意思。看不懂的，如果大家有兴趣，后面我也可以详细说说，怀念一下逝去的青春。

       从开始有想法，到把网站建好，以及将书前三章（准备知识、硬件抽象层、智能指针）的内容放上去，花了不到一个月的时间。在这不到一个月的时间里，学习到了挺多东西：申请域名、云服务器、域名解析、域名邮箱、网站备案以及开发网站等等。因为我一直都是做客户端开发，刚毕业几年做的是Windows客户端，后面做的是Android端，没有做过网站相关的开发，包含前端和后端，所以学习过程还是有些小波折。不过总体上来说还是比较顺利的。这也跟网站的技术选型有关吧。

       网站使用的是LNMP架构，如下图1所示：

图1 进击的程序员网站架构

       网站运行在云服务器上，系统装的是Ubuntu 14.04，除了Nginx、PHP和MySQL，还搭了一个GIT仓库，用来管理网站源码。这个GIT仓库除了用来管理网站源码，还用来将源码分布到网站中去。

       具体是这样的，在本地用自己的电脑开发网站（其实就是用vim编辑网页和PHP）。测试没有问题之后，就用git push命令将源码上传到GIT仓库。然后再登录到云服务器上，在网站根目录用git pull命令从GIT仓库中获得最新网站源码。

       此外，在本地还搭建了一个管理后台。这个管理后台就是用来给管理员管理网站的。主要就是操作一下数据库，例如查看数据、插入数据、更新数据等等。正规的网站会专门提供一些页面供管理员操作。鉴于这个网站不是很正规，管理员又是一个技术控，于是就直接使用Python脚本来实现这个管理后台了，想要什么功能就直接写个脚本。

      Oracle提供了一个Python版的MySQL数据库驱动库MySQL Connector/Python，通过它很容易用Python脚本操作MySQL中的数据。这样一个简单的管理后台就搭建起来了。

      整个网站的架构非常简单，可以非常快上手，同时它又五脏俱全。网站的前端主要用Ajax、jQuery开发，后端没有用什么高大尚的框架，基本上是徒手写的PHP。主要是考虑这个网站要做的事情很简单，就是连载《Android系统源代码情景分析》的内容，基本功能就是浏览和评论。所以就以最简单最快的方式实现。

      为了让大家利用碎片时间更好地阅读书的内容，网站在提供PC版的同时，也提供了移动版。移动版和PC版的功能是一样的，只是它们的页面表现形式不一样。所以网站在设计之初，就考虑了模块化和代码复用，用最小的成本获得同时实现PC端和移动端的功能。

      不知道为什么，说起PHP， 总是会想起“PHP是最好的语言”这句话。从这一个月的经历看，PHP是不是最好的语言不知道，但是用来建网站，PHP的确是最好的语言。用PHP和JS开发网站，效率比用Java/OC开发App，高多了。不过，网站的体验不如App。所以移动开发目前还是王道。

       接下来，我会用一个系列的文章分享整个建站过程，包括：

       1. 域名、云服务器、域名解析、网站备案、域名邮箱、CA证书申请

       2. LNMP开发环境搭建，包括如何配置SSL加密的HTTPS站点

       3. 支持SSH访问的GIT仓库搭建

       4. 网站基本功能开发，PC版和移动版代码复用

       5. 基于MySQL Connector/Python的管理后台开发

       欢迎大家关注！想在线阅读《Android系统源代码情景分析》一书的，点击进击的程序员进入！

百度云的天工物联网服务目前包括：物接入、物解析、物管理、时序数据库和规则引擎等5大部分，本篇文章仅介绍物接入。

天工物联网的物接入，从开发者的角度来说相对有些复杂，需要多步操作才能实现一个云设备的创建，下面我们将详细介绍一下相关的步骤：

第一步：创建实例（类似工程中的项目概念）

支持三种方式访问。TCP，SSL（TCP加密通道），WSS（WebSocket 加密通道）。

第二步：创建设备

第三步：创建身份

天工物联网对设备的访问增加了身份这一个功能，这样对一个项目来说，安全性有了一定层度的提升，比如有些模块，只有上传的功能，那么可以绑定一个低权限的身份。或者是联合进行项目开发的时候，有些设备需要第三方合作开发，那么为第三方配置一个身份即可，约束其要传或收的topic即可。

第四步：创建策略

每个身份其实可以绑定若干个策略，每个策略对应若干个topic主题。和微软及阿里不同，百度的topic没有默认主题，这里我们创建一个相对通用的“yfiothub/yfdevice01/#”。也就是说这个节点下的所有topic都可以订阅也可以发布。

第五步：获取访问密钥

这个密钥其实是和身份绑定的，而不是和设备绑定的，不同的身份对应不同的密钥，不同的身份包含的策略也不一样。所以相同的用户名，不同的密钥对应的身份不同。

完成以上5步操作，那么我们就可以让设备来对接物联网云平台了。

和微软及阿里的物联网平台不同，百度的云连接非常简单。客户ID可以任意，用户名就是和设备对应的用户名，密码就是身份对应的密码，没有所谓的toKen等概念。

发布和订阅的topic，我们仿照阿里的分别定义为：

yfiothub/yfdevice01/update

yfiothub/yfdevice01/get

除了代码编写外，同样我们也做组态的方案，具体实施步骤如下：

第一步：添加设备

设备变量自动生成

第二步：增加百度云MQTT客户端策略

填写完服务器配置信息，然后勾选需要上传的IO变量

第三步：部署运行

相对于微软和阿里，天工物联网的“设备列表”下有一个“连接测试”的功能，可以直接进行通信监控。单击“连接测试”，进入如下页面，需要配置相关信息。

用户名就是设备对应的用户名，身份密钥就是身份对应的密钥。目前该测试页面仅支持WSS方式连接。

连接成功后，我们就可以进行订阅和发布操作了（如下图所示）。

相关的硬件如下：

嵌套类

class Tree(var treeName:String) {
    //在类内部再定义一个类，这个新类称作嵌套类
    class Flower (var flowerName:String) {
        fun getName():String {
            return "这是一朵$flowerName"
            //普通的嵌套类不能访问外部类的成员如treeName
            //否则编译器报错“Unresolved reference: ***”
            //return "这是${treeName}上的一朵$flowerName"
        }
    }
}

    btn_class_nest.setOnClickListener {
        //使用嵌套类时，只能引用外部类的类名，不能调用外部类的构造函数
        val peachBlossom = Tree.Flower("桃花");
        tv_class_secret.text = peachBlossom.getName()
    }

内部类

class Tree(var treeName:String) {
    //在类内部再定义一个类，这个新类称作嵌套类
    class Flower (var flowerName:String) {
        fun getName():String {
            return "这是一朵$flowerName"
            //普通的嵌套类不能访问外部类的成员如treeName
            //否则编译器报错“Unresolved reference: ***”
            //return "这是${treeName}上的一朵$flowerName"
        }
    }

    //嵌套类加上了inner前缀，就成为了内部类
    inner class Fruit (var fruitName:String) {
        fun getName():String {
            //只有声明为内部类（添加了关键字inner），才能访问外部类的成员
            return "这是${treeName}长出来的$fruitName"
        }
    }
}

    btn_class_inner.setOnClickListener {
        //使用内部类时，必须调用外部类的构造函数，否则编译器会报错
        val peach = Tree("桃树").Fruit("桃花");
        tv_class_secret.text = peach.getName()
    }

枚举类

enum Season { SPRING,SUMMER,AUTUMN,WINTER }

enum class SeasonType {
    SPRING,SUMMER,AUTUMN,WINTER
}

enum class SeasonName (val seasonName:String) {
    SPRING("春天"),
    SUMMER("夏天"),
    AUTUMN("秋天"),
    WINTER("冬天")
}

    btn_class_enum.setOnClickListener {
        if (count%2 == 0) {
            //ordinal表示枚举类型的序号，name表示枚举类型的名称
            tv_class_secret.text = when (count++%4) {
                SeasonType.SPRING.ordinal -> SeasonType.SPRING.name
                SeasonType.SUMMER.ordinal -> SeasonType.SUMMER.name
                SeasonType.AUTUMN.ordinal -> SeasonType.AUTUMN.name
                SeasonType.WINTER.ordinal -> SeasonType.WINTER.name
                else -> "未知"
            }
        } else {
            tv_class_secret.text = when (count++%4) {
                //使用自定义属性seasonName表示更个性化的描述
                SeasonName.SPRING.ordinal -> SeasonName.SPRING.seasonName
                SeasonName.SUMMER.ordinal -> SeasonName.SUMMER.seasonName
                SeasonName.AUTUMN.ordinal -> SeasonName.AUTUMN.seasonName
                SeasonName.WINTER.ordinal -> SeasonName.WINTER.seasonName
                else -> "未知"
                //枚举类的构造函数是给枚举类型使用的，外部不能直接调用枚举类的构造函数
                //else -> SeasonName("未知").name
            }
        }
    }

密封类

sealed class SeasonSealed {
    //密封类内部的每个嵌套类都必须继承该类
    class Spring (var name:String) : SeasonSealed()
    class Summer (var name:String) : SeasonSealed()
    class Autumn (var name:String) : SeasonSealed()
    class Winter (var name:String) : SeasonSealed()
}

    btn_class_sealed.setOnClickListener {
        var season = when (count++%4) {
            0 -> SeasonSealed.Spring("春天")
            1 -> SeasonSealed.Summer("夏天")
            2 -> SeasonSealed.Autumn("秋天")
            else -> SeasonSealed.Winter("冬天")
        }
        //密封类是一种严格的枚举类，它的值是一个有限的集合。
        //密封类确保条件分支覆盖了所有的枚举类型，因此不再需要else分支。
        tv_class_secret.text = when (season) {
            is SeasonSealed.Spring -> season.name
            is SeasonSealed.Summer -> season.name
            is SeasonSealed.Autumn -> season.name
            is SeasonSealed.Winter -> season.name
        }
    }

数据类

//数据类必须有主构造函数，且至少有一个输入参数，
//并且要声明与输入参数同名的属性，即输入参数前面添加关键字val或者var，
//数据类不能是基类也不能是子类，不能是抽象类，也不能是内部类，更不能是密封类。
data class Plant(var name:String, var stem:String, var leaf:String, var flower:String, var fruit:String, var seed:String) {
}

    var lotus = Plant("莲", "莲藕", "莲叶", "莲花", "莲蓬", "莲子")
    //数据类的copy方法不带参数，表示复制一模一样的对象
    var lotus2 = lotus.copy()
    btn_class_data.setOnClickListener {
        lotus2 = when (count++%2) {
            //copy方法带参数，表示指定参数另外赋值
            0 -> lotus.copy(flower="荷花")
            else -> lotus.copy(flower="莲花")
        }
        //数据类自带equals方法，用于判断两个对象是否一样
        var result = if (lotus2.equals(lotus)) "相等" else "不等"
        tv_class_secret.text = "两个植物的比较结果是${result}\n" +
                "第一个植物的描述是${lotus.toString()}\n" +
                "第二个植物的描述是${lotus2.toString()}"
    }

模板类

//在类名后面添加“<T>”，表示这是一个模板类
class River<T> (var name:String, var length:T) {
    fun getInfo():String {
        var unit:String = when (length) {
            is String -> "米"
            //Int、Long、Float、Double都是数字类型Number
            is Number -> "m"
            else -> ""
        }
        return "${name}的长度是$length$unit。"
    }
}

    btn_class_generic.setOnClickListener {
        var river = when (count++%4) {
            //模板类(泛型类)声明对象时，要在模板类的类名后面加上“<参数类型>”
            0 -> River<Int>("小溪", 100)
            //如果编译器根据输入参数就能知晓参数类型，也可直接省略“<参数类型>”
            1 -> River("瀑布", 99.9f)
            //当然保守起见，新手最好按规矩添加“<参数类型>”
            2 -> River<Double>("山涧", 50.5)
            //如果你已经是老手了，怎么方便怎么来，Kotlin的设计初衷就是偷懒
            else -> River("大河", "一千")
        }
        tv_class_secret.text = river.getInfo()
    }

UIAlertController 是 iOS 8 中推出的新特性，用以代替 UIAlertView 和 UIActionSheet。在开发中非常常见，今天作一下简要记录，用以备忘。

之所以要把它单独拿出来说，是因为面对设计给出的 UI 界面需求，系统自身的默认配置是不能够得以满足的，常常需要 DIY 其属性。下面主要从设置字体大小、颜色、显示顺序以及弹出输入文本框等方面加以说明，也算得上是使用 UIAlertController 的一点点小小的总结。

1. 修改标题颜色字体大小

NSString *alertTitle = @"确定要关闭窗口吗";
NSMutableAttributedString *attTitle = [[NSMutableAttributedString alloc]initWithString:@"标题1" attributes:@{NSForegroundColorAttributeName:[UIColor blueColor],NSFontAttributeName:[UIFont systemFontOfSize:24]}];

UIAlertController *alert = [UIAlertController alertControllerWithTitle:alertTitle message:nil preferredStyle:UIAlertControllerStyleAlert];
[alert setValue:attTitle forKey:@"attributedTitle"];

NSString *okText = @"确定";
UIAlertAction *confirmAction = [UIAlertAction actionWithTitle:okText style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {

    }];
[confirmAction setValue:[UIColor blackColor] forKey:@"titleTextColor"];

NSString *cancelText = @"否";
UIAlertAction *cancelAction = [UIAlertAction actionWithTitle:cancelText style:UIAlertActionStyleCancel handler:nil];
[cancelAction setValue:[UIColor redColor] forKey:@"titleTextColor"];

[alert addAction:confirmAction];
[alert addAction:cancelAction];

[self presentViewController:alert animated:NO completion:nil];

运行效果见文章末尾的图左边第一个。核心代码：

NSMutableAttributedString *attTitle = [[NSMutableAttributedString alloc]initWithString:@"标题1" attributes:@{NSForegroundColorAttributeName:[UIColor blueColor],NSFontAttributeName:[UIFont systemFontOfSize:24]}];
UIAlertController *alert = [UIAlertController alertControllerWithTitle:alertTitle message:nil preferredStyle:UIAlertControllerStyleAlert];
[alert setValue:attTitle forKey:@"attributedTitle"];

2. 单独修改消息按钮颜色

NSString *alertTitle = @"确定要关闭窗口吗";

UIAlertController *alert = [UIAlertController alertControllerWithTitle:alertTitle message:nil preferredStyle:UIAlertControllerStyleAlert];

NSString *okText = @"确定";
UIAlertAction *confirmAction = [UIAlertAction actionWithTitle:okText style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {

    }];
[confirmAction setValue:[UIColor blackColor] forKey:@"titleTextColor"];

NSString *cancelText = @"否";
UIAlertAction *cancelAction = [UIAlertAction actionWithTitle:cancelText style:UIAlertActionStyleCancel handler:nil];
[cancelAction setValue:[UIColor redColor] forKey:@"titleTextColor"];

[alert addAction:confirmAction];
[alert addAction:cancelAction];

[self presentViewController:alert animated:NO completion:nil];

运行效果见文章末尾的图左边第二个。核心代码（同样是 KVC）：

[confirmAction setValue:[UIColor blackColor] forKey:@"titleTextColor"];
[cancelAction setValue:[UIColor redColor] forKey:@"titleTextColor"];

3. 改变消息按钮位置

要想改变消息按钮的位置，只需将两者的 style 都改为 UIAlertActionStyleDefault 即可。代码如下：

NSString *alertTitle = @"确定要关闭窗口吗";

UIAlertController *alert = [UIAlertController alertControllerWithTitle:alertTitle message:nil preferredStyle:UIAlertControllerStyleAlert];

NSString *okText = @"确定";
UIAlertAction *confirmAction = [UIAlertAction actionWithTitle:okText style:UIAlertActionStyleDefault handler:^(UIAlertAction * _Nonnull action) {

    }];
[confirmAction setValue:[UIColor blackColor] forKey:@"titleTextColor"];

NSString *cancelText = @"否";
UIAlertAction *cancelAction = [UIAlertAction actionWithTitle:cancelText style:UIAlertActionStyleDefault handler:nil];
[cancelAction setValue:[UIColor redColor] forKey:@"titleTextColor"];

[alert addAction:confirmAction];
[alert addAction:cancelAction];

[self presentViewController:alert animated:NO completion:nil];

4. 弹出文本输入框

很多时候也有弹出输入框的需求，废话不多说，直接上代码：

UIAlertController * alertController = [UIAlertController alertControllerWithTitle: @"登陆"
                                                                      message: @"输入用户名密码"
                                                                       preferredStyle:UIAlertControllerStyleAlert];
[alertController addTextFieldWithConfigurationHandler:^(UITextField *textField) {
        textField.placeholder = @"name";
        textField.textColor = [UIColor blueColor];
        textField.clearButtonMode = UITextFieldViewModeWhileEditing;
        textField.borderStyle = UITextBorderStyleRoundedRect;
    }];
[alertController addTextFieldWithConfigurationHandler:^(UITextField *textField) {
        textField.placeholder = @"password";
        textField.textColor = [UIColor blueColor];
        textField.clearButtonMode = UITextFieldViewModeWhileEditing;
        textField.borderStyle = UITextBorderStyleRoundedRect;
        textField.secureTextEntry = YES;
    }];
[alertController addAction:[UIAlertAction actionWithTitle:@"OK" style:UIAlertActionStyleDefault handler:^(UIAlertAction *action) {

    }]];
[alertController addAction:[UIAlertAction actionWithTitle:@"cancel" style:UIAlertActionStyleCancel handler:^(UIAlertAction * _Nonnull action) {

    }]];

[self presentViewController:alertController animated:YES completion:nil];

最后，把上面四个实例的运行结果贴在末尾，供参考：

Android发包有许多坑的地方，下面对之前遇到过的问题进行总结，以期望将来不再出现这些令人不快的问题。

1. 代码混淆

代码混淆问题已经在发包流程中多次出现，其主要的原因是：靠反射执行的方法在代码混淆后会找不到反射的类导致该部分功能失效，甚至导致Crash。
这一问题在广告以及第三方SDK的使用中多次出现，尤其是在SDK升级或者接入新的SDK的时候特别要注意这个问题，另外在自己使用反射的时候也需要注意这个问题。

如何防范：

为了方便解决和验证这一问题，可以在Debug模式下开启混淆功能，以达到在Debug上进行测试混淆结果的目的。

对于日常QA测试来说，验证新广告的时候，所使用的包都需要进行混淆后测试，以验证广告混淆后的工作情况。

2. Manifest中的权限被覆盖

这一问题曾经出现在HyprMX SDK升级后，HyprMX SDK的内部在使用SDK读写权限的时候引入了maxSdkVersion这一属性，对SD卡读写权限进行了限制，导致引入该SDK后会让高版本系统的SD卡读写权限失效，进而影响所有与文件操作相关的功能。在Android studio包合并之后会将该属性合并到主的Manifest中，从而将该问题带入到整个Dingtone工程。

如何防范：

对于以后类似问题的处理，可以在接入新的SDK的时候，审查其Manifest和混淆文件的内容，避免被其坑到，尤其对于权限相关的操作限制。

另外，上包前的自动化case也需要足够全面，能执行对应的功能来检查其权限的情况

3. ContentProvider的用法错误

曾经在Kiip SDK升级的时候出现过该问题，新版本的Kiip demo指定添加Provider组件，但是在声明其authorities属性的时候将Dingtone和TalkU的属性设为了一样的了，这会导致手机中只能存在其中一个App，在安装另一个App的时候就会报错，这种情况在DN1和PN1也一样。

如何防范：

我们App基本不会使用ContentProvider，ContentProvider用于对外提供数据访问，我们App目前暂时不涉及到对其他App提供数据。如果有第三方SDK需要引入ContentProvider的时候，一定要注意了，首先确认该功能对于这类SDK的使用是否是必须的，比如Kiip要求我们声明provider，但实际上该功能对其正常使用没有任何的作用，且可能会存在把我们App数据暴露给其他App的风险，所以可以不需要集成。如果真的有必要使用该组件的话，则必须要让authorities属性在不同的App里面不一样，可以采用与包名对应的命名方式。

比如：${applicationId}.KEY

4. Manifest里uses-feature标签的required属性

uses-feature标签用于声明所需要的硬件需求，如果其required属性设置为ture的话，则App发布后，GooglePlay会对于不支持的设备不提供下载和升级的服务，这会导致用户下载量下降。

如何防范：

与#2点一样，无论是引入第三方SDK还是在自己集成的时候，一定要检查Manifest中的属性是否存在问题，对于 uses-feature 为true的属性，我们需要将其改为false，并且对于调用的功能的地方，需要手动判断设备是否支持这一硬件需求，之后决定要不要给用户提供对应的功能。

5. Manifest Application标签中的supportsRtl属性

该属性在现在的新版本的Android Studio中会自动添加，且值是true，这就会导致在阿拉伯地区，界面排版会出现从右往左进行的混乱的局面。对于我们这样的还没有进行阿拉伯地区界面排版适配的App来说，这个值需要手动设置为false

如何防范：

与#2点一样，无论是引入第三方SDK还是在自己集成的时候，一定要检查Manifest中的属性是否存在问题，对于supportsRtl属性，需要检查Application的标签属性是否正确。

针对Manifest这一系列的问题，我这边想到了一个方案是对比前后两个版本的Apk的Manifest文件，并标出涉及到权限属性方面的改动，以及时发现和预警权限相关的问题。我这边会提供一个检测的脚本工具，在每次发包之前及时进行这方面的检查工作，并且对于发现的有疑点的地方及时与相关的开发人员进行同步。

对于本次发现的问题，我们通过对比工具可以很明确发现检测到相关的一些特征标志

目前搜集的几点敏感特征如下：

required="true"
authorities=
supportsRtl="true"
maxSdkVersion

可以使用如下脚本对当前要发布的Apk以及之前老的Apk中的权限进行比对

# 命令用法
if [ $# -lt 2 ]; then
    echo "apkDiff APK1 APK2"
    exit 1
else
	if [ ${1} == "--h" ]; then
		echo "apkDiff APK1 APK2"
		exit 1
	fi
	if [ ${1} == "--help" ]; then
		echo "apkDiff APK1 APK2"
		exit 1
	fi
fi


# 解析两个Apk文件的Manifest文件

echo start deco ${1}
apktool d -o 1 ${1}
echo success deco ${1}

echo start deco ${2}
apktool d -o 2 ${2}
echo success deco ${2}

# 比较两个Mainifest的不同
diff 1/AndroidManifest.xml 2/AndroidManifest.xml >> diff.txt

# 匹配敏感权限
grep -E "required=\"true\"|authorities=|supportsRtl=\"true\"|maxSdkVersion" diff.txt >> result.txt

result=$(cat result.txt)
echo -e "\033[32m Differ length:${#result} \033[0m"
echo -e "\033[31m ${result} \033[0m"

我想大家在开发过程中都碰到过这样的需求，类似标签展示，要展示如上图效果，这里面的数据不确定每项字数，有的非常长，有的很短，数据动态填充。

这种情况用listView和gridView展示效果都没有上图的效果。

这时我们其实是要自己写一个控件来填充上图的数据，也就是我们今天要说的自定义view,流式布局。

方法还是重写onMeasure和onLayout

话不多说  ，代码贴上

一.自定义view

package com.jky.mobilebzt.view;

import java.util.ArrayList;
import java.util.List;

import android.content.Context;
import android.util.AttributeSet;
import android.view.View;
import android.view.ViewGroup;

public class XCFlowLayout extends ViewGroup {
	// 存储所有子View
	private List<List<View>> mAllChildViews = new ArrayList<List<View>>();
	// 每一行的高度
	private List<Integer> mLineHeight = new ArrayList<Integer>();

	public XCFlowLayout(Context context, AttributeSet attrs, int defStyleAttr) {
		super(context, attrs, defStyleAttr);
	}

	public XCFlowLayout(Context context, AttributeSet attrs) {
		this(context, attrs, 0);
	}

	public XCFlowLayout(Context context) {
		this(context, null);
	}

	@Override
	protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
		// TODO Auto-generated method stub
		// 父控件传进来的宽度和高度以及对应的测量模式
		int sizeWidth = MeasureSpec.getSize(widthMeasureSpec);
		int modeWidth = MeasureSpec.getMode(widthMeasureSpec);
		int sizeHeight = MeasureSpec.getSize(heightMeasureSpec);
		int modeHeight = MeasureSpec.getMode(heightMeasureSpec);

		// 如果当前ViewGroup的宽高为wrap_content的情况
		int width = 0; // 自己测量的宽度
		int height = 0; // 自己测量的高度

		int lineWidth = 0;// 每一行的宽度
		int lineHeight = 0; // 每一行的高度

		int childCount = getChildCount();// 获取子view的个数
		for (int i = 0; i < childCount; i++) {
			View child = getChildAt(i);
			// 测量子View的宽和高
			measureChild(child, widthMeasureSpec, heightMeasureSpec);
			// 得到LayoutParams
			MarginLayoutParams lp = (MarginLayoutParams) getLayoutParams();
			// 得到子View占据的宽度
			int childWidth = child.getMeasuredWidth() + lp.leftMargin
					+ lp.rightMargin;
			// 得到子View占据的高度
			int childHeight = child.getMeasuredHeight() + lp.topMargin
					+ lp.bottomMargin;
			if (lineWidth + childWidth > sizeWidth) {// 需要进行换行
				width = Math.max(width, lineWidth); // 得到最大宽度
				lineWidth = childWidth; // 重置lineWidth
				height += lineHeight; // 得到高度
				lineHeight = childHeight;// 重置LineHeight
			} else {// 不需要进行换行
				lineWidth += childWidth;// 叠加行宽
				lineHeight = Math.max(lineHeight, childHeight);
			}

			if (i == childCount - 1) {// 处理最后一个子View的情况
				width = Math.max(width, lineWidth);
				height += lineHeight;
			}
		}

		// wrapcontent
		setMeasuredDimension(modeWidth == MeasureSpec.EXACTLY ? sizeWidth
				: width, modeHeight == MeasureSpec.EXACTLY ? sizeHeight
				: height);

//		super.onMeasure(widthMeasureSpec, heightMeasureSpec);
	}

	@Override
	protected void onLayout(boolean changed, int l, int t, int r, int b) {
		// TODO Auto-generated method stub
		mAllChildViews.clear();
		mLineHeight.clear();

		int width = getWidth();// 获取当前ViewGroup宽度
		int lineWidth = 0;
		int lineHeight = 0;

		List<View> lineViews = new ArrayList<View>();// 记录当前行的View
		int childCount = getChildCount();
		for (int i = 0; i < childCount; i++) {
			View child = getChildAt(i);
			MarginLayoutParams lp = (MarginLayoutParams) child
					.getLayoutParams();
			int childWidth = child.getMeasuredWidth();
			int childHeight = child.getMeasuredHeight();

			// 需要换行
			if (lineWidth + childWidth + lp.leftMargin + lp.rightMargin > width) {
				mLineHeight.add(lineHeight); // 记录lineHeight
				mAllChildViews.add(lineViews); // 记录当前行的Views
				// 重置 行的宽高
				lineWidth = 0;
				lineHeight = childHeight + lp.topMargin + lp.bottomMargin;
				// 重置当前行的View集合；
				lineViews = new ArrayList<View>();
			}

			lineWidth += childWidth + lp.leftMargin + lp.rightMargin;
			lineHeight = Math.max(lineHeight, childHeight + lp.topMargin
					+ lp.bottomMargin);
			lineViews.add(child);
		}
		// 处理最后一行
		mLineHeight.add(lineHeight);
		mAllChildViews.add(lineViews);

		// 设置子View的位置
		int left = 0;
		int top = 0;
		// 获取行数
		int lineCount = mAllChildViews.size();
		for (int i = 0; i < lineCount; i++) {
			// 当前行的views和高度
			lineViews = mAllChildViews.get(i);
			lineHeight = mLineHeight.get(i);
			for (int j = 0; j < lineViews.size(); j++) {
				View child = lineViews.get(j);
				// 判断是否显示
				if (child.getVisibility() == View.GONE) {
					continue;
				}
				MarginLayoutParams lp = (MarginLayoutParams) child
						.getLayoutParams();
				int cLeft = left + lp.leftMargin;
				int cTop = top + lp.topMargin;
				int cRight = cLeft + child.getMeasuredWidth();
				int cBottom = cTop + child.getMeasuredHeight();
				// 进行子View进行布局
				child.layout(cLeft, cTop, cRight, cBottom);
				left += child.getMeasuredWidth() + lp.leftMargin
						+ lp.rightMargin;
			}
			left = 0;

			top += lineHeight;
		}
	}

	/**
	 * 与当前ViewGroup对应的LayoutParams
	 */
	@Override
	public LayoutParams generateLayoutParams(AttributeSet attrs) {
		return new MarginLayoutParams(getContext(), attrs);
	}
}

xml布局中加上这个

  <com.jky.mobilebzt.view.XCFlowLayout
                android:id="@+id/xcf_hot_words"
                android:layout_width="match_parent"
                android:layout_height="wrap_content"
                android:layout_marginLeft="@dimen/margin_lsmall"
                android:layout_marginBottom="@dimen/margin_normal"
                android:layout_marginRight="@dimen/margin_normal" />

三.初始化数据部分

	@SuppressLint("NewApi")
	private void initHotWordViews() {
		MarginLayoutParams lp = new MarginLayoutParams(
				LayoutParams.WRAP_CONTENT, LayoutParams.WRAP_CONTENT);
		lp.leftMargin = 20;
		lp.rightMargin = 20;
		lp.topMargin = 8;
		lp.bottomMargin = 8;
		for (int i = 0; i < hotWords.size(); i++) {
			final String hotWord = hotWords.get(i);
			TextView view = new TextView(this);
			view.setGravity(Gravity.CENTER);
			view.setText(hotWords.get(i));
			view.setTextColor(Color.BLACK);
			view.setBackground(getResources().getDrawable(R.drawable.hot_word_selector));
			mFlowLayout.addView(view, lp);
			view.setOnClickListener(new OnClickListener() {
				@Override
				public void onClick(View v) {
				
				}
			});
		}
	}

基本核心的东西就上面这些 ，最上面的图是我的项目里面最后实现的效果图。如果还有其他问题欢迎加入我们的qq群：

开发一群：454430053开发二群：537532956

很多伙伴在开发自己公司产品的时候，一般都会考虑用户账号安全 ，或者用户账号功能使用限制等问题。这时候我们就会考虑到单点登录这个功能。

一般情况下我们在开发单点登录功能的时候，其实有很多种做法，这个根据自己的具体需求选择就可以，其实我一直认为很多东西没有绝对的规则，我们其实需要做的是尽量全面的尽可能多的去掌握更多的知识技术，当我们用到的时候可以从中选择出最适合自己的产品的技术，从开发时间，应用性等。

好了 ，多说了几句题外话，我们现在言归正传，说说我做单点登录的实现方式。

1.创建token

首先我们要在服务端创建一个token的值，这个值是和userid以及手机码绑定到一起的，也就是请求token的时候我们要给服务端传递当前设备的设备号及用户id。token这个值就是客户端调用服务端的凭证。

android 中获取机器唯一标示 deviceid

  //deviceId
    public static String getDeviceId(Context context) {
        TelephonyManager tm = (TelephonyManager) context.getSystemService(Context.TELEPHONY_SERVICE);
       if (tm == null) {
           return "";
       }
       return "" + tm.getDeviceId();
   }

	/**
	 * 获取MAC地址，注意：手机重启，mac地址为null；
	 * 
	 * @param context
	 * @return mac地址；
	 */
	public static String getMac(Context context) {
		if (context != null) {
			WifiManager wifi = (WifiManager) context
					.getSystemService(Context.WIFI_SERVICE);
			WifiInfo info = wifi.getConnectionInfo();
			return info.getMacAddress();
		} else {
			return "";
		}
	}

2.获取token

app进入app时要先获取token，获取token的时候我们要给服务端传递当前设备的设备号，当我们换了设备后设备号变了，返回的token值也就变了，那么原设备的token相对来说就失效了，当在原设备和服务端有交互的时候就会返回token失效，用户登陆注销等要及时更新token值。

3.请求交互携带token

每次客户端和服务端有任何交互的时候都要传递这个token参数，当我们在另一台设备登录的时候原设备上存的token就失效了，因为数据库里面当前用户的token已经在新设备获取toekn的时候覆盖了，这样原设备请求时就会提示token失效了。

4.根据服务端返回码处理逻辑

事先客户端和服务端要约定好一个code码，例如：我们约定返回码为99的时候代表token失效，那么当我们请求服务端返回值为99的时候就要提示 您的登陆状态失效，请您重新登陆。

switch (code) {
    case 1:
      break;
    case 99://被踢下线
      //Do Something
      break;
    }

上面说了自己用自己的业务系统实现app单点的基本流程。

其实还有一种情况，我们不用自己做这些工作，就是我们集成了三方的即时通讯sdk，比如 环信sdk，腾讯云通讯sdk。这些都是有自己的监听用户状态的机制的，可以找到对应得监听直接加入自己的业务处理逻辑。

开发一群：454430053开发二群：537532956

package com.farmlink.most.util;


import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.regex.Matcher;
import java.util.regex.Pattern;


import android.net.ParseException;
import android.text.TextUtils;


/**
 * 参数校验
 */
public class ValidateParam {


	/**
	 * 校验用户名判断：头部尾部不能使空格，不能是中文，不能使全角，不能有星号，长度6-16 其实 中文 和 全角 的 new
	 * String(charStr.getBytes("UTF-8"),"8859_1").getBytes().length=6
	 * 字母、数字、特殊符号new
	 * String(charStr.getBytes("UTF-8"),"8859_1").getBytes().length=1
	 */
	public static boolean validateUserName(String username) {
		/**
		 * 长度6-16
		 */
		if (!((username.length() >= 6) && (username.length() <= 16))) {
			return false;
		}
		/**
		 * 头部不能有空格
		 */
		if (username.substring(0, 1).equals(" ")) {// 头部有空格
			System.out.println(33);
			return false;
		}
		/**
		 * 未部不能有空格
		 */
		if (username.endsWith(" ")) {// 未部有空格
			return false;
		}
		if (username.contains(" ")) {// 不能含有
			return false;
		}
		/**
		 * 不能有中文
		 */
		Pattern pattern1 = Pattern.compile("[^\\u4E00-\\u9FA5]*"); // 不是中文
		Matcher m1 = pattern1.matcher(username);
		if (!m1.matches()) {
			return false;
		}
		/**
		 * 不能有*号
		 */
		pattern1 = Pattern.compile("[^\\*]*"); // 不是*号
		m1 = pattern1.matcher(username);
		if (!m1.matches()) {
			return false;
		}


		/**
		 * 不能是纯数字
		 */
		pattern1 = Pattern.compile("^[1-9]\\d*$");
		m1 = pattern1.matcher(username);
		return !m1.matches();
	}


	/**
	 * 校验用户密码：字母，数字，特殊字符，至少两种，6-16个字符
	 */
	public static boolean validateUserPassword(String passport) {
		Pattern pattern1 = Pattern.compile("[0-9]*"); // 数字[0-9]+?
		Matcher m1 = pattern1.matcher(passport);
		pattern1 = Pattern.compile(".*[a-zA-Z].*"); // 字母
		Matcher m2 = pattern1.matcher(passport);
		pattern1 = Pattern.compile(".*[^a-zA-Z0-9].*"); // 非字母和数字
		Matcher m3 = pattern1.matcher(passport);
		pattern1 = Pattern.compile("[^\\u4E00-\\u9FA5]*"); // 不是中文
		Matcher m4 = pattern1.matcher(passport);
		// 长度6-16
		if (!((passport.length() >= 6) && (passport.length() <= 16))) {
			return true;
		}
		/**
		 * 纯数字
		 */
		if (m1.matches()) {
			return true;
		}
		/**
		 * 必须是：字母和数字
		 **/
		if (m1.matches() && m2.matches() && m4.matches()) {
			return true;
		}
		/**
		 * 必须是：数字和特殊符号
		 **/
		if (m1.matches() && m3.matches() && m4.matches()) {
			return true;
		}
		/**
		 * 必须是：字母和特殊符号
		 **/
		return m2.matches() && m3.matches() && m4.matches();
	}


	public static int validateUserPasswords(String passport) {
		passport = new String(passport.getBytes());
		java.util.regex.Pattern pattern2 = java.util.regex.Pattern.compile("[\u4e00-\u9fa5]+");
		java.util.regex.Matcher match2 = pattern2.matcher(passport);
		if (match2.find() == true) {
			return 1;
		}


		java.util.regex.Pattern pattern3 = java.util.regex.Pattern.compile("[\\s\u4e00-\u9fa5]");
		java.util.regex.Matcher match3 = pattern3.matcher(passport);
		if (match3.find() == true) {
			return 2;
		}


		java.util.regex.Pattern pattern4 = java.util.regex.Pattern.compile("\\*");
		java.util.regex.Matcher match4 = pattern4.matcher(passport);
		if (match4.find()) {
			return 3;
		}


		return 0;
	}


	/**
	 * 校验手机
	 */
	public static boolean validatePhone(String phone) {
		Pattern pattern1 = Pattern.compile("^1[34578]\\d{9}$");
		Matcher m1 = pattern1.matcher(phone);
		return m1.matches();
	}


	/**
	 * 校验邮箱
	 */
	public static boolean validateEmail(String email) {
		Pattern pattern = Pattern.compile(
				"^([a-zA-Z0-9_\\-\\.]+)@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.)|(([a-zA-Z0-9\\-]+\\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\\]?)$");
		Matcher matcher = pattern.matcher(email);
		return matcher.matches();
	}
	
	
	/** 
     * 判断字段是否为身份证 符合返回ture 
     * @param str 
     * @return boolean 
     */
    public static  boolean isIdCard(String str) {  
        /** 
         * 身份证正则表达式 
         */
       String IDCARD="((11|12|13|14|15|21|22|23|31|32|33|34|35|36|37|41|42|43|44|45|46|50|51|52|53|54|61|62|63|64|65)[0-9]{4})" +  
                                            "(([1|2][0-9]{3}[0|1][0-9][0-3][0-9][0-9]{3}" +  
                                            "[Xx0-9])|([0-9]{2}[0|1][0-9][0-3][0-9][0-9]{3}))";
        if(TextUtils.isEmpty(str)) return false ;  
        if(str.trim().length() == 15 || str.trim().length() == 18) {  
                return Regular(str,IDCARD);  
        }else {  
            return false ;  
        }  
    }  
    
    /** 
     * 判断字段是否为邮编 符合返回ture 
     * @param str 
     * @return boolean 
     */
    public static  boolean isCode(String str) {  
        /** 
         * 邮编正则表达式  [0-9]\d{5}(?!\d) 国内6位邮编 
         */
    	String CODE="[0-9]\\d{5}(?!\\d)";    
        return Regular(str,CODE) ;  
    }  
    
    /** 
     * 匹配是否符合正则表达式pattern 匹配返回true 
     * @param str 匹配的字符串 
     * @param pattern 匹配模式 
     * @return boolean 
     */
    private static  boolean Regular(String str,String pattern){  
        if(null == str || str.trim().length()<=0)  
            return false;           
        Pattern p = Pattern.compile(pattern);  
        Matcher m = p.matcher(str);  
        return m.matches();  
    }  
}

欢迎大家加入我的qq群：开发一群：454430053开发二群：537532956

报错信息

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:installDebug'.
> com.android.builder.testing.api.DeviceException: com.android.ddmlib.InstallException: Failed to finalize session :
INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package com.xxx signatures do not match the previously installed version; ignoring!

报错原因

不同平台开发的切换，在原手机上还有之前的安装包，在不同平台上安装应用，都会对应一个签名。比如：从mac到win上的切换或者win到mac上的切换，在切换之前，手机上已经打包了之前平台的应用，那么在新平台上重新安装就会报上这个错误。

解决方案

• 手动卸载之前应用，在新平台上重新安装。

• 或者使用adb命令来卸载： $ adb uninstall <packageName>

参考

• https://github.com/facebook/react-native/pull/14577/files

各位看官们，大家好，上一回中咱们说的是Android中Activity的例子，这一回咱们说的例子是Android中的Fragment。闲话休提， 言归正转。让我们一起Talk Android吧！

看官们，我们在前面几个章回中介绍了Activity的内容，在接下来的几个章回中，我们将介绍Fragment相关的内容。现在就让我们一起去看看Fragment吧。

Fragment是一种UI组件，它有点类似Activity，最初的Android版本中并没有该组件，在Android3.0后才引入了该组件，引入的目的是为了让手机上的应用程序兼容平板上的应用程序，因此开发平板上应用程序的时候经常使用它。通俗点说，就是让同一个应用程序既能在手机上运行，又能在平板上运行，而且让用户感觉不到差异。有看官说了：同一应用在手机和平板上运行有差别吗？回答是肯定的，从功能方面来看，几乎没有差别，但是从UI界面上看差别就很大了。大家都知道平板的屏幕比手机大的多，所以应用的UI会有差别。

现在Android已经发布8.0版本了，手机也是日新月异地变化，除了硬件不断地升级外，屏幕也在不断地变大，因此手机和平板的差异也在缩小，Fragment被大量使用在手机应用中，这和最初引入它的目的有点不同。不过这也阻挡不了它的广泛使用。

说了这么多，让我们看看Fragment到底是一个什么东东。它是一种可以嵌入到Activity中的UI组件，它也有自己的布局文件和程序逻辑。因为是嵌入到Activity中的UI组件，因此它使用十分灵活，这也是大家喜欢它的原因。当然，嵌入后也有缺点，那就是它的存在依赖于Activity，如果Activity销毁了，它也会随着Activity一起灰飞烟灭。

看官们，关于Fragment的布局大家可以参考前面章回中关于“Activity布局文件”的介绍，它们几乎是一样的。因此，这里就不再详细介绍了，不过，我们还会给一个整体的总结：首先是定义布局文件（xml类型的文件），然后是在添加其它的UI控件到布局文件中，比如常见的Button和Textview等。至于Fragment的程序逻辑，它和Activity类似，但是有部分不同的内容，我们在后面的章回中再做详细的介绍。

看官们，今天算是让Fragment做一个了简单概要的开场白，希望大家能够对它有一个基本的了解，接下来的几个章回，我们会更加详细地介绍它。

各位看官，关于Android中Fragment的例子咱们就介绍到这里，欲知后面还有什么例子，且听下回分解！

CGRectInset 与 CGRectOffset 都是通过参数改变CGRect并返回一个CGRect类型的数据。总结出两者的区别在于：CGRectInset会进行平移和缩放两个操作。CGRectOffset做的只是平移。

先把苹果的官方文档做简要解释：

CGRect CGRectInset(CGRect rect, CGFloat dx, CGFloat dy)：

通过第二个参数 dx 和第三个参数 dy 重置第一个参数 rect 作为结果返回。重置的方式为，首先将 rect 的坐标（origin）按照(dx,dy) 进行平移，然后将 rect 的大小（size） 宽度缩小2倍的 dx，高度缩小2倍的 dy。

CGRect CGRectOffset(CGRect rect, CGFloat dx, CGFloat dy)：

rect 按照（dx,dy）进行平移。

两者的具体效果如何呢？下面通过代码和程序运行结果做形象解释。

-(void)testCGRectInset
{
    UIView *view1=[[UIView alloc]initWithFrame:CGRectMake(100, 100, 200, 200)];
    [view1 setBackgroundColor:[UIColor yellowColor]];//view1 设置为黄色
    [self.view addSubview:view1];

    //根据view1的大小变换后创建view2;
    CGRect view2Rect=CGRectInset(view1.frame, 20, 20);
    UIView *view2=[[UIView alloc]initWithFrame:view2Rect];
    [view2 setBackgroundColor:[UIColor redColor]];//view2 设置为红色
    [self.view addSubview:view2];
}

如下图左边第一个所示，红色视图首先按照我们给的参数做了平移 然后对大小做了缩放。这里我给的参数是正数，如果换成负数，则向反方向平移并做放大，如下图第二张所示，视图层级关系如图第三张。

同样的思路，对于 CGRectOffset ，有：

-(void)testCGRectOffset
{
    UIView *view1=[[UIView alloc]initWithFrame:CGRectMake(100, 100, 200, 200)];
    [view1 setBackgroundColor:[UIColor yellowColor]];//view1 设置为黄色
    [self.view addSubview:view1];

    //根据view1的大小变换后创建view2;
    CGRect view2Rect=CGRectOffset(view1.frame, 20, 20);
    UIView *view2=[[UIView alloc]initWithFrame:view2Rect];
    [view2 setBackgroundColor:[UIColor redColor]];//view2 设置为红色
    [self.view addSubview:view2];
}

运行结果如下所示（包括参数是正数和负数两种情况）：

由上图可以形象地看出，该方法只是做了平移操作，没有缩放。

在上一篇文章中，我们完成了聊天列表的用户界面与功能代码。在用户添加完会话后，聊天列表会增加对应的会话项，通过点击会话项，可以进入聊天屏幕。在这一篇文章中，我们主要是修改lib/chat_screen.dart的代码，也就是最早的聊天屏幕。

首先打开lib/chat_screen.dart，在ChatScreen中添加五个参数，messages是会话对应的消息列表，myName和sheName是会话双方的名称，myPhone和shePhone则是双方的手机号码，也是唯一标识符。我们需要这些参数来将发送的消息写入到双方的数据节点。

class ChatScreen extends StatefulWidget {
  ChatScreen(
      {this.messages, this.myName, this.sheName, this.myPhone, this.shePhone});
  final String messages;
  final String myName;
  final String sheName;
  final String myPhone;
  final String shePhone;

  @override
  State createState() => new ChatScreenState(messages);
}

接下来在ChatScreenState中添加两个数据库连接，chatsReference连接会话列表，messagesReference连接具体每一个会话中的信息。还有一个ScaffoldState类型的GlobalKey变量，是用来控制聊天屏幕的脚手架（Scaffold）的状态，比如在底部显示提示信息。

class ChatScreenState extends State<ChatScreen> {
  ChatScreenState(this._messages);
  final String _messages;

  static final GlobalKey<ScaffoldState> _scaffoldKey = new GlobalKey<ScaffoldState>();
  final TextEditingController _textController = new TextEditingController();
  final chatsReference = FirebaseDatabase.instance.reference().child('chats');
  final messagesReference = FirebaseDatabase.instance.reference().child('messages');
  bool _isComposing = false;
  //...
}

我们再修改一下ChatScreenState中的_sendMessage方法，会话的一方只要发送了一条消息，就会更新双方的聊天列表中，显示最新的消息内容与消息发送的时间。这里保存的最新时间，是聊天列表排序的依据，这样聊天列表就会以消息的更新时间排序。

class ChatScreenState extends State<ChatScreen> {
  //...
  void _sendMessage({String text, String imageUrl}) {
    String time = new DateTime.now().toString();
    messagesReference.child(_messages).push().set({
      'text': text,
      'imageUrl': imageUrl,
      'senderName': widget.myName,
      'timestamp': time
    });
    chatsReference
        .child('${widget.shePhone}/${widget.myPhone}/lastMessage')
        .set(text);
    chatsReference
        .child('${widget.shePhone}/${widget.myPhone}/timestamp')
        .set(time);
    chatsReference
        .child('${widget.myPhone}/${widget.shePhone}/lastMessage')
        .set(text);
    chatsReference
        .child('${widget.myPhone}/${widget.shePhone}/timestamp')
        .set(time);
  }
  //...
}

在聊天屏幕的右上方，我们需要增加一个弹出菜单，使用PopupMenuButton控件，在标题栏右方增加一个按钮，点击即可弹出选项菜单，更多关于弹出菜单按钮的内容，可以查看《Flutter进阶—质感设计之弹出菜单》。当用户点击删除选项时，会话双方的activate都将被设置成false，表示这个会话已经无效。

class ChatScreenState extends State<ChatScreen> {
  //...
  @override
  Widget build(BuildContext context) {
    return new Scaffold(
      key: _scaffoldKey,
      appBar: new AppBar(
          title: new Text(widget.sheName),
          centerTitle: true,
          elevation: 1.0,
          actions: <Widget>[
            new PopupMenuButton<String>(
                onSelected: (String value) {
                  if (value == "delete") {
                    chatsReference
                        .child('${widget.shePhone}/${widget.myPhone}/activate')
                        .set("false");
                    chatsReference
                        .child('${widget.myPhone}/${widget.shePhone}/activate')
                        .set("false");
                    _scaffoldKey.currentState.showSnackBar(new SnackBar(
                      content: new Text("删除成功！"),
                    ));
                  }
                },
                itemBuilder: (BuildContext context) => <PopupMenuItem<String>>[
                      new PopupMenuItem<String>(
                          value: "delete", child: new Text('删除会话')),
                    ])
          ]),
      body: new Stack(children: <Widget>[
        //...
      ]),
    );
  }
}

当会话已经被被设置为无效状态时，应用程序不会自动返回到聊天列表屏幕，因此当用户再次发送消息时，我们应该提示用户该会话已经被删除。修改一下ChatScreenState中的_handleSubmitted方法，在发送消息之前先判断当前会话是否有效，有效时调用_sendMessage方法发送消息，无效则使用脚手架来显示提示信息。

class ChatScreenState extends State<ChatScreen> {
  //...
  Future _handleSubmitted(String text) async {
    chatsReference
        .child('${widget.myPhone}/${widget.shePhone}/activate')
        .onValue
        .listen((Event event) {
      if (event.snapshot.value == "false") {
        _scaffoldKey.currentState.showSnackBar(new SnackBar(
          content: new Text("会话已经被删除了哦！"),
        ));
      } else {
        if (text.trim() == "") return;
        _textController.clear();
        _isComposing = false;
        _sendMessage(text: text);
      }
    });
  }
  //...
}

关于聊天屏幕的更多样式修改，可以查看chat_screen.dart文件了解详情。现在我们打开group_chat_list_body.dart文件，修改一下_GroupChatListBodyState的build方法，当会话为无效时，不显示该会话。

class _GroupChatListBodyState extends State<GroupChatListBody> {
  //...
  @override
  Widget build(BuildContext context) {
    return new FirebaseAnimatedList(
      //...
      itemBuilder: (BuildContext context, DataSnapshot snapshot,
          Animation<double> animation) {
        return new SizeTransition(
          sizeFactor: animation,
          child: snapshot.value["activate"] == "false"
              ? null
              : new GroupChatListBodyItem(
                  //...
                ),
        );
      },
    );
  }
}

前言

• Android开发中，类似下图的搜索功能非常常见

• 今天，我将手把手教大家实现一款 封装了 历史搜索记录功能 & 样式 的Android 自定义搜索框 开源库，希望你们会喜欢。

已在Github开源：地址：SearchView，欢迎 Star ！

目录

1. 简介

一款封装了 历史搜索记录功能 & 样式 的Android自定义搜索框

已在Github开源：地址：SearchView，欢迎 Star ！

2. 需求场景

• 在开始coding前， 理解好用户的需求场景 有助于我们更好地设计 & 实现功能
• 需求场景如下

3. 业务流程图

根据场景，梳理出来的功能业务流程图如下：

4. 功能需求

根据功能的业务流程图，得出功能需求如下

4.1 功能列表

4.2 功能原型图

4.3 示意图

5. 总体设计

下面，将根据功能需求给出特定的技术解决方案

5.1 总体解决方案

5.2 项目结构说明

• 项目工程示意图

先下载Demo再阅读，效果会更好：Carson_Ho的Github地址：Search_Layout

• 结构说明

6. 功能详细设计

下面将给出详细的功能逻辑

6.1 关键字搜索

• 描述：根据用户输入的搜索字段进行结果搜索
• 原型图
  

  注：关键字搜索功能是因人而异的，所以本源码仅留出接口供开发者实现，不作具体实现

• 源码分析

分析1：EditText_Clear.java

• 作用：自定义EdiText，与系统自带的EdiText对比：多了左侧图片 & 右侧图片设置、一键清空EdiText内容功能
• 具体代码如下：

public class EditText_Clear extends android.support.v7.widget.AppCompatEditText {
    /**
     * 步骤1：定义左侧搜索图标 & 一键删除图标
     */
    private Drawable clearDrawable,searchDrawable;

    public EditText_Clear(Context context) {
        super(context);
        init();
        // 初始化该组件时，对EditText_Clear进行初始化 ->>步骤2
    }

    public EditText_Clear(Context context, AttributeSet attrs) {
        super(context, attrs);
        init();
    }

    public EditText_Clear(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
        init();
    }

    /**
     * 步骤2：初始化 图标资源
     */
    private void init() {
        clearDrawable = getResources().getDrawable(R.drawable.delete);
        searchDrawable = getResources().getDrawable(R.drawable.search);

        setCompoundDrawablesWithIntrinsicBounds(searchDrawable, null,
                null, null);
        // setCompoundDrawablesWithIntrinsicBounds(Drawable left, Drawable top, Drawable right, Drawable bottom)介绍
        // 作用：在EditText上、下、左、右设置图标（相当于android:drawableLeft=""  android:drawableRight=""）
        // 注1：setCompoundDrawablesWithIntrinsicBounds（）传入的Drawable的宽高=固有宽高（自动通过getIntrinsicWidth（）& getIntrinsicHeight（）获取）
        // 注2：若不想在某个地方显示，则设置为null
        // 此处设置了左侧搜索图标

        // 另外一个相似的方法：setCompoundDrawables(Drawable left, Drawable top, Drawable right, Drawable bottom)介绍
        // 与setCompoundDrawablesWithIntrinsicBounds（）的区别：可设置图标大小
          // 传入的Drawable对象必须已经setBounds(x,y,width,height)，即必须设置过初始位置、宽和高等信息
          // x:组件在容器X轴上的起点 y:组件在容器Y轴上的起点 width:组件的长度 height:组件的高度
    }


    /**
     * 步骤3：通过监听复写EditText本身的方法来确定是否显示删除图标
     * 监听方法：onTextChanged（） & onFocusChanged（）
     * 调用时刻：当输入框内容变化时 & 焦点发生变化时
     */

    @Override
    protected void onTextChanged(CharSequence text, int start, int lengthBefore, int lengthAfter) {
        super.onTextChanged(text, start, lengthBefore, lengthAfter);
        setClearIconVisible(hasFocus() && text.length() > 0);
        // hasFocus()返回是否获得EditTEXT的焦点，即是否选中
        // setClearIconVisible（） = 根据传入的是否选中 & 是否有输入来判断是否显示删除图标->>关注1
    }

    @Override
    protected void onFocusChanged(boolean focused, int direction, Rect previouslyFocusedRect) {
        super.onFocusChanged(focused, direction, previouslyFocusedRect);
        setClearIconVisible(focused && length() > 0);
        // focused = 是否获得焦点
        // 同样根据setClearIconVisible（）判断是否要显示删除图标
    }

    /**
     * 关注1
     * 作用：判断是否显示删除图标
     */
    private void setClearIconVisible(boolean visible) {
        setCompoundDrawablesWithIntrinsicBounds(searchDrawable, null,
                visible ? clearDrawable : null, null);
    }

    /**
     * 步骤4：对删除图标区域设置点击事件，即"点击 = 清空搜索框内容"
     * 原理：当手指抬起的位置在删除图标的区域，即视为点击了删除图标 = 清空搜索框内容
     */
    @Override
    public boolean onTouchEvent(MotionEvent event) {
        switch (event.getAction()) {
            // 原理：当手指抬起的位置在删除图标的区域，即视为点击了删除图标 = 清空搜索框内容
            case MotionEvent.ACTION_UP:
                Drawable drawable = clearDrawable;
                if (drawable != null && event.getX() <= (getWidth() - getPaddingRight())
                        && event.getX() >= (getWidth() - getPaddingRight() - drawable.getBounds().width())) {
                    setText("");
                }
                // 判断条件说明
                // event.getX() ：抬起时的位置坐标
                // getWidth()：控件的宽度
                // getPaddingRight():删除图标图标右边缘至EditText控件右边缘的距离
                // 即：getWidth() - getPaddingRight() = 删除图标的右边缘坐标 = X1
                // getWidth() - getPaddingRight() - drawable.getBounds().width() = 删除图标左边缘的坐标 = X2
                // 所以X1与X2之间的区域 = 删除图标的区域
                // 当手指抬起的位置在删除图标的区域（X2=<event.getX() <=X1），即视为点击了删除图标 = 清空搜索框内容
                // 具体示意图请看下图
                break;
        }
        return super.onTouchEvent(event);
    }


}

对于含有一键清空功能 & 更多自定义样式的EditText自定义控件具体请看我的另外一个简单 & 好用的开源组件：Android自定义EditText：手把手教你做一款含一键删除&自定义样式的SuperEditText

分析2：SearchListView.java

• 作用：解决 ListView & ScrollView 的嵌套冲突
• 具体代码如下：

public class Search_Listview extends ListView {
    public Search_Listview(Context context) {
        super(context);
    }

    public Search_Listview(Context context, AttributeSet attrs) {
        super(context, attrs);
    }

    public Search_Listview(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);
    }

    // 通过复写其onMeasure方法，达到对ScrollView适配的效果
    @Override
    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
        int expandSpec = MeasureSpec.makeMeasureSpec(Integer.MAX_VALUE >> 2,
                MeasureSpec.AT_MOST);
        super.onMeasure(widthMeasureSpec, expandSpec);
    }

}

分析3： search_layout.xml

• 作用：搜索框的布局
• 具体代码如下：

<?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"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:focusableInTouchMode="true"
    android:orientation="vertical">

    <LinearLayout
        android:id="@+id/search_block"
        android:layout_width="match_parent"
        android:layout_height="10dp"
        android:orientation="horizontal"
        android:paddingRight="10dp"
        >

        // 返回按钮
        <ImageView
            android:layout_width="38dp"
            android:layout_height="38dp"
            android:layout_gravity="center_vertical"
            android:padding="10dp"
            android:src="@drawable/back" />

        // 搜索框（采用上面写的自定义EditText
        <scut.carson_ho.searchview.EditText_Clear
            android:id="@+id/et_search"
            android:layout_width="0dp"
            android:layout_height="fill_parent"
            android:layout_weight="264"
            android:background="@null"
            android:drawablePadding="8dp"
            android:gravity="start|center_vertical"
            android:imeOptions="actionSearch"
            android:singleLine="true"
            // 最后2行 = 更换输入键盘按钮：换行 ->>搜索
            />

    </LinearLayout>

    // 下方搜索记录布局 = ScrollView+Listview
    <ScrollView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content">

        <LinearLayout
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:orientation="vertical">

                // Listview布局（采用上述讲解的SearchListView，解决了与ScrollView的冲突）
                <scut.carson_ho.searchview.SearchListView
                    android:id="@+id/listView"
                    android:layout_width="match_parent"
                    android:layout_height="wrap_content">

                </scut.carson_ho.searchview.SearchListView>

            <TextView
                android:id="@+id/tv_clear"
                android:layout_width="match_parent"
                android:layout_height="40dp"
                android:background="#F6F6F6"
                android:gravity="center"
                android:visibility="invisible"
                android:text="清除搜索历史" />
        </LinearLayout>
    </ScrollView>
</LinearLayout>

分析4：ICallBack.java、bCallBack.java

• 作用：搜索按键、返回按键回调接口
• 具体代码如下：

/**
 * ICallBack.java
 */
public interface ICallBack {
    void SearchAciton(String string);

}

/**
 * bCallBack.java
 */
public interface bCallBack {
    void BackAciton();
}

分析5：SearchView.java

• 作用：涵盖搜索框中所有功能，此处主要讲解 关键字搜索 功能实现
• 具体代码如下：

/**
   * 步骤1：初始化成员变量
   */

    // 搜索框组件
    private EditText et_search; // 搜索按键
    private LinearLayout search_block; // 搜索框布局
    private ImageView searchBack; // 返回按键

    // 回调接口
    private  ICallBack mCallBack;// 搜索按键回调接口
    private  bCallBack bCallBack; // 返回按键回调接口

    // ListView列表 & 适配器
    private SearchListView listView;
    private BaseAdapter adapter;

   /**
     * 步骤2：绑定 搜索框 组件
     */

    private void initView(){

        // 1. 绑定R.layout.search_layout作为搜索框的xml文件
        LayoutInflater.from(context).inflate(R.layout.search_layout,this);

        // 2. 绑定搜索框EditText
        et_search = (EditText) findViewById(R.id.et_search);

        // 3. 搜索框背景颜色
        search_block = (LinearLayout)findViewById(R.id.search_block);

        // 4. 历史搜索记录 = ListView显示
        listView = (Search_Listview) findViewById(R.id.listView);

        // 5. 删除历史搜索记录 按钮
        tv_clear = (TextView) findViewById(R.id.tv_clear);
        tv_clear.setVisibility(INVISIBLE); // 初始状态 = 不可见

    }

/**
    * 步骤3
    * 监听输入键盘更换后的搜索按键
    * 调用时刻：点击键盘上的搜索键时
    */
        et_search.setOnKeyListener(new View.OnKeyListener() {
            public boolean onKey(View v, int keyCode, KeyEvent event) {
                if (keyCode == KeyEvent.KEYCODE_ENTER && event.getAction() == KeyEvent.ACTION_DOWN) {

                    // 点击搜索按键后，根据输入的搜索字段进行查询
                    // 注：由于此处需求会根据自身情况不同而不同，所以具体逻辑由开发者自己实现，此处仅留出接口
                    if (!(mCallBack == null)){
                        mCallBack.SearchAciton(et_search.getText().toString());
                    }
                    Toast.makeText(context, "需要搜索的是" + et_search.getText(), Toast.LENGTH_SHORT).show();


                }
                return false;
            }
        });

 /**
     * 步骤4：回调接口
     */

// 搜索按键回调接口
public interface ICallBack {
    void SearchAciton(String string);
}

// 返回按键接口回调
    public void setOnClickBack(bCallBack bCallBack){
        this.bCallBack = bCallBack;

    }

6.2 实时显示历史搜索记录

• 描述：包括 最近搜索记录 & 相似搜索记录
• 原型图

• 源码分析

分析1：RccordSQLiteOpenHelper.java

• 作用：创建、管理数据库 & 版本控制

  该数据库用于存储用户的搜索历史记录

• 具体代码如下：

  对于Android SQLlite数据库的操作请看文章：Android：SQLlite数据库操作最详细解析

// 继承自SQLiteOpenHelper数据库类的子类
public class RecordSQLiteOpenHelper extends SQLiteOpenHelper {

    private static String name = "temp.db";
    private static Integer version = 1;

    public RecordSQLiteOpenHelper(Context context) {
        super(context, name, null, version);
    }

    @Override
    public void onCreate(SQLiteDatabase db) {
        // 打开数据库 & 建立一个名为records的表，里面只有一列name来存储历史记录：
        db.execSQL("create table records(id integer primary key autoincrement,name varchar(200))");
    }

    @Override
    public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {
    }
}

分析2：SearchView.java

• 作用：涵盖搜索框中所有功能，此处主要讲解 实时显示历史搜索记录 功能实现
• 具体代码如下：

   /**
     * 步骤1：初始化变量
     */
    // 用于存放历史搜索记录
    private RecordSQLiteOpenHelper helper ;
    private SQLiteDatabase db;

    // ListView列表 & 适配器
    private SearchListView listView;
    listView = (SearchListView) findViewById(R.id.listView);
    private BaseAdapter adapter;

    // 实例化数据库SQLiteOpenHelper子类对象
    helper = new RecordSQLiteOpenHelper(context);

/**
  * 步骤2：搜索框的文本变化实时监听
  */
        et_search.addTextChangedListener(new TextWatcher() {
            @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) {
                // 每次输入后，模糊查询数据库 & 实时显示历史搜索记录
                // 注：若搜索框为空,则模糊搜索空字符 = 显示所有的搜索历史
                String tempName = et_search.getText().toString();
                queryData(tempName); // ->>关注1

            }
        });

/**
   * 步骤3：搜索记录列表（ListView）监听
   * 即当用户点击搜索历史里的字段后,会直接将结果当作搜索字段进行搜索
   */
        listView.setOnItemClickListener(new AdapterView.OnItemClickListener() {
            @Override
            public void onItemClick(AdapterView<?> parent, View view, int position, long id) {

                // 获取用户点击列表里的文字,并自动填充到搜索框内
                TextView textView = (TextView) view.findViewById(android.R.id.text1);
                String name = textView.getText().toString();
                et_search.setText(name);
                Toast.makeText(context, name, Toast.LENGTH_SHORT).show();
            }
        });


/**
   * 关注1
   * 模糊查询数据 & 显示到ListView列表上
   */
    private void queryData(String tempName) {

        // 1. 模糊搜索
        Cursor cursor = helper.getReadableDatabase().rawQuery(
                "select id as _id,name from records where name like '%" + tempName + "%' order by id desc ", null);
        // 2. 创建adapter适配器对象 & 装入模糊搜索的结果
        adapter = new SimpleCursorAdapter(context, android.R.layout.simple_list_item_1, cursor, new String[] { "name" },
                new int[] { android.R.id.text1 }, CursorAdapter.FLAG_REGISTER_CONTENT_OBSERVER);
        // 3. 设置适配器
        listView.setAdapter(adapter);
        adapter.notifyDataSetChanged();

        System.out.println(cursor.getCount());
        // 当输入框为空 & 数据库中有搜索记录时，显示 "删除搜索记录"按钮
        if (tempName.equals("") && cursor.getCount() != 0){
            tv_clear.setVisibility(VISIBLE);
        }
        else {
            tv_clear.setVisibility(INVISIBLE);
        };

    }

6.3 删除历史搜索记录

• 描述：清空所有历史搜索记录
• 原型图

• 源码分析

  /**
     * 步骤1：初始化变量
     */
      private TextView tv_clear;  // 删除搜索记录按键
      tv_clear = (TextView) findViewById(R.id.tv_clear);
      tv_clear.setVisibility(INVISIBLE);// 初始状态 = 不可见

/**
  * 步骤2：设置"清空搜索历史"按钮
  */
        tv_clear.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {

                // 清空数据库->>关注2
                deleteData();
                // 模糊搜索空字符 = 显示所有的搜索历史（此时是没有搜索记录的） & 显示该按钮的条件->>关注3
                queryData("");
            }
        });

/**
  * 关注2：清空数据库
  */
    private void deleteData() {

        db = helper.getWritableDatabase();
        db.execSQL("delete from records");
        db.close();
        tv_clear.setVisibility(INVISIBLE);
    }

 /**
     * 关注3
     * 模糊查询数据、显示到ListView列表上 & 确定显示 “删除历史按钮”条件
     */
    private void queryData(String tempName) {
        // 步骤1、2、3上面已经提到了，直接看步骤4
        // 1. 模糊搜索
        Cursor cursor = helper.getReadableDatabase().rawQuery(
                "select id as _id,name from records where name like '%" + tempName + "%' order by id desc ", null);
        // 2. 创建adapter适配器对象 & 装入模糊搜索的结果
        adapter = new SimpleCursorAdapter(context, android.R.layout.simple_list_item_1, cursor, new String[] { "name" },
                new int[] { android.R.id.text1 }, CursorAdapter.FLAG_REGISTER_CONTENT_OBSERVER);
        // 3. 设置适配器
        listView.setAdapter(adapter);
        adapter.notifyDataSetChanged();

        // 4. 当输入框为空 & 数据库中有搜索记录时，才显示 "删除搜索记录"按钮
        if (tempName.equals("") && cursor.getCount() != 0){
            tv_clear.setVisibility(VISIBLE);
        }
        else {
            tv_clear.setVisibility(INVISIBLE);
        };

    }

6.4 保存历史搜索记录

• 描述：将用户输入的搜索字段保存到数据库中
• 原型图

• 源码分析

/**
  * 监听输入键盘更换后的搜索按键
  * 调用时刻：点击键盘上的搜索键时
  */
        et_search.setOnKeyListener(new View.OnKeyListener() {
            public boolean onKey(View v, int keyCode, KeyEvent event) {
                if (keyCode == KeyEvent.KEYCODE_ENTER && event.getAction() == KeyEvent.ACTION_DOWN) {
                    // 步骤1已经讲解过，直接看步骤2

                    // 1. 点击搜索按键后，根据输入的搜索字段进行查询
                    // 注：由于此处需求会根据自身情况不同而不同，所以具体逻辑由开发者自己实现，此处仅留出接口
                    if (!(mCallBack == null)){
                     mCallBack.SearchAciton(et_search.getText().toString());
                    }
                    Toast.makeText(context, "需要搜索的是" + et_search.getText(), Toast.LENGTH_SHORT).show();

                    // 2. 点击搜索键后，对该搜索字段在数据库是否存在进行检查（查询）->> 关注3
                    boolean hasData = hasData(et_search.getText().toString().trim());
                    // 3. 若存在，则不保存；若不存在，则将该搜索字段保存（插入）到数据库，并作为历史搜索记录
                    if (!hasData) {
                        insertData(et_search.getText().toString().trim()); // ->>关注4
                        queryData("");
                    }
                }
                return false;
            }
        });

/**
  * 关注3
  * 检查数据库中是否已经有该搜索记录
  */
    private boolean hasData(String tempName) {
        // 从数据库中Record表里找到name=tempName的id
        Cursor cursor = helper.getReadableDatabase().rawQuery(
                "select id as _id,name from records where name =?", new String[]{tempName});
        //  判断是否有下一个
        return cursor.moveToNext();
    }

/**
  * 关注4
  * 插入数据到数据库，即写入搜索字段到历史搜索记录
  */
    private void insertData(String tempName) {
        db = helper.getWritableDatabase();
        db.execSQL("insert into records(name) values('" + tempName + "')");
        db.close();
    }

• 至此，关于搜索框的全部源码讲解完毕。
• 完整源代码请看：Carson_Ho的Github地址：SearchView

7. 具体使用

• 具体请看文章：Android开源库：这里有一个简单好用、含历史搜索记录的搜索框
• 完整Demo地址：Carson_Ho的Github地址：SearchView

8. 贡献代码

• 希望你们能和我一起完善这款简单 & 好用的SearchView控件，具体请看：贡献说明
• 关于该开源项目的意见 & 建议可在Issue上提出。欢迎 Star ！

9. 总结

• 相信你一定会喜欢上 这款简单 & 好用的SearchView控件

  已在Github上开源：SearchView，欢迎 Star ！

• 下一篇文章我将继续进行一些有趣的自定义View实例讲解，有兴趣可以继续关注Carson_Ho的安卓开发笔记

  更多简单好用的开源库：简单 & 好用的开源组件：
  自定义EditText：手把手教你做一款含一键删除&自定义样式的SuperEditText

请 帮顶 或 评论点赞！因为你的鼓励是我写作的最大动力！

Realm数据库, 目前有Java, Objective‑C, React Native, Swift, Xamarin的几种实现, 是一套用来取代SQLite的解决方案.

本文面向Android开发, 所以只讨论Java实现.
目前Realm Java的最新版本是2.3.1.

官方文档在此: realm java doc, 花一个下午就可以基本过一遍, 之后随时查用.

我写了一个小程序TodoRealm, 使用Realm做数据库实现的一个To-do应用, 在实际使用的过程中也有一些发现.

本文是我自己看文档的时候的一些记录, 有一些实际使用时的发现也穿插在对应的章节了.

Setup

在项目的根build.gradle的文件中添加:

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath "io.realm:realm-gradle-plugin:2.3.0"
    }
}

然后在app的build.gradle文件中添加:

apply plugin: 'realm-android'

Done.

Models

Model类只要继承RealmObject即可.

public class User extends RealmObject {

    private String          name;
    private int             age;

    @Ignore
    private int             sessionId;

    // Standard getters & setters generated by your IDE…
    public String getName() { return name; }
    public void   setName(String name) { this.name = name; }
    public int    getAge() { return age; }
    public void   setAge(int age) { this.age = age; }
    public int    getSessionId() { return sessionId; }
    public void   setSessionId(int sessionId) { this.sessionId = sessionId; }
}

字段类型

Model类中可以包含的字段类型包括基本数据类型(及它们的装箱类型)和Date类, 另外也可以包含RealmObject的子类或者是RealmList<? extends RealmObject>.

字段性质

在字段上加注解可以定义字段的性质:

@Required表明字段非null.
原生类型和RealmList类型默认是非null的.
RealmObject字段永远是可以为null的.

@Ignore表示字段不会被存储.

@Index加索引.

@PrimaryKey加主键, 主键只能有一个, 主键默认加索引.

但是注意主键默认没有加@Required, 如果主键要求非null, 需要显式添加@Required.

主键使用

有主键才能使用copyToRealmOrUpdate()这个方法.
主键类型必须是String或者整型(byte, short, int, long)或者它们的装箱类型(Byte, Short, Integer, Long).

有主键的对象创建的时候不能使用createObject(Class<E> clazz)方法, 而应该使用createObject(Class<E> clazz, Object primaryKeyValue)附上主键.

或者用
copyToRealm(obj)或copyToRealmOrUpdate(obj), 前者遇到主键冲突时会崩溃, 后者遇到主键冲突会更新已有对象.

自动更新的对象

Realm中的数据对象是自动更新(Auto-Updating)的, 对象一旦被查询出来, 后续发生的任何数据改变也会立即反映在结果中, 不需要刷新对象.

这是一个非常有用的特性, 结合数据变化的通知可以很方便地刷新UI.

关系

Realm model对象间可以很方便地建立关系.
你可以在Model中存储另一个对象的引用, 建立多对一的关系; 也可以存储一组对象RealmList<T>, 建立一对多或多对多的关系.

RealmList<T>的getter永远也不会返回null, 它只会返回一个为空的list.
把这个字段设置为null可以清空这个list.

初始化

Realm在使用之前需要调用初始化:

Realm.init(context);

建议把它放在Application的onCreate()里.

配置

配置类: RealmConfiguration定义了Realm的创建配置.
最基本的配置:

RealmConfiguration config = new RealmConfiguration.Builder().build();

它会创建一个叫default.realm的文件, 放在Context.getFilesDir()的目录下.

如果我们想自定义一个配置, 可以这样写:

// The RealmConfiguration is created using the builder pattern.
// The Realm file will be located in Context.getFilesDir() with name "myrealm.realm"
RealmConfiguration config = new RealmConfiguration.Builder()
  .name("myrealm.realm")
  .encryptionKey(getKey())
  .schemaVersion(42)
  .modules(new MySchemaModule())
  .migration(new MyMigration())
  .build();
// Use the config
Realm realm = Realm.getInstance(config);

所以我们是可以有多个配置, 访问多个Realm实例的.

我们可以把配置设置为默认配置:

Realm.init(this);
RealmConfiguration config = new RealmConfiguration.Builder().build();
Realm.setDefaultConfiguration(config);

之后用Realm.getDefaultInstance()取到的就是这个默认配置对应的实例.

数据库迁移

迁移的策略是通过config指定的:

RealmConfiguration config = new RealmConfiguration.Builder()
    .schemaVersion(2) // Must be bumped when the schema changes
    .migration(new MyMigration()) // Migration to run instead of throwing an exception
    .build()

其中MyMigration实现了RealmMigration接口, 在migrate()方法中根据新旧版本号进行一步一步地升级.

具体例子见Migration.

开发的时候为了方便我用的是.deleteRealmIfMigrationNeeded(), 这样在需要数据库迁移的时候直接就删了数据重新开始了.

关于Realm的close()

一个打开的Realm实例会持有一些资源, 有一些是Java不能自动管理的, 所以就需要打开实例的代码负责在不需要的时候将其关闭.

Realm的instance是引用计数的(reference counted cache), 在同一个线程中获取后续实例是免费的, 但是底层的资源只有当所有实例被释放了之后才能释放. 也即你调用了多少次getInstance(), 就需要调用相应次数的close()方法.

比较建议的方法是在Activity或Fragment的生命周期中处理Realm实例的开启和释放:

• 在Activity的onCreate()中getInstance(), onDestroy()中close().
• 在Fragment的onCreateView()中getInstance(), onDestroyView()中close().

如果多个Fragment相关的都是同一个数据库实例, 那么在Activity中处理更好一些.

写

写操作一般的流程是这样:

// Obtain a Realm instance
Realm realm = Realm.getDefaultInstance();

realm.beginTransaction();

//... add or update objects here ...

realm.commitTransaction();

这里创建对象可以用createObject()方法或者copyToRealm()方法.
前者是先创建再set值, 后者是先new对象再更新数据库.

如果不想自己处理beginTransaction(), cancelTransaction()和commitTransaction(), 可以直接调用realm.executeTransaction()方法:

realm.executeTransaction(new Realm.Transaction() {
    @Override
    public void execute(Realm realm) {
        User user = realm.createObject(User.class);
        user.setName("John");
        user.setEmail("john@corporation.com");
    }
});

异步

因为transactions之间是互相阻塞的.
异步执行可以用这个方法:

realm.executeTransactionAsync(new Realm.Transaction() {
            @Override
            public void execute(Realm bgRealm) {
                User user = bgRealm.createObject(User.class);
                user.setName("John");
                user.setEmail("john@corporation.com");
            }
        }, new Realm.Transaction.OnSuccess() {
            @Override
            public void onSuccess() {
                // Transaction was a success.
            }
        }, new Realm.Transaction.OnError() {
            @Override
            public void onError(Throwable error) {
                // Transaction failed and was automatically canceled.
            }
        });

这两个回调是Optional的, 它们只能在有Looper的线程调用.

注意: 这个方法的返回值对象可以用于在Activity/Fragment生命周期结束的时候取消未完的操作.

删除和更新

所有的写操作都要放在transaction中进行, 如上, 不同的操作只是其中具体方法不同.

删除操作:

final RealmResults<User> users = getUsers();
// method 1:
users.get(0).deleteFromRealm();
// method 2:
users.deleteFromRealm(0);

// delete all
users.deleteAllFromRealm();

更新操作:

realm.copyToRealmOrUpdate(obj);

注意: 这个方法需要Model有主键, 会更新obj的主键对应的对象, 如果不存在则新建对象.

查询

查询可以流式地写:

// Or alternatively do the same all at once (the "Fluent interface"):
RealmResults<User> result2 = realm.where(User.class)
                                  .equalTo("name", "John")
                                  .or()
                                  .equalTo("name", "Peter")
                                  .findAll();

查询条件默认是and的关系, or则需要显式指定.

这个RealmResults是继承Java的AbstractList的, 是有序的集合, 可以通过索引访问.
RealmResults永远不会为null, 当查不到结果时, 它的size()返回0.

查询的线程

基本上所有的查询都是很快进行的, 足够在UI线程上同步进行.
所以绝大多数情况在UI线程上使用findAll()是没有问题的.

如果你要进行非常复杂的查询, 或者你的查询是在非常大的数据集上进行的, 你可以选择异步查询, 使用findAllAsync().

查询条件是一个集合 -> in()

如果想要查询的某一个字段的值是在一个集合中, 比如我有一个id的集合, 我现在想把id在这个集合中的项目全都查出来, 这就可以使用in操作符:

RealmResults<TodoList> toDeleteLists = realm.where(TodoList.class).in("id", ids).findAll();

链式查询

查询的时候可以利用link或关系来查询, 比如一个Person类中含有一个RealmList<Dog> dogs的字段.
查询的时候可以这样:

RealmResults<Person> persons = realm.where(Person.class)
                                .equalTo("dogs.color", "Brown")
                                .findAll();

利用字段名dogs.来查询一个dog的属性, 再查出拥有这种特定属性dog的人.

但是反向地, 我们能不能查询主人是满足特定属性的人的所有dogs呢? 目前(2017.2.17)这种查询仍是不支持的. 这里有讨论: realm-java-issue-607.

所以两种解决办法: 一是做两次查询; 二是在Dog类的model里加入对Person的引用.

Notifications

可以添加一个listener, 在数据改变的时候收到更新.

public class MyActivity extends Activity {
    private Realm realm;
    private RealmChangeListener realmListener;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      realm = Realm.getDefaultInstance();
      realmListener = new RealmChangeListener() {
        @Override
        public void onChange(Realm realm) {
            // ... do something with the updates (UI, etc.) ...
        }};
      realm.addChangeListener(realmListener);
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        // Remove the listener.
        realm.removeChangeListener(realmListener);
        // Close the Realm instance.
        realm.close();
    }
}

注意listener需要在不用的时候删除掉.

可以用这样删除所有的listeners:

realm.removeAllChangeListeners();

Listener不一定要和Realm绑定, 也可以和具体的RealmObject或者RealmResults绑定.
当Listener被调用的时候, 它绑定的对象是自动更新的, 不需要手动刷新.

查看数据库的工具

用Stetho不能直接查看Realm的数据库, 看不到.
需要用这个工具配置一下: stetho-realm.
之后就可以在浏览器中查看Realm的数据库了.

(但是感觉这个工具不是很好用, 有时候不显示数据, 有时候显示的是旧数据.)

也可以用官方提供的Realm Browser来查看, 但是只有Mac版.
如何查看看这里: StackOverflow answer.

实际使用的感想和遇到的问题

优点

• 建立Model之间的关系很方便也很直接, 查询的时候自动关联了其中的关系.
• 自动更新(Auto-Updating)的特性很有用, 不用再关心数据的刷新, 只用关心UI的刷新.

比如一旦给Adapter绑定了数据, 之后的数据更新只需要在onChange()里面通知Adapter调用notifyDataSetChanged()即可.

当然我并没有用RealmBaseAdapter和RealmRecyclerViewAdapter, 估计这两个更好用, 官方有例子, 这里不再赘述.

缺点

这里有的也不能说是缺点, 只是使用起来觉得不方便的地方.

• 限制了创建对象和操作对象必须在同一个线程.
  违反了这条会报错: java.lang.IllegalStateException: Realm access from incorrect thread. Realm objects can only be accessed on the thread they were created.比如我们在UI线程查询出来的对象, 想要异步地删除或者更新, 我们必须在新的线程重新查询.
• 没有主键自增的功能, 见Issue #469, 需要自己控制主键自增.
• 从List中删除了一项之后, 最后的一项会移动过来补到被删除的那一项原来的位置. 这是因为人家就是这么设计的stackoverflow. 默认情况下是没有排序的, 数据按照添加的顺序返回, 但是这并不是一种保证, 所以当删除了中间的元素, 后面的会补上这个位置, 以保证底层的数据是放在一起的. 解决办法就是指定一个排序规则.
• 查询出来的对象不可以临时改变其数据, 否则会报错: java.lang.IllegalStateException: Changing Realm data can only be done from inside a transaction.
• 不支持反向link的查询. (见前面链式查询部分的介绍).
• 不支持级联删除. 即从数据库中删除一个对象的时候, 不会删除其中RealmObject子类或RealmList类型的字段在数据库中对应的数据. Issue #1104, Issue #2717. 这点也可以理解, 因为model之间的关系可能是多对多的. 所以需要实现级联删除的地方需要手动处理.
• 测试不方便: RealmResults对象即不能被mock也不能被new; 所有的Model对象也不能被mock. 因为Mockito can only mock non-private & non-final classes.
• 
  

我的练习Demo:

• TodoRealm

友情推荐：

1. 线程池原理
2. 深入Thread.sleep
3. 多线程中断机制

不使用Thread.join() 测试线程

先上代码：

/**
 * Created by Zero on 2017/8/23.
 */
public class TestJoin implements Runnable {
    public static int a = 0;

    @Override
    public void run() {
        for (int i = 0; i < 5; i++) {
            a = a + 1;
        }
    }

    public static void main(String[] args) throws InterruptedException {
        TestJoin j = new TestJoin();
        Thread thread = new Thread(j);
        thread.start();
        System.out.println(a);
    }
}

以上示例会输出5吗？可能性不大，有可能永远输出为0，之前在线程池原理的那篇就提到过，线程的启动和销毁都需要时间，此处因为thread还没启动好，或者正在为它分配资源准备运行，就已经执行完输出了。

怎样才能确保每次都能输出5呢？现在有请我们的主角join方法闪亮登场，代码如下：

/**
 * Created by apple on 2017/8/23.
 */
public class TestJoin implements Runnable {
    public static int a = 0;

    @Override
    public void run() {
        for (int i = 0; i < 5; i++) {
            a = a + 1;
        }
    }

    public static void main(String[] args) throws InterruptedException {
        TestJoin j = new TestJoin();
        Thread thread = new Thread(j);
        thread.start();
        /**
         * 测试join方法的作用，与下面的threadAgain线程作对比。
         */
        thread.join();
        System.out.println(a);
        a = 0;
        Thread threadAgain = new Thread(j);
        threadAgain.start();
        System.out.println(a);
    }
}

输出的结果将是5和0。

Thread.join()作用

Thread.join()，之前看资料的时候，有些人说可以理解成“将两个线程合并成一个线程”，我是觉得这样说是很不科学的，虽然这样通俗易懂，但这确实是两个不同的线程，只是在调用Thread.join()后，会先执行完Thread线程后再去执行当前线程，即上述的在主线程中执行到thread.join();后，先去执行thread，直到thread执行完后再去执行主线程。

测试Thread.join(long millis)

/**
 * Created by apple on 2017/8/23.
 */
public class TestJoin implements Runnable {
    public static int a = 0;

    @Override
    public void run() {
        for (int i = 0; i < 5; i++) {
            a = a + 1;
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    public static void main(String[] args) throws InterruptedException {
        TestJoin j = new TestJoin();
        Thread thread = new Thread(j);
        thread.start();
        /**
         * 测试join方法的作用
         */
        thread.join(3000);
        System.out.println("thread线程结果为："+a);
        a = 0;
        Thread threadAgain = new Thread(j);
        threadAgain.start();
        System.out.println("threadAgain线程结果为："+a);
    }
}

输出：

thread线程结果为：3
threadAgain线程结果为：0

先上一段源码再来分析：

/**
     * Waits at most {@code millis} milliseconds for this thread to
     * die. A timeout of {@code 0} means to wait forever.
     *
     * <p> This implementation uses a loop of {@code this.wait} calls
     * conditioned on {@code this.isAlive}. As a thread terminates the
     * {@code this.notifyAll} method is invoked. It is recommended that
     * applications not use {@code wait}, {@code notify}, or
     * {@code notifyAll} on {@code Thread} instances.
     *
     * @param  millis
     *         the time to wait in milliseconds
     *
     * @throws  IllegalArgumentException
     *          if the value of {@code millis} is negative
     *
     * @throws  InterruptedException
     *          if any thread has interrupted the current thread. The
     *          <i>interrupted status</i> of the current thread is
     *          cleared when this exception is thrown.
     */
    public final synchronized void join(long millis)
    throws InterruptedException {
        long base = System.currentTimeMillis();
        long now = 0;

        if (millis < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }

        if (millis == 0) {
            while (isAlive()) {
                wait(0);
            }
        } else {
            while (isAlive()) {
                long delay = millis - now;
                if (delay <= 0) {
                    break;
                }
                wait(delay);
                now = System.currentTimeMillis() - base;
            }
        }
    }

源码爸爸说了，孩子，我给你millis这么长的时间，能不能完成任务那是你的事情了，能提前完成，咱就提前走下去，不能完成，过期不候，自己看着办吧。

默认情况下，Thread.join()即Thread.join(0)，当为0的时候，那才叫真爱呢，线程会一直等下去，知道执行结束为止，才会继续朝下执行。

isAlive()：用来测试线程是否处于活动状态，相当于 run 是否还在执行。

相关文章
Android系统启动流程系列
Android应用进程系列
Android深入四大组件系列
Android深入解析AMS系列

前言

关于AMS，原计划是只写一篇文章来介绍，但是AMS功能繁多，一篇文章的篇幅远远不够。这一篇我们接着来学习与AMS相关的ActivityTask和Activity栈管理。

1.ActivityStack

ActivityStack从名称来看是跟栈相关的类，其实它是一个管理类，用来管理系统所有Activity的各种状态。它由ActivityStackSupervisor来进行管理的，而ActivityStackSupervisor在AMS中的构造方法中被创建。
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

   public ActivityManagerService(Context systemContext) {
   ...
    mStackSupervisor = new ActivityStackSupervisor(this);
   ... 
   }

1.1 ActivityStack的实例类型

ActivityStackSupervisor中有多种ActivityStack实例，如下所示。
frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java

public final class ActivityStackSupervisor implements DisplayListener {
   ...
    ActivityStack mHomeStack;
    ActivityStack mFocusedStack;
    private ActivityStack mLastFocusedStack;
    ...
}

mHomeStack用来存储Launcher App的Activity的堆栈，mFocusedStack表示当前正在接收输入或启动下一个Activity的堆栈。mLastFocusedStack表示此前接收输入的Activity的堆栈。

通过ActivityStackSupervisor提供了获取上述ActivityStack的方法，比如要获取mFocusedStack，只需要调用ActivityStackSupervisor的getFocusedStack方法就可以了：
frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java

   ActivityStack getFocusedStack() {
        return mFocusedStack;
    }

1.2 ActivityState

ActivityStack中通过枚举存储了Activity的所有的状态，如下所示。
frameworks/base/services/core/java/com/android/server/am/ActivityStackSupervisor.java

 enum ActivityState {
        INITIALIZING,
        RESUMED,
        PAUSING,
        PAUSED,
        STOPPING,
        STOPPED,
        FINISHING,
        DESTROYING,
        DESTROYED
    }

通过名称我们可以很轻易知道这些状态所代表的意义。应用ActivityState的场景会有很多，比如下面的代码：
frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

   @Override
    public void overridePendingTransition(IBinder token, String packageName,
            int enterAnim, int exitAnim) {
     ...
            if (self.state == ActivityState.RESUMED
                    || self.state == ActivityState.PAUSING) {//1
                mWindowManager.overridePendingAppTransition(packageName,
                        enterAnim, exitAnim, null);
            }
            Binder.restoreCallingIdentity(origId);
        }
    }

overridePendingTransition方法用于设置Activity的切换动画，注释1处可以看到只有ActivityState为RESUMED状态或者PAUSING状态时才会调用WMS类型的mWindowManager对象的overridePendingAppTransition方法来进行切换动画。

1.3 特殊状态的Activity

在ActivityStack中定义了一些特殊状态的Activity，如下所示。

ActivityRecord mPausingActivity = null;//正在暂停的Activity
ActivityRecord mLastPausedActivity = null;//上一个已经暂停的Activity
ActivityRecord mLastNoHistoryActivity = null;//最近一次没有历史记录的Activity
ActivityRecord mResumedActivity = null;//已经Resume的Activity
ActivityRecord mLastStartedActivity = null;//最近一次启动的Activity
ActivityRecord mTranslucentActivityWaiting = null;//传递给convertToTranslucent方法的最上层的Activity

这些特殊的状态都是ActivityRecord类型的，ActivityRecord用来记录一个Activity的所有信息。从栈的角度来说（Activity任务栈是一个假想的模型），一个或多个ActivityRecord会组成一个TaskRecord，TaskRecord用来记录Activity的栈，而ActivityStack包含了一个或多个TaskRecord。

1.4 维护的ArrayList

ActivityStack中维护了很多ArrayList，这些ArrayList中的元素类型主要有ActivityRecord和TaskRecord，其中TaskRecord用来记录Activity的Task。

2.Activity栈管理

我们知道Activity是由任务栈来进行管理的，不过任务栈是一个假想的模型，并不真实的存在。栈管理就是建立在这个假想模型之上的，有了栈管理，我们可以对应用程序进行操作，应用可以复用自身应用中以及其他应用的Activity，节省了资源。比如我们使用一款社交应用，这个应用的联系人详情界面提供了联系人的邮箱，当我们点击邮箱时会跳到发送邮件的界面。

社交应用和系统Email中的Activity是处于不同应用程序进程的，而有了栈管理，就可以把发送邮件界面放到社交应用中详情界面所在栈的栈顶，来做到跨进程操作。
为了更灵活的进行栈管理，Android系统提供了很多配置，下面分别对它们进行介绍。

2.1 Launch Mode

Launch Mode都不会陌生，用于设定Activity的启动方式，无论是哪种启动方式，所启动的Activity都会位于Activity栈的栈顶。有以下四种：
- standerd：默认模式，每次启动Activity都会创建一个新的Activity实例。
- singleTop：如果要启动的Activity已经在栈顶，则不会重新创建Activity，同时该Activity的onNewIntent方法会被调用。如果要启动的Activity不在栈顶，则会重新创建该Activity的实例。
- singleTask：如果要启动的Activity已经存在于它想要归属的栈中，那么不会创建该Activity实例，将栈中位于该Activity上的所有的Activity出栈，同时该Activity的onNewIntent方法会被调用。如果要启动的Activity不存在于它想要归属的栈中，并且该栈存在，则会重新创建该Activity的实例。如果要启动的Activity想要归属的栈不存在，则首先要创建一个新栈，然后创建该Activity实例并压入到新栈中。
- singleInstance：和singleTask基本类似，不同的是启动Activity时，首先要创建在一个新栈，然后创建该Activity实例并压入新栈中，新栈中只会存在这一个Activity实例。

2.2 Intent的FLAG

Intent中定义了很多了FLAG，其中有几个FLAG也可以设定Activity的启动方式，如果Launch Mode设定和FLAG设定的Activity的启动方式有冲突，则以FLAG设定的为准。

• FLAG_ACTIVITY_SINGLE_TOP：和Launch Mode中的singleTop效果是一样的。
• FLAG_ACTIVITY_NEW_TASK：和Launch Mode中的singleTask效果是一样的。
• FLAG_ACTIVITY_CLEAR_TOP：Launch Mode中没有与此对应的模式，如果要启动的Activity已经存在于栈中，则将所有位于它上面的Activity出栈。singleTask默认具有此标记位的效果。

除了这三个FLAG，还有一些FLAG对我们分析栈管理有些帮助。

• FLAG_ACTIVITY_NO_HISTORY：Activity一旦退出，就不会存在于栈中。同样的，也可以在AndroidManifest.xml中设置“android:noHistory”。
• FLAG_ACTIVITY_MULTIPLE_TASK：需要和FLAG_ACTIVITY_NEW_TASK一同使用才有效果，系统会启动一个新的栈来容纳新启动的Activity.
• FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS：Activity不会被放入到“最近启动的Activity”列表中。
• FLAG_ACTIVITY_BROUGHT_TO_FRONT：这个标志位通常不是由应用程序中的代码设置的，而是Launch Mode为singleTask时，由系统自动加上的。
• FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY：这个标志位通常不是由应用程序中的代码设置的，而是从历史记录中启动的（长按Home键调出）。
• FLAG_ACTIVITY_CLEAR_TASK：需要和FLAG_ACTIVITY_NEW_TASK一同使用才有效果，用于清除与启动的Activity相关栈的所有其他Activity。

接下来通过系统源码来查看FLAG的应用，在Android深入四大组件（一）应用程序启动过程（后篇）中讲过，根Activity启动时会调用AMS的startActivity方法，经过层层调用会调用ActivityStarter的startActivityUnchecked方法，如下面的时序图所示。

frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java

 private int startActivityUnchecked(final ActivityRecord r, ActivityRecord sourceRecord,
            IVoiceInteractionSession voiceSession, IVoiceInteractor voiceInteractor,
            int startFlags, boolean doResume, ActivityOptions options, TaskRecord inTask) {
        setInitialState(r, options, inTask, doResume, startFlags, sourceRecord, voiceSession,
                voiceInteractor);//1
        computeLaunchingTaskFlags();//2
        computeSourceStack();
        mIntent.setFlags(mLaunchFlags);//3
 ...       
}

注释1处用于初始化启动Activity的各种配置，在初始化前会重置各种配置再进行配置，这些配置包括：ActivityRecord、Intent、TaskRecord和LaunchFlags（启动的FLAG）等等。注释2处的computeLaunchingTaskFlags方法用于计算出启动的FLAG，并将计算的值赋值给mLaunchFlags。在注释3处将mLaunchFlags设置给Intent，达到设定Activity的启动方式的目的。接着来查看computeLaunchingTaskFlags方法。

frameworks/base/services/core/java/com/android/server/am/ActivityStarter.java

private void computeLaunchingTaskFlags() {
...
      if (mInTask == null) {//1
            if (mSourceRecord == null) {//2
                if ((mLaunchFlags & FLAG_ACTIVITY_NEW_TASK) == 0 && mInTask == null) {//3
                    Slog.w(TAG, "startActivity called from non-Activity context; forcing " +
                            "Intent.FLAG_ACTIVITY_NEW_TASK for: " + mIntent);
                    mLaunchFlags |= FLAG_ACTIVITY_NEW_TASK;
                }
            } else if (mSourceRecord.launchMode == LAUNCH_SINGLE_INSTANCE) {//4
                mLaunchFlags |= FLAG_ACTIVITY_NEW_TASK;
            } else if (mLaunchSingleInstance || mLaunchSingleTask) {//5
                mLaunchFlags |= FLAG_ACTIVITY_NEW_TASK;
            }
        }
}

计算启动的FLAG的逻辑比较复杂，这里只截取了一小部分，注释1处的TaskRecord类型的mInTask为null时，说明Activity要加入的栈不存在。因此，这一小段代码主要解决的问题就是Activity要加入的栈不存在时如何计算出启动的FLAG。注释2处，ActivityRecord类型的mSourceRecord用于描述“初始Activity”，什么是“初始Activity”呢？比如ActivityA启动了ActivityB，ActivityA就是初始Activity。同时满足注释2和注释3的条件则需要创建一个新栈。注释4处，如果“初始Activity”所在的栈只允许有一个Activity实例，则也需要创建一个新栈。注释5处，如果Launch Mode设置了singleTask或singleInstance，则也要创建一个新栈。

2.3 taskAffinity

我们可以在AndroidManifest.xml设置android:taskAffinity，用来指定Activity希望归属的栈， 默认情况下，同一个应用程序的所有的Activity都有着相同的taskAffinity。
taskAffinity在下面两种情况时会产生效果。
1. taskAffinity与FLAG_ACTIVITY_NEW_TASK或者singleTask配合。如果新启动Activity的taskAffinity和栈的taskAffinity相同（栈的taskAffinity取决于根Activity的taskAffinity）则加入到该栈中。如果不同，就会创建新栈。
2. taskAffinity与allowTaskReparenting配合。如果allowTaskReparenting为true，说明Activity具有转移的能力。拿此前的邮件为例，当社交应用启动了发送邮件的Activity，此时发送邮件的Activity是和社交应用处于同一个栈中。如果发送邮件的Activity的allowTaskReparenting设置为true，此后邮件程序所在的栈位于前台，这个时候发送邮件的Activity就会由社交应用的栈中转移到与它更亲近的邮件程序（taskAffinity相同）所在的栈中。

接着通过系统源码来查看taskAffinity的应用。ActivityStackSupervisor的findTaskLocked方法用于找到Activity最匹配的栈，最终会调用ActivityStack的findTaskLocked方法。
frameworks/base/services/core/java/com/android/server/am/ActivityStack.java

 void findTaskLocked(ActivityRecord target, FindTaskResult result) {
...
   for (int taskNdx = mTaskHistory.size() - 1; taskNdx >= 0; --taskNdx) {//1
     final TaskRecord task = mTaskHistory.get(taskNdx);//2
   ...
     else if (!isDocument && !taskIsDocument
                    && result.r == null && task.canMatchRootAffinity()) {
                if (task.rootAffinity.equals(target.taskAffinity)) {//3
                    if (DEBUG_TASKS) Slog.d(TAG_TASKS, "Found matching affinity candidate!");
                    result.r = r;
                    result.matchedByRootAffinity = true;
                }
            } else if (DEBUG_TASKS) Slog.d(TAG_TASKS, "Not a match: " + task);
        }
    }

这个方法的逻辑比较复杂，这里截取了和taskAffinity相关的部分。注释1处遍历mTaskHistory列表，列表的元素为TaskRecord，
用于存储没有被销毁的Task。注释2处得到某一个Task的信息。注释3处将Task的rootAffinity（初始的taskAffinity）和目标Activity的taskAffinity做对比，如果相同，则将FindTaskResult的matchedByRootAffinity 属性设置为true，说明找到了匹配的Task。

参考资料
《深入理解Android卷二》
《深入理解Android内核设计思想》第二版
《Android开发艺术探索》
ActivityRecord、TaskRecord、ActivityStack

欢迎关注我的微信公众号，第一时间获得博客更新提醒，以及更多成体系的Android相关原创技术干货。
扫一扫下方二维码或者长按识别二维码，即可关注。

【编者按】58 同城 App 自 1.0 版本开始，便一直致力于自研 IM 系统。在这过程中，发现如何降低 IM 系统层次和页面间的耦合，减少 IM 系统的复杂性，是降低技术成本提高研发效率的关键。对此，本文作者对 iOS 客户端 IM 系统架构演变的过程以及经验进行了总结，希望能够给设计或改造优化 IM 模块的开发者提供一些参考。

对于 58 同城 App 这样以信息展示及交易为主体的平台而言，App 内的 IM 即时消息功能，相比电话和短信，在促成商品/服务交易上更有着举足轻重的地位。也正因如此，自 1.0 版本开始，便一直致力于自研 IM 系统。在自研过程中，我们发现如何降低 IM 系统层次和页面间的耦合，减少 IM 系统的复杂性，是降低技术成本提高研发效率的关键。

为此，本文将主要从两个方面阐述 58 同城 iOS 客户端 IM 系统架构的变迁过程。一是 IM 系统如何解除对数据库和 Socket 接口的依赖；二是 IM 聊天页面从传统的 MVC 模式走向面向协议的新型架构。希望给具有相似业务场景的开发者提供一些借鉴。

老版本 IM 系统遇到的问题

58 App 在项目早期就自研了 IM 系统，但只实现了文本消息、图片消息、音频等基本类型。虽然业务需求场景简单，却还是遇到了如下问题。

数据扩展性差

数据格式使用的是 Google ProtocolBuffer（以下简称 PB），是因为这种数据格式相比 XML 和 JSON 相同的数据形式，体积更小，解析更加迅速。但 PB 是用 C++实现的，使用起来相对繁琐。需要对不同的消息类型编写不同的 PB 数据结构，每种 PB 结构还需要单独的数据解析方法。由于 58 业务的发展，这种数据协议增加了系统的复杂性。

代码封装性差，研发成本高

在数据发送前，为了安全，还需要将待传输的数据通过特定的加密算法进行加密，再利用 AsyncSocket 做数据传输。相对应的，每接到一种消息类型，就需要解密，将 PB 格式转换成对象模型。这种方案，每次新增消息类型时都比较痛苦，要写加密算法，写 PB 模型解析器。这样不仅代码的扩展性很差，开发难度也比较大。

代码耦合性强

每次如果有新增消息类型，要在 DB 层写个接口对新消息的数据解析并存储。同样，在 Socket 传输层也要新增收发接口与之对应。这种设计方式，开发过程中耦合性很大。

代码可读性差

App 内只有一种消息类型，叫 WBMessagModel。在消息类型判断上，是通过 WBMessageModel 里的特定字段来进行区分的，比如根据 mtype、isOnlineTip、m_msgtype 等字段判断，方式相对混乱。

为了解决上面的问题，打造一款低耦合、可扩展性强的 IM 系统，我们决定重构。

新版本的 IM 系统

框架演进

老的 IM 系统由于代码耦合性严重，一旦遇到问题难于追查。并且扩展性差，每个版本的需求研发，都从底层修改到业务层，影响研发进度。结合之前 IM 开发过程中遇到的问题，新的 IM 系统亟需解决如下问题。

• 简化调用流程

业务开发过程中做到与“底层 DB+数据加密+数据加密+数据传输”的分离，通过调用底层接口就可以做到收发、存储消息。

• 设计低耦合的中间层接口

中间层接口要做到承上启下对接，业务层和底层接口无任何耦合。如果做到这些，以后在 IM 底层升级甚至更换时，只需调整业务接口与底层接口的重新对接，让顶层的业务无感知，做到无感知的迭代。

• 设计单一职能的模型和接口

在具体业务层处理上，要做到模型分离，设计统一。模型上，将之前的只有一个 IM 模型根据各自的类型拆分。接口上，通过底层、中间层业务层的结构划分，每层接口各司其职。

• 可扩展性强

利用面向协议方式抽象和组织代码，做到按照协议新增消息。利用 UITableView 的类别做到现有及新增的消息类型 Cell 能够自动计算高度。通过这种业务上的设计方式，能够快速定位问题。如有新增的消息类型，只需关注新增的消息模型和与之对应的消息界面即可，完全无需关注视图的填充时机以及如何计算视图的高度等。确定了这些设计原则，才能保证在业务研发过程中做到快速迭代，进而满足日益增长的用户需求。

基于上面的目标，重构后的 IM 整体架构图 1 所示。

新的 IM 系统整体架构包含底层、接口服务层、业务层三个部分。底层主要进行数据收发、存储等相关处理，并抽象出通用底层接口，与接口服务层交互。接口服务层主要负责合理地将底层的数据传递到业务层，同样，业务层的数据能够通过接口服务层传递给底层。清晰明了的接口服务层不仅可以让业务层处理数据变得更简单，还能极大地降低业务层和底层的耦合。业务层主要针对具体需求场景，如何合理使用数据进行视图的展示。基于这样的设计，下面详细介绍一下各个层次之间的具体实现。

设计调用流程简洁的底层接口

新的 IM 底层采用了全新的设计思路，如图 2 所示。在底层，为了数据的可扩展性，放弃了之前 PB 的数据协议，而是采用传统的 JSON 格式作为 Socket 端数据的收发协议。

在消息模型上，摒弃了之前只有一种消息模型的策略，而是根据消息类型划分出文本消息模型、图片消息模型等基本消息模型。

58 App 将 DB 和 Socket 的内部处理封装成 SDK，对外只暴露 IMClient 底层接口。顶层所有消息相关的事件都是和底层 IMClient 的接口交互，内部流程完全不用关心。这样业务层完全感知不到数据是如何收发和存储的，极大地简化了接入和使用成本。

但是读者也许会有疑问，IM SDK 里内置了如此多的类型消息，那以后有新增 SDK 里没有的消息类型该怎么办？为了解决这个问题，58 App 采用了一种和 iOS 自定义对象归解档相似的策略——任意定义一种新的消息，只要它继承自基础的消息类型，并遵循 IMMessageCoding 协议。这个协议里定义了 encode 和 decode 方法，其中，encode 方法用于将新类型消息里的数据存储到数据库中（当然，这个过程并不需要上层开发者关注，他们只需在这个函数里返回待存储的数据即可）；decode 方法用于将数据库中的数据恢复成相应的消息模型。现在，我们有了消息类型的定义方式，又如何使用呢？为了让底层能够感知到自定义的消息类型，需要在统一接口层 IMClient 初始化之后，立即注册给它，注册后 IM 底层就知道当前的消息类型，并且明白如何存储和恢复数据。基于这种设计方式，目前 58 App 的 IM 底层可以任意扩展其他消息类型，而底层的代码完全不用修改。

底层代码不仅有良好的扩展性，并且在设计时还为一些基础的场景提供了很多协议。这些协议都是可动态定制或移除的。例如，当联系人列表发生变化时，需要修改联系人头像，就可以订制底层IMClientConversationListUpdateDelegate协议。使用时，业务方通过注册协议addUpdateConversationListDelegate:，当监听到联系人更新回掉后，执行头像更新操作。当不需要时，可通过removeUpdateConversationListDelegate:方式，解除监听。类似的场景还有消息接收协议、在线状态变化协议等。通过这种方式，就可灵活配置业务代码对 IM 的某些状态变化的监听。

目前，通过对底层代码的抽象，提供顶层接口与内部数据处理分离，且很多 IM 服务都可定制化实现，由此就做到了和具体业务无耦合。通过这样的底层设计，完全可以作为基础的 IM SDK，给其他 App 使用，快速集成 IM 功能。

设计低耦合、职责单一的中间层接口

为了业务层和底层能够通信，并且互不耦合，我们创建了中间接口层用以承上启下。根据实际的业务场景，中间接口层分了三种情况，即为登录相关的接口、消息收发相关的接口以及消息查询相关接口，分别和底层统一接口对接。通过业务场景的划分，开发过程中可以快速定位相关业务对应的模块。对于底层提供的消息模型，并没有直接使用，究其原因是底层的消息模型完全不关心视图展示属性，比如行高、重用标识等属性（下节会详细介绍）。而 MVVM 中 VM 部分属性需要和视图关联，因此将底层的消息模型转换成了聊天 Cell 直接可用的消息模型。通过这样的业务接口划分和消息模型的转换，即使之后底层统一接口或消息模型发生变化，只要做好中间接口的重新对接和消息模型的重新转换，顶层业务就完全感知不到下面的变化。

设计可扩展性强的业务层

由于老的 IM 系统项目是早期搭建的，处理的业务场景简单，扩展性不足。例如所有消息都使用同一个数据模型，就会造成随着业务场景的扩展，模型的代码体积越来越大，使用时好多属性冗余不堪。在设计上，老架构使用了 MVC 设计模式，由于在聊天场景下，VC 要处理的聊天视图类型较多，VC 内部十分臃肿。因为之前架构的局限性，这就对新的 IM 业务架构提出了要求，怎样设计出低耦合、扩展性强的业务层？接下来介绍一下具体的实现方案。

• 拆分 IM 消息模型：明确了上面的问题，现在 58 App 把之前只有一个消息模型，拆分成了文本、图片、语音、提醒、音频、视频等消息模型，它们统一继承基类消息的模型，基类消息模型存储了 IM 所需的必要数据，如聊天用户的信息、消息发送的状态等。

• 使用 MVVM 架构：为了降低 VC 和各个聊天视图之间的耦合。VC 管理各种消息模型，消息模型中存储视图展示时需要的数据。在消息视图和消息模型之间，实现了双向数据绑定。实现的方式是在聊天视图里存储与之对应的消息模型，这样当聊天视图变化并需要消息模型做数据更新时，直接对消息模型赋值即可。当聊天视图要根据消息模型属性变化而变化时，则通过 KVO 的方式实现这一功能。例如在 IM 场景中，我们发送一条消息，消息模型中的发送状态是发送中，当发送状态变化时（如发送成功或失败），聊天视图就可以根据改变后的值进行更新；

• 使用面向协议组织 IM 模型和视图：通过面向协议的方式，组织 IM 模型和视图，可以增强 IM 消息模型和视图的扩展性。下文会结合具体的技术细节，阐述面向协议的设计在 58 IM 系统中的重要作用。

技术细节

聊天列表页技术细节

由于 IM 模块的特点，伴随着业务需求的发展，IM 的类型会越来越多。为了避免在研发过程中每次都要花费很多精力计算 UITableView 中 Cell 的高度，为此我们在 App 内利用 XIB 创建不同的 Cell，并使用 AutoLayout 的方式给 Cell 中的视图布局。当然，你也可以通过手写代码的方式，然后利用 AutoLayout 布局。而 App 在 IM 中利用 XIB 布局，目的是为了让视图的布局更直观地展示，以及更好地让视图部分和 VC 分离。当 Cell 中所有布局合理完成后，就可以通过调用系统的 systemLayoutSizeFittingSize:方法，获得 Cell 的高度。基于这种思路，58 App 内部给 UITabelView 增加了自动计算 Cell 高度的能力，代码如下：

#import <uikit uikit.h="">
#import "WBAutoCalculateTableViewDelegate.h"

@interface  NSObject (WBAutoCalculateTableView)
@property (nonatomic,assign) CGFloat kid_height;
@end

@interface UITableView(WBAutoCalculateTableView)
- (CGFloat)heightForRowWithReuseIdentifier:(NSString *indentifiercellEntity:(NSObject *)cellEntity;
@end</uikit>

首先我们给 NSObject 增加了类别，并在类别里添加了 kid_height 属性，目的是在计算完 Cell 的高度后，将其缓存好。这样下次重新加载 UITableView 时，就直接返回缓存过的高度。

其次，我们给 UITableView 添加了类别。利用heightForRowWithReuseIndentifier: cellEntity:这个 API，在传入当前消息 Cell 的重用标识和当前的消息模型后，就返回当前 Cell 的高度。而调用者完全不用关心高度计算细节，计算完成后，立即将高度利用 NSObject 的类别属性缓存在消息模型中。

为了解决不同类型的消息 Cell 填充数据方式不一致的问题，我们引入了如下协议：

#import <foundation foundation.h="">

@protocol  WBCellConfigDelegate<nsobject>
@required
- (void)setModel:(id)cellEntity;
@end</nsobject></foundation>

如此，让 UITableView 中所有的消息 Cell 都遵循此协议，此协议规范了不同的消息 Cell 之间填充数据的统一性。不同的消息 Cell 使用不同类型的消息模型, 但却可以使用相同的填充规范。

@protocol WBAutoCalculateCellViewModelProtocol <nsobject>
@required
  - (NSString *)cellReuseIndentifier;
 - (void)registerCellForTableView:(UITableView *)tableView;
@optional
  - (CGFloat)cellHeight;
@end</nsobject>

为了解决消息视图在即将展示时，还要根据当前的消息类型，去判断该使用哪种视图的模板，58 App 采用让每个消息模型遵循上面的协议，每个消息模型都存储与之对应的重用标识。因为 Cell 的注册方式有多种，如通过类注册或 Nib 注册，这里设计成灵活的接口，注册 Cell 方式完全交由开发者决定。

下面的可选协议，在此还要着重在介绍一下- (CGFloat)cellHeight。这个协议是这样的，虽然大部分场景能够自动计算某个 Cell 的高度，但有些消息类型的高度是固定的，根本无需计算。为了解决这个问题，我们给消息模型增加了可选的 cellHeight 协议，如果消息模型实现这个协议，则 Cell 的高度就不自动计算了，通过此方法的返回值决定。

做项目有时就像搭积木一样，通过上面的介绍，我们已经有了很多小的解决方案，就像有了很多积木零件，如何将这些方案组织在一起，下面到了将这些“积木”组装到一起的时候了。因为我们是通过 UITableView 组织和管理聊天页面视图的，而tableView:heightForRowAtIndexPath:是其重要的代理方法，目前实现如下：

#pragma mark  UITableViewDelegate
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath{
  CGFloat cellHeight = 0;
  id <wbautocalculatecellviewmodelprotocol>cellEntity = self.viewModel.dataSource[indexPath.row];
  //向 tableview 中注册 cell 通过 cellindentifier
  if ([cellEntity conformsToProtocol:@protocol(WBAutoCalculateCellViewModelProtocol)]) {
     if(!self.tableViewRegisters[[cellEntity cellReuseIndentifier]]) {
       [cellEntity registerCellForTableView:tableView];
       self.tableViewRegisters[[cellEntity cellReuseIndentifier]] = @(1);
        }
    }

    if ([cellEntity respondsToSelector:@selector(cellHeight)]) {
        cellHeight = [cellEntity cellHeight];
    }else{
        cellHeight = [tableView heightForRowWithReuseIdentifier:[cellEntitycellReuseIndentifier] cellEntity:(NSObject *)cellEntity];
    }
    return cellHeight;
}</wbautocalculatecellviewmodelprotocol>

在这个方法中，我们看到了每个cellEntity（消息模型），都遵循了上面介绍的 WBAutoCalculateCellViewModelProtocol。在此方法里，让每个消息模型去注册自己的 Cell 类型，然后计算 Cell 的高度，如果消息模型有 cellHeight 方法，则通过此方法计算高度，否则通过上面提到的自动算高的方式，返回 Cell 的高度。

在 Cell 的展示处理上，UITableView 的数据源方法tableview:cellForRowAtIndexPath:是核心的方法，目前实现如下：

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
    id <wbautocalculatecellviewmodelprotocol>model = self.viewModel.dataSource[indexPath.row];
    NSString *cellIndentifier = [model cellReuseIndentifier];

    UITableViewCell<wbcellconfigdelegate> *cell = [tableView dequeueReusableCellWithIdentifier:cellIndentifier];
    if (cell &&[cellconformsToProtocol:@protocol(WBCellConfigDelegate)]) {
        [cell setModel:model];
    }
    if (!cell) {
        cell =  (UITableViewCell<wbcellconfigdelegate> *)[[UITableViewCell alloc]init];
    }
    return cell;
}</wbcellconfigdelegate></wbcellconfigdelegate></wbautocalculatecellviewmodelprotocol>

通过消息模型找出重用标识。因为已经在tableView:heightForRowAtIndexPath:时注册过了 Cell，所有通过重用队列一定能返回该消息类型下的 Cell。而消息 Cell 都遵循WBCellConfigDelegate协议，使得数据在填充时具有统一的方式。
通过面向协议的设计方式，我们在 VC 里 tableView 的代理和数据源方法就变得如此简单。而且以后如果在扩充新的消息类型时，继续遵循相应的协议，VC 里的代码是一行都不用修改的，开发人员只要关和注新增的消息模型和视图即可。

处理离线 Voip 消息的技术细节

实际开发过程中，我们遇到了一个问题，当 B 不在线时，B 的聊天对象可能向 B 发起音视频消息，服务器为了信令消息的完备性，会建立一个队列，将所有向 B 发消息的信令记录下来。过了一段时间，当 B 登录时，Server 会把 B 离线期间所有的通话信令发过来。由于刚开始设计时没有考虑到这一点，造成一个问题就是当 B 启动时，A 发送了一个视频消息过来时，B 接受到第一个视频信令是离线期间的视频消息信令（如果有）。这就造成了 B 尝试连接一个早已不存在的视频通道，而让 A-B 视频聊天连接不上。客户端为了也支持这种信令序列，利用条件锁技术有序地处理视频连接信令，如图 4 所示。

具体解决方案如下：

• 首先，我们创建一个 Concurrent Queue，当有信令信号传给客户端时，就放在 Concurrent Queue 里执行；

• 为了保证 Voip 信令能有序执行，我们引入了条件锁 NSCondition， 并行队列在处理 Voip 信号时，先获取条件锁，获取完毕后，我们将 isAvLockActive Bool 变量标记为 YES，然后对信号进行初步处理，初步处理完毕后 Unlock 条件锁；

• 由于 Unlock 了条件锁，队列里其他的 Voip 信令就有了处理的机会。处理时，检测 isAvLockActive 状态，如果为 YES，说明此前有 Voip 信令还没有处理完毕，则执行条件锁的 wait 方法；

当某个 Voip 信号事件完全处理完毕后，会触发条件锁 Signal， 这时，队列里其他等待条件锁的信号就可以得到处理。这时我们又返回步骤 2，直至队列里没有待处理的 Voip 信号。

总结

这次 IM 系统重构，通过底层接口分离使得 IM SDK 耦合性降低，利用面向协议设计方式使得聊天页面可扩展性增强，所以短时间内 App 内部扩展了富文本、图片、地理位置、简历、卡片等类型消息。希望通过 58 App IM 的重构历程，能给设计或改造优化 IM 模块的开发者提供一些参考。未来，我们会在如何提高页面性能和降低用户流量上进一步调优，继续完善 IM 的各个细节。

• 作者： 蒋演，58 同城 iOS 高级研发工程师，专注于 App IM 系统的架构研发以及性能优化，主导了 58 同城 App 的 IM 系统架构以及研发。
• 责编： 唐门教主（tangxy@csdn.net）
• 声明：本文为 CSDN《程序员》原创文章，未经许可，请勿转载，如需转载，请留言。

Cell

单元格，可用作展示列表信息、链接或者表单等。

Import

按需引入：

import { Cell } from 'mint-ui';

Vue.component(Cell.name, Cell);

全局导入：全局导入后不用再导入

importMint from'mint-ui'

import'mint-ui/lib/style.css'

Vue.use(Mint);

API

示例

xxx.vue：

<template>
  <div id="app">	
	<!-- 列表使用 -->
	<mt-cell
	  title="标题文字"
	  :to="link"
	   is-link
	  value="带链接">
	</mt-cell>
	<!-- 列表使用 -->
	<mt-cell title="标题" label="描述信息" is-link></mt-cell>
	<!-- 列表使用 -->
	<mt-cell title="标题" is-link>
	  <span>信息</span>
	  <img slot="icon" src="../assets/logo.png" width="24" height="24">
	</mt-cell>
 </div>
</template>

<script>
export default {
  data () {
  	return {
  		link:'//blog.csdn.net/michael_ouyang'
  	}
  },
  mounted:function(){
  	
  }
}
</script>

<style>

</style>

show：

3种列表项的格式

demo链接：http://download.csdn.net/download/michael_ouyang/9949550
使用前输入命令:
npm install
npm run dev