Lightweight program conversion method and device and terminal equipment

Abstract

The invention provides a lightweight program conversion method and device and terminal device.The lightweight program conversion method comprises the steps that firstly, a project file set and a conversion configuration set are obtained, and then a first source code file and a second source code file in the project file set are divided according to file types; and converting the first source code file and the second source code file based on the conversion configuration set, and finally integrating to obtain a target lightweight program. According to the method, the source code file is converted on the basis of the conversion configuration set, so that the problem of rigidity of existing simple character string replacement is avoided, meanwhile, manual intervention links are greatly reduced, high dependence on experience of developers is avoided, and the conversion efficiency and accuracy of lightweight programs are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of computers, and more particularly to a lightweight program conversion method, apparatus, and terminal device. Background Technology

[0002] In existing technologies, the mainstream approach to program conversion mainly relies on a combination of simple rule-based file content replacement and manual migration by developers. Simple rule-based file content replacement typically uses a pre-defined string mapping table to globally search and replace specific keywords, interface names, or file paths in the source code. For complex differences that cannot be covered by conversion rules, developers generally rely on official migration documentation to manually compare, rewrite code, and perform functional testing to achieve adaptation.

[0003] However, existing program conversion methods have coarse-grained conversion, rigid replacement mechanisms, and lack of scalability. They struggle to cope with the rapid iterations between different platforms that lead to differences in interfaces and components, resulting in high maintenance costs. Furthermore, numerous manual intervention steps make the conversion process inefficient and highly dependent on the developer's experience. Summary of the Invention

[0004] This invention provides a lightweight program conversion method, apparatus, and terminal device, which solves the technical problems of low efficiency and low conversion accuracy in existing lightweight program conversion methods.

[0005] In a first aspect, the present invention provides a lightweight program conversion method, comprising the following steps: Obtain the project file set and conversion configuration set of the lightweight program to be converted; Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file; Based on the conversion configuration set, the first source code file and the second source code file are converted. By integrating the processed first and second source code files, the target lightweight program is obtained.

[0006] The conversion configuration set includes a set of difference tables for defining conversion rules and specific code differences, and a set of conversion plugins for processing the specific code differences; The conversion process for the first source code file and the second source code file based on the conversion configuration set includes: Based on the set of difference tables, the first source code file undergoes a first transformation process; Based on the set of difference tables and the set of conversion plugins, the second source code file undergoes a second conversion process.

[0007] The first transformation process on the first source code file based on the difference table set includes: Based on the preset file suffix difference table in the difference table set, the file suffix of the first source code file is adjusted.

[0008] Wherein, if the first source code file includes a page view file, the first transformation process of the first source code file based on the difference table set further includes: The page view file is parsed into a content object model; Based on the component difference table in the difference table set, modify the tags and attributes in the content object model; Adjust the modified content object model to the new page view file.

[0009] Wherein, if the first source code file includes a target source code file for configuring interface styles and auxiliary view processing, the first transformation process of the first source code file based on the difference table set further includes: Identify target statements in the content of the target source code file that introduce external resources; Based on the file suffix difference table, the file path suffix in the target statement corresponding to the external resource is adjusted to the target path suffix.

[0010] The second source code file includes at least a custom script file containing interface calls; The second conversion process on the second source code file based on the difference table set and the conversion plugin set includes: The custom script file is parsed into an abstract syntax tree; Based on the interface difference table in the difference table set, the interface call nodes in the abstract syntax tree are transformed. Based on the set of conversion plugins, the corresponding target conversion plugin is matched to the interface call node after conversion, so that the target conversion plugin can convert the specific code differences in the interface call node after conversion.

[0011] The step of transforming the interface call nodes in the abstract syntax tree based on the interface difference table in the difference table set includes: Traverse the abstract syntax tree to identify interface call nodes and extract the interface call information corresponding to the interface call nodes; The interface call information is matched with the interface difference table in the difference table set to determine the difference type; Perform the corresponding conversion operation on the interface call information according to the difference type, and update the converted interface call node in the abstract syntax tree.

[0012] The method further includes, after matching the interface call information with the interface difference table in the difference table set to determine the difference type, and before performing the corresponding conversion operation on the interface call information according to the difference type: For interface call information that does not match the target interface in the interface difference table, determine whether there is a replaceable interface for the interface call information; For a first interface calling node that has the replaceable interface, modify the interface information of the first interface calling 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; For second interface call nodes that do not have the aforementioned replaceable interface, record the interface missing information.

[0013] The step of performing a corresponding conversion operation on the interface call information according to 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.

[0014] 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. The parameter verification rules include at least one of parameter naming verification, parameter valid value verification, and parameter type verification. If a naming difference is detected in the parameter naming check and a corresponding naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule and the abstract syntax tree is updated synchronously. If the parameter value of the input parameter is found to be within the range of supported valid parameter values ​​during the parameter validity check, the parameter value is retained. If the parameter type of the input parameter is detected to be a supported target parameter type during the parameter type verification, the original parameter type of the input parameter shall be maintained.

[0015] This also includes: For input parameters of an unsupported parameter type, record the parameter information of the unsupported parameter; Add a first comment marker indicating that the parameter is not supported at the parameter node corresponding to the abstract syntax tree; For input parameters whose values ​​are not within the range of supported valid parameter values, record the parameter value and the corresponding interface information, and add a second annotation marker indicating that the parameter value is not supported in the abstract syntax tree.

[0016] Secondly, the present invention provides a lightweight program conversion device, the device comprising: The data acquisition module is used to acquire the project file set and conversion configuration set of the lightweight program to be converted; The file partitioning module is used to determine the first source code file and the second source code file based on the file type of the source code files in the project file set. A conversion processing module is used to perform conversion processing on the first source code file and the second source code file based on the conversion configuration set; The target lightweight program output module is used to integrate the processed first source code file and the second source code file to obtain the target lightweight program.

[0017] Thirdly, the present invention provides a terminal device, the terminal device including 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 lightweight program conversion method as described in the first aspect according to instructions in the computer program.

[0018] This application provides a lightweight program conversion method, apparatus, and terminal device. The method first obtains a project file set and a conversion configuration set. Then, it divides the project file set into a first source code file and a second source code file according to file type. Next, it performs conversion processing on the first and second source code files based on the conversion configuration set, and finally integrates them to obtain the target lightweight program. This application's method of converting source code files based on the conversion configuration set avoids the rigidity of existing simple string replacement methods, significantly reduces manual intervention, eliminates heavy reliance on developer experience, and significantly improves the efficiency and accuracy of lightweight program conversion. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a lightweight program conversion method provided in an embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram illustrating the conversion process of a second source code file, as provided in an embodiment of the present invention.

