本文由玉剛說寫作平臺提供寫作贊助，版權(quán)歸玉剛說微信公眾號所有
原作者：Mr.s（豬_隊友）
版權(quán)聲明：未經(jīng)玉剛說許可，不得以任何形式轉(zhuǎn)載

架構(gòu)就像是一場進化史，根據(jù)不同時期的需求，演變出不同的架構(gòu)戒财，車輪滾滾，到今天捺弦，移動端框架百花齊放饮寞，讓人目不暇接。但是其中的本質(zhì)是磨滅不了的列吼，換言之根本沒有磨滅而是隱藏到了人們所看不到的地方幽崩，但是依舊發(fā)揮著不可或缺的作用。

為什么需要架構(gòu)寞钥？

1慌申、一個Activity走天下，包含各種模塊和功能
2理郑、臃腫類太多
3蹄溉、不同功能，不同層次拎不清楚您炉，混合在一起
4柒爵、重復(fù)代碼太多，復(fù)用性為差赚爵。
5棉胀、無法協(xié)作開發(fā)，
6冀膝、耦合嚴重唁奢，bug太多
等等

當(dāng)我們新進一個公司，接受別人的項目的時候窝剖，基本都會說句MMP麻掸，SHI一樣的代碼啊，啥玩意啊赐纱，搞得什么啊论笔。

我擦采郎，我就改了一個參數(shù)千所，怎么全亂套了狂魔，一個功能怎么天上地下都需要改啊。
沒有經(jīng)受過痛苦的人淫痰，是不會想了解架構(gòu)的最楷，只有痛苦過的人，才會急切的了解架構(gòu)待错，好好做人籽孙，不作孽。

進化1.0 MVC

人們剛接觸編程火俄，相信第一個遇到的框架就是MVC犯建，不管你經(jīng)意還是不經(jīng)意寫出來的Android程序他就是MVC框架，只不過是MVC框架的某一個變種（最混亂的那種）瓜客。Android系統(tǒng)本身就根據(jù)MVC建造的适瓦。

• XML的View層
• Activity/Fragment的Controller層
• 數(shù)據(jù)Model層。

我們編寫程序剛開始應(yīng)該是這種結(jié)構(gòu)

image.png

View層和Controller交織在一起谱仪。在Activity里面處理各種事件和邏輯玻熙，界面的顯示和更新都在這里，除了按功能分出去的模塊外疯攒，能在Activity里面寫的都會堆在這里面嗦随，代碼常常達到上千行，別說別人敬尺，自己再回到頭看的時候也是頭皮發(fā)發(fā)麻枚尼。
所以我們開始試著學(xué)Android系統(tǒng)的MVC來梳理代碼。當(dāng)然每個人從眾理解的也不大一樣砂吞。
不管是單向依賴還是雙向依賴都是為了把處理的職責(zé)交給Controller署恍，這一點是不變的，所以不管你用的是哪一種形式都是不打緊的呜舒，沒有對與錯锭汛。根據(jù)自己的需求選擇最適合的一種依賴關(guān)系。

image.png

優(yōu)點：

由于MVC很好的分離了視圖層和業(yè)務(wù)層袭蝗，所以它具有以下優(yōu)點

• 耦合性低
• 開發(fā)速度快
• 可維護性高
• 易于理解

缺點：

• 由于MVC的設(shè)計思想是從Model出發(fā)唤殴，而沒有考慮到View端的復(fù)雜性，這樣導(dǎo)致的問題是Model難以符合復(fù)雜多變的View端變化到腥。導(dǎo)致Model的作用很小朵逝，而很多View層的職責(zé)也轉(zhuǎn)移到了Controller層。Controller變得臃腫不堪乡范。耦合性也變高了配名。
• 測試困難

MVC使用的誤區(qū)

其實我在剛開始編程的時候啤咽，

誤區(qū)一：一度認為Model就是實體類（Entity）

正解：是MVC的Model應(yīng)該有兩個功能：

• 處理業(yè)務(wù)邏輯
• 提供View顯示的數(shù)據(jù)

誤區(qū)二：把業(yè)務(wù)邏輯全部放在Controller端

正解：Model也會處理業(yè)務(wù)邏輯

