WO2019029451A1 - 发布移动应用的方法和电子设备 - Google Patents

Abstract

本申请公开了发布移动应用的方法和电子设备。该方法的一具体实施方式包括：获取宿主文件，其中，宿主文件为非业务功能文件，用以加载至少一个业务插件文件来实现与该业务插件文件关联的移动应用的业务功能；根据宿主文件生成安装包；发布安装包。该实施方式提高了移动应用的发布效率。

Description

发布移动应用的方法和电子设备 技术领域

本申请涉及计算机技术领域，具体涉及互联网技术领域，尤其涉及发布移动应用的方法和电子设备。

背景技术

目前移动应用主要分为Android(安卓)应用和iOS(由苹果公司开发的移动操作系统)应用，在传统的移动应用开发过程中，都是按照功能模块划分好，分配到不同的人员开发，最后合并代码编译打包，上线发布。但是随着公司规模越来越大，业务越来越多，业务变更频繁的情况，这种开发方案就会显现弊端。每个新的特性由不同开发人员实现，上线之前需合并代码，接着编译打包准备上线，由于移动应用上线是需要市场的审核，这个时间多则1～2天，长则1个星期，另外，上线之后不是所有用户都会更新，这些都严重影响产品新特性的上线速度。另外，如果线上应用出现紧急问题的时候，也只能重新打包发布上线，严重耽误时间，降低了移动应用的发布效率。

发明内容

本申请实施例的目的在于提出一种改进的发布移动应用的方法和电子设备，来解决以上背景技术部分提到的技术问题。

第一方面，本申请实施例提供了一种实现移动应用功能的方法，该方法包括：响应于移动应用的启动，移动应用的宿主模块加载移动应用的至少一个业务插件，以实现所述移动应用的业务功能，其中，该宿主模块为非业务功能模块。

在一些实施例中，该方法包括：获取根据宿主文件生成的安装包，安装该安装包以获得宿主模块。

在一些实施例中，宿主模块包括插件加载框架、插件升级框架、 公共UI库和组件接口。

在一些实施例中，至少一个业务插件的插件文件存储于移动应用的资源目录中。

在一些实施例中，宿主模块通过预定接口加载至少一个业务插件。

在一些实施例中，预定接口包括Fragment类，至少一个业务插件的插件文件包括业务插件描述文件，每个业务插件描述文件里面配置有其所要被加载的Fragment类的名称。

在一些实施例中，宿主模块通过预定接口加载至少一个业务插件，包括：读取至少一个业务插件的插件文件中每个业务插件描述文件中Fragment类的名称，通过Fragment类的名称初始化Fragment类对象，并将Fragment类对象加载到宿主模块中。

在一些实施例中，该方法还包括：响应于检测到网络设备存储的业务插件发生变化，向网络设备发送插件更新请求；接收网络设备发送的发生变化的业务插件并重新加载。

第二方面，本申请实施例提供了一种发布移动应用的方法，该方法包括：获取宿主文件，其中，宿主文件为非业务功能文件，用以加载至少一个业务插件文件来实现与该业务插件文件关联的移动应用的业务功能；根据宿主文件生成安装包；发布安装包。

在一些实施例中，该方法包括：

获取所述移动应用的至少一个业务插件文件；

以及根据所述宿主文件生成安装包包括：

根据所述宿主文件以及至少一个业务插件文件生成安装包。

在一些实施例中，该方法还包括：获取用于更新移动应用的新业务插件文件；向已经安装并启动移动应用的移动终端发送新业务插件文件。

在一些实施例中，该方法还包括：获取用于更新移动应用的新业务插件文件；向已经安装并启动移动应用的移动终端发送插件更新请求；响应于接收到移动终端发送的更新确认消息，向移动终端发送新业务插件文件。

第三方面，本申请实施例提供了一种电子设备，包括：一个或多 个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如第一方面和第二方面中任一的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如第一方面和第二方面中任一的方法。

本申请实施例提供的发布移动应用的方法和电子设备，产品服务器将由宿主文件生成的安装包发送到市场服务器进行发布。其中，宿主文件为非业务功能文件，用以加载至少一个业务插件文件来实现与该业务插件文件关联的移动应用的业务功能，发布之后长时间不需要更新。而产品真正的功能和特性由业务插件来完成，不同的业务可以是不同的插件，插件由宿主程序动态加载。移动终端安装了移动应用之后，就可直接从产品服务器获取业务插件文件，以避免市场服务器对业务插件文件的审核，提高了移动应用的发布效率。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请可以应用于其中的示例性系统架构图；

图2是根据本申请的发布移动应用的方法的一个实施例的流程图；

图3a、3b、3c是根据本申请的发布移动应用的方法的一个应用场景的示意图；

图4是根据本申请的实现移动应用功能的方法的一个实施例的流程图；

