Code conversion method and device based on abstract syntax tree and terminal equipment

Abstract

The invention provides a code conversion method and device based on an abstract syntax tree and terminal equipment, according to the code conversion method and device based on the abstract syntax tree, a standardized plug-in interface design of a dynamic plug-in system enables a conversion plug-in to have high expandability and maintainability, and when code specifications are updated, quick response can be achieved only by developing a new plug-in; maintenance cost and adaptation difficulty are greatly reduced, and the method can flexibly adapt to code conversion requirements of multiple scenes and multiple platforms. In addition, the code file is analyzed into the abstract syntax tree for structural analysis, the code logic and syntax relation can be accurately recognized and converted, and the code conversion accuracy is improved. And secondly, by fusing a dynamic plug-in system and a difference table set and utilizing a difference table and a built-in conversion rule of a conversion plug-in to perform conversion processing on nodes in the abstract syntax tree, code format chaos and logic errors caused by misoperation in manual conversion are effectively avoided, and the code conversion efficiency and accuracy are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of computer, in particular to a code conversion method and device based on abstract syntax tree and terminal equipment. BACKGROUND

[0002] In the prior art, program code conversion is mainly realized by two ways, one is manual conversion, that is, reviewing the code to be converted line by line, and manually adjusting the code content according to the syntax rules of the target platform; the other is to use a conversion tool based on a preset code template, a template library containing standard code segments of the target platform is pre-constructed, and when converting, the fixed code blocks in the code to be converted are matched and replaced.

[0003] However, the manual conversion method is inefficient, and the code format is not uniform and the logic is wrong due to human operation, and the conversion quality depends on the familiarity of the developer with the specifications of the target platform; the template type conversion tool can only realize the replacement of the surface code block, and the maintenance cost of the template library is high, and when a new target platform or platform specification is updated, a large number of corresponding templates need to be redesigned. SUMMARY

[0004] The present application provides a code conversion method and device based on abstract syntax tree and terminal equipment, which solves the technical problems of low conversion efficiency and low accuracy in the prior art.

[0005] In a first aspect, the present application provides a code conversion method based on abstract syntax tree, the method comprising: obtaining a difference table set; obtaining a code file to be converted of a preset file type in the file storage path of the lightweight program to be converted; parsing the code file to be converted into an abstract syntax tree, and calling a corresponding target conversion plug-in in a dynamic plug-in system, so that the target conversion plug-in processes the nodes in the abstract syntax tree based on the difference table set and built-in conversion rules; generating a target code file based on the abstract syntax tree after conversion processing.

[0006] Wherein, before obtaining the difference table set, it further comprises: initializing a dynamic plug-in system, the dynamic plug-in system pre-registers a plurality of conversion plug-ins, and each conversion plug-in declares the file type processed by itself through a standardized plug-in interface.

[0007] Wherein, the code file to be converted is a custom script file including interface calls, and the target conversion plug-in processes the nodes in the abstract syntax tree based on the difference table set and built-in conversion rules, comprising: The target conversion plug-in identifies an interface call node associated with an interface call in the abstract syntax tree, and converts the interface call node in the abstract syntax tree based on an interface difference table in the difference table set. The target conversion plug-in converts a first type of interface difference that is not covered by the interface difference table in the interface call node based on the built-in conversion rule.

[0008] The target conversion plug-in converts a first type of interface difference that is not covered by the interface difference table in the interface call node based on the built-in conversion rule, including: In the interface call node, a target interface call node corresponding to a callback function of a preset interface is determined. Based on a parameter conversion rule defined in the built-in conversion rule, a parameter identifier of the callback function in the target interface call node is modified.

[0009] The target conversion plug-in converts the interface call node in the abstract syntax tree based on the interface difference table in the difference table set, including: Interface call information associated with the interface call node in the abstract syntax tree is extracted. The interface call information is matched in the interface difference table to determine a difference type. According to the difference type, a corresponding conversion operation is performed on the interface call information, and a converted interface call node in the abstract syntax tree is adjusted.

[0010] After the interface call information is matched in the interface difference table to determine the difference type, the method further includes: In a case where a corresponding target interface call node is not matched in the interface difference table according to the interface call information, it is determined whether there is a replaceable interface. In a case where the first interface call node exists, the interface information of the first interface call node is modified according to the replaceable interface and a replacement rule in the interface difference table, and a difference type is re-determined based on the modified interface information. In a case where the second interface call node does not exist, interface missing information is recorded.

[0011] The target conversion plug-in converts the interface call node in the abstract syntax tree based on the interface difference table in the difference table set, including: For an interface name difference, an interface name in the interface call information is replaced according to a corresponding target interface name in the interface difference table. To address differences in interface parameters, adaptation processing is performed on the input parameters in the interface call information based on the interface difference table.

[0012] The step of performing adaptation processing on the input parameters in the interface call information based on the interface difference table includes: Based on the parameter verification rules recorded in the interface difference table, the input parameters in the interface call information are verified. If a naming difference is detected in the input parameter and a naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule. If the input parameter value is found to be within the preset range of valid parameter values, the parameter value is retained. If the parameter type of the input parameter is found to be the preset target parameter type, the original parameter type of the input parameter is maintained.

[0013] This also includes: If the parameter type of the input parameter is not the preset target parameter type, the first difference information is recorded, and a first annotation mark indicating that the parameter is not supported is added to the interface call node corresponding to the abstract syntax tree. If the input parameter value is detected to be outside the preset range of valid parameter values, the second difference information is recorded, and a second annotation mark indicating that the parameter value is not supported is added to the interface call node corresponding to the abstract syntax tree.

[0014] The process further includes, after the target transformation plugin performs transformation processing on the nodes in the abstract syntax tree based on the difference table set and the built-in transformation rules: Traverse the interface call nodes carrying annotation tags in the abstract syntax tree, wherein the annotation tags include the first annotation tag and the second annotation tag; Obtain the difference information corresponding to the annotation mark, and generate incompatibility information based on the difference information.

[0015] Secondly, this application provides a code conversion apparatus based on an abstract syntax tree, the apparatus comprising: The difference table retrieval module is used to retrieve a collection of difference tables. The code file acquisition module is used to acquire the code file of the preset file type to be converted from the file storage path of the lightweight program to be converted; The conversion processing module is used to parse the code file to be converted into an abstract syntax tree, and call the corresponding target conversion plugin in the dynamic plugin system so that the target conversion plugin can convert the nodes in the abstract syntax tree based on the difference table set and the built-in conversion rules. The target code output module is used to generate target code files based on the transformed abstract syntax tree.

[0016] Thirdly, this application provides a terminal device, which includes a processor and a memory; The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the code transformation method based on the abstract syntax tree as described in the first aspect, according to instructions in the computer program.

