CN113286006B - 文件加载方法、装置 - Google Patents

Abstract

本申请公开了一种文件加载方法、装置，属于数据处理领域。文件加载方法包括：接收第一应用向操作系统中的网络服务组件发送的文件加载请求；其中，网络服务组件用于向操作系统中的所有应用提供网络服务；响应于文件加载请求，通过网络服务组件下载第一应用请求加载的第一文件；压缩第一文件，得到第二文件；将第二文件发送至第一应用，以使第一应用加载第二文件。

Description

文件加载方法、装置

技术领域

本申请属于数据处理领域，具体涉及一种文件加载方法、装置。

背景技术

在应用的正常运行过程中，需要将所需的各类文件加载到内存中，然后读取这些文件，进行显示、播放等操作。如果文件过大，加载速度过慢，会影响应用的正常运行。因此，相关技术中的应用可能会使用文件压缩工具对文件进行压缩。但是，由于应用在获取到文件之后可能会遗漏对某些文件的压缩，或者某些应用并没有设置文件压缩工具，使得应用加载的文件过大，甚至导致内存溢出、应用异常。

发明内容

本申请实施例的目的是提供一种文件加载方法、装置，能够解决相关技术中应用没有设置文件压缩工具、或者遗漏压缩导致文件加载异常的问题。

第一方面，本申请实施例提供了一种文件加载方法，该方法包括：

接收第一应用向操作系统中的网络服务组件发送的文件加载请求；其中，网络服务组件用于向操作系统中的所有应用提供网络服务；

响应于文件加载请求，通过网络服务组件下载第一应用请求加载的第一文件；

压缩第一文件，得到第二文件；

将第二文件发送至第一应用，以使第一应用加载第二文件。

第二方面，本申请实施例提供了一种文件加载装置，该装置包括：

第一接收单元，用于接收第一应用向操作系统中的网络服务组件发送的文件加载请求；其中，网络服务组件用于向操作系统中的所有应用提供网络服务；

下载单元，用于响应于文件加载请求，通过网络服务组件下载第一应用请求加载的第一文件；

压缩单元，用于压缩第一文件，得到第二文件；

发送单元，用于将第二文件发送至第一应用，以使第一应用加载第二文件。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的文件加载方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的文件加载方法的步骤。

第五方面，本申请实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的文件加载方法。

在本申请实施例中，通过为所有应用提供网络服务的网络服务组件下载文件，并在下载之后压缩文件，进而将压缩之后的文件发送给应用，这样可以统一为所有应用请求加载的网络文件进行压缩，便于统一压缩标准，防止由于应用没有文件压缩工具、或者在使用自己的文件压缩工具时，出现遗漏压缩的情况，进而由于文件过大，导致占用内存较多甚至引起应用崩溃的情况，解决了相关技术中应用没有设置文件压缩工具、或者遗漏压缩导致文件加载异常的问题，并且也解决了文件压缩标准不统一的问题，能够及时有效地压缩通过网络下载的文件，提高了应用加载网络文件的稳定性。

附图说明

图1是本申请实施例提供的一种可选的文件加载方法的流程示意图；

图2是本申请实施例提供的一种可选的文件加载方法的示意图；

图3是本申请实施例提供的另一种可选的文件加载方法的示意图；

图4是本申请实施例提供的另一种可选的文件加载方法的流程示意图；

图5是本申请实施例提供的另一种可选的文件加载方法的流程示意图；

图6是本申请实施例提供的一种可选的文件加载装置的示意框图；

图7是本申请实施例提供的一种可选的电子设备的示意框图；

图8是本申请实施例提供的另一种可选的电子设备的示意框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的文件加载方法进行详细地说明。

本申请实施例提供的文件加载方法可以应用于操作系统中的任意一个应用加载目标类型的文件，由运行操作系统的电子设备来执行。其中，操作系统可以是基于Linux内核/windows内核等的操作系统，举例来说，在移动终端中安装的基于安卓系统的操作系统；文件的目标类型可以是图片、视频、音频等。

