使用React Native一年後的感覺

轉載自；http://www.dobest.me/blog/2016/06/12/%E4%BD%BF%E7%94%A8React%20Native%E4%B8%80%E5%B9%B4%E5%90%8E%E7%9A%84%E6%84%9F%E5%8F%97/

 

當我在面試Discord的時候，技術主管Stanislav跟我說：

React Native表明着將來。等它一發布，咱們就會用它從零構建iOS應用。

做爲一名原生iOS開發者，基於先前使用PhoneGap的經驗，我很是懷疑使用Web技術構建移動應用的這種方式。可是當我學習並使用React Native一段時間以後，我很是慶幸咱們作了這個決定。

開發效率

雖然iOS「團隊」只有我本身一我的，可是iOS應用開發依然能夠遇上Web和桌面應用開發閃電般的速度。Apple公司已經容許開發者使用JavaScriptCore進行應用的升級，而無需等待App Store的審覈流程。這對於那些缺少專業的iOS QA（質量保障）團隊的小公司來講是很是便利的，由於iOS團隊能夠在發佈新功能以後進行熱更新。

使用React Native一年以後，咱們的iOS開發週期明顯變快了，這得益於很高的開發效率。好比：

• 基於現有的前端架構，咱們在兩週以內就發佈了V1.0的版本。

• 相比於Auto Layout，基於Flexbox的樣式能夠節省一半的代碼，而且更容易理解。

• 使用Flux設計模式，iOS和Web應用共享了store和action的98%的代碼。

性能

React Native在後臺線程運行JavaScript併發送極小的代碼到主線程中。事實證實，React Native相比於Objective-C或Swift編寫的原生iOS應用來講有一些性能差別！

Reactiflux小組的性能演示，該組有超過1.1萬個會員 —— UI和JS線程大多數都是60FPS

然而，咱們當初開始構建iOS應用時發現聊天滾動視圖的性能並不使人滿意，尤爲是一些活躍的聊天分組。因而，咱們決定使用ComponentKit構建聊天視圖並編寫必要的橋接代碼代替原有的方案。當JS線程在完成一些繁重任務的時候，類庫也沒法提供原生那樣流暢的動畫（譯註：以前動畫是在JS線程執行，目前有人提交了一份代碼，有望使用原生iOS動畫接口），所以咱們在抽屜側滑動畫上繼續使用PopAnimation。

注： 做者稱該應用僅聊天視圖和抽屜動畫是原生代碼實現的，其餘均由React Native實現。

當React Native Android版本發佈時，咱們也嘗試在Android設備上運行應用，但遺憾的是，咱們遇到了一些性能問題，只好暫時放棄。Android開發主管Miguel是這樣說的：

很遺憾，不一樣Android設備的性能差別很大，這點明顯落後於iOS。咱們可讓應用運行地很快，可是性能——尤爲是觸摸事件，即便在更高端設備上也不能使人滿意。而且在早期，因爲React Native Android缺少完善的功能，咱們從產品原型過渡到成品應用比iOS花費了更多時間。

可用性

React Native讓開發工做更簡潔，使得開發者能夠專一於每一個新版本核心功能的開發。應用內自帶的開發者菜單爲我節省了大量的時間。

其中我最喜歡的一個功能是Show Inspector（審查工具），它能夠即時展示交互視圖的層級結構以及被選組件中全部必要的樣式信息，這無疑是我用過的最棒的iOS審查工具。

社區

React Native項目每兩週會發佈一個新版本，其中包含一些新的特性以及修復的bug。這有利有弊，比如iOS幾個月的穩定版本的發佈，新的代碼須要額外的時間進行升級，尤爲是生產環境中的應用。所以，這也是到目前爲止咱們fork的React Native倉庫只有四次主要升級的緣由。

因爲React Native還不太成熟，資源有限，也不完整。但隨着它愈來愈流行，在不久以後必定能遇上其餘成熟的技術。下面列出了一些實用的資源，我也常常在它的倉庫上提問和獲取最新的信息：

• Reactiflux上的#react-native。

• js.coach—React Native開源組件列表。

• awesome-react-native—大量的React Native文章、教程和示例。

譯註：中文資源：React Native學習指南

總的來講，React Native頗有潛力，它把咱們團隊的移動應用開發帶上了一個新的臺階。像我這樣原生的iOS開發者能夠平滑地過渡到React Native，這有些出乎個人意料。同時，它也幫助我擴展職業技能，由於我也能夠很輕鬆地向React編寫的Web應用貢獻代碼了。