[0017] As described above, this application provides a code conversion method, apparatus, and terminal device based on an abstract syntax tree. The standardized plugin interface design of the dynamic plugin system in this application enables the conversion plugin to have high scalability and maintainability. When code specifications are updated, only new plugins need to be developed for rapid response, greatly reducing maintenance costs and adaptation difficulty, and allowing it to flexibly adapt to code conversion needs across multiple scenarios and platforms. Furthermore, by parsing code files into an abstract syntax tree for structural analysis, this application can accurately identify and convert code logic and syntax relationships, overcoming the limitations of traditional template tools that can only perform surface-level code block matching and replacement, thus improving the accuracy of code conversion. Secondly, by integrating the dynamic plugin system with a set of difference tables, and utilizing the difference tables and the conversion rules built into the conversion plugins to process the nodes in the abstract syntax tree, this effectively avoids code formatting chaos and logical errors caused by operational mistakes during manual conversion, improving the efficiency and accuracy of code conversion. Attached Figure Description

[0018] Figure 1 A flowchart of a code conversion method based on an abstract syntax tree provided in an embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram of the framework of a code transformation method based on an abstract syntax tree provided in an embodiment of the present invention.

[0020] Figure 3 This is a flowchart illustrating another code conversion method based on an abstract syntax tree provided in an embodiment of the present invention.

[0021] Figure 4 This is a schematic diagram illustrating a process for converting a callback function based on a specific conversion rule, as provided in an embodiment of the present invention.

[0022] Figure 5 This is a schematic diagram of an interface replacement process provided in an embodiment of the present invention.

[0023] Figure 6This is a schematic diagram of the structure of a code conversion device based on an abstract syntax tree, provided in an embodiment of the present invention.

[0024] Figure 7 This is a schematic diagram of the frame of a terminal device provided in an embodiment of the present invention. Detailed Implementation

[0025] The following description and accompanying drawings fully illustrate specific embodiments of this application to enable those skilled in the art to practice them. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included in or replace parts and features of other embodiments. The scope of embodiments of this application includes the entire scope of the claims and all available equivalents of the claims. In this document, each embodiment may be referred to individually or collectively by the term "invention," which is merely for convenience and is not intended to automatically limit the scope of the application to any single invention or inventive concept if more than one invention is disclosed. Relational terms such as "first" and "second" are used herein only to distinguish one entity or operation from another, without requiring or implying any actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed. The various embodiments in this document are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the structures, products, etc., disclosed in the embodiments, since they correspond to the disclosed parts, the descriptions are relatively simple; relevant details can be found in the method section.

[0026] In existing technologies, lightweight program code conversion mainly relies on two methods. One is manual conversion, where developers review the code to be converted line by line, manually adjusting the code content according to the syntax rules and interface requirements of the target platform, including modifying variable names and adjusting function call formats. This method is usually used for projects with a small amount of code or simple conversion scenarios. The other method is to use conversion tools based on preset code templates. Technicians pre-build code template libraries for different platforms and file types. The code templates in the code template library include standard code snippets for the target platform. During conversion, the conversion tool matches the fixed code blocks in the code to be converted and replaces them with the corresponding standard code snippets in the code template library.

[0027] However, existing code conversion solutions struggle to meet the demands for efficient and accurate cross-platform conversion. Manual conversion is inefficient, and in large projects with numerous files, human error can easily lead to inconsistent code formats and logical errors. Furthermore, conversion quality is highly dependent on the developer's familiarity with the target platform's specifications, resulting in a low tolerance for errors. Conversion tools based on preset code templates can only match and replace surface-level code blocks, and the maintenance cost of template libraries is extremely high. Adding a new target platform or updating platform specifications necessitates redesigning a large number of corresponding code templates.

[0028] Therefore, in order to solve the above-mentioned technical problems, embodiments of the present invention provide a code transformation method based on an abstract syntax tree, such as... Figure 1 As shown, Figure 1 This is a flowchart illustrating a code conversion method based on an abstract syntax tree (API) according to an embodiment of the present invention. The API-based code conversion method provided in this embodiment can be executed by a terminal device, which can be implemented through software and / or hardware. The terminal device can consist of two or more physical entities, or it can consist of a single physical entity. For example, the terminal device can be a computer or a server. The API-based code conversion method provided in this embodiment includes the following steps: Step 101: Obtain the set of difference tables.

[0029] In this embodiment, before performing code conversion, the terminal device obtains a set of difference tables to provide basic support for subsequent conversion processing. The set of difference tables is a collection of general conversion rules extracted from multi-platform lightweight program development specifications, containing multiple difference tables. Each difference table provides general, directly callable conversion rules for lightweight program conversion, supporting most conversion scenarios that do not require special processing and reducing additional code intervention during the conversion process. For example, the set of difference tables includes a file extension difference table, an interface difference table (defining the mapping of source and target platform interface names and parameter format differences, etc.), and a component difference table (defining the conversion rules for tag names and attribute names of custom or native components, etc.). Each difference table can be stored in a structured format (such as JSON or XML) and supports dynamic updates. When the specification iterates, only the rule content of the corresponding difference table needs to be modified, thereby significantly reducing maintenance costs.

[0030] In one optional implementation, a dynamic plugin system can be initialized before obtaining the difference table set. The dynamic plugin system refers to a system that automatically identifies, registers, and uniformly schedules compliant conversion plugins based on standardized plugin interfaces. The dynamic plugin system automatically identifies and registers conversion plugins that conform to the standardized plugin interface specifications by scanning a preset plugin storage directory. The standardized plugin interface is the core of ensuring plugin compatibility and scalability; it defines core information such as the file types processed by the conversion plugin and the code conversion method, ensuring that all registered conversion plugins can be uniformly scheduled by the dynamic plugin system. In one embodiment, the dynamic plugin system can maintain a dynamically updated list of plugin capabilities, recording the unique identifier of each conversion plugin, supported file types, and version information. For example, one conversion plugin declares that it processes .js script files, while another plugin declares that it processes .ts type files. When adding new conversion scenarios, only a new plugin conforming to the interface specifications needs to be developed and placed in the storage directory; the plugin system can then automatically load and register it without modifying the core architecture.

[0031] Step 102: Obtain the code file to be converted from the file storage path of the lightweight program to be converted, which has a preset file type.

[0032] After initializing the dynamic plugin system and obtaining the difference table set, the terminal device needs to further obtain the code files of the lightweight program to be converted, which are of a preset file type. The preset file type can be specified and set in advance; for example, it can be .js (a logic script file) or .ts (a TypeScript file). For example, after the user inputs the file storage path and preset file type of the lightweight program to be converted through a visual tool or command line, the terminal device iterates through the user-specified file storage path and filters out the code files that match the preset file type based on the file extension. In one embodiment, during the process of obtaining the code files to be converted, the terminal device can further perform a validity check on the code files, such as checking whether the files are corrupted or illegal, and simultaneously record data such as the file's storage path, size, and modification time to provide a basis for subsequent conversion traceability.

