CN112579072B - Browser packaging method and device, storage medium and terminal - Google Patents

Abstract

The embodiment of the present application discloses a browser packaging method, device, storage medium and terminal. The method comprises: in the process of browser kernel compilation, compressing the generated browser files, which include language files or resource files or dynamic library files, and then packaging the compressed packages of these browser files into a browser data packet. Through the method of the present application, various browser files in the browser are compressed and packaged, thereby reducing the capacity of the browser data packet.

Description

Browser packaging method, device, storage medium and terminal

Technical Field

The present invention relates to the field of computer technology, and in particular to a browser packaging method, device, storage medium and terminal.

Background technique

The files that affect the size of the browser can be roughly divided into three parts: the first is the Java code and the imported public jar package, the second is the resource files used by Java or C language, and the third is the dynamic library file. In the prior art, browser slimming is achieved by reducing the resource files in the package, or by dynamically pulling from the server, or removing some unnecessary functions, reducing the size of the browser data packet through the trimming function, or slimming down by reducing the single size capacity of the resource. In this way, the size of the browser data packet is reduced to a negligible amount while ensuring the browser function. When the browser data packet becomes larger, the user will have a significant speed impact during the upgrade or use process.

Summary of the invention

The embodiments of the present application provide a browser packaging method, device, computer storage medium and terminal, aiming to solve the technical problem of how to reduce the memory of browser data packets in the related art. The technical solution is as follows:

In a first aspect, an embodiment of the present application provides a browser packaging method, the method comprising:

During the browser kernel compilation process, the generated browser file is compressed to generate a compressed package corresponding to the browser file, wherein the browser file includes a first language file or a first resource file or a first dynamic library file;

The compressed package is packaged into a browser data package.

In a second aspect, an embodiment of the present application provides a browser packaging device, the device comprising:

A first compression module, used to compress the generated browser file during the browser kernel compilation process to generate a compressed package corresponding to the browser file, wherein the browser file includes a first language file or a first resource file or a first dynamic library file;

The second compression module is used to pack the compressed package into a browser data package.

In a third aspect, an embodiment of the present application provides a computer storage medium, wherein the computer storage medium has a plurality of instructions, and the instructions are suitable for being loaded by a processor and executing the above-mentioned method steps.

In a fourth aspect, an embodiment of the present application provides a terminal, which may include: a memory and a processor; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the memory and executing the above-mentioned method steps.

The beneficial effects brought by the technical solution provided by the embodiment of the present application include at least:

When the solution of the embodiment of the present application is executed, during the browser kernel compilation process, the generated browser files are compressed, and these browser files include the first language file or the first resource file or the first dynamic library file, and then the compressed packages of these browser files are packaged into the browser data packet. Through the method of the present application, various browser files in the browser are compressed and packaged, reducing the capacity of the browser data packet.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without paying any creative work.

FIG1 is a flow chart of a browser packaging method provided in an embodiment of the present application;

FIG2 is a flow chart of a browser packaging method provided in an embodiment of the present application;

FIG3 is a schematic diagram of the structure of a browser data packet in a browser packaging method provided in an embodiment of the present application;

FIG4 is a schematic diagram of the structure of a browser data packet in a browser packaging method provided in an embodiment of the present application;

FIG5 is a schematic diagram of the structure of a browser packaging device provided in an embodiment of the present application;

FIG6 is a block diagram of a terminal provided in an embodiment of the present application;

7 is a schematic diagram of the structure of an operating system and a user space provided in an embodiment of the present application;

FIG8 is an architecture diagram of the Android operating system in FIG6 .

Detailed ways

In order to make the purpose, features, and advantages of the embodiments of the present application more obvious and understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

The present application is described below in conjunction with specific embodiments.

In the following method embodiments, for the sake of convenience, only the execution subject of each step is introduced and described as the terminal.

Please refer to Figure 1, which is a flowchart of a browser packaging method provided in an embodiment of the present application. As shown in Figure 1, the method in the embodiment of the present application may include the following steps:

S101, during the browser kernel compilation process, compressing the generated browser file to generate a compressed package corresponding to the browser file, where the browser file includes a first language file or a first resource file or a first dynamic library file.

