其實(shí)市面上大部分應(yīng)用不外乎就是顛過來倒過去地做以下這些事情：

簡(jiǎn)單來說就是調(diào)API，展示頁面，然后跳轉(zhuǎn)到別的地方再調(diào)API，再展示頁面。

那這特么有毛好架構(gòu)的？

非也，非也。 ---- 包不同 《天龍八部》

App確實(shí)就是主要做這些事情，但是支撐這些事情的基礎(chǔ)，就是做架構(gòu)要考慮的事情。

調(diào)用網(wǎng)絡(luò)API

頁面展示

數(shù)據(jù)的本地持久化

動(dòng)態(tài)部署方案

上面這四大點(diǎn)，稍微細(xì)說一下就是：

如何讓業(yè)務(wù)開發(fā)工程師方便安全地調(diào)用網(wǎng)絡(luò)API？然后盡可能保證用戶在各種網(wǎng)絡(luò)環(huán)境下都能有良好的體驗(yàn)？

頁面如何組織，才能盡可能降低業(yè)務(wù)方代碼的耦合度？盡可能降低業(yè)務(wù)方開發(fā)界面的復(fù)雜度，提高他們的效率？

當(dāng)數(shù)據(jù)有在本地存取的需求的時(shí)候，如何能夠保證數(shù)據(jù)在本地的合理安排？如何盡可能地減小性能消耗？

iOS應(yīng)用有審核周期，如何能夠通過不發(fā)版本的方式展示新的內(nèi)容給用戶？如何修復(fù)緊急bug？

上面幾點(diǎn)是針對(duì)App說的，下面還有一些是針對(duì)團(tuán)隊(duì)說的：

收集用戶數(shù)據(jù)，給產(chǎn)品和運(yùn)營提供參考

合理地組織各業(yè)務(wù)方開發(fā)的業(yè)務(wù)模塊，以及相關(guān)基礎(chǔ)模塊

每日app的自動(dòng)打包，提供給QA工程師的測(cè)試工具

一時(shí)半會(huì)兒我還是只能想到上面這三點(diǎn)，事實(shí)上應(yīng)該還會(huì)有很多，想不起來了。

所以當(dāng)我們討論客戶端應(yīng)用架構(gòu)的時(shí)候，我們討論的差不多就是這些問題。

這系列文章要回答那些問題？

這系列文章主要是回答以下這些問題：

網(wǎng)絡(luò)層設(shè)計(jì)方案？設(shè)計(jì)網(wǎng)絡(luò)層時(shí)要考慮哪些問題？對(duì)網(wǎng)絡(luò)層做優(yōu)化的時(shí)候，可以從哪些地方入手？

頁面的展示、調(diào)用和組織都有哪些設(shè)計(jì)方案？我們做這些方案的時(shí)候都要考慮哪些問題？

本地持久化層的設(shè)計(jì)方案都有哪些？?jī)?yōu)劣勢(shì)都是什么？不同方案間要注意的問題分別都是什么？

要實(shí)現(xiàn)動(dòng)態(tài)部署，都有哪些方案？不同方案之間的優(yōu)劣點(diǎn)，他們的側(cè)重點(diǎn)？

本文要回答那些問題？

上面細(xì)分出來的四個(gè)問題，我會(huì)分別在四篇文章里面寫。那么這篇文章就是來講一些通識(shí)啥的，也是開個(gè)坑給大家討論通識(shí)問題的。

架構(gòu)設(shè)計(jì)的方法

所有事情最難的時(shí)候都是開始做的時(shí)候，當(dāng)你開始著手設(shè)計(jì)并實(shí)現(xiàn)某一層的架構(gòu)乃至整個(gè)app的架構(gòu)的時(shí)候，很有可能會(huì)出現(xiàn)暫時(shí)的無從下手的情況。以下方法論是我這些年總結(jié)出來的經(jīng)驗(yàn)，每個(gè)架構(gòu)師也一定都有一套自己的方法論，但一樣的是，不管你采用什么方法，全局觀、高度的代碼審美能力、靈活使用各種設(shè)計(jì)模式一定都是貫穿其中的。歡迎各位在評(píng)論區(qū)討論。