[0033] Step 103: Parse the code file to be converted into an abstract syntax tree, and call the corresponding target conversion plugin in the dynamic plugin system so that the target conversion plugin can perform conversion processing on the nodes in the abstract syntax tree based on the difference table set and the built-in conversion rules.

[0034] After obtaining the code file to be converted, the terminal device needs to further parse the code file into an Abstract Syntax Tree (AST). The AST ignores formatting differences in the source code, extracting only its syntactic logic structure. It presents a structured representation of each node's corresponding variable declarations, function calls, and other specific syntactic components as a tree-like data model. The terminal device can call a corresponding parsing tool to parse the code file into an AST. For example, the terminal device can use the Babel parsing tool to parse the code file. The parsing process ignores formatting differences in the code, extracting only the syntactic logic structure and mapping syntactic components such as variable declarations, function definitions, interface calls, and expressions in the source code to different types of nodes in the AST, forming a structured tree-like data model.

[0035] After parsing the code file to be converted into an abstract syntax tree (AST), the target conversion plugin corresponding to the preset file type needs to be called in the dynamic plugin system to perform conversion processing on the AST. For example, if the file type to be converted is .js, the dynamic plugin system matches and loads the conversion plugin that declares processing this type.

[0036] After the target transformation plugin is loaded, it performs transformation processing on the nodes in the abstract syntax tree (AST) based on the difference table set and built-in transformation rules. Specifically, when performing transformation processing, the target transformation plugin first uses a specified syntax parsing tool to parse the code file to be transformed into an AST, and then traverses all nodes of the AST in a depth-first traversal manner, extracting the node's identification information by identifying the node's key type (such as call expressions, member expressions, etc.). Subsequently, based on the identification information, it matches the corresponding type of transformation rules in the difference table set, and performs transformations on the nodes according to the transformation rules (such as attribute mapping, identifier adjustment, etc.). For complex or special scenarios not covered by the difference table, further transformation is performed using the plugin's built-in transformation rules. It should be noted that the transformation plugin's built-in transformation rules are plugin-specific inherent transformation logic, used to handle complex / specific difference scenarios in the source code file that cannot be covered by the difference table, such as special syntax adaptation under different file types, exclusive component nesting logic, platform-specific attribute transformation, special resource reference formats, etc. Due to the flexible nature of the differences, complete transformation cannot be achieved through the general transformation rules of the difference table. In this embodiment, the target conversion plugin's built-in conversion rules use structured logic that matches specific scenarios and precisely modifies them. Based on the AST structure of the corresponding file, it locates the target differences and performs the corresponding adaptation operations. This not only does not interfere with the general conversion process of the difference table, but also covers the personalized difference requirements of the code file to be converted.

[0037] Step 104: Generate the target code file based on the abstract syntax tree after transformation.

[0038] After the target transformation plugin completes the AST node transformation, the terminal device needs to generate the target code file based on the transformed abstract syntax tree. For example, the terminal device can use Babel to traverse the transformed AST, generate code text conforming to syntax rules according to the node type, and obtain the target code file.

[0039] like Figure 2 As shown, Figure 2 This is a schematic diagram of a code transformation method based on an abstract syntax tree provided in an embodiment of the present invention. During the execution of steps 101-104 above, the data or file transfer or transformation process processed in each step can be referred to as follows: Figure 2 The schematic flowchart is shown.

[0040] As described above, this invention provides a code conversion method based on an abstract syntax tree. The standardized plugin interface design of the dynamic plugin system in this embodiment makes the conversion plugin highly scalable and maintainable. When code specifications are updated, only new plugins need to be developed for a quick response, greatly reducing maintenance costs and adaptation difficulties, enabling it to flexibly adapt to code conversion needs across multiple scenarios and platforms. Furthermore, by parsing code files into an abstract syntax tree for structural analysis, this invention can accurately identify and convert code logic and syntax relationships, overcoming the limitations of traditional template tools that can only perform surface-level code block matching and replacement, thus improving the accuracy of code conversion. Secondly, by integrating the dynamic plugin system with a set of difference tables, and utilizing the difference tables and the conversion rules built into the conversion plugins to process the nodes in the abstract syntax tree, this effectively avoids code formatting chaos and logical errors caused by operational mistakes during manual conversion, improving the efficiency and accuracy of code conversion.

[0041] This invention also provides another code transformation method based on abstract syntax trees, such as... Figure 3 As shown, Figure 3 This is a flowchart illustrating another code transformation method based on an abstract syntax tree provided in an embodiment of the present invention. Figure 3 The code conversion method based on abstract syntax trees shown is a concretization of the above-mentioned code conversion method based on abstract syntax trees. The code conversion method based on abstract syntax trees provided in this embodiment of the invention includes: Step 201: Initialize the dynamic plugin system and obtain the difference table set. The dynamic plugin system pre-registers multiple conversion plugins. Each conversion plugin declares the file type it processes through a standardized plugin interface. The difference table set includes multiple difference tables used to define conversion rules.

[0042] Step 202: Obtain the code file to be converted from the file storage path of the lightweight program to be converted, which has a preset file type.

[0043] Step 203: Parse the code file to be converted into an abstract syntax tree, call the corresponding target conversion plugin in the dynamic plugin system, so that the target conversion plugin can identify the interface call node associated with the interface call in the abstract syntax tree, and perform conversion processing on the interface call node in the abstract syntax tree based on the interface difference table in the difference table set.

[0044] Step 204: The target conversion plugin performs conversion processing on the first type of interface differences that are not covered by the interface difference table in the interface call node based on the built-in conversion rules. The code file to be converted is a custom script file containing interface calls.

[0045] In this embodiment, the code file to be converted is a custom script file containing interface calls. This custom script file refers to a custom code file used to implement business logic, containing unique or general interface call statements, and is typically a JavaScript file (with a .js extension). When the terminal device converts the code file, it needs to call the conversion plugin corresponding to the JS file type as the target conversion plugin in the dynamic plugin system. Specifically, when the target conversion plugin processes the custom script file, it first needs to parse the custom script file into an abstract syntax tree (AST). For example, the target conversion plugin can use the Babel tool to parse the file content of the custom script file into an AST. Taking the custom script file . / source-tt / pages / index / index.js as an example, it contains interface call statements such as tt.getSystemInfo and tt.onError. The target transformation plugin reads the content of a custom script file using Node.js's `fs` module and then uses Babel to parse it into an Abstract Syntax Tree (AST). This AST structure contains `ExpressionStatement` nodes, `CallExpression` nodes, and `MemberExpression` nodes. In `MemberExpression`, the `object` node has the identifier for the name "tt", and the `property` node has the identifier for the name "getSystemInfo". The `arguments` node in `CallExpression` contains the callback function-related structure, completely reconstructing the syntax logic of the API call. Therefore, if a custom script file contains multiple API call statements, the target transformation plugin can batch parse all code segments containing API calls into their corresponding AST nodes.

