一种应用拆分以及按需加载方法、装置与流程

本申请涉及电子信息领域，尤其涉及一种应用拆分以及按需加载方法、装置。

背景技术：

react-native(下文简称rn)是facebook公司于2015年4月开源的跨平台移动应用开发框架，目前支持ios和安卓两个平台。rn帮助开发者使用javascript语言，以及css来开发移动应用，并获得与原生应用几乎完全一致的体验。

但是，使用rn开发得到的bundle包(bundle包为一个js文件，用于对应用的各种基础信息进行配置，并用于应用的加载)往往很大，例如，一个输出helloworld的项目，在没有什么逻辑代码的情况下，使用“react-nativebundle”命令打包后生成的bundle文件的大小约为530kb。倘若只有寥寥数个业务，如此大小的bundle文件大小尚可接受，但随着业务的增多，业务复杂性的上升，文件的体积势必会急剧增大，这对有一定规模的应用而言是不可接受的。

而门户类应用相较于一般应用而言，规模更大，包含业务更多，其特点是一个应用中包含多个业务模块的入口，由跨部门、跨区域、甚至跨企业的多团队共同开发，每支团队负责部分模块，可以独立开发和部署。在此情况下，使用rn开发得到的bundle包中，包括应用中的各个模块，即所有业务模块打包成一个应用安装包，热更新升级时也是更新整个安装包，这带来如下缺点：单一模块的功能升级必须连带其它模块一起投产，缺乏灵活性，造成系统不稳定；用户从未点击使用的模块也会随整包下载、加载到内存中，造成流量与内存资源的不必要开销；应用代码量越来越大，逐渐形成牵一发而动全身的大型单体应用，风险较高。

可见，如何将使用rn开发得到的bundle包进行拆分并按需加载，以避免上述缺点，成为目前亟待解决的问题。

技术实现要素：

本申请提供了一种应用拆分以及按需加载方法、装置，目的在于解决如何将使用rn开发得到的bundle包进行拆分并按需加载的问题。

为了实现上述目的，本申请提供了以下技术方案：

一种应用拆分方法，包括：

获取拆分配置文件，所述拆分配置文件包括拆分后的基础模块的名称、业务模块的名称、所述基础模块对应的文件和所述业务模块对应的文件；

获取平台指示参数，所述平台指示参数用于指示android平台或ios平台；

对使用rn得到的应用进行拆分，得到所述基础模块和所述业务模块，所述对使用rn得到的应用进行拆分至少包括：依据所述拆分配置文件和所述平台指示参数，对使用rn得到的应用进行拆分。

可选的，所述基础模块包括：

rn框架代码及其依赖模块、和自定义公共模块代码。

可选的，依据所述平台指示参数，对使用rn得到的应用进行拆分包括：

在所述平台指示参数指示android平台的情况下，使用第一命名规则命名所述基础模块和所述业务模块，并将所述基础模块和所述业务模块所需的静态图片对应存储到目标路径下，所述目标路径为与所述静态图片的分辨率对应的路径；

在所述平台指示参数指示ios平台的情况下，使用第二命名规则命名所述基础模块和所述业务模块，并根据倍图值对所述基础模块和所述业务模块所需的静态图片进行命名。

可选的，所述对使用rn得到的应用进行拆分还包括：

使用js解析工具，按照模块定义和模块调用的固定范式解析得到所述基础模块和所述业务模块之间的调用关系，并根据所述调用关系，给每个模块赋予对应的序号，以便拆分后的模块在运行过程中确定各自依赖的模块。

可选的，还包括：

为所述业务模块分配唯一的标识。

一种按需加载方法，包括：

将基础模块设置为默认启动的模块；

在应用启动时，加载所述基础模块；

依据用户的点击指令，加载业务模块中被所述用户点击的业务模块；

其中，所述基础模块和所述业务模块依据以上所述的方法得到。

可选的，在所述加载业务模块中被所述用户点击的业务模块之前，还包括：

查询被所述用户点击的业务模块是否存在更新包，如果是，下载所述更新包；

所述加载业务模块中被所述用户点击的业务模块包括：

加载被下载的所述更新包。

