来看看Flash的奇葩数据结构，你就知道为什么Flash慢如蜗牛了

noword2k

众所周知，Adobe 放弃了 Flash 在移动平台的市场，一条重要的原因就是Flash跑起来太慢了。
Flash为什么这么慢？一起来看看它奇葩的数据结构就知道了。

关于swf格式，Adobe官网上有完整PDF可以下载。
http://www.adobe.com/devnet/swf.html

从Basic Data Types开始，前面是有符号和无符号的整数，从8位到64位都有；接下来是定点数，也很正常。

下面的浮点数，竟然有16位的浮点数。
有那种现代CPU直接支持16位浮点数吗？至少i386架构的CPU没有吧。
还得转换成标准的32位float，才能运算吧。
搜索一下“half float”，看看怎么转吧。

1. 
   
2. unsigned int
   
3. halfToFloat (unsigned short y)
   
4. {
   
5. 
   
6.     int s = (y >> 15) & 0x00000001;
   
7.     int e = (y >> 10) & 0x0000001f;
   
8.     int m =  y        & 0x000003ff;
   
9. 
   
10.     if (e == 0)
    
11.     {
    
12.         if (m == 0)
    
13.         {
    
14.             //
    
15.             // Plus or minus zero
    
16.             //
    
17. 
    
18.             return s << 31;
    
19.         }
    
20.         else
    
21.         {
    
22.             //
    
23.             // Denormalized number -- renormalize it
    
24.             //
    
25. 
    
26.             while (!(m & 0x00000400))
    
27.             {
    
28.                 m <<= 1;
    
29.                 e -=  1;
    
30.             }
    
31. 
    
32.             e += 1;
    
33.             m &= ~0x00000400;
    
34.         }
    
35.     }
    
36.     else if (e == 31)
    
37.     {
    
38.         if (m == 0)
    
39.         {
    
40.             //
    
41.             // Positive or negative infinity
    
42.             //
    
43. 
    
44.             return (s << 31) | 0x7f800000;
    
45.         }
    
46.         else
    
47.         {
    
48.             //
    
49.             // Nan -- preserve sign and significand bits
    
50.             //
    
51. 
    
52.             return (s << 31) | 0x7f800000 | (m << 13);
    
53.         }
    
54.     }
    
55. 
    
56.     //
    
57.     // Normalized number
    
58.     //
    
59. 
    
60.     e = e + (127 - 15);
    
61.     m = m << 13;
    
62. 
    
63.     //
    
64.     // Assemble s, e and m.
    
65.     //
    
66. 
    
67.     return (s << 31) | (e << 23) | m;
    
68. }
    

复制代码

nvidia-texture-tools里面，还有为了优化，而更加夸张的代码。
为了用16位的浮点数，而在底层付出这样的代价，值得吗？

继续看下去。
接下来是EncodedU32。以前，你听说过有这种东东吗？
简单的说，就是可变长的整数。
来看看读取的代码：

1. 
   
2.         unsigned int value = 0;
   
3.         value = getUI8();
   
4.         if (!(value & 0x80)) {
   
5.                 return value;
   
6.         }
   
7.         value = (value & 0x7f) | (getUI8() << 7);
   
8.         if (!(value & 0x4000)) {
   
9.                 return value;
   
10.         }
    
11.         value = (value & 0x3fff) | (getUI8() << 14);
    
12.         if (!(value & 0x200000)) {
    
13.                 return value;
    
14.         }
    
15.         value = (value & 0x1fffff) | (getUI8() << 21);
    
16.         if (!(value & 0x10000000)) {
    
17.                 return value;
    
18.         }
    
19.         value = (value & 0xfffffff) | (getUI8() << 28);
    
20.         return value;
    

复制代码

直接用32位的整数，会死人吗？

接下去，还有更雷人的Rectangle record 和 MATRIX record，取值单位是bit，注意是bit不是byte。
例如，一个byte前5个bit是某个值，后3个bit与后一个byte的若干个bit组成另一个值。

大规模的使用变长的bit结构，这样“打碎”byte的做法，贯穿着整个flash结构。
我不知道当初的设计人员是怎么考虑的，为了节省存储空间吗，还是为秀技巧？
节省存储空间的话，flash不是直接支持zlib压缩的格式吗？

flash死的一点也不冤，从诞生的那一刻起，从那个脑残的 leader 定义这种脑残的数据结构起，就注定失败。

hbmhalley

卧槽 .. 顶起求验证

AD8018

不奇怪，在用电话线上网的年代，flash文件的大小很重要。
正是由于其用极小的空间实现了动画，
它才能如此的成功。
当然，败也萧何，这好像是后话了。

noword2k

AD8018 发表于 2012-01-10 16:07
不奇怪，在用电话线上网的年代，flash文件的大小很重要。
正是由于其用极小的空间实现了动画，
它才能如此 ...

我文章里已说过，如果为了减少存储空间，flash已经有 zlib 了。
文件的信息量不变，用zlib压缩以后，能有多大的区别呢？

鸡丝拌面

难道是为了奸蝾？

hbmhalley

回复 5# 鸡丝拌面


    .. 这个词有什么隐含意义或思想感情么

koolcoy

不就是一个16位的浮点数么，有啥奇怪的。可以有8位的整数，为啥不能有16位的浮点数

noword2k

koolcoy 发表于 2012-01-10 17:42
不就是一个16位的浮点数么，有啥奇怪的。可以有8位的整数，为啥不能有16位的浮点数

回帖不看贴的，你对得起你的头像吗？

koolcoy

回复 8# noword2k

你咋知道我没看帖的{:3_189:}
你不就是因为flash用了一个x86 cpu不支持的16位浮点数，而16位浮点转32位浮点算法繁琐，发了一肚子牢骚么~~~

koolcoy

哦，看见了，还发了其它牢骚的{:3_196:}
视频处理这种以bit为单位的数据结构到处都是，你看看h264什么的就知道了