写flash的哥们,你能否动动脑子,写一下异常处理?
最近在用haokanbu这个服务的时候,遇到一个问题:上传到一半的时候,浏览器失去响应。
我日常用chrome或者firefox,机器内存3G,所以一般是碰不到失去响应的情况的(因为除了IE这样的石器时代浏览器,现在的浏览器一般都做了多线程处理,其中一个部分出了问题不会连累整体)。那么原因在哪里呢?不用猜了,99%是在Flash部件里面。
Flash是个好东西,过去要想在浏览器里面用到多媒体,或者玩游戏,基本只能指望flash。一直到现在,网页视频,标准而通用的方法就是flash播放器。但是苹果声称它的ipad不支持flash,因为它庞大,耗电,而且容易崩溃。
好吧,flash相当于做了一个js虚拟机,而且不像现代的webkit里面的js这样的虚拟机,优化做的还不好(在js虚拟机优化的理论已经公开的今天,估计能在下几个版本看到性能的大提升吧),自然比较耗电。庞大则见仁见智,也就手机这种内存非常紧张的设备才需要害怕那十几兆的内存占用。容易崩溃?
好吧,flash里面 塞进了太多的内容和兼容性,有很多漏洞和容易崩溃是难免的,最大的问题还是adobe公司的开发策略:在快速提供新功能和保持兼容的双重压力下当然难以在稳定和简洁上有所作为(微软的软件就是因此而很烂的……),adobe公司自己的开发管理也称不上很好。偏偏flash又是一个黑匣子,外部的浏览器不能去管理flash内部的死循环……
但是youtube等无数公司的flash界面好得很,从来也没有出过问题啊……
所以说,flash的大部分问题,还是在于写flash程序的程序员身上。你足够小心,那么很容易出错的c也能非常干净和难以出错;你马马虎虎,那么什么都管得死死的,不让你犯错误的java也能故障连连。
我遇到的那个问题是什么呢?非常显然,据我猜测就是对上传图片时候的错误响应(超时,或者错误返回代码)没有写一个比较完善的异常处理。js有很好的异常处理语法,但是你完全不去处理,不抛出也不捕获,那么自然就会是死循环,无尽的等待。
大公司的flash都经过严格测试,防止这些不够完善的异常处理出现(因为这些往往也是黑客可以利用的漏洞),自然我们用起来顺滑,快捷,防错……但是小公司的一些flash插件,那就是悲剧的发生源。实际上写这些东西需要的知识并不多,需要最多的是耐心和测试……但是对于一个小公司,或者对于一个热衷于快速开发新功能的公司,就很难说了。
我日常用chrome或者firefox,机器内存3G,所以一般是碰不到失去响应的情况的(因为除了IE这样的石器时代浏览器,现在的浏览器一般都做了多线程处理,其中一个部分出了问题不会连累整体)。那么原因在哪里呢?不用猜了,99%是在Flash部件里面。
Flash是个好东西,过去要想在浏览器里面用到多媒体,或者玩游戏,基本只能指望flash。一直到现在,网页视频,标准而通用的方法就是flash播放器。但是苹果声称它的ipad不支持flash,因为它庞大,耗电,而且容易崩溃。
好吧,flash相当于做了一个js虚拟机,而且不像现代的webkit里面的js这样的虚拟机,优化做的还不好(在js虚拟机优化的理论已经公开的今天,估计能在下几个版本看到性能的大提升吧),自然比较耗电。庞大则见仁见智,也就手机这种内存非常紧张的设备才需要害怕那十几兆的内存占用。容易崩溃?
好吧,flash里面 塞进了太多的内容和兼容性,有很多漏洞和容易崩溃是难免的,最大的问题还是adobe公司的开发策略:在快速提供新功能和保持兼容的双重压力下当然难以在稳定和简洁上有所作为(微软的软件就是因此而很烂的……),adobe公司自己的开发管理也称不上很好。偏偏flash又是一个黑匣子,外部的浏览器不能去管理flash内部的死循环……
但是youtube等无数公司的flash界面好得很,从来也没有出过问题啊……
所以说,flash的大部分问题,还是在于写flash程序的程序员身上。你足够小心,那么很容易出错的c也能非常干净和难以出错;你马马虎虎,那么什么都管得死死的,不让你犯错误的java也能故障连连。
我遇到的那个问题是什么呢?非常显然,据我猜测就是对上传图片时候的错误响应(超时,或者错误返回代码)没有写一个比较完善的异常处理。js有很好的异常处理语法,但是你完全不去处理,不抛出也不捕获,那么自然就会是死循环,无尽的等待。
大公司的flash都经过严格测试,防止这些不够完善的异常处理出现(因为这些往往也是黑客可以利用的漏洞),自然我们用起来顺滑,快捷,防错……但是小公司的一些flash插件,那就是悲剧的发生源。实际上写这些东西需要的知识并不多,需要最多的是耐心和测试……但是对于一个小公司,或者对于一个热衷于快速开发新功能的公司,就很难说了。