第一步：搞清楚要解決哪些問題，并找到解決這些問題的充要條件。

你必須得清楚你要做什么，業(yè)務(wù)方希望要什么。而不是為了架構(gòu)而架構(gòu)，也不是為了體驗(yàn)新技術(shù)而改架構(gòu)方案。以前是MVC，最近流行MVVM，如果過去的MVC是個(gè)好架構(gòu)，沒什么特別大的缺陷，就不要推倒然后搞成MVVM。

關(guān)于充要條件我也要說明一下，有的時(shí)候系統(tǒng)提供的函數(shù)是需要額外參數(shù)的，比如read函數(shù)。還有翻頁的時(shí)候，當(dāng)前頁碼也是充要條件。但對(duì)于業(yè)務(wù)方來說，這些充要條件還能夠再縮減。

比如read，需要給出file descriptor，需要給出buf，需要給出size。但是對(duì)于業(yè)務(wù)方來說，充要條件就只要file descriptor就夠了。再比如翻頁，其實(shí)業(yè)務(wù)方并不需要記錄當(dāng)前頁號(hào)，你給他暴露一個(gè)loadNextPage這樣的方法就夠了。

搞清楚對(duì)于業(yè)務(wù)方而言的真正充要條件很重要！這決定了你的架構(gòu)是否足夠易用。另外，傳的參數(shù)越少，耦合度相對(duì)而言就越小，你替換模塊或者升級(jí)模塊所花的的代價(jià)就越小。

第二步：?jiǎn)栴}分類，分模塊

這個(gè)不用多說了吧。

第三步：搞清楚各問題之間的依賴關(guān)系，建立好模塊交流規(guī)范并設(shè)計(jì)模塊。

關(guān)鍵在于建立一套統(tǒng)一的交流規(guī)范。這一步很能夠體現(xiàn)架構(gòu)師在軟件方面的價(jià)值觀，雖然存在一定程度上的好壞優(yōu)劣（比如胖Model和瘦Model），但既然都是架構(gòu)師了，基本上是不會(huì)設(shè)計(jì)出明顯很爛的方案的，除非這架構(gòu)師還不夠格。所以這里是架構(gòu)師價(jià)值觀輸出的一個(gè)窗口，從這一點(diǎn)我們是能夠看出架構(gòu)師的素質(zhì)的。

另外要注意的是，一定是建立一套統(tǒng)一的交流規(guī)范，不是兩套，不是多套。你要堅(jiān)持你的價(jià)值觀，不要搖擺不定。要是搞出各種五花八門的規(guī)范出來，一方面有不切實(shí)際的炫技嫌疑，另一方面也會(huì)帶來后續(xù)維護(hù)的災(zāi)難。

第四步：推演預(yù)測(cè)一下未來可能的走向，必要時(shí)添加新的模塊，記錄更多的基礎(chǔ)數(shù)據(jù)以備未來之需。

很多稱職的架構(gòu)師都會(huì)在這時(shí)候考慮架構(gòu)未來的走向，以及考慮做完這一輪架構(gòu)之后，接下來要做的事情。一個(gè)好的架構(gòu)雖然是功在當(dāng)代利在千秋的工程，但絕對(duì)不是一個(gè)一勞永逸的工程。軟件是有生命的，你做出來的架構(gòu)決定了這個(gè)軟件它這一生是坎坷還是幸福。

第五步：先解決依賴關(guān)系中最基礎(chǔ)的問題，實(shí)現(xiàn)基礎(chǔ)模塊，然后再用基礎(chǔ)模塊堆疊出整個(gè)架構(gòu)。

這一步也是驗(yàn)證你之前的設(shè)計(jì)是否合理的一步，隨著這一步的推進(jìn)，你很有可能會(huì)遇到需要對(duì)架構(gòu)進(jìn)行調(diào)整的情況。這個(gè)階段一定要吹毛求疵高度負(fù)責(zé)地去開發(fā)，不要得過且過，發(fā)現(xiàn)架構(gòu)有問題就及時(shí)調(diào)整。否則以后調(diào)整的成本就非常之大了。

第六步：打點(diǎn)，跑單元測(cè)試，跑性能測(cè)試，根據(jù)數(shù)據(jù)去優(yōu)化對(duì)應(yīng)的地方。

你得用這些數(shù)據(jù)去向你的boss邀功，你也得用這些數(shù)據(jù)去不斷調(diào)整你的架構(gòu)。

總而言之就是要遵循這些原則：自頂向下設(shè)計(jì)（1，2，3，4步），自底向下實(shí)現(xiàn)（5），先測(cè)量，后優(yōu)化（6）。

什么樣的架構(gòu)師是好架構(gòu)師？

每天都在學(xué)習(xí)，新技術(shù)新思想上手速度快，理解速度快。

做不到這點(diǎn)，你就是碼農(nóng)。

業(yè)務(wù)出身，或者至少非常熟悉公司所處行業(yè)或者本公司的業(yè)務(wù)。

做不到這點(diǎn)，你就是運(yùn)維。

熟悉軟件工程的各種規(guī)范，踩過無數(shù)坑。不會(huì)為了完成需求不擇手段，不推崇quick & dirty。

做不到這點(diǎn)，你比較適合去競(jìng)爭(zhēng)對(duì)手那兒當(dāng)工程師。

及時(shí)承認(rèn)錯(cuò)誤，不要覺得承認(rèn)錯(cuò)誤會(huì)有損你架構(gòu)師的身份。

做不到這點(diǎn)，公關(guān)行業(yè)比較適合你。

不為了炫技而炫技

做不到這點(diǎn)，你就是高中編程愛好者。

精益求精

做不到這點(diǎn)，（我想了好久，但我還是不知道你適合去干什么。）

什么樣的架構(gòu)叫好架構(gòu)？

代碼整齊，分類明確，沒有common，沒有core

不用文檔，或很少文檔，就能讓業(yè)務(wù)方上手

思路和方法要統(tǒng)一，盡量不要多元

沒有橫向依賴，萬不得已不出現(xiàn)跨層訪問

對(duì)業(yè)務(wù)方該限制的地方有限制，該靈活的地方要給業(yè)務(wù)方創(chuàng)造靈活實(shí)現(xiàn)的條件

易測(cè)試，易拓展

保持一定量的超前性

接口少，接口參數(shù)少

高性能

以上是我判斷一個(gè)架構(gòu)是不是好架構(gòu)的標(biāo)準(zhǔn)，這是根據(jù)重要性來排列的?？蛻舳思軜?gòu)跟服務(wù)端架構(gòu)要考慮的問題和側(cè)重點(diǎn)是有一些區(qū)別的。下面我會(huì)針對(duì)每一點(diǎn)詳細(xì)講解一下：

代碼整齊，分類明確，沒有common，沒有core

代碼整齊是每一個(gè)工程師的基本素質(zhì)，先不說你搞定這個(gè)問題的方案有多好，解決速度有多快，如果代碼不整齊，一切都白搭。因?yàn)槟愕拇a是要給別人看的，你自己也要看。如果哪一天架構(gòu)有修改，正好改到這個(gè)地方，你很容易自己都看不懂。另外，破窗理論提醒我們，如果代碼不整齊分類不明確，整個(gè)架構(gòu)會(huì)隨著一次一次的拓展而越來越混亂。

分類明確的字面意思大家一定都了解，但還有一個(gè)另外的意思，那就是：不要讓一個(gè)類或者一個(gè)模塊做兩種不同的事情。如果有類或某模塊做了兩種不同的事情，一方面不適合未來拓展，另一方面也會(huì)造成分類困難。

