React Native Changed the World? or Nothing.

RN是一個awesome的技術, facebook頗有想法的團隊創造出一項新的技術改變了native開發界. 可是RN自己又疑點重重, RN是爲了解決什麼問題而存在的? 在誕生了一年後, RN又解決了什麼問題? 本文經過分析RN的思想, 試圖透過技術, 理解動態方案.

RN(React Native)是Facebook推出的mobile開發框架, 使用javascript做爲開發的主要語言, 邏輯和樣式的處理由javascript完成, 渲染則使用native渲染, 支持Android和iOS兩個平臺. 對於native開發者, RN經過配置下發可以作到即時生效的上線. 對於web開發者, 可以使用本身熟悉的技術體系作native開發.

一年前, RN推出的時候, 驚豔移動開發業界, 你們都驚呼原來native開發還能這樣作 – 跨平臺, 動態發佈, 簡潔的JSX語法, 各類開發工具和調試工具. 我當時也是RN的狂熱推崇者, 裏面不少思路在當時看來的確是引領了一代創新. 而如今, 在作了一年多native動態性的工做以後, 發現RN的背後問題重重.

問題1 RN是爲了解決什麼問題而存在的?

觀點1 解決跨平臺問題

「React Native enables you to build world-class application experiences on native platforms using a consistent developer experience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms you care about — learn once, write anywhere. Facebook uses React Native in multiple production apps and will continue investing in React Native.」

摘自RN官網, 從這裏咱們能夠看出, 官方是把RN做爲一套跨平臺的技術方案的, learn once, write anywhere, 也就是說RN解決了Android, iOS跨平臺開發的問題. 可是別忘了, web自己就是跨平臺的, HTML, CSS, javascript這些都是universal W3C standards.

觀點2 解決web體驗問題

有人會說, RN是爲了解決web開發者在mobile上的性能體驗問題. 的確, RN經過使用大量native組件作渲染, 優化了WebKit DOM渲染的性能, 經過batch update和專用線程的設計, 下降javascript和native通訊帶來的性能開銷, 保證主線程的流暢執行. RN的組件loadtime的確比web的好, 所以體驗上面, 頁面加載更快, 滑動時候局部留白的時間更短, 對用戶而言體驗效果更好. 但也帶來了不少問題.

一般web的開發是創建在W3C完備標準之上, 不管是瀏覽器中, 仍是app中的webview中, 都遵循W3C的一套標準實現. 也就是說web開發不須要關心具體的瀏覽器是怎樣實現的, 只要按照規範開發, 就能跑在各類各樣的容器上面, 也是在此基礎上, 各類各樣的javascript技術蓬勃發展. 反觀RN, 官方提供了一套javascript API, 可是和W3C相比, 還不成熟完備. 對於web開發很難說把native這層看爲透明的. 或者說, 不改變native徹底使用javascript的開發局限性很大. 極可能某個native組件的性能或者功能不知足現有業務需求, 這時就很尷尬, 須要咱們深刻native的組件. 一旦涉及native組件, 伴隨而來的還有版本和兼容等問題. 做爲開發而言, 須要熟悉web native和RN框架, 這帶來的是開發效率的問題. 但隨着官方不斷吸納標準的組件, 這個問題會逐漸變小, 但站在如今, 這個問題的確存在.

站在這個角度上, 若是web開發者也掌握了native開發的技能或者有app開發的支持, 那爲何不直接作成native app? RN的性能和體驗和native爲主的app仍是有差距的. 這裏總結下來, RN會提高web體驗, 但有必定侷限性, 可能成爲後面業務發展的瓶頸.

觀點3 解決native開發和發佈效率問題

有人又會說, native app不能作動態發佈, 開發效率低, 而RN能夠. 在發佈問題上面, AppStore是嚴禁熱部署動態code的, 所以每次發佈都須要經過AppStore審覈, 而近期AppStore的審覈時間已經縮短到24h之內. Android平臺上面, 須要解決的是更新率的問題, 目前業界一些插件化動態發佈的方案能夠完成動態更新, 如手淘的Atlas, 點評的DynamicAPK.

