Android之增量更新详解

news/2024/11/29 23:31:00/

前言:自从 Android 4.1 开始, Google Play 引入了应用程序的增量更新功能,App使用该升级方式,可节省约2/3的流量。现在国内主流的应用市场也都支持应用的增量更新了,最常见的应用宝省流量更新。

è¿éåå¾çæè¿°

什么是增量更新?

增量更新的关键在于增量一词。平时我们的开发过程,往往都是今天在昨天的基础上修改一些代码,app的更新也是类似的:往往都是在旧版本的app上进行修改。这样看来,增量更新就是原有app的基础上只更新发生变化的地方,其余保持原样。

与之前每次更新都要下载完整apk包的做法相比,这样做的好处显而易见:每次变化的地方总是比较少,因此更新包的体积就会小很多。比某APK的体积在60m左右,如果不采用增量更新,用户每次更新都需要下载大约60m左右的安装包,而采用增量更新这种方案之后每次只需要下载2m左右的更新包即可,相比原来做法大大减少了用户下载等待的时间和流量。

增量更新的原理是什么?

增量更新的原理非常简单,简单的说就是通过某种算法找出新版本和旧版本不一样的地方(这个过程也叫做差分),然后将不一样的地方抽取出来形成所谓的更新补丁(patch),也称之为差分包。客户端在检测到更新的时候,只需要下载差分包到本地,然后将差分包合并至本地的安装包,形成新版本的安装包,文件校验通过后再执行安装即可。本地的安装包通过提取当前已安装应用的apk得到即可。

下面是copy的原理图:

更新步骤是什么?

服务器端:服务端的同学拿到客户端同学开发的新版本A,跟已发布的旧版本B1,B2,B3...做了差分生成相应的差分包C1,C2,C3...,并生成相应差分包的MD5值,当然全量包的签名、MD5值也是需要的,这样客户端需要的所有数据就OK了。

客户端:用户手动更新或程序主动请求检测更新:

        1、客户端用MD5值和版本号作为参数向服务端请求更新数据,若服务端没有差分包则返回全量包下载URL、MD5值、签名值。

        2、若服务端存在相应的差分包则返回差分包下载URL,全量包签名值、全量包和差分包MD5值,全量包签名值和MD5值。把差分包下载到本地之后(C1),先做MD5值校验,确保下载的差分包数据的完整性,校验失败则走全量更新逻辑,校验无误和本地现有安装的旧版本(B1)进行差分合并生成新版本(A),之后进行合成版本的MD5值校验和签名校验,确保合成文件的完整性和签名信息的正确性。校验无误后再进行安装。

需要考虑的一些问题:

    1、服务端生成的差分包大小接近新包大小,或者直接超过新包大小,就没必要进行差分更新;

    2、下载到本地之后是否需要进行签名校验依赖各自情况,若有和系统方进行合作的,系统方一般会拿APK进行二次签名之后作为系统内置应用。

    3、下载文件当然也需要支持断点续传,考虑再细点,下载APK的过程中有可能被劫持或者被运营商重定向,如果是全量更新下载,可以和服务端约定每段下载数据的校验逻辑规则,在HTTP头中附加校验字段数据,确保万无一失;

    4、服务端是否根据客户端的更新请求实时生成差分数据?从目前生成差分包的测试数据来看,这个实现是不靠谱的。最好就是有新版本之后,在服务端先把差分包数据准备好,而不是等到请求更新的时候再生成差分包。

现有增量更新实现方案对比结果如何?

网上有文章对BSDiff/Patch、HDiffPatch和XDelta三种差分包实现方案做对比测试,在Android APK的差分更新实现上,XDelta差分方案实现是最优的。

copy下图:

    

但是呢,BSDiff/Patch   实现方案是最多的,网上一大堆都是这个方案的实现,Android系统也整合了这个实现,所以我也是选择了其作为探究目标。

下面就是用 BSDiff/Patch 实现增量更新的分析,如果想了解其他的实现方案请百度一下相应的文章。

一、生成差分包

最开始需要先下载 BSDiff 压缩包并在电脑配置 使其bsdiff/bspatch 命令可用。此处如果需要点击下面连接:

bsdiff在mac的编译与使用

然后,我们先打出一个安装包,假设为old.apk。对源码做修改后,再打出一个新的安装包new.apk。此处old.apk相当于老版本的应用,而new.apk相当于新版本的应用。

接下来,我们利用bsdiff来生成差分包patch.patch。

将上面的old.apk和new.apk放入bsdiff命令所在的目录,然后在终端执行命令 bsdiff old.apk new.apk patch.patch  稍等一会便可以生成差分包patch.patch。

二、合并差分包

合并old.apk和patch.patch,生成新的安装包new.apk。只要此处合并出来的new.apk和上面我们自己打出来的new.apk一样,那么就可以认为它就是我们需要的新版本安装包。

将old.apk和patch.patch放入bspatch命令所在的文件夹,然后在终端执行命令 bspatch old.apk new2.apk patch.patch  稍等一会便可以生成新的apk文件 new2.apk。 

不出意外的话,合并而来的new2.apk应该和我们自己打出来的new.apk是一模一样的,这是可以通过验证两者的md5来认定的。

到此,新旧apk差分包的生成、旧apk与差分包合并成新apk的流程就结束了。

下面看看项目实践如何?

客户端支持增量更新总体和上面的分析差不多,唯一的区别在于客户端要自行编译bspatch.c来实现合并差分包,也就是所谓的ndk开发,这里我们首先要下载bsdiff以及bzip2,以便后面使用。

bsdiff --- bsdiff 生成差分包及合并差分包库 , 使用bspatch.c文件。
bzip2 --- bzip2  bsdiff 依赖包。

在as中如何进行ndk开发不是本文的重点,如果还不清楚此知识点请先查阅相关文档。

1.编写BsPatchUtil类

BsPatchUtil中只有一个natvie方法patch(String oldApkPath,String newApkPath,String patchPath)用于实现增量包的合并:

public class BsPatchUtil {static {System.loadLibrary("apkpatch");}public static  native int patch(String oldApkPath, String newApkPath, String patchPath);
}

2.编写C代码

在实现BsPatchUtil之前,我们需要将bspatch.c文件以及bzip2压缩包内的相关文件拷贝到jni目录下(bzip只保留.h头文件和.c文件)。目录结构如下: 

è¿éåå¾çæè¿°

这里是将bspatch.c中的main()方法名修改为executePatch(),所以下面的引用也是引用的该方法。

友情提示:在bspatch.c中是需要引入 bzip2 的 , 所有需要在文件头部做bzip2的导入的修改, 引入 bzip2/ :

// bzip2
#include "bzip2/bzlib.c"
#include "bzip2/crctable.c"
#include "bzip2/compress.c"
#include "bzip2/decompress.c"
#include "bzip2/randtable.c"
#include "bzip2/blocksort.c"
#include "bzip2/huffman.c"#define LOGE(TAG,FORMAT,...) __android_log_print(ANDROID_LOG_ERROR,TAG,FORMAT,__VA_ARGS__)

 接下来我们就可以在bspatch_util.c中实现相关的代码了:

#include "com_closedevice_fastapp_util_BsPatchUtil.h"JNIEXPORT jint JNICALL Java_com_closedevice_fastapp_util_BsPatchUtil_patch(JNIEnv *env, jclass clazz, jstring old, jstring new, jstring patch){int args=4;char *argv[args];argv[0] = "bspatch";argv[1] = (char*)((*env)->GetStringUTFChars(env, old, 0));argv[2] = (char*)((*env)->GetStringUTFChars(env, new, 0));argv[3] = (char*)((*env)->GetStringUTFChars(env, patch, 0));//此处executePathch()就是上面我们修改出的int result = executePatch(args, argv);(*env)->ReleaseStringUTFChars(env, old, argv[1]);(*env)->ReleaseStringUTFChars(env, new, argv[2]);(*env)->ReleaseStringUTFChars(env, patch, argv[3]);return result;
}

至此,大部分工作已经完成了。配置app moudle中的build.gradle中添加ndk配置

defaultConfig {//ndk配置ndk{moduleName "apkpatch"abiFilters "armeabi", "armeabi-v7a","x86"}}

接下来,我们编译试试(ndk环境的配置这里不做说明,自行配置即可),不出意外会遇到以下错误: 
è¿éåå¾çæè¿°

该问题的解决方法也非常简单,注释掉对应文件的main()方法即可。重新编译,不出意外没什么问题了。接下来,我们就需要在合适的地方合并差分包了。

3.合并差分包

我们假设差分包已经从服务器下载到本地了,所以上面的过程做完之后,就可以通过BsPatchUtil.patch()来合并当前安装包和差分包了。

首先来看如何获取当前安装包,我们安装的应用通常在 data/app 下,可以通过一下代码获取其路径:

 public static String getApkInstalledSrc(){return BaseApplication.context().getApplicationInfo().sourceDir;}

下面就可以通过 BsPatchUtil.patch(String oldApkPath,String newApkPath,String pathPath) 来进行合并了。此处需要注意两点:

  • 合并的地方建议放在外置存储(SDcard)当中;
  • 合并的过程比较耗时,需要放到子线程中进行;

4.安装apk

任何更新包在下载完成后首先要做的就是进行MD5校验,以便确认该更新包是正规途径下载而来的。同样,对于合并之后的更新包,首先要做的事情也是进行MD5校验,校验通过之后,再进行安装:

  public static void installAPK(Context context, File file) {Intent intent = new Intent();intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);intent.setAction(Intent.ACTION_VIEW);intent.setDataAndType(Uri.fromFile(file),"application/vnd.android.package-archive");context.startActivity(intent);}

