版本迭代更新—增量更新你的应用

App的时候升级提醒有两种方式获得：

一种是通过App Store获取

另一种是打开应用之后提醒用户更新升级

而更新操作一般是在用户点击了更新按钮之后开始执行的，这里的升级操作也分为两种形式：（一般升级，强制升级）

1.App Store升级
在App Store中升级需要为App Store上传新版App，我们在新版本完成之后都会上传到App Store中，不同的应用市场审核的时间不同，一般除了第一次上传时间较长之外，其余的审核都是挺快的，一般不会超过半天（不排除例外情况奥），在审核完成之后就相当于完成了这个应用市场的发布了，也就是发布上线了。这时候如果用户安装了这个应用市场，那么就能看到我们的App有新版本的升级提醒了。

2.应用内升级
在应用内升级主要是通过调用服务器端接口获取应用的升级信息，然后通过获取的服务器升级应用信息与本地的App版本比对，若服务器下发的最新的App版本高于本地的版本号，则说明有新版本发布，那么我们就可以执行更新操作了，否则忽略掉即可。

调用服务器接口案例

1.服务器端：
服务端提供一个接口，或者网址（不是真的）：

http://192.168.191.1:8081/update

获得json数据

{"data":{
  "appname": "hoolay.apk",
  "serverVersion": "1.0.2",
  "serverFlag": "1",
  "lastForce" : "1",
  "updateurl": "http://releases.b0.upaiyun.com/hoolay.apk",
  "upgradeinfo": "更新功能添加了扫描支付、重力感应刷新、修改一些Bug"
},
  "error_code":"300","error_msg" :"蛋疼的认识"}

2.客户端需要实现：

两种方式：app内部下载还是通知栏更新：

app内下载更新
这时我们必须等下载安装完全后才能进行操作，效果是这样的：

通知栏下载更新
这种情况是不在应用内更新，放在通知栏并不会影响当前app的使用，效果是这样的：

app更新分3种：强制更新，推荐更新，无需更新

强制更新

推荐更新

无需更新

具体思路：

1.实现bean用于对接后端接口实现app的更新（不写网络请求模拟本地数据也需要这个模型）
2.使用retrofit来请求版本更新接口
3.下载apk我们分别使用DownloadManager和普通的httpurlconnection
4.通过BroadcastReceiver来监听是否下载完成
实现步骤

应用增量升级

增量升级的原理
服务端通过新版本APK和旧版本APK生成patch补丁（也成为差分包），客户端更新的时候只需要下载差分包到本地，然后从system/app取出旧版本APK，通过差分包来合成新版本的APK，这个过程实际上就是打补丁。

步骤地址

增量升级并非完美无缺的升级方式，至少存在以下两点不足：
1.增量升级是以两个应用版本之间的差异来生成补丁的，你无法保证用户每次的及时升级到最新，所以你必须对你所发布的每一个版本都和最新的版本作差分，以便使所有版本的用户都可以差分升级，这样操作相对于原来的整包升级较为繁琐，不过可以通过自动化的脚本批量生成。
2.增量升级成功的前提是，用户手机端必须有能够让你拷贝出来且与你服务器用于差分的版本一致的apk，这样就存在，例如，系统内置的apk无法获取到，无法进行增量升级；对于某些与你差分版本一致，但是内容有过修改的(比如破解版apk)，这样也是无法进行增量升级的，为了防止合成补丁错误，最好在补丁合成前对旧版本的apk进行sha1sum校验，保证基础包的一致性。