Приложение может делать слишком много работы в своем основном потоке

Я новичок в среде Android SDK / API. Это первое, что я пытаюсь нарисовать график / график. Я пробовал запускать различные виды примеров кода на эмуляторе с использованием 3 разных бесплатных библиотек, на экране макета ничего не отображается. LogCat повторяет следующее сообщение:

 W / Trace (1378): неожиданное значение от nativeGetEnabledTags: 0
 Я / Хореограф (1378): пропущено 55 кадров! Приложение может выполнять слишком много работы в своем основном потоке.

Проблема не исчезла, и диаграмма работала, когда я запустил образец кода, относящийся к пробной копии лицензионной библиотеки.

взято из: Android UI: исправление пропущенных кадров

Любой, кто начинает разработку приложения для Android, видит это сообщение на logcat «Хореограф (abc): пропущенные xx кадры! Приложение может выполнять слишком много работы над своим основным потоком ». Так что же это на самом деле означает, почему вы должны быть обеспокоены и как это решить.

Это означает, что вашему коду требуется много времени для обработки, а фреймы пропускаются из-за него. Возможно, из-за какой-то тяжелой обработки, которую вы выполняете в основе вашего приложения или доступа к БД, или любой другой вещи, которая заставляет поток остановитесь на некоторое время.

Вот более подробное объяснение:

Choreographer позволяет приложениям подключаться к vsync и правильно рассчитывать время для повышения производительности.

Android-анимация для внутреннего просмотра использует Choreographer для той же цели: для правильного определения времени анимации и, возможно, для повышения производительности.

Так как Choreographer рассказывается обо всех событиях vsync, я могу сказать, не завершается ли один из Runnables, переданных с помощью Choreographer.post * apis, за один кадр, что приводит к пропуску кадров.

В моем понимании хореограф может только обнаружить пропуск кадра. Невозможно объяснить, почему это происходит.

Сообщение «Приложение может выполнять слишком много работы в своем основном потоке». может вводить в заблуждение.

источник: смысл сообщений хореографа в Logcat

Почему вы должны быть обеспокоены

Когда это сообщение появляется на эмуляторе Android, а количество пропущенных кадров довольно мало (<100), вы можете сделать безопасную ставку на медленный эмулятор - что происходит почти все время. Но если количество пропущенных и больших кадров составляет порядка 300+, то с вашим кодом могут возникнуть серьезные проблемы. Устройства Android поставляются с огромным количеством аппаратного обеспечения, в отличие от устройств на базе iOS и Windows. Оперативная память и процессор различаются, и если вы хотите разумную производительность и удобство работы на всех устройствах, вам нужно исправить это. Когда кадры пропускаются, пользовательский интерфейс работает медленно и медленно, что нежелательно для пользователя.

Как это исправить

Исправление этого требует идентификации узлов, где есть или может произойти большая продолжительность обработки. Лучший способ - выполнять всю обработку независимо от того, насколько она мала или велика в отдельном от основного потока пользовательского интерфейса. Так что будь то доступ к данным из базы данных SQLite или выполнение какой-то жесткой математики или просто сортировка массива - сделайте это в другом потоке

Теперь здесь есть одна загвоздка: вы создадите новый поток для выполнения этих операций, и при запуске приложения произойдет сбой, сказав, что «только исходный поток, создавший иерархию представлений, может касаться его представлений». Вы должны знать, что пользовательский интерфейс в Android может быть изменен только основным потоком или потоком пользовательского интерфейса. Любой другой поток, который пытается это сделать, завершается сбоем и вылетает с этой ошибкой. Вам нужно создать новый Runnable внутри runOnUiThread, и внутри этого runnable вы должны выполнять все операции, связанные с пользовательским интерфейсом. Найдите пример здесь .

Итак, у нас есть Thread и Runnable для обработки данных из основного потока, что еще? В Android есть AsyncTask, который позволяет выполнять длительные процессы в потоке пользовательского интерфейса. Это наиболее полезно, когда ваши приложения управляются данными или веб-API или используют сложные пользовательские интерфейсы, подобные тем, которые создаются с использованием Canvas. Сила AsyncTask заключается в том, что она позволяет делать вещи в фоновом режиме, и как только вы закончите обработку, вы можете просто выполнить необходимые действия в пользовательском интерфейсе, не вызывая какого-либо запаздывающего эффекта. Это возможно, потому что AsyncTask происходит из потока пользовательского интерфейса Activity - все операции, которые вы выполняете в пользовательском интерфейсе через AsyncTask, выполняются в другом потоке, отличном от основного потока пользовательского интерфейса. Никаких помех для взаимодействия с пользователем.

Так что это то, что вам нужно знать для создания гладких приложений для Android, и, насколько я знаю, каждый новичок получает это сообщение на своей консоли.

Как и другие отвечали выше, "пропустили 55 кадров!" означает, что некоторая тяжелая обработка находится в вашем приложении.

В моем случае нет тяжелого процесса в моем приложении. Я дважды и трижды проверил все и удалил те процессы, которые мне показались немного тяжелыми.

Я удалил фрагменты, действия, библиотеки, пока не остался только скелет. Но все же проблема не ушла. Я решил проверить ресурсы и обнаружил, что некоторые иконки и фон, которые я использую, довольно большие, потому что я забыл проверить размер этих ресурсов.

Итак, я предлагаю, если ни один из приведенных выше ответов не поможет, вы также можете проверить размер файлов ресурсов.

