Cross-platform migration method for application software, storage medium and electronic device

Abstract

Disclosed in the present application are a cross-platform migration method for application software, a storage medium and an electronic device. The method comprises: on the basis of a rendering engine, defining virtual components of target application software, so as to determine a target rendering engine comprising a virtual page component and a virtual module component of the target application software, the virtual page component being a virtual component representing page element information, and the virtual module component being a virtual component for implementing an interaction function of the target application software; on the basis of a programming language requirement of a target platform, generating or modifying dynamic scripts of the virtual page component and the virtual module component, and determining, as target migration data, a first dynamic script corresponding to the virtual page component and a second dynamic script corresponding to the virtual module component; and on the basis of an interface provided by said platform, migrating the target rendering engine and the target migration data to said platform, thereby implementing lightweight application software cross-platform migration, and reducing complexity and costs.

Description

A method for cross-platform migration of application software, storage medium, and electronic device.

[0001] This application claims priority to Chinese Patent Application No. 202411192892.X, filed on August 28, 2024, entitled "A method for cross-platform migration of application software, storage medium and electronic device", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer application technology, specifically to a method and apparatus for cross-platform migration of application software, computer storage media, and electronic devices. Background Technology

[0003] With the continuous development of computer technology, various electronic devices based on system architecture have become increasingly diversified and comprehensive.

[0004] Developing the same application software across electronic devices with different system architectures is a complex process involving cross-platform compatibility and technology adaptation. Implementing application software on multiple different systems requires developers to possess cross-platform development skills and experience. By using cross-platform frameworks and libraries, writing portable code, conducting thorough compatibility testing, and adapting and optimizing for specific platforms, it is possible to ensure the stable operation of application software and a good user experience on different systems. In other words, for different systems, corresponding technical development methods need to be adopted for each system so that the application software can be adapted to different systems.

[0005] The above is a background technical introduction to how application software achieves compatibility and adaptation across different system platforms. Summary of the Invention

[0006] This application provides a method for cross-platform migration of application software to solve the problems of complexity and high cost in the process of developing application software across systems in the prior art.

[0007] This application provides a method for cross-platform migration of application software, including:

[0008] Based on the rendering engine, virtualization components are defined for the target application software, and a target rendering engine including virtual page components and virtual module components of the target application software is determined; wherein, the virtual page component is a virtual component that represents page element information, and the virtual module component is a virtual component that implements the interactive functions of the target application software;

[0009] According to the programming language requirements of the migration platform, dynamic scripts are generated or modified for the virtual page component and the virtual module component, and the first dynamic script corresponding to the virtual page component and the second dynamic script corresponding to the virtual module component are determined as the target migration data.

[0010] The target rendering engine and the target migration data are migrated to the migration platform using the interface provided by the migration platform.

[0011] In some embodiments, the virtualization component definition of the target application software based on the rendering engine includes:

[0012] Based on the access request in the target application software, determine whether the access event corresponding to the access request is a virtual page event or a virtual module event;

[0013] If it is a virtual page event, then the execution task of the virtual page component is defined according to the virtual page event;

[0014] If it is a virtual module event, then the execution task of the virtual module component is defined according to the virtual module event.

[0015] In some embodiments, determining whether the access event corresponding to the access request in the target application software is a virtual page event or a virtual module event includes:

[0016] Based on the access request, determine the type of page state change of the target application software;

[0017] Based on the type of page state change, determine whether the access event is a virtual page event or a virtual module event.

[0018] In some embodiments, determining the type of page state change of the target application software based on the access request includes:

[0019] Based on the access request, determine whether the access page corresponding to the access event contains a change in the first virtual module component itself corresponding to the access event;

[0020] If so, then the page state change type is determined to be a virtual module component change type;

[0021] The step of determining whether the access event is a virtual page event or a virtual module event based on the page state change type includes:

[0022] Based on the change type of the virtual module component, the access event is determined to be a virtual module event.

[0023] In some embodiments, determining the type of page state change of the target application software based on the access request includes:

[0024] Based on the access request, determine whether the access page corresponding to the access event includes changes to the second virtual module component;

[0025] If so, then the page state change type is determined to be a virtual page component change type;

[0026] The step of determining whether the access event is a virtual page event or a virtual module event based on the page state change type includes:

[0027] Based on the change type of the virtual page component, the access event is determined to be the virtual page event.

[0028] In some embodiments, if the event is a virtual page event, then defining the execution task of the virtual page component according to the virtual page event includes:

[0029] Define the data recycling task for the virtual page component based on the virtual page event;

[0030] The data recycling task is determined as the execution task of the virtual page component.