图5是适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解 的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1示出了可以应用本申请的发布移动应用的方法的实施例的示例性系统架构100。

如图1所示，系统架构100可以包括移动终端101、102，市场服务器103和产品服务器104。移动终端101、102和市场服务器103之间，市场服务器103和产品服务器104之间，通过有线、无线通信链路或者光纤电缆等等连接。

用户可以使用移动终端101、102与市场服务器103交互，从市场服务器103下载各种移动应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

移动终端101、102可以是具有显示屏并且支持安卓或iOS操作系统的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

市场服务器103可以是提供各种移动应用的服务器。市场服务器103可以对接收到的移动应用下载请求等数据进行分析等处理，并将处理结果(例如移动应用的安装包)反馈给移动终端。

产品服务器104将编译完成的移动应用的安装包上传至市场服务器103，以便移动终端101、102从市场服务器103下载。产品服务器104还在移动终端101、102安装了移动应用后直接向移动终端101、102提供用于实现业务功能的业务插件文件。

应该理解，图1中的移动终端、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的移动终端、网络和服务器。

继续参考图2，示出了根据本申请的发布移动应用的方法的一个实施例的流程200。该发布移动应用的方法，包括以下步骤：

步骤201，获取宿主文件。

在本实施例中，发布移动应用的方法运行于其上的电子设备(例如图1所示的产品服务器)可以通过有线连接方式或者无线连接方式从开发人员的终端获取宿主文件。其中，宿主文件为非业务功能文件，用以加载至少一个业务插件文件来实现与该业务插件文件关联的移动应用的业务功能。宿主文件不具有与用户交互的功能，其用于动态加载至少一个业务插件文件，而业务插件实现了呈现给用户，与用户进行交互的业务功能。业务功能被封装到业务插件中，一个程序员负责若干个业务插件，每一个业务插件由其相应功能涉及的界面、业务逻辑和数据访问等代码组成。每一个业务插件可以独立开发、测试和部署，开发者间不再需要对代码进行合并。宿主文件包括：1.插件加载框架，2.插件升级框架，3.公共UI(User Interface，用户界面)库和组件接口。插件加载框架可以加载业务插件文件实现业务功能。插件加载框架对CLR(Common Language Runtime，公共语言运行库)类加载进行扩展，使其能够从插件目录中正确加载到插件程序集。插件加载框架还需要引入插件描述方法，它来告知当前插件的基本信息、版本标识、以及这个插件所包含的程序集。插件升级框架可以支持业务插件的更新，当发现产品服务品上出现新版本业务插件时，可以自动更新。公共UI库和组件接口用于实现宿主对插件的加载。

在本申请中，可把移动应用整体架构分成：宿主+业务插件1+业务插件2+业务插件3等。全面插件化方案具体指，核心功能和非核心功能都是业务插件。比如，通常移动应用打开后会有3个或者多个标签页(TAB)，如图3a-3c所示，在传统的移动应用插件方案中，这3个TAB都是核心功能，都是集成在应用的主程序当中，而把二级菜单的一些页面，比如“摇一摇”，“礼物”，“工具”等非核心功能做成业务插件，而在本申请中，每个TAB都是一个业务插件，而且随着业务的增加和删除，TAB的个数也可以随之变化。

在本实施例的一些可选的实现方式中，宿主文件通过预定接口加 载所述至少一个业务插件文件。实现TAB的功能的业务插件都需要继承于预定接口类。

在本实施例的一些可选的实现方式中，在Android的解决方案中，预定接口包括Fragment类。至少一个业务插件的插件文件包括业务插件描述文件，各业务插件描述文件里面配置了各业务所要被加载的Fragment类的名称。移动应用启动的时候，宿主会去读取每个业务插件的业务插件描述文件，业务插件描述文件里面配置了该业务所要被加载的Fragment类的名称，宿主读取这些Fragment类的名称，通过初始化Fragment对象，并加载显示在宿主里面，从而达到每个TAB都是业务插件，且在宿主界面里面切换显示。

步骤202，根据宿主文件生成安装包。

在本实施例中，可以将宿主文件单独打包成移动应用的安装包，而不包括任何业务插件文件。也可将至少一个业务插件文件与宿主文件一起打包，其中，至少一个业务插件文件可以二进制文件形式存储在移动应用的资源目录中。后续开发中更新的业务插件也存储在移动应用的资源目录中。

步骤203，发布安装包。

在本实施例中，上述电子设备需要将安装包上传至市场服务器并且经审核通过后由市场服务器发布后，用户的移动终端才能从市场服务器下载该安装包。通常移动应用上线是需要市场的审核，审核时间多则1～2天，长则1个星期，另外，上线之后不是所有用户都会更新，这些都严重影响产品新特性的上线速度。另外，如果线上应用出现紧急问题的时候，也只能重新打包发布上线，严重耽误时间，影响了用户，导致用户流失。

在本实施例的一些可选的实现方式中，该方法还包括：获取用于更新移动应用的新业务插件文件；向已经安装并启动该移动应用的移动终端发送新业务插件文件。在产品新功能迭代的时候或在产品出现问题需要紧急修复时，不需要重新发版本，无需市场审核等待的时间，直接云端新增业务插件向移动终端推送，让用户无感知的实现了问题修复，使其自动下载更新。

在本实施例的一些可选的实现方式中，该方法还包括：获取用于更新移动应用的新业务插件文件；向已经安装并启动移动应用的移动终端发送插件更新请求；响应于接收到移动终端发送的更新确认消息，向移动终端发送新业务插件文件。即，通知移动终端可以更新业务插件，用户可自行选择是否进行更新。用户同意更新时才发新业务插件文件。

继续参见图3a-3c，图3a-3c是根据本实施例的发布移动应用的方法的应用场景的一个示意图。在图3a-3c的应用场景中，对于实现3个业务的移动应用，开发人员预先把移动应用整体架构分成：宿主+业务插件1+业务插件2+业务插件3。如图3a-3c所示，这3个标签页分别由实现核心功能的业务插件1、业务插件2、业务插件3生成。图3a中所示的是宿主加载了业务插件1后显示的业务1的界面。图3b中所示的是宿主加载了业务插件2后显示的业务2的界面。图3c中所示的是宿主加载了业务插件3后显示的业务3的界面。图3a-3c显示的都是一级标签页面，用户可在这三个界面之间切换选择。上述电子设备获取这4部分的文件，但没有将业务插件集成在应用的主程序当中，而是仅将宿主上传至市场服务器，将这3个业务插件文件存储在产品服务器中。市场服务器对宿主主程序进行审核后正式发布，移动终端可从市场服务器下载安装该移动应用的安装包。当用户安装并启用该移动应用时，从产品服务器的移动应用的资源目录获取3个业务插件加载到宿主中。当业务插件文件更新时，无需再上传到市场服务器，而直接发送给移动终端即可。

本申请的上述实施例提供的方法通过将移动应用分成宿主和业务插件，将宿主上传至市场服务器进行审核，并将业务插件文件存储在产品服务器中，产品服务器中的业务插件文件不用审核即可直接发给移动终端，实现移动应用的全面插件化，从而提高了移动应用的发布效率。

进一步参考图4，其示出了实现移动应用功能的方法的一个实施例的流程400。该实现移动应用功能的方法的流程400，包括以下步骤：

步骤401，启动移动应用。

在本实施例中，实现移动应用的方法运行于其上的电子设备(例如图1所示的移动终端)已经安装包含宿主模块及宿主模块加载的至少一个业务插件的移动应用后，启动该移动应用以实现所述移动应用的业务功能。其中，该宿主模块为非业务功能模块，不实现任何业务功能，其用于动态加载至少一个业务插件文件。

在本实施例的一些可选的实现方式中，移动终端可从网络设备获取根据宿主文件生成的安装包；安装该安装包以获得宿主模块。安装包括可只包括宿主模块，也可包括宿主模块和至少一个业务插件文件。

在本实施例的一些可选的实现方式中，安装安装包获得的宿主模块包括：1.插件加载框架，2.插件升级框架，3.公共UI(User Interface，用户界面)库和组件接口。插件加载框架可以加载业务插件文件实现业务功能。插件加载框架对CLR(Common Language Runtime，公共语言运行库)类加载进行扩展，使其能够从插件目录中正确加载到插件程序集。插件加载框架还需要引入插件描述方法，它来告知当前插件的基本信息、版本标识、以及这个插件所包含的程序集。插件升级框架可以支持业务插件的更新，当发现产品服务品上出现新版本业务插件时，可以自动更新。公共UI库和组件接口用于实现宿主对插件的加载。

在本实施例的一些可选的实现方式中，安装完该安装包之后，首次启动移动应用的时候从移动应用的资源目录中拷贝至少一个业务插件文件至移动应用的资源目录中。

在本实施例的一些可选的实现方式中，宿主模块通过预定接口加载所述至少一个业务插件。

在本实施例的一些可选的实现方式中，在Android的解决方案中，预定接口包括Fragment类，至少一个业务插件的插件文件包括业务插件描述文件，每个业务插件描述文件里面配置了其所要被加载的Fragment类的名称。

步骤402，宿主模块加载至少一个业务插件。

在本实施例中，拷贝至少一个业务插件文件至移动应用的资源目录中之后，宿主模块通过预定接口加载至少一个业务插件文件，使得 移动应用能够实现每个业务插件的功能。

