專欄截止到上一期萝快，架構(gòu)設(shè)計(jì)相關(guān)的理念、技術(shù)著角、實(shí)踐已經(jīng)基本講完揪漩，相信你一路學(xué)習(xí)過來會(huì)有一種感覺，這些內(nèi)容主要都是講后端系統(tǒng)的架構(gòu)設(shè)計(jì)吏口，例如存儲(chǔ)高可用奄容、微服務(wù)、異地多活等产徊，都是后端系統(tǒng)才會(huì)涉及昂勒。事實(shí)上確實(shí)也是如此，通常情況下我們講架構(gòu)設(shè)計(jì)舟铜，主要聚焦在后端系統(tǒng)戈盈，但這并不意味著 App、前端就沒有架構(gòu)設(shè)計(jì)了谆刨，專欄所講述的整套架構(gòu)設(shè)計(jì)理念塘娶，雖然是來源于我的后端設(shè)計(jì)經(jīng)驗(yàn)，但一旦形成完善的技術(shù)理論后痊夭，同樣適應(yīng)于 App 和前端刁岸。

首先，先來復(fù)習(xí)一下我的專欄所講述的架構(gòu)設(shè)計(jì)理念她我，可以提煉為下面幾個(gè)關(guān)鍵點(diǎn)：

架構(gòu)是系統(tǒng)的頂層結(jié)構(gòu)虹曙。

架構(gòu)設(shè)計(jì)的主要目的是為了解決軟件系統(tǒng)復(fù)雜度帶來的問題。

架構(gòu)設(shè)計(jì)需要遵循三個(gè)主要原則：合適原則番舆、簡單原則根吁、演化原則。

架構(gòu)設(shè)計(jì)首先要掌握業(yè)界已經(jīng)成熟的各種架構(gòu)模式合蔽，然后再進(jìn)行優(yōu)化击敌、調(diào)整、創(chuàng)新拴事。

復(fù)習(xí)完我們就可以進(jìn)入今天的正題沃斤，我來談?wù)?App 架構(gòu)的演進(jìn)，以及上面這些架構(gòu)設(shè)計(jì)關(guān)鍵點(diǎn)是如何體現(xiàn)的刃宵。

Web App

最早的 App 有很多采用這種架構(gòu)衡瓶，大多數(shù)嘗試性的業(yè)務(wù)，一開始也是這樣的架構(gòu)牲证。Web App 架構(gòu)又叫包殼架構(gòu)哮针，簡單來說就是在 Web 的業(yè)務(wù)上包裝一個(gè) App 的殼，業(yè)務(wù)邏輯完全還是 Web 實(shí)現(xiàn)，App 殼完成安裝的功能十厢，讓用戶看起來像是在使用 App等太，實(shí)際上和用瀏覽器訪問 PC 網(wǎng)站沒有太大差別。

為何早期的 App 或者嘗試新的業(yè)務(wù)采用這種架構(gòu)比較多呢蛮放？簡單來說缩抡，就是當(dāng)時(shí)業(yè)務(wù)面臨的復(fù)雜度決定的。我們以早期的 App 為例包颁，大約在 2010 年前后瞻想，移動(dòng)互聯(lián)網(wǎng)雖然發(fā)展很迅速，但受限于用戶的設(shè)備娩嚼、移動(dòng)網(wǎng)絡(luò)的速度等約束蘑险，PC 互聯(lián)網(wǎng)還是主流，移動(dòng)互聯(lián)網(wǎng)還是一個(gè)新鮮事物岳悟，未來的發(fā)展前景和發(fā)展趨勢(shì)漠其，其實(shí)當(dāng)年大家也不一定能完全看得清楚。例如淘寶也是在 2013 年才開始決定“All in 無線”的竿音，在這樣的業(yè)務(wù)背景下和屎，當(dāng)時(shí)的業(yè)務(wù)重心還是在 PC 互聯(lián)網(wǎng)上，移動(dòng)互聯(lián)網(wǎng)更多是嘗試性的春瞬。既然是嘗試柴信，那就要求快速和低成本，雖然當(dāng)時(shí)的 Android 和 iOS 已經(jīng)都有了開發(fā) App 的功能宽气，但原生的開發(fā)成本太高随常，因此自然而然，Web App 這種包殼架構(gòu)就被大家作為首選嘗試架構(gòu)了萄涯，其主要解決“快速開發(fā)”和“低成本”兩個(gè)復(fù)雜度問題绪氛，架構(gòu)設(shè)計(jì)遵循“合適原則”和“簡單原則”。

