A package library updating method, device and equipment

Abstract

The embodiments of this specification disclose a package library update method, apparatus, and device. This method detects whether a configuration file for a second package exists in the application; if so, obtains the second package corresponding to the configuration file and loads the second package; otherwise, detects whether a built-in second package exists in the package library; if so, loads the built-in second package; otherwise, loads the first package, where the second package is an upgraded version of the first package. This eliminates the need for code intrusion into the service, i.e., switching between loading the second package or the first package is achieved when the application starts.

Description

Technical Field

[0001] This specification relates to the field of Internet technology, and in particular to a package library update method, device, and equipment. Background Art

[0002] For large client applications, APPs generally contain several large package libraries. Large package codes involve too many aspects, and every code adjustment may introduce risks. A slight mistake may cause a large-scale online crash. Even if grayscale updates are adopted, frequent releases will still cause problems.

[0003] Based on this, a more convenient package library update solution is needed. Summary of the Invention

[0004] One or more embodiments of this specification provide a package library update method, apparatus, device, and storage medium to solve the following technical problem: a more convenient package library update solution is needed.

[0005] To solve the above technical problems, one or more embodiments of this specification are implemented as follows:

[0006] In a first aspect, one or more embodiments of the present specification provide a method for updating a package library, which is used when an application is started, including: detecting whether there is a configuration file of a second package package in the application; if so, obtaining the second package package corresponding to the configuration file and loading the second package package; otherwise, detecting whether there is a built-in second package package in the package library; if so, loading the built-in second package package; if not, loading the first package package, wherein the second package package is an upgraded version of the first package package.

[0007] In a second aspect, one or more embodiments of the present specification provide a device for updating a package library, which is used when an application is started. The device includes: a detection module for detecting whether there is a configuration file of a second package package in the application; an acquisition module for acquiring the second package package corresponding to the configuration file when the configuration file exists, and a loading module for loading the second package package; otherwise, the detection module detects whether there is a built-in second package package in the package library; when the second package package exists, the loading module loads the built-in second package package; when the second package package does not exist, the loading module loads the first package package, wherein the second package package is an upgraded version of the first package package.

[0008] In a third aspect, an embodiment of this specification provides an electronic device, including:

[0009] at least one processor; and,

[0010] a memory communicatively connected to the at least one processor; wherein,

[0011] The memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the method according to the first aspect.

[0012] In a fourth aspect, an embodiment of this specification provides a non-volatile computer storage medium storing computer-executable instructions. When a computer reads the computer-executable instructions in the storage medium, the instructions enable one or more processors to execute the method described in the first aspect.

[0013] At least one of the above technical solutions adopted in one or more embodiments of this specification can achieve the following beneficial effects: by detecting whether a configuration file of the second encapsulation package exists in the application; if so, obtaining the second encapsulation package corresponding to the configuration file and loading the second encapsulation package; otherwise, detecting whether a built-in second encapsulation package exists in the encapsulation library; if so, loading the built-in second encapsulation package; otherwise, loading the first encapsulation package, wherein the second encapsulation package is an upgraded version of the first encapsulation package. This eliminates the need for code intrusion into the service, i.e., switching between loading the second encapsulation package or the first encapsulation package when the application is started, thereby avoiding possible application crashes during the upgrade process and achieving user-unaware updates to the encapsulation library, which is more convenient. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0015] Figure 1 A schematic diagram of a flow chart of a package library update method provided in an embodiment of this specification;

[0016] Figure 2 A schematic diagram of a specific loading process provided in an embodiment of this specification;

[0017] Figure 3 A schematic diagram of loading a second package provided in an embodiment of this specification;

[0018] Figure 4 A package library update device provided in an embodiment of this specification;

[0019] Figure 5This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0020] The embodiments of this specification provide a package library update method, apparatus, device, and storage medium.

[0021] In order to help those skilled in the art better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0022] In large-scale comprehensive application clients (such as payment-type comprehensive application client applications or communication-type comprehensive application clients), several large encapsulation libraries are generally included. An encapsulation library refers to a small code library (Library) formed by encapsulating the business or technical implementation for a specific scenario in an application. The code library usually contains code resources (Class), dynamic link libraries (So), resources (Resource), and other contents. Since the encapsulation library covers a wide range of codes, grayscale updates are used immediately, which will cause frequent version releases. Based on this, the embodiments of this specification provide a more convenient update solution for the encapsulation library.

