dumpsys meminfo is an application-level memory analysis tool provided by Android system, displaying detailed memory usage of specific applications. Unlike system-level /proc/meminfo, this command focuses on single application memory breakdown and is a core tool for application memory optimization.
# Method 1: Analyze specific application (recommended)
adb shell "dumpsys meminfo <package_name>"
# Method 2: Analyze by PID
adb shell "dumpsys meminfo <pid>"
# Method 3: Detailed mode (with more details)
adb shell "dumpsys meminfo -d <package_name>"
# Method 4: All applications overview
adb shell "dumpsys meminfo -a"
# Method 5: Save to file for analysis
adb shell "dumpsys meminfo <package_name>" > meminfo.txt$ mem -a -d com.android.launcher3
Applications Memory Usage (in Kilobytes):
Uptime: 277172845 Realtime: 423847246
** MEMINFO in pid 21936 [com.android.launcher3] **
- Applications Memory Usage: Application memory usage report
- Uptime: System uptime (milliseconds)
- Realtime: System actual runtime (milliseconds)
- pid 21936: Application process ID
- [com.android.launcher3]: Application package name
Pss Pss Shared Private Shared Private Swap Rss Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Dirty Total Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 24482 0 2692 24380 0 0 0 27072 39580 24489 11037
Dalvik Heap 3783 0 4596 3588 0 0 0 8184 28651 4075 24576
Dalvik Other 1755 0 1532 1376 0 0 0 2908
Stack 976 0 12 976 0 0 0 988
Ashmem 2 0 4 0 16 0 0 20
Gfx dev 5884 0 0 5884 0 0 0 5884
Other dev 136 0 216 0 0 136 0 352
.so mmap 3294 168 4280 228 22656 168 0 27332
.jar mmap 1084 8 0 0 11616 8 0 11624
.apk mmap 3048 448 0 0 15468 448 0 15916
.ttf mmap 39 0 0 0 200 0 0 200
.dex mmap 54 0 12 4 128 0 0 144
.oat mmap 1169 4 64 0 9040 4 0 9108
.art mmap 2732 4 16136 2012 156 4 0 18308
Other mmap 490 0 36 8 1776 80 0 1900
EGL mtrack 51348 0 0 51348 0 0 0 51348
GL mtrack 4460 0 0 4460 0 0 0 4460
Unknown 793 0 520 784 0 0 0 1304
TOTAL 105529 632 30100 95048 61056 848 0 187052 68231 28564 35613
- Meaning: 🔴 Most Important Metric - Application's actual contribution to system memory
- Calculation: Private + Shared/Number of sharing processes
- Usage: Key data for memory budget allocation and performance evaluation
- Example: Native Heap 24482 kB
- This application's Native memory contributes 24.5MB to system memory pressure
- Meaning: Shared memory portion that can be reclaimed by system
- Characteristics: Can be discarded under memory pressure, reloaded when needed
- Example: .so mmap 168 kB
- Reclaimable code segments in shared libraries
- Meaning: Memory shared by multiple processes and modified
- Characteristics: Cannot be simply reclaimed, needs to be written back to storage
- Problem Diagnosis: Excessively large values may indicate shared memory usage issues
- Meaning: 🔴 Key Metric - Application-exclusive and non-reclaimable memory
- Importance: The portion that truly consumes system memory
- Optimization Priority: Reducing Private Dirty is the core goal of memory optimization
- Meaning: 🟢 Best Memory - Multi-process shared and reclaimable
- Advantages: No additional memory usage, highest efficiency
- Sources: System libraries, APK files, and other read-only resources
- Meaning: Application-private but reclaimable memory
- Characteristics: Can be discarded under memory pressure, reloaded from files
- Meaning: Memory swapped out to storage devices
- Android Characteristics: Most devices show 0 (no traditional swap)
- Performance Impact: Non-zero values indicate high memory pressure, affecting performance
- Meaning: All physical memory currently occupied by the application
- Comparison: Usually larger than Pss Total (includes complete shared memory)
- Heap Size: Total virtual size of heap
- Heap Alloc: Allocated heap memory
- Heap Free: Available heap space
Native Heap 24482 0 2692 24380 0 0 0 27072 39580 24489 11037
-
Pss Total (24482 kB): Native memory contribution to system
- Evaluation Standards:
- Lightweight apps: <20MB
- Regular apps: 20-50MB
- Heavy apps: 50-100MB
- Abnormal: >100MB
- Evaluation Standards:
-
Private Dirty (24380 kB): True Native memory consumption
- Source: C/C++ malloc/new allocations
- Problem Diagnosis: Close to Pss Total indicates mostly private memory
-
Heap Size (39580 kB): Total Native heap space
- Comparison: Size > Alloc indicates reserved space
- Efficiency: Alloc/Size ratio reflects heap utilization
-
Heap Alloc (24489 kB): Actually allocated Native memory
-
Heap Free (11037 kB): Available Native heap space
# Check Native memory leaks
# 1. Compare Native Heap changes before/after operations
adb shell "dumpsys meminfo <package>" | grep "Native Heap"
# 2. Use detailed mode to view Native categories
adb shell "dumpsys meminfo -d <package>"
# 3. Native memory debugging tools
# - AddressSanitizer (ASan)
# - Malloc debug hooks
# - Valgrind (emulator)Optimization Suggestions:
- Check memory allocation and deallocation in JNI code
- Review third-party Native library memory usage
- Use object pools to reduce frequent malloc/free
Dalvik Heap 3783 0 4596 3588 0 0 0 8184 28651 4075 24576
-
Pss Total (3783 kB): Java heap memory contribution
- Evaluation Standards:
- Lightweight apps: <30MB
- Regular apps: 30-80MB
- Heavy apps: 80-200MB
- Abnormal: >200MB
- Evaluation Standards:
-
Shared Dirty (4596 kB): Shared Java heap memory
- Source: System classes shared from Zygote process
- Characteristics: Larger than Private Dirty indicates effective sharing
-
Private Dirty (3588 kB): Application-exclusive Java objects
- Importance: True Java memory usage
- Optimization Priority: Reduce object creation and memory leaks
-
Heap Size (28651 kB): Maximum available Java heap space
-
Heap Alloc (4075 kB): Currently allocated Java memory
-
Heap Free (24576 kB): Available Java heap space
# Java heap utilization
heap_utilization = Heap Alloc / Heap Size * 100%
# Example: 4075 / 28651 * 100% = 14.2%
# Evaluation standards:
# - <30%: Sufficient heap space
# - 30-70%: Normal usage
# - 70-90%: Memory pressure, frequent GC possible
# - >90%: Insufficient memory, performance affected# 1. HPROF analysis of Java objects
python3 tools/hprof_dumper.py -pkg <package>
python3 tools/hprof_parser.py -f <hprof_file>
# 2. GC monitoring
adb shell "dumpsys gfxinfo <package>"
# 3. Memory leak detection
# - LeakCanary automatic detection
# - MAT (Memory Analyzer Tool) analysis Gfx dev 5884 0 0 5884 0 0 0 5884
EGL mtrack 51348 0 0 51348 0 0 0 51348
GL mtrack 4460 0 0 4460 0 0 0 4460
- Gfx dev (5884 kB): GPU device direct memory
- EGL mtrack (51348 kB): EGL graphics memory tracking
- GL mtrack (4460 kB): OpenGL memory tracking
Total Graphics = Gfx dev + EGL mtrack + GL mtrack
= 5884 + 51348 + 4460 = 61692 kB (about 60MB)- Regular apps: <30MB
- Graphics-intensive: 30-100MB
- Game apps: 100-300MB
- Abnormal: >300MB
// 1. Bitmap optimization
BitmapFactory.Options options = new BitmapFactory.Options();
options.inPreferredConfig = Bitmap.Config.RGB_565; // Reduce memory
options.inSampleSize = 2; // Scale down
// 2. Timely recycle
if (bitmap != null && !bitmap.isRecycled()) {
bitmap.recycle();
}
// 3. GPU resource management
// Timely release textures, buffers and other GPU resources .so mmap 3294 168 4280 228 22656 168 0 27332
- High Shared Clean (22656 kB): System libraries shared by multiple processes
- Low Pss (3294 kB): Efficient memory sharing
- Optimization: Demonstrates shared library memory efficiency
.apk mmap 3048 448 0 0 15468 448 0 15916
- Shared Clean (15468 kB): APK code shared by multiple components
- Private Clean (448 kB): Application-specific APK portion
.art mmap 2732 4 16136 2012 156 4 0 18308
- High Shared Dirty (16136 kB): Sharing of ART compiled code
- Performance Optimization: Precompiled code improves execution efficiency
App Summary
Pss(KB) Rss(KB)
------ ------
Java Heap: 5604 26492
Native Heap: 24380 27072
Code: 880 65056
Stack: 976 988
Graphics: 61692 61692
Private Other: 2364
System: 9633
Unknown: 5752
TOTAL PSS: 105529 TOTAL RSS: 187052 TOTAL SWAP (KB): 0
- Calculation: Dalvik Heap + part of Dalvik Other
- Percentage: 5604/105529 = 5.3%
- Evaluation: Low Java memory percentage, app may lean towards Native or graphics
- Percentage: 24380/105529 = 23.1%
- Comparison: About 4:1 ratio with Java Heap
- Analysis: High Native memory usage, need to focus on C/C++ code
- Percentage: 61692/105529 = 58.5%
- Analysis: Graphics memory over half, optimization priority
- Problem: Possibly large number of bitmaps or GPU resources
# Ideal memory distribution (reference)
Java Heap: 30-50% (Current: 5.3%)
Native Heap: 20-30% (Current: 23.1%)
Graphics: 10-30% (Current: 58.5%)
Code: 5-15% (Current: 0.8%)
Other: 5-20% (Current: 12.3%)- 🔴 Graphics memory too high: Needs priority optimization
- 🟡 Java memory low: May over-rely on Native
- 🟢 Code memory reasonable: High sharing efficiency
Objects
Views: 114 ViewRootImpl: 1
AppContexts: 9 Activities: 1
Assets: 7 AssetManagers: 0
Local Binders: 39 Proxy Binders: 41
Parcel memory: 17 Parcel count: 75
Death Recipients: 1 OpenSSL Sockets: 0
WebViews: 0
- Views (114): Number of View objects
- Evaluation: Reasonable count, large interfaces may have more
- Optimization: Reduce unnecessary View hierarchy
- ViewRootImpl (1): Root view implementation
- Normal: Usually corresponds to Activity count
- AppContexts (9): Number of application contexts
- Source: Application, Service, Activity, etc.
- Problem: Too many may indicate Context leaks
- Activities (1): Activity instance count
- Normal: Corresponds to currently active Activities
- Local Binders (39): Local Binder objects
- Proxy Binders (41): Proxy Binder objects
- Parcel (17/75): Serialized object memory/count
# Monitor object count changes
# 1. Get baseline data
adb shell "dumpsys meminfo <package>" | grep -A 15 "Objects"
# 2. Detect again after operations
# 3. Compare object count changes
# Focus on:
# - Activities > 2: Possible Activity leaks
# - Views continuously growing: Possible View leaks
# - AppContexts abnormally high: Context leaks# Symptoms: Dalvik Heap continuously growing
# Before: Dalvik Heap 3783 kB
# After: Dalvik Heap 8756 kB (growth 4973 kB)
# Diagnosis process:
# 1. Compare meminfo before/after operations
# 2. Check Heap Alloc and Objects count changes
# 3. Use HPROF to analyze specific objects# Symptoms: Graphics memory abnormal growth
# EGL mtrack 51348 kB → 85672 kB
# Common causes:
# - Bitmaps not timely recycled
# - GPU resources not released
# - Texture memory accumulationGraphics: 61692 kB (58.5% of total)
# Problem: Graphics memory percentage too high
# Normal: Should be 10-30%# Possible reasons:
# - Main application logic in Native layer
# - Over-reliance on C/C++ implementation
# - Graphics rendering dominates
# Evaluation:
# - Check if architecture design is reasonable
# - Consider Java/Native balance- Total PSS: <80MB
- Java Heap: 20-40% of total memory
- Native Heap: 20-40% of total memory
- Graphics: <20% of total memory
- Heap Utilization: 30-70%
- Total PSS: 80-150MB
- Graphics: 20-40% of total memory
- Object Count: Within reasonable range
- No obvious memory leaks
- Total PSS: 150-250MB
- Graphics: 40-60% of total memory
- Heap Utilization: >80%
- Object Count: Somewhat high
- Total PSS: >250MB
- Graphics: >60% of total memory
- Obvious Memory Leaks: Abnormal Activity/View counts
- Frequent OOM: Out of memory
- System Level: /proc/meminfo Interpretation Guide
- Process Level: showmap Interpretation Guide
- Detailed Mapping: smaps Interpretation Guide
- Analysis Results: Results Interpretation Guide
- One-click Analysis:
python3 analyze.py live --package <package> - Panorama Analysis:
python3 analyze.py panorama -d ./dump - HPROF Analysis:
python3 tools/hprof_dumper.py/python3 tools/hprof_parser.py - SMAPS Parsing:
python3 tools/smaps_parser.py - Meminfo Parsing:
python3 tools/meminfo_parser.py -f meminfo.txt
- Android Studio Profiler: Real-time memory monitoring
- MAT (Memory Analyzer Tool): Java heap analysis
- LeakCanary: Automatic memory leak detection
# Establish memory monitoring baseline
./scripts/meminfo_monitor.sh com.example.app
# Key checkpoint detection
# - After app startup
# - After main feature usage
# - After long-term running
# - Before/after memory-sensitive operations- Quick Assessment: Check App Summary memory distribution
- Anomaly Identification: Focus on memory types with high percentages
- Detailed Analysis: Use corresponding tools for in-depth analysis
- Trend Monitoring: Compare data across multiple time points
- Graphics Memory: If percentage >40%, prioritize bitmap and GPU usage optimization
- Java Heap: If continuously growing, focus on HPROF analysis
- Native Heap: If oversized, check C/C++ code and third-party libraries
- Object Leaks: Abnormal Activity/View counts need immediate handling
- Establish memory usage standards and Code Review checkpoints
- Integrate automated memory detection tools
- Regularly conduct memory stress testing
- Establish memory usage monitoring and alerting mechanisms
Through deep understanding of every item in dumpsys meminfo output, you can accurately diagnose application memory issues and develop targeted optimization strategies to significantly improve application memory performance.