開發效率上面若是Android和iOS可以用同一套javascript實現, 在熟悉了RN環境後, 的確能夠大幅提高開發效率. 但對於native開發而言, 仍是有必定起步成本, 並且仍是前面提到的瓶頸問題, 依賴現有native組件的完備程度.

問題2 RN如今解決了什麼問題?

按常理講, 推出技術方案大多基於自身遇到的問題. 但RN並無在Facebook的主流產品中使用, 並且使用RN的App也大可能是小衆的App.

相比之下, Facebook的Instant Article更爲搶眼, native端將pageLoad, 交互體驗做爲最終目標, 提升內容體驗. 同時解決內容發佈的幾個問題, 下降發佈門檻, 增長廣告收益, 提供數據分析.

RN技術自己並無什麼問題, 問題是各方面都比較好的方案, 在真實業務場景下反而更難用好.

問題3 RN的尷尬源自哪裏?

最開始看到javascript+native這種技術, 想到的是端遊開發界. 不少端遊開發也是使用lua+遊戲引擎的技術, lua寫邏輯更快, 引擎性能更好. 不一樣的遊戲用多套腳本, 引擎能夠持續複用. 這個很像RN解決問題的思路, 但爲何在RN上行不大通呢?

反覆的思考後, 以爲根源是在mobile這裏. mobile有什麼特色? 用戶時間碎片化, 單任務. 碎片化怎麼理解, 根據友盟+的數據分析報告, 除了主流的資訊, SNS, 遊戲類之外, 一我的使用app次數是分鐘級別的, 而使用次數卻會有10+次. 單任務怎麼理解, 用戶在使用手機的時候更難作app切換, 不會像pc中同時開啓多個任務去作. 這兩個核心的特色決定了, 用戶較難以等待, 更容易流失. 因此pageLoad time是很重要的一個指標, 尤爲是內容型的頁面. 而RN同native相比在pageLoad time上是有很大差距的.

在另外一邊, 相比web, RN性能雖然比web好, 但靈活程度, 成熟程度遠遠不如web技術. 而是有web技術開發的業務通常來講對體驗的要求有必定容忍. 同時還有Google等在作的專一mobile web page性能的Accelerate Web Page這類項目, 這樣RN和web的性能很難拉開大的差距.

這樣RN處在了一個不上不下的尷尬位置.

看清問題, 找到解法.

「再 NB 的想法和假設，真正到了實現層面，也必需要落實到具體的用戶、需求和場景這三要素上面.」

前面一直在說問題, 不是說不承認RN的技術, 只是不想讓你們跟着熱潮去入坑, 而關鍵是要把相關的技術放在一塊兒比較, 看哪一個方案適合本身的業務場景.

舉個例子, 在有強運營需求的基礎功能上, 很是適合用RN來作運營模塊. 由於運營的特性是時效性, 到達率, 而基礎功能又須要保證穩定的體驗. 過去的一年個人團隊都在使用native爲主+動態模塊這種技術, native上提早作好動態模塊的支持, 當營銷活動點到來時, 能夠用RN這種動態技術, 快速響應, 動態上線.

再舉個例子, 像作Instant Article這種內容頁面, 會有大量的內容, 以幾種排版佈局展現. 這類的業務的核心是對內容的承載能力, 體驗. 像這類的業務應該針對業務的現狀和近期發展, 肯定適合業務的方案, 並保持對將來的可擴展性. 若是沒有運營類的需求場景, pure native的實現能夠徹底知足需求, 設計後臺接口時考慮到佈局和組件的擴展性, native上能保證無痛的後續新增和修改佈局, 就能夠了. 簡單的架構也方便後面針對性能瓶頸作持續優化.

總之, 對新技術要保持敏感, 在實際業務的技術選型上仍是要保持警戒, 慎重權衡.