Cross-end transcoding processing method and apparatus

Abstract

This application relates to the field of code processing technology, specifically to a cross-platform code conversion processing method and apparatus. One cross-platform code conversion processing method includes: during the cross-platform code conversion process, constructing a conversion context for converting a source program to a target program through a conversion agent, generating a code conversion scheme based on the conversion context, extracting structured evidence for each item to be confirmed in the code conversion scheme using a deterministic analysis tool, and performing evidence verification processing on the structured evidence for each item to be confirmed. If the evidence verification passes, performing compatibility testing between the runtime characteristics of the source program and the target container constraints of the target program, selecting a target conversion mode from the candidate conversion modes in the code conversion scheme based on the compatibility test results, and performing code conversion according to the target conversion mode. This introduces evidence processing into the cross-platform code conversion process, ensuring that decisions during the code conversion process are supported by deterministic evidence.

Description

Technical Field

[0001] This application relates to the field of code processing technology, and in particular to a cross-platform code conversion processing method and apparatus. Background Technology

[0002] With the continuous advancement of artificial intelligence technology, AI models are being used more and more widely in various processing fields. In particular, in the field of code development, a variety of development tools based on models or intelligent agents for code generation, code modification, code testing, and code conversion have emerged. Although using models or intelligent agents can significantly improve code development efficiency, the differences between operating systems and runtime environments during code generation or conversion place higher demands on code compatibility and pose new challenges to code generation and conversion technologies. Summary of the Invention

[0003] This specification provides one or more embodiments of a cross-platform code conversion processing method, comprising: constructing a conversion context for converting a source program to a target program using a conversion agent, and generating a code conversion scheme based on the conversion context. For each item to be verified in the code conversion scheme, a deterministic analysis tool is invoked to extract structured evidence for each item to be verified, and the structured evidence for each item to be verified is subjected to evidence verification processing. If the evidence verification passes, the runtime characteristics of the source program are subjected to compatibility testing with the target container constraints of the target program. Based on the compatibility testing results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and code conversion is performed according to the target conversion mode.

[0004] This specification provides one or more embodiments of a cross-platform code conversion processing apparatus, comprising: a code conversion scheme generation module configured to construct a conversion context for converting a source program to a target program through a conversion agent, and to generate a code conversion scheme based on the conversion context; an evidence generation and verification module configured to, for each item to be verified in the code conversion scheme, invoke a deterministic analysis tool to extract structured evidence for each item to be verified, and perform evidence verification processing on the structured evidence for each item to be verified; a compatibility detection module configured to, if the evidence verification passes, perform compatibility detection between the runtime characteristics of the source program and the target container constraints of the target program; and a code conversion module configured to, based on the compatibility detection results, select a target conversion mode from the candidate conversion modes of the code conversion scheme, and perform code conversion according to the target conversion mode.

[0005] This specification provides one or more embodiments of a cross-platform code conversion processing device, including: a processor, and a memory configured to store computer-executable instructions; when the computer-executable instructions are executed, the processor: constructs a conversion context for converting a source program to a target program through a conversion agent, and generates a code conversion scheme based on the conversion context. For each item to be verified in the code conversion scheme, a deterministic analysis tool is invoked to extract structured evidence for each item to be verified, and the structured evidence for each item to be verified is subjected to evidence verification processing. If the evidence verification passes, the runtime characteristics of the source program are subjected to compatibility testing with the target container constraints of the target program. Based on the compatibility testing results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and code conversion is performed according to the target conversion mode.

[0006] This specification provides one or more embodiments of a computer-readable storage medium for storing computer-executable instructions. When executed, these instructions implement the following process: A conversion context for converting a source program to a target program is constructed using a conversion agent, and a code conversion scheme is generated based on the conversion context. For each item to be verified in the code conversion scheme, a deterministic analysis tool is invoked to extract structured evidence for each item, and the structured evidence for each item is verified. If the verification passes, the runtime characteristics of the source program are tested for compatibility with the target container constraints of the target program. Based on the compatibility test results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and code conversion is performed according to the target conversion mode.

[0007] This specification provides one or more embodiments of a cross-platform code conversion processing method. During the cross-platform code conversion process, a conversion agent constructs a conversion context for converting the source program to the target platform, and generates a code conversion scheme based on the conversion context. For each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract structured evidence for each item to be confirmed, and the structured evidence for each item to be confirmed is verified. If the evidence verification passes, the runtime characteristics of the source program are tested for compatibility with the target container constraints of the target platform. Based on the compatibility test results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and code conversion is performed according to the target conversion mode. This method uses evidence verification to check the completeness and validity of the evidence. By performing compatibility testing, candidate conversion mode selection, and code conversion based on authentic and reliable structured evidence, it ensures that decisions entering the code generation stage are supported by corresponding deterministic evidence, avoiding the conversion agent from performing code conversion through natural language reasoning. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Figure 1 A schematic diagram illustrating the implementation environment of a cross-platform code conversion processing method provided in one or more embodiments of this specification; Figure 2 A flowchart illustrating a cross-platform code conversion processing method provided in one or more embodiments of this specification; Figure 3 A flowchart illustrating a cross-platform code conversion method for subroutine conversion scenarios, provided in one or more embodiments of this specification. Figure 4 A schematic diagram illustrating an embodiment of a cross-platform code conversion processing device provided in one or more embodiments of this specification; Figure 5 This is a schematic diagram of the structure of a cross-platform code conversion processing device provided for one or more embodiments of this specification. Detailed Implementation

[0009] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this application.

