Detailed Description
The embodiment of the specification provides a method, a device, equipment and a storage medium for updating a package library.
In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, shall fall within the scope of the present application.
In large comprehensive application clients (e.g., payment class comprehensive application client applications or communication class comprehensive application clients), a number of large encapsulation libraries are typically included. The encapsulation Library is an encapsulation implemented for a service or technology of a specific scenario in an application, and is a small-sized code Library (Library) formed, and the code Library generally includes contents such as code resources (Class), dynamic link libraries (So), resources (Resource), and the like. The package library is updated by gray level immediately due to wider code related area, so that the problem of frequent edition issue can be caused. Based on this, the embodiment of the present disclosure provides a more convenient updating scheme of the package library.
In a first aspect, as shown in fig. 1, fig. 1 is a flow chart of a method for updating a package library according to an embodiment of the present disclosure, and the flow chart includes when an application is started.
S101, detecting whether a configuration file of a second encapsulation package exists in the application.
It should be noted that at least a first package exists in the application, and the first package is specific to a stable version of the currently employed package library. The second package may be local to the device where the application is located, or may be on the server side as an updated version of the first package.
Generally, when a gray scale upgrade is performed (i.e., for a part of applications, a first package adopted by the application needs to be upgraded to a second package), a configuration file of the corresponding second package is firstly issued to a device where the application is located, where the configuration file is used to indicate how to obtain the second package, and in particular how to load the second package.
And S103, when the configuration file exists, acquiring a second package corresponding to the configuration file, and loading the second package.
If the configuration file of the second package is locally available, the second package may be obtained and loaded based on the indication of the configuration file.
Specifically, the available non-built-in second package existing locally can be obtained according to the local path indicated by the configuration file. In addition, before loading, whether the version number of the second package corresponding to the download path indicated by the configuration file is higher or not can be detected, and if yes, the second package with the high version number can be downloaded for loading. Or downloading and acquiring the second encapsulation package from the server according to the download path indicated by the configuration file.
In this embodiment of the present disclosure, the built-in package refers to the second package that has been packaged into the package library. Non-built-in packages refer to the second package that has not yet been packaged into the package library.
S105, otherwise, detecting whether a second built-in package exists in the package library.
When there is no configuration file for the second package locally, then either the second package has been packaged into the package library or there is no second package locally (i.e., the user is likely not an object of a greyscale upgrade). Then at this point it can be checked whether there is a second encapsulation packet built in locally.
In the present embodiment, the built-in second package refers to a second package that has been compressed into the package library. The second package is built in independent of the configuration file. Typically, a second package may be compressed into the package library after it has been confirmed to be operating stably. In particular, a specified field may be employed within the encapsulation library to indicate whether the library is a second encapsulation package that is built in.
S107, when the second encapsulation package is present, the second encapsulation package is loaded, and when the second encapsulation package is not present, the first encapsulation package is loaded.
And if the built-in two encapsulation packages exist, loading the built-in second encapsulation package. If not. The first encapsulation packet is directly loaded.
The method comprises the steps of detecting whether a configuration file of a second package exists in an application, acquiring the second package corresponding to the configuration file when the configuration file exists, loading the second package, otherwise, detecting whether a built-in second package exists in a package library, loading the built-in second package when the second package exists, and loading a first package when the second package does not exist, wherein the second package is an upgrade version of the first package. Therefore, the business does not need to be subjected to code invasion, namely, the switching loading of the second package or the first package is realized when the application is started, and the update of the package library which is not felt by a user is realized when the application is prevented from being crashed possibly in the upgrading process, so that the method is more convenient.
In one embodiment, after the configuration file exists locally and the second package is obtained from the server based on the download of 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 be the local path of the downloaded second package, so that when the application is started next time, the downloaded second package can be acquired and loaded based on the local path indicated by the configuration file.
In one embodiment, when the second package has a problem in the loading process or the second package has a problem in the actual running process, the process of enabling the first package is performed. Specifically, the content of the second package which is already loaded is cleared, and after the clearing is finished, the first package is loaded. Meanwhile, the loading and switching process results of the first package and the second package can be reported to the cloud, and the cloud can monitor and evaluate the first package and the second package in real time according to the data. As shown in fig. 2, fig. 2 is a schematic flow chart of a specific loading provided in the embodiment of the present disclosure.
As described above, the second package includes contents such as code resources (Class), dynamic link libraries (so files), resources (Resource), and the like. Since the foregoing content is also contained in the local first package, in order to ensure that the content can be loaded into the second package, in this embodiment of the present disclosure, a loading manner that is more specific to the foregoing code Resource (Class), dynamic link library (So), and Resource (Resource) is also provided.
Specifically, when code resources in the second package are loaded, the code resources are converted into application-identifiable available load objects (DexFile) and then loaded according to system class loader structure and mechanisms.
For example, a list of available loading objects of the application is obtained first (typically DexPathlist files, dexfile is stored in DexPathlist files, and loading is achieved by traversing DexPathlist files during loading), then the available loading objects obtained by converting the code resources in the second package are placed in the head of the list, and the list of available loading objects is loaded, so that the code resources in the second package are loaded. Since the list is loaded by searching the available loading object from the head, and searching is finished and loading is started once searching is successful, the code resources in the second encapsulation package can be ensured to be loaded preferentially.
Further, in one embodiment, when the code resource in the second package is placed in the header of the list, the code resource in the second package may be converted into an executable file object (that is, dexfile), and an array corresponding to the list and the executable file object is generated at the same time, where the size of the array is the sum of the size of the available loading object contained in the list and the size of the executable file object obtained by converting the code resource, and further, the executable file object obtained by converting the code resource is placed in the header of the array, and the list is stored in the tail of the array, so that the loading mode of the system class loader of different versions of the android system can be compatible in this way, and the versatility is improved.
In one embodiment, when loading the resource in the second encapsulation package (the resource object may include a static resource such as a picture, an animation, etc.), since the first encapsulation package exists in the application at the same time, the resource in the first encapsulation package and the resource in the second encapsulation package are both identified by the resource package identifier (Product Part Identification, PPID) to which the resource belongs. Thus, to avoid the pain of invoking 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.
For example, the resource package identification of the resource in the second encapsulation package may be modified to a non-default value by compilation. And, there may be some resources in the system that may already be occupied, the resource package identification of the resources in the second package may be modified to a non-default or non-occupied value. Specifically, if the PPID of the default resource of the system is 0x7f and the value of the occupied PPID is from 0001 to 000A, the resource package identifier of the resource in the second package can be modified to be a non-default value or a non-occupied value, such as 0x5f, 0x6e and the like, and the conflict of resource loading can be avoided through pre-compiling.
Furthermore, the resource in the second package may be inserted into the resource object to be loaded, for example, the object of the resource of the current page may be reflected to obtain its ASSETMANAGER instance, and then the method of reflection calling ADDASSETPATH may be used to insert the resource in the second package into the object of the resource of the current page.
In practical application, in order to realize immediate effectiveness of resource insertion, a getResource method such as Activity, service can be precompiled in advance, a user-defined resource acquisition processing code is dynamically inserted into the method, and the resource in the second package is inserted into a resource object to be loaded through the resource acquisition processing code, so that the user experience is improved.
In one embodiment, for loading the dynamic link library (so file) in the second package, the loading may be performed by obtaining an address of the dynamic link library in the second package, and loading the dynamic link library in the second package according to the address.
Specifically, the method for obtaining the address of the dynamic link library in the second package may include a first method for obtaining the address of the dynamic link library in the second package from a download path or/and a decompression path of the second package, or when the first method fails to load, obtaining 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, for example, recording from the default loading path through a system.loadlibrary, or when the first method and the second method fail to load, generating and recording the address of the dynamic link library by adopting a default universal directory name and a file name of the dynamic link library, for example, splicing to form a new so file path through a default universal directory name content# nativeLibraryDir and a file name mapLibraryName of the dynamic link library, and attempting to load a file indicated by the path obtained through the splicing again through the system.load. By the mode, different equipment and loading modes of different systems can be compatible, and adaptability is improved.
Fig. 3 is a schematic diagram of loading a second package according to an embodiment of the present disclosure. The loading of the content of the second package at the top of the loading flow can be realized by the loading modes of code resources (Class), dynamic link libraries (so files), resources (Resource) and the like of the second package.
In one embodiment, after the second package is loaded successfully, its running condition may also be detected, for example, whether a bug is present in the running, whether an expected effect is achieved, etc. And when the system is normal, upgrading the content in the first package into the second package, deleting the second package and the configuration file, thereby realizing the embedding of the second package into the application, modifying the corresponding configuration file, so as to directly start the upgraded first package (actually, the second package with normal evaluation) when the system is started next time, and realizing iterative upgrading under the condition that a user is not felt.
Based on the same thought, one or more embodiments of the present disclosure further provide apparatuses and devices corresponding to the above method, as shown in fig. 4 and fig. 5.
In a second aspect, as shown in fig. 4, fig. 4 is a device for updating a package library according to an embodiment of the present disclosure, where the device includes:
the detection module 401 detects whether a configuration file of the second package exists in the application;
an obtaining module 403, when the configuration file exists, obtaining a second package corresponding to the configuration file,
A loading module 405 for loading the second encapsulation packet;
Otherwise, the detecting module 401 detects whether a second package is built in the package library;
When the second package exists, the loading module 405 loads the second package built in, and when the second package does not exist, the loading module 405 loads the first package, wherein the second package is an updated version of the first package.
Optionally, the obtaining module 403 obtains the available non-built-in second package locally according to the local path indicated by the configuration file, or downloads and obtains the second package from the server according to the download path indicated by the configuration file.
Optionally, the apparatus further includes an updating module 407, configured to update the configuration file after the second package is downloaded from the server, where the updated configuration file is used to instruct loading of the downloaded second package at the next start.
Optionally, the device further includes a clearing module 409 for clearing the content of the second package that has been loaded when the loading of the second package fails, and the loading module 405 loads the first package after clearing is completed.
Optionally, the loading module 405 obtains a list of available loading objects of the application, places the code resources in the second package in a header of the list, and loads the list of available loading objects to load the code resources in the second package.
Optionally, the loading module 405 converts the code resource 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 a tuple element, stores the tuple element in a header of the array, converts the list into a tuple element, and stores the tuple element in a tail of the array.
Optionally, the loading module 405 inserts the resource in the second package into the resource object to be loaded, where the resource package identifier of the resource in the second package is different from the resource package identifier of the resource in the package library, and loads the resource object to be loaded.
Optionally, the loading module 405 obtains an address of the dynamic link library in the second package, and loads the dynamic link library in the second package according to the address.
Optionally, the loading module 405 obtains an address of a dynamic link library in the second package from a download or/and decompression path of the second package, or obtains an address of a 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 concatenates a default universal directory name and a file name of the dynamic link library to generate the address of the dynamic link library.
Optionally, the device further includes an enabling module 411, after the second package is loaded successfully, detecting whether the second package is operating normally, unloading the second package and loading the first package when the second package is abnormal, and upgrading the content in the first package to the second package and deleting the second package when the second package is normal.
In a second aspect, embodiments of the present disclosure further provide an electronic device, as shown in fig. 5, and fig. 5 is a schematic structural diagram of an electronic device provided in the embodiments of the present disclosure, where the device includes:
at least one processor, and
A memory communicatively coupled to the at least one processor, wherein,
The memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of the first aspect.
Based on the same idea, in a fourth aspect, one or more embodiments of the present disclosure further provide a non-volatile computer storage medium corresponding to the above method, where computer executable instructions are stored, and when the computer reads the computer executable instructions in the storage medium, the instructions cause one or more processors to perform the method as described in the first aspect.
In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable GATE ARRAY, FPGA)) is an integrated circuit whose logic functions are determined by user programming of the device. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented with "logic compiler (logic compiler)" software, which is similar to the software compiler used in program development and writing, and the original code before being compiled is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but HDL is not just one, but a plurality of kinds, 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), and VHDL (Very-High-SPEED INTEGRATED Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, 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, application SPECIFIC INTEGRATED Circuits (ASICs), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, ARC625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smart phone, 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.
For convenience of description, the above devices are described as being functionally divided into various units, respectively. Of course, the functions of each element may be implemented in one or more software and/or hardware elements when implemented in the present specification.
It will be appreciated by those skilled in the art that the present description may be provided as a method, system, or computer program product. Accordingly, the present specification embodiments may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present description embodiments may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the specification. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
In one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises an element.
The description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment mainly describes differences from other embodiments. In particular, for apparatus, devices, non-volatile computer storage medium embodiments, the description is relatively simple, as it is substantially similar to method embodiments, with reference to the section of the method embodiments being relevant.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
The foregoing is merely one or more embodiments of the present description and is not intended to limit the present description. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of one or more embodiments of the present description, is intended to be included within the scope of the claims of the present description.