CN115145627A

CN115145627A - Method, device, equipment and storage medium for building local operation environment of plug-in

Info

Publication number: CN115145627A
Application number: CN202210748630.1A
Authority: CN
Inventors: 宋泽阳; 郭彪
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2022-06-28
Filing date: 2022-06-28
Publication date: 2022-10-04

Abstract

The disclosure provides a method, a device, equipment and a storage medium for building a local operation environment of a plug-in, and relates to the field of plug-in services. The method comprises the following steps: extracting resource data of the target plug-in by using a first tool to obtain a first file; converting the first file into a file in a JAR format by using a second tool to obtain a second file; converting the second file into a file with a target format by using a third tool to obtain a third file so as to construct a target code based on the third file; in response to determining that the object code has been built, add the object code to the application package of the object plug-in using a fourth tool. The method for building the local operation environment of the plug-in improves building efficiency of the local operation environment of the plug-in, and further improves development efficiency.

Description

Method, device, equipment and storage medium for building local operation environment of plug-in

Technical Field

The disclosure relates to the field of plug-in services, and in particular, to a method, an apparatus, a device and a storage medium for building a local operating environment of a plug-in.

Background

Plug-ins (Plug-ins, also known as addins, add-ins, addons, or add-ons, also known as Plug-ins) are programs written in an application program interface that conforms to a certain specification. It can only run under the system platform (possibly supporting multiple platforms simultaneously) specified by the program, and cannot run independently from the specified platform. Since the plug-in needs to call the function library or data provided by the original clean system. Many software has plug-ins, and there are numerous types of plug-ins. The plug-in generally needs to be dynamically issued by the server and highly depends on the host Application (App) environment, and a plug-in developer needs to perform steps of cloud compiling, platform configuration, dynamic issuing and the like after performing function iteration to test a new function, so that the overall process is long.

Disclosure of Invention

The disclosure provides a method, a device, equipment and a storage medium for building a local operation environment of a plug-in.

According to a first aspect of the disclosure, a method for building a local operation environment of a plug-in is provided, which includes: extracting resource data of the target plug-in by using a first tool to obtain a first file; converting the first file into a file in a JAR format by using a second tool to obtain a second file; converting the second file into a file in a target format by using a third tool to obtain a third file so as to construct a target code based on the third file; in response to determining that the object code has been built, add the object code to the application package of the target plug-in using the fourth tool.

According to a second aspect of the present disclosure, there is provided a device for building a local operating environment of a plug-in, including: the extraction module is configured to extract the resource data of the target plug-in by using a first tool to obtain a first file; a first conversion module configured to convert the first file into a file in a JAR format using a second tool, resulting in a second file; a second conversion module configured to convert the second file into a file in a target format by using a third tool, so as to obtain a third file, and construct a target code based on the third file; an add module configured to add the object code to the application package of the target plug-in using a fourth tool in response to determining that the object code has been constructed.

According to a third aspect of the present disclosure, there is provided an electronic device comprising: 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 as described in any implementation manner of the first aspect.

According to a fourth aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing a computer to perform the method as described in any one of the implementations of the first aspect.

According to a fifth aspect of the present disclosure, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the method as described in any of the implementations of the first aspect.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The drawings are included to provide a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:

FIG. 1 is an exemplary system architecture diagram in which the present disclosure may be applied;

FIG. 2 is a flow diagram of one embodiment of a method of building a plug-in local runtime environment according to the present disclosure;

FIG. 3 is a flow diagram of another embodiment of a method of building a native runtime environment for plug-ins according to the present disclosure;

FIG. 4 is a plug-in native runtime environment according to the present disclosure a flow chart of yet another embodiment of the method of construction of (a);

FIG. 5 is an application scenario diagram of a method for building a native runtime environment for plug-ins according to the present disclosure;

FIG. 6 is a schematic structural diagram of one embodiment of a building apparatus of a local runtime environment of a plug-in according to the present disclosure;

fig. 7 is a block diagram of an electronic device for implementing the method for building the local plug-in operating environment according to the embodiment of the present disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

It should be noted that, in the present disclosure, the embodiments and features of the embodiments may be combined with each other without conflict. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.

Fig. 1 shows an exemplary system architecture 100 to which an embodiment of the method for building a plug-in native runtime environment or the device for building a plug-in native runtime environment of the present disclosure can be applied.

As shown in fig. 1, the system architecture 100 may include

terminal devices

101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the

terminal devices

101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.

A user may use

terminal devices

101, 102, 103 to interact with a server 105 over a network 104 to receive or transmit information or the like. Various client applications may be installed on the

terminal devices

101, 102, 103.

The

terminal devices

101, 102, 103 may be hardware or software. When the

terminal devices

101, 102, 103 are hardware, they may be various electronic devices including, but not limited to, smart phones, tablet computers, laptop portable computers, desktop computers, and the like. When the

terminal apparatuses

101, 102, 103 are software, they can be installed in the above-described electronic apparatuses. It may be implemented as a plurality of software or software modules or as a single software or software module. And is not particularly limited herein.

The server 105 may provide various services. For example, the server 105 may analyze and process the resource file of the target plug-in acquired from the

terminal apparatus

101, 102, 103 and generate a processing result (e.g., add the target code to the application package of the target plug-in).

The server 105 may be hardware or software. When the server 105 is hardware, it may be implemented as a distributed server cluster composed of a plurality of servers, or may be implemented as a single server. When the server 105 is software, it may be implemented as multiple pieces of software or software modules (e.g., to provide distributed services), or as a single piece of software or software module. And is not particularly limited herein.

It should be noted that the method for building the local plug-in operating environment provided by the embodiment of the present disclosure is generally executed by the server 105, and accordingly, the building device of the local plug-in operating environment is generally disposed in the server 105.

It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for an implementation.

With continued reference to FIG. 2, a flow 200 of one embodiment of a method of building a native runtime environment for plug-ins according to the present disclosure is shown. The method for building the local operation environment of the plug-in comprises the following steps:

step 201, extracting resource data of the target plug-in by using a first tool to obtain a first file.

In this embodiment, an execution main body (for example, the server 105 shown in fig. 1) of the method for building the local runtime environment of the plug-in may extract resource data of a target plug-in by using a first tool, so as to obtain a first file, where the target plug-in is the plug-in to be built the local runtime environment in this embodiment. After the target plug-in is determined, the execution main body extracts resource data of the target plug-in by using a first tool, so as to obtain a first file, where the first file includes resource files of the target plug-in, such as a dex file, a resource file, a manifest file, and the like, where the dex file is an executable file of an Android (Android) system and includes all operation instructions and runtime data of an application program, the resource file is a resource folder, and the manifest file is an Android development folder, and can run codes of any application program.

The first tool here may be a tool for extracting resources of a target plug-in, for example, the first tool may be an apktool, the apktool is an Android software package decompiling tool, and generally, the apk may be used to parse apk (Android application package), modify some resource files, or add own codes to reconstruct a new apk. The resource data of the target plug-in can be extracted by using the apktool, so that a first file is obtained.

Step 202, converting the first file into a file in a JAR format by using a second tool to obtain a second file.

In this embodiment, the execution body converts the first file into a file in the JAR format by using a second tool, so as to obtain a second file. Since the dex file, the resource file, the manifest file, and the like in the first file obtained in step 201 are in binary format and cannot be directly viewed, the execution entity converts the first file into a file in JAR format, that is, converts the binary file into a file in JAR format.

It should be noted that, in the software field, JAR (Java Archive) is a software package file format, and is generally used for aggregating a large number of Java class files, related metadata and resource (text, picture, etc.) files into one file so as to develop Java platform application software or library.

The second tool is a tool capable of converting a binary file into a file in a JAR format, for example, the second tool may be dex2JAR, and the dex2JAR tool mainly converts a dex file into a JAR file containing a class file. That is, the execution body may convert the first file into a file in the JAR format using dex2JAR, thereby obtaining a second file.

And step 203, converting the second file into a file in a target format by using a third tool to obtain a third file, so as to construct a target code based on the third file.

In this embodiment, the execution body converts the second file into a file in a target format by using a third tool, so as to obtain a third file, so that the relevant developer constructs the target code based on the third file. Since the JAR-formatted file can be directly executed by a JVM (Java Virtual Machine), but cannot be directly viewed by a developer, the execution body converts the second file into a target-formatted file by using a third tool, that is, converts the Machine language into a format readable by the developer, so that the developer can view and read the code file, and determines the logic loaded by the target plug-in based on the code file, thereby constructing a code that enables the target plug-in to run locally.

The third tool may convert the file in JAR format into a file in a readable format, for example, the third tool may be jadx, which is a decompilation software having a graphical interface and a drag-and-drop operation and capable of decompilating and outputting Java code. That is, the execution subject may convert the second file into a file in an object format by using jadx, so as to obtain a third file, so that the developer may build the object code based on the third file.

In response to determining that the object code has been constructed, the object code is added to the application package of the object plug-in using the fourth tool, step 204.

In this embodiment, the executing entity obtains the object code when it is determined that the object code is completely constructed, and adds the object code to a specified position in an application package of the object plug-in by using a fourth tool, so as to logically bypass verification and loading of the object plug-in, thereby completing construction of a local operating environment of the object plug-in, and at this time, a locally prepared plug-in may be loaded.

The fourth tool may be a tool for adding the constructed code to an Application package of the plug-in, for example, the fourth tool may be an Android Transform Api (Application Programming Interface), which allows a third-party plug-in to dynamically modify a corresponding file before the software is packaged into a dex file. That is, the execution main body may write a code in an Android software engineering by using an Android Transform Api, and insert the code into a specified position.

According to the method for building the local operation environment of the plug-in, the resource data of the target plug-in are extracted by using a first tool to obtain a first file; then converting the first file into a file in a JAR format by using a second tool to obtain a second file; then, converting the second file into a file in a target format by using a third tool to obtain a third file so as to construct a target code based on the third file; finally, in response to determining that the object code has been built, the object code is added to the application package of the object plug-in using a fourth tool. According to the method for building the local operation environment of the plug-in, the cloud strategy and dependence are separated, the local operation environment can be built for the target plug-in quickly, building efficiency of the local operation environment of the plug-in is improved, and development efficiency is improved.

In the technical scheme of the disclosure, the processes of collecting, storing, using, processing, transmitting, providing, disclosing and the like of the personal information of the related user all accord with the regulations of related laws and regulations, and do not violate the common customs of public order.

With continued reference to FIG. 3, FIG. 3 shows a flow 300 of another embodiment of a method of building a native runtime environment for plug-ins according to the present disclosure. The method for building the local operation environment of the plug-in comprises the following steps:

step 301, extracting resource data of the target plug-in by using a first tool to obtain a first file.

Step 302, converting the first file into a file in a JAR format by using a second tool to obtain a second file.

Step 303, converting the second file into a file in a target format by using a third tool to obtain a third file, so as to construct a target code based on the third file.

Steps 301 to 303 are substantially the same as steps 201 to 203 in the foregoing embodiment, and the specific implementation manner may refer to the foregoing description of steps 201 to 203, which is not described herein again.

And step 304, acquiring the application program package of the target plug-in.

In this embodiment, an execution subject (for example, the server 105 shown in fig. 1) of the method for building the plug-in local running environment may obtain the application package apk of the target plug-in. apk is an application package file format used by the Android operating system for distributing and installing mobile applications and middleware. The code of an Android application program is required to be run on an Android device, and must be compiled first and then packaged into a file which can be recognized by an Android system to be run, and the file format which can be recognized and run by the Android system is 'apk'. One apk file contains compiled code files (. Dex files), file resources (resources), native resource files (assets), certificates (certifies), manifest files (manifest files), and the like.

And 305, compiling the application program package to obtain a compiled binary file.

In this embodiment, the execution entity compiles the obtained apk to obtain a compiled binary file. Here, the execution body may compile the apk file using an aapt (Android Asset Packaging Tool) Tool, so as to obtain an r.java file, where the r.java file is used to define indexes of all types of resources in the Android program.

And step 306, compiling the binary file by using a preset compiler to obtain a compiled byte code file.

In this embodiment, the execution body compiles the binary file by using a preset compiler to obtain a compiled bytecode file. Since step 305 generates an r.java file, the execution subject uses a Java compiler to compile the binary file obtained in step 305, so as to obtain a compiled class file, that is, a bytecode file. The insertion file of the target code is determined through the steps, so that the replacement of the original logic in the application program package of the plug-in can be completed.

Step 307, in response to determining that the object code has been constructed, a bytecode file is obtained.

In this embodiment, the executing entity may obtain the bytecode file obtained in step 306 when it is determined that the target code has been constructed.

Step 308, add the object code to the bytecode file using a fourth tool.

In this embodiment, the execution body adds the object code to the bytecode file using a fourth tool. The Android Transform Api allows the corresponding class file to be dynamically modified in the form of a third-party plug-in before software is packaged into a dex file. And Javasist is an open source class library for editing and creating Java byte codes, and the logic of software can be dynamically modified on the basis of not modifying the original codes through the technology. Based on the above, the execution main body can complete the context construction of the plug-in loading logic by using Android Transform Api and Javasist, and insert the constructed object code into the class file, so that the logic bypass is performed on the verification and loading of the remote plug-in, and the locally prepared plug-in can be loaded at the same time.

As can be seen from fig. 3, compared with the embodiment corresponding to fig. 2, the method for building the local plug-in operating environment in the embodiment highlights the step of adding the target code, and improves the building efficiency of the local plug-in operating environment, so that plug-in developers can quickly verify after the development is completed, links of cloud end linkage are saved, and the development efficiency is improved.

With continued reference to FIG. 4, FIG. 4 illustrates a flow 400 of yet another embodiment of a method of building a native runtime environment for plug-ins according to the present disclosure. The method for building the local operation environment of the plug-in comprises the following steps:

step 401, importing the application package of the target plug-in into a first tool, and performing decompiling on the application package by using the first tool to obtain a compiled first file.

In this embodiment, an execution main body (for example, the server 105 shown in fig. 1) of the method for building the plug-in local running environment may import the application package into the first tool, and perform decompilation on the application package by using the first tool to obtain a compiled first file, where the first file includes an executable file. For example, the apktool may be used to extract resource data of the target plug-in, that is, the apk of the target plug-in is introduced into the apktool, the appktool is used to perform decompiling on the application package, and a dex executable file, a resource file, a manifest file, and the like included in the apk are extracted to obtain a compiled first file. Through the first tool, the application program package of the target plug-in is decompiled, so that the loading logic for reversely positioning the plug-in based on the decompiled file is realized.

Step 402, importing the executable file into a second tool, and converting the executable file from a binary format to a JAR format by using the second tool to obtain a converted second file.

In this embodiment, the second tool may be dex2JAR, that is, the execution subject may import the dex file into the dex2JAR, so that the dex2JAR converts the dex file into a file in the JAR format, thereby obtaining the second file. And converting the binary file into a file in a JAR format through a second tool so as to realize loading logic of the reverse positioning plug-in based on the file in the JAR format.

Step 403, importing the second file into the third tool, so that the third tool loads the second file and converts the second file into a file in a target format.

In this embodiment, the third tool may be jadx, which is a piece of decompilation software that has a graphical interface and a drag-and-drop operation, and can decompilate and output Java code. That is, the execution body may import the file in the JAR format into the third tool, so that the third tool loads the second file, and thus convert the file in the JAR format into the file in the target format by using jadx, so as to obtain the third file, so that the developer determines the logic loaded by the target plug-in based on the code file, and constructs the code that enables the target plug-in to run locally.

Step 404, obtaining an application package of the target plug-in.

And 405, compiling the application program package to obtain a compiled binary file.

And 406, compiling the binary file by using a preset compiler to obtain a compiled byte code file.

Step 407, in response to determining that the object code has been constructed, obtaining the bytecode file.

Step 408, add the object code to the bytecode file using a fourth tool.

Steps 404 to 408 are substantially the same as steps 304 to 308 of the foregoing embodiment, and the detailed implementation manner may refer to the foregoing description of steps 304 to 308, which is not described herein again.

As can be seen from fig. 4, compared with the embodiment corresponding to fig. 3, the method for building the local plug-in operating environment in the embodiment highlights a process of decompiling a target plug-in, thereby completing reverse positioning of the plug-in loading logic, finding out key steps of the plug-in loading logic, and improving the building efficiency of the local plug-in operating environment.

