CN106055368A - 应用更新方法和装置 - Google Patents

Abstract

本发明提供了一种应用更新方法，包括：应用启动时相应的代码执行被触发，在进行的所述代码执行中触发执行预埋代码；在所述预埋代码的执行中动态加载补丁文件，所述补丁文件携带有更新所述应用的更新代码；所述补丁文件被成功加载时，执行所述补丁文件中的更新代码；按照指定输出类型获得所述更新代码的执行结果。此外，还提供了一种与该方法匹配的应用更新装置。上述应用更新方法和装置能够简易的实现应用更新，以为应用修复问题并解决运营需求。

Description

应用更新方法和装置

技术领域

本发明涉及互联网应用技术领域，特别涉及一种应用更新方法和装置。

背景技术

随着互联网应用的空前繁荣，人们越来越多的通过各种终端获取资讯、进行相互交流、学习和工作，这都是通过终端上的应用完成的。由此将使得各种应用被争相发布，并通过不断的发布新版本、新特性来不断的满足用户提出的需求。

但是，随着应用的需求和功能的逐渐增多，应用中的逻辑也越来越复杂，因此，出现BUG（应用程序代码中存在的逻辑缺陷）和运营需求的情况也越来越多。大部分的应用在一个版本发布周期内出现的BUG和运营需求只能通过进行下下个版本的发布得到解决，由此将所带来的成本非常高，如何在不发布新版本的情况下修复问题和解决运营需求将成为当前亟待解决的问题。

然而，现有的解决这类问题的技术较为复杂，无法为应用修复问题和解决运营需求。

发明内容

基于此，有必要提供一种应用更新方法，所述方法能够简易的实现应用更新，以为应用修复问题并解决运营需求。

此外，还有必要提供一种应用更新装置，所述装置能够简易的实现应用更新，以为应用修复问题并解决运营需求。

一种应用更新方法，包括如下步骤：

应用启动时相应的代码执行被触发，在进行的所述代码执行中触发执行预埋代码；

在所述预埋代码的执行中动态加载补丁文件，所述补丁文件携带有更新所述应用的更新代码；

所述补丁文件被成功加载时，执行所述补丁文件中的更新代码；

按照指定输出类型获得所述更新代码的执行结果。

一种应用更新装置，包括：

代码执行模块，用于应用启动时相应的代码执行被触发，在进行的代码执行中触发执行预埋代码；

动态加载模块，用于在所述预埋代码的执行中动态加载补丁文件，所述补丁文件携带有更新所述应用的更新代码；

更新代码执行模块，用于所述补丁文件被成功加载时，执行所述补丁文件中的更新代码；

结果输出模块，用于按照指定输出类型获得所述更新代码的执行结果。

为解决上述技术问题，将采用如下技术方案：

在应用启动时相应代码的执行被触发，随着代码的执行在执行到预埋代码时，触发执行预埋代码，以在预埋代码的执行中动态加载补丁文件，补丁文件携带有更新应用的更新代码，因此在补丁文件被成功加载时执行补丁文件中的更新代码，按照指定输出类型更新代码的执行结果，通过此过程中更新代码的执行实现应用中问题的修复和运营需求的解决，为应用的更新提供了一种简易的实现方案，实现应用中BUG的动态修复和动态运营。

附图说明

图1是一个实施例中应用更新方法的流程图；

图2是图1中应用启动时相应代码执行被触发，在进行的代码执行中触发执行预埋代码的方法流程图；

图3是图1中在预埋代码的执行中动态加载补丁文件，补丁文件携带有更新应用的更新代码的方法流程图；

图4是一个实施例中应用更新方法的应用示意图；

图5是一个实施例中应用更新装置的结构示意图；

图6是图5中代码执行模块的结构示意图；

图7是图5中动态加载模块的结构示意图；

图8是本发明实施例提供的一种终端设备的结构示意图。

具体实施方式

体现本发明特征与优点的典型实施方式将在以下的说明中详细叙述。应理解的是本发明能够在不同的实施方式上具有各种的变化，其皆不脱离本发明的范围，且其中的说明及图示在本质上是当作说明之用，而非用以限制本发明。

在一个实施例中，一种应用更新方法如图1所示，包括如下步骤：

步骤110，应用启动时相应代码执行被触发，在进行的代码执行中触发执行预埋代码。

应用指的是终端中可供运行的应用程序。应用启动时相应代码被触发执行，并通过代码的执行来实现应用中的相应功能。

