模組化之路（cocoPod VS framework）

模組化之路（實驗）

一直以來，我們都在嘗試讓程式碼儘可能高內聚、低耦合。比如我們將MVP框架改成MVVM框架，以解決Controller層程式碼臃腫不堪，讓model和view儘可能不要耦合。再比如，我們之前嘗試的路由，是為了讓Controller與Controller之間不要有太多的程式碼交集。而模組化實際上就是為了讓模組與模組直接相對獨立。

模組化優勢: 各模組程式碼與資源獨立使用與維護、獨立測試、各模組業務需求利於使用與維護、加快二次啟動速度(使用framework的前提下)

一

cocoapod 私有庫實踐

cocopod 是一個第三方庫依賴工具

要完成一個pod私有化全過程，需要三個倉庫(主專案倉庫、pod庫倉庫、PodDemo專案倉庫)、兩個專案(主專案、PodDemo專案)

1、在repo下建立私有庫(要遠端倉庫)

cd到cocoapods目錄下檢視本地的倉庫，會發現大概的檔案路徑是 ~/.cocoapods/repos/master … 這是系統中有使用到cocoapod後，在install pod的時候，會從cocoapod官網下載一份所有的庫的podspec檔案集合。這些都是共有庫的資源。所有專案需要使用pod庫的時候會在這裡索引，如果search不到，那就需要更新一下你的本地索引了。

因此，建立私有庫也是相同道理，就是在repos下建立一個類似master的私有的索引庫。所以，首先去個人的遠端倉庫(比如gitlab)建立一個git倉庫。比如是git地址是：

https://[email protected]/xx/BTCore.git

然後使用pod命令在Terminal執行：

$pod repo add BTCore https://[email protected]/xx/BTCore.git

執行成功後，就可以在 ~/.cocoapods/repos/目錄下看到BTCore檔案夾了。這個就是私有pod庫最終的索引。如果和同事合作的話，也同樣執行命令創建出一個repo即可。

OK，這一步就是順便完成了上面提到的pod庫倉庫。暫且擱置一旁！

2、建立一個新的PodDemo(要遠端倉庫)

PodDemo就是講程式碼打包成pod庫工具，另外它本身是一個完整的測試pod庫的專案。在將程式碼打包的前提需要先程式碼編譯通過，所以可以在demo裡盡情除錯。

使用pod命令建立一個標準的podDemo專案

$pod lib create BTCoreDemo

建立過程中會提示一些問題，類似：

What platform do you want to use?? [iOS/macOS]
What language do you want to use?/ [Swift/ObjC]
Would you like to include a demo application with your library? [Yes/No]
...

完成後就會生成一個專案

創建出來的專案的檔案結構會包含Example和Pod部分。類似：

BTCoreDemo
|——_pods.xcodeproj
|——BTCoreDemo
| |——Assets //放需要pod裡的資原始檔
| |——Classes //放pod庫程式碼檔案
|
|——Example //存放完整的專案檔案(除pod庫之外)
| |——BTCoreDemo //程式碼檔案，比如使用pod庫的檔案
| |——BTCoreDemo.xcodeproj
| |——BTCoreDemo.xcworkspace
| |——Podfile //庫使用到的第三方
| |——Podlock
| |——Pods //依賴的第三方
| |——Tests
|
|——BTCoreDemo.podspec //最重要的pod配置檔案

3、將程式碼移到Demo中，編譯成功後，update編譯成pod庫，並及時將程式碼更新到遠端倉庫，注意設定tag

接下來將解耦後的獨立程式碼放到Classes檔案中

cd 到Example目錄下，執行

$pod update //完成後會將class裡的東西打包成pod庫

完成之後，用xcode開啟工程，會在pods工程下看到Development Pods檔案，這裡的BTClassDemo就是之後使用的最終的pod庫的內容。

但是不是將程式碼移過來就完成了，首先需要驗證pod庫，而這第一步就是保證當前Demo工程編譯通過。

4、配置podspec（最重要）

