IOS WKWebView JS не обновляет модификацию атрибута, когда приложение в фоновом режиме

Привет, у меня есть приложение iOS с расширением Watch. При запуске приложения Apple Watch оно запускает приложение для iPhone и сохраняет его в живых, отправляя sendMessage вызовы каждые пару секунд. Приложение iPhone затем переходит на веб-сайт в WKWebView, проверяет его содержимое каждые две секунды, а затем отправляет некоторые данные в Apple Watch для отображения там.

Отображение постоянно обновляемого контента в Apple Watch работает отлично, я получаю данные на iPhone следующим образом:

self.webView.evaluateJavaScript("document.documentElement.outerHTML.toString()",
                                   completionHandler: { (html: Any?, error: Error?) 

. . . //splitting html content into TFHppleElements

self.contentArray.add((element.search(withXPathQuery: "//div[contains(@class, 'article-title')]")[0] as AnyObject).content)

который я запускаю каждые 5 секунд. Как только текст в article-title изменится, изменения будут видны на моих часах. Работает.

Все элементы содержат что-то вроде style="z-index: 206; height: ..., и я успешно разбираю его, захватывая атрибуты, а затем подставляя его вниз.

let styleContainer = element.attributes["style"] as! String
var firstHalf = styleContainer.components(separatedBy: "; height:")
...

Я использовал значение z-index для сортировки строк таблицы в Apple Watch, но после 1-3 обновлений z-индекс всех элементов переставал обновляться. Содержимое (например, название статьи) все еще обновлялось, поэтому поток данных определенно работал, но мне было интересно, почему z-index остался прежним. Сначала я подумал, что это проблема с моей сортировкой или во время передачи Apple Watch, но я не смог это уладить - когда я запускал приложение на iPhone, он всегда получал нужный индекс, но когда я бегал приложение, запустив его на часах, появилась проблема, описанная выше.

После нескольких дней беспорядка с структурами данных (все еще думая, что ошибка была на моей стороне), она, наконец, ударила меня: когда приложение запускается в фоновом режиме, z-индекс на самой странице не получает обновления. Я проверил это, запустив приложение на своем Watch и получив неправильный z-index ', как обычно, но затем я открыл приложение Watch и запустил приложение на iPhone. Я видел, как WKWebView обновлял порядок элементов в соответствии с к их z-индексу, и вдруг я получил правильный z-индекс для каждого элемента, даже после нажатия кнопки home. Это объясняет многое, но по-прежнему не помогает мне в решении проблемы.

Как я могу обмануть WKWebView, чтобы позволить JS обновлять все элементы z-index при работе в фоновом режиме? То, что я нахожу странным, заключается в том, что эта проблема не возникает после открытия iPhone приложение в течение короткого периода времени, но я не могу попросить моих пользователей открывать и "сворачивать" приложение каждый раз, когда вы хотите получить доступ к приложению Watch, поскольку цель приложения Watch - держать телефон в кармане.

Активация приложения iPhone с помощью sendMessage также вызывает viewDidLoad, поэтому нет никакой реальной разницы, что я могу указать между запуском приложения на телефоне вручную и делать это с помощью Watch. Сам Javascript также работает в фоновом режиме, так почему бы все обновить, за исключением атрибутов z-index? Предотвращение "графических" обновлений, выполняемых в фоновом режиме, было бы понятным в отношении сохранения времени автономной работы, но также не текстового "графического"? И почему это будет отличаться для обычного приложения, если оно было запущено вручную?

~~Удалено, потому что ниже произошло только одно, странное.~~

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

Before:
A1: 26
A2: 27
A3: 28
A4: 29
After pushing A1 to the top in the background:
A2: 27
A3: 28
A4: 29
A1: 29
After manually opening the app on the phone:
A2: 26
A3: 27
A4: 28
A1: 29

Кажется, что WebKit имеет проблемы с z-index, поэтому давайте посмотрим, куда меня ведет путешествие

Ответ 1

Привет, я не уверен, что у меня есть определенный ответ на этот вопрос, но у меня есть несколько вещей, которые вы можете попытаться вам помочь.

Прежде всего вам понадобится визуализация HTML/CSS в WKWebView, чтобы сделать это, вы можете открыть Safari, а в верхней строке нажмите "Разрабатывать", а третий элемент должен быть именем вашего компьютера, который откроет список видимых экземпляров WebView. Вы можете щелкнуть по той, которая работает в данный момент (вы увидите, что экран будет подсвечиваться при наведении указателя мыши на опцию). Откройте это, а затем вы можете просмотреть источник, стиль и использовать консоль.

Здесь попытайтесь определить, действительно ли Z-индексы обновляются в WebView или нет. Если они не такие, как я подозреваю, это заставит меня поверить, что это проблема кеширования. Из моего опыта одна вещь, которая делает WKWebView более совершенным, чем традиционный UIWebView, - это механизмы кэширования, которые он имеет. Он попытается кэшировать весь CSS, который может, поэтому вы можете попытаться очистить кеш между нагрузками.

let dataTypes = NSSet(array: [WKWebsiteDataTypeDiskCache, WKWebsiteDataTypeMemoryCache, WKWebsiteDataTypeLocalStorage])
let epoch = NSDate(timeIntervalSince1970: 0)
WKWebsiteDataStore.default().removeData(ofTypes:dataTypes as! Set<String>, modifiedSince:epoch as Date, completionHandler:{})

Обратите внимание, что все экземпляры WKWebViews используют один и тот же хранилище данных, поэтому вы фактически не очищаете данные в своем экземпляре WebView, а скорее в WKWebSiteDataStore.

Также я бы использовал javascript для перезагрузки страницы:

webView.evaluateJavaScript("location.reload();", completionHandler: nil)

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