Method and device for checking operability of static library and electronic equipment

Abstract

The embodiment of the invention provides a verification method and device for the operability of a static library and electronic equipment, and relates to the technical field of data processing. The method comprises the following steps: acquiring a first file of a pre-created target static library; obtaining a pre-created target dynamic library project, and setting a target file on which the target dynamic library project currently depends; respectively operating the target dynamic library project in each central processing unit architecture to obtain each compiling result of the target static library in each central processing unit architecture; for any central processing unit architecture, if it is determined that the compiling result in the target static library central processing unit architecture meets the preset condition, it is determined that the target static library can run in the central processing unit architecture. According to the embodiment of the invention, the target dynamic library project is set to depend on the to-be-verified target static library, so that the target static library is compiled along with the running of the dynamic library project, the runnability of the static library under each CPU architecture can be accurately verified, and the released SDK is ensured to be normal.

Description

Technical Field

[0001] This application relates to the technical field of data processing. Specifically, this application relates to a method, apparatus, and electronic device for verifying the runnability of static libraries. Background Art

[0002] A software development kit (SDK) includes multiple static libraries. A static library is a way of sharing program code. If a static library needs to be used, it will be completely copied into the executable file during the code linking stage, and multiple redundant copies will be made if it is used multiple times.

[0003] Before the SDK is released, it is necessary to verify the validity of each static library in the SDK.

[0004] Existing solutions verify the validity by manually unpacking. Specifically, the SDK is manually split into files under different central processing unit (CPU) architectures. For any CPU architecture, if there is a static library under that CPU architecture, it is determined that the static library supports that CPU architecture. However, the existence of a static library under a certain CPU architecture does not mean that the static library can run in that CPU architecture, nor does it mean that the static library can run in other CPU architectures. This verification method is likely to cause the static libraries included in the SDK to be unable to be used normally after the SDK is released. Summary of the Invention

[0005] Embodiments of this application provide a method, apparatus, electronic device, computer-readable storage medium, and computer program product for verifying the runnability of static libraries, which are used to solve at least one technical problem in the background art.

[0006] According to the first aspect of the embodiments of this application, a method for verifying the runnability of static libraries is provided. The method includes:

[0007] Download and decompress the target software development kit to be released to the local platform to obtain at least one static library to be verified; the release platform of the target software development kit includes at least one central processing unit architecture, and the local platform has the same central processing unit architecture as the release platform;

[0008] Select the target static library to be currently verified from at least one static library to be verified, and obtain the first file of the target static library created in advance. The first file is used to describe the basic configuration information of the corresponding static library;

[0009] Obtain a pre-created target dynamic library project, and set the target files currently depended on by the target dynamic library project. The target files include a target static library and a first file of the target static library;

[0010] Run the target dynamic library project on each central processing unit (CPU) architecture respectively, so that the target dynamic library project reads the first file to compile the target static library, and obtain respective compilation results of the target static library on each CPU architecture;

[0011] For any CPU architecture, if it is determined that the compilation result of the target static library on the CPU architecture meets a preset condition, it is determined that the target static library is runnable on the CPU architecture.

[0012] According to a second aspect of the embodiments of the present application, there is provided a verification device for the runnability of a static library. The verification device includes:

[0013] A download module, configured to download and decompress a target software development kit to be released to a local platform, and obtain at least one static library to be verified; the release platform of the target software development kit includes at least one CPU architecture, and the local platform has the same CPU architecture as the release platform;

[0014] A selection module, configured to select a target static library to be currently verified from at least one static library to be verified, and obtain a first file of the pre-created target static library. The first file is used to describe the basic configuration information of the corresponding static library;

[0015] A dependent file setting module, configured to obtain a pre-created target dynamic library project, and set the target files currently depended on by the target dynamic library project. The target files include a target static library and a first file of the target static library;

[0016] A target dynamic library project running module, configured to run the target dynamic library project on each CPU architecture respectively, so that the target dynamic library project reads the first file to compile the target static library, and obtain respective compilation results of the target static library on each CPU architecture;

[0017] A runnability determination module, configured to for any CPU architecture, if it is determined that the compilation result of the target static library on the CPU architecture meets a preset condition, determine that the target static library is runnable on the CPU architecture.

[0018] In a possible implementation manner, the runnability determination module is further configured to for any CPU architecture, if it is determined that the compilation result of the target static library on the CPU architecture does not meet the preset condition, determine that the target static library is not runnable on the CPU architecture.

[0019] In a possible implementation, the dependent file setting module includes:

[0020] A second file determination sub-module, configured to obtain a second file of the target dynamic library project; the second file is used to set the target file currently depended on by the target dynamic library project; the second file includes the address information of the target file.

[0021] An address information determination sub-module, configured to determine the address information of the target static library and the address information of the first file of the target static library.

[0022] An address information addition sub-module, configured to add the address information of the target static library and the address information of the first file of the target static library to the second file, so as to set the target file to include the target static library and the first file of the target static library.

[0023] In a possible implementation, the target dynamic library project running module is further specifically configured to, if the number of at least one central processing unit (CPU) architecture is greater than a first preset number, run the target dynamic library project based on any one of the following methods: run the target dynamic library project in each CPU architecture in sequence; determine a second preset number based on the number of each CPU architecture, generate copies of the target dynamic library project with the second preset number, and run the target dynamic library project and the copies of the target dynamic library project in parallel in each CPU architecture.

[0024] In a possible implementation, the verification device further includes:

[0025] An update module, configured to update the target static library to a new target static library, and use the target static library before the update as the verified static library; the new target static library is other static libraries in at least one static library to be verified except the verified static library.

[0026] In a possible implementation, the verification device further includes: a target dynamic library project creation module, and the target dynamic library project creation module includes:

[0027] An initial dynamic library project creation sub-module, configured to create an initial dynamic library project in a preset development tool, and each configuration item of the initial dynamic library project is an initial value.

[0028] A modification sub-module, configured to modify the target configuration items of the initial dynamic library project to corresponding target values; the target configuration items include version numbers and compilation options.

[0029] In a possible implementation, it is used to determine the directory of the initial dynamic library project, create a second file under the directory, and obtain the target dynamic engineering library.

[0030] In an embodiment of the present application, a possible implementation manner is provided. The download module is specifically configured to run a first script to execute a first command in the first script. The first command is used to download and decompress a target software development kit to be released to a local platform;

