CN109840116A - 一种加载资源文件的方法和装置 - Google Patents

Abstract

本发明公开了一种加载资源文件的方法和装置，涉及计算机技术领域。该方法的一具体实施方式中，所述资源文件被预先拆分为至少一个通用文件和至少一个业务文件；所述通用文件包括前端应用程序各业务所对应的资源文件的公共数据，所述业务文件包括前端应用程序各业务所对应的资源文件的业务数据；所述方法包括：将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流；合并所述通用文件流和业务文件流以得到资源文件流；将所述资源文件流传递至所述前端应用程序的执行器以完成资源文件的加载。该实施方式能够减少资源文件的磁盘占用，并提高资源文件的加载速度。

Description

一种加载资源文件的方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种加载资源文件的方法和装置。

背景技术

随着内容的不断丰富，客户端应用程序包含了越来越多的业务内容，相应的其资源文件的大小也不断增加。由于开发过程中可能涉及到的业务模块很多，会建立对应于不同的业务的多个资源文件。这样的涉及可以方便对于单一业务的升级，但也带来了单个资源文件的数据量过大的问题；一方面会引起应用程序的安装包数据量过大，另一方面也会导致资源文件的架子速度缓慢，内存开销增加。

现有技术中针对资源文件数据量过大的问题提出了一些解决方案，通常是将资源文件进行预先拆分，在应用程序启动时或者具体业务启用时，再将资源文件进行合并保存至磁盘等外部存储器中，进行调用。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：现有技术的方法解决了应用程序安装包数据量过大的问题，但是实际上合并得到的资源文件会以临时文件的形式存储在客户端的磁盘中，仍然存在占用存储空间的问题；此外由于要生成新的磁盘文件，以及读取该新的磁盘文件，因此存在额外的读写磁盘操作，会导致应用程序启动速度或业务加载速度缓慢。

发明内容

有鉴于此，本发明实施例提供一种加载资源文件的方法和装置，能够减少资源文件的磁盘占用，并提高资源文件的加载速度。

为实现上述目的，根据本发明实施例的一个方面，提供了一种加载资源文件的方法，所述资源文件被预先拆分为至少一个通用文件和至少一个业务文件；所述通用文件包括前端应用程序各业务所对应的资源文件的公共数据，所述业务文件包括前端应用程序各业务所对应的资源文件的业务数据；所述方法包括：

将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流；

合并所述通用文件流和业务文件流以得到资源文件流；

将所述资源文件流传递至所述前端应用程序的执行器以完成资源文件的加载。

可选的，将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流的步骤包括：

在前端应用程序的业务被启动时，获取由与所述业务对应的资源文件拆分得到的通用文件和业务文件的存储路径；

以文件流的方式将所述存储路径对应的所述通用文件和业务文件读取至内存中。

可选的，所述方法还包括：

在将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流的步骤后，

将所述通用文件流存储在内存中；

确定需要再次读取所述通用文件时，调用存储在内存中的所述通用文件流。

可选的，将所述资源文件流传递至前端应用程序的执行器以完成资源文件的加载的步骤包括：

将所述资源文件流传递至前端应用程序的执行器后，使用所述执行器根据所述资源文件流形成可执行的资源代码。

可选的，所述前端应用程序为基于React Native框架开发的应用程序，所述资源文件为所述应用程序中的Bundle文件。

为实现上述目的，根据本发明实施例的另一个方面，提供了一种加载资源文件的装置，所述资源文件被预先拆分为至少一个通用文件和至少一个业务文件；所述通用文件包括前端应用程序各业务所对应的资源文件的公共数据，所述业务文件包括前端应用程序各业务所对应的资源文件的业务数据；所述装置包括：

流读取模块，用于将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流；

流合并模块，用于合并所述通用文件流和业务文件流以得到资源文件流；

流传递模块，用于将所述资源文件流传递至所述前端应用程序的执行器以完成资源文件的加载。

可选的，所述流读取模块还用于：

在前端应用程序的业务被启动时，获取由与所述业务对应的资源文件拆分得到的通用文件和业务文件的存储路径；

以文件流的方式将所述存储路径对应的所述通用文件和业务文件读取至内存中。

