Patent Description:
Splash screen is a transition page presented to users each time an application is started, usually with the intention of concealing the fact that the startup speed is slow. At present, as the splash screen page can provide the largest display area and the richest display content, it exists as the first advertising space in all major applications. However, because the splash screen page is the first startup screen, the network may not be available yet when a splash screen resource is displayed. Moreover, the richness of the resource also means increase of volume. Therefore, the splash screen resource is usually downloaded and stored in advance, and then displayed when necessary. However, if the resource needs to be encrypted, many problems occur, making it impossible to display the resource quickly and safely.

At present, a main implementation is to deliver a splash screen resource, or display directly an online resource on the day when it needs to be displayed. However, the inventor realized that the first implementation loses the real-time performance and the success rate of display. The users may no longer open the splash screen page the day the resource is downloaded. Although the second implementation can avoid the above problems, it has defects in the fluency of resource display. In severe cases, resource loading may block the use of applications due to network problems. In addition, both implementations involve communication with a server, which takes <NUM> milliseconds or longer. In some blocked scenarios, a client can decide what to do next only after the communication has been completed, which brings user experience problems. If the splash screen resource loading takes too long, it will lead to a delay in entering the applications.

In<CIT>), a method performed by at least one computer processor is provided, the method comprising: obtaining an original file to be encrypted; encrypting header data of the original file to obtain encrypted header data, the header data comprising metadata of the original file; storing the encrypted header data; recording, to correspond to a file identifier of the original file, a first storage path of the encrypted header data; partitioning file data other than the header data in the original file, into segments; storing the segments in a disordered fragment sequence; and recording, to correspond to the file identifier, second storage paths of the segments along with an actual sequence of the segments in the original file.

In<CIT>), a computer system is provided including a processing unit that processes data in response to instructions read from memory. Before being ready for a user to make use of a loaded application, the system initially loads executable instructions from permanent storage (such as a magnetic disc drive) during a loading process. In order to make better use of this time, operation related data (that is data for assisting a user to operate the system) is displayed during the loading process. The operation related data is stored in a user accessible file. Furthermore, the application itself facilitates the user re-configuration of the user accessible file under the control of the processing unit when the processing unit is executing the instructions; it not being necessary to use a third party text editor and navigate through the file structure. Then, during a subsequent instruction loading process, the user re-configured data is read.

In <CIT>), a file multi-cloud storage method and device is provided, a file multi-cloud downloading method and device and a storage medium. The multi-cloud storage method of the file is applied to encryption distributed storage equipment. The file multi-cloud storage method comprises: segmenting an original file to be uploaded to the cloud for storage into a plurality of cascaded sub-files through the encryption distributed storage device, the cascade sub-files being stored in the cloud; then encrypting the cascade sub-files, and uploading the cascade sub-files to the corresponding cloud for storage according to the preset weight, so that any cloud storage provider cannot analyze the original file, and the security of the cloud storage file is improved. Besides, the encryption key and the file splicing rule are stored in the encryption distributed storage device, so that lawbreakers obtaining all the sub-files cannot decrypt and splice the original file, the security of cloud storage data is further improved, and the technical problem that existing cloud storage data is prone to leakage is solved.

In<CIT>), a file encryption and decryption device and file encryption and decryption method are provided. The encryption device comprises: one or more non-transitory computer readable medium configured to store computer-executable instruction; at least one processor to execute the computer-executable instruction to cause: selecting important data in a source file to be encrypted; receiving the important data selected by the selector and encrypting the important data according to a pre-set encryption algorithm; receiving the encrypted important data provided by the encryptor and storing the encrypted important data at a specified first location; a deletion component for deleting the unencrypted important data in the source file; generating encryption information according to the above encryption procedure and storing the encryption information at a specified second location, the encryption information at least including the original location of the important data in the source file.

It should be noted that the foregoing content is not intended to limit the protection scope of the present application.

A main objective of the present application is to provide a method and system of resource encryption and display, a computer program product, and a computer-readable storage medium, so as to ensure secure and efficient display of a splash screen resource without blocking startup of an application.

The method and system of resource encryption and display, the computer program product, and the computer-readable storage medium provided by the embodiments of the present application can ensure the authenticity and validity of the current device time without waiting for synchronization with the server, and ensure that the splash screen resource can be displayed for most users at the first time. Moreover, without a large amount of encryption and decryption operations, the security of splash screen resources is ensured and resource leakage is prevented. Therefore, the embodiments of the present application can ensure secure and efficient display of a splash screen resource without blocking startup of an application.