原生 App

Web App 雖然解決了“快速開發(fā)”和“低成本”兩個(gè)復(fù)雜度問題涝影，但隨著業(yè)務(wù)的發(fā)展枣察，Web App 的劣勢(shì)逐漸成為了主要的復(fù)雜度問題，主要體現(xiàn)在：

移動(dòng)設(shè)備的發(fā)展速度遠(yuǎn)遠(yuǎn)超過 Web 技術(shù)的發(fā)展速度燃逻，因此 Web App 的體驗(yàn)相比原生 App 的體驗(yàn)序目，差距越來越明顯。

移動(dòng)互聯(lián)網(wǎng)飛速發(fā)展伯襟，趨勢(shì)越來越明顯猿涨，App 承載的業(yè)務(wù)邏輯也越來越復(fù)雜，進(jìn)一步加劇了 Web App 的體驗(yàn)問題姆怪。

移動(dòng)設(shè)備在用戶體驗(yàn)方面有很多優(yōu)化和改進(jìn)叛赚，而 Web App 無法利用這些技術(shù)優(yōu)勢(shì)澡绩，只有原生 App 才能夠利用這些技術(shù)優(yōu)勢(shì)。

因此俺附，隨著業(yè)務(wù)發(fā)展和技術(shù)演進(jìn)肥卡，移動(dòng)開發(fā)的復(fù)雜度從“快速開發(fā)”和“低成本”轉(zhuǎn)向了“用戶體驗(yàn)”，而要保證用戶體驗(yàn)昙读，采用原生 App 的架構(gòu)是最合適的召调，這里的架構(gòu)設(shè)計(jì)遵循“演化原則”膨桥。

原生 App 解決了用戶體驗(yàn)問題蛮浑，沒記錯(cuò)的話大約在 2013 年前后開始快速發(fā)展，那個(gè)時(shí)候的 Android 工程師和 iOS 工程師就像現(xiàn)在的人工智能工程師一樣非常搶手只嚣，很多同學(xué)也是那時(shí)候從后端轉(zhuǎn)行到 App 開發(fā)的沮稚。

Hybrid App

原生 App 很好的解決了用戶體驗(yàn)問題，但業(yè)務(wù)和技術(shù)也在發(fā)展册舞，移動(dòng)互聯(lián)網(wǎng)此時(shí)已經(jīng)成為明確的大趨勢(shì)蕴掏，團(tuán)隊(duì)需要考慮的不是要不要轉(zhuǎn)移動(dòng)互聯(lián)網(wǎng)的問題，而是要考慮如何在移動(dòng)互聯(lián)網(wǎng)更具競(jìng)爭力的問題调鲸，因此各種基于移動(dòng)互聯(lián)網(wǎng)特點(diǎn)的功能和體驗(yàn)方式不斷被創(chuàng)造出來盛杰，大家拼的競(jìng)爭方式就是看誰更快抓住用戶需求和痛點(diǎn)。因此藐石，移動(dòng)開發(fā)的復(fù)雜度又回到了“快速開發(fā)”即供，這時(shí)就發(fā)現(xiàn)了原生 App 開發(fā)的痛點(diǎn)：由于 Android、iOS于微、Windows Phone（你沒看錯(cuò)逗嫡，當(dāng)年確實(shí)是這三個(gè)主流平臺(tái)）的原生開發(fā)完全不能兼容，同樣的功能需要三個(gè)平臺(tái)重復(fù)開發(fā)株依，每個(gè)平臺(tái)還有一些差異驱证，因此自然快不起來。

為了解決“快速開發(fā)”的復(fù)雜度問題恋腕，大家自然又想到了 Web 的方式抹锄，但 Web 的體驗(yàn)還是遠(yuǎn)遠(yuǎn)不如原生，怎么解決這個(gè)問題呢荠藤？其實(shí)沒有辦法完美解決祈远，但可以根據(jù)不同的業(yè)務(wù)要求選取不同的方案，例如對(duì)體驗(yàn)要求高的業(yè)務(wù)采用原生 App 實(shí)現(xiàn)商源，對(duì)體驗(yàn)要求不高的可以采用 Web 的方式實(shí)現(xiàn)车份，這就是 Hybrid App 架構(gòu)的核心設(shè)計(jì)思想，主要遵循架構(gòu)設(shè)計(jì)的“合適原則”牡彻。

組件化 & 容器化

Hybrid App 能夠較好的平衡“用戶體驗(yàn)”和“快速開發(fā)”兩個(gè)復(fù)雜度問題（注意是“平衡”扫沼，不是“同時(shí)解決”）出爹，但對(duì)于一些超級(jí) App 來說，隨著業(yè)務(wù)規(guī)模越來越大缎除、業(yè)務(wù)越來越復(fù)雜严就，雖然在用戶看來可能是一個(gè) App，但事實(shí)上承載了幾十上百個(gè)業(yè)務(wù)器罐。

以手機(jī)淘寶為例梢为，阿里確認(rèn)“All in 無線”戰(zhàn)略后，手機(jī)淘寶定位為阿里集團(tuán)移動(dòng)端的“航空母艦”轰坊，上面承載了非常多的子業(yè)務(wù)铸董，下圖是淘寶的首頁第一屏，相關(guān)的子業(yè)務(wù)初步估計(jì)就有 10 個(gè)以上肴沫。

再以微信為例粟害，作為騰訊在移動(dòng)互聯(lián)網(wǎng)的“航空母艦”，其業(yè)務(wù)也是非常的多颤芬，如下圖悲幅，“發(fā)現(xiàn)”tab 頁就有 7 個(gè)子業(yè)務(wù)。

這么多業(yè)務(wù)集中在一個(gè) App 上站蝠，每個(gè)業(yè)務(wù)又在不斷地?cái)U(kuò)展汰具，后續(xù)又可能會(huì)擴(kuò)展新的業(yè)務(wù)，并且每個(gè)業(yè)務(wù)就是一個(gè)獨(dú)立的團(tuán)隊(duì)負(fù)責(zé)開發(fā)菱魔，因此整個(gè) App 的可擴(kuò)展性引入了新的復(fù)雜度問題留荔。

我在專欄第 32 期提到，可擴(kuò)展的基本思想就是“拆”豌习，但是這個(gè)思想應(yīng)用到 App 和后端系統(tǒng)時(shí)存谎，具體的做法就明顯不同了。簡單來說肥隆，App 和后端系統(tǒng)存在一個(gè)本質(zhì)的區(qū)別既荚，App 是面向用戶的，后端系統(tǒng)是不面向用戶的栋艳，因此 App 再怎么拆恰聘，對(duì)用戶還是只能呈現(xiàn)同一個(gè) App，不可能將一個(gè) App 拆分為幾十個(gè)獨(dú)立 App吸占；而后端系統(tǒng)就不一樣了晴叨，采用微服務(wù)架構(gòu)后，后端系統(tǒng)可以拆分為幾百上千個(gè)子服務(wù)都沒有問題矾屯。同時(shí)兼蕊，App 的業(yè)務(wù)再怎么拆分，技術(shù)棧是一樣的件蚕，不然沒法集成在一個(gè) App 里面孙技；而后端就不同了产禾，不同的微服務(wù)可以用不同的技術(shù)棧開發(fā)。

