Слишком много на основной теме, несмотря на создание потоков [duplicate]

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

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

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

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

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

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

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

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

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

У меня была та же проблема. Android-эмулятор отлично работал на Android & lt; = 6.0. Когда я пробовал эмулятор Nexus 5 (Android 6.0), приложение работало очень медленно с I/Choreographer: Skipped frames в журналах.

Итак, я решил эту проблему, изменив в опции Manifest file 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>

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

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

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

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

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

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

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

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

Как было сказано выше, «пропущено 55 кадров!» означает, что в вашем приложении используется некоторая тяжелая обработка.

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

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

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