With further reference to FIG. 5, FIG. 5 illustrates an application scenario diagram of a method for building a native runtime environment for plug-ins according to the present disclosure. In the application scenario, after determining the target plug-in 501, the execution main body 502 first performs decompiling on the target plug-in 501 by using the apktool, that is, extracts resource data of the target plug-in 501, thereby obtaining a first file, where the first file includes a dex file, a resource file, a manifest file, and the like. The execution agent 502 then converts the extracted dex file into a file in JAR format using dex2JAR, thereby obtaining a second file. Then, the execution main body 502 loads the converted JAR format file by using jadx, converts the JAR format file into a target format file, that is, converts the JAR format file into a format file readable by a developer, thereby obtaining a third file, so that the developer determines a logic loaded by the target plug-in based on the third file, and constructs a target code. Finally, the execution main body 502 completes the context construction of the plug-in loading logic by using Android Transform and Javasist under the condition that the target code is determined to be completely constructed, and adds the target code to the class file of the target plug-in 501, so that the construction of the local operating environment of the target plug-in is completed, and the construction efficiency of the local operating environment of the plug-in is improved.

With further reference to fig. 6, as an implementation of the method shown in the above figures, the present disclosure provides an embodiment of a device for building a local operating environment of a plug-in, where the embodiment of the device corresponds to the embodiment of the method shown in fig. 2, and the device may be specifically applied to various electronic devices.

As shown in fig. 6, the building apparatus 600 for the plug-in local operating environment of the present embodiment includes: an extraction module 601, a first conversion module 602, a second conversion module 603 and an addition module 604. The extracting module 601 is configured to extract resource data of the target plug-in by using a first tool to obtain a first file; a first conversion module 602 configured to convert the first file into a file in JAR format by using a second tool, resulting in a second file; a second conversion module 603 configured to convert the second file into a file in a target format by using a third tool, obtain a third file, and construct a target code based on the third file; an add module 604 configured to add the object code to the application package of the target plug-in using a fourth tool in response to determining that the object code has been built.

In the embodiment, in the building device 600 of the plug-in local operating environment: the specific processing of the extracting module 601, the first converting module 602, the second converting module 603, and the adding module 604 and the technical effects thereof can refer to the related descriptions of steps 201-204 in the corresponding embodiment of fig. 2, which are not repeated herein.

In some optional implementations of this embodiment, the building apparatus 600 for the plug-in local operating environment further includes: an acquisition module configured to acquire an application package of a target plug-in; the first compiling module is configured to compile the application program package to obtain a compiled binary file; the second compiling module is configured to compile the binary file by using a preset compiler to obtain a compiled byte code file; and the adding module comprises: an obtaining submodule configured to obtain a bytecode file; an add sub-module configured to add the object code to the bytecode file using a fourth tool.

In some optional implementations of this embodiment, the extracting module includes: and the decompiling submodule is configured to import the application package into a first tool, and decompiling the application package by using the first tool to obtain a compiled first file, wherein the first file comprises an executable file.

In some optional implementations of this embodiment, the first conversion module includes: and the first conversion sub-module is configured to import the executable file into the second tool, convert the executable file from a binary format to a JAR format by using the second tool, and obtain a converted second file.

In some optional implementations of this embodiment, the second conversion module includes: and the second conversion sub-module is configured to import the second file into the third tool, so that the third tool loads the second file and converts the second file into a file in a target format.

The present disclosure also provides an electronic device, a readable storage medium, and a computer program product according to embodiments of the present disclosure.

FIG. 7 illustrates a schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 7, the device 700 comprises a computing unit 701 which may perform various suitable actions and processes according to a computer program stored in a Read Only Memory (ROM) 702 or a computer program loaded from a storage unit 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the device 700 can also be stored. The computing unit 701, the ROM 702, and the RAM 703 are connected to each other by a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

Various components in the device 700 are connected to the I/O interface 705, including: an input unit 706 such as a keyboard, a mouse, or the like; an output unit 707 such as various types of displays, speakers, and the like; a storage unit 708 such as a magnetic disk, optical disk, or the like; and a communication unit 709 such as a network card, modem, wireless communication transceiver, etc. The communication unit 709 allows the device 700 to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

