资源加载方法、装置、电子设备和计算机可读存储介质

技术领域

本发明涉及互联网技术领域，具体而言，涉及一种资源加载方法、装置、电子设备和计算机可读存储介质。

背景技术

H5(html5)是一种超文本标记语言，具有跨平台、开发容易、效率高、方便调试等优点。随着移动互联网的发展，各类应用程序中都有大量H5页面，应用程序在加载H5页面的时候，容易受移动网络质量的影响，如果移动网络质量较差，则会导致加载时间较长或者加载失败。

移动网络的不稳定、流量敏感、接入变化频繁等特性催生了现代离线包技术，现代离线包技术通过资源离线化的方案，尽可能地减少网络环境对于H5页面加载速度的影响，从而保证移动终端H5产品的良好用户体验。然而，移动端的越狱、ROOT等技术破坏了设备沙盒的封闭性，离线化的资源可以被自由修改，这就导致终端用户真实访问的H5页面可能不再是开发者提供的H5页面，为了避免此类问题的发生，离线包的篡改检测应运而生。

现有技术中，关于移动终端离线包安全加载的方案多为整包验签方案，整包验签方案会在首次加载离线包时对整个离线包进行签名校验，签名校验通过后再将整个离线包的数据解压到运行内存中，由于验签和解压的对象是整个离线包，当离线包体积较大时会面临加载速度慢、内存占用高等问题。

发明内容

有鉴于此，本发明的目的在于提供一种资源加载方法、装置、电子设备和计算机可读存储介质，以解决现有技术中基于整包验签并加载到内存中的安全加载方案存在的资源加载速度慢、内存占用高的问题。

为了实现上述目的，本发明实施例采用的技术方案如下：

第一方面，本发明提供一种资源加载方法，所述方法包括：

获取应用程序发送的资源加载请求；所述资源加载请求携带目标压缩包标识和目标相对路径；所述目标压缩包标识为待加载的目标资源文件对应的本地压缩包的标识，所述目标相对路径为所述目标资源文件对应的目标压缩数据在所述本地压缩包内的相对路径；

根据所述目标压缩包标识获取所述目标资源文件对应的本地压缩包；

对所述本地压缩包进行签名验证；

在签名验证无误后，根据所述目标相对路径从所述本地压缩包中解压出所述目标资源文件；

将所述目标资源文件返回给所述应用程序，以便所述应用程序加载所述目标资源文件。

在可选的实施方式中，所述根据所述目标压缩包标识获取所述目标资源文件对应的本地压缩包，包括：

根据所述目标压缩包标识和预设的压缩包本地路径，确定所述目标资源文件对应的本地压缩包的本地存储路径；

根据所述本地存储路径，获得所述本地压缩包。

在可选的实施方式中，所述根据所述目标相对路径从所述本地压缩包中解压出所述目标资源文件，包括：

根据所述本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系，确定所述目标相对路径对应的本地文件头偏移；

根据所述目标相对路径对应的本地文件头偏移，从所述本地压缩包中获取所述目标资源文件对应的目标压缩数据；

对所述目标压缩数据进行解压，得到所述目标资源文件。

在可选的实施方式中，所述根据所述目标相对路径对应的本地文件头偏移，从所述本地压缩包中获取所述目标资源文件对应的目标压缩数据，包括：

根据所述目标相对路径对应的本地文件头偏移，从所述本地压缩包中获取所述目标资源文件对应的目标压缩数据的本地文件头；所述目标压缩数据的本地文件头中记录有压缩数据大小；

根据所述目标压缩数据的本地文件头和所述压缩数据大小，获取所述目标资源文件对应的目标压缩数据。

在可选的实施方式中，在根据所述本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系，确定所述目标相对路径对应的本地文件头偏移之前，所述方法还包括：

遍历所述本地压缩包的中央目录中的所有文件头；其中，所述本地压缩包中的每个资源文件对应一个文件头，所述文件头中记录有所述资源文件对应的相对路径和本地文件头偏移；

