Странная проблема с дочерним процессом andan bootanimation влияет на занятость памяти родительского процесса init - PullRequest
Новая
       15

Странная проблема с дочерним процессом andan bootanimation влияет на занятость памяти родительского процесса init

0 голосов
/ 15 октября 2018

Эта проблема может быть связана с Android или Linux.Если вы не знакомы с Android, позвольте мне сначала кратко представить init и bootanimation.Android init - это то же самое, что Linux init.Это первый процесс в пространстве пользователя.Pid - 1. Процесс init выполнит некоторые инициализации системы, определенные в init.rc.Одной из инициализаций является анимация загрузки.Это играется процессом, названным бутанимацией.Бутанимация - это родной процесс.Он воспроизводит анимацию с использованием OpenGL ES.Анимация загрузки обычно описывается zip-файлом с десятками или сотнями статических изображений.Воспроизведение их с определенной скоростью становится анимацией.

Теперь возникает странная проблема.Речь идет о заполнении памяти процесса инициализации.В чистой системе Android 8.1.0 память, занимаемая init, превышает 40M +.Мы можем узнать подробности выделения с помощью команды оболочки adb 'dumpsys meminfo init'. 

                   Pss
                 Total
                ------
  Native Heap     1076
  Dalvik Heap        0
        Stack       16
    Other dev      363
   Other mmap      333
   EGL mtrack    10040
    GL mtrack    29170
      Unknown       32
        TOTAL    41030

Мы можем видеть, что связанные с графикой EGL / GL занимают большую часть памяти.Обычно init - это бэкэнд-процесс.Это не имеет ничего общего с графикой.Тогда почему графическая память занимает больше всего.Единственная вещь, связанная с графикой, которую я могу понять, это анимация загрузки.Как описано выше, он запускается / разветвляется процессом init.Итак, я сделал несколько тестов.Если я отключил загрузочную анимацию, объем памяти, занимаемой init, сильно уменьшился примерно до 20M.Я также сделал другие тесты.Я попытался изменить исходный код бутанимации для загрузки и рендеринга одного изображения вместо сотен изображений.Заполнение памяти init также сильно уменьшилось.Это означает, что заполнение памяти init имеет какое-то отношение к числу изображений, загружаемых при бутанимации.Я провел дальнейшее тестирование и обнаружил, что использование памяти init будет значительно уменьшаться после разрыва процесса начальной загрузки init.Кажется, что память передается из init в дочернюю процедуру bootanimation.

Тогда возникает мой последний вопрос: как дочерний процесс, почему bootanimation повлияет на заполнение памяти его родительского процесса?Когда процесс бутанимации завершается, не должны ли все занятые ресурсы быть освобождены?

Дополнительные комментарии: Хотя в моем смысле, когда процесс завершается, все ресурсы должны быть освобождены.И исходные коды Android, написанные Google, должны быть приправленными и не иметь ошибок.Я все еще сомневался в утечке ресурсов в бутанимации.Bootanimation использует SkBitmap, находящийся в библиотеке skia, для загрузки изображений и использования текстур OpenGL ES 1.0 для их рендеринга.Я подтвердил, что если я не подтвердил, что текстуры SkBitmap и OpenGL будут уничтожены правильно.У вас, ребята, могут быть интересы в связанных исходных кодах Android.

Базовый код для воспроизведения анимации в бутанимации: http://androidxref.com/8.1.0_r33/xref/frameworks/base/cmds/bootanimation/BootAnimation.cpp#862 Код для загрузки изображения: http://androidxref.com/8.1.0_r33/xref/frameworks/base/cmds/bootanimation/BootAnimation.cpp#190 Код для запуска бутанимации в init: http://androidxref.com/8.1.0_r33/xref/system/core/init/service.cpp#688

Спасибо за все ваши ответы, предложения и комментарии.

1 Ответ

0 голосов
/ 17 октября 2018

После новой серии тестов и чтения кода я нашел что-то новое.Я добавлю несколько новых комментариев.Эта проблема не имеет ничего общего с init.Проблема связана с реализацией dumpsys meminfo .Память процесса, отображаемая dumpsys meminfo , состоит из двух частей.Одна часть напрямую выделяется этим процессом.Таких как Dalvik Heap и Native Heap.В то время как другая часть не выделяется напрямую этим процессом, она выделяется системой, только что вызванной этим процессом.EGL / GL mtrack часть, показанная выше, принадлежит этой части.Отслеживание этой части памяти осуществляется на другой аппаратной платформе.Это подсчитывается драйвером дисплея.Я использую платформу MTK.Он будет отслеживать память GL для тех процессов, которые выполняют реальные операции GL.Я считаю, что эта статистика точна.Но есть общая память GL, используемая системой, то есть общее значение GL mtrack, которое мы можем видеть, когда выполняем dumpsys meminfo без дополнительных параметров.Может быть не равным сумме подсчитанных значений GL всех учтенных процессов.Затем он учитывает разницу общей памяти GL и суммы памяти GL для процесса инициализации.Потому что init является процессом-предком всех других процессов.Таким образом, значение GL mtrack для init выглядит большим, оно не выделяется ни init, ни фактически вызванным init.

Теперь мы можем объяснить очень странную проблему, описанную выше, и знать, что она не имеет ничего общего с процессом init.Но мой вопрос все еще остается нерешенным.То есть, почему событие bootanimation завершается, выделенная им память GL не освобождается?Означает ли это утечку ресурса?Или, может быть, я считаю это ошибкой драйвера дисплея MTK?

...