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

Ответ 1

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

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

Это означает, что ваш код занимает много времени и обрабатывает из-за этого пропускаются, возможно, из-за некоторых тяжелых обработка, которую вы делаете в основе вашего приложения или базы данных доступ или любая другая вещь, которая заставляет поток останавливаться на некоторое время. Вот более подробное объяснение:

Хореограф позволяет приложениям подключаться к vsync, и   правильно время для улучшения производительности.

     

Android-анимация для просмотра внутри себя использует хореографа для того же   цель: правильно настроить время анимации и, возможно, улучшить   производительность.

     

Поскольку хореографу рассказывают о каждом событии vsync, я могу сказать,   один из Runnables, переданный хореографом .post * apis   не заканчивается за одно время кадра, заставляя кадры пропускаться.

     

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

     

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

     

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

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

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

Как исправить его

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

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

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

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

Ответ 2

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

Для моего случая в моем приложении нет тяжелого процесса. Я дважды и тройной проверил все и удалил этот процесс, я думаю, был немного тяжелым.

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

У меня такая же проблема. Эмулятор 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>

Ответ 8

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

Ответ 9

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

Ответ 10

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

Я решил проблему, перезапустив студию Android [File → Invalidated caches/Restart → нажмите "Invalidate and Restart"].

Ответ 11

это обычно происходит, когда вы выполняете длинные процессы в основном потоке. можно пропустить кадры меньше 200. но если у вас более 200 пропущенных кадров, это может замедлить работу пользовательского интерфейса приложения. что вы можете сделать, это сделать эти процессы в новом потоке, называемом рабочим потоком, и после этого показать результат при взаимодействии с основным потоком. AsyncTask и RunOnUiThread в большинстве случаев могут решить проблему...

Ответ 12

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

Ответ 13

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

Ответ 14

После выполнения большого количества R & D по этой проблеме я получил решение,

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

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

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

Ответ 15

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

Ответ 16

Хотите верьте, хотите нет.. эта ошибка у меня возникла, когда я присваивал значение int вместо String для textview!

Ответ 17

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

Ответ 18

Вы можете использовать библиотеку Glide для загрузки изображений.. она будет загружать изображение в фоновый поток.