下文是轉(zhuǎn)載，本人覺得這個(gè)打包framework還是一個(gè)比較重要的功能，可以用來做一下事情：

（1）封裝功能模塊，比如有比較成熟的功能模塊封裝成一個(gè)包，然后以后自己或其他同事用起來比較方便。

（2）封裝項(xiàng)目，有時(shí)候會(huì)遇到這個(gè)情況，就是一家公司找了兩個(gè)開發(fā)公司做兩個(gè)項(xiàng)目，然后要求他們的項(xiàng)目中的一個(gè)嵌套進(jìn)另一個(gè)項(xiàng)目，此時(shí)也可以把唄嵌套的項(xiàng)目打包成framework放進(jìn)去，這樣比較方便。

我們?yōu)槭裁葱枰蚣埽‵ramework）？

要想用一種開發(fā)者友好的方式共享庫是很麻煩的。你不僅僅需要包含庫本身，還要加入所有的頭文件，資源等等。

蘋果解決這個(gè)問題的方式是框架（framework）?；旧?，這是含有固定結(jié)構(gòu)并包含了引用該庫時(shí)所必需的所有東西的文件夾。不幸的是，iOS禁止所有的動(dòng)態(tài)庫。同時(shí)，蘋果也從Xcode中移除了創(chuàng)建靜態(tài)iOS框架的功能。

Xcode仍然可以支持創(chuàng)建框架的功能，重啟這個(gè)功能，我們需要對(duì)Xcode做一些小小的改動(dòng)。

把代碼封裝在靜態(tài)框架是被app store所允許的。盡管形式不同，本質(zhì)上它仍然是一種靜態(tài)庫。

框架（Framework）的類別

大部分框架都是動(dòng)態(tài)鏈接庫的形式。因?yàn)橹挥刑O果才能在iOS設(shè)備上安裝動(dòng)態(tài)庫，所以我們無法創(chuàng)建這種類型的框架。

靜態(tài)鏈接庫和動(dòng)態(tài)庫一樣，只不過它是在編譯時(shí)鏈接二進(jìn)制代碼，因此使用靜態(tài)庫不會(huì)有動(dòng)態(tài)庫那樣的問題（即除了蘋果誰也不能在iOS上使用動(dòng)態(tài)庫）。

“偽”框架是通過破解Xcode的目標(biāo)Bundle（使用某些腳本）來實(shí)現(xiàn)的。它在表面上以及使用時(shí)跟靜態(tài)框架并無區(qū)別。“偽”框架項(xiàng)目的功能幾乎和真實(shí)的框架項(xiàng)目沒有區(qū)別（不是全部）。

“嵌入”框架是靜態(tài)框架的一個(gè)包裝，以便Xcode能獲取框架內(nèi)的資源（圖片、plist、nib等）。

本次發(fā)布包括了創(chuàng)建靜態(tài)框架和“偽”框架的模板，以及二者的“嵌入”框架。

用哪一種模板？

本次發(fā)布有兩個(gè)模板，每個(gè)模板都有“強(qiáng)”“弱”兩個(gè)類別。你可以選擇最適合一種（或者兩種都安裝上）。

***的不同是Xcode不能創(chuàng)建“真”框架，除非你安裝靜態(tài)框架文件xcspec在Xcode中。這真是一個(gè)遺憾（這個(gè)文件是給項(xiàng)目使用的，而不是框架要用的）。

簡單說，你可以這樣決定用哪一種模板：

• 如果你不想修改Xcode，那么請(qǐng)使用“偽”框架版本
• 如果你只是想共享二進(jìn)制（不是項(xiàng)目），兩種都可以
• 如果你想把框架共享給不想修改Xcode的開發(fā)者，使用“偽”框架版本
• 如果你想把框架共享給修改過Xcode的開發(fā)者，使用“真”框架版本
• 如果你想把框架項(xiàng)目作為另一個(gè)項(xiàng)目的依賴（通過workspace或者子項(xiàng)目的方式），請(qǐng)使用“真”框架（或者“偽”框架，使用-framework——見后）
• 如果你想在你的框架項(xiàng)目中加入其他靜態(tài)庫／框架，并把它們也鏈接到最終結(jié)果以便不需要單獨(dú)添加到用戶項(xiàng)目中，使用“偽”框架

“偽”框架

“偽”框架是破解的“reloacatable object file”（可重定位格式的目標(biāo)文件， 保存著代碼和數(shù)據(jù)，適合于和其他的目標(biāo)文件連接到一起，用來創(chuàng)建一個(gè)可執(zhí)行目標(biāo)文件或者是一個(gè)可共享目標(biāo)文件），它可以讓Xcode編譯出類似框架的東西——其實(shí)也是一個(gè)bundle。

“偽框架”模板把整個(gè)過程分為幾個(gè)步驟，用某些腳本去產(chǎn)生一個(gè)真正的靜態(tài)框架（基于靜態(tài)庫而不是reloacatable object file）。而且，框架項(xiàng)目還是把它定義為wrapper.cfbundle類型，一種Xcode中的“二等公民”。

因此它跟“真”靜態(tài)框架一樣可以正常工作，但當(dāng)存在依賴關(guān)系時(shí)就有麻煩了。

依賴問題

如果不使用依賴，只是創(chuàng)建普通的項(xiàng)目是沒有任何問題的。但是如果使用了項(xiàng)目依賴（比如在workspace中），Xcode就悲劇了。當(dāng)你點(diǎn)擊“Link Binary With Libraries”下方的’+’按鈕時(shí)，“偽框架”無法顯示在列表中。你可以從你的“偽”框架項(xiàng)目的Products下面將它手動(dòng)拖入，但當(dāng)你編輯你的主項(xiàng)目時(shí)，會(huì)出現(xiàn)警告：

warning: skipping file '/somewhere/MyFramework.framework' (unexpectedfile type 'wrapper.cfbundle' in Frameworks & Libraries build phase)

并伴隨“偽”框架中的鏈接錯(cuò)誤。

幸運(yùn)的是，有個(gè)辦法來解決它。你可以在”Other Linker Flags”中用”-framwork”開關(guān)手動(dòng)告訴linker去使用你的框架進(jìn)行鏈接：

-framework MyFramework

警告仍然存在，但起碼能正確鏈接了。

添加其他的庫/框架

如果你加入其他靜態(tài)（不是動(dòng)態(tài)）庫/框架到你的“偽”框架項(xiàng)目中，它們將“鏈接”進(jìn)你最終的二進(jìn)制框架文件中。在“真”框架項(xiàng)目中，它們是純引用，而不是鏈接。

你可以在項(xiàng)目中僅僅包含頭文件而不是靜態(tài)庫/框架本身的方式避免這種情況（以便編譯通過）。

“真”框架

“真”框架各個(gè)方面都符合“真”的標(biāo)準(zhǔn)。它是真正的靜態(tài)框架，正如使用蘋果在從Xcode中去除的那個(gè)功能所創(chuàng)建的一樣。

為了能創(chuàng)建真正的靜態(tài)框架項(xiàng)目，你必需在Xcode中安裝一個(gè)xcspec文件。

如果你發(fā)布一個(gè)“真”框架項(xiàng)目（而不是編譯），希望去編譯這個(gè)框架的人必需也安裝xcspec文件（使用本次發(fā)布的安裝腳本），以便Xcode能理解目標(biāo)類型。

注意：如果你正在發(fā)布完全編譯的框架，而不是框架項(xiàng)目，最終用戶并不需要安裝任何東西。

我已經(jīng)提交一個(gè)報(bào)告給蘋果，希望他們在Xcode中更新這個(gè)文件，但那需要一點(diǎn)時(shí)間.OpenRadarlink here

加其他靜態(tài)庫/框架

如果你加入其他靜態(tài)（不是動(dòng)態(tài)）庫/框架到你的“真”框架項(xiàng)目，它們只會(huì)被引用，而不會(huì)象“偽”框架一樣被鏈接到最終的二進(jìn)制文件中。

從早期版本升級(jí)

如果你是從Mk6或者更早的版本升級(jí)，同時(shí)使用“真”靜態(tài)框架，并且使用Xcode4.2.1以前的版本，請(qǐng)運(yùn)行uninstall_legacy.sh以卸載早期用于Xcode的所有修正。然后再運(yùn)行install.sh，重啟Xcode。如果你使用Xcode4.3以后，只需要運(yùn)行install.sh并重啟Xcode。

安裝

分別運(yùn)行Real Framework目錄或Fake Framework目錄下的install.sh腳本進(jìn)行安裝（或者兩個(gè)你都運(yùn)行）。

重啟Xcode，你將在新項(xiàng)目向?qū)У腇ramework&Library下看到StaticiOS Framework（或者Fake Static iOS Framework）。

卸載請(qǐng)運(yùn)行unistall.sh腳本并重啟Xcode。

創(chuàng)建一個(gè)iOS框架項(xiàng)目

• 創(chuàng)建新項(xiàng)目。
• 項(xiàng)目類型選擇Framework&Library下的Static iOS Framework（或者Fake Static iOS Framework）。
• 選擇“包含單元測試”（可選的）。
• 在target中加入類、資源等。
• 凡是其他項(xiàng)目要使用的頭文件，必需聲明為public。進(jìn)入target的Build Phases頁，展開Copy Headers項(xiàng)，把需要public的頭文件從Project或Private部分拖拽到Public部分。

編譯你的 iOS 框架

• 選擇指定target的scheme
• 修改scheme的Run配置（可選）。Run配置默認(rèn)使用Debug，但在準(zhǔn)備部署的時(shí)候你可能想使用Release。
• 編譯框架（無論目標(biāo)為iOS device和Simulator都會(huì)編譯出相同的二進(jìn)制，因此選誰都無所謂了）。
• 從Products下選中你的framework，“show in Finder”。

在build目錄下有兩個(gè)文件夾：(yourframework).framework and (your framework).embeddedframework.

如果你的框架只有代碼，沒有資源（比如圖片、腳本、xib、coredata的momd文件等），你可以把(yourframework).framework 分發(fā)給你的用戶就行了。如果還包含有資源，你必需分發(fā)(your framework).embeddedframework給你的用戶。

為什么需要embedded framework？因?yàn)閄code不會(huì)查找靜態(tài)框架中的資源，如果你分發(fā)(your framework).framework, 則框架中的所有資源都不會(huì)顯示，也不可用。

一個(gè)embedded framework只是一個(gè)framework之外的附加的包，包括了這個(gè)框架的所有資源的符號(hào)鏈接。這樣做的目的是讓Xcode能夠找到這些資源。

使用iOS 框架

iOS框架和常規(guī)的Mac OS動(dòng)態(tài)框架差不多，只是它是靜態(tài)鏈接的而已。

在你的項(xiàng)目中使用一個(gè)框架，只需把它拖僅你的項(xiàng)目中。在包含頭文件時(shí)，記住使用尖括號(hào)而不是雙引號(hào)括住框架名稱。例如，對(duì)于框架MyFramework：

#import <MyFramework/MyClass.h>

使用問題

Headers Not Found

如果Xcode找不到框架的頭文件，你可能是忘記將它們聲明為public了。參考“創(chuàng)建一個(gè)iOS框架項(xiàng)目”第5步。

No Such Product Type

如果你沒有安裝iOS Universal Framework在Xcode，并企圖編譯一個(gè)universal框架項(xiàng)目（對(duì)于“真”框架，不是“假”框架），這會(huì)導(dǎo)致下列錯(cuò)誤：

