Stability Overview
Stability issues are core factors affecting application availability and user experience. For end users, crashes, freezes, memory anomalies and resource leaks often directly manifest as page exits, interaction failures, performance degradation or abnormal behavior after long-time running. For R&D teams, stability issues not only affect issue counts and version quality, but also affect app ratings, retention and key business metrics.
1. Why Stability Classification First
When stability issues occur, users usually cannot recover by themselves, often requiring app restart. In severe cases, it may cause data loss, feature interruption or long-time page unavailability. Therefore, during troubleshooting, don't treat all issues as "ordinary crashes", but first clarify fault type, then enter corresponding analysis path.
The significance of stability classification mainly includes:
- Helps quickly select correct logs and tools.
- Helps distinguish between process exit, thread blocking, memory anomaly or unreleased resources.
- Helps quickly narrow scope between framework, adaptation layer and business calls.
- Helps form unified issue archiving and governance standards.
2. Stability Issue Classification System
In HarmonyOS scenarios, stability issues can usually be grouped into four major categories.
| Issue Category | Common Sub-types | Typical Characteristics | Main Detection Methods |
|---|---|---|---|
| Application Abnormal Exit | CppCrash, JS Crash | Process directly exits, accompanied by crash logs, exception stacks or error signals | Based on OS signals and runtime exception detection |
| Application Freeze | Thread blocking, input blocking, lifecycle timeout | Interface no response, clicks no reaction, app freezes but process still running | Watchdog mechanism and timeout detection |
| Memory Anomaly | OOM, memory leak, address out-of-bounds | Memory continuous growth, abnormal allocation failure, illegal access | Memory monitoring, address out-of-bounds detection, heap analysis |
| Resource Leak | Handle leak, thread leak, long-term unreleased resources | Resource count abnormally grows after long-time running, eventually causing chain faults | Periodic inspection, threshold detection and resource statistics |
3. Basic Definitions of Each Issue Type
3.1 Application Abnormal Exit
Application abnormal exit refers to process unexpectedly terminating during runtime, usually subdivided into two categories:
- CppCrash: C/C++ runtime crash, usually triggered by null pointer, out-of-bounds access, dangling pointer, abnormal termination, etc. Common signals include SIGSEGV, SIGABRT, SIGBUS, SIGTRAP.
- JS Crash: Unhandled JS exception causing app exit. Common errors include TypeError, ReferenceError, RangeError, etc.
3.2 Application Freeze
Application freeze refers to interface having no response for a long time after user operation, manifesting as clicks no reaction, animation stops, page freezes or system judges as no response. Such issues may not cause process exit, but directly affect interaction availability.
Common scenarios include:
- Main thread executing time-consuming logic for a long time.
- Lock order inconsistency between threads causing deadlock.
- Input event processing timeout.
- Blocking wait during lifecycle switching.
3.3 Memory Anomaly
Memory anomaly includes two common issues:
- OOM: Memory application exceeds runtime environment allocatable limit, app may directly crash. Common characteristics are allocation failure, heap continuous expansion, system recovery pressure rising.
- Address out-of-bounds: Mainly for debugging and stress testing phase discovering illegal memory access issues.
3.4 Resource Leak
Resource leak refers to handles, threads, listeners, timers, request objects or memory objects not released as expected, causing resources occupied for a long time.
4. High-frequency Stability Issues in RNOH Scenarios
In React Native Harmony scenarios, stability issues often concentrate in the following directions:
- Process crash covers C++ side and JS side, possibly from native adaptation layer or unhandled JS exceptions.
- Application no response usually related to blocking, synchronous waiting or lock competition between JS thread, UI thread and Worker thread.
- Memory anomaly and resource leak easily appear in thread objects, callback objects, residual references after instance destruction and long-lifecycle modules.
5. Detection Mechanism Overview
Different fault types have different detection approaches:
- CppCrash: Based on Linux signal mechanism detection, focus on crash signal, FaultLog, crash thread and native backtrace.
- JS Crash: Based on runtime unhandled exception detection, focus on exception type, error message, JS stack and sourcemap restoration result.
- AppFreeze: Based on watchdog and timeout detection, distinguish thread blocking, input blocking and lifecycle timeout.
- Memory Anomaly: Based on memory baseline, peak monitoring, heap snapshot and address out-of-bounds detection.
- Resource Leak: Based on periodic inspection of handle count, thread count, PSS and object survival status.