[0031] The target dynamic library project running module is specifically configured to run a second script to execute a second command in the second script. The second command is used to run the target dynamic library project in at least one central processing unit architecture respectively;

[0032] The dependent file setting module is specifically configured to run a third script to execute a third command in the third script. The third command is used to set a target file on which the target dynamic library project currently depends.

[0033] According to a third aspect of the embodiments of the present application, an electronic device is provided. The electronic device includes a memory, a processor, and a computer program stored on the memory. When the processor executes the program, the steps of the method provided in the first aspect are implemented.

[0034] According to a fourth aspect of the embodiments of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method provided in the first aspect are implemented.

[0035] According to a fifth aspect of the embodiments of the present application, a computer program product is provided. The computer program product includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. When a processor of a computer device reads the computer instructions from the computer-readable storage medium and the processor executes the computer instructions, the computer device is caused to execute the steps of the method provided in the first aspect.

[0036] The beneficial effects brought by the technical solutions provided in the embodiments of the present application are:

[0037] In the embodiments of the present application, by setting that the target dynamic library project depends on the target static library to be verified, the target static library is compiled as the dynamic library project runs, and the runnability of the static library under each CPU architecture can be accurately verified.

[0038] And when the number of CPU architectures is multiple, the target dynamic library project can run on multiple CPU architectures, and the static library can be compiled in multiple CPU architectures, that is, the static library can be compiled in all CPU architectures, ensuring that the released static library can be normally used on multiple CUP architectures and ensuring that the released SDK is normal. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description in the embodiments of the present application.

[0040] Figure 1 It is a schematic diagram of the architecture of a verification system for realizing the runnability of a static library provided by an embodiment of the present application;

[0041] Figure 2 It is a schematic flowchart of a method for verifying the runnability of a static library provided by an embodiment of the present application;

[0042] Figure 3 It is a schematic diagram of a method for verifying the feasibility of another static library in an application scenario provided by an embodiment of the present application;

[0043] Figure 4 It is a schematic diagram of running the target dynamic library project in multiple CPU architectures provided by an embodiment of the present application;

[0044] Figure 5 It is a flowchart of another method for verifying the runnability of a static library provided by an embodiment of the present application;

[0045] Figure 6 It is a schematic diagram of another method for verifying the runnability of a static library provided by an embodiment of the present application;

[0046] Figure 7 It is a schematic diagram of the structure of a device for verifying the runnability of a static library provided by an embodiment of the present application;

[0047] Figure 8 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0048] The embodiments of the present application will be described below with reference to the accompanying drawings in the present application. It should be understood that the embodiments described below in conjunction with the accompanying drawings are exemplary descriptions for explaining the technical solutions of the embodiments of the present application, and do not constitute limitations on the technical solutions of the embodiments of the present application.

[0049] Those skilled in the art can understand that, unless specifically stated otherwise, the singular forms "a", "an", "the" and "said" used herein may also include the plural forms. It should be further understood that the terms "comprising" and "including" used in the embodiments of the present application mean that the corresponding features can be implemented as the presented features, information, data, steps, operations, elements and / or components, but do not exclude the implementation of other features, information, data, steps, operations, elements, components and / or their combinations supported by the technical field of the present application, etc. It should be understood that when we say an element is "connected" or "coupled" to another element, the one element can be directly connected or coupled to the other element, or it can mean that the one element and the other element establish a connection relationship through an intermediate element. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The term "and / or" used herein indicates at least one of the items defined by the term, for example, "A and / or B" can be implemented as "A", or implemented as "B", or implemented as "A and B".

[0050] To make the objectives, technical solutions and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

[0051] First, several terms related to the present application are introduced and explained:

[0052] A program dependency library (also known as a third-party library), abbreviated as a dependency library or a library, is a way of sharing program code. A library is a file, which is divided into two types, namely a static library file (abbreviated as a static library) and a dynamic library file (abbreviated as a dynamic library). Among them,

[0053] The static library is statically linked when used, that is, the static library is completely copied into the executable file during linking, and there are multiple redundant copies if it is used multiple times.

[0054] The dynamic library is dynamically linked when used, that is, the dynamic library is not copied during linking, and is dynamically loaded into the memory by the system during program operation for the program to call. The system only loads it once, and multiple programs share it, saving memory.

[0055] Cocoapods is a tool for managing libraries. Specifically, it can manage the dependency relationships between libraries, download the source code of libraries, and connect the libraries to the engineering project by creating an Xcode workspace, so as to facilitate development and use.

[0056] A podspec file is a file used by CocoaPods to describe a library. It contains some metadata and configuration information, such as the name, version, author, dependencies, source code files, etc. of the library. The podspec file is an important part of CocoaPods for managing library dependencies, which enables developers to easily publish the libraries they write to the CocoaPods platform for other developers to use. In a project engineering, the suffix of the podspec file is ".podspec".

[0057] CPU architecture is the instruction set architecture of a computer processor, that is, the instruction set that the processor can understand and execute. Common CPU architectures include x86 architecture, ARM architecture, MIPS architecture, and PowerPC architecture, etc. An operating system can use multiple instruction set architectures because an operating system can have multiple CPU architectures and different instruction sets need to be written to adapt to different CPU architectures.

[0058] The following describes the technical solutions of the embodiments of the present application and the technical effects produced by the technical solutions of the present application through the description of several exemplary embodiments. It should be noted that the following embodiments can refer to, draw on, or combine with each other. For the same terms, similar features, and similar implementation steps in different embodiments, they will not be described repeatedly.

[0059] Figure 1 The figure is a schematic architecture diagram of a verification system for realizing the runnability of a static library provided by an embodiment of the present application. It can be understood that the verification of the runnability of the static library provided by the embodiments of the present application can be applicable to but not limited to applications such as Figure 1 the application scenarios shown.

[0060] As Figure 1 shown, it can include but not limited to a terminal 110, a server 120, and a network 130. The terminal 110 and the server 120 are interconnected through the network 130.

[0061] The server 120 stores a target software development kit to be released (subsequently referred to as the target SDK). The target SDK includes a static library. Before the target SDK is released, the runnability of the static library needs to be verified, and the terminal can verify the target SDK.