[0046] After obtaining the abstract syntax tree (API), the target transformation plugin can perform transformation processing on the interface call nodes in the API based on the API difference table in the difference table set. The API difference table predefines the name conversion rules, parameter difference rules, and status identifiers (such as the type field recording the difference type, the status field indicating the difference status, and the replace field storing the target replacement value) between the source lightweight program and the target lightweight program. For example, for the `tt.getSystemInfo` call node, the status of this interface in the interface difference table is `DIFF_NAME`, and the `replace` field is `wx.getSystemInfo`. Based on this, the target conversion plugin modifies the `object` of the `MemberExpression` node in the AST (changing `name: "tt"` to `name: "wx"`) to complete the interface name conversion. For the `tt.onError((err)=>{console.log(err.errMsg)})` call node, if the status of `errMsg` in the interface difference table is `DIFF_PARAM` and the `replace` field is `message`, the target conversion plugin modifies the `MemberExpression` node corresponding to `err.errMsg` in the callback function, changing the property's `name: "errMsg"` to `name: "message"`.

[0047] After the API call nodes are transformed, some API call nodes still have specific code differences that cannot be covered by the API difference table, i.e., the first type of API differences still exist. In this case, supplementary transformation processing is required based on the built-in transformation rules of the target transformation plugin. For example, the target transformation plugin first uses the node features of the API call nodes in the Abstract Syntax Tree (AST) as the matching dimension to locate the corresponding built-in transformation rules, and then further transforms the API call nodes according to the corresponding feature transformation rules. For example, the interface call nodes in the AST include nodes such as CallExpression and MemberExpression, which can be used to locate the interface call position. Addressing the parameter conversion differences between res.pageOrientation in the success callback of wx.getSystemInfo and res.deviceOrientation on the target platform, the target conversion plugin traverses the AST to locate the CallExpression node of wx.getSystemInfo and identifies its success callback node (of type ArrowFunctionExpression). Then, it traverses the MemberExpression nodes within the callback function body of the success callback node, matching the node corresponding to res.pageOrientation (object with name: "res", property with name: "pageOrientation"). Finally, based on built-in conversion rules, it changes the property of this node to name: "deviceOrientation" and adjusts the AST structure accordingly.

[0048] Based on the above embodiments, in step 204, the target conversion plugin performs conversion processing on the first type of interface differences that are not covered by the interface difference table in the interface call node, based on the built-in conversion rules, including: Step 2041: In the interface call node, determine the target interface call node corresponding to the callback function of the preset interface.

[0049] Step 2042: Based on the parameter conversion rules defined in the built-in conversion rules, modify the parameter identifier of the callback function in the target interface call node.

[0050] Specifically, the target conversion plugin locates the target interface call node associated with the callback function of a specific interface among the interface call nodes already identified in the abstract syntax tree. Then, based on the preset parameter conversion rules in the built-in conversion rules, it modifies the parameter identifiers in the callback function contained in the target interface call node to achieve the adaptation and conversion of the callback parameters of the specific interface. In one embodiment, as follows... Figure 4 As shown, Figure 4This is a flowchart illustrating a process for transforming callback functions based on specific transformation rules, as provided in an embodiment of the present invention. The target transformation plugin traverses the CallExpression nodes (function call nodes) in the AST, extracts the callee attribute (i.e., the interface call identifier) ​​within the node, and matches it with the target interface name preset by the built-in specific transformation rules. For example, when the callee attribute is of type MemberExpression, and its object (e.g., name: "tt") and property (e.g., name: "getSystemInfo") combination matches the target interface name, the node is confirmed as the target interface call node corresponding to the callback function of the specific interface to be processed.

[0051] After matching the target API call node, the target conversion plugin further traverses the arguments parameter array (i.e., the configuration object passed in by the API) of the target API call node, identifies the callback function attributes (such as success, failure) to process different types of callback functions respectively.

[0052] If the callback function is defined as an ObjectProperty type (e.g., success:()=>{}), the target conversion plugin locates the property through key:{name:"success"} and extracts its value field (ArrowFunctionExpression node, i.e., the callback function body).

[0053] If the callback function is defined as type ObjectMethod (e.g., success(){}), the target conversion plugin locates it using key:{name:"success"} and type:"ObjectMethod" to directly obtain the body node corresponding to the function body. Simultaneously, the target conversion plugin uses interface call stack recording logic to ensure that the currently located callback function belongs to the target interface. Specifically, the interface call stack recording logic refers to tracking the interface call context during the depth-first traversal of the Abstract Syntax Tree (AST) using a stack-based management mechanism. When the iterator enters a node, if it determines that the node is an interface call node (e.g., conforming to the CallExpression type and containing interface characteristics), it pushes the key information of that interface (e.g., interface name, node identifier) ​​onto the call stack. When the iterator completes traversing all child nodes (including callback functions) of that node and exits, if the node is still an interface call node, it is popped from the call stack. Through this "push-pop" operation, the top of the call stack always corresponds to the interface to which the currently traversed callback function belongs, thus clearly defining the affiliation between the callback function and the target interface and avoiding confusion.

[0054] After identifying the callback function, the target conversion plugin predefines a structured relationship of "specific interface - callback type - parameter conversion" within its built-in conversion rules. This structured relationship is designed based on special parameter scenarios not covered by the interface difference table. The target conversion plugin needs to modify the parameter identifiers in the callback function based on these parameter conversion rules. Specifically, for the identified specific interface (such as tt.getSystemInfo) and callback type (such as success), the target conversion plugin loads the corresponding parameter conversion rules from its built-in rules. An example of the parameter conversion rule structure is as follows: { "tt.getSystemInfo":{ / / Specific interface name "success":{ / / Callback function type "pageOrientation":"deviceOrientation", / / Source parameter identifier →Destination parameter identifier "screenWidth":"windowWidth" } }} The target transformation plugin performs a depth-first search on the located callback functions, identifying the MemberExpression nodes (i.e., parameter identifier nodes) that reference target parameters. For example, in the callback function body `console.log(res.pageOrientation)`, the MemberExpression node is located, with its object name: "res" and property name: "pageOrientation". It is determined that `property.name(pageOrientation)` exists in the built-in parameter transformation rules. Based on the correspondence in the specific transformation rules, the `property.name` of the MemberExpression node is changed from "pageOrientation" to "deviceOrientation", and the AST structure is adjusted accordingly. After the modification, the original callback function statement becomes `console.log(res.deviceOrientation)`, conforming to the callback parameter specification of the target lightweight program interface.

[0055] It should be noted that if there are complex scenarios that cannot be determined during the first AST traversal (such as differences in the return value of an interface during a second call), the target conversion plugin can supplement the processing through a secondary detection mechanism. That is, a secondary detection method is defined in the check object of the target conversion plugin. After the first AST traversal is completed, the secondary detection method is called to traverse the AST again to ensure that all specific interface differences are processed.