可选的，所述流读取模块还用于：

将所述通用文件流存储在内存中；

确定需要再次读取所述通用文件时，调用存储在内存中的所述通用文件流。

可选的，所述流传递模块还用于：

将所述资源文件流传递至前端应用程序的执行器后，使用所述执行器根据所述资源文件流形成可执行的资源代码。

可选的，所述前端应用程序为基于React Native框架开发的应用程序，所述资源文件为所述应用程序中的Bundle文件。

为实现上述目的，根据本发明实施例的再一个方面，提供了一种加载资源文件的电子设备，包括：

一个或多个处理器；

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

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器至少实现：

将通用文件读取为通用文件流，将业务文件读取为业务文件流；其中，所述通用文件和所述业务文件由所述资源文件拆分得到；所述通用文件包括前端应用程序各业务所对应的资源文件的公共数据，所述业务文件包括前端应用程序各业务所对应的资源文件的业务数据；

合并所述通用文件流和业务文件流以得到资源文件流；

将所述资源文件流传递至所述前端应用程序的执行器以完成资源文件的加载。

为实现上述目的，根据本发明实施例的又一个方面，提供一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时至少实现：

将通用文件读取为通用文件流，将业务文件读取为业务文件流；其中，所述通用文件和所述业务文件由所述资源文件拆分得到；所述通用文件包括前端应用程序各业务所对应的资源文件的公共数据，所述业务文件包括前端应用程序各业务所对应的资源文件的业务数据；

合并所述通用文件流和业务文件流以得到资源文件流；

将所述资源文件流传递至所述前端应用程序的执行器以完成资源文件的加载。

上述发明中的一个实施例具有如下优点或有益效果：因为采用了将由资源文件拆分得到的子文件读取为子文件流，在合并子文件流后将得到的资源文件流输入至执行器中以实现加载的技术手段，在加载资源的过程中不会产生新的资源文件，并且由于流式操作耗时通常在毫秒级别，因此可以有效避免读写磁盘中资源文件的耗时，所以解决了现有技术占用存储空间并且加载速度慢的问题，实现了减少资源文件的磁盘占用，并提高资源文件的加载速度的技术效果。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是根据本发明实施例的加载资源文件的方法的主要步骤的示意图；

图2是根据本发明实施例的加载资源文件的方法应用于JN框架时的架构示意图；

图3是根据本发明实施例的加载资源文件的装置的主要模块的示意图；

图4是本发明实施例可以应用于其中的示例性系统架构图；

图5是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1是根据本发明实施例的加载资源文件的方法的主要步骤的示意图。

如图1所示，本发明实施例提供一种加载资源文件的方法，资源文件被预先拆分为至少两个子文件；所述方法包括：

S10，将所述子文件读取为子文件流。将文件读取为文件流采用的操作是流式读取，流式读取无需将文件读取至客户端的外部存储器中，而是以顺序排列的字节或者字符的形式将文件内容读取至内存的缓冲区内。

以C++为例，基于头文件fstream.h提供了三种流式操作，分别为ifstream—从已有的文件读数据，ofstream—向文件写数据，以及fstream—打开文件以供读写。当基于C++应用本发明所提供的加载资源文件的方法时，采用ifstream的方式将子文件读取为子文件流并存储至内存中。

S11，合并所述子文件流以得到资源文件流。合并操作发生在客户端的内存中，即直接对内存中存储的子文件流进行合并。合并的具体方式应当根据资源文件被拆分的形式确定，使合并得到的资源文件流等同于直接以流式读取的操作读取资源文件时得到的文件流。例如当资源文件所包含的数据为字符串类型时，可以按照子文件的顺序将各子文件流以加法操作的形式进行连接。

S12，将所述资源文件流传递至执行器以完成资源文件的加载。执行器是对需要使用资源文件实现某项任务的模块的统称，例如执行器可以是用于执行图像渲染工作的模块，也可以是用于处理并发任务的模块，且该用于处理并发任务的模块会调用其他功能模块来加载资源文件。执行器在接收到资源文件流后，根据默认的处理规则将资源文件流还原为可识别的资源数据(例如还原为字符串型的资源代码)，从而完成了对资源文件的加载。

从上面所述可以看出，本实施例提供的加载资源文件的方法，因为采用了将由资源文件拆分得到的子文件读取为子文件流，在合并子文件流后将得到的资源文件流输入至执行器中以实现加载的技术手段，在加载资源的过程中不会产生新的资源文件，并且由于流式操作耗时通常在毫秒级别，因此可以有效避免读写磁盘中资源文件的耗时，所以解决了现有技术占用存储空间并且加载速度慢的问题，实现了减少资源文件的磁盘占用，并提高资源文件的加载速度的技术效果。

在一些可选的实施例中，S10，将所述子文件读取为子文件流的步骤包括：

在业务被启动时，获取由与所述业务对应的资源文件拆分得到的子文件的存储路径；以文件流的方式将所述存储路径对应的所述子文件读取至内存中。

流式操作需要明确被操作文件的存储路径，本实施例进一步说明了在读取文件流前需要获取子文件的存储路径。

在一些可选的实施例中，所述子文件包括至少一个通用文件和至少一个业务文件；所述通用文件包括各业务所对应的资源文件的公共数据，所述业务文件包括各业务所对应的资源文件的业务数据。

资源文件的功能是为具体业务的实现提供资源，不同的业务在实现时通常需要一些独特的业务数据，但同时，各业务也需要一部分相同的公共数据作为支持。特别在实际场景中，公共数据的大小甚至会大于业务数据的大小。

本实施例通过将资源文件拆分为通用文件和业务文件，对于不同的业务所对应的资源文件而言，通用文件相同而业务文件不同；因此在应用程序的安装包中可以只保留一份资源文件，并保存各业务对应的业务文件，从而去除了原各资源文件中重复的公共部分，有效降低了应用程序安装包的数据量。

在一些可选的实施例中，所述方法还包括：

在S10，将所述子文件读取为子文件流的步骤后，

将读取所述通用文件得到的通用文件流存储在内存中。确定再次读取所述通用文件时，调用存储在内存中的所述通用文件流。

文件流被读取至内存中后，是以变量形式被识别的；本步骤中的“存储”是指，将通用文件流的变量实例保留在内存中而不将其释放，这样再次读取资源文件时，可以直接调用通用文件流而不需要再次读取通用文件，可以节约一定的时间。

在一些可选的实施例中，S12，将所述资源文件流传递至执行器以完成资源文件的加载的步骤包括：

将所述资源文件流传递至所述执行器后，使用所述执行器根据所述资源文件流形成可执行的资源代码。在前面实施例中提到，执行器在接收到资源文件流后，会根据默认的处理规则将资源文件流还原为可识别的资源数据；在通常情况下，所述资源数据是指用于实现特定功能的代码，这些代码以字符串的形式进行存储。因此在一些优选的实施方式中，所述文件流可以为字符流。

下面通过一个具体的实施例说明上述实施例中的加载资源文件的方法的实际应用。

本实施例适用于基于React Native框架开发的应用程序，在本实施例中的资源文件指该类应用程序中的Bundle文件。

React Native(简称RN)是Facebook于2015年4月开源的跨平台移动应用开发框架，是Facebook早先开源的UI框架React在原生移动应用平台的衍生产物，目前支持iOS和安卓两大平台。RN使用Javascript语言，类似于HTML的JSX，以及CSS来开发移动应用，因此熟悉Web前端开发的技术人员只需很少的学习就可以使用RN框架进行移动应用开发。

基于RN开发的应用程序，会将所用到的JavaScript代码打包成Bundle文件，作为资源包存放在客户端。通常对于每一个业务模块，会建立一个Bundle文件，这样可以方便地对单个业务模块进行升级，但也造成了Bundle数量多、容量大的问题。

通过分析Bundle文件包的内容，在某项业务所对应的Bundle文件中包含有公共部分和专用于该项业务的业务部分，各Bundle文件的公共部分相同。因此将Bundle文件预先拆分为包含公共部分的通用文件和包含业务部分的业务文件，在调用某项业务前再执行合并，可以有效地降低应用程序占用的磁盘空间。

本实施例在实施时，根据前述原理，首先将Bundle文件拆分为通用文件和业务文件，在应用程序的安装包中保留有1个通用文件和对应于各具体业务模块的业务文件。