[0023] In the first aspect, Figure 1 As shown, Figure 1 This is a flow chart of a method for updating a package library provided in an embodiment of this specification, which is used when an application is started. The flow includes:

[0024] S101: Detect whether there is a configuration file of a second packaging package in the application.

[0025] First, it should be noted that at least the first package already exists in the application. The first package is a stable version of the currently used package library. The second package, as an upgraded version of the first package, may be located locally on the device where the application is located or on the server side.

[0026] Usually, when performing a grayscale upgrade (i.e., for some applications, the first package package they use needs to be upgraded to the second package package), the corresponding second package package configuration file will first be published to the device where the application is located. The configuration file is used to indicate how to obtain the second package package and how to load the second package package.

[0027] S103: If the configuration file exists, obtain the second package corresponding to the configuration file, and load the second package.

[0028] If there is a configuration file of the second package locally, the second package can be obtained and loaded based on the instruction of the configuration file.

[0029] Specifically, a locally available, non-built-in second package can be obtained according to the local path indicated by the configuration file. Furthermore, before loading, a check can be performed to determine whether the second package corresponding to the download path indicated by the configuration file has a higher version number. If so, the second package with the higher version number can be downloaded and loaded. Alternatively, the second package can be downloaded from the server according to the download path indicated by the configuration file.

[0030] In the embodiments of this specification, a built-in package refers to a second package package that has been packaged into the package library, and a non-built-in package refers to a second package package that has not been packaged into the package library.

[0031] S105: Otherwise, check whether there is a built-in second packaging package in the packaging library.

[0032] When the configuration file of the second package does not exist locally, either the second package has been packaged into the package library, or the second package does not exist locally (i.e., the user may not be the target of the grayscale upgrade). In this case, you can check whether there is a built-in second package locally.

[0033] In the embodiments of this specification, a built-in second package refers to a second package that has been compressed into the package library. This built-in second package is independent of the aforementioned configuration file. Typically, after a second package has been confirmed to be stable, it can be compressed into the package library. Specifically, a designated field can be used within the package library to indicate whether the library has a built-in second package.

[0034] S107: If the second package exists, load the built-in second package; if the second package does not exist, load the first package.

[0035] If there is a built-in second package, then the built-in second package is loaded. If not, then the first package is loaded directly.

[0036] This approach detects whether a configuration file for a second package exists in the application; if so, obtains the second package corresponding to the configuration file and loads it; otherwise, it detects whether a built-in second package exists in the package library; if so, loads the built-in second package; otherwise, it loads the first package, where the second package is an upgraded version of the first. This eliminates the need for code intrusion into the service, enabling switching between loading the second package and the first package at application startup. This avoids potential application crashes during the upgrade process while enabling user-imperceptible updates to the package library, making it more convenient.

[0037] In one embodiment, when a local configuration file exists and the second package is downloaded from the server based on the configuration file, the configuration file needs to be updated. For example, the path of the second package in the configuration file is modified to the local path of the downloaded second package. Thus, the next time the application is started, the downloaded second package can be obtained and loaded based on the local path indicated in the configuration file.

[0038] In one embodiment, when a problem occurs during the loading process of the second package, or when a problem occurs during the actual operation of the second package, the process of enabling the first package will be followed. Specifically, the content of the loaded second package is cleared, and after the clearing is completed, the first package is loaded. At the same time, the results of the loading and switching process of the first package and the second package can also be reported to the cloud, and the cloud can perform real-time monitoring and evaluation based on this data. Figure 2 As shown, Figure 2 This is a schematic diagram of a specific loading process provided in an embodiment of this specification.

[0039] As previously mentioned, the second package includes content such as code resources (Class), dynamic link libraries (.so files), and resources (Resources). Since the local first package also contains the aforementioned content, to ensure that the content in the second package can be loaded, the embodiments of this specification also provide more specific loading methods for the aforementioned code resources (Class), dynamic link libraries (.so files), and resources (Resources).

[0040] Specifically, when loading the code resources in the second package, the code resources are converted into a usable loading object (DexFile) that can be recognized by the application, and then loaded according to the system class loader structure and mechanism.

[0041] For example, first obtain the list of available load objects of the application (usually a DexPathlist file, which stores dexfile and is loaded by traversing the DexPathlist file during loading), then put the available load objects converted from the code resources in the second package into the head of the list, and load the list of available load objects to load the code resources in the second package. Since the list searches for available load objects from the head when it is loaded, once the search is successful, the search ends and loading begins. Therefore, this method can ensure that the code resources in the second package will be loaded first.

