與 Xcode 相比，用 Adobe AIR/Flex做 iOS 開發有哪些優勢和局限？

01-31

我沒有用XCode開發過具體項目，我的移動開發經驗主要是Android SDK、AIR for Android、AIR for iOS。

因為開發經驗的限制，我不能準確的說明XCode的優勢和劣勢，這裡只基於自己的Android開發經驗，以及AIR在iOS上的開發經驗來分析。

AIR的優勢

AIR的優勢其實就是Flash或者ActionScript語言的優勢。這些優勢大家已經在互聯網上看過許多了，我還是啰嗦一下：

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易用。相關比較可以看這個：Flex 用的 ActionScript 3.0 語法如此像 Java，為什麼不直接用 Java 語言描述呢？

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

AIR使用的ANE插件技術，讓你用OC開發一些本機插件，以API的方式來調用它，讓你能完成AIR本不能完成的事情。後面我會提到，其實這個也算劣勢。

AIR的劣勢

1. 大文件

AIR在iOS上並非採用的是虛擬機模式。它直接把ActionScript代碼編譯成二進位代碼，這與XCode變成成的二進位代碼沒有區別。整個AIR運行時也變成二進位代碼。這就導致了無論是什麼大小的程序，你總要在它的基礎上加上運行時的大小。

準確的編譯文件大小測試：

AIR3.5，AS項目，僅使用了graphics中的drawRect方法，3.8MB
AIR3.5，Flex4.6項目，沒有放任何組件，5.8MB

2. 不是BUG的BUG

由於上面描述的原因，你要把ActionScript當作OC來用，否則可能會碰到某些不是BUG的BUG。我在這篇文章中就講到了這樣一個BUG：BUG？AIR打包的iOS程序在整數比較上的問題；

這裡還有更多的AdobeBUG：AdobeBug | zrongs Blog

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真實設備上調試，這又碰到了上面說的「痛苦的調試」的情況。

不完善的小結

這種情況下可以使用AIR

你要開發的東西是遊戲（不要用AIR開發應用）
有一個Flash遊戲需要移植到iOS上（移植）
開發一個新遊戲，只有1個月時間（快速開發）
只會ActionScript和Flash（技術限制）
跨平台優先順序高於一切（跨平台）

關於Flex

Flex SDK包含swf編譯器、swf相關工具、MXML語言和一套名為Flex的框架，這套框架大部分是做界面的事情。但即使是Adobe說他們的Flex中包含的UI組件為移動設備做了多少優化，也千萬不要用它來開發移動設備上的程序，否則你會痛苦一被子。

Flex/Flex SDK/AIR的關係，可看這篇文章：Actionscript,AS3,MXML,Flex,Flex Builder,Flash Builder,Flash,AIR,Flash Player之關係

最近做flex的air項目感覺flex要做的很好還是很不容易的

優勢方面：

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這爛東西強多了。

優勢肯定最突出的就是跨平台了，同一份代碼程序可以運行在多個平台，flash/flex的跨平台性比html5還有個好的優勢是交互上不需要維護兩份代碼，adobe自動會將mouse的事件轉移到touch事件，對開發人員是透明的，當然做更複雜的手勢還是需要維護不同的代碼。android上flash支持的較好，ios上需要些特殊處理，畢竟幾乎沒有跨平台方案是完美的，無代價損失的。

語言相對來說也是一個優勢，AS語言對大部分人來說還是容易上手，不過OC在iOS5新引入的ARC機制其實開發人員只要留意下retain cycles問題，大部分情況下寫代碼已經和傳統GC的語言沒太大差異，而ARC的機制可以使性能比傳統MRC和GC方式都更高效。

IDE上XCode性能方面對語言編譯和可視化操作方面還是優於FB的，不過對於我喜歡用純代碼寫界面的人來說只要編譯語言性能過得去也就夠了。

綜合的說如果追求精品級我肯定選用OC+Cocoa，如果定位於快速發布到桌面和移動終端的話選擇flash/flex還是能滿足很多應用的需求，當然你少不了不同平台差異的折騰。

作為一個做過Flash-iOS的開發者，我可以負責任的說，性能比很多人想像中的要高

