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

Abstract

The present application discloses a method, storage medium and electronic device for cross-platform migration of application software, the method comprising: defining a virtual component of a target application software based on a rendering engine, and determining a target rendering engine including a virtual page component and a virtual module component of the target application software; wherein the virtual page component is a virtual component representing page element information, and the virtual module component is a virtual component realizing the interactive function of the target application software; according to the programming language requirements of the migration platform, generating or modifying dynamic scripts for the virtual page component and the virtual module component, and determining a first dynamic script corresponding to the virtual page component and a second dynamic script corresponding to the virtual module component as target migration data; according to an interface provided by the migration platform, migrating the target rendering engine and the target migration data to the migration platform; thereby realizing lightweight cross-platform migration of application software and reducing complexity and cost.

Description

Technical Field

[0001] The present application relates to the field of computer application technology, and in particular to a method and device for cross-platform migration of application software, a computer storage medium and an electronic device. Background Art

[0002] With the continuous development of computer technology, various electronic devices relying on system architecture are becoming more and more diversified and comprehensive.

[0003] The application of the same application software in electronic devices with different system architectures is a complex process involving cross-platform compatibility and technical adaptation. The implementation of application software on multiple different systems requires developers to have cross-platform development skills and experience. By using cross-platform frameworks and libraries, writing portable code, conducting sufficient compatibility testing, and adapting and optimizing for specific platforms, the stable operation of application software on different systems and a good user experience can be ensured. In other words, in the face of different systems, corresponding technical development methods need to be adopted for each system so that the application software can be adapted to different systems.

[0004] The above is an introduction to the background technology of how application software can achieve compatibility and adaptation on different system platforms. Summary of the invention

[0005] The present application provides a cross-platform migration method for application software to solve the problems of complexity and high cost in the process of cross-system application software development in the prior art.

[0006] The present application provides a cross-platform migration method for application software, comprising:

[0007] Based on the rendering engine, a virtual component definition is performed on the target application software, and a target rendering engine including a virtual page component and a virtual module component of the target application software is determined; wherein the virtual page component is a virtual component representing page element information, and the virtual module component is a virtual component realizing the interactive function of the target application software;

[0008] 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 a first dynamic script corresponding to the virtual page component and a second dynamic script corresponding to the virtual module component are determined as target migration data;

[0009] The target rendering engine and the target migration data are migrated to the migration platform according to an interface provided by the migration platform.

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

[0011] According to the access request in the target application software, determining whether the access event corresponding to the access request is a virtual page event or a virtual module event;

[0012] If it is the virtual page event, defining the execution task of the virtual page component according to the virtual page event;

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

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

[0015] Determining a page state change type of the target application software according to the access request;

[0016] According to the page state change type, it is determined whether the access event is the virtual page event or the virtual module event.

[0017] In some embodiments, determining the page state change type of the target application software according to the access request includes:

[0018] Determine, according to the access request, whether the access page corresponding to the access event is a change of the first virtual module component itself corresponding to the access event;

[0019] If yes, determining that the page state change type is a virtual module component change type;

[0020] The step of determining, according to the page state change type, whether the access event is the virtual page event or the virtual module event comprises:

[0021] According to the virtual module component change type, the access event is determined to be the virtual module event.

[0022] In some embodiments, determining the page state change type of the target application software according to the access request includes:

[0023] determining, according to the access request, whether an access page corresponding to the access event includes a change in a second virtual module component;

[0024] If yes, determining that the page state change type is a virtual page component change type;

[0025] The step of determining, according to the page state change type, whether the access event is the virtual page event or the virtual module event comprises:

[0026] According to the virtual page component change type, the access event is determined to be the virtual page event.

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

[0028] According to the virtual page event, define a data recovery task of the virtual page component;

[0029] The data recovery task is determined as an execution task of the virtual page component.

[0030] In some embodiments, defining a data recovery task of the virtual page component according to the virtual page event includes:

[0031] Receiving the virtual page event sent by the virtual module component;

[0032] According to the virtual page event, trigger a data recovery request;

[0033] According to the data recycling request, a data recycling task of the virtual page component is determined.

[0034] In some embodiments, defining the data recovery task of the virtual page component according to the virtual page event includes:

[0035] Determining, according to the virtual page event, whether page data required by the access page corresponding to the access request is local data or remote data;

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

