基于Chromium 50的Android类WebView控件ARM64无限递归崩溃求助

首先咱们拆解下问题核心：你碰到的Fatal signal 11 (SIGSEGV)、code 2 (SEGV_ACCERR)崩溃，本质是JavaScript无限递归引发的Native栈溢出。而只在Android 10 ARM64环境出现的原因，主要有两点：

1. Chromium 50是2016年的版本，完全没适配2019年推出的Android 10，尤其是ARM64架构下的内存栈保护机制更严格——旧系统可能允许少量栈越界，Android 10则直接触发段错误；
2. ARM64与32位的栈布局、默认栈大小存在差异：64位下V8的递归栈帧体积更大，或者系统分配的栈空间更小，导致无限递归更快触达栈上限。

结合你无法更换WebView的限制，给你几个可行的解决方案：

1. 从JS层面限制递归深度（最推荐） #

无限递归的栈溢出没法通过JS的try/catch捕获，所以必须提前给递归逻辑加深度限制。如果是你可控的JS代码，直接修改；如果是第三方JS，可通过注入包装函数来限制：

示例包装代码： #

// 注入递归包装函数，限制最大调用深度
function wrapRecursive(targetFunc, maxDepth = 1000) {
    let currentDepth = 0;
    return function(...args) {
        if (currentDepth >= maxDepth) {
            throw new Error("Recursion depth limit exceeded to prevent crash");
        }
        currentDepth++;
        try {
            return targetFunc.apply(this, args);
        } finally {
            currentDepth--;
        }
    };
}

// 用包装后的函数执行递归逻辑
webView.evaluateJavascript(`
    (function() {
        const safeRecursive = wrapRecursive(function a(i) { a(i++); });
        safeRecursive(0);
    })()
`, null);

这个方法从根源上避免栈溢出，不需要修改Native代码，兼容性最好。

2. 调整V8的栈大小参数 #

Chromium 50的V8引擎支持通过--stack-size命令行参数调整栈大小（单位为KB）。你可以尝试给自定义WebView添加这个参数，增大栈空间来缓解溢出问题：

Java层示例代码（需匹配你的WebView参数配置方式）： #

// 假设你的自定义WebView支持设置Chromium命令行参数
import org.chromium.base.CommandLine;

// 在初始化WebView前调用
CommandLine.getInstance().appendSwitch("--stack-size", "8192"); // 设置为8MB，默认通常1-2MB

注意：不同自定义WebView的参数注入方式可能不同，需对应控件文档调整。这个方法能提升栈溢出阈值，但无法彻底解决无限递归问题，只是延迟崩溃。

3. 将递归逻辑改为迭代（可控场景下最彻底） #

如果触发崩溃的JS是你自己编写的，直接把递归改成循环迭代，彻底消除栈空间占用：

修改后的示例代码： #

// 把无限递归改成无限循环，不占用栈空间
webView.evaluateJavascript("(function() { let i = 0; while(true) { i++; } })()", null);

这种方式从逻辑上根除了栈溢出的可能，是最彻底的解决方案，但仅适用于你能控制JS代码的场景。

4. Native层信号捕获（应急方案，不推荐） #

如果上述方法都无效，且你拥有自定义WebView的Native源码，可以尝试在Native层注册信号处理器，捕获SIGSEGV并做优雅退出。但这个方法风险极高，可能导致内存泄漏、程序不稳定甚至触发ANR，仅作为最后应急手段。

内容的提问来源于stack exchange，提问作者S.Z.P.