前言
本文是就Flutter的数据更新形式来操作，然后通过以观测观测台的状态数据报告，来完成对代码执行效率的监控，并找到突破口。
观测台
不管是Idea还是Android Studio都提供了观测台的功能。
一般我们使用的都是Observatory的timeline部分。
我打开的方式一般都是在
terminal中输入flutter run，如果要使用真机测试则输入flutter run --profile。成功后会出现如图所示的网址，不过这个网址适合在Google浏览器中进行显示。
一般在timeline中，我们一般选用Flutter Developer的选项。出现的渲染显示我们一般会看到gpu和ui的渲染，以及重构过程。
性能优化
在性能优化之前，我们需要知道Flutter重构的逻辑。
在Android中我们知道绘制需要的三个步骤是 measure、layout、draw。
而Flutter对应的是build、layout、paint。
他的重构是基于一种标脏和重新创建的方式进行的，所以我们的性能影响一般来自于一个复杂界面的不断重建。可能你只需要修改一个很小的部分，也就是很小的一个子树需要进行修改，那么在代码没有规范的情况下，可能会出现整个界面的刷新，这样我们的性能可能就要下降了数倍。
对于我的代码而言，就是整个界面的代码都得到了重建的，但是这是基于本身代码还是简单的原因，如果代码是非常复杂的，那会得到怎样毁灭性的结果，也是可想而知。
上文的意思用这张图来表示，就是本来我们重构的就是实线叉号的子树，但是因为代码的书写原因，导致我们的结果重构的虚线叉号的整棵树。所以代码的书写规范在性能优化上起了至关重要的作用。
代码测试
测试代码位于包
test:WanAndroid-Flutter
上图是我测试的代码，黑色图形中的数据是通过
Timer自动更新的。
int _num = 0;
@override
void initState() {
// TODO: implement initState
super.initState();
Timer.periodic(Duration(seconds: 1), (timer) {
setState(() {
_num = timer.tick;
});
});
}
在initState()函数中，我们做了一件事情，就是一个初始化，并且这是一个每1s进行一次更新的。
在源码中，这个数据更新处于两种位置：Main页面、组件化的_buildBottom。
- Main页面：在这个页面中，如果重构，就会发生我们上述所说的情况，把整个页面全部重构了。
- 组件化的_buildBottomde：将上述的更新代码转移到这个组件中，那么重构的效果就会和上述的一样，当然你可以更进行细化。
 性能优化前
|
 性能优化后
|
|---|
通过Observatory的观测，我们能够看到两种位置进行更新，他们重构所需要进行的步骤是完全不一样的程度的，更何况我的页面逻辑是处于一个还算简单的状态呢。
以上就是我的学习成果，如果有什么我没有思考到的地方或是文章内存在错误，欢迎与我分享。
相关文章推荐：
手撕Flutter
