WebView в ScrollView: «Просмотр слишком большой, чтобы вписаться в кеш-файл» – как переделать макет?

У меня есть макет с ScrollView , который содержит следующие виды: ImageView , TextView , WebView , TextView . (Это потому, что я хотел бы прокрутить все вместе, а не только содержимое WebView )

После загрузки некоторого HTML в WebView я получаю следующее:

 WARN/View(632): View too large to fit into drawing cache, needs 14236800 bytes, only 1536000 available 

… и содержимое WebView не будет отображаться. После удаления ScrollView предупреждение исчезает, и все хорошо, за исключением того, что я теряю нужную функцию прокрутки.

Во-первых: я знаю, что попытка использовать ScrollView внутри другого ScrollView – это вообще плохо , но я не уверен на 100%, что в каждом случае есть эквивалентное решение без использования ScrollView … Я имею в виду, конечно, можно было бы поставить Содержимое ImageView и TextView s в WebView , но как насчет Button или каких-либо других элементов интерфейса, которые нуждаются в взаимодействии? Есть ли вообще способ решить такие проблемы, не отказываясь от макета и прокручивая все сразу?

Я узнал, что я не единственный с этой проблемой. Для других примеров, проверьте эти вопросы – без рабочего решения:

  • WebView и GridView в ScrollView, просмотр слишком велик, чтобы вписаться в кеш рисования
  • Android – просмотр слишком большой, чтобы вписаться в кеш-файл

Solutions Collecting From Web of "WebView в ScrollView: «Просмотр слишком большой, чтобы вписаться в кеш-файл» – как переделать макет?"

Проблема, похоже, связана с аппаратным ускорением, которое включено по умолчанию, если уровень API> = 14.

У меня есть приложение с ScrollView которое содержит несколько просмотров, которые я хочу прокрутить, как единое целое, похожее на оригинальный плакат. Одним из таких представлений является веб-представление, которое обертывает его содержимое. Если аппаратное ускорение WebView и визуализированный WebView является совершенно сложным (изображения, границы и т. Д.), Тогда сообщение об ошибке кэша чертежа можно увидеть в LogCat. На одном экране с 12 элементами работал, а следующий экран с 13 элементами не работал. Я не думаю, что это количество элементов, которые имеют значение, но сложность финального визуализированного экрана.

Симптомы обычно представляют собой пустой WebView – другие представления визуально присутствуют и полностью формируются. Очень редко я вижу весь экран пустым, но, возможно, это было, пока я работал с различными предложениями, найденными здесь на SO.

Сообщение не всегда видно. Например, я вижу проблему на Samsung Galaxy 4 Mini 4.2.2, а на других 4.x устройствах, таких как мой дешевый китайский клон Samsung S3, работающий на 4.1.2, все в порядке. Я не видел его на каких-либо устройствах 1.x или 2.x.

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

После отключения аппаратного ускорения все проблемы исчезли. Я не вижу заметных различий в производительности на любом из моих устройств. Предположительно, устройства 1.x и 2.x никогда не использовали аппаратное ускорение в первую очередь, а мои 4.x-устройства должны быть достаточно быстрыми, чтобы справляться с программным рендерингом. Не то, чтобы мои экраны были сложными.

Обновление APRIL 2015

К сожалению, появилось предупреждающее сообщение о том, что Samsung Galaxy 4 Mini теперь работает 4.4.2, даже если аппаратное ускорение отключено. У меня есть веб-просмотр с открытой / закрытой анимацией на панели JavaScript. Все работает отлично, за исключением того, что исходный макет (открытая панель) вызывает эти предупреждения, и каждый раз, когда я закрываю или открываю панель, я также их получаю. Эти предупреждения сейчас просто раздражают, приложение работает нормально.

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

Я решил, что смогу решить проблему, установив в android:layerType="software" параметр android:layerType="software" , который просто отключает аппаратное ускорение для ScrollView и его содержимого.

 <ScrollView android:layout_width="match_parent" android:layout_height="match_parent" android:layerType="software"> <LinearLayout android:layout_width="match_parent" android:layout_height="wrap_content" android:orientation="vertical"> <FrameLayout android:layout_width="match_parent" android:layout_height="wrap_content"> ... </FrameLayout> <WebView android:layout_width="match_parent" android:layout_height="wrap_content" /> </LinearLayout> </ScrollView> 

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

webView.setLayerType(WebView.LAYER_TYPE_NONE, null);

Работал на меня. В зависимости от аппаратного обеспечения для дополнительного буферного экрана нет памяти, так как WebView визуализируется полностью, когда он встроен в другое представление прокрутки.

Я считаю, что это ошибка в Android, которая не автоматически возвращается к этому (медленнее, но работает).

Я создал что-то подобное, и все, что мне было нужно, это добавить это в свой WebView :

 android:layout_height="match_parent" 

Это работает для меня:

 <WebView android:id="@+id/wv" android:layout_width="match_parent" android:layout_height="match_parent" android:scrollbars="horizontal"/>