CN108089873A - 一种应用组件即时更新的方法及终端 - Google Patents

Abstract

本发明公开了一种应用组件即时更新的方法及终端，在进行更新后的应用组件的安装时，为每个更新后的应用组件创建一个类加载器和类的路径加载器，并将其对应的资源文件、Dex包、引用库文件和MD5文件拷贝至所述应用组件对应的目录，实现应用组件的即时更新，不需要应用组件的重启，在进行更新后的应用组件的调用时，只需要读取应用组件的类加载器和类的路径加载器，基于Android应用桌面化开发的原理，基于类加载器和类的路径加载器就可以实现对更新后的应用组件的调用运行，自动遍历应用组件的各个属性，从而将所述应用组件显示出来，无需现有的应用组件更新时的重启操作，操作方便快捷，用户体验好。

Description

一种应用组件即时更新的方法及终端

技术领域

本发明涉及应用组件更新领域，尤其涉及一种应用组件即时更新的方法及终端。

背景技术

在应用组件的日常开发和线上的实时运行过程中，往往会发现一些问题：在应用组件上线前，由于需求变更，需要对现有的版本进行修改；上线后，由于发行版本中存在一些问题，需要进行版本更新。这样就导致用户在使用该应用组件时，应用提供商会发布升级提示给用户，造成版本的频繁更新。

为了解决频繁更新的问题，腾讯的微信团队提出名为Tinker的热更新框架。其原理是在现有应用工程的基础上，生成未修改应用工程中的代码前的应用包-P，当应用工程中的代码被修改后生成现有的应用包-P1，则借助Diff算法，将P和P1两个包进行对比，取出更改后的类，并通过脚本打包成一个补丁包。当线上应用发生问题时，微信的Tinker平台将下推补丁包至用户手机上的补丁服务；补丁服务解析所述补丁包后，进行合并，告知用户应用自动重启，重启后，通过读取META文件下的dex包的名称，将读取出的dex包存放到一个dex的集合中，告知操作系统合并成一个完整的dex包或者oat文件，此时应用更新完成。

如果引用Tinker的热更新机制，确实能够解决用户手机上的应用频繁更新的问题，但是，所述热更新机制在每次应用更新时，都需要应用进行重启才能保证应用更新的完成。

发明内容

本发明所要解决的技术问题是：提供一种应用组件即时更新的方法及终端，应用组件进行更新时，无需应用组件重启，而是自行生效。

为了解决上述技术问题，本发明采用的一种技术方案为：

一种应用组件即时更新的方法，包括步骤：

S1、解析更新后的应用组件，为所述更新后的应用组件创建一个类加载器和类的路径加载器；

S2、根据所述应用组件的类别，将所述类加载器和类的路径加载器分别放入对应的类集合中，并建立索引关联；

S3、检测系统中是否存在与所述应用组件对应的目录，若不存在，则创建与所述应用组件对应的目录；

S4、从解析后的更新后的应用组件中拷贝出资源文件、Dex包、引用库文件和MD5文件至所述应用组件对应的目录。

为了解决上述技术问题，本发明采用的另一种技术方案为：

一种应用组件即时更新的终端，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

S1、解析更新后的应用组件，为所述更新后的应用组件创建一个类加载器和类的路径加载器；

S2、根据所述应用组件的类别，将所述类加载器和类的路径加载器分别放入对应的类集合中，并建立索引关联；

S3、检测系统中是否存在与所述应用组件对应的目录，若不存在，则创建与所述应用组件对应的目录；

S4、从解析后的更新后的应用组件中拷贝出资源文件、Dex包、引用库文件和MD5文件至所述应用组件对应的目录。

本发明的有益效果在于：在进行更新后的应用组件的安装时，为每个更新后的应用组件创建一个类加载器和类的路径加载器，并将其对应的资源文件、Dex包、引用库文件和MD5文件拷贝至所述应用组件对应的目录，实现应用组件的即时更新，不需要应用组件的重启，在进行更新后的应用组件的调用时，只需要读取应用组件的类加载器和类的路径加载器，基于Android应用桌面化开发的原理，基于类加载器和类的路径加载器就可以实现对更新后的应用组件的调用运行，自动遍历应用组件的各个属性，从而将所述应用组件显示出来，无需现有的应用组件更新时的重启操作，操作方便快捷，用户体验好。