[0031] In some embodiments, based on the virtual page event, a data recycling task for the virtual page component is defined, including:

[0032] Receive the virtual page event sent by the virtual module component;

[0033] Based on the virtual page event, a data recycling request is triggered;

[0034] Based on the data recycling request, determine the data recycling task for the virtual page component.

[0035] In some embodiments, defining the data recycling task of the virtual page component based on the virtual page event includes:

[0036] Based on the virtual page event, determine whether the page data required by the access page corresponding to the access request is local data or remote data;

[0037] If it is remote data, then obtain the corresponding target page data from the remote end according to the access request;

[0038] If it is near-end data, then obtain the corresponding target page data from the near end according to the access request;

[0039] The accessed page is updated based on the target page data.

[0040] In some embodiments, it also includes:

[0041] Data is written back based on the target page data obtained from the remote end;

[0042] The page components in the access page corresponding to the virtual page component are updated based on the data written back, and the module components in the access page corresponding to the virtual module component are also updated.

[0043] In some embodiments, if the event is a virtual module event, then defining the execution task of the virtual module component according to the virtual module event includes:

[0044] Based on the virtual module event, determine the module data corresponding to the virtual module event;

[0045] Based on the module data, the access page corresponding to the access request is updated.

[0046] In some embodiments, the step of dynamically generating or modifying scripts for the virtual page component and the module component according to the programming language requirements of the migration platform includes:

[0047] Based on the execution tasks of the virtual page component, a dynamic script is generated or modified to determine the first dynamic script;

[0048] The second dynamic script is determined by generating or modifying a dynamic script based on the execution task of the virtual module component.

[0049] This application also provides a method for outputting pages of cross-platform application software, including:

[0050] In response to an access request to the target application software on the migration platform, an application page is output to the client interface of the target application software on the migration platform; wherein the application page is generated based on the cross-platform migration method of the aforementioned application software.

[0051] This application also provides a page output device for cross-platform migration of application software, including:

[0052] An output unit is configured to, in response to an access request to the target application software on the migration platform, output an application page to the client interface of the target application software on the migration platform; wherein the application page is generated based on the cross-platform migration method of the aforementioned application software.

[0053] This application also provides a computer storage medium for storing data generated by a network platform, and a program for processing the data generated by the network platform.

[0054] When the program is read and executed by the processor, it performs the cross-platform migration method for the application software described above.

[0055] This application also provides an electronic device, including:

[0056] processor;

[0057] The memory is used to store programs that process data generated by the network platform. When the program is read and executed by the processor, it performs the cross-platform migration method of the application software described above.

[0058] Compared with the prior art, this application has the following advantages:

[0059] This application provides a cross-platform migration method for application software. It implements migration data corresponding to virtual page components and virtual module components abstracted from a rendering engine in the target application software. Through an interface provided by the migration platform, the target application software is migrated to the migration platform to achieve cross-platform application. On the one hand, this eliminates the need for redevelopment of the target application software to adapt to another platform (or system) and meet the programming requirements of that platform, reducing the cost of cross-platform application implementation. On the other hand, by defining virtualized components in the target application software through the rendering engine, a target rendering engine including the virtual page components and virtual module components of the target application software is determined, along with the definition of execution task processing logic for virtual page events and virtual module events corresponding to the virtual page components and virtual module components. This enables cross-platform application of the target application software through a lightweight rendering engine. Even in multi-platform scenarios, only the dynamic script needs to be modified to achieve dynamic cross-platform application. Furthermore, while achieving rapid migration, the original development structure of the target application software is preserved, without affecting its iterative maintenance. Attached Figure Description

[0060] Figure 1 is a flowchart of a cross-platform migration method for application software provided in this application.

[0061] Figure 2 is a logical diagram of task execution in a cross-platform migration method for application software provided in this application.

[0062] Figure 3 is a schematic diagram of the structure of a cross-platform migration device for application software provided in this application.

[0063] Figure 4 is a flowchart of a method for outputting pages of cross-platform migration application software provided in this application.

[0064] Figure 5 is a schematic diagram of the page output device for cross-platform migration application software provided in this application.

[0065] Figure 6 is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0066] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0067] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to limit the application. The descriptive terms used in this application and the appended claims, such as "a," "first," and "second," are not intended to limit quantity or sequence, but rather to distinguish information of the same type from one another.

[0068] As can be seen from the background above, the cross-platform migration method for application software provided in this application is a technology for how application software can achieve compatibility and adaptation with multiple different systems in a cross-platform (system) scenario. It is precisely because of the complexity and cost issues associated with cross-system compatibility and adaptation in such a scenario that the technical solution of this application was conceived. Because, regardless of the simplicity or complexity of the functionality of an application software, its natively developed pages are diverse, and the corresponding underlying development architecture and logic are also complex, requiring continuous updates and iterations. In cross-system scenarios, it is necessary to redevelop based on the native pages to adapt to the requirements of the corresponding operating system's development language. This approach inevitably leads to increased development costs, and for an existing native page, the development complexity remains unchanged. Therefore, this application proposes a cross-platform migration method for application software that can not only reduce existing development costs but also reduce existing development complexity. Before describing the cross-platform migration method for application software provided in this application, the technical terms or nouns involved in this field or technical solution will be explained.

[0069] Native platform-specific development refers to a strategy in application software development that employs different native development methods or technology stacks for different platforms (i.e., different operating systems). In native platform-specific development, different operating systems have independent code libraries and development environments, allowing developers to design and implement corresponding functionalities based on the characteristics and user experience requirements of each platform.

[0070] Native app development pages, also known as native app development pages, refer to application interface development using the native programming languages ​​of a specific operating system (such as Objective-C or Swift for iOS, and Java or Kotlin for Android). Simply put, different operating systems require corresponding programming languages ​​for application development.

[0071] Cross-platform: This refers to achieving a consistent user experience across multiple devices, such as computers, laptops, tablets, and mobile phones, for the same application or service. The core of cross-platform technology lies in enabling seamless migration and a consistent experience across different devices.

[0072] Rendering Engine: By optimizing rendering algorithms and data processing workflows, high-performance graphics rendering is achieved. It can quickly process large amounts of graphics data and generate high-quality images, meeting the high requirements of application software pages for real-time performance and realism.

[0073] The migration platform refers to operating systems such as Android, iOS, or HarmonyOS that can install and / or run application software. In the embodiments of this application, at least some pages of the application software are implemented in a dynamic manner, and the development language is not entirely the native language required by the migration platform.

[0074] The above is a brief introduction and explanation of some of the relevant technical terms involved in this technical field. The technical solution of this application will be described in detail below.

[0075] As shown in Figure 1, Figure 1 is a flowchart of a cross-platform migration method for application software provided in this application. The method includes:

[0076] Step S101: Define virtualized components for the target application software based on the rendering engine, and determine the target rendering engine that includes virtual page components and module components of the target application software; wherein, the virtual page component is a virtual component that represents page element information, and the virtual module component is a virtual component that implements the interactive functions of the target application software;

[0077] Step S102: According to the programming language requirements of the migration platform, generate or modify dynamic scripts for the virtual page component and the module component, and determine the first dynamic script corresponding to the virtual page component and the second dynamic script corresponding to the virtual module component as the target migration data;

[0078] Step S103: Migrate the target rendering engine and the target migration data to the migration platform according to the interface provided by the migration platform.

[0079] Regarding step S101: Define virtualization components for the target application software based on the rendering engine, and determine the target rendering engine that includes the virtual page components and virtual module components of the target application software.

[0080] The purpose of step S101 is to define virtualization components for the target application software based on the rendering engine. In this embodiment, the target application software can be a native application software that has been developed on a certain system platform, or it can be an iterative version of the application software. For example, application software A that has been developed on the currently known Android, HarmonyOS, and / or iOS system platforms. Of course, it can also be an application software under development on a certain system platform, such as application software A that is currently under development on the Android, HarmonyOS, and / or iOS system platforms. That is to say, the cross-platform migration method for the target application software in this application is not only applicable to completed application software, but also to application software that is still under development. Therefore, the specific state of the target application software is not limited. In this embodiment, the description mainly takes a completed application software as an example.

[0081] The virtual module components can be defined based on module components in the native application software or a specific version of the application software. In other words, virtual module components can be abstracted from module components in the native application software or a specific version of the application software. A module component (or modular component) refers to a functional unit in application software that can be independently reused, responsible for a specific function or part, with clear functionality and independent logic. It can be reused in different pages or different projects, improving development efficiency and consistency.

[0082] Similarly, the virtual page component can also be defined based on page components in the native application software or an iterative version of the application software; that is, the virtual page component can be abstracted from page components in the native application software or an iterative version of the application software. A page component is a structural unit that constitutes the page hierarchy of the application software and can be composed of multiple modular components to build a complete user interface.

[0083] In summary, the main purpose of page components is to combine different modular components to form a complete and fully functional page. Modular components are reusable functional units, while page components are the structural units that build the entire application page, and are usually composed of multiple modular components.