[0062] The terminal 110 can download and decompress the target SDK to be released from the server to the local platform to obtain at least one static library to be verified; the release platform of the target SDK includes at least one central processing unit architecture (subsequently referred to as CPU architecture), and the local platform has the same CPU architecture as the release platform.

[0063] The terminal 110 can select the target static library to be currently verified from at least one static library to be verified, obtain the first file of the target static library created in advance, where the first file is used to describe the basic configuration information of the corresponding static library; obtain the target dynamic library project created in advance, and set the target files currently depended on by the target dynamic library project, where the target files include the target static library and the first file of the target static library; run the target dynamic library project in each CPU architecture respectively, so that the target dynamic library project reads the first file to compile the target static library, and obtain the compilation results of the target static library in each CPU architecture; for any one CPU architecture, if it is determined that the compilation result of the target static library in the CPU architecture meets the preset conditions, it is determined that the target static library can run in the CPU architecture.

[0064] After the terminal 110 determines that all the compilation results meet the preset conditions, it determines that the target SDK to be released can be released.

[0065] For any one CPU architecture, if the terminal 110 determines that the compilation result of the target static library in the CPU architecture does not meet the preset conditions, it determines that the target static library cannot run in the CPU architecture, and prompts an alarm message, where the alarm message is used to prompt that the target static library cannot run in the CPU architecture, and it is necessary to locate the fault that causes the non - running and repair the fault, so that the compilation result of the target static library in any one CPU architecture meets the preset conditions.

[0066] After the terminal 110 repairs the non - running static library in the target SDK, it obtains the repaired target SDK and uploads the repaired target SDK to the server 120.

[0067] In some embodiments, the server 120 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, 25 domain name services, security services, content delivery network (CDN, Content Delivery Network), and big data and artificial intelligence platforms. The terminal 110 can be a smart phone, a tablet computer, a notebook computer, a desktop computer, a smart speaker, a smart watch, a vehicle terminal, an aircraft, etc., but is not limited thereto. The terminal and the server can be directly or indirectly connected through wired or wireless communication methods, and this is not limited in the embodiments of the present application.

[0068] In the embodiments of the present application, a method for planning cloud services is provided, which can be executed independently by the terminal 110, or jointly executed by the terminal 110 and the server 120, and this is not limited in the embodiments of the present application.

[0069] In an embodiment of the present application, a method for verifying the runnability of a static library is provided. As Figure 2 shown, the method includes:

[0070] Step S201, download and decompress the target SDK to be released to the local platform to obtain at least one static library to be verified; the release platform of the target SDK includes at least one CPU architecture, and the local platform has the same CPU architecture as the release platform.

[0071] Before releasing the target SDK in an embodiment of the present application, it is also necessary to verify the target SDK, and the target SDK includes at least one static library to be verified.

[0072] Before the target SDK of the embodiment of the present application is released, it can be stored on a cloud server. The terminal can download the target SDK from the cloud server and decompress the target SDK to obtain at least one static library to be verified. Of course, in some scenarios, the target SDK can also be directly stored on the local platform. In this case, there is no need to download the target SDK.

[0073] In one embodiment, the static libraries to be verified included in the target SDK include: TXLiteAVSDK_Live static library, TXLiteAVSDK_Player_Premium static library, TXLiteAVSDK_Player static library, TXLiteAVSDK_Professional static library, TXLiteAVSDK_Smart static library, TXLiteAVSDK_TRTC static library, and TXLiteAVSDK_UGC static library.

[0074] The target SDK of the embodiment of the present application has a corresponding release platform, and the release platform includes, but is not limited to, any one of the IOS platform, Linus platform, and Windows platform.

[0075] The terminal of the embodiment of the present application has its own local platform, and the local platform is the same as the release platform. That is, when the release platform is the iOS platform, the local platform is also the IOS platform; when the release platform is the linux platform, the local platform is the linux platform, that is, the local platform and the release platform follow the same platform.

[0076] The release platform and the local platform of the embodiments of the present application have at least one CPU architecture. The CPU architecture is the instruction set architecture of a computer processor, that is, the instruction set that the processor can understand and execute. Common CPU architectures include the x86 architecture, the ARM architecture, the MIPS architecture, and the PowerPC architecture, etc. When the release platform or the local platform has only one CPU architecture, the release platform can be called a single-architecture platform. When the release platform or the local platform includes at least two CPU architectures, the release platform can be called a multi-architecture platform. The at least one CPU architecture included in the release platform or the local platform can be collectively referred to as the full CPU architecture as a whole.

[0077] When verifying the above various static libraries in the existing solutions, usually a single-architecture verification of the static libraries is performed manually, which cannot be automatically extended to the full CPU architecture platform, and only the compilation check of the static libraries related to the single architecture can be performed.

[0078] Generally, both the release platform and the local platform are multi-architecture platforms, and the various CPU architectures they include are the same. That is, it is assumed that the CPU architectures included in the release platform are the x86 architecture and the ARM architecture, then the CPU architectures included in the local platform are also the x86 architecture and the ARM architecture, so as to verify at least one static library in the same CPU architecture environment as the release platform.

[0079] Step S202: Select the target static library to be verified currently from at least one static library to be verified, and obtain the first file of the target static library created in advance. The first file is used to describe the basic configuration information of the corresponding static library.

[0080] The embodiments of the present application can verify each static library to be verified in turn. Specifically, a target static library to be verified currently can be randomly selected from at least one static library to be verified.

[0081] After determining the target static library to be verified currently in the embodiments of the present application, it is also necessary to obtain the first file created in advance for the target static library. The first file is used to describe the basic configuration information of the corresponding static library.

[0082] In practical applications, the first file can be a podspec file, which is used to describe the basic configuration information of the corresponding static library. The basic configuration information includes metadata and configuration information, such as the name, version, author, dependencies, source code files, etc. of the library.

[0083] In practical applications, the podspec file corresponding to the static library can be downloaded from the target website, and the downloaded podspec file can be localized so that the static library depends on the local podspec file. Of course, in some embodiments, the podspec file can also be pre-written by developers, and the embodiments of the present application do not limit this.

[0084] Step S203: Obtain the pre-created target dynamic library project, and set the target files currently depended on by the target dynamic library project. The target files include the target static library and the first file of the target static library.

[0085] In the embodiments of the present application, there is also a pre-created target dynamic library project. The purpose of setting up this target dynamic library project is mainly to provide a general environment for the static library to be compiled into a dynamic library. During the running process of the target dynamic library project, it will perform static and dynamic compilation on the target files it depends on. To compile the target static library into a dynamic library, it is necessary to set the target static library and the first file of the target static library as the target files currently depended on by the target dynamic library.

[0086] In one embodiment, the target dynamic library project can be generated in Xcode. Xcode is an integrated development environment (IDE) for macOS, used to develop software for macOS, iOS, iPadOS, watchOS, tvOS, and visionOS. Specifically, Xcode can be opened, a new dynamic library project can be created to obtain an initial dynamic library project. The configuration items of this initial dynamic library are all corresponding initial values. The target configuration items (such as version numbers, compilation options, etc.) can be modified to corresponding target values, and a second file can be created in the directory of the initial dynamic library project to obtain the target dynamic library project. This second file is a podfile file, and the podfile file is used to set the target files currently depended on by the target dynamic library project. The target files are the target static library and the podspec file of the target static library. The address information of the target static library and the address information of the first file of the target static library can be added to this second file, so as to set the target files to include the target static library and the first file of the target static library.

[0087] Step S204: Run the target dynamic library project on each CPU architecture respectively, so that the target dynamic library project reads the first file to compile the target static library, and obtains the compilation results of the target static library on each CPU architecture.

[0088] After the embodiments of the present application set the target dynamic library project to depend on the target static library and the first file of the target static library, the target dynamic library project is run on each CPU architecture respectively. During the running process of the target dynamic library project, it reads the first file to perform dynamic compilation on the target static library, and obtains the compilation results of the target static library on each CPU architecture.

[0089] In fact, dynamic compilation aims to compile a static library into a dynamic library. There are two cases for the compilation result. The first case indicates that a runnable dynamic library is obtained, and the second case indicates that a non-runnable dynamic library is obtained.

[0090] Step S205: For any CPU architecture, if it is determined that the compilation result of the target static library in this CPU architecture meets the preset conditions, it is determined that the target static library is runnable in the CPU architecture.

[0091] Continuing the foregoing embodiment, if the compilation result is the first case above, that is, a runnable dynamic library is obtained, it is determined that this compilation result meets the preset conditions, and it can be determined that the target static library is runnable on this CPU architecture.

[0092] If the compilation results of the static library in each CPU architecture all meet the preset conditions, it is determined that the target static library is runnable under each CPU architecture. Thus, it can be determined that the target SDK can run normally, and the target SDK can be a target SDK that can be directly released.

[0093] In an embodiment of the present application, a possible implementation manner is provided. After the above step S204, there is further a step S206 (not shown in the figure). For any CPU architecture, if it is determined that the compilation result of the target static library in the CPU architecture does not meet the preset conditions, it is determined that the target static library is not runnable in the CPU architecture.

[0094] If it is determined in an embodiment of the present application that the compilation result is the second case above, that is, a non-runnable dynamic library is obtained, it is determined that the compilation result of the target static library in this CPU architecture does not meet the preset conditions. At this time, an alarm message can be prompted (the alarm message can be a text prompt, a voice prompt, or a prompt using an alarm symbol), so as to inform the developer or tester that there is a fault in the target static library, and the fault needs to be repaired (for example, repairing the source code of the target static library, configuring the environment, etc.). After the developer repairs the above fault, the repaired target static library can be verified again until the compilation result of the target static library in this CPU architecture meets the preset conditions.

[0095] In an embodiment of the present application, by setting the target dynamic library project to depend on the target static library to be verified, the target static library is compiled as the dynamic library project runs, and the runnability of the static library under each CPU architecture can be accurately verified.

[0096] When the number of CPU architectures is multiple, the target dynamic library project can run on multiple CPU architectures, enabling the compilation of static libraries in multiple CPU architectures, that is, enabling the compilation of static libraries across all CPU architectures, ensuring that the released static libraries can be used normally on multiple CPU architectures and ensuring that the released SDK is normal.

[0097] In addition, any static library can be verified using the above method, that is, the embodiments of the present application can solve the compilation verification of multiple different and unrelated static libraries.

[0098] A possible implementation is provided in the embodiments of the present application. Setting the target files currently depended on by the target dynamic library project includes:

[0099] Obtaining the second file of the target dynamic library project; the second file is used to set the target files currently depended on by the target dynamic library project; the second file includes the address information of the target files.

[0100] Determining the address information of the target static library and the address information of the first file of the target static library;

[0101] Adding the address information of the target static library and the address information of the first file of the target static library to the second file to set the target files to include the target static library and the first file of the target static library.

[0102] When setting the target files currently depended on by the target dynamic library project in the embodiments of the present application, it is necessary to obtain the second file of the target dynamic library project. This second file is the podfile file, which is used to set the target files currently depended on by the target dynamic library project, and the second file includes the address information of the target files.

[0103] In the embodiments of the present application, when setting the target files to be the target static library and the first file of the target static library, the address information of the target static library and the address information of the first file of the target static library are determined, and the address information of the target static library and the address information of the first file of the target static library are added to the second file to set the target files to include the target static library and the first file of the target static library.

[0104] After obtaining the verification results of the target static library under each CPU architecture in the embodiments of the present application, the target static library is updated to obtain a new target static library, and the target dynamic library project is set to depend on the new target static library and the first file of the new target static library, that is, the original address information of the target static library and the original address information of the first file of the target static library are deleted from the second file of the target dynamic library, and the address information of the new target static library and the address information of the first file of the new target static library are added to the second file.

[0105] Such as Figure 3As shown, it exemplarily shows a schematic diagram of a method for verifying the feasibility of executing another static library in an application scenario provided by an embodiment of the present application. Assume that the static libraries to be verified in the target SDK include static library 1, static library 2,..., static library i,..., static library n. Assume that there are two CPU architectures, namely the X86 architecture and the ARM architecture. The first file of static library 1 is podspec file 1, the first file of static library 2 is podspec file 2, the first file of static library i is podspec file i, and the first file of static library n is podspec file n, where i ≤ n and both i and n are positive integers. Assume that the verification order is static library 1 - static library 2 -... - static library i -... - static library n. Then, the i-th static library is verified through the following steps:

[0106] Step S1, delete the address information of static library i - 1 and the address information of podspec file i - 1 in the second file of the target dynamic library project;

[0107] Step S2, add the address information of static library i and the address information of podspec file i;