[0042] Furthermore, in one embodiment, when placing the code resources in the second package into the head of the list, the following method can be adopted: the code resources in the second package are converted into an executable file object (i.e., dexfile), and an array corresponding to the list and the executable file object is generated at the same time, the size of the array being the sum of the size of the available loading objects contained in the list and the size of the executable file object converted from the code resources. Then, the executable file object converted from the code resources is placed into the head of the array, and the list is stored into the tail of the array. In this way, it is also compatible with the loading methods of system class loaders of different versions of the Android system, thereby improving versatility.

[0043] In one embodiment, when loading resources in the second package (resource objects may include static resources such as images and animations), since the first package coexists in the application, and the resources in both the first and second packages use product part identification (PPID) to identify the package to which the resources belong, to avoid the pain of calling resources, the resource package identification of the resources in the second package is different from the resource package identification of the resources in the package library.

[0044] For example, the resource package identifier of the resources in the second package can be modified to a non-default value through compilation. Also, there may be some resources that may have been occupied in the system, so the resource package identifier of the resources in the second package can be modified to a non-default value or a non-occupied value. Specifically, the system default resource PPID is 0x7f, and the occupied PPID values ​​are from 0001 to 000A. The resource package identifier of the resources in the second package can be modified to a non-default value or a non-occupied value: such as 0x5f, 0x6e, etc. By pre-compilation, resource loading conflicts can be avoided.

[0045] Furthermore, the resources in the second package can be inserted into the resource object to be loaded. For example, the AssetManager instance can be obtained through the object of the resources of the current page, and then the addAssetPath method can be reflected to insert the resources in the second package into the object of the resources of the current page.

[0046] In actual applications, in order to achieve immediate effect of resource insertion, the getResource methods of Activity, Service, etc. can be pre-compiled, and customized resource acquisition processing code can be dynamically inserted into them. The resource acquisition processing code can be used to insert the resources in the second package into the resource object to be loaded, so that the insertion is seamless for the user and the user experience is improved.

[0047] In one embodiment, the dynamic link library (so file) in the second package can be loaded by obtaining the address of the dynamic link library in the second package; and loading the dynamic link library in the second package according to the address.

[0048] Specifically, the address of the dynamic link library in the second package can be obtained in the following ways: first, obtaining the address of the dynamic link library in the second package from the download or / decompression path of the second package; or, when the first loading method fails, obtaining the address of the dynamic link library in the second package from the default loading path in the operating system of the device where the package library is located, for example, recording it from the default loading path through System.loadLibrary; or, when both the first and second loading methods fail, the address of the dynamic link library can be generated and recorded by splicing the default universal directory name and the file name of the dynamic link library, for example, by splicing the default universal directory name Context#nativeLibraryDir and the file name of the dynamic link library mapLibraryName to form a new so file path, and then trying to load the file indicated by the spliced ​​path again through System.load. In this way, it is compatible with the loading methods of different devices and different systems, thereby improving adaptability.

[0049] like Figure 3 As shown, Figure 3 This is a schematic diagram of loading a second package provided by an embodiment of this specification. Through the aforementioned loading methods such as code resources (Class), dynamic link libraries (so files), and resources (Resource) for the second package, the content of the second package can be loaded at the top of the loading process.

[0050] In one embodiment, after the second package is successfully loaded, its operating status can also be checked, for example, to check whether there are bugs in the operation, whether the expected effect is achieved, etc. If it is abnormal, the second package is uninstalled from the application and the first package is loaded; if it is normal, the content of the first package is upgraded to the second package, and the second package and configuration file are deleted, thereby integrating the second package into the application and modifying the corresponding configuration file so that the upgraded first package (actually the second package that was evaluated as normal) is directly activated the next time the application is started, thus achieving iterative upgrades without the user noticing.

[0051] Based on the same idea, one or more embodiments of this specification also provide devices and apparatuses corresponding to the above methods, such as Figure 4 、 Figure 5 shown.

[0052] In the second aspect, Figure 4 As shown, Figure 4 An embodiment of this specification provides a package library update device, which is used when an application is started. The device includes:

[0053] Detection module 401, detecting whether there is a configuration file of the second encapsulation package in the application;

[0054] The acquisition module 403 acquires the second package corresponding to the configuration file if it exists.

[0055] A loading module 405 is configured to load the second package;

