android設計架構設計-ag真人国际官网

⑴ android架構設計的思想與原則是什麼

rlei分析了android的設計哲學：
理解好intent，就可以理解android哲學(所有應用生來平等)的一部分。舉個簡單的例子，ios裡面應用要集成sns如facebook/twitter/sina weibo等，都需要應用自己實現（ios5也只是集成twitter一家）；android上只需要廣播一個share內容的intent。從理解intent如何工作開始，你就在慢慢理解activity manager, package manager, services這些android的重要組件是如何工作的。
另外binder是android架構里非常核心的一塊。android基於intent的消息傳遞和組件/應用解耦，下面的基礎都是binder ipc。在這一點上，android實際上是光榮的傳承了beos和palm os 6（悲催的os6...）未能發揚光大的一部分。
mvc(content provider, activity, layout, adapters)這個比較基礎，也不算android特有的。
content provider對數據訪問的抽象也是比較有意思的一塊。理想情況下，content provider可以讓客戶端用uri以語義化的方式訪問數據(uri本身即表示數據層次結構和查詢條件），而下面資料庫表的結構可以任意變動，不影響客戶端代碼。當然實做的時候content provider還是會被各種復雜的where子句暴露出sql的實現細節
至於android的許可權管理，其實比較簡單，主要是利用現成的linux安全模型，進程之間相互隔離。api級別的許可權管理和jvm類似。
billy cui重點解析了許可權系統的設計：
android的許可權系統是基於linux，但又增加了很多自己的控制模塊。
總體上來說，其分為以下幾部分許可權系統：
1. userid : 繼承於linux，對於多個app，通過shareuid的方式可以使用同一個userid，主要承擔一些目錄訪問許可權之類的工作，比如私有目錄只能由同一uid應用訪問。
2. 安裝level：system level or app level，這個是根據應用的安裝位置決定的，在system/app下安裝的應用就是system level，在許可權訪問中會得到更多的許可權，比如靜默安裝應用的許可權等。
3. permission : 這個是最主要的許可權控制，一般開發者開發應用主要是接觸這個部分，在這部分中，會根據應用在androidmanifest.xml中聲明的use-permission而在訪問相應api或資源時判斷其是否有訪問許可權，比如常用的android.permission.internet等。
4. signature: 簽名，是android許可權系統中的重要組成部分，對於系統簽名的應用，會有一些特殊的功能，而shareuid等特性也是需要同一簽名作為基礎。此外，permission在設置/自定義其許可權時也經常會使用到簽名，比如控制只有我自己的應用才可以訪問我自己定義的公開api。
除此以外，其實android在uid的裡面設置了一些預定義有特殊功能的uid，比如system/media等，在配置其system level的services的時候會用到。
董兆輝則認為android主要是基於組件搭配思想：
說到android架構的設計思想和原則，按我的理解主要是組件搭配，即在用戶看來，所有的mole或者組件，都是可以重復利用和簡單組合的。想法是好的，不過有得必有失，或者說android現在做的還不夠好，在性能方面是很低的，否則的話android也不會推出補丁（ndk之類的，dalvik的不斷升級）。
我覺得所有framework或者平台或者語言都想給應用開發者最方便使用的介面，最人性化的體驗，同時又要爭取最大的性能，兩者權衡折中吧。不過隨著硬體速度的飛速增長，性能的權重會變低。
范懷宇還談到了資源體系：
android架設在linux之上，因此，繼承了linux可移植性、用戶管理機制、文件系統，等等。
android的核心在framework層，本質上，這是一個基於組件的應用開發系統，組件間通過消息（intent）進行通信。一方面，intent是通信信息的載體，另一方面，intent也定義了android組件的通信協議。
android可以對組件所運行的進程做託管，在android中，進程概念相當薄弱。依賴於進程託管，android可以輕松支撐多任務多進程的應用模型。

⑵ android mvp架構中的presentation層應該怎麼設計

對於mvp（model view presenter），大多數人都能說出一二：「mvc的演化版本」，「讓model和view完全解耦」等等。本篇博文僅是為了做下記錄，提出一些自己的看法，和幫助大家如何針對一個activity頁面去編寫針對mvp風格的代碼。
對於mvp，我的內心有一個問題：
為何這個模式出來後，就能被廣大的android的程序員接受呢？
問了些程序員，他們對於mvp的普遍的認識是：「代碼很清晰，不過增加了很多類」。我在第一次看到mvp的時候，看了一個demo，看完以後覺得非常nice（但是回過頭來，自己想個例子寫，就頭疼寫不出來，當然這在後文會說）。nice的原因還是因為，這個模式的確讓代碼的清晰度有了很大的提升。
那麼，提升一般都是對比出來的，回顧下，沒有應用mvp的代碼結構。很多人說明顯是mvc么：
view：對應於布局文件
model：業務邏輯和實體模型
controllor：對應於activity
看起來的確像那麼回事，但是細細的想想這個view對應於布局文件，其實能做的事情特別少，實際上關於該布局文件中的數據綁定的操作，事件處理的代碼都在activity中，造成了activity既像view又像controller（當然了data-binder的出現，可能會讓view更像view吧）。這可能也就是為何，在該文中有一句這樣的話：
most of the modern android applications just use view-model architecture，everything is connected with activity.
而當將架構改為mvp以後，presenter的出現，將actvity視為view層，presenter負責完成view層與model層的交互。現在是這樣的：
view 對應於activity，負責view的繪制以及與用戶交互
model 依然是業務邏輯和實體模型
presenter 負責完成view於model間的交互
ok，先簡單了解下，文中會有例子到時候可以直觀的感受下。