[0084] In this embodiment, the virtual page components and virtual module components can be defined based on the page components and module components of the native application page, or they can be defined based on the page components and module components of a certain iterative version of the application page.

[0085] It is understandable that the target application software is software that has already been developed. Step S101 defines virtualization components for the target application software based on the rendering engine, that is, establishes a relationship between the rendering engine and the virtualization components so that when the rendering engine is called again, the rendering engine can process the virtualization components accordingly.

[0086] It should be noted that the target application software is not limited to application software downloaded and installed on electronic devices, but may also include software that can be used on electronic devices in various ways such as mini-programs, links, and QR codes.

[0087] The specific implementation process of this embodiment may include:

[0088] Step S101-11: Based on the access request in the target application software, determine whether the access event corresponding to the access request is a virtual page event or a virtual module event;

[0089] Step S101-12: If it is the virtual page event, then define the execution task of the virtual page component according to the virtual page event;

[0090] Step S101-13: If it is the virtual module event, then define the execution task of the virtual module component according to the virtual module event.

[0091] It is understandable that, for application software, the access events corresponding to the access requests, or operation events, include software startup, page loading, page data requests, page layout, page interactions, etc. These events can be processed as event tracking data so that when an operation occurs on the page, the event tracking data is triggered to perform corresponding processing. Application software access events can exist in different types, such as: page events related to page changes themselves, such as: access events (or trigger events) for viewing products, access events for adding products to the shopping cart, etc.; and module events not related to page data, such as: access events for confirming shopping cart submission, access events for order confirmation, etc.

[0092] It should be noted that a page event can be understood as a page-triggered event. This triggering event can correspond to a page component in the application software page or a module component in the application software page. Therefore, in this embodiment, from the perspective of the data processing logic of the application software page, page events are divided into page events and module events. In fact, module events can also be the processing logic of module components that are generated randomly through page events. Therefore, the access event corresponding to the access request can be understood in combination with the actual application scenario and application page.

[0093] Whether the access event is a virtual page event or a virtual module event can be determined based on the type of page state change. Therefore, the specific implementation process of steps S101-11 may include:

[0094] Steps S101-111: Determine the page state change type of the target application software based on the access request;

[0095] Steps S101-112: Determine whether the access event is a virtual page event or a virtual module event based on the page state change type.

[0096] In this embodiment, the specific process for determining the page state change type in steps S101-111 may include:

[0097] Step S101-111-11: Based on the access request, determine whether the change in the access page corresponding to the access event is the change of the first virtual module component itself corresponding to the access event; that is, the virtual module component corresponding to the access event is a closed-loop processing process in the page change state, which does not involve the change of other virtual module components. For example, submitting a shopping cart is a processing process of the virtual module component itself, and does not involve the change of virtual page components in the shopping cart page (which can also be understood as the change of products in the shopping cart page).

[0098] Step S101-111-12: If yes, then determine that the page state change type is a virtual module component change type;

[0099] The specific implementation process of steps S101-112 may include:

[0100] Step S101-112-11: Determine the access event as the virtual module event based on the change type of the virtual module component.

[0101] In this embodiment, the specific process for determining the page state change type in steps S101-111 may include:

[0102] Step S101-111-21: Based on the access request, determine whether the access page corresponding to the access event includes a change in the second virtual module component; the second virtual module component can be understood as another virtual module component that has a related interactive relationship or linkage relationship with the virtual module component corresponding to the current access event.

[0103] Step S101-111-22: If yes, then determine that the page state change type is a virtual page component change type;

[0104] The specific implementation process of steps S101-112 may include:

[0105] Step S101-112-21: Determine the access event as the virtual page event based on the change type of the virtual page component.

[0106] After determining the event type corresponding to the access event, corresponding execution tasks can be defined for different event types. An execution task can be understood as the processing logic executed for different event types, ultimately rendered and output on the display side of the electronic device through the rendering engine. Therefore, the specific implementation of steps S101-12 may include:

[0107] Steps S101-1211: Define the data recycling task of the virtual page component according to the virtual page event;

[0108] Step S101-1212: The data recycling task is determined as the execution task of the virtual page component.

[0109] The purpose of steps S101-1211 and S101-1212 is to process the interaction logic of the page hierarchy based on virtual page events, that is, to define a data recycling task.

[0110] As shown in Figure 2, Figure 2 is a logical principle diagram of task execution in a cross-platform migration method for application software provided in this application.

[0111] Based on the above, a virtual page event can be understood as an access event causing a change in a second virtual module component outside the virtual module component corresponding to the access event, resulting in page interaction. At this time, the application software page will undergo corresponding interactive changes, and the page data involved in these interactive changes includes remote data and local data, which can also be understood as server data (remote) and local data (local). Therefore, the specific implementation process of steps S101-1211 can include:

[0112] Step S101-1211-1: Receive the virtual page event sent by the virtual module component;

[0113] Step S101-1211-2: Trigger a data recycling request based on the virtual page event;

[0114] Step S101-1211-3: Determine the data recycling task for the virtual page component based on the data recycling request.

[0115] The specific implementation process of step S101-1211-3 may include:

[0116] Step S101-1211-31: Based on the virtual page event, determine whether the page data required by the access page corresponding to the access request is local data or remote data;

[0117] Step S101-1211-32: If it is the remote data, then obtain the corresponding target page data from the remote end according to the access request;

[0118] Step S101-1211-33: If it is the near-end data, then obtain the corresponding target page data from the near end according to the access request;

[0119] Step S101-1211-34: Update the accessed page according to the target page data.

[0120] In this embodiment, whether the page data required to determine the access page corresponding to the access request is local data or remote data can be determined according to the settings of the application software. For example, for a food and beverage shopping software, historical order data, delivery service data, product data, etc. can be placed remotely, i.e., on the server; while user-related discount data, historical browsing data, etc. can be placed locally.

[0121] It should be noted that which page data is considered remote data and which is considered local data can be determined by considering the electronic device status of the application software, or by the application software's operational requirements, and is not limited to the examples above.

[0122] In this embodiment, the page can be directly refreshed based on steps S101-1211-31 to S101-1211-33, and may also include:

[0123] Data is written back based on the target page data obtained from the remote end;

[0124] The page components in the access page corresponding to the virtual page component are updated based on the data written back, and the module components in the access page corresponding to the virtual module component are also updated.

[0125] In this embodiment, writing back page data obtained from a remote location can be achieved by storing the obtained target page data locally, which can be done using a cache. This facilitates page refresh and ensures stability during page rendering. Alternatively, the page can be refreshed based on target page data obtained from a server.

[0126] It is understood that in this embodiment, task processing logic such as data recycling can be directly completed based on the virtual page event corresponding to the access event, and is not limited to the virtual page event sent by the virtual module component. That is, when the application software page generates a trigger event, the task processing logic such as data recycling is executed. If there is no page data, it indicates that it is a closed-loop update of the virtual module component itself, which does not involve page interaction logic, and the page does not need to be updated. Therefore, the processing logic (task execution) corresponding to the virtual module event is not limited to the subsequent steps given in the above example, which are based on receiving the virtual page event sent by the virtual module component.

[0127] If step S101-13 is the virtual module event, then the execution task of the virtual module component is defined according to the virtual module event. The specific implementation process may include:

[0128] Steps S101-131: Determine the module data corresponding to the virtual module event based on the virtual module event;

[0129] Steps S101-132: Update the access page corresponding to the access request based on the module data.

[0130] Regarding step S102: According to the programming language requirements of the migration platform, dynamic scripts are generated or modified for the virtual page component and the module component, and the first dynamic script corresponding to the virtual page component and the second dynamic script corresponding to the virtual module component are determined as the target migration data.

[0131] In this embodiment, the page data and module data can be obtained based on the relevant module components and page components involved in the target application software itself. The virtual page components and virtual module components can also originate from the page components and module components of the target application software. Therefore, the execution logic in the above-mentioned task execution can also be based on the script modification of the target application software, or the corresponding script can be generated when the target application software is generated. Therefore, the specific implementation process of step S102 may include:

[0132] Step S102-1: Generate or modify a dynamic script based on the execution task of the virtual page component, and determine the first dynamic script;

[0133] Step S102-2: Generate or modify a dynamic script based on the execution task of the virtual module component, and determine the second dynamic script.

[0134] The purpose of steps S102-1 and S102-2 is to modify the dynamic scripts of the virtual page component and the virtual module component to conform to the requirements of the migration platform's programming language, thereby aligning their execution logic and avoiding execution obstacles caused by differences in programming languages.

[0135] Regarding step S103: According to the interface provided by the migration platform, migrate the target rendering engine and the target migration data to the migration platform.

[0136] The migration platform can be another platform with a different operating system than the platform where the target application software resides. Alternatively, the migration platform can be understood as a migration system, enabling the target application software to be used across systems. In this embodiment, by calling the interfaces provided by the migration platform, the migration data corresponding to the virtual page components and virtual module components implemented by the target application software based on the rendering engine are migrated to the migration platform, thereby enabling the cross-platform application of the target application software.

