目前市面上的Flutter都普遍用于一些简单页面，单纯铺设UI，而开眼快创作为完全使用Flutter开发的APP，除了简单的信息流页面，还有更重要的页面——视频编辑页面和模版视频制作页面。今天主要介绍一下开眼快创的视频编辑页面是如何生成和优化的。

在进入开眼快创项目之前，项目里有很多人甚至对Flutter是完全没有了解的，再加上当时市面上还没找到用Flutter写视频编辑页面的APP，因此很多技术方案都经过了漫长的摸索和迭代。

首先，熟悉一下开眼快创APP中视频编辑页面的基本样式（如下图）：

视频编辑页面有主要以下几个特点：

状态复杂：有太多视频编辑的状态以及当前页面用户操作的中间状态等等。
技术复杂：跨端方案的多端数据类对齐和信息通信效率的提升。
逻辑复杂：变速的需求将时间对齐这件简单事情的复杂度提升了一个次元。
UI复杂：主要复杂在时间轴、视频轴、音乐轴以及音效轴等等。
性能要求高：预览播放时整个页面需根据播放情况更新对应状态，后续优化将主要针对这一点。

基于以上几个特点考虑，在技术方案确定之初，我们也考虑过视频编辑页面是否需要用原生来写，但是毕竟原生开发需要面临很多挑战。相比于市面上很多混编使用Flutter的APP来说，纯Flutter可以在Flutter侧统一管理资源，内存等，因此会避免很多混编的问题，所以我们决定统一都使用Flutter进行编写。

操作复杂性

由于该页面的状态较多，如果采用普通写法的话，把页面进行UI拆分后，各个Widget之间的耦合度会很高，为了解决这个矛盾，我们决定采用Redux处理。

Redux 和 setState

对于一般的StatefulWidget而言，当用户做了某些操作或当其它情况导致Widget中某些状态需要改变的时候，我们会调用setState重绘Widget，从而根据最新的状态展示UI，一般的StatefulWidget只管理几个状态。

而对于Redux而言，它有一个全局的AppState，可以将需要的State挂在这个AppState下，使用Redux的Widget可以提供一个View Model，Redux在属性改变的时候，会对比关心的View Model前后是否相等(所以Model的==方法需要根据开发者自身情况重写)，不相等的时候重写会触发Builder方法进行重绘。

Redux的使用

我们创建了两个State：VideoEditorState和VideoEditorPageState。

VideoEditorState存储了VideoProjectWrapper，其主要用于管理当前正在编辑的视频项目的各种信息，例如添加了几个片段，每个片段需要截取哪段时间，倍速，加了多少音乐，音效字幕等等。

VideoEditorPageState就比较复杂了，当我们进行了几期迭代，但是当回过头再来看它的时候，发现它的状态已经多达40多个（篇幅问题不一一列举，如下图）：

它主要存储了这个页面的各类中间状态，区别于VideoProjectWrapper的信息，这里的信息主要是临时的，且都是以用户操作过程为主的页面展示状态等。

在Redux的结构下，我们可以面向“状态”进行开发，从宏观上来看，就是这个页面所有的Widget面对上面两个State里不同的属性绘制不同的UI即可，Redux会在属性改变的时候触发重绘。从微观上来看，每一个小部分根据自己关心的属性，绘制自己的小部分，然后把所有小部分组装完就是整个页面了。

基于以上的逻辑，我们在后续的一次迭代中对这两个State与整个页面的UI进行了一次梳理和解耦，将庞大的Video_editor_page总页面的很多逻辑都拆分出去了，最终这个页面的Build方法只剩下了这一部分（如下图）：

从上述代码可以看出，我们根据UI结构在最外层做了各个层级的划分，每个大模块都各自区分管理。而这个页面是不会随着Redux的变化而变化的，它就是将所有受Redux变化的Widget按照视频编辑页面的需求进行组装，至于每个部分是如何变化的，它毫不关心。