[0021] Figure 3This is a schematic diagram of the framework of a lightweight program conversion method provided in an embodiment of the present invention.

[0022] Figure 4 This is a schematic diagram illustrating the conversion of a page view file according to an embodiment of the present invention.

[0023] Figure 5 A flowchart illustrating another lightweight program conversion method provided in an embodiment of the present invention.

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

[0025] Figure 7 This is a schematic diagram of a lightweight program conversion device provided in an embodiment of the present invention.

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

[0027] 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.

[0028] In existing technologies, lightweight program conversion primarily relies on a combination of rule-based file content replacement and manual migration by developers. Rule-based file content replacement typically uses a pre-defined string mapping table to globally search and replace specific keywords, interface names, or file paths in the source code. For complex differences that conversion rules cannot cover, especially platform-specific interfaces or components, developers generally rely on official migration documentation to manually compare, rewrite code, and perform functional testing to achieve adaptation.

[0029] However, existing lightweight program conversion methods have significant limitations and defects. First, the granularity of existing technologies is relatively coarse, failing to accurately handle complex logical scenarios such as differences in interface parameters, changes in callback functions, and unequal return object structures, leading to hidden errors or functional abnormalities in the converted code. Second, rule-driven replacement mechanisms are rigid, lack extensibility, and struggle to cope with the rapid iterations between different platforms that result in differences in interfaces and components, leading to high maintenance costs. Finally, significant manual intervention makes the entire conversion process inefficient and highly dependent on developer experience, easily introducing human error and making it difficult to systematically guarantee conversion quality and stability.

[0030] Based on this, in order to solve the above-mentioned technical problems, embodiments of the present invention provide a lightweight program conversion method, such as... Figure 1 As shown, Figure 1 This is a flowchart illustrating a lightweight program conversion method provided in an embodiment of the present invention. The lightweight program 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 lightweight program conversion method provided in this embodiment includes the following steps: Step 101: Obtain the project file set and conversion configuration set of the lightweight program to be converted.

[0031] In this embodiment, the terminal device first needs to obtain the project file set and conversion configuration set of the lightweight program to be converted. The lightweight program refers to a small-sized, feature-focused application with few runtime dependencies, such as a mini-program, quick app, or lightweight web application. The project file set of the lightweight program can be obtained from the storage path where the lightweight program to be converted is stored. For example, before converting the lightweight program, the user needs to input conversion parameters, including the input path of the lightweight program to be converted (i.e., the storage location of the source code files of the lightweight program to be converted) and the output path (i.e., the storage location of the source code files of the converted target lightweight program). After receiving the conversion parameters, the terminal device can use a command-line tool to parse the user parameters, establish the association between the input path / output path and the project file set, and realize convenient conversion invocation. Then, the terminal device can read all source lightweight program files under the input path from the input path and output path parsed from the conversion parameters to form a project file set. The project file set includes source code files of various file types, such as page views, styles, scripts, and global configuration files. While acquiring the project file set, the terminal device needs to load the corresponding conversion configuration set from the preset resource library. The conversion configuration set is a predefined set of conversion rules and tools used to assist in adapting the lightweight program to the target platform specification. For example, the conversion configuration set includes a set of difference tables and a set of conversion plugins.

[0032] Step 102: Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file.

[0033] After obtaining the project file set, the terminal device needs to divide the source code files in the project file set into first source code files and second source code files based on their file types. In one embodiment, the core basis for the division is the conversion dependency of different file types. For example, files that can be converted using only the set of difference tables in the conversion configuration set are classified as first source code files, while files that require both the set of difference tables and the set of conversion plugins to be converted are classified as second source code files. For example, the terminal device can traverse the project file set and identify file types using file extensions (such as .ttml, .ttss, .js, app.json). Page view files (such as .ttml), style files (such as .ttss), and global configuration files (such as app.json) are classified as first source code files; custom script files containing API calls (such as .js) are classified as second source code files. After the terminal device completes the division, it can mark the first and second source code files with corresponding conversion link identifiers to ensure that the required difference tables and plugin resources can be accurately matched during subsequent conversions, avoiding confusion in conversion logic.

[0034] Step 103: Based on the conversion configuration set, perform conversion processing on the first source code file and the second source code file.

[0035] After obtaining the first and second source code files, the terminal device needs to further perform conversion processing on the first and second source code files based on the conversion configuration set. For example, for the first source code file, the terminal device can modify it according to the common conversion rules (such as file extension adjustment, component tag and attribute mapping, configuration field adaptation, etc.) based on the difference table set in the conversion configuration set, thereby completing the conversion process. For the second source code file, the terminal device can perform conversion processing based on the difference table set and the conversion plugin set in the conversion configuration set. For example, the second conversion process involves performing a basic conversion based on the difference table set in the conversion configuration set, and then performing a supplementary conversion based on the conversion plugin set.

[0036] Step 104: Integrate the processed first source code file and the second source code file to obtain the target lightweight program.

[0037] After converting the first and second source code files, the terminal device needs to integrate the converted files to generate a runnable lightweight target program. For example, the terminal device first verifies the file integrity and syntax compliance; if problems are found, they are reported via logs. If the verification passes, the converted files are categorized and stored according to the standard directory structure of the lightweight target program. Finally, the categorized and stored file set is output to the user-specified output path, forming a lightweight target program that can be directly run in development tools, completing the entire conversion process.

[0038] The present invention provides a lightweight program conversion method. This application first obtains a project file set and a conversion configuration set. Then, it divides the project file set into a first source code file and a second source code file according to file type. Next, it performs conversion processing on the first and second source code files based on the conversion configuration set, and finally integrates them to obtain the target lightweight program. This application's method of converting source code files based on the conversion configuration set avoids the rigidity of existing simple string replacement methods, significantly reduces manual intervention, eliminates high dependence on developer experience, and significantly improves the efficiency and accuracy of lightweight program conversion.

[0039] Based on the above embodiments, the conversion configuration set includes a set of difference tables for defining conversion rules and specific code differences, and a set of conversion plugins for handling specific code differences.

