上一篇介绍了以数据为核心的架构服务器端，现在分享一下客户端的经验。
对于客户端而言，做的最大的改动有几点：
（1）更严格的控件化。每个设备都对应一个控件，控件带自己的Id，通过协议传达和接收该控件所有信息（协议里均带Id）。控件形成控件组（比如编码器组，屏幕组），控件除了接收某些广播信息（比如设备在线离线状态通知）外，便通过控件组与外部交互。
（2）基于数据库的信息传递。在客户端的内存里，不保存绝大部分的设备信息，包括设备名称、控制代码、设备间的路由关系等，而统一由数据库存储。客户端控件直接访问数据库。
（3）需持久化的静态信息由数据库存储是常见的，但这版本框架里，诸如某屏幕显示的信号源名称等动态信息，也借由数据库存取。为了减轻数据库访问负担，除了控件初始化时在数据库里找对应的信息外（需要以文字方式展现），在信息动态变化时会由协议广播到所有控件，此时无需访问数据库。
（4）客户端逻辑的后移。诸如路由计算、设备控件命令的拼接等，通过统一协议传递到服务器，由服务器自行运算并给客户端反馈。比如在混合矩阵模型里，通过记录路由起点和路由终点的Id，发送协议到服务器。服务器需要判断起点、终点的设备类型；然后通过核心路由算法计算路径上经历的所有设备，对最多可达五六个的设备（矩阵及编解码器、图形控制器）进行命令发送；同时更新所有设备的信号源名字展示。
架构图如下：
是不是很简单？简单到有点返璞归真了。
但从整个产品线的角度来说，简单的客户端架构是个很不错的选择。毕竟大量项目里，改动最大的便是客户端代码了；而客户端代码里，改动最大的是界面。
上图是符合瘦客户端理念的。上述架构看似简单，但各个模块的具体实现也有不少需要思考的地方。
比如控件的实现，需要有足够的灵活，以满足大量项目的复用需求；
再比如控件的层次，一些控件的继承树可以打五六层，每层都得严格划分类的职责。
然后基于控件的层次而衍生出的信号传递问题，尤其是信号反复传递的“环”的问题。比如控件组需要让组内各控件互斥；又需要将组内被激活的控件信息传递到更上层；如果信号传递机制有问题，容易让更上层将激活信息回传，导致死循环。
再如控件的信息持有问题。持有太多，信息同步和更新会有麻烦；持有太少，需传递的信息就变多，对数据库的依赖也变强。
然后是控件对数据库的访问，因为在移动端数据需经过中间件，所以控件访问数据库时是做成异步，还是同步，也是需要决策的。
再比如控制协议。为了让代表设备的所有控件向服务器传递统一格式的信息，避免控制协议的无节制扩张，需要对控制协议精心设计，使得控制协议能标明设备Id、控制意图及所有可能存在的参数信息。
但总体而言，以上架构还是比较简单的。在后续维护上，只要不断的扩充及完善控件库，便能较好的支持我们项目的需求。
至此，在我现有工作中的架构经验就基本分享完毕。希望能打开大家的思路，对想走上架构道路的诸位有所裨益。