Flutter实践——实现一个动态页

Flutter是Google新出的跨平台开发框架，目前国内外已经有许多产品将Flutter用到正式的生产环境，本文用Flutter实现了一个瀑布流的动态页面。

动态页

1、页面效果

废话不多说，先上图，如下是分别用natvie和Flutter开发的页面：

左边是Native页面，右边是Flutter页面，可以看到Flutter的UI与natvie的几乎没有差别,但是Flutter并不像RN一样使用Native的UI进行绘制，而是在Canvas上自己绘制，可以从如下的视图层级图中看出：

2、跨平台覆盖率

Flutter支持Android和iOS：

1. Android支持4.1及以上的版本，设备要求是arm cpu
2. iOS支持 iOS8及以上，设备是iPhone 4S及以上
复制代码

官网上的描述如下：

• 结论 Flutter对Android和iOS的支持基本上已经覆盖了市场上的绝大部分用户。

3、开发成本

1. 适配层代码量小 Flutter是以Native作为出发点，在平台画布(Canvas)上构建一套独立的绘制体系，独立进行绘制和渲染，再通过粘合层抹平平台差异，达到接近原生程序体验的前提下的跨平台框架。因为Flutter有自己独立的绘制体系，因此相对于React Native和Weex来讲，对Native的依赖更小，所以Flutter和Native之间适配层的代码量很少，Flutter里面适配层的代码都是用于数据的传输。
2. Dart语言开发 同时Flutter使用Dart语言开发,Dart本身的高效特性可节约大量的开发成本。

这里列出开发同一个页面，native和Flutter的代码量:

4、包大小

Flutter 主要包含三部分，分别是：

1. sdk大小:so库(Android)/Framework(iOS)
2. Dart代码的构建产物(Android和iOS)
3. Channel 层的Android代码(iOS这部分在构建产物中)
4. 资源文件
复制代码

Flutter为了性能和调试方便，在debug模式和release模式下的编译方式不同，导致so库和构建产物的大小相差很大，并且Flutter页面越复杂，构建产物的大小越大，其中

1. 在debug模式下，so库打入了x86_64、x86、arm64-v8a，总共22.28M，构建产物大小8.94M，总共31.2M
2. 在release模式下，so库只有armeabi-v7a，总共3.46M，构建产物大小4.19M，总共7.65M
复制代码

而我们集成进工程的都是release模式，所以包大小至少增加7.65M,以下是Flutter、React Natvie、Weex包大小的比较:

• 结论 Flutter的so库及jar包的大小其实和React Native、Weex相差不大，甚至还要小一些，但是由于Flutter与React Native、Weex的实现方式不同，用Flutter写的页面的构建产物会打入到APP里面，从而导致Flutter集成到APP里面的大小要大一些，而且页面越复杂，构建产物的大小越大。

5、内存

往下滑动列表，记录页面内存的使用情况

1. 在native页面中，Java内存、Native内存、Graphics内存都在增长
2. 在Flutter页面中，Java内存、Native内存几乎不变，只有Graphics内存在增长，在官网上可以查到对Graphics内存的解释：

   

   从这里可以看出，Flutter使用的内存不是 Java 内存，虽然Graphics内存使用的很多，但是几乎不会增加Java内存的使用量，这对于我们来说是一个好消息，不会担心OOM的问题。

• 结论 因为Flutter使用的内存不是Java内存，所以不会导致OOM。

6、首屏时间

首屏时间：页面打开，拉取数据，到第一帧显示出来的时间。

• 结论 Flutter首屏时间要慢于natvie页面，慢100ms左右，Flutter首次的渲染速度还是略慢，之后的渲染速度就很快了。

7、页面的流畅度

往下滑动列表，统计页面的FPS,监测页面的流畅度。

• 结论 在滑动时，Flutter的流畅度比native要好一些。

8、 Flutter引擎crash率

截止到2018.6.16号，以下是RDM上报的Flutter相关的Crash数据:

上报的Flutter成功初始化的次数总共是6896796次，crash率只有0.005%

• 结论 可以看到Flutter的crash情况是特别少的，crash率只有0.005%，说明Flutter引擎很稳定。

###9、Flutter页面异常情况 截止到2018.6.16号，监测到Flutter页面总共打开3172次，其中上报的error总共有19个，这些error都是Flutter Framework层的问题，Flutter页面出现error，不会造成crash，但有可能会造成页面异常，比如无法滑动或无法交互等。

• 结论 上报的error都是Flutter Framework层的问题，但是一方面出错的概率很小，另一方面Flutter Framework层都是用Dart来实现，而且更重要的一点是Framework层对于我们来说是白箱的，我们可以直接修改Framework层的代码,也意味着我们可以做更加深入的优化。

Flutter工程化实践

1、cs协议数据获取

因为数据都是通过cs协议来拉取的，而在Flutter层实现一个cs的拉取，还需要管理登录态，实在是一个复杂的事情，好在Flutter有与Native通信的机制，但是Flutter与Native通信只能传基本类型，不能直接传对象，传输支持的类型如下图：

那怎么把cs数据从Native传给Flutter呢？好在Dart支持pb，我们可以把要使用的pb文件，编译成Dart代码，在Dart层组装好pb的request并转化为byte传给Native，在Natvie层发送cs协议，接受到byte格式的数据，在发送给Flutter，Flutter把byte在转化为对象使用。如下图:

pb编译成Dart代码如下图:

2、iOS上crash问题

在开发过程中，当一直下拉拖动列表加载更多时，iOS很容易crash，crash日志如下:

经过分析发现原来是在下拉加载更多的时候，一直在加载图片，导致OOM。

于是去分析Flutter的图片加载机制，发现Flutter虽然提供了一个ImageCache来缓存加载的图片，但他只能粗略的指定最大缓存图片张数，不能精确的使用内存大小来设定缓存池容量，而且更坑的是在加载图片的时候不能裁剪图片尺寸，都是以原尺寸来加载图片，查遍所有资料，也没有看到Dart层能对图片进行裁剪的方法，而我们瀑布流里面的图片都是大图，所以导致在下拉加载更多的额时候，iOS的内存使用量一直在增加，最终导致OOM。

知道Flutter图片缓存策略太简单、以及不能对图片裁剪的问题后，接着就对Flutter的图片加载机制做了如下改造，Flutter拿到图片的url之后，自己不去加载，而是将url交给natvie处理，使用native的图片库将图片下载并裁剪尺寸保存在本地，然后把图片在本地的地址传给Flutter加载，成功解决了Flutter在iOS上的crash问题。流程图如下: