Русские Блоги
android Profiler актуальный боевой анализ и позиционирование утечек памяти
1. Что такое профайлер?
Memory Profiler — это компонент Android Profiler. Это инструмент наблюдения, используемый Android Studio 3.0 для замены предыдущего Android Monitor. Он в основном используется для наблюдения за температурой памяти, сети и процессора. Он позволяет выявлять утечки памяти и колебания памяти, которые приводят к зависанию, запуску и сбоям приложений. Он может показать вам реальный график использования памяти, сообщить вам текущее использование памяти и принудительную перезагрузку памяти, а также отслеживать распределение памяти. мощный инструмент для анализа производительности.
Во-вторых, использование Profiler
1. Подключитесь к мобильному телефону., На панели навигации в правом верхнем углу AndroidStudio есть значок для быстрого запуска Profiler (значок в красной рамке), и приложение запустится после нажатия.
2. После запуска приложения в AndroidStudio вы увидите следующую таблицу:
Вот различные данные, когда приложение в настоящее время работает, среди которых:
ЦП: это процент использования ЦП текущим приложением;
ПАМЯТЬ: размер памяти, занятой текущим приложением;
NETWORK: сетевой трафик, используемый текущим приложением;
Щелкните область под ПАМЯТЬ, и вы увидите подробную информацию об использовании памяти. Здесь мы сосредоточимся на функциях страницы использования памяти:
1) Кнопка, используемая для принудительной сборки мусора, то есть GC;
2) Кнопка дампа используется для захвата дампа кучи. После нажатия на нее она захватит все объекты и отношения вызовов в памяти в следующие несколько секунд (используется часто);
3) Проверьте выделение памяти, эта кнопка будет отображаться только при подключении к устройству под управлением Android 7.1 или ниже;
4) Кнопки, используемые для увеличения / уменьшения масштаба временной шкалы;
5) Кнопки, используемые для перехода к данным памяти в реальном времени;
6) Временная шкала событий, на которой отображается состояние активности, событие, введенное пользователем, и событие поворота экрана;
7) Временная шкала использования памяти, которая содержит следующее содержимое:
A. Диаграмма с накоплением, показывающая, сколько памяти используется каждой категорией памяти, как показано осью Y слева и цветными клавишами вверху.
B. Пунктирная линия указывает количество выделенных объектов, как показано на оси Y справа.
C. Значок, используемый для представления каждого события сборки мусора.
Примечания. Всю информацию можно увидеть на Android 8.0 и более поздних версиях, и не все данные по умолчанию отображаются в 8.0. Вам необходимо включить расширенный анализ, чтобы просмотреть следующее:
* Хронология событий
* Количество выделенных объектов
★ ★ ★ ★ ★ Событие сбора мусора
3. Категории в счетчике памяти следующие.：
Java: Объектная память, выделенная из кода Java или Kotlin.
Native: Объектная память, выделенная из кода C или C ++.
Даже если вы не используете C ++ в своем приложении, вы можете увидеть некоторую внутреннюю память, используемую здесь, потому что платформа Android использует внутреннюю память для обработки различных задач от вашего имени, таких как обработка ресурсов изображений и другой графики, даже если вы пишете код Используйте язык Java или Kotlin.
Graphics: Память, используемая очередью графического буфера для отображения пикселей (включая поверхность GL, текстуру GL и т. Д.) На экране. (Обратите внимание, что это память, совместно используемая с ЦП, а не выделенная память графического процессора.)
Stack: Память, используемая собственным стеком и стеком Java в вашем приложении. Обычно это связано с количеством потоков, выполняемых вашим приложением.
Code: Ваше приложение использует память для обработки кода и ресурсов (таких как байт-код dex, оптимизированный или скомпилированный код dex, библиотека .so и шрифты).
Other: Ваше приложение использует систему, которая не определяет, как классифицировать память.
Allocated: Количество объектов Java / Kotlin, выделенных вашим приложением. Он не считает объекты, размещенные в C или C ++.
При подключении к устройствам под управлением Android 7.1 и ниже это выделение начинает подсчет, только когда профилировщик памяти подключен к приложению, которое вы запускаете. Следовательно, объекты, выделенные до начала анализа, не учитываются. Однако в Android 8.0 есть встроенный инструмент анализа, который записывает все распределения, поэтому в Android 8.0 и выше это число всегда представляет общее количество объектов Java, ожидающих обработки в вашем приложении.
По сравнению с подсчетом памяти в предыдущем инструменте Android Monitor, новый профилировщик памяти записывает вашу память другим способом, поэтому использование памяти теперь может казаться выше. Профилировщик памяти отслеживает больше категорий, что увеличивает общее использование памяти, но если вы заботитесь только о памяти кучи Java, номер элемента «Java» должен быть аналогичен номеру в предыдущем инструменте.
Однако номер Java может не совпадать с номером, который вы видите в Android Monitor. Это связано с тем, что куча Java приложения запускается из Zygote, и новое число учитывает все страницы физической памяти, выделенные для него. Следовательно, он может точно отражать, сколько физической памяти фактически использует ваше приложение.
В настоящее время Memory Profiler также отображает некоторую неверную информацию об использовании собственной памяти в приложении, которая фактически используется инструментами анализа. Приблизительно для 100 000 объектов это увеличивает заявленное использование памяти до 10 МБ. В будущих версиях этих инструментов эти числа будут отфильтрованы из ваших данных.
В-третьих, процесс анализа утечек памяти
1. Как определить, произошла ли утечка памяти в Profiler
Во время использования приложения откройте страницу и используйте ее в течение определенного периода времени, использование памяти увеличится. Когда страница закрыта, подождите некоторое время, использование памяти не уменьшится или уменьшение неочевидно, вручную запускает сборщик мусора, дамп распределения объекта и отношения вызова в стеке. Если обнаруживается, что закрытая страница или объект, который должен быть переработан на странице, все еще существует, можно считать, что произошла утечка памяти.
2. Приведите пример.
В приложении проекта есть страница с фотографиями. После того, как фотография сделана, фотография будет сохранена локально. Было обнаружено, что каждый раз при съемке фотографии объем памяти увеличивается примерно на 40 МБ, а после закрытия страницы фотографии использование памяти по-прежнему велико. Предполагается утечка памяти. Процесс анализа выглядит следующим образом:
2.1: Запустите Profiler, откройте страницу с фотографиями в приложении, сделайте снимок и закройте страницу с фотографиями. Приложение занимает следующую память:
2.2: Вручную запустите GC, а затем нажмите кнопку дампа, чтобы выгрузить объекты в стеке.После завершения дампа вы увидите данные о занятости всех объектов в памяти.
2.3: На панели навигации дампа кучи текущая категория отображения — Упорядочить по классам, которую можно просмотреть по имени класса, имени пакета и стеку обратного вызова. В то же время, в дальнем правом углу есть воронка для фильтрации указанного отображения. данные. В настоящее время фильтруется и отображается по имени пакета:
Вы можете видеть, что страница с фотографиями (SnapActivity) все еще существует. Можно считать, что на этой странице есть утечка памяти. Откуда она просочилась?
2.4 Щелкните SnapActivity, вы можете увидеть размер занятости и взаимосвязь между вызовами каждого объекта в SnapActivity. Было обнаружено, что mPictureManager занимает наибольшую память. После щелчка по нему обнаруживается объект обратного вызова, указывающий на SnapActivity. Может ли этот обратный вызов вызвать утечку? . 
После проверки кода выясняется, что PictureManager является сторонней библиотекой. При ее использовании устанавливается обратный вызов для получения обработки данных после съемки. Это одноэлементный класс шаблона, но его одноэлементный класс записывается так:
Статический финал. . . Это означает, что после установки для него обратного вызова этот обратный вызов будет существовать всегда! ! Однако после выхода из страницы фотографии обратный вызов не был сделан пустым, и SnapActivity не удалось повторно использовать, что привело к утечке памяти.
Решение. Поскольку это сторонняя библиотека, исходный код нельзя изменить, поэтому в onDestroy страницы с фотографиями оставьте обратный вызов PictureManager пустым. Избегайте утечек памяти. .
Источник
Android Profiler
Это еще один важный инструмент трассировки, позволяющий оценить, сколько времени понадобилось для завершения работы того или иного метода в твоем приложении. Так же как и Systrace, он формирует отчет за определенный промежуток времени, но отчет этот гораздо более низкоуровневый и касается каждого отдельно взятого метода, который был вызван.
Запускаем Android Studio, кликаем на Android Profiler внизу экрана, затем на CPU и нажимаем красную круглую кнопку записи вверху экрана, останавливаем запись, когда нужно. Внизу экрана появится окно с отчетом.
По умолчанию отчет выводится в виде диаграммы, где по оси X отображается время, а по оси Y — вызываемые методы. Оранжевым помечены системные методы (API), зеленым — методы самого приложения, голубым — методы сторонних API, включая Java. На вкладке Flame chart — похожая диаграмма, в которой одинаковые методы объединены. Она удобна тем, что позволяет наглядно оценить, сколько всего времени работал тот или иной метод за весь период трейсинга.
Вкладки Top Down и Bottom Up показывают дерево вызовов методов, включая информацию о затраченном на их выполнение времени:
- Self — время исполнения кода самого метода;
- Children — время исполнения кода всех вызванных им методов;
- Total — сумма Self и Children.
Как и Systrace, этот инструмент требует вдумчивого изучения отчета. Он не подскажет тебе, где и что пошло не так. Он просто рассказывает, когда и что происходило в твоем приложении, и позволяет найти участки кода, на которые пришлось больше всего процессорного времени.
Источник
Inspect CPU activity with CPU Profiler
Optimizing your app’s CPU usage has many advantages, such as providing a faster and smoother user experience and preserving device battery life.
You can use the CPU Profiler to inspect your app’s CPU usage and thread activity in real time while interacting with your app, or you can inspect the details in recorded method traces, function traces, and system traces.
The specific kinds of information that the CPU Profiler records and shows are determined by which recording configuration you choose:
- System Trace: Captures fine-grained details that allow you to inspect how your app interacts with system resources.
Method and function traces: For each thread in your app process, you can find out which methods (Java) or functions (C/C++) are executed over a period of time and the CPU resources each method or function consumes during its execution. You can also use method and function traces to identify callers and callees. A caller is a method or function that invokes another method or function, and a callee is one that is invoked by another method or function. You can use this information to determine which methods or functions are responsible for invoking particular resource-heavy tasks too often and optimize your app’s code to avoid unnecessary work.
When recording method traces, you can choose sampled or instrumented recording. When recording function traces, you can only use sampled recording.
For details of using and choosing each of these trace options, see Choose a recording configuration.
CPU Profiler overview
To open the CPU Profiler, follow these steps:
Select View > Tool Windows > Profiler or click Profile in the toolbar.
If prompted by the Select Deployment Target dialog, choose the device to which to deploy your app for profiling. If you’ve connected a device over USB but don’t see it listed, ensure that you have enabled USB debugging.
Click anywhere in the CPU timeline to open the CPU Profiler.
When you open the CPU Profiler, it immediately starts displaying your app’s CPU usage and thread activity. You should see something similar to figure 1.
Figure 1. Timelines in the CPU Profiler.
As indicated in figure 1, the default view for the CPU Profiler includes the following timelines:
- Event timeline: Shows the activities in your app as they transition through different states in their lifecycle, and indicates user interactions with the device, including screen rotation events. For information on enabling the event timeline on devices running Android 7.1 (API level 25) and lower, see Enable advanced profiling.
- CPU timeline: Shows real-time CPU usage of your app—as a percentage of total available CPU time—and the total number of threads your app is using. The timeline also shows the CPU usage of other processes (such as system processes or other apps), so you can compare it to your app’s usage. You can inspect historical CPU usage data by moving your mouse along the horizontal axis of the timeline.
- Thread activity timeline: Lists each thread that belongs to your app process and indicates their activity along a timeline using the colors listed below. After you record a trace, you can select a thread from this timeline to inspect its data in the trace pane.
- Green: The thread is active or is ready to use the CPU. That is, it’s in a running or runnable state.
- Yellow: The thread is active, but it’s waiting on an I/O operation, such as disk or network I/O, before it can complete its work.
- Gray: The thread is sleeping and is not consuming any CPU time. This sometimes occurs when the thread requires access to a resource that is not yet available. Either the thread goes into voluntary sleep, or the kernel puts the thread to sleep until the required resource becomes available.
The CPU Profiler also reports CPU usage of threads that Android Studio and the Android platform add to your app process—such as JDWP , Profile Saver , Studio:VMStats , Studio:Perfa , and Studio:Heartbeat (although, the exact names displayed in the thread activity timeline may vary). Android Studio reports this data so that you can identify when thread activity and CPU usage are actually caused by your app’s code.
Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.
Источник
