1, 同一個(gè)命名域內(nèi)部不需要用CTMediator

問(wèn): 模塊內(nèi)部需不需要走CTMediator。比如A1跳A3，直接A1中引入A3，然后push過(guò)去就行了，外部是根本跳不到A3的。
那也就是說(shuō)內(nèi)部不想公布的跳轉(zhuǎn)就不走CTMediator了？

答:
對(duì)啊，我之前以為你說(shuō)的A1、A2、A3是不同的模塊來(lái)著。
其實(shí)判斷是否應(yīng)該使用mediator的重要參考條件是：調(diào)用方是否有必要引入響應(yīng)方的命名域。
像你這樣命名域本來(lái)就已經(jīng)在里面了，就沒(méi)必要走mediator了。mediator是給那些需要調(diào)用功能但又不需要引入命名域的調(diào)用者去使用的。

2, app 組件化的目的究竟是什么?

1,為了提高多人開(kāi)發(fā)的機(jī)動(dòng)性，
2.為了提高代碼的遷移能力，
3.降低大型App開(kāi)發(fā)的復(fù)雜度，組件化可以理解成“分治法”。

3, 關(guān)于不同模塊間的category放置問(wèn)題

實(shí)際工作中，每一個(gè)模塊的category單獨(dú)是一個(gè)pod，然后這個(gè)pod由這個(gè)模塊的開(kāi)發(fā)者維護(hù)，每更新一版模塊，這個(gè)模塊的開(kāi)發(fā)者就有責(zé)任去維護(hù)對(duì)應(yīng)的category。
不存在針對(duì)接口封裝service類(lèi)的需要，更沒(méi)有單獨(dú)搞個(gè)web后臺(tái)的需要。也不應(yīng)該把這個(gè)category放在模塊的pod中，也不能把所有的category都放在一個(gè)pod中。
使用者需要調(diào)用哪個(gè)模塊，就只引入哪個(gè)模塊對(duì)應(yīng)的category，然后調(diào)用這個(gè)category里面對(duì)應(yīng)的方法就可以了。
最后，category是否放在同一個(gè)pod中，跟安裝包的大小沒(méi)有任何關(guān)系。

把category放在模塊的pod中,這會(huì)使得響應(yīng)者模塊不得不依賴(lài)mediator，這種依賴(lài)是完全沒(méi)有必要的。在將來(lái)模塊復(fù)用的時(shí)候會(huì)帶來(lái)問(wèn)題，具體問(wèn)題的復(fù)雜度取決于你mediator的復(fù)雜度。
你現(xiàn)在看mediator好像干干凈凈的什么都沒(méi)有，但是業(yè)務(wù)復(fù)雜了之后，router、cache、validate邏輯就有可能變多，這都是說(shuō)不好的事情。所以模塊應(yīng)該盡量做到能不依賴(lài)mediator就不依賴(lài)mediator，不要貪圖所謂的方便引入額外耦合，一點(diǎn)都不值得。

4.模塊間更新的處理

問(wèn):

如果所有的業(yè)務(wù)組件都依賴(lài)于網(wǎng)絡(luò)組件，此時(shí)網(wǎng)絡(luò)組件發(fā)生了一次變更，要求業(yè)務(wù)組件必須更新。
這樣的話(huà)，如果沒(méi)做組件化之前，可能一個(gè)批量替換就搞定了（假定是這樣。。）
但是做了組件化之后，有很多事情要做：1、只能一個(gè)組件一個(gè)組件的修改，因?yàn)椴辉谕粋€(gè)工程中了2、每個(gè)組件都得更新 podspec，并打 tag，更新 podspec 源倉(cāng)庫(kù)3、修改相關(guān)業(yè)務(wù)組件和主工程 podfile 里依賴(lài)的版本號(hào)
這樣就多了好多工作量，不知道您有沒(méi)有遇到這類(lèi)問(wèn)題呢？

答:

我們私有pod引入的時(shí)候都不帶版本號(hào)的，默認(rèn)大家都使用最新的。
各業(yè)務(wù)線在podupdate之后各自解決更新導(dǎo)致的編譯問(wèn)題，不過(guò)這種情況極少，一般都是一次更新就所有都更新過(guò)去了。

5 關(guān)于引用第三方庫(kù)

untitled.png

