【天贏金創】Facebook:咱們是如何構建第一個跨平臺的React Native APP

今年早些時候，咱們介紹過iOS版的React Native. React Native帶來的是用web方式的React - 自聲明式的UI組件和快速的開發迭代來完成手機平臺的功能，而後爲了保持速度、保真性、並達到原生的體驗。今天咱們很高興發佈React Native的Anroid版本.

在Facebook咱們已經應用React Native在發佈的產品有超過一年的時間了。幾乎是整整一年以前，咱們的團隊開始規劃開發廣告管理APP。咱們的部門是建立一個新的APP來讓數百萬的Facebook廣告主來管理他們的帳號並能建立新的廣告。在完成的時候,這不只僅是FB的第一個全React Native APP並且是第一個跨平臺的APP.在這篇文章裏，咱們但願能和你分享咱們是如何構建這個APP,React Native是如何讓咱們更快的，還有這個過程當中咱們的經驗。

選擇React Native

不久前，React Native仍是一項新的技術，尚未被一款正式的產品應用過。而且開發這樣一個新的APP會有很大的挑戰，它超過了潛在的好處。

首先，咱們初始的團隊裏有三個產品工程師已經對React很熟悉。另外，這個APP須要處理大量複雜的商業邏輯和精確的處理不一樣的廣告格式、時區、日期格式、貨幣、匯率等等諸如此類。而大部分已經用JavaScript來實現了。所有用Objective-C編碼並稍後用java實現Android版本的想法也並無被同意，並且也並不高效。第三，用React Native將會很容易來實現大部分的UI，能夠實現帶數據的列表、表格、圖表。產品工程師能夠很快的實現這些效果，用React就能夠了。

固然，一些特性的實現存在着挑戰 - 好比，圖片的編輯，用來讓廣告主縮放和剪切圖片；地圖視圖，用來讓廣告主設定地理範圍。另一個是麪包屑導航，幫助廣告主來可視化的知道本身的層級位置。這些都提供機會讓咱們來推進這個平臺的發展。

首先實現廣告工具的iOS版本

咱們的團隊以爲首先開發iOS版本，也是爲了和React Native的iOS版本校準一致。咱們從後面的幾個月時間裏從3個增長到8個工程師。新加入的成員對React並不熟悉 - 其中也並不熟悉JavsScript - 可是他們都渴望構建一個偉大的手機應用來服務廣告主，而且他們成長的很是快。

有經驗React Native的iOS工程師幫助咱們實現一些他們並無在React Native中實現的特性，像提供訪問相冊。他們也幫助咱們和其它FB已經存在的APP在使用的iOS庫作關聯，像認證、分析、崩潰報告、網絡和推送提醒。這讓咱們的團隊能夠關注在產品上。

除了上面提到的，咱們可使用之前就寫好的JavaScript類庫。像Relay,一個經過GraphQL來傳遞數據到React應用的FB框架.另外的一系列庫用來處理國際化和本地化，它能很聰明的實現時區和貨幣的調用。這些庫的加載是在一個JSON的配置文件裏，包括APP用到的iOS的本地關聯文件，僅僅暴露不多的native代碼。這讓咱們的庫幾乎不須要修改就能使用。

咱們遇到的最大的挑戰就是導航。爲了導航廣告主的廣告和活動，咱們想使用麪包屑導航條。指引廣告的建立流程，咱們須要一個導向式的導航條。在最上面，很是重要的是須要使用合適的動畫和手勢操做，不然這個APP看起來仍是像一個通過美化的website.

咱們的解決方案是使用導航組件，是一個用React Native來實現的可定製化的組件。本質上，它是一個追蹤一系列React組件的組件。它能夠在組件之間基於按鈕點擊和按下時進行動畫切換。它也具備可插拔式的導航組件，讓咱們來實現iOS風格的導航視圖，以麪包屑的方式來導航廣告和活動，指引建立流程的步驟。這個導航條組件還能獲取到動畫的進度以及根據須要來調整動畫的頻率。這意味這全部動畫，包括視圖和導航條均可以經過JS來處理，並且測試的結果是仍然可以達到60fps.

只有一種狀況下動畫纔會卡頓，就是當JS線程被一個大的操做佔用時。當咱們遇到這種狀況時，基本上都是執行大量的數據獲取操做形成的。必然的，當導航到新頁面時須要加載大量的數據。當網絡足夠快是，動畫能夠很容易的被執行。咱們的解決方案是延遲數據的獲取直到動畫執行完畢，這時就使用到了InteractionManager組件，一樣是React Native的一部分。咱們首先動畫到一個新的視圖，而後再用Relay來執行數據加載進程，這樣就能自動的讓須要的React組件實現自動渲染了。

開發Android版本

當iOS版本的廣告管理工具接近開發完成時，咱們開始着手Android版本的APP.移植React Native的Android是最好的方式來完成這個工做。幸運的是，React Native團隊已經在上面作了不少的工做。天然的，咱們想盡量的複用更多的代碼，由於大部分的視圖都很類似。固然，也有一些地方須要作Android個性化處理來和iOS版本有所區別，好比，導航的元素或者是調用本地的UI元素像日期選擇、開關等等。

幸運的是，React Native包的黑名單特性和React的抽象結構幫助咱們最大化的重用代碼來實現跨平臺的功能。在iOS版本里，咱們打包的時候忽略全部後綴名爲.android.js的文件。對Android的開發，忽略掉全部後綴名爲.ios.js的文件。如今咱們能夠實現一樣的組件來同時應用Android和iOS，也能夠個性化的編碼在不一樣平臺。替換掉 if/else 這種方式來判斷平臺，咱們嘗試重構每一個平臺的特定UI，這樣就能夠有Android和iOS的不一樣實現。在構建Android版本的過程當中，大約85%的代碼能夠被複用。

另一個挑戰是怎麼管理源代碼的問題。Android和iOS的代碼庫在Facebook兩個不一樣倉庫。廣告管理工具的iOS源代碼在iOS倉庫，Android版本的代碼在Android的代碼庫。舉例來講，像iOS版本的代碼，咱們想用一些Facebook的Android的依賴庫，這些庫卻在Android的代碼庫存放。另外，Android的APP全部的編譯工具，自動化，以及引入的其它插件都在Android的倉庫。基於上面，Android的這些app要求重構這些已經存在的iOS代碼來抽象具體平臺的組件來調用各自的文件。咱們是能夠直接合並兩個版本的代碼到一塊兒。可是這種方式倒是咱們不能接受的。

最後，咱們決定指定iOS庫爲事實上的源代碼庫，由於iOS版本已經相對穩定。咱們設定了定時任務許屢次一天來同步iOS的JavaScript到Android的代碼庫。咱們不鼓勵在Android版本提交JavaScript代碼，若是提交也是在iOS版本同步的提交一份。若是同步代碼發現代碼有差別，會記錄一個任務用來進行後續的檢查。

咱們讓iOS倉庫的JavaScropt打包成能夠在Android版本上運行的代碼。這樣咱們的產品開發人員就能夠接觸到儘量多的JavaScript代碼而沒有原生代碼，也能夠直接在iOS倉庫直接修改和調試兩個版本的代碼。可是若是要構建Android的APP仍是須要在Android倉庫來執行，一樣的操做也會在iOS APP - 測試兩個平臺的不一樣須要大量的額外工做。爲了提升JavaScript開發者的工做流程，咱們一樣構建了腳原本下載合適的來自整合服務器的原生文件。對於大部分開發者來講就不須要複製一份Android的代碼庫了 - 他們就能夠在iOS代碼庫開發完整的JavaScript代碼，而且能比在Facebook的web流程中更快速的進行迭代。

咱們學到的

React Native團隊開發的進程和咱們的APP一塊兒，而且和他們一塊兒調試本地化組件和API。這些組件將會爲每一個構建APP的人帶來幫助。儘管咱們必須本身來構建一些組件，用React Native代替純原生的方式仍然是有價值的。咱們不得不須要寫這些組件，雖然在將來的一段時間裏也可能不會被其它團隊再次使用。

學到的另一課是在分開的iOS和Android代碼倉庫工做是一件困難的事情，儘管使用了大量的工具和自動化。在構建APP的過程當中，Facebook用過這樣的模式，咱們全部構建的自動化和開發進程都創建並圍繞着它。然而，對於產品來講，用一份共享的JavaScript代碼庫，這種方式並很差。幸運的是，Facebook已經對全部平臺都統一了代碼庫 - 只須要一份JavaScript的拷貝，同步那樣的方式已經成爲了過去。

另外學到的是關於測試。當作了修改，每個工程師必定要在全部平臺仔細測試，這個過程很容易出現人爲的錯誤。可是開發一個跨平臺的APP並且是用一套代碼，這些是必須的。即使如此，因爲測試不足致使的成本，遠大於用React Native開發的成本和能重用跨平臺代碼的成本。請記住，這裏說的不只僅是產品工程師；一樣包括React Native平臺的Objective-C和Java工程師.他們的工做不是限制在原生語言。一樣包括JavaScript - 舉例來講，組件API和部分分享部分的實現。ISO工程師通常來講沒必要必定要測試修改後的Android的代碼，對應Android工程師也是同樣。這種文化缺陷須要咱們用時間和努力來消除，隨着時間的推移，咱們會愈來愈穩定。

在每次修改整合版本的時候咱們也會標記問題。這些標記的東東能夠獲取iOS版本的問題，一樣的對Android也適用，咱們連續的整合版本不會在iOS修改的時候來運行Android的測試，反過來也同樣。這樣工程師就能夠更多精力來解決問題，而且不用常常的來重啓APP.

隨着上面說的和作的，咱們的債算還完了 - 咱們能夠運行Facebook的第一個徹底的React Native APP在兩個平臺上，具備原生體驗，一樣的JavaeScript工程師團隊。他們當中有些還並不熟悉React, 可是他們在5個月以後就開發出了具備原生體驗的iOS版本，以後三個月，咱們又發佈了Android版本。