根据各文件头中记录的相对路径和本地文件头偏移，得到所述本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系。

在可选的实施方式中，所述获取应用程序发送的资源加载请求，包括：

在应用程序发送的资源加载请求符合预设拦截条件时，拦截所述资源加载请求。

第二方面，本发明提供一种资源加载装置，所述装置包括：

请求获取模块，用于获取应用程序发送的资源加载请求；所述资源加载请求携带目标压缩包标识和目标相对路径；所述目标压缩包标识为待加载的目标资源文件对应的本地压缩包的标识，所述目标相对路径为所述目标资源文件对应的目标压缩数据在所述本地压缩包内的相对路径；

压缩包获取模块，用于根据所述目标压缩包标识获取所述目标资源文件对应的本地压缩包；

验签模块，用于对所述本地压缩包进行签名验证；

解压模块，用于在签名验证无误后，根据所述目标相对路径从所述本地压缩包中解压出所述目标资源文件；

数据返回模块，用于将所述目标资源文件返回给所述应用程序，以便所述应用程序加载所述目标资源文件。

在可选的实施方式中，所述解压模块用于根据所述本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系，确定所述目标相对路径对应的本地文件头偏移；根据所述目标相对路径对应的本地文件头偏移，从所述本地压缩包中获取所述目标资源文件对应的目标压缩数据；对所述目标压缩数据进行解压，得到所述目标资源文件。

第三方面，本发明提供一种电子设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如前述实施方式中任一项所述的资源加载方法的步骤。

第四方面，本发明提供一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如前述实施方式中任一项所述的资源加载方法的步骤。

本发明实施例提供的资源加载方法、装置、电子设备和计算机可读存储介质，该方法通过获取应用程序发送的资源加载请求，由于资源加载请求携带目标压缩包标识和目标相对路径，且目标压缩包标识为待加载的目标资源文件对应的本地压缩包的标识，目标相对路径为目标资源文件对应的目标压缩数据在本地压缩包内的相对路径，故根据目标压缩包标识可以获取到目标资源文件对应的本地压缩包，并对本地压缩包进行签名验证，在签名验证无误后，根据目标相对路径可以从本地压缩包中解压出目标资源文件，并将目标资源文件返回给应用程序，以便应用程序加载目标资源文件。可见，本发明实施例基于获取的资源加载请求中携带的目标压缩包标识和目标相对路径，仅需将需要加载的资源文件从本地压缩包中解压，暂时用不到的资源文件并不会被解压，只有应用程序加载到哪个资源文件才会解压哪个资源文件，不需要一次性将整个压缩包解压，并且解压得到的资源文件是经过压缩包签名校验的数据，故能实现资源文件的按需安全加载，内存占用会更低，资源加载速度也会更快。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本发明实施例提供的资源加载方法的一种流程示意图；

图2示出了本发明实施例提供的资源加载方法的另一种流程示意图；

图3示出了本发明实施例提供的资源加载方法的又一种流程示意图；

图4示出了PKZip文件的一种结构示意图；

图5示出了中央目录的一种结构示意图；

图6示出了文件头的一种结构示意图；

图7示出了本地文件头的一种结构示意图；

图8示出了本发明实施例提供的资源加载装置的一种功能模块图；

图9示出了本发明实施例提供的电子设备的一种方框示意图。

图标：700-电子设备；800-资源加载装置；710-存储器；720-处理器；730-通信模块；810-请求获取模块；820-压缩包获取模块；830-验签模块；840-解压模块；850-数据返回模块。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

现有的离线包安全加载方案多为整包内存加载，即是需要一次性将整个离线包解压到内存中，解压的对象是整个离线包，因此当离线包体积较大时会面临加载速度慢、内存占用高等问题。

基于此，本发明实施例提出了一种资源加载方法、装置、电子设备和计算机可读存储介质，其基于获取的资源加载请求中携带的目标压缩包标识和目标相对路径，仅需将需要加载的资源文件从本地压缩包中解压，暂时用不到的资源文件并不会被解压，只有应用程序加载到哪个资源文件才会解压哪个资源文件，不需要一次性将整个压缩包解压，并且解压得到的资源文件是经过压缩包签名校验的数据，故能实现资源文件的按需安全加载，内存占用会更低，资源加载速度也会更快。