У меня тоже была такая же проблема.
Мой был случай, когда я использовал фоновое изображение, которое было в drawable. Это конкретное изображение было около 130 КБ и использовалось во время заставки и домашней страницы в моем приложении для Android.

Решение - я просто переместил это конкретное изображение в папку drawables-xxx из drawables и смог освободить много памяти, занятой фоном, и пропускаемые кадры больше не пропускались.

Обновление Используйте папку ресурсов для рисования «nodp» для хранения фоновых файлов.
Будет ли приоритетной для рисования папка, соответствующая плотности, или drawable-nodpi?

Другой распространенной причиной задержек в потоке пользовательского интерфейса является доступ к SharedPreferences. Когда вы вызываете a PreferenceManager.getSharedPreferencesи другие подобные методы в первый раз, связанный XML-файл немедленно загружается и анализируется в том же потоке. .

Одним из хороших способов борьбы с этой проблемой является запуск первой загрузки SharedPreference из фонового потока, запускаемой как можно раньше (например, из onCreate вашего класса Application). Таким образом, объект предпочтения может быть уже создан к тому времени, когда вы захотите его использовать.

К сожалению, иногда чтение файлов предпочтений необходимо на ранних этапах запуска (например, в начальном действии или даже в самом приложении). В таких случаях все еще возможно избежать остановки пользовательского интерфейса с помощью MessageQueue.IdleHandler. Сделайте все остальное, что вам нужно выполнить в главном потоке, затем установите IdleHandler для выполнения кода после того, как ваша активность будет полностью прорисована. В этом Runnable вы должны иметь доступ к SharedPreferences, не откладывая слишком много операций рисования и не делая Choreographer несчастным.

Попробуйте использовать следующие стратегии для повышения производительности вашего приложения:

• Если возможно, используйте многопоточное программирование. Выигрыш в производительности огромен, даже если ваш смартфон имеет одно ядро ​​(потоки могут работать на разных ядрах, если процессор имеет два или более). Полезно отделить логику вашего приложения от пользовательского интерфейса. Используйте потоки Java, AsyncTask или IntentService. Проверьте это .
• Прочитайте и следуйте советам по разной производительности сайта разработки Android. Проверьте здесь .

У меня такая же проблема. Эмулятор Android отлично работал на Android <6.0. Когда я использовал эмулятор Nexus 5 (Android 6.0), приложение работало очень медленно I/Choreographer: Skipped framesв журналах.

Итак, я решил эту проблему, изменив hardwareAcceleratedопцию в файле манифеста trueследующим образом:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.myapplication">

    <application android:hardwareAccelerated="true">
        ...
    </application>
</manifest>

Я не эксперт, но я получил это сообщение отладки, когда я хотел отправить данные из моего приложения для Android на веб-сервер. Хотя я использовал класс AsyncTask и выполнял передачу данных в фоновом режиме, для получения данных результата с сервера я использовал метод get () класса AsyncTask, который делает интерфейс синхронным, что означает, что ваш интерфейс будет ожидать слишком долго. Поэтому я советую вашему приложению выполнять все сетевые задачи в отдельном потоке.

Оптимизируйте ваши изображения ... Не используйте изображения размером более 100 КБ ... Загрузка изображений занимает слишком много ресурсов процессора и приводит к зависанию вашего приложения.

У меня такая же проблема. В моем случае у меня было 2 вложенных реляционных макета. RelativeLayout всегда должен делать два прохода измерения. Если вы вложите RelativeLayouts, вы получите алгоритм экспоненциального измерения.

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

У меня такая же проблема. Когда я запускал код на другом компьютере, он работал нормально. На моем, однако, он отображал «Приложение может выполнять слишком много работы в своем основном потоке».

Я решил свою проблему, перезапустив Android-студию [Файл -> Недействительные кеши / Перезапуск -> нажмите «Отменить и перезагрузить»].

В моем случае это было потому, что я случайно установил точку останова для метода. Как только я очистил его, сообщение исчезло, и производительность значительно улучшилась.

У моего приложения была такая же проблема. Но это было не что иное, как отображение списка карточек и текста на нем. Ничего не работает в фоновом режиме. Но затем после некоторого расследования обнаружил, что причиной этого было изображение, установленное для фона карты, хотя оно было маленьким (350 КБ). Затем я преобразовал изображение в 9-образное изображение, используя http://romannurik.github.io/AndroidAssetStudio/index.html .
Это сработало для меня.

Проведя много исследований и разработок по этому вопросу, я получил решение,

В моем случае я использую Сервис, который будет запускаться каждые 2 секунды и с runonUIThread, мне было интересно, что проблема была там, но не совсем. Следующая проблема, которую я обнаружил, состоит в том, что я использую большое изображение в майском приложении, и в этом проблема.

Я удалил Изображения и установил новые Изображения.

Вывод: - Посмотрите в своем коде есть ли какой-либо необработанный файл, который вы используете, имеет большой размер.

Сначала прочитайте предупреждение. Это говорит о большей нагрузке на основной поток. Так что вам нужно просто запустить функции с большим количеством работы в потоке.

У меня возникла та же проблема при разработке приложения, которое использует много разрисовываемых png-файлов в сетке. Я также попытался оптимизировать мой код, насколько это возможно ... но у меня не получилось ... Потом я попытался уменьшить размер этих png ... и думаю, что он работает абсолютно нормально ... Поэтому я предлагаю уменьшить размер доступных ресурсов, если таковые имеются.