Android程序設計原理之探討

即使平台之間有很大的不同，但是如何利用API創建應用程序的學習過程是大同小異的。一般來說，有兩個步驟：首先，應該知道怎麼用API實現你的功能。其次，要了解平台間的細微差別。換句話說，首先你應該學會如何創建應用程序（了解應用程序的基本結構等），然後就要學會根據具體情況實現這個應用程序。 相比而言，第二階段（學習使用正確的方法來實現應用程序）通常需要很長一段時間，在這個過程中你會不斷地寫代碼，犯錯誤，然後從錯誤中吸取教訓。顯然，這不是一個有效的學習方法，本小節和下面的一些連接針對這向你伸出援助之手，教你怎麼學習創建你的應用程序。 在此之前，先講一個要點：成功的應用程序往往提供一個突出的用戶體驗。當android團隊構建了一個有著健壯核心的系統時，大多數的用戶體驗將來源於用戶和應用程序之間的的交互。因此，我們鼓勵你們花時間去構建應用程序優秀的用戶體驗。 顯著的用戶體驗體現在三個核心特征上：1、快速；2、響應；3、無縫。當然，自從計算機出現以後，每一個平台都曾經有過類似的三種性質。盡管如此，每個平台實現這些特性的方式也有所不同；下面將會簡單的介紹在android平台下面你的應用程序將如何達到這些要求。 快速（Fast） android程序執行應該是很快的。當然，准確來說它的程序應該執行的很有效率（有效率才會快）。在目前的計算機世界裡喲這樣一個傾向：假設摩爾定律能夠最終解決我們所有的問題。當這種傾向遇到嵌入式應用程序的時候，摩爾定律就變得有些復雜了。 與桌面和服務應用程序不一樣，摩爾定律在移動設備應用程序上面不是真正適用的。摩爾定律實際上是關於電子晶體管集成密度的，它原本的含義是：隨著時間的流逝，在給定的電路尺寸上面可以集成更多的電路。對於桌面和服務應用陳旭來說，它的含義是：你可以打包更多的“速度”在一個大小差不多的芯片上面，速度的提高，其他相應的一些性能也會顯著的提高。對以像手機這樣的嵌入式應用程序來說，相反的，使用摩爾定律是為了使芯片變得更小。這樣，隨著芯片密度的提高，相同功能的芯片會變得越來越小，功耗會越來越低，從而使手機做的越來越小，電池的持續的時間越來越長。這樣就導致手持嵌入式設備相對於桌面系統來說正在以一種比較慢二實際的速度在增漲。因而，對於嵌入式設備來說，摩爾定律就意味著更多的功能和更少的功耗，速度只是次要的。 這就是我們要寫出高效代碼的原因：你不能天真的認為電話在速度上面的增漲速度和桌面、服務應用程序是一樣的。一般來說，高效的代碼意味著最小的內存占用，意味著緊湊的風格，意味著避免了因為某種語言和編碼習慣對性能的影響。我們用面向對象這個概念來理解，大部分這樣的工作都是在方法層面上，與實際的代碼，循環等等相類似。 在 《編寫高效的android代碼》 一文中，我們會對此做詳細的介紹。 響應（Responsive） 我們有可能能夠編寫贏得世界上所有的性能測試的代碼，但是用戶使用起來會感到很惱火，這是因為應用程序沒有足夠的響應性——讓人感覺反映遲鈍，在關鍵的時刻失靈，或者處理輸入太慢。在android平台下，那些響應性不夠的應用程序會經常彈出"Application Not Responding" (ANR)這樣的致命消息。 通常，這會在應用程序不能響應用戶的輸入的情況下發生。例如，你的應用程序在一些I/O操作上（如網絡接口調用）阻塞，這是主線程將不會處理用戶的輸入事件，一段時間之後應用系統就會認為你的程序掛起了，就會給一個選項給用戶詢問是否結束它。同樣的，如果你的應用程序花費很多時間去構建內存中的一個結構、或者計算游戲的下一步，這時系統同樣會認為程序已經掛起。當碰到上面情況的時候，要確保計算的高效性，但是即使是最高效的代碼也需要花費時間。 在上面兩個例子中，問題的解決方案是建立一個子線程來處理大部分的工作，這樣就能保證你的主線程（響應用戶界面事件）一直運行，這樣防止系統認為你的程序已經僵化。因為這種線程的實現一般在“類”（CLASS）這個層次上，你可以把響應當成是類的問題來處理（這裡，可以和方法層次描述的基本性能相比較）。 無縫性（Seamless） 即使是你的應用程序執行很快，並且具有很高的響應性，它仍然有可能讓用戶苦惱。一個常見的例子是後台進程(比如Android的 Service 和 BroadcastReceiver)對某些事件可能會突然彈出一個UI響應。這似乎是無關緊要的，並且一般開發者會認為這這是正常的，因為他們花費了戴亮時間去測試和使用自己的應用程序。可是，Android應用程序模型的構建是能夠允許用戶在不同的應用程序之間進行流暢的切換。這就意味著，當你的後台進程實際上彈出那個UI的時候，用戶可能正在系統的其他部分中，做一些其他的事情，如在接電話。想像一下，如果SMS服務每次都會在文本消息傳入時彈出一個對話框，這很快就會使用戶崩潰。這就是為什麼android標准對於這些事件使用的是通知（Notifications）機制；這使用戶能夠自己控制。 這僅僅是一個例子，相似的例子數不勝數。比如，如果ActivitIEs沒有正確的實現onPause()方法和其他生命周期方法，這將會導致數據丟失。或者如果你的應用程序有意的暴露數據給其他應用程序使用，你應該使用一個ContentProvider，而不是用一個路人皆可見的未加工過的文件或者數據庫。 這些例子有一個共同的特點，他們都涉及到程序與程序或則程序與系統之間的交互。系統被設計為將多個應用程序視為一種松耦合組件的聯合，而不是大塊的代碼黑盒。這就允許作為開發人員的你將整個系統看作是一個這些組件的大聯合。這允許你干淨地封裝，無縫地和其他應用程序結合，因而你能設計自己喜歡的程序。 這使一種組件層次的概念（與性能和響應的類層次和方法層次相對應）。至於怎樣編寫無縫性能很高的代碼， 《構建無縫的android程序》 一文中將會對此做出介紹，提供代碼提示和最佳實例。