React Native 開源一周年回顧
React Native 的一周年回顧
自從我們開源 React Native 已經有一年的時間了。這個最早僅僅是一小撮工程師『異想天開』的項目現在已經作為應用開發框架被廣泛使用在 非死book 的產品團隊甚至其他公司中。在今天的 F8 大會上，我們宣布了微軟正在把 React Native 技術帶到Windows的生態系統這消息，讓開發者可以在 Windows PC，Phone，Xbox 上構建 RN 的應用，同時也提供了開源工具和服務（譬如Visual Studio Code的RN擴展和CodePush相關的RN服務）來幫助開發者在 Windows 平臺構建 RN 應用。同時，三星正在用 RN 技術構建它的混合應用平臺，來輔助三星的開發者在數以百萬級的SmartTV，手機和可穿戴設備上開發應用。我們非死book 也發布了 RN 的 非死book 開發者套件，使得開發者更加容易集成 非死book 的社交特性(例如登錄，分享，應用分析和 Graph API 等功能)到他們的應用中。就這一年，React Native 顯著的改變開發者在主流手機客戶端上開發應用的方式。
史詩般的旅程不是嗎，不過我們才剛剛開始。接下來我們往回看自從開源后這一年，RN 是如何一步步流行和不斷完善的，看這一路來我們面對的挑戰，并且我們是怎么看待 RN 未來的發展的。
React Native 開始的緣由
作為非死book 黑客文化的精髓，React Native 于2013年也是作為編程馬拉松 hackathon 的項目開始。類似于 React，React Native一開始也是看起來很大膽的異類想法。一開始我們并不確定這是否能行。譬如 JS 和原生滾動間的交互怎么做，性能怎么樣，如調試等。不過這些挑戰都沒有阻止我們的工程師進一步的推進這個項目。
當我們把這個想法做出原型后，我意識到這個項目在 非死book 中可能會大有用途。在幾年前，我們從Web H5 開發轉變到目前的原生客戶端開發上。不過，每次修改代碼都需要漫長的重新編譯，開發不同的客戶端（iOS、Android）需要不同的配套技能等都讓我們頭疼，這些都導致了產品開發的進展緩慢。React Native 這樣的構想就能把之前我們熱衷的Web開發的一些優點借鑒到原生應用開發上，譬如足夠快的開發迭代速度，只需要精簡的 JS 工程團隊就能交付整個移動端產品。
所以，我們開始在這個項目繼續投資時間和精力。我們也知道證明一項新技術是否真的有效好用就是用它來嘗試解決生產環境下的復雜問題。所以我們決定做 FB 的消息流主頁的原型，這就是我們用 RN 開發的第一個產品項目，同時也在不斷豐富優化 RN 這個基礎框架本身。這些代碼最后成為現在 FB 群組應用代碼的基礎部分。
在2014年7月，還在 RN 上持續下功夫的我們小群團隊第一次接了一項大活：廣告管理大師團隊希望構建單獨的 iOS 應用，但是他們沒有直接的iOS工程師也沒相關的開發經驗。這是個非常不錯的機會，接下來幾個月廣告管理大師的產品團隊和 RN 工程團隊緊密工作相互配合。產品工程師不斷挑戰提升著RN平臺的功能和性能邊界。我們的目標就是要發布一款用戶體驗不差于 Objective-C 構建的 iOS 應用。
在對此任務非常有信心實現后，我們決定盡早讓 RN 能夠跨平臺，在倫敦組建了 RN 的 Android 團隊。這團隊在14年下半年開始寫了最早的 Android 核心運行時和第一個組件。此后我們決定要讓 Android 能順利運行之前的 iOS 廣告管理大師的JS代碼。到2014年底，我們有個最基礎版本，盡管它還缺了不少的界面，在低端Android手機上性能也不行，不過你還是可以看到如下圖展示的一列廣告和可以用它來創建新的廣告。我們當時非常自信能把這項工作推進下去，獲得更棒的性能，更強大的功能。
?
非死book的廣告管理大師運行在Android低端機上。2015/01
FB 廣告管理大師這款應用在2015年2月在iOS在蘋果 AppStore 發布，離我們正式在全職搞 RN 不過才6個月。同時，關注 JS 或 iOS 的同事開始考慮開源這套 iOS RN的實現。在2015年1月的 React.js 開發者大會，我們發布了初次的公開預覽版。在2015年3月的 F8 開發者大會，我們正式開源所有代碼~
在此之后，廣告管理大師的工程團隊開始把他們的 JavaScript 代碼移植到 Android 應用上。和倫敦的RN團隊緊密配合，一開始我們并沒寄希望能在這兩個平臺很復用很多代碼（我們只是把它當做 RN 方案的加分點），不過當 Android 版的廣告管理大師準備發布上線后，我們驚喜發現這兩個應用的85%的代碼都是可共用的。
在2015年的6月，經過三個月的開發和一個月左右的內部 dogfooding 使用，第一個 Android 版本的廣告管理大師發布了，考慮到 RN 的 iOS 部分大受歡迎的情況，我們立即開始把工作重心轉移到開源 RN 的 Android 部分。我們對此熱情高漲。畢竟，需要給不同平臺構建同一款應用是業界都有的大難題，我們從開發廣告管理大師項目的經驗來看，RN 正是解決這樣難題的好方案。
類似于 iOS 部分的發布，我們希望 Android 部分也能盡早發布，從而盡快獲得反饋。因此，我們從核心運行時開始，加上一小部分的視圖和模塊（如文本，圖片，ScrollView，Network，AsyncStorage等）的支持。在9月14號，我們把 Android 核心運行時和初始部分的 Android 模塊發布到 Github 和 npm 上。在 React Native 的0.11版本上，我們第一次發布了 Android 部分的支持。從開源 Android 部分后，我們也陸續加入這些模塊的支持：Alert，APPState，CameraRoll，Clipboard，Date和time pickers，Geolocation，Intent，Modal，NetInfo，Pull to refresh view，Picker，Slider，View pager，WebView等（它們和 iOS 部分的 API 非常類似）
?
從最早 React Native 設想，到我們開源 RN的 Android 部分的時間軸
不得不說，在開源后，外界對 RN 的接受程度和熱情讓我們 RN 團隊感到非常驚喜。
快速迭代：這一年的學習和成長
React Native 的流行程度和它的開發者社區都在快速發展，遠超我們的預期。
超過650個人給 RN 的代碼倉庫貢獻過代碼。在代碼倉庫的5800個提交，有30%左右都是被不在 FB 工作的貢獻者提交的。在2016年2月，第一次超過50%的代碼提交來源于這些外部貢獻者。隨著這么多來著于社區對RN的貢獻，我們發現每個月都將近266新的 PR（每天多大10個PR）被要求合入。這些 PR 很多都是高質量的，提供著后續被廣泛使用的功能特性。
?
這是RN的Github代碼倉庫每個月被提交PR數量趨勢圖
在一開始，這些暴漲的 PR 數量導致我們很難快速高效的審核合入。每天為這些 PR 找到合適的審核人員都消耗著很多人力成本。為了解決這個問題，我們通過開發兩個 Github 機器人來自動化分發 PR 到合適的reviewer頭上~
第一個機器人是提醒機器人，為每個PR找出合適的 Reviewer 審核人。 
?
這個提醒機器人現在被開源了，他的確幫助了我們在一天中更高效的審核這些PR。有趣的是：在上個月（2月份）超過50%的提交來自于社區，提醒機器人總能在社區中找到合適的reviewer來審核（工作原理大概是通過在 Github issues 中定位到提出的人，和 PR 要解決的 issues 關聯起來）
很難Merge這些PR是我們遇到的第二個難題。FB 工程師們用的同一個代碼倉庫（就想你在 Github React Native Repo 上看到的一樣），我沒有對這個做任何 fork 沒有其他的內部 commit 之類的。因此，每次要合入 PR 的代碼到我們內部的大型叫做 fbsource 的Mercurial 倉庫后我們都會自動執行測試腳本來回歸我們類似于 非死book Ads Manager（廣告管理大師？）等應用功能。
?
簡化版的單例Mercurial代碼倉庫fbsource。這個倉庫包含所有的移動端和服務端端代碼
之前合入一個 PR 涉及多個手動操作。我們現在把這些簡化為僅僅需要在 Github 回復一句評論。
?
感謝這些工具，我們這個項目才能和這么多社區持續貢獻的 PR 保持上同一進度。在過去一年，我們總共關閉了2351個 PR！！
?
Github的RN項目上每個月被關閉的PR數量趨勢圖
管理 Github issues
隨著項目的流行，我們要構建和引導一種機制環境：讓社區中有心的人來幫忙一起管理日益增多的 issues。
我們實施了另外一個機器人來使得社區中的任何人都能來幫助管理 Github issues。它可以讓任何人（無需push權限）都可以關閉重復的 issues，回答后關閉 issues，給 issues 添加標簽等等。你可以參考這篇指南參與進來 guide to managing Github issues
?
React Native 涉及的 API 面非常廣泛。它暴露了構建 iOS 和 Android 應用的絕大部分 JavaScript 調用，同時提供了跨平臺的抽象。很難有一個對這些所有APIs都很熟悉的人，即使 FB 中有很多產品團隊在使用 RN，我們還是不能保證覆蓋到所有的邊緣情況。RN 適合我們，但是我們不能保證它絕對完美。這就是需要社區中了解這些代碼倉庫的人參與進來，這對于我們和更寬泛社區的其他人（那些把自己的應用押寶在 RN 上，在 RN 上構建自己的服務，為 RN 開發第三方類庫工具的）都非常重要。
社區貢獻者
React Native 開源貢獻者組織是由社區中那些提供非常高質量的代碼補丁，非常積極幫助其他遇到使用問題用戶的人構成的。我們創建這個組織感謝他們為RN項目的推進表示感謝，也給我們代碼倉庫的提交權限。
下面是我們 RN 開源貢獻者組織的大合照，依次是這些人： 省略
?
開源貢獻者組織的不少人，在2016/02/22的舊金山的React.js Conf開發者大會的合照
React Native 時至今日
每兩周RN就會有新的發布。意味著在主分支中發布后，你就能在你的應用中立即使用上這些功能特性。僅僅在2016年3月，RN 的代碼在 NPM 上的下載次數就達到7w次。在 Github 有著近3w的加星，RN 是 Github 上最受關注的21項目之一。
?
在過去一年，RN在Github的代碼倉庫的加星數從0到30000之多
社區中的成績
自從 iOS 版的 RN 發布后的這一年，有非常多用RN開發的應用被上架到蘋果的AppStore，高質量的RN寫的的Android應用也慢慢出現了。在 展示頁面 羅列了107個用 RN 構建的優秀應用，通過提交 PR 把你的 RN 應用也加入其中。
?
我們嘗試使用這些，發現了不少被精細打磨的RN應用。所以確保你也下載一些來試一試，看看 React Native 能用來干什么。
- Townske 這個城市指南應用就曾經在AppStore的最優秀新應用板塊欄目被推薦。
- Discovery VR 讓你探索瀏覽Discovery頻道的360度視頻。這是第一個用RN構建的VR應用。
- Running 是顏值爆表的運動跟蹤應用。它也是最早一批擁有優秀設計的RN應用之一。
這樣高質量的RN還有很多，在這里就不一一陳訴了。去 showcase展示頁 去一探究竟吧。
除了這些應用外，現在還有不少輔助RN或構建于RN之上的服務：Exponent 讓你無需編譯任何東西就能開發和分享 RN 應用。React Native Playground 讓你在瀏覽器中編輯和運行RN應用。AppHub和微軟的CodePush讓你避開應用市場快速部署新代碼。 JS.coach 提供著索引大量第三方模塊的數據庫，Deco 是用于構建 React Native 的 IDE 集成開發環境。
隨之還有快速發展的第三方模塊的生態，你可以很方便的把這些功能/插件集成到你的應用中。借助于JS.coach，這些模塊非常容易查找。借助于 rnpm 安裝他們也變得非常容易。
網上現在也有非常多的關于 RN 的優秀技術博客和入門提升的教程。感謝社區，繼續保持！我們在這里特別推薦下 Brent Vatne的 React Native Newsletter ，它提供了對 RN 社區發生的所有好玩有趣值得關注的事的不錯的概述，同時提供了不少指向優秀 RN 技術博客的鏈接。
對了，我們現在還有三本關于 RN 的書籍呢~
所有的這些都是在這一年誕生的，成果不少！
非死book中的成績
非死book 中越來越多的產品團隊用 RN 來開發新功能和應用。它即被應用在其他業務的單例App中也被集成在大非死book的iOS/Android App中。
?
非死book群組應用就是個混合應用，消息流就是用RN實現的
在去年，RN團隊中的工程師人數從過去的10名快速增長到20名，成員分布在加州的Menlo Park， 倫敦和紐約。自從 Ads Manager（廣告管理大師）發布RN后，RN 團隊的主要聚焦在：
- 提供諸如在應用啟動時間，響應性和滾動流暢等性能問題上。來看看我們的博客 翻譯：看非死book是如何優化React Native性能 ，和我們在此性能問題上的 計劃安排
- 在大非死book App的iOS和Android平臺上，把 RN 集成到目前的視圖界面UI和基礎架構中
- 構建諸如CPU和內存 profilers等性能調優工具
- 開發非死book產品團隊提出的功能和特性
- 支持使用RN的產品團隊，解決他們的難題，快速為他們解決bug
- 提升開發體驗，譬如整合到內部的開發者工具和構建系統中
展望 React Native
這個項目在去年發展很快取得了長足的進展，不過就像我們在非死book內部說的『我們才完成了1/100的進度』！我們內部會持續大力開發RN項目。在去年，我們團隊規模擴大了一倍。我們也會繼續在開源工具鏈上投入。我們希望 React Native 項目在公司內外都能取得成功~
下面是大家可以參與到這個項目中的一些我們推薦的方式：
- 如果你發現了Bug，那么幫忙提交Fix吧。小的帶有測試規劃的PR（注：Github中給開源項目貢獻代碼的方式）是最快最容易被審核后合入的
- 如果你覺得文檔中有不清晰的地方，請通過PR來改善它
- 在 StackOverflow 上提問關于你有疑問的
- 在 Github Issues 回答和提供方案來幫助 RN 使用者
- 如果你提議一個新特性，那么最好把它提交到 Product Plans 中，它有個投票系統。即使你沒有時間去實現它也沒關系，如果被支持的高會有其他的開發者來幫忙實現。
- 參與到非死book上的 RN 社區群組 來
如果你剛開始接觸 RN，那我推薦你看看我們為RN設計的一系列的教程來介紹這個框架和它的開源生態圈。就拿今年的F8應用作為例子，我們展示了我們在開發時是如何為多平臺做設計的，如何整合數據，通過測試應用來提高代碼質量等。
感謝每一位用 React Native 技術來開發他們優秀應用的開發者，感謝那些在 RN 之上構建工具和服務，開發開源第三方模塊，幫助回答問題，提交PR，幫忙組織會議分享，給RN寫技術博客等社區中的每一位成員。 繼續保持吧！
讓我們期待來年的 RN 的大發展吧~
來自： http://qianduan.guru/2016/04/21/react-native-year-review/