Computing unit 701 may be a variety of general purpose and/or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various dedicated Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and so forth. The computing unit 701 performs the various methods and processes described above, such as the method of building a plug-in native runtime environment. For example, in some embodiments, the method of building the plug-in native operating environment can be implemented as a computer software program tangibly embodied on a machine-readable medium, such as storage unit 708. In some embodiments, part or all of a computer program may be loaded onto and/or installed onto device 700 via ROM 702 and/or communications unit 709. When loaded into RAM 703 and executed by computing unit 701, may perform one or more steps of the method of building a plug-in local runtime environment described above. Alternatively, in other embodiments, the computing unit 701 may be configured in any other suitable way (e.g., by means of firmware) to perform the method of building the plug-in native runtime environment.

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, causes the functions/acts specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, 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 compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

In order to provide for an interaction with the user, the systems and techniques described here can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user may provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in a computing system that includes a back-end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: local Area Networks (LANs), wide Area Networks (WANs), and the Internet.

Cloud computing (cloud computer) refers to a technology architecture that accesses a flexibly extensible shared physical or virtual resource pool through a network, where the resource may include a server, an operating system, a network, software, an application or a storage device, and the like, and can be deployed and managed in an on-demand and self-service manner. Through the cloud computing technology, high-efficiency and strong data processing capacity can be provided for technical application and model training of artificial intelligence, block chains and the like.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server with a combined blockchain.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present disclosure may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein.

The above detailed description should not be construed as limiting the scope of the disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made in accordance with design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims

1. A method for building a local operation environment of a plug-in comprises the following steps:

extracting resource data of the target plug-in by using a first tool to obtain a first file;

converting the first file into a file in a JAR format by using a second tool to obtain a second file;

converting the second file into a file in a target format by using a third tool to obtain a third file so as to construct a target code based on the third file;

in response to determining that the object code has been built, adding the object code to an application package of the object plug-in using a fourth tool.

2. The method of claim 1, further comprising:

acquiring an application program package of the target plug-in;

compiling the application program package to obtain a compiled binary file;

compiling the binary file by using a preset compiler to obtain a compiled byte code file; and

the adding the object code to the application package of the object plug-in by using a fourth tool comprises:

acquiring the byte code file;

adding the object code to the bytecode file using a fourth tool.

3. The method of claim 2, wherein the extracting resource data of the target plug-in using the first tool to obtain the first file comprises:

and importing the application program package into a first tool, and performing decompilation on the application program package by using the first tool to obtain a compiled first file, wherein the first file comprises an executable file.

4. The method of claim 3, wherein converting the first file into a file in a JAR format using a second tool to obtain a second file comprises:

and importing the executable file into a second tool, and converting the executable file from a binary format into a JAR format by using the second tool to obtain a converted second file.

5. The method of claim 4, wherein said converting the second file into a file in a target format using a third tool, resulting in a third file, comprises:

and importing the second file into the third tool so that the third tool loads the second file and converts the second file into a file in a target format.

6. A device for building a local operation environment of a plug-in comprises:

the extraction module is configured to extract the resource data of the target plug-in by using a first tool to obtain a first file;

a first conversion module configured to convert the first file into a file in a JAR format using a second tool, resulting in a second file;

a second conversion module configured to convert the second file into a file in a target format by using a third tool, so as to obtain a third file, and construct a target code based on the third file;

an add module configured to add the object code to an application package of the object plug-in using a fourth tool in response to determining that the object code has been constructed.

7. The apparatus of claim 6, further comprising:

an obtaining module configured to obtain an application package of the target plug-in;

the first compiling module is configured to compile the application program package to obtain a compiled binary file;

the second compiling module is configured to compile the binary file by using a preset compiler to obtain a compiled byte code file; and

the adding module comprises:

an obtaining submodule configured to obtain the bytecode file;

an adding submodule configured to add the object code to the bytecode file using a fourth tool.

8. The apparatus of claim 7, wherein the extraction module comprises:

the decompiling sub-module is configured to import the application package into a first tool, and decompile the application package by using the first tool to obtain a compiled first file, wherein the first file comprises an executable file.

9. The apparatus of claim 8, wherein the first conversion module comprises:

and the first conversion sub-module is configured to import the executable file into a second tool, convert the executable file from a binary format to a JAR format by using the second tool, and obtain a converted second file.

10. The apparatus of claim 9, wherein the second conversion module comprises:

a second conversion sub-module configured to import the second file into the third tool, so that the third tool loads the second file and converts the second file into a file in a target format.

11. An electronic device, comprising:

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 any one of claims 1-5.

12. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-5.

13. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-5.