UITableView SingleCodePath

字数 1649阅读 16

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 概念,强调的是唯一路径进行modelview的更新,增强代码的可维护性和可拓展性,也便于定位 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,所以在实现了 SingleCodePathProtocolListGodContext 之后可以直接使用默认实现。

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)