[0040] In this embodiment, the conversion configuration set includes a set of difference tables and a set of conversion plugins. The difference table set includes multiple difference tables, each defining the code differences between the lightweight program to be converted and the target lightweight program, as well as general conversion rules and complex, personalized conversion scenarios (i.e., specific code differences) that the difference tables cannot cover. The difference tables provide general, directly callable basic rules for the conversion of lightweight programs, supporting most conversion scenarios that do not require special handling and reducing additional code intervention during the conversion process. For example, the difference table set includes file extension difference tables, interface difference tables, component difference tables, configuration difference tables, etc. The conversion plugin set is a component of the conversion configuration set used to supplement and handle specific code differences that the difference tables cannot cover. Its function focuses on complex or personalized conversion scenarios that the difference tables cannot handle (such as callback parameter mapping for specific interfaces and special syntax adaptation). For example, the conversion plugin set includes multiple conversion plugins, each working only for a single or a specific type of code difference scenario, without interfering with the general conversion logic supported by the difference tables, ensuring that more detailed requirements are covered during the lightweight program conversion process, and improving the accuracy and adaptability of the conversion results.

[0041] Based on the above embodiments, step 103 involves converting the first source code file and the second source code file based on the conversion configuration set, including: Step 1031: Based on the difference table set, perform the first transformation process on the first source code file.

[0042] For the first source code file, the terminal device needs to perform a first transformation process based on the set of difference tables in the transformation configuration set. This first transformation process involves completing basic adaptation based on the general transformation rules provided by the difference tables. For example, for a page view file in the first source code file, the terminal device can first call the component difference table in the difference table set to parse the page view file into a document object model, and then perform the transformation according to the mapping rules between the source lightweight program tags and the target lightweight program tags in the component difference table (such as...). <sjs> → <wxs>The process involves modifying tags and attributes in the Document Object Model (DOM) by changing `tt:if` to `wx:if`, and then serializing the modified DOM into a new page view file. For style files in the first source code file (such as `pages / index / index.ttss`), the terminal device can call the file suffix difference table in the difference table set to identify statements that introduce external resources in the style file. Following the replacement rules of the source and target suffixes in the file suffix difference table, the device replaces the file path suffix of the external resources in the statements. The entire conversion process does not require calling the conversion plugin set; it can be completed solely through the general rules provided by the difference table set, ensuring that the first source code file quickly adapts to the basic syntax specifications of the target lightweight program.

[0043] Step 1032: Based on the set of difference tables and the set of conversion plugins, perform a second conversion process on the second source code file.

[0044] For the second source code file, the terminal device needs to perform a second transformation based on the difference table set and the transformation plugin set. The specific process of the second transformation is as follows: after performing a basic transformation based on the difference table set in the transformation configuration set, a supplementary transformation is performed based on the transformation plugin set to cover special code differences that the difference table cannot handle. For example, such as... Figure 2 As shown, Figure 2 This is a schematic diagram illustrating the conversion process of a second source code file provided in an embodiment of the present invention. Taking a custom script file containing interface calls as an example, the terminal device first parses the custom script file into an abstract syntax tree (AST). The AST is an abstract representation of the source code's syntactic structure, presenting the code's syntax structure in a tree-like data structure. Each node corresponds to a syntactic component in the source code (such as variable declaration, function call, expression, etc.). Then, the tree structure is traversed to identify interface call nodes. Based on the name mapping rules between the source and target interfaces in the interface difference table, the interface name nodes in the AST are modified. Subsequently, a dedicated plugin from the conversion plugin set is invoked to perform supplementary conversion, locating specific callback nodes in the interface calls. For special parameter scenarios not covered by the interface difference table, the corresponding parameter nodes in the AST are modified. Finally, a source code file conforming to the target lightweight program's syntax specification is generated based on the modified AST, serving as the result of the second conversion process on the second source code file. After completing the conversion processes of the first and second source code files, the terminal device needs to integrate the converted first and second source code files to ultimately generate a runnable target lightweight program. Figure 3 As shown, Figure 3 This is a schematic diagram illustrating the framework of a lightweight program conversion method provided in an embodiment of the present invention. In another embodiment, the first source code file further includes a global configuration file, and the conversion configuration set further includes a configuration difference table for defining the global configuration conversion rules of the lightweight program. The terminal device can also convert the global configuration file of the lightweight program based on the configuration difference table. Finally, the first source code file after the first conversion process and the second source code file after the second conversion process are integrated to obtain the target lightweight program.

[0045] The embodiments of the present invention employ differentiated methods—namely, using a difference table for individual conversion and a difference table combined with conversion plugins for collaborative conversion—to process the first and second source code files. This approach achieves universal rule conversion through a set of difference tables, avoiding the rigidity of existing simple string replacement methods. Furthermore, the conversion plugin set is adapted to the unique differences of different lightweight programs, improving scalability for iterative differences across different platforms, reducing maintenance costs, and significantly minimizing manual intervention. This approach reduces reliance on developer experience and significantly improves the efficiency and accuracy of lightweight program conversion.

[0046] Based on the above embodiments, step 1031, which involves performing a first transformation process on the first source code file based on the difference table set, includes: Step 10311: Adjust the file extension of the first source code file based on the preset file extension difference table in the difference table set.

[0047] For example, the first source code file includes a page view file, a style file, and an SJS script file. The page view file is the core carrier of the lightweight program's view layer, used to define the page's UI structure, component layout, and data binding relationships. The style file controls the visual presentation of the page view file, defining the layout, color, font, and other style attributes of page elements. The SJS script file is a lightweight logic processing carrier of the lightweight program's view layer, used to perform simple data processing or logical judgments within the view layer.

[0048] When a terminal device performs lightweight program conversion, it inputs conversion parameters via a command-line tool. These parameters include the input path of the lightweight program to be converted (i.e., the storage path of the first source code file to be converted, such as . / source-tt) and the output path (i.e., the storage path of the converted first source code file, such as . / target-xz). The first source code file is then selected from the input path, including page view files (e.g., . / source-tt / pages / index / index.ttml), style files (e.g., . / source-tt / pages / index / index.ttss), and SJS script files (e.g., . / source-tt / common / tools.sjs). During the first conversion process on the first source code file based on the difference table set, the file extension difference table in the difference table set is first invoked. This file extension difference table predefines the file extension mapping rules between the lightweight program and the target lightweight program for the first source code file extensions. For example, the suffix mapping rules are as follows: the page view file suffix .ttml corresponds to the target suffix .xzml, the style file suffix .ttss corresponds to the target suffix .xzss, and the SJS script file suffix .sjs corresponds to the target suffix .xzs. Then, the terminal device performs suffix replacement on the first source code file based on the file suffix difference table. For example, . / source-tt / pages / index / index.ttml is replaced with . / target-xz / pages / index / index.xzml, . / source-tt / pages / index / index.ttss is replaced with . / target-xz / pages / index / index.xzss, and . / source-tt / common / tools.sjs is replaced with . / target-xz / common / tools.xzs, thus completing the basic conversion of the first source code file based on the file suffix difference table. In another embodiment, the terminal device may also perform a suffix replacement operation simultaneously while copying the first source code file from the input path to the output path.