在這種業(yè)務(wù)背景下牵啦，組件化和容器化架構(gòu)應(yīng)運(yùn)而生亚情，其基本思想都是將超級(jí) App 拆分為眾多組件，這些組件遵循預(yù)先制定好的規(guī)范哈雏，獨(dú)立開發(fā)楞件、獨(dú)立測(cè)試、獨(dú)立上線裳瘪。如果某個(gè)組件依賴其他組件土浸，組件之間通過消息系統(tǒng)進(jìn)行通信，通過這種方式來實(shí)現(xiàn)組件隔離盹愚，從而避免各個(gè)團(tuán)隊(duì)之間的互相依賴和影響栅迄，以提升團(tuán)隊(duì)開發(fā)效率和整個(gè)系統(tǒng)的可擴(kuò)展性站故。組件化和容器化的架構(gòu)出現(xiàn)遵循架構(gòu)設(shè)計(jì)的“演化原則”皆怕，只有當(dāng)業(yè)務(wù)復(fù)雜度發(fā)展到一定規(guī)模后才適應(yīng)，因此我們會(huì)看到大廠應(yīng)用這個(gè)架構(gòu)的比較多西篓，而中小公司的 App愈腾，業(yè)務(wù)沒那么復(fù)雜，其實(shí)并不一定需要采用組件化和容器化架構(gòu)岂津。

對(duì)于組件化和容器化并沒有非常嚴(yán)格的定義虱黄，我理解兩者在規(guī)范、拆分吮成、團(tuán)隊(duì)協(xié)作方面都是一樣的橱乱，區(qū)別在于發(fā)布方式，組件化采用的是靜態(tài)發(fā)布粱甫，即所有的組件各自獨(dú)自開發(fā)測(cè)試泳叠，然后跟隨 App 的某個(gè)版本統(tǒng)一上線；容器化采用的是動(dòng)態(tài)發(fā)布茶宵，即容器可以動(dòng)態(tài)加載組件危纫，組件準(zhǔn)備好了直接發(fā)布，容器會(huì)動(dòng)態(tài)更新組件乌庶，無需等待某個(gè)版本才能上線种蝶。

關(guān)于手機(jī)淘寶 App 更詳細(xì)的架構(gòu)演進(jìn)可以參考《Atlas：手淘 Native 容器化框架和思考》，微信 App 的架構(gòu)演進(jìn)可以參考《微信 Android 客戶端架構(gòu)演進(jìn)之路》瞒大。

跨平臺(tái) App

前面我介紹的各種 App 架構(gòu)螃征，除了 Web App 外，其他都面臨著同一個(gè)問題：跨平臺(tái)需要重復(fù)開發(fā)透敌。同一個(gè)功能和業(yè)務(wù)盯滚，Android 開發(fā)一遍锅棕，iOS 也要開發(fā)一遍，這里其實(shí)存在人力投入的問題淌山，違背了架構(gòu)設(shè)計(jì)中的“簡單原則”裸燎。站在企業(yè)的角度來講，當(dāng)然希望能夠減少人力投入成本（雖然我站在程序員的角度來講是不希望程序員被減少的）泼疑，因此最近幾年各種跨平臺(tái)方案不斷涌現(xiàn)德绿，比較知名的有 Facebook 的 React Native、阿里的 Weex退渗、Google 的 Flutter移稳。雖然也有很多公司在嘗試使用，但目前這幾個(gè)方案都不算很成熟会油，且在用戶體驗(yàn)方面與原生 App 還是有一定差距个粱，例如 Airbnb 就宣布放棄使用 React Native，回歸使用原生技術(shù)（https://www.oschina.net/news/97276/airbnb-sunsetting-react-native）翻翩。

前端的情況也是類似的都许，有興趣的同學(xué)可以看看玉伯的文章《Web 研發(fā)模式演變》，專欄里我就不在贅述了嫂冻。

小結(jié)

今天我為你講了 App 架構(gòu)演進(jìn)背后的原因和架構(gòu)分析胶征，希望對(duì)你有所幫助。

這就是今天的全部內(nèi)容桨仿，留一道思考題給你吧睛低，你認(rèn)為 App 架構(gòu)接下來會(huì)如何演進(jìn)？談?wù)勀愕乃伎己头治觥?/p>

歡迎你把答案寫到留言區(qū)服傍，和我一起討論钱雷。相信經(jīng)過深度思考的回答，也會(huì)讓你對(duì)知識(shí)的理解更加深刻吹零。（編輯亂入：精彩的留言有機(jī)會(huì)獲得豐厚福利哦Ｕ挚埂）