iOS 應用架構淺談

標籤：

當我們討論用戶端應用架構的時候，我們在討論什嗎？

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

簡單來說就是調API，展示頁面，然後跳轉到別的地方再調API，再展示頁面。

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

• 調用網路API

• 頁面展示

• 資料的本地持久化

• 動態部署方案

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

• 如何讓業務開發工程師方便安全地調用網路API？然後儘可能保證使用者在各種網路環境下都能有良好的體驗？

• 頁面如何組織，才能儘可能降低業務方代碼的耦合度？儘可能降低業務方開發介面的複雜度，提高他們的效率？

• 當資料有在本地存取的需求的時候，如何能夠保證資料在本地的合理安排？如何儘可能地減小效能消耗？

• iOS應用有審核周期，如何能夠通過不發版本的方式展示新的內容給使用者？如何修複緊急bug？

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

• 收集使用者資料，給產品和運營提供參考

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

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

 所以當我們討論用戶端應用架構的時候，我們討論的差不多就是這些問題。

架構設計的方法 

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

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

　　你必須得清楚你要做什麼，業務方希望要什麼。而不是為了架構而架構，也不是為了體驗新技術而改架構方案。以前是MVC，最近流行MVVM，如果過去的MVC是個好架構，沒什麼特別大的缺陷，就不要推倒然後搞成MVVM。

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

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

　　這個不用多說了吧。

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

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

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

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

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

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

第六步：打點，跑單元測試，跑效能測試，根據資料去最佳化對應的地方 

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

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

iOS 應用架構淺談