如图1所示，本申请实施例提供的文件加载方法包括如下步骤：

步骤101，接收第一应用向操作系统中的网络服务组件发送的文件加载请求。

第一应用是操作系统中已安装的所有应用之一。一个示例中，上述应用可以是在移动终端中安装的应用程序(application，简称APP)。

在操作系统中的任意一个应用需要通过网络加载文件时，可以向网络服务组件发送文件加载请求，其中，网络服务组件用于向操作系统中的所有应用提供网络服务，文件加载请求用于请求网络服务组件通过网络下载文件。可选的，文件加载请求可以包括获取待加载文件的网络连接地址，例如统一资源符URL。接着，在网络服务组件通过网络下载了文件之后，网络服务组件可以将下载的文件提供给发送文件加载请求的应用，使该应用加载文件。

一个示例的应用场景中，用户可以在手机中点开一个软件(第一应用)，例如应用商店、游戏中心、视频类app等，进入软件的首页/其它功能页时，这些页面需要加载图片(文件)，这时，可以将待加载图片的URL地址发送给网络服务组件，请求网络服务组件下载对应的图片。

步骤102，响应于文件加载请求，通过网络服务组件下载第一应用请求加载的第一文件。

在接收到文件加载请求之后，网络服务组件可以响应于文件加载请求，通过网络下载第一应用所请求的第一文件。其中，文件加载请求中可以包括获取第一文件的网络地址。

步骤103，压缩第一文件，得到第二文件。

在下载第一文件之后，并不是直接将第一文件发送至第一应用，而是经过压缩，得到第二文件。

其中，操作系统中可以包括文件压缩组件，这样，步骤103压缩第一文件，得到第二文件可以包括如下步骤：

步骤131，调用文件压缩组件，以请求文件压缩组件压缩第一文件；

步骤132，获取文件压缩组件压缩第一文件后得到的第二文件。

这里，文件压缩组件用于向操作系统中的所有应用提供文件压缩服务。压缩后的文件大小小于压缩前的文件大小。

示例性地，文件压缩组件可以用于对图片进行压缩，可以通过降低图片的分辨率来减小图片大小。

步骤104，将第二文件发送至第一应用，以使第一应用加载第二文件。

在压缩得到第二文件之后，可以将第二文件发送至第一应用。

也即，对于操作系统中的任意一应用，在需要通过网络加载文件时，都需要向网络服务组件发送文件加载请求，而在网络服务组件下载了应用所请求的文件之后，可以对下载的文件进行压缩，将压缩后的文件发送给应用。

这样，请求加载文件的应用所得到的文件是经过了压缩之后的文件，即使应用没有文件压缩工具，或应用的文件压缩工具发生异常，应用所加载的文件也是经过了压缩之后体积较小的文件，从而防止出现加载异常、甚至崩溃的情况。

在文件是图片的情况下，本申请实施例提供的文件加载方法也可以便于对所有应用按照统一的图片压缩标准进行压缩处理，防止应用的图片压缩工具不适应设备屏幕的显示参数导致文件异常。

如图2所示为本申请实施例提供的一个文件加载方法的示意图，第一应用、向网络服务组件发送文件加载请求，网络服务组件通过网络下载第一文件之后，将第一文件发送给文件压缩组件进行压缩，得到第二文件，接着，文件压缩组件将第二文件发送给第一应用，以使第一应用能够加载第二文件。

在另一个示例中，网络服务组件可以包括文件压缩组件，那么，在网络服务组件通过网络下载得到第一文件之后，可以视为由网络服务组件将第一文件压缩为第二文件，如图3所示。

