flutter高刷新率,flutter 刷新

Flutter局部刷新方法

Flutter中Widget分为StatefulWidget和StatelessWidget，分别为动态视图和静态视图，视图的更新需要调用StatefulWidget的setState方法，这会遍历调用子Widget的build方法。当一个主页面比较复杂时，会包含多个widget，如果直接调用setState，会遍历所有子Widget的build，这是非常不必要的性能开销，有没有单独刷新指定Widget的方式呢？这个时候就要用到GlobalKey了。

创新互联建站主要从事成都做网站、网站建设、外贸营销网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务阿拉尔,10余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:028-86922220

一个StatefulWidget包含一个Button，一个Text，通过点击Button调用主Widget的setState方法，刷新Text，示例如下：

同样一个StatefulWidget包含一个多个Text和Button，点击Button我们只需要刷新指定的Text，通过GlobalKey的方式，实现如下：

主Widget，包含一个需要更新的TextWidget和一个不需要更新的Text

需要单独更新的Widget

传递事件的Button

这样点击Button就只会更新指定的TextWidget了，效果如下：

这只是一个简单的例子，在实际开发中为了页面刷新的高效率，模块化封装非常重要。很多情况下都只需要局部刷新，而不是重构整个视图。所以Globalkey的运用在项目中需要熟练掌握

Flutter组件（Widget）的局部刷新方式

Flutter中有两个常用的状态Widget分为StatefulWidget和StatelessWidget，分别为动态视图和静态视图，视图的更新需要调用StatefulWidget的setState方法，这会遍历调用子Widget的build方法。如果一个页面内容比较复杂时，会包含多个widget，如果直接调用setState，会遍历所有子Widget的build，这样会造成很多不必要的开销，所以非常有必要了解Flutter中局部刷新的方式：

globalkey唯一定义了某个element，它使你能够访问与element相关联的其他对象，例如buildContext、state等。应用场景：跨widget访问状态。

例如：可以通过key.currentState拿到它的状态对象，然后就可以调用其中的onPressed方法。

Flutter框架内部提供了一个非常小巧精致的组件，专门用于局部组件的刷新。适用于值改动的刷新。

实现原理：在 initState 中对传入的可监听对象进行监听，执行 _valueChanged 方法，_valueChanged 中进行了 setState 来触发当前状态的刷新。触发 build 方法，从而触发 widget.builder 回调，这样就实现了局部刷新。可以看到这里回调的 child 是组件传入的 child，所以直接使用，这就是对 child 的优化的根源。

可以看到 ValueListenableBuilder 实现局部刷新的本质，也是进行组件的抽离，让组件状态的改变框定在状态内部，并通过 builder 回调控制局部刷新，暴露给用户使用。

通过这个可以创建一个支持局部刷新的widget树，比如你可以在StatelessWidget里面刷新某个布局，但是不需要改变成StatefulWidget；也可以在StatefulWidget中使用做部分刷新而不需要刷新整个页面，这个刷新是不会调用Widget build（BuildContext context）刷新整个布局树的。

异步UI更新：

很多时候我们会依赖一些异步数据来动态更新UI，比如在打开一个页面时我们需要先从互联网上获取数据，在获取数据的过程中显示一个加载框，等获取到数据时我们再渲染页面；又比如我们想展示Stream（比如文件流、互联网数据接收流）的进度。当然StatefulWidget我们完全可以实现以上功能。但由于在实际开发中依赖异步数据更新UI的这种场景非常常见，并且当StatefulWidget中控件树较大时，更新一个属性导致整个树重建，消耗性能，因此Flutter专门提供了FutureBuilder和SteamBuilder两个组件来快速实现这种功能。

通常情况下，子Widget无法单独感知父Widget的变化，当父state变化时，通过其build重建所有子widget；

InheriteddWidget可以避免这种全局创建，实现局部子Widget更新。InheritedWidget提供了一种在Widget树中从上到下传递、共享数据的方式。Flutter SDK正是通过InheritedWidget来共享应用主题和Locale等信息。

InheritedWidgetData

TestData

InheritedTest1Page

provider是Google I/O 2019大会上宣布的现在官方推荐的管理方式，而ChangeNotifierProvider可以说是Provider的一种：

yaml文件需要引入provider: ^3.1.0

顶层嵌套ChangeNotifierProvider

创建共享数据类DataInfo：

