Resource Loading Method, Apparatus, Electronic Device, and Computer-Readable Storage Medium

Abstract

An embodiment of the present invention provides a resource loading method, apparatus, electronic device, and computer-readable storage medium, which relate to the field of Internet technologies. The method obtains a resource loading request sent by an application program. The resource loading request carries a target compressed package identifier and a target relative path. According to the target compressed package identifier, the local compressed package corresponding to the target resource file is obtained. After the signature verification of the local compressed package is correct, the target resource file is decompressed from the local compressed package according to the target relative path, and the target resource file is returned to the application program for loading. Based on the target compressed package identifier and the target relative path carried in the resource loading request, only the resource files that need to be loaded are decompressed from the local compressed package, and the resource files that are not temporarily used will not be decompressed. Moreover, the decompressed resource files are data that have passed the signature verification of the compressed package. Therefore, on-demand and secure loading of resource files can be achieved, with lower memory occupancy and faster resource loading speed.

Description

Technical Field

[0001] The present invention relates to the field of Internet technologies, and in particular, to a resource loading method, apparatus, electronic device, and computer-readable storage medium. Background Art

[0002] H5 (html5) is a hypertext markup language, which has the advantages of cross-platform, easy development, high efficiency, convenient debugging, etc. With the development of mobile Internet, there are a large number of H5 pages in various application programs. When an application program loads an H5 page, it is easily affected by the quality of the mobile network. If the mobile network quality is poor, it will lead to a long loading time or loading failure.

[0003] The characteristics of unstable mobile network, traffic sensitivity, frequent access changes, etc. have spawned modern offline package technologies. Modern offline package technologies minimize the impact of the network environment on the loading speed of H5 pages through resource offlineization solutions, so as to ensure a good user experience of H5 products on mobile terminals. However, technologies such as jailbreaking and ROOT on mobile devices have destroyed the closedness of the device sandbox, and the offline resources can be freely modified, which may result in the H5 pages actually accessed by end users no longer being the H5 pages provided by developers. To avoid such problems, the tampering detection of offline packages has emerged.

[0004] In the prior art, the solutions for secure loading of offline packages on mobile terminals are mostly whole-package signature verification solutions. The whole-package signature verification solution will perform signature verification on the entire offline package when the offline package is loaded for the first time. After the signature verification passes, the data of the entire offline package will be decompressed into the running memory. Since the objects of signature verification and decompression are the entire offline package, when the offline package is large in size, it will face problems such as slow loading speed and high memory occupancy. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a resource loading method, apparatus, electronic device, and computer-readable storage medium to solve the problems of slow resource loading speed and high memory occupancy in the prior art's secure loading solution based on whole-package signature verification and loading into memory.

[0006] To achieve the above purpose, the technical solutions adopted in the embodiments of the present invention are as follows:

[0007] In a first aspect, the present invention provides a resource loading method, and the method includes:

[0008] Obtain a resource loading request sent by an application; the resource loading request carries a target compressed package identifier and a target relative path; the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file within the local compressed package;

[0009] Obtain the local compressed package corresponding to the target resource file according to the target compressed package identifier;

[0010] Perform signature verification on the local compressed package;

[0011] After the signature verification is correct, decompress the target resource file from the local compressed package according to the target relative path;

[0012] Return the target resource file to the application so that the application can load the target resource file.

[0013] In an alternative embodiment, the obtaining the local compressed package corresponding to the target resource file according to the target compressed package identifier includes:

[0014] Determine the local storage path of the local compressed package corresponding to the target resource file according to the target compressed package identifier and a preset local path of the compressed package;

[0015] Obtain the local compressed package according to the local storage path.

[0016] In an alternative embodiment, the decompressing the target resource file from the local compressed package according to the target relative path includes:

[0017] Determine the local file header offset corresponding to the target relative path according to the correspondence between the relative paths of the resource files in the local compressed package and the local file header offsets;

[0018] Obtain the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path;

[0019] Decompress the target compressed data to obtain the target resource file.

[0020] In an alternative embodiment, the obtaining the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path includes:

[0021] Obtain the local file header of the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path; the size of the compressed data is recorded in the local file header of the target compressed data.

[0022] Obtain the target compressed data corresponding to the target resource file according to the local file header of the target compressed data and the size of the compressed data.