在本实施例的一些可选的实现方式中，宿主模块通过预定接口加载至少一个业务插件文件，包括：读取至少一个业务插件的插件文件中每个业务插件描述文件中Fragment类的名称，通过Fragment类的名称初始化Fragment类对象，并将Fragment类对象加载到宿主模块中。从而达到每个TAB都是业务插件，且在宿主界面里面切换显示。

在本实施例的一些可选的实现方式中，该方法还包括：响应于检测到网络设备存储的业务插件文件发生变化，向网络设备发送插件更新请求；接收网络设备发送的发生变化的业务插件文件并重新加载。网络设备可以是市场服务器，也可以是产品服务器。网络设备上的业务插件文件发生变化时，可通知移动终端进行更新，也可直接向移动终端推送更新后的业务插件文件以使得移动终端的宿主重新加载业务插件文件。可选的，移动终端上的移动应用也可向网络设备主动发起业务插件文件检测，当检测到业务插件文件发生更新时，下载新的业务插件文件并重新加载。

从图4中可以看出，与图2对应的实施例相比，本实施例中的实现移动应用功能的方法的流程400突出了移动终端加载业务插件文件的步骤。由此，提高了移动终端上的移动应用的更新速度。

下面参考图5，其示出了适于用来实现本申请实施例的电子设备的计算机系统500的结构示意图。图5示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

需要说明的是，图5示出的电子设备可以为实现移动应用功能的的移动终端，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。此外图5示出的电子设备还可以为发布移动应用的设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

如图5所示，计算机系统500包括中央处理单元(CPU)501，其 可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行各种适当的动作和处理。在RAM 503中，还存储有系统500操作所需的各种程序和数据。CPU 501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

以下部件连接至I/O接口505：包括键盘、鼠标等的输入部分505；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被中央处理单元(CPU)501执行时，执行本申请的方法中限定的上述功能。需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者 与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备发布移动应用或实现移动应用功能。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于) 具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (14)

1. 一种实现移动应用功能的方法，其特征在于，所述方法包括：

   响应于移动应用的启动，移动应用的宿主模块加载移动应用的至少一个业务插件，以实现所述移动应用的业务功能，其中，该宿主模块为非业务功能模块。
2. 根据权利要求1所述的方法，其特征在于，所述方法包括：

   获取根据宿主文件生成的安装包；

   安装所述安装包以获得所述宿主模块。
3. 根据权利要求1所述的方法，其特征在于，所述宿主模块包括：插件加载框架、插件升级框架、公共UI库和组件接口。
4. 根据权利要求1所述的方法，其特征在于，所述至少一个业务插件的插件文件存储于所述移动应用的资源目录中。
5. 根据权利要求1所述的方法，其特征在于，所述宿主模块通过预定接口加载所述至少一个业务插件。
6. 根据权利要求5所述的方法，其特征在于，所述预定接口包括Fragment类，所述至少一个业务插件的插件文件包括业务插件描述文件，每个业务插件描述文件里面配置有其所要被加载的Fragment类的名称。
7. 根据权利要求6所述的方法，其特征在于，所述宿主模块通过预定接口加载所述至少一个业务插件，包括：

   读取所述至少一个业务插件的插件文件中每个业务插件描述文件中Fragment类的名称，通过Fragment类的名称初始化Fragment类对象，并将所述Fragment类对象加载到所述宿主模块中。
8. 根据权利要求1所述的方法，其特征在于，所述方法还包括：

   响应于检测到网络设备存储的业务插件发生变化，向所述网络设备发送插件更新请求；

   接收所述网络设备发送的发生变化的业务插件并重新加载。
9. 一种发布移动应用的方法，其特征在于，所述方法包括：

   获取宿主文件，其中，所述宿主文件为非业务功能文件，用以加载至少一个业务插件文件来实现与该业务插件文件关联的移动应用的业务功能；

   根据所述宿主文件生成安装包；

   发布所述安装包。
10. 根据权利要求9所述的方法，其特征在于，该方法还包括：

    获取所述移动应用的至少一个业务插件文件；

    以及根据所述宿主文件生成安装包包括：

    根据所述宿主文件以及至少一个业务插件文件生成安装包。
11. 根据权利要求9-10之一所述的方法，其特征在于，所述方法还包括：

    获取用于更新所述移动应用的新业务插件文件；

    向已经安装并启动所述移动应用的移动终端发送所述新业务插件文件。
12. 根据权利要求9-10之一所述的方法，其特征在于，所述方法还包括：

    获取用于更新所述移动应用的新业务插件文件；

    向已经安装并启动所述移动应用的移动终端发送插件更新请求；

    响应于接收到所述移动终端发送的更新确认消息，向所述移动终端发送所述新业务插件文件。
13. 一种电子设备，包括：

    一个或多个处理器；

    存储装置，用于存储一个或多个程序，

    当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-12中任一所述的方法。
14. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-12中任一所述的方法。

Images