1.增量升级的原理
增量更新的原理就是将本地apk与服务器端最新版本比对，并得到差异包。比如现在的版本是1.1.4，大小是7.2M，新版本是1.1.5.大小是7.3M。我们发现两个版本只有0.1M的差异，这样我们如果采用增量升级生成0.1M左右的差异包，这样用户只需要下载0.1M的差异包进行升级而不需要重新下载7.3M的新版本了。
2.以往增量升级的实现
首先要有服务端来生成差异包，这一步使用bsdiff（二进制差分工具）来生成老版本和新版本的差异包，再提供给应用下载差异包。应用端则是封装bspatch成so动态库，通过jni调用动态库将旧版本的apk和差异包合成新版本的apk。
3.以往增量升级的弊端
1. 服务端和客户端都需要实现功能，时间周期长
2. 无法保证用户每次的及时升级到最新，所以必须对发布的每一个版本都和最新的版本作成差异包，难以维护。
3. 客户端下载服务端生成的差异包进行合成，可能会出现合成失败问题，有可能是服务端生成的差异包不对，也有可能客户端合成有问题，需要大量的测试和联调。
4.友盟升级
4.1 导入SDK所需jar包
下载最新版SDK的zip包，将其中的libs文件夹合并到本地工程libs子目录下。libs目录下的libs/armeabi/libbspatch.so文件是用于支持增量更新功能的库文件，也需要在eclipse中添加。
4.2 添加资源文件
将SDK提供的res文件夹拷入工程目录下, 和工程本身res目录合并。请不要随便删除其中的文件
4.3 配置AndroidManifest.xml
4.3.1 添加SDK需要的权限到标签下：
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"></uses-permission>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"></uses-permission>
<uses-permission android:name="android.permission.INTERNET"></uses-permission>4.3.2 接着添加APPKEY和渠道到标签下： （如果已经集成了统计SDK等友盟其他服务，不需要重复添加APPKEY）
<meta-data android:value="YOUR APP KEY" android:name="UMENG_APPKEY"/>
<meta-data android:value="Channel ID" android:name="UMENG_CHANNEL"/>UMENG_APPKEY：用来定位该应用的唯一性，用您该应用的UMENG APPKEY，替换value中的”YOUR APP KEY”。
UMENG_CHANNEL：用来标注应用推广渠道，不同渠道可以上传不同更新包，您可以使用20位以内的英文和数字为渠道定名，替换value中的”Channel ID”。如果不改动，将代表默认渠道，如果需要使用友盟自动更新多渠道更新，必须先集成友盟统计SDK。
4.3.3 添加Service和Activity到标签下： （请注意：v2.4的SDK中，对话框改为Activity实现，com.umeng包名可能有变，如果不能下载，请检查包名，替换成正确的包名）
<service
android:name="com.umeng.update.net.DownloadingService"
android:process=":DownloadingService" >
</service>
<activity
android:name="com.umeng.update.UpdateDialogActivity"
android:theme="@android:style/Theme.Translucent.NoTitleBar" >
</activity>
4.3.4 调用更新接口
主要应用场景：最常见的自动更新模式，当用户进入应用首页后，如果处于wifi环境则检测更新，如果有更新，弹出对话框提示有新版本，用户点选更新开始下载更新。
在应用程序入口Activity里的OnCreate() 方法中调用
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
UmengUpdateAgent.update(this);
目前默认在Wi-Fi接入情况下才进行自动提醒。如需要在任意网络环境下都进行更新自动提醒，则请在update调用之前添加以下代码：UmengUpdateAgent.setUpdateOnlyWifi(false)。
4.4 上传最新的APK
如果开发者已经有了最新的APK版本，只要上传到友盟网站，同时客户端版本的版本号（VersionCode）小于上传的最新版本，客户端在启动时就会有更新提示。
5.友盟更新场景
5.1 自动更新
最常见的自动更新模式，当用户进入应用首页后，如果处于wifi环境则自动检测更新（默认只在wifi环境下检测，是为了用户流量考虑。这个行为可以更改），如果有更新，弹出对话框提示有新版本，用户点选更新开始下载更新。
在应用程序入口Activity里的OnCreate() 方法中调用
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
UmengUpdateAgent.update(this)
//UmengUpdateAgent.update(this, "appkey", "channel");
5.2 手动更新
主要使用场景：许多应用的设置界面中都会有检查更新等类似功能，需要用户主动触发而检测更新。它的默认行为基本和自动更新基本一致。
它和自动更新的主要区别是：在这种手动更新的情况下，无论网络状况是否Wifi，无论用户是否忽略过该版本的更新，都可以像下面的示例一样在按钮的回调中发起更新检查，代替update(Context context)：
public void onClick(View v) {
UmengUpdateAgent.forceUpdate(mContext);
}
5.3 静默下载更新
主要使用场景：当用户进入应用首页后如果处于wifi环境检测更新，如果有更新，后台下载新版本，如果下载成功，则进行通知栏展示，用户点击通知栏开始安装。
静默下载中途如果wifi断开，则会停止下载。
在应用程序入口Activity里的OnCreate() 方法中调用
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
UmengUpdateAgent.silentUpdate(this);
6.友盟增量升级
友盟增量更新的原理是：应用集成友盟自动更新SDK之后，SDK会在应用启动时将手机端的Version Code和应用APK文件的MD5值发送到友盟的服务器端。服务器通过对MD5值查找到老版本的APK， 同新老版本的APK做diff， 生成patch文件，返回给SDK。 SDK再将patch文件和手机上的老版本APK文件合成生成新版本的APK。手机端生成的新版APK文件的MD5值会和服务器端的新版APK MD5值保持严格一致。在此过程中， 要求友盟服务器必须存在新老两个版本的APK文件。
友盟默认是采用的增量更新，如果想采用全量更新可以调用setDeltaUpdate(boolean deltaUpdate)设置，默认true，设为false则为全量更新。
版权声明：本文为博主原创文章，未经博主允许不得转载。