下面将结合附图对本发明的各实施例进行详细说明。

请参照图1，为本发明实施例提供的资源加载方法的一种流程示意图。需要说明的是，本发明实施例的资源加载方法并不以图1以及以下的具体顺序为限制，应当理解，在其他实施例中，本发明实施例的资源加载方法其中部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。该资源加载方法可以应用在智能手机、平板电脑、个人数字助理(personal digital assistant，PDA)等电子设备中，下面将对图1所示的具体流程进行详细阐述。

步骤S101，获取应用程序发送的资源加载请求；资源加载请求携带目标压缩包标识和目标相对路径；目标压缩包标识为待加载的目标资源文件对应的本地压缩包的标识，目标相对路径为目标资源文件对应的目标压缩数据在本地压缩包内的相对路径。

在本实施例中，当用户需要访问某一H5页面时，可以通过所持有的电子设备中安装的App(Application，应用程序)发起资源加载请求，电子设备在获取到资源加载请求后，启动对该资源加载请求的处理流程。其中，App可以是浏览器，还可以是其他类型的应用程序，本发明实施例对此不做限制。

在本实施例中，一个应用程序可以对应不同业务类型的压缩包，每个压缩包都有对应的业务ID(即压缩包标识)，应用程序启动时，通过与服务端交互，可以从服务端下载不同压缩包标识对应的压缩包，并根据压缩包标识将对应的压缩包保存到本地。

在本实施例中，当完成资源文件的压缩后，压缩包中会记录每个资源文件对应的压缩数据在压缩包内的相对路径，通过相对路径可以快速找到每个资源文件对应的压缩数据在整个压缩包内的位置。

步骤S102，根据目标压缩包标识获取目标资源文件对应的本地压缩包。

在本实施例中，由于电子设备从服务端获取压缩包后，是根据压缩包标识对压缩包进行本地存储，故根据资源加载请求携带的目标压缩包标识，可以查找到该目标压缩包标识所对应的本地压缩包。

步骤S103，对本地压缩包进行签名验证。

在本实施例中，应用程序启动时不仅会从服务端获得不同压缩包标识对应的压缩包，还会获得服务器提供的每个压缩包对应的版本号、签名等信息，并保存在本地。电子设备在获取目标资源文件对应的本地压缩包后，可采用非对称加密算法对本地压缩包进行签名验证，验证无误表明本地压缩包在本地没有被恶意篡改，方可进行后续操作步骤。

步骤S104，在签名验证无误后，根据目标相对路径从本地压缩包中解压出目标资源文件。

在本实施例中，由于根据每个资源文件对应的压缩数据在压缩包内的相对路径，可以快速找到每个资源文件对应的压缩数据在整个压缩包内的位置，相应地，根据资源加载请求携带的目标相对路径也可找到该目标资源文件对应的目标压缩数据在整个本地压缩包内的位置，进而通过获取目标压缩数据并解压，就可以得到目标资源文件。其中，目标资源文件可以解压至内存，无需写入本地磁盘。

步骤S105，将目标资源文件返回给应用程序，以便应用程序加载目标资源文件。

在本实施例中，电子设备根据目标相对路径从本地压缩包中解压出的目标资源文件，可以是单文件解压数据，电子设备将解压至内存中的单文件数据(目标资源文件)返回给应用程序，由应用程序对目标资源文件进行加载，实现了单文件解压和加载，大大降低了内存占用，提升了资源加载速度。并且，本实施例从本地压缩包中解压到内存的单文件数据，是经过压缩包签名校验的数据，可以确认数据是安全未被恶意篡改的，因此可以将数据返回给应用程序进行加载，确保了资源的安全加载。

可见，本发明实施例提供的资源加载方法，通过获取应用程序发送的资源加载请求，由于资源加载请求携带目标压缩包标识和目标相对路径，且目标压缩包标识为待加载的目标资源文件对应的本地压缩包的标识，目标相对路径为目标资源文件对应的目标压缩数据在本地压缩包内的相对路径，故根据目标压缩包标识可以获取到目标资源文件对应的本地压缩包，并对本地压缩包进行签名验证，在签名验证无误后，根据目标相对路径可以从本地压缩包中解压出目标资源文件，并将目标资源文件返回给应用程序，以便应用程序加载目标资源文件。可见，本发明实施例基于获取的资源加载请求中携带的目标压缩包标识和目标相对路径，仅需将需要加载的资源文件从本地压缩包中解压，暂时用不到的资源文件并不会被解压，只有应用程序加载到哪个资源文件才会解压哪个资源文件，不需要一次性将整个压缩包解压，并且解压得到的资源文件是经过压缩包签名校验的数据，故能实现资源文件的按需安全加载，内存占用会更低，资源加载速度也会更快。

在实际应用中，可以采用拦截的方式获取资源加载请求，考虑到可能不是所有的资源加载请求都需要被拦截，比如有些资源加载请求不是请求离线资源，则不需要拦截，在此情形下，可以预先设置拦截条件，实现对资源加载请求的准确拦截。基于此，上述步骤S101可以包括：在应用程序发送的资源加载请求符合预设拦截条件时，拦截资源加载请求。

在本实施例中，可以为应用程序添加一个自定义拦截代理(例如，Android：WebViewClient，iOS：WKURLSchemeHandler)，并在自定义拦截代理中设置拦截条件，通过该自定义拦截代理拦截符合预设拦截条件的资源加载请求，明确应用程序的具体加载需求，便于进行后续操作步骤。

其中，该预设拦截条件可以根据实际情况设置，例如，可以设置为资源加载请求的协议类型是预设的离线包协议，确保是对离线资源的加载请求进行拦截即可。

在一个具体的示例中，假设某个资源加载请求的请求地址为“gmu://a.vhost.com/index.html”，自定义拦截代理根据协议头判定其协议类型是预设的离线包协议，该资源加载请求符合预设拦截条件，对该资源加载请求进行拦截。

可选地，请参照图2，上述步骤S102可以包括如下子步骤：

子步骤S1021，根据目标压缩包标识和预设的压缩包本地路径，确定目标资源文件对应的本地压缩包的本地存储路径。

在本实施例中，电子设备会预先为每个应用程序设置一个专门存储离线包数据的目录，即压缩包本地路径，例如/App/Demo/离线包。应用程序在从服务端获取到压缩包后，会根据压缩包的压缩包标识保存到相应的目录下。例如，压缩包标识为“a”，则该压缩包会被保存在/App/Demo/离线包/a这个目录下；压缩包标识为“b”，则该压缩包会被保存在/App/Demo/离线包/b这个目录下。

当电子设备通过自定义拦截代理拦截到资源加载请求并提取出资源加载请求携带的目标压缩包标识后，将该目标压缩包标识与预设的压缩包本地路径/App/Demo/离线包进行拼接，就可得到确定目标资源文件对应的本地压缩包的本地存储路径。例如，目标压缩包标识为“a”，则确定目标资源文件对应的本地压缩包的本地存储路径为/App/Demo/离线包/a。

需要说明的是，在实际应用中，由于压缩包可能存在不同的版本，应用程序可根据压缩包的压缩包标识和版本号将压缩包保存在相应目录下，例如压缩包标识为“a”，版本号为“1.0”，则该压缩包会被保存在/App/Demo/离线包/a/1.0这个目录。相应地，电子设备在确定目标资源文件对应的本地压缩包的本地存储路径时，可以先根据目标压缩包标识确定对应的版本号，然后将目标压缩包标识、版本号与预设的压缩包本地路径/App/Demo/离线包进行拼接，得到本地存储路径为/App/Demo/离线包/a/1.0。

子步骤S1022，根据本地存储路径，获得本地压缩包。

