Flex Æô¶¯»ù±¾Á÷³Ì

First, enough bytes for frame 1 are streamed down to the Flash
Player.
The Flash Player executes those bytes by creating a SystemManager
instance.
SystemManager instruct the Flash Player to stop at the end of frame
1.
SystemManager then goes on to create the Preloader which creates the
DownloadProgressBar control and pops that up on the client screen.
The Preloader then starts tracking the rest of the bytes streaming
in from the Flex SWF (or from external SWFs).
Once all the bytes for
the Flex framework and application code are in, the System Manager goes
on to frame 2 and instantiates the Application instance.
All RSLs and their associated classes are now loaded [into the
ApplicationDomain]; note that the load order is in the order defined
during app compile time.[3]

All class definitions used by the application (views, logic, etc)
must be loaded prior to Frame 2. It is here, in Frame1, that your
preloader code can even install patches to the Flex framework BEFORE the
framework classes themselves are loaded.
This technique is called "monkey-patching
"
and will be used later
when we are discussing the decryption
process.
Once the Application instance has been created, the SystemManager
sets Application.systemManager to itself. This is how you, the
application developer, can access the SystemManager at a later time.
The Application dispatches the preinitialize event at the beginning
of the initialization process.
Application goes on to create its children. The method
createChildren() is called on the application. At this point each of the
application’s components is being constructed, and each component’s
createChildren() will be also called. For detail, look at component
lifecycle section.
The Application dispatches the initialize event, which indicates
that all application’s components have been initialized. However, at
this state, all the components are not yet