[0010] The cross-platform code conversion processing method provided in one or more embodiments of this specification can be applied to the implementation environment of a code conversion system. (Refer to...) Figure 1 The implementation environment includes at least: Transformation agent 101, deterministic analysis tool 102, source program 103, and target terminal 104; Among them, the conversion agent 101 refers to the agent that performs conversion context construction, generates code conversion scheme, selects target conversion mode and performs code conversion according to target conversion mode during the code conversion process; Deterministic analysis tool 102 refers to a tool that performs repeatable checks on source code, package descriptions, type declarations, file entities and build artifacts, and outputs a structured record carrying the source code location, check rules and result status; Source code 103 refers to the object being converted during the code conversion process. Specifically, it can be a standalone application or a subroutine running within an application. The target side 104 refers to the target environment system that the source program 103 is adapted to and runs after conversion. It is the target adaptation side of code conversion. It not only includes the target application or target platform carrier that carries the converted code, but also the technical constraints of the target runtime container, the capabilities of the target platform API (Application Programming Interface), the framework specifications and existing code assets of the target project, and the entry point definition of the target side dependency packages.

[0011] In this implementation environment, during the code conversion process, the conversion agent 101 first constructs a conversion context for converting the source program 103 to the target program 104, and generates a code conversion scheme based on the conversion context. On this basis, for each item to be confirmed in the code conversion scheme, the deterministic analysis tool 102 is invoked to extract the structured evidence of each item to be confirmed, ensuring the authenticity and reliability of the extracted structured evidence. The structured evidence of each item to be confirmed is then verified. Furthermore, if the evidence verification passes, the running characteristics of the source program 103 are tested for compatibility with the target container constraints of the target program 104. Based on the compatibility test results, the target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and the corresponding code conversion is performed according to the target conversion mode. In this way, the integrity and validity of the evidence are detected through evidence verification. Compatibility testing, candidate conversion mode selection, and code conversion are performed on the basis of authentic and reliable structured evidence, ensuring that the decision to enter the code generation stage is supported by corresponding deterministic evidence, and avoiding the conversion agent 101 from performing code conversion through natural language reasoning.

[0012] This specification provides one or more embodiments of a cross-platform code conversion processing method as follows: Reference Figure 2 The cross-platform code conversion processing method provided in this embodiment specifically includes steps S202 to S208.

[0013] Step S202: Construct a conversion context for converting the source program to the target program through a conversion agent, and generate a code conversion scheme based on the conversion context.

[0014] The source program mentioned in this embodiment refers to the object being converted during the code conversion process. Specifically, the source program can be an independently running application or a subroutine running within an application. For example, the source program can be an HTML5 subroutine running within application A, and the conversion target is the corresponding subroutine running within application B.

[0015] The target end refers to the target environment system that the source program is adapted to and runs after conversion; it is the target adaptation side of code conversion. It not only includes the target application or target platform carrier that carries the converted code to run, such as the runtime of application B or the platform of a subroutine; it can also include the technical constraints of the target runtime container, the API capabilities of the target platform, the framework specifications and existing code assets of the target project, and the entry point definition of the target end dependency packages.

[0016] The aforementioned conversion agent refers to an intelligent agent that constructs a conversion context, generates a code conversion scheme, selects a target conversion mode, and performs code conversion according to the target conversion mode during the code conversion process. Specifically, the conversion agent is an artificial intelligence execution unit that generates a code conversion scheme based on the task objective, source code, and tool results, calls a specialized conversion unit, and processes verification feedback. It can be implemented using a large language model, a rule planner, or a combination of both.

[0017] In practice, a conversion agent can collect relevant data from the source program and construct a conversion context for converting the source program to the target program based on the collected data. Alternatively, the conversion agent can input relevant data from the source program to construct a conversion context for converting the source program to the target program. Furthermore, based on the constructed conversion context, a code conversion scheme can be generated. Specifically, the conversion agent can call a large language model, input the conversion context into the large language model to generate a code conversion scheme and output it.

[0018] Specifically, the transformation context refers to the transformation task context for the transformation task of transforming the source program to the target. The transformation context includes at least one of the following: source program, target information, routing configuration, existing target project, and dependencies. Among them, dependencies include direct dependencies, indirect dependencies, direct dependency packages, and / or indirect dependency packages; target information refers to the relevant information of the target obtained by the transformation agent; and the existing target project refers to the project framework or project code corresponding to the source program on the target.

[0019] The code transformation scheme includes at least one of the following: candidate transformation patterns, items to be confirmed, dependencies to be reused, and special transformation units.

[0020] Among them, the candidate conversion mode refers to the candidate conversion mode determined by the current conversion agent to convert the source program to the target end. The candidate conversion modes specifically include static conversion mode, native reuse mode, and / or degraded carrying mode. The static conversion mode refers to the conversion mode in which a special conversion unit performs targeted conversion of syntax, components, APIs, etc., to generate target end code that can be run directly. The native reuse mode refers to the conversion mode in which existing target end native components in the dependency package are reused, and parameter mapping, context injection, and initialization control and handling logic are completed. The degraded carrying mode refers to the conversion mode in which the source page of the source program is carried by a web page view container. "Items to be confirmed" refers to the conversion items that the current conversion agent determines for the source program that need to be confirmed. For example, items to be confirmed include "whether there is dynamically executable code in the current HTML5 subprogram" and "whether the components used by the current subprogram page have equivalent components on the application B side". "Dependencies to be reused" refers to the dependencies that the conversion agent obtains by parsing the dependency relationships and that are to be used on the target side. "Specialized conversion units" are conversion units that are allowed to be called for special conversion processing of various types of content contained in the source program. For example, the conversion units that are allowed to be called are page conversion units for converting HTML5 pages, component conversion units for converting page components, or conversion units for converting Hooks or platform capabilities.

