标题：mac pro flash视频原因及解决方法

-------------------------------------------------------------------------------------------------------------------------------

时间：2015/2/20 10:24:27

-------------------------------------------------------------------------------------------------------------------------------

内容：

一是为什么 flash@osx 会使 cpu 明显发热，但 flash@win 为什么就不那么热；
二是同样是高 cpu 负荷的解压缩工作为什么就不热。

先解释下问题三：
core i 系列 cpu 有一项叫做 Turbo Boost 的单核心加速技术，可以依据功率和散热情况短时间提高单一核心的运行频率，加速时的功耗要高于无加速情况下多核心满载的功耗。
flash 是单核心依赖严重的应用，而虚拟机和解压缩可以充分利用多核心。前者会触发加速，因而实际 cpu 功耗和发热要超过后者。

至于 flash 的运行效率问题，只能说 @win 比 @osx 确实要好得多，这与两个系统的图形渲染架构有关。绝大多数 flash 以绘图工作为主，win 版本的 flash 解释器更接近图形渲染后端，而苹果出于安全以及全局考量，拒绝 flash 解释器介入图形渲染的流程，使得 flash 渲染需要走前级图形接口，效率上自然有差距。
这也是 adobe 抨击苹果不合作的地方。osx 的硬件加速长期落后于 ｗｉｎｄｏｗs 也是类似的结果。

PS
作为一种跨平台解决方案，flash 和 java 一样，不得不向效率作出妥协。而在 v9 引入 JIT 技术之后，除了寻求深度系统集成和硬件级加速，flash 已经没有再度提高运行效率的手段了。
至于 adobe 不思进取，看看 adobe 家其他产品吧，至于说 flash 优化不好，我想，有能力优化 的情况下，adobe 会看着 flash 从 90% 的市场份额一路狂跌而无动于衷？假如现在的 cpu 能够集成几十上百倍的矢量运算单元，可能 flash 会是一种人见人爱的技术。

PPS
现在 flash 唯一的阵地就是网页内嵌视频领域了，而且一直有 HTML5 video 取代 flash 的呼声。实际上二者的解码部分是一样的，区别在于，flash 不具有渲染到显卡的能力，而浏览器也没有办法介入 flash 内部，基于 flash 的视频播放必然会受图形系统的影响，而调用硬件加速在沙盒化环境中又是处处受限，前景确实惨淡。基于原生 HTML 支持的视频播放，更容易被浏览器优化，调用硬件加速也更加方便。
所以说 flash 不是死在闭门造车不思进取上，而是死在了更先进的技术面前。我丝毫不怀疑，在运算能力大幅度提升的未来，基于虚拟机的跨平台方案还会卷土重来



两个方面： H.264 解码硬件加速，屏幕渲染硬件加速。
H.264 是高清流媒体的半事实标准，高压缩比可以大幅降低网络带宽需求，代价是解码运算量大。（其他编码方式由于解码运算量小，从硬件加速中受益不明显，所以通常特指 H.264）
win 环境通常由显卡厂商随驱动提供解码器，可供 flash 和其他播放器调用。
osx 目前 Lion 版本未提供 H.264 硬件解码接口（QuickTime 可以调用私有 API 实现硬件解码）。
目前网络视频流最流行的封装手段依旧是 flash 播放器，flash@osx 的性能问题主要就是缺乏硬件解码支持造成的。
后者是现在主流操作系统图形框架的基础（compositing/hardware overlay）。这方面对于性能的影响主要是 flash 动画，不如前者明显和广泛。
compositing/overlay 的优点在于，应用程序独享自身界面部分的显存，组合渲染由显卡硬件实现，图形界面渲染对于 cpu 的占用大幅降低，同时可以利用显卡实现大量窗口特效。
02 年 Jaguar 就实现了 compositing 硬件加速（基于 opengl），06 年 vista 也转向了组合机制。08 年 flash v10 开始支持 win 硬件渲染，10 年 flash v10.1 支持 osx 硬件渲染。


flash@win 和 flash@osx 到底有什么不同？

flash 本身没有太大区别，不同在于 win/osx 的设计思想，ｗｉｎｄｏｗs 强调兼容，而 osx 硬件平台相关的，这样的区别决定了 win/osx 对于第三方 runtime 的不同态度。
win: Hardware -> OS -> OS API / 3rd runtime -> Software
osx: Hardware -> OS -> OS API -> 3rd runtime / Software
flash 作为 3rd runtime 在两个平台的地位是不同的，一般来说，越接近硬件越会有好的性能。出于兼容性考虑，win 向软件开放大量硬件细节；而 osx 只允许第三方应用调用高级 API 同时隐藏硬件细节，保证了上层应用的统一性。flash 在两个平台上的性能就有了先天性差距。


