iOS代碼實踐總結

標籤：

轉載地址：http://mobile.51cto.com/hot-492236.htm

最近一個月除了專門抽時間和精力重構之外，還有就是遇到需要添加功能的模組的時候，由於項目中的代碼曆史因素比較多，第一件乾的事情往往是重構整理代碼，發現很多之前的代碼寫的時候沒有注意的事情特別多，比如全域變數亂用；方法沒有層次感，胡亂添加；對業務不瞭解的情況下，通過打補丁的方式實現功能等等。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　AD：

 

前幾個月完成對MVVM/RAC的學習之後，最近一直在默默地對項目代碼進行重構，寫碼比較多，過了一段時間回頭髮現自己的代碼風格還有代碼品質都有大大的改善。過去幾年在一家小公司負責iOS用戶端後來負責用戶端的研發工作，被雜亂的事情分神比較多，所以到去年的時候，寫碼已經不太多了。在新公司待了大半年，目前只是寫碼的小角色，所以精力基本上在寫業務代碼和業餘學習亂七八糟的技術上面。

最近一個月除了專門抽時間和精力重構之外，還有就是遇到需要添加功能的模組的時候，由於項目中的代碼曆史因素比較多，第一件乾的事情往往是重構整理代碼，發現很多之前的代碼寫的時候沒有注意的事情特別多，比如全域變數亂用；方法沒有層次感，胡亂添加；對業務不瞭解的情況下，通過打補丁的方式實現功能等等。所以我決定寫一篇文章，把自己的覺得實踐中需要注意的一些事項，具體總結一下分享給大家。

減少對象屬性

這個是最容易改善代碼品質的一個點，很多代碼一眼看上去就會讓人感覺很淩亂，一上來就是幾十個不同的物件變數定義在裡面，這讓不同邏輯之間莫名其妙沒法分開。一個是定義的方式不對，很多莫名其妙的內部變數暴露在標頭檔中，讓外部調用者根本不知道哪些才是public可以操作的方法。另外實際上，經過我自己這段時間的重構經驗來看，大多數是可以通過局部變數或者__block變數來代替的。

1. 標頭檔中儘可能少暴露變數或方法，而要使用extension或者category放在.m檔案，或者專門的private標頭檔中

標頭檔中暴露的資訊越少越好，一切不必要的資訊都不要暴露出來

 

m檔案的extension中，定義conforms protocol和對象屬性，對於對象屬性的定義，使用getter/setter 來定義。

 

2. 使用局部變數或者__block變數代替

局部變數不需要多說，需要寫碼的時候思路清晰一些，寫完之後在commit之前即使review一定要check一遍，對自己的代碼品質負責，code review往往檢查不出來冗餘或者廢棄的代碼。不添加一個多餘的對象屬性，不留注釋掉的代碼，不留沒有用途的代碼，這些都是基本功，但是很多開發人員就是做不到，或者說對寫碼沒有愛，所以很多廢棄的代碼，我重構代碼的時候，雖然對業務不熟悉，但是大多數模組都能刪除掉十分之一的代碼和大量的對象屬性，這個是單純的不夠用心。

關於使用__block變數，這個是Android開發中我感覺到最不滿意的地方，這個特性簡直太他媽爽了。

比如這裡，使用block的時候回傳一些變數

 

再比如這裡，我需要記錄一個pan手勢開始時，headerView的頂部座標，結合RAC之後，本來需要全域變數來記錄的值，使用__block變數即可搞定

3. 可以儘可能避免循環參考

有個地方很多開發人員會疏漏，在block中使用_XXX物件變數的時候，block會retain self指標，一不小心就會造成循環參考的出現。所以使用局部變數的話，就能扼殺這種問題在搖籃之中。

減少和模組化對象訊息

1. 減少對象訊息

減少UI的action類訊息，感謝block和RAC，或者blockskit，讓我們得以通過hook來把之前target-action模型換為block來實現，UI和action的代碼終於可以一起了，使整個邏輯變得緊湊，在查看代碼的時候終於不用跳來跳去了。還有就是日常開發中，把自己寫的各種protocol或者傳遞target/selector的地方，盡量使用block來代替，相信我，這個會使代碼好讀很多。

2. 模組化

使用”#pragma mark - XXX”進行分割不同邏輯之間的界限，讓整個檔案閱讀起來更加結構化。還有一個我現在最常用的就是是設定Xcode的快速鍵，把Ctrl + 6 顯示文檔結構的快速鍵改為：Command + J ，搜尋來快速跳轉到對應的訊息和模組，要盡量避免文檔結構顯示超過兩螢幕，超過兩畫面上的指示有點多了，你肯定考慮一下重構了。