[0108] Step S3, run the target dynamic library project in the X86 architecture. During the running process, the target dynamic library project reads podspec file i based on the address information of podspec file i, and compiles static library i based on podspec file i to obtain the compilation result 1 under the X86 architecture;

[0109] Step S4, run the target dynamic library project in the ARM architecture. During the running process, the target dynamic library project reads podspec file i based on the address information of podspec file i, and compiles static library i based on podspec file i to obtain the compilation result 2 under the ARM architecture;

[0110] Step S5, determine whether the compilation result 1 meets the preset conditions; if the compilation result 1 meets the preset conditions, it is determined that the static library i can run in the X86 architecture; if the compilation result 1 does not meet the preset conditions, it is determined that the static library i cannot run in the X86 architecture;

[0111] Step S6, determine whether the compilation result 2 meets the preset conditions; if the compilation result 2 meets the preset conditions, it is determined that the static library i can run in the ARM architecture; if the compilation result 2 does not meet the preset conditions, it is determined that the static library i cannot run in the ARM architecture;

[0112] Each static library can be verified based on the above method. After verifying static library i, the address information of static library i and the address information of podspec file i will be deleted from the second file of the target dynamic library project, and the address information of static library i + 1 and the address information of podspec file i + 1 will be added. Based on the same steps, static library i + 1 will be verified.

[0113] A possible implementation is provided in the embodiments of the present application. The target dynamic library project is run in at least one CPU architecture respectively, including:

[0114] If the number of at least one CPU architecture is greater than the first preset number, the target dynamic library project is run based on any of the following methods:

[0115] The target dynamic library project is run sequentially in each CPU architecture;

[0116] Based on the number of each CPU architecture, a second preset number is determined, and copies of the target dynamic library project with the second preset number are generated. The target dynamic library project and the copies of the target dynamic library project are run in parallel in each CPU architecture.

[0117] When there is only one CPU architecture, the target dynamic library project can be directly run in this CPU architecture. However, the number of CPU architectures may be multiple, that is, the number of CPU architectures is greater than the first preset number. The first preset number can be 2, and of course, it can also be other numbers. The embodiments of the present application do not limit this. In this case, the target dynamic library project can be run serially or in parallel under each CPU architecture.

[0118] Such as Figure 4As shown, it exemplarily shows a schematic diagram of running the target dynamic library project in multiple CPU architectures. If serial is selected, the target dynamic library project is run sequentially in each CPU architecture, that is, after running is completed in one CPU architecture, it switches to another CPU architecture and runs the target dynamic library project in this other CPU architecture. Only one CPU architecture is always running, and compilation results 1, compilation results 2,......, compilation results N are obtained respectively; if parallel is selected, copies of the target dynamic library of the second preset quantity are generated, that is, copy 1 of the target dynamic library project, copy 2 of the target dynamic library project...... and copy m of the target dynamic library project, where m is the second preset quantity. Assuming the number of CPU architectures is N, then m + 1 = N. That is, the target dynamic library project is run in CPU architecture 1, and copies 1, 2...... and m of the target dynamic library project are run respectively in CPU architectures 2 to N. The respective compilation results obtained by compiling the static library during the running of the target dynamic project or the copies of the target dynamic library project are compilation results 1, compilation results 2,......, compilation results m, and compilation results N respectively.

[0119] In the embodiments of the present application, running the target dynamic library project and copies of the target dynamic library project in parallel in each CPU architecture can improve the compilation efficiency of the static library under each CPU architecture.

[0120] In a possible implementation manner provided in the embodiments of the present application, after obtaining the respective compilation results of the target static library in each CPU architecture, it further includes:

[0121] Updating the target static library to a new target static library, and using the target static library before the update as the verified static library;

[0122] The new target static library is the other static libraries in at least one static library to be verified except the verified static library.

[0123] In the embodiments of the present application, after obtaining the respective compilation results of the target static library in each CPU architecture, the target static library can be updated to a new target static library, and the target static library before the update is used as the verified static library. The new target static library is the other static libraries in at least one static library to be verified except the verified static library. The verification process of the new target static library is the same as that in the foregoing embodiments, and the embodiments of the present application will not elaborate here.

[0124] In a possible implementation manner provided in the embodiments of the present application, the target dynamic library project is created in the following way:

[0125] Create an initial dynamic library project in a preset development tool, and the configuration items of the initial dynamic library project are initial values;

[0126] Modify the target configuration items of the initial dynamic library project to the corresponding target values; the target configuration items include version numbers and compilation options;

[0127] Determine the directory of the initial dynamic library project, create a second file under the directory, and obtain the target dynamic engineering library.

[0128] In the embodiment of the present application, a target dynamic library project can be created in a preset development tool. The preset development tool can be Xcode. Specifically, Xcode can be opened, and a new dynamic library project can be created to obtain the initial dynamic library project. The configuration items (names, version numbers, etc.) of the initial dynamic library project are initial values. The type of the initial dynamic library project can be Framework, and the name of the initial dynamic library project is TXLiteAVSDKCheckCorrectness.

[0129] After obtaining the initial dynamic library project in the embodiment of the present application, the target configuration items of the initial dynamic library are configured and modified, and the target configuration items are modified to the corresponding target values. The target configuration items can be version numbers. For example, select Target, select the TXLiteAVSDKCheckCorrectness initial dynamic library project, and set the target value of the version number Minimum Deployments in the General of the target configuration items of the initial dynamic library project to 11.0 to implement setting the latest version.

[0130] For the compilation option, in Build Settings, modify the compilation option Other Librarian Flags to the target value -all_load. -all_load is used to force the linking of all discovered object files, that is, to force the linking of the target static library and the first file of the target static library during the running process.

[0131] In addition, in the embodiment of the present application, a second file is also created under the directory of the initial dynamic library project, that is, a podfile file is created, and the target dynamic library project is obtained.

[0132] As Figure 5 shown, it exemplarily shows a flowchart of another method for verifying the runnability of a static library provided by the embodiment of the present application, including the following steps:

[0133] Step S501, download and decompress the target SDK to be released to the local platform to obtain at least one static library to be verified;

[0134] Step S502, select the target static library to be currently verified from at least one static library to be verified, and obtain the podspec file of the pre-created target static library;

[0135] Step S503: Create an initial dynamic library project in a preset development tool, and set the configuration items of the initial dynamic library project to their initial values;

[0136] Step S504: Modify the target configuration items of the initial dynamic library project to their corresponding target values; the target configuration items include the version number and compilation options;

[0137] Step S505: Determine the directory of the initial dynamic library project, and create a second file in the directory to obtain the target dynamic library project; the second file is used to set the target files currently depended on by the target dynamic library project; the second file includes the address information of the target files;

[0138] Step S506: Select the target static library to be currently verified from at least one static library to be verified;

[0139] Step S507: Add the address information of the target static library and the address information of the first file of the target static library to the second file, so as to set the target files to include the target static library and the first file of the target static library;

[0140] Step S508: Run the target dynamic library project on each CPU architecture respectively, so that the target dynamic library project reads the first file to compile the target static library, and obtain the compilation results of the target static library on each CPU architecture;

[0141] Step S509: For any CPU architecture, if it is determined that the compilation result of the target static library on the CPU architecture meets the preset conditions, it is determined that the target static library can run on the CPU architecture;

[0142] Step S510: If it is determined that the compilation result of the target static library on the CPU architecture does not meet the preset conditions, it is determined that the target static library cannot run on the CPU architecture;

[0143] Step S511: Update the target static library to a new target static library, and use the target static library before the update as the verified static library;

[0144] The new target static library is the other static libraries in at least one static library to be verified except the verified static library.

[0145] After step S508, repeat steps S507 - S511 until all the static libraries are verified.

[0146] The embodiments of the present application do not limit the order of steps S501 to S511. The above step order is one implementation manner, and the detailed implementation processes of S501 to S511 are the same as those of the foregoing embodiments, and will not be elaborated herein in the embodiments of the present application.

[0147] In an embodiment of the present application, a possible implementation is provided. Download and decompress the target SDK to be released to the local platform, including:

[0148] Run the first script to execute the first command in the first script. The first command is used to download and decompress the target SDK to be released to the local platform.

[0149] In an embodiment of the present application, the first script is pre-written. The first script can be a shell script. The first script includes the first command, and the first command can be:

[0150] "curl -O https: / / example.com / example.zip

[0151] unzip myfile.zip -d myfolder"

[0152] After executing the first command, the target SDK to be released can be downloaded and decompressed to the local platform.

[0153] Run the target dynamic library project in at least one CPU architecture respectively, including:

[0154] Run the second script to execute the second command in the second script. The second command is used to run the target dynamic library project in at least one CPU architecture respectively.

[0155] In an embodiment of the present application, the second script is pre-written. The second script can also be a shell script. The second script includes the second command. When the CPU architecture is the x86 architecture, the second command is: "xcodebuild -workspace $workspace -scheme $scheme -arch x86_64 -sdk iphonesimulator". After executing the second command, the target dynamic library project can be run in the x86 architecture. When the CPU architecture is the ARM architecture, the second command is "xcodebuild -workspace $workspace -scheme $scheme -arch ARM64 -sdk iphoneos". After executing the second command, the target dynamic library project can be run in the ARM architecture.

[0156] Set the target file currently depended on by the target dynamic library project, including:

[0157] Run the third script to execute the third command in the third script. The third command is used to set the target file currently depended on by the target dynamic library project.

[0158] In the embodiment of the present application, a third script is also pre-written. The third script can also be a shell script, and the third script includes a third command, which can be: "sed -i's / old_text / new_text / g' file.txt". After executing the third command, the target files currently depended on by the target dynamic library project can be set.

[0159] In the embodiment of the present application, the above-mentioned first script, second script, and third script can be pre-written to script each static library, and the entire verification process is automated, with simple operations.

[0160] As Figure 6 shown, it exemplarily shows a schematic diagram of another method for verifying the runnability of a static library provided by the embodiment of the present application, including: Step 1: Run the first script and execute the first command in the first script to download and decompress the target SDK to be released to the local platform, obtaining at least one static library to be verified; Step 2: Select the target static library currently being verified from the at least one static library to be verified, and obtain the first file of the target static library created in advance. The first file is used to describe the basic configuration information of the corresponding static library; Step 3: Run the third script and execute the third command in the third script to set the target files currently depended on by the target dynamic library project. The target files include the target static library and the first file of the target static library; Step 4: Run the second script and execute the second command in the second script to run the target dynamic library project in each CPU architecture respectively, so that the target dynamic library project reads the first file to compile the target static library, obtaining the compilation results of the target static library in each CPU architecture; Step 5: Determine whether the compilation results in each CPU architecture meet the preset conditions. For any CPU architecture, if it is determined that the compilation result of the target static library in the CPU architecture meets the preset conditions, it is determined that the target static library is runnable in the CPU architecture; for any CPU architecture, if it is determined that the compilation result of the target static library in the CPU architecture does not meet the preset conditions, it is determined that the target static library is not runnable in the CPU architecture; Step 6: Determine whether the target static library is the last static library to be verified. Step 7, if not, update the target static library to a new target static library; repeat the above steps 3 to 7; if so, end.

[0161] The embodiment of the present application provides a device for verifying the runnability of a static library. As Figure 7 shown, the device 70 for verifying the runnability of the static library may include:

[0162] A download module 710, configured to download and decompress the target SDK to be released to the local platform, obtaining at least one static library to be verified; the release platform of the target SDK includes at least one CPU architecture, and the local platform has the same CPU architecture as the release platform;

[0163] A selection module 720 is configured to select a target static library to be currently verified from at least one static library to be verified, and obtain a first file of the target static library created in advance, where the first file is used to describe the basic configuration information of the corresponding static library;

[0164] A dependent file setting module 730 is configured to obtain a target dynamic library project created in advance, and set target files on which the target dynamic library project currently depends, where the target files include the target static library and the first file of the target static library;

[0165] A target dynamic library project running module 740 is configured to run the target dynamic library project in each CPU architecture respectively, so that the target dynamic library project reads the first file to compile the target static library, and obtain respective compilation results of the target static library in each CPU architecture;

[0166] A runnability determination module 750 is configured to, for any CPU architecture, if it is determined that the compilation result of the target static library in the CPU architecture meets a preset condition, determine that the target static library is runnable in the CPU architecture.

[0167] In an embodiment of the present application, a possible implementation manner is provided. The runnability determination module is further configured to, for any central processing unit architecture, if it is determined that the compilation result of the target static library in the central processing unit architecture does not meet the preset condition, determine that the target static library is not runnable in the central processing unit architecture.

