翻譯一篇文章，20條開發AIR Native Extension的建議
原文作者 Richard Lord
英文原文：20-tips-for-creating-air-native-extensions-for-ios
譯者：James Li
過去的三個月中我為 iOS 平臺創建了三個 AIR Native Extension 的擴展(在 Github 中可以找到代碼)，這些擴展全部被用在我們的游戲 Stick Cricket Super Sixes 中，同時我們也總結了很多經驗。雖然我記得并不全面，但下面這幾條建議，可以給很多打算開發 ANE 項目的開發者助以一臂之力。
————-
文檔
————-
1. 開始
這兩篇文檔對初學者很有幫助，如果你不知道該如何起步，可以從閱讀這兩篇文檔開始。在網絡上也有很多好的文章，只要 Google 一下就行了。
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 的位置。
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
在編譯應用的時候你可能會遇到多處下面這樣的警告：
ld: warning: ARM function not 4-byte aligned
這些只是警告，不用去理它。4位對齊只是一個優化，并非是必須的。
—————–
最后的最后
—————–
20. 讓你的原生擴展更加通用
當完成了擴展的開發，你可以有三個選擇：
1， 只讓自己使用。
2， 向其他開發者開源。
3， 賣給其他開發者。
你可以問問自己，是什么讓你的應用獨一無二。如果原因不是你的原生擴展（實際上很少是因為這個），那么請選擇第二個或者第三個，如果每個人都這么做，你也會從中受益。
另外，讓更多人從你的擴展中受益，可以讓 Adobe AIR 這項技術在移動開發領域里更加強大和穩定。這會鼓勵其他的開發者去使用 AIR，也會鼓勵 Adobe 繼續開發和改進它。
在 Stick Sports 我們選擇了第二項，因為比起花時間來運營我們的原生擴展，我們更愿意花時間來運營和支持我們的游戲。