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@WebViewGoogle@WebViewGoogle.apk@classes.dex
另外还有一个信息，crash的线程是在一个我用HandlerThread写的后台处理线程类A，这个类调用的地方不多，大概七八处。
解决思路：
一、先复现
根据上报的机型model和日志里的信息，发现是搜索某个特定的剧后crash的，找到相应的机器后，确实能复现，是个第三方的剧的网页，进去后播放没问题，但是如果做些点击的操作就90%以上概率会crash，而且，同样的8.x机器，非上报机型的华为或荣耀不能复现。
但是，同样的机型，使用同样sdk的公司内另一个app却没事。
二、可能性
- sdk版本不一致，或者其它接入方面不同导致我们有问题，另一个app没问题
- 调用方式不同导致两个app异同
- 其它原因。
对于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里调用剪贴板的地方，换成在主线程里调。
