AI-Assisted Issue Diagnosis Guide
This document introduces how to use AI capabilities to assist developers in quickly diagnosing three types of common issues: performance issues, stability issues, and feature issues.
AI Diagnosis Skill Overview
| Issue Type | Skill Name | Applicable Scenarios |
|---|---|---|
| Stability Issues | rnoh-stability-triage | Crash, freeze, memory anomalies, resource leaks, etc. |
| Stability Code Review | rnoh-stability-review | Code-level stability risk prediction |
| Performance Issues | rnoh-performance-diagnosis | Render lag, slow startup, high memory usage, etc. |
| Feature Issues | rnoh-feature-diagnosis | Feature anomalies, API not working, component behavior issues, etc. |
1. Stability Issue Diagnosis
1.1 Applicable Scenarios
Use rnoh-stability-triage skill when encountering:
- Application abnormal exit (crash, flash exit)
- Application freeze (UI stuck, no response)
- Memory anomalies (OOM, continuous memory growth)
- Resource leaks (handles/threads/listeners not released)
- SIGSEGV, SIGABRT, SIGBUS, SIGTRAP signals
- UAF (use-after-free), null pointer, deadlock
1.2 Minimum Required Input
Before using AI-assisted diagnosis, prepare:
-
Crash Logs
- FaultLog, CppCrash logs
- Native backtrace
- JS exception stack (if JS Crash)
-
Version Information
- RNOH version (e.g., 0.72.53, 0.77.18, 0.82.3)
- React Native version
- HarmonyOS API Level
-
Trigger Scenario
- Startup phase, page switch, instance destruction, animation execution, image loading, etc.
-
Runtime Logs
- hilog, startup logs, lifecycle logs
1.3 AI Analysis Process
User Input → Problem Profile Extraction → Historical Fix Matching → Code Verification → Attribution Judgment → Fix Suggestions
Step 1: Extract Problem Profile
AI extracts the following five-tuple from logs:
- Phenomenon: crash/freeze/OOM/leak
- Category: abnormal exit/freeze/memory anomaly/resource leak
- Thread or Error: JS thread, main thread, SIGSEGV, etc.
- Module: ImageComponentInstance, JSVMRuntime, etc.
- Trigger Phase: startup, destruction, animation, etc.
Step 2: Historical Fix Matching
AI first checks historical stability fix summaries to determine if issue was fixed in later versions:
- 0.72 stability fixes (approx. 95 entries)
- 0.77 stability fixes (approx. 42 entries)
- 0.82 stability fixes (approx. 19 entries)
Step 3: Attribution Judgment
AI provides three attribution results:
- More like framework issue
- More like user code issue
- Cannot determine yet (need more information)
1.4 Usage Example
Input Example:
Use rnoh-stability-triage to analyze:
FaultLog:
Signal: SIGSEGV
Crash thread: JS thread
Backtrace:
#00 pc 00012345 librnoh_core.so (ImageComponentInstance::onImageLoad+124)
#01 pc 00023456 librnoh_core.so (ImageComponentInstance::handleCallback+56)
Version: 0.82.1
Trigger Scenario: Crash when re-entering page after exit
Output Format:
# Stability Issue Analysis
## 1. Conclusion Summary
Issue Category: Application abnormal exit (SIGSEGV)
Trigger Phase: Callback continues execution after instance destruction
Confidence: High
## 2. Historical Fix Match
Matched: Image callback later than instance destruction causing dangling URI crash (0.82.3)
Commit: [409e3d355](https://gitcode.com/OpenHarmony-RN/ohos_react_native/commit/409e3d355...)
MR: [!1985](https://gitcode.com/OpenHarmony-RN/ohos_react_native/merge_requests/1985)
## 3. Attribution Judgment
Conclusion: More like framework issue
Reason: Crash stack in framework internal module, highly matches historical fix
## 4. Fix Suggestions
1. Upgrade to 0.82.3 or later version
2. If unable to upgrade, backport commit 409e3d355 patch
1.5 Code Review Skill
For code-level stability risk prediction, use rnoh-stability-review skill:
Applicable Scenarios:
- Self-check before PR submission
- Systematic review during code review
- Already identified suspicious module, need code-level confirmation
Review Categories:
- A: Abnormal exit risks (post-destruction access, initialization timing, noexcept misuse, etc.)
- B: Freeze risks (lock order, lock re-entry, holding-lock callback, etc.)
- C: Memory anomaly risks (circular reference, UAF typical paths, etc.)
- D: Resource leak risks (listeners not unregistered, threads not reclaimed, etc.)
- E: Huawei official general specs (Node-API, libuv, ArkUI, etc.)
2. Performance Issue Diagnosis
2.1 Applicable Scenarios
Use rnoh-performance-diagnosis skill when encountering:
- Page render lag, frame drops
- Slow application startup
- Scroll/slide not smooth
- Animation execution lag
- Abnormally high memory usage
- Continuously high CPU usage
2.2 Issue Classification
| Category | Typical Phenomenon | Diagnosis Focus |
|---|---|---|
| Render Performance | UI lag, frame drops, animation lag | Layout time, component hierarchy, re-render |
| Startup Performance | Slow cold start, slow first screen load | Bundle loading, initialization chain, preload |
| Memory Performance | High memory usage, OOM | Object holding, cache strategy, image resources |
| List Performance | Scroll lag, slow list loading | renderItem complexity, virtual list config |
| Communication Performance | Slow JS-Native interaction | TurboModule call frequency, serialization overhead |
2.3 Minimum Required Input
-
Performance Data
- Trace analysis results
- Frame rate data (FPS)
- Memory usage curve
- CPU usage rate
-
Scenario Description
- Specific page/component with issue
- Operation sequence (e.g., enter page → scroll list → exit)
- Expected vs actual behavior
-
Code Context
- Related component code snippets
- List configuration (FlatList/FlashList parameters)
- TurboModule call method
2.4 Common Performance Issues and Solutions
| Issue | Common Cause | Solution |
|---|---|---|
| Page render lag | Deep component hierarchy, frequent re-render | Reduce hierarchy, use memo/shouldComponentUpdate, avoid creating objects in render |
| List scroll lag | Complex renderItem, no virtual list | Use FlashList/FlatList, optimize renderItem, set correct windowSize |
| Slow startup | Large bundle, long initialization chain | Use HBC bytecode, preload, lazy load non-critical modules |
| Slow image loading | Uncompressed images, no cache | Compress images, use image cache, preload key images |
| Animation lag | useNativeDriver=false | Use useNativeDriver=true, use transform instead of top/left |
3. Feature Issue Diagnosis
3.1 Applicable Scenarios
Use rnoh-feature-diagnosis skill when encountering:
- API call not working or returning abnormal values
- Component behavior differs from expected
- Event callback not triggered or triggered abnormally
- Configuration not taking effect
- Platform differences causing feature anomalies
3.2 Issue Classification
| Category | Typical Phenomenon | Diagnosis Focus |
|---|---|---|
| API Issues | Call returns null/undefined, Promise not resolved | API version support, parameter validity, TurboModule config |
| Component Issues | Display abnormal, interaction abnormal, style abnormal | Component properties, event handling, platform adaptation |
| Event Issues | Callback not triggered, wrong trigger timing | Event registration, lifecycle, listener management |
| Config Issues | Config not taking effect, abnormal default values | Config method, priority, version compatibility |
| Platform Issues | HarmonyOS differs from iOS/Android | Platform difference docs, spec explanation |
3.3 Common Feature Issues and Solutions
| Issue | Common Cause | Solution |
|---|---|---|
| API returns null/undefined | API not supported in this version, illegal parameter | Check version support docs, validate parameters, use fallback |
| StatusBar style not working | HarmonyOS is system-level UI, not bound to page | Manually reset on page switch, wrap cross-platform component |
| Keyboard event not triggered | RN not in topmost child window, listener not registered correctly | Adjust window level, check listener registration method |
| Image loading failed | Wrong path format, sandbox path config issue | Use correct path format, refer to sandbox loading sample |
| Modal still showing after close | ArkUI Dialog at window topmost layer | Proactively close on page switch, use View to implement modal effect |
| Linking.canOpenURL returns false | scheme not configured in module.json5 | Configure target app scheme in querySchemes |
4. Best Practices
4.1 General Principles for Issue Diagnosis
- Classify first, then deep dive: Clarify issue type before targeted diagnosis
- Minimum input: Don't require all information from user, analyze based on available info
- Evidence first: Conclusions need evidence support, no guessing
- Progressive convergence: First give tendency, then evidence, finally confidence level
- Executable suggestions: Give specific executable next actions
4.2 Notes for Using AI Assistance
- Provide accurate version number: Historical fix matching depends on version boundary
- Describe specific scenario: Avoid vague description, explain specific operation sequence
- Provide key logs: FaultLog, hilog are key for crash diagnosis
- Include code snippets: Code review needs specific code context
- Feedback analysis results: After AI analysis, provide more information to continue convergence
4.3 Issue Diagnosis Flowchart
Issue Discovery → Determine Issue Type → Prepare Required Info → Use Corresponding Skill → AI Analysis → Verify Conclusion → Execute Fix
↓ ↓
Stability/Performance/Feature Provide more info to continue analysis