一则关于flash与耗能（散热）的关系的实测

个人观点：当我们没有选择权的时候，我们只能忍气吞声...所以由软件引起的一些问题，我们只能通过改善运行环境来解决，面对flash这个耗能问题，我很是喜欢有新的技术代替它，以前我玩一款flash小游戏，cup温度从47°C飙升到69°C,这个东西让我很是害怕

要那马儿跑，又要不吃草，难。

要那马儿跑，但要少吃草，可以。

Flash在功耗上改进需两方面之一支持：
1、宿主程序，即浏览器支持GPU渲染，ie9支持，慢慢等吧；
2、Flash Player支持GPU渲染，这个已部分实现，在10.1版本后已支持大部分新的GPU。

不过，确实，Adobe的动作太慢！垄断太久，惰性太大，需要有力的竞争者。

早就听说过flash对cpu的占用高， 发热问题是最近发现的， 偶尔拿着本本看看优酷和土豆视频， 却发现本本很快就烫手了，比玩游戏发热还要猛。
lz太有心了， 分析的很有条理。

在我这里来说视频到还好，pplive，kank最高也就95℃，如果是玩游戏——一般的如deadtime之类的一直99℃,而魔兽争霸b必须说会100℃。而wow则100+，搞不好就自动关机。。

flash我倒是没有什么怨念，除了不能选择文本，在浏览器里的index过高，还有最近的发热外。。

但不得不说flash干了Java生来具备的使命——跨平台。因为发热问题转到Ubuntu后，发现消遣的地方还真少，，视频网站好的几个pplive，ppstream，迅雷看看，pipi，风行等全不能用了，，，但是像youku，土豆和yiqi之类的flash播放器网站幸存了，，，，


不得不感慨Java的命运啊！

就算是个静态的图片，flash每秒都要刷新几十次的....你指的是什么呢
它如果不重绘 当然就不必进行那么复杂的计算了.
那你以为什么软件呈现图像不需要"你说的刷新么"
我来告诉你 你电脑要是液晶屏的话 频率应该是60HZ 它本身不会计算 计算是在显卡的部分[或是CPU],影像不动的话 显卡只是把之前显存的数据输出给显示器 显示器不断地刷新 ,显示器并不关心数据是否变化 它一直只管不断不断地刷新屏幕.一点不动 它也在刷新.

但是如果你的图像不动 你的显卡会热的爆掉么  同学  它不必计算了  这就是为什么你玩<镜之边缘>时而热的死机,但是什么不做,退到桌面的时候不会死机 非计算机专业的吧
服了U

显卡和显示器刷新的原理就不用你普及了，就算鼠标不动，图片是静态的，程序也得有个判断要不要刷新缓冲区吧，你就那么肯定flash实现的那么完美。我说的只是自己猜测的一个可能的原因而已，你既然那么“专业”，那就请给个答案吧

Flash Player 呈现图像的时候 是以帧的概念,进行绘制的.
每一帧交付出去的时候(咱俩讨论的是浏览器的,所以就交付给浏览器了),都是一个位图信息.
这个信息的由来是在FlashPlayer(我就简称FPR了)好一顿渲染计算得来的
在Flex与Flash中 程序员在画界面的时候都是以层的概念来布局的.
在Flex3中大量使用的布局Box,到Flex4中的Group.充拆着Flash的整个屏幕,
打开一个Spark控件的Skin 就可以看得到,Group一层又一层的堆满了.
但是FPR显然不能每一帧都是一层层的输出到屏幕上去的,要是这样,估计Adobe这个公司早就黄了.

有一个队列,是当时屏上可显控件组成的,渲染的时候,是根据这个队列中的控件可视形状生成边缘列表,之后再对这个形状进行优化,再进行填充.之后再扫描逐行边缘生成像素的信息.
比如你放置了一个按钮90*90, 然后又放置了一个全屏大小的图片上去,图片是在按钮之上的,也就是把按钮遮盖住了
那么在成像计算的时候,这个按钮实际上并没有被绘制出来,而是在根据它的大小,位置,层级进行计算的时候,创建出形状为空.
而且,这个渲染计算也不是即时的,而是稍有一些延迟.
这也使得期间进行了一系列的优化工作.比如一个按钮刚加上去就被移除了, 实际上这个按钮进入队列还未参加下一次渲染计算的时候,被发现,就会直接再从队列中移出.
又比如说,你使用一个画笔画一个矩形,马上清空,又使用这个画笔画了一个圆.在优化工作中,第一个绘制矩形并没有被真的绘制.


