Flutter性能调优、复杂业务保证Flutter的高性能高流畅

头像
码农笔录
2020-04-26阅读 291

点击查看Demo源码

高性能高流畅度一直是Flutter团队宣传的一大亮点,也是当初选择Flutter的重要因素之一,但是随着复杂业务的应用落地,通过Flutter页面和原生页面滑动流畅度对比,我们开始产生怀疑,因为部分Flutter页面流畅度明显低于Native,是Flutter的宣传言过其实还是我们开发人员使用姿势有问题,今天我们就来具体分析下。

Flutter有四种运行模式:Debug、Release、Profile和test,这四种模式在build的时候是完全独立的。

1.Debug   

Debug模式可以在真机和模拟器上同时运行:会打开所有的断言,包括debugging信息、debugger aids(比如observatory)和服务扩展。优化了快速develop/run循环,但是没有优化执行速度、二进制大小和部署。命令flutter run就是以这种模式运行的,通过sky/tools/gn --android或者sky/tools/gn --ios来build。有时候也被叫做“checked模式”或者“slow模式”。 
2.Release   
Release模式只能在真机上运行,不能在模拟器上运行:会关闭所有断言和debugging信息,关闭所有debugger工具。优化了快速启动、快速执行和减小包体积。禁用所有的debugging aids和服务扩展。这个模式是为了部署给最终的用户使用。命令flutter run --release就是以这种模式运行的,通过sky/tools/gn --android --runtime-mode=release或者sky/tools/gn --ios --runtime-mode=release来build。 
3.Profile    
Profile模式只能在真机上运行,不能在模拟器上运行:基本和Release模式一致,除了启用了服务扩展和tracing,以及一些为了最低限度支持tracing运行的东西(比如可以连接observatory到进程)。命令flutter run --profile就是以这种模式运行的,通过sky/tools/gn --android --runtime-mode=profile或者sky/tools/gn --ios --runtime-mode=profile```来build。因为模拟器不能代表真实场景,所以不能在模拟器上运行。 
4. test    
headless test模式只能在桌面上运行:基本和Debug模式一致,除了是headless的而且你能在桌面运行。命令flutter test就是以这种模式运行的,通过sky/tools/gn来build。

Flutter的架构主要分成三层:Framework,Engine,Embedder。

1.Framework使用dart实现,包括Material Design风格的Widget,Cupertino(针对iOS)风格的Widgets,文本/图片/按钮等基础Widgets,渲染,动画,手势等。 此部分的核心代码是:flutter仓库下的flutter package,以及sky_engine仓库下的io,async,ui(dart:ui库提供了Flutter框架和引擎之间的接口)等package。

 2.Engine使用C++实现,主要包括:Skia,Dart和Text。 

Skia是开源的二维图形库,提供了适用于多种软硬件平台的通用API。

 3.Embedder是一个嵌入层,即把Flutter嵌入到各个平台上去,这里做的主要工作包括渲染Surface设置,线程设置,以及插件等。 从这里可以看出,Flutter的平台相关层很低,平台(如iOS)只是提供一个画布,剩余的所有渲染相关的逻辑都在Flutter内部,这就使得它具有了很好的跨端一致性。  

Flutter渲染原理简介

优化之前我们先来介绍下Flutter的渲染原理,通过这部分基础了解渲染流程以及主要耗时花费

flutter视图树包含了三颗树:Widget、Element、RenderObject

  • ·Widget: 存放渲染内容、它只是一个配置数据结构,创建是非常轻量的,在页面刷新的过程中随时会重建
  • ·Element: 同时持有Widget和RenderObject,存放上下文信息,通过它来遍历视图树,支撑UI结构
  • ·RenderObject: 根据Widget的布局属性进行layout,paint ,负责真正的渲染

从创建到渲染的大体流程是:根据Widget生成Element,然后创建相应的RenderObject并关联到Element.renderObject属性上,最后再通过RenderObject来完成布局排列和绘制。

例如下面这段布局代码

Container(
color: Colors.blue,
child: Row(
children: <Widget>[
Image.asset('image'),
Text('text'),
],
),
);

对应三棵树的结构如下图  

了解了这三棵树,我们再来看下页面刷新的时候具体做了哪些操作

当需要更新UI的时候,Framework通知Engine,Engine会等到下个Vsync信号到达的时候,会通知Framework进行animate, build,layout,paint,最后生成layer提交给Engine。Engine会把layer进行组合,生成纹理,最后通过Open Gl接口提交数据给GPU, GPU经过处理后在显示器上面显示,如下图:

结合前面的例子,如果text文本或者image内容发生变化会触发哪些操作呢?
Widget是不可改变,需要重新创建一颗新树,build开始,然后对上一帧的element树做遍历,调用他的updateChild,看子节点类型跟之前是不是一样,不一样的话就把子节点扔掉,创造一个新的,一样的话就做内容更新,对renderObject做updateRenderObject操作,updateRenderObject内部实现会判断现在的节点跟上一帧是不是有改动,有改动才会别标记dirty,重新layout、paint,再生成新的layer交给GPU,流程如下图:  

  

到这里大家对Flutter在渲染方面有基本的理解,作为后面优化部分内容理解的基础 。

性能分析工具及方法 Dart DevTool

下面来看下性能分析工具,注意,统计性能数据一定要在真机+profile模式下运行,拿到最接近真实的体验数据。

Dart DevTool ,就是早期的Observatory,官方提供的性能检测工具。它的 timeline 界面可以让逐帧分析应用的 UI 性能。但是目前还是预览版,存在一些问题。

profile模式下运行起来,点击android studio底部的菜单按钮,会弹出一个网页

点击顶部的Timeline菜单 

 这个时候滑动页面,每一帧的耗时会以柱形bar的形式显示在页面上,每条bar代表一个frame,同时用不同颜色区分UI/GPU线程耗时,这个时候我们要分析卡顿的场景就需要选中一条红色的bar(总耗时超过16.6ms),中间区域的Frame events chart显示了当前选中的frame的事件跟踪,UI和GPU事件是独立的事件流,但它们共享一个公共的时间轴。

选中Frame events chart中的某个事件,以上图为例Layout耗时最长,我们选中它,会在底部Flame chart区域显示一个自顶向下的堆栈跟踪,每个堆栈帧的宽度表示它消耗CPU的时长,消耗大量CPU时长的堆栈是我们首要分析的重点,后面就是具体分析堆栈,定位卡顿问题。

或者用android studio 自带的插件分析,这个效率高,速度响应快



另外还有一些debug调试工具可以辅助查看更多信息,注意,只能在debug模式下使用分析,拿到的数据不能作为性能标准

debugProfileBuildsEnabled:向 Timeline 事件中添加每个widget的build 信息

debugProfilePaintsEnabled: 向 timeline 事件中添加每个renderObject的paint 信息

debugPaintLayerBordersEnabled:每个layer会出现一个边框,帮助区分layer层级

debugPrintRebuildDirtyWidgets:打印标记为dirty的widgets

debugPrintLayouts:打印标记为dirty的renderObjects

debugPrintBeginFrameBanner/debugPrintEndFrameBanner:打印每帧开始和结束


实例分析

了解这些工具下面我们来看个简单的demo具体分析下,一个由Column、Container、ListView嵌套的布局,其中有个定时器控制Text中显示的文本实时更新,类似于倒计时

import 'dart:async';
import 'package:flutter/material.dart';

/// 常规布局
class One extends StatefulWidget {
@override
State<StatefulWidget> createState() {
return _OneState();
}
}
class _OneState extends State<One> {
int _count = 0;
Timer _timer;

@override
void initState() {
super.initState();
Timer.periodic(Duration(milliseconds: 1000), (t) {
setState(() {
_count++;
});
});
}
@override
void dispose() {
if (_timer != null && _timer.isActive) {
_timer.cancel();
}
super.dispose();
}
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(
title: Text("性能测试1"),
),
body: Column(
children: <Widget>[
Container(
margin: EdgeInsets.fromLTRB(10, 10, 10, 5),
height: 100,
color: Colors.amberAccent,
),
Container(
margin: EdgeInsets.fromLTRB(10, 10, 10, 5),
height: 100,
color: Colors.blue,
),
Container(
height: 100,
child: ListView.builder(
scrollDirection: Axis.horizontal,
itemCount: 12,
itemBuilder: (context, index) {
return Container(
width: 70,
height: 70,
child: Image.asset(
"assets/2.png",
width: 50,
height: 50,
));
}),
),
Container(
height: 100,
color: Colors.yellow,
child: Center(
child: Text(
_count.toString(),
style: TextStyle(fontSize: 18, fontWeight: FontWeight.bold),
),
),
)
],
),
),
);
}
}



大部分widget都是静态的,只有黄色Container中包含一个内容一直刷新的Text,这个时候我们打开debugProfileBuildsEnabled,用Timeline分析下它的渲染耗时,可以通过Frame events chart中显示的build层级非常深 


 


  结合第一部分渲染原理我们了解到,每次定时器刷新text数字的时候,整个页面widget树都会重新build,但其实只有最底层Container中的Text内容在改变,没有必要刷新整颗树,所以这里我们的优化方案是提高build效率,降低Widget tree遍历的出发点,将setState刷新数据尽量下发到底层节点,所以将Text单独抽取成独立的Widget,setState下发到抽取出的Widget内部  

import 'dart:async';

import 'package:flutter/material.dart';

class Two extends StatefulWidget {
@override
State<StatefulWidget> createState() {
return _TwoState();
}
}

class CountText extends StatefulWidget {
@override
State<StatefulWidget> createState() {
return _CountTextState();
}
}

class _CountTextState extends State<CountText> {
int _count = 0;
Timer _timer;

@override
void initState() {
super.initState();
Timer.periodic(Duration(milliseconds: 1000), (t) {
setState(() {
_count++;
});
});
}

@override
void dispose() {
if (_timer != null && _timer.isActive) {
_timer.cancel();
}
super.dispose();
}

@override
Widget build(BuildContext context) {
return Text(
_count.toString(),
style: TextStyle(fontSize: 18, fontWeight: FontWeight.bold),
);
}
}

class _TwoState extends State<Two> {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(
title: Text("性能测试2"),
),
body: Column(
children: <Widget>[
Container(
margin: EdgeInsets.fromLTRB(10, 10, 10, 5),
height: 100,
color: Colors.amberAccent,
),
Container(
margin: EdgeInsets.fromLTRB(10, 10, 10, 5),
height: 100,
color: Colors.blue,
),
Container(
height: 100,
child: ListView.builder(
scrollDirection: Axis.horizontal,
itemCount: 12,
itemBuilder: (context, index) {
return Container(
width: 70,
height: 70,
child: Image.asset(
"assets/2.png",
width: 50,
height: 50,
));
}),
),
Container(
height: 100,
color: Colors.yellow,
child: Center(child: CountText()),
)
],
),
),
);
}
}

修改后的Timeline显示如下图:  



build层级明显减少,总耗时也明显降低 

import 'dart:async';

import 'package:flutter/material.dart';

class Three extends StatefulWidget {
@override
State<StatefulWidget> createState() {
return _ThreeState();
}
}

class CountText extends StatefulWidget {
@override
State<StatefulWidget> createState() {
return _CountTextState();
}
}

class _CountTextState extends State<CountText> {
int _count = 0;
Timer _timer;

@override
void initState() {
super.initState();
Timer.periodic(Duration(milliseconds: 1000), (t) {
setState(() {
_count++;
});
});
}

@override
void dispose() {
if (_timer != null && _timer.isActive) {
_timer.cancel();
}
super.dispose();
}

@override
Widget build(BuildContext context) {
return Text(
_count.toString(),
style: TextStyle(fontSize: 18, fontWeight: FontWeight.bold),
);
}
}

class _ThreeState extends State<Three> {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(
title: Text("性能测试3"),
),
body: Column(
children: <Widget>[
Container(
margin: EdgeInsets.fromLTRB(10, 10, 10, 5),
height: 100,
color: Colors.amberAccent,
),
Container(
margin: EdgeInsets.fromLTRB(10, 10, 10, 5),
height: 100,
color: Colors.blue,
),
Container(
height: 100,
child: ListView.builder(
scrollDirection: Axis.horizontal,
itemCount: 5,
itemBuilder: (context, index) {
return Container(
width: 70,
height: 70,
child: Image.asset(
"assets/2.png",
width: 50,
height: 50,
));
}),
),
RepaintBoundary(
child: Column(
children: <Widget>[
Container(
margin: EdgeInsets.fromLTRB(10, 10, 10, 5),
height: 100,
color: Colors.yellow,
child: Center(child: CountText()),
),
Container(
margin: EdgeInsets.fromLTRB(10, 10, 10, 5),
height: 100,
color: Colors.cyanAccent,
),
],
))
],
),
),
);
}
}

可以看到我们为黄色的Container建立了单独的layer


总结常见问题

  1. 提高build效率,setState刷新数据尽量下发到底层节点
  2. 提高paint效率,RepaintBoundry创建单独layer减少重绘区域

这两个我们之前的例子已经具体分析过

  1. 1.减少build中逻辑处理,因为widget在页面刷新的过程中随时会通过build重建,build调用频繁,我们应该只处理跟UI相关的逻辑
  2. 2.减少saveLayer(ShaderMask、ColorFilter、Text Overflow)、clipPath的使用,saveLayer会在GPU中分配一块新的绘图缓冲区,切换绘图目标,这个操作是在GPU中非常耗时的,clipPath会影响每个绘图指令,做相交操作,之外的部分剔除掉,所以这也是个耗时操作
  3. 3.减少Opacity Widget 使用,尤其是在动画中,因为他会导致widget每一帧都会被重建,可以用 AnimatedOpacity 或 FadeInImage 进行代替

以上内容介绍了些Flutter常见的性能问题以及我们怎么用工具检测这个问题,在平时开发过程中要留意规避这类问题

 点击查看Demo源码

关注

如果有问题,请在下方评论

关注下方微信公众号,可以及时获取到各种技术的干货哦,如果你有想推荐的帖子,也可以联系我们的。