給iOS開發AIR原生擴充套件的20條建議

來源：james李鵬

譯者注：這篇文章寫得非常好，基本包括了目前ANE開發需要的所有注意事項，感謝作者Richard Lord。文中我會以作者的口吻來翻譯。

過去的三個月中我為iOS平臺建立了三個AIR Native Extension的擴充套件(在Github中可以找到程式碼),這些擴充套件全部被用在我們的遊戲Stick Cricket Super Sixes中，同時我們也總結了很多經驗。雖然我記得並不全面，但下面這幾條建議，可以給很多打算開發ANE專案的開發者助以一臂之力。

 

文件

1. 開始

這兩篇文件對初學者很有幫助，如果你不知道該如何起步，可以從閱讀這兩篇文件開始。在網路上也有很多好的文章，只要Google一下就行了。

• Extending Adobe Air

• 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. 在專案中使用巨集

在定義介面的時候，你可能需要重複輸入很多遍類似這樣的程式碼來定義函式

我建議使用巨集定義來代替所有這些重複的定義方式。你可以在這個原始檔中找到巨集定義的例子。（感謝David Wagner的提供）

11. 把“Enable linking with shared libraries”設定成yes

網路上很多關於在XCode裡如何設定這個選項的討論，有人說”no”有人說”yes”。基本上，說設定成”yes”的說明你的應用在釋出的時候需要連結 外部類庫，這個選項就是這個意思。但是這也意味著你在釋出含有此擴充套件的AIR應用時，你必須要告訴編譯器你的iOS SDK在哪裡，這樣你才可以使用那些類庫。具體看下面第18條。

如果你得到這樣一個編譯錯誤

則你可能要麼忘了開啟這個選項，要麼沒有給編譯器指明SDK的位置。

12. 小心使用執行緒

你的原生擴充套件不能在除主執行緒之外其他執行緒建立Actionscript物件，而且必須要從AIR端呼叫。這樣會導致在Objective-c中使用塊的時 候問題重重。然而，你可以通過一種途徑來達到這個目的，那就是使用Actionscript ExtensionContext事件派發機制。方法如下：

1，在一個執行緒中，建立一個原生物件並儲存資料。

2，派發事件給ExtensionContext，為下一步傳送必要的細節。

3，在事件響應的方法中，呼叫原生介面來獲得這個原生物件。

4，在這個被呼叫的原生方法裡，利用該原生物件建立一個Actionscript物件。

13. 建立原生view物件

AIR應用是在一個標準的window物件裡執行的，你可以通過下面的方法獲得這個window物件：

得到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

在編譯應用的時候你可能會遇到多處下面這樣的警告：

這些只是警告，不用去理它。4位對齊只是一個優化，並非是必須的。

 

最後的最後

20. 讓你的原生擴充套件更加通用

當完成了擴充套件的開發，你可以有三個選擇：

1， 只讓自己使用。

2， 向其他開發者開源。

3， 賣給其他開發者。

你可以問問自己，是什麼讓你的應用獨一無二。如果原因不是你的原生擴充套件（實際上很少是因為這個），那麼請選擇第二個或者第三個，如果每個人都這麼做，你也會從中受益。

另外，讓更多人從你的擴充套件中受益，可以讓Adobe AIR這項技術在移動開發領域裡更加強大和穩定。這會鼓勵其他的開發者去使用AIR，也會鼓勵Adobe繼續開發和改進它。

在Stick Sports我們選擇了第二項，因為比起花時間來運營我們的原生擴充套件，我們更願意花時間來運營和支援我們的遊戲。