附图说明

图1为本发明实施例的一种应用组件即时更新的方法的流程图；

图2为本发明实施例的一种应用组件即时更新的终端的结构示意图；

标号说明：

1、应用组件即时更新的终端；2、存储器；3、处理器。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

本发明最关键的构思在于：在进行更新后的应用组件的安装时，为每个更新后的应用组件创建一个类加载器和类的路径加载器，并将其对应的资源文件、Dex包、引用库文件和MD5文件拷贝至所述应用组件对应的目录，实现应用组件的即时更新。

请参照图1，一种应用组件即时更新的方法，包括步骤：

S1、解析更新后的应用组件，为所述更新后的应用组件创建一个类加载器和类的路径加载器；

S2、根据所述应用组件的类别，将所述类加载器和类的路径加载器分别放入对应的类集合中，并建立索引关联；

S3、检测系统中是否存在与所述应用组件对应的目录，若不存在，则创建与所述应用组件对应的目录；

S4、从解析后的更新后的应用组件中拷贝出资源文件、Dex包、引用库文件和MD5文件至所述应用组件对应的目录。

由上述描述可知，本发明的有益效果在于：在进行更新后的应用组件的安装时，为每个更新后的应用组件创建一个类加载器和类的路径加载器，并将其对应的资源文件、Dex包、引用库文件和MD5文件拷贝至所述应用组件对应的目录，实现应用组件的即时更新，不需要应用组件的重启，在进行更新后的应用组件的调用时，只需要读取应用组件的类加载器和类的路径加载器，基于Android应用桌面化开发的原理，基于类加载器和类的路径加载器就可以实现对更新后的应用组件的调用运行，自动遍历应用组件的各个属性，从而将所述应用组件显示出来，无需现有的应用组件更新时的重启操作，操作方便快捷，用户体验好。

进一步的，所述步骤S1还包括：

为所述更新后的应用组件创建启动类，并根据UUID算法为所述更新后的应用组件创建一个编号，生成解析服务类。

由上述描述可知，通过创建启动类和解析服务类，能够保证所述应用组件能够独立运行。

进一步的，还包括步骤：

S5、在主程序下生成与所述更新后的应用组件对应的清单，所述清单包含所述应用组件的名称、对应的目录的路径、类加载器的编号、类的路径加载器的编号以及所述更新后的应用组件创建的时间。

由上述描述可知，在主程序下生成与所述更新后的应用组件对应的清单，即将应用组件拷贝至主程序目录下，保证主程序每次启动时能够快速地读取到相应的应用组件。

进一步的，当接收到从服务器发送的应用组件清单时，所述清单包括应用组件的名称、MD5值、版本号、紧急程度、应用组件下载地址，根据所述接收到的应用组件的名称、MD5值查找在目录中是否存在对应的应用组件；

若是，则根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载。

由上述描述可知，通过对接收的应用组件清单中的应用组件的名称及MD5值的比较能够准确地获知是否安装有能够更新的应用组件，同时基于接收到的应用组件的紧急程度确定是否对对应的应用组件进行下载，可以进行有选择性地对应用组件进行下载。

进一步的，所述根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载具体包括：

所述紧急程度包括重要、中等和普通，若所述紧急程度为重要，则读取对应的应用组件清单中的应用组件下载地址进行应用组件的下载；

若所述紧急程度为中等，则进行更新提示；

若所述紧急程度为普通，则不进行更新提示。

由上述描述可知，对紧急程度为重要的应用组件直接进行自动下载，对紧急程度为中等的应用组件进行更新提示，而对于紧急程度为普通的应用组件则不进行更新提示，避免对所有的应用组件均进行下载，能够进行资源的合理应用。

请参照图2，一种应用组件即时更新的终端1，包括存储器2、处理器3以及存储在所述存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现以下步骤：

S1、解析更新后的应用组件，为所述更新后的应用组件创建一个类加载器和类的路径加载器；

S2、根据所述应用组件的类别，将所述类加载器和类的路径加载器分别放入对应的类集合中，并建立索引关联；

S3、检测系统中是否存在与所述应用组件对应的目录，若不存在，则创建与所述应用组件对应的目录；

