If an application needs to execute system Shell commands, it can do so through the runCmd(command: string, options?: ConditionType): ChildProcess function of @ohos.process. Please note that this metho

结论 OpenHarmony应用的ArkTS内存上限是多少？先说结论： 4.x系统 计算公式：物理内存 / 9，最小不小于128M 5.x系统 计算公式：物理内存 * 0.6，最大不大于1536M 如物理内存约为1944M，在4.x系统上，应用的ArkTS内存上限约为216M，5.x的系统上则约为1169M。接下来我们来看一下内存上限在代码中是如何定义的。 代码 ArkTS内存相关代码均在ets_

笔者Windows系统版本为Windows 11 下载 在Windows上编译OpenHarmony系统，有两种方式：一种是使用WSL安装Ubuntu，另一种是使用虚拟机。这里选用免费的VirtualBox来实现第二种方式，Ubuntu的系统版本为20.04.6。 安装VirtualBox前需要先安装microsoft visual c++ 2019 redistributable packag

应用如果需要执行系统的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或调用其的函数，以此类推