基于Android端的应用程序更新方法及系统与流程

基于android端的应用程序更新方法及系统
技术领域
1.本发明涉及应用软件领域，特别涉及一种基于android端的应用程序更新方法及系统。


背景技术：

2.目前，由于互联网时代的飞速发展，业务对app产品的快速创新和迭代要求越来越高，对于线上问题处理的灵活性、覆盖率与时效性也提出了更严苛的要求。现在主流的更新方式主要是app内应用升级提示引导android应用程序包(android application package，apk)升级，此方式下用户需要下载整个安装包后走正常app升级流程。市场上也有更进一步的方式：基于某些热更新框架实现的增量更新，以实现部分模块的热修复能力。
3.以应用内升级完整包的方式修复问题，需要先耗费一定的流量将安装包下载到手机，然后在本地进行安装升级。若升级包较大的话，一方面会耗费用户大量的网络流量，另一方面下载安装过程会占用用户大量的等待时间，严重影响用户体验。而基于某些热更新框架实现的增量更新方式，虽然可以节省一定流量，能优化用户体验，但是因为android设备厂商繁多，市场上存在各种定制化的android系统，系统碎片化较为严重，主流的热更新框架均存在一定程度的兼容性问题，无法实现100%的修复成功率。严重时甚至会导致应用闪退，这在遇到严重线上问题时会造成不可估量的消极影响。除此之外，线上问题的修复场景多种多样，单一的修复策略也无法为产品提供一个足够可靠有效的支撑。


技术实现要素：

