闲鱼若何解决iOS情形搭建与APP打包速度问题

由于cocoapod本身的事情事理，pod更新下载工程依赖时，会下载各个版本的文件信息，总量特殊大。
以闲鱼IOS工程为例，统共须要下载近20G的缓存文件，而且大部分都是几K的小文件，下载韶光可能会持续十几个小时，导致新环境搭建到初次体验韶光跨度非常久。

切分后APP打包慢

当开拓同学在多个分支/版本开拓的时候，时常须要切换分支开拓调试和bugfix。
但是切换分支之后，全体IOS工程打包韶光在30-40分钟旁边。
有时候为了修复一个版本的bug，不得不切换分支，然后重新打包调试。
修复和验证bug可能只须要五分钟，打包却用了30多分钟，投入产出不成比例。

为理解决这些存在的问题，我们进行了一些列的探索，跟大家一起分享下，也欢迎有更好的办理方案涌现。

IOS环境搭建

虚拟化技能的不断发展，为我们统一端侧开拓环境供应了新思路，我们设想如果IOS开拓环境能够跟Mac解耦，且可以移植，大家可以轻松复用，那么第一二个问题就迎刃而解了。
为此我们做了几个考试测验：

虚拟机方案

在MacOS本地搭建虚拟机，内装MacOS系统。
在虚拟机内搭建IOS开拓环境，然后通过虚拟机镜像copy实现IOS开拓环境移植，办理环境搭建难题。

这个方案存在以下几个问题：

a. 性能问题，IOS的编译过程是一个IO密集型和CPU密集型操作，虚拟机通过虚拟HOST系统的磁盘和CPU，性能会大打折扣，导致编译韶光变长，影响开拓体验。

b. 安全问题。
在Mac事情机安装虚拟机，须要通过公司安全审核。

c. 黑苹果问题：虚拟机内的Mac系统是没有经由授权的，会带来盗版侵权风险。

虚拟机是比较重的虚拟化技能，因此我们转向了更加轻量化的docker技能。

完备Docker化

将IOS开拓依赖的软件和环境变量全部docker化。
通过docker镜像实现IOS开拓环境的移植。
对付cocoapod, taobaoenv等ruby类工具，鉴于ruby的跨平台特性，可以很方便的迁移到docker内。
但是对付强依赖MacOS的XCode，我们考试测验用Facebook出品的xcbuild替代。
这是一款兼容xcodebuild的编译工具，网上也确实有网友用这个软件搭建IOS编译环境。

这个方案存在以下几个问题：

a. Xcbuild跟Xcodebuild的兼容性无法评估

b. 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增量编译了呢？事实确实如此。

详细方案：

在切分之前缓存当前分支的Pods Project, Flutter Project以及编译的中间产物，Podfile.lock, linkmap等等干系文件。

切换分支

规复新分支之前缓存的中间产物

重新打包IOS APP。
通过这两步优化，我们将闲鱼IOS工程切分支后的打包韶光由原来的30-40分钟降落到五分钟以内，效率提升近六倍。

总结

IOS环境搭建中繁芜和耗时的步骤，通过docker镜像和缓存优化后，搭建的难度大大降落，IOS新手也基本可以在三小时内搞定

同时，通过缓存和复用打包过程产生的中间产物，切换分支后的打包耗时掌握在五分钟内，降落为原来的六分之一，提升了开拓效率。