我们知道flutter跨平台的原理是采用dart语言预编译的方式直接编译出各个平台的原生代码，而不需要类似RN用JavaScript桥接器执行原生代码。那么这样做的性能究竟如何呢？是否能达到和原生一样的流畅度，是否如官方所说达到恒定60fps的性能体验？今天我们就以android为例从几个不同的维度来实际测试一下！
我们分别用 flutter 和 android 原生来编写一个ui效果一模一样的 apk，然后打出 release 版本的安装包，为了保证测试结果的可靠性，我们不引入任何第三方库，只用框架提供的控件做一些简单ui，这里附上demo源码：flutter demo，android demo。好了，我们打出各自的release版本apk，然后使用AndroidStudio自带的APK Analyzer进行分析，如下图：
apk 大小 可以明确的看出来，原生的安装包要比 flutter 安装包小约 6M 左右。
classes.dex 大小 看 dex 大小你会不会很奇怪，原生的 classes.dex 竟然比 flutter
版的dex大六百多KB，这是因为原生的 dex 里引入了 support 库和各种基础控件(ImageView TextView等等)，而
flutter 的 dex 里面没有support库，也没有原生控件，实际上 flutter 实现了一套自己的控件，包括 Material
Design 和 Cupertino（iOS风格的widget）。
res 对比 可以看到原生的资源文件要比 flutter 大约200多k，而我们项目中没有编写任何资源文件，所以这些资源文件大多是
support 包和 sdk 自带的。
lib 库 大家可能会发现，我们的 flutter 版 app 多出了一个 lib 库，打开里边是一个 libflutter.so，因为
Flutter 引擎是用 C、C++ 来编写的，在 android 上会使用 ndk 编译，在 iOS 上使用 LLVM
编译，而我们自己写的 dart 代码会通过 AOT 编译成各个平台的本地代码。
通过对比我们了解到，flutter 版的 apk 大小会比 android 原生的多出约 6M 左右，其中核心引擎大约 3.2MB，框架+应用程序代码大约是 1.25MB，必需的 Java 代码 .dex 将近 60k，而 assets 文件里还约有 2.1MB 的 ICU 数据等，单纯从安装包上来说，原生是要优于 flutter 的。
为了测试覆盖更加充分，我们分别在 debug 和 release 模式上进行性能测试。而据官方介绍 flutter 的 debug 模式在性能上是要略于 release 版的，所以他们提供了 profile 模式供我们测试，profile 模式编译和启动 Flutter 应用程序几乎与 release 模式完全相同。
我们先看 android 原生的 debug 和 flutter 的 proflle 模式性能对比,这里我们用 Android Profiler 进行性能指标检测，demo 只有一个界面，用 ListView 展示 10000 条数据。下面看图：
CPU资源占用 首先，我们看 CPU 的占用，在启动的时候，android 原生对 cpu 的占用峰值在26.8%，而且几乎是比较平稳的变化，而 flutter 对 cpu 的占用峰值达到了 35.5%，是一种很陡峭的形态，然后在大约十六七秒的时候，分别滑动了 listview， android 原生对 cpu 资源的占用峰值约 23%，而flutter约 22.5%。从图中也可以看得出，flutter 对 cpu 资源的占用是突然之间占用很高，而 android则相对平稳一些。
内存占用 内存占用表现上两者都很相似，android 原生在启动时占用内存最高达到 58.1MB，而 flutter 则为72MB，在滑动 listview 的时候，两者表现也很一致，都没有突然出现很高的内存占用。达到稳定状态后，android原生内存占用稳定在35MB，而 flutter 为 52.5MB。
debug 和profile 模式的性能测试如果你还不放心的话，那么下面我分别打包出用 flutter 和 android 原生构建出的release apk，然后将手机开启ROOT权限，以便可以用 Android Profiler 检测到这两个版本的进程，进行性能测试。下面看图：
flutter 性能检测图
我在打开 app 并锁定当前进程后，分别在大约第 10 秒的时候，用手指轻轻滑动了 ListView，下面我们分析下两种方式的资源占用情况。
CPU资源占用 首先，我们看 CPU 的占用，正常情况下，两者都没有占用多少 CPU 资源，当我滑动 listview 的时候，原生的大约会占用最高 7.7% 的 CPU 资源，而 flutter 版的则占用高一些，峰值大概在 18.8%。
内存占用 原生的app内存占用维持在 12M 左右，而 flutter 版的则维持在 21M 左右，原生应用比 flutter 大约低了 9M 的内存占用。
从上边两种模式的性能检测结果分析我们可以总结出，flutter 应用在 CPU 和内存的资源占用上会比原生方式多一些，所以单纯的从性能上来说，android 原生是肯定要优于 flutter 的，但是从用户体验上来说，两者的滑动同样顺畅无比，几乎感觉不到差别。
启动是我们衡量一个应用程序性能的重要指标，下面我先通过一个 gif 来演示下 android 版和 flutter 版启动 app 的体验：
看得出，android 版和 flutter 版从启动体验上来说几乎不相上下。这里我大胆做一个猜测，flutter app的启动机制和原生还是一模一样，所以调用启动 Application 也是创建 ActivityThread 然后最终执行 Application 的 onCreate 方法，所以从启动上来说相差无几。下面我贴出 android 原生和 flutter 版的启动trance文件，
trance 文件几乎一模一样，我一度都怀疑是自己弄错了，然后又仔细确认了一下没出错才放心，可以得出结论，flutter 版的启动流程跟原生是一模一样的。
Flutter 官方指出其旨在提供 60 帧/秒的刷新率，60 fps 意味着大约平均每 16 ms 渲染一帧。我们知道，当 UI 不能平滑的渲染时就会出现掉帧。举个例子，假如有一帧执行的东西太多，花费了 160 ms 的时间去渲染，这段期间就会产生丢帧现象，从而就会看到动画出现了明显的抖动。flutter release 版本是没法去测试渲染指数的，这里我们还是以 profile 模式运行，然后在用官方给我们提供的 Flutter Inspector 工具去展示 fps 变化。下面看图：
通过以上的分析，我们可以很明确的得出结论，android 原生在内存、CPU 资源占用方面要低于 flutter，并且安装包的体积也要小于 flutter，所以，不考虑其他因素，单纯从性能角度来说，android 原生肯定是要优于 flutter 的。但 flutter 也有它的优点，比如跨平台的开发、毫秒级的热重载等等，另外跨端开发也逐渐的流行起来，所以，我们在学好android原生的基础上，对跨端开发也要抱有积极的心态。