对于每个部分而言，我们将某个部分中最关心的属性放入其对应的View Model里面，Widget就会在这些属性变化的时候重绘。当Redux触发重绘的时候，用的是StoreConnection里面的Builder方法，而不是这个Widget外的Build方法，这里需要进行区分。

上述简单地体现了当前模块和selectedKey, movingKey, currentVideoTimeUnit, projectWrapper以及movedPosition这5个状态有关联，该模块的UI会在这5个状态中任何一个发生变化而重新触发Builder方法从而重新生成新的Widget。值得注意的是，这里走的是StoreConnection里面的Builder方法，而不是这个Widget外的Build方法，这里需要区分一下。基于以上逻辑，我们通过梳理与拆解的方式，将很多操作和用于状态进行解耦与各个小的Widget配对，从而解决了操作复杂的问题。

技术复杂性

作为一个视频编辑页面的跨端实现，在技术要求上就是比较高的，主要是视频编辑和跨端的结合。

对于视频编辑来说，一般都是底层提供双端的C++实现，双端和编辑SDK有统一的Protobuf（PB）实现三端类统一这些都是现成的。但是对于跨端方案，我们要在这基础上再弄一个统一的Flutter端，让四端信息同步。所以我们采用Flutter_grpc来生成统一的各端类。信息统一之后，我们一样最终要和编辑SDK进行信息同步的，而对于跨端方案，我们需要先将信息给原生端，然后再让原生端按照原生App一样的方式同步给编辑SDK。这样的方案也能实现需求，但是对性能的来说是有折损的。

经过对Dart技术的更进一步的研究，我们发现Dart提供的FFI方案可以实现从Dart端与C/C++端的直接通信，而编辑SDK正是C/C++的实现，所以我们按照FFI方案将编辑的信息和信息同步进行了一个修改，中台部门也对编辑SDK进行了一个对于FFI方案的封装，最终实现了跳过原生，直接与编辑SDK通信的能力。基于以上的方案和优化，我们从技术角度弥补了跨端方案的天然缺陷，让我们效率无限接近原生开发。

逻辑复杂性

基于逻辑复杂的状态和信息处理，变速也成为了我们面对的挑战之一。

视频编辑从根本上来说是将每个片段，音乐以及音效等素材，通过开始时间和时长的信息将对应的UI在轴上体现出来。但是加入变速之后，事情就变得复杂许多。举个例子，如果把没有倍速情况下解决渲染的问题的复杂度假设成n的话，那么增加了倍速需要之后，复杂度就变成n的二次方了。

这是为什么呢？那就需要从变速的实现逻辑来说明。举个例子，在视频编辑中，我们添加两个10秒的片段，那么起初项目的总时长就是20秒。我们将第二段片段进行2倍速调整后，用户看到的第二段素材的时长就是5秒，那么项目总时长也变成了15秒。但是对于编辑SDK来说，这个片段还是两个10秒的片段，只是第二个片段倍速变成了2。基于上面的情况，我们在12秒处添加一段5秒长的音乐。首先，12秒是用户看到的12秒，但是实际上我们给编辑SDK设置的是14秒；其次，音乐时长的5秒也只是用户所感知的5秒，于是这段音乐用户看到的样子是从12秒到15秒（最后一秒裁掉了，时间不够），但是对于编辑SDK来说，这段视频是从 14秒开始，一直到20秒结束，后面裁掉。如果我们将音乐从8秒开始，依旧是5秒的时长，那么显示的时候，前两秒的长度在编辑SDK是1对1对应的，而后面三秒就是1对2对应的，也就是该音乐在编辑SDK看来是从8秒到了16秒结束，对于用户来说就是8秒到13秒结束。

