Flutter engine management methods, system, media, and native client
By initializing the Flutter engine management module on the native side, the problem of slow page loading caused by Flutter engine initialization is solved, achieving fast loading and unified state management, improving user experience and saving memory.
Patent Information
- Application Number
- CN202110504748.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-05-10
- Publication Date
- 2025-11-14
- Estimated Expiration
- 2041-05-10
AI Technical Summary
When embedding Flutter modules into native applications, the Flutter engine takes time to initialize, which slows down page loading and affects user experience.
Before loading the Flutter engine on the native side, the Flutter engine management module is initialized in advance to ensure that the engine is available, and the available engine is retrieved from the cache pool when needed to avoid duplicate creation.
It optimizes the loading speed of Flutter interfaces, improves user experience, implements unified state management of the Flutter engine, avoids program crashes caused by developer misoperation, and saves memory by reusing the engine.
Smart Images
Figure CN115328528B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of Flutter engine technology, and in particular relates to a Flutter engine management method, system, medium and native client. Background Technology
[0002] In hybrid development of native and Flutter applications, when a native application embeds a Flutter module and navigates to or loads a Flutter-related interface, the loading process of the entire page is quite slow because the Flutter engine takes time to initialize, resulting in a particularly poor user experience. Summary of the Invention
[0003] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a Flutter engine management method, system, medium and native client to solve the problem that when existing native applications embed Flutter modules and jump to or load Flutter-related interfaces, the loading process of the entire page is quite slow because the Flutter engine initialization takes time.
[0004] Another objective of this invention is to provide a Flutter engine management method, system, medium, and native client. By initializing the Flutter engine management module before loading the Flutter engine on the native client, the invention ensures that a usable Flutter engine exists in the Flutter engine management module. When the native client needs to load a Flutter interface, the usable Flutter engine can be directly retrieved from the Flutter engine management module, thereby saving the time required to create the Flutter engine, optimizing the loading speed of the Flutter interface on the native client, and thus improving the user experience.
[0005] Another objective of this invention is to provide a Flutter engine management method, system, medium, and native client. By setting up a Flutter engine management module on the native client, unified state management of the Flutter engine is achieved, eliminating the need for developers to manage the Flutter engine themselves.
[0006] Another objective of this invention is to provide a Flutter engine management method, system, medium, and native client. By managing the state of the Flutter engine, program crashes caused by misoperation by other developers can be avoided in collaborative development scenarios.
[0007] Another objective of this invention is to provide a Flutter engine management method, system, medium, and native client that, after closing the Flutter interface, resets the state of the Flutter engine bound to the Flutter interface to be available so that it can be used when loading the Flutter interface later, thereby achieving the reuse of the Flutter engine and saving memory.
[0008] To achieve the above and other related objectives, this invention provides a Flutter engine management method applied to a native client, wherein the native client has a Flutter engine management module; the Flutter engine management module includes an engine cache pool; the method includes the following steps: initializing the Flutter engine management module so that the engine cache pool includes at least one Flutter engine; after initialization, receiving a first signal sent by the Flutter client and setting the engine state of the Flutter engine to an available state; when loading the Flutter interface, retrieving a target Flutter engine whose engine state is in the available state from the engine cache pool and binding the target Flutter engine to the Flutter interface; after binding, setting the engine state of the target Flutter engine to a used state and sending a second signal to the Flutter client so that the Flutter client performs a corresponding jump operation on the Flutter interface based on the second signal; the second signal includes: interface information that the Flutter client needs to jump to.
[0009] To achieve the above and other related objectives, in another aspect, the present invention provides a storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.
[0010] To achieve the above and other related objectives, in another aspect, the present invention provides a native terminal, comprising: a processor and a memory; the memory for storing a computer program; and the processor for executing the computer program stored in the memory to cause the native terminal to perform the above-described method.
[0011] To achieve the above and other related objectives, in another aspect, the present invention provides a Flutter engine management system, comprising: the aforementioned native client and Flutter client; the Flutter client is used to send a first signal to the native client, and receive a second signal sent by the native client, and perform corresponding jump operations on the Flutter interface based on the second signal. Attached Figure Description
[0012] Figure 1The flowchart shown is an embodiment of the Flutter engine management method of the present invention.
[0013] Figure 2 This diagram illustrates the workflow of the native and Flutter versions of this invention in one embodiment.
[0014] Figure 3 The diagram shows a flowchart illustrating how the developer of this invention applies the Flutter engine management method in one embodiment.
[0015] Figure 4 The flowchart shown is a process for initializing the Flutter engine management module of the present invention to enable the engine cache pool to include at least one Flutter engine in one embodiment.
[0016] Figure 5 The diagram shown is a structural schematic of the native terminal of the present invention in one embodiment.
[0017] Figure 6 The diagram shown is a structural schematic of the Flutter engine management system of the present invention in one embodiment.
[0018] Label Explanation
[0019] 51 processor
[0020] 52 Memory
[0021] 61 Native Client
[0022] 62 Flutter client
[0023] Steps S1 to S5
[0024] Steps S11 to S13 Detailed Implementation
[0025] The following specific embodiments illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.
[0026] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the illustrations only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.
[0027] The Flutter engine management method, system, medium, and native client of this invention initialize the Flutter engine management module before loading the Flutter engine on the native client, ensuring that a usable Flutter engine exists in the Flutter engine management module. This allows the native client to directly retrieve the usable Flutter engine from the Flutter engine management module when a Flutter interface needs to be loaded, saving the time required to create the Flutter engine, optimizing the loading speed of the Flutter interface on the native client, and thus improving the user experience. By setting up the Flutter engine management module on the native client, unified state management of the Flutter engine is achieved, eliminating the need for developers to manage the Flutter engine themselves. Managing the Flutter engine state prevents program crashes caused by accidental operations by other developers in collaborative development scenarios. After closing the Flutter interface, the state of the Flutter engine bound to that interface is reset to usable for subsequent loading of the Flutter interface, achieving Flutter engine reuse and saving memory.
[0028] like Figures 1 to 3 As shown, in one embodiment, the Flutter engine management method of the present invention is applied to a native application (APP), wherein the native application has a Flutter engine management module; the Flutter engine management module includes an engine cache pool; specifically, the Flutter engine management method includes the following steps:
[0029] Step S1: Initialize the Flutter engine management module so that the engine cache pool includes at least one Flutter engine.
[0030] Specifically, when the native client with the embedded Flutter engine starts, the Flutter engine management module is initialized asynchronously on the native client.
[0031] It should be noted that in step S1, the Flutter engine management module is not limited to being initialized asynchronously. It is only a preferred implementation method that can initialize the Flutter engine management module without occupying other process resources.
[0032] like Figure 2 and Figure 4As shown, in one embodiment, initializing the Flutter engine management module to include at least one Flutter engine in the engine cache pool includes the following steps:
[0033] Step S11: Create the Flutter engine, and when creating the Flutter engine, set the engine status of the Flutter engine to the creation state.
[0034] Step S12: Add the created Flutter engine to the engine cache pool.
[0035] Step S13: After the Flutter engine is created, control the Flutter client to execute the main method corresponding to the Flutter engine.
[0036] It should be noted that the Flutter client stores the code of the main method corresponding to the Flutter engine. After the Flutter engine is created on the native client, the native client will automatically send an execution signal to the Flutter client so that the Flutter client will start executing the main method corresponding to the Flutter engine after receiving the execution signal.
[0037] Furthermore, after executing the main method, the Flutter client sends the first signal to the native client through a channel (used for data transmission between the native client and the Flutter client). This first signal is essentially just a signal used to tell the native client that the Flutter client has finished executing the main method. What kind of signal it is is not a limitation of the present invention and can be regarded as a response signal.
[0038] It's important to note that the Flutter engine acts like a start switch. Once the Flutter engine is created, it's like turning on the start switch, and then the Flutter side begins executing the main method. The entire execution of the main method is completed on the Flutter side, so the Flutter engine doesn't know when the Flutter side has finished executing the main method. Only after it finishes executing does it send a signal to the native side (the first signal mentioned above). Upon receiving this signal, the native side (the Flutter engine management module) knows that the Flutter side has finished executing the main method.
[0039] It should be noted that there is no restriction on the execution order of the above steps S12 and S13. Step S12 can be executed first, followed by step S13; or step S13 can be executed first, followed by step S12; or steps S12 and S13 can be executed simultaneously.
[0040] Step S2: After initialization is complete, receive the first signal sent by the Flutter client and set the Flutter engine's engine state to an available state.
[0041] It should be noted that after step S13, when the Flutter side finishes executing the main method corresponding to the Flutter engine, the initialization is complete.
[0042] Step S3: When loading the Flutter interface, retrieve a target Flutter engine whose engine status is in the available state from the engine cache pool, and bind the target Flutter engine to the Flutter interface.
[0043] It should be noted that the Flutter engine and the Flutter interface are bound one-to-one. Once a Flutter engine is bound to a Flutter interface, it cannot be bound to other Flutter interfaces at the same time.
[0044] It should be noted that a container for loading Flutter interfaces is set up on the native client. When the native client needs to load Flutter interfaces, it retrieves the Flutter interfaces from this container.
[0045] Furthermore, when loading the Flutter interface on the native client, the Flutter client will proactively select a target Flutter engine with an available state from the engine cache pool according to the preset engine selection rules and provide it to the native client, without the native client having to make the selection.
[0046] It should be noted that the specific rules for selecting the engine are not intended to limit the invention. Preferably, the Flutter engine is selected based on the order in which the Flutter engines are located within the engine cache pool.
[0047] like Figure 2 As shown, in one embodiment, when loading a Flutter interface, if there is no Flutter engine in the engine cache pool with the engine status in the available state, the Flutter engine management method includes the following steps:
[0048] Step 1: Create a new Flutter engine and add the newly created Flutter engine to the engine cache pool.
[0049] Step 2: Once the new Flutter engine is in the available state, retrieve the new Flutter engine from the engine cache pool.
[0050] It should be noted that the new Flutter engine is the same as the target Flutter engine mentioned in step S3.
[0051] Furthermore, the working principle of the above steps one and two can be referred to steps S1 (steps S11 to S13) and S2 above, and will not be elaborated here; after retrieving the new Flutter engine from the engine cache pool in step two, the new Flutter engine is bound to the Flutter interface in step S3.
[0052] Step S4: After binding, set the engine state of the target Flutter engine to the in-use state and send a second signal to the Flutter client so that the Flutter client can perform the corresponding jump operation of the Flutter interface based on the second signal.
[0053] Specifically, the native client sends the second signal to the Flutter client through a channel.
[0054] It should be noted that the second signal includes at least the interface information that the Flutter client needs to jump to.
[0055] It's important to note that since the Flutter engine and Flutter UI are bound one-to-one, by binding a target Flutter engine to a Flutter UI and setting its engine state to "in use," the native application cannot use this target Flutter engine when loading other Flutter UIs. In other words, it cannot bind the target Flutter engine to any other Flutter UI (the Flutter engine bound to a Flutter UI can only be an available Flutter engine). Therefore, in collaborative development scenarios, the engine state prevents other developers from accidentally manipulating the Flutter engine, which could lead to program crashes when subsequent developers use it. Furthermore, it effectively avoids multiple existing Flutter UIs sharing a single Flutter engine. If the top-level Flutter UI destroys its engine along with the UI, subsequent Flutter UIs will experience program crashes.
[0056] like Figure 1 As shown, in one embodiment, the Flutter engine management method further includes the following steps:
[0057] Step S5: After closing the Flutter interface on the Flutter client, reset the engine state of the target Flutter engine to the available state and add the target Flutter engine back to the engine cache pool.
[0058] It should be noted that after the Flutter client closes the Flutter interface bound to the target Flutter engine via step S3 (meaning the Flutter client has completed its business operation), the Flutter client will send a response signal to the native client to inform it that it has completed the corresponding business operation. At this time, the native client will add the target Flutter engine back to the engine cache pool and reset the engine status of the target Flutter engine to an available state. In this way, the next time the native client needs to load the Flutter interface, it can retrieve the target Flutter engine from the engine cache pool again; of course, it may also retrieve another Flutter engine in the engine cache pool whose engine status is available.
[0059] It should be noted that through step S5 above, the reuse of the Flutter engine is realized (a Flutter engine can be reused multiple times, but at the same time, it can only be used by one Flutter interface, that is, it cannot be used by multiple Flutter interfaces at the same time). On the one hand, it avoids constantly creating new Flutter engines, which leads to excessive memory consumption; on the other hand, it effectively solves the problem that creating different Flutter engines for different Flutter interfaces will cause data within each Flutter engine to be unable to be shared.
[0060] like Figure 2 As shown, in one embodiment, the Flutter engine management method further includes the following steps: when the native end is shut down, all Flutter engines in the engine cache pool are destroyed. On the one hand, this avoids the Flutter engines on the native end from still working after the native end is shut down, causing memory leaks; on the other hand, it reduces memory usage and optimizes the memory usage rate of the Flutter engine.
[0061] like Figure 2 As shown, in one embodiment, when the native end is closed, the following steps are also included: setting the engine status of all Flutter engines in the engine cache pool to the destroyed state; in this way, when a developer wants to call the Flutter engine later, the developer will be reminded that the Flutter engine has been destroyed.
[0062] It should be noted that the native and Flutter sides mentioned in this invention refer to solutions for cross-platform applications using Google's Flutter framework. Development related to the operating system (iOS and Android) within the framework is called native development, while development independent of the operating system is called Flutter development.
[0063] It should be noted that the protection scope of the Flutter engine management method described in this invention is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this invention is included within the protection scope of this invention.
[0064] The storage medium of this invention stores a computer program, which, when executed by a processor, implements the aforementioned Flutter engine management method. The storage medium includes various media capable of storing program code, such as read-only memory (ROM), random access memory (RAM), magnetic disk, USB flash drive, memory card, or optical disk.
[0065] like Figure 5 As shown, the native terminal of the present invention includes a processor 51 and a memory 52.
[0066] The memory 52 is used to store computer programs; preferably, the memory 52 includes various media that can store program code, such as ROM, RAM, magnetic disk, USB flash drive, memory card or optical disk.
[0067] The processor 51 is connected to the memory 52 and is used to execute the computer program stored in the memory 52 so that the native end executes the Flutter engine management method described above.
[0068] Preferably, the processor 51 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0069] like Figure 6 As shown, in one embodiment, the Flutter engine management system of the present invention includes the aforementioned native client 61 and Flutter client 62.
[0070] Specifically, the Flutter client 62 is used to send a first signal to the native client 61 and receive a second signal sent by the native client 61, and perform a corresponding jump operation on the Flutter interface based on the second signal.
[0071] In one embodiment, the Flutter client 62 is further configured to store the code of the main method corresponding to the Flutter engine, execute the main method after the Flutter engine is created on the native client 61, and send a response signal to the native client 61 after the Flutter client 62 closes the Flutter interface.
[0072] It should be noted that the working principle of this Flutter engine management system is the same as that of the Flutter engine management method described above, so it will not be repeated here.
[0073] It should be noted that the Flutter engine management system of the present invention can implement the Flutter engine management method of the present invention, but the implementation device of the Flutter engine management method of the present invention includes, but is not limited to, the structure of the Flutter engine management system listed in this embodiment. All structural modifications and substitutions of the prior art made in accordance with the principles of the present invention are included within the protection scope of the present invention.
[0074] In summary, the Flutter engine management method, system, medium, and native client of this invention initialize the Flutter engine management module before loading the Flutter engine on the native client, ensuring that a usable Flutter engine exists within the module. This allows the native client to directly retrieve the usable Flutter engine from the management module when a Flutter interface needs to be loaded, saving the time required to create the Flutter engine, optimizing the loading speed of the Flutter interface on the native client, and thus improving the user experience. By setting up the Flutter engine management module on the native client, unified state management of the Flutter engine is achieved, eliminating the need for developers to manage the Flutter engine themselves. Managing the Flutter engine state prevents program crashes caused by accidental operations by other developers in collaborative development scenarios. After closing the Flutter interface, the state of the Flutter engine bound to that interface is reset to usable for subsequent loading of the Flutter interface, achieving Flutter engine reuse and saving memory. Therefore, this invention effectively overcomes the various shortcomings of the prior art and has high industrial application value.
[0075] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.
Claims
1. A Flutter engine management method, applied to native applications, characterized in that, The native client has a Flutter engine management module; the Flutter engine management module includes: an engine cache pool; the method includes the following steps: The Flutter engine management module is initialized so that the engine cache pool includes at least one Flutter engine. When the native client with the embedded Flutter engine starts, the Flutter engine management module is initialized asynchronously on the native client. After initialization is complete, the first signal sent by the Flutter client is received, and the Flutter engine's engine state is set to an available state; When loading the Flutter interface, a target Flutter engine whose engine status is in the available state is retrieved from the engine cache pool, and the target Flutter engine is bound to the Flutter interface; After binding, the engine state of the target Flutter engine is set to "in use" and a second signal is sent to the Flutter client, so that the Flutter client performs the corresponding jump operation of the Flutter interface based on the second signal; the second signal includes: the interface information that the Flutter client needs to jump to; Initializing the Flutter engine management module to ensure that the engine cache pool includes at least one Flutter engine includes the following steps: Create the Flutter engine, and set the engine status of the Flutter engine to the "creating" state when creating the Flutter engine; Add the created Flutter engine to the engine cache pool; After the Flutter engine is created, the Flutter client is controlled to execute the main method corresponding to the Flutter engine; the Flutter client is used to send the first signal to the native client after executing the main method; After closing the Flutter interface on the Flutter client, the engine state of the target Flutter engine is reset to the available state, and the target Flutter engine is added back to the engine cache pool. When loading a Flutter interface, if there is no Flutter engine in the engine cache pool with the engine status set to "available", the following steps are included: Create a new Flutter engine and add the newly created Flutter engine to the engine cache pool; Once the new Flutter engine is in the available state, the new Flutter engine is retrieved from the engine cache pool; the new Flutter engine is the target Flutter engine.
2. The method according to claim 1, further comprising the following step: When the native client is shut down, all Flutter engines in the engine cache pool are destroyed.
3. The method according to claim 2, further comprising the following step when the native end is closed: Set the engine status of all Flutter engines in the engine cache pool to the destroyed state.
4. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the Flutter engine management method as described in any one of claims 1 to 3.
5. A native endpoint, characterized in that, include: Processor and memory; The memory is used to store computer programs; The processor is used to execute the computer program stored in the memory, so that the native end performs the Flutter engine management method according to any one of claims 1 to 3.
6. A Flutter engine management system, characterized in that, include: The native client and Flutter client as described in claim 5; The Flutter client is used to send a first signal to the native client, and Receive the second signal sent by the native client, and perform the corresponding jump operation of the Flutter interface based on the second signal.
7. The system according to claim 6, wherein the Flutter client is further configured to store the code of the main method corresponding to the Flutter engine, and After the Flutter engine is created on the native side, the main method is executed, and After closing the Flutter interface on the Flutter side, a response signal is sent to the native side.