[0021] Furthermore, the code conversion scheme may include a file authorization scope, which refers to the range of files that are allowed to be modified during the code conversion process. For example, the scope of files that can be modified is limited to the files in the pages directory corresponding to the page, and public dependencies cannot be modified. In an optional implementation, the code conversion scheme can be implemented in the form of a structured candidate migration plan, which at least includes a task identifier, a source file version summary, a target platform, a candidate conversion mode, a set of necessary evidence identifiers, a specific conversion unit that can be invoked, and / or a range of files that can be modified. Moreover, when generating the code conversion scheme, the conversion agent can also generate evidence requirements corresponding to each item to be confirmed, which can guide the evidence extraction direction of subsequent deterministic analysis tools.

[0022] In one optional implementation of this embodiment, a conversion context for converting the source program to the target program is constructed through a conversion agent, and a code conversion scheme is generated based on the conversion context, including: Input the source code, target information, routing configuration, existing target project, and dependencies into the transformation agent to construct the transformation context; Generate code transformation schemes based on the transformation context, including candidate transformation patterns, items to be confirmed, dependencies to be reused, and specific transformation units.

[0023] Step S204: For each item to be confirmed in the code conversion scheme, call the deterministic analysis tool to extract the structured evidence of each item to be confirmed, and perform evidence verification processing on the structured evidence of each item to be confirmed.

[0024] In practice, the conversion agent generates a code conversion scheme based on the conversion context. For each item to be confirmed in the code conversion scheme, it calls a deterministic analysis tool to extract structured evidence for each item to be confirmed. This ensures that the evidence collected for each item to be confirmed is authentic and reliable. Furthermore, the structured evidence for each item to be confirmed is verified to check the completeness and validity of the evidence. At the same time, it ensures that the decision to enter the code generation stage is supported by corresponding deterministic evidence, avoiding the conversion agent from performing code conversion through natural language reasoning.

[0025] In the specific execution process, during the extraction of structured evidence for each item to be confirmed in the code conversion scheme, deterministic analysis tools are used to extract the structured evidence for each item to be confirmed. Specifically, the structured evidence for each item to be confirmed can be extracted from the source code of the source program, or from the source code of the source program and the conversion context. Deterministic analysis tools refer to tools that perform repeatable checks on source code, package descriptions, type declarations, file entities and build artifacts, and output structured records carrying source code location, check rules and result status. By extracting structured evidence through deterministic analysis tools, the authenticity and reliability of the extracted structured evidence are ensured.

[0026] In one optional implementation of this embodiment, for each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract structured evidence for each item to be confirmed. This includes: invoking the deterministic analysis tool corresponding to each item to be confirmed to extract the runtime characteristics of the source program, the constraints of the target container, the dependency package information, and generating structured evidence.

[0027] Among them, the runtime characteristics of the source program refer to the characteristics that affect whether the source program can be executed in the target container, including the timing of code generation, the method of interface structure generation, host API dependencies and / or component mounting conditions; runtime characteristics can be extracted from the source code and / or transformation context through AST (Abstract Syntax Tree), type system inference, build log parsing or constrained classifier identification, etc.; target container constraints refer to the set of non-functional requirements and interface specifications imposed by the runtime environment, hardware architecture and deployment platform that need to be followed during the code transformation process to ensure that the generated code is usable on the target side; target container constraints include template rules, code execution restrictions, API capability scope and / or lifecycle constraints on the target side; dependency package information includes the target side entry point of the dependency package, the existence of file entities, the set of component files and / or type declarations.

[0028] Furthermore, based on the generation of structured evidence, an evidence record for that structured evidence can also be generated. This record characterizes the information and generation process of the structured evidence. Specifically, the evidence record includes at least one of the following: evidence identifier, evidence type, source location, verification rule identifier, verification status, and associated candidate items. The source location supports multiple formats, including source code files and line numbers, package description fields, type declaration locations, actual file paths, and / or build artifact paths, ensuring traceability throughout the code conversion process.

[0029] In the specific execution process, based on the structured evidence obtained above, the structured evidence of each item to be confirmed is processed for evidence verification. This is done to check the completeness and validity of the evidence. Specifically, the structured evidence of each item to be confirmed is processed for evidence verification, including completeness verification and conflict verification. If the evidence verification passes, the following step S206 is executed to perform compatibility testing between the running characteristics of the source program and the target container constraints of the target end. If the evidence verification fails, it indicates that the currently extracted structured evidence may be incomplete or conflicting, and evidence supplementation can be performed for incomplete or conflicting structured evidence. In one optional implementation of this embodiment, after the structured evidence of each item to be confirmed is processed for evidence verification, if the evidence verification fails, evidence is supplemented for the items to be confirmed that are missing or conflicting; if the evidence supplementation is successful, the supplemented evidence obtained after the evidence supplementation can be used as structured evidence, and subsequent corresponding processing can be performed on this basis. Furthermore, if there are unconfirmed items that failed to be supplemented after the evidence is supplemented, the current conversion of the source program can be blocked and the evidence record of the unconfirmed items that failed to be supplemented can be output. In this way, the abnormality of the current code conversion process can be characterized by the evidence record.

[0030] Step S206: If the evidence verification is successful, perform compatibility testing between the running characteristics of the source program and the target container constraints of the target end.

