最近本身趁業餘時間作的flash小遊戲已經開發得差很少了,準備再完善下ui及數值後,投放到國外flash遊戲站。期間也萌生想法,想把遊戲拓展到手機平臺。這兩天嘗試了下,除去要接入ane接口的工做,小遊戲自己不用作任何改動就能夠遷移到android和ios手機平臺。只是在手機上,遊戲的掉幀狀況很是嚴重,遠達不到pc上的體驗效果。看來作flash移動遊戲,不用starling框架是不行的。打算這幾天學習下starling,對項目進行改造。android
基於Starling移動項目開發準備工做ios
轉自: Starling中文站 - Starling移動開發教程git
做者: 郭少瑞(NeoGuo)github
如今移動開發可謂熱火朝天,若是您是一位Flash開發者,或許您所在的團隊,已經開始基於Flash內容的移動應用開發了。因爲Adobe已經提供了AIR打包技術,來幫咱們把同一份程序打包到iOS,Android,BlackBerry等系統或設備,這在很大程度上下降了跨平臺的研發成本,也爲傳統的Flash研發團隊進入移動開發領域提供了很好的機會。可是有機遇,也有麻煩。其中一個比較大的麻煩就是性能問題。如今的PC平臺都有很強大的計算能力,咱們基於Flash的應用開發,通常不太關心性能問題,但進入移動設備,咱們會發現本身面臨的硬件環境至關苛刻(固然如今的智能機硬件配置已經大大改善,讓咱們開發上的限制已經寬鬆了許多)。好比咱們基於傳統思路,用Flash電影剪輯等方式作了一個應用,在PC上預覽沒有問題,但在移動設備上卻不能很好的執行(出現丟幀現象,這是顯示渲染的壓力太大所致)。爲何會出現這種狀況?由於Flash中傳統的顯示列表機制(Stage,Sprite,MovieClip),都是依賴CPU的,也就是說渲染壓力基本都在CPU上。在移動設備上CPU處理能力低下的狀況下,出現丟幀的現象也就不足爲奇了。編程
能改善這種狀況的一種方式就是利用GPU加速,也就是利用顯卡在圖形方面的計算能力,減輕CPU在屏幕渲染上的壓力。但悲劇的是,Adobe在「爲傳統的顯示列表機制提供GPU加速」這個工做上進展緩慢,以前曾推出了在配置文件中增長<renderMode>GPU</renderMode>的設置來開啓硬件加速,但不要激動,這個設置對於PC無效,對於移動設備也是限制多多,並且並不穩定。筆者曾經在一個項目中分別設置CPU和GPU模式來測試程序(iPad 1),發現CPU模式反而運行效率更好且穩定。出現這樣的狀況至關讓人沮喪,Adobe的技術團隊也專門寫過一篇Blog來解釋其中的難度之大:Flash在以前的架構設計上徹底是基於於CPU的(一般咱們稱之爲軟解),也就是說傳統的2D顯示列表就是爲CPU渲染設計的,這對於跨平臺來講很是有效,但如今要遷移到GPU上就很是麻煩了。網絡
這對咱們來講,就意味着若是咱們以前有一個複雜的,基於Flash傳統顯示列表的應用或遊戲,想要原封不動的移植到智能設備上,並且還要保證和PC類似的執行效率,仍是挺困難的。固然Flash盛行了這麼多年,開發者也積累了不少行之有效的經驗,來提高運行效率(好比基於Bitmap的動畫實現,以空間換時間),這些經驗能夠幫助咱們在必定程度上改善現有應用的執行效率。但可能還不夠,移動設備的特性決定咱們須要儘量的將優化作到極致。要作到這一點,咱們必須更有效的利用GPU。固然Adobe也意識到GPU對於提高渲染性能的重要性,因此推出了Stage3D。Stage3D雖然也作了抽象(解決平臺無關性),但無疑是和硬件更接近的,基於Stage3D咱們能夠開發和桌面遊戲相媲美的網絡3D遊戲。固然由於Stage3D是偏底層的API,學習和掌握的成本也高一些。關於Stage3D本文不作過多介紹,若是您還不瞭解Stage3D,建議參考下面的文章:架構
固然正如其名,Stage3D是面向3D應用的API。若是咱們只是想作2D應用,是否是就不能使用Stage3D了呢?固然也是能夠的,但編程和實現思路將和咱們以前的Flash經驗大不相同,咱們須要徹底站在顯卡的角度去編寫實現過程,這無疑將是枯燥並且困難的,並且有很高的學習成本。所幸的是,一些具有探索和分享精神的技術達人,在Stage3D的基礎上作了進一步的封裝,以更接近傳統Flash 2D顯示對象的機制,來提供對傳統Flash開發者更加友好的技術框架。這樣的框架已經存在一些,比較知名的有Starling,ND2D等等。其中Starling獲得Adobe官方的推薦,其接口也和Flash原有顯示對象很是接近,因此筆者也選擇了Starling來進行項目實踐,並和你們分享這個過程當中的經驗。app
Starling是由Gamua團隊推出和維護的一個基於Stage3D的2D框架。這是一個位於奧地利的團隊,有兩位核心開發成員:Daniel Sperl和Holger Weissb ck。他們擅長Objective C和ActionScript,也正是由於這樣,他們實際上有兩個開源框架:Starling Framework和Sparrow Framework,兩個框架的設計思想是同樣的,只是前者面向Flash,後者面向iOS。框架
工欲善其事,必先利其器,讓咱們先把「武器」準備好。這裏的武器是指咱們的IDE,考慮到大多數Flash開發者應該都是基於Flash Builder進行編程的(Flash Professional實在不適合編程,其它第三方IDE好比Flash Develop,固然也很優秀,但爲了文章簡練起見,再也不涉及其它IDE了,若是您使用其它IDE,請參考IDE的幫助,整合最新的AIR SDK便可),咱們就以Flash Builder爲準,來介紹後面的操做步驟。性能
請安裝最新的Flash Builder 4.6,這個版本已經支持移動項目建立,而且包含了最新的Flex SDK 4.6(PS:咱們後面的討論裏不包括Flex框架或Flex項目,只是在Flash Builder中任何類型的項目都是依賴Flex SDK來編譯的),可是內置的Flex SDK 4.6包含的是AIR 3.1的SDK,而對於移動設備的Stage3D支持則是在AIR 3.2中實現的。因此這個地方咱們要作一下調整,替換Flex SDK中的AIR的部分。
操做步驟:
而後咱們須要下載Starling。固然跟全部的ActionScript類庫同樣,咱們可使用它編譯後的SWC,也可使用它的源碼。這裏筆者建議你們儘可能使用源碼,由於做爲一個新生框架,Bug是不可避免的,一旦有問題,咱們能夠追蹤源碼來發現和解決。若是用SWC就沒有這個便利了。
目前Starling官網( ),提供的穩定下載版本是1.0,從這裏下載。而後還有一個正在開發的版本,在github託管,地址:經測試發現,目前Github上的版本也比較穩定,並且Demo裏帶了一個iOS的實例,若是您作移動開發,能夠嘗試用github上的最新代碼版本。
下載源碼後,能夠經過Flash Builder建立一個庫項目,包含Starling的源碼,Flash Builder會自動將代碼編譯SWC。而後您能夠建立一個ActionScript手機項目,在構建路徑->庫路徑這個界面上,引用剛纔建立的庫項目便可。
剛纔也說到,源碼中是附帶了例子的,若是您下載的是github上的源碼,裏面還有一個專門的iOS的例子。若是您已經具有了Flash開發經驗,那麼看這個例子無疑是快速瞭解Starling使用方式的最佳途徑。
請遵循下面的步驟啓動這個例子
若是您想在真實設備測試,就要分狀況而言:若是是Android設備,比較簡單,經過自建證書打包爲APK,安裝到Android設備便可;若是是iPhone或iPad ,就麻煩一些,您須要一個蘋果承認的簽名證書才能完成打包,這個證書須要註冊蘋果開發者帳號並付費才能獲取,具體過程參見James Li的教程,這裏再也不細述。
今天就到這裏,後面我會繼續和你們探討使用Starling過程當中的一些問題和經驗。