在已经存在的项目中使用flutter，一般都是和原生混合使用的。由于Flutter特性的限制，使用官方的方案是不能实现自由的原生页面和flutter页面混合的。
Flutter官方的思想是只有一个原生页面嵌套flutter页面，之后所有的页面切换都在flutter之内，即都是flutter页面。这在新的项目比较好实现，但是在已经存在的项目里面实现成本就非常高。而且有的界面flutter实现起来也没那么容易。
由于Flutter的isolate是隔离的，每个FlutterView对应一个isolate。ioslate占用的内存是比较大的。如果每个Flutter页面都新建一个FlutterView，就会对应新建一个ioslate，导致内存占用剧增。性能产生较大的影响。
Flutter与Android的交互
FlutterMain
FlutterMain是来初始化Flutter引擎的，初始化的过程：
- 查找并加载dart vm和资源文件
- 加载flutter native lib
- 等待渲染信号
- 初始化Flutter native
初始化完成之后,Flutter的vm已经启动，等待和FlutterJNI进行通信
FlutterView
FlutterView是一个标准的自定义View。
public class FlutterView extends SurfaceView implements BinaryMessenger, TextureRegistry
继承自SurfaceView，flutter的界面就是最终就是画在SurfaceView中的。
实现了BinaryMessenger来向下传递消息
TextureRegistry是通过SurfaceTexture来处理处理纹理，图像
关键属性
- DartExecutor： 配置，加载和执行dart code，通过channel通知调用。还负责监控ioslate的状态
- FlutterRenderer： 负责flutter UI的渲染和交互
- NavigationChannel： 导航，页面切换
- LifecycleChannel： 生命周期的同步
- PlatformChannel： 针对不同平台特性进行处理，如通知，传感器，持久存储等
- TextInputPlugin：文本输入插件，管理文本输入，输入方式等
- AndroidTouchProcessor：触摸事件的处理
- AndroidKeyProcessor: android按键的事件处理
- mFirstFrameListeners：第一帧渲染完成监控
- FlutterNativeView： 负责和Flutter native层交互
FlutterView虽然实现了BinaryMessenger，但并没有直接向Flutter发送消息，而是通过FlutterNativeView的x向下传递的
FlutterNativeView
FlutterNativeView其实并不是一个View
public class FlutterNativeView implements BinaryMessenger
只是实现了BinaryMessenger的一个普通类
属性
- DartExecutor 和flutterView共享，其实是在FlutterNativeView中初始化的
- FlutterPluginRegistry：负责与Android API的交互
- FlutterJNI： Flutter的JNI层，负责Android和Flutter之间的所有交互，通过JNI实现。例如Flutter UI的生成，渲染，状态同步，消息发送及响应传递。DartExecutor的部分功能也是通过flutter来实现的
FlutterNativeView的消息是通过DartExecutor继续向下层传递的，DartExecutor中一个DartMessenger对象，这个对象的初始化依赖了flutterJNI，所以最终的消息都是flutterJNI向flutter传递的
Android和flutter信息传递的过程是：
这个过程所有的对象都是直接初始化的，并相互依赖。
混合栈实现方案
要实现独立的原生和Flutter自由混合栈就必须避免创建多个ioslate，目前已有的实现方案:
共享FlutterView
整个App只有一个FlutterView，每个Flutter页面共用这个FlutterView。可以解决重复创建ioslate的问题。
实现过程：在启动下一个flutter页面的时候将FlutterView从当前页面移除，然后在下个flutter页面添加进去。
返回的时候逻辑一致。
需要特殊处理的地方：由于FlutterView从当前页面移走了，所以当前页面就变成了一个空白页面，跳转过程就会显示空白，为了解决这个问题，需要在移除FlutterView之前对当前的FlutterView截图，转成图片放在容器之中进行占位显示。
共享FlutterNativeView
与上面的方案类似，但是共享的是FlutterNativeView，每个页面都有独立的FlutterView。实现过程与共享FlutterView过程类似，但是不再需要截图了，因为FlutterView仍存在前个页面之中，只是不再刷新和交互。
同时也避免了单例FlutterView引起的内存没法被回收的问题。
但是这个方案需要处理FlutterNativeView和Flutter引擎直接的交互问题，因为FlutterNativeView是直接和Flutter进行通信的，再移除和添加的时候要保证状态同步.
还有就是两个页面共存的情况，如IOS上的侧滑返回，这时页面状态不一定结束。所以还需要截图实现。
多window共享ioslate
Flutter Framework层和Native Engine层的界面绘制交互都是通过两者的Window对象进行的，一个Ioslate只有一个ui.window单例对象。为了突破这个限制就需要在Ioslate中加入多window，使每个FlutterView对应一个独立的window. 同时还要考虑channel通信和内存回收的问题。要实现次方案需要对Flutter代码做大量的修改，工作量比较大。而且一但Flutter版本升级，又要进行适配，维护成本相当高
以上的方案都需要都flutter底层，FlutterView或FlutterNativeView进行一些hook操作才能实现。通过常规手段是无法完美实现的。这就涉及到对不同版本的Flutter进行兼容适配的问题。而且Flutter还在初期，版本升级快，代码，接口改动频繁，适配工作得持续进行，这会消耗不少的人力和精力。所以实现起来还是有一定的困难的。除非官方提供一套解决方案，否则就像android的插件化一样，很难做到完美和低成本。但是这样做不符合官方的初衷，最终就得看Flutter发展的成果了。