To make the objectives, technical solutions, and advantages of the present application clearer and more comprehensible, the present application will be further described in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present application, and are not intended to limit the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

It should be noted that the descriptions related to "first", "second", and the like in the embodiments of the present application are merely used for the illustrative purpose, and should not be construed as indicating or implying the relative importance thereof or implicitly indicating the number of technical features indicated. Thus, features defined with "first" and "second" may explicitly or implicitly include at least one of the features. In addition, technical solutions of various embodiments can be combined with each other, but they must be based on the implementation by those of ordinary skill in the art. When a combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of the technical solutions neither exists, nor falls within the protection scope claimed by the present application.

Referring to <FIG> is an architecture diagram of an application environment for implementing various embodiments of the present application. The present application may be applied to an application environment including, but not limited to, a client <NUM>, a server <NUM>, and a network <NUM>.

The client <NUM> is configured to download a resource file from the server <NUM> and perform splitting, encryption, decryption, and display. The client <NUM> may be a terminal device, e.g., a mobile phone, a tablet computer, a personal computer (PC), a portable computer, or a wearable device.

The server <NUM> is configured to provide the client <NUM> with the resource file and a correct time. The server <NUM> may be a computing device, e.g., a rack server, a blade server, a tower server, or a cabinet server, or may be a standalone server or a server cluster composed of a plurality of servers.

The network <NUM> may be a wireless or wired network, e.g., an intranet, the Internet, a global system for mobile communications (GSM), wideband code division multiple access (WCDMA), a <NUM> network, a <NUM> network, a Bluetooth network, or a Wi-Fi network. The server <NUM> and one or more clients <NUM> are communicatively connected over the network <NUM> for data transmission and exchange.

It should be noted that, in the following embodiments, the resource encryption and display solutions of the present application will be described by taking a splash screen resource as an example. However, it should be understood that other resources that have similar characteristics to the splash screen resource, such as any resource that can be downloaded by means of preloading, can be encrypted and displayed using a solution similar to the present application.

<FIG> is a flowchart of a method of resource encryption and display according to a first embodiment of the present application. It may be understood that the flowchart in this method embodiment is not intended to limit an execution sequence of the steps. In this embodiment, the client <NUM> is used as a main execution body for exemplary description.

S200: Perform file splitting and local encryption on a pre-downloaded splash screen resource file.

The splash screen resource file is used to provide loaded content to a splash screen page of an application and is pre-downloaded by the client <NUM> from the server <NUM>. In this embodiment, after the client <NUM> downloads the splash screen resource file, file splitting and local encryption need to be first performed on the splash screen resource file, specifically including operations such as resource hiding (transferring the downloaded splash screen resource file and changing a format), path encryption (recording a hidden path into an encrypted resource management file), file splitting (removing header information), and partial encryption (writing the header information into a corresponding field of the resource management file). The local encryption refers to encrypting at least one component part of the splash screen resource file after the splitting.

For details, refer to <FIG>, which is a detailed schematic flowchart of step S200. It may be understood that the flowchart is not intended to limit an execution sequence of the steps. As required, addition or deletion may also be made to some steps in the flowchart. In this embodiment, step S200 specifically includes the following steps.

S2000: Transfer the downloaded splash screen resource file and change a file format to obtain a hidden file.

When the splash screen resource file corresponding to an application is downloaded from the server <NUM>, the downloaded splash screen resource file is transferred to a specific location for storage, for example, in a random directory of the application that is not subject to automatic cleanup. Then, a suffix to a filename of the splash screen resource file is removed, and the filename is changed to a name with a naming style similar to file names in the directory. For example, file names in most directories are in the base64 format. The splash screen resource file obtained after the transfer and change is the hidden file.

S2002: Record a hidden path corresponding to the hidden file into an encrypted resource management file.

The hidden path is a path for a storage location of the transferred splash screen resource file, i.e., a storage path of the hidden file. After the hidden file is obtained, the hidden path is recorded into a resource management file, which is an encrypted file.

S2004: Split the hidden file into header information and a remaining part.

The hidden file is split according to a preset splitting policy. The splitting policy includes how many parts the hidden file is to be split into, and where to split. In this embodiment, the hidden file is split into two parts: header information and a remaining part. The header information is information of fixed byte length, and the byte length or information content may be pre-configured. The remaining part is content left after the header information is removed from the hidden file.

S2006: Remove the header information from the hidden file, and writing the header information into a corresponding field of the resource management file.

After the hidden file is split, the header information in the hidden file is removed and only the remaining part is kept, and the removed header information is written into the corresponding field of the resource management file. As the resource management file is an encrypted file, the header information is encrypted, i.e., the hidden file (the splash screen resource file) is locally encrypted.

It should be noted that the embodiments of the present application focus on file splitting and local encryption, so as to make the splash screen resource file unrecognizable. The specific number of parts into which the file is split and the specific method of encryption do not affect the encryption effect, and how to split and encrypt the file may depend on an actual scenario and file type. To be specific, in other embodiments, step S200 may alternatively include: transferring the downloaded splash screen resource file and changing a file format to obtain a hidden file; encrypting a hidden path corresponding to the hidden file; splitting the hidden file into a plurality of component parts; and removing at least one component part from the hidden file, and encrypting the removed component part.

For example, it is assumed that the splash screen resource file is a zip file, the file header information (information about start bytes of the file) occupies <NUM> bytes, representing information such as file type and modification time. After the splash screen resource file is transferred and changed to obtain a corresponding hidden file and hidden path, the <NUM>-byte information is used as the header information during file splitting, and the header information is removed from the hidden file. Certainly, the removed component part may alternatively be set to <NUM>-byte information (the file header information plus partial content information, or simply partial content information), or to even more bytes. The header information (or another removed component part) is written into a Content field of the encrypted resource management file, and the hidden path is written into a File field of the resource management file. When the splash screen resource needs to be displayed later, the header information (or another removed component part) corresponding to the part of data in the Content field and the remaining part corresponding to the hidden path in the File field are combined together, and the splash screen resource file can be complete again through splicing. The encryption method may be simple AES (Advanced Encryption Standard) encryption, or a stronger encryption algorithm such as 3DES (Triple Data Encryption Algorithm) encryption.

When the header information and the suffix are lacking and the file path (the hidden path) is not fixed, the splash screen resource file cannot be opened, thus ensuring the security of the splash screen resource. In addition, the embodiment uses local encryption instead of encrypting the entire file, thereby greatly reducing consumption of resources required for encryption. Besides, file splitting and encryption can be implemented with or without a network connection by using the foregoing method.

Referring back to <FIG>, S202 includes calculating a current true time according to a correct time last obtained from the server <NUM> and a device power-on time difference, and determining whether a current device time is reliable according to the true time.

When the application is started and the splash screen resource needs to be displayed, in order to determine the authenticity of the current device time, the client <NUM> needs to compare the current device time with the correct time obtained from the server <NUM>. However, in order to save the time consumption in communicating with the server <NUM> when starting the application, in this embodiment, it can be determined whether the current device time is reliable according to the correct time last obtained from the server <NUM> and the device power-on time difference without a network connection.

The processing method used in this embodiment is based on the usage habit of current users: leaving the device on or started for a long time. When the device has not been restarted since synchronizing with the server <NUM> for a correct time, the current true time can be directly calculated and the splash screen resource can be displayed in this embodiment. When the client <NUM> has been restarted since then, it is necessary to perform determination and calculate the time again when starting.

For details, refer to <FIG>, which is a detailed schematic flowchart of S202. It may be understood that the flowchart is not intended to limit an execution sequence of the steps. As required, addition or deletion may also be made to some steps in the flowchart. In this embodiment, step S202 specifically includes the following steps.

S2020: Determine whether the device has been restarted since the correct time was last obtained from the server <NUM>. If not restarted, step S2022 is to be performed, and if restarted, step S2028 is to be performed.

The client <NUM> may synchronize with the server <NUM> for a correct time serverTime (a server time at synchronization) by communicating with the server <NUM>. Specifically, the correct time may be updated by directly requesting time synchronization with the server <NUM> or by a time stamp returned in another request to the server <NUM>. Moreover, the client <NUM> may directly obtain a current system time systemTime and a device power-on time poweronTime via a system interface. If the obtained device power-on time is very short (lower than a preset value) or shorter than a previously recorded device power-on time, it indicates that the device power-on time has been reset, i.e., the client <NUM> has been restarted.

