Cocoapods系列教程(二)——开源主义接班人

引言

在写该博客的时候，博主刚看到一个问题：“那些头衔只是看起来很厉害，实际不难获得？”。然后有个神回复写到：“共产主义接班人”。然后脑袋里面就响起那首斗志昂扬的歌：“我们都是共产主义接班人.....!@#$%^&*()”。借此就来引入今天的博文，作为现在开源横行的年代。作为一位刚毕业的iOS小学生，开源主义接班人，我们怎么能不撸起代码来呢？特别是针对那些自己做的很溜的控件啊，插件啊之类的。作为开发者总有一中冲动想向全世界呐喊这个是我写的。当然，如果作为一个控件，框架或者是第三方的开源，想要给别人用，却又能做到版本管理，当然就少不了我们上节说到的Cocoapods啦。 “还有Carthage！”角落里默默传来了一个声音。是谁！是谁在拆我的台。好吧，开玩笑。上节已经讲了Cocoapods作为使用者的基本用法，如果小伙伴没有看过的话，博主强烈建议大家去瞅一瞅。这节我们针对贡献者再进行细致的讲一讲。

“开源”代码

说到“开源”代码很多人脑袋里面第一个想到的就是完全开源给全世界的人。但是这篇文章需要产生另一个分解，针对开源的对象进行分解。对于公开给所有的人的开源我们称之为公有库。而除了我们平常所说的开源外，还有一种形式是公司内部的开源，即对部分开源，通常情况下我们针对这个库有称之为私有库。但是怎么说也是对少部分人开源了对吧。而本章中就针对这两部分人群进行讲解，分别公有库和私有库在Cocoapods上的使用进行讲解一下。当然，对于这两种情况下的库来说还是有一些共同的部分，所以我们先对Cocoapods中的一些使用和配置进行讲解，在讲解之后我们再针对不同的场景进行讲解不同的一些命令和流程。

Podsepc文件

在所有支持Cocoapods导入的库的开源目录(如Github)下，我们都能看到一个*.podspec文件。当然我们不管是做公有库或者是私有库都是必须配置这个文件的。这个文件是告诉Cocoapods你这个库的一些基本信息，包括你的版本号、获取的地址、那些文件是希望被包含进来的等一些信息。细节方面这边就不进行累述了，因为我不是一个特别喜欢讲理论的美男子。废话不多说，上Demo。(我又来做广告了)

Pod::Spec.new do |s|  
  s.name         = "iOS-Echarts"
  s.version      = "1.1.4"
  s.summary      = "A custom component for the ecomfe's echarts."
  s.homepage     = "https://github.com/Pluto-Y/iOS-Echarts"
  s.license      = { :type => "MIT", :file => 'LICENSE.md' }
  s.author       = { "PlutoY" => "kuaileainits@163.com" }
  s.platform     = :ios, "7.0"
  s.source       = { :git => "https://github.com/Pluto-Y/iOS-Echarts.git", :tag => s.version}
  s.frameworks   = 'UIKit'
  s.source_files = "iOS-Echarts/**/*.{h,m}"
  s.resource     = "iOS-Echarts/Resources/**"
  s.requires_arc = true
end

对于一个普通的Podspec文件来说一般都是有这些内容就可以了。而这个文件是在你新建或者需要新提交一个版本的时候回进行改动的文件。里面很简单的内容就不说了，有一点开发基础和英文底子的都看得出来，无非就是你要提交到Cocoapods上的名字、版本号，简介、主页、License、作者信息、最低平台信息、从哪个Git上下载、需要引入的framework、那些文件需要被引入，那些文件是资源文件以及是否需要ARC的模式。

大体就是包含这些信息。不过针对其中source_file、resource以及license稍微说两句。对于source_file主要是指你那些目录是可以被包含进来的，而resource是指哪些文件是作为资源文件进行引入的。而对于这些文件的描述都是可以用一些匹配公式的。可匹配的符号有*, **, ?, [set], {p,q}, \.常用匹配符的人应该能看得懂这些匹配符的意思。

