Google Closure Compiler в деталях
Этот раздел посвящен Google Closure Compiler.
Чтобы его написать, мне пришлось буквально разобрать компилятор по косточкам, благо все сырцы в наличии есть. И, как оказалось, оно того стоило.
Инструмент мощный, сложный (поначалу), парой слов тут не отделаешься. Надеюсь, что после прочтения данного раздела он станет для вас простым.
- Введение
Google Closure Compiler - уникальный инструмент, разработанный Google для сжатия и обфускации собственного javascript.
У него есть ряд интересных особенностей, которые отличают его от прочих упаковщиков. читать дальше »
- Оптимизации стандартного режима
Оптимизации Google Closure Compiler делятся на два типа.
Первый тип - стандартные. Они задуманы как безопасные. Эти оптимизации делают внутренние преобразования функций и кода, которые не должны влиять на результат выполнения.
Их знание помогает писать код так, чтобы компилятор оптимизировал его как можно более эффективно. читать дальше »
- Продвинутые оптимизации
Продвинутые оптимизации google closure compiler включаются опцией --compilation_level ADVANCED_OPTIMIZATIONS.
Слово "продвинутые" (advanced) здесь, пожалуй, не совсем подходит. Кардинальное отличие этих оптимизаций от обычных (simple) - в том, что они небезопасны.
Чтобы ими пользоваться - надо уметь это делать. читать дальше »
- Объявление и проверка типов в примерах
Google Closure Compiler, как и любой кошерный компилятор, старается проверить правильность кода и предупредить о возможных ошибках.
Первым делом он, разумеется, проверяет структуру кода и сразу же выдает такие ошибки как пропущенная скобка или лишняя запятая.
Но, кроме этого, он умеет проверять типы переменных, используя как свои собственные знания о встроенных javascript-функциях и преобразованиях типов,
так и информацию о типах из JSDoc, указываемую javascript-разработчиком.
Это обеспечивает то, чем так гордятся компилируемые языки - статическую проверку типов, что позволяет избежать лишних ошибок во время выполнения. читать дальше »
- Оптимальное ООП с Google Closure Compiler
В javascript есть несколько основных стилей объявления объектов и свойств.
Они основаны на разной структуре кода, и поэтому - по-разному сжимаются компилятором.
Цель этой статьи - выбрать наилучший стиль ООП с точки зрения минификации кода и понять, почему ООП в таком стиле сжимается лучше всего. читать дальше »
- Сборка модулей
Google Closure Compiler умеет собирать javascript не в виде одного большого файла, а в виде нескольких модулей.
Так что все страницы могут грузить только один модуль, а дополнительная функциональность - загружаться лишь там, где она нужна.
Для такой сборки используется флаг компилятора --module. читать дальше »
- Кодировка: русский текст
При использовании Google Closure Compiler, как впрочем и других аналогичных упаковщиков, основанных на Rhino, возникают некоторые проблемы с русским текстом.
Эта статья содержит рецепты, как их легко преодолеть. читать дальше »
- Использование внутренних опций и собственные флаги
В этой статье мы разберем, как устроен общий цикл работы Google Closure Compiler, научимся добавлять новые флаги и устанавливать при их помощи внутренние, недокументированные опции компилятора. читать дальше »
- Директива @define, удаление веток компилятором
Директива @define позволяет переопределить глобальную переменную (как правило, константу) в процессе компиляции. Компилятор заменит значение javascript-переменной на новое непосредственно в коде javascript.
А так как это константа, то сжатие продвинутым режимом позволяет тут же заинлайнить ее и оптимизировать соответствующие ветки if. читать дальше »
- Исходный код сжатого фрагмента: closure inspector
В этой статье мы рассмотрим, как просмотреть исходный код сжатого фрагмента при помощи Closure Inspector для Firebug, и как адаптировать это расширение под себя. читать дальше »
- Вывод синтаксического дерева кода
Синтаксическое дерево - внутренняя структура, которую интерпретатор javascript создает из исходного кода.
Обычно синтаксическое дерево создается для выполнения, но также может использоваться и для оптимизации, чем, собственно, и занимается google closure compiler. читать дальше »
- Автоудаление отладочных свойств и объектов
Как правило, в нашем коде есть отладочные вызовы.
Например:
console.info("created "+object)
Или даже такие:
my.ajax.debugSend(message)
Google Closure Compiler позволяет удалять такие вызовы из production-кода. Здесь вопрос даже не столько в размере кода и в быстродействии, как в удобстве. Как правило, никому не нужны вызовы console.debug на боевом сервере.
читать дальше » - Создание собственных аннотаций
Java-фреймворк, на котором построен Google Closure Compiler, может быть расширен. Например, можно добавить новые аннотации, которые делают что-то с кодом. читать дальше »
- Эвристическое переименование свойств
Где-то посередине между продвинутым и обычным сжатием находится эвристическое переименование.
При его использовании Google Closure Compiler переименует все свойства объекта и прототипа, кроме тех, которые начинаются с _подчеркивания.
Эти свойства оптимизатор считает публичными (да-да, не приватными а публичными) и не переименует вообще. читать дальше »
|
1. можно ли как-то заставить гугл компилятор(или только переписав изрядно JAVA сорцы) при компиляции запретить некоторые функции javascript на свое усмотрение (или даже методы объектов), например запретить использование eval или document.getElementByID
2. можно ли задать ему шаблон, который нужно использовать в момент минификации. Например, попросить префиксировать все функции/объекты словом "development_"
чтобы поддерживались альтернитивные синтаксисы функций function myFunction -> function development_myFunction и myFunction: function() -> development_myFunction: function()
спасибо
1. Да, можно, причем никаких патчей для этого не нужно. Свой проход компилятора.
Причем, этот проход можно добавить в качестве опции (там есть такая, свои проходы) в MyCompilerRunner, т.к. он независим.
2. Шаблон - нет, операции идут над деревом кода. А вот создать аналогичные функции с development_ - конечно, можно. Похожие действия выполняются в проходе, обрабатывающем exportSymbol.
Никак не могу найти, как отключить перенос строк или указать побольше (в YUICompressor-е для этого есть флаг --line-break). Подскажите, если кто знает.
Написан же флаг, во введении --formatting PRETTY_PRINT
При этом флаге он вообще все переносит, а нужно наоборот, что бы все в одну линию было.
В одну линию - по умолчанию ведь ?
По умолчанию бьётся на строки где-то по 550 символов длиной
Илья, низкий Вам поклон за проделанную работу. Всё очень доступно и интересно написано. Прочел все статьи.
Однако поблагодарить вас за этот труд я считаю нужным!
Искренне благодарен. Спасибо.
в личный список избранных руководств! низкий поклон за проделаную работу
Проделанная работа вызывает изумление и восторг!
Илья, огромное вам человеческое спасибо!
интересная статья ! +
Здравствуйте. Вопрос такой: можно ли как то декомпилировать этот код? То есть хотя бы короткие пременные вернуть в прежний вид, или хотя бы как то теоритически объясните как возможно привести закомпиленный код в читабельный вид.
На следующем примере, за счет инлайнинга констант closure compiler увеличивает размер исходника почти в три раза (вообще, на сколько угодно, зависит от длины строк bigString1 и bigString2):
var bigString1 = "....."; var bigString2 = "....."; return { all: bigString1 + " " + bigString2, bs1: bigString1, bs2: bigString2, bs1LC: bigString1.toLowerCase(), bs2LC: bigString2.toLowerCase(), }Он умеет сжимать CSS? И что вообще есть для сжатия CSS? Что лучше сжимает?
Даже с ADVANCED_OPTIMIZATIONS сэкономил всего 7%. Т.е. смысла использовать нету.
Если изначально код нормально написан то там нечего сжимать.
Правда packer сжал почти на 50%. Но там закодирование стоит, без него только на 65%, но все равно на много лучше гугла.
Странно очень.
Без всяких флагов сжал из 352905 байт в 123744. А нормально написанный код как раз имеет не малый размер за счет комментариев кода.