作者：蒋文豪(四点)

音讯客户端计算的复杂性

在客户端的设计中，个别的分层会至多蕴含上层的数据服务层和下层的 UI 层，上层的数据模型次要由所在畛域决定，绝对独立、稳固，而 UI 则更多变，且会对多种数据进行组合。因为 UI 的绝对多变性与模型的绝对稳定性，在数据层和 UI 之间，就须要对数据进行若干的解决能力交给 UI 展现。 比较简单的状况比方将原始数据的工夫戳转换为 PD 要求的字符串，如果波及到对不同数据进行关联、分页加载、变更计算，这部分数据处理逻辑就会比较复杂。

音讯作为富客户端，这部分逻辑非常复杂，加上状态的存在，能够说是音讯客户端中最简单的逻辑之一，这种简单次要体现在这些维度：

1. 本地局部数据：客户端只存局部音讯数据，获取数据时本地数据不全须要再异步申请服务端，还须要反对下层指定申请策略，这使得接口无奈采纳 request-response 的模式，必须应用流式接口，数据回调和后果回调的拆散，以及屡次数据回调，减少了解决逻辑的复杂度；
2. 反对变更同步：除了被动拉取，会话音讯数据须要反对变更的推送，且对于所有的变更，须要保证数据（包含缓存和 UI 展现）的一致性；
3. 多个数据起源：因为历史的起因，音讯的同一种数据（比方会话）存在多个起源，因而须要申请屡次，将屡次数据回调合并，处理错误，还要尽量保障加载速度。通过泛滥同学的致力，手淘和千牛中下掉了 OpenIM、DT 两个数据源，明天用户在手淘和千牛中看的会话和音讯，仍然有 BC、CC、IMBA 三个起源；
4. 多种数据聚合：UI 展现须要把会话、音讯、Profile（头像昵称）、群、群成员信息以及其余业务数据进行聚合，把相干的多个不同数据依照不同的规定聚合在一起；
5. 反对分页申请：总的数据量比拟大，须要通过分页机制加载，除了规范的分页加载之外，还要反对定位到某条音讯从两头开始加载，这就呈现了双向分页加载，以及 进入和退出 两头加载时的状态转换和异样解决；
6. 多条数据合并：因为业务的须要，音讯之间存在更新和替换关系（比方同一条订单的物流状态更新），拉取的新数据要批改已存的音讯状态数据，而非仅仅增加在头部或尾部，新的音讯会导致已有音讯的更新以及在数据结构中的地位变动；
7. 数据结构简单：音讯存在列表、树两种 UI 状态，对应的状态也有两种状态，对于这些数据结构的变更计算逻辑比较复杂，对于树来说，还须要反对虚构节点计算和构造动态变化。

这块逻辑在音讯客户端波及会话、音讯、profile、群、群成员、关系等所有外围服务数据模型，总计大概 25000 行代码，占音讯总代码的 8% 左右，是外围的数据处理。因为这些逻辑很容易耦合在一起，造成一些高维的逻辑，体现为大量的条件分支和递归嵌套，这种高维的逻辑很难写，也很难保护，并且占据了不少包大小，因而有必要对这些逻辑形象和简化。

指标

1. 在不同的模型、不同的接口和类似的逻辑之上再建设一层形象，对立客户端的数据处理；
2. 将高维的数据处理逻辑简化为一个更加清晰的解决模型，代码量降落 60%；
3. 实现数据处理的双端统一。

音讯数据处理过程剖析

通常会将客户端划分为数据服务层、逻辑层、UI 层三层，这部分数据获取和计算会被归到逻辑层。这里的问题在于，数据服务层对应于畛域定义，UI 层对应于渲染、动画和交互事件处理，这样逻辑层很容易变成一个缝合怪，数据申请、数据转换、上下文保护、异步解决、递归逻辑、状态治理、变更同步，所有不属于另外两层的局部都会被扔到逻辑层，导致逻辑层的臃肿。

下图左侧是这个处理过程的工作内容和上下游，右侧为数据拉取和变更解决的数据流向和计算过程：