[0037] If it is the proximal data, obtaining the corresponding target page data from the proximal end according to the access request;

[0038] The access page is updated according to the target page data.

[0039] In some embodiments, it also includes:

[0040] Writing back data according to the target page data obtained from the remote end;

[0041] The page component in the access page corresponding to the virtual page component is updated according to the written-back data, and the module component in the access page corresponding to the virtual module component is updated.

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

[0043] According to the virtual module event, determining module data corresponding to the virtual module event;

[0044] An access page corresponding to the access request is updated according to the module data.

[0045] In some embodiments, the dynamic script generation or modification of the virtual page component and the module component according to the programming language requirements of the migration platform includes:

[0046] Generate or modify a dynamic script according to the execution task of the virtual page component to determine the first dynamic script;

[0047] A dynamic script is generated or modified according to the execution task of the virtual module component to determine the second dynamic script.

[0048] The present application also provides a page output method for cross-platform migration application software, comprising:

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

[0050] The present application also provides a page output device for cross-platform migration application software, comprising:

[0051] The output unit is used to output an application page to the client interface of the target application software on the migration platform in response to an access request to 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.

[0052] The present 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;

[0053] When the program is read and executed by the processor, the cross-platform migration method of the application software as described above is executed.

[0054] The present application also provides an electronic device, including:

[0055] processor;

[0056] The memory is used to store a program for processing data generated by a network platform. When the program is read and executed by the processor, the cross-platform migration method of the application software is executed.

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

[0058] The present application provides a cross-platform migration method for application software. The target application software implements migration data corresponding to virtual page components and virtual module components virtually abstracted by a rendering engine, and migrates to the migration platform through an interface provided by the migration platform to implement cross-platform application of the target application software. On the one hand, there is no need to redevelop the target application software according to the programming needs of another platform to adapt to another platform (or system), thereby reducing the cost of cross-platform application of the target application software. On the other hand, the target application software is virtualized and defined as a component by the rendering engine, and a target rendering engine including the virtual page components and virtual module components of the target application software, as well as a definition of the execution task processing logic of virtual page events and virtual module events corresponding to the virtual page components and virtual module components, is determined to implement cross-platform application of the target application software through a lightweight rendering engine. Even in a cross-multi-platform scenario, dynamic cross-platform application can be implemented by modifying the dynamic script, and the original development structure of the target application software can be retained while achieving rapid migration, without affecting the iterative maintenance of the target application software. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 This is a flow chart of a cross-platform migration method for application software provided by the present application.

[0060] Figure 2 This is a logical principle diagram of task execution in a cross-platform migration method of application software provided by the present application.

[0061] Figure 3 It is a structural diagram of a cross-platform migration device for application software provided by the present application.

[0062] Figure 4 This is a flow chart of a page output method for cross-platform migration application software provided by the present application.

[0063] Figure 5 It is a structural schematic diagram of a page output device for cross-platform migration application software provided by the present application.

[0064] Figure 6 It is a structural schematic diagram of an electronic device provided by this application. DETAILED DESCRIPTION

[0065] Many specific details are described in the following description to facilitate a full understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of the present application, so the present application is not limited by the specific implementation disclosed below.

[0066] The terms used in this application are only for the purpose of describing specific embodiments and are not intended to limit this application. The descriptions used in this application and the appended claims, such as "a", "first", and "second", are not limitations on quantity or sequence, but are used to distinguish the same type of information from each other.

[0067] Based on the above background technology, it can be known that the cross-platform migration method of an application software provided by the present application is a technology based on how the application software can achieve compatibility and adaptation with multiple different systems in a scenario where the background technology is a cross-platform (system). And it is because in such a scenario, there are complexity and cost issues of cross-system compatibility and adaptation, so the technical solution of the present application is conceived. Because, for an application software, no matter whether its function is simple or complex, its natively developed pages are diverse, and the corresponding underlying development architecture and logic are also complex, and they also need to be continuously updated and iterated. In the face of a cross-system scenario, it is necessary to redevelop based on the native page to adapt to the requirements of the corresponding operating system development language. This method will inevitably lead to an increase in development costs, and for an existing native page, the development complexity does not change at all. Therefore, the present application proposes a cross-platform migration method for application software, which can not only reduce the existing development cost but also reduce the existing development complexity. Before the cross-platform migration method of the application software provided by the present application is described below, the technical terms or technical terms involved in this field or the present technical solution are explained.

