摘要：移動精英開發社群的第期，也是圍繞架構這個話題進行討論。本次我們希望結合實際開發中遇到的問題，來聊聊移動端的架構設計。這樣的模式改進一些，可能會更適合移動端架構。潘衛杰之前我們公司移動端的大項目就是插座式開發的，批量出各個行業的。

此前，58 同城的技術委員會執行主席沈劍在 OneAPM 的技術公開課上分享過一個主題，「好的架構不是設計出來的，而是演技出來的」。因為對很多創業公司而言，隨著業務的發展，網站流量或者移動端用戶都會經歷不同的階段。前期的時候，很難去設計一個百萬或者千萬級并發的架構，所以后期往往不斷對架構進行更新迭代。

當然，在這里也推薦一篇文章《移動開發中的痛點》，本文是 infoQ 舉辦線下聚會的一次討論整理，當時參與的討論者包括唐巧、郭亮、郭虹宇、鄧宇光、代碼家等國內知名移動開發者。其中就談及了 MVC 架構的痛點，以及 React Native 所代表的 Web 開發 Native App 技術，相信會對大家有所啟發。移動精英開發社群的第8期，也是圍繞「架構」這個話題進行討論。本文系滴滴出行的劉佳達整理。

以下為討論內容整理：

主持人韓兵：「架構」對開發者而言就是「高大上」，當然也不是每位 coder 都能搞定。對很多菜鳥而言就更陌生了，基本只能停留在理論層次。實踐才能出真知，一個好的架構也是這樣產生的。本次我們希望結合實際開發中遇到的問題，來聊聊移動端的架構設計。

李文杰：我們的項目劃分成了：數據層、UI 層、邏輯層。

上海-李博：我們使用的是 MVVM（Model-View-ViewModel），然后使用了一些 React Native。

韓兵：MVC 這樣的模式可以代替咱們移動端架構嗎？

攻城獅：MVC、MVVM 只是一種設計模式而已。

Wallace：個人認為， MVC 這種經典結構已經滿足不了現在的需求了。

Rory：MVC 這樣的模式改進一些，可能會更適合移動端架構。從業務邏輯的角度看，架構應該服從業務邏輯。

王威特-明道-ios：基于團隊、服務于團隊的代碼基礎規范包含開發模式，代碼規范等等。

Draven-ios：我認為，MVVM + React Native 能讓開發變得輕松很多。

李文杰-上海數云-ios：特別希望有一套成熟的架構，UI 和邏輯都寫好了。只要寫寫數據就可以用了。我針對的是超快速的簡單需求 APP 開發，就像很多建站技術一樣，「拖一拖」就可以完成。

攻城獅：功能模塊化也是架構中很重要的一環。

小龍：萬變不離其宗，天下武功出一家！ 移動端各路設計不也是圍繞著 MVC 控制顯示數據，然后再做各種拆分嗎？

露露：模塊與模塊之間，應該能快速拆分然后移植到新的項目中吧？

蜂鳥：用 React 基于響應式函數編程是可以簡化實現過程，省很多代碼。

劉玉嬌-小鄰小里-ios：問下大家網絡層搭建用的是 delegate 還是 block ？我們后來用的，發現好像 delegate 會好一點。

Draven-ios：block 比較靈活。

王宇-陸金所-ios：但是 block 寫的太隨意了。

Draven-ios：delegate 看起來比較規范。

小龍：block 是方便，但別忘了它是一個結構體。

蜂鳥：昨天碰到一個問題，就是一個 App 有100多個人共同開發，怎么設計架構？才能讓100個人協同開發不出問題？

A-困惑：一般用 block。

Icocos：之前有人討論過，說用 MVP 比較好。

小龍：如果東西多了很重的，delegate 傳的時候只是一個指針。

進擊的小比克：一部分做網絡層，一部分做業務邏輯，一部分做 UI。

王威特-明道-ios：delegate 書寫規范，也可以避免循環引用的問題。block 書寫流暢，但是會把網絡的代碼分散在各處，最終維護不一定好。建議在網絡業務種的結構內用 delegate，反之block更方便。

露露：如果幾個實例用一個 delegate，需要判斷。

上海-李博：我覺得，進行工程性的管理，還是比較好。各做各的業務，淘寶就是采用這種模式。相當于每個業務維護一個工程。

潘衛杰：可以使用插座式的模塊開發。分成多個小 Team ，負責相對獨立的業務功能開發，每個 Team 配一個測試，通過了就提交，隨時可以打包出成品。

