Android 在单个UIViewController最佳实践中嵌入多个颤振小部件？

我正在研究将Flutter集成到现有的iOS和Android项目中。我的主要经验是在iOS，所以这篇文章将从iOS的角度出发。但是可以用UIViewController替换活动/片段。我将给出一些我目前理解的背景知识，并在文章的最后提出我的实际问题

我们的主要用例是将小型的

小部件
嵌入到现有的视图控制器中。我已经阅读了颤振文档和指南，并成功地与我们的项目集成（实际上非常简单！），但我担心颤振的总体设计与我们期望的用途不兼容

看起来理想情况下，flatter应该是应用程序的整个UI：在应用程序启动时创建并启动引擎，将引擎传递给flatterview，并将其作为应用程序的根视图。或者，Flatter似乎很乐意在应用程序中拥有整个流程，在应用程序中，您可以推送一个全屏
小部件
，它可以完成一些工作，可能推送/弹出更多屏幕，并最终将控制权返回到本机应用程序

但是，如果我有一个带有一些UI组件的本机屏幕，我希望还有一个显示一些其他数据（例如条形图）的颤振
小部件
，那么我似乎需要创建单独的模块或单独的
@pragma（vm:入口点）
在我的颤振项目中为我想要显示的每种类型的
小部件
（本例中为图形）提供函数

我的理解是，这些
小部件
中的每一个都需要自己的颤振引擎实例，它将正确的入口点/路径加载到
小部件
的
主
函数，然后调用
runApp（MyWidget）

下面是我的实际问题：


在视图控制器中嵌入颤振
小部件
s的最佳实践是什么
要在视图控制器中嵌入一组小部件，我需要为每个小部件创建单独的引擎隔离，这是否正确
这是使用颤振的正确方式吗？我知道引擎启动延迟有一些解决办法，比如预热和缓存，我可以用Flutter重新创建整个屏幕。但我想保留我们的本土工作，我可以和有一个附加的变化
引擎能否有效地用于单独的vm入口点？拥有一个可以按需使用的缓存引擎池（除了内存压力和线程限制之外）会“奇怪”吗

我仍在绞尽脑汁研究颤振，但到目前为止，它的功能给我留下了深刻的印象！如果我在这里遗漏了什么，请告诉我。
对于将来遇到这种情况的人，从2020年10月21日起，不鼓励在本地UIViewController中嵌入多个颤振小部件。以高性能的方式执行此操作需要更新以更好地跨引擎实例共享内存和线程