一种应用拆分装置，包括：

第一获取模块，用于获取拆分配置文件，所述拆分配置文件包括拆分后的基础模块的名称、业务模块的名称、所述基础模块对应的文件和所述业务模块对应的文件；

第二获取模块，用于获取平台指示参数，所述平台指示参数用于指示android平台或ios平台；

拆分模块，用于对使用rn得到的应用进行拆分，得到所述基础模块和所述业务模块，所述对使用rn得到的应用进行拆分至少包括：依据所述拆分配置文件和所述平台指示参数，对使用rn得到的应用进行拆分。

可选的，所述基础模块包括：

rn框架代码及其依赖模块、和自定义公共模块代码。

可选的，所述拆分模块用于依据所述平台指示参数，对使用rn得到的应用进行拆分包括：

所述拆分模块具体用于，在所述平台指示参数指示android平台的情况下，使用第一命名规则命名所述基础模块和所述业务模块，并将所述基础模块和所述业务模块所需的静态图片对应存储到目标路径下，所述目标路径为与所述静态图片的分辨率对应的路径；在所述平台指示参数指示ios平台的情况下，使用第二命名规则命名所述基础模块和所述业务模块，并根据倍图值对所述基础模块和所述业务模块所需的静态图片进行命名。

可选的，所述拆分模块还用于：

使用js解析工具，按照模块定义和模块调用的固定范式解析得到所述基础模块和所述业务模块之间的调用关系，并根据所述调用关系，给每个模块赋予对应的序号，以便拆分后的模块在运行过程中确定各自依赖的模块。

可选的，所述拆分模块还用于：

为所述业务模块分配唯一的标识。

一种按需加载装置，包括：

设置模块，用于将基础模块设置为默认启动的模块；

加载模块，用于在应用启动时，加载所述基础模块，并依据用户的点击指令，加载业务模块中被所述用户点击的业务模块；

其中，所述基础模块和所述业务模块依据以上所述的应用拆分装置得到。

可选的，所述加载模块还用于：

查询被所述用户点击的业务模块是否存在更新包，如果是，下载所述更新包；

所述加载模块用于加载业务模块中被所述用户点击的业务模块包括：

所述加载模块具体用于，加载被下载的所述更新包。

本申请所述的方法及装置，依据拆分配置文件和平台指示参数，对使用rn得到的应用进行拆分，得到基础模块和业务模块，应用启动时，加载基础模块和被用户点击的业务模块，因此能够实现业务模块的按需加载，从而节省时间和资源。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请书实施例公开的一种应用拆分方法的流程图；

图2为本申请实施例公开的应用拆分方法中使用的配置文件的示例图；

图3为现有技术中默认bundle目录结构示意图；

图4为本申请实施例公开的应用拆分方法拆分后的目录结构示意图；

图5为本申请实施例公开的应用拆分方法拆分前后的实际目录结构图；

图6为本申请实施例公开的一种按需加载方法的流程图；

图7为ios平台加载的逻辑示意图；

图8为android平台加载的逻辑示意图；

图9为ios平台加载的核心代码示意图；

图10为android平台加载的核心代码示意图；

图11为本申请实施例公开的一种应用拆分装置的结构示意图；

图12为本申请实施例公开的一种需加载装置的结构示意图。

具体实施方式

本申请实施例所述的方法，适用但不限于由多团队并行合作开发的包括多个模块的应用。这类应用在开发时，多团队并行合作，不同模块采用不同分支进行并行开发；投产验收测试前，从分支合并到主干，在主干上进行回归测试，如果有原生代码变化，需要构建、发布新版本apk或者ipa；如果只有业务模块的js或者图片等静态资源变化，可以单独发布热更新包。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请书实施例公开的一种应用拆分方法，包括以下步骤：

s101：获取拆分配置文件。

本实施例中，拆分配置文件包括拆分后的基础模块的名称、业务模块的名称、基础模块对应的文件和业务模块对应的文件。

以图2为例进行说明：图2中，通过配置splitconfig文件，完成拆分设置，配置文件用于配置被拆分形成的基础模块和业务模块，例如包括各个模块的名称、对应的文件(包括入口文件和js文件)、基础模块包含的模块等。

