AS3.0学习

1. 函数的参数传递是值传递还是地址传递：

In ActionScript 3.0, all arguments are passed by reference, because all values are stored as objects. However, objects that belong to the primitive data types, which includes Boolean, Number, int, uint, and String, have special operators that make them behave as if they were passed by value.（From “Adobe Flex Builder3 Helper"）

 

2. 核心可见类结构图（From “Adobe Flex Builder3 Helper"）

 

3. flash.display.DisplayObject中的坐标系统：

DisplayObject类中，有如下属性与坐标系统相关：x, y, width, height, scaleX, scaleY, transform.matrix。

其中，x、y与transform.matrix中的对应值保持一致，scaleX、scaleY和transform.matrix中的对应值保持一致，width、height根据“实际内容的尺寸”及缩放比例计算出来，如果“实际内容”不变，“实际内容的尺寸”也不会变，所以设置width和height时，scaleX、scaleY及transform.matrix中的相应值都会随之改变。

“实际内容的尺寸”就是DisplayObject中的实际内容的尺寸，比如用Graphics画出来的东西、子对象等。

修改上述任一坐标属性，其他与之有联系的属性都会进行相应更改。

 

4.AS3中的broadcast event和一般的event有什么区别（From “Adobe Flex Builder3 Helper"）：

简单的说就是broadcast event的target可以是统一类型对象的任何实例，也就是想要监听某一broadcast event，可以在会发出该event的类的任何实例上调用addEventListener添加监听函数。原文如下：

The DisplayObject class contains several broadcast events. Normally, the target of any particular event is a specific DisplayObject instance. For example, the target of an added event is the specific DisplayObject instance that was added to the display list. Having a single target restricts the placement of event listeners to that target and in some cases the target's ancestors on the display list. With broadcast events, however, the target is not a specific DisplayObject instance, but rather all DisplayObject instances, including those that are not on the display list. This means that you can add a listener to any DisplayObject instance to listen for broadcast events. In addition to the broadcast events listed in the DisplayObject class's Events table, the DisplayObject class also inherits two broadcast events from the EventDispatcher class: activate and deactivate.

 

5. LayoutManager——Flex的布局引擎（From “Adobe Flex Builder3 Helper"）：

默认情况下，LayoutManager是Flex程序的布局引擎，单实例，可以通过UIComponent实例的layoutManager属性或LayoutManager.getInstance()取到。

Flex对元素的布局过程分为三个阶段：commit、measurement和layout。commit阶段用于提交属性，measurement阶段用于计算尺寸，layout阶段用于布局排版。每一个阶段必须处理完所有的显示列表中的元素后才会进入下一个阶段。

三个阶段分别开始与UIComponent的validateProperties（），validateSize（）和validateDisplayList（）方法；每个方法中会分别调用UIComponent的commitProperties（），measure（）和updateDisplayList（）方法；UIComponent的invalidateProperties（），invalidateSize（）和invalidateDisplayList（）方法可以分别标记当前实例参与下次对应的布局阶段；三个阶段中遍历显示元素的顺序分别是自外向里（从最外层的元素到最里层的元素）、自里向外和自外向里。原文如下：

The LayoutManager is the engine behind Flex's measurement and layout strategy. Layout is performed in three phases; commit, measurement, and layout.
Each phase is distinct from the others and all UIComponents of one phase are processed prior to moving on to the next phase. During the processing of UIComponents in a phase, requests for UIComponents to get re-processed by some phase may occur. These requests are queued and are only processed during the next run of the phase.

The commit phase begins with a call to validateProperties(), which walks through a list (reverse sorted by nesting level) of objects calling each object's validateProperties() method.

The objects in the list are processed in reversed nesting order, with the least deeply nested object accessed first. This can also be referred to as top-down or outside-in ordering.

This phase allows components whose contents depend on property settings to configure themselves prior to the measurement and the layout phases. For the sake of performance, sometimes a component's property setter method does not do all the work to update to the new property value. Instead, the property setter calls the invalidateProperties() method, deferring the work until this phase runs. This prevents unnecessary work if the property is set multiple times.

The measurement phase begins with a call to validateSize(), which walks through a list (sorted by nesting level) of objects calling each object's validateSize() method to determine if the object has changed in size.

If an object's invalidateSize() method was previously called, then the validateSize() method is called. If the size or position of the object was changed as a result of the validateSize() call, then the object's invalidateDisplayList() method is called, thus adding the object to the processing queue for the next run of the layout phase. Additionally, the object's parent is marked for both measurement and layout phases, by calling invalidateSize() and invalidateDisplayList() respectively.

The objects in the list are processed by nesting order, with the most deeply nested object accessed first. This can also be referred to as bottom-up inside-out ordering.

The layout phase begins with a call to the validateDisplayList() method, which walks through a list (reverse sorted by nesting level) of objects calling each object's validateDisplayList() method to request the object to size and position all components contained within it (i.e. its children).

If an object's invalidateDisplayList() method was previously called, then validateDisplayList() method for the object is called.

The objects in the list are processed in reversed nesting order, with the least deeply nested object accessed first. This can also be referred to as top-down or outside-in ordering.