Among them, the browser kernel is also called the rendering engine, which mainly converts the page into a visual image result. Then, the browser rendering engine is a module that can convert HTML (Hyper Text Markup Language)/CSS (Cascading Style Sheets)/JavaScript text and its corresponding resource files into image results. Then, the browser kernel compilation process is the process of the rendering engine converting the corresponding resource files into image results. In the process of converting resource files into image results, the files that ultimately affect the size of the browser data packet may include: Java code files (class*.dex files), Native code files (.so files in the lib directory) and resource files (assets directory, res directory and resources.arsc index table file). Then these files can be divided into three categories: the first dynamic library file, mainly Native code files, that is, .so files in the lib directory; the second is the first resource file, mainly including files in the assets directory, files in the res directory and resources.arsc index table file; the third is the first language file, mainly including Java code files. Then the first language file or the first resource file or the first dynamic library file may be encrypted and compressed respectively to obtain an encrypted and compressed first language file or an encrypted and compressed first resource file or an encrypted and compressed first dynamic library file.

S102, packaging the compressed package into a browser data package.

The browser data packet is an apk (Android application package) file in the Android system, which is an application package file format used by the Android operating system for distributing and installing mobile applications and middleware. If an Android application code wants to run on an Android device, it must first be compiled and then packaged into a file that can be recognized by the Android system before it can be run. The file format that can be recognized and run by the Android system is "apk".

An apk file contains files such as AndroidManifest.xml, assets, class.dex, lib, res, resources.arsc, and META-INF. AndroidManifest.xml is the system manifest file of the Android project, which is used to control global properties such as the name, desktop icon, and access rights of the Android application. In addition, the four major components of the Android application, Activity, Service, BroadcastReceiver, and ContentProvider, also need to be declared and configured in this file. The assets directory is used to store static resource files that need to be packaged into the Android application, such as image resource files, JSON configuration files, channel configuration files, binary data files, and HTML5 offline resource files. class.dex is the executable file of the application, and Android code is packaged in this type of file. The lib directory stores .so files of different ABI types that the application depends on. The res directory stores all the resource files of the application, including image resources, string resources, color resources, and size resources. res and assets are both resource files, but the difference is that the assets directory supports subdirectories of any depth, and the files under this directory will not generate resource IDs. resources.arsc is a resource index table that describes the configuration information of resources with ID values. The META-INF directory mainly stores signature-related information, which is used to verify the integrity of the APK package and ensure the security of the system.

According to some embodiments, based on the encrypted and compressed first language file or the encrypted and compressed first resource file or the encrypted and compressed first dynamic library file obtained in S101, the compressed packages of these browser files may be repackaged into an APK package.

When the solution of the embodiment of the present application is executed, during the browser kernel compilation process, the generated browser files are compressed, and these browser files include the first language file or the first resource file or the first dynamic library file, and then the compressed packages of these browser files are packaged into the browser data packet. Through the method of the present application, various browser files in the browser are compressed and packaged, reducing the capacity of the browser data packet.

Please refer to Figure 2, which is a flowchart of a browser packaging method provided in an embodiment of the present application. As shown in Figure 2, the method in the embodiment of the present application may include the following steps:

S201, during the browser kernel compilation process, if the capacity value of the generated browser file is greater than or equal to the capacity threshold, the browser file is compressed to generate a compressed package corresponding to the browser file.

Among them, the capacity threshold is the capacity threshold set for each browser file. The browser files mainly include three categories, one is the first language file, the second is the first resource file, and the third is the first dynamic library file. The first language file mainly refers to the Java file, that is, the class*.dex file. Then, accordingly, there is a class*.dex file capacity threshold. The first resource file mainly includes files under the assets directory, files under the res directory, and the resources.arsc index table file. Correspondingly, there are file capacity thresholds for the assets directory, file capacity thresholds for the res directory, and resources.arsc index table file capacity thresholds. The first dynamic library file mainly refers to the files under the lib directory, and accordingly, there is a file capacity threshold for the lib directory. The files in the lib directory are mainly .so files. The capacity thresholds of various browser files can be set according to actual applications, and the embodiments of the present application do not impose any restrictions on this.

For various browser files generated, if the capacity value of the first language file is greater than or equal to the corresponding capacity threshold, or the capacity value of the first resource file is greater than or equal to the corresponding capacity threshold, or the capacity value of the first dynamic library file is greater than or equal to the corresponding capacity threshold, the above browser files are compressed, and encryption can also be performed during compression. The first resource file also includes resource files of various types, and each type of resource file is detected to see whether it is greater than or equal to the corresponding capacity threshold. Only resource files of the type whose capacity value is greater than or equal to the capacity threshold are compressed, and the size and name of the compressed resource file are saved.