[0056] Otherwise, the detection module 401 detects whether there is a built-in second encapsulation package in the encapsulation library;

[0057] If it exists, the loading module 405 loads the built-in second encapsulation package. If it does not exist, the loading module 405 loads the first encapsulation package, wherein the second encapsulation package is an upgraded version of the first encapsulation package.

[0058] Optionally, the acquisition module 403 acquires a locally available non-built-in second package according to the local path indicated by the configuration file; or acquires the second package by downloading from a server according to the download path indicated by the configuration file.

[0059] Optionally, the apparatus further includes an updating module 407, configured to update the configuration file after downloading and obtaining the second encapsulation package from the server, wherein the updated configuration file is used to instruct the loading of the downloaded second encapsulation package at the next startup.

[0060] Optionally, the apparatus further comprises a clearing module 409 for clearing the content of the loaded second encapsulation package when loading of the second encapsulation package fails; after the clearing is completed, the loading module 405 loads the first encapsulation package.

[0061] Optionally, the loading module 405 obtains a list of available loading objects of the application; places the code resources in the second package into the head of the list; and loads the list of available loading objects to load the code resources in the second package.

[0062] Optionally, the loading module 405 converts the code resources in the second package into an executable file object; generates an array corresponding to the list and the executable file object; converts the executable file object into array elements and stores them at the head of the array; and converts the list into array elements and stores them at the tail of the array.

[0063] Optionally, the loading module 405 inserts the resources in the second encapsulation package into the resource object to be loaded, wherein the resource package identifier of the resources in the second encapsulation package is different from the resource package identifier of the resources in the encapsulation library; and loads the resource object to be loaded.

[0064] Optionally, the loading module 405 obtains the address of the dynamic link library in the second package; and loads the dynamic link library in the second package according to the address.

[0065] Optionally, the loading module 405 obtains the address of the dynamic link library in the second package from the download or / decompression path of the second package; or obtains the address of the dynamic link library in the second package from the default loading path in the operating system of the device where the package library is located; or generates the address of the dynamic link library by concatenating a default general directory name and the file name of the dynamic link library.

[0066] Optionally, the device further includes an enabling module 411, which detects whether the second encapsulation package is running normally after the second encapsulation package is successfully loaded; if not, the second encapsulation package is uninstalled and the first encapsulation package is loaded; if normal, the content in the first encapsulation package is upgraded to the second encapsulation package, and the second encapsulation package is deleted.

[0067] In a second aspect, the embodiments of this specification further provide an electronic device, such as Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this specification, the device comprising:

[0068] at least one processor; and,

[0069] a memory communicatively connected to the at least one processor; wherein,

[0070] The memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the method according to the first aspect.

[0071] Based on the same idea, in the fourth aspect, one or more embodiments of this specification also provide a non-volatile computer storage medium corresponding to the above method, which stores computer-executable instructions. When the computer reads the computer-executable instructions in the storage medium, the instructions enable one or more processors to execute the method described in the first aspect.

[0072] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD through their own programming, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0073] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the means for implementing various functions included therein can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as both a software module implementing the method and a structure within the hardware component.

[0074] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0075] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0076] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0077] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0078] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0079] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0080] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0081] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0082] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0083] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0084] This specification may be described in the general context of computer-executable instructions, such as program modules, executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including storage devices.

[0085] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0086] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0087] The foregoing description is merely one or more embodiments of this specification and is not intended to limit this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of one or more embodiments of this specification are intended to be within the scope of the claims of this specification.

Claims

1. A package library update method, used when an application is started, comprising: Detecting whether a configuration file of a second package exists in the application; If the configuration file exists, obtaining the second package corresponding to the configuration file, and loading the second package; Otherwise, detecting whether there is a built-in second package in the package library; If the second package exists, the built-in second package is loaded; if the first package does not exist, the first package is loaded, wherein the second package is an upgraded version of the first package; An encapsulation library refers to a small code library formed by encapsulating business or technical implementations for specific scenarios in an application.

2. The method according to claim 1, wherein Obtaining a second package corresponding to the configuration file includes: According to the local path indicated by the configuration file, obtain a locally available non-built-in second encapsulation package; Alternatively, the second package is downloaded from the server according to the download path indicated by the configuration file.

3. The method according to claim 2, wherein: After downloading and obtaining the second package from the server, the method further includes: The configuration file is updated, wherein the updated configuration file is used to instruct to load the downloaded second package during the next startup.

