Flutter和原生APP的性能对比
前言
自从今年google IO大会推出flutter跨平台开发框架以来,flutter在各个技术论坛里被吵得如日中天。flutter团队直言flutter可以帮助开发者轻松实现恒定60fps的性能体验。
我们知道flutter跨平台的原理是采用dart语言预编译的方式直接编译出各个平台的原生代码,而不需要类似RN用JavaScript桥接器执行原生代码。那么这样做的性能究竟如何呢?是否能达到和原生一样的流畅度,是否如官方所说达到恒定60fps的性能体验?今天我们就以android为例从几个不同的维度来实际测试一下!
安装包对比
我们分别用 flutter 和 android 原生来编写一个ui效果一模一样的 apk,然后打出 release 版本的安装包,为了保证测试结果的可靠性,我们不引入任何第三方库,只用框架提供的控件做一些简单ui,这里附上demo源码:flutter demo,android demo。好了,我们打出各自的release版本apk,然后使用AndroidStudio自带的APK Analyzer进行分析,如下图:
android原生apk
flutter apk
- 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 条数据。下面看图:
android原生debug性能检测图
flutter profile性能检测图
- 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 检测到这两个版本的进程,进行性能测试。下面看图:
android原生性能检测图
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文件,
android原生trance文件
flutter trance文件
trance 文件几乎一模一样,我一度都怀疑是自己弄错了,然后又仔细确认了一下没出错才放心,可以得出结论,flutter 版的启动流程跟原生是一模一样的。
flutter 60帧/秒的刷新率测试
Flutter 官方指出其旨在提供 60 帧/秒的刷新率,60 fps 意味着大约平均每 16 ms 渲染一帧。我们知道,当 UI 不能平滑的渲染时就会出现掉帧。举个例子,假如有一帧执行的东西太多,花费了 160 ms 的时间去渲染,这段期间就会产生丢帧现象,从而就会看到动画出现了明显的抖动。flutter release 版本是没法去测试渲染指数的,这里我们还是以 profile 模式运行,然后在用官方给我们提供的 Flutter Inspector 工具去展示 fps 变化。下面看 Gif 图:
我的手机是小米Note 2,高通骁龙821处理器 4G 内存,性能大概属于 Anroid 阵营中上等。我打开 app 后先是平稳的滑动 listview,然后又快速的滑动,由图可看出,刷新率起初恒定在 60fps,当我快速滑动的时候,刷新率大约保持在58~59 之间,所以 flutter 官方所说 fps 恒定在 60fps 还是可信的。
总结
通过以上的分析,我们可以很明确的得出结论,android 原生在内存、CPU 资源占用方面要低于 flutter,并且安装包的体积也要小于 flutter,所以,不考虑其他因素,单纯从性能角度来说,android 原生肯定是要优于 flutter 的。但 flutter 也有它的优点,比如跨平台的开发、毫秒级的热重载等等,另外跨端开发也逐渐的流行起来,所以,我们在学好android原生的基础上,对跨端开发也要抱有积极的心态。
参考
flutter中文网:https://flutterchina.club
flutter官网:https://flutter.io
喜欢小编的可以点个赞关注小编哦,小编每天都会给大家分享文章。
我自己是一名从事了多年的前端老程序员,小编为大家准备了新出的前端编程学习资料,免费分享给大家!
如果你也想学习前端,那么帮忙转发一下然后再关注小编后私信【1】可以得到我整理的这些前端资料了(私信方法:点击我头像进我主页有个上面有个私信按钮)