我個人習慣一般劃分的模組有: life cycle，ui helper，datasource/delegate，依據功能進行劃分的模組等等，如下是我最近重構的一個ViewController的文檔結構

 

MVVM && RAC

我自己使用MVVM思路的感覺是太爽了，說一下，MVVM不一定需要使用RAC，但是data binding少不了，在iOS中也就是KVO了，建議大家都去嘗試一下，我自己感覺這個基本上MVVM的最核心的東西了，連Android SDK也不得不引入這個特性。把資料部分的邏輯抽取放在ViewModel中，然後讓UI和ViewModel中的資料binding，這個不會減少代碼量，但是絕對可以大大簡化開發時邏輯的複度，再也不用重寫-setXXX:方法來update一大堆不相關的UI了，關於UI開發，後面會專門再講講新的。這裡說一下我自己的理解，有人說RAC影響效能，回調棧太深，這個的確是會有的，但是個人感覺RACObserver是基於KVO實現的，調用的時候是同步調用的，所以對效能的影響有限，也不會出現調用順序的問題，所以我敢在列表開發中使用data binding，實踐之後還好，對使用者體驗沒什麼影響。

關於RAC，即使你不使用RAC，有一些東西也是絕對值得你在項目中引入的，比如@weakify(self)/@strongify(self)，通過先行編譯查看的話，這個的做法是設定一個局部變數self來覆蓋全域的self，進而避免循環參考的，需要注意的是block層次較深的時候使用的問題，http://stackoverflow.com/questions/21716982/explanation-of-how-weakify-and-strongify-work-in-reactivecocoa-libextobjc。

RAC/MVVM，我剛開始學習的時候，寫了兩篇文章，算是我自己的總結，理解上面還有不足，跟大家參考一下：http://blog.csdn.net/colorapp/article/details/46524893，http://blog.csdn.net/colorapp/article/details/46537729。大家可以通過我部落格中文章的參考連結學習。

UI開發

1. 重寫setter方法和Code Block Evaluation C Extension文法

重寫UI的getter方法，把UI的初始化放在getter中，減輕 -viewDidLoad的負荷，同時可以使整個頁面變得清晰；同時，可以通過使用使用GCC Code Block Evaluation C Extension ({…})文法，結構化局部變數初始化和處理的邏輯。關於這個文法，參考我之前的部落格：http://blog.csdn.net/colorapp/article/details/47006771。關於setter代碼風格，可以參考別人寫的一篇文章，http://casatwy.com/iosying-yong-jia-gou-tan-viewceng-de-zu-zhi-he-diao-yong-fang-an.html，這個問題之前在我們Q群裡探討之後我也非常認同這種方式寫UI。

舉一個例子，-viewDidLoad中，做為邏輯的入口，代碼會變少但是變清晰，代碼如下：

 

然後重寫bgView的getter方法，包括View和frame這些都可以使用({...})文法使代碼結構化層次化：

 

2. 複雜UI的開發

有時候我們開發業務的時候，產品需求往往非常複雜，酷炫的UI加上各種考慮全面的邏輯，這個的結果就是，碼農的超長代碼，而我們平時工作面對的也大多數都是這類問題。關於這個問題，我的解決方式，組合式UI / custom view / child view controller來解決。

(1) 組合式view

這個概念是從Android中借鑒而來。重構時查看項目中的代碼，發現大家用的做UI的時候，對這個概念不是很強烈，感覺是對UIView的view hierarchy理解不夠。比如一個複雜的UI，直接把所有的subviews直接堆積到super view上面，這樣的結果就是，調整subview的frame非常困難。我個人的做法是，首先對複雜UI進行分塊，從左至右或者從上倒下，把各個UI元素放到不同的container view上面，然後組合這些container view放到super view上面，這樣的好處非常明顯，首先UI乾淨清晰，閱讀起來不那麼費勁。其次就是你計算座標或者設定約束會變得很簡單，因為你調整一個UI元素的時候，只需要考慮它與包含它的container view的座標關係即可，而不是通過一大堆無趣計算跟最外層super view關聯起來。還有就是可以充分利用Auto Layout和autoresiziingmask這些UI利器，使用的時候會非常方便。再有就是結合RACObserver這個利器之後，你能很容易做到根據data來update ui。

舉個例子，是我們項目中前一段時間我重構的一個頁面，這個首頁列表，效能要求比較高。並沒有使用Auto Layout來實現，但是不使用Auto Layout並不是不把它寫的很乾淨的理由。

 

