Adobe Alchemy

FLASH 从一个简单的动画客户端,一跃升级成一个未来富媒体应用程序的平台. 从这一系列战略步骤,不难看出ADOBE想成为WEB乃至桌面开发霸主的野心! 微软要小心了.

这里介绍的是Adobe Alchemy的入门知识。首先 AS3_Val 是Alchemy用来表示AS3中数据类型的 所有对Actionscript可见的方法，其返回值变量都需要被表示AS3_Val

main()函数中的第一行的作用是将用在Actionscript中的方法先声明为AS3_Function实例。
下一步（代码14行）是创建一个AS3_Object，它将承载所有声明为AS3_Function的方法。在这个例子里，就只有cMethod这一个方法。
通过调用AS3_Release来释放不需要的AS3方法。

最后，通知AS3虚拟机库已经被AS3_LibInit初始化好了，将承载了所有的As3方法引用的对象result传递给Actionscript代码。注意，这一步应该在最后调用。

代码编写好之后，我们就可以开始编译了。

打开cygwin(编者注：cygwin是一个可以让你在windows上执行Linux下命令的工具，从某种角度说，可以认为是一种虚拟的Linux环境。其执行效率要比在Linux上执行速度要慢。)

通过命令

alc-on

打开Alchemy,然后运行命令

gcc helloWorld.c -O3 -Wall -swc -o helloworld.swc

这样，就可以生成一个SWC库文件。

到这里，大家看到，我们已经生成了一个可以供Flex或者FlashCS4调用的SWC库文件。

使用Adobe Alchemy主要是使用C,C++源码编译成SWC的Flash 库文件。 在FlashCS4或者Flex中使用这些库文件。
首先，我们需要设置好Adobe Alchemy,你可以在Adobe Lab 上面找到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 . 而这种LLVM和AVM2的区别是, AVM2实时解释运行脚本代码,LLVM 预编译本地运行.可以这样认为 AVM2 是 JAVA虚拟机, LLVM是 .NET虚拟机.他们在构架上处于不同的层次,满足不同需求对速度的要求.
        
        当生成编译完成后,字节码需要保存在一个缓冲区之内. 由于在框架之内需要和AVM2兼容,所以这个缓冲区,将以 AVM2能识别的BYTEARRAY 形式保存在内存之中. 即使使用反编译工具,反编译这个SWF文件,也看不到任何代码. 并且, alchemy自动生成一个 AS3的接口文件,以方便AS3程序进行调用. 值得注意的是, 所有C/C++编译之后的数据,都以 SWC 函数库的形式生成, 用户可以在自己的工程里 IMPORT.经过使用后发现,由 Alchemy 生成的SWC文件是比较大, 比 C/C++源文件大的多.即使一个只有几十来行的纯C 功能,生成SWC后都会有100多KB. 参考ADOBE的文档上说, 编译C/C++的代码,会将C/C++所需要的所有库,比如C标准库 统统放到一个SWC里去,并且严格遵循POSIX标准. (可移植操作系统接口) 由于这种机制的存在, 我们甚至可以在C/C++里嵌入线程的支持, 来运行同步或者异步的功能. 从而弥补了FLASH是单线程这一不足! 这将是一件美妙的事情! 而本人认为,由于C/C++代码是公用一个C标准库的,所以只要SWC中的功能越多,那么从空间效率上就越是划算. 并且在目前的宽带之下,多个100来KB问题不是太大.
        
        当然,安全问题,也是alchemy的重头戏, 我们知道, FLASH 对安全问题是有一套非常严格的措施的,比如访问本地资源后,就不能访问远程资源,访问这个域的资源后,就不能访问其他域的资源.如果你要访问,就要在另外一个域上安装一个沙箱(SecurityBox)文件,才能顺利访问. 而alchemy将C/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出现在网页上,你也不要惊奇. 因为新时代的门已经打开!