[0023] In an alternative embodiment, before determining the local file header offset corresponding to the target relative path according to the correspondence between the relative paths of the resource files in the local compressed package and the local file header offsets, the method further includes:

[0024] Traverse all the file headers in the central directory of the local compressed package; wherein, each resource file in the local compressed package corresponds to a file header, and the relative path and local file header offset corresponding to the resource file are recorded in the file header.

[0025] Obtain the correspondence between the relative paths of the resource files in the local compressed package and the local file header offsets according to the relative paths and local file header offsets recorded in each file header.

[0026] In an alternative embodiment, the obtaining of the resource loading request sent by the application program includes:

[0027] When the resource loading request sent by the application program meets the preset interception condition, intercept the resource loading request.

[0028] In a second aspect, the present invention provides a resource loading device, and the device includes:

[0029] A request acquisition module, configured to acquire a resource loading request sent by an application program; the resource loading request carries a target compressed package identifier and a target relative path; the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file in the local compressed package.

[0030] A compressed package acquisition module, configured to acquire the local compressed package corresponding to the target resource file according to the target compressed package identifier.

[0031] A signature verification module, configured to perform signature verification on the local compressed package.

[0032] An extraction module, configured to extract the target resource file from the local compressed package according to the target relative path after the signature verification is correct.

[0033] A data return module, configured to return the target resource file to the application, so that the application can load the target resource file.

[0034] In an optional embodiment, the decompression module is configured to determine the local file header offset corresponding to the target relative path according to the correspondence between the relative paths of the resource files in the local compressed package and the local file header offsets; obtain the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path; and decompress the target compressed data to obtain the target resource file.

[0035] In a third aspect, the present invention provides an electronic device, including a processor, a memory, and a computer program stored on the memory and executable on the processor. When the computer program is executed by the processor, the steps of the resource loading method according to any one of the foregoing embodiments are implemented.

[0036] In a fourth aspect, the present invention provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the resource loading method according to any one of the foregoing embodiments are implemented.

[0037] The resource loading method, device, electronic device, and computer-readable storage medium provided by the embodiments of the present invention. The method obtains a resource loading request sent by an application. Since the resource loading request carries a target compressed package identifier and a target relative path, and the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file in the local compressed package, the local compressed package corresponding to the target resource file can be obtained according to the target compressed package identifier, and the local compressed package is subjected to signature verification. After the signature verification is correct, the target resource file can be decompressed from the local compressed package according to the target relative path, and the target resource file is returned to the application so that the application can load the target resource file. It can be seen that based on the target compressed package identifier and the target relative path carried in the obtained resource loading request, the present invention only needs to decompress the resource file to be loaded from the local compressed package, and the resource files that are not temporarily used will not be decompressed. Only when the application loads a certain resource file will that resource file be decompressed, and it is not necessary to decompress the entire compressed package at one time. Moreover, the decompressed resource file is data that has passed the signature verification of the compressed package. Therefore, the on-demand and secure loading of resource files can be realized, the memory occupancy will be lower, and the resource loading speed will be faster.

[0038] To make the above objects, features, and advantages of the present invention more obvious and understandable, the following specific preferred embodiments are given in conjunction with the accompanying drawings and are described in detail as follows. Brief Description of the Drawings

[0039] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention, and thus should not be regarded as limiting the scope. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0040] Figure 1 It shows a schematic flowchart of a resource loading method provided by an embodiment of the present invention;

[0041] Figure 2 It shows another schematic flowchart of a resource loading method provided by an embodiment of the present invention;

[0042] Figure 3 It shows yet another schematic flowchart of a resource loading method provided by an embodiment of the present invention;

[0043] Figure 4 It shows a schematic structural diagram of a PKZip file;

[0044] Figure 5 It shows a schematic structural diagram of a central directory;

[0045] Figure 6 It shows a schematic structural diagram of a file header;

[0046] Figure 7 It shows a schematic structural diagram of a local file header;

[0047] Figure 8 It shows a functional module diagram of a resource loading device provided by an embodiment of the present invention;

[0048] Figure 9 It shows a schematic block diagram of an electronic device provided by an embodiment of the present invention.

[0049] Icons: 700 - Electronic device; 800 - Resource loading device; 710 - Memory; 720 - Processor; 730 - Communication module; 810 - Request acquisition module; 820 - Compressed package acquisition module; 830 - Signature verification module; 840 - Decompression module; 850 - Data return module. Detailed Embodiments

