作者：腾讯 - 小德（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无法做到持续集成。
扫描二维码关注公众号，回复： 4532027 查看本文章
** 4、本地编译环境无法统一 **
因为第三点的原因，Flutter是本地编译的，可是每个人Flutter SDK的环境很不容易统一，例如SDK版本的差异或者系统的差异，会导致Flutter编译产物不一致，从而影响现网的表现，出现iOS和Android表现不一致的情况，甚至会因为SDK版本不匹配造成App的crash。
改进开发模式
针对上面的问题，我们转而采用了如下的开发模式：
将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的敏捷开发和持续集成,实现了多团队协作远程构建产出的模式。