韓兵：之前也有人說了，架構是不僅僅是為了方便業務，還有一個是為了我們 coder 快速開發。那架構解決了我們項目開發中的什么問題？

露露：現在 block 用的很多，但是怎么才算使用的好呢？

小龍：delegate 是指針，block 是結構體，一個傳遞的時候輕，但寫著麻煩，一個寫著方便傳遞的時候比較重。

潘衛杰：之前我們公司移動端的大項目就是「插座式」開發的，批量出各個行業的 App。

Rory：移動架構設計和選型根據我的經驗應該遵守以下幾個原則吧：

優先保證業務邏輯；

架構設計遵循簡潔的原則；

架構的學習成本不要太高，需要符合當前技術團隊內開發人員的能力范圍；

架構是在開發過程中不斷擴充和維護的，代碼重構也是架構的核心之一。

劉玉嬌：還有個問題，大家 VC 的分層是 base 然后下邊分為 baselist 和 baseentity 然后往下繼承嗎？

上海-李博：我感覺上面說的繼承這樣下去會越來越痛苦

潘衛杰：前年的時候，行業內有一個說法：各個行業扁平化，去中心化，很多行業老板也都想有自己的電子商務平臺。我們之前就給他們解決這個問題，但是我們又不能每家都出一個，就用這種方式出一個很多功能的，各家用的時候在后臺自定義組合。

小龍：高內聚低耦合！

Noark9：以前公司做一個 Windows 上應用的覺得思路可以借鑒：我們有一個比較大的，我們稱為 shell（殼程序），然后，殼程序提供了接口請求的框架，用戶信息的接口，發送通知，以及一些公共的功能。然后，每個小功能，都作為一個動態庫接入，殼程序負責加載下載下來的動態庫，然后打開到界面上。

王宇-陸金所-ios：具體怎么和業務模塊拆分方法呢？

韓兵：服務端都是重架構，一般移動端都偏輕架構。

王威特：是，繼承的耦合性太重。用組合的方式更好，前幾天的一篇文章就非常推薦閱讀。

http://blog.yongfengzhang.com/cn/blog/write-code-that-is-easy-to-delete-not-easy-to/

Rory：理論上，架構不一定要多復雜。但是至少簡明的可以區分組件、組件的邏輯、業務邏輯、數據層。讓組件的邏輯和業務邏輯分離，減少代碼耦合；方法的適量重載和重寫；在項目的維護期，抽離項目特有的組件。

蜂鳥：具體到寫代碼，就是多用接口，定義個協議來實現后使用它。

小龍：面向協議就是看接口定義的怎么樣了?？梢园迅餍袠I一些特性歸類為某一類屬性，統一處理，最后用的時候換個皮，換套文案就可以。

蜂鳥：API 接口定義的好，說明模塊分離，邊界定義的很清楚。

小龍：面向協議的變成是不是給 ViewController 暴露的都是 id<某個協議> ？這種形式的，而不需要 import 具體的類？求解答。

你該休息了：Android 架構中熱部署大家常采用的多嗎 ？

李哲-京東：我重寫的時候，就遵循的就是各個模塊的拆分。將業務，功能，包括很小的通知名，顏色，緩存路徑都搞成了宏定義。將網絡，數據，業務，功能都剝離了出來。

王威特：宏定義寫起來有些難堪，用 const string 不是更好嗎？

韓兵：可以推薦一些架構設計比較好的來源代碼

阿塵：個人感覺，要深入移動架構，必須了解企業應用架構。開源的完整 App 應該比較少。為什么要有架構？根本原因還是在于復雜性。頭一次看到就五體投地，之前用 NimbusKit 搭架構，現在打算轉向 YYKit 。簡單的 App 是不需要架構的。

李哲：將一些業務的解決方法，使用模型思想去解決，尤其是那個微博列表的設計。要寫易刪除，而不易擴展的代碼。

阿塵：個人感覺，合理的分層設計很關鍵。

哈哈：比如微信 SDK，集成了登錄、分享、支付三個大的功能，不支持多帶帶拆分使用，如果之前已經使用了友盟、shareSDK 等，只想接入微信支付功能，就會出現沖突問題。

阿塵：架構的構建是一個不斷權衡的過程。

有一個道理：架構的構建是一個不斷權衡的過程？這個有點不同意。

蜂鳥：我覺得架構之所以需要，就是要保持一個基本的穩定架構，別變來變去的。再變也是細節和模塊功能的補充，跳不出已經設定好的架構。

韓兵：好的東西都不是不斷改，不斷優化的。

