一、 什么是弱业务服务池
根据iOS端目前的工程化设计蓝图，我们将iOS的app结构，从代码的组织形式上分为四层结构。 其中的基础层和核心层的建设已经基本完成，接下来的主要工作是弱业务层的构造。而弱业务服务池就是对弱业务层中各类业务的统一规范和抽象。根据实际情况发现，弱业务的共性主要是需要统一进行生命周期的管理和集中的对账户信息的依赖（uid）。因此弱业务池的核心部分就是对以上两点的实现。
二、 为什么要拆分弱业务，如何拆分
弱业务本质上就是复用性足够高的业务，在移动端中，UI基本很难复用，Controller内的业务逻辑与表现给用户的功能的联系过于紧密，只有数据模型相关的业务与对应的处理逻辑相对通用。因此对于多个业务场景共用的数据和数据流的处理可以进行抽象，根据实际功能范围设计做“服务组”的划分。
一个设计完善的弱业务层可以解决很多工程上的问题，例如：弱业务层的代码复用性比较高，并且可以在多业务线中快速移植；弱业务层由于每个服务功能单一，给出参数就有对应结果，因此比较适合做单元测试。因此根据公司的实际业务情况，和现阶段的工程化实施目标，制定了以下弱业务层的设计方案：
如图所示，弱业务层使用WBServicePool做统一的生命周期管理(construct\destroy)，pool内置userCenter作为公共依赖。
每一个服务组使用WBServicePool规定的模块协议WBServiceAbstructProtocol的子协议来做功能规范和约束，例如聊天服务组WBServiceChat使用WBServiceChatProtocol协议作为一系列service的约束。私聊模块作为聊天服务组的一部分，就需要作为实现WBServiceChatProtocol协议的实体类。
聊天服务组WBServiceChat内包含了多个功能模块，每个功能模块只包含单一职责，例如messagePersonal只处理私聊消息，commandPersonal只处理私聊命令等。每个模块都与WBServicePool通过self.service来联系。服务组只提供抽象接口，不提供实际功能。这样服务池就建立完成了。
具体的service的实现则根据具体的弱业务需求，一般来说就是将服务端给出的数据进行处理和回调拼装，这一块可以各显神通，根据具体场景使用最合适的实现方式。
service的设计有以下几点要求：
- service遵循单一功能原则，模块之间最好通过WBLinker来调用，避免出现模块耦合
- service的接口尽量设计的简洁明了，回调方式尽量使用代理或者多播代理，避免出现对象生命周期管理问题
- service的接口参数尽量使用通用数据模型，如字典流，或者下沉到service层的数据模型，禁止使用纯业务模型对象作为参数
- 同3，尽管service-servicepool的关系是依赖倒置的，但是service禁止对强业务有任何依赖
开发service时须遵守以上几条规则，避免造成架构污染。
三、 弱业务层的实现细节
实现细节我们以本次改造的重点WBServiceChat为例，自底向上进行梳理：
- 聊天服务的基础功能是MQTT消息和数据库存储，因此核心层提供了
WBMessageCenter连接池和WBPersistenceDatabasePool数据库池。 - 继承
WBServicePool服务池的service基础服务协议WBServiceAbstructProtocol，构造出符合聊天场景的WBServiceChatAdaptorProtocol。WBServiceChatAdaptorProtocol中包含了mqtt相关的收发消息和订阅状态处理的方法。 - 遵循
WBServiceChatAdaptorProtocol实现了WBServiceChatAdaptorchat service基础类，基础类从mqtt连接池中获取所需的topic，实现了基础的消息处理，并在特定方法进行回调，供子类重写。 - 以
WBServiceChatMessagePersonal为例，继承WBServiceChatAdaptor，实现要求重写的回调方法，并提供多播代理接口转发给强业务。并根据弱业务需求使用数据库池获取到对应的表，这里由于目前业务中私聊消息与私聊数据库的处理关联性很大，暂时没有做隔离，理论上是应该将数据库处理相关代码隔离成WBServiceChatDatabasePersonal服务对象的。 - 强业务层直接引入
WBServiceChatMessagePersonal，调用其通用接口+service获取服务池池中对象，直接使用该服务对象提供的接口获取数据或者对数据进行处理即可。这样强业务层通过弱业务层的隔离，将感知不到所有的下层实现，只对service产生依赖，避免了跨层访问带来的依赖难以梳理的问题。 - 强业务层在这里只感知具体的service模块，而不需要知道service pool。service pool对service的生命周期管理是通过基础协议的通用方法实现的，当service pool的核心部分
WBServiceUserCenter中的销毁命令开始时，service pool就开始对池内所有的服务发送destroy消息，并销毁其指针。因此强业务层在使用service对象时最好不要持有service对象的属性，否则容易造成service对象生命周期延长的问题。
四、 弱业务层改造的实施范围
对于弱业务层改造来说，目前只完成了基础服务池和聊天服务的建设，后续可以逐渐将所有弱业务都抽离进来，通过WBLinker进行组件间调用，根据目前的规划，通知处理、游戏容器、API接口等都属于弱业务的范畴，弱业务层的改造以服务组为单位，后续改造计划以排期为准。