一、前言

微盟商户助手的组件化开发已有三年有余，随着业务的不断扩增，组件也越来越多，从原来的账号、零售、美业、餐厅、客来店几条业务线扩展至酒店、旅游、会务等十几条业务线。组件越来越多，代码量也越来越大，伴随而来的便是编译和打包时间越来越长，如果把DerivedData删除，无缓存全量编译竟然达到了令人无法忍受的45分钟左右（以我的Mac2015 8 GB 1867 MHz DDR3为参考），极大影响了团队小伙伴的开发效率，因而缩短编译和打包时间迫在眉睫。

那么如何缩短编译时间呢，我们知道iOS主要有以下三种方式：
1.优化工程配置
如Debug时Build Active Architecture Only设为NO，Debug Information Format改为DWARF，使用PCH等
2.使用第三方工具
如缓存插件CCache、分布式编译工具distcc等
3.组件二进制化
其中第三点的效果最立竿见影，原因在于二进制已经是编译好后的产物，在iOS中形式为Framework，本文重点针对这点讲述我是如何在商户助手App中进行组件二进制化的。

文章将从以下三个方面进行介绍
一、组件集成方式
二、组件打包
三、源码和二进制之间切换

二、组件集成方式

在商户助手App中组件的引入方式有两种：
1.手动创建Framework，在主工程中的pofile文件中对声明此target第三方依赖；
2.通过cocopods自动管理，在podspec文件中声明第三方依赖。
那么这两种方式有什么区别呢，见下表

通过上述比较，可见各有优劣，至于选择哪种还得根据实际项目情况而来，从个人而言推荐后者，原因后文会谈及。

两种不同的组件方式，打包的方式自然也就不一样。

三、组件打包

3.1 脚本打包

手动创建的Framework，打包步骤如下：
1.配置打包环境：Mach-O Type设为Static Library；暴露所需头文件；Build Active Architecture Only设为NO等。
2.分别在模拟器和真机下编译。
3.通过lipo命令打出模拟器和真机的合并包。

如果每个组件的打包都按部就班使用上述步骤完成，必定影响工作效率。好在有脚本的帮助，把这些步骤写在脚本中，按下回车就可以解放你的双手。

#!/bin/sh

# 存放所以二进制文件的基地址
BASEBUILD_DIR="${SOURCECODE_DIR}/DerivedData/Build/Products"

# 支持真机的二进制文件目录
IPHONE_DEVICE_BUILD_DIR="${BASEBUILD_DIR}/iphoneos"

# 支持模拟器的二进制文件目录
IPHONE_SIMULATOR_BUILD_DIR="${BASEBUILD_DIR}/iphonesimulator"

# 合并后的二进制文件目录
UNIVERSAL_OUTPUT_FOLDER="${BASEBUILD_DIR}/Combine_Products"

# 最终更新组件的路径
TARGET_FRAMEWORK_DIR="$4/${TARGET_NAME}/Frameworks"

# 最终更新资源的路径
TARGET_ASSETS_DIR="$4/${TARGET_NAME}/Assets"

#创建输出目录，并删除之前的framework文件
rm -rf "${IPHONE_SIMULATOR_BUILD_DIR}/${CONFIGURATION}-iphonesimulator/${TARGET_NAME}.framework" "${IPHONE_DEVICE_BUILD_DIR}/${CONFIGURATION}-iphoneos/${TARGET_NAME}.framework"
rm -rf "${IPHONE_SIMULATOR_BUILD_DIR}/${CONFIGURATION}-iphonesimulator/libPods-${TARGET_NAME}.a" "${IPHONE_DEVICE_BUILD_DIR}/${CONFIGURATION}-iphoneos/libPods-${TARGET_NAME}.a"

mkdir -p "${UNIVERSAL_OUTPUT_FOLDER}"
rm -rf "${UNIVERSAL_OUTPUT_FOLDER}/${TARGET_NAME}.framework"

