大规模重构——重写 Instagram Feed 的经验之谈

阅读 883
收藏 21
2017-10-13
原文链接:academy.realm.io

在 Instagram 团队重写他们全新的 iOS Feed 的过程中,他们积累了大量的经验,遇到的坑无疑已经超出了他们的预料,比如说集合视图、差异化 (Diffing) 以及冗长代码所带来的危险之处。在本次 try! Swift 讲演之中,Ryan Nystrom 向我们分享了如何才能进行一次成功的重构,并且向我们介绍了 Instagram 的一个很赞的开源组件:IGListKit。


概述 (0:00)

大家好,我的名字是 Ryan Nystrom,是 Instagram 纽约的一名工程师。我们在基础框架上面做了很多很酷的工作。在过去的一年里,我一直在努力重构 Instagram 的 Feed 模块。这个过程非常有趣,从中我们获取到了很多经验。每当我去参加会议的时候,我都非常喜欢去听其他行业的经验分享,因为我觉得其他公司的组织架构和运作形式是非常有趣的。

因此,我想和大家分享一下,我们是如何重构 Instagram Feed 这个模块的。

技术债务 (1:29)

我们为什么要重写 Feed 呢?答案很简单:因为技术债务 (Technical Debt)

Instagram 已经 6 岁半了,但是底层代码仍然一成不变。如果您去搜索 git 历史并进行归类的话,就会发现有很多 Instagram 的初始代码提交。此外还有很多手动内存管理时代的东西,代码杂乱无序,简直是一团糟。这使得我们要做一些新的事情就比较捉襟见肘。

最初是怎么实现的呢? (2:05)

最开始,我们使用了集合视图。当我们在查看 Instagram 上的一个 Post 的时候,我们会看到一大个 Section,我们可以将它们分解成多个小单元格。分解的结果如下:

nystrom feed item split

可以看到,顶部有一个补充视图 (supplementary view),中间是视图单元格,然后是包含操作项的单元格,最后就是底部的那些文本单元格了。这是完全由一个名为 “Feed Item” 的数据模型驱动的。

这样我们便使用 FeedItem 来决定有多少条评论、是否要显示图片、是否要播放视频、用户名是什么等各种问题。我们整个应用是完全基于这个 FeedItem 数据模型来构建的,而这个数据模型就需要包含有图像、视频、评论等各种信息。当有人过来说:「我们想向这个 Feed 中增加一个这玩意儿」,但是我们只能遗憾地告诉他们「不行,我们没法做,因为它不在 FeedItem 这个模型里面」。

nystrom new feed item

这是一个单元格,是一位设计师设计的,并且还有一名产品经理一直在跟进这个设计,但是它里面的数据实际上是一组用户,而不是评论,因此我们毫无办法。我觉得对我们自己的团队说「做不到」是很不好的一件事。

胡乱堆砌 (3:41)

Instagram 是 2010 年的时候发布的,那个时候里面的数据还只有图片。随着时间的推移,我们便想要增加诸如视频、用户以及其他类型的数据模型。我很确定那个时候我们只是想着「改一点点就好了」,而不是选择重构,我们选择了错误的做法……因此我们只是胡乱堆砌,有功能就往上加。

好吧,这就是我们的做法。我们没有创建一系列独立的小模型,而是创建了一个臃肿模型。解析这个模型变得越来越复杂,并且极大地拖慢了我们的速度。要记住这个单元格是映射为由 FeedItem 驱动的。如果您看一下 Instagram 当中的 Feed,实际上您看到不仅仅只是一个简单的 Post,这里面包含了大量的数据信息。

我们视图控制器的任务就是获取对应的数据模型,然后将其放到 Section 当中,然后配置这些单元格(视图控制器的数目有很多个)。对于集合视图而言还有一个单独的视图控制器,继承自执行网络任务的视图控制器,而这个网络任务视图控制器继承自执行通用 Feed 的视图控制器,此外对于应用的主界面来说,同样也还有一个视图控制器。这使得这类视图控制器有四层的纵深。添加新单元格变得无比困难。