在編譯通過的前提下，就可以對pod進行一些定製化的操作。

Pod::Spec.new do |s|
s.name = 'BTCoreDemo' #庫名稱
s.version = '0.0.1' #version要和git上的tag進行對應
s.summary = 'BT學院App中基礎檔案、公共檔案、第三方庫等整合框架庫'
s.description = <<-DESC
'BT學院App中基礎檔案、公共檔案、第三方庫等整合框架庫,gogogogo'
DESC
s.homepage = 'https://[email protected]/caifan/BTCoreDemo' #隨便一網址
s.license = { :type => 'MIT', :file => 'LICENSE' }
s.author = { 'caifan' => '[email protected]' }
s.source = { :git => 'https://[email protected]/caifan/BTCoreDemo.git', :tag => '0.0.1' } #git地址，當前demo的git地址，tag則要和上面的version一樣

s.platform = :ios,'9.0' #平臺就iOS版本

s.requires_arc = true #是否支援arc

s.prefix_header_file = 'BTCoreDemo/Classes/prefixHeader.h' #pch標頭檔案，注意：寫完prefixHeader.h後，要執行pod update，成功後才會將prefixHeader.h檔案的內容copy一份到Support Files下的.pch中。否則專案中使用不了
s.frameworks = 'UIKit', 'AVFoundation','QuartzCore' #對外依賴的庫

#subspec: 建立子分支，每個子分支對應一層資料夾，注意：雖然在當前Demo中pod庫看似有檔案層次，但是當最終生成pod庫之後，只會存在子分支的檔案層次，各子分支裡的所有檔案都會被拍扁成一個層級檔案
#source_files: 子分支的檔案路徑，這裡有時候會出現找不到檔案的情況，所以要實時更新，多個檔案用,分割開，**/*表示子資料夾下所有的檔案和資料夾
#public_header_files: 子分支的標頭檔案路徑。
#dependency: 依賴，子分支之間的依賴、對第三方的依賴
#resource: 資源路徑

s.subspec 'Kit' do |kit|
kit.source_files = 'BTCoreDemo/Classes/Kit/**/*',
kit.public_header_files = 'BTCoreDemo/Classes/Kit/**/*.h'
kit.dependency 'BTCoreDemo/ThirdParty'
end

s.subspec 'ThirdParty' do |thirdparty|
thirdparty.source_files = 'BTCoreDemo/Classes/ThirdParty/**/*'
thirdparty.public_header_files = 'BTCoreDemo/Classes/ThirdParty/**/*.h'
thirdparty.resource = 'BTCoreDemo/Assets/SVProgressHUD.bundle'
end

s.dependency 'Masonry', '~> 1.0.2'

end

注意，每次完成後，需要直接pod update，這樣pod裡的檔案才會重新整理更新。

然後給podspec打上tag。注意tag必須和version一致

$cd .. //這裡是從Example資料夾退到上一層，含有podspec檔案的層級
$git tag 0.0.1
$git push --tag

最後，進行驗證:

$pod lib lint

如果要忽略警告，加上—allow-warnings，如果使用了第三方庫，則加上—use-libraries。

如果驗證不通過的話，是沒法push到repos裡的。

而驗證通過的前提就是不能有任何error。（這才是整個專案最蛋疼的地方）

5、將編譯驗證完成的podspec庫push到第一步建立的repo私有庫中（完成後會看到私有庫的遠端倉庫也會有一份podspec），在podspec檔案層級下進行

$pod repo push BTCoreDemo BTCoreDemo.podspec --allow-warnings

執行完這句後，會在第一步建立的BTCoreDemo下多出一個資料夾，資料夾下是對應版本的podspec。同時第一步建立的遠端的git倉庫也會多出這些檔案。

至此，說明pod庫是可用的了。

6、檢測是否能search到私有庫

$pod search BTCoreDemo

如果搜尋不到就先執行：

$rm ~/Library/Caches/CocoaPods/search_index.json

7、將pod成功的私有庫新增到原來的專案中

編譯原來專案的Podfile，將BTCoreDemo新增進去。

