¿Construcciones/patrones de JavaScript para evitar en iOS Safari?
v8 haxe (4)
Tengo una aplicación web que contiene una gran cantidad de JavaScript generado. El consumo de memoria difiere en un factor 6 entre la ejecución de la aplicación web en Chrome en un escritorio en comparación con la ejecución de la aplicación web en un UIWebView en un iPad (actualizado).
¿Qué construcciones o patrones debo evitar para obtener el consumo de memoria en iOS a la par con Chrome?
Caracterización del JavaScript generado:
- El código es generado por Haxe .
- El código está "orientado a objetos", ya que hace un uso intensivo del
prototype, pero de una manera civilizada . - El código hace un uso intensivo de los índices con nombre en los objetos JavaScript para implementar tablas hash.
- Hay muchas cadenas, pero casi ninguna concatenación de cadenas.
No parece haber ninguna pérdida de memoria; El consumo excesivo de memoria en iOS se muestra inmediatamente después de la construcción del (conjunto fijo de) objetos Javascript.
Dado que su código se ejecuta bien en el escritorio, es probable que se trate de una característica subyacente en iOS. Lo cual dudo que puedas arreglar usando una forma de programación más orientada a objetos. Claro que esto podría reducir la huella de memoria un poco, pero no por un factor de 6.
UIWebView es bastante conocido por crear fugas de memoria que podrías intentar usar el más nuevo (iOS 8+) WKWebView tiene una recolección de basura mucho mejor.
Mi sugerencia es que mire la parte DOM de su aplicación. No creo que haya mucha optimización que se pueda hacer en su estructura de JavaScript. El enlace débil en los dispositivos móviles / tabletas suele ser el proceso de renderizado. Si su objetivo es reducir el consumo de memoria, puede cambiar la forma en que funciona su DOM. intente mantener lo mínimo posible los nodos DOM, oculte el contenido (contenido de nodo) de los nodos DOM ocultos. este tipo de manipulaciones de DOM me ayudó en el pasado a hacer que mi aplicación web sea más receptiva y a que el uso de la memoria sea lo más bajo posible.
Virtual Scroll, es algo útil para mantener el dominio lo más pequeño posible, virtual-scroll
Una forma potencial de intentar optimizar su código es a través de GWT (cuyo compilador, creo, es un compilador más optimizador que el compilador js de haxe).
Primero compilaría todo su código haxe en java, luego lo convertiría en js a través de GWT, y vería si los requisitos de memoria siguen siendo similares.
Si la conversión a java, entonces a GWT es demasiado difícil, una aproximación cercana es utilizar el compilador de cierre de google en el javascript resultante generado a través de haxe. No estoy seguro de si haxe es capaz de generar javascript de una manera que sea compatible con el modo ADVANCED_OPTIMIZATION ( https://developers.google.com/closure/compiler/docs/compilation_levels#advanced_optimizations ), que es lo que necesita para hacer (de lo contrario, el cierre no es mejor que un simple minimizador de código).
Usted mencionó que está usando mucho de prototipo. Esa podría ser una razón: si cree que sus objetos pueden compartir el mismo prototipo, intente hacerlo; Por ejemplo:
baz.Bar = function () {
// constructor
};
baz.Bar.prototype = {
fooProp: ["bar", "foo"],
foo : function (){
//method
}
};
baz.Bar2.prototype = baz.Bar.prototype;
Notará que baz.Bar2.prototype apunta a baz.Bar.prototype. Con este concepto, puede guardar la memoria que se asignará por baz.Bar2 porque se comparte desde baz.Bar.