应用启动运行中所执行的代码来自于应用的代码信息，而在应用的代码信息中包括了预埋代码，该预埋代码是与应用的功能模块或者方法对应的。例如，如果预估到应用中一定的功能模块或者方法存在BUG或者运营需求的可能性较高，则在应用的代码信息中为此功能模块或者方法设置预埋代码。

由此在进行的代码执行中，如果执行到预埋代码，则说明相应的功能模块或者方法被触发运行，此时，将执行此预埋代码。

步骤130，在预埋代码的执行中动态加载补丁文件，补丁文件携带有更新应用的更新代码。

预埋代码用于实现补丁文件的动态加载。其中，补丁文件用于实现预埋代码对应的功能模块或者方法的问题修复，也可用于实现对应功能模块或者方法中新的运营需求，具体可根据实际需要确定。

无论是进行问题修复还是实现新的运营需求，都只要在补丁文件中添加新逻辑和/或新需求即可，由此便获得补丁文件中携带的更新代码。

需要说明的是，本发明所指的需要进行修复的问题是应用程序代码中存在的逻辑缺陷。

在预埋代码的执行中，通过进行补丁文件的动态加载方能够加载和执行除了应用的执行程序之外的其他代码，如更新代码。通过动态加载的实现为应用中问题修复和新的运营需求的实现提供了可能。

具体的，在执行到预埋代码时，判断是否存在补丁文件，如果存在补丁文件，则进行补丁文件的动态加载，如果不存在补丁文件，则执行本地逻辑。

步骤150，补丁文件被成功加载时，执行补丁文件中的更新代码。

判断补丁文件加载是否成功，如果补丁文件被成功加载，则能够执行添加于补丁文件中的更新代码，即为修复问题和/或新的运营需求的实现而添加的新逻辑和/或新需求，进而得以实现应用中相关功能模块或者方法的修复或功能更新。

步骤170，按照指定输出类型获得更新代码的执行结果。

在动态加载补丁文件所实现的更新代码执行中，按照指定输出类型输出更新代码的执行结果。其中，指定输出类型用于约定执行新逻辑和/或新的运营需求的实现中返回结果的类型，其是与本地逻辑的执行中结果的输出类型相一致的，由此方能够适配于应用的执行程序，进而使得更新后的应用能够顺畅运行。

通过如上所述的过程，使得应用能够自动实现其问题修复和/或新的需求的实现，进而使得应用的更新是与应用本身适配的，提高了应用更新的可靠性和简易性。

如前所述的，对于如何在不发布新版本的情况下修复应用中的问题并解决新的运营需求这类问题，目前所研究出解决这类问题的技术包括基于Xposed框架的Dexposed和Andfix，基于Cassloader的Nuwa、HotFix和DroidFix等，但都存在着技术复杂，无法为应用修复问题并解决运营需求。

一方面，基于Xposed框架的Dexposed和Andfix是通过改变一个方法对象方法在虚拟机中的定义来实现的。具体做法是将该方法的类型改变为native，并且将这一方法的实现链接到一通用的Native Dispatch方法上，Native Dispatch方法通过回调到Java端的一个统一处理方法来实现AOP（A-Oriented Programming，面向方面编程）。

但是此做法与本发明所提供的方案相比较，本身存在着安全隐患，并且为了达到版本适配的目的，需要对现有的所有版本做适配，还需要增加额外的工具至应用的安装包中。

另外，基于Xposed框架的Dexposed和Andfix对于使用者的技术门槛要求较高，需要使用者对Java的反射机制非常了解；此外，还只能对旧版本中的已有代码进行修复，并无法添加新特性，进而满足在线添加运营特性的需求。

另一方面，基于Class loader的Nuwa、HtFix和DroidFix是通过修改Cassloader中findClass方法的查找顺序，优选从下发的补丁文件中查找被修复的类，加载并执行被修复后的代码来实现修复问题的目的。

但是，由于***对于DEX文件（应用的执行程序）中的类有一个校验机制，即，如果一个类A引用另外一个类B，A和B在同一个DEX文件中，则在对DEX文件优化时，会在优化后的类A的字节码中加入一个CLASS_ISPREVERIFIED标志。

在此情况下，如果让Cassloader中findClass方法强制到DEX文件中查找类B，则会发生无法通过验证的异常。

也就是说，如果一个类带有CLASS_ISPREVERIFIED标志，则无法对该类进行修复，所以只能将DEX文件中包含的所有类都制作成不带CLASS_ISPREVERIFIED标志的类，但将由此带来比较大的运行效率问题，且为开发造成困难。

