Во время разработки апплета отдел контроля качества несколько раз обнаруживал на странице белый экран, который трудно воспроизвести и отладить, поэтому я хочу изучить проблему белого экрана апплета.
Из официальной документации разработчика апплета мы знаем, что апплет WeChat работает на трех терминалах: iOS (iPhone/iPad), Android и инструментах разработчика для отладки. Среда выполнения скрипта с тремя терминалами и среда, используемая для рендеринга неродных компонентов, различаются [1]:
- В iOS код javascript слоя логики апплета выполняется в JavaScriptCore, слой представления визуализируется WKWebView, а среда — iOS8, iOS9, iOS10;
- На Android в старой версии работает javascript код слоя логики апплета, в X5 JCore слой представления рендерится X5 на базе ядра Mobile Chrome 53/57;
- В новой версии javascript-код слоя логики апплета работает в V8, а слой представления рендерится саморазработанным движком XWeb на основе ядра Mobile Chrome 53;
- В инструменте разработки код javascript уровня логики апплета выполняется в NW.js, а уровень представления визуализируется с помощью Chromium 60 Webview.
Поговорим о том, что такое WKWebView, Mobile Chrome 53/57, Mobile Chrome 53.
На веб-сайте документации для разработчиков Apple есть введение в WKWebView.Короче говоря, WKWebView — это компонент, который отображает интерактивный веб-контент для встроенного браузера приложения, заменяя старую версию компонента UIWebView [2]. Будь то UIWebView или WKWebView, все они принадлежат IOS WebView. Мы можем понимать WebView как системный компонент мобильной операционной системы. Будь то встроенный браузер мобильного телефона или другие приложения, такие как WeChat и т. д., если вы хотите представить интерактивный веб-контент, вы можете вызвать для этого WebView. То же самое верно и для Android WebView [3].
Теперь мы можем назвать WKWebView WebView на стороне IOS, тогда что такое Mobile Chrome 53/57 на стороне Android или Mobile Chrome 53, и какова связь между этими двумя и WebView? Мы можем понимать Mobile Chrome 53/57 как версию Chrome для Android 537, где 537 относится к версии ядра WebKit, принятой механизмом компоновки Chrome.Подробности см. в истории версий Google Chrome[4]. Следует отметить, что здесь сомнительно, является ли 53/57 537, и не было найдено никаких достоверных справочных материалов, но это не должно влиять на наше исследование и может быть проигнорировано. На данный момент представлены две концепции: механизм компоновки и ядро WebKit. Далее краткое введение в механизм компоновки и ядро WebKit.
Все мы знаем, что у браузера есть два важных движка: движок рендеринга (движок рендеринга, также известный как движок верстки, то есть упомянутый выше движок верстки, который для удобства будет описан как движок рендеринга) и движок JS. Механизм рендеринга отвечает за синтаксический анализ содержимого веб-страницы, расчет режима отображения и вывод его на устройство отображения. Механизм JS отвечает за синтаксический анализ языка JavaScript и реализацию эффекта динамического взаимодействия веб-страницы. В начале движок рендеринга и движок JS не были четко разграничены, позже движок JS становился все более и более независимым, и ядро имело тенденцию ссылаться только на движок рендеринга, то есть ядро браузера - это используемый движок рендеринга. браузером, в основном ссылаясь на исследовательский отчет ядра X5 [5]. В последующем обсуждении ядро браузера относится исключительно к механизму рендеринга.
Тогда что такое ядро WebKit? Это должно вернуться к истории WebKit. В 1998 году сообщество свободного программного обеспечения KDE разработало механизм набора HTML KHTML и механизм синтаксического анализа JavaScript KJS, которые являются двумя важными механизмами для современных браузеров. Разработчик Apple Дон Мелтон запустил проект WebKit в 2001 году на основе KDE. В начале WebKit был только ответвлением KDE.Мы можем понять, что WebKit является ответвлением, основанным на KDE. Позднее, в проекте WebKit, KHTML был назван WebCore, а KJS — JavaScriptCore, в основном ссылаясь на Википедию [6]. Пока что мы можем ответить, что, по крайней мере, для продуктов Apple ядром браузера является WebKit, то есть движок рендеринга использует ядро WebKit.
Проект webkit — это проект, начатый Apple для разработки собственного браузера. Google также создал проект Chromium при разработке браузера Chrome. В проекте Chromium движок парсинга JavaScript использует знаменитый движок V8, разработанный самой Google, а движок рендеринга использует ядро WebKit. К июлю 2013 года проект Chromium заменил механизм рендеринга на механизм Blink и принял его в Chrome 28 и последующих версиях [4][7]. Движок Blink — это ответвление форка Google, основанное на WebCore в проекте WebKit [8][9]. Мы можем соединить KDE, WebKit и Chromium на одной диаграмме:
Теперь давайте вернемся и посмотрим на Mobile Chrome 53/57 или Mobile Chrome 53. На самом деле его ядро все еще эволюционировало из WebKit. Зайдя так далеко, всего одно предложение: апплет работает поверх WebView. Таким образом, наше первоначальное намерение, изучение проблемы белого экрана небольших программ, на самом деле состояло в том, чтобы исследовать проблему белого экрана WebView. Если вы хотите быть немного более подробным, это причина белого экрана WKWebview, Android WebView.
Что касается белого экрана WKWebview, общие причины, перечисленные в Интернете, примерно следующие:
- Когда использование памяти относительно велико, процесс WebContent завершается сбоем, что приводит к феномену белого экрана.
- URL-адрес недействителен или содержит китайские символы.
- Когда WKWebview был впервые запущен, в IOS8.0~8.2 иногда появлялся белый экран.
- Из-за вложенной структуры компонентов прокрутки проблема не обновления.
По причине 3 решение состоит в том, чтобы оценить версию системы IOS и использовать UIWebView, если она меньше 8.2. С точки зрения разработчиков небольших программ это, кажется, не имеет к нам никакого отношения. Апплет - это платформа. Мы разрабатываем наше приложение-апплет на этой платформе. Если в апплете тоже есть эта проблема, ее может решить только команда апплета. Также, например, причина 4, нам все равно придется вкладываться, и если возникнет какая-то проблема, команда апплета решит ее. Что касается причины 2, если апплет изначально разработан, URL-адреса перехода между страницами также могут нормально переходить, если они содержат китайский язык.Это должно быть совместимо с апплетом. Но причина 1, это имеет к нам большое отношение, например, мы определяем большое количество переменных, но они не освобождаются после использования, поэтому эта часть памяти будет занята до тех пор, пока апплет не будет уничтожен. В другом примере, если мы оперируем относительно большой переменной в определенный момент, использование памяти также может резко возрасти за короткий период времени. Точно так же большинство проблем, вызывающих белый экран Android WebView, могут быть решены только командой апплета.
Таким образом, с точки зрения фронтенд-разработки апплетных приложений, мы можем сделать все возможное, чтобы избежать проблемы с белым экраном, вызванной перезапуском некоторых WebView из-за ограниченного использования памяти. До сих пор проблема белого экрана изученного нами апплета может быть обращена к изучению оптимизации памяти апплета.
Ниже приводится сводка операций, которые могут вызывать предупреждения памяти во время обычного процесса разработки:
-
Используйте большие изображения и изображения с длинным списком. Согласно большинству случаев, проанализированных командой Mini Program, использование больших изображений и изображений с длинным списком приведет к повторному использованию WKWebview [10]. Среди них изображения на странице длинного списка относятся к страницам, содержащим большое количество списков, и изображения упоминаются в каждом списке.
-
Произвольно определенная переменная, из-за механизма небольших программ, но не выпущенных. Переменные, определенные в следующих четырех сценариях, даже если покинуть текущую страницу, переменная не будет восстановлена:
-
Глобальная переменная определена вне конструктора страницы.
-
Данные, определенные внутри данных.
-
Определяется внутри страницы, данные класса data.
-
Данные смонтированы в getApp().globalData.
Если мы определим вышеуказанные переменные на странице testvar, testvar перейдет на следующую страницу otherpage через navigationTo, На странице otherpage мы можем получить ссылку на страницу testvar через getCurrentPages(), а затем получить переменные внутри. Открытие новой страницы через navigationTo, предыдущая страница попадает в стек страниц, и страница просто скрывается, а не выгружается[11]. Стек страниц фреймворка апплета может поддерживать до 10 слоев страниц. Представьте себе эти страницы со сложными взаимодействиями, каждый слой страниц сопровождается большим количеством данных и даже содержит много изображений, и, учитывая сосуществование многослойных страниц, использование памяти будет значительным. Пока страница в стеке страниц не будет выгружена, это приведет к постоянному использованию памяти.
-
-
Операции с большими данными за короткий промежуток времени. Предположим, в определенный момент времени нам нужно оперировать большим объемом данных, возвращаемых интерфейсом, что может привести к мгновенному использованию памяти.
-
Непрерывное накопление данных списка приводит к тому, что некоторые данные становятся аномально большими. Представьте, что если наша страница со списком имеет много данных, то после каждого запроса на подкачку мы объединяем новые данные с существующими, со временем эти данные могут стать гигантскими, постепенно вымывая из нас память.
К счастью, описанных выше операций, которые могут привести к большому использованию памяти, можно избежать или оптимизировать.
- Для большого изображения по причине 1 мы можем соответствующим образом сжать его. Если больше не нажимается, или картинка должна быть такой большой, и одна картинка не большая, а списков слишком много, что делать? Что ж, это можно временно отложить, и соответствующее решение будет упомянуто в последующем обсуждении.
- Для причины 2 нам нужно объединить фактические бизнес-сценарии.Для тех переменных, которые могут быть отброшены после использования и не должны существовать на протяжении всего жизненного цикла страницы, не используйте эти четыре метода для определения данных.
- По причине 3 мы можем попытаться договориться с разработчиком интерфейса, чтобы интерфейс не возвращал большое количество данных за один раз с помощью пейджинга или других методов.
- Для причины 4 основная причина заключается в том, что непрерывные запросы на подкачку приводят к тому, что новые данные постоянно добавляются к существующим данным.В этом сценарии нам нужно отбросить некоторые из существующих данных. Какие существующие данные отбрасывать требует принципа. Представьте себе сценарий, в котором мы вводим список страниц списка и определяем listData для хранения данных, запрошенных каждой страницей. Приходят данные первой страницы, listData содержит только данные первой страницы. Пришла вторая страница данных, конкатируем новые данные на первую страницу, в это время listData содержит данные первой и второй страниц. Приходят данные третьей страницы, а listData содержит данные первых трех страниц. А теперь давайте остановимся и подумаем. В данный момент мы представляем пользователю данные на третьей странице, а данные на первой странице находятся в невидимом состоянии. Раз они невидимы, то почему бы их не отбросить? Если пользователь проводит пальцем вверх и ему нужно представить данные первой страницы, мы можем снова запросить данные первой страницы. ListData отбрасывает часть данных, которые со временем будут возвращены на уровень представления, а некоторые узлы на уровне представления также будут уничтожены, так что часть памяти, занятая уровнем службы приложений и уровнем представления, будет освобождена. . Конечно, предлагаемое нами решение состоит в том, чтобы решить проблему, заключающуюся в том, что непрерывные запросы на подкачку вызывают постоянное добавление новых данных к существующим. данные, они должны быть оценены и взвешены в сочетании с фактическим бизнесом.
Я надеюсь, что все могут критиковать и исправлять!
использованная литература: [1]:Developers.WeChat.QQ.com/mini программа… [2]: developer.apple.com/document ATI… [3]: developer.Android.com/reference/ ах… [4]: Итак, Wikipedia.org/wiki/Google… [5]: nuggets.capable/post/684490… [6]: zh.wikipedia.org/wiki/WebKit [7]: Это.Wikipedia.org/wiki/Google… [8]: This.Wikipedia.org/wiki/CH RO fan… [9]: zh.wikipedia.org/wiki/Blink [10]:Developers.WeChat.QQ.com/mini программа… [11]: Developers.WeChat.QQ.com/mini программа…