HarmonyOS开发常见问题及解答(三)
本原创文章帖发布在华为开发者联盟社区,欢迎开发者前往访问评论交流,更多与该内容相关讨论,请点击原帖查看:
HarmonyOS开发常见问题及解答(三)-华为开发者话题 | 华为开发者联盟
FAQ 1:混淆导致的鸿蒙云调试闪退问题如何解决?
【问题场景】:鸿蒙云调试闪退,模拟器正常运行,日志显示proxy SendRequest失败,
【解决方案】:开启混淆后导致云调试应用jscrash,关闭混淆后就好了
排查功能异常步骤:
1. 在obfuscation-rules.txt中配置-disable-obfuscation选项关闭混淆,确认问题是否由混淆引起。
2. 若确认开启混淆后功能出现异常,请先阅读文档,了解模块已配置的混淆规则的能力和需要配置白名单的语法场景,以确保应用功能正常。下文简要介绍默认开启的四项选项功能,详情请参阅对应选项的完整描述。
• -enable-toplevel-obfuscation 为顶层作用域名称混淆开关。
• -enable-property-obfuscation 为属性混淆开关。配置白名单的主要场景包括网络数据访问、json字段访问、动态属性访问、调用so库接口等。需要使用-keep-property-name来保留指定的属性名称。
• -enable-export-obfuscation 为导入/导出名称混淆。一般与-enable-toplevel-obfuscation和-enable-property-obfuscation选项配合使用。配置白名单的主要场景为模块对外接口不能混淆。需要使用-keep-global-name来保留指定的导出/导入名称。
• -enable-filename-obfuscation 为文件名混淆。配置白名单的主要场景为动态import或运行时直接加载的文件路径。需要使用-keep-file-name来保留这些文件路径及名称。
3. 排查需要配置的白名单场景时,推荐使用混淆助手配置保留选项,可以快速识别需要配置的保留选项和白名单字段。也可以参考以下典型报错案例,若遇到相似场景,可参照对应解决方法快速处理。
4. 若以下报错案例中未找到相似场景,建议依据各项配置功能正向定位(若不需要相应功能,可删除对应配置项)。
5. 应用运行时崩溃分析方法:
• 打开应用运行日志,或点击DevEco Studio中出现的Crash弹窗,找到运行时崩溃栈。
• 应用运行时异常栈中的行号为编译产物的行号,方法名也可能为混淆后名称;因此排查时建议直接根据异常栈查看编译产物,进而分析哪些名称不能被混淆,然后将其配置到白名单中。
6. 应用在运行时未崩溃但出现功能异常(如白屏)的分析方法:
• 打开应用运行日志:选择HiLog,检索与功能异常直接相关的日志,定位问题发生的上下文。
• 定位异常代码段:分析日志,找到引发功能异常的代码块。
• 增强日志输出:在疑似异常的功能代码中,增加日志打印以检查数据是否正常。
• 分析并确定关键字段:通过分析新增的日志输出,判断数据异常是否由混淆导致。
• 配置白名单以保护关键字段:将混淆后对应用功能有直接影响的关键字段添加到白名单中。
排查非预期的混淆能力
若出现预期外的混淆效果,检查是否由于依赖的本地模块或三方库开启了某些混淆选项。
假设当前模块未配置-compact,但混淆的中间产物中代码都被压缩成一行,可按照以下步骤排查混淆选项:
1. 查看当前模块的oh-package.json5中的dependencies,此字段记录了当前模块的依赖信息。
2. 在依赖的模块/三方库中的混淆配置文件内检索"-compact":
o 在本地依赖的library中的consumer-rules.txt文件中检索"-compact"。
o 在工程目录下的oh_modules文件夹中,对全部的obfuscation.txt文件检索"-compact"。
更多指导及案例详见:
ArkGuard混淆常见问题-ArkGuard源码混淆工具-ArkTS编译工具链-ArkTS(方舟编程语言)-应用框架- 华为HarmonyOS开发者
FAQ 2:上架审核中泄漏问题如何分析?
示例:
问题描述:您的应用运行过程中存在内存泄漏问题,原因:包名_JS_LEAK.。问题现象:应用卡顿甚至发生闪退。