总之，在计算时间的时候，我们需要区分这个时间点和时长具体是“编辑SDK”体系还是“用户感知”体系，两个体系互相转换的过程是需要重新经过计算的。因此，当我们根据时间进行渲染时，需要先过一遍变速的逻辑，斟酌一下当前的这个时间是需要变成用户所看到的时间体系还是编辑SDK处理的时间体系。所以，我们不再通过Double来记录时间，而是通过VideoEditorUserTimeRange和VideoEditorSDKTimeRange来处理，在同一个Project下，VideoEditorUserTimeRange可以通过changeCurrentTimeToTrue来获得VideoEditorSDKTimeRange的时间，反之VideoEditorSDKTimeRange可以通过changeToUserTimeRange来获得VideoEditorUserTimeRange，因此在固定场景下，它们可以很方便的互相转换。

在之后的渲染中，当遇到类型对应不上的情况，我们就知道需要去转换成对应类型的时间再进行渲染或者计算了。通过这样的区分，我们尽可能地将变速带来的复杂度重新降回了无变速时的复杂度。

UI复杂性

UI在表面上的复杂性其实已经通过上述的状态复杂，逻辑复杂等方式解决了，这一部分主要讲另外一个点。

根据最上面的页面UI示例可以发现，中间部分有很多轴，而单个轴之间有像主轴上各个片段的缩略图，像list一样排列的，也有像最后一个轴，音效录音互相叠加的，还有中间音乐音效，可以互相排列，但是也会断开毫无关联。

其实对于这种UI，本能的会想到通过List来渲染，每个部分就是一个Item，可以放空的Item，也可以放实际布局的Item，而且能叠加的需求其实在第一版是没有的。

所以项目最初的方案其实就是放了多个List，然后互相排列，根据自身的时长决定自身的宽度，通过起始时间与前一个素材的结束时间的计算算出两个Item之间需要放一个多宽的空白的Item。

这个方案能满足需求，但是因为自身滚动并不是靠List本身，而是在最外层有一个ScrollView控制着所有的滚动情况以及播放时进度变化的时候改变这个ScrollView的offset。那么这种情况下，List的复用其实是没有起作用的，它是全部渲染，所有性能有问题。同时，对于每个素材来说，我们第一时间能确定的就是这个素材的开始时间和时长，在通过List渲染的时候，我们还需要额外的计算中间的间隙情况，间隙又要结合自己的前面的素材，将前后素材耦合起来。

基于以上问题，渲染采用了Stack的方式，Stack的方式其实就是叠加，在每个轴上面，每个Item根据自己的起始时间计算出左偏移量，根据自身时长计算出宽度，然后根据数组顺序渲染之后，不论挨着排还是叠加还是有缝隙都无所谓，最主要的是所有信息都基于自己的信息，不用管前后情况。所以这里每个轴，包括上面的时间刻度都是通过这种方式来渲染的。

性能方面

视频编辑页面本身就比较吃性能，哪怕是原生写的比较好的其他视频编辑APP，在低端机型上面表现也不佳，这是由于这个业务本身造成的。所以，这个页面更加需要注重性能的优化，尽可能将帧率达到最佳体验。上述很多方面其实在解决问题的同时，也在提升性能，这里主要再额外阐述一下在Flutter编写情况下值得优化的点。

避免额外重绘

在Flutter和Redux的结合下，重绘有两个方式，换句话说，有两个Build方法需要去优化。一个是Widget自己的Build方法，这个方法会在自己创建的时候触发一次，然后会在setState的时候触发一次，因为采用了Redux的方式，视频编辑页面基本不采用setState方式重绘，这里主要讲解创建的这种情况。

正常情况下，我们会根据UI的模块将页面划分成对应的Widget，在Redux下的话，上面也有提及，需要同时将对应的Redux里面的State的属性划分给对应的Widget，除此之外，Widget之间的相互嵌套也是需要讲究的。

举个例子：

如下图所示有一个页面A，上半部分为B，下半部分为C，同时有a,b,c三个状态，a状态变化的时候A需要重绘，b状态变化的时候B需要重绘，c状态变化的时候C需要重绘。

那么在A的Build方法里面，我们会这样写：

