support navegadores internet funciona compatibilidad jquery jquery-ui frames internet-explorer-6

jquery - navegadores - Marcos IE6 y fuga de memoria



jquery support (3)

No ha publicado ningún código para juzgar esto desde ... pero muchos de estos escenarios resultan del uso incorrecto de cierres.

La lectura incluye, pero no se limita a:

Antes de comenzar esta pregunta, entiendo que cada aspecto de ella es incorrecto. Por favor tenlo en mente...

Tengo una aplicación de intranet CRM-ish con un teléfono integrado desarrollado en 2001 que heredé. Básicamente es una aplicación de cobranza que integra los controles de telefonía con un front-end basado en web para la administración de cuentas. (Telefonía Genesys y un sistema de colecciones basado en AS400 ... usando MQSeries)

Estoy tratando de modernizar esta aplicación tanto como sea posible antes de llamarlo "fin de la vida". Como parte de mis intentos de modernizarlo, he implementado jQuery & jQuery UI para mi funcionalidad JS y UI. No me estoy volviendo loco con eso, pero está bastante arraigado.

Ahora ingrese el problema: actualmente usamos IE6 y la aplicación se construye utilizando marcos. La implementación de las bibliotecas jQuery ha expuesto la naturaleza similar a un tamiz de la aplicación desde una perspectiva de memoria. En la actualidad consume alrededor de 75Mb de memoria en el arranque y crece hasta 150Mb - 300Mb después de unas 2-3 horas. Entonces el navegador se bloquea.

He reducido las pérdidas de memoria a la diafonía entre los cuadros. He probado las páginas individualmente en sIEve y Drip y no se han encontrado fugas. Pero acceda a las páginas dentro del conjunto de marcos y es una bomba de tiempo.

Sé que la respuesta es rediseñar la aplicación sin marcos y comenzar a usar un mejor navegador. Hay dos problemas con eso:

  1. He probado esto en IE9 y los problemas siguen ahí, pero un poco más controlados

  2. Rediseñar la aplicación tomaría aproximadamente $ 500k y 6-12 meses.

¿Alguien sabe una forma de resolver el problema de "pérdida de marco"? Sé que no he dado ningún ejemplo de código pero solo estoy buscando conocimiento general. Estoy llamando al CollectGarbage() IE CollectGarbage() en onload y onunload para cada página en la aplicación, pero fue en vano. Intenté llamar al método empty() en jQuery. Intenté configurar todos los elementos del elemento document.body para null . Nada está funcionando.

Odiaría tener que rechazar todos estos cambios porque en realidad hay algunas características de reducción de costos bastante grandes que se han implementado.

INFORMACIÓN ADICIONAL

Pude identificar el escenario en el que se producen las pérdidas de memoria. Pensé que era una "diafonía" entre fotogramas, pero parece que las pérdidas de memoria ocurren cuando se refresca un solo fotograma.

Configuré un conjunto de marcos básico con 5 instancias de la misma página (una que estoy bastante segura de que no tiene filtraciones por cada miembro).

<html> <head> <title>Frame Leak Test</title> </head> <frameset cols="*" rows="50%,50%" frameborder="1"> <frameset cols="33%,33%,34%" rows="100%"> <frame src="http://npasappgeneqa02/live/" /> <frame src="http://npasappgeneqa02/live/" /> <frame src="http://npasappgeneqa02/live/" /> </frameset> <frameset cols="50%,50%" rows="100%"> <frame src="http://npasappgeneqa02/live/" /> <frame src="http://npasappgeneqa02/live/" /> </frameset> </frameset> </html>

La página de índice que se está cargando no muestra fugas en sIEve.

Cuando cargo la página de conjunto de marcos en sIEve y hago clic en la actualización automática, no se informan pérdidas de memoria. Sin embargo, si hago clic derecho -> actualizar en un marco individual, el 75% de los elementos cargados en el DOM aparecen como fugas.

Obviamente, la actualización automática es equivalente a la actualización F5 / shift + F5. Y eso limpia la memoria de la página. Pero cuando se recarga un cuadro individual, la memoria nunca se borra ... aparentemente. Y cada pantalla que mis usuarios deben ver vuelve a cargar en el marco principal.

No puedo simplemente actualizar el conjunto de marcos porque hay un softphone en el conjunto de marcos que generará Armageddon si se actualiza o se cierra la sesión de forma incorrecta.

¿Alguien sabe de una forma de controlar la memoria del conjunto de marcos sin refrescarla?

Solo quería dar una actualización sobre esta situación particular. Creo que encontré una solución aceptable para este problema de pérdida de memoria:

  1. En lugar de utilizar la biblioteca jQueryUI completa en las páginas donde se necesitaban elementos de IU, utilicé los scripts individuales minimizados (uicore + datepicker, etc.).
  2. Siempre que sea posible, evité los elementos de la interfaz de usuario que utilizaban el script de widgets, ya que aquí es donde surgía la mayor concentración de problemas.
    • a. Esto me obligó a escribir scripts personalizados para los elementos del button y el elemento del accordion .
  3. Dado que esta aplicación se ejecuta en un frameset , la utilización de métodos de window (es decir, window.onload , window.onunload ) no funciona, ya que la ventana solo carga o descarga con el frameset . Para combatir esto, implementé los métodos de document.body , específicamente, document.body.onbeforeunload y haciendo un desvinculación global para eliminar las referencias que estaban colgando ( $("*").unbind(); ).

Con la metodología utilizada anteriormente, mi consumo de memoria de 4 horas en IE6 (e IE8) ha disminuido de ~ 200-250 Mb a ~ 80-95 Mb. Mi objetivo era mantener un consumo de 8 horas por debajo de 150Mb y creo que esto logrará la tarea.

Gracias a todos por toda su ayuda.

Sugeriría que JSLint tu código JS a través de JSLint o JSHint .

Estas dos utilidades (*) son inspectores de calidad de código para Javascript. Las cosas de las que se quejan son donde el código JS es válido pero contiene prácticas de programación deficientes.

Hay muchas posibilidades de que retomen al menos algunas de las cosas que le causan problemas.

(* JSHint es una bifurcación de JSLint, pero son lo suficientemente diferentes ahora que vale la pena probarlos a ambos)