這是我對一個UITableViewCell的分層，最外層由 icon view / right view / bottom view這些container view組成，而right view這個container view則又是由right top view / right middle view /right bottom view 這些 sub container view組合而成，而具體的UI元素則是放在這些sub container view之中。這樣UI代碼就會以一種層次化樣式展示出來，init/layoutsubviews只需要維護self與container view的關係即可，而具體展示資料的UI元素也只跟sub container view存在座標關係。我們看一下right view這個container view的代碼實現：

 

關於效能的話，感謝iOS，我們不存在Android中頁面層次較深效能卡頓的問題，放心把UI層次化就行

(2) custom view

對於非常複雜並且相對獨立或者可以重用的UI，及時使用custom view子類化。對於單純的展示UI，我們只需要簡單通過組合式view就可以實現了。但是有時候，我們會遇到一些包含無論是動畫，邏輯都比較複雜的情況，這個時候使用組合式View去實現，一方面容易把邏輯弄混亂，會把檔案的文檔結構變得很複雜，簡單來說就是對象的訊息數量很多。這個時候，我們可以通過custom view來實現，實際上這個也是組合式view，但是我們是把這些組合式view變成了一個類而已，只暴露少量的介面給外部調用。如果這個custom view會出現在多個業務模組中，那麼有必要使用一個單獨的檔案來容納這個類，如果僅僅是這個模組一個使用的話，可以直接寫在這個業務模組的檔案中即可，沒有必要對所有的類都單獨一個檔案，我們就當作這個“內部類”來弄了。

什麼時候使用custom view而不是組合view，我想了很久，你覺得組合式view的代碼很亂的時候，別客氣，封裝為一個custom view就行了。我這邊最近遇到的幾個問題是使用UICollectionView來做部分UI的時候，同時還有其他很多UI元素，我會寫一個custom view。比如下面這個檔案，把一個左右滑動查看圖片的UI使用PhotoView這個custom view進行封裝，內部使用UICollectionView實現一部分相對獨立的模組，這個時候這個控制項實際上是可以封裝為一個相對獨立的模組的，用子類我感覺比較合適一些。

 

(3) container view controller

這個用法很多開發人員不熟悉或者說是用的不多，但實際業務中，這個技術非常有用途，可以大大提高開發效率。對這部分知識不熟悉的，可以參考我之前的部落格：http://blog.csdn.net/colorapp/article/details/45765601。對於有相對獨立商務邏輯以及生命週期要求的業務，使用child view controller進行封裝，如果parent view contrller與child view controller之間非常密切，則使用View Model以及block來對parent view controller和 child view controller 進行銜接。

使用child view controller來開發UI而不是custom view的優勢很多，我個人認為最大優勢在於可以方便利用View Controller的生命週期以及View Controller Hierarchy，比如在-viewWillAppear/-viewDidDisappear中做一些操作，再比如直接擷取UINavigationController指標等等。之前的做法一般是在View Controller的對應生命週期內調用custom view的方法，傳遞self.navigationController指標給custom view等。所以可以不僅僅把UI相關的程式碼封裝裝進入這個child view controller，也可以把網路請求，資料處理這些這些邏輯放到child view controller中，這樣下來就能避免那種動不動超過1k行的view controller的出現了。

利用MVVM之後，還有一個比較有好處的用法，比如公用一些資料的時候，之前我們是把對象傳遞來傳遞去，這樣的問題是很容易出現混亂，這個時候我們是傳遞ViewModel就可以避免這個問題，ViewModel既負責網路請求又負責資料處理，而parent view controller與child view controller所需要做的事情就是跟ViewModel進行binding而已。

Auto Layout/Masonry

在一些效能要求不是那麼強烈的非列表頁，我們可以大量使用Auto Layout來開發UI，充分利用UI根據資料的自適應能力，連在container view中調整UI的步驟都不需要了。之前有一段時間我根本不想開發iOS，原因很簡單，Android的布局式以及可見式的開發方式非常方便，再加上AS這樣的神器，我自己感覺效率不比iOS低。自從項目最低支援變到iOS6之後，我才開始使用Auto Layout，雖然比較費勁，但是感覺這個對UI開發來說是個解脫。

至於Masonry這個架構，之前我對這個抱有一定的懷疑不敢使用，所以我把源碼讀了一遍，發現這個封裝很薄很巧妙，很多設計思路也值得借鑒，對源碼有興趣的可以參考我的部落格：http://blog.csdn.net/colorapp/article/details/45030163。我讀完源碼之後，嘗試著完全使用Mansory來開發一個展示資訊的頁面，感覺太爽了！