這兩個誤區(qū)其實也和MVC的構(gòu)成有關(guān)系，很容易讓人誤解渠脉，但是本質(zhì)上還是不理解MVC宇整，特別是對Model的作用不明白。
其實Model在MVC框架里面的作用不僅僅是Entry芋膘，Model在MVC中起著很重要的作用鳞青，它更應(yīng)該是業(yè)務(wù)邏輯的真正實現(xiàn)層，而Controller層更應(yīng)該作為一個橋接的作用为朋，把View的求情轉(zhuǎn)發(fā)給Model臂拓，再把Model處理結(jié)束的消息告訴View。這樣做也就是界面和代碼（邏輯）分離习寸。

進化2.0 MVP

但是踏入誤區(qū)的人太多了胶惰，大家都在Activity里面處理邏輯因為太方便了（寫的很爽）。
但是這樣之后霞溪，我們Activity的職責(zé)太多了孵滞，耦合也嚴重，所以我們就想著怎么能給Activity減負威鹿，同時把耦合也降下來剃斧，所以就想找個哥們來替Activity分擔(dān)的責(zé)任，大家最后都只有一個責(zé)任忽你，各層關(guān)系也相對好理解幼东，大家照著這個方式寫，那多好科雳，不用加班根蟹，天天都很快樂。
既然Activty這么愿意和View搞到一起（解耦太高了）糟秘，那么就讓他們倆在一起（在一起简逮，在一起，在一起）尿赚，共同負責(zé)View散庶，我們在招聘一個職業(yè)經(jīng)理人（Presenter）來處理事務(wù)，有啥事都找Presenter凌净，你看著多方便啊悲龟，MVP是一個真正意義上的隔離View的細節(jié)和復(fù)雜性的模式

image.png

至于虛線的部分，這個和樓上的MVC的虛線一樣冰寻，每個人的理解不同须教，情況不同，選擇合適的就好斩芭，不用糾結(jié)誰對對錯轻腺，本質(zhì)不變就可以的乐疆。

這樣就簡單多了，Activity和View兩人各種膩歪秀恩愛贬养，各層的關(guān)系也一目了然挤土，大家各干各的事情，想要什么和Presenter說一聲煤蚌，有啥事情Presenter也會匯報耕挨，簡直爽的不要不要的。Presenter也會處理和View層的交互尉桩，Presenter在手天下我有。

優(yōu)點：

1贪庙、模型與視圖完全分離（就像牛郎和和織女隔了一個銀河蜘犁，每次都需要靠燕子來傳信，好可憐~~）

2止邮、可以更高效地使用模型这橙，因為所有的交互都發(fā)生在一個地方——Presenter內(nèi)部

3、（Presener的復(fù)用）一個Presener可以用于多個視圖（View）导披，而不需要改變Presenter的邏輯屈扎。視圖（View）的變化比模型（Model）的變化更頻繁的多 ，所以這樣超級方便撩匕。

4鹰晨、（View的復(fù)用）View可以進行組件化。在MVP當(dāng)中止毕，View不依賴Model模蜡。這樣就可以讓View從特定的業(yè)務(wù)場景中脫離出來，可以說View可以做到對業(yè)務(wù)邏輯完全無知扁凛。它只需要提供一系列接口提供給上層操作忍疾。這樣就可以做高度可復(fù)用的View組件。

5谨朝、更容易單元測試

缺點：
1卤妒、由于對視圖的渲染放在了Presenter中，所以視圖View和Presenter的交互會過于頻繁字币。特別是需要修改視圖的時候则披，Presenter也需要跟著修改，很麻煩纬朝。

2收叶、Presenter中除了業(yè)務(wù)邏輯以外，還有大量的View->Model共苛，Model->View的手動同步邏輯判没，造成Presenter比較笨重蜓萄，維護起來會比較困難。

3澄峰、其實總的來說就是結(jié)構(gòu)很清晰嫉沽，業(yè)務(wù)邏輯也很明白，耦合低俏竞，但是就是自己寫的麻煩绸硕，Presenter不好維護，工作量太大魂毁，太笨重玻佩，有點像MVC中的Activity了，職責(zé)太多了席楚。也可以把這三個缺點總結(jié)成一句話咬崔，麻煩，尾大不掉烦秩。

