前言
App 出现意外闪退我们称之为 Crash,Crash 率是衡量 App 稳定性的一个重要指标,App 的稳定性不仅影响使用体验,甚至会造成用户流失。由于导致 App Crash 的原因和类型众多,一篇文章无法阐述清楚,也不是本文的重点,我们不做过多赘述。
众所周知,WebView 具有跨端运行的优势,大多场景下无需跟随 App 发版,最新内容渗透率明显高于 Native,这使得 WebView 的应用场景越来越多。WebView 导致的 Crash 也占据较大比例,有效治理 WebVi ew 导致的 Crash 迫在眉睫。
本文主要讲述 Android WebView 常见 Crash 及解决方案。
01. WebView 开启多进程引发的崩溃
在 Android 9.0 系统上如果引入多个进程使用 WebView 需要使用官方提供的 api 在子进程中给 WebView 的数据文件夹设置后缀。
WebView.setDataDirectorySuffix(suffix);
复制代码
否则会出现如下异常:
Using WebView from more than one process at once with the same data directory is not supported. https://crbug.com/558377
1 com.android.webview.chromium.WebViewChromiumAwInit.startChromiumLocked(WebViewChromiumAwInit.java:63)
2 com.android.webview.chromium.WebViewChromiumAwInitForP.startChromiumLocked(WebViewChromiumAwInitForP.java:3)
3 com.android.webview.chromium.WebViewChromiumAwInit$3.run(WebViewChromiumAwInit.java:3)
4 android.os.Handler.handleCallback(Handler.java:873)
5 android.os.Handler.dispatchMessage(Handler.java:99)
6 android.os.Looper.loop(Looper.java:220)
7 android.app.ActivityThread.main(ActivityThread.java:7437)
8 java.lang.reflect.Method.invoke(Native Method)
9 com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:500)
10 com.android.internal.os.ZygoteInit.main(ZygoteInit.java:865)
复制代码
使用官方提供的 API 后问题减少了一部分,但是线上依然有大量崩溃上报。
问题分析
通过阅读源码发现最终调用到了 AwDataDirLock 中的 lock 方法。
public class WebViewChromiumAwInit {
protected void startChromiumLocked() {
...
AwBrowserProcess.start();
...
}
}
public final class AwBrowserProcess {
public static void start() {
...
AwDataDirLock.lock(appContext);
}
复制代码
AwDataDirLock 中抛出如上异常的核心代码:
// We failed to get the lock even after retrying.
// Many existing apps rely on this even though it's known to be unsafe.
// Make it fatal when on P for apps that target P or higher
String error = getLockFailureReason(sLockFile);
boolean dieOnFailure = Build.VERSION.SDK_INT >= Build.VERSION_CODES.P
&& appContext.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.P;
if (dieOnFailure) {
throw new RuntimeException(error);
} else {
Log.w(TAG, error);
}
复制代码
lock 方法对 WebView 缓存目录中的 webview_data.lock 文件在 for 循环中尝试加锁 16 次,如注释解释:可能出现的极端情况是一个旧进程正在被杀死时一个新的进程启动了,如果加载成功会将该进程 id 和进程名写入到文件,如果加锁失败则会抛出异常,在 Android P 及更高版本检测应用是否存在多进程公用 WebView 数据目录的原理就是进程持有 WebView 数据目录中的 webview_ data.lock 文件的锁。所以如果子进程也尝试对 webvie w_data.loc 文件加锁则会导致应用崩溃。
// Android versions before 11 have edge cases where a new instance of an app process can
// be started while an existing one is still in the process of being killed. This can
// still happen on Android 11+ because the platform has a timeout for waiting, but it's
// much less likely. Retry the lock a few times to give the old process time to fully go
// away.
for (int attempts = 1; attempts <= LOCK_RETRIES; ++attempts) {
try {
sExclusiveFileLock = sLockFile.getChannel().tryLock();
} catch (IOException e) {
// Older versions of Android incorrectly throw IOException when the flock()
// call fails with EAGAIN, instead of returning null. Just ignore it.
}
if (sExclusiveFileLock != null) {
// We got the lock; write out info for debugging.
writeCurrentProcessInfo(sLockFile);
return;
}
// If we're not out of retries, sleep and try again.
if (attempts == LOCK_RETRIES) break;
try {
Thread.sleep(LOCK_SLEEP_MS);
} catch (InterruptedException e) {
}
}
// We failed to get the lock even after retrying.
// Many existing apps rely on this even though it's known to be unsafe.
// Make it fatal when on P for apps that target P or higher
String error = getLockFailureReason(sLockFile);
boolean dieOnFailure = Build.VERSION.SDK_INT >= Build.VERSION_CODES.P
&& appContext.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.P;
if (dieOnFailure) {
throw new RuntimeException(error);
} else {
Log.w(TAG, error);
}
}
复制代码
解决方案
既然获取文件锁失败就会发生崩溃,并且该文件只是用于加锁判断是否存在多进程共用 WebView 数据目录,每次加锁成功都会重新写入对应进程信息,那么我们可以在应用启动时对该文件尝试加锁,如果加锁失败就删除该文件并重新创建,加锁成功就立即释放锁,这样当系统尝试加锁时理论上是可以加锁成功的,也就避免了这个问题的发生。
private static void fixWebviewDataDirLock(Context context) {
if (Build.VERSION.SDK_INT < Build.VERSION_CODES.P) {
return;
}
try {
String suffix = "";
String processName = getProcessName(context);
if (!TextUtils.equals(context.getPackageName(), processName)) {
suffix = TextUtils.isEmpty(processName) ? context.getPackageName() : processName;
WebView.setDataDirectorySuffix(suffix);
suffix = "_" + suffix;
}
ensureSuffixLock(context,suffix);
} catch (Exception e) {
e.printStackTrace();
}
}
@TargetApi(Build.VERSION_CODES.P)
private static void ensureSuffixLock(Context context,String suffix) {
String sb = context.getDataDir().getAbsolutePath() +
"/app_webview"+suffix+"/webview_data.lock";
File file = new File(sb);
if (file.exists()) {
try {
FileLock tryLock = new RandomAccessFile(file, "rw").getChannel().tryLock();
if (tryLock != null) {
tryLock.close();
} else {
createFile(file, file.delete());
}
} catch (Exception e) {
e.printStackTrace();
boolean deleted = false;
if (file.exists()) {
deleted = file.delete();
}
createFile(file, deleted);
}
}
}
private static void createFile(File file, boolean deleted){
try {
if (deleted && !file.exists()) {
file.createNewFile();
}
} catch (Exception e) {
e.printStackTrace();
}
}
复制代码
02. 支持 64 位 CPU 架构升级引发的 Crash
App 升级支持 64 位系统后,部分国产手机升级覆盖安装后,进入 WebView 的页面发生 Crash,日志如下:
pid: 1947, tid: 2230, name: Chrome_InProcGp >>> com.####### <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x958caf8000
x0 000000718baf4000 x1 0000000000000000 x2 000000718baf4000 x3 000000718baf4250
x4 0000000000000000 x5 000000718baf4b44 x6 00000000000029a4 x7 000000718baf69a4
x8 0000000000000000 x9 0000007188e2a748 x10 000000718baf4afc x11 0000000000000b44
x12 0000000000000001 x13 000000718baf4b44 x14 0000000000000000 x15 0000002401004000
x16 0000007188e2a748 x17 0000000000000000 x18 000000958caf8000 x19 0000007187361200
x20 00000071a54cb080 x21 000000718baf1000 x22 000000718baf4000 x23 000000718baf4070
x24 00000071a147b07c x25 0000007188e2a748 x26 0000000000000000 x27 0000000000000000
x28 0000000000000130 x29 0000000000000000 x30 00000071a118a12c
sp 0000007188e2a4d0 pc 00000071a118a384 pstate 0000000060000000
08-20 16:38:46.697 2304-2304/? A/DEBUG: backtrace:
#00 pc 0000000000a7b384 /vendor/lib64/libllvm-glnext.so
(ShaderObjects::loadProgramBinary(CompilerContext, void, unsigned long, QGLC_LINKPROGRAM_RESULT)+1400)
#01 pc 00000000009b0e38 /vendor/lib64/libllvm-glnext.so
(CompilerContext::loadProgramBinary(void, unsigned long, QGLC_LINKPROGRAM_RESULT)+156)
#02 pc 0000000000a92550 /vendor/lib64/libllvm-glnext.so
(QGLCLoadProgramBinary(void, void, unsigned long, QGLC_LINKPROGRAM_RESULT)+88)
#03 pc 00000000001b9694 /vendor/lib64/egl/libGLESv2_adreno.so (EsxShaderCompiler::LoadProgramBinaryBlob
(EsxContext, EsxProgram, void const, unsigned long, EsxInfoLog)+256)
08-20 16:38:48.125 1395-1743/? E/TaskPersister: File error accessing recents directory (directory doesn't exist?).
复制代码
问题分析
Android 8.0 版本的 WebView 在读取 WebView 缓存时出现内存溢出。
解决方案
App 升级后删除/data/data/包名/app_webview/GPUCache 目录,由于手机厂商对 app_webview/GPUCache 目录修改太多不同机型删除细节不同。如华为手机的目录是 app_hws_webview/Default/GPUCache;OPPO 和小米手机的目录是 app_webview/Default/GPUCache,为了彻底兼容不同机型的适配问题,我们采用暴力删除的方式,App 版本升级后,首次启动时删除/data/data/包名/所有包含 webview 的缓存目录。
SharedPreferences prefs =
application.getSharedPreferences("WebViewChromiumPrefs", Context.MODE_PRIVATE);
prefs.edit().clear().apply();
final File dir = context.getFilesDir();
if (dir != null && dir.getParent() != null) {
File file = new File(dir.getParent());
if (file.exists() && file.isDirectory()) {
final File[] files = file.listFiles();
if (files != null) {
for (File child : files) {
final String path = child.getAbsolutePath();
if (!TextUtils.isEmpty(path) && path.toLowerCase().contains("webview")) {
deleteFile(child);
}
}
}
}
}
private static void deleteFile(File file) {
if (file == null || !file.exists()) {
return;
}
if (file.isDirectory()) {
File[] files = file.listFiles();
if (files != null) {
for (File child : files) {
deleteFile(child);
}
}
} else {
file.delete();
}
}
复制代码
03. WebView 本地缓存数据导致的 Crash
App 覆盖升级安装后在部分手机上进入 WebView 页面直接崩溃的现象,而且是必现的,非首次安装不会出现该问题。对于出现问题的手机只能进入到设置-应用管理-应用里清楚数据,用户体验极差。
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'java_vm_ext.cc:534] JNI DETECTED ERROR IN APPLICATION:
JNI GetMethodID called with pending exception java.lang.NoSuchMethodError: no non-static method
"Lorg/android/spdy/SpdyAgent;.spdySessionConnectCB(Lorg/android/spdy/SpdySession;
Lorg/android/spdy/SuperviseConnectInfo;)V"'
r0 00000000 r1 000001fe r2 00000006 r3 00000008
r4 0000018c r5 000001fe r6 89219074 r7 0000010c
r8 00000000 r9 a4319368 sl 0000000a fp 892190c0
ip 972e59e0 sp 89219060 lr a4ec18bd pc a4ebb40e cpsr 200b0030
backtrace:
#00 pc 0001a40e /system/lib/libc.so (abort+63)
#01 pc 0035ca45 /system/lib/libart.so (art::Runtime::Abort(char const*)+392)
#02 pc 0041fe2d /system/lib/libart.so (android::base::LogMessage::~LogMessage()+452)
#03 pc 0024e545 /system/lib/libart.so (art::JavaVMExt::JniAbort(char const*, char const*)+1212)
#04 pc 0024e6c7 /system/lib/libart.so (art::JavaVMExt::JniAbortV(char const*, char const*, std::__va_list)+58)
#05 pc 000d6403 /system/lib/libart.so (art::ScopedCheck::AbortF(char const*, ...)+42)
#06 pc 000d5f83 /system/lib/libart.so (art::ScopedCheck::CheckThread(_JNIEnv*)+274)
#07 pc 000d492d /system/lib/libart.so (art::ScopedCheck::
Check(art::ScopedObjectAccess&, bool, char const*, art::JniValueType*)+596)
#08 pc 000d79e9 /system/lib/libart.so (art::CheckJNI::
GetMethodIDInternal(char const*, _JNIEnv*, _jclass*, char const*, char const*, bool)+464)
#09 pc 000c9365 /system/lib/libart.so (art::CheckJNI::
GetMethodID(_JNIEnv*, _jclass*, char const*, char const*)+20)
#10 pc 00003657 /data/app/此处为应用包名-K2pKM3UWvCbPitz1xjJr7A==/lib/arm/libtnet-3.1.11.so
#11 pc 00004a0d /data/app/此处为应用包名-K2pKM3UWvCbPitz1xjJr7A==/lib/arm/libtnet-3.1.11.so
#12 pc 0003d0cd /data/app/此处为应用包名-K2pKM3UWvCbPitz1xjJr7A==/oat/arm/base.odex
(offset 0x3b000)
复制代码
问题分析
清除应用数据后不再崩溃,可以正常使用,结合上面日志里面出现的 data/data/应用包名/lib/***.so,由此推断系统在覆盖安装或升级新版本的时候如果老版本和新版本存在相同库文件并不会重新加载进系统导致新版本安装之后用的还是老版本加载的库文件,然而新版本与老版本的缓存文件之间没有必要的关联,从而导致找不到方法名而报错。
解决方案
根据上面分析,在新版本进入应用初始化的时候对应用缓存进行一次清理,在系统检测到没有缓存之后就会重新加载新的库文件主要清楚的缓存文件路径是:getFileDir().getParent()这个路径下有一些文件夹如:/lib、/database、/shared_prefs..... /shared_prefs 下面保存的是 SharedPreference 数据,/database 下保存的是 db 数据库文件,这两个文件下的文件保存着用户数据,可以不用删除或者选择性删除,删除代码如下:
public static void deleteFolder(File file) {
if (!file.exists())
return;
if (file.isDirectory()) {
File files[] = file.listFiles();
for (int i = 0; i < files.length; i++) {
if(files[i].getAbsolutePath().endsWith("/databases")){
continue;
}
deleteFolder(files[i]);
}
}
if(!file.getAbsolutePath().endsWith("/shared_prefs/user_info.xml") ){
file.delete();
}
SharePreferenceUtils.saveOrUpdateAttribute(context,MyConstants.USER_INFO, "dataCleared", true);
}
复制代码
在 Application 的 onCreate 方法中调用:
@Override
public void onCreate() {
super.onCreate();
if(!SharePreferenceUtils.getAttributeByKey(this,MyConstants.USER_INFO, "dataCleared",SharePreferenceUtil.VALUE_IS_BOOLEAN)){
deleteFolder(new File(getFilesDir().getParent()));
}
}
复制代码
在删除 SharePreference 数据的时候,只保留了自己创建的文件,其余都删除了,因为在测试过程中发现如果保留整个/shared_prefs 文件夹的话还是会出错,里面存有一些其他第三方库文件写进去的数据如果不清楚也会报错。
04. WebView 页面 OOM
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 W Adreno-GSL: <sharedmem_gpuobj_alloc:2736>: sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory
2973 8387 E Adreno-GSL: <gsl_memory_alloc_pure:2604>: GSL MEM ERROR: kgsl_sharedmem_alloc ioctl failed.
2973 8387 E chromium: [ERROR:buffer_manager.cc(488)] [.RendererMainThread-0xe90cdf20]GL ERROR
:GL_OUT_OF_MEMORY : glBufferData: <- error from previous GL command
2973 8387 E chromium: [ERROR:gles2_cmd_decoder.cc(5995)] Error: 5 for Command kBufferData
复制代码
MemFree: 1211920 kB
VmSize: 3912496 kB
复制代码
问题分析
通过日志 sharedmem_gpumem_alloc: mmap failed errno 12 Out of memory 不难发现,Crash 的原因是内存分配出现问题引发了 RenderMainThread 退出,RenderMainThread 8387 是负责向 GPU 申请绘制所需内存的,GPU 与 RAM 本质都是一块物理内存,sharedme m_gpumem_alloc 需要分配内存 VmSize 近 4G,而此时可供使用的有效内存 1.16G,申请分配远超空闲内存,引发内存 OOM 而发生崩溃。
解决方案
针对该 Crash,紧急联系相关运营人员中止活动投放,同时将页面替换成文本+小图的方式后再次投放,Crash 得以中止。
但是这种方案不是长久之计,我们有效约束所有运营人员都按照我们的标准去配置。所以短期的解决方案是后端限制图片的分辨率,当超出该分辨率后提示上传失败并给出提示及引导方案。
长期有效的方案是在 WebView 页面加载图片的时候,校验图片的分辨率和大小,对不符合规范的图片做响应的压缩,像 Glide 一样。这项内容我们还在有条不紊的规划开发中,待成熟后及时输出给大家。
0.5 WebView 常见问题
//在安卓5.0之后,默认不允许加载http与https混合内容,需要设置webView允许其加载混合网络协议内容
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
webviewSetting.setMixedContentMode(WebSettings.MIXED_CONTENT_ALWAYS_ALLOW);
}
复制代码
//Android 8以上 默认开启 &【Google Play Service】
webviewSetting.setSafeBrowsingEnabled(false) 26以下 xml中配置
WebView.setSafeBrowsingWhitelist(List<String> hosts, ValueCallback<Boolean> callback)
复制代码
public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
// handler.cancel(); 不处理或者cancel默认白屏
// handler.proceed(); // 忽略证书异常,正常加载页面,不推荐
// TODO 进行证书验证
}
复制代码
WebView 默认不支持标签:<br />
localStorage.XXX = YYY <br />
webviewSetting.setDomStorageEnbale(true)
复制代码
语法错误造成页面无法渲染
网络资源获取出错
Webview 自身内存问题
if (mWebView != null) {
mWebView.loadDataWithBaseURL(null, "", "text/html", "utf-8", null);
mWebView.clearHistory();
mLayout.removeView(mWebView);
mWebView.destroy();
mWebView = null;
}
复制代码
加载内容引起的内存问题
对 WebViewClient.onRenderProcessGone(WebView view, RenderProcessGoneDetail detail) 回调进行处理,将引起问题的 WebView 移除、destroy()。
评论 13 条评论