1. “按在地上摩擦”这个结论我是怎么验证的看到这个标题你大概率会下意识觉得又是一波营销号在吹Flutter或者是在故意拉踩iOS和安卓原生开发。我承认这个标题确实带节奏但带节奏不等于没有依据。我把手里维护的两个双端原生App挑了一个功能模块又照网上流传的几种跑分方案重新搭了一套对照测试。流程很固定同一台iPhone和同一台Android旗舰同一套页面结构同一个测试用例分别用纯原生和Flutter重写跑冷启动时间、长列表滚动帧率、复杂动画流畅度、内存占用四组数据。测完的结论是Flutter并没有在所有环节都“按在地上摩擦”原生但在渲染稳定性和跨端一致体验这两个维度上它已经把原生开发逼到必须认真回应的位置。很多人口中的“跑分”只是甩一张帧率图真正有价值的其实是这几个背后的技术逻辑AOT编译怎么运作、Impeller渲染引擎解决了什么、为什么双端一致本身就是性能竞争力。把这三点搞清楚你才能看懂为什么Flutter近几个版本的性能表现能追平甚至反超原生。1.1 AOT编译不是“把代码翻译成机器码”那么简单先说最容易误解的一点。Flutter的Dart代码在release模式下会被AOT编译成纯机器码直接跑在CPU上不走任何解释器或虚拟机中间层。听起来简单但实际影响很大它在主流程里没有JIT编译开销没有运行时class解析整个Widget树的构建、布局、绘制都是机器码在执行。Debug模式下Flutter走的是JIT所以很多人用debug包测性能得出的结论是“Flutter也就那样卡得很”。这完全是测试方式错了。抓性能、测帧率、做对比必须打release包而且不能用模拟器模拟器里的渲染路径跟真机差距太大测出来的数字只能骗自己。我这次测试里纯Flutter release包在滚动场景的帧时间分布相当稳定丢帧集中在极少数瞬间而原生工程在同场景下偶尔出现掉帧原因通常不是原生本身慢而是某段业务逻辑直接跑在了主线程上。这说明一个事实Flutter的架构天然逼着你把重计算隔离到后台Isolate反而躲开了不少主线程卡顿的坑。1.2 Impeller到底改了什么为什么iOS和安卓的帧率被拉齐了Flutter早期版本用Skia做渲染iOS上有一个非常经典的问题首次遇到新的着色器时GPU要现场编译导致滚动过程中出现莫名其妙的卡顿业内叫“shader jank”。解决的办法通常是预热提前把Shader编译掉但总有没有覆盖到的分支。Impeller的出现就是冲着这个问题去的。它把着色器在构建阶段提前编译好并且在运行时尽量避免Shader编译这类不确定开销。你可以把它理解成两双鞋Skia这双是到比赛现场才临时给你调尺码而Impeller是一双出厂前就已经和你脚型完全贴合的鞋不管你跑几步都稳定。在最近的稳定版本里Impeller已经在iOS上默认启用Android上也逐步转正。我实测的Android设备上复杂列表和页面转场动画的帧时间比之前Skia时代平滑很多iOS上的shader jank基本销声匿迹。这就是为什么现在拿Flutter跟原生比渲染性能已经不像前几年那样一边倒被吊打了。1.3 双端一致本身就是一种性能优势原生开发永远面临一个隐性成本同样的业务逻辑iOS写一遍Android写一遍两边的列表优化思路、图片缓存策略、导航转场细节都不同。你会发现即使两边跑分都不低实际手感还是不一样。Flutter是同一套代码、同一个渲染引擎、同一个布局系统这意味着它在一台设备上表现的性能特性在另一台设备上几乎可以复现。性能问题一旦能稳定复现定位和修复就比“我这没问题你那边怎么卡了”这种跨端扯皮高效得多。这次测试里我的Flutter工程在iOS和Android上的帧数据曲线走势非常接近原生双端曲线的离散程度反而更大。所以“按在地上摩擦”这个说法我更愿意把它理解为Flutter用一套工程同时拉起两个平台并且把渲染表现拉到了跟原生同一水平线这才是它真正让原生开发感到压力的地方。接下来聊聊真正影响日常开发的通信机制因为跑分再好看跨端协作写不好照样翻车。2. 组件通信与原生协作跑分背后躲不过的硬功夫性能数据再漂亮日常开发也绕不开Flutter和原生互相调用的场景。结合我最近在社区里看到的高频问题“flutter组件通信怎么设计”“eventchannel怎么用”“安卓原生项目嵌入flutter页面怎么搞”基本是新人问得最多的三座大山。2.1 MethodChannel、EventChannel、BasicMessageChannel三张牌怎么打Flutter和原生通信主要通过三种Channel很多人一上来就只会用MethodChannel遇到连续回调就懵了。通道类型通信模型典型场景注意点MethodChannel一问一答获取token、调用原生能力、同步读状态适合低频调用频繁调用会有序列化开销EventChannel原生单向推流传感器数据、电量变化、定位流、音频电平记得在页面销毁时cancel订阅否则内存泄漏BasicMessageChannel双向消息传递两端需要持续互相通信的场景没有方法名分发需要自己约定消息结构举个例子我在一个地铁App里需要把门禁蓝牙的实时信号强度传给Dart端画曲线。用MethodChannel轮询也行但既浪费性能又容易造成通道阻塞。正确做法是EventChannel// Dart端 const EventChannel _rssiChannel EventChannel(com.example.app/rssi); void startListen() { _rssiChannel.receiveBroadcastStream().listen((event) { // event 是原生端推过来的信号强度 setState(() _rssi event); }); }// Android原生端 EventChannel(flutterEngine.dartExecutor.binaryMessenger, com.example.app/rssi) .setStreamHandler(object : EventChannel.StreamHandler { override fun onListen(arguments: Any?, events: EventChannel.EventSink?) { // 在这里把蓝牙信号回调塞给 events.success(value) } override fun onCancel(arguments: Any?) { // 在这里释放原生侧监听避免泄漏 } })MethodChannel则适合“我要一个结果”这种一次性调用比如读取设备型号、触发系统分享、获取推送token。我在项目里会把所有MethodChannel的方法名统一放在一个常量表里两端共用一份避免字符串散落在代码各处改一个方法名还要全局搜。2.2 原生项目里嵌入Flutter页面的正确姿势“安卓原生项目嵌入flutter页面”这个问题网上能搜到很多半吊子教程但最核心的一点是引擎生命周期。常见错误是每次打开Flutter页面都new一个FlutterEngine导致内存暴涨、加载卡顿。推荐做法是缓存引擎多个Flutter页面共用同一个引擎// 在Application初始化时创建一个引擎并缓存 FlutterEngine engine new FlutterEngine(context); engine.getDartExecutor().executeDartEntrypoint( DartExecutor.DartEntrypoint.createDefault() ); FlutterEngineCache.getInstance().put(default_engine, engine);// 需要展示Flutter页面时 FlutterFragment flutterFragment FlutterFragment .withCachedEngine(default_engine) .build(); getSupportFragmentManager() .beginTransaction() .add(R.id.container, flutterFragment) .commit();iOS端思路类似用FlutterEngine注册后交给FlutterViewController使用。注意withCachedEngine模式下Dart入口已经在引擎里跑起来了不能再调用runApp去创建新的WidgetsFlutterBinding否则会直接抛异常。另外提醒一点原生和Flutter页面共处一个宿主时导航关系要自己理清楚。Flutter页面的返回按钮不会自动通知原生关闭页面需要你在Dart端监听返回事件再通过MethodChannel通知原生侧finish或dismiss。这个细节漏了用户就会遇到“点返回没反应”的诡异问题。2.3 通信里的线程与生命周期坑Channel调用默认跑在平台主线程如果你在原生侧接到调用后执行了重活比如加解密、大文件读取iOS主线程和Android主线程都会被卡住。正确做法是原生侧先把重活丢到自己的子线程处理完再回到主线程回传结果。我早期踩过一个坑自定义的BasicMessageChannel里传输了一个很大的JSON结构每次通信都触发整包序列化聊天页面数据一多就开始掉帧。后来改成只传增量数据必要字段单独拆成轻量Map帧率立刻回来。通信设计要克制通道里传的内容越少性能越稳定。3. 三个经典翻车现场状态丢失、微任务队列和掉帧排查跑分解决的是“行不行”的问题真正的日常是“稳不稳”。最近社区里高频出现的“flutter navigator切换页面后会丢失状态吗”“flutter future的then回调是放入微任务队列吗”就是非常典型的“性能好但用不好照样难受”的场景。3.1 页面切走再回来状态为什么丢了首先要区分两种情况。如果你用的是Navigator.push进入新页面后旧页面还留在路由栈里理论上状态不会丢。但如果你做的是Tab切换或者用页面索引重建Widget子树那旧页面可能被彻底销毁重新回来时状态自然清零。我在一个资讯App里遇到列表滚到第80条切到另一个Tab再切回来列表直接从顶部开始。排查下来发现根因是Tab切换时用了条件渲染把列表对应的Widget子树整个销毁了而不是用IndexedStack保活。解决方案有两个层级页面级保活用IndexedStack包住各Tab内容所有Tab的State在切换时都保留。控件级保活列表项里的图片加载、滚动位置等状态用AutomaticKeepAliveClientMixin配合KeepAlive通知机制维持。另外文本输入框的草稿滚动位置这类带“存储型”状态用PageStorageKey来保存路由返回时能自动恢复。ListView.builder( key: PageStorageKeyString(home_feed_list), itemBuilder: ... )这已经是我项目里的默认写法就算业务需求改了也不怕页面重建导致状态归零。3.2 Future.then里的回调究竟进了哪个队列这个问题看起来学术实际上直接影响你对界面卡顿的判断。Dart的事件循环分微任务队列和事件队列Future.then注册的回调是微任务会在当前同步代码执行完后立刻执行而Future(() {...})这种构造函数里的代码属于事件队列任务会排到下一轮事件循环。看我随手写的一段验证代码void main() { scheduleMicrotask(() print(A直接调度微任务)); Future(() print(B事件队列任务)); Future.value().then((_) print(CFuture.value().then)); print(D同步代码); }执行顺序是D、A、C、B。A和C都是微任务按调度顺序执行B被放到了事件队列所以最后才打印。这跟帧率有什么关系如果你在build方法里调用了大量同步Future链每个then都会在一个微任务里跑而微任务阶段在渲染下一帧之前就要全部执行完。微任务太多、太重帧就会晚一拍表现为“点击没反应半秒然后一次性弹出好几个状态”。长任务不要塞在Future.then里优先用Isolate.run或compute做后台计算再通过Future把结果送回主Isolate。3.3 一次掉帧问题的完整排查链路说一个真实的线上排查。某页面A push到页面BB页面里触发了一个原生相册选择选完照片回到B再返回AA页面整个重建了列表数据重新加载图片闪白用户体感就是“页面跳转很卡”。我当时的排查链路是先在A页面打印生命周期确认页面是否重建。结果显示A页面的State确实被重新创建了。检查路由栈发现A页面并没有被移除说明问题不是路由问题而是A页面在某种条件下被释放了。进一步查看A页面的结构发现它被包在了一个根据权限动态显示的父组件里权限状态在B页面变化后A的父组件重建连带把A的子树放弃了。这就是典型的“你没改路由但改了一条会影响路由生命周期的数据链”。修复方式是把“根据权限决定是否显示”的判断放到路由入口层而不是在已有页面的父级做动态分支同时给列表区域加AutomaticKeepAliveClientMixin即使树重建也能恢复滚动位置。排查完再回头看问题的本质不是Flutter性能而是组件生命周期设计没想清楚。这类机制上的坑比跑分更能决定一个项目到底能不能稳定上线。4. 换不换Flutter别只盯着跑分看Flutter跑分再强也改变不了一个现实有些业务场景天然跟“原生化”绑定得很死硬切Flutter会付出额外成本。我在评估迁移时会从下面四个角度算总账。4.1 重原生依赖场景的成本评估音视频采集、蓝牙外设、系统级通知横幅、iOS分屏适配、Android电视盒子适配、回声消除这类功能Flutter生态里虽然都有插件但要么是在原生代码外面套了一层壳要么只覆盖了80%的厂商差异。我做过一个实时音视频项目回声消除、设备管理、码率自适应全依赖原生SDKFlutter侧只做UI呈现。这套方案可行但有一个前提团队里必须有能随时上手原生代码的工程师而且得把所有原生能力都封装成干净的Channel接口不然项目会变成两坨代码互相拉扯。如果你评估下来核心功能有三分之一以上必须写原生代码那Flutter带来的“一套代码双端跑”红利就被稀释了这时候硬切Flutter属于给自己挖坑。4.2 三种迁移路线我建议多数团队走第二条现在从原生往Flutter迁移基本是三条路新项目直接用Flutter老项目彻底不管。适合从0到1的产品没有历史包袱。老项目保留新业务模块用Flutter通过原生容器嵌入。适合已有千万级用户App的渐进式改造。老项目推翻重写为纯Flutter。除非产品逻辑极其简单或者原代码已经烂到不可维护否则不推荐。我自己一直推荐路线二因为它在控制风险的同时能让团队慢慢积累Flutter经验老业务不受影响。我踩过最多的坑反而不在技术而在团队心态原生工程师总觉得“这是在抢我饭碗”Flutter工程师又容易“觉得原生侧拖后腿”。要先把协作边界定清楚才能谈技术迁移。4.3 包体积、CI、版本管理这笔账Flutter包体积确实比原生重一些但也没到不可接受。Android侧打Release用App Bundle加ab拆分功能就可以了平时用flutter build appbundle --release --split-per-abi可以让不同ABI的设备只下载对应产物而不是一股脑全塞进去。iOS侧同理App Thinning能在分发时去掉多余架构用户实际下载体积并没那么可怕。我见过不少项目因为包体积问题纠结半天其实打开App Store的下载页看一眼大部分用户根本感知不到那几兆的差异。CI这边要把流程固定好我现在的流水线是flutter pub get flutter analyze flutter test flutter build appbundle --release --split-per-abi flutter build ipa --release版本管理上强烈建议用FVM锁Flutter SDK版本。团队里有人local环境升到新版本有人还卡在旧版本编译出来行为不一样排查起来特别费劲。把版本固定住才能保证“我这能跑”不是玄学。5. 关于跑分我的最终态度关键不在输赢而在你怎么用它聊到这里我想把标题再拎出来说一遍。“别再跪舔原生开发”和“Flutter把iOS和安卓按在地上摩擦”这两句话单独拎出来都不够客观。但放在一起却能传递一个真实信号原生开发确实不再是唯一的高性能答案。我现在的工程默认选型是通用业务层的UI和逻辑都交给Flutter系统能力调用、特色原生SDK、特殊交互体验这些我仍然保留原生通道。这样做的好处是Flutter帮我省掉了一大块重复的界面开发和双端联调时间原生的能力又能在我需要的时候随时顶上来。它俩不是谁把谁按在地上摩擦的对头而是各有分工。我经常用一条命令来辨别应用真实性能flutter run --profileprofile模式下Flutter会保持release级别的编译优化同时保留性能统计。跑起来之后点击右下角的时间线按钮所有帧的耗时分布一眼就能看出来。哪一帧超了16ms是哪段代码拖慢的直接定位。如果你想真正认识Flutter的性能别光看别人发的跑分图自己用profile模式跑两轮比什么结论都靠谱。至于说要不要担心“原生开发被取代”我的理解是平台底层能力永远有存在的价值但作为开发者选择更高效的工具并不丢人。跑分赢了、输了都不影响一个事实——你手上能用的牌变多了。把每张牌用在合适的地方才是这件事最实在的收获。