4. The method according to claim 1, wherein The method further comprises: When loading of the second encapsulation package fails, clearing the content of the loaded second encapsulation package; After the clearing is completed, the first packaging package is loaded.

5. The method according to claim 1, wherein Loading the second package includes: Obtain a list of available load objects for the application; Put the code resources in the second package into the head of the list; The list of available load objects is loaded to load the code resources in the second package.

6. The method according to claim 5, wherein: Putting the code resources in the second package into the head of the list includes: Convert the code resources in the second package into an executable file object; generating an array corresponding to the list and the executable file object; Convert the executable file object into an array element and store it in the head of the array; Convert the list into array elements and store them at the end of the array.

7. The method of claim 1, wherein: Loading the second package includes: Inserting the resources in the second package into the resource object to be loaded, wherein the resource package identifier of the resources in the second package is different from the resource package identifier of the resources in the package library; Load the resource object to be loaded.

8. The method of claim 1, wherein: Loading the second package includes: Obtaining the address of the dynamic link library in the second package; The dynamic link library in the second package is loaded according to the address.

9. The method of claim 8, wherein: Obtaining the address of the dynamic link library in the second package includes: Obtaining the address of the dynamic link library in the second package from the download or / decompression path of the second package; Alternatively, the address of the dynamic link library in the second package is obtained from a default loading path in the operating system of the device where the package library is located; Alternatively, the address of the dynamic link library is generated by concatenating a default general directory name and the file name of the dynamic link library.

10. The method according to claim 1, further comprising: after the second package is successfully loaded: Detecting whether the second encapsulation package operates normally; When it is abnormal, uninstall the second package and load the first package; When it is normal, the content in the first encapsulation package is upgraded to the second encapsulation package, and the second encapsulation package is deleted.

11. A package library update device, used when an application is started, comprising: A detection module, detecting whether a configuration file of the second encapsulation package exists in the application; The acquisition module, when present, acquires the second package corresponding to the configuration file, Loading module, loading the second package; Otherwise, the detection module detects whether there is a built-in second encapsulation package in the encapsulation library; When it exists, the loading module loads the built-in second encapsulation package; when it does not exist, the loading module loads the first encapsulation package, wherein the second encapsulation package is an upgraded version of the first encapsulation package; An encapsulation library refers to a small code library formed by encapsulating business or technical implementations for specific scenarios in an application.

12. The apparatus of claim 11, wherein the acquisition module acquires a locally available non-built-in second package according to a local path indicated by the configuration file; or acquires the second package by downloading from a server according to a download path indicated by the configuration file.

13. The device according to claim 12, further comprising an updating module, configured to update the configuration file after downloading and obtaining the second package from the server, wherein: The updated configuration file is used to instruct to load the downloaded second package during the next startup.

14. The apparatus according to claim 11, further comprising a clearing module, which clears the content of the loaded second encapsulation package when loading of the second encapsulation package fails; after clearing, the loading module loads the first encapsulation package.

15. The device of claim 11, wherein the loading module obtains a list of available loading objects of the application; places the code resources in the second package into the head of the list; and loads the list of available loading objects to load the code resources in the second package.

16. The apparatus of claim 15, wherein the loading module converts the code resources in the second package into an executable file object; generates an array corresponding to the list and the executable file object; converts the executable file object into an array element and stores it at the head of the array; and converts the list into an array element and stores it at the tail of the array.

17. The apparatus according to claim 11, wherein the loading module inserts the resources in the second package into the resource object to be loaded, wherein: The resource bundle identifier of the resource in the second encapsulation package is different from the resource bundle identifier of the resource in the encapsulation library; and the resource object to be loaded is loaded.

18. The device according to claim 11, wherein the loading module obtains an address of a dynamic link library in the second package; and loads the dynamic link library in the second package according to the address.

19. The apparatus of claim 18, wherein the loading module obtains the address of the dynamic link library in the second package from a download or / decompression path of the second package; or obtains the address of the dynamic link library in the second package from a default loading path in an operating system of a device where the package library is located; or generates the address of the dynamic link library by concatenating a default universal directory name and a file name of the dynamic link library.

20. The device according to claim 11 further includes an enabling module, which detects whether the second encapsulation package is running normally after the second encapsulation package is successfully loaded; when it is not normal, unloads the second encapsulation package and loads the first encapsulation package; when it is normal, upgrades the content in the first encapsulation package to the second encapsulation package and deletes the second encapsulation package.

21. An electronic device comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 10.

Images