Здравствуйте, уважаемые читатели блога сайт. Во вступительной статье я пытался в двух словах рассказать, а так же на пальцах разъяснить понятия категорий-разделов и показать, что на любой пункт любого можно повесить не только открытие одной статьи (материала), но и серии статей из одной категории или из одного раздела.
Из чего состоит и как работает движок Джумла
В этом посте я хотел бы остановиться на еще одном моменте в логике работы с этой системой, который вызвал у меня небольшие сложности в понимании. Но прежде я все-таки попробую описать из чего состоит сайт, созданный на бесплатной CMS (читайте про то, ). Ну, во-первых, при работе с этим движком мы имеем как бы два различных вебсайта.
Первый — это, собственно, основной, который видят посетители и ради которого все и задумывалось (фронтэнд). А второй можно назвать оборотной стороной — это так называемая , в которую мы можем попасть, добавив в адресной строке к URL нашего проекта /administrator (например, http://dfdf.ru/administrator).
Причем, вход в админку закрыт для обычных пользователей и осуществляется только путем ввода логина и пароля (авторизации).
Почему в этой ЦМС сделано именно так? Зачем нужно создавать фактически отдельный вебсайт (админку), который даже имеет собственный шаблон и, наверное, такое же, если не большее, количество файлов принадлежит ей в движке, чем у основного ресурса (Front Page)? А для нашего с вами удобства !
Ведь в противном случае, не имей Joomla админки, нам пришлось бы напрямую вводить все настройки в файлы нашего проекта, а тексты статей, ссылки, адреса рисунков и прочее, напрямую вставлять в базу данных, ну, например, с помощью PhpMyadmin.
Согласитесь, это было бы неудобно, да и багаж знаний для такой работы с базой данных напрямую нужен гораздо больший, чем работа с интерфейсом админки, очень сильно напоминающим интерфейс обычной программы. Работа с текстовым редактором (читайте про ) в админке Джумлы, так вообще похожа на работу в Ворде. В общем, все это для нас с вам и нашего удобства.
Видимая часть сайта сделанного на Джмумле (Front Page)
Рассмотрим предназначенную для посетителей, видимую часть этой CMS, которая называется Front Page. Из чего она состоит? Если рассматривать этот вопрос с точки зрения внешнего вида, то состоит она из центральной части, в которой располагается контент и окружающих его, так называемых, .
Если рассматривать этот же вопрос с точки зрения программной организации работы Joomla, то Front Page состоит из шаблона (читайте про ) и подгружаемых данных в разные позиции для модулей шаблона.
В область контента подгружаются соответствующие этой странице статьи или же, например, фотографии с помощью компонента фотогалереи (читайте про очень функциональную и бесплатную фотогалерею под названием ).
В позиции для модулей (они имеют место быть абсолютно во всех шаблонах выпускаемых для Джумлы) может подгружаться все, что угодно, в зависимости от того, для чего он создан (например, в некоторых выводятся те же самые или, допустим, заголовки последних сообщений).
Как формируются (генерируются) страницы в CMS Джумла
Обратите внимание, что данные в этом случае подгружаются из базы данных по мере необходимости, а это происходит, только если пользователь открывает какую-нибудь страничку. А как он ее открывает? Ну, либо переходит по ссылке с другого ресурса, либо перемещается по вашему проекту, используя его внутреннюю навигацию – меню или .
К чему я все это говорю? А к тому, что по логике работы Джумлы, к вебстранице нельзя обратиться пока не будет создан пункт меню, ссылающийся на эту страничку. Немного не понятно? Попробую пояснить.
Все дело в том, что браузеры работают только со страничками в формате и напрочь не понимают язык PHP на котором, собственно, и написана Joomla. Поэтому система управления контентом (ЦМС), после того как пользователь обратится к той или иной вебстранице вашего проекта, должна успеть сгенерировать эту страничку, опираясь на алгоритм, прописанный в ее коде на языке PHP.
Получается, что любая страница такого динамического ресурса существует, только если к ней обратились , а обратиться к ней мы можем, только перейдя по . Круг замкнулся. Получается, что нужно иметь ссылку на то чего нет, пока мы не обратимся к нему по этой ссылке.
Этот момент в работе CMS под названием Joomla особенно сложно понять тем, кто хоть немного представляет создание классического вебсайта, состоящего только из статичных страничек с расширением HTML. Все вебстраницы, в этом случае, реально существуют и находятся на сервере .
К ним всегда можно обратиться, введя соответствующий адрес в браузере или даже физически, через FTP, скачать какую-нибудь страничку с сервера себе на компьютер и открыть просто двойным щелчком по ней. Как говорится, ее можно пощупать.
В случае же с Джумлой, да, собственно, и любой другой CMS, базирующейся на PHP, странички в формате HTML генерятся непосредственно на сервере хостинга в момент обращения к ним. Каким образом они генерятся?
В соответствии с содержанием запрашиваемой вебстраницы, в центральную часть шаблона загружается из базы данных соответствующий контент (статьи, фотогалерея, интернет магазин и т.п.), а по бокам шаблона, сверху и снизу, в позиции для модулей загружаются данные в те из них, которые должны отображаться именно на этой вебстранице. Весь этот алгоритм работы ЦМС прописывается в файлах движка и настраивается как раз в админке.
Как вы уже, наверное, заметили, такой способ формирования страниц скрывает в себе некоторую проблему, которая особенно остро может встать при большом количестве посетителей на проекте. Код файлов этого движка, написанных на PHP, интерпретируется в HTML страничку прямо на сервере хостинга в реальном времени .
Если запросов на создание страниц будет очень много (высокая посещаемость или же какой-то бот начнет генерить кучу запросов), то это может нагнуть сервер хостинга, т.е. существенно замедлить его работу. Даже если предположить, что все посетители, находящиеся в данный момент на вашем ресурсе, запросили одну и ту же вебстраницу, она все равно будет создаваться движком заново столько раз, сколько посетителей нажали по соответствующей ей ссылке. О как!
Включаем кэширование для снятия нагрузки с сервера хостинга
Выход из этой ситуации состоит в использовании кэширования (этот способ снижения нагрузки имеет место быть практически во всех популярных сейчас ЦМС-ках). Как это работает? Довольно просто. Каждый раз, когда по требованию посетителя на сервере хостинга создается вебстраница в формате HTML, то она не только передается браузеру пользователя, нажавшего по ссылке, но и сохраняется CMS в папке с кэшем на сервере хостинга.
И уже при следующем обращении к этой вебстранице она не будет заново создаваться, отнимая ресурс сервера хостинга (создавая дополнительную нагрузку на его процессор), а будет передана браузеру пользователя, запросившему эту страничку, из той самой папки на сервере хостинга, где хранятся все закэшированные страницы.
А как же тогда быть с обновлением информации на ресурсе? Если все берется из кэша движка, то любые вносимые изменения, допустим, в статьи, не будут видны пользователям. Ведь они то получают статью из папки для кэша. Да, действительно, в случае применения кэширования в Joomla, внесенные изменения сразу видны не будут, но они обязательно появятся потом, чуть позже. А вот насколько позже — зависит от времени жизни кэша, которое вы сможете задать в админке.
Для включения и настройки кэширования в этой бесплатной системе управления контентом просто зайдите в админку и выполните следующие перемещения: «Общие настройки» — вкладка «Система» — область «Установки кэша». Поставьте галочку в позицию «Да» в строке «Включить кэширование» и выберите время жизни кэша. Не забудьте по окончании настройки нажать кнопку «Применить» или «Сохранить», в противном случае внесенные вами изменения не вступят в силу.
Более подробно про кэширование в Джумле вы можете почитать в этой статье — .
Чем отличаются действия кнопок «Применить» и «Сохранить»
Кстати, вы знаете в чем заключается различие между действиями, выполняемыми по нажатию кнопки «Применить» от действий, выполняемых по нажатию кнопки «Сохранить»? Совсем немногим.
В обоих случаях будут сохранены все внесенные изменения, но после нажатия на кнопку «Применить» вы останетесь в этом же окне и сможете продолжить редактирование, а после нажатия на кнопку «Сохранить» — окно редактирования в админке закроется и вы очутитесь на той страничке, которая была открыта до этого.
Т.е. кнопку «Применить» нужно нажимать, если вы еще планируете работать в этом окне, а кнопку «Сохранить» — если работу в этом окне вы уже закончили.
Частичное отключения кэширования
Хочу остановиться еще на одном моменте, связанном с кэшем в этой системе. Дело в том, что для некоторых элементов вашего проекта желательно вообще не применять кэширования. Например, это могут быть какие-нибудь информеры в модулях, данные на которых должны меняться при каждом обращении к страничке, где они установлены. В случае применения кэша это становится невозможно.
Именно для таких случаев в настройках всех модулей предусмотрена возможность отключить кэширование именно для этого модуля, при том, что все остальное на вашем вебсайте может продолжать прекрасно кэшироваться. Эту возможность отключить кэш в Джумле нужно искать в правой части окна настройки модуля. Например для того, в котором будет выводится на сайт меню, настройка кэширования находится здесь:
Итак, в начале поста я говорил, что нельзя создать ссылку на страницу в этой CMS, если нет соответствующего пункта меню, ссылающегося на эту страничку. А если пункт меню с такой ссылкой не нужен, но сама ссылка нужна и должна использоваться в тексте какой-нибудь статьи?
В таком случае нужно создать фиктивное меню, которое не будет публиковаться на Front Page и которое будет включать в себя пункт с нужной ссылкой на страницу. Тут я как раз и подошел к вопросу, который меня озадачил в начале изучения работы этой системы управления контентом.
Как создать новое меню в Джумле я понял, но оно, после добавления в него пунктов, не хотело отображаться на сайте.
— «Ты же не вставил его в модуль», — скажите вы и будете совершено правы.
Действительно, меню в этой ЦМС должно быть привязано к модулю, который и определит, где оно будет находиться на Front Page.
Как посмотреть позиции для модулей, предусмотренные в шаблоне Joomla
Дело в том, что в любом шаблоне для модулей отведены специальные позиции. Увидеть их вы сможете, просто добавив в конце URL вашего ресурса в адресной строке браузера?tp=1 (например, http://dfdf.ru/?tp=1).
В разных шаблонах количество и расположение позиций для модулей отличается. Поэтому, прежде чем в какую-либо позицию (например, left, right или top) шаблона Джумлы, убедитесь, где именно в нем находится эта позиция. Не исключен вариант, что позиция left будет находиться справа.
Более подробно о создании меню, его вставку в определенное место шаблона и многое другое, связанное с работой в этой системе управления контентом, я расскажу в следующих постах рубрики .
Удачи вам! До скорых встреч на страницах блога сайт
посмотреть еще ролики можно перейдя на");">
Вам может быть интересно
Модули в Joomla - просмотр позиции, настройка и вывод, а так же назначение суффиксов класса
Меню в Joomla - добавление вложенного или выпадающего меню, а так же создание и настройка модуля для его отображения на сайте
Админка Joomla - полный мануал по всем настройкам административной панели Джумлы в деталях и картинках
Встроенные в Joomla модули для работы с RSS лентами, для создания хлебных крошек, для входа и поиска по сайту
Установка Joomla 1.5 в деталях и картинках, решение возможных проблем
Плагины Joomla - TinyMCE, Load Module, Legacy и другие установленные по умолчанию
Перед вами - второй материал из серии, посвящённой особенностям работы JavaScript на примере движка V8. В первом шла речь о механизмах времени выполнения V8 и о стеке вызовов. Сегодня мы углубимся в особенности V8, благодаря которым исходный код на JS превращается в исполняемую программу, и поделимся советами по оптимизации кода.
О JS-движках
JavaScript-движок - это программа, или, другими словами, интерпретатор, выполняющий код, написанный на JavaScript. Движок может быть реализован с использованием различных подходов: в виде обычного интерпретатора, в виде динамического компилятора (или JIT-компилятора), который, перед выполнением программы, преобразует исходный код на JS в байт-код некоего формата.Вот список популярных реализаций JavaScript-движков.
- - движок с открытым исходным кодом, написан на C++, его разработкой занимается Google.
- Rhino - этот движок с открытым кодом поддерживает Mozilla Foundation, он полностью написан на Java.
- SpiderMonkey - это самый первый из появившихся JS-движков, который в прошлом применялся в браузере Netscape Navigator, а сегодня - в Firefox.
- JavaScriptCore - ещё один движок с открытым кодом, известный как Nitro и разрабатываемый Apple для браузера Safari.
- KJS - JS-движок KDE, который разработал Гарри Портен для браузера Konqueror, входящего в проект KDE.
- Chakra (JScript9) - движок для Internet Explorer.
- Chakra (JavaScript) - движок для Microsoft Edge.
- Nashorn - движок с открытым кодом, являющийся частью OpenJDK, которым занимается Oracle.
- JerryScript - легковесный движок для интернета вещей.
Почему был создан движок V8?
Движок с открытым кодом V8 был создан компанией Google, он написан на C++. Движок используется в браузере Google Chrome. Кроме того, что отличает V8 от других движков, он применяется в популярной серверной среде Node.js.
Логотип V8
При проектировании V8 разработчики задались целью улучшить производительность JavaScript в браузерах. Для того, чтобы добиться высокой скорости выполнения программ, V8 транслирует JS-код в более эффективный машинный код, не используя интерпретатор. Движок компилирует JavaScript-код в машинные инструкции в ходе исполнения программы, реализуя механизм динамической компиляции, как и многие современные JavaScript-движки, например, SpiderMonkey и Rhino (Mozilla). Основное различие заключается в том, что V8 не использует при исполнении JS-программ байт-код или любой промежуточный код.
О двух компиляторах, которые использовались в V8
Внутреннее устройство V8 изменилось с выходом версии 5.9, которая появилась совсем недавно. До этого же он использовал два компилятора:- full-codegen - простой и очень быстрый компилятор, который выдаёт сравнительно медленный машинный код.
- Crankshaft - более сложный оптимизирующий JIT-компилятор, который генерирует хорошо оптимизированный код.
- Главный поток, который занимается тем, что от него можно ожидать: читает исходный JS-код, компилирует его и выполняет.
- Поток компиляции, который занимается оптимизацией кода в то время, когда выполняется главный поток.
- Поток профилировщика, который сообщает системе о том, в каких методах программа тратит больше всего времени, как результат, Crankshaft может эти методы оптимизировать.
- Несколько потоков, которые поддерживают механизм сборки мусора.
После того, как код какое-то время поработает, поток профилировщика соберёт достаточно данных для того, чтобы система могла понять, какие методы нужно оптимизировать.
Далее, в другом потоке, начинается оптимизация с помощью Crankshaft. Он преобразует абстрактное синтаксическое дерево JavaScript в высокоуровневое представление, использующее модель единственного статического присваивания (static single-assignment, SSA). Это представление называется Hydrogen. Затем Crankshaft пытается оптимизировать граф потока управления Hydrogen. Большинство оптимизаций выполняется на этом уровне.
Встраивание кода
Первая оптимизация программы заключается в заблаговременном встраивании в места вызовов как можно большего объёма кода. Встраивание кода - это процесс замены команды вызова функции (строки, где вызывается функция) на её тело. Этот простой шаг позволяет сделать следующие оптимизации более результативными.
Вызов функции заменяется на её тело
Скрытые классы
JavaScript - это язык, основанный на прототипах: здесь нет классов. Объекты здесь создаются с использованием процесса клонирования. Кроме того, JS - это динамический язык программирования, это значит, что, после создания экземпляра объекта, к нему можно добавлять новые свойства и удалять из него существующие.Большинство JS-интерпретаторов используют структуры, напоминающие словари (основанные на использовании хэш-функций), для хранения сведений о месте расположения значений свойств объектов в памяти. Использование подобных структур делает извлечение значений свойств в JavaScript более сложной задачей, чем в нединамических языках, таких, как Java и C#. В Java, например, все свойства объекта определяются не изменяющейся после компиляции программы схемой объекта, их нельзя динамически добавлять или удалять (надо отметить, что в C# есть динамический тип, но тут мы можем не обращать на это внимание). Как результат, значения свойств (или указатели на эти свойства) могут быть сохранены, с фиксированным смещением, в виде непрерывного буфера в памяти. Шаг смещения можно легко определить, основываясь на типе свойства, в то время как в JavaScript это невозможно, так как тип свойства может меняться в процессе выполнения программы.
Так как использование словарей для выяснения адресов свойств объекта в памяти очень неэффективно, V8 использует вместо этого другой метод: скрытые классы. Скрытые классы похожи на обычные классы в типичном объектно-ориентированном языке программирования, вроде Java, за исключением того, что создаются они во время выполнения программы. Посмотрим, как всё это работает, на следующем примере:
Function Point(x, y) {
this.x = x;
this.y = y;
}
var p1 = new Point(1, 2);
Когда происходит вызов new Point(1, 2) , V8 создаёт скрытый класс C0 .
Первый скрытый класс С0
Пока, ещё до выполнения конструктора, у объекта Point нет свойств, поэтому класс C0 пуст.
Как только будет выполнена первая команда в функции Point , V8 создаст второй скрытый класс, C1 , который основан на C0 . C1 описывает место в памяти (относительно указателя объекта), где можно найти свойство x . В данном случае свойство x хранится по смещению 0, что означает, что если рассматривать объект Point в памяти как непрерывный буфер, первое смещение соответствует свойству x . Кроме того, V8 добавит в класс C0 сведения о переходе к классу C1 , где указывается, что если к объекту Point будет добавлено свойство x , скрытый класс нужно изменить с C0 на C1 . Скрытый класс для объекта Point , как показано на рисунке ниже, теперь стал классом С1 .
Каждый раз, когда к объекту добавляется новое свойство, в старый скрытый класс добавляются сведения о переходе к новому скрытому классу. Переходы между скрытыми классами важны, так как они позволяют объектам, которые создаются одинаково, иметь одни и те же скрытые классы. Если два объекта имеют общий скрытый класс и к ним добавляется одно и то же свойство, переходы обеспечат то, что оба объекта получат одинаковый новый скрытый класс и весь оптимизированный код, который идёт вместе с ним.
Этот процесс повторяется при выполнении команды this.y = y (опять же, делается это внутри функции Point , после вышеописанной команды по добавлению свойства x).
Тут создаётся новый скрытый класс, C2 , а в класс C1 добавляются сведения о переходе, где указывается, что если к объекту Point добавляется свойство y (при этом речь идёт об объекте, который уже содержит свойство x), тогда скрытый класс объекта должен измениться на C2 .
Переход к использованию класса C2 после добавления к объекту свойства y
Переходы между скрытыми классами зависят от порядка, в котором к объекту добавляются свойства. Взгляните на этот пример кода:
Function Point(x, y) {
this.x = x;
this.y = y;
}
var p1 = new Point(1, 2);
p1.a = 5;
p1.b = 6;
var p2 = new Point(3, 4);
p2.b = 7;
p2.a = 8;
В подобной ситуации можно предположить, что у объектов p1 и p2 будет один и тот же скрытый класс и одно и то же дерево переходов скрытых классов. Однако, на самом деле это не так. В объект p1 первым добавляется свойство a , а затем - свойство b . В объект p2 сначала добавляют свойство b , а затем - a . В результате объекты p1 и p2 будут иметь различные скрытые классы - результат различных путей переходов между скрытыми классами. В подобных случаях гораздо лучше инициализировать динамические свойства в одном и том же порядке для того, чтобы скрытые классы могли быть использованы повторно.
Встроенные кэши
V8 использует и другую технику для оптимизации выполнения динамически типизированных языков, называемую встроенным кэшем вызовов. Встроенное кэширование основано на наблюдении, которое заключается в том, что повторяющиеся обращения к одному и тому же методу имеют тенденцию происходить с использованием объектов одного типа. Более подробно об этом можно почитать . Если у вас нет времени слишком в это углубляться, читая вышеупомянутый материал, здесь мы изложим концепцию встроенного кэширования буквально в двух словах.Итак, как же всё это работает? V8 поддерживает кэш типов объектов, которые мы передали в качестве параметра недавно вызванным методам, и использует эту информацию для того, чтобы сделать предположение о типах объектов, которые будут переданы как параметры в будущем. Если V8 смог сделать правильное предположение о типе объекта, который будет передан методу, он может пропустить процесс выяснения того, как получать доступ к свойствам объекта, а, вместо этого, использовать сохранённую информацию из предыдущих обращений к скрытому классу объекта.
Как связаны концепции скрытых классов и встроенных кэшей вызовов? Когда метод вызывается для некоего объекта, движок V8 должен обратиться к скрытому классу этого объекта для того, чтобы определить смещение для доступа к конкретному свойству. После двух успешных обращений одного и того же метода к одному и тому же скрытому классу, V8 опускает операцию обращения к скрытому классу и просто добавляет сведения о смещении свойства к самому указателю объекта. Выполняя вызовов этого метода в будущем, V8 предполагает , что скрытый класс не менялся и идёт прямо по адресу памяти для конкретного свойства, используя смещение, сохранённое после предыдущих обращений к скрытому классу. Это очень сильно увеличивает скорость выполнения кода.
Встроенное кэширование вызовов, кроме того, является причиной того, почему так важно, чтобы объекты одного и того же типа использовали общие скрытые классы. Если вы создаёте два объекта одинакового типа, но с разными скрытыми классами (как сделано в примере выше), V8 не сможет использовать встроенное кэширование, так как, даже хотя объекты имеют один и тот же тип, в соответствующих им скрытых классах назначено разное смещение их свойствам.
Перед нами объекты одного типа, но их свойства a и b были созданы в разном порядке и имеют разное смещение
Компиляция в машинный код
Как только граф Hydrogen оптимизирован, Crankshaft переводит его в низкоуровневое представление, которое называется Lithium. Большинство реализаций Lithium зависимо от архитектуры системы. На этом уровне, например, происходит выделение регистров.В итоге Lithium-представление компилируется в машинный код. Затем происходит то, что называется замещением в стеке (on-stack replacement, OSR). Перед компиляцией и оптимизацией методов, в которых программа тратит много времени, нужно будет поработать с их неоптимизированными вариантами. Затем, не прерывая работу, V8 трансформирует контекст (стек, регистры) таким образом, чтобы можно было переключиться на оптимизированную версию кода. Это очень сложная задача, учитывая то, что помимо других оптимизаций, V8 изначально выполняет встраивание кода. V8 - не единственный движок, способный это сделать.
Как быть, если оптимизация оказалась неудачной? От этого есть защита - так называемая деоптимизация. Она направлена на обратную трансформацию, возвращающую систему к использованию неоптимизированного кода в том случае, если предположения, сделанные движком и положенные в основу оптимизации, больше не соответствуют действительности.
Сборка мусора
Для сборки мусора V8 использует традиционный генеалогический подход «пометь и выброси» (mark-and-sweep) для маркировки и очистки предыдущих поколений кода. Фаза маркировки предполагает остановку выполнения JavaScript. Для того, чтобы контролировать нагрузку на систему, создаваемую сборщиком мусора и сделать выполнение кода более стабильным, V8 использует инкрементный алгоритм маркирования: вместо того, чтобы обходить всю кучу, он пытается пометить всё, что сможет, обходя лишь часть кучи. Затем нормальное выполнение кода возобновляется. Следующий проход сборщика мусора по куче начинается там, где закончился предыдущий. Это позволяет добиться очень коротких пауз в ходе обычного выполнения кода. Как уже было сказано, фазой очистки памяти занимаются отдельные потоки.Ignition и TurboFan
С выходом в этом году V8 версии 5.9. был представлен и новый конвейер выполнения кода. Этот конвейер позволяет достичь ещё большего улучшения производительности и значительной экономии памяти, причём, не в тестах, а в реальных JavaScript-приложениях.Новая система построена на базе интерпретатора Ingnition и новейшего оптимизирующего компилятора TurboFan . Подробности об этих новых механизмах V8 можно почитать в этом материале.
С выходом V8 5.9 full-codegen и Crankshaft (технологии, которые использовались в V8 с 2010-го года) больше применяться не будут. Команда V8 развивает новые средства, стараясь не отстать от новых возможностей JavaScript и внедрить оптимизации, необходимые для поддержки этих возможностей. Переход на новые технологии и отказ от поддержки старых механизмов означает развитие V8 в сторону более простой и хорошо управляемой архитектуры.
Улучшения в тестах производительности для браузерного и серверного вариантов использования JS
Эти улучшения - лишь начало. Новый конвейер выполнения кода на основе Ignition и TurboFan открывает путь к дальнейшим оптимизациям, которые улучшат производительность JavaScript и сделают V8 экономичнее.
Мы рассмотрели некоторые особенности V8, а теперь приведём несколько советов по оптимизации кода. На самом деле, кстати, всё это вполне можно вывести из того, о чём мы говорили выше.
Подходы к оптимизации JavaScript-кода для V8
- Порядок свойств объектов . Всегда инициализируйте свойства объектов в одном и том же порядке. Нужно это для того, чтобы одинаковые объекты использовали одни и те же скрытые классы, и, как следствие, оптимизированный код.
- Динамические свойства . Добавление свойств к объектам после создания экземпляра объекта приведёт к изменению скрытого класса и к замедлению методов, которые были оптимизированы для скрытого класса, используемого объектами ранее. Вместо добавления свойств динамически, назначайте их в конструкторе объекта.
- Методы . Код, который несколько раз вызывает один и тот же метод, будет выполняться быстрее, чем код, который вызывает несколько разных методов по одному разу (из-за встроенных кэшей).
- Массивы . Избегайте разреженных массивов, ключи которых не являются последовательными числами. Разреженный массив, то есть массив, некоторые из элементов которого отсутствуют, будет обрабатываться системой как хэш-таблица. Для доступа к элементам такого массива требуется больше вычислительных ресурсов. Кроме того, постарайтесь избежать заблаговременного выделения памяти под большие массивы. Лучше, если их размер будет увеличиваться по мере надобности. И, наконец, не удаляйте элементы в массивах. Из-за этого они превращаются в разреженные массивы.
- Числа . V8 представляет числа и указатели на объекты, используя 32 бита. Он задействует один бит для того, чтобы определить, является ли некое 32-битное значение указателем на объект (флаг - 1), или целым числом (флаг - 0), которое называется маленьким целым числом (SMall Integer, SMI) из-за того, что его длина составляет 31 бит. Если для хранения числового значения требуется более 31 бита, V8 упакует число, превратив его в число двойной точности и создаст новый объект для того, чтобы поместить в него это число. Постарайтесь использовать 31-битные числа со знаком везде, где это возможно, для того, чтобы избежать ресурсоёмких операций упаковки чисел в JS-объекты.
Итоги
Мы, в SessionStack, стараемся следовать вышеизложенным принципам при написании JS-кода. Надеемся, немного разобравшись в том, как работают внутренние механизмы V8, и учтя то, что мы рассказали выше, вы сможете улучшить качество и производительность ваших программ.Все мы слышали про движки для создания игр, при этом мало кто понимает, что это такое.
Даже сами студии, занимающиеся разработкой видеоигр, дают весьма расплывчатое определение термина, точнее, толком не могут отделить саму игру от движка, на котором она строится.
Попробуем разобраться с вопросом, подходя к ситуации в роли , и рассмотрим самые популярные игровые движки : их особенности, сферы применения, слабые и сильные стороны.
Понятие
Игровой движок или game engine – это изначальное программное обеспечение, разработанное для создания на его основе компьютерных игр, зачастую определённого жанра.
Термин образовался в средине 90-х по отношению к шутерам вроде Quake, Wolfenstein и Doom .
Еще до возникновения такого понятия игровой мир заметил, что удивительно хорошо сочетали в себе:
- трехмерную графику;
- расчёт столкновений с объектами;
- объемный игровой мир;
- звуковую составляющую;
- инвентарь (система вооружения) и другие правила.
Обратив внимание на это, разработчики начали выпускать собственные игры на основе того же Doom , с минимальными изменениями: перерисовка карт и прочих графических моделей, редактирование физического движка.
Преимущественное большинство движков создаются под определённый игровой жанр и часто для указанной платформы.
Использование game engine для нескольких платформ или жанров делает его менее унифицированным и оптимальным, он не раскроет свой потенциал.
Разновидности
Движки для разработки игр специализируются на жанрах.
Например, базовое программное обеспечение и экшена будет изрядно отличаться даже в основных составляющих. Несмотря на это, все они имеют ряд общих или схожих частей (строк кода).
В любой игре есть взаимодействие объектов , управление кем-либо или чем-либо при помощи геймпада, мыши и клавиатуры, вывод картинки и звука, наложение текста, рендеринг трехмерных объектов (в 3D-играх).
С учётом этого некоторые движки успешно используются для разработки развлечений разных жанров. изначально был платформой для создания шутеров от первого лица, но Gear of War (вид от третьего лица) и Speed Star (гонка) на его основе получились полноценными видеоиграми.
Шутер
Благодаря им появилось понятие движка, с них и начнём.
В какой-то мере платформы для создания стрелялок являются наиболее технологичными, проработанными и сложными. Кроме высококачественного , к игрушке выдвигаются следующие требования:
- функция моделирования виртуального трехмерного мира с учётом динамики развития событий;
- наличие контроля прицеливания;
- высокая отзывчивость игровой механики;
- значительная четкость прорисовки и детализация рук персонажа и оружия;
- хорошая анимация выстрелов и взрывов на основе взаимодействия частиц;
- реалистичное поведение окружающей среды в ответ на выстрелы и взрывы, в том числе разрушаемость объектов, из-за чего к таким движкам предъявляются высокие требования в области кинематики;
- большой выбор вооружения с разными характеристиками;
- проработанная модель движений и взаимодействия персонажей;
- качество искусственного интеллекта при наличии одиночной игры;
- многообразие игровых режимов и массовость в корпоративном режиме.
Платформер
Обычно это двухмерные развлечения, к ним требования более снисходительны:
- немало внимания уделяется внешнему виду, кастомизации, поведению и анимации главного героя;
- разнообразие так называемых перемещающихся платформ (падающие, движущиеся по разным траекториям, исчезающие, вращающиеся);
- дополнительные платформы в виде ступенек, верёвок, лестниц, труб и система взаимодействия с ними;
- наличие элементов головоломок;
- многослойная геометрия;
- простая физика взаимодействия объектов;
- взаимодействие с иными игровыми персонажами (диалоги, бои).
Файтинг
Для них характерны большое разнообразие персонажей с уникальными способностями и техниками, отдельная анимация каждого из них, мимика и жесты, выполнение заданий на протяжении раундов, сложная система ударов, их комбинаций, защитных движение, комбо и спец-приемов.
Нередки в файтингах и сетевое взаимодействие, кастомизация персонажа, появление последствий драки (царапины, ссадины), добивающие приёмы.
Гонки
Для гонок создан не один игровой движок с учётом специфики игр.
Ввиду реализации мультипоточности, PhysX отличается наличием выделенного потока без каких-либо проверок. Это позволяет выполняться ряду задач одновременно в параллельных потоках.
Тесселяция позволяет добиться , что положительно отражается на цветовой коррекции, наложении шума и зернистости на изображение в реальном времени.
Объемный туман, размытие в движении, параллакс для любой поверхности, значительная точность и высокая детализация – не все преимущества движка.
Звуковая составляющая поддерживает трехмерное позиционирование, отчего появляется ощущение трехмерного пространства и возможность вычислить источник звука.
Прочий функционал:
- визуализация сцен с широким цветовым пространством;
- использование десятков источников света в кадре;
- полностью динамическое освещение;
- размытие в движении без влияния на производительность;
- отличное распараллеливание процесса визуализации;
- расчёт распространения звука, его поглощение и отражение от преград;
- множество условий боя;
- удобная и понятная система скриптования;
- система анализа топологии ИИ;
- персонажи наделены зрением, слухом и прочими чувствами, что делает их серьёзными противниками;
- групповое поведение.
- сложность процесса портирования игр на консоли;
- не оригинальная разработка, а усовершенствованный X-Ray (факт не доказан, но намёки на это есть);
- поддержка DirextX12 не реализована.
- улучшена графическая часть;
- разрушаемость моделей и прочие преимущества PhysX;
- нет спецэффектов ради спецэффектов (добавляются только необходимые).
Игры: серия Metro, в том числе разрабатывается Metro Exodus, и Arktika.1.
Яркий пример реализации личных амбиций и один из немногих всемирно известных движков, созданных на просторах СНГ.
Anvil
Создан дочерней компанией Ubisoft, используется для выпуска и только внутри компании.
Первой игрой была первая часть Креда Убийцы, затем появился симулятор сноуборда и Prince of Persia.
Любая из них вызвала массу удивления и привнесла в мир виртуальных развлечений немало нового.
Поддерживается на PC, PS всех версий, Nintendo, Wii и Xbox.
Код написан на C++, модели нарисованы в ZBrush, а окружающий мир – в 3ds Max. Для правильной скелетной анимации задействовано . Физику виртуального мира моделирует легендарный Havok. В последних релизах было уделено немало внимания смене времени суток, динамическому освещению и дистанционной прорисовке. Также в него была интегрирована прогрессивная схема растительности (как в Far Cry 2) с новым ИИ, важным отличием коего является усовершенствованная система навигации NPC. Реализация и отладка Direct3D 10/11 хоть и весьма затратные, работа все же была проделана.
Среди неназванных особенностей движка выделим следующие:
- оптимизация работы на многоядерных системах, вплоть до 32 потоков;
- запуск игр на нескольких экранах в панорамном режиме;
- сложный шумовой туман, способный симулировать песчаную бурю без падения fps;
- эффекты преломления, отражения и рассеивания света в воде;
- до шести отличающихся персонажей в одной кат-сцене;
- большинство анимаций снято с реальных актеров;
- в одной сцене может находиться до 3 тысяч участников, что позволяет устраивать массовые баталии, лишь бы ПК справился с нагрузкой;
- NPC активно реагируют на героя, могут нападать одновременно, а не поочерёдно;
- технология отсечения моделей и сортировка объектов по глубине прорисовки.
- требователен к ресурсам;
- не лицензируется;
- долго не поддерживал DirectX 10 и 11.
- хорошая реализация многопоточности;
- работает на PC и множестве консолей;
- возможность реализации массовок при участии сотен игровых персонажей.
С Ubisoft, в плане устроить массовую заваруху и нагнать побольше людей в одно место, не сравнится никто.
Creation Engine
Довольно новый движок от американской студии Bethesda, которая продемонстрировала его возможности в Skyrim. Как и предыдущие решения, создан только для нужд его разработчика. За основу был взят Gamebryo – подспорье для Oblivion и его аддонов.
Первое, что интересно в технологии – поддержка огромных локаций с дальней прорисовкой, свободным и быстрым перемещением.
Большое внимание уделено работе с водой и снегом, а система автоматической генерации осадков, камней, деревьев и травяного покрова самостоятельно определяет пропорции создаваемых объектов в зависимости от местности.
Улучшенный ИИ, использованный в Oblivion, более правдоподобно симулирует жизнь людей и их отношение к главному герою.
Концепция управления развитием сюжета способна генерировать дополнительные задания с учётом стиля игры.
Система построения деревьев изрядно переработана в новой версии движка, что позволило разнообразить растительный мир, и разгрузить для её просчёта.
Для анимации персонажей использован посторонний инструмент от Havok.
Особенности:
- наличие редактора уровней Creation Kit для геймеров и разработчиков модов;
- в Fallout появился основанный на физике рендеринг;
- масса инструментов для модостроителей;
- простота переноса модификаций на консоли.
- не лицензируется;
- тяжело создавать двуручное оружие;
- система поведения персонажей достаточно слаба.
- есть редактор модов, которые будут работать на любой платформе;
- большая дистанция прорисовки;
- уникальная схема генерации деревьев и их анимации.
Ничего лучшего для моддеров пока не придумано, поэтому больше, чем для Fallout, их создано только для Oblivion.
CryEngine 4
Последняя версия движка от немецкой компании Crytek для шутеров от первого лица.
Самый удачный пример использования – .
С 2016 года движок стал распространяться по схеме «заплати, сколько не жалко», но только для игрового использования.
Особенности и возможности:
- наличие огромных территорий, причем не коридорных;
- локации создаются без швов;
- поддержка инверсной кинематики персонажей и транспорта, его взаимодействия с окружающей средой;
- имитация различных нетвёрдых объектов: ткань, вода;
- огромный арсенал с уникальными характеристиками каждого вида оружия;
- скриптовый и командный интеллект;
- можно изменять параметры ИИ, не имея знаний в области программирования;
- интерактивное музыкальное сопровождение – музыка соответствует ситуации;
- полная поддержка звуковой системы 5.1;
- воспроизведение звуков природы с учётом среды, отражения и поглощения звука;
- реалистичный эффект жары и пожара;
- прозрачность стекол – можно видеть, что находится в зданиях;
- эксплуатация карт высот для получения многоуровневой среды с видимым расстоянием до 2000 м;
- невероятные возможности работы с освещением и тенями, что отлично демонстрирует Crysis;
- объемный густой туман и дым для придания атмосферы;
- наличие необычных физических эффектов (например, нанокостюма).
От автора: приветствую вас, друзья. Данная статья рассчитана на новичков, на тех, кто совсем недавно установил CMS DLE и хочет узнать, как работать с DLE. Итак, давайте вкратце узнаем, что же это за движок такой и как с ним работать. Приступим?
Итак, вы только что установили DLE или собираетесь его установить. Если вы все еще сомневаетесь в том, стоит ли использовать эту CMS или возможно стоит познакомиться с другим движком, тогда стоит для самого себя ответить на один простой вопрос: — для каких целей вам нужен сайт?
Если вы хотите создать блог или новостной сайт, то есть сайт, на котором регулярно будете публиковать различные статьи, тогда DLE будет идеальным выбором. Собственно, это же сказано и на официальном сайте движка:
Хорошо, для блога или новостного сайта (если именно такова тематика вашего ресурса) DLE подойдет. А что насчет преимуществ самого движка? Об этом также можно прочесть на той же главной странице офсайта:
К безусловным преимуществам движка можно отнести его производительность. DLE — это действительно одна из самых быстрых CMS и если скорость работы сайта для вас важна, тогда DLE будет неплохим выбором.
Ну что же, с вопросом — что такое DLE — мы более-менее разобрались. А теперь давайте перейдем к вопросу как работать с DLE. И здесь нет ничего сложного. DLE отличается продуманным и логичным интерфейсом админпанели, с которой разберется даже новичок за считанные минуты. Например, наиболее частой операцией, как вы понимаете, будет публикация статей и новостей. Инструменты для этого всегда под рукой на самом видном месте админпанели — это две кнопки в правом верхнем углу админпанели.
Кстати, а как попасть в админпанель? Находится она по адресу http://your-site/admin.php. Перейдя по нужному адресу, мы увидим форму авторизации для доступа к святая святых нашего сайта — его админки.
Ну а о подробнее о работе с админкой DLE вы можете прочесть в статье . В этой статье мы пройдемся по наиболее часто используемым пунктам админки и познакомимся с админпанелью детальнее. На этом я с вами прощаюсь. Удачи!
