喵神談：跨平臺開發時代的 (再次) 到來
這篇文章主要想談談最近又刮起的移動開發跨平臺之風，并著重介紹和對比一下像是 Xamarin，NativeScript 和 React Native 之類的東西。不會有特別深入的技術討論，大家可以當作一篇科普類的文章來看。
故事的開始
“一次編碼，處處運行” 永遠是程序員們的理想鄉。二十年前 Java 正是舉著這面大旗登場，擊敗了眾多競爭對手。但是時至今日，事實已經證明了 Java 笨重的體型和緩慢的發展顯然已經很難再抓住這個時代快速躍動的腳步。在新時代的移動大潮下，一個應用想要取勝，***的使用體驗可以說必不可少。使用 native 的方式固然對提升用戶體驗很有幫助，但是移動的現狀是必須針對不同平臺 (至少是 iOS 和 Android) 進行開發。這對于開發來說妥妥的是隱患和額外的負擔：我們不僅需要在不同的項目間努力用不同的語言實現同樣代碼的同步，還要承擔由此帶來的后續維護任務。如果僅只限制在 iOS 和 Android 的話還行，但是如果還要繼續向 Windows Phone 等平臺拓展的話，所需要付出的代價和工數將幾何級增長，這顯然是難以接受的。于是，一個其實一直斷斷續續被提及但是從沒有占據過統治地位的概念又一次走進了移動開發者們的視野，那就是跨平臺開發。
本地 HTML 和 JavaScript
因為每個平臺都有瀏覽器，也都有 WebView 控件，所以我們可以使用 HTML，CSS 和 JavaScript 來將 web 的內容和體驗搬到本地。通過這樣做我們可以將邏輯和 UI 渲染部分都統一，以減少開發和維護成本。這種方式開發的 app 一般被稱為 Hybrid app，像 PhoneGap 或者 Cordova 這樣的解決方案就是典型的應用。除了使用前端開發的一套技巧來構建頁面和交互以外，一般這類框架還會提供一些訪問設備的接口，比如相機和 GPS 等。
雖然使用全網頁的開發策略和環境可以帶來代碼維護的便利，但是這種方式是有致命弱點的，那就是緩慢的渲染速度和難以駕馭的動畫效果。這兩者對于用戶體驗是致命而且難以接受的。隨著三年前 Facebook 使用 native 代碼重新構建 Facebook 的手機 app 這一標志性事件的發生，曾經一度占領半壁江山的網頁套殼的 app 的發展也日漸式微。特別在現在對于用戶體驗的追求幾近苛刻的現在，呆板的動畫效果和生硬的交互體驗已經完全無法滿足人民群眾對高質量 app 的心理預期了。
跨平臺之心不死的我們該怎么辦
想要解決用戶體驗的問題，基本還是需要回到 native 來進行開發，但是這種行為必然會與平臺綁定。世界上總是有聰明人的，并且他們總會利用看起來更加聰明但是實際上卻很笨的電腦來做那些很笨的事情 (恰得其所)。其中一件事情就是自動將某個平臺的代碼轉換到另外的平臺上去。有一家英國的小公司正在做這樣的事情，MyAppConverter 想做的事情就是把 iOS 的代碼自動轉成 Java 的。但是很可惜，如果你嘗試過的話，就知道他們的產品暫時還處于無法實用的狀態。
在這條路的另一個分叉上有一家公司走得更遠，它叫做 Apportable。他們在游戲的轉換上已經取得了很大的成果，像是 Kingdom Rush 或者 Mega Run 這樣的大作都使用了這家的服務將游戲從 iOS 轉換到 Android，并且非常成功?？梢院敛豢鋸埖卣f，Apportable 是除開直接使用像 Unity 或者 Cocos2d-x 以外的另一套誘人的游戲跨平臺解決方案?；旧夏憧梢允褂?Objective-C 或者 Swift 來在熟悉的平臺上開發，而不必去觸碰像是 C++ 這樣的怪獸 (雖然其實在游戲開發中也不會碰到很難的 C++)。
但是好消息終結于游戲開發了，因為游戲在不同平臺上體驗不會差別很大，也很少用到不同平臺的不同特性，所以處理起來相對容易。當我們想開發一個非游戲的 app 時，事情就要復雜得多。雖然 Apportable 有一個計劃讓 app 轉換也能可行，但是估計還需要一段時間我們才能看到它的推出。
新的希望
其實跨平臺開發***的問題還是針對不同的平臺 UI 和體驗的不同。如果忽視掉這個最困難的問題，只是共用邏輯部分的代碼的話，問題一下子就簡單不少。十多年前，當 .NET 剛剛被公布，大家對新時代的開發充滿期待的同時，一群喜歡搗鼓的 Hacker 就在盤算要如何將 .NET 和 C# 搬到 Linux 上去。而這就是 Mono 的起源。Mono 通過在其他平臺上實現和 Windows 平臺下功能相同的 Common Language Runtime 來運行 .NET 中間代碼。現在 Mono 社區已經足夠強大，并且不僅僅支持 Linux 平臺，對移動設備也同樣支持。Mono 背后的支撐企業 Xamarin 也順理成章并適時地推出了一整套的移動跨平臺解決方案。
Xamarin 的思路相對簡單，那就是使用 C# 來完成所有平臺共用的，和平臺無關的 app 邏輯部分；然后由于各個平臺的 UI 和交互不同，使用預先由 Xamarin 封裝好的 C# API 來訪問和操控 native 的控件，進行分別針對不同平臺的 UI 開發。
雖然只有邏輯部分實現了真正的跨平臺，而表現層已然需要分別開發，但這確實也是一種在完整照顧用戶體驗的基礎上的好方式 -- 至少開發語言得到了統一。因為 Xamarin 解決方案中的純 C# 環境和有深厚的 .NET 技術背景做支撐，這個項目現在也受到了微軟的支持和重視。
不過存在的致命問題是針對某個特定平臺你所能使用的 API 是由 Xamarin 所決定的。也就是說一旦 iOS 或者 Android 平臺推出了新的 SDK，加入了新的功能，你必須要等 Xamarin 的工程師先進行封裝，然后才能在自己的項目中使用。這種延遲往往可能是致命的，因為現在 AppStore 對于新功能的首頁推薦往往只會有新系統上線后的一兩周，錯過這段時間的話，可能你的 app 就再無翻身之日。而且如果你想使用一些第三方框架的話，將不得不自己動手將它們打包成二進制，并且寫 binding 為它們提供 C# 的封裝，除非已經有別人幫你做過這件事情了。
另外，因為 UI 部分還是各自為戰，所以不同的代碼庫依然存在于項目之中，這對工作量的減少的幫助有限，并且之后的維護中還是存在無法同步和版本差異的隱患。但是總體來說，Xamarin 是一個很不錯的解決跨平臺開發的思路了。(如果拋開價格因素的話)
#p#
NativeScript
NativeScript 是一家名叫 Telerik 的名不見經傳保加利亞公司剛剛宣布的項目。雖然 Telerik 并不是很出名，但是卻已經在 hybrid app 和跨平臺開發這條路上走了很久。
JavaScript 因為廣泛的群眾基礎和易學易用的語言特點，已經大有一統天下的趨勢。而現在主流移動平臺也都有強勁的處理 JavaScript 的能力 (iOS 7 以后的 JavaScriptCore 以及 Android 自帶的 V8 JavaScript Engine)，因為使用 JavaScript 來跨平臺水到渠成地成為了一個可選項。
在此要吐槽一下，JavaScript 真的是一家公司，一個項目拯救回來的語言。V8 之前誰能想到 JavaScript 能有今日...
NativeScript 的思路就是使用移動平臺的 JavaScript 引擎來進行跨平臺開發。邏輯部分自然無需多說，關鍵在于如何使用平臺特性，JavaScript 要怎樣才能調用 native 的東西呢。NativeScript 給出的答案是通過反射得到所有平臺 API，預編譯它們，然后將這些 API 注入到 JavaScript 運行環境，接下來在 Javascript 調用后攔截這個調用，并運行 native 代碼。
在此不打算展開說 NativeScript 詳細的原理，如果你對它感興趣，不妨去看看 Telerik 的員工的寫的這篇博客以及發布時的 Keynote。
這么做***的好處是你可以任意使用***的平臺 API 以及各種第三方庫。通過對元數據的反射和注入，NativeScript 的 JavaScript 運行環境總能找到它們，觸發相應的調用以及最終訪問到 iOS 或者 Android 的平臺代碼。***版本的平臺 SDK 或者第三方庫的內容總是可以被獲取和使用，而不需要有什么限制。
舉個簡單的例子，比如創建一個文件，為 iOS 開發的話，可以直接在 JavaScript 里寫這樣的代碼：
- var fileManager = NSFileManager.defaultManager();
- fileManager.createFileAtPathContentsAttributes( path );
而對應的 Android 版本也許是：
- new java.io.File( path );
你不需要擔心 NSFileManager 或者 java.io 這類東西的存在，而是可以任意地使用它們！
如果僅只是這樣的話，使用上還是非常不便。NativeScript 借助類似 node 的一套包管理系統，用 modules 對這些不同平臺的代碼進行了統一的封裝。比如上面的代碼，可以統一使用下面的形式替換：
- var fs = require( "file-system" );
- var file = new fs.File( path );
寫過 node 的同學肯定對這樣的形式很熟悉了，這里的 file-system 就是 NativeScript 進行的統一平臺的封裝?，F在的完整的封裝列表可以參見這個 repo。因為寫法很簡單，所以開發者如果有需要的話，也可以創建自己的封裝，甚至使用 npm 來發布和共享 (當然也有獲取別人寫的封裝)。因為依賴于已有的成熟包管理系統，所以可以認為擴展性是有保證的。
對于 UI 的處理，NativeScript 選擇了使用類似 Android 的 XML 的方式進行布局，然后用 CSS 來控制控件的樣式。這是一種很有趣的想法，雖然 UI 的布局靈活性上無法與針對不同平臺的 native 布局相比，但是其實和傳統的 Android 布局已經很接近。舉個布局文件的例子就可見一斑：
- <Page loaded="onPageLoaded">
- <GridLayout rows="auto, *">
- <StackLayout orientation="horizontal" row="0">
- <TextField width="200" text="{{ task }}" hint="Enter a task" id="task" />
- <Button text="Add" tap="add"></Button>
- </StackLayout>
- <ListView items="{{ tasks }}" row="1">
- <ListView.itemTemplate>
- <Label text="{{ name }}" />
- </ListView.itemTemplate>
- </ListView>
- </GridLayout>
- </Page>
熟悉 Android 或者 Window Phone 開發的讀者可能會感到找到了組織。你可能已經注意到，相比于 Android 的布局方式，NativeScript 天生支持 MVVM 和 data binding，這在開發中會十分方便 (但是性能上暫時就未知了)。而像是 Button 或者 ListView 這樣的控件都是由 modules 映射到對應平臺的系統標準控件。這些控件的話都是使用 css 來指定樣式的，這與傳統的網頁開發沒太大區別。
nativescript-ui
NativeScript 代表的思路是使用大量 web 開發的技巧來進行 app 開發。這是一個很值得期待的方向，相信也會受到很多前端開發者的歡迎 -- 因為工具鏈和語言都非常熟悉。但是這個方向依然面臨的***挑戰還是 UI，現在看來開發者是被限制在預先定義好的 UI 控件中的，而不能像傳統 Hybrid app 那樣使用 HTML5 的元素。這使得如何能開發出高度自定義的 UI 和交互成為問題。另一個可能存在的問題是最終 app 的尺寸。因為我們需要將整個元數據注入到運行環境中，也存在很多在不同語言中的編譯，所以不可避免地會造成較大的 app 尺寸。***一個挑戰是對于像 app 這樣的工程，沒有類型檢查和編譯器的幫助，開發起來難度會比較大。另外在調試的時候也可能會有傳統 app 開發中不曾遇到的問題。
總體來看，NativeScript 是很有希望的一個方案。如果它能實現自己的愿景，那必將是跨平臺這塊大蛋糕的有力競爭者。當然，現在 NativeScript 還太年輕，也還有很多問題。不妨多給這個項目一點時間，看看正式版本上線后的表現。
React Native
Facebook 幾個月前公布了 React Native，而今天這個項目終于在萬眾期待下發布了。
React Native 在一定程度上和 NativeScript 的概念類似：都是使用 JavaScript 和 native UI 來實現 app (所以說 JavaScript 真是有一桶漿糊的趨勢..如果你現在還不會寫幾句 JavaScript 的話，建議盡早學一學)。但是它們的出發點略有不同，React Native 在首頁上就寫明了，使用這個庫可以：
- learn once, write anywhere
而并不是 "run anywhere"。所以說 React Native 想要達成的目標其實并不是一個跨平臺 app 開發方案，而是讓你能夠使用相似的方法和同樣的語言來在不同平臺進行開發的工具。另外，React Native 的主要工作是構建響應式的 View，其長處在于根據應用所處的狀態來決定 View 的表現狀態。而對于其他一些系統平臺的 API 來說，就顯得比較無力。而正是由于這些要素，使得 React Native 確實不是一個跨平臺的好選擇。
那為什么我們還要在這篇以 “跨平臺” 為主題的文章里談及 React Native 呢？
因為雖然 Facebook 不是以跨平臺為出發點，但是卻不可能阻止工程師想要這么來使用它。從原理上來說，React Native 繼承了 React.js 的虛擬 DOM 的思想，只不過這次變成了虛擬 View。事實上這個框架提供了一組 native 實現的 view (在 iOS 平臺上是 RCT 開頭的一系列類)。我們在寫 JavaScript (更準確地說，對于 React Native，我們寫的是帶有 XML 的 JavaScript：JSX) 時，通過將虛擬 View 添加并綁定到注冊的模塊中，在 native 側用 JavaScript 運行環境 (對于 iOS 來說也就是 JavaScriptCore) 執行編譯并注入好的 JavaScript 代碼，獲取其對 UI 的調用，將其截取并橋接到 native 代碼中進行對應部件的渲染。而在布局方面，依然是通過 CSS 來實現的。
這里整個過程和思路與 NativeScript 有相似之處，但是在與 native 橋接的時候采取的策略完全相反。React Native 是將 native 側作為渲染的后端，去提供統一的 JavaScript 側所需要的 View 的實體。NativeScript 基本算反其道行之，是在 JavaScript 里寫分開的中間層來分別對應不同平臺。
對于非 View 的處理，對于 iOS，React Native 提供了 RCTBridgeModule 協議，我們可以通過在 native 側實現這個協議來提供 JavaScript 中的訪問可能。另外，回調和事件發送等也可以通過相應的 native 代碼來完成。
總結來說，如果想要把 React Native 作為一個跨平臺方案來看的話 (實際上也并不應當如此)，那么單靠 JavaScript 一側是難以完成的，因為一款有意義的 app 不太可能完全不借助平臺 API 的力量。但是畢竟這個項目背后是 Facebook，如果 Facebook 想要通過自己的影響力自立一派的話，必定會通過不斷改進和工具鏈的完善，將 app 開發的風向引導至自己旗下。對于原來就使用 React.js 的開發者來說，這個框架降低了他們進入 app 開發的門檻。但是對于已經在做 native app 開發的人來說，是否值得和需要投入精力進行學習，還需要觀察 Facebook 接下來動作。
不過現在 React Native 的正式發布才過去了不到 24 小時，我想我們有的是時間來思考和檢閱這樣一個框架。
總結
當然還有一些其他方案，比如 Titanium 等?，F在使用跨平臺方案開發 app 的案例并不算很多，但是無論在項目管理還是維護上，跨平臺始終是一種誘惑。它們都解決了一些 Hybrid app 的遺留問題，但是它們又都有一些非 native app 的普遍面臨的陰影。誰能找到一個好的方式來解決像是自定義 UI，API 擴展性以及 app 尺寸這樣的問題，誰就將能在這個市場中取得領先或者勝利，從而引導之后的開發潮流。
但是誰又知道***誰能取勝呢？也有可能大家在跨平臺的道路上再一次全體失敗。伺機而動也許是現在開發者們很好的選擇，不過我的建議是提前學點兒 JavaScript 總是不會出錯的。
