Android SystemII глючит в Lollipop

Ответ 1

Настройка android:hardwareAccelerated="false" - это своего рода экстремальное решение, так как графическая производительность, вероятно, будет очень плохой.

Если вы можете точно определить мнение, которое является неправильным и вызвало эту проблему, лучшим решением было бы переключить его на рендеринг программного обеспечения вместо setLayerType(), например

view.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

Забавно, что до сих пор я не испытывал никаких сбоев с Lollipop, но мы видели их в KITKAT (как упоминалось в этом вопросе), и только когда WebViews присутствуют на экране.

Я бы рекомендовал экспериментировать с переключением этого на разные представления, пока проблема не будет изолирована (особенно если ее легко воспроизвести).

До сих пор каждое возникновение этой проблемы связано с WebViews (или с компонентами, использующими WebView, такими как AdMob). Согласно AOSP Issue Tracker проблема устранена в Android 5.0, но, похоже, это не так.

Ответ 2

Я видел сбои UI с Lollipop, хотя и отличается от вашего. Единственным обходным решением, которое я нашел, было отключение аппаратного ускорения:

android:hardwareAccelerated="false"

на уровне активности или приложения. Если это устраняет ваши сбои, обязательно сообщите об этом Google, так как это указывает на ошибку в платформе. Уже есть хотя бы один открытый отчет с ними.

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

Надеюсь, это поможет!

EDIT 12/10/2014:

@matiash предложил гораздо более точный ответ, чем это предложение "кувалды". Я видел сбои в основном на ActionBar в приложении с несколькими вкладками с ViewPager и всегда на вкладках/страницах без какого-либо WebView. Однако один из моих вкладок/фрагментов имеет встроенный WebView, и при настройке на рендеринг программного обеспечения мои глюки, похоже, ушли. Мне не совсем неудобно устанавливать обходное решение, предлагаемое @matiash в приложении для доставки... хотя оно все еще указывает на некоторые основные проблемы на платформе.

Ответ 3

Я также видел эту проблему в своем приложении.

Любые Android-разработчики когда-либо испытывают такой визуальный статический? (см. рисунок)

Я не только получил визуальный статический, но и повторный рисунок. Только он наблюдался на Nexus 5 с 5.0 при разработке с api 21 и поддержкой библиотеки 21.0. +.

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

Я не использую WebViews (допускаю, возможно, через admob). Я использую ViewPagers с фрагментами. Я также использую DragSortList и впервые начал видеть проблему в действиях, которые ее использовали.

https://github.com/bauerca/drag-sort-listview

Насколько воспроизводимым это для вас, ребята?

Ответ 4

Вы пытались установить android:fitsSystemWindows="true" в макете Fragment? это позволит убедиться, что макет ниже statusBar, im не совсем уверен в кнопках навигации, но я думаю, что это тоже сработает для него.

Ответ 5

Схема запроса вызова на DecorView после рендеринга:

getActivity().getWindow().getDecorView().requestLayout();

Я называю это с помощью postDelay() в WebViewClient.onPageFinished(). Это не идеальное решение (только обходное решение), но, возможно, лучший способ, например LAYER_TYPE_SOFTWARE.

Ответ 6

......... перейдите к настройкам, а затем к вариантам разработчика (если они не видны... перейдите к телефону, затем щелкните по номеру сборки 7-10 раз и включите режим разработчика), и там прокрутите вниз и отвяжите "показывать границы макета", и все готово. его просто и легко.