您可能会想「代码复杂了一点,可能有些时候会减慢开发速度,那么这种做法糟糕吗?」

没错,非常糟糕!技术债务开始拖后腿了。因此我们决定要严肃对待这个问题,因此我们在三个月前上线了新版本的 Feed。

Feed 2.0 (6:35)

我们的主要目标之一是解决视图控制器层叠继承的问题,我们想让 Feed 更加轻巧、简单,并且还能够让开发人员使用不同的单元格和数据模型。我们希望能够摆脱 Feed Item 这个方法,这个数据类型是完全不可控的。

差异化 (7:10)

我们首先想到了差异化操作,这个概念是创建一个包含一系列模型的数组。当我们对这个数组进行删除、插入或者移动操作的时候,就发生了值的更新。在构建基础框架的时候,差异化操作是非常有用的,但是要用在集合视图当中就非常困难。

首先,我们必须要删除旧数组当中的内容,然后重新加载数据,才能将数组当中的内容放置到合适的位置,接着基于最后的索引来执行插入操作。要做好这个操作需要一点点数学知识。

差异化操作最原始实现的时间复杂度是 O(n²)。当操作过多的话,就会发现速度被大大减缓了。我看过的大多数实现方式都会前往后台队列当中,执行一些数学运算,然后再回到前台并继续操作,但是即便这样速度仍然不够快。因为他们是用低优先级队列来解决复杂问题,那么为什么不直接在主线程上执行呢?

我们去搜索了一下解决方案,然后发现一篇撰于 1978 年的论文,作者是 Paul Heckel。这篇文章使用一个名为最小公共子序列 (least common subsequence) 的东西,使得这个问题能够在线性时间内得以解决。

基于这篇论文,我们编写了一个算法,从而能够在线性时间内找到两个数据集之间所有需要删除的内容,然后重新加载,然后执行插入和移动。这使得我们可以在主队列当中执行这个操作,这样我们便可以在集合视图上执行所有的这些更新;这对我们而言提供了一个更为简单的模型。此外,我们还想出了集合视图才能更好地配合这个算法进行工作,这个过程中耗费的时间是大家无法想象的。

执行更新 (9:35)

让我们回到视图控制器来,这时候我们已经去除了很多的内容了,我们将这些内容改写为共享对象、使用系统库等等来规避掉了。这样就不必继承这么多视图控制器了。网络归网络,诸如分析之类的主 Feed 可以变为一个共享对象。但是我们仍然还是要对 Feed 进行一些处理。

这里用到了一个我们称之为「世界」的概念,视图控制器知晓项目数组的全部信息,知道这些项目该如何添加到 Section 当中,知道这些 Section 该如何配置,知道单元格该如何填充。它将处理用户交互、日志记录、显示事件等一系列操作。

项目控制器 (10:28)

在我们创建的新基础框架当中,我们决定将这些任务进行分解。我们创建了一个名为「项目控制器 (Item Controller)」的抽象概念。实际上它是专门实现 Section 的一个小型视图控制器。

在这里,我们决定项目的数量、对单元格进行配置、返回单元格尺寸,以及处理用户交互。但最为重要的是,这里存放了所有的业务逻辑。我们也没有用什么黑科技,它就是一个集合视图,但是通过这样的分解方式,使得我们可以向集合视图当中添加任意一种类型的对象

而我们所要做的就是创建一个新的项目控制器,它会自行处理所有的逻辑。

我们此前觉得这简直是异想天开,但是我们还是将其实现了。整个团队为之欢欣鼓舞,我们将这个架构变成了我们的基础框架。

我们能给大家回馈什么? (11:26)

当我们构建完框架之后,我们意识到我们已经解决了个大问题,因此我们扪心自问,我们能给社区回馈什么呢?我们想要大家摆脱这个问题的困扰。

IGListKit (12:48)

我们将开源一个全新的框架:IGListKit(发布时间待定),这个框架会帮助您实现我上面所述的那些内容。

我们所有的示例应用和文档是完全用 Swift 编写的,此外还使用了 Objective-C 可空性、完善的注释以及泛型。这是完全适配 Swift 的,C++ 被完全掩盖住了,您将不会看到一丁点 C++ 的内容。

IGItemController (13:34)

这个框架当中最为重要的一个类就是 IGItemController 了。这就是我在一开始所提到的「项目控制器」。这里面的代码不是很多。它默认只是处理���一个带有文本标签的单元格,仅此而已。

要让这个类派上用场的话,我们需要创建一个新的项目控制器,然后让其实现 IGListItemType 协议。

class LabelItemController: IGListItemController, IGListItemType {
    ...
}

在编译时,这个协议可以确保您实现了所有必需的方法,比如说返回项目的总数:

func numberOfItems() -> UInt {
    return 1
}

在 Instagram 的主 Feed 当中,我们存放了一个包含图片、评论和动作条的动态数组。我们这里将会返回这个数组的大小。同时也要注意到,我们还有一个上下文对象 (context object):

func sizeForItemAtIndex(index: Int) -> CGSize {
    return CGSize(width: collectionContext!.containerSize.width, height: 55)
}

这样可以将这个单元格设置为屏幕的宽度,或者设置为其父容器的宽度,并且设置其高度为 55 个点。接下来就是一个全新的概念了,这与传统的集合视图截然不同。我们需要实现这个 didUpdateToItem 方法:

var item: String?

func didUpdateToItem(item: AnyObject) {
    self.item = item as? String
}

在这里,基础框架将会向您的项目控制器传递所需的模型。通过使用映射,我们可以将所有的模型与项目控制器建立映射关系。在这种情况下,我们得到了一个项目之后,我们可以选择将其转换为字符串,然后存储到一个实例变量当中。接下来我们就可以读取这个实例变量,然后在对应索引的单元格项目当中,对这个单元格进行重用,然后设置标签上的文本,然后再将这个单元格返回,这样就和集合视图的数据源类似了。

我们已经移除了重用标识符的概念,并且我们还完全消除了注册单元格的需求和提供补充视图的需求。因此,这就是这个控制器所做的工作了。那么我们该如何去使用这个项目控制器呢?

IGListAdapter (15:42)

这里我们推出了 IGListAdapter 的概念:

//MARK: IgListAdapterDataSource

func itemsForListAdapter(listAdapter: IGListAdapter) -> [IGListDiffable] {
    return [
        "Foo",
        "Bar",
        "Baz"
    ]
}

func listAdapter(listAdapter: IGListAdapter, itemControllerForItem item: AnyObject) -> IGListItemController {
    return LabelItemController()
}

它将会把相应的数据、所有的项目控制器以及您的集合视图糅合在一起,让它们能够共同协作。为了要使用这个功能,我们需要连接数据源。

在第一个方法当中,我们仅仅只是返回了一个数组。现在它们当中的值全都是字符串。这里实际上可以是任何值。注意到返回类型实际上是 IGListDiffable。我们已经为这个协议提供了标准的实现,因此大家无需去关注太多内容。不过,您仍然可以重写并扩展这个协议,以便实现自己的处理操作,从而实现更灵活的差异化操作。然后还有另外一个方法,对于指定的项目,我们可以返回对应的项目控制器。这里我们只返回了相同的基础项目控制器,这里面只有一个标签。