在本实施例中，当获得目标资源文件对应的本地压缩包的本地存储路径后，基于该本地存储路径可查询到存储的本地压缩包。例如，本地存储路径为/App/Demo/离线包/a，则在/App/Demo/离线包/a这个目录下就可读取到目标资源文件对应的本地压缩包。

可选地，请参照图3，上述步骤S104可以包括如下子步骤：

子步骤S1041，在签名验证无误后，根据本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系，确定目标相对路径对应的本地文件头偏移。

在本实施例中，本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系可以通过如下步骤获得：遍历本地压缩包的中央目录中的所有文件头；其中，本地压缩包中的每个资源文件对应一个文件头，文件头中记录有资源文件对应的相对路径和本地文件头偏移；根据各文件头中记录的相对路径和本地文件头偏移，得到本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系。

以图4所示的PKZip文件的结构为例，通过中央目录(Central Directory)数据段的标志位可以定位到“Central Directory”的数据内容(如图5所示)，在图5所示的“Central Directory”数据内容中，遍历所有的文件头(File Header 1、File Header2、...、File Header n)的内容，其中每个文件头的内容如图6所示，“File name”中记录资源文件对应的相对路径信息，“Offset of local header”记录资源文件对应的本地文件头偏移，通过读取每个文件头中“File name”和“Offset of local header”的内容，可以得到本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系。

应理解的是，在实际应用中，只需在对本地压缩包首次解压时遍历中央目录中的所有文件头，来获得本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系；后续再对本地压缩包中的某个目标资源文件进行加载，直接根据该目标资源文件对应的目标相对路径查找之前遍历得到的对应关系，就可快速定位到该目标资源文件对应的目标压缩数据在整个本地压缩包中的偏移位置(即本地文件头偏移)。

子步骤S1042，根据目标相对路径对应的本地文件头偏移，从本地压缩包中获取目标资源文件对应的目标压缩数据。

可选地，电子设备可以根据目标相对路径对应的本地文件头偏移，从本地压缩包中获取目标资源文件对应的目标压缩数据的本地文件头；目标压缩数据的本地文件头中记录有压缩数据大小；根据目标压缩数据的本地文件头和压缩数据大小，获取目标资源文件对应的目标压缩数据。

在本实施例中，电子设备得到本地文件头偏移后，可以定位到本地文件头“Localfile headers”的数据内容(如图7所示)，并根据本地文件头以及本地文件头中“Compressed size”记录的压缩数据大小，计算出目标资源文件对应的目标压缩数据的范围，进而读取出目标资源文件对应的目标压缩数据。

子步骤S1043，对目标压缩数据进行解压，得到目标资源文件。

在本实施例中，电子设备可以通过操作系统提供的数据解压API(ApplicationProgramming Interface，应用程序编程接口)对目标压缩数据进行解压，得到目标资源文件。

为了执行上述实施例及各个可能的方式中的相应步骤，下面给出一种资源加载装置的实现方式。请参阅图8，为本发明实施例提供的资源加载装置800的一种功能模块图。需要说明的是，本实施例所提供的资源加载装置800，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。该资源加载装置800包括请求获取模块810、压缩包获取模块820、验签模块830、解压模块840和数据返回模块850。

请求获取模块810，用于获取应用程序发送的资源加载请求；资源加载请求携带目标压缩包标识和目标相对路径；目标压缩包标识为待加载的目标资源文件对应的本地压缩包的标识，目标相对路径为目标资源文件对应的目标压缩数据在本地压缩包内的相对路径。

可以理解，该请求获取模块810可以执行上述步骤S101。

压缩包获取模块820，用于根据目标压缩包标识获取目标资源文件对应的本地压缩包。

可以理解，该压缩包获取模块820可以执行上述步骤S102。

验签模块830，用于对本地压缩包进行签名验证。

可以理解，该验签模块830可以执行上述步骤S103。

解压模块840，用于在签名验证无误后，根据目标相对路径从本地压缩包中解压出目标资源文件。