这样，第一应用可以加载压缩后的文件，从而降低第一应用加载文件所占用的内存，并且，不需要第一应用对文件进行处理，防止操作系统中每个应用使用独立的文件压缩工具执行文件压缩，可能会由于应用所使用的文件压缩工具压缩不规范，导致文件过大，造成内存占用过高、甚至内存溢出引起应用崩溃的问题。

本申请实施例提供的文件加载方法，通过为所有应用提供网络服务的网络服务组件下载文件，并在下载之后压缩文件，进而将压缩之后的文件发送给应用，这样可以统一为所有应用请求加载的网络文件进行压缩，便于统一压缩标准，防止由于应用没有文件压缩工具、或者在使用自己的文件压缩工具时，出现遗漏压缩的情况，进而由于文件过大，导致占用内存较多甚至引起应用崩溃的情况，解决了相关技术中应用没有设置文件压缩工具、或者遗漏压缩导致文件加载异常的问题，并且也解决了文件压缩标准不统一的问题，能够及时有效地压缩通过网络下载的文件，提高了应用加载网络文件的稳定性。

一个可选的示例中，在对于第一文件进行压缩时，可以依据第一应用向网络服务组件发送的文件压缩请求中的压缩目标参数，对下载的文件进行压缩，以使文件压缩至请求的参数大小。例如，对于图片类型的文件，压缩目标参数可以用于限定图片分辨率、压缩后的图片大小等，对于音频类的文件，压缩目标参数可以用于限定音频的比特率、压缩后的音频大小等等。当然，第一应用也可以请求不执行压缩，例如，对于一些并非用于显示的图片等，第一应用可以请求网络服务组件提供下载的原文件。

具体而言，在执行步骤103压缩第一文件，得到第二文件之前，可以执行步骤105：接收第一应用向网络服务组件请求的文件压缩请求。其中，文件压缩请求用于表示第一应用对第一文件的压缩目标参数。

这样，步骤103压缩第一文件，得到第二文件可以包括执行如下步骤：

步骤1031，获取文件压缩请求；

步骤1032，根据文件压缩请求，确定第一文件的压缩目标参数；

步骤1033，根据压缩目标参数压缩第一文件，得到第二文件。

也即，可以根据网络服务组件接收到的文件压缩请求，以确定第一应用请求压缩的目标参数，从而按照压缩目标参数对下载的第一文件进行压缩。可选的，在文件压缩请求用于请求第一文件的原文件的情况下，将第一文件发送至第一应用。

这样，可以提高应用加载文件的灵活性。

其中一个示例中，在第一文件为图片、压缩目标参数包括图片压缩之后的图片分辨率的情况下，可以依据屏幕分辨率对第一应用的文件压缩请求进行判定：如果压缩目标参数中的图片分辨率不超过屏幕分辨率，将第一文件的图片分辨率等比例压缩至压缩目标参数中的图片分辨率，得到第二文件；如果压缩目标参数中的图片分辨率超过屏幕分辨率，则将第一文件的图片分辨率等比例压缩至不超过屏幕分辨率的图片分辨率，得到第二文件。

由于运行应用的设备的屏幕分辨率可能是不同的，如果应用请求的图片分辨率高于屏幕分辨率，屏幕也是显示不出来对应的效果的，为了防止运行资源的浪费，可以通过上述的示例进行压缩处理，这样，可以结合运行本申请实施例提供的文件加载方法的电子设备的硬件特性(屏幕分辨率)，对应用的文件压缩请求进行辨别，使压缩处理更适用于当前设备的屏幕。

结合上述几个示例，在一个应用场景中提供一种可选的实施方式，如图4所示：

用户通过手机打开第一应用之后，第一应用需要进行页面的展示，页面中包括至少一张图片，这时，第一应用可以使用第一应用中的图片加载工具(例如Glide、Pissco、ImageLoader等已有的图片加载工具，或对其进行一定改动后得到的图片加载工具)进行图片资源请求(文件加载请求)，其中，文件加载请求中包括下载图片的URL地址。

