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上能保證無痛的後續新增和修改布局, 就可以了. 簡單的架構也方便後面針對效能瓶頸做持續最佳化.

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

React Native Changed the World? or Nothing.