能够看到，将这部分数据处理仅仅定义为逻辑是过于宽泛的，不利于针对性的优化，因而有必要进行深刻的剖析和钻研。

在对会话、音讯、profile、群、群成员、关系 6 大外围数据处理链路进行演绎、合成、剖析和综合之后，咱们能够将数据处理过程简化为如下的过程：

1. 申请每个通道的 会话 \ 音讯 数据，并将屡次后果回调合并为一次后果回调，解决屡次数据回调，申请会话 \ 音讯对应的 Profile、群、群成员、关系数据、业务数据；
2. 建设会话 \ 音讯 和 Profile、群、群成员、关系数据、业务数据之间的 关联关系，生成聚合数据，并解决聚合数据之间的依赖、优先级和缓存一致性；
3. 将数据转换为数组 \ 树形构造，反对申请来的数据与数据结构中已存的数据进行替换、更新合并计算，反对树结构和虚构节点的动静计算，反对 UI 部分更新；
4. 响应各种数据的增删改等变更事件，依据事件处理计算变更和后果，保证数据的一致性；
5. 在进入和退出两头加载时，解决各种数据缓存、关联关系、加载信息的正确性；
6. 反对非凡逻辑，如实时新数据不依照工夫排序，而是间接增加在头部或尾部；
7. 两头每个逻辑的异样解决、超时机制、线程同步、上屏工夫优化、日志、监控等逻辑。

咱们能够将这些逻辑分为两类：

作为计算的逻辑

对应于下面的过程 2、3、4、5、6。

如果咱们将这块逻辑看做黑盒，关怀它的输入输出和性能，能够得出 这块逻辑的外围工作是将各种各样的输出数据转换为特定的输入数据，这完满的对应着计算的概念 的论断，即：

基于计算的概念，能够将这段计算过程形式化地形象为一个函数 f，从而实现对状态计算的形象，上图很直观的体现了入参为输出和以后状态，输入为新的状态和后果：

f :: (Input, State1) -> (State2, Result)

来剖析一下函数 f 的入出参和模式：

第一，这里的 Input 能够能是拉取回来的数据，也能够是增删改等数据变更，或者是音讯已读等明确的事件。这里咱们能够通过定义插入、更新、删除三个来对立所有的事件，因为所有的事件逻辑上都必然能够惟一的映射到这三个事件上（只管实际上，因为局部服务不具备计算变更细节的能力，咱们还反对了 RemoveAll 和 Reload 两个事件）。

第二，联合高阶函数，Input 实际上曾经决定了这个函数的模式，即对于一个数据插入事件，其对应的 f 必然为 \state -> insert someData into state 的模式，即 Input 曾经蕴含在 f 的实现中了，因而能够将函数 f 进一步简化为：

f :: (State1) -> (State2, Result)

其中 f 的模式由输入的事件决定，这样就失去了一个十分简化的函数形象。

第三，下面的剖析还能得出一个推论，即 事件和函数是等价的（能够相互转换），这使得咱们能够通过处理事件来实现对函数的解决，从而能够通过数据的解决来优化计算的性能，能够看到，数据和过程边界的突破赋予咱们更强的能力。

第四，对于 State 参数，须要蕴含聚合后的数据，因而须要解决数据的关联，个别的，咱们能够将数据的关联场景形象为 一个主数据对应多个从属数据 的模式，通过定义一个 pair 函数来进行关联关系的判断：

pair :: (mainData, subData) -> Bool

这样就能够通过注入 pair 函数来实现主数据和从属数据的关联，而后将有关联关系的数据进行聚合。

第五，State 还波及数据 \ 树形构造计算，这里在不同的场景是不一样的，能够形象为一个 DataStructure，定义增删改查接口，而后在不同的场景应用不同的 DataStructure。

作为结构化数据获取的逻辑

对应于下面的过程 1、6。

