iOS 组件化(一) - CocoaPods原理理论篇
iOS 组件化(二) - 远程/本地管理私有库
iOS 组件化(三) - 组件化工程介绍
一、前言
1.了解组件化
组件化就是将单一工程的项目按照功能职责或者业务职责划分成一个一个模块，模块间解耦调用。
2.组件化解决耦合问题
当一个项目开发初期的时候，开发人员较少，业务较为简单，此时采用单一工程开发的模式,能保证开发效率。当项目越来越大，开发人员越来越多，单一工程开发就会有一些弊端，诸如：
- 代码耦合严重
- 提交容易出现冲突
- 编译时间太长导致开发效率低
- 代码冗余严重(相同功能代码可能反复被实现)
3.组件化的好处
- 加快编译速度,不需要编译整个项目(每个组件都有一个壳工程)
- 方便做针对性测试
- 代码解耦后更利率开发职责的划分
- 不容易出现代码提交冲突
4.使用组件化面临的问题
不是所有APP都适合走组件化的路子，盲目的为了组件化而组件化反而会因为各种原因导致开发效率变低。例如一个两三个人维护业务简单的项目，组件化的解耦调用可能会导致代码逻辑变复杂。组件化粒度过细也会一个业务需求需要修改多个组件也容易让代码追踪变得困难，与对应组件负责人的沟通也会拖慢开发的进度。业务简单项目易管理就不需要用到组件化了。
二、远程私有索引仓库
1.创建远程私有索引仓库
我这里以码云平台为例
就像我们在公司创建项目一样，我这里就叫WJSpec
(最好勾选readme功能成使用说明文件)
创建完后就可以获得下载链接 https://gitee.com/xxx/WJSpec.git
2.将远程仓库Spec关联到本地的repos里
终端定位到CocoaPods的repos，并且进行关联
$ cd /Users/用户名/.cocoapods/repos
$ pod repo add WJSpec https://gitee.com/xxx/WJSpec.git
执行成功后，我们可以看到repos目录下就拥有我们自己的私有索引库了
至此远程私有索引仓库创建就完成了。
接下来要生成我们的组件啦。
三、私有组件工程（本地和远程）
1.创建本地私有代码
在桌面创建一个名为Modules的文件夹，打开终端使用pod命令创建组件工程，取名为WJCommon
cd /Users/xxx/Desktop/Modules
pod lib create WJCommon
结束之后会生成一个工程 (Example是可运行的工程项目)
将组件的代码文件拷贝到Classes
将组件的资源文件(如png、xib)拷贝到Assets
(下一章节还会详细介绍组件的各个配置和组件依赖等等)
修改组件工程里的WJCommon.podspec文件：
自行修改对应的远程组件工程的地址
（PS：WJCommon的远程组件地址的生成部分内容在下面）
Pod::Spec.new do |s|
s.name = 'WJCommon' # 库名称
s.version = '0.0.1' # 版本号
s.summary = 'Swift 工具类组件' #对组件的简述
# This description is used to generate tags and improve search results.
# * Think: What does it do? Why did you write it? What is the focus?
# * Try to keep it short, snappy and to the point.
# * Write the description between the DESC delimiters below.
# * Finally, don't worry about the indent, CocoaPods strips it!
#对组件的描述
s.description = <<-DESC
TODO: Add long description of the pod here.
DESC
#此处为远程仓库地址，要去掉 /xxx.git
s.homepage = 'https://gitee.com/xxx'
# s.screenshots = 'www.example.com/screenshots_1', 'www.example.com/screenshots_2'
s.license = { :type => 'MIT', :file => 'LICENSE' }
#作者邮箱
s.author = { '作者名称' => 'xxx@qq.com' }
#库地址、当前的版本号
s.source = { :git => 'https://gitee.com/xxx/WJCommon.git', :tag => s.version.to_s }
# s.social_media_url = 'https://twitter.com/<TWITTER_USERNAME>'
s.ios.deployment_target = '10.0' # 依赖最低版本
# 开放的库文件
s.source_files = 'WJCommon/Classes/**/*'
# 开放的库资源文件 - 有资源则需要打开这里的注释
# s.resource_bundles = {
# 'WJCommon' => ['WJCommon/Assets/*.png']
# }
# s.public_header_files = 'Pod/Classes/**/*.h'
# s.frameworks = 'UIKit', 'MapKit' # 组件所依赖的系统框架
s.dependency 'AFNetworking' # 组件所依赖的三方库 如AFNetworking等等
end
2.创建远程组件代码库
1.在码云上创建一个远程组件代码库
其操作与 远程私有索引仓库的操作是一样的，我将创建的远程组件代码库命名为WJCommon，既可以得到其地址： https://gitee.com/xxx/WJCommon.git
2.将本地的WJCommon工程代码提交到远程WJCommon组件代码库
cd /Users/xxx/Desktop/Modules/WJCommon
git remote add origin https://gitee.com/xxx/WJCommon.git
git push -u origin master -f
git add .
git commit -am "提交代码"
git push -u origin master -f
git tag 0.0.1#（注意，这里的tag必须和WJCommon.podspec文件的版本一致）
git push --tags
3.对文件进行本地验证和远程验证
$ pod lib lint --allow-warnings # 本地认证
本地认证成功如下
$ pod spec lint --use-libraries --allow-warnings # 远程认证
4,将本地的WJCommon.podspec文件推送到本地CocoaPods/repos索引库
pod repo push WJSpec WJCommon.podspec --use-libraries --allow-warnings #(如果前面一步加了--use-libraries --allow-warnings 此时务必加上,不加会报错）
此时我们的本地WJSpec就有了该组件的信息了
查看远程仓库是否有我们的WJCommon组件
$ pod search WJCommon
至此远程组件化就集成完成了。
5.拓展常用附加处理
- 查看详细信息，请在命令后加入
--verbose - 忽略警告，请在命令后加入
--allow-warnings - 使用本地库，请在命令后加入
--use-libraries - 检查所有问题，请在命令后加入
--no-clean - 依赖了私有库，需要添加源，请在命令后加入
--sources=（注意如果依赖了公有库，还需要添加公有库源:https://github.com/CocoaPods/Specs即--sources=私有库名,https://github.com/CocoaPods/Specs）
注意：一定要添加上https://github.com/CocoaPods/Specs.git
pod lib lint --allow-warnings --sources=https://gitee.com/xxx/WJSpec.git,https://github.com/CocoaPods/Specs.git
三、验证是否能够集成
在我们的项目中使用WJCommon组件
1.在Podfile文件头部声明source源
source "https://gitee.com/xxx/WJSpec.git"
2.在Podfile文件中对应的项目target添加pod WJCommon
如果想更新库的版本并且推送上去，则需要重新修改版本号并提交 流程如下：
#A、工程中修改你要修改的代码等。
#B、.podSpec文件中修改版本号，设置成你此次修改的版本，然后打tag，推送到远端。
cd /Users/xxx/Desktop/Modules/WJCommon
git push -u origin master
git add .
git commit -am "提交0.0.2版本"
git push -u origin master
git tag 0.0.2 # 新的版本
git push --tags
pod repo push WJSpec WJCommon.podspec --use-libraries --allow-warnings
四、常见问题（error）
问题1: 校验失败
** BUILD FAILED **
The following build commands failed:
CompileSwift normal x86_64
CompileSwiftSources normal i386 com.apple.xcode.tools.swift.compiler
CompileSwift normal i386
CompileSwift normal arm64
(4 failures)
Testing with `xcodebuild`.
解决办法：在.podspec文件中加入;参考iOS 指令集架构
s.pod_target_xcconfig = { 'VALID_ARCHS' => 'x86_64 armv7 arm64' }
问题2: 组件中依赖的第三方库中有framework或者.a文件， pod install 报错:
target has transitive dependencies that include statically linked binaries:
解决办法： 在podfile文件中加入以下代码:
pre_install do |installer| Pod::Installer::Xcode::TargetValidator.send(:define_method, :verify_no_static_framework_transitive_dependencies) {}
end
问题3: Xcode setting ENABLE_BITCODE
You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE)
解决办法：将target下 ENABLE_BITCODE 设置为 NO
参考文档：
CocoaPods官方制作文档
用 CocoaPods 私有库提高团队的整体效率
GitHub 将使用 main替换掉 master等术语
