轉載請注明出處
關于GB移動小組iOS端關于新架構的一些研究
前幾天就開始研究了關于新項目的架構,也研究了模塊化架構和關于Cocoapods私有庫的研究衅枫。
對于前幾天的研究也有了自己的心得嫁艇,就把我們目前研究的一套適合自己項目的框架拿出來。
先說一下架構弦撩,大神可以忽略下面我的胡言亂語了步咪,直接可以關閉不看了。
可能我下面說的你們覺得既陌生又熟悉益楼,甚至熟悉不能再熟悉猾漫,陌生的覺得我說的有點不對点晴。
研究的不是太透徹可以忽略.....
架構思想:
模塊化架構 + MVVM變種的設計模式 +Cocoapods版本依賴
下面是我們星期五簡單寫了一下PPT,做一下簡單的講解。
為什么要在新項目使用新的框架呢悯周?
- 大GB項目耦合度太高
- 相互依賴性太強
- 對于代碼沒有寫接口 有的在基類里面寫死了
- 之前的代碼對于新項目很難做到重用
- 之前的設計模式既不是MVC 也不是MVVM 亂作一團
- 項目文件命名太隨意 容易和其他人的文件有沖突
- 項目的功能無法提煉
- 功能沒有版本控制 回滾太麻煩
- 兩個一樣的APP進行一樣的功能 修改一個APP的BUG還需要同步代碼到另外一處
之前項目的架構
之間的依賴如果用一個東西形容那就是地球網絡之間的連線
![C6B2DB3A-CF37-40A6-BA26-3DAEF9F4E637](https://ww2.sinaimg.cn/large/006tNbRwgw1fbs6q2f613j30lr0d9adz.jpg)
現在新項目架構的構想
![E4D70902-56E5-4DA0-9A61-3981902624EA](https://ww1.sinaimg.cn/large/006tNbRwgw1fbs6qlye4rj30sg0f1774.jpg)
現在的模塊條跳轉
![984573B4-B7B2-47B1-9284-020DEFC159C0](https://ww1.sinaimg.cn/large/006tNbRwgw1fbs6rgrbxpj30l90do0vc.jpg)
模塊中心
![B8E1B5E1-19D2-4414-BEE7-FBDC8184E1B0](https://ww1.sinaimg.cn/large/006tNbRwgw1fbs6rxz02nj30li0dr76n.jpg)
模塊中心件核心思想
模塊A如果跳轉到B
模塊A發(fā)送路由到中間件 中間件分別分發(fā)剩下的模塊 紅色的線代表無法解析 藍色可以解析成功 進行跳轉
![740FDE2D-F676-4E6E-B56B-FFFC030E050D](https://ww3.sinaimg.cn/large/006tNbRwgw1fbs6sm7ypaj30lf0czjsx.jpg)
對于新架構優(yōu)點
- 層次分明
- 不會相互依賴 高層依賴底層 底層不依賴高層
- 容易分離模塊
- 查找問題十分的方便
- 容易解決多個APP存在的同一個問題
- 適用性強
簡單的描述什么是CocoaPods
紅色代表app從源代碼安裝庫
黃色代表從一個APP更新代碼到庫再去更新其他的APP
![2416918F-C1B8-4098-960A-AA49FC088323](https://ww4.sinaimg.cn/large/006tNbRwgw1fbs6tkibtkj30ld0cy0uj.jpg)
使用CocoaPods的好處
- 模塊有歷史版本 并且每一個版本都能獨立編譯運行
- 一處修改 處處運行
- 一人造輪子 全公司使用
- 每一次都有版本記錄 好維護 找問題
- 每一次發(fā)布都能保證模塊化結構清晰可見
- 其他的APP一鍵集成 刪除
關于Module設計模式,我們稱為MVVM的變種模式
- 目前大GB項目使用的是基于MVVM變種 我們準備使用全新的設計模式
- Controller: 負責界面的跳轉
- view:負責界面的展示
- Modle: 負責后臺接口數據解析
- ViewModel: 負責界面數據解析 和發(fā)送請求
- Api: 負責封裝請求參數
- Other: 負責Manager 類初始化配置Style 或者其他
- 我們叫做MVVM-AOC設計模式
對于上面的PPT粒督,小組的小伙伴也提出了不同的建議和意見。我是一致的堅持把不同的模塊也進行Cocoapods托管禽翼,這樣才真正的模塊化屠橄,才會模塊單獨編譯,模塊版本控制闰挡,模塊一鍵集成锐墙。
下面是上面所做的PPT做一個講解,希望大家看完也可以提出自己不同的見解长酗。
為什么我一再的堅持使用Cocoapods托管溪北?
我是一個樂于分享代碼的人,但是這不意味著分享公司的代碼夺脾。
我現在對于公司項目進行Cocoapods進行托管之拨,只是想把代碼分享公司所有其他的項目。哪怕大家項目模塊不一樣咧叭,總可以借鑒蚀乔,進行分支變種吧。
哪怕分支變種也不行菲茬,對于自己的項目進行依賴進行模塊化的版本記錄我覺得也比之前直接放在工程里面是一個好的方案乙墙。
對于我來說什么是模塊化,模塊化就是大樹上面的樹葉生均。樹葉離開大樹可能不能活听想,但是大樹離開樹葉照樣生長。
對于大樹來說马胧,不能因為扯掉一片樹葉就要連枝扯掉汉买。
所以對于工程和模塊來說,工程就是所謂的大樹佩脊,模塊就是葉子蛙粘。
模塊可以單獨的編譯,但是離開了工程可能運行不了威彰。但是工程離開了其他的模塊也是可以編譯運行的出牧。這是我對于模塊化架構設計的一個理解。
什么東西可以讓代碼進行模塊化和版本呢控制歇盼,單獨編譯呢舔痕,并且可以意見集成呢。我現在除了Cocoapod,別的沒想到任何可以替代伯复,這就是我堅持使用Cocoapodas的原因慨代。
![2B8D3AA6-7393-495B-B4FC-AE29CC6B06C2](https://ww1.sinaimg.cn/large/006tNbRwgw1fbsb1p44lgj307405ht8z.jpg)
工程和模塊的依賴
![A80263AE-4C03-4B1B-82F8-DD2D954DF81B](https://ww2.sinaimg.cn/large/006tNbRwgw1fbsb66jmm7j30t70kb77j.jpg)
模塊的依賴
![7D04518D-D5A3-48AB-9CE9-CA376F0A20F6](https://ww3.sinaimg.cn/large/006tNbRwgw1fbsbfq3el0j30td0k6wh1.jpg)
我們口中所了解的MVVM的變種模式
![38A502DB-90AA-44BF-8E3B-289890124981](https://ww2.sinaimg.cn/large/006tNbRwgw1fbsbnaro1yj30rz0ougpv.jpg)
我們稱作MVVM-AOC變種的設計模式。
每一個模塊里面都是一個MVVM-AOC的設計模式,是屬于一個模式的循環(huán)
中間件,是解決模塊之間傳遞的中間轉發(fā)器啸如。模塊之間進行配置文件到轉發(fā)器侍匙,轉發(fā)器再把配置文件到對應的模塊。
我們之前想到的是模塊先注冊到中間件叮雳,之后其他模塊發(fā)送配置文件到中間件想暗,中間件再把配置文件轉發(fā)到之前注冊的模塊。
這是我了解的模塊化架構的核心思想帘不。
關于MVVM-AOC設計模式就如上圖所示那樣子江滨。
新架構層次的說明
之前是相互依賴的所以會造成無法解耦,造成錯綜復雜的交叉網絡⊙峋現在如果分為層級,上層只能依賴下層的文件告唆。下層無法依賴上層的棺弊,同級用中間件進行連接,就不會造成錯綜復雜的關聯關系擒悬。
![6E9982E2-6FF6-420D-986F-12A4B9294987](https://ww3.sinaimg.cn/large/006tNbRwgw1fbsdz5j6b1j30rm0es75e.jpg)
說一下Cocoapods私有倉庫原理吧
![35E1A4EF-C00C-4330-9EAE-AD7A7A2818B3](https://ww3.sinaimg.cn/large/006tNbRwgw1fbse72it6rj30pd0hetbo.jpg)
其實和公有庫原理是一樣的模她。
公有庫和私有庫就只是放置配置文件的地方,根據配置文件找到對應庫的版本和源文件懂牧。
私有庫有很多侈净,但是公有庫只有一個。
目前模塊路由轉發(fā)的問題所在
我看了最火的就是蘑菇街的模塊路由轉發(fā)僧凤,但是問題依然存在畜侦。
我覺得模塊化存在的問題就是A到B模塊就要引入B的文件存在耦合。如果解決這個問題就解決模塊化問題了躯保。
蘑菇街的庫是利用DeepLink的路由查找旋膳,第一其他庫屬性比如block不支持,還有萬一改屬性途事,容易出BUG验懊。
我目前想到一個可以解決的方案,但是還有一些問題尸变。
每個模塊通過中間件注冊义图,每個中間件都有一個配置文件。配置文件存在架構模塊化下層召烂。這樣A跳轉到B碱工,就從下層找到B模塊配置文件配置。
A發(fā)送配置文件到中間件,B模塊收到配置文件創(chuàng)建對象返回A痛垛,A進行自定義的跳轉和其他操作草慧。
這樣不是通過字符串路由方式,可以和之前傳值一樣的匙头,又達到了模塊化解耦的方案漫谷。
下面的設計圖。
![C3843126-F6F6-420B-9147-EC6ECEDBAAF2](https://ww4.sinaimg.cn/large/006tNbRwgw1fbsek461hpj30n60b7abb.jpg)
現在每一個模塊都要注冊到中間件蹂析,都要有一個配置文件是一個問題舔示。
之后慢慢優(yōu)化吧。下面是我們模塊化組件中間件實現庫电抚。