本文講述如何讓自己的代碼、.a、.framework支持cocoapods導(dǎo)入,變成類似于AFNetworking、SDWebImage那樣的第三方庫(kù)。代碼可以托管在SVN和Git服務(wù)器上,會(huì)在不同之處做出說(shuō)明。是公有庫(kù)還是私有庫(kù)取決于你的代碼托管平臺(tái)設(shè)置的公開(kāi)性。
初級(jí)階段
所謂“初級(jí)階段”,是說(shuō)使用cocoapods提供的模板創(chuàng)建項(xiàng)目,然后將自己的代碼添加進(jìn)去,做一些修改之后發(fā)布出去。這種方式相對(duì)簡(jiǎn)單,結(jié)構(gòu)固定,但是靈活性不高。
下面進(jìn)入正題~
1. 創(chuàng)建空項(xiàng)目
首先在SVN或者Git服務(wù)器上創(chuàng)建一個(gè)空項(xiàng)目,然后check out或者clone到本地。
2. 創(chuàng)建模板工程
打開(kāi)終端,cd到工程所在目錄,輸入命令:pod lib create 工程名。Cocoapods會(huì)在終端詢問(wèn)幾個(gè)問(wèn)題,下面結(jié)合圖片解釋:

5個(gè)問(wèn)題回答完之后,將會(huì)自動(dòng)打開(kāi)項(xiàng)目。你需要把自己的代碼放在Pods/Development Pods/目錄下。
3. 修改配置
在Xcode的Demo項(xiàng)目中的Podspec Metadata文件夾下,或者Finder中該項(xiàng)目的根目錄下找到一個(gè)后綴為podspec的跟項(xiàng)目名同名的文件,這個(gè)是讓自己的代碼支持Cocoapods導(dǎo)入的核心配置文件,下面對(duì)文件中各配置項(xiàng)的含義進(jìn)行逐條說(shuō)明:
Pod::Spec.new do |s|
# 庫(kù)名
s.name = 'TestPoood'
# 版本號(hào)
s.version = '0.1.0'
# 對(duì)庫(kù)的類型、作用做一個(gè)簡(jiǎn)短的描述
s.summary = 'A short description of TestPoood.'
# 如果需要對(duì)庫(kù)進(jìn)行較多的說(shuō)明,可在此處進(jìn)行描述
s.description = <<-DESC
TODO: Add long description of the pod here.
DESC
# 庫(kù)工程目錄地址,這里會(huì)根據(jù)你在SVN或Git服務(wù)器上創(chuàng)建項(xiàng)目的地址自動(dòng)生成
s.homepage = 'https://github.com/RavenKite/TestPoood'
# 遵守的哪些許可協(xié)議,默認(rèn)就行了
s.license = { :type => 'MIT', :file => 'LICENSE' }
# 作者信息
s.author = { '作者名' => '郵箱' }
# 庫(kù)的源路徑。SVN與Git稍有不同,下面分為兩行舉例。后面的`:tag => s.version.to_s`是庫(kù)的版本號(hào),
# `pod install`時(shí)會(huì)自動(dòng)根據(jù)后面的tag版本號(hào)去工程目錄中尋找與版本號(hào)同名的源。
s.source = { :svn => 'http://192.168.101.1/svn/iOS/TestPoood/', :tag => s.version.to_s }
s.source = { :git => 'https://github.com/RavenKite/TestPoood.git', :tag => s.version.to_s }
# 最低兼容的iOS版本號(hào)
s.ios.deployment_target = '8.0'
# 庫(kù)中源碼的路徑,默認(rèn)包含Classes下所有文件夾及所有的.h和.m文件
# 注意:如果包含xib或storyboard,放在此目錄下是無(wú)效的,必須將其移動(dòng)到Assets目錄下作為資源文件存在
s.source_files = 'Classes/**/*.{h,m}'
# 資源文件目錄,可以在此目錄下存放圖片、xib等資源,可以使用通配符或者{png,jpg,xib}這樣的方式來(lái)指定文件類型
s.resource_bundles = {
'TestPoood' => ['TestPoood/Assets/*.*']
}
s.public_header_files = 'Pod/Classes/**/*.h'
# 依賴的系統(tǒng)庫(kù)(framework)。多個(gè)可以使用英文逗號(hào)隔開(kāi)
s.frameworks = 'UIKit', 'MapKit'
# 依賴的系統(tǒng)dylib庫(kù),依賴這種庫(kù)時(shí)不需要寫(xiě)前面的"lib",如依賴"libz.tbd",只需要寫(xiě)上'z'就行了
s.ios.library = 'z','c++'
# 依賴的第三方庫(kù)。如果依賴多個(gè),不能使用依賴系統(tǒng)庫(kù)的方式用英文逗號(hào)隔開(kāi),必須要另起一行,后面也可以指定版本號(hào)
s.dependency 'AFNetworking', '~> 2.3'
s.dependency 'Masonry'
end
4. 代碼位置
配置文件修改好之后,將你的代碼放到Pods/Development Pods/TestPoood下,然后在終端執(zhí)行pod install后才能在Demo項(xiàng)目中調(diào)用。
5. 校驗(yàn)
在本地的工作(配置、代碼)完成之后,提交SVN或Git服務(wù)器之前,最好先讓Cocoapods做一下校驗(yàn),校驗(yàn)通過(guò)后再提交,以確保你的庫(kù)能夠被其他項(xiàng)目正常導(dǎo)入。
在終端執(zhí)行以下命令:
pod lib lint TestPoood.podspec
如果終端打印了TFFramework passed validation. 則說(shuō)明校驗(yàn)通過(guò),否則校驗(yàn)失敗。
如果校驗(yàn)失敗,可以查看終端輸出的日志。
- NOTE是正常項(xiàng);
- ERROR是錯(cuò)誤項(xiàng),需要根據(jù)后面的提示做出修改,否則無(wú)法通過(guò)校驗(yàn)。錯(cuò)誤情況可能五花八門(mén),在此也無(wú)法窮舉,這里就考驗(yàn)大家解決問(wèn)題的能力啦(~ ̄  ̄)~;
- WARN是警告項(xiàng),建議根據(jù)提示做出修改,也可以通過(guò)在校驗(yàn)命令后拼接--allow-warnings忽略警告以完成校驗(yàn),代碼如下:
pod lib lint TestPoood.podspec --allow-warnings
6. 提交代碼服務(wù)器
在以上功能都實(shí)現(xiàn)完成后,提交到SVN或Git服務(wù)器,打上tag(tag名為版本號(hào),如1.0.0,不要加其他中英文字符),GitHub可以Draft a new release。別的項(xiàng)目接入時(shí)跟引用其他第三方庫(kù)稍有不同,下面是引用示例。
在podfile文件中增加:
# SVN
pod 'TestPoood', :svn => 'http://192.168.101.1/svn/iOS/TestPoood/',:tag=>'0.1.0'
# Git
pod 'TestPoood', :git => 'https://github.com/RavenKite/TestPoood.git',:tag=>'0.1.0'
與引用常見(jiàn)的如AFNetworking不同的是(也可以跟引入AFN時(shí)一樣,需要將.podspec文件上傳到Cocoapods的服務(wù)器,后面的高級(jí)階段會(huì)講到),引用自己的庫(kù)需要在后面增加源地址,源地址就是.podspec文件s.source中的路徑,再之后的tag可根據(jù)需要使用指定的版本。
但是,開(kāi)發(fā)狀態(tài)時(shí),由于可能會(huì)頻繁的修改庫(kù)中的文件,而在別的項(xiàng)目中接入該庫(kù)時(shí)必須要指定一個(gè)版本號(hào),這樣頻繁的修改文件后提交服務(wù)器然后打tag的方式過(guò)于繁瑣且沒(méi)必要,我們可以通過(guò)下面的方式,不指定版本號(hào),而是直接引入庫(kù)的開(kāi)發(fā)環(huán)境時(shí)的代碼,等到穩(wěn)定后再使用上面的方式引入。
# SVN直接引用trunk目錄下的源文件
pod 'TestPoood', :svn => 'http://192.168.101.1/svn/iOS/TestPoood/trunk'
# Git不指定后面的版本號(hào),即會(huì)自動(dòng)引用根目錄中的代碼,而不是tag中的
pod 'TestPoood', :git => 'https://github.com/RavenKite/TestPoood.git'
6. 修改和更新
如果版本號(hào)、庫(kù)的公開(kāi)類、私有類、目錄結(jié)構(gòu)、資源文件等變更時(shí),需修改.podspec中的配置然后提交SVN或Git,之后在引用該庫(kù)的工程中 pod update。
注意,podspec中的版本號(hào)要與Pods->TestPood中的版本號(hào)一致,且每次提交SVN或Git也應(yīng)該改變版本號(hào)(當(dāng)然,開(kāi)發(fā)過(guò)程中可不必如此)。
7. 完成
至此,你已經(jīng)按照模板成功的制作出了支持Cocoapods導(dǎo)入的開(kāi)源庫(kù)。
但是,如果你的庫(kù)中的代碼較多,或者你喜歡把不同的類按照其功能性等方式分散在不同文件夾中的話,你會(huì)發(fā)現(xiàn),制作出來(lái)的庫(kù)是沒(méi)有文件夾、完全扁平化的。然而,你會(huì)發(fā)現(xiàn)AFNetworking有文件夾的。如果你去它的GitHub地址查看AFNetworking.podspec文件的話,你會(huì)發(fā)現(xiàn)里面有s.subspec這個(gè)配置項(xiàng),它的含義是創(chuàng)建一個(gè)子庫(kù),具體使用方式會(huì)在下面的高級(jí)階段介紹,因?yàn)樗鼘?duì)庫(kù)的結(jié)構(gòu)及代碼耦合性有很高的要求。
高級(jí)階段
如果你按照“初級(jí)階段”介紹的方法成功的制作出了一個(gè)簡(jiǎn)單的庫(kù)的話,那么你肯定會(huì)發(fā)現(xiàn)這其中最重要的就是.podspec文件,尤其是它內(nèi)部的配置項(xiàng),這才是決定了我們的代碼能否支持Cocoapods導(dǎo)入的關(guān)鍵。
并且你可能會(huì)發(fā)現(xiàn),“初級(jí)階段”所講的方式實(shí)際上是有很明顯的缺點(diǎn)的:它是按照模板來(lái)的,結(jié)構(gòu)過(guò)于固定而沒(méi)有靈活性,需要自己把代碼一點(diǎn)點(diǎn)的遷移到這個(gè)模板項(xiàng)目中來(lái)。而且這個(gè)項(xiàng)目結(jié)構(gòu)……我個(gè)人感覺(jué)有點(diǎn)奇怪。另外就是,我沒(méi)有提到怎么將.a或.framework添加進(jìn)模板項(xiàng)目,因?yàn)槲矣X(jué)得采用這種模板的方式不適合制作閉源庫(kù)。
那么,在所謂的“高級(jí)階段”,就是要介紹怎樣靈活的創(chuàng)建和配置.podspec文件,怎樣讓它與項(xiàng)目結(jié)合起來(lái),甚至可以在不影響現(xiàn)有項(xiàng)目的基礎(chǔ)上,將項(xiàng)目中任何一部分代碼制作成開(kāi)源庫(kù)(閉源庫(kù)還是要對(duì)項(xiàng)目結(jié)構(gòu)做一些修改的),并支持Cocoapods導(dǎo)入。
好了,廢話說(shuō)完了,現(xiàn)在開(kāi)始!
這次,我們不再按照模板創(chuàng)建項(xiàng)目,而是先手動(dòng)創(chuàng)建好項(xiàng)目之后(如果你打算使用自己現(xiàn)有的項(xiàng)目,則可以跳過(guò)第一步),再用終端命令創(chuàng)建.podspec文件。
我先把下面所講內(nèi)容用到的Demo地址貼出來(lái),希望能給大家提供一些參考。
1. 首先,創(chuàng)建好項(xiàng)目,項(xiàng)目結(jié)構(gòu)如下圖所示。
其中,TFClasses是庫(kù)的類文件存放目錄,TFAssets是庫(kù)的資源文件存放目錄。
對(duì)下圖中包含.xcworkspace的項(xiàng)目結(jié)構(gòu)有疑問(wèn)的童鞋,我安利下自己的另一篇文章。(~ ̄▽ ̄)~

