Зверніть увагу, що використання пам'яті в сучасних операційних системах, таких як Linux, є надзвичайно складною і важко зрозумілою областю. Насправді шанси на те, що ви дійсно правильно інтерпретіруете будь-які цифри, які ви отримуєте, вкрай низькі. (Практично кожен раз, коли я дивлюся на номери використання пам'яті з іншими інженерами, завжди є довга дискусія про те, що вони насправді означають, що тільки призводить до невиразним висновків.)
Примітка. Тепер у нас є набагато більш велика документація з управління пам'яттю вашого застосування, яка охоплює більшу частину матеріалу тут і сучасніша зі станом Android.
Перш за все, ймовірно, прочитайте останню частину цієї статті, в якій обговорюється, як управляється пам'ять на Android:
Перебуваючи на більш низькому рівні, ви можете використовувати API Debug для отримання вихідної інформації про рівень пам'яті на рівні ядра: android.os.Debug.MemoryInfo
Зверніть увагу, що починаючи з версії 2.0 є API, ActivityManager.getProcessMemoryInfo. щоб отримати цю інформацію про інший процес: ActivityManager.getProcessMemoryInfo (int [])
Це повертає низкоуровневую структуру MemoryInfo з усіма цими даними:
Але що стосується різниці між Pss. PrivateDirty і SharedDirty. ну, тепер починається найцікавіше.
Велика частина пам'яті в Android (і Linux-системах в цілому) фактично поділяється між кількома процесами. Отже, скільки пам'яті використовує процес, насправді неясно. Додайте поверх цього пейджінга на диск (не кажучи вже про обмін, який ми не використовуємо на Android), і це ще менш зрозуміло.
Таким чином, якщо ви повинні були відібрати всю фізичну RAM, фактично відображається для кожного процесу, і додати всі процеси, ви, ймовірно, в кінцевому підсумку отримаєте число, набагато більше, ніж фактична кількість оперативної пам'яті.
Номер Pss - це метрика, яку обчислює ядро, яке враховує спільне використання пам'яті - в основному кожна сторінка ОЗУ в процесі масштабується співвідношенням кількості інших процесів, також використовують цю сторінку. Таким чином, ви можете (теоретично) додати pss в усі процеси, щоб побачити загальну RAM, яку вони використовують, і порівняти pss між процесами, щоб отримати приблизне уявлення про їх відносному вазі.
Іншою цікавою метрикою тут є PrivateDirty. який являє собою в основному обсяг оперативної пам'яті всередині процесу, який не можна вивантажити на диск (він не підтримується одними і тими ж даними на диску) і не використовується ні з якими іншими процесами. Інший спосіб поглянути на це - це ОЗУ, яке стане доступним для системи, коли цей процес піде (і, ймовірно, швидко включиться в кеши і інші його застосування).
Для цього це API SDK. Однак ви можете зробити це як розробник за допомогою свого пристрою.
Якщо ви просто хочете подивитися на використання пам'яті в усіх процесах, ви можете використовувати команду adb shell procrank. Висновок цього в тій же системі виглядає наступним чином:
Pss. як ми бачили раніше, і Uss Priv Dirty.
Цікаво відзначити тут: Pss і Uss трохи (або трохи більше) відрізняються від того, що ми бачили в meminfo. Чому це? Прокранк використовує інший механізм ядра для збору своїх даних, ніж meminfo. і дає дещо різні результати. Чому це? Чесно кажучи, я поняття не маю. Я вважаю, що procrank може бути більш точним. але насправді це просто залиште точку: «Візьміть будь-яку інформацію про пам'ять, яку ви отримаєте з сіллю, часто дуже великим зерном».
Нарешті, є команда adb shell cat / proc / meminfo яка дає короткий опис загального використання пам'яті в системі. Тут багато даних, тільки перші кілька номерів, про які варто поговорити (а решта з них зрозумілі кільком людям, і мої запитання про тих небагатьох людей про них часто призводять до суперечливих пояснень):
MemTotal - це загальний обсяг пам'яті, доступний ядру і призначеного для користувача простору (часто менше, ніж фактичне фізичне ОЗУ пристрою, оскільки деякі з цих ОЗУ необхідні для радіо, буферів DMA і т. Д.).
MemFree - це обсяг оперативної пам'яті, який взагалі не використовується. Номер, який ви бачите тут, дуже високий; Як правило, в системі Android це буде всього лише кілька МБ, оскільки ми намагаємося використовувати доступну пам'ять для підтримки процесів
Cached - це оперативна пам'ять, яка використовується для кешей файлової системи і інших подібних речей. Для типових систем потрібно 20 МБ або близько того, щоб уникнути попадання в погані стану пошукового виклику; Забійний вбивця Android не налаштований для конкретної системи, щоб переконатися, що фонові процеси вбиті до того, як кешована ОЗУ буде занадто багато споживатися ними, щоб привести до такого пошуковому викликом.
Так, ви можете отримати інформацію про пам'ять програмно і вирішити, чи слід робити інтенсивну роботу з пам'яттю.
Отримайте розмір купи VM, зателефонувавши:
Отримайте виділену пам'ять VM, зателефонувавши:
Отримайте обмеження розміру купи VM, зателефонувавши:
Отримайте внутрішню виділену пам'ять, викликавши:
Я зробив додаток, щоб з'ясувати поведінку OutOfMemoryError і контролювати використання пам'яті.
Це незавершене виробництво, але я цього не розумію:
Чому PID НЕ зіставляється з результатом в activityManager.getProcessMemoryInfo ()? Очевидно, що ви хочете, щоб отримані результуючі дані були значущими, чому Google настільки ускладнив кореляцію результатів? Поточна система навіть не працює, якщо я хочу обробити всі використання пам'яті, так як повертається результат являє собою масив об'єктів android.os.Debug.MemoryInfo, але жоден з цих об'єктів насправді не говорить вам, з якими pids вони пов'язані. Якщо ви просто передасте масив всіх pids, ви не зможете зрозуміти результати. Наскільки я розумію, це використання, це робить безглуздим передачу більш ніж одного pid за раз, а потім, якщо це так, навіщо робити так, щоб ActivityManager.getProcessMemoryInfo () брав тільки масив int?
Hackbod's - один з кращих відповідей на переповнення стека. Він проливає світло на дуже неясну тему. Це мені дуже допомогло.
Статистика процесу, служба, щоб дізнатися, як ваш додаток управляє пам'яттю, пояснено в повідомленні в блозі. Статистика процесу: розуміння того, як ваш додаток використовує RAM від Dianne Hackborn:
1) Вважаю, немає, по крайней мере, не від Java.
2)
Android Studio 0.8.10+ представила неймовірно корисний інструмент під назвою Memory Monitor.
Що це добре для:
- Відображення даних та зайнятої пам'яті в графіку і події збору сміття з плином часу.
- Швидке тестування на повільність програми може бути пов'язано з надмірними подіями збору сміття.
- Швидке тестування збоїв додатків може бути пов'язано з нестачею пам'яті.
Малюнок 1. Примушування події GC (збірка сміття) на моніторі Android Memory
Використовуючи це, ви можете отримати багато корисної інформації про споживання оперативної пам'яті вашого застосування в режимі реального часу.