android上webivew是個坑貨，無疑！以前就曾出現(xiàn)過好幾次莫名其妙的發(fā)出signal退出進(jìn)程的例子，你退就退對應(yīng)的activity就行了，為啥要把整個進(jìn)程干掉？這回遇到的是一個crash，基本都在8.x機(jī)器上，而且絕大部分都是華為和榮耀機(jī)器，比如DUB-AL00占比三分之一。堆棧如下：

>>> backtrace <<<
#00 pc 014a2d98  /data/hw_init/system/app/WebViewGoogle/WebViewGoogle.apk!libwebviewchromium.so (offset 0x44f9000)
>>> registers <<<
r0  ba5b37b4  r1  ba5b37b4  r2  00004cce  r3  ce4fffe9
r4  00004d44  r5  d00906e8  r6  13c80010  r7  b8abe5e8
r8  13c801c8  r9  bb861800  r10 138d3f18  r11 00000000
ip  cffdb264  sp  b9f7f420  lr  ce4ffe53  pc  cec50d98

>>> stack <<<
     b9f7f3e0  e838bb40  [anon:libc_malloc]
     b9f7f3e4  00000000
     b9f7f3e8  bc4f1534  /dev/ashmem/dalvik-LinearAlloc (deleted)
     b9f7f3ec  00000043
     b9f7f3f0  ce4fffe9  /data/hw_init/system/app/WebViewGoogle/WebViewGoogle.apk!libwebviewchromium.so
     b9f7f3f4  00004d44
     b9f7f3f8  d00906e8  [anon:.bss]
     b9f7f3fc  13c80010  /dev/ashmem/dalvik-main space (region space) (deleted)
     b9f7f400  b8abe5e8  [anon:.bss]
     b9f7f404  13c801c8  /dev/ashmem/dalvik-main space (region space) (deleted)
     b9f7f408  bb861800  [anon:libc_malloc]
     b9f7f40c  ce4ffe53  /data/hw_init/system/app/WebViewGoogle/WebViewGoogle.apk!libwebviewchromium.so
     b9f7f410  d00906f0  [anon:.bss]
     b9f7f414  13c80010  /dev/ashmem/dalvik-main space (region space) (deleted)
     b9f7f418  b8abe5e8  [anon:.bss]
     b9f7f41c  cec50d83  /data/hw_init/system/app/WebViewGoogle/WebViewGoogle.apk!libwebviewchromium.so
#00  b9f7f420  d00906ec  [anon:.bss]
     b9f7f424  d00906e8  [anon:.bss]
     b9f7f428  b8abe5e8  [anon:.bss]
     b9f7f42c  cec50de5  /data/hw_init/system/app/WebViewGoogle/WebViewGoogle.apk!libwebviewchromium.so
     b9f7f430  bb861800  [anon:libc_malloc]
     b9f7f434  138d3f18  /dev/ashmem/dalvik-main space (region space) (deleted)
     b9f7f438  00000000
     b9f7f43c  e831b3a9  /system/lib/libart.so (art_jni_dlsym_lookup_stub+8)
     b9f7f440  13b4a700  /dev/ashmem/dalvik-main space (region space) (deleted)
     b9f7f444  13c80010  /dev/ashmem/dalvik-main space (region space) (deleted)
     b9f7f448  00271a65
     b9f7f44c  13b4a700  /dev/ashmem/dalvik-main space (region space) (deleted)
     b9f7f450  13c80010  /dev/ashmem/dalvik-main space (region space) (deleted)
     b9f7f454  cec4d21f  /data/hw_init/system/app/WebViewGoogle/WebViewGoogle.apk!libwebviewchromium.so (Java_org_chromium_ui_base_Clipboard_nativeInit+6)
     b9f7f458  b8abe5e8  [anon:.bss]
     b9f7f45c  b87efbad  /data/dalvik-cache/arm/data@hw_init@system@app@WebViewGoogle@WebViewGoogle.apk@classes.dex

另外還有一個信息，crash的線程是在一個我用HandlerThread寫的后臺處理線程類A，這個類調(diào)用的地方不多，大概七八處。

解決思路：
一、先復(fù)現(xiàn)
根據(jù)上報的機(jī)型model和日志里的信息，發(fā)現(xiàn)是搜索某個特定的劇后crash的，找到相應(yīng)的機(jī)器后，確實能復(fù)現(xiàn)，是個第三方的劇的網(wǎng)頁，進(jìn)去后播放沒問題，但是如果做些點擊的操作就90%以上概率會crash，而且，同樣的8.x機(jī)器，非上報機(jī)型的華為或榮耀不能復(fù)現(xiàn)。
但是，同樣的機(jī)型，使用同樣sdk的公司內(nèi)另一個app卻沒事。
二、可能性

1. sdk版本不一致，或者其它接入方面不同導(dǎo)致我們有問題，另一個app沒問題
2. 調(diào)用方式不同導(dǎo)致兩個app異同
3. 其它原因。

對于1，嘗試各方面對齊另一個app后，未果，一樣crash。
對于2，找遍了各種調(diào)用方式上異同，比如傳參等，未果，一樣crash
那看起來是3了，但是不敢面對這個現(xiàn)實哈哈。

嘗試通過breadpad來恢復(fù)堆棧，不可行，沒有chrome的帶symbol的so庫。
想來想去，還是回到crash本身，為啥每次都在那個線程類A里，是上報系統(tǒng)不準(zhǔn)還是確實和線程A有關(guān)，反正調(diào)用A的地方也不多，那索性都給注釋了，再試，果然沒問題，那接下來就簡單了挨個排除就行了，最后發(fā)現(xiàn)是在那個線程里會讀取剪貼板的地方有問題，不讀剪貼板就行了?；剡^頭看堆棧：

/data/hw_init/system/app/WebViewGoogle/WebViewGoogle.apk!libwebviewchromium.so (Java_org_chromium_ui_base_Clipboard_nativeInit+6)

剛好可以對上，所以猜測，是非主線程里讀取了剪貼板了，導(dǎo)致webview在主線程里對剪貼板相關(guān)操作時崩潰，具體源碼沒去看了，有興趣的可以研究下。

嗯，其實一開始就應(yīng)該把線程A和堆棧里的Clipboard聯(lián)想起來的。
解決方案：
線程A里調(diào)用剪貼板的地方，換成在主線程里調(diào)。