[0137] The above describes a cross-platform migration method for application software provided in this application. This method implements migration data corresponding to virtual page components and virtual module components based on the rendering engine in the target application software, and migrates the target application software to the migration platform through the interface provided by the migration platform to achieve cross-platform application of the target application software. On the one hand, it eliminates the need for the target application software to be redeveloped to adapt to another platform (or system) and meet the programming requirements of another platform, reducing the cost of cross-platform application of the target application software. On the other hand, by defining virtualized components of the target application software through the rendering engine, the target rendering engine including the virtual page components and virtual module components of the target application software is determined, as well as the definition of the execution task processing logic of the virtual page events and virtual module events corresponding to the virtual page components and virtual module components. This enables the cross-platform application of the target application software through a lightweight rendering engine. Even in multi-platform scenarios, only the dynamic script needs to be modified to achieve dynamic cross-platform application. Furthermore, while achieving rapid migration, the original development structure of the target application software can be preserved, without affecting the iterative maintenance of the target application software.

[0138] The above is a detailed description of an embodiment of a cross-platform migration method for application software provided in this application. Corresponding to the aforementioned embodiment of a cross-platform migration method for application software, this application also discloses an embodiment of a cross-platform migration apparatus for application software. Please refer to Figure 3. Since the apparatus embodiment is basically similar to the method embodiment, it is described simply. For relevant details, please refer to the description of the method embodiment. The apparatus embodiment described below is merely illustrative.

[0139] As shown in Figure 3, Figure 3 is a structural schematic diagram of a cross-platform migration device for application software provided in this application. The device includes:

[0140] The first determining unit 301 is used to define virtualized components for the target application software based on the rendering engine, and to determine the target rendering engine that includes virtual page components and virtual module components of the target application software; wherein, the virtual page component is a virtual component that represents page element information, and the virtual module component is a virtual component that implements the interactive functions of the target application software.

[0141] The second determining unit 302 is used to generate or modify dynamic scripts for the virtual page component and the module component according to the programming language requirements of the migration platform, and determine the first dynamic script corresponding to the virtual page component and the second dynamic script corresponding to the virtual module component as target migration data.

[0142] The migration unit 303 is used to migrate the target rendering engine and the target migration data to the migration platform according to the interface provided by the migration platform.

[0143] The first determining unit 301 includes: a first determining subunit, a first defining subunit, and a second defining subunit;

[0144] The first determining subunit is used to determine whether the access event corresponding to the access request in the target application software is a virtual page event or a virtual module event.

[0145] The first defining subunit is used to define the execution task of the virtual page component according to the virtual page event if the determination result of the first determining subunit is the virtual page event;

[0146] The second definition subunit is used to define the execution task of the virtual module component according to the virtual module event if the determination result of the first determination subunit is the virtual module event.

[0147] The first determining subunit specifically includes: a type determining subunit and an event determining subunit;

[0148] The type determination subunit is used to determine the page state change type of the target application software based on the access request;

[0149] The event determination subunit is used to determine whether the access event is a virtual page event or a virtual module event based on the page state change type.

[0150] The type determination subunit specifically includes: a first change determination subunit and a module change determination subunit;

[0151] The first change determination subunit is used to determine, based on the access request, whether the change in the access page corresponding to the access event is the change in the first virtual module component itself corresponding to the access event;

[0152] The module change determination subunit is used to determine the page state change type as a virtual module component change type when the determination result of the first change determination subunit is yes.

[0153] The event determination subunit is specifically used to determine the access event as the virtual module event based on the change type of the virtual module component.

[0154] The type determination subunit specifically includes: a second change determination subunit and a page change subunit;

[0155] The second change determination subunit is used to determine, based on the access request, whether the access page corresponding to the access event includes a change in the second virtual module component;

[0156] The page change subunit is used to determine the page state change type as a virtual page component change type when the determination result of the second change determination subunit is yes.

[0157] The event determination subunit is specifically used to determine the access event as the virtual page event based on the change type of the virtual page component.

[0158] The first definition subunit specifically includes: a task definition subunit and a task determination subunit;

[0159] The task definition subunit is used to define the data recycling task of the virtual page component according to the virtual page event;

[0160] The task determination subunit is used to determine the data recycling task as the execution task of the virtual page component.

[0161] The task definition subunit includes: a receiving subunit, a triggering subunit, and a determining subunit;

[0162] The receiving subunit is used to receive the virtual page event sent by the virtual module component;

[0163] The triggering subunit is used to trigger a data recycling request based on the virtual page event;

[0164] The determining subunit is used to determine the data recycling task of the virtual page component based on the data recycling request.

[0165] The task definition subunit specifically includes: a data determination subunit, a first acquisition subunit, a second acquisition subunit, and an update subunit;