進化3.0 MVVM

但是吧垮斯，你們爽了Presenter可就累壞了，大事小事都要經(jīng)過Presenter只祠，就連放個屁也要Presenter來扒褲子兜蠕，日子過得久了，Presenter總會有意見啊抛寝，不帶這么使喚人的熊杨。

我們就想啊，以前過多的依賴Activity造成結(jié)構(gòu)混亂墩剖，耦合太高猴凹，后來有了Presenter，雖然耦合大大降低岭皂，但是還是過于依賴Presenter郊霎，為啥總會過于依賴某一個東西呢，就不能大家都干點活爷绘，耦合性也不高的嗎书劝？就不能大家有事相互通知嗎？非要那么懶依賴別人嗎土至？總要有點正能量吧购对。那么我們就把Presenter辭退，引入了一個新的小伙伴VM（ViewModel即 Model of View）它即包含了Modle也有View的狀態(tài)陶因。

MVVM模式中骡苞，一個ViewModel和一個View匹配，它沒有MVP中的IView接口，而是完全的和View綁定解幽，所有View中的修改變化贴见，都會自動更新到ViewModel中，同時ViewModel的任何變化也會自動同步到View上顯示躲株。

這種自動同步的原因其實就是是ViewModel中的屬性都實現(xiàn)了observable這樣的接口片部，也就是說當(dāng)使用屬性的set的方法，都會同時觸發(fā)屬性修改的事件霜定，使綁定的UI自動刷新档悠。

在android中DataBinding幫助我們實現(xiàn)MVVM，在XML進行數(shù)據(jù)綁定望浩，增加了XML的重量辖所，不再像以前那樣僅僅是布局，均衡了各部分的職責(zé)曾雕。

所以MVVM比MVP更升級一步奴烙，在MVP中，V是接口IView, 解決對于界面UI的耦合; 而MVVM干脆直接使用ViewModel和UI無縫結(jié)合, ViewModel直接就能代表UI.

image.png

優(yōu)點：

1剖张、解決了MVP大量的手動View和Model同步的問題，提供雙向綁定機制揩环。提高了代碼的可維護性搔弄。大大方便了開發(fā)者。（只有試過才知道有多方便）

2丰滑、簡化測試顾犹。

3、響應(yīng)式編程更方便褒墨。

缺點：

1炫刷、過于簡單的圖形界面顯得大材小用（讓開發(fā)者麻煩的都是缺點）

2、視圖狀態(tài)較多郁妈，ViewModel的構(gòu)建和維護的成本都會比較高浑玛。

3、數(shù)據(jù)綁定的聲明是指令式地寫在View的模版當(dāng)中的噩咪，這些內(nèi)容是沒辦法去打斷點debug的顾彰。（這是很碉堡的，只能自己細心了）

進化4.0 CLEAN

進化了一代有一點胃碾，作為東家的谷歌坐不住了涨享，給不給我面子了，來來來仆百，我給你們一個終結(jié)的厕隧，CLean~~~
WTF？這個洋蔥一個的家伙是誰？再給你一個圈就是五環(huán)了~~四個圈圈了不起坝跆帧髓迎？

image.png

官方的話說來就是：

獨立

• 獨立于框架。該體系結(jié)構(gòu)不依賴于某些特征庫軟件庫的存在挡爵。這允許您將此類框架用作工具竖般，而不必將您的系統(tǒng)塞入其有限的約束中。
  可測試茶鹃』恋瘢可以在沒有UI，數(shù)據(jù)庫闭翩，Web服務(wù)器或任何其他外部元素的情況下測試業(yè)務(wù)規(guī)則挣郭。
• 獨立于UI。UI可以輕松更改疗韵，而無需更改系統(tǒng)的其余部分兑障。例如，可以使用控制臺UI替換Web UI蕉汪，而無需更改業(yè)務(wù)規(guī)則流译。
• 獨立于數(shù)據(jù)庫。您可以換掉Oracle或SQL Server者疤，用于Mongo福澡，BigTable，CouchDB或其他東西驹马。您的業(yè)??務(wù)規(guī)則未綁定到數(shù)據(jù)庫革砸。
• 獨立于任何外部機構(gòu)。事實上糯累，您的業(yè)務(wù)規(guī)則根本不了解外部世界算利。

