在移动开发领域，Flutter与Native的混合开发有众多值得探讨之处。一方面Dart在Flutter的使用有其独特优势，另一方面二者混合存在不少麻烦事。这些内容对于开发者来说既充满挑战，也有解决问题后的成就感。
一、Dart引入及编译模式优势
Dart被Flutter团队引入是经过深思熟虑的。它具有AOT和JIT两种模式。线上采用AOT方式编译为机器码，大大提升了运行效率。例如在一些大型的Flutter应用中，高效的编译能让APP启动和运行更加流畅。这种机制的存在让Flutter在性能上有了可靠的保证，也为其能在众多开发框架中有一席之地奠定了基础。Dart的这一特性在解码复杂页面逻辑或者处理大量数据交互时，优势就能更显著地体现出来。
在实际项目开发中，这两种编译模式也给开发者更多的选择空间。在开发初期的测试环节，可以利用JIT模式快速编译和测试代码。而到了项目上线阶段，切换为AOT模式保证最终的运行效率。
二、Flutter与Native工程混合的研发问题
Flutter和Native混合开发面临着研发上的难题。首先，现有的Native工程往往不能与Flutter默认规范相匹配。在很多场景下，开发人员要去修改打包脚本。就拿某个电商APP来说，它原来大量的iOS和Android原生代码工程，要集成Flutter的时候就必须得调整打包脚本才能进行后续开发。还有的时候甚至要对Flutter的打包工具进行修改。这对开发人员来说既需要掌握原有Native的开发知识体系，又得熟悉Flutter相关的打包工具等知识结构，增加了开发的复杂性。
另外，开发人员如何在现有的Native工程中开展Flutter开发也是问题。纯Native开发同学，不想引入Flutter工程时，要保证Flutter能以产物的方式集成到Native中运行。而Flutter的开发同学则要引入Submodule。这样的开发模式就要求开发人员在不同的开发思维和开发流程中切换，稍不注意就容易出错。
三、Hybrid栈和实例剥离管理
在Flutter与Native混合开发时，栈管理和实例剥离是不容忽视的。是选择Hybrid栈管理，还是在Flutter管理，这是个要权衡的问题。而实例剥离也是很复杂的一块内容。比如移动单例本身就很难处理，在闲鱼的开发过程中采用了把单例剥离出来的方式，然后在上面包裹出多个实例。这种做法有一定的好处。像页面复用的时候，复用这些实例就不会每次都重新获取新实例，从而提高效率。从加载速度来看，这样操作后加载速度明显加快了，这对于重视性能的平台如闲鱼来说是至关重要的。
四、Native功能在Flutter中的复用
在实际开发中，Native中的一些已优化的功能希望能复用到Flutter页面中。像视频播放器，在Native中已经做了很多优化工作。在将其应用到Flutter页面时，就有了明确的分工。Flutter侧负责展示播放器的UI，并且要接收对播放器做的各种控制交互。而Native侧则负责视频的实际渲染，并且通过TextureLayer展示到Flutter侧。通过这样的分工合作，可以把Native已有的优势在Flutter页面中尽可能地发挥出来，避免重复开发。
五、Flutter开发中Dart反射和数据解析
Flutter不支持Dart的反射这一点，在开发中带来不少困扰。当开发Flutter页面，还需要解析服务端返回的数据并且生成Flutter对象的时候，开发人员就特别不适应。因为不能通过反射机制快速地对数据进行处理，往往需要进行大量的硬编码。在一些涉及数据交互频繁的页面，例如新闻资讯类的Flutter应用页面，每次从服务端获取数据来展示的时候，硬编码工作量就很大，既增加了开发成本，也增加了后续维护难度。
六、Flutter默认图片缓存策略及优化
闲鱼等平台页面中存在大量图片。Flutter默认的图片缓存策略相对比较简单。按照截止到演讲时的情况，默认图片缓存策略是按照图片数量，以1000为上限，以LRU的方式置换。这在面对海量图片时显然不够完善。不过官方正在进行优化，提出了按照整个空间大小来做缓存策略的第二种方案。相关的具体内容可以去关注图中的链接内容。不同的图片缓存策略直接影响着APP对图片资源的管理效率，对于图片资源较多的APP而言意义非凡。
你在Flutter与Native混合开发中有没有遇到过特别棘手的问题？欢迎在评论区留言分享，也请点赞和转发这篇文章。