不應該說用Flex做遊戲，Flex框架對遊戲沒有一點幫助，相反如果使用Flex框架的MXML頁面代碼，會大大增加性能開銷。而Flex中大量的控制項都是為企業應用服務的，所以不適合做遊戲。

做遊戲應該使用純AS3開發（可以基於各種流行的遊戲框架）。做出來的遊戲在性能上與用Objective-c開發的遊戲沒有任何區別（當然這需要開發者在開發時注意各種會影響性能的問題）。

所以我個人覺得沒有任何劣勢，iOS上也有很多Flash開發的優秀遊戲，比如《機械迷城》(Machinarium)

最簡單也是最重要的一點就是不要新建Flex項目來做遊戲，而應該使用純AS3項目。這是保證整個遊戲可以有高性能的基礎。

10年，adobe把攤子鋪太大了，air被耽誤掉一年，去年地終於想通了，，開始主攻高變現度的遊戲開發，現在開始初見成效，明年預計會有大量頁游產品轉到手機上來。到拋開技術不談，現在的頁游轉手機的產品做的都算不上有心。以後的形態肯定不是現在這樣

-------------------------2014.05.19----------------------------

目前是Flash Builder4.7+AIR14+Starling1.5 開發中小型跨平台遊戲，性能上還是完全夠用的，當然周邊生態的發展，也還有待完善，比如Starling 製作UI框架，如何把flash的UI快速轉換成Starling的UI，還沒一個統一的完善的工具。。。

優勢：

1.跨平台，xcode開發的直接在ios上跑，AIR開發的可以在安卓和IOS上運行

2.開發流程上，速度比較快，雖然沒有深入研究過xcode的開發流程，但是用AIR肯定不會比xcode慢

3.對於那些flash頁游時代的同胞們來說，做移動開發的成本要低太多了，不需要重新學習oc

劣勢：

1.性能上稍差一些，但是只要不是大型的移動rpg遊戲，AIR在開發中小型遊戲上完全hold的住，這和項目類型也有關係

2.如果只是做ios開發，在開發流程和appstore銜接上，肯定是xcode更方便一些，不過影響不大

3.AIR開發移動方面，發展時間短，Starling也就是去年開始才真正能用，所以有些配套工具及周邊生態的發展，還需要進一步完善，有不少公司都有自己的工具，但是卻沒有一個比較統一的解決方案。

------------------------------------------早期

現在最新版本 Flash Builder 4.7 + AIR 3.8 + Starling 1.4等等開發移動遊戲已經很方便了性能也很不錯了，雖然不能和原生的比，但是好好優化，完全能滿足需要的，嚴重懷疑那些整天說Flash不行的人，要麼是觀念還停留在幾年前，要麼就是技術不行！

性能問題吧如果用flex做ios遊戲的話個人感覺性能可能不怎樣但如果用flex做的話可以同時發布android 和ios平台而且開發成本低只要是普通電腦就OK 但如果是xcode的話必須得蘋果機吧

Air 3.2 移動版應該說在移動平台不存在性能問題了。直接可用GPU渲染。直接用Stage 3D做開發。。

優勢，開發效率高，跨平台和代碼移植方便，另外，FP在桌面端的成功，在webgame的成功，可以預見將來用Air開發的移動項目會越來越多。

劣勢，目前用FB調試還不太方便，不過下一個版本更新，馬上就能直接通過設備調試了，而不用打包那麼久，據說就在Air3.3的更新計劃裡面，so...此劣勢即將消失。

instapaper

主要是性能（耗能）問題。做遊戲非常適合，成本低。

作為遊戲開發程序的性能一定要過關(對於 cpu gpu,以及內存和顯存的使用調度),所以第三方干框架也好自己寫也好都要經驗老道。其實只要是遊戲，顯示規模一上來，性能要求就是必須的。as3在複雜計算上性能不行，所以可以用flascc 來處理複雜計算, 但是flascc在使用的時候也不是亂用，否則其和as3交互的過程也會耗性能。說的gpu,那就要很多東西盡量放在gpu計算,一個drawTri批次,盡量處理比較多的東西，盡量放在頂點shader計算，這樣的話整體的流暢度就會提上來。