Android中早期版本Platformview的实现基于Virtual Display。VirtualDisplay方案的原理是，先将Native View绘制到虚显，然后Flutter通过从虚显输出中获取纹理并将其与自己内部的widget树举行合成，末了作为Flutter在 Android 上更大的纹理输出的一部分举行渲染。该方案除了存在性能问题外，更重要的是其作为假造表现屏， 只是办理了表现问题，对于事故输入，native组件无法直接接受到用户点击事故， 有很多难以办理的功能性问题，比方，事故/文本输入/可访问性。
iOS中对Platformview的支持重要是一种被称作Hybrid Composition的方案。其根本原理是，UI渲染由Native驱动，在Native组件外层会包裹一层FlutterTouchInterceptingView ， 用于吸取处理点击事故， 然后添加到Flutterview上。 然后在native组件之上再增加一层FlutterOverlayView， 用来表现在其之上的Flutter组件以办理组件的遮挡问题。该方案优点是可以完备捕获Platformview上的点击、滑动等事故，但由于每添加一个Platformview，额外会在其上新增一个全屏的FlutterOverlayView，会带来明显的额外内存斲丧。别的，为了合成Flutter和Platformview的图层，Quartz还可能创建额外buffer空间。所以， 如果确信Platformview上不会有其他的Flutter图层，我们可以自动将FlutterOverlayView释放以节省内存。
Flutter 3.0版本后，Android也开始支持与iOS雷同的Hybird Composition方案，即TextureLayer方案。其原理是，Native侧创建一个 PlatformViewWrapper 对象，其负责拦截处理Nativeview的用户点击事故。 将NativeView渲染到FlutterView上，采用的是外接纹理方案。即在Native侧通过调用FlutterEnginge的接口创建一个Texture，天生一个 TextureId，并将其通报给Flutter侧；在Flutter 侧通过textureId将其包装成一个Texture Widget组件，native组件的纹理被映射到Flutter侧的Texture组件上。具体做法是，重写PlatformViewWrapper的draw方法，通过surface.lockHardwareCanvas()获得canvas画板，然后 将native组件直接绘制到该画板上，换言之，上述过程将Native组件的canvas替换为TextureWidget的对应的canvas，进而实现Native组件在Flutter的表现。
该方案与iOS方案非常接近，Native组件是真实存在于视图层级中的，而且由于渲染过程制止了数据在不同情况间传输和拷贝，理论上性能更好。区别是其不需要创建额外的overlayview，Platformview与Flutter多图层叠加的效果渲染是通过纹理的叠加实现的。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 | 