[0068] Native split-end: refers to the strategy of using different native development methods or technology stacks for different platforms (i.e. different operating systems) in application software development. In native split-end development, different operating systems have independent code bases and development environments, and developers can design and implement corresponding functions based on the characteristics and user experience requirements of each platform.

[0069] Native development page: Native App development page refers to application interface development using native programming languages ​​of specific operating systems (such as Objective-C or Swift for iOS, Java or Kotlin for Android, etc.). It can be simply understood that different operating systems require corresponding development programming languages ​​for application development.

[0070] Cross-end: refers to achieving a consistent user experience on the same application or service across multiple devices, such as computers, laptops, tablets, and mobile phones. The core of cross-end technology is to achieve seamless migration of applications and consistent experience between different devices.

[0071] Rendering engine: By optimizing the rendering algorithm and data processing flow, high-performance graphics rendering is achieved. It can quickly process large amounts of graphic data and generate high-quality images to meet the high requirements of real-time and realism of application software pages.

[0072] The migration platform refers to an operating system such as Android, IOS, or Hongmeng that can install and / or run application software. In the embodiment of the present application, at least part of the pages of the application software are implemented in a dynamic manner, and the development language does not completely use the native language required by the migration platform.

[0073] The above is a brief introduction and explanation of some relevant technical terms involved in this technical field. The following is a detailed description of the technical solution of this application.

[0074] like Figure 1 As shown, Figure 1 This is a flow chart of a cross-platform migration method for application software provided by the present application, the method comprising:

[0075] Step S101: defining a virtual component of a target application software based on a rendering engine, and determining a target rendering engine including a virtual page component and a module component of the target application software; wherein the virtual page component is a virtual component representing page element information, and the virtual module component is a virtual component realizing an interactive function of the target application software;

[0076] Step S102: generating or modifying dynamic scripts for the virtual page component and the module component according to the programming language requirements of the migration platform, and determining a first dynamic script corresponding to the virtual page component and a second dynamic script corresponding to the virtual module component as target migration data;

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

[0078] Regarding step S101: virtualizing components of the target application software based on the rendering engine, and determining a target rendering engine including a virtual page component and a virtual module component of the target application software.

[0079] The purpose of step S101 is to define the virtualized components of 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 in a certain system platform or an iterative version of the application software, for example: an application software A that has been developed in the currently known Android, Hongmeng and / or IOS system platforms. Of course, it can also be an application software that is under development in a certain system platform, for example: an application software A that is being developed in Android, Hongmeng and / or IOS system platforms. In other words, 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, there is no specific limitation on the status of the target application software. In this embodiment, the description is mainly based on the example of the application software that has been developed.

[0080] The virtual module component can be defined based on the module component in the native application software or an iterative version of the application software, that is, the virtual module component can be abstracted based on the module component in the native application software or an iterative version of the application software. A module component (or modular component) refers to a functional unit that can be reused independently in the application software, is responsible for a specific function or part, has clear functions and independent logic, and can be reused in different pages or different projects, thereby improving development efficiency and consistency.

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

[0082] In summary, the main purpose of page components is to combine different module components to form a complete and fully functional page. Module components are reusable functional units, while page components are the structural units for building the entire application page, usually composed of multiple module components.

[0083] In this embodiment, the virtual page component and the virtual module component can be defined based on the page component and the module component of the native application page, and of course can also be defined based on the page component and the module component of a certain iterative version of the application page.

[0084] It is understandable that the target application software is already developed software, and step S101 is to define the virtualized component of the target application software based on the rendering engine, that is, to establish an association relationship between the rendering engine and the virtualized component so that when the rendering engine is called again, the rendering engine can perform corresponding processing on the virtualized component.

[0085] It should be noted that the target application software is not limited to the application software downloaded and installed on the electronic device, but may also include: software that can be implemented on the electronic device in various ways such as mini-programs, links, and code scanning.

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

[0087] Step S101 - 11: determining, according to the access request in the target application software, whether the access event corresponding to the access request is a virtual page event or a virtual module event;

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

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