小龍：響應式編程思想：不需要考慮調用順序，只需要知道考慮結果，類似于蝴蝶效應，產生一個事件，會影響很多東西，這些事件像流一樣的傳播出去，然后影響結果，借用面向對象的一句話，萬物皆是流。

而函數式編程思想是把操作盡量寫成一系列嵌套的函數或者方法調用。函數式編程特點：每個方法必須有返回值（本身對象），把函數或者 Block 當做參數，block 參數（需要操作的值）block 返回值（操作結果）。

代表：ReactiveCocoa。

李哲-京東：而一個好的架構也總是在業務不斷變化中慢慢變好的。

小龍：鏈式編程思想：是將多個操作（多行代碼）通過點號(.)鏈接在一起成為一句代碼,使代碼可讀性好。a(1).b(2).c(3)

鏈式編程特點：方法的返回值是 block,block 必須有返回值（本身對象），block 參數（需要操作的值）

代表：masonry 框架。

蜂鳥：如果架構總是變來變去，恰恰證明了架構設計的不合理。

攻城獅：現在好多大公司有個技術平臺部，把一些功能抽象出來模塊化，這樣業務線開發就簡單很多，效率也高了。

阿塵：架構是一組決策的組合，做每個決策的過程都是一次取舍和權衡，這樣理解嗎？我覺得，實踐出真知，從0開始打造一個復雜 App 的過程，會讓你受益匪淺。

王威特：這回到主持人說的，架構是經驗積累出來的，慢慢來。即使做了一個壞架構，以后和別人的對比下就收獲頗豐了。

攻城獅：架構不是一下就有的，走過才知道捷徑。

蜂鳥：同意你說的決策的取舍平衡，我的看法是這種決策取舍越少越好。好的架構應該能有空間適應這種業務的變化，預見到也許會有的改動，有點理想化了。

王威特：一個長期迭代的 App 做的就是架構和業務，架構能力也是慢慢磨出來的。如果在外包公司工作，更要做好架構，才能快速開發。

攻城獅：有些公司 iOS 頁面跳轉是統一的一個管理類來管理的，在座各位有這么做的嗎？

進擊的小比克：現在的項目既按功能模塊分，又分業務邏輯、網絡層、數據層，分得有點亂啊！和網絡服務器框架一樣。

高山：比如一個頁面，需要 abcd 四個頁面才能過來，現在一個 url ，很多前置條件都沒有，可能導致錯誤。這就對架構解耦提出更高的要求。

王威特：最早 ABRouter ，你給 viewController 寫個 category 就行了。這里說的是iOS，用 router 實現跳轉，一個極大的極大的便利就是以后你的 App 需要實現從 safari 瀏覽器打開 App ，發現你都搞定了。

韓兵：好像咱們討論組做服務端的人不多。什么是服務端架構？服務端涉及的東西太多。只有親自設計過和處理過數量級比較大的系統，才可能會對架構有所體悟。要不然很可能是「紙上談兵」。

Wallace：其實好的架構，無非是能在你現有的情況下，能解決實際中存在的問題。有些很牛逼的架構不一定適用于現在的具體場景。

韓兵：本身架構包含的知識就很多，不僅僅一門編程語言。

攻城獅：Java 比較成熟，但是提供的架構還有一些并不是很成熟。

檸檬：從頭看了下，都是偏于理論，對于架構還是沒什么印象，比如說 MVC，這也是最基本的。但是如何做到架構師級別？求指教。

檸檬：最近在整理一些知識，個人感覺，想能為架構師，就是把基本的東西包「打包」在一個項目中。

Wallace：其實寫的時間長了，很自然的就能時刻考慮到「高內聚低耦合」的思維了。尤其是，寫完一個模塊后也可以錘煉自己。

韓兵：設計一個 App，首先應該考慮的就是它的架構。先把結構搭建起來，網絡層封裝好，第三方控件封裝好，然后最快速度支撐起業務層。其實在實際開發中，沒有那么多時間成本，還是需要優化一些東西。

丁建龍：模塊化，最少的暴露參數和接口。

檸檬：目前所面臨的代碼質量問題，絕大部分不是技術問題，不是 coding 能力問題，是節奏把控，是質量觀念的問題，如何平衡 scope 、quality、schedule，這不是自下而上的變革，是自上而下的思想改變，每一個技術 leader 都需要去權衡把控。

一切質量問題，本質上就是技術 leader 的問題，很多人可能會說，業務需求太多，工作量太大，跑得太快，這些都是事實，事實的背后是，我們技術有沒有真正去理解業務，理解產品的思路和想法，理解業務的核心訴求和難點，大家一定可以平衡好這三方面的關系。

