AIR功能扩展的分享

之前的公司业务，和现在的项目研究，所以对这块用的还算比较多，所以总结下：

业务运算量大，对处理速度和效率有要求，所以在AIR自身处理单线程，CPU运算能力不足的情况下，借力第三方，自然而然就引入到了今天的话题。

1.flasCC

百度百科的简介地址

FlasCC功能介绍

前身是“炼金术士”，这个是第二版了，adobe官方貌似也没有继续跟进，目前是1.

编辑
将强大、熟悉、高性能的C/C++与覆盖全球的互联网相结合；
通过Flash C++编译器(FlasCC)你可以把你的原生C/C++程序(控制台和PC端)通过浏览器覆盖数十亿用户，而且不需要安装；
使令人惊叹的客户端游戏，获得数量巨大的互联网新用户。

优点：正如上面所说，可以直接编译C++平台的高性能代码，为flash所用，注意这里的flash指的不仅仅是AIR平台，也包括浏览器中的swf，所以在页游上用的比较多。

缺点：话说直接编译C++先有代码，但是经常在使用flasCC打包过程中，编译失败的问题，主要就是C语言的各种依赖库不全，反正我是被这个坑过好久，但是编译通过后，就是爽爆了的节奏。

大家有兴趣深入了解的话，可以参考：官方贡献的开源版本 :crossbridge

2.ANE

ANE，即是Adobe Air Native Extension的缩写，是指AdobeAir的本地扩展。它的作用是提供给基于AdobeAir平台上层开发的as3脚本调用所在设备功能的接口及方法。

官方的解释：使用 Adobe AIR 的本机扩展

运行的一个流程图：

在以下情况下，本机扩展非常有用：

• 本机代码实现提供对特定于平台的功能的访问。这些特定于平台的功能在内置 ActionScript 类中不可用，也无法在特定于应用程序的 ActionScript 类中实现。本机代码实现可以提供此类功能，因为它可以访问特定于设备的硬件和软件。

• 本机代码实现有时可能比仅使用 ActionScript 的实现速度更快。

• 本机代码实现可以提供对旧本机代码的 ActionScript 访问。

优点：正如上述

缺点：这是针对AIR的本地扩展，开发的话，作为扩展功能，类似一个中介载体，中间扩展的接口，需要自己去封装，利用封装好的swc类库，再和扩展的dll动态库，去构建生成ane文件给AIR去扩展使用。个人觉得这一过程，不算复杂，如果有打包工具一键生成就完美了。

下面贴一张这个框架的示意图：

3.NativeProcess

对AIR熟悉的朋友，可能接触过这个类，在一些项目中可能早已接触过这部分，为什么提到了上述2大功能后，还要提到这个呢？自然是有他的道理。下面补充

adobe的解释：

ActionScript 3.0 提供了一个 NativeProcess 类。此类允许 AIR 应用程序在主机操作系统上执行本机进程。此功能与本机扩展的功能类似，后者提供对特定于平台的功能和库的访问。

在决定使用 NativeProcess 类还是使用本机扩展时，请考虑以下因素：

• 只有 extendedDesktop AIR 配置文件支持 NativeProcess 类。因此，对于使用 AIR 配置文件mobileDevice 和extendedMobileDevice 的应用程序，本机扩展是唯一选择。

• 本机扩展开发人员通常为各种平台提供本机实现，但其提供的 ActionScript API 在各平台上通常相同。使用 NativeProcess 类时，不同平台上启动本机进程的 ActionScript 代码可能会不同。

• NativeProcess 类启动一个单独的进程，而本机扩展与 AIR 应用程序运行在同一进程中。因此，如果担心代码崩溃，则使用 NativeProcess 类比较安全。不过，单独的进程意味着可能需要实现进程间的通信处理。

看到这里，大家应该知道为啥还要给他留一席之地了，前面1，2点的话，只是针对ANE来说，ANE搞不定的，可以用flasCC ,至于第三点，就是它的优势所在，自己一个独立的进程，和AIR环境是独立开的，所以在大数据运算的时候，不会影响到flash的运行效率和内存泄漏什么的。

优点：就是上述总结的，需要完全独立开的话，用这种方式比较合适，尤其是做多项目合作的时候，可以用这个快速开发调试程序

缺点：就是依赖一个独立的exe文件，这个对有些项目来说有些限制，以前做项目碰到过，被第三方安全软件给屏蔽掉，所以用这个方法的话，需要多做点测试。还有一点就是上述的第三点，二者数据通信相对来说麻烦，所以用独立exe这个方法的话，建议做相对对立，纯干活的事。这个属于项目规划的问题了，算我多嘴了 ：）