第一应用将URL地址发送至httpclient(http代理)模块，接着，由网络代理将URL地址转发至http模块，其中，网络进程可以包括图4中的http、httpclient模块，手机中的每个应用在需要加载网络图片时，都需要通过网络进程下载图片，换句话说，http、httpclient是每个应用加载文件的公共模块。

由于图片是在网络中的服务端，此时第一应用的图片加载工具会向网络进程(网络服务组件)发出网络数据请求，由网络进程进行下载处理。

网络进程通过网络从服务端获取图片之后，首先可以判断应用层(包括所有应用)是否不限制图片大小的上限。

比如下载一张原图到手机，不需要进行展示的场景，可以不限制图片大小上限。这样，在第一应用向网络进程请求获取图片时，在请求中加上开关即可，根据开关判断是否在网络进程层对图片进行压缩处理。

如果第一应用请求不压缩，则网络进程直接向第一应用返回下载得到的原图。

如果第一应用未请求不压缩，则网络进程可以按照手机的屏幕分辨率来压缩图片。

由于每个手机展示的图片大小实际上有最大值，即使图片分辨率更大，在手机上展示出来，也没有效果。以一个1080*1920像素分辨率的手机举例，当加载的图片是2000*2000像素或者4000*4000像素，加载效果是没有区别的，因为手机最多承载的范围是1080*1920像素。

基于此，网络进程可以依据屏幕分辨率给图片分辨率设置上限，当图片分辨率大于手机的屏幕分辨率时，以屏幕分辨率为上限对图片进行压缩处理。该处理方式可以有效避免APP加载的图片过大、引起崩溃。

图片在手机内存加载所占用的大小可以简单的按照图片宽*图片高*像素格式(固定值)进行计算。所以当图片的宽高设置上限后，图片加载在手机的内存占用情况也就不会过大。

在网络进程对图片做压缩处理之后，网络进程将压缩后的图片发送给第一应用，这时，第一应用无需再通过图片加载工具进行处理，直接展示网络进程提供的图片即可。

上述实施方式避免了每个应用在加载图片时分别独立的进行内存优化处理带来的问题：由于没有一个统一的标准，处理的结果不同，页面比较多，存在压缩遗漏的情况，仍然可能造成加载的图片较大，引起应用崩溃。而本申请实施例提供的文件加载方法通过网络进程层面，对图片加载制定了一套压缩规范，可有效解决图片展示时较大的问题，能避免内存飙升，应用崩溃问题。

举例来说，如果下载了一张4896*6528像素的原图，该图片如果没有被压缩(每个应用都可能会在一些页面上对图片有压缩遗漏的场景)，占据的内存大小为4896*6528*4＝127844352byte＝120M，占据内存过大，有可能造成加载速度慢、甚至导致应用崩溃，影响应用使用的稳定性。但是，当使用本申请实施例提供的文件加载方法之后，通过网络进程在下载之后统一的进行压缩，不会造成压缩遗漏，根据屏幕分辨率对文件进行压缩后占据的内存大小为：1080*1920*4＝8294400byte＝7.9M，可以明显看出，图片所占用的内存从120M降为7.9M，这样就大大减小应用崩溃的可能性，提高了应用的稳定性。

在一个应用场景中，对于两个不同的应用，比如应用商店和游戏中心，可能都需要加载同一个会员活动详情的图片，对于这个图片，两个应用会向网络服务组件提供两个不同的URL，但是实际上这两个URL指向的图片内容是一致的，只是由于两个应用分属于不同的运营平台，所以应用商店、游戏中心会各自通过不同的URL加载一次，下载两张图片到本地。如果使用相关技术中的文件加载方法，由两个应用分别对图片独立的进行压缩，由于压缩规则不同，可能会导致图片的显示样式不同，用户看到后体验不统一，相同的图片在不同的页面忽大忽小。