[0090] It is understandable that, for application software, the access event corresponding to the access request or operation event includes software startup, page loading, page data request, page layout, page interaction, etc. These events can be processed as buried data, so that when responding to the page operation, the buried data is triggered for corresponding processing. There can be different types of access events for application software, for example: page events that are associated with page changes themselves, such as: access events (or trigger events) for viewing products, access events for adding products to shopping carts, etc.; module events that are not associated with page data, such as: access events for shopping cart submission confirmation, access events for order confirmation, etc.

[0091] It should be noted that the so-called page event can be understood as a page trigger event, which 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 generated by page events. Therefore, as for the access event corresponding to the access request, it can be understood in combination with the actual application scenario and application page.

[0092] Whether the access event is a virtual page event or a virtual module event can be determined according to the type of page state change. Therefore, the specific implementation process of step S101-11 may include:

[0093] Step S101-111: determining the page state change type of the target application software according to the access request;

[0094] Step S101 - 112 : Determine whether the access event is the virtual page event or the virtual module event according to the page state change type.

[0095] In this embodiment, the specific process of determining the page status change type in step S101-111 may include:

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

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

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

[0099] Step S101 - 112 - 11: Determine, according to the virtual module component change type, that the access event is the virtual module event.

[0100] In this embodiment, the specific process of determining the page status change type in step S101-111 may include:

[0101] Step S101-111-21: determining, according to the access request, whether the access page corresponding to the access event includes a change in a second virtual module component; the second virtual module component may be understood as another virtual module component that has a relevant interactive relationship or linkage relationship with the virtual module component corresponding to the current access event;

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

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

[0104] Step S101 - 112 - 21: Determine, according to the virtual page component change type, that the access event is the virtual page event.

[0105] After determining the event type corresponding to the access event, corresponding execution tasks can be defined for different event types. The so-called execution tasks can be understood as processing logic executed for different event types, and finally rendered and outputted on the display side of the electronic device through the rendering engine. Therefore, the specific implementation of step S101-12 may include:

[0106] Step S101-1211: defining a data recovery task of the virtual page component according to the virtual page event;

[0107] Step S101 - 1212 : Determine the data recovery task as the execution task of the virtual page component.

[0108] The purpose of steps S101 - 1211 and S101 - 1212 is to process the interaction logic at the page level based on the virtual page event, that is, to define the data recovery task.

[0109] like Figure 2 As shown, Figure 2 This is a logical principle diagram of task execution in a cross-platform migration method of application software provided by the present application.

[0110] Based on the above, it can be understood that the virtual page event can be understood as an access event that causes a second virtual module component other than the virtual module component corresponding to the access event to change, and the resulting page interaction. At this time, the application software page will undergo a corresponding interactive change, and the page data involved in the interactive change 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 the steps S101-1211 can include:

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

[0112] Step S101-1211-2: triggering a data recovery request according to the virtual page event;

[0113] Step S101-1211-3: Determine the data recovery task of the virtual page component according to the data recovery request.

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

[0115] Step S101-1211-31: Determine, according to the virtual page event, whether the page data required by the access page corresponding to the access request is local data or remote data;

[0116] 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;

[0117] Step S101-1211-33: If it is the proximal data, obtaining the corresponding target page data from the proximal end according to the access request;

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

[0119] 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 based on the settings of the application software. For example, for restaurant shopping software, historical order data, delivery service data, product data, etc. can be placed remotely, that is, the server; user-related discount data, historical browsing data, etc. can be placed locally.

[0120] It should be noted that which page data is used as remote data and which page data is used as local data can be determined in combination with the electronic device state of the application software, and can also be determined according to the application software running requirements, and is not limited to the above examples.

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

[0122] Writing back data according to the target page data obtained from the remote end;

[0123] The page component in the access page corresponding to the virtual page component is updated according to the written-back data, and the module component in the access page corresponding to the virtual module component is updated.

[0124] In this embodiment, the data writing back for the page data obtained remotely can be to store the obtained target page data locally, which can be stored in the form of cache, so as to facilitate refreshing the page and ensure the stability of page rendering. Of course, the page can also be refreshed based on the target page data obtained by the server.

