2018 年 10 月 10 日的這天，我們的團隊發(fā)布了一個新版本的 React Native 應(yīng)用程序豁护。我們很高興又為我們的用戶交付了新功能哼凯。
但是，恐怖的事情發(fā)生了楚里！
發(fā)布幾個小時后断部，我們突然收到很多 Android 崩潰事件。
Android 版本上發(fā)生了 10000 次崩潰
我們的崩潰報告工具Sentry像著火了一樣!
所有的新錯誤都是類似“JSApplicationIllegalArgumentException Error while updating property ‘left’ in shadow node of type: RCTView”這樣的班缎。
在 React Native 中蝴光，如果你使用錯誤的類型設(shè)置屬性，通常會發(fā)生這種情況吝梅。但是虱疏，為什么我們在測試應(yīng)用程序時沒有發(fā)現(xiàn)這個錯誤？我們的新版本已經(jīng)在多個設(shè)備上測試過了苏携。
此外做瞪，錯誤似乎是隨機的，似乎在遇到屬性和陰影節(jié)點類型的組合時會發(fā)生這個錯誤。以下是其中的 3 個錯誤：
根據(jù) Sentry 的報告装蓬，這些錯誤似乎在任意設(shè)備和任意 Android 版本上都會發(fā)生著拭。
大多數(shù)Android 8.0.0崩潰但這與我們的用戶群一致
讓我們來重現(xiàn)錯誤
修復(fù)錯誤的第一步是重現(xiàn)錯誤。所幸的是牍帚，因為有 Sentry 日志儡遮，我們知道用戶在觸發(fā)崩潰之前正在做什么。
絕大多數(shù)的崩潰都是發(fā)生在用戶打開應(yīng)用程序的時候暗赶。
現(xiàn)在我們也嘗試重現(xiàn)一下鄙币。我們在 6 臺不同的 Android 設(shè)備上安裝從應(yīng)用商店下載的 App，可惜的是蹂随，并沒有發(fā)生崩潰十嘿！而且，在開發(fā)模式下就更不可能在本地重現(xiàn)這個錯誤了岳锁。
看來這樣做似乎毫無意義绩衷。無論如何，崩潰似乎是隨機發(fā)生的激率。發(fā)生崩潰的概率約為 10％咳燕，也就是說，基本上啟動 App10 次會有一次發(fā)生崩潰乒躺。
分析堆棧跟蹤信息
為了能夠重現(xiàn)崩潰招盲，我們試著去了解問題出在哪里。
好吧聪蘸，如前所述宪肖，我們遇到了幾個不一樣的錯誤。它們都有類似但不完全相同的堆棧跟蹤信息健爬。
我們先來分析第一個：
java.lang.ArrayIndexOutOfBoundsException: length=10; index=-1
at android.support.v4.util.Pools$SimplePool.release(Pools.java:116)
at com.facebook.react.bridge.DynamicFromMap.recycle(DynamicFromMap.java:40)
at com.facebook.react.uimanager.LayoutShadowNode.setHeight(LayoutShadowNode.java:168)
at java.lang.reflect.Method.invoke(Method.java)
...
java.lang.reflect.InvocationTargetException: null
at java.lang.reflect.Method.invoke(Method.java)
...
com.facebook.react.bridge.JSApplicationIllegalArgumentException: Error while updating property 'height' in shadow node of type: RNSVGSvgView
at com.facebook.react.uimanager.ViewManagersPropertyCache$PropSetter.updateShadowNodeProp(ViewManagersPropertyCache.java:113)
...
我們找到了發(fā)生錯誤的地方：android/support/v4/util/Pools.java。
我們已經(jīng)非常深入到 Android 支持庫么介，但不確定現(xiàn)在可以從中推斷出多少信息娜遵。
使用另一種方式
另一種方法是檢查我們在新版本代碼中所做的修改，特別是那些會影響原生 Android 代碼的修改壤短。我們發(fā)現(xiàn)了 2 個可能性：
我們升級了 Native Navigation设拟，這是一種在 Android 上為每個屏幕使用原生片段的導(dǎo)航解決方案；
我們升級了 react-native-svg久脯。有一些與 SVG 組件相關(guān)的異常纳胧，但有些與它沒有關(guān)系，所以很難說帘撰。
因為無法重現(xiàn)錯誤跑慕，我們最好的選擇是：
回退 2 個庫中的一個；
只發(fā)布給 10％的用戶；
與這些用戶確認核行，看看新版本有沒有發(fā)生崩潰牢硅。這樣就可以驗證我們的假設(shè)。
要回退哪個庫呢芝雪？
一種辦法是通過拋硬幣來決定减余，但我們真的要這么做嗎？
深究這一點
好吧惩系，讓我們深入挖掘之前的堆棧跟蹤信息位岔，看看是否可以確定選擇回退哪個庫。
/**
* Simple (non-synchronized) pool of objects.
*
* @param The pooled type.
*/
public static class SimplePool implements Pool {
private final Object[] mPool;
private int mPoolSize;
...
@Override
public boolean release(T instance) {
if (isInPool(instance)) {
throw new IllegalStateException("Already in the pool!");
}
if (mPoolSize < mPool.length) {測試學(xué)習(xí)交流175317069君(qun)羊
mPool[mPoolSize] = instance;
mPoolSize++;
return true;
}
return false;
}
以上是崩潰發(fā)生的地方堡牡。錯誤是java.lang.ArrayIndexOutOfBoundsException: length=10; index=-1赃承，意思是說，mPool 是一個大小為 10 的數(shù)組悴侵，但 mPoolSize = -1瞧剖。
除了上面的 recycle 方法之外，可以修改 mPoolSize 的另一個地方是 SimplePool 類的 acquire 方法：
public T acquire() {
if (mPoolSize > 0) {
final int lastPooledIndex = mPoolSize - 1;
T instance = (T) mPool[lastPooledIndex];
mPool[lastPooledIndex] = null;
mPoolSize--;
return instance;
}
return null;
}
因此可免，導(dǎo)致 mPoolSize 變?yōu)?-1 的唯一可能是在 mPoolSize=0 時繼續(xù)執(zhí)行 mPoolSize–抓于。 但在 mPoolSize > 0 時，這種情況怎么可能會發(fā)生呢浇借？
我們在 Android Studio 中設(shè)置了一個斷點捉撮，并檢查啟動應(yīng)用程序時發(fā)生了什么。我的意思是妇垢，因為有一個 if 條件巾遭，這段代碼不應(yīng)該會出現(xiàn)故障！
最后闯估，啟示灼舍！
DynamicFromMap有一個靜態(tài)引用SimplePool。
private static final Pools.SimplePool<DynamicFromMap> sPool = new Pools.SimplePool<>(10);
如果對軟件測試涨薪、接口測試骑素、自動化測試、性能測試刚夺、LR腳本開發(fā)献丑、面試經(jīng)驗交流。感興趣可以175317069侠姑，群內(nèi)會有不定期的發(fā)放免費的資料鏈接创橄，這些資料都是從各個技術(shù)網(wǎng)站搜集、整理出來的莽红，如果你有好的學(xué)習(xí)資料可以私聊發(fā)我妥畏，我會注明出處之后分享給大家。
在幾十次點擊播放按鈕后，我們可以通過精心放置的斷點查看SimplePool.acquire并通過React Native SimplePool.release調(diào)用mqt_native_modules線程來管理React組件的樣式屬性（在組件下面width）
但同時也被主線程調(diào)用咖熟！
從上面我們可以看到圃酵，它被用于更新主線程上的 fill prop，這個屬性通常屬于 react-native-svg 組件馍管！實際上郭赐，react-native-svg 只在版本 7 之后才開始使用 DynamicFromMap 來提高原生 svg 動畫的性能。
函數(shù)實際上被 2 個線程調(diào)用确沸，但 DynamicFromMap 沒有以線程安全的方式使用 SimplePool捌锭。“線程安全”又是什么鬼罗捎？
線程安全理論
因為 JavaScript 是單線程的观谦，因此 JavaScript 開發(fā)人員通常不需要處理線程安全問題。
另一方面桨菜，Java 支持并發(fā)或多線程概念豁状。多個線程可以在單個程序中運行，并且可能會并發(fā)訪問公共數(shù)據(jù)結(jié)構(gòu)倒得，可能會導(dǎo)致意外的結(jié)果泻红。
讓我們舉一個簡單的例子，在下圖中霞掺，線程 A 和線程 B 都：
將整數(shù)讀入內(nèi)存谊路；
增加它的價值；
將它返回菩彬。
在線程 A 完成更新之前缠劝，線程 B 可能會訪問數(shù)據(jù)的值。我們期望它們是兩個單獨的遞增值操作骗灶，最終結(jié)果為 19惨恭，但結(jié)果可能會是 18。對于這樣情況矿卑，數(shù)據(jù)的最終狀態(tài)取決于線程操作的順序喉恋，稱為競態(tài)條件。競態(tài)條件的問題在于它們不一定總是會發(fā)生母廷。對于上述的情況，線程 B 在遞增值之前還有更多的工作要做糊肤，為線程 A 提供足夠的時間來更新值琴昆。這就解釋了重現(xiàn)崩潰的隨機性和不可能性。
如果操作可以由很多線程同時完成馆揉，則數(shù)據(jù)結(jié)構(gòu)被認為是線程安全的业舍，就不會有出現(xiàn)競態(tài)條件的風(fēng)險。
當(dāng)一個線程讀取一個特定數(shù)據(jù)元素時，不應(yīng)該讓其他線程修改或刪除這個元素（這稱為原子性）舷暮。在我們之前的示例中态罪，如果更新周期是原子的，就可以避免出現(xiàn)競態(tài)條件下面。線程 B 將等待線程 A 完成操作复颈。
在我們的例子中，這是可能發(fā)生的事情：
由于 DynamicFromMap 持有對 SimplePool 的靜態(tài)引用沥割，因此不同線程的多個 DynamicFromMap 調(diào)用導(dǎo)致可以同時調(diào)用 SimplePool 的 acquire 方法耗啦。
在上圖中，線程 A 調(diào)用 acquire 方法机杜，得出條件為 true帜讲，但尚未減小 mPoolSize 的值（與線程 B 共享），而線程 B 同時調(diào)用該方法椒拗，并得出相同的條件似将。然后每個單獨的調(diào)用都將減少 mPoolSize 的值，這就是為什么你會獲得一個錯誤的值蚀苛。
修復(fù)錯誤
我們在 react-native 上發(fā)現(xiàn)了一個未合并的 PR在验，這個 PR 修復(fù)了線程安全問題。
然后枉阵，我們部署了一個修補版本的 react native译红，將其發(fā)布給我們的用戶。崩潰問題終于得到了解決兴溜！
這個修復(fù)將包含在 React Native 的下一個小版本 0.57 中侦厚。
為了修復(fù)這個錯誤，我們確實做出了很大的努力拙徽，但這也是一個深入了解 react-native 和 react-native-svg 的絕佳機會刨沦。一個好的調(diào)試器和一些很好的斷點很長的路要走。希望你也學(xué)到了一些有用的東西膘怕！
