iOS开发体验存在的问题
▐ 开发环境搭建难
开发环境依赖特定软件版本，配置复杂
闲鱼iOS工程不仅依赖XCode，还依赖了taobaoenv 1.2.0和cocoapods 1.2.0这两个包管理工具。根据大家的经验，这两个工具在ruby2.3.x时，问题较少。特定软件版本，系统自带软件版本冲突，环境变量设置等等一些列的操作步骤导致环境搭建复杂，需要求助iOS开发同学才能搞定。
维护难
Mac系统升级后，cocoapod容易出现问题，不得不重新搭建开发环境。具体原因也是多种多样：系统环境变量变了，导致找不到特定版本ruby；ruby随系统升级导致cocoapod不能用，需要重新安装；Gem版本问题；Ruby源问题等等。这也导致许多开发同学不敢轻易的去升级系统，无法及时体验到新系统的特性。
Pod依赖下载量大
由于cocoapod本身的工作原理，pod更新下载工程依赖时，会下载各个版本的文件信息，总量特别大。以闲鱼iOS工程为例，总共需要下载近20G的缓存文件，而且大部分都是几K的小文件，下载时间可能会持续十几个小时，导致新环境搭建到初次体验时间跨度非常久。
▐ 切分后APP打包慢
当开发同学在多个分支/版本开发的时候，时常需要切换分支开发调试和bugfix。但是切换分支之后，整个iOS工程打包时间在30-40分钟左右。有时候为了修复一个版本的bug，不得不切换分支，然后重新打包调试。修复和验证bug可能只需要五分钟，打包却用了30多分钟，投入产出不成比例。
为了解决这些存在的问题，我们进行了一些列的探索，跟大家一起分享下，也欢迎有更好的解决方案出现。
iOS环境搭建
虚拟化技术的不断发展，为我们统一端侧开发环境提供了新思路，我们设想如果iOS开发环境能够跟Mac解耦，且可以移植，大家可以轻松复用，那么第一二个问题就迎刃而解了。为此我们做了几个尝试：
▐ 虚拟机方案
在MacOS本地搭建虚拟机，内装MacOS系统。在虚拟机内搭建iOS开发环境，然后通过虚拟机镜像copy实现iOS开发环境移植，解决环境搭建难题。
这个方案存在以下几个问题：
性能问题：iOS的编译过程是一个IO密集型和CPU密集型操作，虚拟机通过虚拟HOST系统的磁盘和CPU，性能会大打折扣，导致编译时间变长，影响开发体验。
安全问题：在Mac工作机安装虚拟机，需要通过公司安全审核。
黑苹果问题：虚拟机内的Mac系统是没有经过授权的，会带来盗版侵权风险。
虚拟机是比较重的虚拟化技术，因此我们转向了更加轻量化的docker技术。
▐ 完全Docker化
将iOS开发依赖的软件和环境变量全部docker化。通过docker镜像实现iOS开发环境的移植。对于cocoapod, taobaoenv等ruby类工具，鉴于ruby的跨平台特性，可以很方便的迁移到docker内。但是对于强依赖MacOS的XCode，我们尝试用Facebook出品的xcbuild替代。这是一款兼容xcodebuild的编译工具，网上也确实有网友用这个软件搭建iOS编译环境。
这个方案存在以下几个问题：
Xcbuild跟Xcodebuild的兼容性无法评估
xcode升级后，xcbuild跟进升级兼容的一段时间内，只能回退到原来的开发方案，来回切换开发环境，体验差。
上面两个方案都没有很好的解决iOS开发环境移植和解耦的问题，但是在完全docker化的尝试中，我们发现最复杂的cocoapod和ruby安装配置部分是能够docker化的，xcode安装后并不需要特殊的配置，因此我们设计实现了一个折中方案：Host内开发（部分docker化）
▐ Host内开发（部分docker化）
本方案中：开发编译调试工作仍然在MacOS本地，使用xcode; 而将cocoapod和taobaoenv相关的软件和环境变量配置等docker化。这样既遵循了开发同学一贯的开发体验，又兼顾了开发环境的可移植问题。
为了能够让Docker内cocoapod拉取的依赖文件和生成的pod工程能被本地的XCode识别，我们将本地pod缓存目录挂载到docker，这样Pod拉取的依赖既能在docker内更新，也能在MacOS中被XCode访问，具体如下图（统一编程平面端+Faas软件架构图）：
这样既做到了简化开发环境搭建的复杂度，方便了想尝试iOS开发的同学快速搭建环境，还能给开发同学无差别体验。而且通过这个方案，我们的iOS开发环境可以方便的在各个同学的开发环境中迁移，而且也可以统一进行升级改造。
本方案将Pod相关的依赖迁移到了Docker中，与MacOS解耦，因此iOS开发同学可以自由升级Mac系统，不用担心开发环境被破坏,解决了维护难的问题。
为了解决新搭建的环境需要大量拉取pod依赖的问题，我们将pod的本地中间文件上传到OSS云盘（上图蓝色OSS云盘），开发同学只需要一次性下载压缩包并解压到本地，然后增量更新就可以了。
切分支后APP打包速度问题
客户端开发同学经常需要在多个分支（版本）上面开发业务，且时常需要来回切换进行业务开发和问题定位。这带来的一个问题是：当开发同学从A分支切换到B分支的时候，需要重新打包APP，整个过程大概需要30-40分钟左右。
在分析了闲鱼iOS工程打包过程后，我们将耗时锁定在两个阶段：Pod操作和XCode编译。打包速度优化也将分为两个阶段进行：
▐ Pod操作加速
Pod install/update主要的工作是读取Podfile，进行依赖版本控制和冲突解决，并生成Pod工程。生成的相关文件存储在Pods目录和Pods.xcodeproj中。当切换回之前分支时，Podfile经常是不会发生变化的，因此重新生成pod工程实属浪费。
经过测试，如果我们将这些中间文件保存起来，多次切换分支后，这些中间文件仍然能够还原之前的Pod工程，从而避免切分支后重新生成Pod工程的步骤，省去10分钟左右的开销。
▐ XCode编译速度优化
对于XCode编译速度优化，网上有很多方案，大致可以分为三类：
Cocopods依赖编译加速：
比如cocoapods-packager，它可以将pod依赖打包成static library,IOS工程以静态库的形式引入pod依赖，省去重复编译的时间。
但是这个方案也存在一些问题；私有库和第三方库更新很麻烦，每次都需要重新打包静态库，并上传到代码仓库；且很难调试源码
分布式编译：比如distcc
分布式编译的原理是将需要编译的文件分散到编译集群的其他机器上编译，然后将编译好的二进制文件传回。本地编译器再将这些二进制文件链接在一起。分布式编译对于大工程提速明显，但是对于小工程，反而会拖累编译速度。
缓存编译的中间结果：CCache，BUCK
更为广泛的加速方案是缓存编译的中间结果，比如CCache，Buck等，这些方案，网上有详细的资料，不再一一赘述。但是引入这些方案，都需要对目前的iOS工程进行改造，甚至需要改变用户的开发习惯，因此不符合我们的要求。但是缓存中间编译结果的方案给我们提供了一些启发：
我们知道XCode是具有增量编译能力的，这其实也是利用了上一次编译的中间产物，本地再次编译的时候，如果发现文件没有变化，则忽略这个文件，如果源码文件时间戳更新了，那么就重新编译这个文件，因为每次变化的源码都是少量的，这样就可以达到加快编译速度的目的。
对于闲鱼iOS工程，如果我们在切分支之前保存当前iOS分支编译的中间产物，然后在切换回当前分支的时候，恢复之前保存的中间产物，那么是不是就可以触发XCode增量编译了呢？事实确实如此。
具体方案：
1、在切分之前缓存当前分支的Pods Project, Flutter Project以及编译的中间产物，Podfile.lock, linkmap等等相关文件。
2、切换分支
3、恢复新分支之前缓存的中间产物
4、重新打包iOS APP。
通过这两步优化，我们将闲鱼iOS工程切分支后的打包时间由原来的30-40分钟降低到五分钟以内，效率提升近六倍。
总结
iOS环境搭建中复杂和耗时的步骤，通过docker镜像和缓存优化后，搭建的难度大大降低，iOS新手也基本可以在三小时内搞定。
同时，通过缓存和复用打包过程产生的中间产物，切换分支后的打包耗时控制在五分钟内，降低为原来的六分之一，提升了开发效率。
关注「淘系技术」微信公众号，一个有温度有内容的技术社区~
