Это зависит от вашего определения, какой запрос памяти вы хотите получить.
Обычно вы хотите узнать состояние памяти кучи, так как, если она использует слишком много памяти, выполучить OOM и завершить работу приложения.
Для этого вы можете проверить следующие значения:
final Runtime runtime = Runtime.getRuntime();
final long usedMemInMB=(runtime.totalMemory() - runtime.freeMemory()) / 1048576L;
final long maxHeapSizeInMB=runtime.maxMemory() / 1048576L;
final long availHeapSizeInMB = maxHeapSizeInMB - usedMemInMB;
Чем больше переменная usedMemInMB приближается к maxHeapSizeInMB, тем ближе availHeapSizeInMB
достигает нуля, чем ближе вы получаете ООМ.(Из-за фрагментации памяти вы можете получить OOM ДО того, как он достигнет нуля.)
Это также то, что показывает инструмент использования памяти DDMS.
Альтернативно, существует реальное использование ОЗУ, это то, сколько использует вся система - см. принятый ответ , чтобы вычислить это.
Обновление: поскольку Android O заставляет ваше приложение также использовать собственную оперативную память (по крайней мере для растровых изображений)хранилище, которое обычно является основной причиной огромного использования памяти), а не только куча, все изменилось, и вы получите меньше OOM (поскольку куча больше не содержит растровые изображения, проверьте здесь ), но вы все равно должны следить за использованием памяти, если вы подозреваете, что у вас есть утечки памяти.На Android O, если у вас есть утечки памяти, которые должны были вызвать OOM на более старых версиях, кажется, что он просто потерпит крах, и вы не сможете его перехватить.Вот как проверить использование памяти:
val nativeHeapSize = Debug.getNativeHeapSize()
val nativeHeapFreeSize = Debug.getNativeHeapFreeSize()
val usedMemInBytes = nativeHeapSize - nativeHeapFreeSize
val usedMemInPercentage = usedMemInBytes * 100 / nativeHeapSize
Но я считаю, что лучше всего использовать профилировщик среды IDE, который показывает данные в режиме реального времени с использованием графика.
Итак, хорошая новость для Android O состоит в том, что сбои намного сложнее из-за того, что OOM хранит слишком много больших растровых изображений, но плохая новость заключается в том, что я не думаю, что можно обнаружить такой случай во времяво время выполнения.