[0166] The data determination subunit is used to determine, based on the virtual page event, whether the page data required by the access page corresponding to the access request is near-end data or far-end data.

[0167] The first acquisition subunit is used to acquire the corresponding target page data from the remote end according to the access request if the determination result of the data determination subunit is the remote data;

[0168] The second acquisition subunit is used to acquire the corresponding target page data from the near end according to the access request if the determination result of the data determination subunit is the near end data;

[0169] The update subunit is used to update the accessed page based on the target page data.

[0170] It may also include:

[0171] The write-back subunit is used to write back data based on the target page data obtained from the remote end;

[0172] The update subunit can be specifically used to update the page component in the access page corresponding to the virtual page component, and to update the module component in the access page corresponding to the virtual module component, based on the data written back.

[0173] The second definition subunit specifically includes: a module data determination subunit and an update subunit;

[0174] The module data determination subunit is used to determine the module data corresponding to the virtual module event based on the virtual module event.

[0175] The update subunit is used to determine the module data determined in the subunit based on the module data, and update the access page corresponding to the access request.

[0176] The second determining unit 303 may specifically include: a first determining subunit and a second determining subunit;

[0177] The first determining subunit is used to generate or modify a dynamic script based on the execution task of the virtual page component, and to determine the first dynamic script;

[0178] The second determining subunit is used to determine the second dynamic script by generating or modifying a dynamic script based on the execution task of the virtual module component.

[0179] The above is a description of an embodiment of a cross-platform migration device for application software provided in this application. For details about the device, please refer to the specific content of the above method embodiment, which will not be described in detail here.

[0180] Based on the above, this application also provides a method for outputting pages of cross-platform migration application software, as shown in Figure 4. Figure 4 is a flowchart of a method for outputting pages of cross-platform migration application software provided by this application, which includes:

[0181] Step S401: In response to an access request to the target application software on the migration platform, the application page is output to the client interface of the target application software on the migration platform; wherein the application page is generated based on the cross-platform migration method of the application software described above.

[0182] In this embodiment, the migration can be understood as dynamically modifying the page of an application software developed on a first system platform to run and / or output on a second system platform and / or a third system platform (using a different development language than the application software on the first system platform); it can also be understood as directly enabling the application software page to run and / or output on the first, second, and third system platforms through dynamic means. The first, second, and third system platforms can be system platforms with different development languages. The solution provided in this application can achieve cross-platform application of the application software during the application software development process on three or more different system platforms, or it can achieve cross-platform application of the application software after the application software development is completed on a certain system platform.

[0183] For details regarding step S401, please refer to the above description of the cross-platform migration method for application software, which will not be elaborated here.

[0184] Accordingly, this application also provides a page output device for cross-platform migration of application software, as shown in Figure 5. Figure 5 is a structural schematic diagram of a page output device for cross-platform migration of application software provided in this application. The device includes:

[0185] The output unit 501 is used to output the application page to the client interface of the target application software on the migration platform in response to an access request for the target application software on the migration platform; wherein the application page is generated based on the cross-platform migration method of the application software described above.

[0186] The specific details of the page output device for this cross-platform migration application software can be found in the above-mentioned output method and migration method, and will not be elaborated here.

[0187] Based on the above, this application also provides a computer storage medium for storing data generated by a network platform and a program for processing the data generated by the network platform.

[0188] When the program is read and executed by the processor, it performs the steps involved in the cross-platform migration method embodiment of the application software described above; or, it performs the steps involved in the page output method embodiment of the cross-platform migration application software described above.

[0189] Based on the above, this application also provides an electronic device, as shown in FIG6. FIG6 is a schematic diagram of the structure of an electronic device provided by this application. An embodiment of the electronic device may include:

[0190] Processor 601;

[0191] The memory 602 is used to store a program for processing the application software. When the program is read and executed by the processor, it performs the steps involved in the cross-platform migration method embodiment of the application software described above; or, it performs the steps involved in the page output method embodiment of the cross-platform migration application software described above.

[0192] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

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

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

[0195] 1. Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer 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, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

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

[0197] Although this application discloses preferred embodiments as described above, it is not intended to limit this application. Any person skilled in the art can make possible changes and modifications without departing from the spirit and scope of this application. Therefore, the scope of protection of this application should be determined by the scope defined in the claims of this application.

Claims