而通过本发明所提供的应用更新方法，能够在原有应用的DEX文件基础上通过补丁文件的动态加载实现问题修复和运营需求更新，进而不会对应用的运行效率造成任何影响，也不需要为此额外地制作DEX文件中包含的类，因此能够保证较低成本。

另外，通过本发明所提供的应用更新方法，对于使用者而言技术门槛较低，且能够同时兼顾问题的修复和运营需求的更新。

在一个实施例中，如上所述的方法还包括：

应用被触发进行服务器中补丁文件的查询，通过该查询从服务器获得补丁文件。

服务器是应用所对应服务器，补丁文件是通过服务器发布，以便于应用获得的。具体的，终端中应用被触发运行之后，将进行服务器中补丁文件的查询，在服务器中查询得到补丁文件之后，拉取查询得到的补丁文件。

其中，应用从服务器获得补丁文件的过程即为插件下载过程，并且通过文件大小、文件信息摘要值来保证补丁文件下载的完整性。

也就是说，通过应用与服务器之间的交互，使得运行于终端中的应用能够随时获得是发布的补丁文件，进而及时有效的实现自身问题的修复和新的运营需求的实现，极大地提高了时效性，并且对于问题修复和运营需求的实现而言，所需要耗费的成本最低。

在一个实施例中，步骤110如图2所示，包括如下步骤：

步骤111，被触发启动的应用中功能模块被触发，根据被触发的功能模块执行相应代码。

终端中应用被触发启动，以运行于终端中。对于应用而言，其包含了多个功能模块，以用于实现应用中的各种功能，对于每一功能模块，其都有对应的代码信息，以通过对应代码信息中代码的执行来实现功能模块的运行。

在应用运行的过程中，将触发各种功能模块来实现应用中所需要的功能，因此，被触发的功能模块将执行其相应代码。

步骤113，随着代码的执行，功能模块的代码信息中存在的预埋代码被触发执行。

如前所述的，对于某些功能模块，在其代码信息包含了预埋代码，这将意味着一旦功能模块被触发，便能够触发执行预埋代码，进而通过预埋代码来实现补丁文件相关的处理过程，简易有效地实现应用更新。

在一个实施例中，步骤130如图3所示，包括如下步骤：

步骤131，在预埋代码的执行中构造自定义的类加载器。

首先需要说明的是，应用启动后执行的代码，都是通过操作***中的类加载器，例如，Classloader，进行加载执行的。但是，操作***自身的类加载器只能够加载应用的执行程序（比如，DEX文件）中存在的代码，而执行程序之外的代码并无法加载。

因此，在预埋代码的执行中，通过逻辑控制创建自定义的类加载器，例如，一个新的Classloader。自定义的类加载器用过读取和加载补丁文件中存在的代码，进而方能够实现动态加载，即不受操作***的限制。

步骤133，通过自定义的类加载器动态加载补丁文件，在加载的补丁文件中触发执行补丁文件的代码。

如前所述的，补丁文件的代码包括了用以实现问题修复和/或新需求的更新代码。换而言之，对于服务器所进行的补丁文件发布而言，其是通过在添加新逻辑、新需求来得获得向应用发布的补丁文件的。

由此便能够在应用中通过预埋代码实现为所进行的更新，进而不断修复运行中的问题或者实现动态运营，而并不需要依赖于版本的迭代更新。

例如，已发布的终端应用如果出现BUG或者有运营需求时，不再需要通过更新应用版本才能修复问题、更新产品特性，明显降低应用的版本发布频率，能够快速、方便、灵活的更新产品特性，降低运营成本。

在一个实施例中，步骤150包括：

在补丁文件被成功加载时，预埋代码被触发从补丁文件调用指定接口执行更新代码。

如前所述的，补丁文件中携带了预埋代码，除此之外，还在补丁文件中约定了用以执行更新代码的接口，进而能够从补丁文件中调整指定接口来执行更新代码，以实现问题修复和动态运营。

其中，预埋代码从补丁文件所调用的指定接口作为扩展接口，有对应的调用方法，因此，在调用指定接口执行更新代码的过程即为调用接口来通过对应的调用方法执行更新代码的过程，

在另一个实施例中，如上所述的方法还包括：

在补丁文件未被成功加载时，通过代码的执行进行应用的本地逻辑执行。

一方面，在不存在补丁文件时，即服务器并未发布补丁文件，则创建本地逻辑，通过本地逻辑的执行来使得应用得以顺畅运行。

另一方面，在未成功加载补丁文件时，也将调用本地逻辑中的方法来实现应用的顺畅运行。

