《iOS App開發(fā)的那些事兒》系列文章從更宏觀的角度出發(fā)，不僅僅局限于具體某個(gè)功能、界面的實(shí)現(xiàn)，而是結(jié)合網(wǎng)易云信iOS端研發(fā)負(fù)責(zé)人多年的經(jīng)驗(yàn)，從如何優(yōu)化現(xiàn)有代碼的角度出發(fā)，深度分析如何創(chuàng)造出iOS App開發(fā)中比較合適的規(guī)范和框架。

?

推薦閱讀

iOS App開發(fā)的那些事兒1：如何建立合適的規(guī)范

?

一個(gè)合適的框架不是銀彈，在我看來框架要解決的問題從來不是：有了框架之后，工程就能無比正確地進(jìn)行下去。好的框架能夠做到的事僅僅只是：降低通用問題的復(fù)雜度和減少發(fā)生錯(cuò)誤的可能性。個(gè)人認(rèn)為一個(gè)良好iOS App框架應(yīng)該是有如下特點(diǎn)：

定義清晰的層次結(jié)構(gòu)

l?橫向上，各模塊互相獨(dú)立，僅通過有限的幾個(gè)接口進(jìn)行通訊。最理想的狀態(tài)是除核心模塊外，其他模塊都是可拔插。縱向上，各層次間依賴關(guān)系清晰，基本不出現(xiàn)逆向依賴的情況。

l?橫向模塊一般依賴于業(yè)務(wù)需求，常被定義成各種Service或Manager。一種好的做法是有個(gè)統(tǒng)一的Service管理器負(fù)責(zé)相應(yīng)Serivce的加載，卸載，監(jiān)聽和分發(fā)App級(jí)別的通知給相應(yīng)Service，如前后臺(tái)切換，收到內(nèi)存警告等。這樣做一方面容易實(shí)現(xiàn)上面說的模塊的可插拔化，另一方面也保證了公用特性處理的一致性。在這方面微信就做得不錯(cuò)，基本所有的模塊都是從MMService繼承而來，由MMServiceCenter進(jìn)行管理。當(dāng)然從dump出來的頭文件也可以發(fā)現(xiàn)一些管理上的紊亂，比如一些ViewController都是繼承自MMService。

l?縱向的層次劃分基本各個(gè)App不會(huì)有太大區(qū)別，一般可以分為三個(gè)層次：

展現(xiàn)層(Presentation layer)，負(fù)責(zé)管理UI和UIViewController。

邏輯層(Business/Service Layer)，負(fù)責(zé)邏輯數(shù)據(jù)的定義和轉(zhuǎn)發(fā)，起到承上啟下的作用。

數(shù)據(jù)訪問層(Data Access Layer)，負(fù)責(zé)具體API構(gòu)造，網(wǎng)絡(luò)請(qǐng)求，數(shù)據(jù)持久化等。

各層根據(jù)業(yè)務(wù)邏輯的復(fù)雜性內(nèi)部又會(huì)使用單層或者多層結(jié)構(gòu)。以數(shù)據(jù)訪問層為例，一般又可以細(xì)分為網(wǎng)絡(luò)層，持久化層。而一般而言，展現(xiàn)層(UIView和UIViewController)都是直接使用邏輯層提供的Model進(jìn)行展現(xiàn)，但是某些場(chǎng)景下往往需要不同的Model有相同的界面展示(如我們的App易信中，會(huì)話界面，收藏界面，問一問功能都需要進(jìn)行圖片的展現(xiàn)，但這三個(gè)模塊下的Model定義并不一致)，這就需要增加額外的ViewModel層用于粘合展現(xiàn)層和邏輯Model。

?

遵守SOLID原則和慎用各種設(shè)計(jì)模式

這是個(gè)老生常談的話題了，并不是iOS開發(fā)獨(dú)有，展開講可以講上幾天幾夜，不贅述。

?

定義自己的UI基類：UIView，UIViewController，UITableviewCell

這一點(diǎn)的好處不言而喻，所有的子View，Controller，Cell都能夠很方便的繼承基類的共有的行為，樣式。但也會(huì)引進(jìn)很大的管理風(fēng)險(xiǎn)：組內(nèi)成員總會(huì)經(jīng)不起誘惑往基類塞各種并不普適的特性，引起基類權(quán)責(zé)的無限膨脹。大基類不僅增加組內(nèi)成員對(duì)代碼的理解難度，同時(shí)也增加出現(xiàn)問題時(shí)的排查難度。從這方面講，微信的UIViewController基類設(shè)計(jì)就極端失敗：MMUIViewController這個(gè)類光頭文件就有上百行。

?

提供方便好用的工具類

一些好用的工具類往往會(huì)成為框架重要的有機(jī)組成部分，方便快捷地解決局部問題，同時(shí)又不引入過多的復(fù)雜度。NSTimer的retain cycle是個(gè)很容易掉去的坑，那么提供一個(gè)基于Block或者weak delegate的NSTimer的封裝就是不錯(cuò)的選擇。使用KVO容易發(fā)生add和remove的不配對(duì)調(diào)用，那么就引入THObserversAndBinders或者FB的KVOContorller。某些核心模塊需要被多個(gè)模塊依賴時(shí)，引入類似XMPP的GCDMulticastDelegate就能夠方便地進(jìn)行解耦。

?

好的范例

在前幾年使用C++的那段暗無天日的日子里，我常想的一個(gè)問題是：如何在API層面去限制和規(guī)避一些錯(cuò)誤。比如往線程池里面扔的task必須是堆上分配的對(duì)象，那么如何去強(qiáng)制傳入的指針指向的是堆地址而不是棧地址呢？這種傻問題大部分情況下是無解的，有時(shí)候有解卻是個(gè)異常別扭的解。而現(xiàn)在我更相信破窗理論所提供的可能性：做好示范，接下來的一切都會(huì)水到渠成。

?

大家可以戳 iOS App開發(fā)的那些事兒1：如何建立合適的規(guī)范?回顧該系列第一篇文章，也歡迎大家積極發(fā)表自己的看法，與我們共同討論。

?

轉(zhuǎn)載于:https://www.cnblogs.com/wangyiyunxin/p/9241627.html

總結(jié)

以上是生活随笔為你收集整理的iOS App开发的那些事儿2：如何搭建合适的框架的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。