可以理解，该解压模块840可以执行上述步骤S104。

数据返回模块850，用于将目标资源文件返回给应用程序，以便应用程序加载目标资源文件。

可以理解，该数据返回模块850可以执行上述步骤S105。

可选地，该请求获取模块810具体用于在应用程序发送的资源加载请求符合预设拦截条件时，拦截资源加载请求。

可选地，该压缩包获取模块820具体用于根据目标压缩包标识和预设的压缩包本地路径，确定目标资源文件对应的本地压缩包的本地存储路径；根据本地存储路径，获得本地压缩包。

可以理解，该压缩包获取模块820具体可以执行上述子步骤S1021、子步骤S1022。

可选地，该解压模块840可以用于根据本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系，确定目标相对路径对应的本地文件头偏移；根据目标相对路径对应的本地文件头偏移，从本地压缩包中获取目标资源文件对应的目标压缩数据；对目标压缩数据进行解压，得到目标资源文件。

可以理解，该解压模块840可以执行上述子步骤S1041～S1043。

可选地，该解压模块840具体用于根据目标相对路径对应的本地文件头偏移，从本地压缩包中获取目标资源文件对应的目标压缩数据的本地文件头；目标压缩数据的本地文件头中记录有压缩数据大小；根据目标压缩数据的本地文件头和压缩数据大小，获取目标资源文件对应的目标压缩数据。

可选地，该解压模块840还用于在根据本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系，确定目标相对路径对应的本地文件头偏移之前，遍历本地压缩包的中央目录中的所有文件头；其中，本地压缩包中的每个资源文件对应一个文件头，文件头中记录有资源文件对应的相对路径和本地文件头偏移；根据各文件头中记录的相对路径和本地文件头偏移，得到本地压缩包中各资源文件对应的相对路径与本地文件头偏移的对应关系。

可见，本发明实施例提供的资源加载装置，通过请求获取模块获取应用程序发送的资源加载请求；资源加载请求携带目标压缩包标识和目标相对路径；目标压缩包标识为待加载的目标资源文件对应的本地压缩包的标识，目标相对路径为目标资源文件对应的目标压缩数据在本地压缩包内的相对路径；压缩包获取模块根据目标压缩包标识获取目标资源文件对应的本地压缩包；验签模块对本地压缩包进行签名验证；解压模块在签名验证无误后，根据目标相对路径从本地压缩包中解压出目标资源文件；数据返回模块将目标资源文件返回给应用程序，以便应用程序加载目标资源文件。该装置基于获取的资源加载请求中携带的目标压缩包标识和目标相对路径，仅需将需要加载的资源文件从本地压缩包中解压，暂时用不到的资源文件并不会被解压，只有应用程序加载到哪个资源文件才会解压哪个资源文件，不需要一次性将整个压缩包解压，并且解压得到的资源文件是经过压缩包签名校验的数据，故能实现资源文件的按需安全加载，内存占用会更低，资源加载速度也会更快。

请参照图9，为本发明实施例提供的电子设备700的一种方框示意图。该电子设备700包括存储器710、处理器720及通信模块730。存储器710、处理器720以及通信模块730各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。

其中，存储器710用于存储程序或者数据。存储器710可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-Only Memory，PROM)，可擦除只读存储器(ErasableProgrammable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric ErasableProgrammable Read-Only Memory，EEPROM)等。

处理器720用于读/写存储器710中存储的数据或程序，并执行相应地功能。例如，当存储器710中存储的计算机程序被处理器720执行时，可以实现上述各实施例所揭示的资源加载方法。

通信模块730用于通过网络建立电子设备700与其它通信终端之间的通信连接，并用于通过网络收发数据。

应当理解的是，图9所示的结构仅为电子设备700的结构示意图，电子设备700还可包括比图9中所示更多或者更少的组件，或者具有与图9所示不同的配置。图9中所示的各组件可以采用硬件、软件或其组合实现。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器720执行时实现上述各实施例所揭示的资源加载方法。

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

另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。