不要搞Common，Core這些東西。每家公司的架構(gòu)代碼庫里面，最惡心的一定是這兩個(gè)名字命名的文件夾，我這么說一定不會(huì)錯(cuò)。不要開Common，Core這樣的文件夾，開了之后后來者一定會(huì)把這個(gè)地方搞得一團(tuán)糟，最終變成Common也不Common，Core也不Core。要記住，架構(gòu)是不斷成長的，是會(huì)不斷變化的。不是每次成長每次變化，都是由你去實(shí)現(xiàn)的。如果真有什么東西特別小，那就索性為了他單獨(dú)開辟一個(gè)模塊就好了，小就小點(diǎn)，關(guān)鍵是要有序。

不用文檔，或很少文檔，就能讓業(yè)務(wù)方上手。

誰特么會(huì)去看文檔啊，業(yè)務(wù)方他們已經(jīng)被產(chǎn)品經(jīng)理逼得很忙了。所以你要盡可能讓你的API名字可讀性強(qiáng)，對(duì)于iOS來說，objc這門語言的特性把這個(gè)做到了極致，函數(shù)名長就長一點(diǎn)，不要緊。

思路和方法要統(tǒng)一，盡量不要多元。

解決一個(gè)問題會(huì)有很多種方案，但是一旦確定了一種方案，就不要在另一個(gè)地方采用別的方案了。也就是做架構(gòu)的時(shí)候，你得時(shí)刻記住當(dāng)初你決定要處理這樣類型的問題的方案是什么，以及你的初衷是什么，不要搖擺不定。

另外，你當(dāng)初設(shè)立這個(gè)模塊一定是有想法有原因的，要記錄下你的解決思路，不要到時(shí)候換個(gè)地方你又靈光一現(xiàn)啥的，引入了其他方案，從而導(dǎo)致異構(gòu)。

要是一個(gè)框架里面解決同一種類似的問題有各種五花八門的方法或者類，我覺得做這個(gè)架構(gòu)的架構(gòu)師一定是自己都沒想清楚就開始搞了。

沒有橫向依賴，萬不得已不出現(xiàn)跨層訪問。

沒有橫向依賴是很重要的，這決定了你將來要對(duì)這個(gè)架構(gòu)做修補(bǔ)所需要的成本有多大。要做到?jīng)]有橫向依賴，這是很考驗(yàn)架構(gòu)師的模塊分類能力和是否熟悉業(yè)務(wù)的。

跨層訪問是指數(shù)據(jù)流向了跟自己沒有對(duì)接關(guān)系的模塊。有的時(shí)候跨層訪問是不可避免的，比如網(wǎng)絡(luò)底層里面信號(hào)從2G變成了3G變成了4G，這是有可能需要跨層通知到View的。但這種情況不多，一旦出現(xiàn)就要想盡一切辦法在本層搞定或者交給上層或者下層搞定，盡量不要出現(xiàn)跨層的情況?？鐚釉L問同樣也會(huì)增加耦合度，當(dāng)某一層需要整體替換的時(shí)候，牽涉面就會(huì)很大。

對(duì)業(yè)務(wù)方該限制的地方有限制，該靈活的地方要給業(yè)務(wù)方創(chuàng)造靈活實(shí)現(xiàn)的條件。

把這點(diǎn)做好，很依賴于架構(gòu)師的經(jīng)驗(yàn)。架構(gòu)師必須要有能力區(qū)分哪些情況需要限制靈活性，哪些情況需要?jiǎng)?chuàng)造靈活性。比如對(duì)于Core Data技術(shù)棧來說，ManagedObject理論上是可以出現(xiàn)在任何地方的，那就意味著任何地方都可以修改ManagedObject，這就導(dǎo)致ManagedObjectContext在同步修改的時(shí)候把各種不同來源的修改同步進(jìn)去。這時(shí)候就需要限制靈活性，只對(duì)外公開一個(gè)修改接口，不暴露任何ManagedObject在外面。