#分别编译模拟器和真机的Framework
buildFramework()
{
PODS_PROJECT="${SOURCECODE_DIR}/XYMainApp/Pods/Pods.xcodeproj"

PROJECT_DIR="${SOURCECODE_DIR}/$1/$1.xcodeproj"

echo "target路径 $1/$1"

echo "===== 正在构建Pods-$1====="
echo "===== 模拟器 ====="
xcodebuild -project ${PODS_PROJECT} -target "Pods-$1" ONLY_ACTIVE_ARCH=NO -configuration "${CONFIGURATION}" -sdk iphonesimulator BUILD_DIR="${IPHONE_SIMULATOR_BUILD_DIR}" BUILD_ROOT="${IPHONE_SIMULATOR_BUILD_DIR}" ARCHS='x86_64 i386' VALID_ARCHS='x86_64 i386' build -UseModernBuildSystem=NO

echo "===== 真机 ====="
xcodebuild -project ${PODS_PROJECT} -target "Pods-$1" ONLY_ACTIVE_ARCH=NO -configuration "${CONFIGURATION}" -sdk iphoneos BUILD_DIR="${IPHONE_DEVICE_BUILD_DIR}"  BUILD_ROOT="${IPHONE_DEVICE_BUILD_DIR}" ARCHS='armv7 armv7s arm4' VALID_ARCHS='armv7 armv7s arm64' build -UseModernBuildSystem=NO

echo "===== 正在构建$1====="
echo "===== 模拟器 ====="
xcodebuild -project "${PROJECT_DIR}" -target "$1" ONLY_ACTIVE_ARCH=NO -configuration "${CONFIGURATION}" -sdk iphonesimulator BUILD_DIR="${IPHONE_SIMULATOR_BUILD_DIR}" BUILD_ROOT="${IPHONE_SIMULATOR_BUILD_DIR}" ARCHS='x86_64 i386' VALID_ARCHS='x86_64 i386' build  -UseModernBuildSystem=NO

echo "===== 真机 ====="
xcodebuild -project "${PROJECT_DIR}" -target "$1" ONLY_ACTIVE_ARCH=NO -configuration "${CONFIGURATION}" -sdk iphoneos BUILD_DIR="${IPHONE_DEVICE_BUILD_DIR}"  BUILD_ROOT="${IPHONE_DEVICE_BUILD_DIR}" ARCHS='armv7 armv7s arm64' VALID_ARCHS='armv7 armv7s arm64' build -UseModernBuildSystem=NO

#拷贝framework到univer目录
echo "拷贝framework到univer目录"
echo "${IPHONE_DEVICE_BUILD_DIR}/${CONFIGURATION}-iphoneos/$1.framework"
echo "拷贝framework到univer目录"
cp -R "${IPHONE_DEVICE_BUILD_DIR}/${CONFIGURATION}-iphoneos/$1.framework" "${UNIVERSAL_OUTPUT_FOLDER}"

#合并framework，输出最终的framework到build目录
echo "合并framework，输出最终的framework到build目录"
lipo -create "${IPHONE_DEVICE_BUILD_DIR}/${CONFIGURATION}-iphoneos/$1.framework/$1" "${IPHONE_SIMULATOR_BUILD_DIR}/${CONFIGURATION}-iphonesimulator/$1.framework/$1" -output "${UNIVERSAL_OUTPUT_FOLDER}/$1.framework/$1"

#删除编译之后生成的无关的配置文件
dir_path="${UNIVERSAL_OUTPUT_FOLDER}/$1.framework/"
for file in ls $dir_path
do
if [[ ${file} =~ ".xcconfig" ]]
then
rm -f "${dir_path}/${file}"
fi
done

#清除组件build文件
if [ -d "${SOURCECODE_DIR}/${1}/build" ]
then
rm -rf "${SOURCECODE_DIR}/${1}/build"
fi
}

buildFramework ${TARGET_NAME}

#清除主工程build文件
if [ -d "${SOURCECODE_DIR}/XYMainApp/build" ]
then
rm -rf "${SOURCECODE_DIR}/XYMainApp/build"
fi

# 拷贝asset资源
ASSETS_DIR=$(find ${SOURCECODE_DIR}/${TARGET_NAME} -name ${TARGET_NAME}.xcassets)
mkdir -p "${TARGET_ASSETS_DIR}"
rm -rf "${TARGET_ASSETS_DIR}/${TARGET_NAME}.xcassets"
cp -R "${ASSETS_DIR}" "${TARGET_ASSETS_DIR}/${TARGET_NAME}.xcassets"

mkdir -p "${TARGET_FRAMEWORK_DIR}"
# 覆盖framework
rm -rf "${TARGET_FRAMEWORK_DIR}/${TARGET_NAME}.framework"
cp -R "${UNIVERSAL_OUTPUT_FOLDER}/${TARGET_NAME}.framework" "${TARGET_FRAMEWORK_DIR}/${TARGET_NAME}.framework"

# 打开合并后的文件夹
open "${TARGET_FRAMEWORK_DIR}"

这里值得一提的是每个组件都是一个target，执行pod install后，会生成对应的target，名称为‘target-库名’，所以需要先对其进行编译，否则打包会失败。
由于组件比较多，为了提高打包效率，写了个小工具，可以自由切换组件进行打包，它的本质还是执行以上脚本。

3.2 Cocopods-packager打包

cocoapds家族提供了可以将pod库打包成静态库的插件cocoapods-packager，它的安装十分简单，只需要执行gem install cocoapods-packager命令即可，使用它对项目中的组件进行打包的前提是必须配置好了podsepc文件，因为它是依据此文件来锁定源码、资源、系统和第三方依赖、环境配置等信息。
以助手App中的XYPublicClasses的podspec文件为例：