通过如上的过程，提供了一种轻量的、稳定的、平台兼容性强的应用更新过程，通过预埋代码，在调用者和内容提供者之间约定调用接口和结果的输出类型，进而在代码编写难易度方面也有更优表现。

下面结合一个具体的实施例来详细阐述如上所述的过程。该实施例中，如图4所示的，应用的一功能模块中，Invoker类需要得到输出类型为Class A 的执行结果，其作为有大量运营需求或者新开发、有较高风险的功能模块，将在应用的版本发布之前，为此功能模块设置预埋代码。

另一方面的，如图4所标示的，还将定义约定的指定接口，即输出结果提供者接口IContentPrider及其调用方法getClassResult.，即执行步骤210。

创建一个补丁内容提供者PatchContentPrider来实现指定接口和调用方法，即执行步骤220，并编译后封装到patch.dex文件，即补丁文件中，下发到应用，即执行步骤230。

此时，运行于终端中的应用而言，如步骤240至步骤290，其将在判断到补丁文件存在的前提条件下，通过Classsloader动态加载补丁文件，并在加载成功之后，通过Classloader从补丁文件中动态加载约定的补丁内容提供者PatchContentPrider，在加载成功时方可调用其封装的方法getClassAResult返回约定输出类型的执行结果，由此便实现了应用中问题的修复和动态运营。

另外，需要补充的是，如图4中步骤310和步骤330所标示的，在不存在补丁文件或者补丁文件未被成功加载时，将通过本地逻辑来实现应用的顺畅运行。

具体的，在不存在补丁文件时，创建一个默认内容提供者接口，即LocalContentPrider，来实现指定接口IContentPrider和调用方法getClassAResult。

通过如上所述的过程便能够方便快捷的对用户提出的问题、新的运营需求进行响应和满足。

此外，还相应地提供了一种应用更新装置，所述装置如图5所示，包括代码执行模块410、动态加载模块430、更新代码执行模块450和结果输出模块470，其中：

代码执行模块410，用于应用启动时相应的代码执行被触发，在进行的代码执行中触发执行预埋代码。

动态加载模块430，用于在预埋代码的执行中动态加载补丁文件，补丁文件携带有更新应用的更新代码。

更新代码执行模块450，用于补丁文件被成功加载时，执行补丁文件中的更新代码。

结果输出模块470，用于按照指定输出类型获得更新代码的执行结果。

在一个实施例中，如上所述的装置还包括查询模块，该查询模块用于应用被触发进行服务器中补丁文件的查询，通过查询从服务器获得补丁文件。

在一个实施例中，代码执行模块410如图6所示，包括功能模块执行单元411和预埋代码执行单元413，其中：

功能模块执行单元411，用于被触发启动的应用中功能模块被触发，根据被触发的功能模块执行相应代码。

预埋代码执行单元413，用于随着代码的执行，功能模块的代码信息中存在的预埋代码被触发执行。

在一个实施例中，动态加载模块430如图7所示，包括构造单元431和动态加载执行单元433，其中：

构造单元431，用于在预埋代码的执行中构造自定义的类加载器。

动态加载执行单元433，用于通过自定义的类加载器动态加载补丁文件，在加载的补丁文件中触发执行补丁文件的代码。

在一个实施例中，更新代码执行模块450进一步用于在补丁文件被成功加载时，预埋代码被触发从补丁文件调用指定接口执行更新代码。

在另一个实施例中，如上所述的装置还包括本地执行模块，该本地执行模块用于在补丁文件被成功加载时，通过代码的执行进行应用的本地逻辑的的执行。

图8示出了本发明实施例提供的一种终端设备的结构。该终端设备500只是一个适用本发明的示例，并不能认为是提供了对本发明的使用范围的任何限制。该终端设备500也不能解释为需要依赖于或具有图示的示例性的终端设备500中的一个或者多个部件的组合。

如图8所示，终端设备500包括处理器510、存储器520和***总线530。包括存储器520和处理器510在内的各种组件将连接到***总线530上。处理器510是一个用于通过计算机***中基本的算术和逻辑运算来执行计算机程序指令的硬件。存储器520是一个用于临时或永久性存储计算机程序或数据的物理设备。

其中，存储器520中存储了相应的程序指令和当前显示的内容；处理器510将执行存储器520中的程序指令，侦听输入的各种指令，并对侦听得到的指令进行响应。

终端设备500还包括各种输入接口570、输入装置540，以实现各种操作的输入。其中，该输入装置540可以是触摸屏幕、按键、键盘和鼠标等至少一种。