这样，本申请实施例提供的文件加载方法还提供了一种可选的实施方式，可以保存历史压缩的文件，在第一应用请求的文件内容与历史下载的文件内容相同时，可以不再执行压缩处理，而是调取历史压缩的文件，从而保证文件压缩规格相同，并省略掉本次文件压缩的过程，减少占用内存。

具体而言，在执行步骤103压缩第一文件，得到第二文件时，可以执行如下步骤：

步骤202，获取所述第一文件的验证密码。

其中，验证密码可以是预先通过加密方法对文件内容进行加密得到的，例如，可以通过MD5信息摘要算法(MD5 Message-Digest Algorithm)，也即通过一种密码散列函数对文件进行处理，产生出一个128位(16字节)的散列值(hash value)，用于确保文件信息传输完整一致。

步骤203，根据所述验证密码，在历史下载文件中匹配是否已下载所述第一文件。

在本实施方式中，可以保存历史下载的文件以及对其进行压缩处理后的文件。这样，在获得下载文件的验证密码之后，可以在历史下载文件中根据验证密码匹配已保存的下载文件中是否存在第一文件。

步骤204，在匹配到所述第一文件的情况下，获取历史已对所述第一文件执行压缩得到的所述第二文件。

如果匹配到第一文件，说明可能存在其它应用或者是第一应用已下载过相同的文件。

这样，通过本实施方式提供的文件加载方法，可以使用网络服务组件判断是否已经压缩过相同内容的文件，这样，该应用或另一个应用需要加载相同内容的文件时，即使下载文件的URL地址不同，仍然可以用验证密码来对比需要加载的文件是否已下载并压缩处理过。这样，在历史下载文件中匹配到相同的文件之后，可以将之前压缩处理后的文件直接提供给发送文件加载请求的应用，避免重复对相同内容的文件执行压缩处理，并可以保证文件压缩规格的统一性。

例如，如图5所示，应用商店在加载图片之后，可以记录和保存该图片和压缩后的图片。当游戏中心再去加载这个图片时，URL可能是不同的，但是，md5是一致的，因此，在获取下载后的文件之后，可以根据这个图片的md5与历史记录中文件的md5进行比对，如果md5一致，则说明是相同图片。这时，就可以直接返回给游戏中心已保存的压缩好的图片，保证了两个应用侧的资源一致，不会出现异常，并且也不需要再额外做一次图片压缩，减少了对运行内存的占用。

需要说明的是，本申请实施例提供的文件加载方法，执行主体可以为文件加载装置，或者该文件加载装置中的用于执行文件加载方法的控制模块。本申请实施例中以文件加载装置执行文件加载方法为例，说明本申请实施例提供的文件加载装置。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的文件加载装置进行详细地说明。在本申请实施例提供的文件加载装置中未详述的内容，可以参考本申请实施例提供的文件加载方法，在此不再赘述。

如图6所示，本申请实施例提供的文件加载装置包括第一接收单元601，下载单元602，压缩单元603和发送单元604。

其中，第一接收单元601用于接收第一应用向操作系统中的网络服务组件发送的文件加载请求；其中，网络服务组件用于向操作系统中的所有应用提供网络服务；

下载单元602用于响应于文件加载请求，通过网络服务组件下载第一应用请求加载的第一文件；

压缩单元603用于压缩第一文件，得到第二文件；

发送单元604用于将第二文件发送至第一应用，以使第一应用加载第二文件。

可选地，该装置还可以包括：

第二接收单元，用于在压缩第一文件，得到第二文件之前，接收第一应用向网络服务组件请求的文件压缩请求，其中，文件压缩请求用于表示第一应用对第一文件的压缩目标参数；

相应地，压缩单元可以包括：

第一获取子单元，用于获取文件压缩请求；

确定子单元，用于根据文件压缩请求，确定第一文件的压缩目标参数；

压缩子单元，用于根据压缩目标参数压缩第一文件，得到第二文件。

