|
Flash的压缩算法 |
来源:转载 人气:1705 录入时间: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) #解压缩
|
|
|