[0125] It is understandable that, in this embodiment, the task processing logic such as data recovery can be completed directly 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. In other words, when the application software page generates a trigger event, the task processing logic such as data recovery is executed. If there is no page data, it means that it is a closed-loop update of the virtual module component itself, which does not involve the page interaction logic. The page does not need to be updated, and then the processing logic corresponding to the virtual module event is executed (the task is executed). Therefore, the processing logic (task execution) corresponding to the virtual page event is not limited to the execution of subsequent steps based on receiving the virtual page event sent by the virtual module component given in the above example.

[0126] If the 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:

[0127] Step S101 - 131: according to the virtual module event, determining module data corresponding to the virtual module event;

[0128] Step S101 - 132 : updating the access page corresponding to the access request according to the module data.

[0129] 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 target migration data.

[0130] 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, and the virtual page components and virtual module components can also be derived from the page components and module components of the target application software. Therefore, the execution logic in the above-mentioned execution task can also modify the script based on the target application software, and of course, the corresponding script can also be generated when the target application software is generated. Therefore, the specific implementation process of step S102 can include:

[0131] Step S102-1: Generate or modify a dynamic script according to the execution task of the virtual page component to determine the first dynamic script;

[0132] Step S102-2: Generate or modify a dynamic script according to the execution task of the virtual module component to determine the second dynamic script.

[0133] The purpose of step S102-1 and step S102-2 is to modify the dynamic script of the virtual page component and the dynamic script of the virtual module component into a form required by the programming language of the migration platform, thereby achieving alignment of the execution logic of the two and avoiding execution barriers caused by different types of programming languages.

[0134] Regarding step S103: according to the interface provided by the migration platform, the target rendering engine and the target migration data are migrated to the migration platform.

[0135] The migration platform can be another platform with a different operating system from the platform where the target application software is located, and the migration platform can also be understood as a migration system, that is, to achieve cross-system application of the target application software. In this embodiment, by calling the interface provided by the migration platform, the migration data corresponding to the virtual page component and the virtual module component based on the virtual rendering engine implemented by the target application software is migrated to the migration platform, thereby achieving cross-platform application of the target application software.

[0136] The above is a cross-platform migration method for application software provided by the present application. The method implements the migration data corresponding to the virtual page components and virtual module components virtually abstracted by the rendering engine through the target application software, and migrates to the migration platform through the interface provided by the migration platform to realize the cross-platform application of the target application software. On the one hand, there is no need to redevelop the target application software according to the programming needs of another platform to adapt to another platform (or system), thereby reducing the application cost of the target application software in cross-platform implementation; on the other hand, the virtualization component definition of the target application software is performed through the rendering engine, and the target rendering engine including the virtual page components and virtual module components of the target application software, 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, is determined, so as to realize the cross-platform application of the target application software through the lightweight rendering engine. Even in the scenario across multiple platforms, only the dynamic script needs to be modified to realize the dynamic cross-platform application, and the original development structure of the target application software can be retained while realizing rapid migration, without affecting the iterative maintenance of the target application software.

[0137] The above is a detailed description of an embodiment of a cross-platform migration method for application software provided by the present application. Corresponding to the embodiment of a cross-platform migration method for application software provided above, the present application also discloses an embodiment of a cross-platform migration device for application software. Figure 3 Since the device embodiment is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device embodiment described below is only illustrative.

[0138] like Figure 3As shown, Figure 3 This is a schematic diagram of the structure of a cross-platform migration device for application software provided by the present application, the device comprising:

[0139] The first determining unit 301 is used to perform virtualization component definition on the target application software based on the rendering engine, and determine the target rendering engine including the virtual page component and the virtual module component of the target application software; wherein the virtual page component is a virtual component representing page element information, and the virtual module component is a virtual component realizing the interactive function of the target application software;

[0140] 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;

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

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

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

[0144] The first definition subunit is used to define an execution task of the virtual page component according to the virtual page event if the determination result of the first determination subunit is the virtual page event;

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

[0146] The first determination subunit specifically includes: a type determination subunit and an event determination subunit;

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

[0148] The event determination subunit is used to determine whether the access event is the virtual page event or the virtual module event according to the page state change type.

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

[0150] A first change determination subunit is used to determine, according to the access request, whether the access page corresponding to the access event is a change of the first virtual module component itself corresponding to the access event;

[0151] The module change determination subunit is used to determine that the page state change type is a virtual module component change type when the determination result of the first change determination subunit is yes;

[0152] The event determination subunit is specifically configured to determine, according to the virtual module component change type, that the access event is the virtual module event.

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