乍一看其实没有问题，我们简单分析下，当a发生变化的时候，A的Build方法是不会走的，但是会触发Redux Build A，从而重新创建B和C，而如果B和C重新创建，B和C里面的Build和Redux Build都会重新走一遍。正常情况下本身也没啥问题，因为到了渲染树的时候，你多创建也不影响渲染效率。但是在目前场景下，有两个问题，第一，是违背了Redux的设计原理，我们希望的a状态改变的时候，我们只重绘A，虽然B和C是在A里面，但是B和C是不受a状态变化而影响的，我们不应该重新创建B和C。第二，B和C的Build方法如果需要比较多的计算，那这部分的消耗也是没必要的。所以，在这个基础上，我们可以做一点如下图所示的小小调整。

当然，业务场景下b和c是外界传入的，而不会是在这里创建，基本思路就是通过避免没必要的创建，从而避免没必要的Build方法。

缩略图优化

缩略图的获取也是性能压力的一大环节，从逻辑层面也是比较简单，最初是通过Channel向原生获取的，然后将对应的缩略图在Flutter侧进行缓存，再遇到相同Path和时间的请求直接拿缓存。后来因为添加了手势捏合可以缩放时间刻度，在这个需求下，缩略图不再是1秒取一张了，而是可能是 0.1秒，0.001秒取一张，而缓存那边存的时间是没做处理的，也就是0.0001和0.00001都会去再请求一次。但是其实到了更小的时间刻度下，重复获取这些缩略图是没有意义的，所以基于这个逻辑，缓存的时候时间进行了小数点后两位的处理。

上面其实有提及，FFI的方案其实是现在缩略图获取上面进行验证的，我们通过FFI，直接调用编辑SDK的C++方法来获取缩略图，但是实现之后进行数据对比发现，FFI方案在安卓平台可行，效率是比Channel方案提升了的，但是在iOS平台上面，因为系统自带的缩略图获取的api效率极高，而编辑SDK的缩略图获取效率就没那么高了，因此缩略图的获取目前采用的是安卓FFI，iOS Channel的方式。

缩略图的展示也是一个问题，如果不做优化，在一开始就进行大量的缩略图获取就是没必要的，还需要我们自己额外做优化。这个思路也是进过优化的，最初是遍历了所有的片段，符合需要展示的时间点的片段进行获取，但是每次都要遍历所有的片段。后面根据当前定位时间，改成符合条件的片段，因为片段本身是有序的，所有只需要处理某个区间即可。

帧率优化

上面的优化也会提升帧率，这里主要提及另外一个思路来优化帧率。在视频编辑页面下，对于每一个状态改变，都会有对应需要改变的Widget触发重绘，而不同的状态，改变的频率也是不一样的，例如像CurrentTime这个状态，在播放的时候还有用户快速滑动的时候改变的频率特别高。而面对这种高频率的状态，尽可能让对应需要改变的Widget越少，内部的计算越简单越好。

一个本身就比较高效的计算再往更高效优化是很难的，但是让这个高效的计算触发频率不那么高也可以是另一种优化思路，甚至如果频率降低的很多的情况下，这个计算哪怕稍微降低点效率，总的来看也是更优化的。所以，我们将很多与CurrentTime状态关联的Widget都剥离了出去，对于可一次性渲染全部，并且效率影响不大的轴都采用了整轴全部渲染，而放弃了每个变化渲染局部的方式。只有缩略图，因为一次性获取的压力太大，依旧保持了局部渲染的方式。

总结

总而言之，采用Flutter来编写视频编辑页面有挑战，但是不是不可行，并且经过多次优化之后，在主流机型上面，整个性能都能保持在于原生编写的视频编辑页面差不多的水平。并且，Flutter的视频编辑页面从0到上线，前后花了2个月，人力成本基本就是原生一端的人力情况（这里面绝大部分人还是刚开始接触的Flutter）。所以Flutter的多平台统一，开发效率高，上手快等特点在面对复杂页面的时候，依旧能体现它的优势。技术无边界，优化无止境，我们永远在解决问题的道路上前行。

【快手技术】Flutter系列（三）：Flutter挑战复杂页面！视频编辑页面来袭