-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ограничить количество потоков для загрузки иконок при пролистывании списков видео #17
Comments
Добавил ThreadPool в VideoItemPagedListAdapter. Плейлист Союзмультфильм с 1000 удаленных видео при быстрой прокрутке вниз с ограничением в 100 потоков вылетает вот так:
С ограничением в 1 поток не вылетает вообще. С огранинием в 10 потоков вылетает довольно быстро (но не так быстро, как со 100), с ограничением в 5 потоков почти не вылетает, но если долго мотать вниз, то всё равно вылетает. |
Убрал (временно) обращение в сеть для загрузки изображения, плейлист с ограничением в 100 потоков не вылетает, хотя заметны тормоза при скоростной прокрутке вниз (один раз все-таки вылетел). |
Добавил запуск потоков через Executors.newFixedThreadPool, выставил ограничение 10 потоков: на главной странице заметного замедления загрузки иконок (как в случае с 1-м потоком) нет: 6d67146 Плейлист с удаленными на сервере роликами (Союзмультфильм) прокручивается дальше если не сильно торопиться, хотя все равно вылетает. Пусть будет пока так. Еще поправил освобождение ресурсов при загрузке картинок: 4b54211 субъективно плейлист Союзмультфильм стал тормозить поменьше, но это не точно. |
Возможно, кстати, дело в одновременном обращении к базе данных (вылет сопровождается SQLiteException), они там тоже в фоновых потоках, их тоже можно поместить в ThreadPool'ы. |
Оборачивание обращений к базе данных в ThreadPool не помогло, всё равно вылетает вот так, даже с ограничением на 1 поток:
|
Но странно:
|
Решение проблемы: 23a309e Если на сервере нет файла с иконкой (connection.getInputStream() выбрасывает FileNotFound и input получается null), то нужно не только закрывать подключение connection.disconnect(), но и закрывать поток connection.getErrorStream().close(), даже если мы к нему не обращались вообще. Если это не делать, то:
Эксепшен (пойманный) при отсутствующей иконке на сервере выглядит вот так:
Две проблемы одним исправлением. Вероятно, открытые стримы connection.getErrorStream() резервируют какие-то ресурсы (например, что-то вроде дескрипторов открытых файлов) так, что их перестаёт хватать на доступ к файлу базы данных. В списке с большим количеством отсутствующих иконок при быстрой прокрутке ресурс быстро исчерпывается и вылетает непойманная ошибка при очередном обращении к базе данных. После этого патча прокрутка плейлиста Союзмыльтфильм (удаленного на сервере) перестаёт крашить приложение (экспепшен SQLiteCantOpenDatabaseException исчезает), получается домотать в самый низ и не получить краш. При этом есть небольшое подтормаживание и экран со списком все равно может вылететь (возможно, прибивает система за чрезмерное использование процессора), но эксепшена SQLiteCantOpenDatabaseException всё равно больше равно нет. |
здесь (хотя это и не было причино описанных выше проблем): 7bdc1b8
вот это реализовано: 71a4cf2 Эффект заметен сразу при быстрой прокрутке любого длинного списка - иконки появляются сразу, а не появляются через время (после того, как прогрузятся иконки из уже прокрученных областей списка). |
Обоснование:
Попытка промотать плейлист Союмультфильма с удаленными видео приводит к вылету приложения.
Причина: на быстром соединении картинка закрывается быстро и вместе с ней прибивается загружающий поток. На медленном соединении (или при отсутствующей картинке) сначала требуется выждать таймаут с недостающим ресурсом, поэтому в незавершенном состоянии остаётся большое количество фоновых потоков.
При этом обратить внимание: на раннем этапе разработки я уже реализовал загрузку иконок через ThreadPool (ровно то, что написано в тикете) и это привело к тому, что иконки появлялись в списках заметно медленнее, чем при создании неограниченного количества фоновых потоков. На тот момент я решил эту фичу удалить, в старых версиях код не сохранился. Но, возможно, ее следовало аккуратнее настроить (например, задать достаточно большое, но разумное количество фоновых потоков - по крайней мере, они не будут постоянно пересоздаваться, и/или, как написано выше, поиграть с порядком отправки ожадающих заданий на выполнение).
The text was updated successfully, but these errors were encountered: