Что означает blockWebkitDraw и как его исправить?

Я обертываю приложение Android с помощью WebView, и для этого требуется рендеринг холста HTML5. Он отлично работает на всех моих устройствах, кроме одного. Моя Galaxy S4 (4.2.2) мигает холстом, а затем быстро становится серым. Вот сообщение logcat, которое он производит:

D/GestureDetector (20071): [Surface Touch Event] mSweepDown False, mLRSDCnt: -1 mTouchCnt: 7 mFalseSizeCnt: 0

V/WebViewInputDispatcher (20071): blockWebkitDraw

V/WebViewInputDispatcher (20071): blockWebkitDraw lockedfalse

D/webview (20071): blockWebkitViewMessage = false

Я нажимаю на кнопку, затем холст должен отображать. Поэтому первый элемент журнала относится к событию с поверхностным касанием. Он работает на моем S4, когда я пингую свое приложение, используя браузер webkit напрямую, но когда его обертывание или использование Кордовы дает мне эту ошибку. Я добавил два скриншота для дальнейшего отображения проблемы. Первая выполняется правильно, вторая проблема.

Android 2.3.6:

Android: 4.2.2:

Итак, вернемся к моему вопросу. Что происходит с этим сообщением? Есть ли у кого-нибудь какие-либо предложения о том, как правильно отобразить холст?

Ответ 1

Я смог исправить эту проблему, установив минимальную версию sdk в файле манифеста Android до 14:

<uses-sdk android:minSdkVersion="14" />

В версии 14 сообщения все еще появляются в журнале, но события касания обрабатываются. Когда я устанавливаю minSdkVersion обратно, события касания не обрабатываются. Отключение аппаратного ускорения в манифесте, а также различные стили webkit CSS не помогли. Только настройка minSdkVersion исправила это для меня.

Как бы то ни было, на вкладке Galaxy поддержка SDK для более старых версий вызывает проблемы с обработкой событий javascript touch, а blockWebkitDraw остается верным, пока происходит движение касания. Это не позволяет моему холст-коду получать события touchmove и выполнять ничью. Когда я устанавливаю версию SDK в 14, blockWebkitDraw получает значение true при срабатывании события касания, но после того, как сенсорный процесс обрабатывается, он не отменяется, и код холста для рисования получает вызов.

Ответ 2

Я немного просмотрел классы WebView и WebViewInputDispatcher, но ничего не придумал. Может быть, вы можете посмотреть там.

http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/webkit/WebView.java http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.2.2_r1/android/webkit/WebViewInputDispatcher.java

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

Ответ 3

Я стучал головой с очень похожим вопросом во время тестирования на Galaxy Tab 2. В моем случае у меня была простая гиперссылка, а не кнопка, но проблема такая же. Вот что я обнаружил:

Сообщение об ошибке в моей консоли с тегом WebViewInputDispatcher и значением blockWebkitDraw lockedfalse появляется каждый раз, когда я касаюсь экрана, независимо от того, нажимаю ли я кнопку или ссылку. Поэтому это сообщение об ошибке относится к событиям onTouch, а не к вашей кнопке, как вы могли ожидать.

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

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

Ответ 4

У меня была аналогичная проблема на Galaxy S3. Я нашел решение в этом ответе: fooobar.com/info/309229/.... Проблема была решена путем добавления следующего css ко всем проблемным элементам DOM:

-webkit-transform: translate3d(0,0,0);
transform: translate3d(0, 0, 0);

Применение translate3d к элементу может включать аппаратное ускорение на некоторых устройствах (см. этот ответ: fooobar.com/info/90334/...), поэтому это может также помочь в рендеринге.