阅读 1449

iOS:原生应用 VS Flutter VS GICXMLLayout 比较

最近,有些朋友问我,到底GICXMLLayout的性能如何?因此有了本篇文章。另外,考虑到现在Flutter也比较火,为了不藏私,因此也加入对Flutter的比较。因此这里详细的对三种开发方式进行横向比较。

注1:flutter采用的是最新的1.0.0版本。

注2:flutter的测试都在profile模式下测试,性能接近release

文中用到的测试代码可以直接从这里点击下载

在做比较之前,先确定一个比较的样例。这里以如下UI内容为例。

这里面给出了一个显示可变高度的列表的案例,这样的案例比较具有通用性,有图片的加载、有高度不固定文本的显示、有高度不固定CellHeight的计算等等。下面针对这样的案例,从各种角度来比较分析在不同的开发方式下的比较。

1. 启动时间

测试平台是iPhoneX,iOS 12.0,因为做的是横向比较,因此不在多设备上进行测试,只在iPhoneX上进行测试分析。

启动时间的比较由两个方面组成。

  1. main之前

    main函数之前的时间表示的是iOS对动态链接库的加载、系统加载等所耗时间。这个时间通过添加DYLD_PRINT_STATISTICS宏来获得。

  2. main函数之后

    main函数之后的时间通过main函数和applicationDidBecomeActive:方法的时间差来获得。

另外,为了公平起见,测试方式采用的profile的方式测试。

主要是考虑到Flutterreleasedebug两种模式下的性能差异太大,而releaseprofile两种模式很接近,因此采用profile的方式

另外,测试加载的数据为11条,时间单位为(秒)

原生

main函数之前的时间范例

Total pre-main time: 205.82 milliseconds (100.0%)
         dylib loading time: 191.47 milliseconds (93.0%)
        rebase/binding time:   0.29 milliseconds (0.1%)
            ObjC setup time:   6.29 milliseconds (3.0%)
           initializer time:   7.76 milliseconds (3.7%)
           slowest intializers :
             libSystem.B.dylib :   4.67 milliseconds (2.2%)
复制代码
main之前 mian之后 总计
0.201 0.099 0.3
0.206 0.086 0.292
0.210 0.092 0.302
0.197 0.089 0.286
0.195 0.098 0.293
平均 0.294

以上数据是原生APP的启动时间,平均0.294秒

GICXMLLayout

main函数之前的时间范例

Total pre-main time: 342.71 milliseconds (100.0%)
         dylib loading time: 291.83 milliseconds (85.1%)
        rebase/binding time:   1.55 milliseconds (0.4%)
            ObjC setup time:  15
.76 milliseconds (4.5%)
           initializer time:  33.48 milliseconds (9.7%)
           slowest intializers :
             libSystem.B.dylib :   7.05 milliseconds (2.0%)
               AsyncDisplayKit :  42.27 milliseconds (12.3%)
复制代码
main之前 mian之后 总计
0.318 0.066 0.384
0.342 0.069 0.411
0.338 0.066 0.404
0.337 0.067 0.404
0.330 0.064 0.394
平均 0.399

Flutter

main函数之前的执行时间范例

Total pre-main time: 206.08 milliseconds (100.0%)
         dylib loading time: 189.66 milliseconds (92.0%)
        rebase/binding time:   0.82 milliseconds (0.3%)
            ObjC setup time:   7.52 milliseconds (3.6%)
           initializer time:   8.06 milliseconds (3.9%)
           slowest intializers :
             libSystem.B.dylib :   4.61 milliseconds (2.2%)
复制代码
main之前 mian之后 总计
0.218 0.115 0.333
0.203 0.105 0.308
0.209 0.113 0.322
0.211 0.110 0.321
0.203 0.107 0.310
平均 0.319

分析

通过以上三种开发方式的数据分析可以看出,

  1. 启动时间最短的是原生应用,最长的是GIC的应用。
  2. GIC之所以最长,是因为在main函数之前加载了太多的第三方库,但是可以看到main函数之后的执行时间是最短的。
  3. flutterrelease模式下的main函数之前的加载时间跟原生应用可以说相差无几,从这里可以看出,大厂就是大厂,技术能力不得不服。
  4. fluttermain函数之后的执行时间是三种方式中是最长的。

    flutter的引擎、UI、GPU相关的操作都有专门的线程负责,区别于iOS中的UI线程。而fluttermain函数之后的执行时间却是最长的,那么说明,flutter有些初始化操作可能是在iOS的UI线程中执行的。考虑到Flutterapp加载了一个Flutter.framework,并且包含了对iOS平台调用的代码(FlutterAppDelegateFlutterViewController等),因此初步判断是这个库中的代码的执行结果。

  5. GICmain之后执行时间最短应该说是情理之中,因为GIC的列表布局渲染等都在非UI线程执行的(得益于Texture)。也就是说,GIC在UI线程上做的事情是在三种开发方式中最少的。

从这里也可以看出,GIC的问题在于对第三方库的依赖太多,后续考虑如何减少对第三方库的依赖,事实上目前已经在做对RAC库的剥离工作,相信剥离后会进一步的提升加载速度。

原生应用在加载列表的时候采用的是最粗暴的方法,没有任何的优化,没有height缓存,没有在后台线程做height计算等等,因此原生应用在启动时间方面也有进一步的优化空间。但是排名不会发生变化,最多就是mian函数后的执行时间会缩短,但不会短过GIC