4.为了克服上述现有技术的缺点，本发明提供一种更灵活、更全面的基于android端的应用程序更新方法及系统。
5.本发明提供一种基于android端的应用程序更新方法，其包括如下步骤：接受服务器反馈的补丁信息；根据补丁信息中的特定字段信息，自动选择重大更新方案和次要更新方案中之一进行应用程序更新；其中，重大更新方案：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则进入全量包更新流程，下载全量包对应用程序进行更新；次要更新方案：仅使用补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则重试或停止更新。
6.作为上述实施例的进一步改进，重大更新方案包括重大更新子方案一和重大更新子方案二，当选择重大更新方案时，根据补丁信息字段中的特定字段信息，自动选择重大更新子方案一和重大更新子方案二的其中之一进行应用程序更新；其中，重大更新子方案一：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则自动进入全量包更新流程，下载全量包对应用程序进行更新；重大更新子方案二：首先补丁对应用程序进行更新，如果使用补丁更新应用程序
失败，则提示用户可选全量包更新流程，且当用户选择全量包更新流程时，下载全量包对应用程序进行更新。
7.作为上述实施例的进一步改进，在重大更新方案中，当下载补丁失败或者校验补丁失败超过预定次数，或者下载补丁和校验补丁均成功，但使用补丁更新应用程序未成功，均确定为使用补丁更新应用程序失败。
8.作为上述实施例的进一步改进，次要更新方案包括次要更新子方案一和次要更新子方案二，当选择次要更新方案时，根据补丁信息字段中的特定字段信息，自动选择次要更新子方案一和次要更新子方案二的其中之一进行应用程序更新；其中，次要更新子方案一：使用弹窗补丁进行应用程序更新，当使用补丁更新应用程序失败时，进行静默重试且应用程序正常运行；次要更新子方案二：使用静默补丁进行应用程序更新，当使用补丁更新应用程序失败时，以无效状态结束应用程序更新，且应用程序正常运行。
9.作为上述实施例的进一步改进，所述补丁信息包括新全量包地址字段，当新全量包地址字段不为空时，自动选择重大更新方案；当新全量包地址字段为空时，自动选择次要更新方案。
10.作为上述实施例的进一步改进，所述补丁信息包括强制更新字段和新全量包地址字段，当强制更新字段为是且新全量包地址字段不为空时，自动选择重大更新子方案一，当强制更新字段为否且新全量包地址字段不为空时，自动选择重大更新子方案二，当强制更新字段为是且新全量包地址字段为空时，自动选择次要更新子方案一，当强制更新字段为否且新全量包地址字段为空时，自动选择次要更新子方案二。
11.作为上述实施例的进一步改进，所述补丁信息包括补丁地址字段和新全量包地址字段，在重大更新方案中，根据补丁地址字段下载补丁，根据新全量包地址字段下载全量包，在次要更新方案中，根据补丁地址字段下载补丁。
12.本发明实施例另一方面提供一种基于android端的应用程序更新系统，其包括：通讯模块：用于接受服务器反馈的补丁信息；更新模块：用于根据补丁信息中的特定字段信息，自动选择重大更新方案和次要更新方案中之一进行应用程序更新；其中，重大更新方案：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则进入全量包更新流程，下载全量包对应用程序进行更新；次要更新方案：仅使用补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则重试或停止更新。
13.作为上述实施例的进一步改进，所述重大更新方案包括重大更新子方案一和重大更新子方案二，当选择重大更新方案时，根据补丁信息字段中的特定字段信息，自动选择重大更新子方案一和重大更新子方案二的其中之一进行应用程序更新；其中，重大更新子方案一：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则自动进入全量包更新流程，下载全量包对应用程序进行更新；重大更新子方案二：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则提示用户可选全量包更新流程，且当用户选择全量包更新流程时，下载全量包对应用程序进行更新；
所述次要更新方案包括次要更新子方案一和次要更新子方案二，当选择次要更新方案时，根据补丁信息字段中的特定字段信息，自动选择次要更新子方案一和次要更新子方案二的其中之一进行应用程序更新；其中，次要更新子方案一：使用弹窗补丁进行应用程序更新，当使用补丁更新应用程序失败时，进行静默重试且应用程序正常运行；次要更新子方案二：使用静默补丁进行应用程序更新，当使用补丁更新应用程序失败时，以无效状态结束应用程序更新，且应用程序正常运行。
14.作为上述实施例的进一步改进，所述补丁信息包括强制更新字段和新全量包地址字段，当强制更新字段为是且新全量包地址字段不为空时，自动选择重大更新子方案一，当强制更新字段为否且新全量包地址字段不为空时，自动选择重大更新子方案二，当强制更新字段为是且新全量包地址字段为空时，自动选择次要更新子方案一，当强制更新字段为否且新全量包地址字段为空时，自动选择次要更新子方案二。
15.本发明实施例通过设计应对不同场景的更新方案，整合出一整套完整灵活的android端应用程序更新方案，相较于现有技术更加灵活，覆盖率更广，时效性更好。
附图说明
16.通过附图中所示的本发明优选实施例更具体说明，本发明上述及其它目的、特征和优势将变得更加清晰。
17.图1为本发明实施例提供的基于android端的应用程序更新方法的流程图。
18.图2为重大更新子方案一的流程图。
19.图3为次要更新子方案二的流程图。
20.图4为在服务器上传补丁配置的示意图。
具体实施方式
21.下面结合附图和具体实施例对本发明技术方案作进一步的详细描述，以使本领域的技术人员可以更好的理解本发明并能予以实施，但所举实施例不作为对本发明的限定。
22.请参考图1至图3，本发明实施例提供一种基于android端的应用程序更新方法，其包括如下步骤：接受服务器反馈的补丁信息；根据补丁信息中的特定字段信息，自动选择重大更新方案和次要更新方案中之一进行应用程序更新；其中，重大更新方案：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则进入全量包更新流程，下载全量包对应用程序进行更新；次要更新方案：仅使用补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则重试或停止更新。
23.在重大更新方案和次要更新方案中，均先通过网络下载补丁（补丁包）。而全量包是指应用程序（app）升级所需的完整固件包，是最完整纯净的升级方式。
24.在优选实施例中，重大更新方案包括重大更新子方案一和重大更新子方案二，当选择重大更新方案时，根据补丁信息字段中的特定字段信息，自动选择重大更新子方案一
和重大更新子方案二的其中之一进行应用程序更新；其中，重大更新子方案一：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则自动进入全量包更新流程，下载全量包对应用程序进行更新；重大更新子方案二：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则提示用户可选全量包更新流程，且当用户选择全量包更新流程时，下载全量包对应用程序进行更新。用户也可选择忽略全量包更新流程。如忽略本次补丁修复以无效状态结束，app继续执行正常启动流程。
25.在重大更新子方案一中，补丁为强制性弹窗补丁，在重大更新子方案二中，补丁为可选兜底弹窗补丁。在本实施例中，该全量包是对应用程序进行降级修复。
26.请参考图2，在优选实施例中，在重大更新方案中，当下载补丁失败或者校验补丁失败超过预定次数（本实施例中为2次），或者下载补丁和校验补丁均成功，但使用补丁更新应用程序未成功，均确定为使用补丁更新应用程序失败。此时，开始下载全量包进行应用程序更新。
27.在优选实施例中，次要更新方案包括次要更新子方案一和次要更新子方案二，当选择次要更新方案时，根据补丁信息字段中的特定字段信息，自动选择次要更新子方案一和次要更新子方案二的其中之一进行应用程序更新；其中，次要更新子方案一：使用弹窗补丁进行应用程序更新，当使用补丁更新应用程序失败时，进行静默重试且应用程序正常运行；次要更新子方案二：使用静默补丁进行应用程序更新，当使用补丁更新应用程序失败时，以无效状态结束应用程序更新，且应用程序正常运行。
28.在次要更新子方案一中，补丁为普通弹窗补丁，在次要更新子方案二中，补丁为静默补丁。静默补丁是指补丁运行安装时用户无感知，弹窗补丁则是运行安装时会弹窗提示用户。
29.在优选实施例中，所述补丁信息包括新全量包地址字段（newappurl），新全量包地址字段用于记载新全量包在网上唯一的网络地址，也即url（uniform resource locator，统一资源定位器），终端系统可以通过访问该网络地址而下载新全量包。当新全量包地址字段不为空（也即记载有新全量包的地址）时，自动选择重大更新方案；当新全量包地址字段为空（也即未记载新全量包的地址）时，自动选择次要更新方案。
30.在优选实施例中，所述补丁信息包括强制更新字段（newappforcedupdate）和新全量包地址字段（newappurl）。强制更新字段是用于控制补丁类型，该字段可以记为是（1）或者否（0）。当强制更新字段为是且新全量包地址字段不为空时，自动选择重大更新子方案一。当强制更新字段为否且新全量包地址字段不为空时，自动选择重大更新子方案二。当强制更新字段为是且新全量包地址字段为空时，自动选择次要更新子方案一。当强制更新字段为否且新全量包地址字段为空时，自动选择次要更新子方案二。
31.在优选实施例中，所述补丁信息包括补丁地址字段（patchurl）和新全量包地址字段。补丁地址字段用于记载补丁的网络地址。在重大更新方案中，终端系统根据补丁地址字段下载补丁，根据新全量包地址字段下载全量包，在次要更新方案中，根据补丁地址字段下载补丁。补丁地址字段为空则会导致补丁下载失败。
32.为了更好地理解上述基于android端的应用程序更新方法，下面通过一具体实施
例展示该基于android端的应用程序更新方法。
33.请参考图4，首先在服务器上上传补丁配置。
34.字段说明：补丁名称、补丁描述为弹窗型补丁配置了弹窗的title与内容；补丁上传配置真正的补丁包并生成下载url；app版本号为当前补丁适用的app版本；补丁状态用于控制当前补丁的上下架状态；可见范围目前可配置4个灰度环境枚举，用于补丁的灰度发布，当补丁灰度环境不匹配则不下发补丁；补丁版本号顾名思义，为当前补丁的版本号；系统版本号(最大)，用于在热更新框架未及时兼容最新版本android系统时提供一个降级处理，如有配置，若目标客户端系统版本大于配置版本，不下发补丁下载地址，将走全量包下载的降级修复流程；全量包上传地址为全量包下载的降级处理配置全量包下载地址；是否强制更新用于控制补丁类型，如是则为弹窗补丁，用户无法绕过，否则为静默更新，用户对整个补丁流程无感知。
35.新增补丁如上述配置后，客户端（用户终端）请求补丁服务接口，给服务器提供当前的补丁灰度环境设置、版本号、系统版本号等状态信息，服务器根据状态信息，控制补丁的下发，给客户端反馈补丁信息（包含patchinfo字段的map），信息细节如下："patch_info": {"patchname": "补丁title","patchdesc": "补丁描述","patchurl": "************.zip","patchstatus": "1","patchmd5": "************","patchfilesize": 100,"patchflag": "p1","newappurl": "************.html"“newappforcedupdate”:”0”(否)
ꢀ“
1”（是）}若patchstatus=1&&patchurl不为空时，为绕开补丁的状态，用于配置了最大android系统版本且当前版本大于所配置的版本的情况。
36.根据不同的线上问题严重程度，配置不同的强制更新字段（newappforcedupdate）与新全量包地址字段（newappurl），根据强制更新字段与新全量包地址字段的信息，执行以下几种不同更新方案：重大更新子方案一（强制性弹窗补丁）：当newappforcedupdate=1 &&newappurl不为空时，使用强制弹窗补丁，补丁失败必须升级全量包，适用于修复影响最大的线上问题，需保证全量用户覆盖，当补丁失败时必须走全量包加载的降级修复流程。若patchurl为空，则执行强制的全量包降级修复流程。当patchurl不为空则如图2所示，在app启动页弹出补丁弹窗，用户点击确定后下载patchurl的补丁包资源文件，下载完成后比对补丁信息和补丁包的md5和patchmd5以及文件体积和patchfilesize，均一致则认为校验成功。此过程下载与校验其中一步失败会重试下载，直到失败超过两次后不再尝试，进入全量包降级修复流程。如校验成功，则进入框架的补丁修复流程（解压、合成、加载），若应用补丁（即使用补丁更新应用程序）失败，则进入强制的全量包降级修复流程，若成功，则删除补丁包文件并
重启app使补丁生效，本次补丁修复流程结束。
37.重大更新子方案二（可选兜底弹窗补丁）：当newappforcedupdate=0 &&newappurl不为空时，使用弹窗补丁，补丁失败提示一次升级全量包，适用于修复影响次大的线上问题，当补丁失败时提示用户可选全量包降级修复流程。此方案与上述重大更新子方案一流程基本相同，不同之处在于进入全量包降级修复流程时，全量包为可选，用户可选择执行也可以选择忽略。如忽略本次补丁修复以无效状态结束，app继续执行正常启动流程。
38.次要更新子方案一（普通弹窗补丁）：当newappforcedupdate=1 &&newappurl为空时，使用弹窗补丁，补丁失败时可进行静默重试，适用于影响更小的线上问题，可接受少量用户无法有效修复。此方案与前述流程重大更新方案的前段基本相同，不同之处在于补丁失败时的降级处理，补丁失败时降级成静默重试，app继续执行正常启动流程。
39.次要更新子方案一（静默补丁）：当newappforcedupdate=0 &&newappurl为空，使用静默补丁，patchurl为空时或者补丁失败不做处理，适用于待优化类问题的修复，不影响主流程，用户无感知。具体流程如图3所示，在启动页获取到静默补丁信息并缓存。进入首页后，获取到缓存的静默补丁信息并开始静默下载补丁包，若判断单次补丁流程中补丁下载和校验次数失败达两次，则清除本地补丁下载和校验失败次数，下载失败可无限次重试，校验最多重试三次，重试次数达三次以上就不再重试，本次补丁修复以无效状态结束。如果校验成功，执行框架的补丁修复流程（解压、合成、加载）。此时若加载失败则删除补丁包文件以无效状态结束本次流程。如加载成功，由于部分补丁框架限制，补丁加载后需要重启才能生效。故静默补丁情况下，不可直接强制app重启。监听app是否非前台状态或者app是否息屏，若条件成立，则在下次app返回前台或亮屏时重启app使补丁生效，本次补丁修复流程结束。
40.如上述，如果进入全量包降级修复流程，将启动断点续传下载线程下载配置在newappurl的apk安装包，下载完成后直接调取系统的apk安装程序对app进行覆盖安装。
41.本发明实施例另一方面还提供一种基于android端的应用程序更新系统，其包括：通讯模块：用于接受服务器反馈的补丁信息；更新模块：用于根据补丁信息中的特定字段信息，自动选择重大更新方案和次要更新方案中之一进行应用程序更新；其中，重大更新方案：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则进入全量包更新流程，下载全量包对应用程序进行更新；次要更新方案：仅使用补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则重试或停止更新。
42.在优选实施例中，所述重大更新方案包括重大更新子方案一和重大更新子方案二，当选择重大更新方案时，根据补丁信息字段中的特定字段信息，自动选择重大更新子方案一和重大更新子方案二的其中之一进行应用程序更新；其中，重大更新子方案一：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则自动进入全量包更新流程，下载全量包对应用程序进行更新；重大更新子方案二：首先补丁对应用程序进行更新，如果使用补丁更新应用程序失败，则提示用户可选全量包更新流程，且当用户选择全量包更新流程时，下载全量包对应用程序进行更新；
所述次要更新方案包括次要更新子方案一和次要更新子方案二，当选择次要更新方案时，根据补丁信息字段中的特定字段信息，自动选择次要更新子方案一和次要更新子方案二的其中之一进行应用程序更新；其中，次要更新子方案一：使用弹窗补丁进行应用程序更新，当使用补丁更新应用程序失败时，进行静默重试且应用程序正常运行；次要更新子方案二：使用静默补丁进行应用程序更新，当使用补丁更新应用程序失败时，以无效状态结束应用程序更新，且应用程序正常运行。
43.在优选实施例中，所述补丁信息包括强制更新字段和新全量包地址字段，当强制更新字段为是且新全量包地址字段不为空时，自动选择重大更新子方案一，当强制更新字段为否且新全量包地址字段不为空时，自动选择重大更新子方案二，当强制更新字段为是且新全量包地址字段为空时，自动选择次要更新子方案一，当强制更新字段为否且新全量包地址字段为空时，自动选择次要更新子方案二。
44.该基于android端的应用程序更新系统的工作原理与上述基于android端的应用程序更新方法相同，此处不再赘述。
45.本发明在现有技术的应用程序更新方式的基础上，通过设计应对不同场景的更新方案，整合出一整套完整灵活的android端热修复方法，有效克服了现有方式带来的灵活性、覆盖率与时效性等方面的缺点。
46.本发明是基于通用android热更新框架（例如微信tinker、美团robust等）为app提供基础的热修复能力，在此基础上设计了以下机制，并带来相应的优点：（1）补丁灰度发布，支持不同灰度环境的补丁下发。
47.（2）全量包加载的修复流程，当紧急补丁在各种异常情况出现而无法生效时，作为一种有效的兜底处理，保证严重线上问题能及时、全面修复。
48.（3）系统兼容失败异常处理，当前客户端所在系统版本与集成的热更新框架不兼容时可按需进行降级修复处理，避免因为热更新框架自身兼容问题引发的应用闪退问题。
49.（4）补丁包校验机制，并且添加了下载校验异常重试机制，当重试机制无法继续处理可按需进行降级修复处理。
50.（5）可配置的补丁策略：目前支持强制性弹窗补丁、可选兜底弹窗补丁、普通弹窗补丁、静默补丁等几种方案，可根据不同的线上问题紧急程度，采用更合适的策略来达到用户体验与问题修复的平衡，从而以更小成本修复线上问题，有效保障业务正常运作。
51.以上仅为本发明的优选实施例，并非因此限制本发明的保护范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的保护范围内。