[0056] The above approach, by parsing custom script files into an abstract syntax tree, relying on the interface difference table to achieve basic standardized transformation of interface call nodes, and then using the plugin's built-in transformation rules to handle specific code differences that cannot be covered by the interface difference table, ensures the accuracy and completeness of interface transformation, avoids the tedious operation of manually locating and modifying interface calls and special differences one by one, further improves the overall efficiency of code transformation based on the abstract syntax tree, and reduces the risk of functional abnormalities caused by improper interface adaptation.

[0057] Based on the above embodiments, step 203, based on the interface difference table in the difference table set, performs transformation processing on the interface call nodes in the abstract syntax tree, including: Step 2031: Extract the interface call information associated with the interface call node in the abstract syntax tree.

[0058] In this embodiment, when the target conversion plugin processes the abstract syntax tree based on the interface difference table, after traversing the abstract syntax tree to identify the interface call nodes, it needs to further extract the interface call information corresponding to the interface call nodes. This interface call information includes at least the interface name and input parameters. The input parameters include key information passed through the command line or scaffolding during the code conversion process based on the abstract syntax tree, used to specify the core configurations such as the path and type required for the conversion. For example, the target conversion plugin traverses the abstract syntax tree using the Babel tool, locating all interface call nodes through two key node types: CallExpression and MemberExpression. In the MemberExpression node, the object field (e.g., name: "tt") is the interface prefix, the property field (e.g., name: "getSystemInfo") is the specific interface name, and the arguments field of the CallExpression node contains the input parameters. For example, the node corresponding to `tt.getSystemInfo({success:(res)=>{console.log(res.pageOrientation)}})` in the AST is identified as a `CallExpression` node, its `callee` property is of type `MemberExpression`, and the interface name is extracted as `tt.getSystemInfo`; the input parameters in the `arguments` field are extracted, including the `success` callback function; similarly, the interface name `tt.onError` and the input parameter `err` callback function are extracted for the node `tt.onError((err)=>{console.log(err.errMsg)})`.

[0059] Step 2032: Match the interface call information with the interface difference table to determine the difference type.

[0060] Next, the target conversion plugin needs to match the extracted API call information against the API difference table, and determine the difference type based on the type and status fields of the API difference table. The difference types include: (1) Difference in interface name: status is DIFF_NAME, indicating that the interface names are different.

[0061] (2) Differences in interface parameters: status is DIFF_PARAM, indicating that the parameter names, supported values ​​or callback parameters are different.

[0062] For example, when matching `tt.getSystemInfo`, the `status` field of the interface in the interface difference table is `DIFF_NAME`, the `replace` field is `wx.getSystemInfo`, and the target conversion plugin determines the difference type as "interface name difference". When matching `tt.onError`, the `params` field of the interface in the interface difference table records that the `errMsg` parameter needs to be replaced with `message`, the `status` is `DIFF_PARAM`, and the target conversion plugin determines the difference type as "interface parameter difference".

[0063] Step 2033: Perform corresponding conversion operations on the interface call information according to the difference type, and adjust the converted interface call nodes in the abstract syntax tree.

[0064] After determining the difference type, the target transformation plugin performs corresponding transformation operations on the interface call information based on the difference type. For example, for interface name differences, the target transformation plugin replaces the interface name in the interface call node; for interface parameter differences, the target transformation plugin replaces the callback parameters. After the transformation operations are completed, the corresponding interface call node in the Abstract Syntax Tree (AST) is adjusted.

[0065] Based on the above embodiments, after matching the interface call information with the interface difference table in the difference table set to determine the difference type, the method further includes: Step 2034: If no corresponding target interface call node is found in the interface difference table based on the interface call information, determine whether there is a replaceable interface.

[0066] Step 2035: If there is a first interface call node with a replaceable interface, modify the interface information of the first interface call node according to the replaceable interface and the replacement rules in the interface difference table, and redetermine the difference type based on the modified interface information.

[0067] Step 2036: If there is no second interface call node with a replaceable interface, record the missing interface information.

[0068] For example, such as Figure 5 As shown, Figure 5 This is a schematic diagram of an interface replacement process provided in an embodiment of the present invention. Figure 5 In the process, after the target conversion plugin matches the extracted interface call information with the interface difference table, if no corresponding target interface is found, it can determine whether there is a replacement option by checking the status field (marking the status) and replace field (storing the replaceable interface name) of the interface in the interface difference table. If a replaceable interface is found (the replace field in the difference table has a value), that is, there is a first interface call node, the name of the interface call node in the AST is modified according to the replacement rules. For example, if the replace field of tt.oldApi is wx.newApi, the target conversion plugin locates the MemberExpression node in the AST, changes object (tt) to wx and property (oldApi) to newApi, and adjusts the AST accordingly. Then, the difference type is re-determined based on the modified interface name. If no replaceable interface is found (the replace field in the difference table is empty and the status is marked "missing"), that is, there is no second interface call node, the missing interface information is recorded.

[0069] Based on the above embodiments, step 2033 involves performing a corresponding conversion operation on the interface call information according to the difference type, including: Step 20331: For interface name differences, replace the interface name in the interface call information with the corresponding target interface name in the interface difference table.

[0070] Specifically, when the difference type is an interface name difference, the target transformation plugin needs to replace the interface name of the interface call node in the abstract syntax tree according to the target interface name recorded in the interface difference table. For example, the target transformation plugin matches tt.getSystemInfo from the interface difference table and obtains its replace field value as wx.getSystemInfo. Then, it uses the Babel tool to locate the corresponding MemberExpression node in the AST for this interface call. This node's object is the Identifier node with name: "tt", and its property is the Identifier node with name: "getSystemInfo". The target transformation plugin modifies the object property of the MemberExpression node, changing name: "tt" to name: "wx", while keeping the property unchanged, thus completing the replacement of the interface name from tt.getSystemInfo to wx.getSystemInfo. After the replacement is completed, the interface call node in the AST is adjusted synchronously.

[0071] Step 20332: For differences in interface parameters, perform adaptation processing on the input parameters of the interface call information based on the interface difference table.

[0072] When the difference type is an interface parameter difference, adaptation processing needs to be performed on the input parameters based on the interface difference table. For example, the target conversion plugin can call the interface difference table in the difference table collection, locate the `params` field corresponding to the current interface, extract the preset parameter verification rules and processing rules, and determine the adaptation direction and standard. In one embodiment, the parameter verification rules include parameter naming verification, parameter valid value verification, and parameter type verification. In parameter naming verification, if a naming difference is detected and a naming replacement rule exists, the parameter name is modified according to the naming replacement rule; in parameter valid value verification, if the parameter value is within the preset range of valid values, the original parameter value is retained; in parameter type verification, if the parameter type belongs to the preset target parameter type, the original parameter configuration is maintained. After all adaptation operations are completed, the corresponding parameter node in the abstract syntax tree is directly modified to ensure that the adapted parameter information is synchronously adjusted to the AST.