Then, according to the system time and the device power-on time, a restart time point of the client <NUM> can be obtained, and it is further determined whether the time point is before or after the correct time was last obtained from the server <NUM>, so as to determine whether the client <NUM> has been restarted since the correct time was last obtained from the server <NUM>.

S2022: Calculate the current true time according to the correct time last obtained from the server <NUM> and the device power-on time difference.

The device power-on time difference is a difference between a first power-on time poweronTime1 of the device when the correct time was last obtained from the server <NUM> and a currently obtained second power-on time poweronTime2 of the device. When the client <NUM> has not been restarted since the correct time was last obtained from the server <NUM>, the current true time trueTime can be calculated according to the correct time and the device power-on time difference. The formula for calculating the true time is:<MAT>.

S2024: Compare whether the current system time is equal to the true time. If they are equal, step S2026 is to be performed; and if they are not equal, step S2028 is to be performed.

The client <NUM> may obtain the current system time systemTime via the system interface, and then compare whether the system time is equal to the calculated true time.

S2026: Determine that the current device time is reliable.

Conditions for the client <NUM> to determine that the current device time is reliable are: the device has not been restarted since the correct time was last obtained from the server <NUM>, and systemTime == trueTime. If the above conditions are met, the client <NUM> determines that the current device time is reliable.

S2028: Determine that the current device time is unreliable.

If the calculated true time is not equal to the system time, or the device has been restarted since the correct time was last obtained from the server <NUM> (i.e., the device has not obtained a correct time from the server <NUM> since the restart), the client <NUM> determines that the current device time is unreliable, and it is necessary to obtain a correct time from the server <NUM> again.

In this embodiment, the authenticity of the current device time can be ensured even without a network connection, thus saving time consumed for communicating with the server <NUM> when the application is started, and making a decision in a very short time (e.g., in <NUM> millisecond) to preferentially display the splash screen resource to a trusted device.

If it is determined that the current device time is unreliable, a time synchronization operation is triggered, and the correct time is forcibly re-obtained from the server <NUM> and updated. Later, when the device is not restarted, the above steps may be used to determine whether the current device time is reliable.

In addition, the client <NUM> further randomly records a timeline (including, but not limited to, the correct time, the power-on time of the device, and the system time) in a running process of an application, and when the timeline is found not conform to the normal time rule, sets the current device time to be unreliable, and then re-obtains a correct time from the server <NUM> for update. For example, the recorded system time is <NUM> o'clock, <NUM> o'clock, and <NUM> o'clock. If the next obtained system time is <NUM> o'clock, it indicates that the time has been changed, and the current device time is set to be unreliable.

Referring back to <FIG>, S204 includes, if the current device time is reliable, directly obtaining the splash screen resource file through decryption and splicing, and displaying the splash screen resource file.

When the client <NUM> determines that the current device time is reliable, the splash screen resource file can be directly obtained and displayed without waiting for communication with the server <NUM>.

For details, refer to <FIG>, which is a detailed schematic flowchart of S204. It may be understood that the flowchart is not intended to limit an execution sequence of the steps. As required, addition or deletion may also be made to some steps in the flowchart. In this embodiment, step S204 specifically includes the following steps.

S2040: Decrypt the resource management file to obtain the hidden path and the header information.

As the hidden path and the header information corresponding to the splash screen resource file have previously been written into the encrypted resource management file, the hidden path and the header information can be obtained by decrypting the resource management file.

For example, after the resource management file is decrypted using a decryption method corresponding to the encryption method of the resource management file, the header information can be obtained from the Content field, and the hidden path can be obtained from the File field. When the splash screen resource needs to be displayed later, the header information corresponding to the part of data in the Content field and the remaining part corresponding to the hidden path in the File field are combined together, and the splash screen resource file can be complete again through splicing.

S2042: Obtain the remaining part of the hidden file according to the hidden path.

The hidden path indicates a storage location of the remaining part of the hidden file after the header information is removed, and according to the hidden path, the client <NUM> can find the storage location and obtain the remaining part. For example, according to the hidden path obtained from the File field, the remaining part of the hidden file after the <NUM>-byte header information is removed can be obtained.