注意，podfile中需要把共有和私有的兩個地址都加上。

source 'https://github.com/CocoaPods/Specs.git' # 官方庫
source 'https://[email protected]/xx/BTCore.git' #私有庫

8、碼過留坑

這裡整理一下遇到的問題及解決的方案：

1、pod lib lint 中碰到的各種error和warn

ERROR | [iOS] file patterns: The resource_bundles pattern for SVProgressHUD did not match any file.

分析：目前總結出現這個問題的原因一般為：1、沒有打tag；2、tag與version不一致；3、各種路徑錯誤（這個有可能是它本身會抽，有時候提示路徑問題，但是改完倒騰回來就又有用了，也可能是沒有掌握到精髓）

—allow-warnings 忽略警告的驗證過程

2、資原始檔問題bundle

resource和resource_bundles的差異，參考簡書

3、subspec分支問題、資料夾問題

目前所知資料夾是沒法做層級的，只有分子分支，每個子分支會是一個資料夾。

4、swift混編問題

無論swift檔案在哪裡，使用#import 匯入swift橋接檔案
這裡的XX指的是pod包的名稱，其次要注意的是swift類應該用@objc標註宣告

5、編譯不通過

Returned an unsuccessful exit code. You can use --verbose for more information.
打成pod包的前提就是編譯一定要通過，所以這個沒有捷徑可走

6、庫迴圈依賴問題

There is a circular dependency between BTCore/ThirdParty and BTCore/Kit

出現這個問題的原因是由於pod庫裡面有子分支，每個子分支也是一個單獨的pod庫，所以分支之間檔案的引用如果不要pch的話，就需要使用dependency做依賴。因為子分支有可能會有相互引用到對方檔案的問題，所以如果使用dependency，就有可能會相互依賴的問題，最後導致circular dependency。

目前的解決問題就是子分支也解耦。如果子分支無法解耦，那就使用pch全域性引入需要用到的檔案。不過這也導致一個問題，那就是子分支就沒法單獨做pod使用了。所以最好的解決方案是解耦。

7、pch使用

語法： prefix_header_file: 預編譯標頭檔案路徑，將該檔案的內容插入到Pod的pch檔案內
1:ERROR | [iOS] unknown: Encountered an unknown error (No such file or directory @ rb_sysopen - /private/var/folders/n2/0fyx87s539j43pqj65tnwccc0000gn/T/CocoaPods-Lint-20180829-11315-7jhkz-BTCore/Pods/BTCore/BTCore/Classes/prefixHeader.pch) during validation.

目前得出的結論，pch除了能在PodDemo中使用，在pod庫中，完全就是絆腳石般的存在

8、壓死駱駝的最後一根稻草

xcodebuild: Returned an unsuccessful exit code. You can use --verbose for more information.

無解！！！

初步估計是因為pch的問題。查看了很多第三方pod，發現壓根不使用pch這玩意。而且每次error後的note也都是提示pch裡的import檔案not found。

所以，首先。準備好子分支之間的拆分。不能出現迴圈依賴的問題，不能相互import，總之pch沒有作用。

掉進坑裡，掙扎出不來了！！

pod lib lint —allow-warnings 忽略警告的驗證過程

pod repo push mySpec myLibrary.podspec —allow-warnings

9、pod存在的問題：

1、資料夾問題

pod暴露的東西只存在public_header_files中，而且目前沒有找到資料夾區分層次關係的問題。

2、生成的pod與實際能夠使用的pod有區別

生成的pod在demo中和實際驗證之後pod update下來的pod檔案層次是不一樣的，感覺非常不友好。而且及時生成了pod，驗證也存在很多問題，且問題難以定位。

二

cocoa touch framework實踐

1、什麼是動態庫

庫Library是一段編譯好的二進位制檔案，如果想自己的實現程式碼不暴露給別人，就可以使用庫的形式進行封裝，編譯的時候只需要link就好。連結又存在靜態連結和動態連結兩種方式，於是便產生了靜態庫和動態庫。

