flutter占内存高,float占用内存

Flutter 与 iOS 原生 webView 对比

本文对比的是 UIWebView、WKWebView、flutter_webview_plugin（在iOS中使用的是WKWebView）的加载速度，内存使用情况。

公司主营业务：做网站、成都网站建设、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。成都创新互联公司是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联公司推出老边免费做网站回馈大家。

测试网页打开的速度，只需要获取 WebView 在开始加载网页和网页加载完成时的时间戳，时间戳的差即为打开网页的时间

为了使差异更明显，我们选择较为复杂的 新浪首页 进行加载的对比，为了减小网络对加载速度的影响，我们让手机连接同一个网络，分别进行 10 次测试然后取平均值，另外，我们需要关闭 WebView 的缓存，防止缓存对加载速度产生影响

下面使笔者进行 10 次测试所得到的数据

结果让我有点惊讶，一直以为 WKWebView 会是个王者。结果看，速度上 WKWebView 略慢一点，不过总体差异不大（该结果仅仅是测试新浪的结果，仅供参考啦）

在这里，笔者又加了一个测试，尝试记录从 viewController 的 viewDidLoad 到 webview 的 didFinish 时间，测试了新浪的数据，如下：

UIWebViewA ： 4970、3808、3815、4250、3556 avg(4079.8) （加载完所有页面）

UIWebViewB ： 4103、3124、3070、3256、2835 avg(3277.6)（加载sina完毕）

WKWebView ： 3672、3032、2892、2912、2739 avg(3049.4)

flutter_webView ： 4532、3901、4310、3496、3378 avg(3923.4)

其中可以看到，webView 有两行，UIWebViewB 的数据就是加载 sina 主站的时间；UIWebViewA 的数据是因为在加载完 sina 主站之后，新浪又加载了一个 ，所以导致总时间延长，不过即使按照 UIWebViewB 的数据来比较，也是 wkWebView 略胜一筹。

此处可以看出 flutter_webView 使用的是 wkwebView，所以它吃亏的主要原因是 flutter 包了一层。

结论：

速度（didStart - didFinish） UIWebView flutter_webview WKWebView

速度（viewDidLoad - didFinish）WKWebView UIWebView flutter_webview

这里查看内存使用的是 xcode 的 debug session 中的 memory。

首先看之前测试时，连续打开十次新浪的内存情况

接着我们在看一下打开淘宝首页的内存情况

从图上可以看出，WKWebView 在内存方面有很大的优势啊，UIWebView 的内存是真的伤啊，然后 debug 看了一下 flutter_webView，他使用的就是原生的 webView 。

他相比较原生 WKWebView 的内存开销稍大一点，从测试表现来看，一般大个 30 MB 左右。

结论：内存 WKWebView flutter_webview UIWebView

可以在 html5test 中对浏览器的兼容性进行评分，通过测试发现得分分别如下

因为 flutter 里使用的就是 WK，所以和原生的 WKWebView 一样都是 444 分，比 UIWebView 的 437 略胜一筹

结论：兼容性 WKWebView = flutter_webview UIWebView

UIWebView : 速度相比较 WKWebView 稍快一点，但是内存是一大硬伤，所以只要条件允许，就不推荐使用了

WKWebView : 速度略慢一点，不过差别不大，总体可以接受。是比UIWebView更好的选择，推荐使用。

flutter_webView_plugin ：在iOS中使用的就是原生的WKWebView，所以总体和 native WKWebView 表现差不多。如果是混编项目中，因为它被包了一层，所以页面加载上存在一定的劣势，所以混编项目中仍然推荐使用 WKWebView。不过如果从多端考虑、以及项目可迁移等，那么使用也未尝不可，就是维护成本要增加一些，需要维护两套 webView。这个就需要根据自己的情况自己取舍了。

Flutter 之 文件操作（二十九）

Dart的 IO 库包含了文件读写的相关类，它属于 Dart 语法标准的一部分，所以通过 Dart IO 库，无论是 Dart VM 下的脚本还是 Flutter，都是通过 Dart IO 库来操作文件的，不过和 Dart VM 相比，Flutter 有一个重要差异是文件系统路径不同，这是因为Dart VM 是运行在 PC 或服务器操作系统下，而 Flutter 是运行在移动操作系统中，他们的文件系统会有一些差异。

