Flutter持续化集成上的演进之路

作者：腾讯 - 小德（koudleren 任晓帅）

##存在的问题 为了使用Flutter，刚开始的时候为了快速上线，采用将Flutter和Native代码混合开发的模式，具体的工程目录如下：

可以明显的看到工程目录很乱，android目录下有多个代码目录，lib目录下是dart代码，images目录下是Flutter所用到的图片等资源，而且竟然还包含了iOS的代码。如此混乱的目录给我们带来了四个问题：

** 1、需要对Native工程进行了大量的改造 **

为了将Flutter集成到Native工程里，对Flutter和Native的目录和编译脚本都进行了大量的改造，对原来Native的工程影响比较大。

** 2、不开发Flutter的同学也必须得配置Flutter的SDK **

因为Flutter的开发需要Flutter SDK的环境，但是团队内并不是所有人都做Flutter的开发，如果要求每个人都安装Flutter SDK的环境，无疑带来了额外的开发成本。

** 3、无法做持续集成 **

因为Flutter编译需要Flutter的编译环境，但是现有的持续集成的环境没有Flutter的环境，使得Flutter无法做到持续集成。

** 4、本地编译环境无法统一 **

因为第三点的原因，Flutter是本地编译的，可是每个人Flutter SDK的环境很不容易统一，例如SDK版本的差异或者系统的差异，会导致Flutter编译产物不一致，从而影响现网的表现，出现iOS和Android表现不一致的情况，甚至会因为SDK版本不匹配造成App的crash。

改进开发模式

针对上面的问题，我们转而采用了如下的开发模式：

** 1、Flutter工程和Native工程分开 **

将Flutter和Native剥离，Flutter是单独的工程，Native也是单独的工程，这样从工程上面就将Flutter和Native彻底分开，两者互不影响，Native工程不在需要改造，单独打开Native工程也不需要配置Flutter SDK的环境。在Flutter工程里编译Flutter的产物，然后集成到Native工程里。

2、本地开发，服务端构建

在本地开发Flutter，但是将编译构建的工作交给服务端来做，因为服务端的Flutter SDK的环境是唯一的而且可控的，这样不管有几个开发者，本地环境有多复杂，Flutter的构建都在服务端，保证了Flutter构建产物的一致性。

3、Flutter构建产物自动同步

在服务端触发Flutter的编译，如果编译成功，会自动将最新的Flutter产物同步到Native工程里，保证Native的工程里的Flutter产物是稳定的而且是最新的，可以及时看到最新的更改的Flutter页面。

这里持续集成服务是用QCI搭建的。 ##改进后的效果

经过以上的改造，工程目录如下：

可以明显看到工程目录清晰了很多，fluttersdk目录下是Flutter的构建产物，对于原来的Native工程来说就是一个module，flutternew目录下是Flutter的业务代码，flutternew依赖fluttersdk，flutternew也是Native工程的一个module。经过改造，可以达到如下的效果：

1.实现Flutter对原来Native工程的非侵入式集成

Flutter只是Native工程的一个module，和其他Native的module是平级的，Naitvie也不需要关心Flutter model的环境，对原来的Native工程没有影响。

2.保证Flutter编译环境的唯一性

因为Flutter的编译都是在服务端进行的，这样就保证了Flutter编译环境的唯一性，iOS和Android都是在同一份代码同一个编译环境下构建的，也就保证了Flutter产物的稳定性。

3、实现了Flutter的持续集成

Flutter的代码提交之后，会自动触发Flutter的构建，可以很容易知道此次的变更是否有问题，最新的Flutter构建产物也会自动同步到Native的工程里。

##结语 经过改进Flutter的开发模式，目前已经实现了对Flutter的敏捷开发和持续集成,实现了多团队协作远程构建产出的模式。