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

Abstract

The present disclosure provides a plugin local runtime environment building method and device, equipment and storage medium, and relates to the field of plugin services. The method comprises the following steps: extracting resource data of a target plugin by using a first tool to obtain a first file; converting the first file into a JAR format file by using a second tool to obtain a second file; converting the second file into a target format file by using a third tool to obtain a third file, and constructing target code based on the third file; and adding the target code into an application package of the target plugin by using a fourth tool in response to determining that the target code has been constructed. The plugin local runtime environment building method provided by the present disclosure improves the building efficiency of the plugin local runtime environment, and further improves the development efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of plug-in services, and in particular to methods, apparatus, devices and storage media for building a local runtime environment for plug-ins. Background Technology

[0002] A plugin (also known as an addin, addon, or add-on, or plug-in) is a program written according to a specific application programming interface (API). It can only run on the system platform specified by the program (and may support multiple platforms simultaneously), and cannot run independently of a designated platform. This is because plugins need to call function libraries or data provided by the original clean system. Many software programs have plugins, and there are countless types of plugins. Plugins generally require dynamic distribution from a server, and they are highly dependent on their host application environment. Plugin developers need to perform cloud compilation, platform configuration, and dynamic distribution steps after iterating on features before they can test new features, making the overall process lengthy. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, and storage medium for building a local runtime environment for plugins.

[0004] According to a first aspect of this disclosure, a method for building a local runtime environment for a plugin is provided, comprising: using a first tool to extract resource data of a target plugin to obtain a first file; using a second tool to convert the first file into a JAR format file to obtain a second file; using a third tool to convert the second file into a target format file to obtain a third file, thereby building target code based on the third file; and in response to determining that the target code has been built, using a fourth tool to add the target code to the application package of the target plugin.

[0005] According to a second aspect of this disclosure, an apparatus for building a local runtime environment for a plugin is provided, comprising: an extraction module configured to extract resource data of a target plugin using a first tool to obtain a first file; a first conversion module configured to convert the first file into a JAR format file using a second tool to obtain a second file; a second conversion module configured to convert the second file into a target format file using a third tool to obtain a third file, for constructing target code based on the third file; and an adding module configured to add the target code to the application package of the target plugin using a fourth tool in response to determining that the target code has been constructed.

[0006] According to a third aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a method as described in any implementation of the first aspect.

[0007] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing a computer to perform a method as described in any implementation of the first aspect.

[0008] According to a fifth aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0011] Figure 1 This is an exemplary system architecture diagram to which this disclosure can be applied;

[0012] Figure 2 This is a flowchart of an embodiment of the method for building a local runtime environment for a plugin according to the present disclosure;

[0013] Figure 3 This is a flowchart of another embodiment of the method for building a local runtime environment for a plugin according to the present disclosure;

[0014] Figure 4 This is a flowchart of yet another embodiment of the method for building a local runtime environment for a plugin according to the present disclosure;

[0015] Figure 5 This is an application scenario diagram based on the method for building a local runtime environment for plugins disclosed herein;

[0016] Figure 6 This is a schematic diagram of a structure of an embodiment of the plug-in local runtime environment building apparatus according to the present disclosure;

[0017] Figure 7 This is a block diagram of an electronic device used to implement the plug-in local runtime environment construction method of the embodiments of this disclosure. Detailed Implementation

[0018] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0019] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] Figure 1 An exemplary system architecture 100 is shown, which can be applied to an embodiment of the method or apparatus for building a plugin local runtime environment disclosed herein.

[0021] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0022] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send information, etc. Various client applications can be installed on terminal devices 101, 102, and 103.

[0023] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules, or as a single software program or software module. No specific limitations are made here.

[0024] Server 105 can provide various services. For example, server 105 can analyze and process the resource files of the target plugin obtained from terminal devices 101, 102, and 103, and generate processing results (such as adding the target code to the application package of the target plugin).

[0025] It should be noted that server 105 can be either hardware or software. When server 105 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 105 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0026] It should be noted that the method for building a local runtime environment for a plugin provided in this embodiment is generally executed by the server 105, and correspondingly, the device for building a local runtime environment for a plugin is generally located in the server 105.

[0027] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0028] Continue to refer to Figure 2 This illustrates a flow 200 of an embodiment of a method for building a plugin local runtime environment according to the present disclosure. The method for building the plugin local runtime environment includes the following steps:

[0029] Step 201: Use the first tool to extract the resource data of the target plugin to obtain the first file.

[0030] In this embodiment, the execution body of the method for building the plugin's local runtime environment (e.g.) Figure 1 The server 105 shown can use the first tool to extract the resource data of the target plugin, thereby obtaining the first file. The target plugin is the plugin for which the local runtime environment is to be built in this embodiment. After determining the target plugin, the execution entity will use the first tool to extract the resource data of the target plugin, thereby obtaining the first file. The first file contains the resource files of the target plugin, such as dex files, resource files, manifest files, etc. Among them, the dex file is an executable file of the Android system, which contains all the operation instructions and runtime data of the application. The resource file is the resource folder, and the manifest file is the Android development folder, which can run the code of any application.

[0031] The first tool here refers to any tool that can extract resources from the target plugin. For example, the first tool could be apktool, an Android package decompiler. It's typically used to parse APKs (Android application packages), modify resource files, add custom code, and then rebuild the APK. apktool can be used to extract the resource data of the target plugin, thus obtaining the first file.

[0032] Step 202: Use the second tool to convert the first file into a JAR file to obtain the second file.

[0033] In this embodiment, the execution entity uses a second tool to convert the first file into a JAR file, thereby obtaining the second file. Since the dex file, resource file, manifest file, etc. in the first file obtained in step 201 are all in binary format and cannot be viewed directly, the execution entity converts the first file into a JAR file, that is, converts the binary file into a JAR file.

[0034] It should be noted that in the software field, JAR (Java Archive) is a software package file format, typically used to aggregate a large number of Java class files, related metadata, and resource files (text, images, etc.) into one file for the development of Java platform applications or libraries.

[0035] The second tool is one that can convert binary files into JAR format files. For example, the second tool could be dex2jar, which primarily converts dex files into JAR files containing class files. In other words, the aforementioned executable can use dex2jar to convert the first file into a JAR format file, thus obtaining the second file.

[0036] Step 203: Use a third tool to convert the second file into a target format file to obtain a third file, and build the target code based on the third file.

[0037] In this embodiment, the execution entity uses a third tool to convert the second file into a target format file, thereby obtaining a third file. This allows relevant developers to build the target code based on the third file. Since JAR format files can be directly executed by the JVM (Java Virtual Machine), but cannot be directly viewed by developers, the execution entity uses a third tool to convert the second file into a target format file. This involves converting machine language into a format readable by developers, allowing them to view and read the code file. Based on this code file, they can determine the loading logic of the target plugin and build code that enables the target plugin to run locally.

[0038] The third tool can convert JAR files into a readable format. For example, this third tool could be jadx, a decompiler with a graphical interface, drag-and-drop functionality, and the ability to decompile and output Java code. In other words, the execution entity mentioned above can use jadx to convert the second file into the target format, thus obtaining the third file, which developers can then use to build the target code.

[0039] Step 204: In response to determining that the target code has been built, the target code is added to the application package of the target plugin using the fourth tool.

[0040] In this embodiment, the execution entity will obtain the target code after confirming that the target code has been built, and use the fourth tool to add the target code to a specified location in the application package of the target plugin, thereby logically bypassing the verification and loading of the target plugin, thus completing the construction of the local running environment of the target plugin, at which point the locally prepared plugin can be loaded.

[0041] The fourth tool is one that adds the built code to the plugin's application package. For example, this fourth tool could be the Android Transform API (Application Programming Interface). The Android Transform API allows third-party plugins to dynamically modify corresponding files before the software is packaged into a dex file. In other words, the aforementioned execution entity can use the Android Transform API to write code in the Android software project and insert that code at a specified location.

[0042] The method for building a local runtime environment for a plugin provided in this embodiment first uses a first tool to extract resource data of the target plugin to obtain a first file; then uses a second tool to convert the first file into a JAR file to obtain a second file; next, uses a third tool to convert the second file into a target format file to obtain a third file, and builds target code based on the third file; finally, in response to determining that the target code has been built, uses a fourth tool to add the target code to the application package of the target plugin. This method for building a local runtime environment for a plugin in this embodiment is independent of cloud strategies and dependencies, and can quickly build a local runtime environment for the target plugin, thereby improving the efficiency of building the local runtime environment for the plugin and thus improving development efficiency.