一句话总结：flash@osx 性能差的原因主要是缺少 H.264 硬件解码支持，小部分原因是图形渲染流程所致

一是为什么 flash@osx 会使 cpu 明显发热，但 flash@win 为什么就不那么热；
二是同样是高 cpu 负荷的解压缩工作为什么就不热。

先解释下问题三：
core i 系列 cpu 有一项叫做 Turbo Boost 的单核心加速技术，可以依据功率和散热情况短时间提高单一核心的运行频率，加速时的功耗要高于无加速情况下多核心满载的功耗。
flash 是单核心依赖严重的应用，而虚拟机和解压缩可以充分利用多核心。前者会触发加速，因而实际 cpu 功耗和发热要超过后者。

至于 flash 的运行效率问题，只能说 @win 比 @osx 确实要好得多，这与两个系统的图形渲染架构有关。绝大多数 flash 以绘图工作为主，win 版本的 flash 解释器更接近图形渲染后端，而苹果出于安全以及全局考量，拒绝 flash 解释器介入图形渲染的流程，使得 flash 渲染需要走前级图形接口，效率上自然有差距。
这也是 adobe 抨击苹果不合作的地方。osx 的硬件加速长期落后于 ｗｉｎｄｏｗs 也是类似的结果。

PS
作为一种跨平台解决方案，flash 和 java 一样，不得不向效率作出妥协。而在 v9 引入 JIT 技术之后，除了寻求深度系统集成和硬件级加速，flash 已经没有再度提高运行效率的手段了。
至于 adobe 不思进取，看看 adobe 家其他产品吧，至于说 flash 优化不好，我想，有能力优化 的情况下，adobe 会看着 flash 从 90% 的市场份额一路狂跌而无动于衷？假如现在的 cpu 能够集成几十上百倍的矢量运算单元，可能 flash 会是一种人见人爱的技术。

PPS
现在 flash 唯一的阵地就是网页内嵌视频领域了，而且一直有 HTML5 video 取代 flash 的呼声。实际上二者的解码部分是一样的，区别在于，flash 不具有渲染到显卡的能力，而浏览器也没有办法介入 flash 内部，基于 flash 的视频播放必然会受图形系统的影响，而调用硬件加速在沙盒化环境中又是处处受限，前景确实惨淡。基于原生 HTML 支持的视频播放，更容易被浏览器优化，调用硬件加速也更加方便。
所以说 flash 不是死在闭门造车不思进取上，而是死在了更先进的技术面前。我丝毫不怀疑，在运算能力大幅度提升的未来，基于虚拟机的跨平台方案还会卷土重来


两个方面： H.264 解码硬件加速，屏幕渲染硬件加速。
H.264 是高清流媒体的半事实标准，高压缩比可以大幅降低网络带宽需求，代价是解码运算量大。（其他编码方式由于解码运算量小，从硬件加速中受益不明显，所以通常特指 H.264）
win 环境通常由显卡厂商随驱动提供解码器，可供 flash 和其他播放器调用。
osx 目前 Lion 版本未提供 H.264 硬件解码接口（QuickTime 可以调用私有 API 实现硬件解码）。
目前网络视频流最流行的封装手段依旧是 flash 播放器，flash@osx 的性能问题主要就是缺乏硬件解码支持造成的。
后者是现在主流操作系统图形框架的基础（compositing/hardware overlay）。这方面对于性能的影响主要是 flash 动画，不如前者明显和广泛。
compositing/overlay 的优点在于，应用程序独享自身界面部分的显存，组合渲染由显卡硬件实现，图形界面渲染对于 cpu 的占用大幅降低，同时可以利用显卡实现大量窗口特效。
02 年 Jaguar 就实现了 compositing 硬件加速（基于 opengl），06 年 vista 也转向了组合机制。08 年 flash v10 开始支持 win 硬件渲染，10 年 flash v10.1 支持 osx 硬件渲染。


flash@win 和 flash@osx 到底有什么不同？

flash 本身没有太大区别，不同在于 win/osx 的设计思想，ｗｉｎｄｏｗs 强调兼容，而 osx 硬件平台相关的，这样的区别决定了 win/osx 对于第三方 runtime 的不同态度。
win: Hardware -> OS -> OS API / 3rd runtime -> Software
osx: Hardware -> OS -> OS API -> 3rd runtime / Software
flash 作为 3rd runtime 在两个平台的地位是不同的，一般来说，越接近硬件越会有好的性能。出于兼容性考虑，win 向软件开放大量硬件细节；而 osx 只允许第三方应用调用高级 API 同时隐藏硬件细节，保证了上层应用的统一性。flash 在两个平台上的性能就有了先天性差距。


一句话总结：flash@osx 性能差的原因主要是缺少 H.264 硬件解码支持，小部分原因是图形渲染流程所致