6. 考慮進(jìn)行這種組件化的方案，以盡量降低各組件之間的耦合

問(wèn)1:

隨著我們的項(xiàng)目模塊越來(lái)越大，也在考慮進(jìn)行這種組件化的方案，以盡量降低各組件之間的耦合，我的思路1. 各模塊組件化這個(gè)可以參考你這篇文章實(shí)現(xiàn)，應(yīng)該能比較好的解決2. 各模塊組件化后，希望各組件有自己?jiǎn)为?dú)工程，而不必將代碼全部堆到主工程內(nèi)這樣做的好處很明顯，各模塊單獨(dú)開(kāi)發(fā)互相不影響3. 各模塊的代碼可以套一個(gè)殼工程里面，可以單獨(dú)運(yùn)行，可以單獨(dú)遞交測(cè)試這樣方便QA測(cè)試，也便于版本控制，另外也可以保證代碼訪問(wèn)安全，相關(guān)模塊的開(kāi)發(fā)人員只有自己模塊的代碼訪問(wèn)權(quán)限，因?yàn)橛袣すこ蹋胁挥绊懰{(diào)試代碼4. 封裝一些公用的組件，譬如登錄，一些utility庫(kù)等，其他模塊可以引用和使用這些組件。譬如有一個(gè)組件叫“我的賬單”，那運(yùn)行這個(gè)組件肯定先需要登錄，那么包含“我的賬單”的代碼的殼工程就需要使用“登錄”這個(gè)組件的功能5. 最后有一個(gè)主工程，會(huì)將所有組件打包生成最后的ipa安裝包
以上就是我這邊的一個(gè)大致思路，如果不對(duì)希望可以指點(diǎn)一下，目前也有幾個(gè)問(wèn)題想問(wèn)一下1. 這么多組件（包括自己組件的殼工程），主工程該如何組織。用CocoaPods的私有源的方式嗎？如果是的話(huà)該如何實(shí)現(xiàn)呢2. 對(duì)一些公共的圖片資源，又該如何處理呢，譬如組件A和組件B都需要用到一張公共的圖片，組件A的殼工程和組件B的殼工程都會(huì)包含這張圖片，但是為了避免資源重復(fù)，在把這兩個(gè)組件引入到主工程的時(shí)候該如何處理呢？ 是把公共的圖片打成一個(gè)bundle的形式共享給各個(gè)組件使用么？3. 每個(gè)組件肯定有一些網(wǎng)絡(luò)API的調(diào)用，那這些網(wǎng)絡(luò)API是寫(xiě)在每個(gè)組件里面（感覺(jué)這樣太分散），還是說(shuō)弄一個(gè)公共的負(fù)責(zé)所有網(wǎng)絡(luò)請(qǐng)求的API組件（感覺(jué)這樣也不太合理，這個(gè)公共的組件就需要知道每個(gè)組件的網(wǎng)絡(luò)請(qǐng)求的參數(shù)及邏輯）
以上是我的一些思考和疑問(wèn)，希望有空的時(shí)候能回復(fù)一下。 最好是能寫(xiě)個(gè)簡(jiǎn)單的demo

答1:

1. 是的，自建私有pod源。
2. 我們目前是所有的圖片單獨(dú)放在一個(gè)pod里面的，然后業(yè)務(wù)pod依賴(lài)這個(gè)圖片pod。這樣比較容易做去重。我是所有的圖片都在一個(gè)pod里面，這個(gè)pod的podspec只寫(xiě)了要引入resource
3. 我們網(wǎng)絡(luò)層是rtnetworking，這是一個(gè)單獨(dú)pod。然后所有的apimanagers都按照業(yè)務(wù)分好類(lèi)放在各自單獨(dú)的一個(gè)pod中。由于我的項(xiàng)目是離散型api設(shè)計(jì)，任何有網(wǎng)絡(luò)請(qǐng)求的業(yè)務(wù)pod，就都依賴(lài)apimanager的pod就好了。
關(guān)于離散型api設(shè)計(jì)，你可以去看一下前面的網(wǎng)絡(luò)層文章。

7.如果ModuleA需要取得ModuleB的異步返回值需要怎么處理。比如其他模塊調(diào)用登陸模塊

 參數(shù)中帶上block，用block接收異步返回值。