[0049] As described above, the embodiments of the present invention, based on a preset file suffix difference table in the difference table set, realize batch and accurate adaptation of multiple types of first source code file suffixes, and complete the basic format conversion without manual intervention. Compared with the existing technology, which relies on simple string global replacement or manual modification for suffix conversion, it can improve conversion efficiency and accuracy.

[0050] Based on the above embodiments, when the first source code file includes a page view file, step 1031, which involves performing a first transformation process on the first source code file based on the difference table set, further includes: Step 10312: Parse the page view file into a content object model.

[0051] In this embodiment, platform-specific tags and attributes within the page view file need further conversion and adaptation. First, the terminal device needs to parse the page view file into a Content Object Model (DOM). The DOM is a structured tree-like data model for the page view file, its core function being to transform unstructured tags, attributes, and text content into a computer-readable and modifiable hierarchical node structure. For example, the DOM can be a Document Object Model (DOM). Exemplarily, the terminal device can use file structure parsing tools (such as the unified library and the stricter-htmlparser2 parsing plugin) to parse the page view file into a DOM. Figure 4 As shown, Figure 4 This is a schematic diagram illustrating the conversion of a page view file according to an embodiment of the present invention. Figure 4 In this process, the terminal device reads the page view file (such as . / source-tt / pages / index / index.ttml) through the vfile module of the unified library, a file structure parsing tool. After constructing a structured representation of the file, it calls the unified library to execute a processing chain of parsing, custom transformation (ttmlToXxml), and serialization (stringify), realizing the transformation from the source file to the Document Object Model and the new file. The specific process is as follows: Parsing Phase: The stricter-htmlparser2 parsing plugin is used to parse the text content of the page view file into a Document Object Model (DOM). For example, for...<importsrc=".. / .. / .. / common / head.ttml" / > After parsing, the DOM structure of the tag will contain fields such as type:'tag' (tag type), name:'import' (tag name), attribs:{src:'.. / .. / .. / common / head.ttml'} (tag attributes), and children:[] (child elements), clearly presenting the hierarchy and content composition of the page view.

[0052] Conversion Phase: A custom `ttmlToXxml` conversion function is used (this function, based on the component difference table, defines the mapping rules between the source lightweight application tags and the target lightweight application tags; for example, it converts...). <sjs>Replace with <xzs>Replace tt:if with xz:if), traverse and modify tags and attributes in the DOM to complete the syntax adaptation.

[0053] Serialization stage: The stringify plugin of unified is called to serialize the modified DOM structure into text content, and finally the content is saved as the page view file of the target lightweight program (such as . / target-xz / pages / index / index.xzml).

[0054] Step 10313: Based on the component difference table in the difference table collection, modify the tags and attributes in the content object model.

[0055] After converting the page view file into a content object model, the terminal device needs to modify the tags and attributes in the content object model based on the component difference table in the difference table set. The component difference table in the difference table set predefines the tag mapping rules (such as tag replacement, component attribute adjustment, etc.), tag attribute processing rules (such as src path suffix adaptation), and special syntax conversion rules (such as conditional rendering syntax replacement) between the lightweight application and the target lightweight application's page view files. It is the core basis for the specific conversion of the page view file. For example, this page view file includes unique tags.<sjssrc=". / utils.sjs" / > Conditional rendering syntax tt:if="{{show}}" and importing external view files<importsrc=".. / .. / .. / common / head.ttml" / > Tags. For example, a terminal device can access a component difference table and process different tags according to the conversion rules in the component difference table. The specific processing procedure is as follows: (1) To <import>The tag replaces the remaining source lightweight program suffix ".ttml" in its src attribute with the target suffix ".xzml". After processing, the src path is .. / .. / .. / common / head.xzml.

[0056] (2) To <sjs>Tags, replaced with the target lightweight program's tags according to the component difference table rules. <xzs>The tag is modified by replacing the .sjs extension in its src attribute with .xzs, resulting in the tag being...<xzssrc=". / utils.xzs" / > .

[0057] For example, the tt:if conditional rendering syntax in the page view file is replaced with the xz:if syntax of the target lightweight application according to the conversion rules in the component difference table. After processing, the syntax becomes xz:if="{{show}}". In addition, if the page view file includes unique components recorded in the component difference table, the terminal device can further replace them with the corresponding components of the target lightweight application according to the component difference table and adjust the component's attribute mapping.

[0058] Step 1034: Adjust the modified content object model to the new page view file.

[0059] After modifying the tags and attributes of the content object model, the terminal device needs to readjust the processed content object model into a new page view file. For example, the content object model can be reserialized into a new page view file using the stringify plugin of the unified library, and the new page view file can be used to overwrite the original page view file.

[0060] As described above, by combining the component difference table and the content object model, a deep conversion of the page view file content adaptation is achieved, avoiding the tedious operation of manually modifying tags and attributes one by one in the existing technology. This not only improves the conversion accuracy of the page view file, but also further reduces the manual intervention and improves the conversion efficiency.

[0061] Based on the above embodiments, when the first source code file includes a target source code file for configuring interface styles and auxiliary view processing, step 103, which involves performing a first transformation process on the first source code file based on the difference table set, further includes: Step 1035: Identify the target statements in the target source code file that introduce external resources.

[0062] In this embodiment, the first source code file includes target source code files for configuring interface styles and auxiliary view processing. Interface styles refer to configuration content defining the layout, colors, fonts, spacing, and other visual presentation effects of the lightweight program page. Auxiliary view processing refers to auxiliary configuration logic that supports non-visual but ensures normal view rendering, such as page view loading, resource import, and conditional display. For example, the source code file for configuring interface styles is a style file, and the source code file for auxiliary view processing is an SJS script file. When the target source code file includes both a style file and an SJS script file, the paths of external resources imported within the style file and SJS script file using specific syntax retain the file extension of the original lightweight program and need further adaptation to the target lightweight program format. These external resources are resource files that need to be loaded from outside to support the functionality of the target lightweight program. Based on this, the terminal device also needs to further identify the target statements in the target source code file that import external resources. For example, target statements refer to statements in the style file that import external style files using the `@import` keyword, and statements in the SJS script file that import external SJS script files using the `require` keyword. Terminal devices can use text parsing technology to locate target statements in style files and SJS script files respectively. Specifically, for style files, they can identify target statements containing the @import keyword followed by a file path; for SJS script files, they can identify target statements containing the require keyword followed by a file path.