[0043] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0044] Continue to refer to Figure 3 , Figure 3 A flow 300 is shown as another embodiment of the method for setting up a plugin local runtime environment according to this disclosure. The method for setting up the plugin local runtime environment includes the following steps:

[0045] Step 301: Use the first tool to extract the resource data of the target plugin to obtain the first file.

[0046] Step 302: Use the second tool to convert the first file into a JAR file to obtain the second file.

[0047] Step 303: Use a third tool to convert the second file into a target format file to obtain a third file, and build the target code based on the third file.

[0048] Steps 301-303 are basically the same as steps 201-203 in the aforementioned embodiments. For specific implementation methods, please refer to the aforementioned description of steps 201-203, which will not be repeated here.

[0049] Step 304: Obtain the application package of the target plugin.

[0050] In this embodiment, the execution body of the method for building the plugin's local runtime environment (e.g.) Figure 1The server 105 shown will obtain the target plugin's application package (APK). APK is an application package file format used by the Android operating system for distributing and installing mobile applications and middleware. For an Android application's code to run on an Android device, it must first be compiled and then packaged into a file that the Android system can recognize and run. This file format that the Android system can recognize and run is called an "APK". An APK file contains compiled code files (.dex files), file resources, native resource files (assets), certificates, and a manifest file, etc.

[0051] Step 305: Compile the application package to obtain the compiled binary file.

[0052] In this embodiment, the aforementioned execution entity compiles the acquired APK file to obtain a compiled binary file. Here, the execution entity can use the aapt (Android Asset Packaging Tool) tool to compile the APK file, thereby obtaining an R.java file. The R.java file is used to define the indexes of all types of resources in the Android program.

[0053] Step 306: Compile the binary file using the default compiler to obtain the compiled bytecode file.

[0054] In this embodiment, the execution entity uses a preset compiler to compile the binary file, thereby obtaining a compiled bytecode file. Since step 305 generates the R.java file, the execution entity uses a Java compiler to compile the binary file obtained in step 305, thereby obtaining a compiled .class file, i.e., a bytecode file. By determining the insertion file for the target code through the above steps, the original logic in the plugin's application package can be replaced.

[0055] Step 307: In response to determining that the target code has been built, obtain the bytecode file.

[0056] In this embodiment, the execution entity will obtain the bytecode file obtained in step 306 after determining that the target code has been constructed.

[0057] Step 308: Use the fourth tool to add the target code to the bytecode file.

[0058] In this embodiment, the execution entity uses a fourth tool to add target code to the bytecode file. Since the Android Transform API allows dynamic modification of the corresponding .class file before the software is packaged into a dex file as a third-party plugin, and Javasist is an open-source library for editing and creating Java bytecode, this technology allows for dynamic modification of software logic without altering the original code. Based on this, the execution entity can utilize the Android Transform API and Javasist to construct the context for plugin loading logic and insert the constructed target code into the .class file, thereby bypassing remote plugin verification and loading logic, and simultaneously loading locally prepared plugins.

[0059] from Figure 3 It can be seen from this that, with Figure 2 Compared to the corresponding embodiments, the method for building a local runtime environment for plugins in this embodiment emphasizes the step of adding target code, improves the efficiency of building a local runtime environment for plugins, and helps plugin developers to quickly verify after development, saving the cloud linkage process and improving development efficiency.

[0060] Continue to refer to Figure 4 , Figure 4 A flow 400 is shown as another embodiment of the method for setting up a plugin local runtime environment according to the present disclosure. The method for setting up the plugin local runtime environment includes the following steps:

[0061] Step 401: Import the application package of the target plugin into the first tool, and use the first tool to decompile the application package to obtain the compiled first file.

[0062] In this embodiment, the execution body of the method for building the plugin's local runtime environment (e.g.) Figure 1 The server 105 shown imports the application package into a first tool, which then decompiles the application package to obtain a compiled first file, which contains an executable file. For example, apktool can be used to extract the resource data of a target plugin. This involves importing the target plugin's APK into apktool, decompiling the application package using apktool, and extracting the dex executable file, resource files, manifest file, etc., contained within the APK to obtain the compiled first file. The first tool enables the decompilation of the target plugin's application package, allowing for the reverse location of the plugin's loading logic based on the decompiled file.

