App 出现意外闪退我们称之为 Crash，Crash 率是衡量 App 稳定性的一个重要指标，App 的稳定性不仅影响使用体验，甚至会造成用户流失。由于导致 App Crash 的原因和类型众多，一篇文章无法阐述清楚，也不是本文的重点，我们不做过多赘述。

　　众所周知，WebView 具有跨端运行的优势，大多场景下无需跟随 App 发版，最新内容渗透率明显高于 Native，这使得 WebView 的应用场景越来越多。WebView 导致的 Crash 也占据较大比例，有效治理 WebVi ew 导致的 Crash 迫在眉睫。

　　在 Android 9.0 系统上如果引入多个进程使用 WebView 需要使用官方提供的 api 在子进程中给 WebView 的数据文件夹设置后缀。

　　lock 方法对 WebView 缓存目录中的 webview_data.lock 文件在 for 循环中尝试加锁 16 次，如注释解释：可能出现的极端情况是一个旧进程正在被杀死时一个新的进程启动了，如果加载成功会将该进程 id 和进程名写入到文件，如果加锁失败则会抛出异常，在 Android P 及更高版本检测应用是否存在多进程公用 WebView 数据目录的原理就是进程持有 WebView 数据目录中的 webview_ data.lock 文件的锁。所以如果子进程也尝试对 webvie w_data.loc 文件加锁则会导致应用崩溃。

　　既然获取文件锁失败就会发生崩溃，并且该文件只是用于加锁判断是否存在多进程共用 WebView 数据目录，每次加锁成功都会重新写入对应进程信息，那么我们可以在应用启动时对该文件尝试加锁，如果加锁失败就删除该文件并重新创建，加锁成功就立即释放锁，这样当系统尝试加锁时理论上是可以加锁成功的，也就避免了这个问题的发生。

　　App 升级支持 64 位系统后，部分国产手机升级覆盖安装后，进入 WebView 的页面发生 Crash，日志如下：

　　App 覆盖升级安装后在部分手机上进入 WebView 页面直接崩溃的现象，而且是必现的，非首次安装不会出现该问题。对于出现问题的手机只能进入到设置 - 应用管理 - 应用里清楚数据，用户体验极差。

　　清除应用数据后不再崩溃，可以正常使用，结合上面日志里面出现的 data/data/ 应用包名 /lib/***.so，由此推断系统在覆盖安装或升级新版本的时候如果老版本和新版本存在相同库文件并不会重新加载进系统导致新版本安装之后用的还是老版本加载的库文件，然而新版本与老版本的缓存文件之间没有必要的关联，从而导致找不到方法名而报错。

　　根据上面分析，在新版本进入应用初始化的时候对应用缓存进行一次清理，在系统检测到没有缓存之后就会重新加载新的库文件主要清楚的缓存文件路径是：getFileDir().getParent() 这个路径下有一些文件夹如:/lib、/database、/shared_prefs..... /shared_prefs 下面保存的是 SharedPreference 数据，/database 下保存的是 db 数据库文件clash客户端如何智能代理，这两个文件下的文件保存着用户数据，可以不用删除或者选择性删除，删除代码如下：

　　在删除 SharePreference 数据的时候，只保留了自己创建的文件，其余都删除了，因为在测试过程中发现如果保留整个 /shared_prefs 文件夹的话还是会出错，里面存有一些其他第三方库文件写进去的数据如果不清楚也会报错。

　　针对该 Crash，紧急联系相关运营人员中止活动投放，同时将页面替换成文本 + 小图的方式后再次投放，Crash 得以中止。

　　但是这种方案不是长久之计，我们有效约束所有运营人员都按照我们的标准去配置。所以短期的解决方案是后端限制图片的分辨率，当超出该分辨率后提示上传失败并给出提示及引导方案。

　　长期有效的方案是在 WebView 页面加载图片的时候，校验图片的分辨率和大小，对不符合规范的图片做响应的压缩，像 Glide 一样。这项内容我们还在有条不紊的规划开发中，待成熟后及时输出给大家。