【正文】 ntentView(int)方法定義你的 UI，和用 findViewById(int)在你的 UI 中檢索你需要編程地交互的小部件（ widgets）。 setContentView 指定由哪個(gè)文件指定布局（ ），可以將這個(gè)界面顯示出來(lái)，然后我們進(jìn)行相關(guān)操作，我們的操作會(huì)被包裝成為一個(gè)意 19 圖（ Intent），然后這個(gè)意圖對(duì)應(yīng)有相關(guān)的 activity 進(jìn)行處理。 onPause()：處理當(dāng)離開(kāi)你的活動(dòng)時(shí)要做的事情。最重要的是，用戶(hù)做的所有改變應(yīng)該在這里提交（通常 ContentProvider 保存數(shù)據(jù)）。 生命周期如圖 31 圖 31Android 的生命周期 每 一個(gè)應(yīng)用程序可能只包含一個(gè)活動(dòng)，或者 是像 短信應(yīng)用 程序一樣 ，它可能 會(huì) 包含幾個(gè)活動(dòng)。這些活動(dòng) 分別 是 什么，以及有多少， 這個(gè) 當(dāng)然取決于它的應(yīng)用 程序自己的 設(shè)計(jì)。 根據(jù) 一般 情況 來(lái) 說(shuō) ，當(dāng) 一個(gè)應(yīng)用程序被啟動(dòng) 的時(shí)候 ， 會(huì) 被標(biāo)記為第一個(gè)的活動(dòng) ， 應(yīng)該展示給用戶(hù)。從一個(gè)活動(dòng) 轉(zhuǎn) 移到另 外 一個(gè)活動(dòng)由當(dāng)前的活動(dòng)完成 從而 開(kāi)始下一個(gè)。 每 一 個(gè)活動(dòng)都 會(huì) 有一個(gè)默認(rèn)的窗口。 根據(jù) 一般 情況來(lái)說(shuō) ，窗口 是 會(huì)填滿(mǎn)整個(gè)屏幕 的 ，但是它 也有 可 20 能比屏幕小 或者是 浮在其他窗口上 ，這個(gè)就是程序員代碼的編寫(xiě)情況了 。一個(gè)活動(dòng)還可以使用額外窗口 。比如 彈出式對(duì)話(huà)框， 或者是 當(dāng)一 個(gè) 用戶(hù)選擇屏幕上一個(gè)特定的項(xiàng)時(shí) ，會(huì)跳出 一個(gè)窗口 來(lái) 顯示給用戶(hù)重要的信息。 窗口的可視 化 內(nèi)容是由繼承自 接口 為 View 基類(lèi) ， 一個(gè)分層的視圖 —對(duì)象提供。每個(gè) 可視化 控件是窗口內(nèi)的一個(gè)特定的矩形空間。父視圖包含和組織子女視圖的布局。葉子視圖 分層的底層 。 繪制的矩形 會(huì) 直接控制和響應(yīng)用戶(hù)的操作。 所以 ，一個(gè)視圖活動(dòng) 是 與用戶(hù)發(fā)生 交互 的地方。 比如說(shuō) ，一個(gè)視圖顯示一個(gè)小的圖片和當(dāng)用戶(hù)點(diǎn)擊圖片時(shí)發(fā)起一個(gè) 動(dòng)作 行為。 Android 有一些現(xiàn)成的 可視化控件 你可以使用，其中 包括按鈕（ buttons）、 圖片按鈕（ ImageButton）、 文本域（ text fields）、 可編輯文本控件（ EditText）、菜單項(xiàng)（ menu items） 、仿真 時(shí)鐘（ AnalogClock） 滾動(dòng)條（ scroll bars）、 開(kāi)關(guān)按鈕（ ToggleButton）、 復(fù)選 按鈕 （ check boxes）等等。 通過(guò) () 方法 來(lái)設(shè) 置一個(gè)視圖層次在 我們的 活動(dòng)窗口中。內(nèi)容視圖（ content view）是層次結(jié)構(gòu)的根視圖對(duì)象。層次結(jié)構(gòu)如下圖 32 所示： 圖 32 View 的層次結(jié)構(gòu) ()方法： public void setContentView (int layoutResID)：根據(jù)布局資源 的 設(shè)置活動(dòng)界面。資源將 會(huì) 被夸大，添加布局資源文件中 的 所有的最高層的視圖（ toplevel views ）到活動(dòng) . 服務(wù)（ Services） 與 Activity 相反， Service 是沒(méi)有可視化的用戶(hù)界面，但是 Service 的特點(diǎn)是能長(zhǎng)時(shí)間在后臺(tái)運(yùn)行的 。所以，也可以這樣去理解， Service 是具有一段較長(zhǎng)生命周期而且沒(méi)有用戶(hù)界面的程序。比如說(shuō) 一個(gè)服務(wù)可能 要 播放背景音樂(lè) 但是 用戶(hù)做 可以去做 其他一些事情，或者它 也 可能從網(wǎng)絡(luò)獲取數(shù)據(jù)， 也或者是 計(jì)算一些東西并 會(huì) 提供 一個(gè) 結(jié)果給需要的活動(dòng)（ activities）。每 一 個(gè)服務(wù)都繼承自 Service 基類(lèi)。 21 每 一 個(gè)服務(wù)類(lèi) 都惠子 在 中有 自己 相應(yīng)的 service聲明。服務(wù) 必須 可以通過(guò) Co()或者 ()啟動(dòng) 因?yàn)?service 是有兩個(gè)不同的生命周期的 。 一個(gè) 非常 典型的例子是媒體播放器播放一個(gè)播放列表中的歌曲 文件 。該播放器應(yīng)用程序?qū)⒖赡苡幸粋€(gè) 或者是 多個(gè)活動(dòng)（ activities）， 可以 允許用戶(hù)選擇 要聽(tīng)的 歌曲和開(kāi)始播放。然而，音樂(lè)播放本身 就 不會(huì)被一個(gè)活動(dòng)處理，因?yàn)橛脩?hù) 是 希望保持音樂(lè) 一直 播放 的 ，當(dāng)用戶(hù)離開(kāi)播放器 的時(shí)候而 去做其他事情。為了保持音樂(lè) 能夠 繼續(xù)播放，媒體播放器活動(dòng)可以啟動(dòng)一個(gè)服務(wù)運(yùn)行在后臺(tái) 的運(yùn)行 。系統(tǒng)將 會(huì) 保持音樂(lè)播放服務(wù)運(yùn)行，甚至媒體播放器離開(kāi)屏幕 的時(shí)候 。 可以連接到（綁定到）一個(gè)持續(xù)運(yùn)行的服務(wù)（并啟動(dòng)服務(wù)，如果它尚未運(yùn)行）。連接之后，你可以通過(guò)服務(wù)暴 露的接口與服務(wù)交流。對(duì)于音樂(lè)服務(wù)，這個(gè)接口可以允許用戶(hù)暫停、倒帶、停止和重新播放。 像活動(dòng)（ activities）和其他組件一樣，服務(wù)（ services）運(yùn)行在應(yīng)用程序進(jìn)程中的主線程中。因此，他們將不會(huì)阻止其他組件或用戶(hù)界面，他們往往產(chǎn)生其他一些耗時(shí)的任務(wù)（如音樂(lè)播放）。 廣播接收者（ Broadcast receivers） 一個(gè)廣播接收者是這樣一個(gè)組件，它不做什么事，僅是接受廣播公告并作出相應(yīng)的反應(yīng)。許多廣播源自于系統(tǒng)代碼，例如公告時(shí)區(qū)的改變、電池電量低、已采取圖片、用戶(hù)改變了語(yǔ)言偏好。應(yīng)用 程序也可以發(fā)起廣播，例如為了他其他程序知道某些數(shù)據(jù)已經(jīng)下載到設(shè)備且他們可以使用這些數(shù)據(jù)。 一個(gè)應(yīng)用程序可以有任意數(shù)量的廣播接收者去反應(yīng)任何它認(rèn)為重要的公告。所有的接受者繼承自 BroadcastReceiver 基類(lèi)。 BroadcastReceiver 類(lèi)：是接受 sendBroadcast()發(fā)送的意圖（ intents）的基類(lèi)。可以用 rReceiver()動(dòng)態(tài)地注冊(cè)這個(gè)類(lèi)的實(shí)例，或者通過(guò) 中 receiver標(biāo)簽靜態(tài)發(fā)布。注意：如果你在 () 注冊(cè)一個(gè)接受者，你應(yīng)該在 ()注銷(xiāo)它。因?yàn)楫?dāng)暫停時(shí)你不會(huì)收到意圖，注銷(xiāo)它將削減不必要的系統(tǒng)開(kāi)銷(xiāo)。不要在 ()中注銷(xiāo)它，因?yàn)樗鼘⒉粫?huì)被調(diào)用，如果用戶(hù)移動(dòng)到先前的堆棧。 有兩種主要的可接受廣播類(lèi)型： 正常廣播（由 發(fā)送）是完全異步的。所有的廣播接收者以無(wú)序方式運(yùn)行，往往在同一時(shí)間接收。這樣效率較高，但是意味著接受者不能使用結(jié)果或終止廣播數(shù)據(jù)傳播。 有序廣播 （由 發(fā)送）一次傳遞給一個(gè)接收者。由于每個(gè)接收者依次執(zhí)行，因此它可以傳播到下一個(gè)接收器，也可以完全終止傳播以便他不會(huì)傳遞給其他接收者。接收者的運(yùn)行順序可由匹配的意圖過(guò)濾器（ intentfilter）的 android:priority 屬性控制。 廣播接收者不顯示一個(gè)用戶(hù)界面。然而，它們啟動(dòng)一個(gè)活動(dòng)去響應(yīng)收到的信息，或者他們可能使用 22 NotificationManager 去通知用戶(hù)。通知可以使用多種方式獲得用戶(hù)的注意 ——閃爍的背光、振動(dòng)設(shè)備、播放聲音等等。 典型的是放在一個(gè)持久的圖標(biāo)在狀態(tài)欄，用戶(hù)可以打開(kāi)獲取信息。 內(nèi)容提供者（ Content providers） 內(nèi)容提供者（ content provider）使一個(gè)應(yīng)用程序的指定數(shù)據(jù)集提供給其他應(yīng)用程序。這些數(shù)據(jù)可以存儲(chǔ)在文件系統(tǒng)中、在一個(gè) SQLite 數(shù)據(jù)庫(kù)、或以任何其他合理的方式。內(nèi)容提供者繼承自 ContentProvider 基類(lèi)并實(shí)現(xiàn)了一個(gè)標(biāo)準(zhǔn)的方法集，使得其他應(yīng)用程序可以檢索和存儲(chǔ)數(shù)據(jù)。然而，應(yīng)用程序并不直接調(diào)用這些方法。相反，替代的是它們使用一個(gè) ContentResolver 對(duì)象并調(diào)用它 的方法。 ContentResolver 能與任何內(nèi)容提供者通信，它與提供者合作來(lái)管理參與進(jìn)來(lái)的進(jìn)程間的通信。 內(nèi)容提供者是 Android 應(yīng)用程序的主要組成部分之一，提供內(nèi)容給應(yīng)用程序。他們封裝數(shù)據(jù)且通過(guò)單個(gè) ContentResolver 接口提供給應(yīng)用程序。只有需要在多個(gè)應(yīng)用程序間共享數(shù)據(jù)是才需要內(nèi)容提供者。例如，通訊錄數(shù)據(jù)被多個(gè)應(yīng)用程序使用，且必須存儲(chǔ)在一個(gè)內(nèi)容提供者中。如果你不需要在多個(gè)應(yīng)用程序間共享數(shù)據(jù)，你可以直接使用 SQLiteDataBase 當(dāng) ContentResolver 發(fā)出一個(gè)請(qǐng)求時(shí)，系統(tǒng)檢查給 定的 URI 的權(quán)限并傳遞請(qǐng)求給內(nèi)容提供者注冊(cè)。內(nèi)容提供者能理解 URI 想要的東西。 UriMatcher 類(lèi)用于幫組解析 URIs。 需要實(shí)現(xiàn)的方法主要如下： query(Uri, String[], String, String[], String) 返回?cái)?shù)據(jù)給調(diào)用者 insert(Uri, ContentValues) 插入數(shù)據(jù)到內(nèi)容提供者 update(Uri, ContentValues, String, String[]) 更新內(nèi)容提供者已存在的數(shù)據(jù) delete(Uri, String, String[]) 從內(nèi)容提供者中刪除數(shù)據(jù) getType(Uri) 返回內(nèi)容提供者中的 MIME 類(lèi)型數(shù)據(jù) 更多的關(guān)于 ContentResolver 信息，請(qǐng)查看相關(guān)文檔。 每當(dāng)有一個(gè)應(yīng)該由特定組件處理的請(qǐng)求， Android 可以確保該組件的應(yīng)用程序正在運(yùn)行，如果沒(méi)有就啟動(dòng)它，而且一個(gè)適當(dāng)?shù)慕M件實(shí)例可用，如果沒(méi)有就創(chuàng)建。 5 程序的設(shè)計(jì)與實(shí)現(xiàn) 本章節(jié)主要介紹一下此論文中用到了的 Android 的布局文件，可視化控件以及它們 23 的具體實(shí)現(xiàn)。 程序 的算法研究： 本游戲是以五子棋為背景的游戲，游戲 的畫(huà)面按照 9*9 的畫(huà)面進(jìn)行匯總，內(nèi)容的算法則是根據(jù) JAVA的基本循環(huán)語(yǔ)句進(jìn)行定義，棋盤(pán)的繪制尤為重要，它是整個(gè)游戲的關(guān)鍵，因?yàn)樗钦麄€(gè)游戲的主界面，利用 surface 可得到 9*9 的游戲棋盤(pán)坐標(biāo)畫(huà)面。 在游戲中，落子定義也十分重要，因?yàn)槲遄悠逵螒蛑?，只要黑白任意一方在任何方向?5 個(gè)連續(xù)落子連成一線，便獲得了勝利。算法便是在坐標(biāo)定義上進(jìn)行 ++的方式。 棋盤(pán) 布局 的數(shù)據(jù)結(jié)構(gòu) 首先要先獲得整個(gè)棋盤(pán)的高度，以及其他一些寬度的參數(shù)，因?yàn)槔玫氖?surface 的重繪，所以對(duì)此類(lèi)棋盤(pán)高度寬度進(jìn)行定義，部分 代碼如下： public void setGameState(int newState) { mGameState = newState。 switch (mGameState) { case GS_GAME: mGameMap = new int[CHESS_HEIGHT][CHESS_WIDTH]。 mMapHeightLengh = 。 mMapWidthLengh = mGameMap[0].length。 mCampTurn = CAMP_HERO。 break。 關(guān)于盤(pán)面情況的表示， 首先得到屏幕的大小，然后根據(jù)所畫(huà)棋子的大小來(lái)確定下一條棋盤(pán)的畫(huà)線。 整個(gè)棋盤(pán)是利用 superface 進(jìn)行重繪， superface 是安卓系統(tǒng)繪制列陣最普通的一種 在 android 中，對(duì)view 及其子類(lèi)，都是畫(huà)在 surface 上的。每個(gè) window 對(duì)應(yīng)一個(gè) surface，各 surface 對(duì)象通過(guò) surfaceflinger 合成到 framebuffer，每個(gè) surface 都是雙緩沖，它有一個(gè) back buffer 和一個(gè) front buffer。 back buffer 就是畫(huà)畫(huà)的地方， front buffer 是用來(lái)合成。 surface 創(chuàng)建 Canvas 對(duì)象（用來(lái)管理 surface 繪圖操作）， Canvas 對(duì)應(yīng) bitmap（存儲(chǔ) surface 內(nèi)容）。當(dāng)調(diào)用 unlockCanvas（）后， back buffer 開(kāi)始變?yōu)榭捎?，就開(kāi)始顯示了。有一套機(jī)制實(shí)現(xiàn) back buffer和 front buffer 的互換，當(dāng)要更新時(shí)， back buffer 與 front buffer 互換， back buffer 變成 front buffer。 代碼如下： for (i = 0。 i mMapHeightLengh。 i++) { for (j = 0。 j mMapWidthLengh。 j++) { int CampID = mGameMap[i][j]。 24 float x = (j * mTitleSpace) + mTitleIndex_x。 float y = (i * mTitleSpace) + mTitleHeight + mTitleIndex_y。 if (CampID == CAMP_HERO) { DrawImage(mBlack, x, y, ALIGN_VCENTER | ALIGN_HCENTER)。 } else if (CampID == CAMP_ENEMY) { DrawImage(mWhite, x, y, ALIGN_V