可选地，在第一文件为图片、压缩目标参数包括图片压缩之后的图片分辨率的情况下，确定子单元还可以在压缩目标参数中的图片分辨率不超过屏幕分辨率的情况下，将第一文件的图片分辨率等比例压缩至压缩目标参数中的图片分辨率，得到第二文件；以及在压缩目标参数中的图片分辨率超过屏幕分辨率的情况下，将第一文件的图片分辨率等比例压缩至不超过屏幕分辨率的图片分辨率，得到第二文件。

可选地，发送单元还可以在接收第一应用向网络服务组件请求的文件压缩请求之后，在文件压缩请求用于请求第一文件的原文件的情况下，将第一文件发送至第一应用。

可选地，压缩单元可以包括：

第二获取子单元，用于获取第一文件的验证密码；

匹配子单元，用于根据验证密码，在历史下载文件中匹配是否已下载第一文件；

第三获取子单元，用于在匹配到第一文件的情况下，获取历史已对第一文件执行压缩得到的第二文件。

可选地，操作系统中可以包括文件压缩组件，相应地，压缩单元可以包括：

调用子单元，用于调用文件压缩组件，以请求文件压缩组件压缩第一文件；

第四获取子单元，用于获取文件压缩组件压缩第一文件后得到的第二文件。

可选地，网络服务组件可以包括上述的文件压缩组件。

本申请实施例提供的文件加载装置，通过为所有应用提供网络服务的网络服务组件下载文件，并在下载之后压缩文件，进而将压缩之后的文件发送给应用，这样可以统一为所有应用请求加载的网络文件进行压缩，便于统一压缩标准，防止由于应用没有文件压缩工具、或者在使用自己的文件压缩工具时，出现遗漏压缩的情况，进而由于文件过大，导致占用内存较多甚至引起应用崩溃的情况，解决了相关技术中应用没有设置文件压缩工具、或者遗漏压缩导致文件加载异常的问题，并且也解决了文件压缩标准不统一的问题，能够及时有效地压缩通过网络下载的文件，提高了应用加载网络文件的稳定性。