S202, packaging the compressed package into a browser data package.

Among them, there are multiple directory folders under the browser data packet, as shown in the apk file structure diagram in Figure 3, which mainly include the system manifest file (AndroidManifest.xml), static resource file directory (assets directory), compiled file directory (lib directory), resource file directory (res directory), signature file directory (META-INF directory), executable file (class.dex) and resource index table file (resources.arsc). The contents stored in the above directory files can be seen in step S102 in Figure 1, which will not be repeated here.

Specifically, the compressed package is packaged into the browser data package. At this time, a new apk file is generated. The new apk file can be named colorOS1101.apk. Please refer to the file structure diagram of colorOS1101.apk shown in Figure 4, including the system manifest file compression package (AndroidManifest.xml compression package), static resource folder compression package (assets directory folder compression package), compilation folder compression package (lib directory folder compression package), resource folder compression package (res directory folder compression package), signature folder compression package (META-INF directory folder compression package), executable file compression package (class.dex compression package) and resource index table file compression package (resources.arsc compression package).

S203, after the browser kernel is compiled, a compressed package list file is generated, where the compressed package list file includes first compression information of the compressed package.

The first compression information includes the size and name of the compressed first language file, the size and name of the compressed first resource file, and the size and name of the compressed first dynamic library file. The size and name of the compressed first language file are mainly the size and name of the compressed class.dex file. The size and name of the compressed first resource file mainly include: assets directory folder, res directory folder and resources.arsc file. The compressed sizes and names of the above resource folders, and the size and name of the compressed first dynamic library file mainly include the size and name of the compressed lib directory folder.

S204, during the browser startup process, obtaining second compression information of existing browser files in the browser installation directory, where the existing browser files include a second language file or a second resource file or a second dynamic library file.

S205, obtaining the first compression information from the compression package list file, and determining whether the first compression information is the same as the second compression information.

The second compression information includes the size and name of the compressed second language file, the size and name of the compressed second resource file, and the size and name of the compressed second dynamic library file. The second language file refers to the Java code file in the apk package that already exists in the browser installation directory. The second resource file refers to the assets directory folder, the res folder, and the resources.arsc index table file in the apk package that already exists in the browser installation directory. The second dynamic library file refers to the lib directory folder in the apk package that already exists in the browser installation directory. Steps S204 and S205 are described in detail below.

Generally, the installation directory of the android application is /data/app, so the browser data package, that is, the apk file, is stored in the /data/app directory. If /data/app already has an apk package, this apk package is called colorOS1011.apk, it can be understood that the file structure in this apk package is the same as the file structure of the apk package shown in Figure 4. During the browser startup process, first obtain the second compressed information in the existing colorOS1011.apk from the /data/app directory, then obtain the first compressed information in colorOS1101.apk from the compressed package manifest file, and compare whether the first compressed information and the second compressed information are the same. The comparison here is mainly to compare the size and name of the compressed first language file in the first compressed information with the size and name of the second language file in the second compressed information, compare the size and name of the compressed first resource file in the first compressed information and the size and name of the second resource file in the second compressed information, and compare the size and name of the compressed first dynamic library file in the first compressed information and the size and name of the second dynamic library file.

S206: When the first compression information is different from the second compression information, copy the browser data packet to the browser installation directory.

S207, decompressing the compressed package in the browser data package, and determining whether the decompression is successful.

S208: If the decompression is successful, the browser file is used to replace the existing browser file.

Steps S206-S208 are described in detail below.

Generally, according to the comparison result of S205, when the first compression information is different from the second compression information, it means that the startup process is started by installing a new apk package, and the new apk package colorOS1101.apk will be copied to /data/app, and then the signature of the apk will be verified to be correct, and the structure of the apk will be checked to be normal. Further, each compressed package in the apk package will be decompressed. It should be noted that, from the above content, it can be known that in the process of generating the apk package, it is compressed and packaged. First, each browser file is compressed to obtain a compressed package of each browser file, and second, the compressed package of each browser file is packaged into the apk package. Correspondingly, the decompression process is also to first decompress the apk package to obtain the compressed package of each browser file, and then decompress the compressed package of each browser file to obtain each browser file. In addition, if the above decompression process involves encryption operation, then the corresponding decompression operation will also be performed during decompression.

Among them, in the process of decompressing the apk package to obtain the compressed packages of each browser, the dex file in the apk will be checked. After confirming that the dex file is not damaged, that is, the decompression is successful, the dex will be optimized to odex, which will speed up the startup time of the application. At the same time, a folder with the same name as the apk package will be created in the /data/data directory. If there is a lib library in the apk, the system will determine the name of these so libraries to see whether it starts with lib and ends with .so, and then decompress the corresponding so library to /data/data/packagename/lib according to the CPU architecture.

S209: Use the first compressed information as second compressed information of the existing browser file in the browser installation directory.

After obtaining the initial browser files, the second compression information is replaced with the first compression information accordingly. Since the browser is currently installing a new apk package for startup, the browser files used in the startup process are different from the browser files used last time. Correspondingly, the compression information of the corresponding compressed packages of the browser files used in this startup process is different from the compression information of the corresponding compressed packages of the browser files used in the last run. Therefore, the first compression information used for this startup needs to be used as the second compression information of the existing browser file.

S210: If the decompression fails, continue to use the existing browser files in the browser installation directory.

According to some embodiments, when decompressing the apk package to obtain the browser files, the decompression failure may occur. It may be that the compressed package of the browser files obtained by decompressing the apk package fails to be decompressed, or it may be that the compressed package of the browser files is successfully obtained, and the decompression failure occurs when the compressed package of the browser files is decompressed to obtain the browser files. Then, regardless of which of the above decompression failures occurs, the existing browser files in the browser installation directory can continue to be used, that is, the existing browser files used by the browser in the last running process, that is, the browser files in the apk package used in the last running process.

S211, when all compressed packages are decompressed, the kernel loader is started, the browser file or the existing browser file is loaded, and the browser kernel initialization operation is performed.

Generally, after all compressed packages are successfully decompressed, the kernel loader is started to load all browser files, and the browser kernel initialization operation is performed based on the browser files. In the case that all compressed packages are not successfully decompressed, including the case that some are successfully decompressed, some are failed to be decompressed, or all are failed to be decompressed, the existing browser files are loaded, and the browser kernel initialization operation is performed based on the existing browser files.

S212: When the first compression information is identical to the second compression information, a kernel loader is started to load the existing browser file and perform a browser kernel initialization operation.

Generally, according to the comparison result of S205, when the first compressed information is the same as the second compressed information, it means that the startup process does not install a new apk package to start, but uses the previous apk package to start, that is, it is started based on the apk package used in the previous operation. It can be understood that the steps of the embodiment of the present application are a continuous process. After each new apk package is installed, the old apk package will be replaced by the new apk package. In the next startup process, the new apk package used in this startup becomes the existing apk package. When starting based on the existing apk, it will verify whether the signature of the apk is correct and whether the structure of the apk is normal. Further, the compressed packages in the apk package are decompressed. It should be noted that in the process of generating the apk package, it is compressed and packaged. First, each browser file is compressed to obtain the compressed package of each browser file, and second, the compressed package of each browser file is packaged into the apk package. Correspondingly, the decompression process is also to first decompress the apk package to obtain the compressed package of each browser file, and then decompress the compressed package of each browser file to obtain each browser file. In addition, if the above decompression process involves encryption operations, corresponding decompression operations will also be performed during decompression.

Among them, in the process of decompressing the apk package to obtain the compressed packages of each browser, the dex file in the apk will be checked. After confirming that the dex file is not damaged, that is, the decompression is successful, the dex will be optimized to odex, which will speed up the startup time of the application. At the same time, a folder with the same name as the apk package will be created in the /data/data directory. If there is a lib library in the apk, the system will determine the name of these so libraries to see whether it starts with lib and ends with .so, and then decompress the corresponding so library to /data/data/packagename/lib according to the CPU architecture.