React Native目前仅支持根据路径读取完整的Bundle文件，所以需要设置额外的功能代码来完成分别读取通用文件和业务文件，以及对二者的合并。

在RN的sdk(Software Development Kit，软件开发工具包)中，包含了大量的Java代码和C++代码，可划分为Java层和C++层。sdk的上层暴露的数据接口基于Java实现，并通过JNI(Java Native Interface，Java本地接口)的方式与C++层进行交互。

图2是根据本发明实施例的加载资源文件的方法应用于JN框架时的架构示意图。

如图2所示，本实施例对程序代码所做的改进，是在Java/JNI层中增加路径接口200和加载器201。当需要执行某项业务时，调用路径接口200将通用文件的路径和该业务所对应的业务文件的路径传递给所述加载器201(通用文件和业务文件的路径是预先存储在已知位置的)，由加载器将通用文件和业务文件分别读取为文件流并进行合并以得到资源文件流，然后将资源文件流传递给C++层的执行器202，从而完成对资源文件的加载。执行器202在获取到资源文件流后，还会对资源文件流的内容进行检验，若检验无误，则至此资源文件已注入应用程序。路径接口200和加载器201可以通过编写代码实现，执行器202优选为基于RN框架开发的应用程序中，C++层内的“JSCExecutor.cpp”模块。

优选的，加载器201以ifstream的流读取方式分别读取通用文件和业务文件，分别形成两个字符串式的文件流，而并不读取两个文件的内容。然后以通用文件对应的字符串在前、业务文件对应的字符串在后的形式，对两个文件流进行拼接，以得到字符串式的资源文件流。执行器202在获取到资源文件流后，会读取流以形成一份可以执行的资源代码。

加载器201在读取完毕通用文件后，可以选择不释放用于保存通用文件流的变量，以便将通用文件流保留在内存中，这样需要再次读取通用文件时，可以直接调用该变量，以节约加载时间。

从上面所述可以看出，本实施例通过将由资源文件拆分得到的通用文件和业务文件以文件流的形式进行读取、合并，然后传递给执行器而完成对资源文件的加载，不会产生新的磁盘文件，可以节省客户端的存储空间，还可以免去读写磁盘消耗的时间；并且由于文件流的读取较为快捷，耗时通常在毫秒级，因此可以显著提高加载资源文件的速度，提升应用程序运行的流畅程度。

图3是根据本发明实施例的加载资源文件的装置的主要模块的示意图。

如图所示，根据本发明实施例提供的加载资源文件的装置300，资源文件被预先拆分为至少两个子文件；所述装置300包括：

流读取模块301，用于将所述子文件读取为子文件流；

流合并模块302，用于合并所述子文件流以得到资源文件流；

流传递模块303，用于将所述资源文件流传递至执行器以完成资源文件的加载。

在一些可选的实施例中，所述流读取模块301还用于：

在业务被启动时，获取由与所述业务对应的资源文件拆分得到的子文件的存储路径；

以文件流的方式将所述存储路径对应的所述子文件读取至内存中。

在一些可选的实施例中，所述子文件包括至少一个通用文件和至少一个业务文件；所述通用文件包括各业务所对应的资源文件的公共数据，所述业务文件包括各业务所对应的资源文件的业务数据。

在一些可选的实施例中，所述流读取模块301还用于：

将读取所述通用文件得到的通用文件流存储在内存中；

确定再次读取所述通用文件时，调用存储在内存中的所述通用文件流。

在一些可选的实施例中，所述流传递模块303还用于：

将所述资源文件流传递至所述执行器后，使用所述执行器根据所述资源文件流形成可执行的资源代码。

在一些可选的实施例中，所述资源文件为基于React Native框架开发的应用程序中的Bundle文件。

从上面所述可以看出，本实施例提供的加载资源文件的装置，因为采用了将由资源文件拆分得到的子文件读取为子文件流，在合并子文件流后将得到的资源文件流输入至执行器中以实现加载的技术手段，在加载资源的过程中不会产生新的资源文件，并且由于流式操作耗时通常在毫秒级别，因此可以有效避免读写磁盘中资源文件的耗时，所以解决了现有技术占用存储空间并且加载速度慢的问题，实现了减少资源文件的磁盘占用，并提高资源文件的加载速度的技术效果。

