Как я могу найти память, используемую в приложении для Android, программно?
Я надеюсь, что есть способ сделать это. Кроме того, как мне получить бесплатную память телефона?
Как узнать использование памяти моего приложения в Android?
Ответ 1
Обратите внимание, что использование памяти в современных операционных системах, таких как Linux, представляет собой чрезвычайно сложную и трудно понятную область. На самом деле шансы на то, что вы действительно правильно интерпретируете все, что вы получаете, крайне низки. (Практически каждый раз, когда я смотрю на номера использования памяти с другими инженерами, всегда есть длинная дискуссия о том, что они на самом деле означают, что только приводит к неопределенному заключению.)
Примечание: теперь у нас есть гораздо более обширная документация по Управление памятью приложений, которая покрывает большую часть материала здесь и больше -то-дата с состоянием Android.
Прежде всего, возможно, прочитайте последнюю часть этой статьи, в которой обсуждается, как управляется память на Android:
Изменения API сервисов, начиная с Android 2.0
Теперь ActivityManager.getMemoryInfo() - это наш API самого высокого уровня для просмотра общего использования памяти. В основном это помогает определить, насколько близко система приближается к отсутствию памяти для фоновых процессов, поэтому необходимо начать убивать необходимые процессы, такие как службы. Для чистых приложений Java это должно быть малопригодно, так как ограничение кучи Java частично отчасти позволяет избежать того, что одно приложение не сможет подчеркнуть систему до этой точки.
Переход на более низкий уровень, вы можете использовать API отладки для получения информации об использовании памяти на уровне ядра: android.os.Debug.MemoryInfo
Обратите внимание, что начиная с версии 2.0 существует также API, ActivityManager.getProcessMemoryInfo, чтобы получить эту информацию о другом процессе: ActivityManager.getProcessMemoryInfo(int [])
Это возвращает низкоуровневую структуру MemoryInfo со всеми этими данными:
/** The proportional set size for dalvik. */
public int dalvikPss;
/** The private dirty pages used by dalvik. */
public int dalvikPrivateDirty;
/** The shared dirty pages used by dalvik. */
public int dalvikSharedDirty;
/** The proportional set size for the native heap. */
public int nativePss;
/** The private dirty pages used by the native heap. */
public int nativePrivateDirty;
/** The shared dirty pages used by the native heap. */
public int nativeSharedDirty;
/** The proportional set size for everything else. */
public int otherPss;
/** The private dirty pages used by everything else. */
public int otherPrivateDirty;
/** The shared dirty pages used by everything else. */
public int otherSharedDirty;
Но что касается разницы между Pss, PrivateDirty и SharedDirty... ну, теперь начинается забава.
Большая часть памяти в Android (и Linux-системах в целом) фактически разделяется между несколькими процессами. Итак, сколько памяти использует процесс, на самом деле неясно. Добавьте поверх этого пейджинга на диск (не говоря уже об обмене, который мы не используем на Android), и это еще менее понятно.
Таким образом, если вы должны были отобрать всю физическую RAM, фактически отображаемую в каждом процессе, и добавить все процессы, вы, вероятно, в конечном итоге получили бы число, намного большее, чем фактическая общая оперативная память.
Число Pss - это метрика, которую вычисляет ядро, которое учитывает совместное использование памяти - в основном каждая страница ОЗУ в процессе масштабируется соотношением количества других процессов, также использующих эту страницу. Таким образом, вы можете (теоретически) добавить pss во все процессы, чтобы увидеть общую RAM, которую они используют, и сравнить pss между процессами, чтобы получить приблизительное представление об их относительном весе.
Другим интересным показателем является PrivateDirty, который представляет собой в основном объем ОЗУ внутри процесса, который не может быть выгружен на диск (он не поддерживается одними и теми же данными на диске) и не используется совместно с другими процессы. Другой способ взглянуть на это - это ОЗУ, которое станет доступным системе, когда этот процесс уйдет (и, вероятно, быстро включится в кеши и другие его применения).
В этом почти все API-интерфейсы SDK. Однако вы можете сделать это как разработчик с помощью своего устройства.
Используя adb, вы можете получить много информации о работе используемой системы. Обычной является команда adb shell dumpsys meminfo, которая выплевывает кучу информации об использовании памяти в каждом процессе Java, содержащей вышеуказанную информацию, а также множество других вещей. Вы также можете использовать имя или pid одного процесса, чтобы увидеть, например, adb shell dumpsys meminfo system дать мне системный процесс:
** MEMINFO in pid 890 [system] **
native dalvik other total
size: 10940 7047 N/A 17987
allocated: 8943 5516 N/A 14459
free: 336 1531 N/A 1867
(Pss): 4585 9282 11916 25783
(shared dirty): 2184 3596 916 6696
(priv dirty): 4504 5956 7456 17916
Objects
Views: 149 ViewRoots: 4
AppContexts: 13 Activities: 0
Assets: 4 AssetManagers: 4
Local Binders: 141 Proxy Binders: 158
Death Recipients: 49
OpenSSL Sockets: 0
SQL
heap: 205 dbFiles: 0
numPagers: 0 inactivePageKB: 0
activePageKB: 0
Верхний раздел является основным, где size - это общий размер в адресном пространстве конкретной кучи, allocated - это kb фактических распределений, которые куча думает, что он имеет, free - оставшийся kb free куча имеет дополнительные распределения, а Pss и priv dirty такие же, как обсуждалось ранее, для конкретных страниц, связанных с каждой из кучек.
Если вы просто хотите посмотреть на использование памяти во всех процессах, вы можете использовать команду adb shell procrank. Вывод этого в той же системе выглядит следующим образом:
PID Vss Rss Pss Uss cmdline 890 84456K 48668K 25850K 21284K system_server 1231 50748K 39088K 17587K 13792K com.android.launcher2 947 34488K 28528K 10834K 9308K com.android.wallpaper 987 26964K 26956K 8751K 7308K com.google.process.gapps 954 24300K 24296K 6249K 4824K com.android.phone 948 23020K 23016K 5864K 4748K com.android.inputmethod.latin 888 25728K 25724K 5774K 3668K zygote 977 24100K 24096K 5667K 4340K android.process.acore ... 59 336K 332K 99K 92K /system/bin/installd 60 396K 392K 93K 84K /system/bin/keystore 51 280K 276K 74K 68K /system/bin/servicemanager 54 256K 252K 69K 64K /system/bin/debuggerd
Здесь столбцы Vss и Rss в основном представляют собой шум (это прямое адресное пространство и использование ОЗУ в процессе, где, если вы добавляете использование ОЗУ в процессы, вы получаете смехотворно большое количество).
Pss, как мы видели ранее, а Uss - priv dirty.
Интересно отметить здесь: Pss и Uss немного (или несколько больше), чем то, что мы видели в meminfo. Почему это? Ну procrank использует другой механизм ядра для сбора своих данных, чем meminfo, и они дают несколько разные результаты. Почему это? Честно говоря, я понятия не имею. Я считаю, что procrank может быть более точным... но на самом деле это просто оставляет точку: "возьмите любую информацию о памяти, которую вы получите с зерном соли, часто очень крупным зерном".
Наконец, есть команда adb shell cat /proc/meminfo, которая дает краткое описание общего использования памяти в системе. Здесь много данных, а только первые несколько номеров, о которых стоит обсудить (а остальные - мало кто знает, а мои вопросы о тех немногих людей о них часто приводят к противоречивым объяснениям):
MemTotal: 395144 kB MemFree: 184936 kB Buffers: 880 kB Cached: 84104 kB SwapCached: 0 kB
MemTotal - общий объем памяти, доступный ядру и пользовательскому пространству (часто меньше, чем фактическое физическое ОЗУ устройства, так как часть этого ОЗУ необходима для радио, буферов DMA и т.д.).
MemFree - объем ОЗУ, который вообще не используется. Номер, который вы видите здесь, очень высок; как правило, в системе Android это будет всего лишь несколько МБ, поскольку мы пытаемся использовать доступную память, чтобы поддерживать процессы, выполняемые
Cached - ОЗУ, используемая для кэшей файловой системы и других подобных вещей. Для типичных систем потребуется 20 МБ или около того, чтобы избежать попадания в плохие состояния поискового вызова; убойный убийца Android из памяти настроен для конкретной системы, чтобы убедиться, что фоновые процессы убиты до того, как кэшированная ОЗУ будет слишком много потребляться ими, чтобы привести к такому поисковому вызову.
Ответ 2
Да, вы можете получить информацию о памяти программно и решить, следует ли делать интенсивную работу с памятью.
Получить размер кучи VM, вызвав:
Runtime.getRuntime().totalMemory();
Получите выделенную память VM, вызвав:
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
Получить ограничение размера кучи VM, вызвав:
Runtime.getRuntime().maxMemory()
Получить внутреннюю выделенную память, вызвав:
Debug.getNativeHeapAllocatedSize();
Я сделал приложение, чтобы выяснить поведение OutOfMemoryError и контролировать использование памяти.
https://play.google.com/store/apps/details?id=net.coocood.oomresearch
Вы можете получить исходный код на https://github.com/coocood/oom-research
Ответ 3
Это незавершенное производство, но этого я не понимаю:
ActivityManager activityManager = (ActivityManager) context.getSystemService(ACTIVITY_SERVICE);
MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
activityManager.getMemoryInfo(memoryInfo);
Log.i(TAG, " memoryInfo.availMem " + memoryInfo.availMem + "\n" );
Log.i(TAG, " memoryInfo.lowMemory " + memoryInfo.lowMemory + "\n" );
Log.i(TAG, " memoryInfo.threshold " + memoryInfo.threshold + "\n" );
List<RunningAppProcessInfo> runningAppProcesses = activityManager.getRunningAppProcesses();
Map<Integer, String> pidMap = new TreeMap<Integer, String>();
for (RunningAppProcessInfo runningAppProcessInfo : runningAppProcesses)
{
pidMap.put(runningAppProcessInfo.pid, runningAppProcessInfo.processName);
}
Collection<Integer> keys = pidMap.keySet();
for(int key : keys)
{
int pids[] = new int[1];
pids[0] = key;
android.os.Debug.MemoryInfo[] memoryInfoArray = activityManager.getProcessMemoryInfo(pids);
for(android.os.Debug.MemoryInfo pidMemoryInfo: memoryInfoArray)
{
Log.i(TAG, String.format("** MEMINFO in pid %d [%s] **\n",pids[0],pidMap.get(pids[0])));
Log.i(TAG, " pidMemoryInfo.getTotalPrivateDirty(): " + pidMemoryInfo.getTotalPrivateDirty() + "\n");
Log.i(TAG, " pidMemoryInfo.getTotalPss(): " + pidMemoryInfo.getTotalPss() + "\n");
Log.i(TAG, " pidMemoryInfo.getTotalSharedDirty(): " + pidMemoryInfo.getTotalSharedDirty() + "\n");
}
}
Почему PID не сопоставляется с результатом в activityManager.getProcessMemoryInfo()? Очевидно, что вы хотите, чтобы полученные результирующие данные были значимыми, почему Google настолько затруднил корреляцию результатов? Текущая система даже не работает, если я хочу обработать все использование памяти, поскольку возвращаемый результат представляет собой массив объектов android.os.Debug.MemoryInfo, но ни один из этих объектов не говорит вам, с какими связями они связаны. Если вы просто передадите массив всех pids, вы не сможете понять результаты. Насколько я понимаю, это использование, это делает бессмысленным передавать более чем за один pid за раз, а затем, если это так, зачем делать так, чтобы activityManager.getProcessMemoryInfo() принимал только массив int?
Ответ 4
Hackbod - один из лучших ответов на Stack Overflow. Он проливает свет на очень неясную тему. Это очень помогло мне.
Другим очень полезным ресурсом является обязательное видео: Google I/O 2011: управление памятью для приложений Android
UPDATE:
Статистика процесса, служба, чтобы узнать, как ваше приложение управляет памятью, объясняется в сообщении блога Статистика процесса: понимание того, как ваше приложение использует ОЗУ от Dianne Hackborn:
Ответ 5
Android Studio 0.8.10+ представила невероятно полезный инструмент под названием Монитор памяти.
Что это хорошо для:
- Отображение доступной и используемой памяти на графике и сборка мусора событий со временем.
- Быстрое тестирование того, может ли медленность приложения связанных с чрезмерными событиями сбора мусора.
- Быстрое тестирование могут ли проблемы со сбоями приложений быть исчерпаны.
Рисунок 1. Принуждение события GC (сборка мусора) на мониторе Android Memory
У вас может быть много хорошей информации о потреблении оперативной памяти приложения в режиме реального времени, используя его.
Ответ 6
1) Я думаю, нет, по крайней мере, не из Java.
2)
ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
MemoryInfo mi = new MemoryInfo();
activityManager.getMemoryInfo(mi);
Log.i("memory free", "" + mi.availMem);
Ответ 7
Мы выяснили, что все стандартные способы получения полной памяти текущего процесса имеют некоторые проблемы.
-
Runtime.getRuntime().totalMemory(): возвращает только память JVM -
ActivityManager.getMemoryInfo(),Process.getFreeMemory()и все остальное на основе/proc/meminfo- возвращает информацию о памяти обо всех процессах (например android_util_Process.cpp) -
Debug.getNativeHeapAllocatedSize()- используетmallinfo(), который возвращает информацию о распределении памяти, выполняемую толькоmalloc()и связанными функциями (см. android_os_Debug.cpp) -
Debug.getMemoryInfo()- делает работу, но она слишком медленная. Он занимает около 200 мс на Nexus 6 для одного вызова. Накладные расходы производительности делают эту функцию бесполезной для нас, как мы ее называем регулярно, и каждый вызов довольно заметен (см. android_os_Debug.cpp) -
ActivityManager.getProcessMemoryInfo(int[])- вызываетDebug.getMemoryInfo()внутренне (см. ActivityManagerService.java)
Наконец, мы закончили использование следующего кода:
const long pageSize = 4 * 1024; //`sysconf(_SC_PAGESIZE)`
string stats = File.ReadAllText("/proc/self/statm");
var statsArr = stats.Split(new [] {' ', '\t', '\n'}, 3);
if( statsArr.Length < 2 )
throw new Exception("Parsing error of /proc/self/statm: " + stats);
return long.Parse(statsArr[1]) * pageSize;
Он возвращает метку VmRSS. Вы можете найти более подробную информацию об этом здесь: один, два и три.
PS Я заметил, что в теме по-прежнему отсутствует фактический и простой фрагмент кода о том, как оценить использование частной памяти в частной памяти, если производительность не является критическим требованием:
Debug.MemoryInfo memInfo = new Debug.MemoryInfo();
Debug.getMemoryInfo(memInfo);
long res = memInfo.getTotalPrivateDirty();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT)
res += memInfo.getTotalPrivateClean();
return res * 1024L;
Ответ 8
Выше приведено много ответов, которые определенно помогут вам, но (после 2 дней использования и изучения инструментов памяти adb) я думаю, что тоже могу помочь с моим мнением.
Как говорит Хэкбод: Таким образом, если бы вы взяли все физическое ОЗУ, фактически сопоставленное каждому процессу, и суммировали все процессы, вы, вероятно, в итоге получили бы число, намного превышающее фактическое общее ОЗУ. таким образом, вы не сможете получить точное количество памяти на процесс.
Но вы можете приблизиться к этому по некоторой логике.. и я расскажу, как..
Есть некоторые API, такие как
android.os.Debug.MemoryInfoиActivityManager.getMemoryInfo()упомянутые выше, о которых вы, возможно, уже читали и использовали, но я расскажу о другом способе
Итак, во-первых, вам нужно быть пользователем root, чтобы все заработало. Войдите в консоль с правами суперпользователя, выполнив su в процессе, и получите его output and input stream. Затем передайте id\n (enter) в ouputstream и запишите его для обработки выходных данных. Если вы получите входной поток, содержащий uid=0, вы являетесь пользователем root.
Теперь вот логика, которую вы будете использовать в процессе выше
Когда вы получаете ouputstream процесса, передайте команду (procrank, dumpsys meminfo и т.д.) С \n вместо id и получите его inputstream и прочитайте, сохраните поток в байтах [], char [] и т.д. Используйте необработанные данные..и вы сделали !!!!!
разрешение:
<uses-permission android:name="android.permission.FACTORY_TEST"/>
Проверьте, являетесь ли вы пользователем root:
// su command to get root access
Process process = Runtime.getRuntime().exec("su");
DataOutputStream dataOutputStream =
new DataOutputStream(process.getOutputStream());
DataInputStream dataInputStream =
new DataInputStream(process.getInputStream());
if (dataInputStream != null && dataOutputStream != null) {
// write id to console with enter
dataOutputStream.writeBytes("id\n");
dataOutputStream.flush();
String Uid = dataInputStream.readLine();
// read output and check if uid is there
if (Uid.contains("uid=0")) {
// you are root user
}
}
Выполните вашу команду с помощью su
Process process = Runtime.getRuntime().exec("su");
DataOutputStream dataOutputStream =
new DataOutputStream(process.getOutputStream());
if (dataOutputStream != null) {
// adb command
dataOutputStream.writeBytes("procrank\n");
dataOutputStream.flush();
BufferedInputStream bufferedInputStream =
new BufferedInputStream(process.getInputStream());
// this is important as it takes times to return to next line so wait
// else you with get empty bytes in buffered stream
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
// read buffered stream into byte,char etc.
byte[] bff = new byte[bufferedInputStream.available()];
bufferedInputStream.read(bff);
bufferedInputStream.close();
}
}
logcat: 
Вы получаете необработанные данные в единственной строке из консоли, а не в каком-то случае из любого API, который сложно хранить, так как вам придется отделить его вручную.
Это всего лишь попытка, пожалуйста, предложите мне, если я что-то пропустил
Ответ 9
В Android Studio 3.0 они представили Android-Profiler, чтобы помочь вам понять, как ваше приложение использует ресурсы процессора, памяти, сети и батареи.
https://developer.android.com/studio/profile/android-profiler