至于"程序也得有个判断要不要刷新缓冲区吧",这个在FPR里边是通过事件机制来实现的.事件发生后就是执行代码的时候,在虚拟机中.
假设,一个空白的画布,然后静静不动,一分钟后(我可以通过定时器,或是鼠标点击)我在这个画布上添加了一个Button.
我使用的是AddElement方法.这个AddElement方法执行的时候,它也就触发了渲染的事件,于是这个新加入的Button也就进入了待显示队列之中,
当下一次的渲染操作(其实就是下一帧成像时)执行的时候,渲染器就会对这个Button进行扫描边缘....上面提到的过程
最后得出了 Button所在区域的像素信息.这个时候把这个信息更新到之前的已成像的位图缓冲区中就可以了.
即这样一个简单的动作,并没有重新计算其他的不变的地方,只是改变的地方被重新计算了.
我们使用的FlashPlayer都是发布版,也可以去Google搜"FlashPlayer Debug DownLoad"下载Debug版本的FlashPlayer,
在Debug版中, 点击右键,会多出来一个显示重绘区域,选上之后,会用红色框标记出来,在画图发生变化的时候哪一区域被重绘了

既然楼上提到了FPS,我就再多说一点,据听闻,除了MAC机外的其他PC机上使用的FPR,它的FPS貌似是变化的.帧之间的间隔好像是十几MS至100MS之间?记不太清楚了.当FPR要求的频率比当前频率低的时候,好像是会自动降频的.

不过这个无所谓,咱们说的是画面不动的时候.如果真的画面一点不动了,就没有任何事件发生,那么显示的列表也就是一个空列表,渲染器工作的时候,列表为空,那它就算已经工作完了.没更新,So把之前缓冲区中的旧数据再输出就可以了.

打字有些快, 错别字,语病就不挑了
---------------
没有攻击的意思
但是我觉得好像国内从事Flex与Flash开发的人员中,出身自艺术类要多一些,零编程经验的也要多一些.
你让这些人去搞颜色,布局那自是非常不错的了.但是要让他们像正常的Coder一样去注重算法,注重逻辑,注意内存泄漏,貌似有一些困难.
一个优秀的有经验的C/C++或Javaer尚不能完全控制自己的代码.何况这些人呢.
我举一个简单的例子,比如一张柱形图的图表,当这个图表更新的时候,它有两部分在更新(我就说成是两部分吧,有可能更多的),一部分是显示区,一部分是坐标轴.当两部分都更新结束之后,这张图才是我们要呈现的.可是中途有可能其他的事件会影响这个过程,导致未完成时,就把它加入到显示列表中了.
所以,官方实现的时候,非常注意,在覆写UpdateDisplay的时候,很多阶段都使用了阻止重绘的方法,以防止进行很多不必要的重复的工作.
又比如,控件要更改宽度和高度，如果在更改宽度后立即更新组件，然后在设置新高度后,再次更新组件，就有些浪费。更改两个属性后再使用新的大小一次性呈示组件，效率会更高。
很难相像现在有多少的Flash/Flex程序员在设计自己的图形控件时都如此细微的考虑.那么那种基于Flash的网游,
满屏幕人物花草,随意的使用资源,随意地呈现动画,让你的电脑卡一些也是正常的.不卡才不正常呢.

还有就是Adobe的Flash版本也是在变化的.如Java一样. 说1.6已经这么多年了, 可还有人在使用1.4吧.那你使用1.4编程,用不了新的特性,没有新的优化,又能怪谁呢.要知道现在很多开发Flash版本也是旧的.
假设它发布的8版的,即使用的环境是10版的也没有用,也是按8版的去执行.搞不好还可能有兼容不好的地方,在新版的FPR下还会报错.历史原因,和习惯问题.谁也阻止不了.

若说你是枪文，恐怕你不服！
图形动画需要大量计算。会导致计算机发热。
你要是有个同样动画，用其他技术来实现，然后进行温度比较才公平客观，否则你要马儿跑，又不要马儿吃草，明显有问题！

cpu运行动画，肯定耗能厉害；移到gpu，可能又不想做2d了，呵呵，而且gpu级别上的开发成本太高了，耗能估计也不会低的很明显（一般优化好了耗能可能也会相应低些），gpu级别的喜欢60fps，相信对楼主的机器很摧残啊。

难得这么长的回复，，很有营养。有些东西在冲突的时候可能更容易暴露，欢迎良性的争论！