UITableView SingleCodePath

1. 起因

2. 设计与实现

3. 拓展

1. 起因

List 是开发中最常见的一种控件，由于业务迭代频繁，所以，列表的使用会更多。但是，列表中会有许多重复的逻辑。比如，数据源和操作事件的回调等。将这些通用的代码逻辑抽象出来，不但有利于规范代码路径，同时也是为 controller 减负的手段之一。我们目前项目中用到了 DJTableView 做这件事情。但是，相对于 Swift 项目来说，DJTableView 的实现方式和接口调用上都不十分友好。并且，使用到目前发现了一些问题。

<1> 只是对 tableView 各种系统方法进行了一层封装，并不关心实际的数据传递刷新，将所有的行为都交给使用者。
<2> 会多一层 data -> row 的封装，对于数据源数量很大时，会创建很多这样的封装。比如，读取很多相册中的图片。
<3> 过度依赖继承

Github上处理 List 比较流行的应该是 IGListKit，主要实现是有一个 adapter，将自定义 list 和当前 controller 注册给它，再将 controller 注册为数据源，通过代理回调数据。这里，在回调方法中，需要返回继承自 sectionController 的子类，在子类中，有一系列方法需要重写。对于 cell 只需要实现数据 protocol，就会在合适的时机被回调更新 cell。IGListKit 无论从代码逻辑还是接口封装都做的很棒，也始终贯彻面向协议的编程。但也存在一些问题。

<1> 没有支持 tableView issues #584
<2> 对 swift value type 只能通过 wrapper 的方式实现 issues #35
<3> 没有发现对 swift 中形为 [[ListDiffable]] 的支持，语法转换后只能是 [ListDiffable]。

以上两者尽管在接口上都对系统的 tableView 或 collectionView 有了完全性的封装，IGListKit 还专门针对 Swift 提供了支持。但是，Swift 是强大的。因此，针对此问题，我尝试用 more swift 的方式解决一下。

在 Swift 中更加鼓励 Protocol + Value Type 的方式，使用 Protocol 应该是目前用组合代替继承的最佳实践。关于继承的一些可能的问题，我引用 WWDC 2015 - 408 Protocol-Oriented Programming in Swift 中的描述来简单阐述。

Inheritance Intrusive

- One superclass
- Single Inheritance weight gain - bloated
- No retroactive modeling - define not extension
- Superclass may have stored properties
   - You must accept them
   - Initialization burden
   - Don’t break superclass invariants
- Know what / how to override (and when not to)

关于值类型的种种好处，像是线程安全，通过写时复制提供良好性能，便于编译器进一步优化等。

这次探索主要的灵感也来自于 WWDC 2016 - 419 Protocol and Value Oriented Programming in UIKit Apps 中的 single code path 概念，强调的是唯一路径进行model与view的更新，增强代码的可维护性和可拓展性，也便于定位 bug。而且 protocol 的设计更加倾向于限制某些行为的路径，让大家在这些行为上达成共识，这样在跨业务合作开发时，能减少很多阅读别人代码带来的负担，也更利于整个 app 各种行为的统一。像 UI 组件化做的也就是类似的事情。

2. 设计与实现

<1> 针对特定的行为，抽象 protocol
<2> 提供对 tableView 的统一管理
<3> Demo 接入

图 I 部分

Protocol Reference
ListDiffable - 唯一 id 与判等方法
DataProtocol - 定义 data
ListProtocol - 定义 view
SingleCodePathProtocol - 定义更新 data 与 view 的唯一路径

图 II 部分

Protocol Reference
ListGodContext - dequeueReusableCell
ListSectionProtocol - 定义 dataSource 与 delegate 的各种行为
ListGodDataSource - 获取 data 与 cell.type

定义了 ListGod 作为 tableView 的 dataSource 与 delegate，统一抽象对 tableView 的数据管理与事件回调。这里，将 section 抽象为 ListSectionProtocol，由 struct ListSections 统一管理，ListSections 实现了 subscript、ExpressibleByArrayLiteral、Sequence、Collection，用于获得标准库的各种便利方法。

ListGod 实现了 DataListProtocol，所以在实现了 SingleCodePathProtocol 与 ListGodContext 之后可以直接使用默认实现。

ListGodContext 想要获取 reusableCell，需要保证 cell 是用 identifier 注册过的，因此有了 IdentifierProtocol。最后在 extension UITableView 中提供注册和 dequeue 的泛型方法。

SingleCodePathProtocol 想要统一 model 与 view 的更新，首先需要保证 model 和 view 的一一对应，这在构建 tableView 的时候已经构建好了。之后，需要计算出 oldModel 与 newModel 之间的 diff，这个 diff 是数据变化的最小集合，再通过 view 提供的接口更新数据，这整个过程都被统一在 SingleCodePath 中。对于 tableView，映射的更新对象是 IndexPath，相应的行为是插入、删除、更新、移动。这里，我引用了 IGListDiffKit 来计算 IndexPathDiff。最初的版本是直接使用 IGListDiffable，但是后来因为其对值类型支持的缺失，所以用 swift 重写了这个算法。

IGListDiffKit

<1>
有序用
ListDiffing
mInserts: old Data 中未出现
mDeletes: new Data 中未出现
mUpdates: 对于 index 和 originalIndex，在 new old Data 中 key 相同，但指向的对象不同
mMoves: 对于相同 key 的 data，在 new old 中 index 不同

无序用
Set
inserted = to.subtracting(from)
deleted = from.subtracting(to)

<2> 原理

图还是比较自解释的。除去边界判断，主要流程是：
i. 顺序遍历 newData，构建 VectorNew<Record>，增加 newCounter，push(N)
ii. 逆序遍历 oldData，构建 VectorOld<Record>，增加 oldCounter，push(originalIndex)
iii. 顺序遍历 VectorNew<Record>，与 oldData[originalIndex] 判断 Updated，
VectorNew<Record>.record.index = originalIndex，
VectorOld<Record>.record.index = i
iv. 顺序遍历 VectorOld<Record>，mDeletes
v. 顺序遍历 VectorNew<Record>，mInserts，mUpdates，mMoves

<3> 性能
容器选用： unordered_map & vector
函数调用： C - struct func
时间复杂度: O(n)

图 III 部分

给 listGod 对应的 tableView 和 data，并通过实现了 ListSectionProtocol 的 ListSection 返回自定义的 Cell.Type。在 cell 中用回调的 data 填充完后。只需要在数据变化时，调用 reloadDiffableData()。就可以免去管理 tableView 的繁琐及唯一刷新 data->view 的路径。

这里有三个例子，一个来自 IGListKit，两个来自 session 220 2019，都可以用 listGod 无缝对接。

3. 拓展

Layout protocol
State protocol
Generic diff algorithm - IGListKit (issues #694)