阅读 1175

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

作者:腾讯 - 小德(koudleren 任晓帅)

存在的问题

为了使用Flutter,刚开始的时候为了快速上线,采用将Flutter和Native代码混合开发的模式,具体的工程目录如下:

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

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

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

  1. 不开发Flutter的同学也必须得配置Flutter的SDK

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

  1. 无法做持续集成

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

  1. 本地编译环境无法统一

因为第三点的原因,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工程里。

  1. 本地开发,服务端构建

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

  1. 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工程没有影响。

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

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

  1. 实现了Flutter的持续集成

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

结语

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