可选的，拆分配置文件中还可以包括拆分后的整体数据包的名称，如图2所示的整包名。

本实施例中，基础模块包括的模块，即需要被放入拆分后的基础模块的模块包括：rn框架代码及其依赖模块、和自定义公共模块代码。rn框架代码的一个示例为：polyfill，polyfill是bundle最开始的一段代码，主要是向javascript解释器上下文注入一些能力，比如模块系统、引用函数等。

综上所述，拆分配置文件的作用为，指示基础模块和业务模块各自所需要包含的所有代码以及各自包含的资源模块。

配置文件可以由开发人员设置并输入。

s102：获取平台指示参数，所述平台指示参数用于指示android平台或ios平台。

实际应用中，可以通过命令行的方式输入平台指示参数，指示具体是针对哪一个平台进行拆分，例如，通过“--platform”这个参数来指定平台，针对ios平台，则命令行中关于平台的内容为“--platformios”，针对android平台，则命令行中关于平台的内容为“--platformandroid”。

s103：对使用rn得到的应用进行拆分，得到基础模块和业务模块。

拆分的过程具体可以包括以下几个方面：

1、依据拆分配置文件，拆分得到基础模块和业务模块。

2、依据平台指示参数，对使用rn得到的应用进行拆分。对两个平台作出的不同拆分动作主要体现在模块的命名和图片文件的存放路径两个方面。

具体的，关于bundle包命名：在平台指示参数指示android平台的情况下，使用第一命名规则命名基础模块和业务模块，在平台指示参数指示ios平台的情况下，使用第二命名规则命名基础模块和业务模块。

例如：android平台的bundle命名规则为：以“.android.bundle”为文件名后缀。ios平台的bundle命名规则为：以“.jsbundle”为文件名后缀。因此，无论是基础模块还是业务模块，在平台指示参数指示android平台的情况下，均使用“.android.bundle”为文件名后缀，在平台指示参数指示ios平台的情况下，均使用“.jsbundle”为文件名后缀。

关于图片文件存放路径：android平台通常有4个静态文件存放路径，drawable-lhdpi、drawable-mdpi、drawable-hdpi、drawable-xhdpi，这4个路径分别用于存放低分辨率、中等分辨率、高分辨率、以及960*720分辨率以上的图片。基于此，在平台指示参数指示android平台的情况下，将基础模块和业务模块所需的静态图片对应存储到目标路径下，目标路径为与静态图片的分辨率对应的路径。如，模块a中有一张中等分辨率的图片文件pica.jpg，则其存放路径为a/drawable-mdpi/pica.jpg。

而ios平台中则无需将不同分辨率图片放入不同路径，只需根据倍图值来对图片进行命名即可，如，模块b中有一张图片picb.jpg，普通命名为picb.jpg，2倍图命名为：picb@2x.jpg，3倍图命名为：picb@3x.jpg，系统在加载图片时，会自动根据设备屏幕尺寸读取对应的图片，同时该图片的路径也与android平台不同，图片都将存放在b/assets/src/assets/路径下。基于此，在平台指示参数指示ios平台的情况下，根据倍图值对基础模块和业务模块所需的静态图片进行命名。

3、进一步的，各个rn模块之间很可能存在相互调用的依赖关系，众多模块相互依赖就形成一颗模块依赖树，每一个模块都是这棵树上的一个节点。基于此，在拆分过程中，可以使用第三方js解析工具如babylon或babel等，按照模块定义和模块调用的固定范式对这棵树进行解析，并得到各个模块之间的依赖调用关系，并根据依赖的先后顺序，给每个模块赋予一个序号，以便拆分后的程序在运行过程中能够确定各自依赖的模块。

举例说明：rn模块之间的依赖关系使用“require”关键字，众多模块相互依赖形成一颗模块依赖树。由于模块定义和调用都具有固定的格式，因此，在使用第三方工具如babylon或者babel等来解析依赖树时，只需按照这种固定的格式去解析即可。具体的解析过程可以参见现有技术，这里不再赘述。

