給iOS開發AIR Native擴展的20條建議
過去的三個月中我為iOS平臺創建了三個AIR Native Extension的擴展(在Github中可以找到代碼),這些擴展全部被用在我們的游戲Stick Cricket Super Sixes中，同時我們也總結了很多經驗。雖然我記得并不全面，但下面這幾條建議，可以給很多打算開發ANE項目的開發者助以一臂之力。
文檔
1. 開始
這兩篇文檔對初學者很有幫助，如果你不知道該如何起步，可以從閱讀這兩篇文檔開始。在網絡上也有很多好的文章，只要Google一下就行了。
• AIR Native Extension Example: iBattery for iOS
2. 閱讀Adobe官方文檔
大部分的開發所需的資料在這篇 Adobe’s documentation 中都可以找得到。
編寫Actionscript代碼
3. 認真編寫 Actionscript API
確保你的Actionscript接口是你的項目中想要的。不要往Actionscript里被動地照搬iOS接口，要像編寫常規Actioscript類那樣定義你的接口。
記住，后期如果修改原生代碼只會影響到ANE擴展本身，但如果修改Actionscript接口則會影響到所有使用該ANE的項目。所以在前期要盡可能完善地定義你的Actionscript接口。
4. 盡可能在Actionscript一端做錯誤檢查
為了避免錯誤的發生，你需要在調用ANE方法的時候做參數合法性的檢查，你可以等到調用原生代碼時再做檢查，但如果提前在調用Actionscript接 口的時候就做檢查會更簡單一些。如果你能保證每次調用原生代碼時都不會出錯，比如參數個數和參數類型，那么完全可以只在Actionscript里做判 斷。
當然，如果你習慣于在C里寫錯誤檢查，當然可以。我個人更喜歡在Actionscript里做這件事情。
5. 創建一個原生類的替身
即使你打算僅為iOS寫擴展，我也建議你創建一個原生類庫的替身。用純Actionscript代碼創建這個替身，這樣它就可以為所有的平臺所用。在這個 替身里按照iOS原生接口定義一套純Actionscript接口方法，即使在調用的時候拋異?；蛘叻祷乜罩狄矝]有關系，至少它是合法的 Actionscript調用，而且可以在其他平臺比如桌面上測試使用。
如果不用這樣一個替身，你就每次只能在iOS設備上做測試，這樣會讓開發測試工作極為痛苦。相反，如果使用這個替身，你可以在桌面上快速發布應用來測試那些與設備不相關的功能和模塊。
編寫原生代碼
6. 使用Objective-C來實現蘋果的程序接口
你并不是必須要使用Objective-C，但是如果想要實現蘋果的程序接口，用Objective-C會很方便。否則你需要用C或者C++。
7. 把為AIR編寫的接口方法寫在.m文件里
AIR和原生代碼之間的接口是用C寫的，所以你的原生代碼需要引用一個包含C代碼的文件來實現這些接口。如果你把接口放在.c文件中，那么你不能使用任何 Objective-C功能(比如你無法用objective-c的語法去調用objective-c接口)，但是如果你把接口放在了.m文件就可以。所 以用.m文件會更方便一些。
8. 包含AIR原生接口的.m文件不需要.h頭文件
但是你需要在XCode項目設置中的警告選項里把”missing function prototypes”這一項給關掉。
9. 為initializer和finalizer方法起一個獨一無二的名字
很多ANE的例子都使用了”extInitializer”和”extFinalizer”來給擴展的入口和出口函數命名。但如果在項目中使用多個ANE擴展，這樣會導致命名沖突。所以給入口和出口函數起一個獨一無二的名字。
10. 在項目中使用宏
在定義接口的時候，你可能需要重復輸入很多遍類似這樣的代碼來定義函數
- FREObject someFunction(FREContext context, void* functionData, uint32_t argc, FREObject argv[])
我建議使用宏定義來代替所有這些重復的定義方式。你可以在這個源文件中找到宏定義的例子。(感謝David Wagner的提供)
11. 把“Enable linking with shared libraries”設置成yes
網絡上很多關于在XCode里如何設置這個選項的討論，有人說”no”有人說”yes”?；旧?，說設置成”yes”的說明你的應用在發布的時候需要鏈接 外部類庫，這個選項就是這個意思。但是這也意味著你在發布含有此擴展的AIR應用時，你必須要告訴編譯器你的iOS SDK在哪里，這樣你才可以使用那些類庫。具體看下面第18條。
如果你得到這樣一個編譯錯誤
- ld warning: unexpected srelocation type 9
則你可能要么忘了開啟這個選項，要么沒有給編譯器指明SDK的位置。
#p#
12. 小心使用線程
你的原生擴展不能在除主線程之外其他線程創建Actionscript對象，而且必須要從AIR端調用。這樣會導致在Objective-c中使用塊的時 候問題重重。然而，你可以通過一種途徑來達到這個目的，那就是使用Actionscript ExtensionContext事件派發機制。方法如下：
1，在一個線程中，創建一個原生對象并儲存數據。
2，派發事件給ExtensionContext，為下一步傳送必要的細節。
3，在事件響應的方法中，調用原生接口來獲得這個原生對象。
4，在這個被調用的原生方法里，利用該原生對象創建一個Actionscript對象。
13. 創建原生view對象
AIR應用是在一個標準的window對象里運行的，你可以通過下面的方法獲得這個window對象：
- [UIApplication sharedApplication].keyWindow
得到window對象后你可以給它添加subviews來顯示原生的view對象。
編譯擴展
14. 批處理編譯和測試
當我開發Game Center擴展的時候我創建了一個簡單的AIR應用來測試ANE。
我創建了一個ANT腳本來編譯整個擴展(編譯原生C類，編譯AS3類，編譯AS3原生替身類，并把它們全部打包入ANE里)。
結果就是，在Eclipse里點擊一次，我就可以編譯和測試整個項目，下一步就是拖入設備直接測試應用了(XCode里的Organiser可以很方便的 實現這步)。總共花了差不多10秒鐘的時間來打包，雖然仍然比理想的多了9秒，但已經比我見過的大多數工作流都要好很多。
也許用Flash Builder有更好的方法(因為我用的是FDT)，而且你當然不必使用ANT，任何編譯工具都可以達到這個效果。但是你需要盡可能的使用流水線的方式來編譯和測試這個流程。如果你需要這些代碼，可以在Game Center extension project里找到。
15. 使用第三方類庫
如果你正在擴展里使用一個第三方類庫(比如在Flurry extension里的Flurry統計類庫)，你需要在編譯的時候使用“-platform iPhone-ARM” 參數來引用這個類庫。
16. 你可能需要使用platform.xml
如果你會用到任何一個但不是大多數的iOS SDK類庫，你需要創建一個platform.xml文件來指明你需要使用的類庫，以及應用所需要的最小iOS版本。我為每一個擴展都創建了一個platform.xml文件，因為在使用AIR3.1編譯時會出現一個有關未知最小iOS版本的警告，使用這個文件會隱藏這個警告。
打包應用
17. 如果IDE編譯的時候并不依賴原生擴展，則你的應用需要引用擴展替身swc來保證運行成功
這個SWC里包括了一整套與原生擴展相同的Actionscript接口，所以你可以使用它進行編譯，并且在開發的時候用來測試。當然，不依賴原生擴展的IDE不會正確地發布移動應用，但你可以用我介紹過的那種批處理編譯腳本來實現最終的正常編譯。
18. 發布AIR應用的時候，指明需要引用的iOS SDK地址
默認情況下，AIR編譯器會使用iOS SDK 4.0來編譯應用。如果你使用了這個版本里所不包括的新功能，則編譯的時候就會出錯。這時需要指明iOS SDK的新版本位置，從而實現對新功能類庫的引用。在這篇文章中查看詳細信息。在Flash Builder里，在配置原生擴展的某個面板中可以進行這個設置，但如果你使用命令行來編譯，可以使用-platformsdk標簽來指定iOS SDK的路徑。
19. ld: warning: ARM function not 4-byte aligned
在編譯應用的時候你可能會遇到多處下面這樣的警告：
1ld: warning: ARM function not 4-byte aligned
這些只是警告，不用去理它。4位對齊只是一個優化，并非是必須的。
最后的最后
20. 讓你的原生擴展更加通用
當完成了擴展的開發，你可以有三個選擇：
1， 只讓自己使用。
2， 向其他開發者開源。
3， 賣給其他開發者。
你可以問問自己，是什么讓你的應用獨一無二。如果原因不是你的原生擴展(實際上很少是因為這個)，那么請選擇第二個或者第三個，如果每個人都這么做，你也會從中受益。
另外，讓更多人從你的擴展中受益，可以讓Adobe AIR這項技術在移動開發領域里更加強大和穩定。這會鼓勵其他的開發者去使用AIR，也會鼓勵Adobe繼續開發和改進它。
在Stick Sports我們選擇了第二項，因為比起花時間來運營我們的原生擴展，我們更愿意花時間來運營和支持我們的游戲。
【編輯推薦】