[0031] If the structured evidence for each item to be confirmed passes the evidence verification process, the runtime characteristics of the source program and the target container constraints of the target end are subjected to a compatibility test to determine whether the target end is compatible with the runtime characteristics of the source program. The compatibility test result may be that the target end is compatible with the runtime characteristics of the source program, that is, the compatibility test result is that there are no incompatible items (incompatible items are empty). In addition, the test result may also be that the target end is not compatible with all runtime characteristics of the source program, that is, the compatibility test result is that there are incompatible items.

[0032] In practice, during the compatibility test between the runtime characteristics of the source program and the constraints of the target container, the template rules, code execution restrictions, API capability range and / or lifecycle constraints contained in the target container constraints can be read, and the runtime characteristics of the source program can be matched with each constraint item contained in the target container constraints. Runtime characteristics that do not match the constraint items contained in the target container constraints are considered incompatible items. In addition, after identifying the operational features that do not match the constraints contained in the target container constraints, it is further determined whether there are equivalent features with equivalent alternative paths for the operational features that do not match the constraints contained in the target container constraints. If there are no equivalent features, the operational features that do not match the constraints contained in the target container constraints and do not have equivalent features are regarded as incompatible items. If there are equivalent features, the operational features with equivalent features may not be regarded as incompatible items.

[0033] In practice, upon identifying incompatible items, an incompatibility evidence set can be generated for each item. This set provides definitive evidence for subsequent processing. For example, the dataset containing the feature type, source code location, required capabilities, and / or reasons for judgment of the incompatible item can be used as the incompatibility evidence set. The incompatibility evidence set is a structured dataset recording the feature type, source code location, required capabilities, and reasons for judgment that are not supported by the target container. By generating traceable runtime feature incompatibility evidence, rather than simply recording syntax conversion failures, runtime infeasibility can be clearly identified before code generation, avoiding the generation of syntactically complete target code that cannot be executed in the target container.

[0034] Step S208: Select the target conversion mode from the candidate conversion modes of the code conversion scheme according to the compatibility detection results, and perform code conversion according to the target conversion mode.

[0035] As mentioned above, the compatibility test results include the running characteristics of the target-side compatible source program or all the running characteristics of the target-side incompatible source program, that is, there are no incompatible items (incompatible items are empty) or there are incompatible items. Based on this, the target conversion mode is selected from the candidate conversion modes of the code conversion scheme according to the compatibility test results. Specifically, if the incompatible items in the compatibility test results are empty, the static conversion mode can be selected from the candidate conversion modes, that is, the static conversion mode is selected as the target conversion mode from the candidate conversion modes. Furthermore, if incompatible items are found in the compatibility test results, either the native reuse mode or the downgraded carrying mode can be selected as the target conversion mode from the candidate conversion modes. Specifically, when incompatible items are found in the compatibility test results, during the selection of the target conversion mode from the candidate conversion modes, the native artifact descriptions corresponding to the source program's dependency packages can be used to check whether the native artifact descriptions can accommodate the source program capabilities mapped by the incompatible items. If they can, the capabilities of the incompatible items can be accommodated by reusing the native artifacts in the dependency packages of the source program's source pages. In this case, the native reuse mode is selected as the target conversion mode from the candidate conversion modes. If they cannot accommodate, the downgraded carrying mode is selected as the target conversion mode from the candidate conversion modes.

[0036] In one optional implementation of this embodiment, the target conversion mode is selected from the candidate conversion modes of the code conversion scheme based on the compatibility detection results, including: If incompatible items are found in the compatibility test results, parse the dependency packages of the source page of the source program and generate native artifact descriptions; The source program capabilities mapped to incompatible items are matched with the native artifact descriptions in terms of interface and runtime conditions. Based on the matching results, the target conversion mode is selected from the candidate conversion modes.

[0037] In this process of parsing the dependency packages of the source page of the source program and generating native artifact descriptions, it is possible to detect whether the dependency packages of the source page declare the target entry point. If so, it indicates that the target entry point has been declared in the dependency packages of the current source program, and the native artifacts in the dependency packages of the current source program can be reused. Specifically, in an optional implementation of this embodiment, parsing the dependency packages of the source page of the source program and generating native artifact descriptions includes: Iterate through the dependency packages and open the description file of each dependency package. Check whether the target entry point is declared in the description file. If so, perform a verification check on the description file and generate the native artifact description based on the check results.

[0038] Native artifacts can be discovered through various means such as package description field declarations, conditional export identifiers, independent manifest files, or artifact index services. During the parsing process, a structured native artifact description is formed through package description parsing, real path verification, file existence check, component file set verification, and type declaration verification. The native artifact description can specifically be structured data containing dependent package names, target platform entry points, file entities, artifact types, input parameters, output events, and lifecycle requirements.

[0039] In addition, if the target endpoint is not declared in the description file, the downgraded bearer mode can be selected as the target conversion mode in the candidate conversion modes.

[0040] Subsequently, during the process of selecting the target conversion mode from the candidate conversion modes based on the acceptance matching results, if the acceptance matching result is that the source program capability of the incompatible item mapping is successfully matched with the native artifact description in terms of interface and runtime conditions, the capability acceptance of the incompatible item can be achieved by reusing the native artifact in the dependency package of the source page of the source program. In this case, the native reuse mode is selected as the target conversion mode from the candidate conversion modes. In the specific process of acceptance and matching, the source program capabilities corresponding to the incompatible evidence set can be matched one by one with the necessary input, output events, context items and life cycle requirements in the original product description to determine whether the interface and running conditions can be accepted. If the matching result indicates that the source program capability of the incompatible item mapping fails to match the interface and runtime conditions with the native artifact description, and the native artifact in the dependency package of the source program's source page cannot be reused to implement the capability of the incompatible item, then the downgraded carrying mode is selected as the target conversion mode from the candidate conversion modes.