2. 創(chuàng)建podspec
打開(kāi)終端,cd到TestFramework項(xiàng)目的根目錄,即TestFramework.xcworkspace所在的目錄(使用自己項(xiàng)目的童鞋根據(jù)自己項(xiàng)目情況cd到根目錄);終端輸入以下命令pod spec create 庫(kù)名,回車。
創(chuàng)建成功后,打開(kāi)TFFramework.podspec,你會(huì)發(fā)現(xiàn)里面有一大堆東西,不要擔(dān)心,其中大多數(shù)為注釋描述,關(guān)鍵的配置都與在“初級(jí)階段”時(shí)所講一致,只有少數(shù)地方需要我們略作修改。
創(chuàng)建podspec之后的項(xiàng)目目錄結(jié)構(gòu)是這樣的:

其實(shí),你也可以把podspec文件直接放在與TFClasses平級(jí)的目錄下,但是下面幾點(diǎn)中所說(shuō)的相對(duì)路徑就要根據(jù)實(shí)際情況做出調(diào)整了。
3. 修改庫(kù)中源碼路徑:s.source_files。
由于podspec文件是在項(xiàng)目根目錄的,而存放庫(kù)的類文件的目錄TFClasses與它不在同一級(jí)。因此,需要修改為下面這樣:
# TFClasses后的通配符“**”意味包含該目錄下所有的目錄層級(jí),“*.{h,m}”意味著包含目錄中的所有后綴為.h或.m的文件
s.source_files = "TestFramework/TestFramework/TFClasses/**/*.{h,m}"
# 如果庫(kù)中的類只有一層目錄,可以不要中間那一層的通配符,改成下面的方式
s.source_files = "TestFramework/TestFramework/TFClasses/*.{h,m}"
# 或者直接全部使用通配符
s.source_files = "TestFramework/TestFramework/TFClasses/*.*"
需要注意的是,庫(kù)中的所有類應(yīng)該與項(xiàng)目中的其他類是完全解耦的,即庫(kù)中的代碼不依賴項(xiàng)目中的其他任何代碼也能夠正常運(yùn)行,否則制作出的庫(kù)在導(dǎo)入到別的項(xiàng)目中后肯定無(wú)法正常運(yùn)行。
4. 修改庫(kù)中引用的資源路徑
s.resource、s.resources 、s.resource_bundle = { } 或 s.resource_bundles = { }。
如果庫(kù)中引用了資源文件,或者使用了Xib、Storyboard(不能直接放在TFClasses里面,即使使用了通配符"*.*",因?yàn)樗鼈儾皇穷愇募?,而是屬于資源文件),需要為這些資源文件單獨(dú)建立目錄(如果不單獨(dú)建立目錄,也是可以放在TFClasses中的,只是需要指定文件后綴名,過(guò)于麻煩且結(jié)構(gòu)混亂)。
# 引用單個(gè)資源
s.resource = 'img.png'
# 引用多個(gè)資源
s.resources = ['TestFramework/TestFramework/TFAssets/*.*', 'TestFramework/TestFramework/TFText/*.*']
注意:上述方式是Cocoapods不建議的,但仍可以使用(這是因?yàn)橛锌赡芘c導(dǎo)入該庫(kù)的項(xiàng)目產(chǎn)生資源文件名沖突,因?yàn)橘Y源文件都是平鋪在mainBundle中的)。
Cocoapods推薦使用下面的方式:
s.resource_bundle = {
'TFAssets' => ['TestFramework/TestFramework/TFAssets.bundle/**/*.*']
}
# 導(dǎo)入多個(gè)資源目錄或文件
s.resource_bundles = {
'TFAssets' => ['TestFramework/TestFramework/TFAssets.bundle/**/*.*']
}
這種方式Cocoapods會(huì)在導(dǎo)入該庫(kù)的項(xiàng)目中的mainBundle里創(chuàng)建一個(gè)bundle,名稱就是“=>”左邊的字符串。所以,如果你是直接將自己項(xiàng)目中的一部分代碼制作成庫(kù)的話,最好是將所有引用的資源放在一個(gè)bundle中,bundle名就是上面配置中的名稱(所以,這時(shí)需要將上面所創(chuàng)建的TFAssets修改為T(mén)FAssets.bundle)。這樣就能保證你在開(kāi)發(fā)該庫(kù)的項(xiàng)目中和導(dǎo)入該庫(kù)的項(xiàng)目中調(diào)用資源文件的代碼是一致的,否則將可能會(huì)出現(xiàn)找不到文件的情況。
如果你覺(jué)得這樣比較麻煩,也可以直接使用第一種方法,但是要注意可能產(chǎn)生的命名沖突。
5. 創(chuàng)建子庫(kù):s.subspec。
這是為了實(shí)現(xiàn)類似AFNetworking那樣導(dǎo)入后在Pods里可以分成幾個(gè)文件夾,就像下面這樣:

如果你仔細(xì)研究過(guò)AFNetworking的話,你會(huì)發(fā)現(xiàn),它的每個(gè)文件夾(其實(shí)只有Serialization、Security、Reachability這三項(xiàng))都是可以單獨(dú)導(dǎo)入項(xiàng)目的,你可以在podfile里這么寫(xiě):
pod 'AFNetworking/Serialization'
pod 'AFNetworking/Security'
為什么NSURLSession和UIKit不能單獨(dú)導(dǎo)入項(xiàng)目?其實(shí)并不是這樣,它們也是可以的,但是導(dǎo)入這兩個(gè)的時(shí)候,也會(huì)同時(shí)導(dǎo)入另外三項(xiàng),因?yàn)樗膒odspec是這樣的:
s.subspec 'NSURLSession' do |ss|
# 這里可以看出,NSURLSession是需要依賴Serialization、Reachability和Security的
# 因此,導(dǎo)入NSURLSession時(shí),也會(huì)同時(shí)導(dǎo)入另外三項(xiàng)
ss.dependency 'AFNetworking/Serialization'
ss.ios.dependency 'AFNetworking/Reachability'
ss.osx.dependency 'AFNetworking/Reachability'
ss.tvos.dependency 'AFNetworking/Reachability'
ss.dependency 'AFNetworking/Security'
ss.source_files = 'AFNetworking/AF{URL,HTTP}SessionManager.{h,m}', 'AFNetworking/AFCompatibilityMacros.h'
ss.public_header_files = 'AFNetworking/AF{URL,HTTP}SessionManager.h', 'AFNetworking/AFCompatibilityMacros.h'
end
s.subspec 'UIKit' do |ss|
ss.ios.deployment_target = '7.0'
ss.tvos.deployment_target = '9.0'
# 這里可以看出UIKit依賴NSURLSession,而NSURLSession又依賴另外三項(xiàng)
ss.dependency 'AFNetworking/NSURLSession'
ss.public_header_files = 'UIKit+AFNetworking/*.h'
ss.source_files = 'UIKit+AFNetworking'
end
因此,可以看出,這個(gè)所謂的子庫(kù)(s.subspec)其實(shí)是“庫(kù)中庫(kù)”。如果你希望自己的庫(kù)可以像AFNetworking那樣有多層級(jí)的文件夾,必須要清晰的規(guī)劃好自己庫(kù)中的類,使得它們之間有一部分類是完全與其他類解耦的,有一部分類可能需要依賴其他子庫(kù)中的類。但是,如果你規(guī)劃的這些文件夾之間存在相互依賴的話……我相信,你最終肯定會(huì)放棄這么做的。
但是,我可不是為了勸退大家才這么說(shuō)的,只是子庫(kù)的使用確實(shí)有一定的前提,如果你的庫(kù)不滿足這樣的前提,或者你嫌麻煩不打算使用子庫(kù)的話,那么你可以直接跳過(guò)這一段了。
下面,開(kāi)始正式介紹子庫(kù)的使用方式。至于怎樣解耦自己的庫(kù)和規(guī)劃文件夾,這里就不介紹了,大家各顯神通吧╮( ̄  ̄)╭。
首先,要從podspec文件的第一行代碼開(kāi)始說(shuō)起,為什么所有的配置項(xiàng)都是以“s”開(kāi)頭呢?能不能以別的什么字符開(kāi)頭?答案是當(dāng)然可以,它就藏在第一行代碼中:
# |s|就相當(dāng)于給這個(gè)podspec空間創(chuàng)建了一個(gè)宏,在這個(gè)“命名空間”內(nèi),“s”就代表當(dāng)前這個(gè)庫(kù)。如果你想自定義一個(gè)字符,修改這里就行了
Pod::Spec.new do |s|
然后,再來(lái)看AFNetworking里關(guān)于子庫(kù)的配置:
# 1. 子庫(kù)內(nèi)部的配置項(xiàng)與外面完全一致,你不需要再指定version、summary、author等固定信息,但至少需要指定source_files,其他配置項(xiàng)根據(jù)子庫(kù)的實(shí)際情況確定
# 2. 這里的|ss|就相當(dāng)于給Security子庫(kù)創(chuàng)建了一個(gè)宏,它的作用域僅是這個(gè)子庫(kù)。所以你會(huì)發(fā)現(xiàn),AFNetworking所有子庫(kù)的宏都是“ss”
# 3. Security是導(dǎo)入該庫(kù)的項(xiàng)目中顯示的子庫(kù)的名稱,它可以與你在開(kāi)發(fā)該庫(kù)的項(xiàng)目中的文件夾名稱不同,只要你在子庫(kù)中的source_files指定正確的路徑即可。但為了避免麻煩,我想你一般都會(huì)選擇兩者一致的
s.subspec 'Security' do |ss|
ss.source_files = 'AFNetworking/AFSecurityPolicy.{h,m}'
ss.public_header_files = 'AFNetworking/AFSecurityPolicy.h'
ss.frameworks = 'Security'
end
總之,子庫(kù)的關(guān)鍵在于規(guī)劃文件夾及各文件夾之間的解耦;其內(nèi)部的配置與外面是完全一致的。
到了這里,應(yīng)該能夠很輕松的制作出一個(gè)開(kāi)源庫(kù)了。但是還想提醒一點(diǎn),就是在開(kāi)發(fā)庫(kù)的過(guò)程中,尤其是對(duì)podspec做了修改,不要忘記多使用pod lib lint命令校驗(yàn)?zāi)愕呐渲檬欠裾_。
創(chuàng)建閉源庫(kù)
上面一直在說(shuō)開(kāi)源庫(kù),接下來(lái)該介紹下閉源庫(kù)了。所謂閉源庫(kù),就是指.a、.framework這樣不公開(kāi)源碼的庫(kù)。
既然是要閉源,那么開(kāi)發(fā)和發(fā)布肯定不能在一個(gè)地址中進(jìn)行。因此,你的podspec所在的目錄應(yīng)該只包含輸出后的.framework或.a+headers,以及可能會(huì)引用的資源bundle。
至于怎么創(chuàng)建.framework或.a,網(wǎng)上都有比較多且詳細(xì)的文章,這里就不贅述了。
那么我們直接開(kāi)始~
一個(gè)制作好的閉源庫(kù),以.framework為例,應(yīng)該類似于下面這樣:

關(guān)于閉源庫(kù)的podspec,其中的配置項(xiàng)與上面所講幾乎完全一致,只是閉源庫(kù)沒(méi)有了s. source_files,需要修改為s. vendored_frameworks。
下面是配置代碼:
# 如果有多個(gè).framework,可以使用英文逗號(hào)隔開(kāi)
s.vendored_frameworks = 'TFFramework.framework', 'Other.framework'
# .a庫(kù)是下面這個(gè)配置,多個(gè)也可以使用英文逗號(hào)隔開(kāi)
s.vendored_libraries = 'libTFLibrary.a', 'libOther.a'
上傳podspec到Cocoapods
上面提到過(guò),如果你希望自己的庫(kù)可以這樣導(dǎo)入:
pod 'TFFramework', '~>0.1.0'
而不是一定要指定地址:
pod 'TFFramework' :git => 'https://github.com/RavenKite/TestFramework.git', :tag=>'0.1.0'
就必須要將該庫(kù)的podspec上傳到Cocoapods的服務(wù)器,這樣你就可以在終端通過(guò)pod search搜索到它,并且可以用上面那種簡(jiǎn)化的方式導(dǎo)入。
但是,如果你的目的是制作私有庫(kù)的話,還是不要將podspec上傳到Cocoapods了。
1. 注冊(cè)Cocoapods
在終端輸入以下命令:
# 如果你之前注冊(cè)過(guò)Cocoapods,但是會(huì)話過(guò)期了,也需要執(zhí)行以下命令,但是可以不輸入用戶名,除非你需要修改
pod trunk register 郵箱 '用戶名'
之后你會(huì)收到一封驗(yàn)證郵件,點(diǎn)擊郵件中的鏈接進(jìn)行驗(yàn)證。
驗(yàn)證通過(guò)后,執(zhí)行以下命令,查看自己的信息:
pod trunk me
如果注冊(cè)成功且會(huì)話有效,則會(huì)打印出你的個(gè)人信息。
2. 校驗(yàn)podspec的有效性
這個(gè)命令上面已經(jīng)提到過(guò)了,只有校驗(yàn)通過(guò)(沒(méi)有ERROR)的podspec才能上傳Cocoapods。其中的警告是可以在命令后拼接--allow-warnings忽略的,但是建議還是根據(jù)提示做出修改,以達(dá)到?jīng)]有警告的程度再進(jìn)行上傳。
pod lib lint TFFramework.podspec
# 忽略警告
pod lib lint TFFramework.podspec --allow-warnings
3. 上傳podspec
需要注意的是,在上傳之前,一定要在自己庫(kù)的SVN或Git倉(cāng)庫(kù)創(chuàng)建tag,且tag版本與podspec中一致,否則將會(huì)上傳失敗。在GitHub上就是Draft a new release。
經(jīng)過(guò)第二步的校驗(yàn)通過(guò)且創(chuàng)建tag后,再執(zhí)行上傳命令:
pod trunk push TFFramework.podspec
# 如果你選擇了不處理第二步中的警告就直接上傳,需要在后面拼接'--allow-warnings'
pod trunk push TFFramework.podspec --allow-warnings
至于上傳速度方面,以我的經(jīng)驗(yàn),一般都會(huì)很慢,所以要有耐心~
上傳成功后,控制臺(tái)的結(jié)果如下:

4. 搜索自己的庫(kù)
檢測(cè)是否上傳成功的標(biāo)識(shí),就是能通過(guò)pod search搜索到自己的庫(kù):
pod search TFFramework