[0073] Based on the above embodiments, in step 20332, when the difference type is interface parameter difference, adaptation processing is performed on the input parameters based on the interface difference table, including: Based on the parameter verification rules recorded in the interface difference table, the input parameters in the interface call information are verified. If a naming difference is detected in the input parameter and a naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule. If the input parameter value is found to be within the preset range of valid parameter values, the parameter value is retained. If the parameter type of the input parameter is found to be the preset target parameter type, the original parameter type of the input parameter is maintained.

[0074] In this embodiment, the parameter verification rules are composed of the type field (marking the verification type), the extra field (storing the list of legal values / preset types), and the replace field (storing the naming replacement rules) of the IPAramDiff in the interface difference table. After extracting the input parameters, the target conversion plugin first calls the interface difference table to perform the verification to determine whether the parameters need to be adjusted.

[0075] For example, when a naming difference is detected in the input parameter through parameter naming validation, and a corresponding naming replacement rule exists in the interface difference table, the target transformation plugin modifies the name of the input parameter according to the naming replacement rule and adjusts the abstract syntax tree accordingly. For instance, for the input parameter `duration` in `tt.showToast({title:'Prompt', duration:2000})`, the target transformation plugin extracts the parameter name `duration` and matches it with the `params` field of `tt.showToast` in the interface difference table, determining that `duration` is a naming difference and `replace` is `timeout`. Then, by locating the Property node (key: "duration") corresponding to `duration` in the AST using Babel, the plugin changes the `name` attribute of that node from `duration` to `timeout`.

[0076] When the parameter value is detected to be within the preset range of valid parameter values ​​in the interface difference table through parameter validity verification, the target conversion plugin retains that parameter value. For example, for the `icon` parameter of `tt.showToast({title:'Prompt',icon:'none'})`, the parameter value "none" is extracted and matched against the `params.icon.extra` field of `tt.showToast` in the interface difference table (which stores preset values ​​such as ["none", "success"]). Since "none" is detected to be within the preset range of valid parameter values, the parameter value does not need to be modified, and the original configuration is directly retained.

[0077] When the parameter type check detects that the type of the input parameter matches the preset target parameter type in the interface difference table, the target conversion plugin maintains the original parameter configuration. For example, for the data parameter of tt.request({url:' / api',data:{id:1}}), the data parameter type is identified as "Object", matching the params.data.extra field of tt.request in the interface difference table (which stores preset types such as ["Object","string"]); since the "Object" type is confirmed to be a preset target parameter type, the original configuration of data:{id:1} is maintained, and no adjustment to the AST node is required.

[0078] The above-mentioned automatic verification and adaptation are performed by pre-setting parameter verification rules and relying on the interface difference table, avoiding the tedious operation of manually judging the rationality of parameters. This ensures that the input parameters conform to the target lightweight program specifications in terms of naming, value and type, and further improves the accuracy and efficiency of interface parameter conversion.

[0079] Based on the above embodiments, it also includes: If the parameter type of the input parameter is not the preset target parameter type, the first difference information is recorded, and the first annotation mark indicating that the parameter is not supported is added to the interface call node corresponding to the abstract syntax tree.

[0080] If the parameter value of the input parameter is detected to be outside the preset range of valid parameter values, the second difference information is recorded, and a second comment mark indicating that the parameter value is not supported is added to the interface call node corresponding to the abstract syntax tree.

[0081] In this embodiment, when the target transformation plugin detects that the input parameter type is unsupported, it records the parameter name, the corresponding interface identifier, and the reason for the difference as the first difference information. Simultaneously, it adds a first comment marker indicating that the parameter is unsupported to the corresponding interface call node in the abstract syntax tree. For example, when it detects that the input parameter type does not belong to the preset supported types of the `params` field `extra` in the interface difference table, it calls the log module to record the first difference information, including the parameter name, the corresponding interface identifier, and the reason for the difference, ensuring subsequent traceability. At the same time, it uses Babel to locate the Property node corresponding to the parameter in the AST and adds a first comment marker next to the node (e.g., / / [Unsupported parameter type] Parameter name: data, Interface: tt.request, Reason: Array type not supported), clearly marking the location and cause of the problem.

[0082] If the input parameter value is detected to be outside the preset range of valid parameters, the parameter value, parameter name, and the identifier of the interface to which it belongs can be recorded as second difference information. Simultaneously, a second comment marker indicating that the parameter value is not supported is added to the corresponding interface call node in the abstract syntax tree. For example, when the terminal device detects that the input parameter value is outside the preset range of valid values ​​in the `extra` field of the interface difference table, the logging module records the second difference information. At the same time, the node corresponding to the parameter value in the AST is located, and a second comment marker is added next to the node, indicating the unsupported value and the preset range of valid parameters. For example: / / [Unsupported parameter value] Parameter name: url, Parameter value: / home, Interface: tt.navigateTo, Valid value range: Must start with / pages / .

[0083] The above-mentioned methods, through information recording and AST annotation, enable the visual traceability of unsupported parameters, ensuring that subsequent manual verification or secondary processing can be carried out efficiently.

[0084] Based on the above embodiments, after the target transformation plugin performs transformation processing on the nodes in the abstract syntax tree based on the difference table set and built-in transformation rules, it further includes: Traverse the interface call nodes in the abstract syntax tree that carry annotation tags, including the first annotation tag and the second annotation tag; Obtain the difference information corresponding to the annotation markers, and generate incompatibility information based on the difference information.

[0085] In this embodiment, before generating the target code file based on the transformed Abstract Syntax Tree (AST), the terminal device can invoke the Babel tool to traverse the transformed AST to filter out interface call nodes carrying a first comment marker or a second comment marker. After filtering out the interface call nodes carrying comment markers, for each comment-marked interface call node, the difference information corresponding to the comment marker of that interface call node is obtained. After summarizing all the difference information, the difference information is organized according to a preset format (including report title, generation time, report description, and a list of problem details) to generate incompatibility information. In one embodiment, the format of the incompatibility information is as follows: #Lightweight program code conversion incompatibility report Generation time: 2025-XX-XX List of issues: 1. Problem type: Parameter type not supported Interface identifier: tt.request Parameter information: Parameter name = data, actual type = Array, supported types = Object / String Reason for the difference: The type of the input parameter does not meet the preset supported type requirements in the interface difference table. AST node location: Line XX in the source file . / source-tt / pages / index.js 2. Problem type: Parameter values ​​are not supported. Interface identifier: tt.navigateTo Parameter information: Parameter name = url, actual value = / home, valid value range = must start with / pages / Reason for the difference: The input parameter value is not within the range of valid values ​​preset in the interface difference table. AST node location: Line XX in the source file . / source-tt / pages / index.js.