[0041] As mentioned above, the candidate conversion modes specifically include static conversion mode, native reuse mode, and / or degraded bearer mode. The target conversion mode selected in the candidate conversion modes can be any one of the static conversion mode, native reuse mode, and / or degraded bearer mode. Based on this, code conversion is performed according to the target conversion mode, that is, code conversion is performed according to any one of the selected candidate conversion modes. The code conversion process under these three candidate conversion modes is explained in detail below.

[0042] (1) When the static conversion mode is selected as the target conversion mode among the candidate conversion modes, the static conversion mode refers to the conversion mode in which the special conversion unit performs targeted conversion of syntax, components, APIs, etc., and generates target code that can be run directly. Accordingly, during the code conversion process according to the target conversion mode, the conversion task can be dispatched to the special conversion unit corresponding to each item to be confirmed according to the items to be confirmed and the special conversion unit included in the code conversion scheme. The special conversion unit generates the target code of the target side according to the conversion task. Under this static conversion mode, each special conversion unit generates code only within the file range and capability boundary allowed by the code conversion scheme. It shall not perform conversion beyond the authorized scope, so as to avoid generating interfaces or paths that are inconsistent with the actual dependencies, file paths and interface definitions in the code repository, and ensure the authenticity of the conversion result.

[0043] Specifically, in one optional implementation of this embodiment, code conversion is performed according to the target conversion mode, including: dispatching conversion tasks to the corresponding special conversion units according to the special conversion units and file authorization scope recorded in the code conversion scheme, and generating target code for the target end according to the conversion task within the file authorization scope of each corresponding special conversion unit.

[0044] (2) When the native reuse mode is selected as the target conversion mode in the candidate conversion mode, the native reuse mode refers to the conversion mode that reuses the existing target native components in the dependency package and completes the parameter mapping, context injection and initialization control handling logic; accordingly, in the process of code conversion according to the target conversion mode, the source page is converted by mapping the page parameters of the source page to the loading parameters of the target page, executing the configuration loading of the target container and injecting the runtime context into the target container. Specifically, in one optional implementation of this embodiment, code conversion is performed according to the target conversion mode, including: If the target conversion mode is native reuse mode, generate the host page and create a lock identifier; Map the source page's page parameters to the target page's loading parameters, execute the target container's configuration loading, and inject the runtime context into the target container; the lock flag is released after the parameter mapping, configuration loading, and context injection initialization are completed.

[0045] The host page is a lightweight page that connects the lifecycle of the target page with the reused native container; the locking flag is a control mechanism that prevents native components from being mounted when the configuration or context is not ready, and it can be implemented by a boolean state variable, a state machine, a Promise object or an observable.

[0046] In this native reuse mode, the reuse of native artifacts includes the synthesis of host runtime preconditions, rather than just replacing component names. This ensures that native components enter the mounting lifecycle only after context initialization is complete, avoiding runtime anomalies caused by component mounting occurring before context initialization.

[0047] (3) When the downgraded carrying mode is selected as the target conversion mode in the candidate conversion mode, the downgraded carrying mode refers to the conversion mode of carrying the source page of the source program through the web page view container; accordingly, in the process of code conversion according to the target conversion mode, the source page is converted by carrying the source page of the source program through the web page view container. In one optional implementation of this embodiment, code conversion is performed according to the target conversion mode, including: if the target conversion mode is a downgraded hosting mode, performing pre-compilation processing of the webpage view container. In addition to the above-mentioned method of converting the source page by hosting the source program's source page in a webpage view container, conversion blocking processing can also be performed and evidence of unacceptable differences, missing interfaces, or unmet operating conditions can be output.

[0048] In practical applications, when selecting static conversion mode or native reuse mode among the candidate conversion modes, in order to improve the quality of code conversion, quality checks can be performed on the target code or host page obtained from the code conversion. This ensures the runnability of the converted code through quality checks. Specifically, in an optional implementation method provided in this embodiment, after the code conversion is performed according to the target conversion mode, the following operations are performed: Perform runtime feature detection and target project build detection on the target code or host page; If the test passes, conversion result data is generated that includes executable code, code conversion scheme, evidence records and / or the decision basis for the target conversion mode. In this way, by generating conversion result data that includes the complete conversion process and relevant evidence, the authenticity and reliability of the code conversion process can be demonstrated. In addition, if the detection fails, failure feedback evidence can be generated and input into the conversion agent. The conversion agent then re-converts the local content where the code conversion failed, thereby improving the overall success rate of the code conversion based on the re-conversion of the local content. In one optional implementation of this embodiment, after generating failure feedback evidence and inputting it into the conversion agent, the conversion agent determines the conversion error page, conversion error dependency, and / or conversion error stage based on the input failure feedback evidence, and performs corresponding local conversion retry operations for the conversion error page, conversion error dependency, and / or conversion error stage within a preset number of conversion retries.

[0049] For example, a quality inspection access control system can be constructed. The inspection items of this system include page configuration compliance inspection, dependency path validity inspection, component registration status inspection, prohibited class dynamic execution feature inspection, and target project construction result inspection. After the inspection passes, the output conversion result data may include executable artifacts, code conversion scheme, full evidence record, access control inspection results, target conversion mode and / or decision basis, realizing full traceability of the conversion process. If the inspection fails, failure feedback evidence is generated. The failure feedback evidence adopts a structured verification failure record form, which includes at least the access control identifier, failure stage, file location, expected state, actual state, related evidence and / or affected artifacts.

