与Xcode 相比，用 Adobe AIRFlex做 iOS 开发有哪些优势和局限

优势 方面：

1 跨平台的代码上， 在电脑，android 手机和android平板 ， iphone和ipad 逻辑代码都是一套，开发效率非常高。而且as3 程序员成本也比一般的低一些

2 UI设计和开发流程上，时间成本也能节省很多，从psd设计完后，然后经过flash重新设计UI界面组件，如果设计人薯裂卖员同时会ps和flash效率还是很高的， 然后由开发人员进行编码

3 flex框架的高效上，flex目前4.6 提供的常用界面还是基本够用了，尤其针对android提供了和ios一样的用户源锋UI，在不同设备和分辨率 DPI上，通过不同的state和微调界面布局（虽然很繁琐）但可视化 *** 作还是比多个平台容易多了 ，

4 性能上其实非常不错了，如果不是3D应用，一般都够用了数逗，基本能达到原生80% 到100%， 比html5强多了（flex框架本身较慢，如果不用flex框架纯as3性能很高，做一些游戏很适合）

劣势 方面：

1 和IOS好的原生程序相比还有一定UI和性能上的差距，主要iOS自带的UI很好，但flex很难用到。

2 硬件新特性 虽然有ANE但用起来非常麻烦，虽然比html5强多了，但iOS上的icloud和gamecente iap，这些东西开发效率很低。 而且android4.0上也有很多新功能例如nfc相关，flex还是没办法直接使用。

3 调试也没有原生的方便，只能生成ipa后安装到设备上调，flex上UI的小的bug很多也很难解决。

总结

如果专心一个平台 ios 还是原生的好，原生开发效率也高。

如果是跨平台android和ios 其实还是不错的，效率很高，开发出来的东西也不错的，肯定比html5这烂东西强多了。

以上转自网络

共同点：AIR和RIA（即Flex）都是富Internet应用程序，都是跨平台的。不同点：AIR是桌面应用，而RIA是web应用，也可以说AIR包好仔括RIA。一个AIR程序可以使用如下一种或多种组合技术构建：--Flash / Flex / ActionScript--HTML / JavaScript / CSS / Ajax--PDF 可嵌入任何应用程序中而作为结果，AIR 应用程序可以是：--基于Flash 或 Flex：应用程序根内容（理解为容器）为Flash/Flex (SWF)--基于Flash 或 Flex 的友做汪HTML 或 PDF。应用程序的根内容为基于Flash/Flex (SWF) 的HTML(HTML, JS, CSS) 或 PDF--基于HTML，应用程序根内容为HTML, JS, CSS--基于HTML的Flash/Flex或PDF，应用程序根内容胡含为基于HTML 的Flash/Flex (SWF) 或 PDF

优势：

1.优秀的2D性能和渲染机制

网络上关于Flash性能底下的言论是绝对错误的。其实Flash的性能相当高，而且大多数情况下都比Javascript高。ActionScript

经过如此长时间的专制发展，形成了一套易于使用的显示列表（DisplayObject）机制，加上灵活的MovieClip和Sprite等等对象，在

制作2D动画方面，是目前互联网技术中最好的选择。即使是你认为显示列表的性能底下（在显示对象超过1K的情况下确实低下），你也神塌完全可以使用

BitmapData这个高性能的引擎做位图渲染。

2. 蓬勃发展的3D技术

Stage3D比OpenGL要更容易掌握。使用各种开源、付费的引擎，程序员可能不需要了解3D工作机制，就能制作3D动画（或者游戏）。当然，目前的Stage3D的驱动支持还有待完善，但Adobe目前很努力（不努力就挂掉了），驱动情况会慢慢解决掉。

更让人激动的是Starling这类使用Stage3D进行2D渲染的引擎。完全为游戏而生，把Flash的2D性能又提高了一个数量级。

3. 比较完善的框架和社区

Flash社区经过多年发展，已经非常完善，有很多的优秀的框架、空灶工具、引擎、调试斗瞎扮器、甚至编译器可以使用。当然，OC社区或许更完善，所以这个有优势并不明显。

4. 简单易用的语言

ActionScript是简化版的JAVA。我无法把ActionScript与OC对比，但ActionScript绝对比JAVA易用。相关比较可

以看这个：http://www.zhihu.com/question/19762068/answer/15544195

5. 使用ANE可以完成所有OC能做的事情

AIR使用的ANE插件技术，让你用OC开发一些本机插件，以API的方式来调用它，让你能完成AIR本不能完成的事情。后面我会提到，其实这个也算劣势。

AIR的劣势:

1. 大文件

AIR在iOS上并非采用的是虚拟机模式。它直接把ActionScript代码编译成二进制代码，这与XCode变成成的二进制代码没有区别。整个AIR运行时也变成二进制代码。这就导致了无论是什么大小的程序，你总要在它的基础上加上运行时的大小。——10MB+。

2012-11-12 17:29更新：

准确的编译文件大小测试：

AIR3.5，AS项目，使用了graphics中的drawRect方法，3.8MB

AIR3.5，Flex4.6项目，没有放任何组件，5.8MB

所以，上面的10MB+说法不准确。

2. 不是BUG的BUG

由于上面描述的原因，你要把ActionScript当作OC来用，否则可能会碰到某些不是BUG的BUG。我在这篇文章中就讲到了这样一个BUG：http://zengrong.net/post/1654.htm

3. 痛苦的调试

FlashBuilder并不是面向iOS开发的，所以它的调试过程复杂且痛苦。在FlashBuilder

4.6上，我必须利用iTunes这个垃圾软件把打包好的Debug版本的ipa文件安装到iOS设备上，然后在FlashBuider上启动调试进程。

Debug版本的ipa运行十分缓慢（对，是十分），甚至因为它的缓慢，很多BUG都无法发生。

当然，这种情况在AIR 3.4出现之后有所好转。AIR

3.4不需要iTunes就能把ipa部署到iOS设备中进行调试。但是，目前的FlashBuilder4.6还不支持这种方式，你要使用AIR3.4

的新的直接部署调试功能，就必须使用命令行，然后调用fdb来调试。

AIR 3.5支持在Release版本（非Debug版本）中输出调试堆栈，这能让我们用正常的速度来调试ipa，但这其实是让我们更麻烦了。

4. 痛苦的编译

你能忍受一次编译需要20分钟么？如果你的程序很复杂，那么这个时间还会延长。你能忍受在发布程序之前，突然发现一个小bug，然后等待20分钟编译调试么？注意，某些bug，只能在编译之后才会出现。

5.痛苦的ANE调试

和上面的调试不同，ANE的调试更加痛苦可不可捉摸。很多情况下，ANE的错误是直接FC，没有报错代码，没有消息，解决问题只能靠猜，你能猜中么？

更痛苦的是，大部分情况下，使用AIR的程序员都在Windows下工作，使用AIR自带的ADL在Windows系统上调试，这种调试方法是不支持ANE的，你要测试ANE，必须打包后在iOS真实设备上调试，这又碰到了上面说的“痛苦的调试”的情况。

---