[0154] The second change determination subunit is used to determine, according to the access request, whether the access page corresponding to the access event includes a change of the second virtual module component;

[0155] The page change subunit is used to determine that the page state change type is a virtual page component change type when the determination result of the second change determination subunit is yes;

[0156] The event determination subunit is specifically used to determine, according to the virtual page component change type, that the access event is the virtual page event.

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

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

[0159] The task determination subunit is used to determine the data recovery task as an execution task of the virtual page component.

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

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

[0162] The trigger subunit is used to trigger a data recovery request according to the virtual page event;

[0163] The determining subunit is used to determine the data recycling task of the virtual page component according to the data recycling request.

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

[0165] The data determination subunit is used to determine whether the page data required by the access page corresponding to the access request is local data or remote data according to the virtual page event;

[0166] The first acquisition subunit is configured to acquire 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;

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

[0168] The updating subunit is used to update the access page according to the target page data.

[0169] It may also include:

[0170] A write-back subunit, used for writing back data according to the target page data obtained from the remote end;

[0171] The updating subunit may be specifically configured to update the page component in the access page corresponding to the virtual page component according to the written-back data, and to update the module component in the access page corresponding to the virtual module component.

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

[0173] The module data determination subunit is used to determine the module data corresponding to the virtual module event according to the virtual module event;

[0174] The updating subunit is used to update the access page corresponding to the access request according to the module data determined in the module data determining subunit.

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

[0176] The first determining subunit is used to generate or modify a dynamic script according to the execution task of the virtual page component to determine the first dynamic script;

[0177] The second determination subunit is used to generate or modify a dynamic script according to the execution task of the virtual module component to determine the second dynamic script.

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

[0179] Based on the above content, the present application also provides a page output method for cross-platform migration application software, such as Figure 4 As shown, Figure 4 This is a flow chart of a page output method for a cross-platform migration application software provided by the present application, the method comprising:

[0180] Step S401: in response to an access request to a target application software on a migration platform, output an application page to a 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.

[0181] In this embodiment, the migration can be understood as running and / or outputting a page of application software developed based on the first system platform on a second system platform and / or a third system platform (using a different development language from the first system platform application software) through dynamic transformation; it can also be understood as: directly making the application software page run and / or output on the first, second, and third system platforms in a dynamic manner. The first, second, and third system platforms can be system platforms with different development languages. The solution provided by this application can use the above-mentioned technical solution of this application to realize cross-platform application of application software in the process of application software development on three or more different system platforms, and can also use the above-mentioned technical solution of this application to realize cross-platform application of application software after the application software development is completed on a certain system platform.

[0182] For the specific content of step S401, please refer to the above description of the cross-platform migration method of application software, which will not be described in detail here.

[0183] Accordingly, the present application also provides a page output device for cross-platform migration application software, such as Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of a page output device for a cross-platform migration application software provided by the present application, the device comprising:

[0184] The output unit 501 is used to output an application page to the client interface of the target application software on the migration platform in response to an access request to 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.

[0185] The specific content of the page output device of the cross-platform migration application software can be combined with the specific content of the above-mentioned output method and migration method, and will not be described in detail here.

[0186] Based on the above content, the present 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;

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

[0188] Based on the above content, the present application also provides an electronic device, such as Figure 6 As shown, Figure 6 : is a schematic diagram of the structure of an electronic device provided by the present application. The electronic device embodiment may include:

[0189] Processor 601;

[0190] 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 executes the steps involved in the above-mentioned cross-platform migration method embodiment of the application software; or, it executes the steps involved in the above-mentioned cross-platform migration application software page output method embodiment.

[0191] 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, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

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

[0193] Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0194] 1. Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules 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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include non-transitory media such as modulated data signals and carrier waves.

[0195] 2. Those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0196] Although the present application is disclosed as above in the form of a preferred embodiment, it is not intended to limit the present application. Any technical personnel in this field may make possible changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims of the present application.

Claims