[0050] In summary, the cross-platform code conversion processing method provided in this embodiment first constructs a conversion context for converting the source program to the target program through a conversion agent, and generates a code conversion scheme based on the conversion context. On this basis, for each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract structured evidence for each item to be confirmed, ensuring the authenticity and reliability of the extracted structured evidence. The structured evidence for each item to be confirmed is then verified. Furthermore, if the evidence verification passes, the runtime characteristics of the source program are tested for compatibility with the target container constraints of the target program. Based on the compatibility test results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme. Specifically, based on the compatibility test results, any one of the three candidate conversion modes—static conversion mode, native reuse mode, and / or degraded bearing mode—can be selected as the target conversion mode. The corresponding code conversion processing is then performed according to the target conversion mode. In this way, the completeness and validity of the evidence are detected through evidence verification. Compatibility testing, candidate conversion mode selection, and code conversion are performed on the basis of authentic and reliable structured evidence, ensuring that the decision to enter the code generation stage is supported by corresponding deterministic evidence, and avoiding the conversion agent from performing code conversion through natural language reasoning.

[0051] The following example uses a cross-platform code conversion processing method provided in this embodiment to illustrate its application in a subroutine conversion scenario. Figure 3 The cross-platform code conversion processing method provided in this embodiment will be further explained below. Figure 3 The method for cross-platform code conversion in subroutine conversion scenarios includes the following steps.

[0052] Step S302: Input the subroutine to be converted, target end information, routing configuration, existing target project and / or dependency relationship into the conversion agent to construct the conversion context.

[0053] Step S304: Generate a code transformation scheme based on the transformation context, which includes candidate transformation patterns, items to be confirmed, dependencies to be reused, and / or specific transformation units.

[0054] Step S306: Invoke the deterministic analysis tool corresponding to each item to be confirmed, extract the running characteristics of the subroutine, the target container constraints and / or dependency package information, generate structured evidence, and generate evidence records of the structured evidence.

[0055] Step S308: Perform evidence verification processing on the structured evidence of each item to be confirmed; If the evidence verification is successful, proceed to step S310; If the evidence verification fails, supplement the evidence for the items that are missing or conflicting; if there are still items that fail to be supplemented after the evidence is supplemented, then block the current conversion of the subroutine and output the evidence record of the items that failed to be supplemented.

[0056] Step S310: Perform compatibility testing between the running characteristics of the subroutine and the target container constraints of the target end.

[0057] Step S312: If the incompatible items in the compatibility test results are empty, select the static conversion mode from the candidate conversion modes.

[0058] Step S314: Based on the specialized conversion units and file authorization scope recorded in the code conversion scheme, the conversion task is dispatched to the corresponding specialized conversion unit, and each corresponding specialized conversion unit generates the target code of the target end according to the conversion task within the file authorization scope.

[0059] Step S316: If there are incompatible items in the compatibility test results, parse the dependency packages of the source page of the subroutine and generate the native artifact description.

[0060] Step S318: Match the subroutine capabilities mapped to incompatible items with the native artifact description in terms of interface and runtime conditions.

[0061] Step S320: If the acceptance matching is successful, select the native reuse mode from the candidate conversion modes, generate the host page and map the page parameters of the source page to the loading parameters of the target page, execute the configuration loading of the target container and inject the runtime context into the target container.

[0062] Step S322: If the bearing match fails, select the downgrade bearing mode from the candidate conversion modes and perform the pre-compilation processing of the web page view container.

[0063] Step S324: Perform runtime feature detection and target project construction detection on the target code or host page; If the test passes, proceed to step S326; If the detection fails, failure feedback evidence is generated and input into the conversion agent.

[0064] Step S326: Generate conversion result data containing the decision basis of executable code, code conversion scheme, evidence records and / or target conversion mode.

[0065] It should be noted that any one or more steps in steps S302 to S326 can be combined with any one or more steps in steps S202 to S208 to form a new implementation method according to the needs of implementation and deployment. In addition, any one or more technical features in steps S302 to S326 can be selected and combined with any one or more technical features provided in steps S202 to S208 to form a new implementation method according to the actual deployment needs. Alternatively, any one or more technical features in steps S302 to S326 can be replaced with any one or more technical features provided in steps S202 to S208 to form a new implementation method according to the actual deployment needs. These will not be elaborated on here.

[0066] This specification provides an embodiment of a cross-platform code conversion processing device as follows: In the above embodiments, a cross-platform code conversion processing method is provided, and correspondingly, a cross-platform code conversion processing device is also provided, which will be described below with reference to the accompanying drawings.

[0067] Reference Figure 4 This illustration shows a schematic diagram of an embodiment of a cross-platform code conversion processing device provided in this embodiment.

[0068] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0069] This embodiment provides a cross-platform code conversion processing device, the device comprising: The code conversion scheme generation module 402 is configured to construct a conversion context for converting the source program to the target program through a conversion agent, and generate a code conversion scheme based on the conversion context; The evidence generation and verification module 404 is configured to, for each item to be confirmed in the code conversion scheme, call a deterministic analysis tool to extract the structured evidence of each item to be confirmed, and perform evidence verification processing on the structured evidence of each item to be confirmed. The compatibility detection module 406 is configured to perform compatibility detection between the running characteristics of the source program and the target container constraints of the target end if the evidence verification is successful. The code conversion module 408 is configured to select a target conversion mode from the candidate conversion modes of the code conversion scheme based on the compatibility detection results, and perform code conversion according to the target conversion mode.

[0070] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more embodiments of this specification, the functions of each module or unit can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; 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.

