Flutter引擎管理方法、系统、介质及原生端与流程

flutter引擎管理方法、系统、介质及原生端
技术领域
1.本发明属于flutter引擎技术领域，特别是涉及一种flutter引擎管理方法、系统、介质及原生端。


背景技术：

2.在原生应用与flutter应用混合开发中，当原生应用在嵌入flutter模块，跳转或加载flutter相关界面时，会因为flutter引擎初始化需要时间，导致整个页面的加载的过程相当慢，对于用户的体验会特别差。


技术实现要素：

3.鉴于以上所述现有技术的缺点，本发明的目的在于提供一种flutter引擎管理方法、系统、介质及原生端，用于解决现有原生应用在嵌入flutter模块，跳转或加载flutter相关界面时，由于flutter引擎初始化需要时间，导致整个页面的加载的过程相当慢的问题。
4.本发明的另一目的在于提供一种flutter引擎管理方法、系统、介质及原生端，通过在原生端加载flutter引擎之前，事先对flutter引擎管理模块进行初始化，保证flutter引擎管理模块中存在状态为可用的flutter引擎，以在该原生端需要加载flutter界面时，可直接从该flutter引擎管理模块中调取该状态可用的flutter引擎，从而省去了创建flutter引擎需要的时间，优化了在原生端里flutter界面的加载速度，进而提升了用户的使用体验。
5.本发明的又一目的在于提供一种flutter引擎管理方法、系统、介质及原生端，通过在原生端设置flutter引擎管理模块，实现了对flutter引擎统一的状态管理，使开发人员无需自行管理flutter引擎。
6.本发明的再一目的在于提供一种flutter引擎管理方法、系统、介质及原生端，通过对flutter引擎状态的管理，在多人员共同开发的情况下，通过flutter引擎的状态可避免其他开发人员误操作引起的程序崩溃。
7.本发明的再一目的在于提供一种flutter引擎管理方法、系统、介质及原生端，在关闭flutter界面后，将与该flutter界面绑定的flutter引擎的状态重新设置为可用，以便后续加载flutter界面时使用，做到了flutter引擎的重复使用，节省了内存。
8.为实现上述目的及其他相关目的，一方面，本发明提供一种flutter引擎管理方法，应用于原生端，所述原生端上设有flutter引擎管理模块；所述flutter引擎管理模块包括：引擎缓存池；所述方法包括以下步骤：初始化所述flutter引擎管理模块，以使所述引擎缓存池中包括至少一flutter引擎；在初始化完成后，接收flutter端发送的第一信号，并将所述flutter引擎的引擎状态设置为可用状态；在加载flutter界面时，从所述引擎缓存池中取出一所述引擎状态为所述可用状态的目标flutter引擎，并将所述目标flutter引擎与所述flutter界面绑定；在绑定后，将所述目标flutter引擎的引擎状态设置为使用中状态，
并向所述flutter端发送第二信号，以使所述flutter端基于所述第二信号执行所述flutter界面的相应跳转操作；所述第二信号中包括：所述flutter端需要跳转的界面信息。
9.为实现上述目的及其他相关目的，另一方面，本发明提供一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述的方法。
10.为实现上述目的及其他相关目的，又一方面，本发明提供一种原生端，包括：处理器及存储器；所述存储器用于存储计算机程序；所述处理器用于执行所述存储器存储的计算机程序，以使所述原生端执行上述的方法。
11.为实现上述目的及其他相关目的，再一方面，本发明提供一种flutter引擎管理系统，包括：上述的原生端和flutter端；所述flutter端用于向所述原生端发送第一信号，及接收所述原生端发送的第二信号，并基于所述第二信号执行flutter界面的相应跳转操作。
附图说明
12.图1显示为本发明的flutter引擎管理方法于一实施例中的流程图。
13.图2显示为本发明的原生端与flutter端于一实施例中的工作流程图。
14.图3显示为本发明的开发人员应用flutter引擎管理方法于一实施例中的使用流程图。
15.图4显示为本发明的初始化flutter引擎管理模块，以使引擎缓存池中包括至少一flutter引擎于一实施例中的流程图。
16.图5显示为本发明的原生端于一实施例中的结构示意图。
17.图6显示为本发明的flutter引擎管理系统于一实施例中的结构示意图。
18.标号说明
19.51
ꢀꢀꢀꢀꢀꢀꢀꢀꢀ
处理器
20.52
ꢀꢀꢀꢀꢀꢀꢀꢀꢀ
存储器
21.61
ꢀꢀꢀꢀꢀꢀꢀꢀꢀ
原生端
22.62
ꢀꢀꢀꢀꢀꢀꢀ
flutter端
23.s1～s5
ꢀꢀꢀ
步骤
24.s11～s13 步骤
具体实施方式
25.以下通过特定的具体实施例说明本发明的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。
26.需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图示中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。
27.本发明的flutter引擎管理方法、系统、介质及原生端，通过在原生端加载flutter
引擎之前，事先对flutter引擎管理模块进行初始化，保证flutter引擎管理模块中存在状态为可用的flutter引擎，以在该原生端需要加载flutter界面时，可直接从该flutter引擎管理模块中调取该状态可用的flutter引擎，从而省去了创建flutter引擎需要的时间，优化了在原生端里flutter界面的加载速度，进而提升了用户的使用体验；通过在原生端设置flutter引擎管理模块，实现了对flutter引擎统一的状态管理，使开发人员无需自行管理flutter引擎；通过对flutter引擎状态的管理，在多人员共同开发的情况下，通过flutter引擎的状态可避免其他开发人员误操作引起的程序崩溃；在关闭flutter界面后，将与该flutter界面绑定的flutter引擎的状态重新设置为可用，以便后续加载flutter界面时使用，做到了flutter引擎的重复使用，节省了内存。
28.如图1至图3所示，于一实施例中，本发明的flutter引擎管理方法应用于原生端(一应用程序app)，所述原生端上设有flutter引擎管理模块；所述flutter引擎管理模块包括引擎缓存池；具体地，该flutter引擎管理方法包括以下步骤：
29.步骤s1、初始化所述flutter引擎管理模块，以使所述引擎缓存池中包括至少一flutter引擎。
30.具体地，在嵌入flutter引擎的原生端启动时，采用异步的方式在原生端初始化该flutter引擎管理模块。
31.需要说明的是，于步骤s1中，不限于采用异步的方式初始化该flutter引擎管理模块，其只是作为一种优选的实施方式，能够在不占用其它进程资源的情况下，实现对该flutter引擎管理模块的初始化。
32.如图2和图4所示，于一实施例中，初始化所述flutter引擎管理模块，以使所述引擎缓存池中包括至少一flutter引擎包括以下步骤：
33.步骤s11、创建所述flutter引擎，并在创建所述flutter引擎时，将所述flutter引擎的引擎状态设置为创建中状态。
34.步骤s12、将创建好的所述flutter引擎加入所述引擎缓存池里。
35.步骤s13、在创建好所述flutter引擎后，控制所述flutter端执行所述flutter引擎对应的main方法。
36.需要说明的是，flutter端上存储有flutter引擎对应的main方法的代码，在原生端创建好flutter引擎后，该原生端会自动向flutter端，反馈一执行信号，以使该flutter端在接收到该执行信号后，即开始在其上执行该flutter引擎对应的main方法。
37.进一步地，所述flutter端用于在执行完所述main方法后，通过通道(用于原生端与flutter端之间传输数据)向所述原生端发送所述第一信号；该第一信号本质上只是一个用来实现告诉原生端，flutter端已经执行完main方法了的信号，其具体是一个什么样的信号并不作为限制本发明的条件，可以看做是一响应信号。
38.需要说明的是，flutter引擎相当于一个启动开关，在创建好该flutter引擎后，即相当于打开了该启动开关，然后，flutter端就开始执行main方法；整个main方法的执行是在flutter端上完成的，所以flutter引擎并不知道flutter端何时执行完该main方法，而只有在其执行完后，向该原生端发送一个信号(即上述的第一信号)，该原生端(flutter引擎管理模块)在接收到该信号后，即知道flutter端已经执行完main方法了。
39.需要说明的是，上述步骤s12和步骤s13的执行顺序没有先后限制，可以先执行步
骤s12，再执行步骤s13；也可以先执行步骤s13，再执行步骤s12；当然，也可以步骤s12和步骤s13同时执行。
40.步骤s2、在初始化完成后，接收flutter端发送的第一信号，并将所述flutter引擎的引擎状态设置为可用状态。
41.需要说明的是，经步骤s13，flutter端执行完flutter引擎对应的main方法后，即为初始化完成。
42.步骤s3、在加载flutter界面时，从所述引擎缓存池中取出一所述引擎状态为所述可用状态的目标flutter引擎，并将所述目标flutter引擎与所述flutter界面绑定。
43.需要说明的是，flutter引擎与flutter界面是一一绑定的，在一flutter引擎与一flutter界面绑定后，其无法同时再与其它的flutter界面进行绑定。
44.需要说明的是，于原生端上，设置有装载flutter界面的容器，在该原生端需要加载flutter界面时，即从该容器中调取出该flutter界面。
45.进一步地，在原生端加载flutter界面时，flutter端会主动按照预设的引擎选择规则从引擎缓存池内选取一引擎状态为可用状态的目标flutter引擎，并提供给该原生端，而不需要改原生端去选取。
46.需要说明的是，该预设的引擎选择规则具体是什么样的规则，不作为限制本发明的条件；优选地，是按照引擎缓存池内，flutter引擎位置的先后排列顺序，选择靠前位置的flutter引擎。
47.如图2所示，于一实施例中，在加载flutter界面时，若所述引擎缓存池中无引擎状态为所述可用状态的flutter引擎，则该flutter引擎管理方法包括以下步骤：
48.步骤一、创建新的flutter引擎，并将创建好的所述新的flutter引擎加入所述引擎缓存池里。
49.步骤二、待所述新的flutter引擎的引擎状态为所述可用状态时，再从所述引擎缓存池里取出所述新的flutter引擎。
50.需要说明的是，所述新的flutter引擎即对应步骤s3中所述的目标flutter引擎。
51.进一步地，上述步骤一和步骤二的工作原理可参考上述步骤s1(步骤s11～步骤s13)和步骤s2，在此不再详细赘述；而在经步骤二，从引擎缓存池里取出新的flutter引擎后，再通过步骤s3中，将该新的flutter引擎与flutter界面绑定。
52.步骤s4、在绑定后，将所述目标flutter引擎的引擎状态设置为使用中状态，并向所述flutter端发送第二信号，以使所述flutter端基于所述第二信号执行所述flutter界面的相应跳转操作。
53.具体地，原生端通过通道将第二信号发送至flutter端。
54.需要说明的是，所述第二信号中至少包括所述flutter端需要跳转的界面信息。
55.需要说明的是，由于flutter引擎与flutter界面是一一绑定的，通过在目标flutter引擎与一flutter界面进行绑定后，将该目标flutter引擎的引擎状态设置为使用中状态，使得该原生端在加载其它的flutter界面时，无法再使用该目标flutter引擎，即无法再将该目标flutter引擎与其它的flutter界面进行绑定(与flutter界面进行绑定的flutter引擎只能是引擎状态处于可用状态的flutter引擎)，从而在多人员共同开发的情况下，通过flutter引擎的引擎状态可避免其他开发人员误操作flutter引擎，导致后续开
发人员使用该flutter引擎时引起的程序崩溃；而且，有效避免了现有多个flutter界面共用一个flutter引擎，如果顶端flutter界面在销毁界面时，一并销毁了flutter引擎，则后续的flutter界面会出现的程序崩溃。
56.如图1所示，于一实施例中，该flutter引擎管理方法还包括以下步骤：
57.步骤s5、在所述flutter端关闭所述flutter界面后，将所述目标flutter引擎的引擎状态重新设置为所述可用状态，并将所述目标flutter引擎重新加入所述引擎缓存池里。
58.需要说明的是，在flutter端关闭经步骤s3与目标flutter引擎绑定的flutter界面(即表示flutter端执行完其所要进行的业务操作)后，该flutter端会向该原生端发出一响应信号，以告知该原生端，其已经完成了相应的业务操作，此时，该原生端会将该目标flutter引擎重新再加入至引擎缓存池里，并将该目标flutter引擎的引擎状态重新设置为可用状态，这样，在下次，该原生端需加载flutter界面时，可从该引擎缓存池里再次调取出该目标flutter引擎；当然，也可能调取的是该引擎缓存池内其它引擎状态为可用状态的一flutter引擎。
59.需要说明的是，通过上述步骤s5，实现了对flutter引擎的重复使用(一个flutter引擎可以被多次重复使用，但在同一时刻，只能被一个flutter界面使用，即不能同时被多个flutter界面使用)，一方面，避免了不停创建新的flutter引擎，导致内存占用量过大；另一方面，有效解决了对于不同的flutter界面创建不同的flutter引擎，会导致各个flutter引擎内的数据无法共享的问题。
60.如图2所示，于一实施例中，该flutter引擎管理方法还包括以下步骤：在所述原生端关闭时，将所述引擎缓存池里所有的flutter引擎均销毁，一方面，避免了在该原生端关闭后，其上的flutter引擎仍在工作，造成内存泄漏；另一方面，减少了内存占用，优化了flutter引擎的内存占用率。
61.如图2所示，于一实施例中，在所述原生端关闭时，还包括以下步骤：将所述引擎缓存池里所有的flutter引擎对应的引擎状态均设置为已销毁状态；这样，在后续有开发人员想要调取该flutter引擎时，会提醒该开发人员，该flutter引擎已被销毁。
62.需要说明的是，本发明中所涉及的原生端和flutter端，是指采用google的flutter框架，解决应用跨平台的方案，框架中依赖操作系统(ios和android)的相关开发是为原生端开发，与操作系统无关的开发称为flutter端开发。
63.需要说明的是，本发明所述的flutter引擎管理方法的保护范围不限于本实施例列举的步骤执行顺序，凡是根据本发明的原理所做的现有技术的步骤增减、步骤替换所实现的方案都包括在本发明的保护范围内。
64.本发明的存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述的flutter引擎管理方法。所述存储介质包括：只读存储器(read-only memory，rom)、随机访问存储器(random access memory，ram)、磁碟、u盘、存储卡或者光盘等各种可以存储程序代码的介质。
65.如图5所示，本发明的原生端包括处理器51及存储器52。
66.所述存储器52用于存储计算机程序；优选地，所述存储器52包括：rom、ram、磁碟、u盘、存储卡或者光盘等各种可以存储程序代码的介质。
67.所述处理器51与所述存储器52相连，用于执行所述存储器52存储的计算机程序，
以使所述原生端执行上述的flutter引擎管理方法。
68.优选地，所述处理器51可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等；还可以是数字信号处理器(digital signal processor，简称dsp)、专用集成电路(application specific integrated circuit，简称asic)、现场可编程门阵列(field programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
69.如图6所示，于一实施例中，本发明的flutter引擎管理系统包括上述的原生端61和flutter端62。
70.具体地，所述flutter端62用于向所述原生端61发送第一信号，及接收所述原生端61发送的第二信号，并基于所述第二信号执行flutter界面的相应跳转操作。
71.于一实施例中，所述flutter端还62用于存储flutter引擎对应的main方法的代码，和在所述原生端61创建好所述flutter引擎后，执行所述main方法，及在所述flutter端62关闭所述flutter界面后，向所述原生端61发出响应信号。
72.需要说明的是，该flutter引擎管理系统的工作原理与上述flutter引擎管理方法的工作原理相同，故在此不再赘述。
73.需要说明的是，本发明的flutter引擎管理系统可以实现本发明的flutter引擎管理方法，但本发明的flutter引擎管理方法的实现装置包括但不限于本实施例列举的flutter引擎管理系统的结构，凡是根据本发明的原理所做的现有技术的结构变形和替换，都包括在本发明的保护范围内。
74.综上所述，本发明的flutter引擎管理方法、系统、介质及原生端，通过在原生端加载flutter引擎之前，事先对flutter引擎管理模块进行初始化，保证flutter引擎管理模块中存在状态为可用的flutter引擎，以在该原生端需要加载flutter界面时，可直接从该flutter引擎管理模块中调取该状态可用的flutter引擎，从而省去了创建flutter引擎需要的时间，优化了在原生端里flutter界面的加载速度，进而提升了用户的使用体验；通过在原生端设置flutter引擎管理模块，实现了对flutter引擎统一的状态管理，使开发人员无需自行管理flutter引擎；通过对flutter引擎状态的管理，在多人员共同开发的情况下，通过flutter引擎的状态可避免其他开发人员误操作引起的程序崩溃；在关闭flutter界面后，将与该flutter界面绑定的flutter引擎的状态重新设置为可用，以便后续加载flutter界面时使用，做到了flutter引擎的重复使用，节省了内存；所以，本发明有效克服了现有技术中的种种缺点而具高度产业利用价值。
75.上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，举凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。