项目多版本的一次实践 - ShenYj/ShenYj.github.io GitHub Wiki

在2021年4月份 ~ 10月份间，先后做了两个项目，这两个项目都有一个要求：多版本

结合iOS的多环境配置方案对比、业务需要，我的实现思路是

xcconfig + scheme的单Target方式, 通过xcconfig完成版本的配置，环境变量及参数的配置

scheme配合configurations和swift other flags完成构建、证书、代码层处理

为什么？

首先说下方案的不足之处：所有的资源（SDK、图片等）都会被打进ipa，比如两个app的图片都会被包含，会造成包的体积变大

好在虽然是多版本的项目，但我们两个app的区别也仅限于样式：色值、图片，SDK最初只有三网取号时计划采用不同的方案，但最终都是使用的移动一键取号SDK，而其他的地图、支付、推送等等都是一致的功能；而图片说少不少，说多也不多，抛去一些公用的， 个别的还是手动代码层渲染的色值后使用的，所以冗余的图片并不是很多

target本身就是为了控制指定代码和资源文件的具体构建方式，但是我在入职这家公司的时候接手了一个N手的SDK项目，这个项目就是多Target的方案，几十个target，xcode本身对target这种支持就不够好，过多会导致xcode解析变慢，而且加上这个老项目年久失修，很多target都不维护了，也不知道是误操作还是什么原因， 某些target下存在错误，比如文件缺失等直到升级xcode后一点点暴露出来，大概就是每逢升级项目就跑步起来，所以给我留下了不好的印象

实现效果

简单的说明

通过配置实现了一套代码根据3套证书输出三个app

默认的debug、release配置的部门内的个人账号，已经没啥用处了，所以在scheme中隐藏了

接下来说明下Debug、Dokit和Release的区别

• Debug

  是日常开发调试的环境，包含log输出

• Dokit

  在Debug的基础上，开启了滴滴的Dokit调试工具，比如mockAPI等功能，同时该配置下开启了RxSwift的引用计数，用于检测RxSwift的内存，防止泄露

• Release

  用于CI/CD送测使用，这里是基于开发证书打包的，部门使用的Jenkins流水线2.0 构建方式，构建是针对不同语言项目用Groovy写的一套构建项目，限制的有点死，其他的iOS项目都是基于分支构建的，经过尝试，暂时改成了deploy-choice的方式，将deploy-choice与项目的scheme绑定进行构建

其实多环境配置并不一定是项目多版本的场景下才会用到，比如测试推送这种需求，完善的方案应该是有单独的一套环境的，这样能避免事故，而我暂时的方案是没有针对推送做环境配置的

公司之前的多个iOS并没有为生产环境配置自动构建，Jenkins的自动构建和交付都是针对内部（测试）的（代码扫描、单元测试、构建、内网部署），所以后期项目我也没加，生产的包都是走的脚本或者直接xcode打包

目前满足的场景还算是比较简单的，如果想要满足的场景更多，项目的结构也就更复杂，一定要做好文档，便于后人维护