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版本。