重度使用Flutter研发模式下的页面性能优化实践

重度使用Flutter研发模式下，页面性能优化可通过模块级混合、数据预取与FFI、资源预加载与缓存、服务端优化等策略实现，具体实践如下：

一、模块级混合——解决首页启动性能问题

淘宝特价版首页最初全部采用Flutter+DXFlutter实现，但发版时发现启动性能下降1秒。由于Flutter动态库加载和DXFlutter模板逻辑消耗性能，团队决定采用模块级混合方案：

方案选择：
Native实现推荐页：App启动时首页推荐页采用Native实现，避免Flutter动态库加载的延迟。
Flutter实现搜索分类tab：搜索业务的其他分类tab继续使用Flutter，保持研发模式一致性。
技术挑战与解决：
单引擎问题：FlutterBoost仅支持页面级混合，模块切换时需重新连接引擎导致空白或不可交互。通过FlutterWrapperVC基于FlutterBoost解决，根据模块可见性切换FlutterEngine和虚拟机，确保当前可见模块正常渲染。
单window布局问题：Flutter页面弹Native弹窗会导致布局错乱。通过强制修正Window大小解决，确保渲染窗口尺寸一致。
成果：
首页启动时间提升至少1秒，研发模式灵活，推荐页可复用淘宝等成熟App的优化经验。
后续通过DX模板打底、图标本地化、图片压缩等措施进一步优化启动性能。

二、数据预取与FFI——优化纯Flutter页面性能

以详情页为例，通过以下策略优化100多毫秒（Android vivo y67优化80～100ms，iOS iPhone6优化120~200ms）：

问题根源：
Flutter通过Bridge访问Native性能差，涉及线程切换、数据编解码（encode/decode）等，导致CPU紧张或数据量大时性能下降。
Engine与Native启动顺序不确定，可能导致消息丢失（如VC启动后Flutter Engine未准备好）。
优化策略：
Native侧发起数据预取：在路由构造Native VC/Activity时立即发起mtop请求，避免Flutter线程切换。
FFI机制传递数据：mtop返回数据通过FFI（Foreign Function Interface）直接供Flutter读取，减少Bridge调用。
LRU缓存策略：Native侧暂存数据，采用LRU策略避免资源泄漏（iOS避免使用NSCache，因其不遵循LRU规则）。
多级缓存与失效策略：
激进型：第二次请求直接使用缓存数据，待自然过期后刷新，适用于数据不常变场景。
正常型：第二次请求使用缓存但立即刷新数据，适用于数据变化不频繁场景。
保守型：第二次请求不使用缓存，强制请求最新数据，适用于强实时性场景。
成果：
详情页、我的、店铺等页面启动性能显著提升，iOS侧封装为独立SDK（pod LTPrefetch '1.0.1.19'）供复用。

三、其他优化实践

资源预加载与本地化：
首页dx模板预置：将模板文件打包到App中，减少网络请求。
Json与图片压缩：压缩数据体积，加快加载速度。
详情页借图：从首页缓存中复用图片，避免重复加载。
数据异步加载：
我的页面数据：用户登录时异步加载并缓存，通过缓存更新策略管理数据新鲜度。
服务端优化：
精简协议：减少传输数据量，降低网络延迟。
优化RT（Response Time）：提升服务端响应速度。

四、未来优化方向

热门标签