HWUI源码剖析（一） - 渲染中RenderProxy视角看一种很有用的编程模式

概述

实际的工程项目中，往往都是多线程编程，也就是必然有某些业务逻辑或者功能要运行在特定的线程，比如android开发中常见的IO线程，UI线程，Render线程，这样会涉及从线程A向这些工作线程通信或者函数调用的代码编程，具体实现上可以有多种多样，但是他们的核心思想其实都是一致的，Android Handler/Looper视角看UI线程的原理_nginux的博客-CSDN博客

这篇文章中介绍的Looper/Handler机制其实就是很精妙的一种，其他的具体编程也往往跟这种思想是一致的，只是根据不同的业务场景，编码形式上面稍作改变，本文将介绍的是阅读Android HWUI中RendProxy和DrameFrameTask以及RenderThread源码的一种类似的编程模式。

业务场景及设计思想

假设我们的工作的业务模型描述如下：需要在线程A处理各种业务逻辑，那么就需要一个类实现一些接口类A来向B线程发送消息，线程A在没有消息的时候休眠，有消息之后取出处理，这里面涉及几个核心问题：

1. 接口类A怎么给线程B发送消息，包括重要参数传递，以及拿到返回值。
2. 线程B怎么做到没有消息时候休眠，有消息之后处理，这里面最重要的是线程B的收消息处理的实现代码，是否要跟消息发送方耦合（比如代码上要知道发送消息的ID，参数类型等）。

上述编程模式的代码实现上，往往我们成为接口类A为xxxProxy，相应的android hwui中名字叫做RenderPrody；线程B必须有一个线程循环体，不断取出消息并处理，具体到这里，由于是函数调用，基于面向对象的编程思想，这里的”消息“我们可以封装程一个类对象，android hwui中这里叫做：RenderTask，由于这个消息必须”可执行“，所以这个RenderTask得具备一个run()函数，同时基于多态的思想，这个RenderTask的run()可执行是个基类接口，因为具体”可执行“的任务可能有多种类型，比如渲染，函数调用等，所以同时可以定义一个函数调用的RenderTask，android Hwui中叫：MethodInvokeRenderTask，由于函数调用包括：函数体，参数和返回值，所以MethodInvokeRenderTask类中必须有表示函数体，参数和返回值的成员变量。

上面的设计模式有一种好处就是：把整个函数调用的执行最终封装成一个函数调用，这样在Proxy里面把对应的函数指针封装到类MethodInvokeRenderTask中，具体在线程中循环取出”消息“(Task)只要执行对应的函数体就好了，相对比还有一种实现模式类似Looper/Handler：向线程B发送消息消息的时候，给”消息”按ID分类，那么B线程收到处理的时候，按ID分别实现对应的处理函数，整个是不是特别类似Looper/Handler。而本文介绍的模式不需要显示按ID来实现，只要四号线一个函数处理实体就好了