应用如果需要执行系统的Shell指令，可以通过@ohos.process的runCmd(command: string, options?: ConditionType): ChildProcess函数来执行。 需要说明的是，该方法局限性比较大，通常不建议使用，仅做参考 使用方法 下载Full SDK 由于该api是系统应用权限，且不对普通应用开放，因此需要下载Full SDK，如果已经是Full

由于目前DevEco Studio暂时不支持断点调试Hvigor插件代码，在开发一些复杂插件时体验较差，因此可以使用VSCode来弥补这一块的能力缺失。 编写插件 参考文档：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/ide-hvigor-plugin-V5 创建好鸿蒙工程以及编写好插件代码后，需要先根据插件功能

本系列文章旨在提供定位与解决OpenHarmony应用与子系统内存泄露的常见手段与思路，将会分成几个部分来讲解。首先我们需要掌握发现内存泄漏问题的工具与方法，以及判断是否可能存在泄漏。接着需要掌握定位泄漏问题的工具，以及抓取trace、分析trace，以确定是否有泄漏问题。如果发现问题的场景过于复杂，需要通过分解问题来简化场景。

综合类的案例，一般都是需要结合native napi代码，与对应的JavaScript对象一起分析的类型。 OnJsRemoteRequest 该案例，是在进行rpc通信时，服务端的占用内容会不断增大，JavaScript代码如下： class ServiceImpl extends rpc.RemoteObjec

本篇提供了一些3.2 release上Native相关的内存泄漏的真实案例，旨在提供常见泄漏原因的解决办法 智能指针 Ability与ContextDeal循环引用 相关代码在trace分析一章中已经分析过，这里就不再贴出。要解决循环引用，最常见的解决办法就是将其中一方的share_ptr改为weak_ptr。 但是，由于不管是Ability

有些时候，在我们抓取了native或js的trace后，创建栈非常多非常密集，可能是好几个问题都集中到一起，比较难以通过肉眼筛选出关键对象。这时候时间轴内的曲线通常也毫无规律，没法准确区分每次操作的间隔在哪，干扰判断。因此我们需要将复杂的问题分解为一个个简单的问题，方便分析。 由于场景复杂的通常是应用

在通过hiprofiler或chrome devtools抓取trace后，接下来重点就是找出可疑的对象，并反编译，然后分析代码确认其是否有泄露。 可疑对象 hiprofiler Native trace需要从下往上看。最下方一般是malloc等分配内存的函数，往上一层则是operator new或调用其的函数，以此类推

在发现问题一文中，如果通过测试手段发现某进程可能存在泄露，接下就需要通过其他工具来查找泄露点，并通过分析代码来确认并解决问题。本篇教程主要讲解通过工具来定位问题-即定位泄漏点。 hiprofiler hiprofiler用来抓取一段时间内，进程中创建对象的栈，包括Native对象与JavaScript对象。但是由于JavaScr

本系列教程旨在提供定位与解决OpenHarmony应用与子系统内存泄露的常见手段与思路，将会分成下面几个部分来讲解： 发现问题 定位问题 分析Trace 分解问题 解决问题 内存查看工具 本教程提供如何发现应用或子系统是否有内存泄露问题的常见手段。内存泄露问题一般表现为进程的内存占用随着进程的持续运行而持续升高，且不会回落。那么想要确定是否有内存泄露&am

本文分享了无法进入桌面时的常见分析思路，如有遗漏，欢迎补充。 在提供思路前，我们需要了解在OpenHarmony上，应用依赖的服务有哪些，开机动画的消失时机是什么，以及预装应用安装与启动的大概流程，方便出现问题是能快速定位。 基础应用依赖的服务 进程名 id 依赖 作用 备注 foundation 401包管理foundation 4606窗口管理foundation 180