React Native 雖然強(qiáng)調(diào)自己不是 “Write once, run anywhere” 的框架，但是它至少能像 Google 的 j2objc 那樣，在 Model 層實(shí)現(xiàn)復(fù)用。那些底層的、與界面無(wú)關(guān)的邏輯，相信 React Native 也可以實(shí)現(xiàn)復(fù)用。這樣，雖然 UI 層的工作還是需要做 iOS 和 Android 兩個(gè)平臺(tái)，但如果抽象得好，Logic 和 Model 層的復(fù)用不但可以讓代碼復(fù)用，更可能實(shí)現(xiàn)底層的邏輯的單元測(cè)試。這樣移動(dòng)端的代碼質(zhì)量將更加可靠。
其實(shí) React Native 宣傳的 “Learning once, write anywhere” 本身也是一種復(fù)用的思想。大家厭煩了各種各樣的編程語(yǔ)言，如果有一種語(yǔ)言真的能夠統(tǒng)一移動(dòng)開(kāi)發(fā)領(lǐng)域，對(duì)于所有人都是好事。
UI 排版的問(wèn)題
我自己一直不喜歡蘋(píng)果新推出的 AutoLayout 那套解決方案，其實(shí) HTML 和 CSS 在界面布局和呈現(xiàn)上深耕多年，Android 也是借鑒的 HTML 的那套方案，蘋(píng)果完全可以也走這套方案的。但是蘋(píng)果選擇發(fā)明了一個(gè) Constraint 的東西來(lái)實(shí)現(xiàn)排版。在企業(yè)的開(kāi)發(fā)中，其實(shí)大家很少使用 Xib 的，而手寫(xiě) Constraint 其實(shí)是非常痛苦的。所以出現(xiàn)了 Masonry 一類(lèi)的開(kāi)源框架來(lái)解決這類(lèi)同行的痛苦。
我一直在尋找使用類(lèi)似 HTML + CSS 的排版，但是使用原生控件渲染的框架。其實(shí)之前 BeeFramework 就做了這方面的事情。所以我還專(zhuān)門(mén)代表 InfoQ 對(duì)他進(jìn)行過(guò)采訪。BeeFramework 雖然開(kāi)源多年，而且有 2000 多的 star 數(shù)，但是受限于它自身的影響力以及框架的復(fù)雜性，一直沒(méi)有很大的成功。至少我不知道有什么大的公司采用。
這次 Facebook 的 React Native 做的事情相比 BeeFramework 更加激進(jìn)。它不但采用了類(lèi)似 HTML + CSS 的排版，還把語(yǔ)言也換成了 JavaScript，這下子改變可以稱(chēng)作巨大了。但是 Facebook 有它作為全球互聯(lián)網(wǎng)企業(yè)的光環(huán)，相信會(huì)有不少開(kāi)發(fā)者跟進(jìn)采用 React Native。
不過(guò)也說(shuō)回來(lái)，F(xiàn)acebook 開(kāi)源的也不一定都好，比如 three20 就被 Facebook 放棄了，但是不可否認(rèn) three20 作為一個(gè)框架，在那個(gè)時(shí)期的特定價(jià)值。所以 React Native 即使沒(méi)有成功，它也將人們關(guān)注的焦點(diǎn)放在了移動(dòng)開(kāi)發(fā)的效率上了。很可能會(huì)有越來(lái)越多相關(guān)的框架因此涌現(xiàn)出來(lái)。
MVVM
MVVM 在 Web 開(kāi)發(fā)領(lǐng)域相當(dāng)火熱，而 iOS 領(lǐng)域的 ReactiveCocoa 雖然很火，但是還是非常小眾。糾其原因，一方面是 ReactiveCocoa 帶來(lái)的編程習(xí)慣上的改變實(shí)在太大，ReactiveCocoa 和 MVVM 的學(xué)習(xí)成本還是很高。另一方面是 ReactiveCocoa 在代碼可讀性、可維護(hù)性和協(xié)作上不太友好。