依賴規(guī)則

同心圓代表軟件的不同領(lǐng)域。一般來說泳姐，你走的越遠效拭，軟件就越高。外圈是機制仗岸。內(nèi)圈是政策允耿。
使這種架構(gòu)工作的首要規(guī)則是依賴規(guī)則。此規(guī)則表明源代碼依賴項只能指向內(nèi)部扒怖。內(nèi)圈中沒有任何東西可以對外圈中的某些東西一無所知较锡。特別是，內(nèi)圈中的代碼不得提及在外圈中聲明的內(nèi)容的名稱盗痒。這包括功能蚂蕴，類低散。變量或任何其他命名的軟件實體吞瞪。
外圈中使用的數(shù)據(jù)格式不應(yīng)該被內(nèi)圈使用稽犁，特別是如果這些格式是由外圈中的框架生成的話。我們不希望外圈中的任何東西影響內(nèi)圈素跺。

官方的話就是繞鸟整，其實就是依賴是能向里依賴引镊，白話就是內(nèi)圈向外圈提供服務(wù)，比如你去食堂吃飯篮条，選擇不同的窗口弟头，對著里面喊到給我來一份魚香肉絲。你不用管里面的師傅是不是昨天那一個涉茧，也不用管里面的菜是不是昨天的那個口味赴恨，你只管你的目的是來一份魚香肉絲就可以了，里面的菜和師傅伴栓，也不用管你是誰伦连，是不是個漂亮的MM，他們只管自己事情钳垮，對他們?nèi)ν獾牟灰蕾嚮蟠荆凑阋蕾囄揖涂梢粤恕?/p>

image.png

Clean將核心業(yè)務(wù)（Domain層）、UI相關(guān)（Presenter層）以及數(shù)據(jù)加載（Data層）彼此獨立開來饺窿，不同的層之間由接口依次連接起來汛聚，但卻又彼此不了解彼此的具體實現(xiàn)。

優(yōu)點：

1短荐、代碼復(fù)用性更高
2、更易于測試
3叹哭、耦合度更小

缺點：

1忍宋、學(xué)習(xí)難度大（容易懵逼）
2、代碼量大（一個小Demo都夠你寫一壺了）

從MVC->MVP->MVVM->MVP-Clean 后者解決了前者遺留的問題风罩，把前者的缺點優(yōu)化成了優(yōu)點糠排。一代更比一代強，但是都是需要代價的超升，學(xué)習(xí)成本更高入宦，更加規(guī)范，但是并不一定就誰比誰更好室琢，只有誰更適合你的項目乾闰，都有優(yōu)劣，怎么選擇需要靠自己了盈滴。
其實MVX系列的本質(zhì)一直未變：

• 關(guān)注點分離原則
• 高內(nèi)聚低耦合原則

同時也希望適度設(shè)計涯肩，不要太過追求某一點。會得不償失。找到最經(jīng)濟的方案才是王道病苗，也可以多種方案配合一起配合疗垛。

image.png

如何能夠更好的將多種架構(gòu)表現(xiàn)在一款A(yù)PP里面呢？對硫朦！組件化贷腕。

組件化

image.png

組件化開發(fā)就是將一個app分成多個模塊，每個模塊都是一個組件（Module）咬展，開發(fā)的過程中我們可以讓這些組件相互依賴或者單獨調(diào)試部分組件等泽裳，但是最終發(fā)布的時候是將這些組件合并統(tǒng)一成一個apk，這就是組件化開發(fā)挚赊。
不同的Module我們根據(jù)職責(zé)劃分選擇不同的架構(gòu)诡壁，可以最經(jīng)濟的開發(fā)一款A(yù)PP。

image.png

目前成熟的方案有阿里的ARouter荠割，通過路由的方式進行通信妹卿，感興趣的同學(xué)可以學(xué)習(xí)下。

• 優(yōu)點

1蔑鹦、低耦合
2夺克、可以針對測試（降低測試成本）
3、復(fù)用性強
4嚎朽、支持并行開發(fā)
5铺纽、適合使用多進程
6、減小編譯時間

• 缺點

1哟忍、不適合小型應(yīng)用或者獨立開發(fā)
2狡门、各組件開發(fā)人員聯(lián)調(diào)，開發(fā)進度不一致等問題

