iOS 應用架構淺談

當咱們討論客戶端應用架構的時候，咱們在討論什麼？

其實市面上大部分應用不外乎就是顛過來倒過去地作如下這些事情：

簡單來講就是調API，展現頁面，而後跳轉到別的地方再調API，再展現頁面。

 App確實就是主要作這些事情，可是支撐這些事情的基礎，就是作架構要考慮的事情。

• 調用網絡API

• 頁面展現

• 數據的本地持久化

• 動態部署方案

上面這四大點，稍微細說一下就是：

• 如何讓業務開發工程師方便安全地調用網絡API？而後儘量保證用戶在各類網絡環境下都能有良好的體驗？

• 頁面如何組織，才能儘量下降業務方代碼的耦合度？儘量下降業務方開發界面的複雜度，提升他們的效率？

• 當數據有在本地存取的需求的時候，如何可以保證數據在本地的合理安排？如何儘量地減少性能消耗？

• iOS應用有審覈週期，如何可以經過不發版本的方式展現新的內容給用戶？如何修復緊急bug？

上面幾點是針對App說的，下面還有一些是針對團隊說的：

• 收集用戶數據，給產品和運營提供參考

• 合理地組織各業務方開發的業務模塊，以及相關基礎模塊

• daily build 自動打包，提供給產品體驗，給測試觀測性能

 因此當咱們討論客戶端應用架構的時候，咱們討論的差很少就是這些問題。

架構設計的方法 

全部事情最難的時候都是開始作的時候，當你開始着手設計並實現某一層的架構乃至整個app的架構的時候，頗有可能會出現暫時的無從下手的狀況。無論你採用什麼方法，全局觀、高度的代碼審美能力、靈活使用各類設計模式必定都是貫穿其中的。 

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

　　你必須得清楚你要作什麼，業務方但願要什麼。而不是爲了架構而架構，也不是爲了體驗新技術而改架構方案。之前是MVC，最近流行MVVM，若是過去的MVC是個好架構，沒什麼特別大的缺陷，就不要推倒而後搞成MVVM。

　　搞清楚對於業務方而言的真正充要條件很重要！這決定了你的架構是否足夠易用。另外，傳的參數越少，耦合度相對而言就越小，你替換模塊或者升級模塊所花的的代價就越小。

第二步：問題分類，分模塊

　　這個不用多說了吧。

第三步：搞清楚各問題之間的依賴關係，創建好模塊交流規範並設計模塊

 　　關鍵在於創建一套統一的交流規範。要注意的是，必定是創建一套統一的交流規範，不是兩套，不是多套。你要堅持你的價值觀，不要搖擺不定。要是搞出各類五花八門的規範出來，一方面有不切實際的炫技嫌疑，另外一方面也會帶來後續維護的災難。

第四步：推演預測一下將來可能的走向，必要時添加新的模塊，記錄更多的基礎數據以備將來之需

　　不少稱職的架構師都會在這時候考慮架構將來的走向，以及考慮作完這一輪架構以後，接下來要作的事情。一個好的架構雖然是功在當代利在千秋的工程，但絕對不是一個一勞永逸的工程。軟件是有生命的，你作出來的架構決定了這個軟件它這一輩子是坎坷仍是幸福。

第五步：先解決依賴關係中最基礎的問題，實現基礎模塊，而後再用基礎模塊堆疊出整個架構

 　　這一步也是驗證你以前的設計是否合理的一步，隨着這一步的推動，你頗有可能會遇到須要對架構進行調整的狀況。這個階段必定要吹毛求疵高度負責地去開發，不要得過且過，發現架構有問題就及時調整。不然之後調整的成本就很是之大了。

第六步：打點，跑單元測試，跑性能測試，根據數據去優化對應的地方 

你得用這些數據去向你的leader邀功，你也得用這些數據去不斷調整你的架構。

總而言之就是要遵循這些原則：自頂向下設計（1，2，3，4步），自底向上實現（5），先測量，後優化（6）。