這個的優勢就是你設定UI的資料之後，不需要再考慮去update ui了，這樣世界瞬時就清淨了。。。。，下面是我一個簡單的樣本，結合({….})文法和RAC，可以使用最簡單的label這樣的命名來對UI設定資料，這個對我們開發UI來說，絕對是一種解脫。

 

 

說一下Auto Layout的問題：

1. 首先一個問題，是如果一個view不是leaf view的話，那麼這個UIView如果hidden的話，它的約束仍然是work的，所以會留下空白，不會像Android中那樣設定GONE那麼方便。國內sunny大神開源一個不錯的解決方式，https://github.com/forkingdog/UIView-FDCollapsibleConstraints。這裡說一下我之前的解決方式，比較土逼，直接子類化：

 

2. 動畫的問題

使用Auto Layout有一個比較大的問題在於動畫，通過更改約束來進行動畫，一直是我比較頭疼的問題，所以一般遇到這類問題的時候，我都會盡量避免使用Auto Layout來解決，而是使用frame的方式來做。可以參考objc.io上面的一篇文章：http://www.objc.io/issues/3-views/advanced-auto-layout-toolbox/。

3. 多行UILabel的問題

iOS7以及以下的作業系統上，UILabel顯示多行文本是又不足的，你需要設定UILabel的preferredMaxLayoutWidth為一個固定值才能顯示多行文本。在iOS8以後就不再需要設定這個了。

 

4. UIScrollView的問題以及約束歧義和其他問題

參考我的文章：http://blog.csdn.net/colorapp/article/details/47007143

這個地方，我的建議是根據具體問題來選擇實現方式 ：spring & structs也好，Auto Layout也好，那種解決問題較為簡潔快速就用那種，不一定非要固定於一種行為，尤其是開發的頁面有大量動畫的時候。

注釋

不要寫一堆中文注釋，代碼不要出現大量的中文，OC已經夠囉嗦，不要這麼囉嗦地寫碼。除了提供服務的public功能或者方法，業務代碼僅在某些關鍵點上注釋一下就行，不需要一大堆中文，這樣太low，代碼自注釋即可，需要注釋的，可以通過喵神的Xcode外掛程式來實現，https://github.com/onevcat/VVDocumenter-Xcode。

而對於出現拼音命名代碼的人，能做主的話，別猶豫，開掉吧。這裡吐一下槽，之前的公司就有這樣的哥們，不是我招進來的，老闆硬塞給我的。

善用OC的新文法

OC有很多新的文法糖，可以大大提高我們的效率，參考Apple Guide：https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html。

比如列印數位時候，我們可以用@(xxx)來列印，定義枚舉的時候使用typedef NS_ENUM，使用instancetype而不用id等等。而最近又到了每年技能槽重新整理的日子了，iOS 9發布了，OC又有了一些新文法，去學習一下多用用吧。

JSON資料的處理

新手往往會被這個稍微困惑一下，比如伺服器返回的資料格式不正確啦，包含null啦，都很容易引起項目崩潰。這個問題可以使用Mantle來解決，很多兄弟都在使用這個，我自己倒是一直沒有用過。之前寫了一個小架構放在了github上面，https://github.com/lihei12345/CYJSONValidator，這個在我們項目內部也在使用，效果不錯，用來解析資料的時候，對資料的類型以及是否為null等進行校正，確保解析出來資料類型的正確性。對於可能不存在key的時候，還可以設定一些預設值。

舉個例子：

 

block

使用block代替delegate，這個沒啥可多說的，把代碼變得非常緊湊，減少檔案的訊息數量，最主要的是關係沒那麼緊密了。對於有大量的delegate方法才考慮使用protocol實現，這個時候block太多也影響閱讀。

同時，對於傳遞target/selector，也盡量使用block吧，這種閱讀尋找起來太不方便了。

提交代碼

及時stage，這個非常重要，開發過程中經常需要經常比對上一步的代碼，這樣才能最大程度上確保自己的改動是正確的。如果有一些小問題，也可以即使找到曆史版本。

及時commit，每完成一個相對完整的需求，就commit，小提交是個好習慣。

PR code review要做好，要花大量的時間做，有條件的話，最好每個版本開一次總結會。

RAC封裝網路請求

返回的signal要避免多次出現side effect，但不使用replay/replayLazily，因為dispose不會被調用。

使用RACCommand封裝請求，查看這幾篇文章：http://codeblog.shape.dk/blog/2013/12/05/reactivecocoa-essentials-understanding-and-using-raccommand/，https://github.com/ReactiveCocoa/ReactiveCocoa/issues/963，https://github.com/ReactiveCocoa/ReactiveCocoa/issues/1326。

結合RACCommand和takeUntil:來封裝一個可以cancel的請求

iOS代碼實踐總結