S2044: Splice the header information and the remaining part to obtain and display the complete splash screen resource file.

As the splash screen resource file has been previously split into the header information and the remaining part, after the header information and the remaining part are obtained, the complete splash screen resource file can be obtained by splicing the two. Then, the corresponding splash screen resource is displayed to the user on a splash screen page of the currently started application according to the splash screen resource file.

Likewise, as there may be no limitation on the specific number of parts into which the file is split and the specific method of encryption, in other embodiments, step S204 may alternatively include: decrypting the hidden path and the removed component part of the hidden file; obtaining a remaining component part of the hidden file according to the hidden path; and splicing the removed component part and the remaining component part to obtain and display the complete splash screen resource file.

The method of resource encryption and display provided by this embodiment can ensure no leakage of the splash screen resource without needing a large amount of encryption and decryption computing resources; ensure the authenticity of the current device time to the greatest extent without depending on a network, and make a decision on whether to display the splash screen resource to the user without needing to wait for reconfirmation of time from the server, thus ensuring that most normal users can view the display of the splash screen resource at the first time.

<FIG> is a schematic diagram of a hardware architecture of an electronic apparatus <NUM> according to a second embodiment of the present application. In this embodiment, the electronic apparatus <NUM> may include, but is not limited to, a memory <NUM>, a processor <NUM>, and a network interface <NUM> that can be communicatively connected to each other via a system bus. It should be noted that <FIG> shows only the electronic apparatus <NUM> having the components <NUM> to <NUM>, but it should be understood that not all of the illustrated components are required to be implemented, and more or fewer components may be implemented instead. In this embodiment, the electronic apparatus <NUM> may be the client <NUM>.

The memory <NUM> includes at least one type of readable storage medium, and the readable storage medium includes a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disc, etc. In some embodiments, the memory <NUM> may be an internal storage unit of the electronic apparatus <NUM>, such as a hard disk or an internal memory of the electronic apparatus <NUM>. In some other embodiments, the memory <NUM> may alternatively be an external storage device of the electronic apparatus <NUM>, for example, a plug-in type hard disk equipped on the electronic apparatus <NUM>, a smart media card (SMC), a secure digital (SD) card, or a flash card. Certainly, the memory <NUM> may alternatively include both the internal storage unit of the electronic apparatus <NUM> and the external storage device thereof. In this embodiment, the memory <NUM> is generally configured to store an operating system and various types of application software installed on the electronic apparatus <NUM>, such as program code of a system of resource encryption and display <NUM>. In addition, the memory <NUM> may be further configured to temporarily store various types of data that has been output or will be output.

The processor <NUM> may be, in some embodiments, a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chips. The processor <NUM> is generally configured to control overall operations of the electronic apparatus <NUM>. In this embodiment, the processor <NUM> is configured to run the program code stored in the memory <NUM> or process data, for example, to run the system of resource encryption and display <NUM>.

The network interface <NUM> may include a wireless network interface or a wired network interface, and the network interface <NUM> is typically configured to establish a communication connection between the electronic apparatus <NUM> and another electronic device.

<FIG> is a schematic modular diagram of a system of resource encryption and display <NUM> according to a third embodiment of the present application. The system of resource encryption and display <NUM> may be divided into one or more program modules, and the one or more program modules are stored in a storage medium and executed by one or more processors to implement the embodiments of the present application. The program modules mentioned in this embodiment of the present application refer to a series of computer-readable instruction segments that can complete specific functions. Functions of various program modules in this embodiment will be specifically described below.

In this embodiment, the system of resource encryption and display <NUM> includes an encryption module <NUM>, a determination module <NUM>, and a display module <NUM>.

The encryption module <NUM> is configured to perform file splitting and local encryption on a pre-downloaded splash screen resource file.

A specific process of performing file splitting and local encryption on the splash screen resource file by the encryption module <NUM> includes:.

Refer to <FIG> and its related description for specific details of the above process, which will not be repeated herein.

It should be noted that the embodiments of the present application focus on file splitting and local encryption, so as to make the splash screen resource file unrecognizable. The specific number of parts into which the file is split and the specific method of encryption do not affect the encryption effect, and how to split and encrypt the file may depend on an actual scenario and file type. To be specific, in other embodiments, the above process may alternatively include: transferring the downloaded splash screen resource file and changing a file format to obtain a hidden file; encrypting a hidden path corresponding to the hidden file; splitting the hidden file into a plurality of component parts; and removing at least one component part from the hidden file, and encrypting the removed component part.