如果是設(shè)計(jì)一個(gè)ABTest相關(guān)的API的時(shí)候，我們又希望增加它的靈活性。使得業(yè)務(wù)方不光可以通過Target-Action的模式實(shí)現(xiàn)ABtest，也要可以通過Block的方式實(shí)現(xiàn)ABTest，要盡可能滿足靈活性，減少業(yè)務(wù)方的使用成本。

易測(cè)試易拓展

老生常談，要實(shí)現(xiàn)易測(cè)試易拓展，那就要提高模塊化程度，盡可能減少依賴關(guān)系，便于mock。另外，如果是高度模塊化的架構(gòu)，拓展起來將會(huì)是一件非常容易的事情。

保持一定量的超前性

這一點(diǎn)能看出架構(gòu)師是否關(guān)注行業(yè)動(dòng)態(tài)，是否能準(zhǔn)確把握技術(shù)走向。保持適度的技術(shù)上的超前性，能夠使得你的架構(gòu)更新變得相對(duì)輕松。

另外，這里的超前性也不光是技術(shù)上的，還有產(chǎn)品上的。誰說架構(gòu)師就不需要跟產(chǎn)品經(jīng)理打交道了，沒事多跟產(chǎn)品經(jīng)理聊聊天，聽聽他對(duì)產(chǎn)品未來走向的暢想，你就可以在合理的地方為他的暢想留一條路子。同時(shí)，在創(chuàng)業(yè)公司的環(huán)境下，很多產(chǎn)品需求其實(shí)只是為了趕產(chǎn)品進(jìn)度而產(chǎn)生的妥協(xié)方案，最后還是會(huì)轉(zhuǎn)到正軌的。這時(shí)候業(yè)務(wù)方可以不實(shí)現(xiàn)轉(zhuǎn)到正規(guī)的方案，但是架構(gòu)這邊，是一定要為這種可預(yù)知的改變做準(zhǔn)備的。

接口少，接口參數(shù)少

越少的接口越少的參數(shù)，就能越降低業(yè)務(wù)方的使用成本。當(dāng)然，充要條件還是要滿足的，如何在滿足充要條件的情況下盡可能地減少接口和參數(shù)數(shù)量，這就能看出架構(gòu)師的功力有多深厚了。

高性能

為什么高性能排在最后一位？

高性能非常重要，但是在客戶端架構(gòu)中，它不是第一考慮因素。原因有下：

1.客戶端業(yè)務(wù)變化非常之快，做架構(gòu)時(shí)首要考慮因素應(yīng)當(dāng)是便于業(yè)務(wù)方快速滿足產(chǎn)品需求，因此需要盡可能提供簡(jiǎn)單易用效果好的接口給業(yè)務(wù)方，而不是提供高性能的接口給業(yè)務(wù)方。

2.蘋果平臺(tái)的性能非常之棒，正常情況下很少會(huì)出現(xiàn)由于性能不夠?qū)е碌挠脩趔w驗(yàn)問題。

3.蘋果平臺(tái)的優(yōu)化手段相對(duì)有限，甚至于有些時(shí)候即便動(dòng)用了無所不用其極的手段乃至不擇手段犧牲了穩(wěn)定性，性能提高很有可能也只不過是100ms到90ms的差距。10%的性能提升對(duì)于服務(wù)端來說很不錯(cuò)了，因?yàn)榉?wù)端動(dòng)不動(dòng)就是幾十萬上百萬的訪問量，幾十萬上百萬個(gè)10ms是很可觀的。但是對(duì)于客戶端的用戶來說，他無法感知這10ms的差別，如果從10s優(yōu)化成9s用戶還是有一定感知的，但是100ms變90ms，我覺得吧，還是別折騰了。

