React Native是一款很強大的技術工具，用它能開發(fā)出有美感、原生態(tài)的跨平臺應用程序。當下，React Native的應用率持續(xù)上升，尤其受入門級用戶的青睞。

當今針對ReactResearch的研究和文章，多圍繞性能、擴充性以及與同類軟件的對比情況展開論述。本文將介紹7個能將React Native編程效率最大化的竅門：

入手一臺Mac

假如你真的習慣了微軟系統(tǒng)，又認為使用熟練使用的操作系統(tǒng)會更好（我起初也是這么想的），但是個人經(jīng)驗表明，有一條規(guī)則程序員不得不信——那就是，MacOS（蘋果電腦操作系統(tǒng)）無疑是React Native開發(fā)領域里的最合適的系統(tǒng)配置。

主要原因有兩點：

1. 很明顯，MacOS能為用戶構建iOS客戶端應用提供便利。React Native的所有使用教程都默認用戶持有Mac絕非巧合。所以想做跨平臺開發(fā)，早晚都需要一臺Mac。

2. React Native在iOS系統(tǒng)上性能更優(yōu)，運行更穩(wěn)定。React Native本來就是從iOS軟件“發(fā)家”的。不論是模擬器、構建過程、實時加載/熱加載功能還是遠程JS故障排除功能，都能在MacOS上完美運行。在微軟系統(tǒng)上，npm和React Native本身，甚至是微軟的命令行都漏洞百出。

在Mac端開發(fā)React Native至少比在其他系統(tǒng)上的快兩倍。所以，想贏在起跑線上，就要確保是（或即將成為）macOS用戶。

入手更高配置的Mac

React Native是那種能夠充分利用資源，并從中獲益的技術軟件。它的工作流可以讓至多三四個不同的iOS/安卓仿真器同時運行。

配置越高，性能越好——能夠實時觀測用戶的應用程序是否在所有目標平臺上正常運行，不僅貼心，還為開發(fā)者節(jié)省了大量時間。不用再擔心“解決一個平臺上的問題，卻給其他平臺引入新的漏洞”的意外發(fā)生。

另外，IDE上的每一次CTRL+ S 保存操作都會重建體系，這將最小化構建應用和編碼驗收之間的等待的時間，讓一天之內(nèi)重復成百上千次的工序耗時大大減少，時間因此得到有效利用。

還有，沒有比即刻看到程序的實施效果更令人滿意的事了。

從老版Mac mini到2018年新版MacBook，工作效率提高了約50%。所以，盡量購買最高配置的Mac。

讓IDE成為幫手

每一個IDE都自帶某種格式特征，或許有人會覺得這就足夠了。但當今的IDE已經(jīng)變得更為智能，讓格式特征成為其冰山一角。

縮進代碼、清除變量、整理輸入、轉換引用等其他操作能使用戶的程序變得整齊劃一——這些操作都可以用IDE實現(xiàn)，且應該用IDE實現(xiàn)！直到記不起最近一次按下tab鍵是什么時候。

Echobind網(wǎng)站上有一篇關于“如何把Prettier+Eslint+airbnb規(guī)則合并成VS代碼”的優(yōu)質文章。

傳送門：https://blog.echobind.com/integrating-prettier-eslint-airbnb-style-guide-in-vscode-47f07b5d7d6a

這篇文章的建議會縮短用戶開發(fā)耗時，提高成果滿意度。

把所有程序都編成代碼段

盡量遵循DRY原則。編程的時候，你是否總是手動輸入<View></View>或者<Text></Text>？不如把它們轉化為代碼段！

不要就此止步——也許你還想應用剛設計出來的一種全新風格的視圖，為何不動手嘗試呢？

以上步驟可以看作對編寫的代碼“應用壓縮算法”。識別出重復的操作，并用“標識符”（代碼段）代替。歸納用戶的編程習慣，根據(jù)個人習慣生成用戶自己的項目索引。

別讓IDE妨礙編程。學習如何簡便高效地使用IDE，就不會浪費以上步驟節(jié)省下來的時間。

另外，編寫三字節(jié)程序和列表生成是成為編程大神的必備技能。

窗口加倍，速度加倍？

倒不一定……但開啟雙窗口多少有用。

總是在兩個文件之間來回操作的用戶，一定要養(yǎng)成拆分窗口的習慣。

也許兩個窗口剛開始會顯得有些力不從心，但是，拆分窗口，特別是在重要編程環(huán)節(jié)中拆分窗口，是提高編程效率的基礎和核心。

熟悉快捷鍵和習慣使用快捷鍵還差很遠。因此，需要找到并組合適合自己的IDE命令。

對本文作者來說，恰好滿足了個人（VS碼編寫）需求的命令是：

workbench.action.focusSecondEditorGroup

