接上篇：https://developer.aliyun.com/article/1225938?spm=a2c6h.13148508.setting.28.595d4f0eudDbz0
六、 Flutter代码Trim机制的坑
我们都知道Flutter中的dart代码在编译过程中，会对没用调用到的代码进行裁剪。这样做的好处是尽可能减少产物的大小。以闲鱼场景为例关闭代码Trim，闲鱼的包大小会增加额外的8M。但是实际开发过程中的一个不起眼的操作，竟然会打入你可能意料之外的代码。
上述代码中dependencyCall所在代码是会在编译期间被trim掉的（如果没有其他任何引用的话）。但是如果代码改成了如下方案，情况就不同了。
由于在编译期间，编译器无法100%确认needSomething变量的值。所以就会将dependencyCall所在代码打入最终的包中。包大小就“意外”变大了。
一个非常小的改动，即便最后的值都是false，看起来是逻辑等价。但是“不经意间”却影响了最终打入的代码。
七、 Flutter为什么引入EngineGroup
众所周知，Flutter最早是面向APP级别进行设计的。但是实际应用过程中，更多的场景是将Flutter纳入现有的APP之中，这时Flutter多实例就是一个无法回避的问题。闲鱼团队之前的解决方案是FlutterBoost，目前也已经开源。本质上是多个页面复用一个Flutter Engine。
Flutter 2.0版本中，官方对Flutter多实例场景进行了优化。据官方数据，增加一个新的Flutter实例，只会增加约180K的内存占用。这无疑对多实例场景是一个重大利好。官方数据如下：
但是这个方案真的那么完美么？目前的EngineGroup方案也有他的一些不足：
• 每个Engine都有自己的Isolate，彼此之间数据独立无法复用。同时不同页面之间的数据通信的成本也大幅提升。
• 每个Engine都有自己的桥通道。需要单独注册和管理。
• 多Engine即便已经大幅优化，考虑到更多的Isolate和数据隔离。真实页面性能成本相比单Engine版本会更高。
大家可以根据自己业务的实际情况选择使用。
引用
【1】Flutter新一代图形渲染器Impeller
【2】https://github.com/flutter/flutter/wiki/Impeller
【3】https://docs.flutter.dev/development/tools/sdk/release-notes/release-notes-3.3.0
【4】FlutterBoost：https://github.com/alibaba/flutter_boost
