【導讀】在科技文化高速發(fā)展的今天，人們對電子游戲娛樂的需求也日益高漲。無不體現(xiàn)了游戲的魅力。而隨著智能手機終端的涌現(xiàn)，更是為電子游戲提供了高。特別是iPhone智能手機和Android智能手機的面世，為掌上休閑。究并開發(fā)了一款名為“吉祥鳥”的寵物休閑類游戲。該游戲主要是在研究了。Android系統(tǒng)的SQLite數(shù)據(jù)庫、AppWidget框架、SurfaceView組件、重力感應(yīng)。對游戲的各個模塊進行了功能和性能測試。附帶萬年歷等實用功能；其三是在重力感應(yīng)的基礎(chǔ)上開發(fā)出了電子羅盤。

　　

【正文】 tivity。 Activity 之間的可以相互切換，并通過 Intent 來實現(xiàn)通信。 Android 系統(tǒng)是通過 Activity 棧來管理 Activity 的，在游戲的運行過程不同的 Activity 會經(jīng)歷不同的生命周期。 Activity 的生命周期中本質(zhì)上分為四種狀態(tài)即： （ 1） activity 在屏幕的前景中則處于 activity 棧的頂端，它是 active 或者 running 狀態(tài)。 （ 2） activity 失去了焦點但是仍然可見，如 這個 activity 頂上遮擋了一個透明的或者非全屏的 activity，它的狀態(tài)則是 paused。一個 paused 狀態(tài)的activity 完全是 alive 的。它維護自己所有的狀態(tài)和成員信息，而且仍然在window manager 的管理中，但當系統(tǒng)內(nèi)存極度貧乏時也會將其 killed。 （ 3） activity 由于其他的 activity 而完全變暗，它就進入了 stopped 狀態(tài)。它仍然保持著所有的狀態(tài)和成員的信息，可是，他對于用戶來說不可見，當別的地方需要內(nèi)存的時候它經(jīng)常會被 killed。 （ 4） activity 是 paused 或者 stopped，系統(tǒng)需要將其清理出內(nèi)存的時可以命令其 finish 或者簡單 kill 其進程。當它重新在用戶面前顯示的時候，它必須完全重新啟動并且將其關(guān)閉之前的狀態(tài)全部恢復回來。 游戲在操作過程中可能會發(fā)生界面切換，遇到接電話、收發(fā)短信甚至電量不足關(guān)機等偶發(fā)情況都會影響 Activity 的狀態(tài)。 Android 系統(tǒng)對資源控制較嚴，在狀態(tài)的轉(zhuǎn)換時可能對資源回收，為了保證程序的正確性，必須在 onPause()里寫上持久層操作的代碼，將游戲產(chǎn)生的數(shù)據(jù)都保存到存數(shù)據(jù)庫中。游戲運行中生命周期的變化而帶來的其他問題 也很多，例如游戲創(chuàng)建的線程在運行中被中斷了，則可以暫停、殺掉或數(shù)據(jù)回滾來維護此線程。因為 Activity 可能被殺掉，所以線程中使用的變量和一些界面元素就需要采用 Android的消息機制 Handler或 Message 來處理多線程和界面交互的問題。 Intent Receiver Intent[8]是 Android 系統(tǒng)中用于通信和交互的一種機制，不但可以實現(xiàn)不同應(yīng)用間的通信與交互還可以在應(yīng)用程序內(nèi)部的不同 Activity 以及 Service 間實現(xiàn)交互。在通信過程 Intent 起了一個媒介的作用，提供組件 互相調(diào)用的相關(guān)信息，為調(diào)用者與被調(diào)用者解耦。在不同應(yīng)用程序交互時， Intent 負責對應(yīng)用中一次操作的動作、動作涉及數(shù)據(jù)、附加數(shù)據(jù)進行描述， Android 則根據(jù)此 Intent的描述，負責找到對應(yīng)的組件，將 Intent 傳遞給調(diào)用的組件，并完成組件的調(diào)用。在本寵物游戲中不同 Activity 就是通過 Intent 來交換數(shù)據(jù)的。 游戲中 Activity 的相互調(diào)用的動作需要在 Intent Filter 中進行描述，當發(fā)生調(diào)用關(guān)系時， Android 會解析對應(yīng)的 Intent 來決定如何來 調(diào)用 Activity，需要解析 Intent 屬性包括以下六類： （ 1） Action，指定要執(zhí)行的動作?？梢允亲约憾x的動作也可以是系統(tǒng)預定義的動作。寵物游戲中指定的通常是自定義的動作以完成特定功能，如掉調(diào)用輸入屏幕為游戲提供用戶數(shù)據(jù)。系統(tǒng)預定義的動作通常是與手機使用緊密相關(guān)的動作，例如發(fā)送短信的動作 ACTION_CALL。 （ 2） Data，指定動作要操作的數(shù)據(jù)，通常用 URI 來表示，例如聯(lián)系人的 URI為 （ 3） type，顯式指定 Intent 的數(shù)據(jù)類型。 （ 4） category，動作的類別，例如 LAUNCHER_CATEGORY 表示此動作為頂級應(yīng)用，在應(yīng)用軟件啟動后便執(zhí)行，相當于 MAIN 函數(shù)。 （ 5） ponent，指定 Intent 的的目標組件的類名稱。 第三章 Android 手機寵物游戲引擎及相關(guān)技術(shù)研究 —————————————————————————————————————————————— 17 （ 6） extras，指定動作的附加信息集合。需要傳遞的數(shù)據(jù)都可以保存到extras 中來實現(xiàn)數(shù)據(jù)通信。 相應(yīng)動作在 Intent Filter 中配置好后就可以在 Activity 中實例化，如果需要傳遞參數(shù)則需要綁定 Bundle 來附加需要傳遞的數(shù)據(jù)，最后使用startActivity(myIntent)來啟動動作。 Service Service[9]是一種沒有用戶界面的后臺程序，通常為前臺 Activity 服務(wù)。它在 Activity 中由 () 啟 動 ， 也 可 以 使 用 連接到另一個 Service，之后可以通過 Service 提供的接口進行通信。當一個 Service 啟動之后其他組件可以綁定到此 Service，并通過遠程調(diào)用來調(diào)用它定義的方法。在寵物游戲中定義了一個為 AppWidget 服務(wù)的Service 和一個實現(xiàn)游戲版本升級的 Service。由于 Service 運行于主進程中的，為減少對主線程或 UI 操作的阻塞，通常在 Service 中另啟動一個新線程來完成特定操作。 Service 的生命周期不一定與前臺 Activity 同步，可以使用stopService（）方法來結(jié)束 Service 從而回收線程占用的資源。 ContentProvider 圖 ContentProvider 工作原理 ContentProvider 這個抽象接口是實現(xiàn)應(yīng)用程序間共享數(shù)據(jù)的唯一方法。這個接口的主要功能就讓是應(yīng)用程序?qū)⒆约旱臄?shù)據(jù)充分暴露出去給其他應(yīng)用程序共享，無論應(yīng)用程 序的數(shù)據(jù)是以什么樣的方式存儲的，如數(shù)據(jù)庫、本地文件、網(wǎng)絡(luò)文件等，都會以類似于訪問數(shù)據(jù)庫的方式提供給其他程序。例如電話本中聯(lián)系人信息，電話本程序可以將自己有哪些信息共享、以及如何共享等寫入 配置文件，其他程序可以通過 ContentResolver 來獲取這些信息。圖 描述了以上所述 ContentProvider 的工作機制。這個機制可以將Activity1 的 UI界面數(shù)據(jù)映射給 Activity2 使用。 多線程 在寵物游戲中要實現(xiàn)角色動畫以及游戲聲效，必須要采用多線 程技術(shù) [10]來與游戲同步，另外為 AppWidget 提供動畫的 Service 也需要后臺線程來支持。在Android 虛擬機中每個線程的資源都有一定的限制，游戲在渲染角色動畫時會消耗大量的系統(tǒng)資源，有時會出現(xiàn)內(nèi)存溢出的狀況，為減少線程阻塞的情況發(fā)生可以采取多線程渲染的方式。 游戲在運行后會進入主屏幕的 Activity，這時會啟動一個主線程，這個線程主要負責與 UI相關(guān)的工作，通常又稱為 UI 線程。之后主線程根據(jù)需要實例化渲染線程、聲效線程以及其他服務(wù)線程并用 Run()方法啟動。當這些線程需要與其他線程或主線程通信同 步時可以通過 Android提供的 Handle和 Looper來進行數(shù)據(jù)以及參數(shù)傳遞。 Android 的線程分為有消息循環(huán)的線程和沒有消息循環(huán)的線程。有消息循環(huán)的線程一般都會有一個 Looper，主線程就是一個消息循環(huán)的線程。針對這種消息循環(huán)的機制引入了一個新的機制 Handler。如果有消息循環(huán)，就要往消息循環(huán)里面發(fā)送相應(yīng)的消息，自定義消息一般都會有自己對應(yīng)的處理，消息的發(fā)送和清除，把這些都封裝在 Handler 里面。 Handler 只是針對那 些有 Looper 的線程，不管是 UI 線程還是子線程，只要有 Looper，就 可以往消息隊列里面添加東西，并做相應(yīng)的處理。但是關(guān)于 UI 相關(guān)的東西，就不能放在子線程中，因為子線程是不能操作 UI 的，只能進行數(shù)據(jù)、系統(tǒng)等其他非 UI 的操作。一個 Handler 的創(chuàng)建它就會被綁定到這個線程的消息隊列中，如果是在主線程創(chuàng)建的，那就不需要寫代碼來創(chuàng)建消息隊列了，默認的消息隊列會在主線程被創(chuàng)建。但是如果是在子線程的話，就必須在創(chuàng)建 Handler 之前先初始化線程的消息隊列。 第三章 Android 手機寵物游戲引擎及相關(guān)技術(shù)研究 —————————————————————————————————————————————— 19 游戲數(shù)據(jù)中心 游戲運行過程中將涉及大量的數(shù)據(jù)，包括寵物預測相關(guān) 16 兆字節(jié)大小的數(shù)據(jù)信息，以及游戲運行過程中產(chǎn)生的中間數(shù)據(jù)， 這些數(shù)據(jù)都需要長時間持久保存。數(shù)據(jù)中心 [45]的任務(wù)就是為游戲的各模塊快速有效的提供數(shù)據(jù)支持。 Android 數(shù)據(jù)存取方式概述 在 Android 系統(tǒng)框架下主要有 3 種方法來實現(xiàn)數(shù)據(jù)的存取，分別是 SQLite數(shù)據(jù)庫管理數(shù)據(jù)、 Share preferences 類存取數(shù)據(jù)、文件形式存取數(shù)據(jù)。通常使用 SQLite[27]來管理大容量關(guān)系型數(shù)據(jù)，這種方式安全性較高，數(shù)據(jù)整合程度最好。 Share Preference 類存取數(shù)據(jù)更直接，速度較快，適用于零散數(shù)據(jù)的存取。文件形式存取數(shù)據(jù)也是一種常用的方式，通常將數(shù) 據(jù)存儲為結(jié)構(gòu)化的 XML 文件，可利用 DOM 或 SAX 來解析提取數(shù)據(jù)，雖然效率不高，但在少量數(shù)據(jù)存取方面仍可以發(fā)揮很強的作用。在本寵物鳥游戲中特別是寵物預測模塊中需要進行大量的高效率的數(shù)據(jù)存取操作，故采用 SQLite 方式較為方便合理。同時在游戲中產(chǎn)生少量的玩家數(shù)據(jù)，用 SharePreference 方式來存取較為快捷。寵物鳥游戲的數(shù)據(jù)中心就是由于 SQLite 和 SharePreference 構(gòu)建而成。 SQLite 數(shù)據(jù)庫 SQLite[11]數(shù)據(jù)庫是一種跨平臺的的輕量級嵌入式關(guān)系型數(shù)據(jù)庫，支持 SQL92標 準中常用的視圖、觸發(fā)器、事務(wù)等功能，可以用標準的 SQL 語言正常訪問數(shù)據(jù)庫。數(shù)據(jù)庫中的所有信息都包含在一個文件內(nèi)，容易移植，可以拷貝到任何裝有SQLite 的機器中。它不依賴與第三方軟件，在部署時非常便捷。缺點主要是對并發(fā)訪問支持不夠好，數(shù)據(jù)庫經(jīng)常被操作系統(tǒng)獨占，導致阻塞其他進程。另外SQLite 在并發(fā)訪問網(wǎng)絡(luò)文件系統(tǒng)時可能出現(xiàn)諸如文件損壞等問題。 Android 內(nèi)置的 SQLite 由 4 個組件組成：內(nèi)核、 SQL 編譯器、附件以及后端。SQLite 利用虛擬數(shù)據(jù)庫引擎和虛擬機使修改、調(diào)試、擴展其內(nèi)核也更加方便。SQLite[25]與其他數(shù)據(jù)庫最大的區(qū)別在于對弱類型數(shù)據(jù)的支持。在創(chuàng)建表時可以指定某列數(shù)據(jù)的類型，但是在使用中可以將任何類型的數(shù)據(jù)存入， SQLite 會自動檢查它的類型，如果類型不匹配，則會嘗試轉(zhuǎn)換該值的類型，如果不能也將數(shù)據(jù)存入。另外， SQLite 不支持外鍵約束、嵌套、 RIGHT OUTER JOIN 等特殊功能。 在 Android 系 統(tǒng) 中 ， SQLite 數(shù) 據(jù) 庫 的 所 有 文 件 存 放 于 手 機 的/data/data/package_name/databases 路徑下，只為當前應(yīng)用軟件私有，保障數(shù)據(jù)的安全性。另外， Android 系統(tǒng) 的 SQLite 還不夠完善，并無自動導入數(shù)據(jù)庫文件的功能，應(yīng)用軟件在第一次使用數(shù)據(jù)庫之前需要通過文件讀寫等操作將數(shù)據(jù)庫文件導入到該應(yīng)用的私有路徑下。 受手機平臺所限， Android 環(huán)境下的 SQLite 不方便執(zhí)行復雜的操作，當常用的刪改查詢操作還是比較齊全的。在數(shù)據(jù)庫操作方面， Android 為我們提供了SQLiteOpenHelper、 SQLiteDatabase 和 ContentProvider 三種方式訪問 SQLite數(shù)據(jù)庫。 SQLiteOpenHelper 是一個非常方便的 SQLite 輔助類，可以自動進行數(shù)據(jù)庫 版本控制。它主要封裝了添加、刪除、查詢、修改等數(shù)據(jù)庫操作。ContentProvider 則是一個可以在不同應(yīng)用程序間實現(xiàn)數(shù)據(jù)庫共享的抽象接口。 最為常用的是 SQLiteOpenHelper[12]這個輔助抽象類，可以實現(xiàn)數(shù)據(jù)庫的創(chuàng)建和版本管理。使用前首先要實現(xiàn) onCreate 和 onUpgrade 兩個方法。 onCreate方法在數(shù)據(jù)庫第一次被建立時運行，用于創(chuàng)建表和初始化數(shù)據(jù)。 onUpgrade 方法通常在刪除永久表或創(chuàng)建新表等影響數(shù)據(jù)庫版本的動作時執(zhí)行。為實現(xiàn)數(shù)據(jù)庫的管理，我們可以在此類中預定義查詢方法，以便 在應(yīng)用程序中調(diào)用。 SQLiteDatabase 是 Android系統(tǒng)中實現(xiàn) SQLite數(shù)據(jù)庫管理的最基本的核心類。它直接封裝了能夠進行數(shù)據(jù)庫操作的所有方法，包括添加 insert、刪除delete、查詢 query、修改 update 四個數(shù)據(jù)庫的標準操作。這些方法需要引用了兩個數(shù)據(jù)結(jié)構(gòu) ContentValues 和 Cursor。其中 ContentValues 相當于 Map 類型，主要接口有 get()和 put()，結(jié)合 insert()方法可以實現(xiàn)將字段對應(yīng)的數(shù)值插入數(shù)據(jù)表中。 Cursor 則是查詢記錄返回的結(jié)果集，通過 MoveNext()、GetColumns()方法可以獲取需要的數(shù)據(jù)。 SharePreference 存儲方式 SharedPreferences [12]是以鍵值存儲的方式來保存應(yīng)用程序的簡單數(shù)據(jù)，實際上最終是保存在一個 XML 文件中，因此只能存儲一些基本數(shù)據(jù)類型。這些被存儲的數(shù)據(jù)不僅可以在本應(yīng)用程序中使用，也可以特殊的方式提供給其他應(yīng)用程序使用。 實際上 SharedPreferences 采用的是以 XML 格式將數(shù)據(jù)存儲到/data/data/package name/shares_prefs 路徑 下。 在 Android 應(yīng)用程序中可以通過 (String 第三章 Android 手機寵物游戲引擎及相關(guān)技術(shù)研究 —————————————————————————————————————————————— 21 name,int mode) 、 (int mode) 兩 種 方 式 獲 取SharedPreferences 對象。之后可以調(diào)用 SharedPreferences 的 getXXX()方法讀取保存在此對象中的數(shù)據(jù)。如果需要保存數(shù)據(jù)至 SharedPreferences 中，必須調(diào)用 edit()方法切換至可編輯狀態(tài)，然后調(diào)用 putXXX()方法將數(shù)據(jù)寫入此對象。 AppWidget 框架 AppWidget 概述 AppWidget[8][13]是 以上版本提供的一個實現(xiàn)手機桌面與后臺相互協(xié)同工作的框架。它其實是 App 和 Widget 的結(jié)合，開發(fā)者可以編寫 Widget 并將它直接拖放到手機桌面作為互動的接口，也可以通過主窗口的 Widget 輔助某些 APPs 和后臺服務(wù)程序的應(yīng)用，日歷和播放器都是在這個框架之上開發(fā)的應(yīng)用程序。但是與傳統(tǒng)的 Widget 不同，傳統(tǒng)的 Widget 核心是基于 Web 技術(shù)，需要專門的 Widget 引擎運行，而 AppWidget 完全以 Android 平臺的上層應(yīng)用框架為基礎(chǔ)，使用特定的 UI 組件來展現(xiàn)內(nèi)容。 Appwidget 的工作原理 從高層級的實現(xiàn)層來分析 AppWidget 的工作機理?？梢园l(fā)現(xiàn)它實際上是一個BroadcastReceiver，借助了與其匹配的對應(yīng) xml 來描述更多其 widget 自身細節(jié)信息，從而可以使 AppWidget 框架通過 broadcastintents 與某些 Widget 通訊。其通訊的信息內(nèi)容，是借助于 RemoteViews 將 Layout 和內(nèi)容捆綁為獨立的對象，Widget 作為一個載體將其所包含的內(nèi)容顯示在 主窗口。 圖 為 AppWidget 的工作原理，當我們把某個 AppWidget 拖放到手機桌面的時候，實際上這個 AppWidget 是安置在 Launcher 的一個 View 上面，被停靠的這個 Activity 即為宿主，而 AppWidget 則運行在一個相對獨立的進程中，如果AppWidget 要與宿主通信的話就需要通過 IPC 來實現(xiàn)。當 RemoteViews 把AppWidget 的 View 信息傳遞給宿主時，需要通過 AppWidgetHost 來獲取AppWidgetHostView 實例，如此按照 RemoteViews 中的配 置信息將 AppWidget 的View 映射到宿主中。最終， Widget 就顯示在宿主上了。這個過程可以比喻為借尸還魂， 在 Android 中，因為進程之間有邊界的阻隔，使得 AppWidget與 AppHost通常是不能直接溝通的。 利用 RemoteView 這個橋梁，讓 AppWidget 將一切需要呈現(xiàn)的描述構(gòu)建到 RemoteView 中， AppHost 中再基于該描述，重新創(chuàng)建于屬于自己進程中的 View 進而顯示。另外 AppWidget 框架還需要 AppWidgetManager 來管理 AppWidgetHost 與 AppWidgetService 之間的事務(wù)關(guān)系。 W i d g e t P r o v i d e rU p d a t e S e r v i c eA p p W i d g e tA p p W i d g e t H o s tA p p W i d g e t H o s tV i e wL a n u h H o s tR e m o t e V i e w 工作原理 AppWidget 構(gòu)建方法 從 上 一 小 節(jié) 我 們 可 知 AppWidget 框 架 中 有 AppWidgetProvider 、AppWidgetProviderInfo、 AppWidgetManager 和 RemoteViews 四個重要的類。其中 AppWidgetProviderInfo 用于描述 AppWidget 的初始界面、大小和更新頻率等信息。以 XML文件方式保存在應(yīng)用程序的 res/xml/路徑下；而 AppWidgetProvider繼承了 BroadcastReceiver基類，在 AppWidget應(yīng)用程序中遇到 deleted、 update, disable 和 enable 時收到通知。其最常用的方法是 onReceive 和 onUpdate，它們同樣接收更新通知； AppWidgetManager 的任務(wù)是管理 AppWidget 并向AppWidgetProvider 發(fā)送通知； RemoteViews 是一個可以在其他應(yīng)用進程中運行的類，是架構(gòu) AppWidget 的核心，是連系 Provider 和 Host 的橋梁。只是目前在Android 下 RemoteViews 支持的布局類暫時只有 LinearLayout 、 FrameLayout和 RelativeLayout，不支持其他自定義類。 構(gòu)建一個 AppWidget 一般需要以下三個步驟： 第一步，建立 Android 應(yīng)用工程，然后在 res/xml/路徑下添加一個 xml 文件來描述 AppWidgetProviderInfo 的界面、大小和刷新頻率等信息。 AppWidget的像素大小取決于它所占的方塊多少，其計算公式是 (塊數(shù) * 74) – 2，單位通常為 dip。需要注意 不同手機的分辨率，例如，標