Flutter & Native 资源共享方案

这里需要客观指出：如果是一个纯 Flutter APP，原生方案是完善，够用的。但是如果从混合 APP 的角度来说，有如下两个缺陷：
1)无法复用 Native 图片加载能力
毫无疑问，原生的图片方案是完全独立的图片加载方案。对于一个混合 APP 来说，原生方案和 Native 的图片框架相互独立，能力无法复用。例如 CDN 裁剪 & 压缩等能力需要重复建设。特别是 Native一些独特的图片解码能力，Flutter 就很难使用。这会造成 APP 范围内的图片格式的支持不统一。
2)内存性能不足
从整个 APP 的视角来说，采用原生图片方案的情况下，其实我们维护了两个大的缓存池：一个是 Native 的图片缓存，一个是 Flutter 侧的图片缓存。两个缓存无法互通，这无疑是一个巨大的浪费。特别是对内存的峰值内存性能产生了非常大的压力。

1. channel bytes流传输方式
2. 文件路径方式
3. 内存指针共享方式
4. bitmap内存指针共享
5. 修改flutter engine直接读取native内置其他assets资源方式

外接纹理同层渲染

《Flutter技术解析》：p70

外接纹理：

最后存在一个 TextureLayer 节点，是 Flutter 的 Texture 控件，当它存在时表明这个控件上显示的数据需要由 Native 提供。