Flash RIA

登录站点

用户名

密码

划时代的 Adobe Alchemy

2已有 1096 次阅读  2009-01-27 16:52   标签Adobe  Alchemy  划时代 

划时代的 Adobe Alchemy

      

       Adobe 自从2007年中推出了AS3支持了面向对象的开发方式之后, 可谓动作不断. 去年又将AVM2的核心虚拟机tamarin 捐赠给了ECMA4 , 又将FlexBuild2直接升级到FlexBuild3, 这不,08年末,又蹦出一个 Adobe Alchemy, 这在战略上具有极为重要意义. FLASH 从一个简单的动画客户端,一跃升级成一个未来富媒体应用程序的平台. 从这一系列战略步骤,不难看出ADOBE想成为WEB乃至桌面开发霸主的野心! 微软你要小心了.

      

那么你可能要问了, 为什么Alchemy这么重要呢?  作为FLASH实践者, 效率问题是众所周知的. 因为, FLASH中运行的代码是 ACTIONSCRIPT, 它是一个脚本语言.而这个语言是运行在FLASH内部的AVM2虚拟机上的. 所以它的一些功能都需要经过, 语言解释成AVM2虚拟机字节码,然后AVM2运行字节码,最后由本地NATIVE语言,也就是本机2进制程序执行.虽然这解决了平台无关的问题,但是带来一个副作用,就是比较慢,这就是为什么FLASH上一直没有杀手级应用的主要原因.

 

从本质上来说, 这是一个构架上的问题. Alchemy 的出现,从构架上,改进了这个问题,你可以使用C/C++编写核心,快速的算法,AS3进行调用,达到加速的目标. 这在过去,你只能使用ADOVE提供给你的内置native 程序. 现在,你可以自己干这件事情了. 既解决了平台无关的问题,又解决了效率的问题,甚至可以利用FLASH本身几十亿现有的客户端的优势,解决了渠道问题.可以这样说, Alchemy 打开了一个前所未有的时代!

      

       让我们看看 Alchemy 到底做什么. ADOBE的说明文档上可以看到, Alchemy 是一个 运行在低层的虚拟机 (Low Level Virtual Machine) ,他运行在AVM2之下. 那你又要问了.既然有了一个虚拟AVM2,为什么还要一个LLVM?  其实, LLVM C/C++代码进行编译,并且生成RISC-LIKE指令的字节码, 存储在缓冲区之中, FLASH运行开始的时候, 实时翻译成机器相关的本地代码. 需要调用的时候是调用翻译之后的2进制本地代码.以此来提高整体速度.这就是LLVM的关键技术, 而运行时译 (Runtime-Compile) 这种技术有点像 .NET . 而这种LLVMAVM2的区别是, AVM2实时解释运行脚本代码,LLVM 预编译本地运行.可以这样认为 AVM2 JAVA虚拟机, LLVM .NET虚拟机.他们在构架上处于不同的层次,满足不同需求对速度的要求.

      

       当生成编译完成后,字节码需要保存在一个缓冲区之内. 由于在框架之内需要和AVM2兼容,所以这个缓冲区,将以 AVM2能识别的BYTEARRAY 形式保存在内存之中. 并且, alchemy自动生成一个 AS3的接口文件,以方便AS3程序进行调用. 值得注意的是, 所有C/C++编译之后的数据,都以 SWC 函数库的形式生成, 用户可以在自己的工程里 IMPORT.经过使用后发现, Alchemy 生成的SWC文件是比较大, C/C++源文件大的多.即使一个只有几十来行的纯C 功能,生成SWC后都会有100KB. 参考ADOBE的文档上说, 编译C/C++的代码,会将C/C++所需要的所有库,比如C标准库统统放到一个SWC里去,并且严格遵循POSIX标准. (可移植操作系统接口) 由于这种机制的存在, 我们甚至可以在C/C++里嵌入线程的支持, 来运行同步或者异步的功能. 从而弥补了FLASH是单线程这一不足! 这将是一件美妙的事情! 而本人认为,由于C/C++代码是公用一个C标准库的,所以只要SWC中的功能越多,那么从空间效率上就越是划算. 并且在目前的宽带之下,多个100KB问题不是太大.

   

    当然,安全问题,也是alchemy的重头戏, 我们知道, FLASH 对安全问题是有一套非常严格的措施的,比如访问本地资源后,就不能访问远程资源,访问这个域的资源后,就不能访问其他域的资源.如果你要访问,就要在另外一个域上安装一个沙箱(SecurityBox)文件,才能顺利访问. alchemyC/C++带入FLASH之中,C/C++ 是否能坏了这个规矩,让应用程序出轨呢? 答案当然是否定的,一旦这个程序被调用之后,C/C++程序被严格的运行在一LLVM,LLVM作为一个代理机构,向上,提供了对C/C++的平台支持,比如独立的内存空间,独立的堆栈空间,独立的线程管理机构,等等. 向下将2进制程序输送到 本机CPU进行执行. 所以安全问题上是非常到位的, 所以对C/C++来说,只要LLVM环境没有提供的,它将永远访问不到.

 

    Adobe已经对 alchemy 进行了比较深度的优化,并且我相信以后将继续下去.就从用户来说,由于有了alchemy 的出现,一些对速度要求较高的算法,都可以使用C/C++来代替. 由于接口上都是AS3的接口,所以移植现有的程序将会非常轻松.比如目前游戏开发中广泛使用的那个BitmapData.CopyPixel 如果用C纯代码进行改写,那么速度将提高几十倍之多.

 

    总结.  Alchemy 的出现,开启了一个全新的时代, 未来你将会发现网业上不再是简单画面,而是充满动态的不同的效果,给于用户全新的体验.随着LLVM提供的功能加多,比如将显卡硬件的功能作为一个抽象接口提供给C/C++调用,那么将来UNREAL3出现在网页上,你千万不要惊奇.甚至WOW出现在网页上,你也不要惊奇. 因为新时代的门已经打开!