The determination module <NUM> is configured to calculate a current true time according to a correct time last obtained from a server and a device power-on time difference, and determine whether a current device time is reliable according to the true time.

When the application is started and the splash screen resource needs to be displayed, in order to determine the authenticity of the current device time, the client <NUM> needs to compare the current device time with the correct time obtained from the server <NUM>. However, in order to save the time consumption in communicating with the server <NUM> when starting the application, in this embodiment, it can be determined whether the current device time is reliable according to the correct time last obtained from the server <NUM> and the device power-on time difference without a network connection. A specific process includes:.

The display module <NUM> is configured to, when the current device time is reliable, directly obtain the splash screen resource file through decryption and splicing, and display the splash screen resource file.

When the client <NUM> determines that the current device time is reliable, the splash screen resource file can be directly obtained and displayed without waiting for communication with the server <NUM>. A specific process includes:.

Likewise, as there may be no limitation on the specific number of parts into which the file is split and the specific method of encryption, in other embodiments, the above process may alternatively include: decrypting the hidden path and the removed component part of the hidden file; obtaining a remaining component part of the hidden file according to the hidden path; and splicing the removed component part and the remaining component part to obtain and display the complete splash screen resource file.

The system of resource encryption and display provided by this embodiment can ensure no leakage of the splash screen resource without needing a large amount of encryption and decryption computing resources; ensure the authenticity of the current device time to the greatest extent without depending on a network, and make a decision on whether to display the splash screen resource to the user without needing to wait for reconfirmation of time from the server, thus ensuring that most normal users can view the display of the splash screen resource at the first time.

The present application further provides another implementation, that is, provides a computer-readable storage medium storing computer-readable instructions that may be executed by at least one processor to cause the at least one processor to perform the following steps:
performing file splitting and local encryption on a pre-downloaded splash screen resource file, where the local encryption is encrypting of at least one component part of the resource file; calculating a current true time according to a correct time obtained from a server and a device power-on time difference of a client, and determining whether a current device time is reliable according to the true time; if the current device time is reliable, obtaining the splash screen resource file through decryption and splicing, and displaying the splash screen resource file.

It should be noted that, in this specification, the terms "include", "comprise", or any of their variants are intended to cover a non-exclusive inclusion, so that a process, a method, an article, or an apparatus that includes a series of elements not only includes those elements but also includes other elements that are not expressly listed, or further includes elements inherent to such a process, method, article, or apparatus. In the absence of more restrictions, an element defined by "including a. " does not exclude another same element in a process, method, article, or apparatus that includes the element.

The serial numbers of the foregoing embodiments of the present application are merely for description, and do not represent the superiority or inferiority of the embodiments.

It will be apparent to those skilled in the art that the various modules or steps in the embodiments of the present application can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network formed by a plurality of computing devices. Optionally, they may be implemented by program codes executable by the computing device, such that they may be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described may be performed in a sequence different from the sequence described herein, or they may be respectively fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof may be implemented as a single integrated circuit module. In this way, the embodiments of the present application are not limited to any specific combination of hardware and software.

Claim 1:
A computer-implemented method of resource encryption and display, comprising:
performing (S200) file splitting and local encryption on a pre-downloaded splash screen resource file, wherein the local encryption is encrypting of at least one component part of the pre-downloaded splash screen resource file obtained by performing the file splitting on the pre-downloaded splash screen resource file;
calculating (S202) a current true time according to a correct time obtained from a server and a device power-on time difference of a client, and determining whether a current device time is reliable according to the true time, comprising:
determining (S2020) whether the device has restarted since the correct time was last obtained from the server;
when the device has not restarted, calculating (S2022) the current true time according to the correct time last obtained from the server and the device power-on time difference, wherein the device power-on time difference is a difference between a first power-on time of the device when the correct time was last obtained from the server and a second power-on time of the device that is obtained currently;
comparing (S2024) whether a current system time is equal to the true time; and
determining (S2026) that the current device time is reliable when the system time is equal to the true time; and
when the current device time is reliable, obtaining (S204) the splash screen resource file through decryption and splicing, and displaying the splash screen resource file without waiting for communication with the server.