比如，判断一个依赖树上的节点是否为模块定义节点，仅需判断该节点的type是否为“expressionstatement”，以及节点的表达式type是否为“callexpression”，以及节点的表达式调用类型是否为“identifier”，以及节点的表达式调用名称是否为“d”，如果同时满足，则表示该节点为模块定义节点。同理可划分出模块调用节点。而模块之间的依赖关系则使用正则表达式去匹配“require”关键字即可。

4、可选的，可以为业务模块分配唯一标识，以用于后续更新过程的区分。

图3为现有技术中默认bundle目录结构示意图，图4为拆分bundle后的目录结构示意图。从图3和图4的区别可以看出拆分钱后的bundle文件的区别：拆分后，root根目录下包含base路径和business路径，两个路径下又包含各自的bundle文件和静态图片资源文件。

在实际中，可以依据拆分配置文件和平台指示参数编写拆分脚本，并通过运行拆分脚本进行bundle拆分，完成后该项目的实际目录结构如图5所示。

从图1所示的过程可以看出，本实施例中所述的应用拆分方法，可以针对两大主流平台android平台或ios平台，进行应用的拆分，拆分得到基础模块和业务模块，为后续模块的按需加载奠定基础。

完成拆分后，需要对拆分后的bundle包进行分步加载，图6为本申请实施例公开的一种按需加载方法，包括以下步骤：

s601：将基础模块设置为默认启动的模块。

s602：在应用启动时，加载基础模块。

s603：依据用户的点击指令，判断被用户点击的业务模块是否存在更新包，如果是，执行s604，如果否，执行s605。

s604：下载并加载更新包。

s605：加载业务模块中被用户点击的业务模块。

具体的，可以通过rn官方推荐的方式加载基础模块。业务模块的加载，针对不同平台使用不同方式：

ios采用rn开发主界面，再分步加载其它业务模块(图7所示)，其核心代码如图9所示。android采用原生java语言开发主界面，再分步加载业务模块(图8所示)，其核心代码如图10所示。

本实施例中，由于拆分后的模块适用于本地加载，因此，步骤s604中，先下载更新包后再进行加载。具体的，业务模块的更新包由开发者通过web发布管理工具上传至文件服务器中，发布时指定包所属应用、版本、业务模块的标识，作为元数据存储到数据库中。s603中，从数据库中查询被用户点击的业务模块是否存在更新包。

从图6所示的方法可以看出，基于应用的拆分，在应用启动时，只需加载基础模块和被用户点击的业务模块，而对于其它业务模块，不进行加载，并且，只更新被用户点击的业务模块，而无需下载整个应用bundle包。从而大幅减少应用首次加载以及更新的时间消耗。并且，以拆分后的业务模块为更新的粒度单位，能够减少更新包下载和载入的时间成本。

图11为本申请实施例公开的一种应用拆分装置，包括：第一获取模块、第二获取模块和拆分模块。

其中，第一获取模块用于获取拆分配置文件。第二获取模块用于获取平台指示参数，所述平台指示参数用于指示android平台或ios平台。拆分模块用于对使用rn得到的应用进行拆分，得到所述基础模块和所述业务模块，所述对使用rn得到的应用进行拆分至少包括：依据所述拆分配置文件和所述平台指示参数，对使用rn得到的应用进行拆分。

以上各个模块的功能的具体实现过程，可以参见图1所示的方法，这里不再赘述。

图12为本申请实施例公开的一种需加载装置，包括：设置模块和加载模块。其中，设置模块用于将基础模块设置为默认启动的模块。加载模块用于在应用启动时，加载所述基础模块，并依据用户的点击指令，加载业务模块中被所述用户点击的业务模块，以及查询被所述用户点击的业务模块是否存在更新包，如果是，下载所述更新包。在此情况下，加载模块加载被下载的所述更新包。

以上各个模块的功能的具体实现过程，可以参见图6所示的方法，这里不再赘述。

图11所示的装置可以实现应用的拆分，图12所示的装置，可以在应用拆分的基础上，实现业务模块的按需加载。图11以及图12所示的装置，可以构成一种按需加载的平台。

本申请实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算设备可读取存储介质中。基于这样的理解，本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一台计算设备(可以是个人计算机，服务器，移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。