启动阶段的数据同步
但凡是社交类或带有一点社交属性的App，其不可避免的一项常规工作就是「好友数据的维护」，常见的好友数据包括但不限于：
- 好友资料更新
- 新增好友申请
- 好友关系变更(密友/拉黑/删除等)
- ...
当发生诸如此类的好友数据变动时，通常要求能将变动及时同步到用户端。否则一旦同一好友链上的多个用户的信息不一致，就有可能出现很多莫名其妙的现象。
用户在线时，可以考虑直接通过长连接通道下发「控制消息」(如好友资料更新通知、好友关系变动通知等)，主动通知客户端进行相应的数据更新操作。这种做法可以进行较细粒度的更新，一方面更新更及时，另一方面也可以减少下次数据同步的数据量。
用户离线时，则需要在用户下次启动App后，主动请求同步好友接口，用于同步离线期间好友数据的变化。
全量更新 VS 增量更新
数据同步一个比较粗暴的做法就是「全量更新」，即每次都拉取完整的好友列表，把本地缓存的好友数据全部清空，再重新插入一遍。
这种做法虽然也可以实现更新，但产生的后果就是——除非在产品层面上做了好友数量的限制，否则当好友很多时，可能会导致每次请求的数据量巨大，不但导致请求速度变慢，请求失败几率也会相应增加。虽然可以采用分页拉取的方式进行优化，但整体的体验还是不太好。
另一个比较合理的做法就是「增量更新」，即仅对该产生变化的那一部分好友数据进行更新，变化了多少接口就返回多少，没变化就不返回。相对于全量更新，能显著地减少请求的数据量，提高请求响应的速度。
增量更新的实现
要实现数据同步的增量更新，只需在「同步好友接口」的请求上新增一个「version」参数。
该参数代表的是服务端所维护的相关好友数据的版本号，客户端每次请求接口时都需要携带此参数，默认可传0，表示是首次请求，此时进行的是全量更新。
当指定用户的好友数据有变动时，服务端所维护的版本号也会随之更新。
服务端每次都会比较两个版本号之间的数据差异，返回增量的好友数据，以及最新的版本号。客户端获取到好友数据进行更新的同时，需要在本地保存此版本号，然后在下次同步好友时原样传递。
同步好友接口
接口地址：/v1/friends/sync/{version}
请求参数：
| 参数名称 | 参数说明 | 是否必须 | 数据类型 |
|---|---|---|---|
| version | 客户端本地保存的好友数据的版本号 | true | number |
响应参数：
| 参数名称 | 参数说明 | 数据类型 |
|---|---|---|
| version | 服务端所维护的好友数据的版本，需要在客户端本地保存此版本号，然后在下次同步好友时原样传递 | number |
| friends | 好友列表，如果客户端本地版本号与服务端的版本号一样，则此列表无数据，为null，表示客户端的好友列表已是最新；如果没有任何好友，则为空数组 | array |