• 應(yīng)用場景

假如一個app用戶量很大锅很，業(yè)務(wù)豐富其馏，比如某寶，很明顯不是一個小團隊可以開發(fā)的了的爆安，如果不分模塊的話叛复，工程的復(fù)雜度就太大了，編譯時間估計半天都完不成扔仓，維護更不用說了褐奥，簡直不是人干的了。所以很適合分模塊來開發(fā)翘簇。各個模塊的耦合性也能降到最低撬码，不至于一個模塊有問題，牽連別的模塊缘揪。編譯時間也會大大減小耍群。每個模塊相當(dāng)于一個小APP义桂，更容易靈活的編譯，編寫蹈垢。測試也只需要測試本模塊慷吊，最后聯(lián)調(diào)整體就可以了。所以說業(yè)務(wù)越復(fù)雜曹抬，組件化越有優(yōu)勢溉瓶。

小結(jié)

移動端架構(gòu)的差異化體現(xiàn)在通信機制上。通信機制主要分為3種：
1） 對象持有
2） 接口持有
3） 路由

對象持有最簡單谤民，但是解耦率最低堰酿；
接口持有較為復(fù)雜，實現(xiàn)解耦的需求张足，但是解耦不徹底触创，相互持有交互方的接口。
路由機制可以實現(xiàn)完全解耦为牍，實現(xiàn)組件化

完了嗎哼绑？不不不~~移動端不僅僅Android和ios，還有前端碉咆，上面僅僅是MVX的進化史抖韩，同時還有不同分支的進化。

當(dāng)下移動端的趨勢疫铜，越來越向大前端靠攏了茂浮，Android的道友們也越來越瑟瑟發(fā)抖，看到RN壳咕，F(xiàn)Lutter等等的興起席揽，越來越覺得僅僅學(xué)習(xí)Android是不夠的，還要學(xué)習(xí)跨平臺谓厘，大前端的知識驹尼。
俗話說他山之石可以攻玉，我們對架構(gòu)的思考也是如此庞呕，不能僅限于自己的一畝三分地，也要學(xué)習(xí)下友軍的套路程帕。
這類一般都是響應(yīng)式視圖的系統(tǒng)住练，MVVM就是個響應(yīng)式，所以其實都是有聯(lián)系的愁拭。

進化 5.0 Flutter/ReatNative

• Flutter
  是Google用以幫助開發(fā)者在Ios和Android兩個平臺開發(fā)高質(zhì)量原生應(yīng)用的全新移動UI框架讲逛，也是據(jù)說要把Android替換掉的一個恐怖存在（目前現(xiàn)在還是個弱雞）

• React Native
  讓開發(fā)者使用 JavaScript 和 React 編寫應(yīng)用，利用相同的核心代碼就可以創(chuàng)建 Web岭埠，iOS 和 Android 平臺的原生應(yīng)用盏混。React Native 的宗旨是蔚鸥，學(xué)習(xí)一次，高效編寫跨平臺原生應(yīng)用许赃。

• ReatNative

JS 開發(fā)者可以用類似DOM編程模型就可以開發(fā)原生APP止喷，畫UI只需要畫到virtual DOM 中，不需要特別關(guān)心具體的平臺, RN 會把應(yīng)用的JS代碼編譯成一個js文件混聊，RN的整體框架目標(biāo)就是為了解釋運行這個js 腳本文件弹谁，通過bridge 傳遞到native ， 然后根據(jù)數(shù)據(jù)屬性設(shè)置各個對應(yīng)的真實native的View句喜。

image.png

RN官方給的框架是Flux

image.png

• action 封裝請求
• dispatcher 注冊處理器预愤、分發(fā)請求
• store 是處理器，處理業(yè)務(wù)邏輯咳胃，保存數(shù)據(jù)
• view 根據(jù)store提供的數(shù)據(jù)進行展現(xiàn);接受用戶的輸入并發(fā)出action請求植康。

解耦很細，做一個功能會涉及很多地方展懈，所以人們對于這個官方架構(gòu)進行簡化

Reflux：

Reflux.png

