Что означает 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:

Введите описание изображения здесь

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

Solutions Collecting From Web of "Что означает blockWebkitDraw и как его исправить?"

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

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

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

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

Я немного просмотрел классы 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 / внутр / com.google.android / Android / 4.2.2_r1 / Android / WebKit / WebViewInputDispatcher.java

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

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

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

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

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

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

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

Применение метода translate3d к элементу может включать аппаратное ускорение на некоторых устройствах (см. Этот ответ: https://stackoverflow.com/a/18529444/3531606 ), поэтому он также может помочь в рендеринге.