When the scheme of the embodiment of the present application is executed, during the browser kernel compilation process, it is first determined whether the capacity value of the generated browser file is greater than or equal to the capacity threshold. If so, the browser file is compressed, a compressed package corresponding to the browser file is generated, and the compressed package is packaged into the browser data package. After the browser kernel compilation is completed, a compressed package list file is generated, and the compressed package list file includes the first compression information of the compressed package. Further, during the browser startup process, the second compression information of the existing browser file in the browser installation directory is obtained, and it is determined whether the first compression information and the second compression information are the same. If the two are different, the browser file is updated based on the newly generated browser data package to complete the browser startup process; if the two are the same, the existing browser data package is used to complete the browser startup process. Through the method of the present application, when the capacity value of the browser file in the browser exceeds the capacity threshold, each browser file is first compressed, which can ensure that when the capacity of each browser file is too large, and before each browser file is packaged into the apk package, the capacity of each browser file is reduced. Furthermore, the compressed packages of the browser files are packaged into the apk package, which further reduces the capacity of the browser apk package, and thus the upgrade success rate of the browser can be further improved, making the improvement of the upgrade success rate of the browser more obvious.

Please refer to FIG5, which is a schematic diagram of the structure of a browser packaging device provided in an embodiment of the present application. The browser packaging device 500 can be implemented as all or part of a server through software, hardware, or a combination of both. The device 500 includes:

The first compression module 510 is used to compress the generated browser file during the browser kernel compilation process to generate a compressed package corresponding to the browser file, wherein the browser file includes a first language file or a first resource file or a first dynamic library file;

A second compression module 520, used for packaging the compressed package into a browser data package;

Optionally, the apparatus 500 further includes:

An upgrade module is used to upgrade the browser based on the browser data packet during the browser startup process.

Optionally, the first compression module 510 includes:

A capacity detection unit, used to determine whether the capacity value of the generated browser file is greater than or equal to a capacity threshold;

The resource compression unit is used to compress the browser file and generate a compression package corresponding to the browser file when the capacity value of the browser file is greater than or equal to the capacity threshold.

Optionally, the apparatus 500 further includes:

A compressed package manifest file generating unit, configured to generate a compressed package manifest file after the browser kernel is compiled, wherein the compressed package manifest file includes first compression information of the compressed package;

An upgrading unit is used to upgrade the browser based on the browser data packet and the compressed package manifest file during the browser startup process.

Optionally, the upgrade unit includes:

A first upgrading unit, configured to obtain second compressed information of existing browser files in the browser installation directory, wherein the existing browser files include a second language file or a second resource file or a second dynamic library file;

A second upgrading unit, configured to obtain the first compression information from the compression package list file;

A third upgrading unit, configured to copy the browser data packet to the browser installation directory when the first compression information is different from the second compression information;

The fourth upgrading unit is used to decompress the compressed package in the browser data package, and if the decompression is successful, use the browser file to replace the existing browser file.

Optionally, the upgrading unit further includes:

The fifth unit is used to use the first compressed information as the second compressed information of the existing browser file in the browser installation directory.

Optionally, the upgrading unit further includes:

The sixth unit is used for continuing to use the existing browser file in the browser installation directory when the decompression fails.

Optionally, the upgrading unit further includes:

The seventh unit is used to start the kernel loader after all the compressed packages are decompressed, load each of the browser files and/or the existing browser files, and perform the browser kernel initialization operation.

Optionally, the upgrading unit further includes:

The eighth unit is used to start a kernel loader, load the existing browser file, and perform a browser kernel initialization operation when the first compression information is the same as the second compression information.

When the solution of the embodiment of the present application is executed, during the browser kernel compilation process, the generated browser files are compressed, and these browser files include the first language file or the first resource file or the first dynamic library file, and then the compressed packages of these browser files are packaged into the browser data packet. Through the method of the present application, various browser files in the browser are compressed and packaged, reducing the capacity of the browser data packet.

Please refer to Figure 6, which shows a block diagram of a terminal provided by an exemplary embodiment of the present application. The terminal in the present application may include one or more of the following components: a processor 610, a memory 620, an input device 630, an output device 640, and a bus 650. The processor 610, the memory 620, the input device 630, and the output device 640 may be connected via a bus 650.

The processor 610 may include one or more processing cores. The processor 610 uses various interfaces and lines to connect various parts of the entire terminal, and executes various functions of the terminal and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 620, and calling data stored in the memory 620. Optionally, the processor 610 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 110 can integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 610, but may be implemented separately through a communication chip.

The memory 620 may include a random access memory (RAM) or a read-only memory (ROM). Optionally, the memory 620 includes a non-transitory computer-readable storage medium. The memory 620 may be used to store instructions, programs, codes, code sets or instruction sets. The memory 620 may include a storage program area and a storage data area, wherein the storage program area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the following various method embodiments, etc. The operating system may be an Android system (including a system deeply developed based on the Android system) or other systems. The storage data area may also store data (such as a phone book, audio and video data, chat record data) created by the terminal during use.

