在新浪微博的app中，从别的页面进入主页，在没有网络的情况下，首页中的已经收到的微博还是能显示的，这显然是把相关的数据存储在app本地。
使用数据的app本地存储，能减少网络的流量，同时极大提高了用户的体验（想想，很多数据都能在app本地获取，显示的速度当然快）。使用了本地存储后，需要考虑的是数据的增量更新方案。
什么是数据的增量更新？假设，用户A的首页在数据表中是有40条数据，id1-40，app每次获取10条数据。第一次运行，app从数据表获取了id1-10条数据同时存储在本地。假设用户离开了这个页面再回到首页，这时app需要再次从数据库中获取数据，由于之前已经有10条数据（id1-10）存储在app本地了，那么现在需要从数据库中获取的10条数据就是从剩余的30条中数据获取（id11-40）后并保存在app本地。这个就是增量更新的典型例子。
增量更新的原理是在数据库中，每条数据都必须有update_time这个值，记录数据最后更新的时间，当app从服务器获取了一次数据后（返回的数据必须按时间排序，update_time最近的在第一条），记录下第一条数据的update_time，当再次获取数据就只需要获取上个时间点到访问服务器这刻为止所更新的数据即可。
因为分页机制的存在，这个算法实现起来是挺多需要注意的地方，下面我举一个简化的例子详细说明：
一些假设：
1. app每次请求都带4个参数
http://test/api/timeline?count=3&page=1&since=1100&max=1200
count: 每页的显示条数（默认为3）
page: 当前页码（默认为1）
since: 时间戳，若指定此参数，则返回时间戳大于等于since的结果（应该是上次获取的最新数据的update_time）
max: 时间戳，若指定此参数，则返回时间戳少于等于max的结果（应该是发送时的时间）
在sql的查询时，使用条件 since<=update_time<= max
2. api 返回的数据包含
{
"size": 10, //实际返回的数据量（因为分页获取的缘故，所以经常少于total值）
"total": 284, //应该返回的总数据量
"page": 1,
"count": 3,
"max": 0, //max为获取的最后一条数据的update_time
"since": 0
},
{ //返回的数据实体
data:.......
}
3. app存储的本地数据中的update_time是指服务器中的这条数据的更新时间，不是指app中这条数据的更新时间。
现在开始讨论：
（1）当app安装完毕后还没启动，服务器的数据表中的数据为3条，app存储的本地数据为空
服务器的数据表的数据
|
id |
update_time |
|
1 |
1100 |
|
2 |
1101 |
|
3 |
1101 |
app存储的本地数据
|
id |
update_time |
（2）当app第一次运行（时间为11：05），因为是第一次运行，since为0，max为现在的时间点1105，在服务器的数据表中获取所有数据。
发送的请求为：http://test/api/timeline?count=3&page=1&since=0&max=1105
（3）从（2）中发送请求后，api的返回数据，服务器的数据表中的数据，app存储的本地数据如下：
api返回的数据
{
"size": 3, //实际返回的数据量
"total": 3, //应该返回的总数据量
"page": 1,
"count": 3,
"max": 1101,
"since":0
},
{ //返回的数据实体
data:.......
}
服务器的数据表的数据
|
id |
update_time |
|
1 |
1100 |
|
2 |
1101 |
|
3 |
1101 |
app存储的本地数据
|
id |
update_time |
|
1 |
1100 |
|
2 |
1101 |
|
3 |
1101 |
这里是策略的重点（1）： api返回数据中的max必须为最后一条数据的update_time
（4）现在的时间是11:20，用户点击了页面中“获取更多”的按钮，app应该从服务器的数据表中拉取数据，在发送请求前，服务器的数据表中的数据如下：
服务器的数据表的数据
|
id |
update_time |
|
1 |
1100 |
|
2 |
1101 |
|
3 |
1101 |
|
4 |
1118 |
|
5 |
1118 |
|
6 |
1119 |
|
7 |
1119 |
可看到，比起上次拉取数据的时候，服务器的数据表多了id为4,5,6,7的数据。
这时发送api请求，策略的重点（2）：当api的返回数据size=total时，since值比上次获取大一点，因为这时数据已经获取完整了，没必要重复获取数据上次已经获取的数据（记得条件since<=update_time<= max 吗？）所以since值设置为1101+1=1102，max为现在的时间点：1120，请求的url如下：
http://test/api/timeline?count=3&page=1&since=1102&max=1120
发送请求后api的返回数据和app存储的本地数据如下：
api返回的数据
{
"size": 3, //实际返回的数据量（因为分页获取的缘故，所以经常少于total值）
"total": 4, //应该返回的总数据量
"page": 1,
"count": 3,
"max": 1119,
"since":1102
},
{ //返回的数据实体
data:.......
}
app的数据：
|
id |
update_time |
|
1 |
1100 |
|
2 |
1101 |
|
3 |
1101 |
|
4 |
1118 |
|
5 |
1118 |
|
6 |
1119 |
这里是策略的重点（3）：在数据库中，update_time为1101~1120的数据有4条，但由于分页的缘故，只获取了3条（从size和total参数可以判定），这意味着1101~1120这段时间的数据没有获取完整，app所获取的最后一条数据的update_time是1119，服务器的数据表中剩下的没有被app获取的数据有两种情况：
a.update_time刚好是1119
b.update_time大于1119
由于我们没法判断属于哪种种情况，如果我们下次拉数据的时候 since大于1119，服务器的数据表中id为7的数据不会再获取，那么会造成app中丢失了id为7的数据，所以针对上次数据获取不完整的情况，下次获取数据时since必须是等于1119，虽然有可能会获取重复的数据。
（5）现在的时间是11:30，用户点击了页面中“获取更多”的按钮，app应该从服务器的数据表中拉取数据，在发送请求前，服务器的数据表中的数据如下：
服务器的数据表的数据
|
id |
update_time |
|
1 |
1100 |
|
2 |
1101 |
|
3 |
1101 |
|
4 |
1118 |
|
5 |
1118 |
|
6 |
1119 |
|
7 |
1119 |
|
8 |
1120 |
这时发送api请求，这里是策略的重点（4）：当api的返回数据size少于total，为了避免有数据丢失，since为上次收到api的返回数据的max值：1119，max为现在的时间点：1130。关于策略重点（4），请结合策略的重点（3）一起理解。
请求的url如下：
http://test/api/timeline?count=3&page=1&since=1119&max=1130
发送请求后api的返回数据和app存储的本地数据如下：
api返回的数据
{
"size": 3, //实际返回的数据量（因为分页获取的缘故，所以经常少于total值）
"total": 3, //应该返回的总数据量
"page": 1,
"count": 3,
"max": 1120,
"since":1119
},
{ //返回的数据实体
data:.......
}
这是策略的重点（5）：api中返回数据中id为6的数据，在app的本地数据中已经存在，对于这条数据，app端应该放弃重复插入。
最后app存储的本地数据如下：
app的数据：
|
id |
update_time |
|
1 |
1100 |
|
2 |
1101 |
|
3 |
1101 |
|
4 |
1118 |
|
5 |
1118 |
|
6 |
1119 |
|
7 |
1119 |
|
8 |
1120 |
ok，整个增量更新的策略已经分析完毕了。在这个策略中，page参数几乎没用，之所以要保留，是为了兼容分页不带since,max的情况。对于这个增量更新的策略，请仔细理解策略的重点（1）（2）（3）（4）（5）的分析。
增量更新的策略，还要处理一个删除数据的同步问题。假设，在服务器的数据表要删除一条数据，怎么通知app本地也删除这条数据。我们的解决方案是服务器的服务器的数据表中增加一个标识is_delete，当需要在业务逻辑上删除的时候，把这条数据的is_delete设为1，同时更新update_time。当app增量更新检测到这条is_delete为1的数据，就在app本地数据中把这条数据删除。为了避免在服务器保存太多的数据，在服务器设置一个crontab，定期把那些已经标识is_delete设为1已经一段时间的数据删除。
这个增量更新的策略，适用于需要分页显示的app页面。