靜態庫與動態庫的區別

首先來看什麼是庫，庫(Library)說白了就是一段編譯好的二進制代碼，加上頭文件就可以供別人使用。

什麼時候我們會用到庫呢？一種情況是某些代碼需要給別人使用，但是我們不希望別人看到源碼，就需要以庫的形式進行封裝，只暴露出頭文件。另外一種情況是，對於某些不會進行大的改動的代碼，我們想減少編譯的時間，就可以把它打包成庫，因為庫是已經編譯好的二進制了，編譯的時候只需要 Link 一下，不會浪費編譯時間。

上面提到庫在使用的時候需要 Link，Link 的方式有兩種，靜態和動態，於是便產生了靜態庫和動態庫。

靜態庫

靜態庫即靜態鏈接庫（Windows 下的 .lib，Linux 和 Mac 下的 .a）。之所以叫做靜態，是因為靜態庫在編譯的時候會被直接拷貝一份，復制到目標程序裡，這段代碼在目標程序裡就不會再改變了。

靜態庫的好處很明顯，編譯完成之後，庫文件實際上就沒有作用了。目標程序沒有外部依賴，直接就可以運行。當然其缺點也很明顯，就是會使用目標程序的體積增大。

動態庫

動態庫即動態鏈接庫（Windows 下的 .dll，Linux 下的 .so，Mac 下的 .dylib/.tbd）。與靜態庫相反，動態庫在編譯時並不會被拷貝到目標程序中，目標程序中只會存儲指向動態庫的引用。等到程序運行時，動態庫才會被真正加載進來。

動態庫的優點是，不需要拷貝到目標程序中，不會影響目標程序的體積，而且同一份庫可以被多個程序使用（因為這個原因，動態庫也被稱作共享庫）。同時，編譯時才載入的特性，也可以讓我們隨時對庫進行替換，而不需要重新編譯代碼。動態庫帶來的問題主要是，動態載入會帶來一部分性能損失，使用動態庫也會使得程序依賴於外部環境。如果環境缺少動態庫或者庫的版本不正確，就會導致程序無法運行（Linux 下喜聞樂見的 lib not found 錯誤）。

iOS Framework

除了上面提到的 .a 和 .dylib/.tbd 之外，Mac OS/iOS 平台還可以使用 Framework。Framework 實際上是一種打包方式，將庫的二進制文件，頭文件和有關的資源文件打包到一起，方便管理和分發。

在 iOS 8 之前，iOS 平台不支持使用動態 Framework，開發者可以使用的 Framework 只有蘋果自家的 UIKit.Framework，Foundation.Framework 等。這種限制可能是出於安全的考慮（見這裡的討論)。換一個角度講，因為 iOS 應用都是運行在沙盒當中，不同的程序之間不能共享代碼，同時動態下載代碼又是被蘋果明令禁止的，沒辦法發揮出動態庫的優勢，實際上動態庫也就沒有存在的必要了。

由於上面提到的限制，開發者想要在 iOS 平台共享代碼，唯一的選擇就是打包成靜態庫 .a 文件，同時附上頭文件（例如微信的SDK）。但是這樣的打包方式不夠方便，使用時也比較麻煩，大家還是希望共享代碼都能能像 Framework 一樣，直接扔到工程裡就可以用。於是人們想出了各種奇技淫巧去讓 Xcode Build 出 iOS 可以使用的 Framework，具體做法參考這裡和這裡，這種方法產生的 Framework 還有 “偽”(Fake) Framework 和 “真”(Real) Framework 的區別。

iOS 8/Xcode 6 推出之後，iOS 平台添加了動態庫的支持，同時 Xcode 6 也原生自帶了 Framework 支持（動態和靜態都可以），上面提到的的奇技淫巧也就沒有必要了（新的做法參考這裡）。為什麼 iOS 8 要添加動態庫的支持？唯一的理由大概就是 Extension 的出現。Extension 和 App 是兩個分開的可執行文件，同時需要共享代碼，這種情況下動態庫的支持就是必不可少的了。但是這種動態 Framework 和系統的 UIKit.Framework 還是有很大區別。系統的 Framework 不需要拷貝到目標程序中，我們自己做出來的 Framework 哪怕是動態的，最後也還是要拷貝到 App 中（App 和 Extension 的 Bundle 是共享的），因此蘋果又把這種 Framework 稱為 Embedded Framework。

Swift 支持

跟著 iOS8 / Xcode 6 同時發布的還有 Swift。如果要在項目中使用外部的代碼，可選的方式只有兩種，一種是把代碼拷貝到工程中，另一種是用動態 Framework。使用靜態庫是不支持的。

造成這個問題的原因主要是 Swift 的運行庫沒有被包含在 iOS 系統中，而是會打包進 App 中（這也是造成 Swift App 體積大的原因），靜態庫會導致最終的目標程序中包含重復的運行庫（這是蘋果自家的解釋）。同時拷貝 Runtime 這種做法也會導致在純 ObjC 的項目中使用 Swift 庫出現問題。蘋果聲稱等到 Swift 的 Runtime 穩定之後會被加入到系統當中，到時候這個限制就會被去除了（參考這個問題 的問題描述，也是來自蘋果自家文檔）。

CocoaPods 的做法

在純 ObjC 的項目中，CocoaPods 使用編譯靜態庫 .a 方法將代碼集成到項目中。在 Pods 項目中的每個 target 都對應這一個 Pod 的靜態庫。不過在編譯過程中並不會真的產出 .a 文件。如果需要 .a 文件的話，可以參考這裡，或者使用 CocoasPods-Packager這個插件。

當不想發布代碼的時候，也可以使用 Framework 發布 Pod，CocoaPods 提供了vendored_framework 選項來使用第三方 Framework，具體的做法可以參考這裡和這裡。

對於 Swift 項目，CocoaPods 提供了動態 Framework 的支持，通過 use_frameworks!選項控制。

更多有關代碼分發的擴展資料可以參考這篇博客： http://geeklu.com/2014/02/objc-lib/

參考資料

• https://stackoverflow.com/questions/2649334/difference-between-static-and-shared-libraries
• https://stackoverflow.com/questions/25080914/will-ios-8-support-dynamic-linking
• https://stackoverflow.com/questions/6245761/difference-between-framework-and-static-library-in-xcode4-and-how-to-call-them
• http://blog.cocoapods.org/CocoaPods-0.36/
• 轉載自：https://skyline75489.github.io/post/2015-8-14_ios_static_dynamic_framework_learning.html