|
| Flash的压缩算法 |
| 来源：转载 人气：1706 录入时间：2007-11-8 |
由于要解决大数据传输问题,所以前几天研究了一下,Flash的压缩算法,8.5以前版本的FlashPlayer本身没有压缩算法,所以只能用户自己写,清风同志挑选了LZW算法，因为是无损压缩，而且压缩比很高，但使用过程中发现压缩速度以及对cpu的占用确实有些高(一个64K的字符串,压缩后大概是14-16K之间,结果很好,但是过程大概要用1.5秒,有明显的停顿感,要是120K客户端可就受不了)
加上flash是脚本语言，延迟比较明显.所以还是等到8.5正式出了以后吧,好的都要留到最后!
ActionScript的lzw压缩算法:
http://blog.xuite.net/ticore/blog2/4060011
什么是LZW
LZW压缩编码
LZW（Lempel Ziv Welch）压缩编码是一种先进的数据压缩技术，属于无损压缩编码，该编码主要用于图像数据的压缩。对于简单图像和平滑且噪声小的信号源具有较高的压缩比，并且有较高的压缩和解压缩速度。
1977年，两位以色列教授Lempel和Ziv提出了查找冗余字符和用较短的符号标记替代冗余字符的概念。1985年，由Welch加以充实而形成LZW，简称“LZW”技术。
1.LZW压缩基本原理
LZW压缩技术把数据流中复杂的数据用简单的代码来表示，并把代码和数据的对应关系建立一个转换表，又叫“字符串表”。
转换表是在压缩或解压缩过程中动态生成的表，该表只在进行压缩或解压缩过程中需要，一旦压缩和解压缩结束，该表将不再起任何作用。
2.LZW算法
LZW算法基于转换串表（字典）T，将输入字符串映射成定长（通常为12位）的码字。在12位4096种可能的代码中，256个代表单字符，剩下3840给出现的字符串。
LZW字典中的字符串具有前缀性，即 。
LZW算法流程：
1)初始化：将所有的单字符串放入串表
2)读第一个输入字符给前缀串ω
3)Step: 读下一个输入字符K;
if 没有这样的K(输入已穷尽)：
码字(ω) 输出；结束。
If ωK 已存在于串表中：
ωK:=ω；repeat Step；
else ωK不在于串表中:
码字(ω) 输出；
ωK加进串表；
K:=ω；repeat Step.
例子：ababcbababaaaaaaa
LZW编码：a,b,c,ab,ba,abc,cb,bab,baba,aa,aaa,aaaa
3．LZW压缩的特点
LZW码能有效利用字符出现频率冗余度进行压缩，且字典是自适应生成的，但通常不能有效地利用位置冗余度。
具体特点如下：
l)LZW压缩技术对于可预测性不大的数据具有较好的处理效果，常用于GIF格式的图像压缩，其平均压缩比在2)1以上，最高压缩比可达到3：1。
2)对于数据流中连续重复出现的字节和字串，LZW压缩技术具有很高的压缩比。
3)除了用于图像数据处理以外，LZW压缩技术还被用于文本程序等数据压缩领域。
4)LZW压缩技术有很多变体，例如常见的ARC、RKARC、PKZIP高效压缩程序。
5)对于任意宽度和像素位长度的图像，都具有稳定的压缩过程。压缩和解压缩速度较快。
6)对机器硬件条件要求不高，在 Intel 80386的计算机上即可进行压缩和解压缩。
各种压缩算法的介绍
http://www.chinaaspx.com/comm/dotnetbbs/Showtopic.aspx?Forum_ID=44&Id=139926&PPage=1
Flash本身作zlib压缩(需要FlashPlayer8.5支持)
flashwenfeng2005-12-28, 12:31 PM
AS3除了带来全新的DOM外，另一个大革新就是 Event Model。
以往在AS1/2里，处理事件的方式有百百种，但基本上就是：
Actionscript:
btn.onRelease = function(){
//do something
}
或是
Actionscript:
Mouse.addListener(someListener);
function someListener(){
//do...
}
而使用V2 components时，处理方式又变成
Actionscript:
btn.addEventListener("click", doClick);
这些不一致性往往让新手倍感头痛(好吧，其实老手才更是咬牙切齿...)不知标准在那。
从AS3开始，flash的世界将只有一种Event Model，也就是V2 元件用的那种，而为了惯彻这种设计理念，整个Actionscript Class的架构都做了大改变，我们可以从下面的class tree看出来。
Object
|
+--flash.events.EventDispatcher
|
+--flash.display.DisplayObject
|
+--flash.display.InteractiveObject
|
+--flash.display.DisplayObjectContainer
|
+--flash.display.Sprite
|
+--flash.display.MovieClip
在这个架构的最上层是Object(是的，这代表下次你不知该如何cast一个物件时，仍然有个万灵丹可恶搞，但当然这样做要付出许多代价)，下一个就是 EventDispatcher，这代表者flash里几乎每个物件都俱备了 dispatchEvent()的能力，因此自然也都可以用 addEventListener()来侦听事件。
这也是为何在 flash.events.* 里面新增了快一百多种event type 与 event class，真可说是处处是event、何处不广播啊~
既然放了这张图，可以顺便看一下这颗树的前面几层，前文中提到的 Display Object与 DisplayObjectContanier都在很前面的位置，因此它们的重要性就不言可喻，此外InteractiveObject也是个重要的东西，它负责一切 Mouse, Keyboard、IME等装置的动作侦测与广播，从它所在的位置就可看出这次mm真的是很用心在重新设计整个架构。
AS3其它几个重大的改变快速整理如下：
＊runtime type checking + JIT compiled bytecode:
AS2之前flash只有 compiler time check, 因此许多runtime做的 type casting如果发生错误是没办法被抓出来的，只能靠自已一次次的 debug并trace每个物件来瞭解程式执行时记忆体的状态，但现在加入了 runtime type checking后事情就变的很不一样。
每次在 eclipse里debug 时，只要一出现 casting error，eclipse会立刻跳到那一段并说明那里错误，我故意试了几个转手casting的dirty trick想骗过它结果没一个成功。
至于JIT的好处主要是在 byte code 与 native code之间的转换，前者有体积小、可携性高与安全的优点，但是执行效率慢(非常慢，看看JVM 1.1时的表现即知，或拿 FP7 与 FP8.5比较看看也可以)，后者最主要的优点就是「快」，快到像 C++一样的神速，这次 FP8.5全面採用 JIT bytecode后，执行效率的进步已经快到让人惊讶(一般常见的测速结果都有 10x - 15x左右的差距)。
＊32k 魔咒退却：
以往一个class最大只能有32k, 这让许多人得不停的把原本好好的一支class给分裂出去，才能降到 32k以下，而AS3则一口气把这个limit拉高到 8mb，yes, 这应该是一个你永远也没办法达到的上限才对，如果你能达到，代表你该把 design pattern的书拿出来再好好k一遍 Facade 跟 delegate 这两章....(呃 Abstract Factory 跟 Command其实也要看一下)
＊binary socket:
这是一个非常有趣的功能，FP8.5可以直接透过socket与各种socket server连线，最常见的socket 应用就是 email, 例如可以用 flash 写一个 native的 pop3/smtp mail client，或是够热血的话可以连 NNTP, IMAP, IRC, SSH等各种应用都写起来，目前我正在试者写一个 pop3 client，直接透过 port 110 跟 pop3 server交谈并操作，虽然对 socket programming还不是很熟悉，但仍然觉得很有趣啊~
另外伴随 binary socket而来的就是 byteArray，这个array可以储存 binary的资料，一般是透过socket传回来的资料，但有趣的是它提供了一个 zlib压缩功能，只要用：
Actionscript:
ByteArray.compress();
就可以使用FP内建的 zlib 将资料压缩，然后透过 socket传出去，更棒的是，还记得 Flash 8里最引人注目的 Image API吗？现在只要透过 ByteArray.readXXX()的一系列操作，就可以将Image Data读入 ByteArray, 然后压缩后传回 server，这不正是许多人梦眛以求的图片/video上传功能吗？(ticore你不用再试 lzw 跟 php压缩了，开始用 byteArray + socket才是王道啊...)
＊mx.collection.*:
这个 package里提供了两个重要的资料结构，一个是 ICollectionView，另一个是 IList，它们将是未来AS3里最主流的两种资料结构(当然 Array的重要性仍然是排第一的啦)，而在这里面最重要的实作就是 ArrayCollection，简单来讲，它就是 RecordSet的继任人选，对使用 flash remoting的人来说，recordset的重要性与必要性应该不用再解释吧？现在既然AS3已把 recordset完全拿掉而且也不会再支援，应该是开始学ArrayCollection的时后啰~
＊AMF3:
AMF(Action Media Format)是flash remoting, flashcom, local connection三者共用的 binary format，主要用来传递native flash object 并提供高度压缩与自动编/解码的功能，之前AS2使用的现在统称为 AMF0，而AMF3自然就是专给AS3使用。
它主要的改良是在运作模式与编码方式上，变的更有效率而且更聪明，因此可以大幅减少redundant data，这代表者传输速度会更快，同时应用范围也会更广，而且种种迹象显示mm似乎有开放这个规格的倾向(例如在手册中就提到 binary socket 的用途之一是透过它传递AMF object)。
但由于 FP8.5还在alpha阶段，因此 remoting adptor这段只能靠最原始的 NetConnection自已去手动制作，当初为了成功连回 AMFPHP，可是废了好大一翻功夫把整个 NetService, Service class都翻完才搞定，这真是回味无穷的经验吶 -_-"
＊e4x:
好吧，这个实在已经是旧闻中的旧闻了，AS3正式支援 ECMAScript For XML，you can dot down the xml document, period.
不过目前E4X 真的还在alpha的阶段，执行效率只能用惨不忍睹来形容，比自已写的 XPath还要慢，所以现在还不用期待太深。
Python作zlib压缩
imoprt zlib
s1=zlib.compress(s)#压缩
s2=zlib.decompress(s1) #解压缩
|
| |
|