target specifies product type 'com.apple.product-type.framework.static',but there's no such product type for the 'iphonesimulator' platform

為了編譯“真”iOS靜態(tài)框架，Xcode需要做一些改動(dòng)，因此為了編譯“真”靜態(tài)框架項(xiàng)目，請(qǐng)?jiān)谒械拈_發(fā)環(huán)境中安裝它（對(duì)于使用框架的用戶不需要，只有要編譯框架才需要）。

The selected run destination is not valid for this action

有時(shí)，Xcode出錯(cuò)并加載了錯(cuò)誤的active設(shè)置。首先，請(qǐng)嘗試重啟Xcode。如果錯(cuò)誤繼續(xù)存在，Xcode產(chǎn)生了一個(gè)壞的項(xiàng)目（因?yàn)閄code4的一個(gè)bug，任何類型的項(xiàng)目都會(huì)出現(xiàn)這個(gè)問題）。如果是這樣，你需要?jiǎng)?chuàng)建一個(gè)新項(xiàng)目重來一遍。

鏈接警告

***次編譯框架target時(shí)，Xcdoe會(huì)在鏈接階段報(bào)告找不到文件夾：

ld: warning: directory not found for option'-L/Users/myself/Library/Developer/Xcode/DerivedData/MyFramework-ccahfoccjqiognaqraesrxdyqcne/Build/Products/Debug-iphoneos'

此時(shí)，可以clean并重新編譯target，警告會(huì)消除。

Core Data momd not found

對(duì)于框架項(xiàng)目和應(yīng)用程序項(xiàng)目，Xcode會(huì)以不同的方式編譯momd（托管對(duì)象模型文件）。Xcode會(huì)簡單地在根目錄創(chuàng)建.mom文件，而不會(huì)創(chuàng)建一個(gè).momd目錄（目錄中包含VersionInfo.plist和.mom文件）。

這意味著，當(dāng)從一個(gè)embedded framework的model中實(shí)例化NSManagedObjectModel時(shí)，你必需使用.mom擴(kuò)展名作為model的URL，而不是采用.momd擴(kuò)展名。

NSURL *modelURL = [[NSBundle mainBundle]URLForResource:@"MyModel" withExtension:@"mom"];

Unknown class MyClass in Interface Builder file.

由于靜態(tài)框架采用靜態(tài)鏈接，linker會(huì)剔除所有它認(rèn)為無用的代碼。不幸的是，linker不會(huì)檢查xib文件，因此如果類是在xib中引用，而沒有在O-C代碼中引用，linker將從最終的可執(zhí)行文件中刪除類。這是linker的問題，不是框架的問題（當(dāng)你編譯一個(gè)靜態(tài)庫時(shí)也會(huì)發(fā)生這個(gè)問題）。蘋果內(nèi)置框架不會(huì)發(fā)生這個(gè)問題，因?yàn)樗麄兪沁\(yùn)行時(shí)動(dòng)態(tài)加載的，存在于iOS設(shè)備固件中的動(dòng)態(tài)庫是不可能被刪除的。

有兩個(gè)解決的辦法：

• 讓框架的最終用戶關(guān)閉linker的優(yōu)化選項(xiàng)，通過在他們的項(xiàng)目的Other Linker Flags中添加-ObjC和-all_load。
• 在框架的另一個(gè)類中加一個(gè)該類的代碼引用。例如，假設(shè)你有個(gè)MyTextField類，被linker剔除了。假設(shè)你還有一個(gè)MyViewController，它在xib中使用了MyTextField，MyViewController并沒有被剔除。你應(yīng)該這樣做：

在MyTextField中：

+ (void)forceLinkerLoad_ {}

在MyViewController中：

+(void) initialize {     [MyTextField forceLinkerLoad_]; }

他們?nèi)匀恍枰砑?ObjC到linker設(shè)置，但不需要強(qiáng)制all_load了。