2. 帧率CPUGPU

这三项数据的测试在iPhoneX上看不出明显的不同,因此这里就以iphone 6的测试数据为准。

测试方式:不停的滑动列表

原生

GICXMLLayout

flutter

分析

  1. 帧率:

    在帧率方面,三种方式都差不多,基本上都能维持满帧。

  2. CPU:

    CPU占用率从高到低排名为:flutter(平均14%) > 原生(平均10%) > GIC(平均7%)。

  3. GPU:

    GPU占用率从高到低排名为:flutter(平均22%) > 原生(平均16%) > GIC(平均12%)。跟CPU的结果差不多,flutter在滑动的时候GPU耗费也高达22%,比最低的GIC差不多高了一倍。

这一轮的测试中,flutter基本上算是完败了,不是百分之多少的差距,而是成倍的差距。

GIC在UI层是基于Textrue开发的,因此继承了Textrue的所有优点。在这一轮测试中可以说完胜。

3. 内存占用

测试方式:页面加载完成后滑动列表,然后静置一段时间 测试设备:iphone6

原生

GICXMLLayout

flutter

flutter依然是以profile模式测试。

分析

由上面三张图看出,flutter(40MB)占用的内存最多,GIC(13.7MB)次之,原生(9MB)应用占用最少。

  1. 可以看出flutter占用了40MB,比原生应用多了将近3倍都不止。
  2. GIC占用了13.7MB

    由于GIC在基于Texuture封装的时候把布局元素也作为UI元素封装了,因此导致实际的内存占用稍微高了点。

另外,GIC在使用的过程中创建了JSContext,你可以理解为JS引擎。而在实际使用过程中,JS并没有占用太多的内存。当然,这里面涉及到JS功能也比较少,因此也无法直接说JS占用内存地。

4. 包大小。

为了公平起见,这里的测试基于release模式下测试。另外,在打开和关闭bitcode两种模式下,包的大小差距会很大。这里分别给出。

另外,测试应用已经踢除了静态图片资源。

原生

  1. 打开bitcode:1.1MB
  2. 关闭bitcode:269KB

GICXMLLayout

  1. 打开bitcode:16.2MB
  2. 关闭bitcode:3.7MB

flutter

flutter本身就不支持bitcode。因此忽略bitcode。包的大小为:11MB

分析

通过上面的数据可以分析出,在关闭bitcode的情况下,包的大小依次为,flutter(11MB) > GIC(3.7MB) > 原生(269KB)。

5. 动画

这里以一个简单的水平位移动画作为案例。

测试设备:iphone6

原生

使用CABasicAnimation做动画。

GICXMLLayout

flutter

分析

对于这么简单的动画,都是满帧运行的。因此只需要对GPU和CPU做分析比较即可。

  1. 原生:

    原生方式的性能表现是最好的。在动画的时候,几乎不占用CPU资源。而GPU一直保持着7%的占用。

  2. GICXMLLayout:

    GIC的GPU的占用上跟原生的差不多,但是CPU却一直有占用,差不多维持着最高10%的占用。并且可以注意到,CPU的占用不是连续的而是断断续续的,这是有原因的,因为GIC的动画是基于popAnimation实现的,而popAnimation是基于CADisplaylink开发的,并且是按照60帧计算的。也就是差不多每秒60次的动画计算。而只有在动画计算的时候才会占用CPU资源,因此从测试结果来看,也是符合预期的。另外,在内存占用方面,跟原生动画差不多。

  3. flutter

    flutter的动画在GPU的占用上几乎是原生的两倍以上。而且CPU也是连续维持着10%的占用。而内存占用方面也差不多是原生的两倍以上。

总结

在上面的测试中,由于测试案例比较简单,并不能代表大多数情况,只是针对当前的测试案例得出的结果,仅仅只是给出一个参考。

对于原生引用的测试代码可能有点不公平,没有进行任何的优化。然而这并不是关键,这样正说明了原生应用的优化空间比较大。

本来还想做一个列表加载时间测试的,但是对于flutter却无从下手,暂时不知道如何测试,等以后有方法了再做测试。

另外,这里也不得不为我自己的GICXMLLayout做个宣传。作为一个独立开发者维护的一个开源库并不容易,我花了很多的心血在这上面。各位,如果觉得GIC这个库还可以,还希望能给个star,感谢!项目地址

抛开原生应用不谈,如果您想像前端开发一样开发IOS应用,那么我觉得GIC值得您一试。不管从开发效率、上手难度、代码可读性等方面来说,GIC都能有优秀的表现,而GIC目前相较于flutter等支持跨平台的库来说最大的缺点是不支持跨平台。如果您开发的应用不考虑跨平台开发的话,那么GIC是一个很好的选择。

有的朋友可能会说,现在flutter很流行,并且dart的效率比JS高。但是GICUI业务逻辑(ViewModel)上是两套完全不同的架构,UI是纯native的并且是基于Texuture开发的,而ViewModel你既可以使用native代码来写,也支持使用JS来写。另外在实际的应用(非游戏)开发中,业务逻辑如果复杂到能通过不同的语言来区分的地步(比如dart和JS),那么这样的应用应该是一个非常复杂的应用了。因此我认为在语言上来比较孰优孰虑并不是最优先级。另外,事实上GIC从架构设计上其实也可以支持dart语言、甚至其他的脚本语言。

关注下面的标签,发现更多相似文章
评论