demo地址開發(fā)中會有一些常用的類或方法，或者是某個(gè)特定功能的，比如一個(gè)自定義的彈框、一個(gè)更容易使用的網(wǎng)絡(luò)請求庫，可以把它們放到一個(gè)單獨(dú)的工程里，通過靜態(tài)庫（library、FrameWork）的方式應(yīng)用到任何其他需要的項(xiàng)目里。就像使用百度地圖sdk那樣。
現(xiàn)在有一些文章介紹如何構(gòu)建和使用自定義的靜態(tài)庫，但似乎沒有說使用Workspace的。其實(shí)本質(zhì)上，Workspace還是編譯靜態(tài)庫然后給主工程使用，但不用先打開工程A，編譯出libA.a，然后把文件拖到工程B，然后再工程B里面使用。主工程和它所用到的庫工程是在同一個(gè)工作環(huán)境下（估計(jì)這就是Workspace的名字意思吧）。配置好了之后，你只需要運(yùn)行主工程的target,會自動幫你編譯需要的庫。用過Pods庫應(yīng)該就明白。
好處就是：1.只需要打開一個(gè)工作環(huán)境，需要修改、同步代碼，都不需要打開新的項(xiàng)目、新的文件，讓人可以集中心思在代碼上，在不同的項(xiàng)目里跳來跳去很容易打斷思維的。
2.可以像同一個(gè)工程里一樣，直接點(diǎn)擊方法名查看引用庫項(xiàng)目的代碼，否則就要打開另一個(gè)項(xiàng)目，然后找到對應(yīng)文件再找到方法。
3.只要運(yùn)行自己的項(xiàng)目就行，就會自動幫你編譯庫文件。
下面以一個(gè)圖書管理的demo來說WorkSpace的整個(gè)操作。
構(gòu)建一個(gè)Workspace
如圖選擇構(gòu)建一個(gè)WorkSpace,會生成.xcworkspace文件，以后就通過打開這個(gè)文件來打開WorkSpace。打開工程，會發(fā)現(xiàn)什么都沒有，然后我們要添加各個(gè)工程（project）。在Xcode文管理文件的面板里，右鍵選擇添加新文件。
當(dāng)然，先要把項(xiàng)目建好。這里我建個(gè)項(xiàng)目叫BookManager，然后上面的添加文件，就把項(xiàng)目的BookManager.xcodeproj文件加進(jìn)來就可以了。
重復(fù)上述動作，把所有需要的項(xiàng)目都加進(jìn)來。這里我再建一個(gè)項(xiàng)目，用作對書籍的處理，假設(shè)這個(gè)庫的作用是給一個(gè)URL，然后把書籍信息獲取下來，并存到本地?cái)?shù)據(jù)庫，取名BookObtain吧。當(dāng)然，這里建項(xiàng)目就要選擇庫類型了。
雖然添加項(xiàng)目是可以任意路徑的，但是建議把所有要添加的項(xiàng)目放到同一個(gè)文件夾里，這樣便于像header search paths這類的路徑配置。
在BookObtain項(xiàng)目里構(gòu)建了兩個(gè)類，BookObtain負(fù)責(zé)獲取書籍，Book是書籍的類。代碼如下：
然后，現(xiàn)在我的項(xiàng)目里，想使用這個(gè)庫里的獲取書籍的功能，假設(shè)是寫在ViewController這個(gè)類里，我在界面上加一個(gè)按鈕，點(diǎn)擊我就獲取圖書，然后把書籍信息顯示到一個(gè)label里，就這么簡單功能。
那其實(shí)就是調(diào)用BookObtain的+(Book*)obtainAndSaveBookWithURL:(NSString*)urlString方法，那要先導(dǎo)入頭文件吧，發(fā)現(xiàn)#import"BookObtain.h" 報(bào)錯(cuò)，找不到頭文件。那現(xiàn)在就遇到第一個(gè)問題：指定引用庫的頭文件路徑。
在主項(xiàng)目的Build Settings 里找到Header Search Paths，添加一項(xiàng)$(SRCROOT)/../BookObtain，并且設(shè)置為recursive。$(SRCROOT)是當(dāng)前的工程路徑，..是返回上一層，然后到BookObtain文件夾。使用了相對路徑，為了是項(xiàng)目移動不會影響這個(gè)配置，只要主工程和其他工程的相對位置不變，這里的相對位置是固定在同一個(gè)文件夾。
好了,添加代碼：
- (IBAction)obtainBook:(UIButton*)sender {
Book* book = [BookObtainobtainAndSaveBookWithURL:@"xxx"];
NSLog(@"%@",book);
編譯，報(bào)錯(cuò)：
Undefined symbols for architecture arm64:
"_OBJC_CLASS_$_BookObtain", referenced from:
objc-class-ref in ViewController.o
BookObtain這個(gè)類未定義，什么原因？
頭文件#import,只是知道了頭文件，但是源碼不知道，BookObtain并沒有被編譯到，這時(shí)要把靜態(tài)庫添加到主工程里。
到主工程的Build Phases的Link Binary With Libraries里添加，點(diǎn)擊“+”按鈕，會給出整個(gè)Workspace可選的靜態(tài)庫，把BookObtain.a加進(jìn)來就好了。這是第二個(gè)問題：添加靜態(tài)庫。
但是，還有一個(gè)大問題，那就是靜態(tài)庫是不能攜帶資源的，比如書籍如果沒有獲取到封面信息，就是用一個(gè)默認(rèn)封面，那這個(gè)圖片肯定是固定并且存放在BookObtain項(xiàng)目里，因?yàn)檫@個(gè)功能被做成靜態(tài)庫就是為了能夠在多個(gè)項(xiàng)目里使用，如果每個(gè)使用的項(xiàng)目還得負(fù)責(zé)這個(gè)圖片，那就違背了節(jié)省工作的初衷了。
這是第三個(gè)問題：怎么攜帶資源文件？
我知道的，有兩種處理：1.使用bundle,這個(gè)東西本就是用來攜帶資源的，百度地圖的sdk同時(shí)也攜帶一個(gè)bundle.這種呢，比較正規(guī)一些，麻煩的是資源就不是在mainBundle里面了，找圖片啥的麻煩。
2.使用shell腳本，Xcode本身支持使用腳本做編譯處理，腳本里做的事就是把資源文件編譯到 xxx.app文件里面去，xxx.app目錄就對應(yīng)著mainBundle。
點(diǎn)“+”添加bundle,iOS那一類里沒有，選OS X里的frameWork...，也因?yàn)檫@個(gè)，bundle建立后，要把Build Settings 里的Base SDK由OS X換成iOS。
然后為了編譯項(xiàng)目的時(shí)候先把需要的bundle編譯了再編譯主工程的target,可以在Edit Scheme->Build里把bundle加進(jìn)去，而且加到主工程target前面。
腳本拷貝資源，Pods是個(gè)很好的例子，它的腳本文件名叫Pods-resources.sh.里面寫好了對各種資源類型的處理。
腳本使用就是在Build Phases里，添加一個(gè)新的組件，在頂端左邊有個(gè)“+”，點(diǎn)開選擇New Run Script Phase,
然后在腳本組件里，寫入執(zhí)行腳本的代碼：
/Users/sh/Pods/Pods-resources.sh指定腳本文件，后面跟著的是給它的參數(shù)/Users/sh/Desktop/BookObtain/Resource。我們可以把需要拷貝的資源都放到一個(gè)文件夾里，然后把這個(gè)文件夾路徑作為參數(shù)。腳本只要針對給定的文件路徑做處理就可以了。
更新
編譯的時(shí)候，是否會自動編譯依賴項(xiàng)目？是否會更新依賴的bundle的問題，Xcode9上測試
資源包bundle
1. 只添加到Copy Bundle Resources里，是不會自動編譯資源包的
2. 如果自己主動編譯了這個(gè)包，因?yàn)閣orkspace里的項(xiàng)目公用一個(gè)目標(biāo)位置，所以主項(xiàng)目這時(shí)可以得到資源包；
3. 以上面這種方式通過編譯后，clean project之后再編譯bundle會自動回來，但是如果修改了原項(xiàng)目的bundle內(nèi)容，這種方式不會跟隨更新。所以它其實(shí)更像是保留了一份數(shù)據(jù)然后拷貝過來，還是原來的bundle，并不是重新編譯的
4. 想主項(xiàng)目編譯的時(shí)候自動更新bundle,需要在Edit scheme-> Build里加入bundle,這樣點(diǎn)擊build的時(shí)候會同時(shí)編譯多個(gè)項(xiàng)目。這樣bundle會更新。
在build這里處理有幾個(gè)注意的點(diǎn)：
1. Parallelize Build并行編譯，應(yīng)該是同時(shí)編譯多個(gè)target
2. Find Implicit Dependencies查找隱性的依賴，在這些target之中，有一些會依賴另一些，就會在編譯的時(shí)候把依賴的庫一起帶上。
3. 幾個(gè)target的順序，它是按照從上到下嚴(yán)格執(zhí)行的。
如果把bundle的編譯放在主項(xiàng)目后面：
只開啟Find Implicit Dependencies, clean project第一次編譯報(bào)錯(cuò)，找不到bundle;之后編譯會好，但是如果修改了bundle之后第一次是沒效果的，第二次才有效果。
得出的猜測是：主項(xiàng)目在前面所以先編譯主項(xiàng)目，然后主項(xiàng)目編譯的時(shí)候把bundle帶進(jìn)去，clean project之后bundle清空了，所以報(bào)錯(cuò)；之后修改bundle內(nèi)容,在編譯主項(xiàng)目的時(shí)候，因?yàn)閎undle還沒重新編譯，所以拿到的是舊的內(nèi)容，所以要在第二次才會生效。
總結(jié)來說，雖然勾選了依賴，但是編譯順序還是不變
如果再同時(shí)開啟Parallelize Build,一切正常，說明這時(shí)Xcode重新調(diào)整了編譯順序，把被依賴的bundle放到了主項(xiàng)目前面。
所以Parallelize Build的意思并不是所有的項(xiàng)目全部同時(shí)開始編譯，而是要考慮Find Implicit Dependencies的，會從那些沒有依賴的開始編譯。我猜測，按照依賴關(guān)系可以形成一個(gè)圖，用圖算法就可以達(dá)到這個(gè)需求。
然后也可以我們自己手動調(diào)整，把bundle放在主項(xiàng)目的前面。這樣先把bundle編譯了，一切都沒問題了。
?靜態(tài)庫文件
只要加在了Link Binary With Libraries里，Xcode就會自動尋找隱性的依賴。文檔里:
Xcode examines the files in the build directory to discover implicit dependencies.
動態(tài)庫
1. 修改Runpath search Paths,設(shè)定動態(tài)庫鏈接的位置，默認(rèn)是@executable_path/frameWorks,但workspace會把其他項(xiàng)目的目標(biāo)都輸出到@executable_path/,所以修改一下。否則報(bào)錯(cuò)dyld: Library not loaded:xxx Reason: image not found
2. 除了把動態(tài)庫加入到Link Binary With Libraries,還需要加入到Copy Bundle Resurces里。
3. 動態(tài)庫需要簽名，就跟APP一下，否則報(bào)錯(cuò)Reason: no suitable image found.? Did find: xxxFramework: required code signature missing