分享 举报

发表评论 评论 (4 个评论)

  • 东写西读 2009-12-03 10:09
    读君一席言,省下买书钱!看到你的这篇文章,受益匪浅.并立即下了源文件自己尝试.E文不好,资料是连蒙带猜看的. 现在有一个疑问,不知可否赐教.你的文章中说到copyPixel方法用C改写. 我看里面的API,好像这种BitmapData这样的复杂类型是无法使用在里面的.那么似乎只有先把其读取出ByteArray再丢进来处理.但我试验分析这个getPixels()方法,好像每次调用都是产生了一个新的byteArray对象.而且效率消耗也不少.不知是否还有别的方案.望复,不胜感激.
  • HuangYZ 2009-12-03 18:24
    1 ALCHEMY的C语言接口里,可以访问所有对象和函数.具体可以参考 AS3_Call系列API.
    2 BitmapData的getPixels会生成一个选中区域的ByteArray对速度是非常有影响的. 所以在BitmapData的层面,只能使用它已经实现的方法比如copyPixels来进行调用,无法进一步加速.另外,还可以在C的层面重新实现一套API,使用ALCHEMY作为C和AS3的桥梁,并且可以将最终数据导入到BITMAPDATA作为输出.这样在一定程度上也可以实现加速,可以参考alchemy-linux-doom的做法实现.希望以上能帮助到你.
  • 东写西读 2009-12-04 14:13
    多谢你这么忙还抽时间回答我的问题.虽然我现在还不能完全理解:).实际上,我对C的了解仅从上周末看过你的文章后去图书馆借回的一本大学教程开始.我先消化消化.再次感谢!
  • fanjiawei5800 2010-04-17 18:12
    通过c/c++;哪是不是可以写本地文件了呢!
涂鸦板