靜態庫即.a檔案(windows的lib)，靜態庫編譯的時候會將二進位制檔案直接copy進目標程式中，之後將隨著一起載入，所以也就導致目標檔案太大的問題。

動態庫則是.tab、.dylib檔案，與動態庫不同的是編譯的時候不會被copy，而是隻在目標檔案中存一份動態庫的引用。它不會導致體積問題，但是動態載入的時候也會導致一些效能損耗。

Framework是一直打包方式，它將二進位制檔案、標頭檔案、資原始檔打包到一起。

2、建立自己的framework

1、建立framework

開啟xcode 選擇建立 cocoa touch framework 就可以了。
這裡有幾點注意：

建立動態庫需要去setting中將mach-Type改成Dynamic Library
如果要引入其他的framework，需要去setting中將Allow non-modular includes in Framework Modules 改成YES。
如果有使用swift，需要去設定好swift的版本
framework不允許存在其他的framework
如果是Swift&OC混編的framework，則要把swift中使用到的OC標頭檔案在Header中放到public中，因為framework不支援bridge
將要對外的標頭檔案也放到Header的public中
把需要新增的依賴庫加上，尤其是使用了第三方，比如wechatsdk的
把需要對外暴露的標頭檔案在xx.h裡暴露出來，否則會有警告

2、使用framework

將framework拖進來後，將framework copy一份。確保Embedded Binaries存在你的framework
如果framework中有swift檔案而當前工程還沒有swift檔案，則需要先建立一個swift bridge。
將原來framework依賴到的第三方也要pod進來

3、framework使用其他第三方framework

蘋果禁止在Dynamic Framework中使用Framework。比如alipay。而pod的framework也只是將引用打包進去。所以這種依賴要在自己的framework的readme中註釋清楚。

4、給framework新增armv7s架構

模擬器對應的核心框架中，32位處理器對應的是i386，64位處理器對應的是x86_64

真機核心情況如下：

armv7: iPhone4 以下機型、iPad mini、iPod、iPad3以下

armv7s: iPhone5、iPhone5C、iPad4

arm64: iPhone5s以上、iPad air、iPad mini2

在Architectures新增完armv7s後，一直報error: Invalid bitcode signature ; clang: error: linker command failed with exit code 1 (use -v to see invocation)。

解決的步驟就是：將DeviceData刪掉，然後給所有pod導進來的framework新增上armv7s。重新編譯就OK了。

3、整合framework，將模擬器和真機的debug、release包整合到一起

首先將每一次build都只有一個包產生。而要產生release和debug包得分別在release和debug下進行編譯，這樣在Debug-iphoneos下兩個資料夾才有對應的包。然後在將Build Active Architecture Only設定成NO(包括pod庫裡的target)，這樣才能在切換真機與模擬器的同時編譯出對應的iphoneos和iphonesimulator包

使用命令列打包

//檢視包的核心架構有哪些：
$lipo -info /Users/fengcaifan/Library/Developer/Xcode/DerivedData/BTCore-foehvkpuvmgklxekqrhynchxldkr/Build/Products/Release-iphoneos/BTCore.framework/BTCore
// armv7 armv7s arm64

//將Debug環境下的真機和模擬器一同打包：
$cd 到包目錄

$lipo -create Debug-iphoneos/BTCore.framework/BTCore Debug-iphonesimulator/BTCore.framework/BTCore -output BTCoreDebugFramework //結束後會產生一個包

$lipo -info BTCoreDebugFramework //檢視包內容 Architectures in the fat file: BTCoreDebugFramework are: i386 x86_64 armv7 armv7s arm64

//這裡執行完是整合出一個可執行檔案，還並不是.framework。所以只需將這個可執行檔案將上述任意framework裡的可執行檔案替換掉就可以使用了。

這裡碰到一個問題，使用cocoapod的庫，使用Aggregate 指令碼打包一直報swift找不到pod庫。

4、framework結合cocoapod的實踐