它解決了打開新標簽頁帶來的麻煩，用單個按鍵組合（CTRL+ 2），既移動了文件夾，也讓標簽頁更集中。

比如說，創(chuàng)建UI（用戶界面）的同時在屏幕上顯示標記和樣式，既省時又省力。

合理使用熱加載

談到代碼更改預覽，React Native的熱加載技術就是最“頂尖”的運行內(nèi)容之一。

但以上論斷的前提是用戶會使用熱加載功能。目前，ReactNative反饋條目中有超過130項熱門評價是關于熱加載問題的，充分證據(jù)表明，熱加載十分脆弱。

熱加載崩潰的原因常常難以偵測，但我注意到大多時候，熱加載崩潰的根源，不在代碼自身的“毛病”，而在于代碼不能和熱加載兼容。

舉個例子，經(jīng)過幾個小時的故障排除，將以下代碼格式：

componentDidMount = async() => {} 

更改為

async componentDidMount() {} 

能讓熱加載重新運轉起來。

當然，熱加載不運行不一定是箭頭函數(shù)的問題；不同的編碼基數(shù)存在不同的問題。但讓熱加載持續(xù)運行的技巧在于，密切關注是哪一類代碼導致它出現(xiàn)故障，并重構錯誤代碼。最常用的重構方法就是簡化代碼形式。

用戶需要耗費必要的時間讓熱加載重新運轉。熱加載能幫助用戶更快地構建UI，并且，我將在下文具體說明，熱加載也是排除UI和商業(yè)邏輯故障的重要工具。

巧妙利用熱加載

從Web過渡到React Native時，系統(tǒng)布局是為用戶詬病的主要問題——其原因多在于，React Native的界面缺乏合理（或者是說有用）的“檢驗”UI，不能使用戶從視覺上檢驗各要素的尺寸、形態(tài)和邊界。

熱加載除了提供更快、更高效的開發(fā)流程之外，還是一種實用的要素檢驗工具。

它的檢驗效果如下。

將熱加載和快捷代碼段組合之后，能在一秒鐘內(nèi)滿足用戶的所有需求，且不需重建IDE。

做一個可以生成紅色邊框的bred代碼段，就能夠將其運用于任何要素。按下CMD+ S就能通過屏幕看到彈出的要素。用戶還可以根據(jù)個人喜好，調整或增強要素風格。這看起來簡單又局限的操作，實際上能節(jié)省10%的操作時間。

使用這種方法之后，再也不需要打開檢測彈窗和菜單，不用擔心它們會打斷你的工作流，從此實現(xiàn)隨時隨地清除故障。

使用熱加載的又一實用竅門是，用戶能夠在現(xiàn)有的開發(fā)框架上檢測所有的變量數(shù)值。比如這個例子：

幾周前，本文作者做成了這個“玩家數(shù)據(jù)”界面，這里本應顯示玩家的數(shù)據(jù)，但由于某一個代碼自上周起就出了問題，于是需要找出問題在哪里。

代碼如下：

<View> 
 {stats.map(stat => 
 <Stat {...stat} /> 
 )} 
</View> 
... 
export const Stat= ({ value = '-', name }) => ... 
import seaborn as sb 

在截屏中，數(shù)據(jù)欄的數(shù)值總是“-”。這意味著stat變量的結構不太對，需要檢查。

在React Native里，一種故障檢測的方法是啟動遠程故障排查功能，去掉Chrome界面的標簽頁（否則RN就會影響那些后臺標簽頁），打開dev工具，打開當前文件夾，在render功能前的return那里設置一個斷點，重新加載應用，把應用導航至前面的斷點界面，祈禱不要有源映射錯誤，然后再檢查接收數(shù)據(jù)。

如果先載入stats變量，進行屏幕導航，再檢查載入數(shù)據(jù)會更簡便一些。

熱加載技術可以將故障排除推進一步：

<View> 
 {stats.map(stat => 
 <Stat 
dog={console.log(stat)} {...stat} /> 
 )} 
</View> 

基于render方程的本質，每次調用它時，每一個要素屬性都會被評估，并以組件的形式返回。

然而，在本文的討論的中，“以評估組件的形式返回”這一部分不是很重要，只需要關注“被評估”這一部分。

對純隨機、非顯性的屬性調用console.log(stat)命令（這里具體指代“dog”——我覺得有用的熱點序列），然后保存以啟動熱加載，它就會評估整個render方程，其中包括dog屬性。

最后得出如上數(shù)據(jù)，無需重啟，無需檢測程序，更不需要連接遠程故障排查；這種方法就能立即反饋需求數(shù)據(jù)。

當然，也不難發(fā)現(xiàn)，其實需要展開的是stat.content而不是stat，因為數(shù)據(jù)嵌套在content之下。

在任何時候，使用熱加載都能幫助用戶極速解決編程故障！