首先查看入口函数：
十载建站经验， 成都做网站、网站制作客户的见证与正确选择。成都创新互联公司提供完善的营销型网页建站明细报价表。后期开发更加便捷高效，我们致力于追求更美、更快、更规范。
类MyApp：
MyHomePage:
state:
build:
此demo页面涉及到两个组件：图片和icon。在这里做一个简单的介绍，更详细的学习请参考flutter官网和相关书籍
在flutter中，我们可以通过Image组件来加载并显示图片，Image的数据源可以是asset、文件、内存以及网络。
ImageProvider 是一个抽象类，主要定义了图片数据获取的接口 load() ，从不同的数据源获取图片需要实现不同的 ImageProvider ，如 AssetImage 是实现了从Asset中加载图片的ImageProvider，而 NetworkImage 实现了从网络加载图片的ImageProvider。
Image也提供了一个快捷的构造函数 Image.asset 用于从asset中加载、显示图片：
Image也提供了一个快捷的构造函数 Image.network 用于从网络加载、显示图片：
Flutter中，可以像web开发一样使用iconfont，iconfont也即"字体图标"，它是将图标做成字体文件，然后通过指定不同的字符而显示不同的图片。
加号为图片组件，减一为icon组件。点击加号，数字加1；点击-1，数字减少1。
本文对比的是 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。这个就需要根据自己的情况自己取舍了。
这是他提的 ：
用的是这个官方动画效果
（ ）
运行起来的效果 如下：就是在一个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平台主流的两个播放器是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实现数据流的传输，以做到实时展示的效果
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，导致无法更新。
按照给定尺寸进行图片的解码，而不是解码整个图片的尺寸，用来减少内存的占用。
官方文档：
官方说明：
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 的
来获取缩略图。