As shown in FIG. 7 , the memory 620 can be divided into an operating system space and a user space. The operating system runs in the operating system space, and native and third-party applications run in the user space. In order to ensure that different third-party applications can achieve good operating results, the operating system allocates corresponding system resources to different third-party applications. However, different application scenarios in the same third-party application also have different requirements for system resources. For example, in the local resource loading scenario, the third-party application has higher requirements for disk reading speed; in the animation rendering scenario, the third-party application has higher requirements for GPU performance. The operating system and the third-party application are independent of each other, and the operating system often cannot perceive the current application scenario of the third-party application in a timely manner, resulting in the operating system being unable to perform targeted system resource adaptation according to the specific application scenario of the third-party application.

In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to open up data communication between third-party applications and the operating system so that the operating system can obtain the current scenario information of third-party applications at any time, and then perform targeted system resource adaptation based on the current scenario.

Taking the operating system as the Android system as an example, the programs and data stored in the memory 620 are shown in Figure 8. The memory 620 may store a Linux kernel layer 820, a system runtime library layer 840, an application framework layer 860, and an application layer 880, wherein the Linux kernel layer 820, the system runtime library layer 840, and the application framework layer 860 belong to the operating system space, and the application layer 880 belongs to the user space. The Linux kernel layer 820 provides underlying drivers for various hardware of the terminal, such as display drivers, audio drivers, camera drivers, Bluetooth drivers, Wi-Fi drivers, power management, etc. The system runtime library layer 840 provides the main feature support for the Android system through some C/C++ libraries. For example, the SQLite library provides database support, the OpenGL/ES library provides 3D drawing support, and the Webkit library provides browser kernel support, etc. The Android runtime library (Android runtime) is also provided in the system runtime library layer 840, which mainly provides some core libraries that allow developers to use the Java language to write Android applications. The application framework layer 860 provides various APIs that may be used when building applications. Developers can also use these APIs to build their own applications, such as activity management, window management, view management, notification management, content provider, package management, call management, resource management, and location management. At least one application runs in the application layer 880. These applications can be native applications that come with the operating system, such as contact applications, text messaging applications, clock applications, camera applications, etc.; they can also be third-party applications developed by third-party developers, such as game applications, instant messaging applications, photo beautification applications, shopping applications, etc.

Among them, the input device 630 is used to receive input instructions or data, and the input device 630 includes but is not limited to a keyboard, a mouse, a camera, a microphone or a touch device. The output device 640 is used to output instructions or data, and the output device 640 includes but is not limited to a display device and a speaker. In one example, the input device 630 and the output device 640 can be combined, and the input device 630 and the output device 640 are a touch display screen, which is used to receive touch operations on or near it by a user using any suitable object such as a finger or a touch pen, and to display the user interface of each application. The touch display screen is usually set on the front panel of the terminal. The touch display screen can be designed as a full screen, a curved screen or a special-shaped screen. The touch display screen can also be designed as a combination of a full screen and a curved screen, or a combination of a special-shaped screen and a curved screen, which is not limited in the embodiments of the present application.

In addition, those skilled in the art will appreciate that the structure of the terminal shown in the above drawings does not constitute a limitation on the terminal, and the terminal may include more or fewer components than shown, or combine certain components, or arrange the components differently. For example, the terminal also includes a radio frequency circuit, an input unit, a sensor, an audio circuit, a wireless fidelity (WiFi) module, a power supply, a Bluetooth module, and other components, which will not be described in detail here.

In the embodiment of the present application, the execution subject of each step may be the terminal described above. Optionally, the execution subject of each step is the operating system of the terminal. The operating system may be an Android system, or other operating systems, which is not limited in the embodiment of the present application.

The terminal of the embodiment of the present application may also be equipped with a display device, which may be any device capable of realizing a display function, such as a cathode ray tube display (CR), a light-emitting diode display (LED), an electronic ink screen, a liquid crystal display (LCD), a plasma display panel (PDP), etc. The user may use the display device on the terminal 601 to view displayed text, images, videos and other information. The terminal may be a smart phone, a tablet computer, a gaming device, an AR (Augmented Reality) device, a car, a data storage device, an audio playback device, a video playback device, a notebook, a desktop computing device, a wearable device such as an electronic watch, an electronic glasses, an electronic helmet, an electronic bracelet, an electronic necklace, electronic clothing and other devices.