韓兵：大家的項目都是怎么搭建起來的？

檸檬：我們是第一版肯定是快速出原形，看用戶的功能，兩周一個迭代。成型后重構。

Rory：初期：簡易架構，實現基礎功能，組件；開發過程中：迭代豐富組件，抽離業務，形成模塊化。像初期選型，我可以用諾遠目前1.0->1.1的版本發展歷程舉個例子。后期維護擴容，可以用365日歷的 Android 客戶端舉個例子。

韓兵：這個只有實踐過，才可能會有一些感悟。說說大家 App 從無到有的構建過程。從這個過程中理解架構的形成和運作。個人覺得從這點入手，會容易理解一些。

檸檬：架構看功力，架構師的路很長，不斷的被指責，改進的過程，這是漫長的過程。我現在的想法是把幾乎所有項目都用到的東西，整理在一個項目下，以后獨立開發可以直接運用。還可以把整個項目底層做一個基類。

Rory：目前互聯網行業主要還是敏捷開發，所以初期選型的時候，其實架構細分顯得不是很重要，倒是架構上為后期模塊化，可擴展性的方面考慮更多。比如，小諾理財 Android 客戶端，初期架構只做了網絡層，數據解析，activity 基類封裝，圖片緩存，和一些常用的 UI 組件。

露露：我覺得你可以整合，但是如果用了某一個功能，能快速拆分。

Wallace：我曾經最開始工作的時候，以為把見過的東西都存下來，到時候用上，但其實都沒用上。

Rory：整體上業務結構初期都是在 Activity 中處理的，沒有做業務邏輯的抽離。從1.0-1.1的過程中，這邊的 Android 技術團隊進行了一些重構和業務抽離，構建基礎。形成目前定制的 UI組件庫（目前 UI 組件的邏輯仍然未進行細致抽離）、業務邏輯 control 單元（目前是依據業務模塊的不同，抽離不同模塊的 control。）這么做，主要的目的是為了后續新加入的技術，可以快速熟悉項目，了解業務。

韓兵：如果這個項目越做越大，咱們就暫定理財項目，是不是要考慮底層框架對現有業務的支持？如果團隊越來越大，是不是還要考慮對n多個團隊的支持？

Rory：理財和支付一樣，對數據安全和通信安全比較重視。

阿塵：橫向業務模塊化，豎向低耦合，做到單向依賴。

Rory：曾經參與過，365日歷 Android 客戶端的后期維護。當時客戶端項目到了后期，模塊劃分會越來越多，項目會變得越來越臃腫。這時候在 java 層面和 Android framework 層的優化其實更少。

多數組件這時候都已經很成熟，這時候需要集成性能測試，針對某一點上進行細節優化。架構上也是抽離出更多的庫，進行細分支持。365日歷其實是典型的 MVC 向 MVP 的過渡。當然，我離職的時候這個過渡還未完成?；旧想r形可以看到，UI 層和業務層已經進行深度劃分，通過 control 控制數據傳遞和通信。

MVP，個人經驗更適合移動端，移動端開發的主要難點是兩個，業務邏輯和界面效果。

韓兵：所以移動端和服務端考慮的點也是不一樣的！

Rory：把 UI 和業務邏輯區分，這樣控制單元更有針對性，對原有業務或者UI的修改更有針對性，迭代過程中產生錯誤理解和錯誤邏輯導致 bug 的可能性也更小。

可能因為這樣抽離后，新技術的加入，理解項目需要更長的時間。代碼閱讀性會隨著項目的臃腫變得越來越差。所以必要的抽離就是保證代碼的可讀性。

過渡重構舉個很簡單的例子，一個 View 的 UI 邏輯非要強行適應整個項目所有的 View，創造 n 個構造，傳入多個控制參數。那么邏輯理解起來是不是很困難？最簡單的判定標準，代碼的創造者如果隔一段時間都很難讀得懂自己寫的代碼，算不算一種過度？

簡單的總結下，架構應該隨著項目發展不斷發展，一成不變的架構是行不通的！

國內 ITOM 管理平臺 OneAPM 致力于幫助企業用戶提供全棧式的性能管理以及 IT 運維管理服務，通過一個探針就能夠完成日志分析、安全防護、APM 基礎組件監控、集成報警以及大數據分析等功能。想閱讀更多優秀文章，請訪問 OneAPM 官方技術博客
本文轉自 OneAPM 官方博客