本申请实施例中的文件加载装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personaldigital assistant，PDA)等，非移动电子设备可以为服务器、网络附属存储器(NetworkAttached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的文件加载装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的文件加载装置能够实现图1至图5的方法实施例实现的各个过程，为避免重复，这里不再赘述。

可选地，如图7所示，本申请实施例还提供一种电子设备900，包括处理器901，存储器902，存储在存储器902上并可在所述处理器901上运行的程序或指令，该程序或指令被处理器901执行时实现上述文件加载方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

图8为实现本申请实施例的一种电子设备的硬件结构示意图。

该电子设备1000包括但不限于：射频单元1001、网络模块1002、音频输出单元1003、输入单元1004、传感器1005、显示单元1006、用户输入单元1007、接口单元1008、存储器1009、以及处理器1010等部件。

本领域技术人员可以理解，电子设备1000还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器1010逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图8中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。

其中，网络模块1002用于接收第一应用向操作系统中的网络服务组件发送的文件加载请求；其中，网络服务组件用于向操作系统中的所有应用提供网络服务；响应于文件加载请求，通过网络服务组件下载第一应用请求加载的第一文件；

网络模块1002或处理器1010可以压缩第一文件，得到第二文件；并将第二文件发送至第一应用，以使第一应用加载第二文件。

可选地，网络模块1002还用于在压缩第一文件，得到第二文件之前，接收第一应用向网络服务组件请求的文件压缩请求，其中，文件压缩请求用于表示第一应用对第一文件的压缩目标参数。相应地，网络模块1002或处理器1010在压缩第一文件，得到第二文件时，可以获取文件压缩请求；根据文件压缩请求，确定第一文件的压缩目标参数；根据压缩目标参数压缩第一文件，得到第二文件。

可选地，在第一文件为图片、压缩目标参数包括图片压缩之后的图片分辨率的情况下，网络模块1002或处理器1010在根据文件压缩请求，确定第一文件的压缩目标参数时，可以在压缩目标参数中的图片分辨率不超过屏幕分辨率的情况下，将第一文件的图片分辨率等比例压缩至压缩目标参数中的图片分辨率，得到第二文件；或者，在压缩目标参数中的图片分辨率超过屏幕分辨率的情况下，将第一文件的图片分辨率等比例压缩至不超过屏幕分辨率的图片分辨率，得到第二文件。

可选地，网络模块1002或处理器1010可以在接收第一应用向网络服务组件请求的文件压缩请求之后，在文件压缩请求用于请求第一文件的原文件的情况下，将第一文件发送至第一应用。

可选地，网络模块1002或处理器1010在压缩第一文件，得到第二文件时，可以获取第一文件的验证密码；根据验证密码，在历史下载文件中匹配是否已下载第一文件；在匹配到第一文件的情况下，获取历史已对第一文件执行压缩得到的第二文件。

可选地，处理器1010运行的操作系统中可以包括文件压缩组件，这样，处理器1010在执行压缩第一文件，得到第二文件时，可以包括执行如下步骤：

调用文件压缩组件，以请求文件压缩组件压缩第一文件；

获取文件压缩组件压缩第一文件后得到的第二文件。

可选地，上述网络服务组件可以包括文件压缩组件。

本申请实施例提供的电子设备，通过为所有应用提供网络服务的网络服务组件下载文件，并在下载之后压缩文件，进而将压缩之后的文件发送给应用，这样可以统一为所有应用请求加载的网络文件进行压缩，便于统一压缩标准，防止由于应用没有文件压缩工具、或者在使用自己的文件压缩工具时，出现遗漏压缩的情况，进而由于文件过大，导致占用内存较多甚至引起应用崩溃的情况，解决了相关技术中应用没有设置文件压缩工具、或者遗漏压缩导致文件加载异常的问题，并且也解决了文件压缩标准不统一的问题，能够及时有效地压缩通过网络下载的文件，提高了应用加载网络文件的稳定性。

应理解的是，本申请实施例中，输入单元1004可以包括图形处理器(GraphicsProcessing Unit，GPU)1041和麦克风1042，图形处理器1041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态文件或视频的图像数据进行处理。显示单元1006可包括显示面板1061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板1061。用户输入单元1007包括触控面板1071以及其他输入设备1072。触控面板1071，也称为触摸屏。触控面板1071可包括触摸检测装置和触摸控制器两个部分。其他输入设备1072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。存储器1009可用于存储软件程序以及各种数据，包括但不限于应用程序和操作系统。处理器1010可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1010中。

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述文件加载方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述文件加载方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (8)

1.一种文件加载方法，其特征在于，所述方法包括：

接收第一应用向操作系统中的网络服务组件发送的文件加载请求；其中，所述网络服务组件用于向所述操作系统中的所有应用提供网络服务；所述文件加载请求包括统一资源符URL；

响应于所述文件加载请求，通过所述网络服务组件下载所述第一应用请求加载的第一文件；

压缩所述第一文件，得到第二文件；

将所述第二文件发送至所述第一应用，以使所述第一应用加载所述第二文件；

所述压缩所述第一文件，得到第二文件，包括：

获取所述第一文件的验证密码，所述验证密码通过加密方法对文件内容进行加密得到的；不同应用加载相同内容的文件时，发送的文件加载请求中的URL不同；

根据所述验证密码，在历史下载文件中匹配是否已下载所述第一文件；

在匹配到所述第一文件的情况下，获取历史已对所述第一文件执行压缩得到的所述第二文件。

2.根据权利要求1所述的方法，其特征在于，在压缩所述第一文件，得到第二文件之前，所述方法还包括：

接收所述第一应用向所述网络服务组件请求的文件压缩请求，其中，所述文件压缩请求用于表示所述第一应用对所述第一文件的压缩目标参数；

所述压缩所述第一文件，得到第二文件，包括：

获取所述文件压缩请求；

根据所述文件压缩请求，确定所述第一文件的压缩目标参数；

根据所述压缩目标参数压缩所述第一文件，得到所述第二文件。

3.根据权利要求2所述的方法，其特征在于，在所述第一文件为图片、所述压缩目标参数包括所述图片压缩之后的图片分辨率的情况下，所述根据所述文件压缩请求，确定所述第一文件的压缩目标参数，包括：

在所述压缩目标参数中的图片分辨率不超过屏幕分辨率的情况下，将所述第一文件的图片分辨率等比例压缩至所述压缩目标参数中的图片分辨率，得到所述第二文件；

在所述压缩目标参数中的图片分辨率超过屏幕分辨率的情况下，将所述第一文件的图片分辨率等比例压缩至所述不超过所述屏幕分辨率的图片分辨率，得到所述第二文件。

4.根据权利要求2所述的方法，其特征在于，在接收所述第一应用向所述网络服务组件请求的文件压缩请求之后，所述方法还包括：

在所述文件压缩请求用于请求所述第一文件的原文件的情况下，将所述第一文件发送至所述第一应用。

5.一种文件加载装置，其特征在于，所述装置包括：

第一接收单元，用于接收第一应用向操作系统中的网络服务组件发送的文件加载请求；其中，所述网络服务组件用于向所述操作系统中的所有应用提供网络服务；所述文件加载请求包括统一资源符URL；

下载单元，用于响应于所述文件加载请求，通过所述网络服务组件下载所述第一应用请求加载的第一文件；

压缩单元，用于压缩所述第一文件，得到第二文件；

发送单元，用于将所述第二文件发送至所述第一应用，以使所述第一应用加载所述第二文件；

所述压缩单元，包括：

第二获取子单元，用于获取所述第一文件的验证密码，所述验证密码通过加密方法对文件内容进行加密得到的；不同应用加载相同内容的文件时，发送的文件加载请求中的URL不同；

匹配子单元，用于根据所述验证密码，在历史下载文件中匹配是否已下载所述第一文件；

第三获取子单元，用于在匹配到所述第一文件的情况下，获取历史已对所述第一文件执行压缩得到的所述第二文件。

6.根据权利要求5所述的装置，其特征在于，所述装置还包括：

第二接收单元，用于在压缩所述第一文件，得到第二文件之前，接收所述第一应用向所述网络服务组件请求的文件压缩请求，其中，所述文件压缩请求用于表示所述第一应用对所述第一文件的压缩目标参数；

所述压缩单元包括：

第一获取子单元，用于获取所述文件压缩请求；

确定子单元，用于根据所述文件压缩请求，确定所述第一文件的压缩目标参数；

压缩子单元，用于根据所述压缩目标参数压缩所述第一文件，得到所述第二文件。

7.根据权利要求6所述的装置，其特征在于，在所述第一文件为图片、所述压缩目标参数包括所述图片压缩之后的图片分辨率的情况下，所述确定子单元还用于在所述压缩目标参数中的图片分辨率不超过屏幕分辨率的情况下，将所述第一文件的图片分辨率等比例压缩至所述压缩目标参数中的图片分辨率，得到所述第二文件；以及在所述压缩目标参数中的图片分辨率超过屏幕分辨率的情况下，将所述第一文件的图片分辨率等比例压缩至所述不超过所述屏幕分辨率的图片分辨率，得到所述第二文件。

8.根据权利要求6所述的装置，其特征在于，所述发送单元还用于在接收所述第一应用向所述网络服务组件请求的文件压缩请求之后，在所述文件压缩请求用于请求所述第一文件的原文件的情况下，将所述第一文件发送至所述第一应用。

Images