数据类需要with ChangeNotifier 以使用 notifyListeners()函数通知监听者更新界面。

使用Provider.of(context)获取DataInfo

nextPage：

使用Consumer包住需要使用共享数据的Widget

RepaintBoundary就是重绘边界，用于重绘时独立于父视图。页面需要更新的页面结构可以用 RepaintBoundary组件嵌套,flutter 会将包含的组件独立出一层"画布"，去绘制。官方很多组件 外层也包了层 RepaintBoundary 标签。如果你的自定义view比较复杂，应该尽可能的避免重绘。

以上总结了几种Flutter的局部刷新的方式，可根据实际需要使用不同的方式，最适合的才是最好的。

flutter刷新页面的方法

这种方法最常见，但是有些地方引用的话，刷新的成本比较大，刷新的是整个页面，数据太多加载太慢的话，会有闪烁的现象

这种方法类似于iOS中的set方法，通过设置某个属性的时候，去刷新某个控件。在flutter中这种刷新方式，是对上面setState(){}方法的改进，根本的方法还是setState(){}，只不过是通过方法去刷新某个控件。如下：

首先在pubspec.yaml中添加provider依赖

下面通过provider来实现一个发送验证码的案例。

创建一个TimerModel文件

页面布局如下：

Android 图形系统（Graphics）

本文将从三个方面介绍Android 图形系统。

图形系统提供绘图和图形处理支持。

Android 框架提供了各种用于 2D 和 3D 图形渲染的 API、图片解码库，以及各种Driver支持。

• 绘图API：2D引擎 Skia，3D引擎 OpenGL ES，RenderScript，OpenCV和Vulkan。

• 图片解码库：jpg，png，gif等。

应用开发者可通过三种方式将图像绘制到屏幕:

• Canvas : 2D图形API，Android View树实际的绘制者。

• OpenGL ES : 嵌入式设备的OpenGL 三维图形API子集。

• Vulkan :跨平台的2D和3D绘图引擎,Android 7.0后支持，NDK。

整个图形系统架构是一个生产者和消费者模式，五层依次介绍：

2D绘制：Canvas api / view 的子类 (button ,list)/自定义view

3D绘制：应用直接使用OpenGL 接口绘制图形(PixelFlinger对应的是openGl 1.0 ，GUP driver 对应的是2.0和3.0)

所有情况下的绘图都渲染到一个包含 GraphicBuffer的Surface上，当一块 Surface 显示在屏幕上时，就是用户所看到的窗口。

• Canvas：画布，2D图形API，Android View树实际的渲染者。

• Skia绘制：Android4.0之前默认使用，主线程通过CPU完成绘图指令操作，在复杂场景下单帧容易超过16ms导致卡顿。

WindowManagerService（WMS）窗口管理服务，管理系统中所有的窗口。

• 管理window （view的容器）

• Window与surface对应，一块显示区域。添加一个window，就是 WMS 为其分配一块 Surface 的过程。

Google 在Android source官网提示：

这里就对这些控件进行简单介绍：

Surface : Handle onto a raw buffer that is being managed by the screen compositor.

Surface 对应一块屏幕缓冲区。生产者是： SurfaceTexture、MediaRecorder 等，消费者是： OpenGL、MediaPlayer 或 CameraDevice等。每个window对应一个Surface。Canvas或OpenGL ES等最终都渲染到Surface上。

• Flutter在Android平台上也是直接渲染到Surface。例如：一个Activity/Dialog都是一个Surface，它承载了上层的图形数据，与SurfaceFlinger侧的Layer相对应。

Canvas（画布）实现由 Skia 图形库提供。为了确保两个客户端不会同时更新某个缓冲区，使用以下命令处理画布锁：

使用双缓冲机制，有自己的 surface，View只是一个透明的占位符，Surface可以在后台线程中绘制。双缓冲机制提高渲染效率，独立线程

绘制，提升流畅性。适合一些场景：需要界面迅速更新、UI绘制时间长、对帧率要求较高的情况。

提供访问和控制Surface 相关的方法 。通过SurfaceView的getHolder()函数可以获取SurfaceHolder对象，Surface 就在SurfaceHolder对象内。

addCallback(SurfaceHolder.Callbackcallback) /Canvas lockCanvas() /unlockCanvasAndPost(Canvascanvas)

SurfaceTexture： Surface 和 OpenGL ES (GLES) 纹理（Texture）的组合。将图像流转为 OpenGL 外部纹理。