[0050] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Usually, the components of the embodiments of the present invention described and shown in the drawings here can be arranged and designed in various different configurations.

[0051] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention claimed for protection, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present invention.

[0052] It should be noted that relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0053] Most existing offline package security loading solutions are for whole package memory loading, that is, the entire offline package needs to be decompressed into the memory at one time, and the decompression object is the entire offline package. Therefore, when the offline package is large, it will face problems such as slow loading speed and high memory usage.

[0054] Based on this, an embodiment of the present invention proposes a resource loading method, device, electronic device and computer-readable storage medium, which only needs to decompress the resource files that need to be loaded from the local compressed package based on the target compressed package identifier and the target relative path carried in the obtained resource loading request, and the resource files that are not used temporarily will not be decompressed. Only the resource files loaded by the application will be decompressed, and there is no need to decompress the entire compressed package at one time. The resource files obtained by decompression are data that has been verified by the compressed package signature, so on-demand and secure loading of resource files can be achieved, memory usage will be lower, and the resource loading speed will be faster.

[0055] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0056] Please refer to Figure 1 , is a flow chart of a resource loading method provided by an embodiment of the present invention. It should be noted that the resource loading method of the embodiment of the present invention is not based on Figure 1And subject to the following specific order, it should be understood that in other embodiments, the order of some steps of the resource loading method of the embodiments of the present invention can be mutually exchanged according to actual needs, or some of the steps can also be omitted or deleted. This resource loading method can be applied to electronic devices such as smart phones, tablet computers, personal digital assistants (PDAs), etc. The following will describe Figure 1 the specific process shown in detail.

[0057] Step S101, obtain a resource loading request sent by an application; the resource loading request carries a target compressed package identifier and a target relative path; the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file within the local compressed package.

[0058] In this embodiment, when a user needs to access a certain H5 page, an App (Application) installed in the held electronic device can initiate a resource loading request. After the electronic device obtains the resource loading request, it starts the processing process for the resource loading request. Among them, the App can be a browser or other types of application programs, and the embodiments of the present invention do not limit this.

[0059] In this embodiment, an application program can correspond to compressed packages of different business types, and each compressed package has a corresponding business ID (i.e., the compressed package identifier). When the application program starts, by interacting with the server, it can download the compressed packages corresponding to different compressed package identifiers from the server and save the corresponding compressed packages to the local according to the compressed package identifiers.

[0060] In this embodiment, when the compression of the resource file is completed, the relative path of the compressed data corresponding to each resource file within the compressed package will be recorded in the compressed package. Through the relative path, the position of the compressed data corresponding to each resource file within the entire compressed package can be quickly found.

[0061] Step S102, obtain the local compressed package corresponding to the target resource file according to the target compressed package identifier.

[0062] In this embodiment, since the electronic device stores the compressed package locally according to the compressed package identifier after obtaining the compressed package from the server, the local compressed package corresponding to the target compressed package identifier can be found according to the target compressed package identifier carried in the resource loading request.

[0063] Step S103, perform signature verification on the local compressed package.

[0064] In this embodiment, when the application starts, it not only obtains the compressed packages corresponding to different compressed package identifiers from the server, but also obtains information such as the version number and signature corresponding to each compressed package provided by the server, and saves them locally. After the electronic device obtains the local compressed package corresponding to the target resource file, it can use an asymmetric encryption algorithm to verify the signature of the local compressed package. If the verification is successful, it indicates that the local compressed package has not been maliciously tampered with locally, and subsequent operation steps can be performed.

[0065] Step S104, after the signature verification is successful, extract the target resource file from the local compressed package according to the target relative path.

[0066] In this embodiment, since the position of the compressed data corresponding to each resource file in the entire compressed package can be quickly found according to the relative path of the compressed data corresponding to each resource file in the compressed package, correspondingly, the position of the target compressed data corresponding to the target resource file can also be found in the entire local compressed package according to the target relative path carried in the resource loading request. Then, by obtaining the target compressed data and decompressing it, the target resource file can be obtained. Among them, the target resource file can be decompressed into memory without being written to the local disk.

[0067] Step S105, return the target resource file to the application so that the application can load the target resource file.

