Подробное объяснение профиля из "adb shell dumpsys meminfo my-app-name"?

Может ли кто-нибудь дать мне подробное объяснение профиля, полученного через adb shell dumpsys meminfo my-app-name?

Результат выглядит так, как показано ниже в Как узнать использование памяти моего приложения на Android?:

** MEMINFO in pid 890 [process-name] **
                    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

Что означает каждый столбец (native, dalvik, other, total)? особенно, что "другая" колонка (я не могу понять, что это помимо родного и далвика)? Было бы здорово, если бы кто-то мог дать конкретный пример, чтобы рассказать об этом. например У меня есть приложение A. A имеет свой собственный объект obj_private и собственную библиотеку lib_private. Кроме того, A ссылается на какой-то объект фреймворка Android obj_shared и некоторый собственный lib платформы Android lib_shared. И obj_shared ссылается на некоторый собственный lib из Android lib_shared_indirect. Для этого случая могу ли я сказать те?

  • "Общий размер" равен всей памяти, используемой "obj_private + lib_private + obj_shared + lib_shared + lib_shared_indirect".
  • "Частная грязная" равна памяти, загрязненной "obj_private + lib_private"

Причина, по которой мы хотим прояснить это, - это некоторое необычное увеличение времени исполнения нашей последней версии по сравнению с предыдущей версией. И когда я использовал meminfo dumpsys, я обнаружил, что столбцы "native" и "other" резко увеличились. Но изменение новой версии связано только с java, и нет объяснения о "другом" столбце. Я искал это и не нашел документа. Я также попытался прочитать исходный код adb. Но мне было легко заблудиться в исходном коде для новичков, подобных мне. Поэтому я размещаю этот вопрос здесь, если кто-то может помочь.

Ответы

Ответ 1

Теперь у нас есть больше документации, посвященной использованию ОЗУ в Android, которая подробно рассказывает о том, что означают разные номера ОЗУ: Управление вашей памятью приложений. В частности, посмотрите на середину страницы здесь, где обсуждаются ключевые части дампа meminfo: Исследование использования вашей оперативной памяти.

Похоже, ваш вывод meminfo из довольно старой версии Android, прежде чем мы смогли идентифицировать многие из разных типов распределений. Чтобы сопоставить то, что вы видите в текущей документации, просто считайте, что "другое" - это все, что показывает современный дамп, помимо родного и далвикового секций. В вашей свалке, я считаю, что ваш раздел dalvik на самом деле представляет собой современную "Dalvik Heap" и "Dalvik Other".

Что касается родного и других разделов, все чаще после изменения кода Java, да, это, безусловно, может случиться. Ряд компонентов Android Java API находится поверх собственных распределений и может также вызывать другие распределения. Классическим примером этого было бы растровое изображение на Gingerbread и ранее, где данные для растрового изображения были родным распределением, а не были распределением массива в куче Java, как сегодня.

Ваши увеличенные другие распределения могут быть связаны с рядом вещей, которые вы увидите в последних версиях данных: курсоры памяти, области общей памяти из ashmem, устройства, выделяющие для вас вещи, такие как графические текстуры и т.д. Есть так много вещей, что трудно сказать, что может происходить, поэтому отчет более подробный в эти дни. (И даже там, у нас все еще есть ряд вещей, которые обрушиваются на неизвестные.)

Чтобы отладить это, вы, вероятно, захотите посмотреть на кучу Java для просочившихся объектов. Поскольку фактическое распределение объекта не находится в куче Java, это может быть сложно, конечно. Я предлагаю взять кучу кучи на ранней стадии вашего приложения, делать все, что вы делаете, что приводит к увеличению его объема памяти RAM, после этого берет кучу кучи и ищет, какие объекты подсчитываются. В ссылочной документации показано, как сравнивать дампы кучи с MAT.

Также, когда вы смотрите на свою кучу Java как общий анализ (за исключением случаев, когда выполняете различия), всегда следите за инструкциями по удалению zygote части кучи. Как упоминается в документации, каждый процесс имеет большое количество распределений от zygote, но они разделяются во всех процессах, что обычно не имеет отношения к анализу кучи. Я очень часто вижу заинтересованных людей, потому что они видят в своем приложении много очень больших растровых изображений, которые система, по-видимому, выделяет на них, и думают, что это главное, используя RAM в своем приложении, когда это не так, это просто общие распределения из зиготы.