[0063] Step 402: Import the executable file into the second tool, and use the second tool to convert the executable file from binary format to JAR format to obtain the converted second file.

[0064] In this embodiment, the second tool can be dex2jar. That is, the aforementioned execution entity can import the dex file into dex2jar, so that dex2jar can convert the dex file into a JAR format file, thereby obtaining the second file. The second tool achieves the conversion of binary files into JAR format files, enabling the loading logic of the JAR-based file reverse positioning plugin.

[0065] Step 403: Import the second file into the third tool so that the third tool can load the second file and convert it into the target format.

[0066] In this embodiment, the third tool can be jadx, a decompiler with a graphical interface, drag-and-drop operation, and the ability to decompile and output Java code. That is, the aforementioned execution entity can import a JAR file into the third tool, causing the third tool to load the second file. Jadx then converts the JAR file into the target format, resulting in the third file. This allows developers to determine the loading logic of the target plugin based on the code file, thereby constructing code that enables the target plugin to run locally.

[0067] Step 404: Obtain the application package of the target plugin.

[0068] Step 405: Compile the application package to obtain the compiled binary file.

[0069] Step 406: Compile the binary file using the default compiler to obtain the compiled bytecode file.

[0070] Step 407: In response to determining that the target code has been built, obtain the bytecode file.

[0071] Step 408: Use the fourth tool to add the target code to the bytecode file.

[0072] Steps 404-408 are basically the same as steps 304-308 in the previous embodiment. For specific implementation methods, please refer to the above description of steps 304-308, which will not be repeated here.

[0073] from Figure 4 It can be seen from this that, with Figure 3Compared with the corresponding embodiments, the method for building a local runtime environment for plugins in this embodiment emphasizes the process of decompiling the target plugin, thereby completing the reverse location of the plugin loading logic, identifying the key steps of the plugin loading logic, and improving the efficiency of building a local runtime environment for plugins.

[0074] Further reference Figure 5 , Figure 5 This diagram illustrates an application scenario of the method for building a local runtime environment for a plugin according to this disclosure. In this scenario, after identifying the target plugin 501, the execution entity 502 first uses apktool to decompile the target plugin, extracting its resource data to obtain a first file containing a dex file, a resource file, a manifest file, etc. Then, the execution entity 502 uses dex2jar to convert the extracted dex file into a JAR file, resulting in a second file. Next, the execution entity 502 uses jadx to load the converted JAR file and converts it into a target format file, that is, into a format readable by developers, resulting in a third file. This third file allows developers to determine the loading logic of the target plugin and construct the target code. Finally, once the execution entity 502 has determined that the target code has been built, it will use Android Transform and Javasist to complete the context construction of the plugin loading logic and add the target code to the .class file of the target plugin 501, thereby completing the setup of the target plugin's local runtime environment and improving the efficiency of the plugin's local runtime environment setup.

[0075] Further reference Figure 6 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a device for building a plugin local runtime environment. This device embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0076] like Figure 6As shown, the plugin local runtime environment building device 600 of this embodiment includes: an extraction module 601, a first conversion module 602, a second conversion module 603, and an adding module 604. The extraction module 601 is configured to extract resource data of the target plugin using a first tool to obtain a first file; the first conversion module 602 is configured to convert the first file into a JAR format file using a second tool to obtain a second file; the second conversion module 603 is configured to convert the second file into a target format file using a third tool to obtain a third file, and to build target code based on the third file; the adding module 604 is configured to add the target code to the application package of the target plugin using a fourth tool in response to determining that the target code has been built.

[0077] In this embodiment, the specific processing of the extraction module 601, the first conversion module 602, the second conversion module 603, and the addition module 604 in the plugin local runtime environment building device 600, and the resulting technical effects, can be found in the following references: Figure 2 The relevant descriptions of steps 201-204 in the corresponding embodiments will not be repeated here.

