Конструкции JavaScript/шаблоны, которые следует избегать в iOS Safari?

У меня есть веб-приложение, содержащее огромное количество сгенерированного JavaScript. Потребление памяти в 6 раз работает между веб-приложением в Chrome на рабочем столе по сравнению с запуском веб-приложения в UIWebView на (обновленном) iPad.

Какие конструкторы или шаблоны я должен избегать, чтобы получить потребление памяти в iOS наравне с потребностью в Chrome?

Характеристика сгенерированного JavaScript:

Код генерируется Haxe.
Код является "объектно-ориентированным", поскольку он сильно использует prototype, но в цивилизованном способе.
Этот код сильно использует именованные индексы для объектов JavaScript для реализации хеш-таблиц.
Есть много строк, но вряд ли какие-либо конкатенации строк.

Кажется, что нет утечек памяти; чрезмерное потребление памяти на iOS сразу отображается при создании объектов (фиксированный набор) Javascript.

Ответ 1

Так как ваш код работает хорошо на рабочем столе, это, вероятно, некоторые основные причуды в iOS. Я сомневаюсь, что вы можете исправить использование более объектно-ориентированного способа программирования. Конечно, это может немного уменьшить объем памяти, но не в 6 раз.

UIWebView довольно известен тем, что для создания утечек памяти вы можете попробовать использовать более новую версию (iOS 8+). WKWebView имеет много лучшую сборку мусора.

Справочник Apple WKWebView

Ответ 2

Мое предложение состоит в том, что вы смотрите на часть DOM вашего приложения. Я не думаю, что в вашей структуре JavaScript есть много оптимизаций. Слабой ссылкой в мобильных/планшетах обычно является процесс рендеринга. Если ваша цель - сократить потребление памяти, вы можете изменить способ работы DOM. попытайтесь сохранить как можно меньше узлов DOM, спрячьте содержимое (node -content) скрытых узлов DOM. такого рода манипуляции с DOM, помогли мне в прошлом, чтобы сделать мое веб-приложение более отзывчивым и максимально сократить использование памяти.

Виртуальный прокрутка - это что-то полезное для того, чтобы сохранить как можно меньше dom, виртуальный прокрутить

Ответ 3

Потенциальный способ, которым вы можете попробовать оптимизировать свой код, - это использовать GWT (компилятор которого, я считаю, является более оптимизирующим компилятором, чем компилятор haxe js).

Сначала я скомпилировал весь ваш код haxe в java, а затем конвертировал его в js через GWT и посмотрел бы, будут ли требования к памяти оставаться одинаково высокими.

Если преобразовать в java, то в GWT слишком сложно, близкое приближение заключается в использовании компилятора google закрытия на результирующем javascript, сгенерированном через haxe. Я не уверен, что haxe способен выводить javascript таким образом, который совместим с режимом ADVANCED_OPTIMIZATION (https://developers.google.com/closure/compiler/docs/compilation_levels#advanced_optimizations), что и есть то, что вы (в противном случае закрытие не лучше простого минимизатора кода).

Ответ 4

Вы упомянули, что он сильно использует прототип. Это может быть причиной: если вы думаете, что ваши объекты могут использовать один и тот же прототип, попробуйте сделать это; Например:

baz.Bar = function () {
    // constructor
};

baz.Bar.prototype = {
    fooProp: ["bar", "foo"],
    foo : function (){
        //method
    }
};

baz.Bar2.prototype = baz.Bar.prototype;

Вы заметите, что baz.Bar2.prototype указывает на baz.Bar.prototype. С помощью этой концепции вы можете сохранить память, которая будет выделена baz.Bar2, поскольку она делится с baz.Bar.