[0063] Step 1036: Based on the file suffix difference table, adjust the file path suffix in the target statement corresponding to the external resource to the target path suffix.

[0064] After identifying the target statement in the target source code file, it is necessary to adjust the file path suffix corresponding to the external resource in the target statement to the target path suffix based on the file suffix difference table. In this embodiment, the file suffix difference table also predefines the suffix mapping rules of external resource files between the source lightweight program and the target lightweight program. For example, in the stylesheet file, the target statement `@import ".. / .. / common / base.ttss"` extracts the file path suffix `.ttss`. Based on the replacement rule in the file suffix difference table (source suffix `.ttss` → target suffix `.xzss`), the file path is replaced with `.. / .. / common / base.xzss`, resulting in the target statement `@import ".. / .. / common / base.xzss"`. Similarly, in the SJS script file, the target statement `const utils=require(". / utils.sjs")` extracts the file path suffix `.sjs`. Based on the replacement rule in the file suffix difference table (source suffix `.sjs` → target suffix `.xzs`), the file path is replaced with `. / utils.xzs`, resulting in the target statement `const utils=require(". / utils.xzs)`.

[0065] In one embodiment, if a style file contains multiple external style import statements, the terminal device can identify all @import statements in batches and uniformly replace the file path suffix; if the external resource path imported by the SJS script file contains multiple levels of directories (such as require(".. / lib / helper.sjs")), only the .sjs suffix at the end of the path is extracted and replaced, keeping the path hierarchy unchanged.

[0066] The above method, by introducing the target statement of external resources and replacing the file path suffix of external resources based on the file suffix difference table, eliminates the need to manually search and modify the path suffix of external resources one by one. This avoids the problem of lightweight program resource loading failure caused by path suffix mismatch, ensures the complete adaptation of the first source code file, and improves the efficiency and accuracy of the lightweight program conversion method.

[0067] This invention also provides another lightweight program conversion method, such as... Figure 5 As shown, Figure 5 This is a flowchart illustrating another lightweight program conversion method provided in an embodiment of the present invention. Figure 5 The lightweight program conversion method shown is a specific implementation of the above-mentioned lightweight program conversion method. In this embodiment, a mini-program is used as an example for illustration. The lightweight program conversion method provided by this embodiment includes: Step 201: Obtain the project file set and conversion configuration set of the lightweight program to be converted. The conversion configuration set includes a set of difference tables for defining conversion rules and specific code differences, and a set of conversion plugins for handling specific code differences.

[0068] Step 202: Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file.

[0069] Step 203: Based on the difference table set, perform the first transformation process on the first source code file.

[0070] Step 204: Parse the custom script file into an abstract syntax tree.

[0071] In this embodiment, the second source code file includes at least a custom script file containing interface calls. This custom script file is a script file used in the mini-program to implement business logic. Its core feature is that it contains interface call statements, used to implement specific business functions such as data requests and functional interactions by calling interfaces. When processing the custom script file, the terminal device first needs to convert it into an abstract syntax tree (AST). For example, the terminal device can use a syntax transpilation tool (such as Babel) to parse the content of the custom script file into an AST. For instance, 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. After the terminal device reads the content of the custom script file through Node.js's `fs` module, it uses the Babel tool to parse the file into an Abstract Syntax Tree (AST). For example, for the API call statement `tt.getSystemInfo({success:(res)=>{console.log(res.pageOrientation)}})`, Babel will parse it into an AST structure containing `ExpressionStatement`, `CallExpression`, and `MemberExpression`. The `object` node of `MemberExpression` has an `Identifier` node for `name:"tt"`, the `property` node has an `Identifier` node for `name:"getSystemInfo"`, and the `arguments` node of `CallExpression` contains the callback function-related structure, consistent with the syntax logic of the API call. Therefore, if a custom script file contains multiple API call statements, the terminal device can batch parse all code segments containing API calls into their corresponding AST nodes.

[0072] Step 205: Based on the interface difference table in the difference table set, perform transformation processing on the interface call nodes in the abstract syntax tree.

[0073] After obtaining the Abstract Syntax Tree (AST), the terminal device can perform conversion processing on the interface call nodes in the AST based on the interface difference table in the difference table set. The interface call node is a structured node in the AST corresponding to the interface call statement in the source code, storing information such as the interface name and input parameters. In this embodiment, the interface difference table predefines the name mapping rules, parameter difference rules, and status identifiers between the source and target mini-programs. The terminal device can use the interface difference table to perform conversion processing on the interface call nodes in the AST. For example, the interface difference table includes interface definitions such as APIDiffItem, where the type field records the interface difference type, the status field identifies the detailed difference status, and the replace field stores the target interface name or parameter replacement value. 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 terminal device 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 call node, if its parameter errMsg is marked as DIFF_PARAM in the interface difference table and the replace field is message, then the terminal device further modifies the AST node corresponding to err.errMsg in the callback function, replacing errMsg with message.

[0074] Step 206: Based on the set of conversion plugins, match the corresponding target conversion plugin to the interface call node after conversion, so that the target conversion plugin can convert the specific code differences in the interface call node after conversion.

[0075] After converting the interface call nodes, some nodes still have specific code differences that cannot be covered by the interface difference table. In this case, it is necessary to match the target conversion plugin based on the conversion plugin set. Specifically, the terminal device first uses the key node features of the Abstract Syntax Tree (AST) and the interface identifier as matching dimensions to locate the adaptation plugin. For example, the key node features of the AST include node types such as CallExpression and MemberExpression, which can be used to locate the interface call location, while the interface identifier includes information such as the interface name. The terminal device traverses the conversion plugin set and, based on the plugin's preset parseType (adapting to specific interface scenarios), selects the target plugin that is compatible with the interface call node to be processed. The target plugin is then used to handle the specific code differences that cannot be covered by the interface difference table.