文件匹配的属性有:sourcefiles, publicheaderfiles,privateheaderfiles,vendoredframeworks,vendoredlibraries,resourcebundles,resources,excludefiles,preservepaths,module_map.

而针对license来说的话，一定要填写正确的，要不然在之后的验证过程中(validate)，会一直出现warming的信息，让人看着很不舒服。

在Podspec文件中，很经常看到do |名字|的形式，这个有点类似于在对应end之前声明了一个local的参数一样。除了上问所示的Pod::Spec.new do |s|的情况外，还有可能会出现在s.subspec 'SubModule' do |sm|的形式，同样sm也是可以自己修改成自己想要的名字。

Podspec文件进阶

进阶其实也是非常简单的内容，主要是针对如果处理一个公有库或者私有库要进行模块的话，也就是针对上文出现的Subspec说一些注意点。照惯例，还是先上Demo：

s.subspec 'Security' do |ss|  
  ss.source_files = 'AFNetworking/AFSecurityPolicy.{h,m}'
  ss.public_header_files = 'AFNetworking/AFSecurityPolicy.h'
  ss.frameworks = 'Security'
end

可以看出，需要声明一个子模块的话只需通过父节点名.subspec '子模块名' do |子节点名|来进行声明一个子模块，而子模块里面一般都只需要配置一些文件匹配的信息、资源文件的信息以及一些依赖的信息即可。当然需要声明的都只是跟这个子模块有关的。大体的配置项跟上一小节中的配置项差不多，只是这部分的配置项的作用效果只是针对这个子模块而已。

除了上述所说的常用的配置项之外，还有其他的配置项大家可以通过Cocoapods的Podspec语法进行查询。这里就不对每个参数进行讲解了。其实对于一个公有库或者私有库来说，Podspec文件是非常重要的，因为这里面定义了

开源的接班人

上面简单的讲述了Podspec文件，下面开始我们的开源之旅吧。在开始提交项目到Cocoapods之前，小伙伴们有没有想过在提交源代码前怎么标示你的源代码是属于你的，我们总要一个类似账号的东东吧。当然需要，那么我们先来搞一个账号吧:

pod trunk register abc@163.com 'Pluto Y' --description='My own computer'

只要运行上面命令则会像Cocoapods方面注册一个账号。不过他的账号没有类似登陆的机制，所以在你切换设备后，需要再次使用这个命令进行“登陆”操作。其语法为pod trunk register 邮箱 '昵称' --description='设备信息'，其中的昵称和--description是可有可无的。对于昵称来说，第一次"注册"时最好填写一下。第二次"登陆"时，则可不比填写，而对于--description来说的话，其实就是为了让你区分不同设备"登陆"，因为Cocoapods是以Session的形式将用户信息缓存在机子中，而可能出现多台设备"登陆"的情况，所以在register的时候带上--description方面之后查看哪些设备“登陆”过. 只要只要通过pod trunk me来查看是否"注册"成功。如果成功的话,并且多台设备登陆的情况，具体如下图:

好了，有了账号之后，当然是着手开始做了。既然要开源，那么当然首先就是写代码，你不会是希望我帮你写代码吧，好吧如果是美铝我会考虑考虑的(I'm kidding)。在写好代码后，在你项目的根目录下运行:

pod spec create 'SlideMenuControllerOC'

当然SlideMenuControllerOC就是你开源出去让别人搜到的项目名啦，你直接替换成你的项目名即可。运行完这个目录后，Cocoapods会自动帮你产生一个包含一部分基础内容的Podspec文件，通过对里面进行一些必要的修改即可。当然对于开源项目一般都不需要对于子模块的定义。然后根据上述的内容以及Cocoapods官网文档描述进行定义那个文件即可。

当然这个是针对于那些已经创建好项目的小伙伴么，对于那些连项目都没有创建的小伙伴们，Cocoapods还提供了另一个命令:

pod lib create 'FirstCocoapodsProject'

通过这条命令会创建好一个项目,在执行这个项目的过程中，根据命令行的引导，你会创建好一个Cocoapdos定义好的一个项目模板。如果对于刚开始创建项目的小伙伴们来说，或许这个是一个不错的选择。通过这个命令Cocoapods会给你创建好,Podspec文件，travis文件,MIT Lisence文件以及README.md文件等。当然对于一个好的开源文件来说的话，一个好的文档说明来说是非常有必要的。所以对于一个你来说最简单的文档说明当然是README.md，特别是那些需要提交到Cocoapds上的Github上的项目。我们一进入Github上的一个项目时，首先看到的就是README.md的内容，所以小伙伴对于这个文件里面的内容要慎重进行书写。当然Github上的这个文件是支持Markdown的语法，所以对于书写文档也是一种版主。

好了，在准备好文档，代码，内容以及一些其他的资料后，肯定很多小伙伴很迫不及待的想要上传了，但是桥到嘛太(日文-等等的意思),小伙伴有木有想过，我们还有一些其他的工作需要做。

准备向发布进攻

首先需要验证你的代码是否有错以及Podspec文件，那么这个时候下面这条命令就起到非常大的作用了：

pod lib lint Name.podspec

这条命令是用来验证你的Podspec文件是否有问题，并且代码里面是否有问题的命令。当然我还是建议这条命令后面跟着--verbose的参数，除此之外，这条命令还有其他参数是可以跟着的，这里稍微讲讲其中的一部分，毕竟参数也是比较少嘛： * --allow-warnings 是否允许警告，在用到第三方框架的时候，有的时候是自带会有warmings的代码，用这参数可以屏蔽警告 * --fail-fast 原本这条命令是在所有代码校验完成后，才会输出所有信息，可是可以通过这个参数在出现第一个错误的时候就停止 * --use-libraries 如果用到的第三方中需要使用库文件的话，则会用到这个参数。（如在项目中依赖了ShareSDK的情况） * --sources 如果一个库的podspec包含了除了Cocoapods仓库以外的其他库的引用，则需要该参数指明，用逗号分隔，这个参数对于私有库是非常有用的 * --verbose 这条参数可以输出所有的消息信息，在验证过程中，博主还是建议大家都用这个参数 * --subspec=NAME 这个参数是用来指检验某一个子模块的情况当然，这里只是对参数进行大概的描述，上述参数中，--allow-warnings和--verbose是博主强烈希望大家加上的。

好了，在验证通过你的项目之后，你就可以通过git上的进行打tag了。具体打tag的命令博主就不说了，自己去打tag吧。也有小伙伴将打tag和验证的顺序调换了，不过小伙伴们听哥一句劝啊，千万先验证完后在打tag啊，要不然你打完tag后发现验证不通过之前的tag就没有太大的作用了。

最后，终于到达上传的时间了，运行命令:

pod trunk push 项目名.podspec

只要通过上述命令即可上传项目到Cocoapods官方的仓库里去，当然如果你有新的tag版本的话也是通过该命令进行上传新的版本到Cocoapods的。而我们可以通过pod search 名字来查询是否上传成功。

-> iOS-Echarts (1.1.4)
   A custom component for the ecomfe's echarts.
   pod 'iOS-Echarts', '~> 1.1.4'
   - Homepage: https://github.com/Pluto-Y/iOS-Echarts
   - Source:   https://github.com/Pluto-Y/iOS-Echarts.git
   - Versions: 1.1.4, 1.1.3, 1.1.2 [master repo]

成功的话就会出现上述信息，里面包含了对于项目的描述。至此，对于提交开源的项目到Cocoapods就结束了。最后在附带一条命令吧，如果你是多人开发的情况，或者是希望加入一个小伙伴到你的项目中的话，可以通过: pod trunk add-owner '项目名' '邮箱'的方式，将别人加入到你的项目中去。

总结

至此，本系列的第二节也就讲完了。本节主要讲了一个Podspec文件的内容、提交项目到Cocoapods仓库的流程以及一些命令的讲解。希望大家多为开源的事业做出自己能做的一部分。本人讲的比较马虎，如果中间有什么不懂的小伙伴可以留言或者是直接联系我。而在下一张中，我讲针对Cocoapods的私有库以及在项目中的多模块管理进行一些讲解。如果有兴趣的小伙伴可以留心一下。好了，到这里小伙伴就可以退下了，朕要就寝了。