5.使用代码示例

 private void smartupdate() {Observable.create(new Observable.OnSubscribe<File>() {@Overridepublic void call(Subscriber<? super File> subscriber) {//定义生成的新包File newApk = new File(Environment.getExternalStorageDirectory(), "newApk.apk");//假设patch.patch文件已经下载到sdcard上,切已经校验通过File patch = new File(Environment.getExternalStorageDirectory(), "patch.patch");if(!patch.exists()){subscriber.onError(new IOException("patch file not exist!"));return;//合并差分包BsPatchUtil.patch(OSUtil.getApkInstalledSrc(), newApk.getAbsolutePath(), patch.getAbsolutePath());if (newApk.exists()) {subscriber.onNext(newApk);subscriber.onCompleted();patch.delete();}else{subscriber.onError(new IOException("bspatch failed,file not exist!"));}}}).subscribeOn(Schedulers.newThread()).observeOn(AndroidSchedulers.mainThread()).doOnSubscribe(new Action0() {@Overridepublic void call() {showDialog("正在应用差分包");}}).subscribe(new Subscriber<File>() {@Overridepublic void onCompleted() {hideDialog();}@Overridepublic void onError(Throwable e) {hideDialog();LogUtils.d(e.getMessage());}@Overridepublic void onNext(File file) {OSUtil.installAPK(getActivity(),file);}});}

到现在,增量更新就已经完成了,把增量包以及合并之后的安装包进行删除了。

增量更新的缺点

增量更新虽让有效的解决了更新包过大的问题,但是存在以下问题:

 1. 客户端和服务端需要加入相应的支持。每次发布新版本,服务端都需要为以前所有的老版本生成对应的差分包,并根据客户端端请求返回对应的更新包,维护过程将会变得相对复杂。客户端需要对差分包做更为详细的验证,防止出错,除此之外,客户端应该可以根据服务端更新开关来确定当前是使用完整更新还是增量更新。

2. apk包之间的差异过小时,比如2m以下,此时生成的差分包仍然有几百k,此时使用增量更新得不偿失,毕竟形成差分包和合并的过程都非常耗时。另外,但版本之间变化非常大的时候,通常是是大版本好变化的时候使用完整更新也不错。 
 

本文结束  see you


http://www.ppmy.cn/news/500578.html

相关文章

角雷达“突破”天线设计瓶颈,巨大增量市场机会爆发

毫米波雷达正在受益整车搭载数量提升的利好&#xff0c;其中&#xff0c;和前向雷达&#xff08;市场份额集中于少数几家&#xff09;不同&#xff0c;角雷达市场份额集中度相对较低&#xff0c;量产供应商数量也更多。 近年来角雷达&#xff08;盲区预警及变道辅助&#xff0…

全民营销时代,让私域流量变成业务增量需要几步?

本篇文章暨 CSDN《中国 101 计划》系列数字化转型场景之一。 《中国 101 计划——探索企业数字化发展新生态》为 CSDN 联合《新程序员》、GitCode.net 开源代码仓共同策划推出的系列活动&#xff0c;寻访一百零一个数字化转型场景&#xff0c;聚合呈现并开通评选通道&#xff0…

增量型博客

增量型博客-- 一种全新的博客模式 随着牛人越来越多&#xff0c;我们看到网上的技术博客也是与日俱增。但是大部分的博客都是一种模式&#xff0c;write one&#xff0c;run everywhere&#xff01; ( java说&#xff0c;谁在夸我&#xff1f;:-). 也就是说&#xff0c;一旦博…

数据同步之全量同步与增量同步

一、什么是数据同步 业务数据是数据仓库的重要数据来源&#xff0c;我们需要每日定时从业务数据库中抽取数据&#xff0c;传输到数据仓库中&#xff0c;之后再对数据进行分析统计。 为保证统计结果的正确性&#xff0c;需要保证数据仓库中的数据与业务数据库是同步的&#xff0…

增量模型优缺点

1、增量模型的优点&#xff1a; 整个项目的资金不会被提前消耗&#xff0c;因为首先开发和交付了主要功能和高风险功能。每个增量交付一个可操作的产品。每次增量交付过程中获取的经验&#xff0c;有利于后面的改进&#xff0c;客户也有机会对建立好的模型作出反应。采用连续增…

品牌策划:“增量市场”枯竭,城市品牌打造刻不容缓

文 | 公关之家 作者&#xff1a;小5 引言&#xff1a;在这个富有创造力的21世纪&#xff0c;每个人都不甘平庸&#xff0c;都有一颗成为主角的心。人如此&#xff0c;城市亦如此。 见惯了风花雪月&#xff0c;见惯了物是人非&#xff0c;见惯了人来人往&#xff0c;这一切的行…

2021年中国白酒市场现状分析,产量持续下降,利润持续增长,市场集中度提升「图」

一、白酒产业概述 在中华文化五千年的文明史中&#xff0c;酒的酿造可追溯至三千多年前&#xff0c;酒文化早已与传统文化、习俗等深深交融。作为中国酒的代表&#xff0c;白酒更是经过一次次蜕变&#xff0c;形成了“百花争艳&#xff0c;各有千秋”的格局。 1、分类状况 由…

增量、迭代

增量、迭代 1.目的: 减少项目的风险 2.适用项目: 大型项目.(增量迭代很适合 需要做半年, 一年, 几年的项目) 增量迭代这两个模型很容易混淆, 下来分别介绍一下这两个模型的概念 3.增量: 第一次发布一个功能, 第二次发布一个功能, 第二次发布的功能对第一次发布的功能对第一次功…