[0071] This specification provides an example of a cross-platform code conversion processing device as follows: Corresponding to the cross-platform code conversion processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a cross-platform code conversion processing device, which is used to execute the cross-platform code conversion processing method provided above. Figure 5 This is a schematic diagram of the structure of a cross-platform code conversion processing device provided for one or more embodiments of this specification.

[0072] This embodiment provides a cross-platform code conversion processing device, including: like Figure 5As shown, device 500 mainly consists of a communication interface 502, a user interface 504, a processor 506, and a data storage 508. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 510. The communication interface 502 enables device 500 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 502 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 502 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 502 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 502 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces. The user interface 504 includes receiving user input and providing output to the user. Therefore, user interface 504 may include input components such as a keypad, keyboard, touch panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with the touch panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 504 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 504 may include software, circuitry, or other forms of logic capable of transmitting and receiving data to and from external user input / output devices. Additionally or alternatively, device 500 may support remote access from other devices via communication interface 502 or another physical interface (not shown). User interface 504 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 504 may also be configured as a display device for rendering or displaying text fragments.

[0073] Processor 506 may include one or more general-purpose processors and / or dedicated processors. Data storage 508 may include one or more volatile and / or non-volatile storage components, and may be integrated wholly or partially with processor 506. Data storage 508 may include removable and non-removable components.

[0074] Processor 506 is capable of executing program instructions 518 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 508 to perform the various functions described herein. Data storage 508 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 500, enable device 500 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Execution of program instructions 518 by processor 506 may result in processor 506 using data 512. For example, program instructions 518 may include an operating system 522 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 500 and one or more application programs 520 (e.g., a browser, social application, or game application). Similarly, data 512 may include operating system data 516 and application data 514. Operating system data 516 is primarily accessible to operating system 522, while application data 514 is primarily accessible to one or more application programs 520. Application data 514 may reside in a file system visible or hidden from the user of device 500. Application 520 can communicate with operating system 522 through one or more application programming interfaces (APIs). These APIs facilitate application 520 in reading and / or writing application data 514, transmitting or receiving information via communication interface 502, and receiving or displaying information on user interface 504. In some terms, application 520 may be simply referred to as "app". Furthermore, application 520 can be downloaded to device 500 through one or more online app stores or app markets. However, applications can also be installed on device 500 in other ways, such as through a web browser or a physical interface on device 500 (e.g., a USB port).

[0075] In one specific embodiment, the cross-platform code conversion processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the cross-platform code conversion processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: A conversion context is constructed by converting the source program to the target program through a conversion agent, and a code conversion scheme is generated based on the conversion context; For each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract the structured evidence for each item to be confirmed, and the structured evidence for each item to be confirmed is subjected to evidence verification processing. If the evidence verification is successful, the running characteristics of the source program will be tested for compatibility with the target container constraints of the target end. Based on the compatibility test results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and the code conversion is performed according to the target conversion mode.

[0076] This specification provides an embodiment of a computer-readable storage medium as follows: Corresponding to the cross-platform code conversion processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a computer-readable storage medium.

[0077] The computer-readable storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed, implement the following process: A conversion context is constructed by converting the source program to the target program through a conversion agent, and a code conversion scheme is generated based on the conversion context; For each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract the structured evidence for each item to be confirmed, and the structured evidence for each item to be confirmed is subjected to evidence verification processing. If the evidence verification is successful, the running characteristics of the source program will be tested for compatibility with the target container constraints of the target end. Based on the compatibility test results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and the code conversion is performed according to the target conversion mode.

[0078] It should be noted that the embodiments of a computer-readable storage medium described in this specification and the embodiments of a cross-platform code conversion processing method described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0079] This specification provides an example of a computer program product as follows: Corresponding to the cross-platform code conversion processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a computer program product.

[0080] A computer program product includes a computer program / instructions that, when executed by a processor, perform the following steps: A conversion context is constructed by converting the source program to the target program through a conversion agent, and a code conversion scheme is generated based on the conversion context; For each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract the structured evidence for each item to be confirmed, and the structured evidence for each item to be confirmed is subjected to evidence verification processing. If the evidence verification is successful, the running characteristics of the source program will be tested for compatibility with the target container constraints of the target end. Based on the compatibility test results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and the code conversion is performed according to the target conversion mode.

[0081] It should be noted that the embodiments of a computer program product described in this specification and the embodiments of a cross-platform code conversion processing method described in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0082] The various embodiments in this specification are described in a progressive manner. For the same or similar parts between the various embodiments, please refer to each other. Each embodiment focuses on describing the differences from other embodiments. For example, the device embodiment, equipment embodiment, and computer-readable storage medium embodiment are all similar to the method embodiment, so the description is relatively simple. For reading the relevant content of the device embodiment, equipment embodiment, and computer-readable storage medium embodiment, please refer to the description of the method embodiment.

[0083] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps, and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims. This specification uses specific terms to describe embodiments of this specification. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0084] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0085] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0086] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0087] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0088] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0089] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0090] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0091] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0092] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0093] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0094] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0095] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, or other magnetic storage devices, which can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0096] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising at least one…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0097] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0098] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A cross-platform code conversion processing method, characterized in that, The method includes: A conversion context is constructed by converting the source program to the target program through a conversion agent, and a code conversion scheme is generated based on the conversion context; For each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract the structured evidence for each item to be confirmed, and the structured evidence for each item to be confirmed is subjected to evidence verification processing. If the evidence verification is successful, the running characteristics of the source program will be tested for compatibility with the target container constraints of the target end. Based on the compatibility test results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and the code conversion is performed according to the target conversion mode.