但是！不重要不代表用不著去做，關(guān)于性能優(yōu)化的東西，我會(huì)對(duì)應(yīng)放到各系列文章里面去。比如網(wǎng)絡(luò)層優(yōu)化，那就會(huì)在網(wǎng)絡(luò)層方案的那篇文章里面去寫，對(duì)應(yīng)每層架構(gòu)都有每層架構(gòu)的不同優(yōu)化方案，我都會(huì)在各自文章里面一一細(xì)說。

 關(guān)于架構(gòu)分層？

昨晚上志豪看了這篇文章之后說，看到你這個(gè)題目本來我是期望看到關(guān)于架構(gòu)分層相關(guān)的東西的，但是你沒寫。

嗯，確實(shí)沒寫，當(dāng)時(shí)沒寫的原因是感覺這個(gè)沒什么好寫的。前面談?wù)摰郊軜?gòu)的方法的時(shí)候，關(guān)于問題分類分模塊這一步時(shí)，架構(gòu)分層也屬于這一部分，給我一筆帶過了。

既然志豪提出來了這個(gè)問題，我想可能大家關(guān)于這個(gè)也會(huì)有一些想法和問題，那么我就在這兒講講吧。

其實(shí)分層這種東西，真沒啥技術(shù)含量，全憑架構(gòu)師的經(jīng)驗(yàn)和素質(zhì)。

我們常見的分層架構(gòu)，有三層架構(gòu)的：展現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)層。也有四層架構(gòu)的：展現(xiàn)層、業(yè)務(wù)層、網(wǎng)絡(luò)層、本地?cái)?shù)據(jù)層。這里說三層、四層，跟TCP/IP所謂的五層或者七層不是同一種概念。再具體說就是：你這個(gè)架構(gòu)在邏輯上是幾層那就幾層，具體每一層叫什么，做什么，沒有特定的規(guī)范。這主要是針對(duì)模塊分類而言的。

也有說MVC架構(gòu)，MVVM架構(gòu)的，這種層次劃分，主要是針對(duì)數(shù)據(jù)流動(dòng)的方向而言的。

在實(shí)際情況中，針對(duì)數(shù)據(jù)流動(dòng)方向做的設(shè)計(jì)和針對(duì)模塊分類做的設(shè)計(jì)是會(huì)放在一起的，也就是說，一個(gè)MVC架構(gòu)可以是四層：展現(xiàn)層、業(yè)務(wù)層、網(wǎng)絡(luò)層、本地?cái)?shù)據(jù)層。

那么，為什么我要說這個(gè)？

大概在五六年前，業(yè)界很流行三層架構(gòu)這個(gè)術(shù)語。然后各種文檔資料漫天的三層架構(gòu)，并且喜歡把它與MVC放在一起說，MVC三層架構(gòu)/三層架構(gòu)MVC，以至于很多人就會(huì)認(rèn)為三層架構(gòu)就是MVC，MVC就是三層架構(gòu)。其實(shí)不是的。三層架構(gòu)里面其實(shí)沒有Controller的概念，而且三層架構(gòu)描述的側(cè)重點(diǎn)是模塊之間的邏輯關(guān)系。MVC有Controller的概念，它描述的側(cè)重點(diǎn)在于數(shù)據(jù)流動(dòng)方向。

好，為什么流行起來的是三層架構(gòu)，而不是四層架構(gòu)或五層架構(gòu)？

因?yàn)樗械哪K角色只會(huì)有三種：數(shù)據(jù)管理者、數(shù)據(jù)加工者、數(shù)據(jù)展示者，意思也就是，籠統(tǒng)說來，軟件只會(huì)有三層，每一層扮演一個(gè)角色。其他的第四層第五層，一般都是這三層里面的其中之一分出來的，最后都能歸納進(jìn)這三層的某一層中去，所以用三層架構(gòu)來描述就比較普遍。

那么我們?cè)趺醋龇謱樱?/strong>