In general, components do not override the validateProperties(), validateSize(), or validateDisplayList() methods. In the case of UIComponents, most components override the commitProperties(), measure(), or updateDisplayList() methods, which are called by the validateProperties(), validateSize(), or validateDisplayList() methods, respectively.

At application startup, a single instance of the LayoutManager is created and stored in the UIComponent.layoutManager property. All components are expected to use that instance. If you do not have access to the UIComponent object, you can also access the LayoutManager using the static LayoutManager.getInstance() method.

 

6. Package和namespace:

Package用来组织源文件、避免名字冲突以利于代码共享；namespace用于控制方法、属性或变量的访问可见性。Package据说在flash player内部也是一种namespace，只不过所有Package对编译器都是默认可见的。
每一个名字（identifier）必须有一个namespace。flash内部有四种预定义的namespace，即public、internal、protected和private。Class只能用前两者，属性、方法和变量四种都可以。这四种namespace的可见范围分别是“全局”、“package内部”、“子类链上”和“自己类内部”。
如果这四种预定义名字空间的可见范围分类不能满足要求，则可以用自定义namespace在某一种预定义访问范围内对其中的元素进行再分组，同组内的元素即同一namespace下的元素可以通过use namespace来控制它们的可见性。
自定义namespace的应用分三步：
第一步，声明定义namespace，比如：
public namespace dream = "http://dreamlover.me/ns/";或
public namespace dream;
第二步，应用namespace，比如：
import dream;
class CT
{
 dream static function testFunc()
 {
  trace("iloveyingmei");
 }
}
第三步，引用namespace下的元素，比如：
import dream;
import CT;
CT.dream::testFunc();
或
use namespace dream;
CT.testFunc();

 

 

7. as程序中domain的概念：

domain翻译成中文是“域”的意思，“区域”的“域”，这个“域”，与“域名”、“主机域”中的“域”一样，都是表示一个范围，处于该“域”之内的事物具有某些方面的共同属性。注意是“某些方面”，而不是“所有方面”，所以同一事物，在不同的角度看可能属于不同的域。也就是说，从其划分事物的方面来分类的话，域也有N多种。

Flex中有两种域的概念，另外由于flash程序与网络关系密切，所以在它的帮助文档中“网络域名”也经常出现，这三者要分清。

flex中的两种域分别是application domains和security domains。前者定义如下“An application domain is a container for class definitions.”所有的flash app共享一个“top-level” application domain：system domain，flash api中提供的类（即包flash.*.*下的类）都定义在该域中，然后每个flex应用程序（这里“flex应用程序”指使用了flex framework的程序）都有一个自己的application domain，该domain相当于system domain的child node，该flex程序使用的flex framework中的类便都定义在这个application domain中。

为什么这样做呢？flex framework有很多版本，比如目前已有的flex2、flex3、flex4等，不同的程序可能使用了不同的flex版本，而flash player又支持在一个程序中载入另外一个程序，如果flex framework中的一个类在不同的版本中具有不同的定义，那么使用了该类不同版本的app1和app2要想在一起能够运行良好的话，必定各自要包含各自的该类定义——在同一环境中，存在两个同名的类（所在包的位置等都相同），就必须要通过某种机制把它们区分开来，这就是我理解的application domain的作用。

security domain：一个app加载另一个app时，另一个app可以是“可信的”也可以是“不可信的”，可信与不可信决定了被载入的app与载入app之间的可交互程度，当被载入的app与载入app在同一个security domain中时，它是“可信的”，否则就“不可信”，两个app是不是在同一个security domain中不是自然存在的，是人为规定的。

 

8. modules与loaded applications的区别（摘自Adobe Flex4 Beta Help）：

 

Modules and sub-applications are also different. The main difference is that modules typically share classes with their host application. This sharing of classes creates a dependency between the module and the main application. Sub-applications, on the other hand, typically have their own versions of the classes, so less dependency exists between them and the main application.

Other differences between modules and sub-applications include the following:

File size

Modules and their host applications are often smaller in file size because you can externalize shared classes. You can’t always externalize shared classes for sub-applications. In cases where the versions of the applications are different, each application must have its own set of classes.

 

Reuse

Modules are more tightly bound to the host application. They use interfaces to communicate with the loading application. This means that as your application changes, if your application uses modules, you’ll probably need to recompile all of them if you move the main application to a later version of Flex.

 

Versioning

Modules do not support multi-versioning. The main application and all modules must be compiled by the same version of the Flex framework.

 

Manager classes

Modules and their host applications typically share manager classes. The modules are in a child application domain, whereas sub-applications often have their own instance of the manager class so that they can be multi-versioned.

 

ActionScript-only

Modules can be either MXML-based or ActionScript-only; applications and sub-applications are not typically pure ActionScript.

 

Application domains

sub-applications can be loaded into sibling application domains or child application domains, whereas modules must be loaded into a child application domain of the host application.

 

Security domains

Modules must be loaded into the same security domain as their host application. Sub-applications can be loaded into either the same security domain or a different security domain.

For more information about modules, see Creating modular applications.