TextureView：持有 SurfaceTexture，将图像处理为 OpenGL 纹理更新到 HardwareLayer。

GLSurfaceView：加入 EGL 管理，自带 GL 上下文和 GL 渲染线程

这些View通常涉及到Android音视频相关，需要高效的渲染能力。如下面的SurfaceTexture在camera中的应用。

简称Buffer, 一个Buffer包含一帧图像，Buffer由gralloc分配和回收。Buffer 属性包含：width, height, format, usage等

BufferQueue 的引入是为了解决显示和性能问题。

• Surface属于APP进程，Layer属于系统进程，如果它们之间只用一个Buffer，会存在显示和性能问题。

• 一些Buffer用于绘制，一些Buffer用于显示，双方处理完之后，交换一下Buffer，提高效率。

• BufferQueue中包含多个Buffer对象。

Android图形系统包含了两对生产者和消费者模型，它们都通过BufferQueue进行连接：

1.Canvas和OpenGL ES生产图形数据，SurfaceFlinger消费图形数据。

2.SurfaceFlinger合成所有图层的图形数据，Display显示合成结果。

code：frameworks/native/services/surfaceflinger

• Surface表示APP进程的一个窗口，承载了窗口的图形数据。

• SurfaceFlinger是系统进程合成所有窗口的系统服务，负责合成所有Surface提供的图形数据，然后送显到屏幕。

• SurfaceFlinger既是上层应用的消费者，又是Display的生产者，起到了承上启下的作用。

数据流：

合成示意图：

在介绍Vsync机制之前先介绍两个重要概念：

屏幕刷新率：屏幕每秒钟可以刷新多少次。60HZ刷新率，16.7ms刷新一次。（120HZ/8.3ms），硬件指标。

GPU 绘制帧率：GPU 每秒能够合成绘制多少帧。

软件层触发 View 绘制的时机是随机的，当下一次屏幕刷新时，屏幕从 Frame Buffer 中拿到的数据还是“帧1”的数据，导致“丢帧”。

每隔 16ms 硬件层发出 vsync 信号，应用层接收到此信号后会触发UI 的渲染流程，同时 vsync 信号也会触发 SurfaceFlinger 读取Buffer 中的数据，进行合成显示到屏幕上。

总结：Vsync机制将 CPU 和 GPU 的开始时间与屏幕刷新强行拖拽到同一起跑线

Android提供的Graphics流程相对比较复杂对其进行具象后的流程如下两张图所示：

Android原生和Flutter使用过程的差异对比（一）

1、界面搭建过程中各种大小单位

Android：通常采用dp设置View宽高（和px像素的换算关系是dp值 × density逻辑密度），sp设置字体大小（会随着系统字体设置的大小而改变）。

Flutter：没有具体的大小单位描述， 和尺寸相关的MediaQueryData类中较为重要的几个值如下：

（一）devicePixelRatio（设备像素比），对应Android中的density

（二）size.width和height，设备的逻辑像素宽高，并非绝对物理像素（例如iphone6的设备像素比是2，通过size获取到的逻辑像素宽高为375  ×  667，实际物理像素则为750 × 1334，即分辨率）

（三）textScaleFactor：单位逻辑像素字体像素数，默认为1，设置成1.5则字体变大50%，如果想让Text组件的字体大小不随系统设置的变化而变化，需将这个值设定成固定值1

UI适配解决方案：

1、采用ScreenUtil插件，初始化时候传入设计稿大小，当发现一屏显示的大小有差异时候采用插件提供的setWidth和setHeight来设置具体的宽高（会根据设计稿大小和实际设备逻辑像素宽高比进行缩放）。

2、TextButton、Text等按钮和文本组件，通过设置字体大小和内边距来控制整体的宽高，而非固定其宽高。

2、本地资源文件的引用方式

Android：图片通常存放在res/mipmap或res/drawable下，不同分辨率对应不同后缀名，如mipmap-hdpi、mipmap-xhdpi

Flutter：需在pubspec.yaml中配置，如下图所示

如果只配置父级目录例如（assets/images/common_status）则无法再存放不同尺寸的图片。不同尺寸的图片需建立对应的2.0x、3.0x目录后存放，设备在读取时候会自行根据分辨率去找对应的图片，弊端是每有一张图片就需在pubspec.yaml文件中声明这些图片

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实现数据流的传输，以做到实时展示的效果