2. The cross-platform code conversion processing method according to claim 1, characterized in that, The step of selecting the target conversion mode from the candidate conversion modes of the code conversion scheme based on the compatibility detection results includes: if the incompatibility items in the compatibility detection results are empty, selecting the static conversion mode from the candidate conversion modes; The code conversion according to the target conversion mode includes: dispatching conversion tasks to the corresponding special conversion units according to the special conversion units and file authorization range recorded in the code conversion scheme, and generating the target code of the target end according to the conversion task within the file authorization range of each corresponding special conversion unit.

3. The cross-platform code conversion processing method according to claim 1, characterized in that, The step of selecting the target conversion mode from the candidate conversion modes of the code conversion scheme based on the compatibility detection results includes: If there are incompatible items in the compatibility test results, parse the dependency packages of the source page of the source program and generate native artifact descriptions; The source program capabilities mapped by the incompatible items are matched with the native product description in terms of interface and runtime conditions. Based on the matching results, the target conversion mode is selected from the candidate conversion modes.

4. The cross-platform code conversion processing method according to claim 3, characterized in that, The process of parsing the dependency packages of the source pages of the source program and generating native artifact descriptions includes: Iterate through the dependency packages and open the description file of each dependency package, and check whether the target entry point is declared in the description file; If so, perform a verification check on the description file and generate the original product description based on the check results.

5. The cross-platform code conversion processing method according to claim 3, characterized in that, The code conversion according to the target conversion mode includes: If the target conversion mode is native reuse mode, generate a host page and create a lock identifier; The page parameters of the source page are mapped to the loading parameters of the target page, the configuration loading of the target container is executed, and the runtime context is injected into the target container; the locking flag is released after the parameter mapping, configuration loading, and context injection initialization are completed.

6. The cross-platform code conversion processing method according to claim 2 or 5, characterized in that, After the code conversion and execution according to the target conversion mode, the process further includes: Perform runtime feature detection and target project build detection on the target code or host page; If the test passes, conversion result data is generated, which includes executable code, the code conversion scheme, evidence records, and the decision basis for the target conversion mode. If the detection fails, failure feedback evidence is generated and input into the conversion agent.

7. The cross-platform code conversion processing method according to claim 6, characterized in that, Also includes: The conversion agent determines the conversion error page, conversion error dependency, and / or conversion error stage based on the input failure feedback evidence, and performs corresponding local conversion retry operations for the conversion error page, the conversion error dependency, and / or the conversion error stage within a preset number of conversion retries.

8. The cross-platform code conversion processing method according to claim 3, characterized in that, The code conversion according to the target conversion mode includes: If the target conversion mode is a downgraded hosting mode, perform pre-compilation processing of the webpage view container; or, perform conversion blocking processing and output evidence that the unacceptable differences, missing interfaces, or unmet operating conditions are not met.

9. The cross-platform code conversion processing method according to claim 1, characterized in that, After performing the evidence verification process on the structured evidence of each item to be confirmed, the process further includes: If the evidence verification fails, supplementary evidence shall be provided for the items that are missing or conflicting. If, after the supplementary evidence is completed, there are still items that fail to be supplemented and require confirmation, then the current conversion of the source program is blocked and the evidence record of the items that fail to be supplemented and require confirmation is output.

10. The cross-platform code conversion processing method according to claim 1, characterized in that, The step of constructing a conversion context for converting the source program to the target program through a conversion agent, and generating a code conversion scheme based on the conversion context, includes: The source program, target information, routing configuration, existing target project, and dependencies are input into the conversion agent to construct the conversion context; Based on the transformation context, a code transformation scheme is generated that includes the candidate transformation pattern, the item to be confirmed, the dependency to be reused, and the special transformation unit.

11. The cross-platform code conversion processing method according to claim 1, characterized in that, For each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract structured evidence for each item to be confirmed, including: Invoke the deterministic analysis tools corresponding to each item to be confirmed, extract the runtime characteristics of the source program, the constraints of the target container, the dependency package information, and generate structured evidence; Generate an evidence record for the structured evidence; the evidence record includes at least one of the following: evidence identifier, evidence type, source location, verification rule identifier, verification status, and associated candidate.

12. A cross-platform code conversion processing device, characterized in that, The device includes: The code conversion scheme generation module is configured to construct a conversion context for converting the source program to the target program through a conversion agent, and generate a code conversion scheme based on the conversion context; The evidence generation and verification module is configured to, for each item to be confirmed in the code conversion scheme, call a deterministic analysis tool to extract the structured evidence of each item to be confirmed, and perform evidence verification processing on the structured evidence of each item to be confirmed. The compatibility detection module is configured to perform compatibility detection between the running characteristics of the source program and the target container constraints of the target end if the evidence verification passes. The code conversion module is configured to select a target conversion mode from the candidate conversion modes of the code conversion scheme based on the compatibility detection results, and perform code conversion according to the target conversion mode.

13. A cross-platform code conversion processing device, characterized in that, include: The processor, and the memory configured to store computer-executable instructions; When the computer-executable instructions are executed, they cause the processor to: A conversion context is constructed by converting the source program to the target program through a conversion agent, and a code conversion scheme is generated based on the conversion context; For each item to be confirmed in the code conversion scheme, a deterministic analysis tool is invoked to extract the structured evidence for each item to be confirmed, and the structured evidence for each item to be confirmed is subjected to evidence verification processing. If the evidence verification is successful, the running characteristics of the source program will be tested for compatibility with the target container constraints of the target end. Based on the compatibility test results, a target conversion mode is selected from the candidate conversion modes of the code conversion scheme, and the code conversion is performed according to the target conversion mode.

14. A computer-readable storage medium for storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, they implement the steps of the method of claim 1.

Images