1. A method for cross-platform migration of application software, characterized in that, include: Based on the rendering engine, virtualization components are defined for the target application software, and a target rendering engine including virtual page components and virtual module components of the target application software is determined; wherein, the virtual page component is a virtual component that represents page element information, and the virtual module component is a virtual component that implements the interactive functions of the target application software; According to the programming language requirements of the migration platform, dynamic scripts are generated or modified for the virtual page component and the virtual module component, and the first dynamic script corresponding to the virtual page component and the second dynamic script corresponding to the virtual module component are determined as the target migration data. The target rendering engine and the target migration data are migrated to the migration platform using the interface provided by the migration platform.

2. The cross-platform migration method for application software according to claim 1, characterized in that, The definition of virtualization components for the target application software based on the rendering engine includes: Based on the access request in the target application software, determine whether the access event corresponding to the access request is a virtual page event or a virtual module event; If it is a virtual page event, then the execution task of the virtual page component is defined according to the virtual page event; If it is a virtual module event, then the execution task of the virtual module component is defined according to the virtual module event.

3. The cross-platform migration method for application software according to claim 2, characterized in that, The step of determining whether the access event corresponding to the access request in the target application software is a virtual page event or a virtual module event includes: Based on the access request, determine the type of page state change of the target application software; Based on the type of page state change, determine whether the access event is a virtual page event or a virtual module event.

4. The cross-platform migration method for application software according to claim 3, characterized in that, The step of determining the type of page state change of the target application software based on the access request includes: Based on the access request, determine whether the access page corresponding to the access event contains a change in the first virtual module component itself corresponding to the access event; If so, then the page state change type is determined to be a virtual module component change type; The step of determining whether the access event is a virtual page event or a virtual module event based on the page state change type includes: Based on the change type of the virtual module component, the access event is determined to be a virtual module event; Based on the access request, determine whether the access page corresponding to the access event includes changes to the second virtual module component; If so, then the page state change type is determined to be a virtual page component change type; The step of determining whether the access event is a virtual page event or a virtual module event based on the page state change type includes: Based on the change type of the virtual page component, the access event is determined to be the virtual page event.

5. The cross-platform migration method for application software according to claim 2, characterized in that, If it is the virtual page event, then the execution task of the virtual page component is defined according to the virtual page event, including: Define the data recycling task for the virtual page component based on the virtual page event; The data recycling task is determined as the execution task of the virtual page component.

6. The cross-platform migration method for application software according to claim 5, characterized in that, Based on the virtual page event, define the data recycling task for the virtual page component, including: Receive the virtual page event sent by the virtual module component; Based on the virtual page event, a data recycling request is triggered; Based on the data recycling request, determine the data recycling task for the virtual page component.

7. The cross-platform migration method for application software according to claim 5 or 6, characterized in that, The step of defining the data recycling task for the virtual page component based on the virtual page event includes: Based on the virtual page event, determine whether the page data required by the access page corresponding to the access request is local data or remote data; If it is remote data, then obtain the corresponding target page data from the remote end according to the access request; If it is near-end data, then obtain the corresponding target page data from the near end according to the access request; The accessed page is updated based on the target page data.

8. The cross-platform migration method for application software according to claim 7, characterized in that, Also includes: Data is written back based on the target page data obtained from the remote end; The page components in the access page corresponding to the virtual page component are updated based on the data written back, and the module components in the access page corresponding to the virtual module component are also updated.

9. The cross-platform migration method for application software according to claim 2, characterized in that, If the event is a virtual module event, then the execution task of the virtual module component is defined according to the virtual module event, including: Based on the virtual module event, determine the module data corresponding to the virtual module event; Based on the module data, the access page corresponding to the access request is updated.

10. The cross-platform migration method for application software according to claim 2, characterized in that, The step of dynamically generating or modifying scripts for the virtual page components and the module components according to the programming language requirements of the migration platform includes: Based on the execution tasks of the virtual page component, a dynamic script is generated or modified to determine the first dynamic script; The second dynamic script is determined by generating or modifying a dynamic script based on the execution task of the virtual module component.

11. A method for outputting pages of cross-platform application software, characterized in that, include: In response to an access request to the target application software on the migration platform, an application page is output to the client interface of the target application software on the migration platform; wherein the application page is generated based on the cross-platform migration method of the application software according to any one of claims 1-10.

12. A computer storage medium for storing data generated by a network platform and a program for processing the data generated by the network platform; When the program is read and executed by the processor, it performs the cross-platform migration method for application software as described in any one of claims 1-10, or it performs the page output method for cross-platform migration of application software as described in claim 11.

13. An electronic device, comprising: processor; The memory is used to store a program for processing data generated by the network platform. When the program is read and executed by the processor, it executes the cross-platform migration method of application software as described in any one of claims 1-10, or executes the page output method of cross-platform migration application software as described in claim 11.

Images