framework中使用cocoapod是將需要依賴的第三方庫以pod的形式匯入進來。但是要注意的一點就是framework如果是swift專案或者儲存swift混編，則需要將pod庫打包成framework。

5、framework結合carthage的實踐

carthage和cocoapod一樣是一個三方庫管理工具, carthage和cocoapod的區別。因為carthage只生成framework，所以更符合我們這種混編的framework的需求。因為它目前流行於swift第三方庫中，對於一些老的OC庫還不支援，比如Masonry。所以這裡按自己需求使用。

6、上線之前，最好將framework進行拆包，只上傳Release真機包到app store。

拆包，將需要的架構拆出來，整合成新的架構

$ lipo BTCore -thin armv7 -output BTCoreV7 //將BTCore中armv7架構拆出來，生成一個叫BTCoreV7可執行檔案
$ lipo BTCore -thin arm64 -output BTCore64 //將BTCore中arm64架構拆出來，生成一個叫BTCore64可執行檔案
$ lipo -create BTCoreV7 BTCore64 -output BTCoreV764 //將BTCoreV7 BTCore64整合成一個新的BTCoreV764

7、碼過留坑

1、framework中OC與Swift類的相互呼叫(無法使用bridging導致的鍋)

因為framework無法使用bridging，所以swift中使用到的OC的類，必須得放到public中。然後在xx.h (xx是專案名稱)中按說明的格式import進來

2、framework裡的swift使用pod裡的OC類(無法使用bridging導致的鍋)

因為framework無法使用bridging，所以pod裡的oc類無法通過上述方式匯入，而應該通過將第三方pod生成framework匯入，即在podfile中新增 use_framework!。但是要注意的是，此時生成的framework在xcode中還顯示紅色，得把mach-type和Allow non-modular..設定好，build之後才能在pod資料夾找到framework。

3、dyld: Library not loaded: @rpath/libswiftCore.dylib (Demo裡沒有swift bridge導致的鍋)

說明framework裡有swift類，但是demo中沒有建立swift bridge。所以去建立一個就好了

4、Reason: image not found

embedded沒有framework導致的。

5、無法使用framework裡的類(request改成optional導致的鍋)

實際上，request是不允許改成optional的，否則執行時是沒法使用framework裡的類，正確的做法就是去檢視framework的allow non_module是否配置成功。然後確保demo中embedded中是否存在自己的framework。

6、framework中使用到的資源問題

framework中使用到的資源，最好應該單獨建立一個bundle，讓bundle和framework分離，但是這樣子使用的時候必須表明屬於哪個bundle會恨蛋疼。否則就是資源還是放在main bundle裡，不過這個獨立demo就沒法使用資源了。檢視 framework關於資源的讀取

7、framework存在的問題

因為framework只暴露了標頭檔案，所以沒法對其進行除錯。這會是一個很蛋疼的問題
如果要達到framework最大優勢化，應該給每個framework建立單獨的測試和除錯Demo
每個子模組也應該有對應的環境設定、登入資訊等模組
如果不能自動打包，收到打包會恨繁瑣，最好要有對應的工具鏈

三

專案處理

(卓明設計)

資料夾隔離

老的專案我們大多數是按單個小業務或者頁面分資料夾，然後分成M、V、C。而模組化我們需要做如下幾件事：

在就要求原來的基礎上之上套一層模組資料夾;
將每一個模組除M、V、C之外的api、對外依賴、資原始檔、巨集也都分離出來;
將各個模組共享的檔案、資源、巨集整合到一起，沉澱到基礎庫裡
模組間使用路由進行通訊。controller之間儘量不依賴，相互通訊儘可能走路由。通訊之間儘可能減少資訊流的傳遞

抽出基礎庫

在我們專案裡，我們稱之為BTCore。
可以看一下目前我們的BTCore有哪些東西：

Base         自定義basenavigation basecontroller等
Macro      巨集定義 + 協議
ThirdParty 經過用原始碼匯入的第三方 SDK
Kit         公用View + 所有工具類
Api api模組

豆瓣模組化