hmos-memory-tier-optimizer

Optimizes HarmonyOS app memory on low-end devices through tiered degradation and before-after verification.

2|Updated Jun 21, 2026
One-click install
npx skills add https://github.com/IsKenKenYa/skills --skill hmos-memory-tier-optimizer-iskenkenya
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hmos-memory-tier-optimizer
Source: https://github.com/IsKenKenYa/skills/tree/main/skills/harmonyos/solutions/quality/performance/hmos-memory-tier-optimizer
Command: npx skills add https://github.com/IsKenKenYa/skills --skill hmos-memory-tier-optimizer-iskenkenya

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? HarmonyOS apps often exceed memory budgets on low-end devices, causing OOM crashes and jank. This Skill runs a full closed-loop workflow: collect meminfo/UI tree/screenshots via hdc, analyze bottlenecks against 14 detection rules, propose tiered optimization schemes, modify and review ArkTS/C-API code, build and install the HAP, re-measure, and produce a patch plus comparison report. ## Core Features & Use Cases - End-to-end memory optimization loop: baseline collection, data-driven analysis, user-confirmed code changes, ArkTS rule-based code review, build/install, post-optimization re-measurement, and patch/report generation. - 12 built-in optimization schemes: cachedCount tiering, image memory optimization, resource leak fixes, Web preload/prerender/offline-reuse tiering, media degradation, Tabs cache, component detaching, QuickJS limits, plus Flutter VMA and RN-specific schemes, all built on a shared device tiering mechanism (low/medium/high). - Use Case: A developer reports their HarmonyOS app exceeds PSS limits on low-end phones. The Skill collects meminfo, detects a hardcoded cachedCount of 50 in a long list, applies device-tiered cachedCount values, verifies the build, and reports a before/after PSS reduction. ## Quick Start Ask the assistant to optimize this HarmonyOS app's memory for low-end devices and produce a before-and-after PSS comparison report.

Frequently Asked Questions about hmos-memory-tier-optimizer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I reduce HarmonyOS app memory usage on low-end devices?

Collect meminfo with hdc, identify dominant memory types (native heap, ArkTS heap, GL), then apply device-tiered schemes such as dynamic cachedCount, image autoResize, Web preload limits, and resource leak fixes. Verify with a before/after PSS comparison.

How to collect HarmonyOS meminfo and UI tree with hdc?

Use hdc shell hidumper --mem <PID> for meminfo, uitest dumpLayout for the UI tree, and uitest screenCap for screenshots. The Skill's collect_memory scripts automate this per platform and save results into a TestData directory.

What is device tiering in HarmonyOS memory optimization?

Device tiering classifies phones as low, medium, or high using RAM size and CPU model, optionally downgraded by cold-start latency. Optimization parameters like cachedCount and Web preload counts are then set per tier instead of hardcoded.

Does this work for Flutter or React Native HarmonyOS projects?

Yes, it includes Flutter-specific rules for Vulkan VMA allocator memory and RN-specific rules for background GC and image resizing. Project type is detected by scanning for src/flutter/ or @rnoh/react-native-openharmony before applying those rules.

Why does ArkTS code review require compile verification?

Text-only review cannot detect type errors such as bigint versus number arithmetic from APIs like hidebug.getSystemMemInfo. The Skill prefers the check_ets_files MCP, falling back to hvigorw assembleHap or manual DevEco Studio compilation.

Will the optimization modify my code automatically?

No. The analysis phase only outputs candidate schemes. Code changes happen only after the user confirms the scheme, affected files, and verification approach, and a git diff patch is generated for review or rollback.