因为项目,接手了一个公司外包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也知道问题出在哪里。而不是去各种瞎碰,去修改延时时间。