这部分逻辑的作用是会话音讯 Profile 等数据的获取和变更事件监听，因为 6 大服务的接口各不相同，之前的实现是一一对接。通过形象之后，咱们能够 通过定义具备拉取接口和变更接口的 Inject 来实现这部分逻辑的形象，这属于规范操作，不再赘述。

这部分数据获取的第二个特点是申请的平行散发和垂直组合，举例来说，有多个通道决定了数据申请时须要平行的申请每个通道，每个通道的申请则依据不同的申请策略和每一步的回调数据决定下一次申请（这里与规范的 Future/Promise 的区别在于，Future/Promise 前后步骤的工作是不同的，前面的逻辑须要后面的数据，这里前后步骤的逻辑雷同，可能上一步申请本地，下一次申请远端，因而能够比 Future/Promise 更简化）。

如果不进行形象，这里是一个至多三维的逻辑，即对于多个通道的多个步骤进行主数据的获取，而后对获取的主数据再获取从属数据，逻辑会写的非常复杂。这里的关键在于每个通道的申请，每个步骤的申请都是十分类似的，次要是 屡次申请的构造不同，并且数据申请的构造由参数和数据决定，因而能够把它称为结构化数据获取，即这里能够通过对申请构造的形象进行简化。

能够定义出结构化数据获取工作平行和垂直组合的外围函数：

dispatch :: [param] -> [task]\
compose :: strategy -> task**

其中 dispatch 函数对应于 Rx 中的 flatMap，不过因为手淘 iOS 没有集成 RxSwift 和 OpenCombine，官网的 Combine 框架要 iOS13 之上能力应用，因而只能本人实现一个轻量的。

这样通过 dispatch 和 compose 将工作进行结构化组合实现工作获取的形象和简化。

技术计划

核心技术计划

外围模块：

1. MergeDispatcher : 实现数据获取的结构化，并将数据和变更对立为变更，解决所有的异样；
2. Calculator : 实现主数据和从属数据的关联和聚合，计算的多线程同步，变更上报；
3. DataStructure : 进行主数据的构造计算。

此外，Inject 为计算提供申请接口和变更事件，为所有数据的注入点，下层通过 ModelService 获取计算后有聚合数据形成的数据结构，以及变更事件。

调用关系与数据流向

ModelService 会应用初始化 DataStructure、CalCulator、主数据、从属数据的 Inject，并用来初始化 MergeDispatcher

1. 当 UI 须要数据时，调用 ModelService 的 load 接口；
2. ModelService 间接调用 MergeDispatcher 的 load 接口；
3. MergeDispatcher 平行调用主数据 Inject 的 load 接口，在每次回调主数据时，调用从属数据 Inject 的 load 接口申请从属数据，依据场景执行对应的超时逻辑，将主数据和从属数据给到 Calculator 进行计算，超时后的数据也持续给到 Calculator 进行计算；
4. Calculator 执行计算的多线程同步，更新主数据、从属数据、关联关系的缓存，生成聚合数据，并将主数据给到 DataStructure 计算构造，而后将返回的全量和变更进行上报；
5. 数据结构接收数据后，对以后状态（数据结构）执行增删改操作，并返回对应的新状态和变更数组。

技术成果

最终，咱们实现了 计算和数据获取的拆散 ，计算过程全副在 Calculator，数据获取次要在 MergeDispatcher，两局部独立实现，不再耦合，将逻辑档次从原来的模型数量 接口数量 数据结构 降为 事件数量 数据结构，解决模型十分清晰，且实用于任意模型。

针对计算过程，逻辑上形象出一个高阶计算函数 f :: (State1) -> (State2, Result)，这个函数模式上非常简单，却紧紧抓住这种简单状态计算的实质，让咱们得以对立计算过程，整个计算过程的正确性有齐备的实践根底，后续新增模型不会减少计算逻辑。

针对数据获取，咱们将数据类型化为主数据和从属数据，并针对由申请的构造进行形象，实现了所有的数据获取的对立和简化。

关注【阿里巴巴挪动技术】微信公众号，每周 3 篇挪动技术实际 & 干货给你思考！