AS3里的禁区：Timer

因为项目，接手了一个公司外包flex项目的跟进，BUG很多，慢慢理清程序逻辑，发现外包的团队，都有一个使用Timer的不良习惯，从而导致了该项目从开发初期，就已经埋好了很多地雷。

我会从项目里抽出部分代码说明，最后以自己的经验，做个总结，什么时候用TIMER，什么时候不该用TIMER

	/**
		 * 
		 * @param event
		 * 
		 */
		protected function resizeHandler(event:ResizeEvent):void
		{
			var timer:Timer = new Timer(50,1);
			timer.addEventListener(TimerEvent.TIMER_COMPLETE,function():void
			{
				fitDisplay();
			});
			timer.start();
			
		}

这里的fitDisplay(); 就是用户处理屏幕缩放后，界面元素的尺寸处理

这里大家可以很显然看到，有一个50毫秒的延时，至于为什么用50毫秒，估计外包的公司的那几个程序员，做过了一些测试，可能他们的开发机，上限制值20毫秒就能有处理结果，他们为了保险，用了50毫秒，就臆断了客户机可以胜任了此程序的运行。

很显然这是不负责任的写法，程序员的职责是什么？就是编写能稳定运行功能的代码。为什么这次要重点讲到这部分，是因为TIMER,一直都有不少人在重复犯相同的错误，而这次的外包项目，我从代码的注释和编码风格，大概知道了是2个老手带3个新手，而这个团队5个人都有乱语，甚至滥用TIMER的习惯。

好了，吐槽完毕，认真的解析下这个TIMER的官方说法：

Timer 类是 Flash Player 计时器的接口。 可以创建新的 Timer 对象，以便按指定的时间顺序运行代码。 使用 start() 方法来启动计时器。 为 timer 事件添加事件侦听器，以便将代码设置为按计时器间隔运行。 
可以创建 Timer 对象以运行一次或按指定间隔重复运行，从而按计划执行代码。 取决于 SWF 文件的帧频或 Flash Player 的环境（可用内存及其它因素），Flash Player 会能会按稍有偏差的间隔调度事件。 例如，如果某个 SWF 文件设置为以每秒 10 帧 [fps]（也就是 100 毫秒的间隔）的速度播放，但计时器设置为在 80 毫秒时触发事件，则 Flash Player 将按接近于 100 毫秒的间隔触发事件。 大量耗费内存的脚本也可能使事件发生偏差。

官方解释的很清楚，FlashPlayer的虚拟机是以帧频去触发渲染的，而帧频又和电脑硬件等有着必然联系，所以注定了开发者不能以自己或周边几天电脑为判断依据，去随意估值一个延时的时间，再去触发事件，这样会有很多不可预计的现象发生。

还有现在从事FLEX开发的程序员，并不是从flash转型过来，对帧频这个概念比较模糊

上述只是其1的问题，是FP自身的渲染逻辑注定的，其2大量使用TIMER，是程序员自身不负责任的编码习惯。 上述那段代码，其实就是界面初始化后，才能去执行缩放处理，但是界面初始化是有一定的时间差，这个时间差应该通过事件去调度执行缩放处理，而不是妄自的认为给定一个50毫秒就解决的。现在初始化50毫秒上限制可以渲染出来，假如刚好在那个初始阶段，机器有其他吃CPU的软件在突然运行，那50毫秒，甚至500毫秒都可能渲染不出来，那这个缩放处理函数还是会出错，报null值错误。作为程序员，应该是严谨的，多学习事件执行流程对自己开发是多多益善。

说了这么多，就是告诫自己，程序运行执行的逻辑顺序，一定要掌握在自己手中，而不是交给机器，放任不管，这样可以做到心中有数，遇到BUG也知道问题出在哪里。而不是去各种瞎碰，去修改延时时间。