[0168] In an embodiment of the present application, a possible implementation manner is provided. The dependent file setting module includes:

[0169] A second file determination sub-module is configured to obtain a second file of the target dynamic library project; the second file is used to set target files on which the target dynamic library project currently depends; the second file includes address information of the target files;

[0170] An address information determination sub-module is configured to determine the address information of the target static library and the address information of the first file of the target static library;

[0171] An address information adding sub-module is configured to add the address information of the target static library and the address information of the first file of the target static library to the second file, so as to set the target files to include the target static library and the first file of the target static library.

[0172] In an embodiment of the present application, a possible implementation manner is provided. Specifically, the target dynamic library project running module is further configured to, if the number of at least one central processing unit (CPU) architecture is greater than a first preset number, run the target dynamic library project based on any one of the following methods: sequentially run the target dynamic library project in each CPU architecture; determine a second preset number based on the number of each CPU architecture, generate copies of the target dynamic library project with the second preset number, and run the target dynamic library project and the copies of the target dynamic library project in parallel in each CPU architecture.

[0173] In an embodiment of the present application, a possible implementation manner is provided. The verification device further includes:

[0174] An update module, configured to update the target static library to a new target static library, and use the target static library before the update as the verified static library; the new target static library is other static libraries in at least one static library to be verified except the verified static library.

[0175] In an embodiment of the present application, a possible implementation manner is provided. The verification device further includes: a target dynamic library project creation module, and the target dynamic library project creation module includes:

[0176] An initial dynamic library project creation sub-module, configured to create an initial dynamic library project in a preset development tool, and each configuration item of the initial dynamic library project is an initial value;

[0177] A modification sub-module, configured to modify the target configuration items of the initial dynamic library project to corresponding target values; the target configuration items include version numbers and compilation options;

[0178] A second file creation sub-module, configured to determine the directory of the initial dynamic library project, create a second file in the directory, and obtain the target dynamic project library.

[0179] In an embodiment of the present application, a possible implementation manner is provided. Specifically, the download module is configured to run a first script to execute a first command in the first script, and the first command is used to download and decompress a target software development kit to be released to a local platform;

[0180] The target dynamic library project running module is specifically configured to run a second script to execute a second command in the second script, and the second command is used to run the target dynamic library project in at least one CPU architecture respectively;

[0181] The dependent file setting module is specifically configured to run a third script to execute a third command in the third script, and the third command is used to set the target files currently dependent on the target dynamic library project.

[0182] The device according to the embodiment of the present application can execute the method provided by the embodiment of the present application, and their implementation principles are similar. The actions performed by each module in the device of each embodiment of the present application correspond to the steps in the method of each embodiment of the present application. For the detailed function description of each module of the device, reference can be specifically made to the description in the corresponding method shown above, and details will not be repeated here.

[0183] An electronic device is provided in an embodiment of the present application, including a memory, a processor, and a computer program stored on the memory. The processor executes the above computer program to implement the steps of the method for verifying the runnability of a static library. Compared with the related art, the following can be achieved: In the embodiment of the present application, by setting the target dynamic library project to depend on the target static library to be verified, the target static library is compiled as the dynamic library project runs, and the runnability of the static library under each CPU architecture can be accurately verified.

[0184] And when the number of CPU architectures is multiple, the target dynamic library project can run on multiple CPU architectures, realizing the compilation of the static library in multiple CPU architectures, that is, realizing the compilation of the static library in all CPU architectures, ensuring that the released static library can be used normally on multiple CUP architectures and ensuring that the released SDK is normal.

[0185] In an optional embodiment, an electronic device is provided, as Figure 8 shown Figure 8 The electronic device 8000 shown includes: a processor 8001 and a memory 8003. Among them, the processor 8001 and the memory 8003 are connected, such as through a bus 8002. Optionally, the electronic device 8000 may further include a transceiver 8004, and the transceiver 8004 can be used for data interaction between the electronic device and other electronic devices, such as data sending and / or data receiving, etc. It should be noted that in practical applications, the transceiver 8004 is not limited to one, and the structure of the electronic device 8000 does not constitute a limitation to the embodiment of the present application.

[0186] The processor 8001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logical blocks, modules, and circuits described in connection with the disclosure of this application. The processor 8001 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc.

[0187] The bus 8002 may include a path for transmitting information between the above components. The bus 8002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 8002 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 only a thick line is used to represent it here, but it does not mean that there is only one bus or one type of bus.

[0188] The memory 8003 may be a ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, a RAM (Random Access Memory) or other type of dynamic storage device that can store information and instructions, or it may also be an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory), or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium that can be used to carry or store computer programs and can be read by a computer, which is not limited here.

[0189] The memory 8003 is used to store the computer program for implementing the embodiments of the present application and is controlled by the processor 8001 for execution. The processor 8001 is used to execute the computer program stored in the memory 8003 to implement the steps shown in the foregoing method embodiments.

[0190] Among them, the electronic device package may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Tablet Computers), PMPs (Portable Multimedia Players), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 8 The electronic device shown is merely an example and should not impose any limitations on the functions and usage scope of the embodiments of the present disclosure.

[0191] The embodiments of the present application provide a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps and corresponding contents shown in the foregoing method embodiments can be implemented. Compared with the prior art, it can be realized that: by setting the target dynamic library project to depend on the target static library to be verified, the target static library is compiled as the dynamic library project runs, and the runnability of the static library under each CPU architecture can be accurately verified.

[0192] And when the number of CPU architectures is multiple, the target dynamic library project can run on multiple CPU architectures, realizing the compilation of the static library in multiple CPU architectures, that is, realizing the compilation of the static library in all CPU architectures, ensuring that the released static library can be normally used on multiple CUP architectures, and ensuring that the released SDK is normal.

[0193] It should be noted that the above-mentioned computer-readable medium in the present disclosure can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of the computer-readable storage medium can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, the computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or in combination with an instruction execution system, apparatus, or device. In the present disclosure, the computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, and this computer-readable signal medium can send, propagate, or transmit a program for use by or in combination with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted by any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0194] The embodiment of the present application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, it can implement the steps and corresponding contents of the foregoing method embodiment. Compared with the prior art, it can be achieved that: in the embodiment of the present application, by setting the target dynamic library project to depend on the target static library to be verified, the target static library is compiled as the dynamic library project runs, and the runnability of the static library under each CPU architecture can be accurately verified.

