MXML компилатор

Още едно копие на пристанището

Главно меню

Навигация на публикации

MXML компилатор. Част 3. Разбиране как работи компилаторът Flex

Както обикновено, всички, които не са уморени, след като са прочели до този ред - моля, подрежете! Първо, считам за уместно да дам връзки към други статии от поредицата:

Второ, трябваше да потърся доста добре в Google, за да намеря актуална (във връзка с прехвърлянето на Flex към Apaches) връзка към кода на клона 4.6 и за да ви спестя време, просто ще я оставя тук: opensource.adobe.com/svn//opensource/flex/sdk/branches/4.y/

Езикови компилатори

Като цяло компилаторът Flex поддържа различни езици за програмиране. Те се компилират от набор от езикови компилатори. Ако погледнете списъка с класове в проекта с име Compiler, можете да видите някои от тях:

mxml
Въпреки това, не може да се каже, че всички езици могат да бъдат компилирани в една стъпка. Например MXML компилатор може да използва зависимости, написани в AS3. Следователно, преди да компилира MXML компонент в байт код, компилаторът трябва да определи кои AS3 класове са му необходими и да провери дали AS3 кодът, извикан от MXML, е правилен.

Също така е разумно да се предположи, че различните компилатори изискват различен брой стъпки. Например компилаторът MXML изисква два пъти повече стъпки от AS3.

flex2.compiler.SubCompiler

Във Flex всички езикови компилатори имплементират един и същ интерфейс -flex2.compiler.SubCompiler:

От методите, които не са свързани с процеса на компилиране, можем да различим:String getName()- както можете да разберете от името, методът връща името на компилатора;isSupportedиgetSupportedMimeTypes- използвани за определяне на типа файлове, коитотози компилатор може да инвертира; сравнителни методи, свързани с измерване на производителността на компилация.

Стъпки на компилация

Както може би сте забелязали, процесът на компилиране се състои от 9 етапа. Основният Flex компилатор действа като координатор и е отговорен за извикване на екземпляри на компилатор, които очакват нещо подобно:

  1. предварителна обработка (веднъж)
  2. parse1 (веднъж)
  3. parse2 (веднъж)
  4. анализирай1 (веднъж)
  5. анализирай2 (веднъж)
  6. анализирай3 (веднъж)
  7. анализирай4 (веднъж)
  8. генерирам (веднъж)
  9. последваща обработка (многократно, докато екземплярът трябва да бъде спрян)

В допълнение към извикването на тези методи, основният компилатор на Flex прави редица неща:

  • Съвпада с подходящия екземпляр на компилатор въз основа на типа на изходния файл;
  • Получава списък с неразрешени типове от екземпляри и ги търси сред източниците и библиотеките на проекти;
  • Предава информация за типа на инстанции;
  • Решава кой компилатор да се изпълни въз основа на състоянието на екземплярите и общото състояние на ресурсите.

За да контролира всичко и всички, главният компилатор принуждава инстанциите да си сътрудничат. По принцип това изисква да следвате определен набор от правила:

  • Синтаксисното дървотрябвада е достъпно до края на стъпкатаparse2;
  • analyze1трябва да има информация за име на суперклас;
  • analyze2трябва да е наясно с всички зависимости;
  • analyze4трябва да предостави пълна информация за типа.

Процесът на компилиране продължава, докато:

  • Няма да останат зависимости за разрешаване;
  • Екземпляри на компилаторще даде грешка.

Алгоритми за повикване

Както бе споменато по-рано, процесът на компилиране се състои от извикване на тези 9 метода. Но въпреки че редът, в който се извикват тези методи, е доста точен, главният компилатор може да ги извика по различен начин. Всъщност има 2 алгоритъма: Единият (flex2.compiler.API.batch1()) е структуриран, а другият (flex2.compiler.API.batch2()) е условно патогенен. Нека ги разгледаме отделно:

API.batch1()е консервативен и по-структуриран алгоритъм. Същността му се състои в това, че гарантира началото на една фаза за всеки файл, преди да премине към друга фаза. Напримерanalyze1()ще бъде извикан за всички файлове, преди да премине къмanalyze2().

API.batch2()е условно патогенен алгоритъм, основната му цел е да минимизира консумацията на памет. За разлика отAPI.batch1(), изходните файлове с по-малко зависимости могат да достигнат етапа нагенериранемного по-рано, отколкото файловете с повече зависимости достигат фазата на analys3(). Идеята е, че ресурсите, разпределени за файл, могат да бъдат освободени веднага щом файлът бъде компилиран в байт код.

Заключение

Е, сега знаете много повече за вътрешната работа на компилатора Flex! Нека обобщим:

  • Основният компилатор на Flex използва само един от двата алгоритъма за компилиране: batch1 или batch2;
  • Алгоритмите за компилиране използват 2 различни стратегии за извикване на 9 стъпки за изграждане на приложение;
  • По време на компилация екземплярите на компилатора трябва да си сътрудничат и да предоставят информация за типа на главния компилатор в края на всяка стъпка;
  • Основният компилатор върши цялата тежка работа (търсене на източникфайлове/библиотеки, управление на регистриране на грешки и т.н.), което означава, че езиковите компилатори не трябва да се тревожат за това.

Горното е приложимо за всички версии на помощните програми (mxmlc, compc, asdoc), включени във Flex Framework.