之前有很多人质疑lock的效率，那到底lock有没有作用，今天做了个测试。
首先说明，lock只对setPixel、setPixel32有效，其他位图的API没有区别。
下面测试循环一千万次 setPixel32()
oldTime = getTimer();
bmp1.lock();
for (var i:int = 0; i < 10000000; i++)
bmp1.setPixel32(100, 100,0xffcc0000);
trace("锁了：", getTimer() - oldTime);
bmp1.unlock();
oldTime = getTimer();
for (var j:int = 0; j < 10000000; j++)
bmp1.setPixel32(100, 100,0xffcc0000);
trace("没锁：", getTimer() - oldTime);
输出：
测试代码：
记得加上编译参数：–keep-as3-metadata+=Embed
package com.cityShop.assets
{
import flash.utils.describeType;
/**
* ...
* @author Cenfee
*/
public class AssetsManager
{
[Embed(source = "../../../../assets/renderer/map/tiles/red_tile.png")]
public var Building1:Class;
public function AssetsManager()
{
trace(describeType(this));
}
}
}
【翻译】http://jacksondunstan.com/articles/1279
最近在进行内存分析，我发现了在AS3中一些不为人知的途径而造成的内存分配。我并非从分配的过程中分析，而是从垃圾回收时候。曾经使用一个Flash分析器，仅仅是看到CPU不断地在扫描、覆盖、回收一大块内存。没错，那就是GC在工作。这篇文章就是讲如何防止这些隐藏的对象的内存分配，这些微妙的错误可能会造成很大的问题。
首先，连接字符串也会分配内存。这些看起来没什么的可能会是性能的杀手。
// 分配两个字符串
var fullName:String = person.first + " " + person.last;
// 分配N各字符串
for (var i:int = 0; i < N; ++i)
{
trace("person #" + i);
}
接下来是Vector3D和Matrix3D类。不幸的是，这些核心内置的3D辅助类某些操作会使得它完成地重新分配内存。
这几天关于对象池的呼声非常高，都源于这篇文章：http://bbs.9ria.com/thread-114544-1-1.html
其实对象池并不适用于大多情况，并且使用不当，反而得到相反的结果，内存，CPU消耗更大。
对象池就是大量对象的集合。（你可以用数组保存它们）
（黑色就是已经符合被移除条件的，非活动的；白色代表正在使用中的，活动的）