這個三層框架就大大簡化了flux的復(fù)雜交互销睁。
不管是面向?qū)ο筮€是面向狀態(tài)，其實本質(zhì)上是一致的标沪。三層框架能夠很好處理視圖榄攀，數(shù)據(jù)，事件金句，邏輯的問題檩赢。

我們也可以參考另外一種架構(gòu)

Redux：

Redux.png

我們可以看出 其實也是分為三層，組件违寞，Store贞瞒，Action。組件綁定這Action和state趁曼，store reducer都是頁面單例军浆，易于管理。action為請求dto對象挡闰，是請求類型乒融，請求數(shù)據(jù)的載體，reducer是處理請求的方法摄悯。不允許有狀態(tài)赞季，必須是純方法。必須嚴格遵守輸入輸出奢驯，中間不允許有異步調(diào)用申钩。不允許對state直接進行修改，要想修改必須返回新對象瘪阁。

這就是 面向狀態(tài)編程

react的組件只關(guān)注數(shù)據(jù)的最終狀態(tài)撒遣，數(shù)據(jù)是怎么產(chǎn)生的并不關(guān)心邮偎。這個是RN的核心思想。

• 優(yōu)點

1义黎、提升產(chǎn)品迭代速度禾进，APP迭代周期變短
2、減少研發(fā)成本（可不轩缤，ios和android都可以下崗了）
3命迈、提升開發(fā)測試效率（不用雙端兩套代碼分開測試了）

• 缺點

1、原生有些功能實現(xiàn)不了或者說很復(fù)雜
2火的、需要掌握IOS和Android的知識壶愤，個人學(xué)習(xí)成本高
3、需要兼容IOS和Android（很苦逼）

• Flutter

今年谷歌推出了Flutter的Beta版本馏鹤，離正式的出生越來越近了征椒。我們來看看這個新同學(xué)吧。

Flutter主要解決了移動開發(fā)中的兩個重要問題湃累，一是原生應(yīng)用程序的性能與平臺的集成;二是提供多平臺勃救、可移植的UI工具包支持高效應(yīng)用開發(fā)。

和RN的跨平臺思想不同
RN是將一種設(shè)計理念延伸到兩個平臺治力，而Flutter則實現(xiàn)了一套代碼蒙秒，部署多個平臺。解決了RN開發(fā)需要IOS和Android基礎(chǔ)的窘迫和成本宵统。

在Flutter中晕讲，每個應(yīng)用程序都是Widget，這點和其他的應(yīng)用框架不一樣马澈，F(xiàn)lutter的對象模型是統(tǒng)一的瓢省，也就是控件。
Flutter 基本上就是一個 V（View）痊班，響應(yīng)式視圖勤婚，它可以是無狀態(tài)或有狀態(tài)的 widget，就連 AppCompatActivity 也是一個 widget涤伐。是不是很過分馒胆？簡單到粗暴。采用widget 和 state分離 凝果，比如我們在原生里大量重復(fù)代碼來管理 Activity 的生命周期国章。但是在 Flutter 中，這是不需要的豆村，從設(shè)計的角度就解決了這個問題。就像LifeCycles也是這種思想骂删，解決了生命周期的問題掌动。
對于這種面向狀態(tài)編程的思想四啰，架構(gòu)和RN是類似，同時我們也期待Google的官方架構(gòu)指導(dǎo)的出現(xiàn)粗恢，會不會有更多的驚喜呢柑晒？

image.png

• 優(yōu)點

1、響應(yīng)式視圖眷射，不需要JavaScript的橋接器
2匙赞、性能更好，兼容性更好
3妖碉、代碼將AOT編譯為本機(ARM)代碼
4涌庭、美觀，可定制的UI組件欧宜，開發(fā)人員完全控制UI組件和布局
5坐榆、熱重新加載

• 缺點

1、包體很大需要打包自己的SDK
2冗茸、占用內(nèi)存空間大
3席镀、啟動時間很慢
4、流暢性和原生有差距

不過因為FLutter還沒與正式出版夏漱，相信FLutter會解決這些缺點的豪诲。

• RN和Flutter差別：

對于這兩者系統(tǒng)架構(gòu)的區(qū)別 這里有兩張圖：

Flutter.png

ReatNative.png

