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则为全量更新。
版权声明:本文为博主原创文章,未经博主允许不得转载。
原文地址:http://blog.csdn.net/itachi85/article/details/47357313