[0076] For example, the conversion plugin collection includes dedicated plugins (such as SystemInfoPlugin) for specific interface scenarios. The plugin type conforms to the IBabelPlugin interface definition and has name, parseType properties, and an apply method. For parameter differences in the source mini-program's callback res.pageOrientation and the target mini-program's res.deviceOrientation that cannot be handled by the interface difference table, the terminal device traverses the conversion plugin collection and matches the target conversion plugin SystemInfoPlugin based on the name (getSystemInfo) of the converted interface call node. The target conversion plugin SystemInfoPlugin injects AST traversal logic through the apply method, locates the success callback node (ArrowFunctionExpression type) of the wx.getSystemInfo call node, calls the internal replacePageOrientationInSuccessCallback method, and replaces the property (name:"pageOrientation") of the MemberExpression node corresponding to res.pageOrientation in the AST with name:"deviceOrientation", thus completing the specific code difference conversion.

[0077] It should be noted that if there are complex scenarios that cannot be identified during the first AST traversal, a secondary detection mechanism can be used to supplement and handle the uncovered scenarios. For example, the target plugin can define a secondary detection execution method in the check object. After the first AST traversal is completed, the secondary detection execution method is called uniformly to perform secondary detection and supplementary transformation, ensuring that all uncovered special code differences are handled.

[0078] Step 207: Integrate the processed first source code file and second source code file to obtain the target lightweight program.

[0079] 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 a set of transformation plugins to match target plugins 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 lightweight program transformation, and reduces the risk of functional abnormalities caused by improper interface adaptation.

[0080] Based on the above embodiments, step 205 involves transforming the interface call nodes in the abstract syntax tree based on the interface difference table in the difference table set, including: Step 2051: Traverse the abstract syntax tree to identify the interface call node and extract the interface call information corresponding to the interface call node.