[0086] As described above, by traversing the interface call nodes marked with annotations in the Abstract Syntax Tree (AST), the difference information in the AST is summarized and integrated into a structured incompatibility report, avoiding the tedious operation of manually traversing the AST to find problems. Furthermore, by generating the incompatibility report before generating the target code file, users can be aware of and address incompatibility issues during the conversion process in advance, effectively reducing the possibility of target code malfunctions due to undiscovered hidden problems and lowering subsequent debugging costs.

[0087] Step 205: Use a code generation tool to serialize the converted abstract syntax tree into text-formatted code content to obtain the target code file.

[0088] After the target conversion plugin has completed the conversion of the abstract syntax tree, the terminal device can call @babel / generator as a code generation tool. This tool serializes the converted AST into text format code content that conforms to JavaScript syntax specifications. Then, based on the original directory structure of the code file to be converted, it generates the corresponding target code file in the preset target output path.

[0089] As described above, this invention provides a code conversion method based on an abstract syntax tree. The standardized plugin interface design of the dynamic plugin system in this embodiment makes the conversion plugin highly scalable and maintainable. When code specifications are updated, only new plugins need to be developed for a quick response, greatly reducing maintenance costs and adaptation difficulties, enabling it to flexibly adapt to code conversion needs across multiple scenarios and platforms. Furthermore, by parsing code files into an abstract syntax tree for structural analysis, this invention can accurately identify and convert code logic and syntax relationships, overcoming the limitations of traditional template tools that can only perform surface-level code block matching and replacement, thus improving the accuracy of code conversion. Secondly, by integrating the dynamic plugin system with a set of difference tables, universal conversion is achieved through the conversion rules of the difference tables, effectively avoiding code formatting chaos and logical errors caused by operational mistakes during manual conversion, improving conversion efficiency and fault tolerance. For complex conversion scenarios not covered by the difference tables, the built-in conversion rules of the target conversion plugin are used for supplementary conversion, improving the accuracy of code conversion.

[0090] This invention also provides a code conversion device based on an abstract syntax tree, such as... Figure 6 As shown, Figure 6 This is a schematic diagram of a code conversion device based on an abstract syntax tree (AST) according to an embodiment of the present invention. The code conversion device based on an abstract syntax tree provided in this embodiment of the present invention includes: The difference table acquisition module 301 is used to acquire the difference table set.

[0091] The code file acquisition module 302 is used to acquire the code file of the preset file type to be converted from the file storage path of the lightweight program to be converted.

[0092] The conversion processing module 303 is used to parse the code file to be converted into an abstract syntax tree and call the corresponding target conversion plugin in the dynamic plugin system so that the target conversion plugin can convert the nodes in the abstract syntax tree based on the difference table set and the built-in conversion rules.

[0093] The target code output module 304 is used to generate target code files based on the transformed abstract syntax tree.

[0094] It also includes an initialization module, which initializes the dynamic plugin system before obtaining the difference table set. The dynamic plugin system pre-registers multiple conversion plugins, and each conversion plugin declares the file type it processes through a standardized plugin interface.

[0095] The code file to be converted is a custom script file containing interface calls. The target conversion plugin is specifically used to convert the interface call nodes in the abstract syntax tree that are associated with the interface calls, based on the interface difference table in the difference table set. Based on the built-in conversion rules, the first type of interface difference that is not covered by the interface difference table in the interface call node is converted.

[0096] Specifically, the target conversion plugin is used to determine the target interface call node corresponding to the callback function of the preset interface in the interface call node; and to modify the parameter identifier of the callback function in the target interface call node based on the parameter conversion rules defined in the built-in conversion rules.

[0097] Specifically, the target conversion plugin is used to extract the interface call information corresponding to the interface call node in the abstract syntax tree; match the interface call information in the interface difference table to determine the difference type; perform the corresponding conversion operation on the interface call information according to the difference type, and adjust the converted interface call node in the abstract syntax tree.

[0098] Specifically, the target conversion plugin is used to match the interface call information in the interface difference table, determine the difference type, and if no corresponding target interface is found in the interface call node in the interface difference table based on the interface call information, determine whether there is a replaceable interface; if there is a first interface call node with a replaceable interface, modify the interface information of the first interface call node according to the replaceable interface and the replacement rules in the interface difference table, and redetermine the difference type based on the modified interface information; if there is no second interface call node with a replaceable interface, record the missing interface information.

[0099] Specifically, the target conversion plugin is used to replace the interface name in the interface call information with the corresponding target interface name in the interface difference table for interface name differences; and to perform adaptation processing on the input parameters in the interface call information based on the interface difference table for interface parameter differences.

[0100] Specifically, the target conversion plugin is used to examine the input parameters in the interface call information based on the parameter verification rules recorded in the interface difference table. If a naming difference is found in the input parameter and a naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule. If the parameter value of the input parameter is found to be within the preset range of valid parameter values, the parameter value is retained. If the parameter type of the input parameter is found to be the preset target parameter type, the original parameter type of the input parameter is maintained.

[0101] The target conversion plugin is also used to record first difference information and add a first comment mark indicating that the parameter is not supported in the interface call node corresponding to the abstract syntax tree when the parameter type of the input parameter is detected to be different from the preset target parameter type; and to record second difference information and add a second comment mark indicating that the parameter value is not supported in the interface call node corresponding to the abstract syntax tree when the parameter value of the input parameter is detected to be different from the preset range of the parameter's legal value.

[0102] This also includes: The annotation node traversal module is used to traverse the interface call nodes in the abstract syntax tree that carry annotation tags after the target transformation plugin has transformed the nodes in the abstract syntax tree based on the difference table set and the built-in transformation rules. The annotation tags include the first annotation tag and the second annotation tag. The report generation module is used to obtain the difference information corresponding to the annotation tags and generate incompatibility information based on the difference information.

[0103] The code conversion device based on abstract syntax tree provided in this embodiment of the invention is included in a terminal device and can be used to execute the code conversion method based on abstract syntax tree provided in the above embodiment, and has corresponding functions and beneficial effects.

[0104] It is worth noting that in the above embodiments of the code conversion device based on abstract syntax trees, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.

[0105] This embodiment also provides a terminal device, such as Figure 7 As shown, Figure 7 This is a schematic diagram of the frame of a terminal device provided in an embodiment of the present invention. Figure 7 In the terminal device 40, a processor 400 and a memory 401 are included; Memory 401 is used to store computer program 402 and transfer computer program 402 to processor 400; The processor 400 is used to execute the steps in the above embodiment of a code transformation method based on an abstract syntax tree, according to the instructions in the computer program 402.

[0106] For example, computer program 402 may be divided into one or more modules / units, one or more of which are stored in memory 401 and executed by processor 400 to complete this application. One or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 402 in terminal device 40.

[0107] Terminal device 40 can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. Terminal device 40 may include, but is not limited to, processor 400 and memory 401. Those skilled in the art will understand that... Figure 7 This is merely an example of terminal device 40 and does not constitute a limitation on terminal device 40. It may include more or fewer components than shown, or combine certain components, or different components. For example, terminal device 40 may also include input / output devices, network access devices, buses, etc.

[0108] The processor 400 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0109] The memory 401 can be an internal storage unit of the terminal device 40, such as a hard disk or RAM of the terminal device 40. The memory 401 can also be an external storage device of the terminal device 40, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or FlashCard equipped on the terminal device 40. Furthermore, the memory 401 can include both internal and external storage units of the terminal device 40. The memory 401 is used to store computer programs and other programs and data required by the terminal device 40. The memory 401 can also be used to temporarily store data that has been output or will be output.

[0110] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0111] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0112] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0113] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0114] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing computer programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0115] This invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a code transformation method based on an abstract syntax tree. The method includes the following steps: Get the collection of difference tables; Obtain the code file of the preset file type to be converted from the file storage path of the lightweight program to be converted; The code file to be converted is parsed into an abstract syntax tree, and the corresponding target conversion plugin in the dynamic plugin system is called so that the target conversion plugin can convert the nodes in the abstract syntax tree based on the difference table set and the built-in conversion rules. The target code file is generated based on the abstract syntax tree after the transformation.

[0116] Note that the above are merely preferred embodiments and the technical principles applied in this invention. Those skilled in the art will understand that the embodiments of this invention are not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the protection scope of this invention. Therefore, although the embodiments of this invention have been described in detail above, the embodiments of this invention are not limited to the above embodiments. More other equivalent embodiments may be included without departing from the concept of the embodiments of this invention, and the scope of the embodiments of this invention is determined by the scope of the appended claims.

Claims

1. A code transformation method based on abstract syntax trees, characterized in that, The method includes: Get the collection of difference tables; Obtain the code file of the preset file type to be converted from the file storage path of the lightweight program to be converted; The code file to be converted is parsed into an abstract syntax tree, and the corresponding target conversion plugin in the dynamic plugin system is called so that the target conversion plugin can convert the nodes in the abstract syntax tree based on the difference table set and the built-in conversion rules. The target code file is generated based on the abstract syntax tree after the transformation.

2. The code conversion method based on abstract syntax trees according to claim 1, characterized in that, Before obtaining the set of difference tables, the following is also included: A dynamic plugin system is initialized, which pre-registers multiple conversion plugins. Each conversion plugin declares the file type it processes through a standardized plugin interface.

3. The code conversion method based on abstract syntax trees according to claim 1, characterized in that, The code file to be converted is a custom script file containing interface calls. The target conversion plugin performs conversion processing on the nodes in the abstract syntax tree based on the difference table set and built-in conversion rules, including: After identifying the interface call node associated with the interface call in the abstract syntax tree, the target conversion plugin performs conversion processing on the interface call node in the abstract syntax tree based on the interface difference table in the difference table set. The target conversion plugin performs conversion processing on the first type of interface differences that are not covered by the interface difference table in the interface call node, based on the built-in conversion rules.

4. The code conversion method based on abstract syntax trees according to claim 3, characterized in that, The process of converting the first type of interface differences not covered by the interface difference table in the interface call node based on the built-in conversion rules includes: In the interface call node, determine the target interface call node corresponding to the callback function of the preset interface; Based on the parameter conversion rules defined in the built-in conversion rules, modify the parameter identifier of the callback function in the target interface call node.

5. The code conversion method based on abstract syntax trees according to claim 3, characterized in that, The process of transforming the interface call nodes in the abstract syntax tree based on the interface difference table in the difference table set includes: Extract the interface call information associated with the interface call node from the abstract syntax tree; The interface call information is matched against the interface difference table to determine the difference type; Perform corresponding conversion operations on the interface call information according to the difference type, and adjust the converted interface call nodes in the abstract syntax tree.

6. The code conversion method based on abstract syntax tree according to claim 5, characterized in that, After matching the interface call information with the interface difference table to determine the difference type, the method further includes: If no corresponding target interface call node is found in the interface difference table based on the interface call information, determine whether there is a replaceable interface; In the case of a first interface calling node with a replaceable interface, the interface information of the first interface calling node is modified according to the replaceable interface and the replacement rules in the interface difference table, and the difference type is re-determined based on the modified interface information. If a second interface call node for the replaceable interface does not exist, record the missing interface information.

7. The code conversion method based on abstract syntax tree according to claim 5, characterized in that, The step of performing a corresponding conversion operation on the interface call information based on the difference type includes: For differences in interface names, replace the interface name in the interface call information with the target interface name corresponding to the interface difference table; To address differences in interface parameters, adaptation processing is performed on the input parameters in the interface call information based on the interface difference table.

8. The code conversion method based on abstract syntax tree according to claim 7, characterized in that, The adaptation processing of the input parameters in the interface call information based on the interface difference table includes: Based on the parameter verification rules recorded in the interface difference table, the input parameters in the interface call information are verified. If a naming difference is detected in the input parameter and a naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule. If the input parameter value is found to be within the preset range of valid parameter values, the parameter value is retained. If the parameter type of the input parameter is found to be the preset target parameter type, the original parameter type of the input parameter is maintained.

9. The code conversion method based on abstract syntax tree according to claim 8, characterized in that, Also includes: If the parameter type of the input parameter is not the preset target parameter type, the first difference information is recorded, and a first annotation mark indicating that the parameter is not supported is added to the interface call node corresponding to the abstract syntax tree. If the input parameter value is detected to be outside the preset range of valid parameter values, the second difference information is recorded, and a second annotation mark indicating that the parameter value is not supported is added to the interface call node corresponding to the abstract syntax tree.

10. The code conversion method based on abstract syntax tree according to claim 9, characterized in that, After the target transformation plugin performs transformation processing on the nodes in the abstract syntax tree based on the difference table set and the built-in transformation rules, it further includes: Traverse the interface call nodes carrying annotation tags in the abstract syntax tree, wherein the annotation tags include the first annotation tag and the second annotation tag; Obtain the difference information corresponding to the annotation mark, and generate incompatibility information based on the difference information.

11. A code conversion device based on an abstract syntax tree, characterized in that, The device includes: The difference table retrieval module is used to retrieve a collection of difference tables. The code file acquisition module is used to acquire the code file of the preset file type to be converted from the file storage path of the lightweight program to be converted; The conversion processing module is used to parse the code file to be converted into an abstract syntax tree, and call the corresponding target conversion plugin in the dynamic plugin system so that the target conversion plugin can convert the nodes in the abstract syntax tree based on the difference table set and the built-in conversion rules. The target code output module is used to generate target code files based on the transformed abstract syntax tree.

12. A terminal device, characterized in that, The terminal device includes a processor and a memory; The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the code transformation method based on the abstract syntax tree as described in any one of claims 1-10, according to the instructions in the computer program.

Images