HarmonyOS鸿蒙Next中上架审核提示应用在运行中存在JsCrash异常的问题

HarmonyOS鸿蒙Next中上架审核提示应用在运行中存在JsCrash异常的问题 【问题描述】：测试步骤：1. 应用在运行中存在JsCrash异常的问题，原因：Generated by HiviewDFX@OpenHarmony at anonymous (entry|webview|1.0.0|src/main/ets/views/WebViewPage.ts:1268:53) at anonymous (entry|webview|1.0.0|src/main/ets/views/WebViewPage.ts:1263:49).;。

【问题现象】：我本地没有复现这个问题，我该怎么改？

【版本信息】：

【复现代码】：

【尝试解决方案】：


更多关于HarmonyOS鸿蒙Next中上架审核提示应用在运行中存在JsCrash异常的问题的实战教程也可以访问 https://www.itying.com/category-93-b0.html

4 回复

开发者您好，本地测试没有问题，打release包上架时测试出现闪退，大概率是混淆导致的，可先按下述步骤排查，如仍有问题，麻烦提供一下完整的报错日志。

【背景知识】

  • 本地安装的hap包和上架的app包可能存在混淆配置的不一致。混淆规则分为两种类型，一种是混淆选项（通常以-enable开头），一种是保留选项（通常以-keep开头）；前者是提供顶层作用域名称、属性名称、文件名称等多种混淆功能配置开关，后者是提供各种混淆功能的白名单配置能力。
  • 混淆规则配置文件obfuscation-rules.txt默认开启了四项推荐的混淆选项：-enable-property-obfuscation、-enable-toplevel-obfuscation、-enable-filename-obfuscation和-enable-export-obfuscation，开发者可以根据需要进一步修改混淆配置。需要注意的是，开启这四项规则可能会导致应用在运行时崩溃，因此建议开发者参考混淆选项配置指导来修正应用功能。

【问题定位】

首先排查是否是由于代码混淆导致的问题。在Release模式下，代码混淆可能会引入难以追踪的错误，而在Debug模式下这些混淆通常是不启用的，因此应用能够正常运行。

【修改建议】

可以按照以下步骤进行操作：

  1. 关闭代码混淆：

    • 参考ArkGuard混淆开启指南，对所有模块关闭代码混淆。
    • 在本模块build-profile.json5配置文件中的arkOptions.obfuscation.ruleOptions字段中，将enable字段设置为false，以禁用混淆功能。

    2、添加混淆取消规则： 如果您希望保留部分混淆配置，但想临时取消所有混淆以进行问题排查，可以在obfuscation-rules.txt文件 中添加-disable-obfuscation规则。这将全局禁用代码混淆。

    3、开启混淆模式下定位错误代码具体行数方法： 应用在Release后，经过代码混淆的堆栈信息无法定位到源码的具体文件和行位置，不易于快速解决问题。针对该场景，DevEco Studio提供了Release应用堆栈解析功能，利用Release应用堆栈中的bundle路径，通过映射规则转换为具体的源码路径，从而提升解决问题的效率。

    Release应用堆栈解析功能操作方法如下：

    1. 单击菜单栏Code> Analyze Stack Trace。
    2. 在弹出的Analyze Stack Trace对话框中，粘贴Release应用的异常堆栈信息，单击OK。
    3. DevEco Studio将解析后的堆栈信息显示在底部的Stacktrace页签中，点击路径链接可快速定位到源码具体位置。

更多关于HarmonyOS鸿蒙Next中上架审核提示应用在运行中存在JsCrash异常的问题的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


自己Release模式打包，在WebViewPage.ts:对应文件的函数(如果知道哪个函数最好)里强制造clash,看一下哪里和“WebViewPage.ts:1263:49” 这个错误最接近，问题大概在那边了，在看一下代码，看能不能造个一摸一样的clash log.

在HarmonyOS Next中，JsCrash通常由JavaScript运行时错误导致。常见原因包括：未捕获的异常、内存访问越界、API调用不当或资源加载失败。需检查应用代码逻辑，确保异步操作正确处理，避免内存泄漏。使用DevEco Studio的日志与调试工具定位具体错误堆栈，修复后重新提交审核。

根据你提供的错误日志，这是一个典型的WebView页面中的JavaScript异常导致的JsCrash。错误发生在WebViewPage.ts文件的第1268行和第1263行附近。虽然你本地无法复现，但审核环境检测到了这个崩溃，必须修复才能通过上架。

核心问题在于WebView中加载或运行的JavaScript代码存在未捕获的异常。由于是审核环境复现，可能与特定操作流程、网络状态或数据有关。

建议排查和修复方向：

  1. 定位具体代码： 立即检查src/main/ets/views/WebViewPage.ts文件中第1263行和1268行附近的代码。这极有可能是你调用WebView的runJavaScript、loadUrl或处理页面回调（如onPageEnd、onMessage）的地方。

  2. 增强JavaScript错误捕获：

    • 在WebView组件中，务必启用并实现onError或onJsError回调，以捕获页面内的JS错误。
    • 在调用runJavaScript执行脚本时，使用try-catch包裹，并处理异常。
    • 示例代码框架：
    webviewController.onJsError((error) => {
  // 将错误信息记录到本地日志，用于分析
  console.error(`WebView JS Error: ${error.message}`);
  // 可进行降级处理，如显示错误页面或提示
});

// 执行JS代码时
try {
  await webviewController.runJavaScript('yourScript()');
} catch (error) {
  console.error(`runJavaScript failed: ${error}`);
}

  3. 检查WebView加载内容：

    • 如果加载的是远程URL，确保网络请求有超时和失败处理，避免因网络问题导致页面加载不全而引发JS错误。
    • 如果是加载本地HTML/JS，检查相关资源是否完整打包，并确保JS语法兼容性。

  4. 审查异步操作： WebView中JS与ArkTS的交互（如使用postMessage）是异步的。检查相关事件监听和消息处理逻辑，确保在页面未准备就绪、WebView已销毁等边界情况下不会触发非法调用。

  5. 模拟严苛环境测试： 在本地尝试模拟弱网、快速切换页面、频繁刷新等操作，看是否能触发异常。审核环境通常执行自动化测试，路径可能较用户操作更快速。

关键点： 即使本地未复现，也必须根据错误日志定位到代码块，并添加健壮的异常捕获和处理逻辑。上架审核要求应用具备足够的稳定性，不允许存在可导致崩溃的未处理异常。修复后，建议进行全面回归测试，特别是WebView相关功能。

回到顶部