[0081] In this embodiment, when processing the abstract syntax tree based on the interface difference table, after traversing the abstract syntax tree to identify the interface call nodes, it is necessary to further extract the interface call information corresponding to the interface call nodes. For example, the 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 lightweight program conversion process, which is used to specify the core configurations such as the path and type required for conversion. For example, the terminal device traverses the abstract syntax tree through a syntax transpilation tool (such as Babel) and locates all interface call nodes through two key node types: CallExpression and MemberExpression. The object field (e.g., name: "tt") of the MemberExpression node is the interface prefix, the property field (e.g., name: "getSystemInfo") is the specific interface name, and the arguments field of the CallExpression node is 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)})`.

[0082] Step 2052: Match the interface call information with the interface difference table in the difference table set to determine the difference type.

[0083] Next, the terminal device matches the extracted interface call information against the interface difference table one by one, and determines the difference type based on the interface difference table. For example, the terminal device can determine the difference type based on the `type` and `status` fields, and the difference types include: (1) Difference in interface name: status is DIFF_NAME, indicating that the interface names are different; (2) Differences in interface parameters: if status is DIFF_PARAM, it means that the parameter name, supported values ​​or callback parameters are different; For example, when matching tt.getSystemInfo, the status of this interface in the interface difference table is DIFF_NAME, the replace field is wx.getSystemInfo, and the difference type is determined to be "interface name difference". When matching tt.onError, the params field of this interface in the interface difference table records that the errMsg parameter needs to be replaced with message, the status is DIFF_PARAM, and the difference type is determined to be "interface parameter difference".

[0084] Step 2053: Perform the corresponding conversion operation on the interface call information according to the difference type, and update the converted interface call node in the abstract syntax tree.

[0085] After determining the difference type, corresponding transformation operations can be performed on the interface call information according to the difference type. For example, for interface name differences, the interface name in the interface call node can be replaced; for interface parameter differences, the callback parameters can be replaced. After the transformation operation is completed, the corresponding interface call node in the Abstract Syntax Tree (AST) is updated. In one embodiment, performing corresponding transformation operations on the interface call information according to the difference type includes: Step 20531: For interface name differences, replace the interface name in the interface call information with the corresponding target interface name in the interface difference table.

[0086] In this embodiment, the terminal device replaces the interface name of the interface call node in the Abstract Syntax Tree (AST) according to the target interface name recorded in the interface difference table. For example, the terminal device matches tt.getSystemInfo in 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. The object of this node is the Identifier node with name: "tt", and the property is the Identifier node with name: "getSystemInfo". The terminal device 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 updated synchronously.

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

[0088] When the difference type is interface parameter difference, the terminal device needs to process the extracted input parameters according to the parameter mapping rules defined in the interface difference table. For example, the terminal device can call the interface difference table in the difference table set, 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. For example, 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 is recorded in the `replace` field, the parameter name is modified according to the naming replacement rule. In parameter valid value verification, if the parameter value is within the range of valid values ​​recorded in the `extra` field, the original parameter value is retained. In parameter type verification, if the parameter type belongs to the supported 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 updated to the AST.

[0089] Based on the above embodiments, step 20532 performs adaptation processing on the input parameters in the interface call information 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. The parameter verification rules include at least one of parameter naming verification, parameter valid value verification, and parameter type verification. If a naming difference is detected in the parameter naming check and a corresponding naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule and the abstract syntax tree is updated synchronously. If the parameter value is found to be within the range of supported valid parameters during the parameter validity check, the parameter value is retained. If the parameter type of the input parameter is detected to be a supported target parameter type during parameter type verification, the original parameter type of the input parameter shall be maintained.

[0090] For example, the parameter verification rules consist of the type field (marking the verification type), the extra field (storing the list of valid values / supported types), and the replace field (storing the naming replacement rules) of the IPAramDiff in the interface difference table. After the terminal device extracts the input parameters, it first calls the interface difference table to perform the verification to determine whether the parameters need to be adjusted.

[0091] For example, when parameter naming checks detect a naming difference in the input parameter, and a corresponding naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule, and the abstract syntax tree is updated synchronously. For instance, for the input parameter `duration` in `tt.showToast({title:'Prompt', duration:2000})`, the terminal device 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 key attribute `name` of that node is changed from `duration` to `timeout`, and the abstract syntax tree is updated synchronously.

[0092] When the parameter validity check detects that the value of the input parameter is within the range of valid values ​​supported by the interface difference table, the parameter value is retained. 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 supported values ​​such as ["none", "success"]). Since "none" is detected to be within the supported range, the parameter value does not need to be modified, and the original configuration is directly retained.

[0093] When the parameter type check detects that the type of the input parameter is a supported target parameter type preset in the interface difference table, the original parameter configuration is maintained. For example, for the data parameter of tt.request({url:' / interface',data:{id:1}}), the data parameter type is identified as "Object", and it matches the params.data.extra field of tt.request in the interface difference table (which stores supported types such as ["Object","string"]); if it is confirmed that the "Object" type is within the supported range, the original configuration of data:{id:1} is maintained, and there is no need to adjust the AST node.

[0094] The above-mentioned automated 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 mini-program specifications in terms of naming, value and type, and further improves the accuracy and efficiency of interface parameter conversion.

[0095] 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, and before performing the corresponding conversion operation on the interface call information according to the difference type, the method further includes: Step 2054: For interface call information that does not match the corresponding target interface in the interface difference table, determine whether there is a replaceable interface for the interface call information.

[0096] Step 2055: For the 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.

[0097] Step 2056: For second interface call nodes that do not have a replaceable interface, record the missing interface information.

[0098] For example, such as Figure 6 As shown, Figure 6 This is a schematic diagram of an interface replacement process provided in an embodiment of the present invention. Figure 6 In this process, when the terminal device 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 the first interface call node has a replaceable interface, the interface information of the first interface call node can be modified according to the replaceable interface and the replacement rules in the interface difference table. For example, for a first interface call node with a replaceable interface (the replace field in the difference table has a value), the name of the first interface call node in the AST is modified according to the replacement rules. For example, if the replace field of the tt.old interface is wx.newApi, the terminal device locates the MemberExpression node in the AST, changes object(tt) to wx and property(oldApi) to newApi, and updates the AST synchronously. Then, the difference type is re-determined based on the modified interface name. If the second interface call node is determined to have no replaceable interface (e.g., the replace field in the difference table is empty and the status is marked "missing"), the missing interface information is recorded.

[0099] Based on the above embodiments, it also includes: For input parameters of unsupported types, record the parameter information for unsupported parameters; Add a first comment marker indicating that the parameter is not supported at the parameter node corresponding to the abstract syntax tree; For input parameters whose values ​​are not within the range of supported valid values, record the parameter value and the corresponding interface information, and add a second annotation marker indicating that the parameter value is not supported in the abstract syntax tree.

[0100] In this embodiment, when the terminal device detects that the input parameter type is unsupported, it records the parameter information of the unsupported parameter, including the parameter name, the interface identifier, and the reason for the difference. Simultaneously, the terminal device adds a first comment marker indicating that the parameter is unsupported at the parameter node corresponding to the abstract syntax tree. For example, when the terminal device 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 key information, including the parameter name, the 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 comment 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.

[0101] If a parameter value is detected to be outside the supported range of valid values, the parameter value and its corresponding interface information can be recorded. Simultaneously, a second annotation marking the unsupported parameter value is added to 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 `params` field `extra` of the interface difference table, the logging module is invoked to record the parameter value and its corresponding interface information. At the same time, the node corresponding to the parameter value in the AST is located, and an annotation is added next to the node, indicating both the unsupported value and the valid range.

[0102] 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.

[0103] This invention also provides a lightweight program conversion device, such as... Figure 7 As shown, Figure 7 This is a schematic diagram of a lightweight program conversion device provided in an embodiment of the present invention. The lightweight program conversion device provided in this embodiment of the present invention includes: The data acquisition module 301 is used to acquire the project file set and conversion configuration set of the lightweight program to be converted.

[0104] The file partitioning module 302 is used to determine the first source code file and the second source code file based on the file type of the source code files in the project file set.

[0105] The conversion processing module 303 is used to perform conversion processing on the first source code file and the second source code file based on the conversion configuration set.

[0106] The target lightweight program output module 304 is used to integrate the processed first source code file and the second source code file to obtain the target lightweight program.

[0107] The conversion configuration set includes a set of difference tables for defining conversion rules and specific code differences, and a set of conversion plugins for handling specific code differences. The conversion processing module 303 includes: The first conversion processing submodule is used to perform a first conversion processing on the first source code file based on the difference table set; The second conversion processing submodule is used to perform a second conversion process on the second source code file based on the set of difference tables and the set of conversion plugins.

[0108] Specifically, the first conversion processing submodule is used to adjust the file extension of the first source code file based on a preset file extension difference table in the difference table set.

[0109] Where the first source code file includes a page view file, the first conversion processing submodule further includes: The model parsing unit is used to parse the page view file into a content object model; The model modification unit is used to modify the tags and attributes in the content object model based on the component difference table in the difference table collection. The model serialization unit is used to adapt the modified content object model into a new page view file.

[0110] Where the first source code file includes a target source code file for configuring interface styles and auxiliary view processing, the first conversion processing submodule further includes: The external resource identification unit is used to identify target statements in the content of the target source code file that introduce external resources. The suffix replacement unit is used to adjust the file path suffix in the target statement corresponding to the external resource to the target path suffix based on the file suffix difference table.

[0111] The second source code file includes at least a custom script file containing interface calls; The second conversion processing submodule includes: The syntax tree parsing unit is used to parse custom script files into an abstract syntax tree; The node processing unit is used to transform the interface call nodes in the abstract syntax tree based on the interface difference table in the difference table set; The plugin conversion unit is used to match the corresponding target conversion plugin to the interface call node after conversion based on the set of conversion plugins, so that the target conversion plugin can convert the specific code differences in the interface call node after conversion.

[0112] The node processing unit includes: Syntax tree traversal sub-units are used to traverse the abstract syntax tree to identify interface call nodes and extract the interface call information corresponding to the interface call nodes. The difference type determination subunit is used to match the interface call information with the interface difference table in the difference table set to determine the difference type; The information conversion subunit is used to perform corresponding conversion operations on the interface call information according to the difference type, and update the converted interface call nodes in the abstract syntax tree.

[0113] The lightweight program conversion device also includes: The API replacement judgment subunit is used to determine whether there is a replaceable interface for interface call information that does not match the corresponding target interface in the interface difference table after matching the interface call information with the interface difference table in the difference table set and determining the difference type, and before performing the corresponding conversion operation on the interface call information according to the difference type. The API replacement subunit is used to modify the interface information of the first interface call node with a replaceable interface 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. The API Missing Record Sub-unit is used to record missing interface information for second interface call nodes that do not have a replaceable interface.

[0114] Specifically, the information conversion subunit 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.

[0115] Specifically, the information conversion subunit is used to verify the input parameters in the interface call information based on the parameter verification rules recorded in the interface difference table. The parameter verification rules include at least one of parameter naming verification, parameter validity value verification, and parameter type verification. If the parameter naming verification detects a naming difference in the input parameter and there is a corresponding naming replacement rule in the interface difference table, the name of the input parameter is modified according to the naming replacement rule and the abstract syntax tree is updated synchronously. If the parameter validity value verification detects that the parameter value of the input parameter is within the range of supported parameter validity values, the parameter value is retained. If the parameter type verification detects that the parameter type of the input parameter is a supported target parameter type, the original parameter type of the input parameter is maintained.

[0116] Specifically, the information conversion subunit is used to record the parameter information of unsupported parameters for input parameters of unsupported parameter types; add a first comment mark indicating that the parameter is not supported at the corresponding parameter node in the abstract syntax tree; and record the parameter value and corresponding interface information of input parameters whose parameter values ​​are not within the range of supported parameter values, and add a second comment mark indicating that the parameter value is not supported in the abstract syntax tree for input parameters.

[0117] The lightweight program conversion device provided in this embodiment of the invention is included in a terminal device and can be used to execute the lightweight program conversion method provided in the above embodiment, and has corresponding functions and beneficial effects.

[0118] It is worth noting that in the embodiments of the lightweight program conversion device described above, 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.

[0119] This embodiment also provides a terminal device, such as Figure 8 As shown, Figure 8 This is a schematic diagram of the frame of a terminal device provided in an embodiment of the present invention. Figure 8 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-described embodiment of a lightweight program conversion method according to the instructions in the computer program 402.

[0120] 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.

[0121] Terminal device 40 may be a computing device such as a desktop computer, laptop, or 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 8 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.

[0122] 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] This invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform a lightweight program conversion method, the method comprising the following steps: Obtain the project file set and conversion configuration set of the lightweight program to be converted; Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file; Based on the conversion configuration set, the first source code file and the second source code file are converted. By integrating the processed first and second source code files, the target lightweight program is obtained.

[0130] 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.< / xzs> < / sjs> < / import> < / xzs> < / sjs> < / wxs> < / sjs>

Claims

1. A lightweight program conversion method, characterized in that, Includes the following steps: Obtain the project file set and conversion configuration set of the lightweight program to be converted; Based on the file types of the source code files in the project file set, determine the first source code file and the second source code file; Based on the conversion configuration set, the first source code file and the second source code file are converted. By integrating the processed first and second source code files, the target lightweight program is obtained.

2. The lightweight program conversion method according to claim 1, characterized in that, The conversion configuration set includes a set of difference tables for defining conversion rules and specific code differences, and a set of conversion plugins for handling the specific code differences; The conversion process for the first source code file and the second source code file based on the conversion configuration set includes: Based on the set of difference tables, the first source code file undergoes a first transformation process; Based on the set of difference tables and the set of conversion plugins, the second source code file undergoes a second conversion process.

3. The lightweight program conversion method according to claim 2, characterized in that, The first transformation process on the first source code file based on the difference table set includes: Based on the preset file suffix difference table in the difference table set, the file suffix of the first source code file is adjusted.

4. The lightweight program conversion method according to claim 3, characterized in that, When the first source code file includes a page view file, the first transformation process of the first source code file based on the difference table set further includes: The page view file is parsed into a content object model; Based on the component difference table in the difference table set, modify the tags and attributes in the content object model; Adjust the modified content object model to the new page view file.

5. The lightweight program conversion method according to claim 3, characterized in that, When the first source code file includes a target source code file for configuring interface styles and auxiliary view processing, the first transformation process of the first source code file based on the difference table set further includes: Identify target statements in the content of the target source code file that introduce external resources; Based on the file suffix difference table, the file path suffix in the target statement corresponding to the external resource is adjusted to the target path suffix.

6. The lightweight program conversion method according to claim 2, characterized in that, The second source code file includes at least a custom script file containing interface calls; The second conversion process on the second source code file based on the difference table set and the conversion plugin set includes: The custom script file is parsed into an abstract syntax tree; Based on the interface difference table in the difference table set, the interface call nodes in the abstract syntax tree are transformed. Based on the set of conversion plugins, the corresponding target conversion plugin is matched to the interface call node after conversion, so that the target conversion plugin can convert the specific code differences in the interface call node after conversion.

7. The lightweight program conversion method according to claim 6, 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: Traverse the abstract syntax tree to identify interface call nodes and extract the interface call information corresponding to the interface call nodes; The interface call information is matched with the interface difference table in the difference table set to determine the difference type; Perform the corresponding conversion operation on the interface call information according to the difference type, and update the converted interface call node in the abstract syntax tree.

8. The lightweight program conversion method according to claim 7, characterized in that, After matching the interface call information with the interface difference table in the difference table set to determine the difference type, and before performing the corresponding conversion operation on the interface call information according to the difference type, the method further includes: For interface call information that does not match the target interface in the interface difference table, determine whether there is a replaceable interface for the interface call information; For a first interface calling node that has the replaceable interface, modify the interface information of the first interface calling 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; For second interface call nodes that do not have the aforementioned replaceable interface, record the interface missing information.

9. The lightweight program conversion method according to claim 7, 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.

10. The lightweight program conversion method 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. The parameter verification rules include at least one of parameter naming verification, parameter valid value verification, and parameter type verification. If a naming difference is detected in the parameter naming check and a corresponding naming replacement rule exists in the interface difference table, the name of the input parameter is modified according to the naming replacement rule and the abstract syntax tree is updated synchronously. If the parameter value of the input parameter is found to be within the range of supported valid parameter values ​​during the parameter validity check, the parameter value is retained. If the parameter type of the input parameter is detected to be a supported target parameter type during the parameter type verification, the original parameter type of the input parameter shall be maintained.

11. The lightweight program conversion method according to claim 10, characterized in that, Also includes: For input parameters of an unsupported parameter type, record the parameter information of the unsupported parameter; Add a first comment marker indicating that the parameter is not supported at the parameter node corresponding to the abstract syntax tree; For input parameters whose values ​​are not within the range of supported valid parameter values, record the parameter value and the corresponding interface information, and add a second annotation marker indicating that the parameter value is not supported in the abstract syntax tree.

12. A lightweight program conversion device, characterized in that, The device includes: The data acquisition module is used to acquire the project file set and conversion configuration set of the lightweight program to be converted; The file partitioning module is used to determine the first source code file and the second source code file based on the file type of the source code files in the project file set. A conversion processing module is used to perform conversion processing on the first source code file and the second source code file based on the conversion configuration set; The target lightweight program output module is used to integrate the processed first source code file and the second source code file to obtain the target lightweight program.

13. 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 lightweight program conversion method as described in any one of claims 1-11 according to instructions in the computer program.

Images