Red de conocimiento informático - Problemas con los teléfonos móviles - [iOS] Resumen de los problemas encontrados al usar WKWebView

[iOS] Resumen de los problemas encontrados al usar WKWebView

Cuando usamos WKWebView para obtener userAgent, si queremos configurarlo globalmente para que todos los WKWebViews puedan tener efecto, podemos configurarlo en AppDelegate, pero requiere un objeto de instancia de WKWebView, por lo que podemos escribirlo así:

De esta manera, encontrará que la configuración siempre no es válida cuando se imprime la devolución de llamada:

En este momento, el campo de información es cero y el mensaje de error es el siguiente:

Mi conjetura: Esto se debe a que WKWebView El método evaluaJavaScript se ejecuta de forma asincrónica. Cuando WKWebView vuelve a llamar a este método, su objeto de instancia se ha liberado de la memoria cuando WKWebView vuelve a llamar a este método, lo que provoca que la devolución de llamada falle.

Hice la siguiente verificación y generé el objeto de instancia de webView en el método de devolución de llamada:

Encontrará que la salida es información tiene un valor y el error es cero, webView tiene un valor, y es normal, alguien dice, ¡esto no parece un problema! ¿En realidad? Si lo piensa detenidamente, encontrará que ¿qué sucede cuando se utiliza una instancia de webView en el cierre de devolución de llamada del método webView? ¡Sí, referencia circular! En este punto, la instancia de webView no es nula, lo que verifica que si la instancia de webView funciona correctamente, no habrá errores al obtener los resultados. Continuando con la validación anterior, hagamos una referencia débil:

En este punto, verá: ¡info y webView son cero y el error es el mismo que el anterior!

¡Esto básicamente verifica que la causa del problema es que webView se lanzó antes de tiempo!

Pero agregar esta configuración y configurar webView como una variable global parece un poco desventajoso. Puede configurarlo en la página usando webView o usar UIWebView en su lugar:

Hacer JS al interactuar con. en el local, el protocolo inyectado usando el siguiente método no es válido:

Luego úselo en el lado js

Al interactuar con el local, usar el siguiente método para inyectar el protocolo no es válido de:

Luego úselo en el lado js: no es necesario pasar parámetros aquí, solo escriba así

¡De esta manera, no responderá a los eventos js! !!!

En el método proxy:

¡¡¡No se recibió ninguna devolución de llamada!!!

De hecho, no es que el protocolo de inyección haya fallado, y allí No hay problema en usarlo de esta manera. El problema radica en los parámetros de postMessage. Si escribe con parámetros:

no hay ningún problema, por lo que si no necesita pasar parámetros, puedes escribir así:

Proporciona un diccionario vacío, ¡¡¡puedes interactuar normalmente!!!

En la página HTML cargada por WKWebView, si la presionas prolongadamente, aparecerá algunos cuadros de selección, si mantiene presionado el texto, aparecerá UIMenuController Cuadro de selección:

Si mantiene presionada la imagen, aparecerá la hoja de alerta:

Aquí puede guarde la imagen en el álbum del sistema (si tiene permiso) o cópiela en el portapapeles. Puede guardar la imagen en el álbum del sistema (si tiene permiso) o copiarla al portapapeles. Pero esto no es lo que necesitamos, ¿cómo desactivar estos comportamientos? Necesitamos comenzar con JS. Solo necesitamos ejecutar las siguientes dos líneas de JS:

Se puede inyectar al crear WKWebView:

También se puede ejecutar en el método proxy. después de cargar la página:

En la página HTML cargada, aparecerá inexplicablemente un cuadro flotante publicitario:

Cuando se abra, se verá así:

Y sólo aparecerá en redes móviles 4G.

Durante el proceso de coordinación, los estudiantes de front-end cambiaron algunas cosas, como el diseño de la página, los elementos de visualización, los métodos js, etc., ¡pero el lado de la aplicación no respondió!

Esto se debe a que WKWebView tiene un caché. Para garantizar que se cargue la última página cada vez, puede agregar una marca de tiempo al cargar el enlace. Por ejemplo, su dirección HTML es:

.

El uso general es el siguiente:

En este caso, hay un caché después de cargar una vez, no será la página más reciente cuando la cargue nuevamente. Puede usarlo así.

De esta manera, será el último cada vez que se cargue. Por supuesto, la desventaja es que consumirá algo de tráfico adicional cada vez.

Cuando no hay navegación en la página, el sistema ajustará automáticamente el contentInset de la vista de desplazamiento para que la vista esté siempre debajo de la barra de estado, pero si queremos que la coordenada y de la vista de desplazamiento comience desde la parte superior de la pantalla (barra de estado). Todos sabemos cómo cambiarlo, pero WKWebView no hereda de UIScrollView, por lo que no se puede configurar directamente.

Al interactuar con JS y utilizar el siguiente método para registrar un protocolo, se producirá un bloqueo:

Si registra repetidamente un protocolo con el mismo nombre, se producirá un bloqueo, por lo que Debes recordar eliminar el protocolo registrado después de usar webView:

La página de inicio de la aplicación, que usa WKWebView para alojar el contenido. Cuando la página de inicio de la aplicación usa WKWebView para alojar el contenido, si es el bootstrap. / En la página de publicidad, si se produce un gesto, como hacer clic en la pantalla cuando aparece la página de publicidad, retrocederá y se mostrará en la consola:

Agregue un punto de interrupción global y, después de la depuración, el La información del bloqueo es:

Revisé cierta información, pero no encontré el motivo específico, pero descubrí que esto está relacionado con el método +load, es decir, el método para inicializar la página publicitaria. en el método +carga.

Solución alternativa:

Coloque la inicialización de la vista de la página de anuncios/clientes potenciales en el método didFinishLaunchingWithOptions.