图4示出了可以应用本发明实施例的加载资源文件的方法或加载资源文件的装置的示例性系统架构400。

如图4所示，系统架构400可以包括终端设备401、402、403，网络404和服务器405。网络404用以在终端设备401、402、403和服务器405之间提供通信链路的介质。网络404可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备401、402、403通过网络404与服务器405交互，以接收或发送消息等。终端设备401、402、403上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备401、402、403可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器405可以是提供各种服务的服务器，例如对用户利用终端设备401、402、403所浏览的购物类网站提供支持的后台管理服务器。

需要说明的是，本发明实施例所提供的加载资源文件的方法一般由终端设备401、402、403执行，相应地，加载资源文件的装置一般设置于终端设备401、402、403中。

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

根据本发明的实施例，本发明还提供了一种电子设备和一种可读存储介质。

图5是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。

下面参考图5，其示出了适于用来实现本发明实施例的终端设备的计算机系统500的结构示意图。图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：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(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 (12)

1.一种加载资源文件的方法，其特征在于，所述资源文件被预先拆分为至少一个通用文件和至少一个业务文件；所述通用文件包括前端应用程序各业务所对应的资源文件的公共数据，所述业务文件包括前端应用程序各业务所对应的资源文件的业务数据；所述方法包括：

将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流；

合并所述通用文件流和业务文件流以得到资源文件流；

将所述资源文件流传递至所述前端应用程序的执行器以完成资源文件的加载。

2.根据权利要求1所述的方法，其特征在于，将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流的步骤包括：

在前端应用程序的业务被启动时，获取由与所述业务对应的资源文件拆分得到的通用文件和业务文件的存储路径；

以文件流的方式将所述存储路径对应的所述通用文件和业务文件读取至内存中。

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

在将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流的步骤后，

将所述通用文件流存储在内存中；

确定需要再次读取所述通用文件时，调用存储在内存中的所述通用文件流。

4.根据权利要求1所述的方法，其特征在于，将所述资源文件流传递至前端应用程序的执行器以完成资源文件的加载的步骤包括：

将所述资源文件流传递至前端应用程序的执行器后，使用所述执行器根据所述资源文件流形成可执行的资源代码。

5.根据权利要求1所述的方法，其特征在于，所述前端应用程序为基于React Native框架开发的应用程序，所述资源文件为所述应用程序中的Bundle文件。

6.一种加载资源文件的装置，其特征在于，所述资源文件被预先拆分为至少一个通用文件和至少一个业务文件；所述通用文件包括前端应用程序各业务所对应的资源文件的公共数据，所述业务文件包括前端应用程序各业务所对应的资源文件的业务数据；所述装置包括：

流读取模块，用于将所述通用文件读取为通用文件流，将所述业务文件读取为业务文件流；

流合并模块，用于合并所述通用文件流和业务文件流以得到资源文件流；

流传递模块，用于将所述资源文件流传递至所述前端应用程序的执行器以完成资源文件的加载。

7.根据权利要求6所述的装置，其特征在于，所述流读取模块还用于：

在前端应用程序的业务被启动时，获取由与所述业务对应的资源文件拆分得到的通用文件和业务文件的存储路径；

以文件流的方式将所述存储路径对应的所述通用文件和业务文件读取至内存中。

8.根据权利要求6所述的装置，其特征在于，所述流读取模块还用于：

将所述通用文件流存储在内存中；

确定需要再次读取所述通用文件时，调用存储在内存中的所述通用文件流。

9.根据权利要求6所述的装置，其特征在于，所述流传递模块还用于：

将所述资源文件流传递至前端应用程序的执行器后，使用所述执行器根据所述资源文件流形成可执行的资源代码。

10.根据权利要求6所述的装置，其特征在于，所述前端应用程序为基于React Native框架开发的应用程序，所述资源文件为所述应用程序中的Bundle文件。

11.一种加载资源文件的电子设备，其特征在于，包括：

一个或多个处理器；

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

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-5中任一所述的方法。

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