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