第2種方法需要你多做一點(diǎn)工作，但卻讓最終用戶避免在使用你的框架時(shí)關(guān)閉linker優(yōu)化（關(guān)閉linker優(yōu)化會(huì)導(dǎo)致object文件膨脹）。

unexpected file type 'wrapper.cfbundle' in Frameworks &Libraries build phase

這個(gè)問題發(fā)生在把“假”框架項(xiàng)目作為workspace的依賴，或者把它當(dāng)作子項(xiàng)目時(shí)（“真”框架項(xiàng)目沒有這個(gè)問題）。盡管這種框架項(xiàng)目產(chǎn)生了正確的靜態(tài)框架，但Xcode只能從項(xiàng)目文件中看出這是一個(gè)bundle，因此它在檢查依賴性時(shí)發(fā)出一個(gè)警告，并在linker階段跳過它。

你可以手動(dòng)添加一個(gè)命令讓linker在鏈接階段能正確鏈接。在依賴你的靜態(tài)框架的項(xiàng)目的OtherLinker Flags中加入：

-framework MyFramework

警告仍然存在, 但不會(huì)導(dǎo)致鏈接失敗。

Libraries being linked or not being linked into the finalframework

很不幸， “真”框架和“假”框架模板在處理引入的靜態(tài)庫/框架的工作方式不同的。

“真”框架模板采用正常的靜態(tài)庫生成步驟，不會(huì)鏈接其他靜態(tài)庫/框架到最終生產(chǎn)物中。

“假”框架模板采用“欺騙”Xcode的手段，讓它認(rèn)為是在編譯一個(gè)可重定位格式的目標(biāo)文件，在鏈接階段就如同編譯一個(gè)可執(zhí)行文件，把所有的靜態(tài)代碼文件鏈接到最終生成物中（盡管不會(huì)檢查是否確實(shí)目標(biāo)代碼）。為了實(shí)現(xiàn)象“真”框架一樣的效果，你可以只包含庫/框架的頭文件到你的項(xiàng)目中，而不需要包含庫/框架本身。

Unrecognized selector in (some class with a category method)

如果你的靜態(tài)庫或靜態(tài)框架包含了一個(gè)模塊（只在類別代碼中聲明，沒有類實(shí)現(xiàn)），linker會(huì)搞不清楚，并把代碼從二進(jìn)制文件中剔除。因?yàn)樵谧罱K生成的文件中沒有這個(gè)方法，所以當(dāng)調(diào)用這個(gè)類別中定義的方法時(shí)，會(huì)報(bào)一個(gè)“unrecognizedselector”異常。

要解決這個(gè)，在包含這個(gè)類別的模塊代碼中加一個(gè)“假的”類。linker發(fā)現(xiàn)存在完整的O-C類，會(huì)將類別代碼鏈接到模塊。

我寫了一個(gè)頭文件 LoadableCategory.h，以減輕這個(gè)工作量：

#import "SomeConcreteClass+MyAdditions.h"

#import "LoadableCategory.h"  MAKE_CATEGORIES_LOADABLE(SomeConcreteClass_MyAdditions);   @implementation SomeConcreteClass(MyAdditions)

  ...

@end

在使用這個(gè)框架時(shí)，仍然還需要在Build Setting的Other Linker Flags中加入-ObjC。

執(zhí)行任何代碼前單元測試崩潰

如果你在Xcode4.3中創(chuàng)建靜態(tài)框架（或庫）target時(shí)，勾選了“withunit tests”，當(dāng)你試圖運(yùn)行單元測試時(shí)，它會(huì)崩潰：

Thread 1: EXC_BAD_ACCESS (code=2, address=0x0) 0 0x00000000 --- 15 dyldbootstrap:start(...)

這是lldb中的一個(gè)bug。你可以用GDB來運(yùn)行單元測試。編輯scheme，選擇Test，在Info標(biāo)簽中將調(diào)試器Debugger從LLDB改為GDB。