android webview这个坑货-之一

android上webivew是个坑货，无疑！以前就曾出现过好几次莫名其妙的发出signal退出进程的例子，你退就退对应的activity就行了，为啥要把整个进程干掉？这回遇到的是一个crash，基本都在8.x机器上，而且绝大部分都是华为和荣耀机器，比如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@[email protected]@classes.dex

另外还有一个信息，crash的线程是在一个我用HandlerThread写的后台处理线程类A，这个类调用的地方不多，大概七八处。

解决思路：
一、先复现
根据上报的机型model和日志里的信息，发现是搜索某个特定的剧后crash的，找到相应的机器后，确实能复现，是个第三方的剧的网页，进去后播放没问题，但是如果做些点击的操作就90%以上概率会crash，而且，同样的8.x机器，非上报机型的华为或荣耀不能复现。
但是，同样的机型，使用同样sdk的公司内另一个app却没事。
二、可能性

1. sdk版本不一致，或者其它接入方面不同导致我们有问题，另一个app没问题
2. 调用方式不同导致两个app异同
3. 其它原因。

对于1，尝试各方面对齐另一个app后，未果，一样crash。
对于2，找遍了各种调用方式上异同，比如传参等，未果，一样crash
那看起来是3了，但是不敢面对这个现实哈哈。

尝试通过breadpad来恢复堆栈，不可行，没有chrome的带symbol的so库。
想来想去，还是回到crash本身，为啥每次都在那个线程类A里，是上报系统不准还是确实和线程A有关，反正调用A的地方也不多，那索性都给注释了，再试，果然没问题，那接下来就简单了挨个排除就行了，最后发现是在那个线程里会读取剪贴板的地方有问题，不读剪贴板就行了。回过头看堆栈：

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

刚好可以对上，所以猜测，是非主线程里读取了剪贴板了，导致webview在主线程里对剪贴板相关操作时崩溃，具体源码没去看了，有兴趣的可以研究下。

嗯，其实一开始就应该把线程A和堆栈里的Clipboard联想起来的。
解决方案：
线程A里调用剪贴板的地方，换成在主线程里调。