1. A cross-platform migration method for application software, characterized in that: include: Based on the rendering engine, a virtual component definition is performed on the target application software, and a target rendering engine including a virtual page component and a virtual module component of the target application software is determined; wherein the virtual page component is a virtual component representing page element information, and the virtual module component is a virtual component realizing the interactive function of the target application software; According to the programming language requirements of the migration platform, the virtual page component and the virtual module component are subjected to dynamic script generation or modification, and a first dynamic script corresponding to the virtual page component and a second dynamic script corresponding to the virtual module component are determined as target migration data; including: according to the execution task of the virtual page component, the dynamic script is generated or modified to determine the first dynamic script; according to the execution task of the virtual module component, the dynamic script is generated or modified to determine the second dynamic script; Migrating the target rendering engine and the target migration data to the migration platform according to an interface provided by the migration platform; The virtualization component definition of the target application software based on the rendering engine includes: According to 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 the virtual page event, define the execution task of the virtual page component according to the virtual page event; if it is the virtual module event, define the execution task of the virtual module component according to the virtual module event; the virtual page event is a page event that has an association relationship with the page change itself; the virtual module event is a module event that has no association relationship with the page data; wherein, the virtual module event only involves changes in the first virtual module component itself corresponding to the access event, and the virtual page event involves changes in a second virtual module component other than the first virtual module component corresponding to the access event.

2. The cross-platform migration method of application software according to claim 1, characterized in that: The step of determining, according to the access request in the target application software, whether the access event corresponding to the access request is a virtual page event or a virtual module event comprises: Determining a page state change type of the target application software according to the access request; According to the page state change type, it is determined whether the access event is the virtual page event or the virtual module event.

3. The cross-platform migration method of application software according to claim 2, characterized in that: The step of determining the page state change type of the target application software according to the access request includes: Determine, according to the access request, whether the access page corresponding to the access event is a change of the first virtual module component itself corresponding to the access event; If yes, determining that the page state change type is a virtual module component change type; The step of determining, according to the page state change type, whether the access event is the virtual page event or the virtual module event comprises: According to the virtual module component change type, determining that the access event is the virtual module event; determining, according to the access request, whether an access page corresponding to the access event includes a change in a second virtual module component; If yes, determining that the page state change type is a virtual page component change type; The step of determining, according to the page state change type, whether the access event is the virtual page event or the virtual module event comprises: According to the virtual page component change type, the access event is determined to be the virtual page event.

4. The cross-platform migration method of application software according to claim 1, characterized in that: If it is the virtual page event, defining the execution task of the virtual page component according to the virtual page event includes: According to the virtual page event, a data recovery task of the virtual page component is defined; wherein the data recovery task is to update the access page corresponding to the access request; The data recovery task is determined as an execution task of the virtual page component.

5. The cross-platform migration method of application software according to claim 4, characterized in that: According to the virtual page event, a data recovery task of the virtual page component is defined, including: Receiving the virtual page event sent by the virtual module component; According to the virtual page event, trigger a data recovery request; According to the data recycling request, a data recycling task of the virtual page component is determined.

6. The cross-platform migration method of application software according to claim 4 or 5, characterized in that: Defining the data recovery task of the virtual page component according to the virtual page event includes: Determining, according to the virtual page event, whether page data required by the access page corresponding to the access request is local data or remote data; If it is the remote data, then the corresponding target page data is obtained from the remote end according to the access request; if it is the local data, then the corresponding target page data is obtained from the local end according to the access request; The access page is updated according to the target page data.

7. The cross-platform migration method of application software according to claim 6, characterized in that: Also includes: Writing back data according to the target page data obtained from the remote end; The page component in the access page corresponding to the virtual page component is updated according to the written-back data, and the module component in the access page corresponding to the virtual module component is updated.

8. The cross-platform migration method of application software according to claim 1, characterized in that: If it is the virtual module event, defining the execution task of the virtual module component according to the virtual module event includes: According to the virtual module event, determining module data corresponding to the virtual module event; An access page corresponding to the access request is updated according to the module data.

9. A page output method for cross-platform migration 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 for application software as described in any one of claims 1-8 above.

10. 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, the program executes the cross-platform migration method of application software as described in any one of claims 1 to 8 above, or executes the page output method of cross-platform migration application software as described in claim 9 above.

11. An electronic device, comprising: processor; A memory for storing a program for processing data generated by a network platform, wherein when the program is read and executed by the processor, the program executes a method for cross-platform migration of application software as described in any one of claims 1 to 8 above, or executes a page output method for cross-platform migration of application software as described in claim 9 above.

Images