S4、从解析后的更新后的应用组件中拷贝出资源文件、Dex包、引用库文件和MD5文件至所述应用组件对应的目录。

由上述描述可知，本发明的有益效果在于：在进行更新后的应用组件的安装时，为每个更新后的应用组件创建一个类加载器和类的路径加载器，并将其对应的资源文件、Dex包、引用库文件和MD5文件拷贝至所述应用组件对应的目录，实现应用组件的即时更新，不需要应用组件的重启，在进行更新后的应用组件的调用时，只需要读取应用组件的类加载器和类的路径加载器，基于Android应用桌面化开发的原理，基于类加载器和类的路径加载器就可以实现对更新后的应用组件的调用运行，自动遍历应用组件的各个属性，从而将所述应用组件显示出来，无需现有的应用组件更新时的重启操作，操作方便快捷，用户体验好。

进一步的，所述步骤S1还包括：

为所述更新后的应用组件创建启动类，并根据UUID算法为所述更新后的应用组件创建一个编号，生成解析服务类。

由上述描述可知，通过创建启动类和解析服务类，能够保证所述应用组件能够独立运行。

进一步的，还包括步骤：

S5、在主程序下生成与所述更新后的应用组件对应的清单，所述清单包含所述应用组件的名称、对应的目录的路径、类加载器的编号、类的路径加载器的编号以及所述更新后的应用组件创建的时间。

由上述描述可知，在主程序下生成与所述更新后的应用组件对应的清单，即将应用组件拷贝至主程序目录下，保证主程序每次启动时能够快速地读取到相应的应用组件。

进一步的，当接收到从服务器发送的应用组件清单时，所述清单包括应用组件的名称、MD5值、版本号、紧急程度、应用组件下载地址，根据所述接收到的应用组件的名称、MD5值查找在目录中是否存在对应的应用组件；

若是，则根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载。

由上述描述可知，通过对接收的应用组件清单中的应用组件的名称及MD5值的比较能够准确地获知是否安装有能够更新的应用组件，同时基于接收到的应用组件的紧急程度确定是否对对应的应用组件进行下载，可以进行有选择性地对应用组件进行下载。

进一步的，所述根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载具体包括：

所述紧急程度包括重要、中等和普通，若所述紧急程度为重要，则读取对应的应用组件清单中的应用组件下载地址进行应用组件的下载；

若所述紧急程度为中等，则进行更新提示；

若所述紧急程度为普通，则不进行更新提示。

由上述描述可知，对紧急程度为重要的应用组件直接进行自动下载，对紧急程度为中等的应用组件进行更新提示，而对于紧急程度为普通的应用组件则不进行更新提示，避免对所有的应用组件均进行下载，能够进行资源的合理应用。

实施例一

请参照图1，一种应用组件即时更新的方法，包括步骤：

在进行应用组件的开发过程中，对每个应用组件进行打包，生成一个应用包，即APK，可以根据现有的需求层级关系，将每个应用组件进行树形划分，有子应用组件和父应用组件的划分，如果某一应用组件有父级应用组件，则在该组件的Android清单列表，即AndroidManifest.xml中配置父组件的代称，比如父应用组件中有一个页面叫A，则在子应用组件的页面A2中配置A，以保证主程序装载所述子应用组件时，可以读取所述子应用组件的清单；在将更新后的应用组件下载到对应的移动终端后，可以通过后续步骤S1-S4实现对所述更新后的应用组件的即时更新；

S1、解析更新后的应用组件，为所述更新后的应用组件创建一个类加载器和类的路径加载器；

进一步的，还为所述更新后的应用组件创建启动类，并根据UUID算法为所述更新后的应用组件创建一个编号，生成解析服务类；

其中，启动类，相当于系统启动一个应用程序的应用入口类，而在应用组件化中，该入口为每个应用组件的入口类，系统通过将该入口类调用起该入口类所对应的应用组件；

解析服务类其实质就是一个对象类，该对象类保存了应用组件创建的启动类和对应的编号，以及跟该应用组件相关的一些类，比如资源文件对应的ID数组集合，以及资源文件的名称以及该应用组件的上下文；系统可以通过该解析服务类读取应用组件中相关的一些类，并把这些类加入到该应用组件所对应的类加载器中进行加载，同时也保证了系统能通过该类读取该应用组件中的资源文件ID以保证这些类不加入安卓虚拟机的前提下，通过系统为其分配生命周期后，系统使用安卓底层自带的adb_shell的命令为其创建一个独立进程；当系统初始化完应用组件时根据应用组件上的清单上的分割位置，将当前的应用组件放置到该进程中，使得当前应用组件可以独自运行；

在Android操作系统内，可以调用操作系统内置的包解析类PackageParser类，对更新后的应用组件进行解析，解析出Dex包，所述Dex包中存放着java编译后的二进制文件，并为所述更新后的应用组件创建一个类加载器classloader和类的路径加载器patchclassloader以及启动类launcher，并根据UUID算法为其创建一个编号，生成解析服务类PackageApplicationParser类；主程序基于所述类加载器classloader和类的路径加载器patchclassloader可以读取对应的应用组件的类和资源包；

S2、根据所述应用组件的类别，将所述类加载器和类的路径加载器分别放入对应的类集合中，并建立索引关联；

比如，如果相应的类是在Android的Activity类，则将其放入Activity的集合中。包解析类中自带解析应用组件的类的类，解析后，系统会将这些类下所关联的节点进行自动分配；通过将应用组件加入各个应用类，使得应用组件可以独立运行，也可以集成在主程序中；

S3、检测系统中是否存在与所述应用组件对应的目录，若不存在，则创建与所述应用组件对应的目录；

S4、从解析后的更新后的应用组件中拷贝出资源文件、Dex包、引用库文件和MD5文件至所述应用组件对应的目录；

当接收到从服务器发送的应用组件清单时，所述清单包括应用组件的名称、MD5值、版本号、紧急程度、应用组件下载地址，根据所述接收到的应用组件的名称、MD5值查找在目录中是否存在对应的应用组件；

若是，则根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载；

所述根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载具体包括：

所述紧急程度包括重要、中等和普通，若所述紧急程度为重要，则读取对应的应用组件清单中的应用组件下载地址进行应用组件的下载；

若所述紧急程度为中等，则进行更新提示；

若所述紧急程度为普通，则不进行更新提示；

具体的，当进入APP时，主程序会读取应用组件列表中对应的应用组件，检测所述的应用组件的紧急程度，如果是中等，系统会提示是否更新应用，而不是平台主动下推；如果是普通，则在进去APP时，不提示更新，而是进入应用的设置页面时，设置页面上显示应用版本的地方会显示标识更新的红色标记，当所述红色标记被点击后，会进行应用组件的更新。

实施例二

在实施例一的基础上，还包括步骤：

S5、在主程序下生成与所述更新后的应用组件对应的清单，所述清单包含所述应用组件的名称、对应的目录的路径、类加载器的编号、类的路径加载器的编号以及所述更新后的应用组件创建的时间；

主程序负责对应用组件包的安装和读取，管理应用组件包之间的协议和通讯，并合理分配应用组件包之间的树形关系，对于具有父级应用组件的应用组件，主程序在装载时，会读取所述应用组件的清单，并把清单中的配置信息拷贝到主程序目录下，通过合并应用组件的清单到主程序的Android清单内；

为保证主程序可以快速地调起某个应用组件，将每个应用组件的类加载器和类的路径加载器存放到组件池中，并将从Android清单列表中读取出的每一个类加入到对应的集合中，当应用组件需要被调起时，系统会从组件池中读取该类加载所对应的类的集合；

当主程序接收到要从主程序的某一个页面跳转到某一个应用组件时，从PackageServer读取到所述应用组件的类加载器后，启动所述应用组件的Launcher类即可，并且Android系统会自动将该类加入到Android系统自己的堆栈中。

实施例三

请参照图2，一种应用组件即时更新的终端1，包括存储器2、处理器3以及存储在所述存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现实施例一的步骤。

实施例四

请参照图2，一种应用组件即时更新的终端1，包括存储器2、处理器3以及存储在所述存储器2上并可在所述处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现实施例二的步骤。