[0195] And when the number of CPU architectures is multiple, the target dynamic library project can run on multiple CPU architectures, realizing the compilation of the static library in multiple CPU architectures, that is, realizing the compilation of the static library in all CPU architectures, ensuring that the released static library can be normally used on multiple CUP architectures, and ensuring that the released SDK is normal.

[0196] The terms "first", "second", "third", "fourth", "1", "2", etc. (if any) in the description, claims and the above-mentioned drawings of the present application are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present application described herein can be implemented in an order other than the illustrated or described order.

[0197] It should be understood that although the flowchart of the embodiments of the present application indicates each operation step by an arrow, the execution order of these steps is not limited to the order indicated by the arrow. Unless otherwise clearly stated in this document, in some implementation scenarios of the embodiments of the present application, the implementation steps in each flowchart can be executed in other orders according to requirements. In addition, some or all of the steps in each flowchart may include multiple sub-steps or multiple stages based on the actual implementation scenario. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage among these sub-steps or stages can also be executed at different times respectively. In the scenario where the execution times are different, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and the embodiments of the present application do not limit this.

[0198] The above are only optional implementation manners of some implementation scenarios of the present application. It should be noted that for those of ordinary skill in the art, without departing from the technical concept of the solution of the present application, using other similar implementation means based on the technical idea of the present application also belongs to the protection scope of the embodiments of the present application.

Claims

1. A method for verifying the runnability of a static library, characterized in that, it includes: Download and decompress the target software development kit to be released to the local platform to obtain at least one static library to be verified; The release platform of the target software development kit includes at least one central processing unit architecture, and the local platform has the same central processing unit architecture as the release platform; Select the target static library to be currently verified from at least one static library to be verified, and obtain the first file of the target static library created in advance, where the first file is used to describe the basic configuration information of the corresponding static library; Obtain the pre-created target dynamic library project, and set the target files currently depended on by the target dynamic library project, where the target files include the target static library and the first file of the target static library; Run the target dynamic library project respectively in each central processing unit architecture, so that the target dynamic library project reads the first file to compile the target static library, and obtain the respective compilation results of the target static library in each central processing unit architecture; For any one central processing unit architecture, if it is determined that the compilation result of the target static library in the central processing unit architecture meets the preset conditions, it is determined that the target static library is runnable in the central processing unit architecture.

2. The method according to claim 1, characterized in that, after obtaining the respective compilation results of the target static library in each central processing unit architecture, it further includes: For any one central processing unit architecture, if it is determined that the compilation result of the target static library in the central processing unit architecture does not meet the preset conditions, it is determined that the target static library is not runnable in the central processing unit architecture.

3. The method according to claim 1, characterized in that, the setting of the target files currently depended on by the target dynamic library project includes: Obtain the second file of the target dynamic library project; the second file is used to set the target files currently depended on by the target dynamic library project; the address information of the target files is included in the second file; Determine the address information of the target static library and the address information of the first file of the target static library; Add the address information of the target static library and the address information of the first file of the target static library to the second file, so as to set the target files to include the target static library and the first file of the target static library.

4. The method according to claim 1, characterized in that, the running of the target dynamic library project respectively in the at least one central processing unit architecture includes: If the number of the at least one central processing unit architecture is greater than the first preset number, the target dynamic library project is run based on any one of the following methods: Run the target dynamic library project in each central processing unit architecture in sequence; Based on the number of each central processing unit architecture, determine the second preset number, generate copies of the target dynamic library project with the second preset number, and run the target dynamic library project and the copies of the target dynamic library project in parallel in each central processing unit architecture.

5. The method according to claim 1, characterized in that, After obtaining the compilation results of the target static library in each central processing unit architecture, the following steps are further included: Update the target static library to a new target static library, and use the target static library before the update as the verified static library; The new target static library is the other static libraries in the at least one static library to be verified except the verified static library.

6. The method according to claim 3, wherein, The target dynamic library project is created by the following method: Create an initial dynamic library project in a preset development tool, and the configuration items of the initial dynamic library project are initial values; Modify the target configuration items of the initial dynamic library project to corresponding target values; the target configuration items include version numbers and compilation options; Determine the directory of the initial dynamic library project, and create a second file under the directory to obtain the target dynamic library project.

7. The method according to claim 4, wherein, Downloading and decompressing the target software development kit to be released to the local platform includes: Running a first script to execute a first command in the first script, where the first command is used to download and decompress the target software development kit to be released to the local platform; Running the target dynamic library project in each of the at least one central processing unit architecture respectively includes: Running a second script to execute a second command in the second script, where the second command is used to run the target dynamic library project in each of the at least one central processing unit architecture respectively; Setting the target files currently depended on by the target dynamic library project includes: Running a third script to execute a third command in the third script, where the third command is used to set the target files currently depended on by the target dynamic library project.

8. A verification device for the runnability of a static library, wherein, It includes: A download module, configured to download and decompress the target software development kit to be released to the local platform to obtain at least one static library to be verified; The release platform of the target software development kit includes at least one central processing unit architecture, and the local platform has the same central processing unit architecture as the release platform; A selection module, configured to select the target static library currently being verified from at least one static library to be verified, and obtain a first file of the target static library created in advance, where the first file is used to describe the basic configuration information of the corresponding static library; A dependent file setting module, configured to obtain a pre-created target dynamic library project, and set the target files currently depended on by the target dynamic library project, where the target files include the target static library and the first file of the target static library; A target dynamic library project running module, configured to run the target dynamic library project in each central processing unit architecture respectively, so that the target dynamic library project reads the first file to compile the target static library, and obtain the compilation results of the target static library in each central processing unit architecture; A runnability determination module, configured to determine that the target static library is runnable in the central processing unit (CPU) architecture if it is determined that the compilation result of the target static library in the CPU architecture meets a preset condition for any CPU architecture.

9. An electronic device, comprising a memory, a processor, and a computer program stored on the memory, wherein, the processor executes the computer program to implement the steps of the method according to any one of claims 1-7.

10. A computer-readable storage medium, having stored thereon a computer program, wherein, the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1-7.

11. A computer program product, comprising a computer program, wherein, the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1-7.

Images