Android 和 iOS 的应用存储目录不同， PathProvider 插件提供了一种平台透明的方式来访问设备文件系统上的常用位置。该类当前支持访问两个文件系统位置：

File代表一个整体的文件,他有三个构造函数，分别是：

文件读取本身有两种形式，一种是文本，一种是二进制。

2.2.1 读取文本内容

如果是文本文件，File提供了readAsString、readAsLines、readAsStringSync、readAsLinesSync方法，读取文本内容

readAsString 一次性读取所有文本

readAsLines 一行行的读取文本

结果返回的是一个List，list中表示文件每行的内容

readAsStringSync、readAsLinesSync同步读取文本

2.2.2 读取二进制内容

如果文件是二进制，那么可以使用readAsBytes或者同步的方法readAsBytesSync:

dart中表示二进制有一个专门的类型叫做Uint8List,他实际上表示的是一个int的List。

上面提到的读取方式，都是一次性读取整个文件，缺点就是如果文件太大的话，可能造成内存空间的压力。

所以File为我们提供了另外一种读取文件的方法，流的形式来读取文件.

示例

dart提供了open和openSync两个方法来进行随机文件读写：

写入和文件读取一样，可以一次性写入或者获得一个写入句柄，然后再写入。

一次性写入的方法有四种，分别对应字符串和二进制

句柄形式可以调用openWrite方法，返回一个IOSink对象，然后通过这个对象进行写入：

默认情况下写入是会覆盖整个文件的，但是可以通过下面的方式来更改写入模式：

虽然dart中所有的异常都是运行时异常，但是和java一样，要想手动处理文件读写中的异常，则可以使用try,catch:

我们还是以计数器为例，实现在应用退出重启后可以恢复点击次数。 这里，我们使用文件来保存数据：

1.引入PathProvider插件；在pubspec.yaml文件中添加如下声明：

执行 flutter pub get

2.实现如下

参考：

Flutter性能优化

1.圆角对性能的影响

尽量避免用Clipxxx组件，建议用BoxDecoration的image属性实现，如果用Clipxxx组件，圆角取整后性能会提升。

2.减少重绘

根据场景合理使用RePaintBoundary，使绘制独立于父布局，避免重绘，提升性能，但过度使用增加的图层会带来Raster合成的耗时。例如scrollview是滑动过程会导致所有的节点都重绘，可以在scrollview下一层使用RePaintBoundary。

3.滚动步长插值器优化（了解）

官方的滚动差值器在出现小卡顿时，滚动步长会出现大的跳跃，导致体感上出现很明显的抖动，优化步长偏移量算法与原生效果对齐。

4.开启SurfaceView

官方推荐Flutter用SurfaceView ，因为SurfaceView与应用窗口内容分隔开，在专有硬件中合成，产生的中间副本少于TextureView，所以性能高，占用内存少，但是在混合栈遇到的问题需要突破

5.使用RepaintBoundary 提升频繁重绘控件的性能。使用RelayoutBoundary提升频繁修改大小，增删的布局中也可以提升性能。

6.build中不要去写大量的耗时逻辑，因为数据更新会触发build的多次调用，在里面做耗时逻辑会降低性能。

7.尽量使用statelessWidget代替statefulWidget，因为statefulWidget的销毁重建会引起子widget的销毁与重建。

8.解析json可以放到子线程线程中，开Isolate去解析，这样，当返回数据特别大的时候也不会阻塞界面。

9.使用不变的组件的时候可以添加const，const组件不会进行build更新

10.由于flutter通过widget.runtimeType和key来判断是否需要跟新组建，所以我们写组件的时候尽量保持key不变，或者不写key。对于一些需要频繁改变，例如新增、删除、排序的最好加上key。如果type一直，如果不写key容易导致，element无法区分新旧widget，导致无法更新。

Flutter开发--视频播放器

目前Flutter平台主流的两个播放器是video_player和fijkplayer

pub

github

1、Flutter平台官方插件，作者是国外的，有问题沟通比较困难，只能通过提交issue

2、硬解码

4、UI封装： better_player

基于video_player和Chewie的高级视频播放器。它解决了许多典型的用例，并且易于运行。

5、播放器宽高比例与视频内容宽高比例不一致时，会出现图像压缩变形的问题

6、调用原生内核播放器：iOS--AVPlayer， Android--ExoPlayer