[0068] In this embodiment, the target resource file extracted by the electronic device from the local compressed package according to the target relative path can be single-file decompression data. The electronic device returns the single-file data (target resource file) decompressed into memory to the application, and the application loads the target resource file, realizing single-file decompression and loading, greatly reducing memory occupancy and improving resource loading speed. Moreover, the single-file data decompressed from the local compressed package to memory in this embodiment is data that has passed the compressed package signature verification, and it can be confirmed that the data is safe and has not been maliciously tampered with. Therefore, the data can be returned to the application for loading, ensuring the safe loading of resources.

[0069] It can be seen that for the resource loading method provided in the embodiment of the present invention, by obtaining a resource loading request sent by an application program, since the resource loading request carries a target compressed package identifier and a target relative path, and the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file within the local compressed package, the local compressed package corresponding to the target resource file can be obtained according to the target compressed package identifier, and the local compressed package is subjected to signature verification. After the signature verification is correct, the target resource file can be decompressed from the local compressed package according to the target relative path, and the target resource file is returned to the application program so that the application program can load the target resource file. It can be seen that based on the target compressed package identifier and the target relative path carried in the obtained resource loading request, only the resource file that needs to be loaded needs to be decompressed from the local compressed package, and the resource files that are not temporarily needed will not be decompressed. Only when the application program loads a certain resource file will that resource file be decompressed, and it is not necessary to decompress the entire compressed package at one time. Moreover, the decompressed resource file is data that has passed the signature verification of the compressed package. Therefore, on-demand and secure loading of resource files can be achieved, the memory occupancy will be lower, and the resource loading speed will also be faster.

[0070] In practical applications, the resource loading request can be obtained by means of interception. Considering that not all resource loading requests may need to be intercepted. For example, some resource loading requests are not requests for offline resources, so they do not need to be intercepted. In this case, the interception condition can be set in advance to achieve accurate interception of the resource loading request. Based on this, step S101 above can include: intercepting the resource loading request when the resource loading request sent by the application program meets the preset interception condition.

[0071] In this embodiment, a custom interception proxy can be added to the application program (for example, Android: WebViewClient, iOS: WKURLSchemeHandler), and the interception condition is set in the custom interception proxy. The resource loading request that meets the preset interception condition is intercepted through the custom interception proxy to clarify the specific loading requirements of the application program, which is convenient for subsequent operation steps.

[0072] Among them, the preset interception condition can be set according to the actual situation. For example, it can be set that the protocol type of the resource loading request is a preset offline package protocol to ensure that only the loading request for offline resources is intercepted.

[0073] In a specific example, assume that the request address of a certain resource loading request is "gmu: / / a.vhost.com / index.html". The custom intercept proxy determines that its protocol type is the preset offline package protocol according to the protocol header. The resource loading request meets the preset interception conditions, and the resource loading request is intercepted.

[0074] Optionally, please refer to Figure 2 , the above step S102 may include the following sub-steps:

[0075] Sub-step S1021, determine the local storage path of the local compressed package corresponding to the target resource file according to the target compressed package identifier and the preset local path of the compressed package.

[0076] In this embodiment, the electronic device will pre-set a directory for each application to specifically store offline package data, that is, the local path of the compressed package, such as / App / Demo / offline package. After the application obtains the compressed package from the server, it will be saved in the corresponding directory according to the compressed package identifier of the compressed package. For example, if the compressed package identifier is "a", the compressed package will be saved in the directory / App / Demo / offline package / a; if the compressed package identifier is "b", the compressed package will be saved in the directory / App / Demo / offline package / b.

[0077] When the electronic device intercepts a resource loading request through the custom intercept proxy and extracts the target compressed package identifier carried by the resource loading request, the target compressed package identifier is concatenated with the preset local path of the compressed package / App / Demo / offline package, and the local storage path of the local compressed package corresponding to the target resource file can be obtained. For example, if the target compressed package identifier is "a", the local storage path of the local compressed package corresponding to the target resource file is determined to be / App / Demo / offline package / a.

[0078] It should be noted that in actual applications, since there may be different versions of the compressed package, the application can save the compressed package in the corresponding directory according to the compressed package identifier and version number of the compressed package. For example, if the compressed package identifier is "a" and the version number is "1.0", the compressed package will be saved in the directory / App / Demo / offline package / a / 1.0. Correspondingly, when the electronic device determines the local storage path of the local compressed package corresponding to the target resource file, it can first determine the corresponding version number according to the target compressed package identifier, and then concatenate the target compressed package identifier, version number with the preset local path of the compressed package / App / Demo / offline package to obtain the local storage path of / App / Demo / offline package / a / 1.0.

[0079] Sub-step S1022, obtain the local compressed package according to the local storage path.

[0080] In this embodiment, after obtaining the local storage path of the local compressed package corresponding to the target resource file, the stored local compressed package can be queried based on this local storage path. For example, if the local storage path is / App / Demo / offline package / a, then the local compressed package corresponding to the target resource file can be read in the directory / App / Demo / offline package / a.

[0081] Optionally, please refer to Figure 3 , the above step S104 may include the following sub-steps:

[0082] Sub-step S1041: After the signature verification is correct, determine the local file header offset corresponding to the target relative path according to the correspondence between the relative paths of the respective resource files in the local compressed package and the local file header offsets.

[0083] In this embodiment, the correspondence between the relative paths of the respective resource files in the local compressed package and the local file header offsets can be obtained through the following steps: Traverse all the file headers in the central directory of the local compressed package; where each resource file in the local compressed package corresponds to a file header, and the relative path and local file header offset corresponding to the resource file are recorded in the file header; according to the relative paths and local file header offsets recorded in each file header, obtain the correspondence between the relative paths of the respective resource files in the local compressed package and the local file header offsets.

[0084] Taking Figure 4 the structure of the PKZip file shown as an example, the data content of "Central Directory" can be located through the flag bits in the central directory (Central Directory) data segment (as shown in Figure 5 ). In the data content of "Central Directory" shown in Figure 5 , traverse the content of all file headers (File Header 1, File Header2,..., File Header n), where the content of each file header is as shown in Figure 6 . The relative path information corresponding to the resource file is recorded in "File name", and the local file header offset corresponding to the resource file is recorded in "Offset of local header". By reading the content of "File name" and "Offset of local header" in each file header, the correspondence between the relative paths of the respective resource files in the local compressed package and the local file header offsets can be obtained.

[0085] It should be understood that in practical applications, only when the local compressed package is decompressed for the first time, all file headers in the central directory need to be traversed to obtain the correspondence between the relative paths of each resource file in the local compressed package and the local file header offsets; subsequently, when a certain target resource file in the local compressed package is to be loaded, the previously traversed correspondence can be directly searched according to the target relative path corresponding to the target resource file, and the offset position (i.e., the local file header offset) of the target compressed data corresponding to the target resource file in the entire local compressed package can be quickly located.

[0086] Sub-step S1042: Obtain the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path.

[0087] Optionally, the electronic device can obtain the local file header of the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path; the size of the compressed data is recorded in the local file header of the target compressed data; the target compressed data corresponding to the target resource file is obtained according to the local file header of the target compressed data and the size of the compressed data.

[0088] In this embodiment, after the electronic device obtains the local file header offset, it can locate the data content of the local file header "Localfile headers" (as Figure 7 shown), and calculate the range of the target compressed data corresponding to the target resource file according to the local file header and the size of the compressed data recorded in "Compressed size" in the local file header, and then read out the target compressed data corresponding to the target resource file.

[0089] Sub-step S1043: Decompress the target compressed data to obtain the target resource file.

[0090] In this embodiment, the electronic device can decompress the target compressed data through the data decompression API (Application Programming Interface) provided by the operating system to obtain the target resource file.

[0091] In order to execute the corresponding steps in the above embodiments and various possible ways, an implementation manner of a resource loading device is given below. Please refer to Figure 8, which is a functional module diagram of a resource loading device 800 provided by an embodiment of the present invention. It should be noted that the basic principle and the technical effects produced by the resource loading device 800 provided in this embodiment are the same as those in the above embodiments. For a brief description, for the parts not mentioned in this embodiment, reference can be made to the corresponding content in the above embodiments. The resource loading device 800 includes a request acquisition module 810, a compressed package acquisition module 820, a signature verification module 830, a decompression module 840, and a data return module 850.

[0092] The request acquisition module 810 is configured to acquire a resource loading request sent by an application program; the resource loading request carries a target compressed package identifier and a target relative path; the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file within the local compressed package.

[0093] It can be understood that the request acquisition module 810 can execute the above step S101.

[0094] The compressed package acquisition module 820 is configured to acquire the local compressed package corresponding to the target resource file according to the target compressed package identifier.

[0095] It can be understood that the compressed package acquisition module 820 can execute the above step S102.

[0096] The signature verification module 830 is configured to perform signature verification on the local compressed package.

[0097] It can be understood that the signature verification module 830 can execute the above step S103.

[0098] The decompression module 840 is configured to decompress the target resource file from the local compressed package according to the target relative path after the signature verification is correct.

[0099] It can be understood that the decompression module 840 can execute the above step S104.

[0100] The data return module 850 is configured to return the target resource file to the application program so that the application program can load the target resource file.

[0101] It can be understood that the data return module 850 can execute the above step S105.

[0102] Optionally, the request acquisition module 810 is specifically configured to intercept the resource loading request when the resource loading request sent by the application program meets a preset interception condition.

[0103] Optionally, the compressed package obtaining module 820 is specifically configured to determine the local storage path of the local compressed package corresponding to the target resource file according to the target compressed package identifier and the preset local path of the compressed package; and obtain the local compressed package according to the local storage path.

[0104] It can be understood that the compressed package obtaining module 820 can specifically execute the above sub-steps S1021 and S1022.

[0105] Optionally, the decompression module 840 can be used to determine the local file header offset corresponding to the target relative path according to the corresponding relationship between the relative paths of the resource files in the local compressed package and the local file header offsets; obtain the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path; and decompress the target compressed data to obtain the target resource file.

[0106] It can be understood that the decompression module 840 can execute the above sub-steps S1041 to S1043.

[0107] Optionally, the decompression module 840 is specifically configured to obtain the local file header of the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path; the size of the compressed data is recorded in the local file header of the target compressed data; and obtain the target compressed data corresponding to the target resource file according to the local file header of the target compressed data and the size of the compressed data.

[0108] Optionally, the decompression module 840 is further configured to traverse all the file headers in the central directory of the local compressed package before determining the local file header offset corresponding to the target relative path according to the corresponding relationship between the relative paths of the resource files in the local compressed package and the local file header offsets; each resource file in the local compressed package corresponds to a file header, and the relative path and the local file header offset corresponding to the resource file are recorded in the file header; and obtain the corresponding relationship between the relative paths of the resource files in the local compressed package and the local file header offsets according to the relative paths and the local file header offsets recorded in each file header.

[0109] As can be seen, the resource loading device provided by the embodiment of the present invention obtains a resource loading request sent by an application through a request acquisition module; the resource loading request carries a target compressed package identifier and a target relative path; the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file in the local compressed package; the compressed package acquisition module acquires the local compressed package corresponding to the target resource file according to the target compressed package identifier; the signature verification module performs signature verification on the local compressed package; after the signature verification is correct, the decompression module decompresses the target resource file from the local compressed package according to the target relative path; the data return module returns the target resource file to the application so that the application can load the target resource file. Based on the target compressed package identifier and the target relative path carried in the obtained resource loading request, the device only needs to decompress the resource file that needs to be loaded from the local compressed package. The resource files that are not temporarily used will not be decompressed. Only when the application loads a certain resource file will that resource file be decompressed. It is not necessary to decompress the entire compressed package at one time, and the decompressed resource file is data that has passed the compressed package signature verification. Therefore, it can achieve the on-demand and secure loading of resource files, with lower memory occupancy and faster resource loading speed.

[0110] Please refer to Figure 9 , which is a block diagram of an electronic device 700 provided by an embodiment of the present invention. The electronic device 700 includes a memory 710, a processor 720, and a communication module 730. Each element of the memory 710, the processor 720, and the communication module 730 is directly or indirectly electrically connected to each other to achieve data transmission or interaction. For example, these elements can be electrically connected to each other through one or more communication buses or signal lines.

[0111] Among them, the memory 710 is used to store programs or data. The memory 710 can be, but is not limited to, a random access memory (RAM), a read only memory (ROM), a programmable read only memory (PROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), etc.

[0112] The processor 720 is used to read / write the data or programs stored in the memory 710 and perform corresponding functions. For example, when the computer program stored in the memory 710 is executed by the processor 720, the resource loading methods disclosed in the above embodiments can be implemented.