s.source           = { :git => '组件git地址'}
s.source_files = 'XYPublicClasses/Classes/**/*.{h,pch,m}'
s.public_header_files = 'XYPublicClasses/Classes/**/*.{h,pch}'
s.prefix_header_file = 'XYPublicClasses/Classes/Supporting Files/Config/XYPrefixHeader.pch'
s.resources = ['XYPublicClasses/Classes/**/*.{xib,storyboard,plist,png,bundle,wm}']
s.dependency 'WechatOpenSDK'
s.dependency 'AFNetworking'
s.dependency 'YYKit'
s.dependency 'Masonry'

确保配置完基本信息后，便是执行pod package命令进行打包

pod package  XYPublicClasses.podspec --no-mangle --force --exclude-deps  --spec-sources=依赖的私有库地址

几个参数的介绍

-no-mangle：即Do not mangle symbols of depedendant Pods。
            如果组件有其他依赖项，必须填写，否则会报Undefined symbols for architecture 错误
--force：强制覆盖之前打包好的Framework
--exclude-deps：不包含依赖的符号表。动态库不能加，但我们项目中使用的是静态库，需加上。
--spec-sources：依赖的私有库地址，注意官方源https://github.com/CocoaPods/Specs.git也需要加上
--subspecs：批量生成subspec的二进制库，每一个subspec的库名就是podspecName+subspecName

打包完成后，查看Framework的大小是否正常，我在刚开始尝试的时候，发现包的大小竟然只有1KB，反复查找原因发现是podspec没有配置正确，修改后打包成功。

通过上述两种方法成功得到Framework后，那么问题来了：如何在项目中使用呢？接下来便是要讨论如何在源码和二进制之间快速切换。

四、源码和二进制切换

依赖于cocoapods方式切换的方案有两种：
方案一：在podspec中使用ENV环境变量，执行pod install时指定SOURCE的值来切换，但此方案的弊端是每次切换都需要pod cache clean清理缓存，后续再执行pod install时又需要再重新拉一遍代码，这一步的快慢取决于你配置的代理源和网络快慢了。

  if ENV['SOURCE']
    puts '配置源码、资源等信息'
  else
    puts '配置之前打包好二进制、资源等信息'
  end

方案二：通过subspec切换，和方案一比起来除了外层条件判断不一样，内层配置信息保持一致，好处就是不需要清理缓存，这也是我在项目当中使用的方案。

首先，需要改造一下上面所提到podspec文件配置，增加subspec来区分源码和二进制

  s.subspec 'Source' do |ss|
     ss.source_files = '路径'
     puts '配置源码、资源等信息'
  end
 
  s.subspec 'Framework' do |ss|
     ss.ios.vendored_framework = '二进制路径'
     puts '配置之前打包好二进制、资源等信息'
  end

其次，在podfile中引入，并执行pod install即可

pod '库名', :path =>'库路径',:subspecs => 'Source或者Framework'

至此新的问题产生了：
一、每个小伙伴切换源码和二进制的组件可能都不一样，如果都在主工程中pofile修改，执行install后，主工程势必冲突连连。好在主工程不承载业务代码，作为一个壳子代码已长期稳定，我的做法就是拷贝一份主工程，这样既避免了冲突问题，也加速了编译速度。
二、手动创建的Framework在podfile中原有的源码依赖是target ‘组件名’ do方式，如果要切换至二进制库，这种方式就得注释掉，来回切换显得比较麻烦，不如pods管理的库更加简洁纯粹，只需要改变Source或者Framework的变量即可。从这一点上来说，这也是我更推荐使用它的原因。

最后，编译整个项目，依然还是踩到几个坑，记录如下：
1.duplicate symbol
使用pod package打出来的静态库，需要加上参数–exclude-deps，不包含依赖的符号表。
2.图片显示异常问题
在podspec中资源引入的方式有两种：resource_bundles和resources。这两者的主要区别在于前者会把资源打入指定bundle中，可以减少命名冲突，但是代码引入时需要指定此bundle，而后者则直接把资源平铺在主bundle中，这样如果不同组件中有相同命名的图片则会导致显示异常问题。
在商户助手中，使用的是resources方式引入，因为不同组件要求资源必须指定前缀，从而避免命名冲突导致的异常问题，并且图片资源是放在xcassets中的，这样组件的assets和主工程的xcassets会合并成一个car文件，使用时直接指定名称即可，而不需要如resource_bundles方式必须指定自定义的bundle。

s.resources = ['path/Assets/*.xcassets']

3.没有权限访问.app
原因在于方式一打包出来的Framework中包含Info.plist，而资源的配置项是*.plist，导致编译时把主工程的Info.plist覆盖，因而无法打开app。
解决方法有两种：组件中Info.plist非必要，可以删除；或者在podspec使用exclude_files忽略此文件

s.exclude_files = 'path/Info.plist'

五、总结

执行完上述步骤后，项目的编译速度有了质的提高。

当然，提升编译速度是一场持久战，随着项目的迭代，仍然需要不断寻求最优解。

六、参考资源

Cocoapods-packager官方文档

Podfile语法参考（译）