[0078] In some optional implementations of this embodiment, the above-mentioned plugin local runtime environment building device 600 further includes: an acquisition module configured to acquire the application package of the target plugin; a first compilation module configured to compile the application package to obtain a compiled binary file; a second compilation module configured to compile the binary file using a preset compiler to obtain a compiled bytecode file; and an addition module including: an acquisition submodule configured to acquire the bytecode file; and an addition submodule configured to add the target code to the bytecode file using a fourth tool.

[0079] In some optional implementations of this embodiment, the extraction module includes a decompilation submodule, configured to import the application package into a first tool, and use the first tool to decompile the application package to obtain a compiled first file, wherein the first file contains an executable file.

[0080] In some optional implementations of this embodiment, the first conversion module includes: a first conversion submodule, configured to import the executable file into a second tool, and use the second tool to convert the executable file from binary format to JAR format to obtain the converted second file.

[0081] In some optional implementations of this embodiment, the second conversion module includes a second conversion submodule configured to import the second file into a third tool, so that the third tool loads the second file and converts the second file into a target format file.

[0082] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0083] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0084] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 708 into random access memory (RAM) 703. RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0085] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0086] The computing unit 701 can be various 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 special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as the method for building a plug-in local runtime environment. For example, in some embodiments, the method for building a plug-in local runtime environment can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the method for building a plug-in local runtime environment described above can be performed. Alternatively, in other embodiments, computing unit 701 may be configured by any other suitable means (e.g., by means of firmware) to execute a method for building a plugin local runtime environment.

[0087] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0088] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This 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 when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0089] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0090] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the 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 can be received in any form (including sound input, voice input, or tactile input).

[0091] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0092] Cloud computing refers to a technology system that enables access to a shared pool of physical or virtual resources via a network. These resources can include servers, operating systems, networks, software, applications, and storage devices, and can be deployed and managed on demand and in a self-service manner. Cloud computing technology can provide efficient and powerful data processing capabilities for applications such as artificial intelligence and blockchain, as well as for model training.

[0093] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0094] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0095] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for setting up a local runtime environment for a plugin, comprising: The application package of the target plugin is compiled to obtain the compiled binary file; The binary file is compiled using a preset compiler to obtain a compiled bytecode file; The resource data of the target plugin is extracted using the first tool to obtain a first file, which contains the resource files of the target plugin; Use the second tool to convert the first file into a second file in JAR format; The second file is imported into the third tool so that the third tool loads the second file and converts the second file into a third file of the target format; Based on the third file, construct target code for bypassing the cloud verification logic of the target plugin and enabling direct loading and running of the target plugin in the local environment; In response to determining that the target code has been built, the target code is added to the bytecode file using a fourth tool.

2. The method according to claim 1, wherein, The step of extracting resource data of the target plugin using the first tool to obtain the first file includes: The application package is imported into a first tool, and the application package is decompiled using the first tool to obtain a first compiled file, wherein the first file contains an executable file.

3. The method according to claim 2, wherein, The step of using a second tool to convert the first file into a JAR format file to obtain a second file includes: The executable file is imported into the second tool, which is then used to convert the executable file from binary format to JAR format, resulting in the converted second file.

4. A device for building a local runtime environment for a plugin, comprising: The first compilation module is configured to compile the application package of the target plugin to obtain the compiled binary file; The second compilation module is configured to compile the binary file using a preset compiler to obtain a compiled bytecode file; The extraction module is configured to use a first tool to extract the resource data of the target plugin to obtain a first file, wherein the first file contains the resource files of the target plugin; The first conversion module is configured to use a second tool to convert the first file into a second file in JAR format. The second conversion 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 third file of the target format; The build module is configured to build target code based on the third file to bypass the cloud verification logic of the target plugin and enable the direct loading and running of the target plugin in the local environment; The module is configured to add the target code to the bytecode file using a fourth tool in response to determining that the target code has been built.

5. The apparatus according to claim 4, wherein, The extraction module includes: The decompilation submodule is configured to import the application package into a first tool, and use the first tool to decompile the application package to obtain a compiled first file, wherein the first file contains an executable file.

6. The apparatus according to claim 5, wherein, The first conversion module includes: The first conversion submodule is configured to import the executable file into the second tool, and use the second tool to convert the executable file from binary format to JAR format to obtain the converted second file.

7. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-3.

8. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method of any one of claims 1-3.

9. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-3.

Images