[0113] The communication module 730 is used to establish a communication connection between the electronic device 700 and other communication terminals through a network, and is used to transmit and receive data through the network.

[0114] It should be understood that Figure 9 The structure shown is only a schematic diagram of the structure of the electronic device 700. The electronic device 700 may also include more or fewer components than those Figure 9 shown, or have a different configuration from that Figure 9 shown. Figure 9 Each component shown can be implemented by hardware, software, or a combination thereof.

[0115] An embodiment of the present invention also provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by the processor 720, the resource loading methods disclosed in the above embodiments are implemented.

[0116] In several embodiments provided by the present application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions, and operations of devices, methods, and computer program products according to multiple embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code, and the module, program segment, or part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order from that marked in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0117] In addition, in each embodiment of the present invention, the various functional modules may be integrated together to form an independent part, or each module may exist alone, or two or more modules may be integrated to form an independent part.

[0118] When the above-mentioned functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs.

[0119] The above are only the preferred embodiments of the present invention and are not used to limit the present invention. For those skilled in the art, the present invention can have various changes and modifications. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A resource loading method, characterized in that, The method includes: Obtaining a resource loading request sent by an application; the resource loading request carries a target compressed package identifier and a target relative path; the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file within the local compressed package; Obtaining the local compressed package corresponding to the target resource file according to the target compressed package identifier; Performing signature verification on the local compressed package; After the signature verification is correct, decompressing the target resource file from the local compressed package according to the target relative path; decompressing the target resource file from the local compressed package according to the target relative path includes: determining the local file header offset corresponding to the target relative path according to the correspondence between the relative paths of the resource files in the local compressed package and the local file header offsets; obtaining the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path; decompressing the target compressed data to obtain the target resource file; Returning the target resource file to the application so that the application can load the target resource file.

2. The method according to claim 1, wherein The obtaining the local compressed package corresponding to the target resource file according to the target compressed package identifier includes: Determining the local storage path of the local compressed package corresponding to the target resource file according to the target compressed package identifier and the preset local path of the compressed package; Obtaining the local compressed package according to the local storage path.

3. The method according to claim 1, characterized in that, The obtaining the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path includes: Obtaining the local file header of the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path; the local file header of the target compressed data records the size of the compressed data; Obtaining the target compressed data corresponding to the target resource file according to the local file header of the target compressed data and the size of the compressed data.

4. The method according to claim 1, wherein Before determining the local file header offset corresponding to the target relative path according to the correspondence between the relative paths of the resource files in the local compressed package and the local file header offsets, the method further includes: Traversing all the file headers in the central directory of the local compressed package; each resource file in the local compressed package corresponds to a file header, and the relative path and local file header offset corresponding to the resource file are recorded in the file header; Obtaining the correspondence between the relative paths of the resource files in the local compressed package and the local file header offsets according to the relative paths and local file header offsets recorded in each file header.

5. The method according to claim 1, wherein The obtaining the resource loading request sent by the application includes: Intercepting the resource loading request when the resource loading request sent by the application meets the preset interception conditions.

6. A resource loading device, characterized in that, The device includes: A request acquisition module, configured to acquire a resource loading request sent by an application; the resource loading request carries a target compressed package identifier and a target relative path; the target compressed package identifier is the identifier of the local compressed package corresponding to the target resource file to be loaded, and the target relative path is the relative path of the target compressed data corresponding to the target resource file within the local compressed package; A compressed package acquisition module, configured to acquire the local compressed package corresponding to the target resource file according to the target compressed package identifier; A signature verification module, configured to perform signature verification on the local compressed package; An extraction module, configured to extract the target resource file from the local compressed package according to the target relative path after the signature verification is correct; the extraction module is configured to determine the local file header offset corresponding to the target relative path according to the correspondence between the relative paths of the resource files in the local compressed package and the local file header offsets; acquire the target compressed data corresponding to the target resource file from the local compressed package according to the local file header offset corresponding to the target relative path; and extract the target compressed data to obtain the target resource file; A data return module, configured to return the target resource file to the application so that the application can load the target resource file.

7. An electronic device, characterized in that, It includes a processor, a memory, and a computer program stored on the memory and executable on the processor. When the computer program is executed by the processor, the steps of the resource loading method according to any one of claims 1-5 are implemented.

8. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, the steps of the resource loading method according to any one of claims 1-5 are implemented.

Images