7、对于分段源 m3u8 的播放不友好，如果一个切片播放超时，会导致整个播放都失败

8、better_player可以缓存视频，但不能自定义缓存的地址，只能指定key，和缓存的最大内存量（还未研究超出最大的话是不能缓存新的，还是删除最旧的）

9、better_player不能完全自定义UI，只能修改类中的一些开放属性，比如说icon图标，文字颜色啥的

10、无网络有缓存时，封面可以正常展示

11、better_player播放失败有手动retry的设计

pub

github

1、fijkplayer 是一个 Flutter 生态的媒体播放器，是对 ijkplayer 的 Flutter 封装，支持 Android 和 iOS。 fijkplayer 使用 ijkplayer 作为播放器内核，ijkplayer 使用 ffmpeg 进行音视频解封装和解码，同时添加了 Android 和 iOS 平台特有的硬件加速解码能力。

2 、国内有QQ群，但是活跃度也是不高。

3、可以缓存视频，可以自定义缓存的地址，方便后续的内存维护。

4、可以通过FijkPanelWidgetBuilder较大程度上自定义UI。

5、无网络有缓存视频时，无法展示封面，因为内部是通过imageProvider去加载网络图片的。

7、播放失败无手动retry的设计

1、两种播放器都是通过外接纹理方案 (Texture)，将播放器视频画面渲染接入 flutter 中，性能上优于 PlatformView 的接入方法。

如何自己实现？

下面以video_palyer的iOS源码部分解释：

iOS用CVPixelBufferRef将渲染出来的数据存在内存中，Flutter engine会将Texture的数据在内存中直接进行映射无需通过Channel传输，然后Texture Widget就可以把你提供的这些数据显示出来。在我们传输数据的时候会需要将其与 TextureID 绑定，绑定的过程通过BasicMessageChannel实现数据流的传输，以做到实时展示的效果

Flutter动画性能， 官方flutter基础动画在真机上能跑到20-30%CPU

这是他提的 ：

用的是这个官方动画效果

（ ）

运行起来的效果 如下：就是在一个Column 中放置了3个的动画

目前测试App在前台，运行中的CPU的情况

打开App的时候 CPU的使用率 ，当App在做网络请求的时候，占用率会更加的高

这是打开百度翻译的APP CPU占有率

记不记得这个图片，电脑的CPU使用率，如果它的占用大于了60%，你就会发现电脑的风扇在拼命的转，而且电脑会运行过慢

但是手机好像没有像电脑那么严重，使用起来也没有那么卡，这个和手机的固件设计有关系

这是另外一个小伙伴的公司的App内存的占用情况

CPU使用率是性能测试是一项重要指标，CPU占用过高会使得设备运行程序出现卡顿与发热，甚至出现应用程序Crash,影响用户体验。在排除硬件环境的限制下，应用程序应该尽可能少的占用CPU。

一个Demo，3个动画的CPU使用率达到了80%，如果用java or kotlin 去实现应该不会有那么高的占有率，所以Flutter的还需要继续的优化。

(App性能测试—CPU使用率):

flutter图片内存优化

按照给定尺寸进行图片的解码，而不是解码整个图片的尺寸，用来减少内存的占用。

官方文档：

官方说明：

Instructs Flutter to decode the image at the specified dimensions instead of at its native size.

This allows finer control of the size of the image in ImageCache and is generally used to reduce the memory footprint of ImageCache .

The decoded image may still be displayed at sizes other than the cached size provided here.

使用：

三方库： cached_network_image 限2.5.0之后版本才可用

设定最大的缓存宽度和高度 this.maxWidthDiskCache 、 this.maxHeightDiskCache

使用：

从相册选取图片，展示时使用指定尺寸宽高进行处理。

使用三方库：

使用自定义 provider 来指定所需图片的宽高：

AssetEntityImageProvider 传入宽高和图片原图 AssetEntity 数据。

provider 中 key.entity.thumbDataWithSize 方法：

进入 entity 中 thumbDataWithSize 方法：

进入 _getThumbDataWithId 方法中，

进入getThumb：

调用iOS原生的获取图片方法，

进入 getThumbWithId 方法，

原生实现获取置顶宽高缩略图方法实现：

使用 iOS 原生类 PHImageManager 的

来获取缩略图。