假设当我们在等待一个网络请求返回数据的时候,我们想要添加一个指示器。这样我们可以创建一个令牌对象(这里只是一个名为 spinToken 的 NSObject 对象),我们可以将其放到数组的中间位置。由于这里是一个协议,因此我们可以放上我们所期望的任何类型的模型对象。接下来,当框架让我们提供项目控制器的时候,我们需要检查「这个项目是否是 spinToken?」如果是的话,我们就返回这个新的 SpinnerItemController。否则就保持原样:

func listAdapter(listAdapter: IGListAdapter, 
            itemControllerForItem item: AnyObject) -> IGListItemController {
    if item === spinToken {
        return SpinnerItemController()
    } else {
        return LabelItemController()
    }
}

这样便会在我们的单元格中间显示一个指示器:

nystrom spinner

这看起来可能不是很 exciting,但是我其实对我们搞的这个大新闻很是骄傲。试想假设我们提供了一个 UISearchBar。当用户输入了文本之后,我们就可以实时更新搜索结果了:

func searchBar(searchBar: UISearchBar, textDidChange searchText: String) {
    filterString = text
    adapter.performUpdatesAnimated(true, completion: nil)
}

因此在这个 searchBar 委托方法当中,我们向实例变量中存放了用户搜索的文本,然后调用 performUpdatesAnimated 方法。这将告知框架去获取新的项目,然后执行差异化操作,更新集合视图。

我们同样可以对数组进行匹配:

let words = ["Foo", "Bar", "Baz"]

func itemsForListAdapter(listAdapter: IGListAdapter) -> [IGListDiffable] {
    return words.filter { word in
        return word.containsString(filterString)
    }
}

我们对字符串数组进行匹配操作,然后将匹配的结果返回。这个方法是一个数据源方法,因为只有当您通知框架进行更新的时候这个方法才会被调用。它会自动执行插入、删除、更新等所有在集合视图上发生的操作。我并没有为这个集合视图撰写任何一条代码;我只是配置了下单元格、项目控制器,然后通知适配器 (adapter) 进行更新就行了。所有的动画和更新操作都在框架内部执行了。

为什么要使用 IGListKit 呢? (19:15)

假设我有一个很简单的应用,其中有一个很简单的表视图,我调用了它的 reloadData 方法。使用 IGListKit 有什么好处呢?其实,我建议当您遇到像 Feed 一样,视图当中有多种数据类型的时候使用 IGListKit 会更好。如果您的 Feed 非常复杂,并且也讨厌去处理那些恼人的整数枚举的话(我就是这样的人),那么 IGListKit 正是您的选择。

如果您希望有一个快速、不会发生崩溃、同时拥有更新动画的 Feed 的话,那么您也可以选择 IGListKit。这同样也会鼓励您撰写可重用的功能组件,将您的单元格和项目控制器从视图控制器当中分离。

我可以在某个地方编写一个项目控制器,然后在其他视图控制器当中使用,因为它们不需要去考虑其父容器的情况。同样我也很高兴,我不用再去调用那些烦人的 performBatchUpdates 或者 reloadData 方法了。

您可能会想「Instagram 编写了这个框架,那么我该不该去使用它呢?」在应用发布的 15 分钟后,我们在全球范围内处理了 3,900 万次差异化操作,而这些操作没有一例发生了崩溃,并且这些操作都是在主线程进行的,也没有卡顿的现象发生。

该在何处使用它呢? (21:13)

这整个项目源于我们期望重写我们的 Feed。现在我们的「Explore」页面、「Activity Feed」,甚至通信模块当中的那些复杂单元格和交互也使用了 IGListKit。我们一个月前发布的 Instagram Stories 这个产品,也使用了这个框架,并且是完完全全使用 IGListKit 构建的。我们当然非常赞同大家来使用这个框架。因为这正是我们未来应用也要使用的。

IGListKit 即将到来

我在这儿期望能和大家分享一些 Instagram 中工作的一些故事,我希望大家能从中学习到一些知识,并且将这些知识应用到您所在组织的应用当中。我真的很高兴看到大家使用 IGListKit 构建自己的应用!

评论