In the terminal shown in FIG. 6 , the processor 610 may be used to call an application program stored in the memory 620 and specifically execute the browser packaging method of the embodiment of the present application.

In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional module in each embodiment of the present application can be integrated into a processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The above integrated modules can be implemented in the form of hardware or software functional modules.

If the integrated module is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of each embodiment method of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.

It should be noted that, for the convenience of description, the aforementioned method embodiments are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described action sequence, because according to the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

The above is a description of a browser packaging method, device, storage medium and terminal provided by the present application. For technicians in this field, according to the ideas of the embodiments of the present application, there may be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as limiting the present application.

The embodiment of the present application also provides a computer storage medium, which can store multiple instructions, and the instructions are suitable for being loaded by a processor and executing the method steps as described above. The specific execution process can be found in the specific description of the embodiments shown in Figures 1 and 2, and will not be repeated here.

Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing related hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the processes of the embodiments of the above-mentioned methods. The storage medium can be a disk, an optical disk, a read-only storage memory, or a random access memory, etc.

The above disclosure is only the preferred embodiment of the present application, which certainly cannot be used to limit the scope of rights of the present application. Therefore, equivalent changes made according to the claims of the present application are still within the scope covered by the present application.

Claims (9)

1. A method for packaging a browser, the method comprising:

In the compiling process of a browser kernel, compressing the generated browser file to generate a compressed package corresponding to the browser file, wherein the browser file comprises a first language file or a first resource file or a first dynamic library file;

Packaging the compressed packet into a browser data packet;

after the browser kernel is compiled, generating a compressed package list file, wherein the compressed package list file comprises first compressed information of the compressed package;

in the process of starting the browser, upgrading the browser based on the browser data packet and the compressed packet list file;

wherein, in the process of starting the browser, upgrading the browser based on the browser data packet and the compressed packet manifest file includes:

Acquiring second compressed information of an existing browser file under the browser installation directory, wherein the existing browser file comprises a second language file or a second resource file or a second dynamic library file;

Copying the browser data packet to the browser installation directory when the first compressed information is different from the second compressed information;

and decompressing the compressed package in the browser data package, and if the decompression is successful, replacing the existing browser file with the browser file.

2. The method of claim 1, wherein the compressing the generated browser file to generate the compressed package corresponding to the browser file includes:

Judging whether the capacity value of the generated browser file is larger than or equal to a capacity threshold value;

If yes, compressing the browser file to generate a compressed package corresponding to the browser file.

3. The method according to claim 1, wherein the method further comprises:

And taking the first compressed information as second compressed information of the existing browser file under the browser installation directory.

4. The method according to claim 1, wherein the method further comprises:

If decompression fails, continuing to use the existing browser file under the browser installation directory.

5. The method according to claim 3 or 4, characterized in that the method further comprises:

And after the decompression of all the compression packets is completed, starting a kernel loader, loading the browser file or the existing browser file, and executing the initialization operation of the browser kernel.

6. The method according to claim 1, wherein the method further comprises:

And when the first compressed information is the same as the second compressed information, starting a kernel loader, loading the existing browser file, and executing the initialization operation of the browser kernel.

7. A browser packaging apparatus, the apparatus comprising:

The first compression module is used for compressing the generated browser file in the compiling process of the browser kernel to generate a compression package corresponding to the browser file, wherein the browser file comprises a first language file or a first resource file or a first dynamic library file;

The second compression module is used for packaging the compression packet into a browser data packet;

the browser kernel compiling unit is used for compiling the browser kernel according to the first compression information of the compression package;

the updating unit is used for updating the browser based on the browser data packet and the compressed packet list file in the starting process of the browser;

wherein, the upgrading unit includes:

the first upgrading unit is used for obtaining second compressed information of an existing browser file under the browser installation directory, wherein the existing browser file comprises a second language file or a second resource file or a second dynamic library file;

The third upgrading unit is used for copying the browser data packet to the browser installation catalog when the first compressed information is different from the second compressed information;

And the fourth upgrading unit is used for decompressing the compressed package in the browser data package, and if the decompression is successful, replacing the existing browser file with the browser file.

8. A computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the method steps of any one of claims 1 to 6.

9. A terminal, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the method steps of any of claims 1-6.