终端设备500还包括存储设备580，存储设备580可以从多种计算机可读存储介质中选择，计算机可读存储介质是指可以进行访问的任何可利用的介质，包括移动的和固定的两种存储介质。例如，计算机可读存储介质，包括但不限于闪速存储器（微型SD卡）、CD-ROM、数字通用光盘（DVD）或其它光盘、磁带盒、磁带存储或其它存储设备、或者可用于存储所需要信息并可访问的任何其它存储介质。

如上面所详细描述的，适配于本发明的终端设备500将执行分享移动终端内容的指定操作，即通过处理器510运行存储器520中的程序指令的形式执行该指定操作，以实现移动终端设备500中内容的分享。

此外，通过硬件电路或者硬件电路结合软件指令也能同样实现本发明，因此，实现本发明并不限于任何特定硬件电路、软件以及两者的结合。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

虽然已参照几个典型实施方式描述了本发明，但应当理解，所用的术语是说明和示例性、而非限制性的术语。由于本发明能够以多种形式具体实施而不脱离发明的精神或实质，所以应当理解，上述实施方式不限于任何前述的细节，而应在随附权利要求所限定的精神和范围内广泛地解释，因此落入权利要求或其等效范围内的全部变化和改型都应为随附权利要求所涵盖。

Claims (12)

1.一种应用更新方法，其特征在于，包括如下步骤：

应用启动时相应的代码执行被触发，在进行的所述代码执行中触发执行预埋代码；

在所述预埋代码的执行中动态加载补丁文件，所述补丁文件携带有更新所述应用的更新代码；

所述补丁文件被成功加载时，执行所述补丁文件中的更新代码；

按照指定输出类型获得所述更新代码的执行结果。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述应用被触发进行服务器中补丁文件的查询，通过所述查询从所述服务器获得补丁文件。

3.根据权利要求1所述的方法，其特征在于，所述应用启动时相应的代码执行被触发，在进行的所述代码执行中触发执行预埋代码的步骤包括：

被触发启动的所述应用中功能模块被触发，根据被触发的所述功能模块执行相应代码；

随着所述代码的执行，所述功能模块的代码信息中存在的预埋代码被触发执行。

4.根据权利要求1所述的方法，其特征在于，所述在所述预埋代码的执行中动态加载补丁文件的步骤包括：

在所述预埋代码的执行中构造自定义的类加载器；

通过所述自定义的类加载器动态加载补丁文件，在加载的所述补丁文件中触发执行所述补丁文件的代码。

5.根据权利要求1所述的方法，其特征在于，所述补丁文件被成功加载时，执行所述补丁文件中的更新代码的步骤包括：

在所述补丁文件被成功加载时，所述预埋代码被触发从所述补丁文件调用指定接口执行更新代码。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述补丁文件未被成功加载时，通过所述代码的执行进行所述应用的本地逻辑的执行。

7.一种应用更新装置，其特征在于，包括：

代码执行模块，用于应用启动时相应的代码执行被触发，在进行的代码执行中触发执行预埋代码；

动态加载模块，用于在所述预埋代码的执行中动态加载补丁文件，所述补丁文件携带有更新所述应用的更新代码；

更新代码执行模块，用于所述补丁文件被成功加载时，执行所述补丁文件中的更新代码；

结果输出模块，用于按照指定输出类型获得所述更新代码的执行结果。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

查询模块，用于所述应用被触发进行服务器中补丁文件的查询，通过所述查询从所述服务器获得补丁文件。

9.根据权利要求7所述的装置，其特征在于，所述代码执行模块包括：

功能模块执行单元，用于被触发启动的所述应用中功能模块被触发，根据被触发的所述功能模块执行相应代码；

预埋代码执行单元，用于随着所述代码的执行，所述功能模块的代码信息中存在的预埋代码被触发执行。

10.根据权利要求7所述的装置，其特征在于，所述动态加载模块包括：

构造单元，用于在所述预埋代码的执行中构造自定义的类加载器；

动态加载执行单元，用于通过所述自定义的类加载器动态加载补下文件，在加载的所述补丁文件中触发执行补丁文件的代码。

11.根据权利要求7所述的装置，其特征在于，所述更新代码执行模块进一步用于在所述补丁文件被成功加载时，所述预埋代码被触发从所述补丁文件调用指定接口执行更新代码。

12.根据权利要求7所述的装置，其特征在于，所述方法还包括：

本地执行模块，用于在所述补丁文件被成功加载时，通过所述代码的执行进行所述应用的本地逻辑的执行。