我們可以看出來 主要差別就是Widgets的差別，還有Bridge中間層的區(qū)別挂绰，F(xiàn)lutter從理論上的速度要別RN高很多屎篱，沒有了中間層的倒轉(zhuǎn)，有自己的Widgets可以保證IOS和android上的統(tǒng)一扮授。
實現(xiàn)跨平臺的這兩種方式也是架構(gòu)設(shè)計的體現(xiàn)芳室，Bridge有沒有和Presenter很相似，連接著js和系統(tǒng)刹勃。
RN是將一種設(shè)計理念延伸到兩個平臺堪侯，而Flutter則實現(xiàn)了一套代碼，部署多個平臺荔仁。
不同的設(shè)計思想伍宦，會走向不同的路，到底是哪一種走的更好乏梁，這個可能就需要隨著時間去檢驗了次洼，雖然理論上FLutter要比RN好很多，但是現(xiàn)在的顯示很殘酷遇骑。不過FLutter才是Beta版本卖毁，潛力非常大。

image.png

寫在最后

本文把目前移動端主流的架構(gòu)順了一遍，也是我自己對架構(gòu)認識的一個時間軸亥啦，從剛開始的胡亂編寫炭剪，到后來有些章法，不過還是對框架的領(lǐng)悟很淺翔脱，肯定有很多謬論錯輪奴拦，希望以我個人對架構(gòu)的思考可以拋磚引玉，如果可以給你一些幫助届吁，那是極好的一件事情了错妖。

不管是RN還是Flutter，亦或是原生的IOS和Android疚沐，其實他們本質(zhì)編程思想是一致暂氯，同樣，隨著更多更方便的框架出來濒旦，我們的理解能力和學(xué)習(xí)能力受到了很大的挑戰(zhàn)株旷，很多同學(xué)都說學(xué)不動，但是事實上技術(shù)的更新?lián)Q代遠比我們學(xué)習(xí)新知識要快尔邓，往往我們剛學(xué)會這個晾剖，又會出了另外一個，我們只要掌握了它的核心思想梯嗽，就不會那么累和無奈了齿尽。

這就是技和道的差別，通過技最終掌握道灯节，而不是以技學(xué)技循头，那樣沒有終點。

我們在實際中如何選擇架構(gòu)炎疆，其實這個的因素很多卡骂，最關(guān)鍵的是一個經(jīng)濟，比如項目時間比較短形入，還是獨立開發(fā)全跨，我們可能就要用MVC了，或者說應(yīng)用的功能相對簡單亿遂，也會取用MVC浓若，至于MVP，或者MVVM蛇数，CLEAN挪钓，這個對于大型開發(fā)，特別是協(xié)作開發(fā)耳舅，有著很大的幫助碌上。因為我們工作不僅僅是技術(shù)，還有項目周期，老板的喜好馏予，歷史遺留問題蔓纠，所以選擇最經(jīng)濟的一個，而不是選擇那個公認最好的那個吗蚌。

移動端的趨勢越來越走向統(tǒng)一了，我們發(fā)現(xiàn)越來越多的公司纯出，需要大前端的人才蚯妇，所以要一直學(xué)習(xí)，創(chuàng)造時代的人都沒有說累暂筝，我們跟著學(xué)習(xí)的人更不應(yīng)該喊累箩言，沒有學(xué)不動，只有不想學(xué)焕襟。同時歡迎大家來剛哥的知識星球陨收，一起激勵，一起砥礪前行鸵赖。

大家可以點個關(guān)注务漩，告訴我大家想要深入探究哪些問題，希望看到哪方面的文章它褪，我可以免費給你寫專題文章饵骨。。哈哈茫打。居触。。
希望大家多多支持老赤。轮洋。你的一個關(guān)注，是我堅持的最大動力抬旺。弊予。

參考：
React Native運行原理解析
https://blog.csdn.net/xiangzhihong8/article/details/52623852
React Native vs. Flutter 評測
https://mp.weixin.qq.com/s/Or28Gf71wuJrCUP0lKGpGg
ReactNative的組件架構(gòu)設(shè)計
http://react-china.org/t/reactnative/3486
為安卓開發(fā)者介紹的移動開發(fā)框架 Flutter
https://blog.csdn.net/Px01Ih8/article/details/79683595
等等