Titanium (Node.js) require() против Global

Я не уверен, считается ли что-либо из следующего лучшей практикой.

Среда: Appcelerator Titanium/Alloy — платформа для создания нативных приложений. Он использует javascript в качестве источника, сравнимого с node.js (больше похоже на CommonJS).

Случай 1:

Многие файлы, где я использую:

var localInstance = require('main/module/sub/foobar')({ initialize: true});

Случай 2:

Основной файл, в котором я бы сделал глобальный:

Globalnamespace.foobar = require('main/module/sub/foobar');

И в других файлах:

var localInstanceWhichINeed = Globalnamespace.foobar({initialize: false});

Дело в том, что модуль нужен не везде, и помещение его в глобальное пространство имен может занять лишнюю память. Каждый модуль foobar должен быть создан в каждом файле, поэтому нет глобального экземпляра (только модуль для создания экземпляра).

Я говорю о памяти мобильного устройства и пытаюсь ее сократить. Отсюда вопрос.


node.js javascript commonjs require titanium
person Flame    schedule 11.03.2015    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Я не лучший человек, чтобы ответить на это. Тем не менее, я исследовал тот же вопрос и поэтому имею некоторое представление, которое может вам помочь ;-)

Модули CommonJS работают так, что они загружаются при первом обращении к ним. Таким образом, последующее направление стоит очень дешево. Поэтому я бы сказал, что это больше вопрос «аромата». Лично я склонен использовать первый подход, который вы упомянули, т.е. что-то вроде этого:

var UiHelper = require('ui/helper);
  :
  :
UiHelper.showListBox(.....);

Итак, вернемся к вашему вопросу - я не думаю, что есть наказание за использование того или другого. Это больше о том, как вы хотите структурировать свой код ;-)

/Джон

person John Dalsgaard    schedule 11.03.2015
comment
хорошо, это имеет смысл, если require() уже использует дружественный подход для предотвращения бесполезной перезагрузки, тогда я выберу этот вариант. Я предполагаю, что это все еще микрооптимизация, потому что case 2 загрузит его в местах, где он может вам не понадобиться. - person Flame; 12.03.2015
comment
Я согласен с этим, поэтому я использую другой подход, как показано (например, ваш случай 1) ;-) - person John Dalsgaard; 13.03.2015

arrow_upward
1
arrow_downward

В частности, в отношении использования пространства имен и Titanium: я бы не рекомендовал это. Пространства имен так легко выходят за рамки. Даже если привязать их к Ti.App (тоже не лучшая идея).

И CommonJS (особенно в последних версиях Titanium) действительно хорош в том, что не перезагружает то, что было загружено ранее.

Если вы беспокоитесь о памяти, убедитесь, что все ваши представления и окна уничтожаются, когда вы закончите с ними. Это вещь номер один в Titanuim.

person Ric Johnson    schedule 12.03.2015
comment
+1 А так же отметил бы как лучший ответ, если бы ты был первым. Мне еще предстоит определить структуру для легкого уничтожения представлений и контроллеров (я использую Alloy MVC), так как я так много слышал о паршивой сборке мусора, пока вы сами активно не помогаете ей. - person Flame; 12.03.2015
comment
Я не использую сплав, но общая практика заключается в создании внеэкранного окна, перемещении в него всех представлений и удалении окна. Не так хорошо работает в Android, как окна, которые любят появляться на экране, но Android лучше справляется со сборкой мусора... - person Ric Johnson; 13.03.2015