UITableView 处理feed流数据同步问题

feed流 其实是两个词，和在了一起

首先说feed（其实是一个很装逼的词）直接翻译叫饲料，其实是把用户都比喻成爱吃东西得某种动物，不断的给他喂食，满足他的需求，wiki百科上定义是一种数据格式，网站可通过它将最新信息传播给用户，用户能够订阅网站的先决条件是网站可提供持续更新的信息。消息来源受到博客及新闻网站的广泛采用，因为此类型的网站经常更新内容。

简单说来，就是一种信息单元格，你也可以理解为某一个卡片啊，一段文字啊，一段视频啊，一段音频啊，等等的信息单元，可能包含，这是谁的，有多少人看，什么类型消息等等

一个feed 就是一个信息单元，一个用户想看的有用信息单元，一个满足用户需求的信息单元（我的定义！）

第二个词，流，就是他的呈现形式，就是这个信息怎么呈现的，大多数的都是用时间排列的形式呈现的，就是上面有人回答timeline形式，还有其他的呈现形式，就不多做赘述了

数据源同步问题

删除一条数据（主线程）--> 数据源 < -- LoadMore (子线程) （涉及到了多线程对共享数据源的一个同步问题，面试的时候可能会被问到 如何解决这种tableView在多线程环境下的去修改或者访问数据源这样的同步问题）

并发访问、数据拷贝

20200309111956837.png

1、比方说现在有主线程和子线程，我们在做数据拷贝的时候，一般在主线程当中。
2、拷贝之后呢会把拷贝的结果给子线程来使用，同时在子线程里进行新数据的网络请求、数据解析和预排版等。
3、 在子线程操作的同时，我们在主线程删除一行数据（为了防止和子线程数据不同步，需要记录删除操作）、reload UI后，此条数据会消失不见，如果还有时间，主线程会做other work一切其他的操作。
4、子线程将要返回数据，更新主线程UI的时候，同步删除操作，在子线程里面把拷贝过来的数据也做一次删除的操作
5、然后回到主线程去reload UI。

串行访问

2020030911300621.png

比方说有主线程和子线程，既然是串行访问，就要使用到GCD当中的一个串行队列。
1、此时比如说子线程正在进行网络请求、数据解析，然后它会把网络数据请求过来的一部分在串行队列当中进行新增数据预排版，当然这一过程是在子线程当中进行的。
2、如果在这一过程当中，在主线程里面删除某一行数据的话，需要以同步的方式在串行队列当中进行处理，此时如果子线程正在进行新增数据预排版等操作的时候，那么主线程要等一小会Waiting，然后在串行队列当中,前一个block任务执行完成之后，然后去同步主线程发送的任务数据删除。
3、把数据删除同步之后，再回到主线程reload UI 。这样就能保证无论是主线程还是子线程，对tableView的数据源的操作都是在串行队列中进行的，就可以保证数据的一个同步的问题，避免UI刷新错乱的一个现象。

总结：两种方案各有利弊，比如②串行访问方案，要求在子线程处理任务特别耗时的时候呢，我们某一个删除动作可能有一定的延迟。对于①并发访问、数据拷贝来说呢，有数据同步的一个操作（记录数据删除的一个动作），然后我们还需要大量数据源的一个拷贝，内存的开销是有一定的问题。所以应该根据实际业务选择哪种方案。