综上所述，本发明提供的一种应用组件即时更新的方法及终端，在进行更新后的应用组件的安装时，为每个更新后的应用组件创建一个类加载器和类的路径加载器，并将其对应的资源文件、Dex包、引用库文件和MD5文件拷贝至所述应用组件对应的目录，实现应用组件的即时更新，不需要应用组件的重启，在进行更新后的应用组件的调用时，只需要读取应用组件的类加载器和类的路径加载器，基于Android应用桌面化开发的原理，基于类加载器和类的路径加载器就可以实现对更新后的应用组件的调用运行，自动遍历应用组件的各个属性，从而将所述应用组件显示出来，无需现有的应用组件更新时的重启操作，操作方便快捷，用户体验好。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种应用组件即时更新的方法，其特征在于，包括步骤：

S1、解析更新后的应用组件，为所述更新后的应用组件创建一个类加载器和类的路径加载器；

S2、根据所述应用组件的类别，将所述类加载器和类的路径加载器分别放入对应的类集合中，并建立索引关联；

S3、检测系统中是否存在与所述应用组件对应的目录，若不存在，则创建与所述应用组件对应的目录；

S4、从解析后的更新后的应用组件中拷贝出资源文件、Dex包、引用库文件和MD5文件至所述应用组件对应的目录。

2.根据权利要求1所述的一种应用组件即时更新的方法，其特征在于，

所述步骤S1还包括：

为所述更新后的应用组件创建启动类，并根据UUID算法为所述更新后的应用组件创建一个编号，生成解析服务类。

3.根据权利要求1所述的一种应用组件即时更新的方法，其特征在于，

还包括步骤：

S5、在主程序下生成与所述更新后的应用组件对应的清单，所述清单包含所述应用组件的名称、对应的目录的路径、类加载器的编号、类的路径加载器的编号以及所述更新后的应用组件创建的时间。

4.根据权利要求1所述的一种应用组件即时更新的方法，其特征在于，

当接收到从服务器发送的应用组件清单时，所述清单包括应用组件的名称、MD5值、版本号、紧急程度、应用组件下载地址，根据所述接收到的应用组件的名称、MD5值查找在目录中是否存在对应的应用组件；

若是，则根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载。

5.根据权利要求4所述的一种应用组件即时更新的方法，其特征在于，

所述根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载具体包括：

所述紧急程度包括重要、中等和普通，若所述紧急程度为重要，则读取对应的应用组件清单中的应用组件下载地址进行应用组件的下载；

若所述紧急程度为中等，则进行更新提示；

若所述紧急程度为普通，则不进行更新提示。

6.一种应用组件即时更新的终端，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现以下步骤：

S1、解析更新后的应用组件，为所述更新后的应用组件创建一个类加载器和类的路径加载器；

S2、根据所述应用组件的类别，将所述类加载器和类的路径加载器分别放入对应的类集合中，并建立索引关联；

S3、检测系统中是否存在与所述应用组件对应的目录，若不存在，则创建与所述应用组件对应的目录；

S4、从解析后的更新后的应用组件中拷贝出资源文件、Dex包、引用库文件和MD5文件至所述应用组件对应的目录。

7.根据权利要求6所述的一种应用组件即时更新的终端，其特征在于，

所述步骤S1还包括：

为所述更新后的应用组件创建启动类，并根据UUID算法为所述更新后的应用组件创建一个编号，生成解析服务类。

8.根据权利要求6所述的一种应用组件即时更新的终端，其特征在于，

还包括步骤：

S5、在主程序下生成与所述更新后的应用组件对应的清单，所述清单包含所述应用组件的名称、对应的目录的路径、类加载器的编号、类的路径加载器的编号以及所述更新后的应用组件创建的时间。

9.根据权利要求6所述的一种应用组件即时更新的终端，其特征在于，

当接收到从服务器发送的应用组件清单时，所述清单包括应用组件的名称、MD5值、版本号、紧急程度、应用组件下载地址，根据所述接收到的应用组件的名称、MD5值查找在目录中是否存在对应的应用组件；

若是，则根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载。

10.根据权利要求9所述的一种应用组件即时更新的终端，其特征在于，

所述根据所述接收到的应用组件的紧急程度确定是否对所述应用组件进行下载具体包括：

所述紧急程度包括重要、中等和普通，若所述紧急程度为重要，则读取对应的应用组件清单中的应用组件下载地址进行应用组件的下载；

若所述紧急程度为中等，则进行更新提示；

若所述紧急程度为普通，则不进行更新提示。