在瀏覽器構(gòu)建的 web 中開發(fā)者可能不用花費太多精力關(guān)注圖像上，但是在移動應(yīng)用中，對于圖像的關(guān)注顯得非常重要。因為在 RN 應(yīng)用中，無論是圖片還是動圖，或者是視頻都是非常耗內(nèi)存的，內(nèi)存的暴漲就很容易造成應(yīng)用的崩潰。
一 前言
在構(gòu)建高性能 React Native 跨端應(yīng)用—引擎與渲染章節(jié)中，我們從引擎與渲染角度介紹了 React Native 的優(yōu)化手段，本文我們繼續(xù)從圖片和內(nèi)存角度繼續(xù)討論一下如何構(gòu)建高性能的 React Native 應(yīng)用。
二 圖像層面
在瀏覽器構(gòu)建的 web 中開發(fā)者可能不用花費太多精力關(guān)注圖像上，但是在移動應(yīng)用中，對于圖像的關(guān)注顯得非常重要。因為在 RN 應(yīng)用中，無論是圖片還是動圖，或者是視頻都是非常耗內(nèi)存的，內(nèi)存的暴漲就很容易造成應(yīng)用的崩潰。
圖片合理應(yīng)用
圖片的處理，占 RN 性能優(yōu)化的大頭，在現(xiàn)在的移動端應(yīng)用中，有很多應(yīng)用大量圖片的場景，加載圖片的過程實際是很復(fù)雜的，并且圖片本身的大小，也不是最后加載到內(nèi)存中的大小，也就是說最后落實在內(nèi)存里面的大小，會大于圖片本身的大小。
圖片的處理在不同平臺上表現(xiàn)也不一致，在 IOS 平臺上對于圖像的加載，加密，到最后的展現(xiàn)，表現(xiàn)還算比較好。但是在Android/ target=_blank class=infotextkey>安卓平臺，就時常會出現(xiàn)幺蛾子。
筆者在開發(fā) RN 應(yīng)用中，就遇到了這樣的場景：我們 RN 只運行在安卓端，一個 RN 頁面會加載大量的圖片，剛開始我們沒有對圖片進行任何處理，只是圖片的寬度和高度是寫死的，那么造成的現(xiàn)象是，所有的圖片都展現(xiàn)不出來，并且圖片是黑的，接下來就是安卓程序直接崩潰。
后來經(jīng)過排查我們發(fā)現(xiàn)，原來我們給圖片的容器特別小，但是圖片資源卻非常大，由于為了在小容器中呈現(xiàn)大的圖片，就比如說一個 100 * 100 圖片容器，加載一個 1000 * 1000 圖片，安卓底層需要對圖片源數(shù)據(jù)進行算法壓縮，此時就會讓內(nèi)存暴漲，幀率直接降為個位數(shù)，導(dǎo)致黑屏，閃退的情況。筆者還把這種小容器加載大圖片的情況，叫做小馬拉大車。
那么如何解決這個問題呢？ RN 中的 Image 組件有個 resizeMethod 屬性，就是解決 Android 圖片內(nèi)存暴漲的問題。當(dāng)圖片實際尺寸和容器樣式尺寸不一致時，決定以怎樣的策略來調(diào)整圖片的尺寸。
<Image resizeMethod="resize" source={{ uri: imageUrl }} />
resizeMethod 屬性有三個可選的值，默認(rèn)為 auto .
resize：小容器加載大圖的場景就應(yīng)該用這個屬性。原理是在圖片解碼之前，會用算法對其在內(nèi)存中的數(shù)據(jù)進行修改，一般圖片大小大概會縮減為原圖的 1/8。 scale：不改變圖片字節(jié)大小，通過縮放來修改圖片寬高。因為有硬件加速，所以加載速度會更快一些。
auto：使用啟發(fā)式算法來在resize和scale中自動決定，，如果是本地圖片，就會用 resize，其他的一般都是 scale 屬性，由于項目運用的是網(wǎng)絡(luò)圖片，所以就按照 scale 處理邏輯。
實際最佳的方案就是，適當(dāng)?shù)拇笮〉膱D片容器，加載適當(dāng)?shù)膱D片。但是對于一些圖片資源的大小是未知的，我們不能直接通過設(shè)置寬和高的方式草率的設(shè)置圖片容器大小，解決方案就是可以通過 api 的方式獲取遠(yuǎn)程圖片的大小。如下：
import { Image } from 'react-native'
/* 使用 */
Image.getSize(imageUrl,(width,height)=>{
console.log('寬度：',width,'高度：',height)
})
當(dāng)然客戶端也可以把圖片壓縮的操作交給服務(wù)端去做，目前很多大公司都有自己的內(nèi)建圖床和 CDN 服務(wù)，會提供一些自定制圖片的功能，在請求圖片資源的時候，就把圖片的寬和高拼接到 url 中，這樣服務(wù)器接受到圖片請求，會根據(jù)路徑獲取 width 和 height，然后自行的對圖片進行壓縮。返回給客戶端的就已經(jīng)是處理好的能夠適配圖片容器大小的圖片了。
圖片管理優(yōu)化
上面介紹了圖片的合理使用，接下來我們看一下圖片的管理優(yōu)化，在 RN 中有多種多樣的類型的圖片，比如 png/jpg/base64/gif ，對于 gif 在安卓 build.gradle 中需要添加相關(guān)依賴。對于一些動圖的處理，比如 svg 和 svga ，RN 也提供了相關(guān)的生態(tài)去處理這些圖像。
對圖片的管理可以通過不同的場景，運用更為合理的方案。比如對于一些大量 gif 圖片的場景，內(nèi)存就是一個棘手問題，圖片的管理工具就需要均衡好內(nèi)存緩存和磁盤緩存的策略，一般都會采用三級緩存策略。
對于一些網(wǎng)絡(luò)加載的圖片，在一些網(wǎng)絡(luò)差或者特殊網(wǎng)絡(luò)的情況下，可以出現(xiàn)加載慢，丟包的現(xiàn)象，這樣就會導(dǎo)致圖片一致加載失敗。慶幸的是，還有專門的圖片管理庫來來解決這個問題。那就是 react-native-fast-image。
react-native-fast-image 這個庫比較受歡迎的，它對圖片的加載和內(nèi)存優(yōu)化上都有著不錯的表現(xiàn)。這個庫在 iOS 和安卓平臺上，底層用原理也各不相同。
三 內(nèi)存層面
清除資源
對于清楚資源，談不上具體的主流優(yōu)化手段，確切的說，應(yīng)該是一個值得關(guān)注的細(xì)節(jié)。
比如當(dāng) A 頁面中有視頻播放的模塊，而 B 頁面是 A 的二級頁面，在融合模式下，進入 A 頁面之后會開始播放視頻流，但是當(dāng)從 A 頁面進入到 B 頁面之后，本質(zhì)上 A 頁面并沒有被回收，但是這個時候，還在加載著視頻資源。那么這樣下去，會讓內(nèi)存越來越大。
那么如何解決這個問題呢？ 當(dāng) A 跳轉(zhuǎn)到 B 頁面之后，應(yīng)該停止 A 頁面加載資源，或者清空視頻資源，讓內(nèi)存維護一個健康的水平。
對于一些超多 gif 圖片的頁面，并還有列表加載功能，這樣在向下加載數(shù)據(jù)的過程中，會渲染更多的 gif 組件，這樣就會讓內(nèi)存越來越大，并且不容易下來，或者一些低端的機型，根本無法渲染太多的 gif 圖片，那么此時應(yīng)該如何解決呢？
這個時候可以做一個優(yōu)化，就是只有在視圖范圍內(nèi)的元素才渲染真正的 gif 圖片，而其他看不見的直接渲染圖片或者是占位圖。如下所示：
圖片
WechatIMG2339.png
清除狀態(tài)
對于一些全局的狀態(tài)，比如存在 Redux 中的數(shù)據(jù)源，或者是全局綁定的監(jiān)聽事件，setTimeout 延時器
四 總結(jié)
本文從圖像與內(nèi)存兩個方面介紹了 RN 優(yōu)化手段，希望這篇文章的能給 React Native 開發(fā)同學(xué)一個性能優(yōu)化上啟發(fā)。
參考
- React Native 性能優(yōu)化指南
- 大前端跨端開發(fā)指南