稳定性分析
资源泄漏产生的原因是程序未正确释放已分配的内存资源,导致资源被持续占用无法再利用。故障日志文件名: memleak-js-[process_name]-[pid]-[tid]-[timestamp].rawheap或者.heapsnapshot,该文件记录了对象堆内存的详细信息。API14后,通过DevEco Studio或浏览器打开展示,将其导入DevEco Studio并展示,详情见Snapshot模板基本操作-离线导入内存快照文件。导入后可参照JS内存泄漏分析方法分析定位,详情见稳定性分析-资源泄漏类问题分析方法-内存泄漏分析方法-JS泄漏。
分析snapshot日志,基于Retained Size排序后,发现主要占用为"JSObject",可使用LocalHandle工具分析,可参考ArkTS 内存泄漏定位神器!带你揭秘鸿蒙最新LocalHandle泄漏检测工具。
稳定性优化
内存泄漏优化建议1:使用定时器组件销毁时一定要调用clearTimeout和clearInterval,否则对象无法析构。详情见资源泄漏类问题优化建议-内存泄漏问题优化建议1。
内存泄漏优化建议2:异常分支需要关注释放申请的内存,详情见资源泄漏类问题优化建议-内存泄漏问题优化建议2 。
稳定性检测
对于能比较稳定复现,有特定业务场景的泄漏问题,可以使用IDE工具对比两次snapshot快照的方式来定位问题,通过对比两次快照文件,可以获知新增了哪些虚拟机对象,这时候可以结合业务逻辑分析这些新增对象是否合理来判断是否真的泄漏。使用Snapshot检测虚拟机内存泄漏,使用IDE工具检测虚拟机内存泄漏的详细步骤,详情见稳定性检测-资源泄漏类问题检测-内存泄漏类问题检测方法-JS内存泄漏问题检测方法。
如果观测到应用进程的ArkTS内存持续增长,需要定位GC机制无法回收的ArkTS内存泄漏对象,可参考使用JsLeakWatcher开发实践。
APMS运维
APMS上运维态高效处理ArkTS泄漏,支持应用灰度下发,故障预警和AI智慧分析,详情见运维态高效处理ArkTS泄漏。
更多示例详见:【上架检测FAQ】内存泄漏-华为开发者话题|华为开发者联盟
FAQ 3:input瞬时栈,主线程卡死的崩溃日志如何分析?
【问题场景】:怎么分析,主线程卡死的崩溃日志。
【解决方案】:使用冻屏增强日志定位繁忙类问题
概述
用户在使用应用时,如果出现点击无反应或应用无响应等情况,并且持续时间超过一定限制,就会被定义为应用冻屏(AppFreeze),即应用无响应。系统会检测应用无响应,并生成AppFreeze日志,供应用开发者分析。从API 21开始,支持获取AppFreeze的增强日志。该日志通过采集整机及主线程的运行负载,并抓取多份主线程调用栈,帮助开发者知晓函数调用耗时。
日志获取及规格可以参考:AppFreeze(应用冻屏)检测
增强日志具体用法详见:使用冻屏增强日志定位繁忙类问题-华为开发者话题|华为开发者联盟
FAQ 4:开发过程中@Param参数使用不当导致的问题如何分析解决?
【问题场景】:在鸿蒙系统中,使用@BuilderParam传递Builder时,当自动切换深色模式时会导致应用崩溃。
【解决方案】:
示例:@Param装饰器可增强子组件接受外部参数输入的能力,但@Param装饰器只能在@ComponentV2装饰器的自定义组件中使用,可参考链接:@Param的使用限制。
是否混淆@Param与@Link的使用场景?
@Link、@Prop与@Param分别为状态管理V1和状态管理V2的主要接收参数的装饰器,其差异与对比如下:
| 装饰器 | @Link | @Prop | @Param |
| 状态管理版本 | 状态管理V1 | 状态管理V1 | 状态管理V2 |
| 初始化规则 | @Link装饰的变量不能本地初始化,只能通过父组件传入,若父组件未传入则会校验报错。 | @Prop装饰的变量允许本地初始化,若无本地初始化则必须从外部传入初始化。当同时存在本地初始值与外部传入值时,优先使用外部传入值进行初始化。 | 1. @Param装饰的变量允许本地初始化,若无本地初始化则必须从外部传入初始化。当同时存在本地初始值与外部传入值时,优先使用外部传入值进行初始化。2. 当@Param搭配@Require一起使用时,不允许本地初始化,只能通过父组件传入,若父组件未传入则会校验报错。 |
| 同步规则 | 双向同步。父组件状态变量与子组件@Link建立双向同步,当其中一方改变时,另一方也会同步更新。 | 单向同步。对父组件状态变量值的修改,将同步给子组件@Prop装饰的变量,子组件@Prop装饰的变量的修改不会同步到父组件的状态变量上。 | 1. 单向同步。对父组件状态变量值的修改,将同步给子组件@Param装饰的变量。2. 双向同步。@Param搭配@Event装饰器在子组件内调用父组件传递的函数,修改父组件的变量(若接收的是对象,且改变的是对象属性时,无需搭配@Event,可以通过@ObservedV2/@Trace装饰的数据源实现双向同步,详见官网:使用限制)。3. 单向首次同步。搭配@Once只接收第一次父组件向子组件传递的参数,父组件后续的修改,将不会再同步给子组件。 |
通过上述差异对比,状态管理V1与状态管理V2在参数传递方面优缺点如下:
| 状态管理版本 | 状态管理V1 | 状态管理V2 |
| 优缺点 | @Link、@Prop分别支持双向与单向传递,但是不支持单向首次同步。只能通过@State、@Provide等装饰的状态变量以及没有装饰器装饰的普通变量接收外部传参实现单向首次同步,导致@State、@Provide等其它本地化初始化的变量与需要单向首次同步的变量无法区分,组件内参数较多时,维护成本高。 | 通过在@Param的基础上搭配不同装饰器可分别实现单向同步、双向同步、单向首次同步。实现与@Local、@Provider等本地初始化变量的有效区分。组件内参数较多时,维护成本较低。 |
更多示例详见:@Param和@Once相较于@Prop、@Link的使用场景及优势-组件使用-UI框架-应用框架开发 - 华为HarmonyOS开发者
FAQ 5:Release应用堆栈解析相关错误提示及解决措施?
【问题场景】:使用覆盖率插桩生成release包时应用崩溃,且无法通过sourcemap.map和namecache.json文件解析日志。
【解决方案】:
在使用Release应用堆栈解析功能时,遇到的错误提示及解决措施如下所示。
| 错误提示 | 问题原因 | 解决措施 |
| Incorrect path format in line X | 堆栈解析功能会将含有(路径:行号:列号)的堆栈识别为ArkTS堆栈进行解析,会对堆栈进行进一步的校验,路径不能含有运行系统下的不合法字符。如果输入的某行堆栈不满足上述形式,则会提示"Incorrect path format in line X"。 | 请排查输入堆栈是否满足“(路径:行号:列号)”的格式,若不满足应按照格式进行修改,并重新解析。 |
| Failed to find the source file in line X | 在不勾选Unscramble stack trace的情况下,会将堆栈默认为是当前工程产生的堆栈,从本工程中获取解析需要的文件,解析结果也会从当前工程中寻找源文件,如果不存在会提示"Failed to find the source file in line X"。 在勾选Unscramble stack trace的情况下,ArkTS堆栈解析结果是相对路径,不会去寻找源文件,so解析结果如果不存在会提示"Failed to find the source file in line X"。 | 如果解析结果不包含一个绝对路径,可以用“file”命令检查so是否包含debuginfo。 检查堆栈对应工程与所打开工程的是否一致,并检查堆栈对应的源文件是否存在。 如果是自提供的so文件,请确定是产生当前堆栈的so。 |
| SourceMap error in line X | 解析堆栈信息时,DevEco Studio需要sourceMap将堆栈中的bundle文件信息映射为源码信息。如果没有提供相应的sourceMap,或者sourceMap文件不一致,或堆栈被修改,导致堆栈与sourceMap不匹配。 出现上述情况则可能导致无法将堆栈中的信息映射为源码信息,此时会提示"SourceMap error in line X"。 | 检查所打开工程中的bundle文件与生成堆栈信息对应的bundle文件是否一致,如不一致,利用生成堆栈时的源码构建Release版本App,再进行堆栈解析。 如果是FA模型产生的堆栈,请在对应工程中不勾选Unscramble stack trace进行解析。勾选情况下,FA模型产生的堆栈无法匹配到源码信息。 |
| So Error in Line X | 解析堆栈信息时,DevEco Studio需要用so文件将so的堆栈映射为源码信息,如果没有提供对应的so,则可能导致无法将堆栈中的信息映射为源码信息,此时会提示"So error in Line X"。 | 请提供堆栈对应的so文件,确保so包含符号信息,可以使用"file"命令查看so是否为"not striped"。若so为"striped",说明so的信息已被清除,可在模块级build-profile.json5中的debugSymbol->strip字段置为false。 |
| Failed to find source data in line X | 如果输入堆栈中存在字符串"Cannot get SourceMap info, dump raw stack:",DevEco Studio则会将其所在行替换为:"Error Line: +第一条解析成功的堆栈对应的源码数据"。 当第一条解析成功的堆栈对应的源码不存在时(比如源码可能已被修改),则会提示:"Failed to find source data in line X:"。 | 检查源码是否存在,如果不存在,将源码文件改为堆栈信息对应的源码文件。 |
| Failed to find the bundle file in line X | 未勾选Unscramble stack trace时,堆栈解析功能需要在打开对应工程并构建App对应Release版本的条件下使用。 对于输入的堆栈信息,DevEco Studio会根据对应工程类型的路径转换规则寻找堆栈对应的Release版本bundle文件,如果转换后的路径对应bundle文件不存在,则会提示"Failed to find the bundle file in line X:"。 | 打开工程并构建对应App的Release版本,重新输入堆栈进行解析。 |
更多推荐

所有评论(0)