android體系架構

1. 一般的android開發都用到了系統架構哪些層

一般的android開發都用到了系統架構哪些層?

1：android分為四個層，從高層到低層分別是應用程式層、應用程式框架層
開發一個程式，android系統框架是層層相扣，不能分開的。 應用程式層： 這個層主要指的就是用java語言編寫的執行在虛擬機器上的程式，Google在最開始時就 在android系統中捆綁了一些核心的應用（核心應用的編寫必須使用應用層序框架層的API框架.
2：android 開發框架有四個層，從高層到低層分別是應用程式層、應用程式框架層
android應用開發框架是 Application Framework. 其系統架構由5部分組成，分別是：Linux Kernel、Android Runtime、Libraries、Application Framework、Applications。

android開發一般用哪些框架

開發什麼應用？
硬體還是軟體？
硬體的話，看看這個：
:m2m.temolin./doc/62/m100wu-lian-mo-kuai
軟體的話，看看這個：
:jb51./article/51052.htm

開發安卓APP 系統架構算是C/S架構么？

對於作業系統來言，不存在C/S,B/S一說。
java的確執行效率不如C/C++,但任何開發語言都有其各種特點，有缺點必有優點，否而只能被淘汰。
java有很多過人之處，要不然android也不會看上java作為其應用層的開發語言。
android相比IOS，的確存在距離，但我始終相信以LINUX為核心的android在幾百萬開發者的磨練下，將會越來越完美，「開源」永遠值得人們去琢磨，精益求精！

Solaris支援哪些系統架構?

Solaris支援多種系統架構: SPARC, x86 and x64. x64即AMD64及EMT64處理器。在版本2.5.1的時候，Solaris曾經一度被移植到PowerPC架構, 但是後來又在這一版本正式釋出時被刪去。與Linux相比，Solaris可以更有效地支援對稱多處理器、即SMP架構。Sun同時宣布將在Solaris 10的後續版本中提供Linux執行環境, 允許Linux二進位製程式直接在Solaris x86和x64系統上執行。
Solaris傳統上與基於Sun SPARC處理器的硬體體系結構結合緊密, 在設計上和市場上經常捆綁在一起，整個軟硬體系統的可靠性和效能也因此大大增強。然而SPARC系統的成本和價格通常要高於PC類的產品，這成為Solaris進一步普及的障礙。可喜的是，Solaris對x86體系結構的支援正得到大大加強，特別是Solaris 10已經能很好地支援x64(AMD64/EMT64)架構。Sun公司已推出自行設計的基於AMD64的工作站和伺服器，並隨機附帶Solaris 10。

dalvik虛擬機器屬於android系統架構中的哪一層

dalvik是執行的時候編譯+執行，安裝比較快，開啟應用比較慢，應用佔用空間小
ART是安裝的時候就編譯好了，執行的時候直接就可以執行的，安裝慢，開啟應用快，佔用空間大
用個比喻來說就是，騎腳踏車
dalvik 是已經摺疊起來的腳踏車，每次騎都要先組裝腳踏車才能騎
ART 是已經組裝好的腳踏車，每次騎直接上車就能走人

系統架構鍵亮耐方案有哪些

系統架構屬於系統設計階段，系統架構圖只是這個階段一個產物，要正確的、合理的畫系統架構圖需要全面的理解使用者需求以及業務流程，當理解了這些東西後，剩下的就是如何進行表達了，一般而言，可以參照RUP的用例驅動來進行邏輯架構，開發架構等設計工作，你稿春的系統架構圖可以反應在各個視圖裡面，我估計你所說的系統架構圖是屬於邏輯架構裡面，比鍵枝如分多少層，每層分多少模組等。
至於，繪制的工具，有很多很多。可以選擇微軟的visio,或者EA,rose,power designer等UML建模工具，當然，你甚至可以用PPT,Word來繪制。
當然，系統架構不是一日之功，需長期努力，跟經驗和技術都有很大關系。
今天興致來了，回復了這么多，不知滿意不。

android開發架構的問題

我不是高人，也談不上指點，我只是一個很普通的程式碼工人發表一下自己的看法哈~~
一個activity上多個surfaceview切換的做法是做游戲開發的，現在市面上大多數游戲都是採用的這種做法，並沒有什麼不妥，surfaceview使得畫面更自由，拿到canvas後就不局限於安桌提供的控制元件了，純自由發揮，各種游戲特效表現得更精彩。只是切換surfaceview時稍微麻煩點，需要寫程式碼來手動判斷游戲狀態和控制切換。
如果你只是做普通的應用，安桌提供的控制元件能滿足你的需求，你就用普通的activity唄。用surfaceview多麻煩啊。把切換丟給系統來管理，省去不少事兒。如果你願意麻煩，使用surfaceview來相互手動切換，也沒什麼問題的，放心去做吧。畢竟記憶體管理機制用的是JАVΑ的那一套，自動回收，用哪種架構都差別不大。
個人拙見，手動拼音打字，非ctrl+c/ctrl+v之流。望諸位看官別笑話俺哈~~

系統架構師 要學什麼?哪些學習提供培訓系統架構師?

一個好的IT架構師,眼光不會僅僅停留在寫程式碼的層次上,在做開發的時間里，他們會積極學習各種知識，經驗，培養自己的商業頭腦，包括擴充套件自己各方面的資源，這些積累會為他們未來成為管理者或創業打下牢固的基礎。
對於學習來說我們都是希望可以全面綜合的掌握技術，這樣才有助於你今後的整體發展。目前企業需要的不再是理論型人才了，而是實用技能型人才。
首先我們需要全面掌握專業實用的技術，其次加強個人整體素質的提升，這樣才能符合目前企業的用人需求。如果我們選擇了單科學習無疑是在起跑線上局限了我們的個人發展，或許短期內你覺得只是需要某項單獨的技術，但是你有沒有想過今後你不可能一直從事底層的程式設計師，看著和你同意時間進入公司的同事雖然技術和你不相上下，但是由於掌握的比較全面而被提升為專案主管、專案經理，或許到那個時候你又要為此再一次走進培訓機構，這樣也是耽誤你個人的時間和精力，我相信你也希望自己今後可以步入管理層工作，有一個更好的發展。最好 是 掌握全面的技術,資料庫,JAVA.NET.客戶端技術。

對於Java系統，大家現在都用什麼系統架構

就我接觸到的說一下，我第一家公司專案比較小型是 springmvc + spring + hibernate （也有mabatis的） ，第二家公司，專案是大型的，所以好多是分散式的框架，spring、spring integration、bbo、zookeeper、redis、mybatis等都有用到

「系統架構」是什麼意思？都有哪些架構？

JDE屬於分散式架構,人和系統恕我孤陋寡聞,沒聽過阿

2. NFC開發（一）——HCE基於主機的卡模擬簡述

許多提供NFC功能的基於Android的設備已經支持NFC卡模擬。在大多數情況下，該卡由設備中的單獨晶元模擬，稱為 安全元件(Secure Element) 。無線運營商提供的許多SIM卡還包含安全元件(Secure Element)。

Android 4.4引入了另一種卡模擬方法，它不涉及SE，稱為 基於主機的租芹卡模擬 。這允許任何Android應用程序模擬卡並直接與NFC讀卡器通話。本文檔描述了基於主機的卡肢型裂模擬（HCE）如何在Android上工作，以及如何使用此技術開發模擬NFC卡的應用程序。

當使用安全元件(Secure Element)提供NFC卡模擬時，將通過Android應用程序將要模擬的卡提供到設備上的安全元件(Secure Element)中。然後，當用戶通過NFC終端握住設備時，設備中的NFC控制器將來自讀卡器(NFC Reader)的所有數據直接路由到安全元件(Secure Element)。圖1說明了這個概念。

安全元件(Secure Element)本身執行與NFC終端的通信，並且完全不涉及Android應用。交易完成後，Android應用程序可以直接查詢SE的交易狀態並通知用戶。

當使用基於主機的卡模擬來模擬NFC卡時，數據將被路由到直接運行Android應用程序的主機CPU，而不是將NFC協議幀路由到SE。圖2展示了基於主機的卡模擬如何工作。

NFC標准提供對許多不同協議的支持，並且可以模擬不同類型的卡。

Android 4.4支持當今市場上常見的幾種協議。許多現有的非接觸式卡已經基於這些協議，例如非接觸式支付卡。這些協議也得到了當今市場上眾多NFC讀卡器的支持，其中包括Android NFC設備可以自己作為讀卡器（請參見 IsoDep 課程）。這使您可以僅使用基於Android的設備在HCE周圍構建和部署端到端NFC解決方案。

具體而言，Android 4.4支持基於NFC-Forum ISO-DEP規范（基於ISO / IEC 14443-4）的模擬卡，並處理ISO / IEC 7816-4規范中定義的應用協議數據歷閉單元（APDU）。Android只強制在Nfc-A（ISO / IEC 14443-3 Type A）技術之上模擬ISO-DEP。支持Nfc-B（ISO / IEC 14443-4 Type B）技術是可選的。所有這些規格的分層如圖3所示。

Android中的HCE體系結構基於Android Service 組件（稱為「HCE服務」）。服務的一個關鍵優勢是它可以在沒有任何用戶界面的情況下在後台運行。這對於許多HCE應用程序來說非常合適，例如會員卡或公交卡，用戶不需要啟動應用程序即可使用它。相反，通過NFC讀卡器輕敲設備將啟動正確的服務（如果尚未運行）並在後台執行該事務。當然，如果有意義的話，您可以自由地從您的服務中啟動額外的UI（例如用戶通知）。

當用戶將設備連接到NFC讀取器時，Android系統需要知道NFC讀取器實際想要與哪個HCE服務通話。這就是ISO / IEC 7816-4規范的出處：它定義了一種選擇應用程序的方式，以應用程序ID（AID）為中心。一個AID最多由16個位元組組成。如果您正在模擬現有NFC讀卡器基礎架構的卡片，那麼這些讀卡器所尋找的AID通常是眾所周知的並且是公開注冊的（例如Visa和MasterCard等支付網路的AID）。

如果您想為自己的應用程序部署新的讀卡器基礎結構，則需要注冊您自己的AID。AID的注冊程序在ISO / IEC 7816-5規范中定義。如果您要為Android部署HCE應用程序，Google建議按照7816-5注冊AID，因為它可以避免與其他應用程序發生沖突。

在某些情況下，HCE服務可能需要注冊多個AID才能實現某個應用程序，並且需要確保它是所有這些AID的默認處理程序（而不是組中的某些AID轉到其他服務） 。

一個AID組是應該被OS視為一起歸屬的AID列表。對於AID組中的所有AID，Android會保證以下其中一項：

換句話說，沒有中間狀態，組中的一些AID可以路由到一個HCE服務，另一些AID可路由到另一個。

每個AID組都可以與一個類別關聯。這允許Android按類別將HCE服務組合在一起，並且反過來又允許用戶在類別的級別而不是AID級別設置默認值。通常，避免在應用程序的任何面向用戶的部分提及AID：它們對普通用戶沒有任何意義。

Android 4.4支持兩種類別: CATEGORY_PAYMENT （涵蓋行業標准支付應用程序）和 CATEGORY_OTHER （對於所有其他HCE應用程序）。

要使用基於主機的卡模擬來模擬NFC卡，您需要創建一個 Service 處理NFC事務的組件。

您的應用程序可以通過檢查 FEATURE_NFC_HOST_CARD_EMULATION 功能來檢查設備是否支持HCE 。您應該 <uses-feature> 在應用程序清單中使用該標記來聲明您的應用程序使用HCE功能，以及該應用程序是否需要運行。

Android 4.4帶有一個便利的 Service 類，可以作為實現HCE服務的基礎： HostApService 類。

因此，第一步要擴大 HostApService 。

HostApService 聲明了兩個需要重寫和實現的抽象方法。

processCommandAp() 只要NFC讀卡器將應用協議數據單元（APDU）發送到您的服務，就會調用它。APDU也在ISO / IEC 7816-4規范中定義。APDU是在NFC讀卡器和您的HCE服務之間交換的應用級數據包。該應用級協議是半雙工的：NFC讀卡器會向您發送命令APDU，並等待您發送響應APDU作為回報。

如前所述，Android使用AID來確定讀者想要與哪個HCE服務交談。通常，NFC讀卡器向您的設備發送的第一個APDU是「SELECT AID」APDU; 這個APDU包含讀卡器想與之交談的AID。Android從APDU中提取AID，將其解析為HCE服務，然後將該APDU轉發給已解析的服務。

您可以通過返回響應APDU的位元組來發送響應APDU [processCommandAp()]( https://developer.android.com/reference/android/nfc/cardemulation/HostApService.html#processCommandAp(byte[] , android.os.Bundle))。請注意，此方法將在應用程序的主線程中調用，該線程不應被阻止。所以如果你不能立即計算並返回一個響應APDU，那麼返回null。然後，您可以在另一個線程上完成必要的工作，並 sendResponseAp() 在完成後使用 HostApService 該類中定義的方法發送響應。

Android會繼續將新的APDU從讀取器轉發到您的服務，直到：

在這兩種情況下，你的類的 onDeactivated() 實現都是通過一個參數來調用的，這個參數指出了兩者中的哪一個發生了。

如果您正在使用現有的讀卡器基礎架構，則需要實現讀卡器在您的HCE服務中期望的現有應用程序級協議。

如果您正在部署您控制的新讀卡器基礎架構，則可以定義自己的協議和APDU序列。通常，嘗試限制APDU數量和需要交換的數據大小：這樣可以確保用戶只需將設備通過NFC讀取器持續一段時間即可。合理的上限約為1KB的數據，通常可以在 300ms 內交換。

您的服務必須像往常一樣在清單中聲明，但還必須在服務聲明中添加一些附加件。

首先，為了告訴平台它是一個實現 HostApService 介面的HCE服務 ，你的服務聲明必須包含一個 SERVICE_INTERFACE 動作的 Intent Filter 。

另外，為了告知平台哪個AIDs組被這個服務請求，一個 SERVICE_META_DATA <meta-data> 標簽必須包含在服務的聲明中，指向一個XML資源和關於HCE服務的附加信息。

最後，您必須將該 android:exported 屬性設置為true，並且 "android.permission.BIND_NFC_SERVICE" 在服務聲明中要求許可權。前者確保服務可以被外部應用程序綁定。後者然後強制只有擁有該 "android.permission.BIND_NFC_SERVICE" 許可權的外部應用程序 才能綁定到您的服務。既然 "android.permission.BIND_NFC_SERVICE" 是一個系統許可權，這有效地強制只有Android OS可以綁定到你的服務。

這是一個 HostApService 清單聲明的例子：

這個元數據標簽指向一個 apservice.xml 文件。下面顯示了具有包含兩個專有AID的單個AID組聲明的此類文件的示例：

該 <host-ap-service> 標簽需要包含一個 <android:description> 屬性，該屬性包含可能在UI中顯示的用戶友好的服務描述。該 requireDeviceUnlock 屬性可用於指定在調用此服務來處理APDU之前必須先解鎖設備。

在 <host-ap-service> 必須包含一個或多個 <aid-group> 標簽。每個 <aid-group> 標簽都需要：

最後，您的應用程序還需要擁有 NFC 可以注冊為HCE服務的 許可權。

多個 HostApService 組件可以安裝在單個設備上，並且可以由多個服務注冊相同的AID。Android平台根據AID屬於哪個類別來解決AID沖突。每個類別可能有不同的沖突解決策略。

例如，對於某些類別（如付款），用戶可能能夠在Android設置UI中選擇默認服務。對於其他類別，策略可能總是要求用戶在沖突情況下調用哪個服務。要查詢特定類別的沖突解決策略，請參閱 getSelectionModeForCategory() 。

應用程序可以使用[isDefaultServiceForCategory(ComponentName, String)]( https://developer.android.com/reference/android/nfc/cardemulation/CardEmulation.html#isDefaultServiceForCategory(android.content.ComponentName , java.lang.String))API 檢查其HCE服務是否是某個類別的默認服務。

如果您的服務不是默認設置，則可以請求將其設置為默認設置。看 ACTION_CHANGE_DEFAULT 。

Android會將AID組為「payment」的類別，聲明的HCE服務視為支付應用程序。Android 4.4版本包含一個名為「tap＆pay」的top-level設置菜單條目，它列舉了所有這些支付應用程序。在此設置菜單中，用戶可以選擇在點按付款終端時將調用的默認支付應用程序。

為了提供更具視覺吸引力的用戶體驗，HCE支付應用程序需要為其服務提供額外的resource：所謂的服務標記。

這個asset的大小應該是260x96 dp，並且可以在元數據(meta-data)XML文件中通過添加指向drawable resource android:apServiceBanner 的 <host-ap-service> 標簽的屬性來指定 。一個例子如下所示：

當設備的屏幕關閉時，當前的Android實施將NFC控制器和應用程序處理器完全關閉。因此，當屏幕關閉時，HCE服務將無法工作。

然而，HCE服務可以從鎖定屏幕中起作用：這由HCE服務標記中的 android:requireDeviceUnlock 屬性控制 <host-ap-service> 。默認情況下，不需要設備解鎖，即使設備被鎖定，您的服務也會被調用。

如果您將 android:requireDeviceUnlock HCE服務的屬性設置為「true」，Android會提示用戶在您靠近NFC讀卡器時解鎖設備，NFC讀卡器會選擇已解析為您的服務的AID。解鎖後，Android會顯示一個對話框，提示用戶再次點擊以完成交易。這是必要的，因為用戶可能已經將設備從NFC讀卡器移開以便解鎖它。

本部分對於已經部署依賴SE進行卡模擬的應用程序的開發人員很感興趣。Android的HCE實現旨在與其他實現卡模擬的方法並行工作，包括使用SE。

這種共存基於一種稱為「AID路由」的原則：NFC控制器保留一個由（有限）路由規則列表組成的路由表。每個路由規則都包含一個AID和一個目的地。目標可以是主機CPU（Android應用程序正在運行的地方），也可以是連接的SE。

當NFC讀卡器發送具有「SELECT AID」的APDU時，NFC控制器解析它並檢查AID是否與其路由表中的任何AID匹配。如果匹配，那麼APDU和其後的所有APDU將被發送到與AID相關聯的目的地，直到收到另一個「SELECT AID」 APDU或NFC鏈路斷開。

圖4說明了這種架構。

NFC控制器通常還包含APDU的默認路由。在路由表中找不到AID時，將使用默認路由。盡管此設置可能因設備而異，但Android設備需要確保您的應用注冊的AID已正確路由到主機。

實現HCE服務或使用SE的Android應用程序不必擔心配置路由表 - 這是由Android自動處理的。Android只需要知道哪些AID可以由HCE服務處理，哪些可以由SE處理。基於哪些服務已安裝，以及哪些用戶已配置為首選服務，路由表會自動配置。

我們已經介紹了如何聲明HCE服務的AID。以下部分說明如何為使用SE進行卡模擬的應用程序聲明AID。

使用SE進行卡模擬的應用程序可以在其清單中聲明所謂的「關閉主機服務」。這種服務的聲明幾乎與宣布HCE服務相同。以下情況例外：

相應 apservice.xml 文件注冊兩個AID 的示例：

該 android:requireDeviceUnlock 屬性不適用於脫離主機服務，因為主機CPU不參與事務，因此無法阻止SE在設備鎖定時執行事務。

該 android:apServiceBanner 屬性必須用於作為支付應用程序的關閉主機服務，以便作為默認支付應用程序進行選擇。

Android本身永遠不會啟動或綁定到聲明為「脫離主機」的服務。這是因為實際交易由SE執行，而不是由Android服務本身執行。服務聲明僅允許應用程序注冊安全元件(Secure Element)上存在的AID。

HCE體系結構本身提供了一個核心安全性：因為您的服務受到 BIND_NFC_SERVICE 系統許可權的保護，所以只有操作系統可以綁定到您的服務並與之通信。這可以確保您收到的任何APDU實際上都是OS從NFC控制器接收到的APDU，並且您發回的任何APDU只會發送到操作系統，而操作系統會直接將APDU轉發給NFC控制器。

剩下的核心部分就是您獲取應用程序發送給NFC讀卡器的數據的位置。這在HCE設計中有意解耦：它不關心數據來自何處，它只是確保將其安全地傳送到NFC控制器並傳送到NFC讀取器。

為了安全地存儲和檢索您希望從HCE服務發送的數據，例如，您可以依靠Android應用程序沙箱，將應用程序的數據與其他應用程序隔離。有關Android安全性的更多詳細信息，請閱讀 安全提示 。

這部分內容對於希望了解HCE設備在NFC協議的防沖突和激活階段使用何種協議參數的開發人員很感興趣。這允許構建與Android HCE設備兼容的讀卡器基礎結構。

作為Nfc-A協議激活的一部分，交換多個幀。

在交換的第一部分，HCE設備將呈現其UID; HCE設備應該被假定為具有隨機的UID。這意味著在每個抽頭中，呈現給讀卡器的UID將是隨機生成的UID。因此，NFC讀卡器不應依賴HCE設備的UID作為身份驗證或身份驗證的一種形式。

NFC讀取器可以隨後通過發送SEL_REQ命令來選擇HCE設備。HCE設備的SEL_RES響應將至少設置第6位（0x20），表示設備支持ISO-DEP。注意，SEL_RES中的其他位也可以被設置，表示例如對NFC-DEP（p2p）協議的支持。由於可以設置其他位，所以想要與HCE設備交互的讀者應該明確檢查第6位，並且<stront style="box-sizing: inherit;">不要將完整的SEL_RES與值0x20進行比較。</stront>

Nfc-A協議激活後，NFC讀取器啟動ISO-DEP協議激活。它發送一個「RATS」（請求選擇應答）命令。RATS響應（ATS）完全由NFC控制器生成，不能由HCE服務配置。然而，HCE實現需要滿足NFC論壇對ATS響應的要求，因此NFC讀卡器可以根據NFC論壇對任何HCE設備的要求設置這些參數。

以下部分提供了有關NFC控制器在HCE設備上提供的ATS響應的各個位元組的更多詳細信息：

請注意，許多HCE設備可能符合EMVCo聯合的支付網路在其「非接觸式通信協議」規范中指定的協議要求。尤其是：

如前所述，HCE實現僅支持單個邏輯通道。嘗試在不同的邏輯通道上選擇應用程序將不適用於HCE設備。

本文 翻譯自 谷歌開發者文檔，已由本人仔細校對。如有錯誤，請聯系我，以便修改。

3. 什麼是android系統，android的發展以及android的平台架構和特性

Android平台採用了整合的策略思想，包括底層Linux操作系統、中間層的中間件和上層的Java應用程序。下面我把Android的特性及其架構體系結構總結一下。

一、Android的平台特性

Android平台有如下特性：

1. 應用程序框架支持組件的重用與替換。

這樣我們可以把系統中不喜歡的應用程序刪除，安裝我們喜歡的應用程序。

2. Dalvik虛擬機專門為移動設備進行了優化。

Android應用程序將由Java編寫、編譯的類文件通過DX工具轉換成一種後綴名為.dex的文件來執行。Dalvik虛擬機是基於寄存器的，相對於Java虛擬機速度要快很多。

3. 內部集成瀏覽器基於開源的WebKit引擎。

有了內置的瀏覽器，這將意味著WAP應用的時代即將結束，真正的移動互聯網時代已經來臨，手機就是一台「小電腦」，可以在網上隨意遨遊。

4. 優化的圖形庫包括2D和3D圖形庫，3D圖形庫基於OpenGL ES 1.0。

強大的圖形庫給游戲開發帶來福音。在3G最為重要的的應用莫過於手機上網和手機游戲。

5. SQLite用作結構化的數據存儲。

6. 多媒體支持包括常見的音頻、視頻和靜態印象文件格式

如MPEG4、H.264、MP3、AAC、AMR、JGP、PNG、GIF。

7. GSM電話（依賴於硬體）。

8. 藍牙（Bluetooth）、EDGE、3G、WiFi（依賴於硬體）。

9. 照相機、GPS、指南針和加速度計（依賴於硬體）。

10. 豐富的開發環境包括設備模擬器、調試工具、內存及性能分析圖表和Eclipse集成的開發環境插件。

Google提供了Android開發包SDK，其中包含了大量的類庫和開發工具，並且針對Eclipse的可視化開發插件ADT。

二、Android平台架構

從上圖我們可以看出，Android操作系統的體系結構可分為4層，由上到下依次是應用程序、應用程序框架、核心類庫和Linux內核，其中第三層還包括Android運行時的環境。下面分別來講解各個部分。

1. 程序應用

Android
連同一個核心應用程序包一起發布，該應用程序包包括E-mail客戶端、SMS短消息程序、日歷、地圖、瀏覽器、聯系人管理程序等。所有的應用程序都是用Java編寫的。

2. 應用程序框架

開發者完全可以訪問核心應用程序所使用的API框架。該應用程序框架架構用來簡化組件軟體的重用，任何一個應用程序都可以發布它的功能塊並且任何其他的應用程序都可以使用其所發布的功能塊（不過得遵循框架的安全性限制）。該應用程序重用機制使得組件可以被用戶替換。

以下所有的應用程序都由一系列的服務和系統組成，包括：

1）一個可擴展的視圖（Views）可以用來創建應用程序，包括列表（lists）、網路（grids）、文本框（text
boxes）、按鈕（buttons），甚至是一個可嵌入的Web瀏覽器。

2）內容管理器（Content Providers）使得應用程序可以訪問另一個應用程序的數據（如聯系人資料庫），或者共享它們自己的數據。

3）一個資源管理器（Resource Manager）提供非代碼資源的訪問，如本地字元串、圖形和分層文件（layout files）。

4）一個通知管理器（Notification Manager）使得應用程序可以在狀態欄中顯示客戶通知信息。

5）一個活動類管理器（Activity Manager）用來管理應用程序生命周期並提供常用的導航回退功能。

3. Android程序庫

Android包括一個被Android系統中各種不同組件所使用的C/C++集庫。該庫通過Android應用程序框架為開發者提供服務。

以下是一些主要的核心庫：

1）系統C庫：一個從BSD繼承來的標准C系統函數庫（libc），專門為基於Embedded Linux的設備定製。

2）媒體庫：基於PacketVideo
OpenCORE；該庫支持錄放，並且可以錄制許多流行的音頻視頻格式，還有靜態映像文件包括MPEG4、H.264、MP3、AAC、JPG、PNG。

3）Surface Manager：對顯示子系統的管理，並且為多個應用程序提供2D和3D圖層的無縫融合。

4）LibWebCore：一個最新的Web瀏覽器引擎，用來支持Android瀏覽器和一個可嵌入的Web視圖。

5）SGL：一個內置的2D圖形引擎。

6）3D libraries：基於OpenGL ES 1.0 APIs實現；該庫可以使用硬體3D加速(如果可用）或者使用高度優化的3D軟加速。

7）FreeType：點陣圖（bitmap）和向量（vector）字體顯示。

8）SQLite：一個對於所以應用程序可用、功能強勁的輕型關系型資料庫引擎。

4. Android運行庫

Android包括了一個核心庫，該核心庫提供了Java編程語言核心庫的大多數功能。

每一個Android應用程序都在它自己的進程中運行，都擁有一個獨立的Dalvik虛擬機實例。Dalvik是針對同時高效地運行多個VMs實現的。Dalvik虛擬機執行.dex的Dalvik可執行文件，該格式文件針對最小內存使用做了優化。該虛擬機是基於寄存器的，所有的類都是經由Java匯編器編譯，然後通過SDK中的DX工具轉化成.dex格式由虛擬機執行。

Dalvik虛擬機依賴於Linux的一些功能，比如線程機制和底層內存管理機制。

5. Linux內核

Android的核心系統服務依賴於Linux內核，如安全性、內存管理、進程管理、網路協議棧和驅動模型。Linux內核也同時作為硬體和軟體棧之間的硬體抽象層。

4. android系統 主要有哪幾部分

android系統分為四部分，從高到低分別是：

1、Android應用層

2、Android應用框架層

3、Android系統運行層

4、Linux內核層

Android系統構架主要應用於ARM平台，但不僅限於ARM，通過編譯控制，在X86、MAC等體系結構的機器上同樣可以運行。

(4)android體系架構擴展閱讀：

Android運行庫

Android包括了一個核心庫，該核心庫提供了JAVA編程語言核心庫的大多數功能。

每一個Android都擁有一個獨立的Dalvik虛擬機實例。Dalvik被設計成一個設備可以同時高效地運行多個虛擬系統。Dalvik虛擬機執行(.dex)的Dalvik可執行文件，該格式文件針對小內存使用做了優化。

同時虛擬機是基於寄存器的，所有的類都經由JAVA編譯器編譯，然後通過SDK中的「dx」工具轉化成.dex格式由虛擬機執行。

5. 安卓架構中最底層是哪個

Android系統構架是安卓系統的體系結構，android的系統架構和其操作系統一樣，採用了分層的架構，共分為四層，從高到低分別是Android應用層，Android應用框架層，Android系統運行庫層和Linux內核層。
Android系統構架主要應用於ARM平台，但不僅限於ARM，通過編譯控制，在X86、MAC等體系結構的機器上同樣可以運行。
中文名
安卓系統構架
外文名
Android systematic framework
Android系統架構分為四層架構，從高到低分別是應用層，應用框架層，系統運行層和Linux內核層。
Android系統體系結構
1.應用層
Android會同一系列核心應用程序包一起發布，該應用程序包包括email客戶端，SMS短消息程序，日歷，地圖，瀏覽器，聯系人管理程序等。它們一般都是使用Java進行編寫。
2.應用框架層
開發人員也可以完全訪問核心應用程序所使用的API框架。該應用程序的架構設計簡化了組件的重用;任何一個應用程序都可以發布它的功能塊並且任何其它的應用程序都可以使用其所發布的功能塊(不過得遵循框架的安全性限制)。同樣，該應用程序重用機制也使用戶可以方便的替換程序組件。

6. 簡述android應用程序結構是哪些

android應用開發框架是ApplicationFramework.其系統架構由5部分組成，分別是：LinuxKernel、AndroidRuntime、Libraries、ApplicationFramework、Applications。第二部分將詳細介紹這5個部分。下面自底向上分析各層。Android架構1、LinuxKernelAndroid基於Linux2.6提供核心系統服務，例如：安全、內存管理、進程管理、網路堆棧、驅動模型。LinuxKernel也作為硬體和軟體之間的抽象層，它隱藏具體硬體細節而為上層提供統一的服務。如果你學過計算機網路知道OSI/RM，就會知道分層的好處就是使用下層提供的服務而為上層提供統一的服務，屏蔽本層及以下層的差異，當本層及以下層發生了變化不會影響到上層。也就是說各層各盡其職，各層提供固定的SAP（ServiceAccessPoint），專業點可以說是高內聚、低耦合。如果你只是做應用開發，就不需要深入了解LinuxKernel層。2、AndroidRuntimeAndroid包含一個核心庫的集合，提供大部分在Java編程語言核心類庫中可用的功能。每一個Android應用程序是Dalvik虛擬機中的實例，運行在他們自己的進程中。Dalvik虛擬機設計成，在一個設備可以高效地運行多個虛擬機。Dalvik虛擬機可執行文件格式是.dex，dex格式是專為Dalvik設計的一種壓縮格式，適合內存和處理器速度有限的系統。大多數虛擬機包括JVM都是基於棧的，而Dalvik虛擬機則是基於寄存器的。兩種架構各有優劣，一般而言，基於棧的機器需要指令，而基於寄存器的機器指令更大。dx是一套工具，可以將Java.class轉換成.dex格式。一個dex文件通常會有多個.class。由於dex有時必須進行最佳化，會使文件大小增加1-4倍，以ODEX結尾。Dalvik虛擬機依賴於Linux內核提供基本功能，如線程和底層內存管理。3、LibrariesAndroid包含一個C/C++庫的集合，供Android系統的各個組件使用。這些功能通過Android的應用程序框架（applicationframework）暴露給開發者。下面列出一些核心庫：系統C庫--標准C系統庫（libc）的BSD衍生，調整為基於嵌入式Linux設備媒體庫--基於PacketVideo的OpenCORE。這些庫支持播放和錄制許多流行的音頻和視頻格式，以及靜態圖像文件，包括MPEG4、H.264、MP3、AAC、AMR、JPG、PNG界面管理--管理訪問顯示子系統和無縫組合多個應用程序的二維和三維圖形層LibWebCore--新式的Web瀏覽器引擎,驅動Android瀏覽器和內嵌的web視圖SGL--基本的2D圖形引擎3D庫--基於OpenGLES1.0APIs的實現。庫使用硬體3D加速或包含高度優化的3D軟體光柵FreeType--點陣圖和矢量字體渲染SQLite--所有應用程序都可以使用的強大而輕量級的關系資料庫引擎4、ApplicationFramework通過提供開放的開發平台，Android使開發者能夠編制極其豐富和新穎的應用程序。開發者可以自由地利用設備硬體優勢、訪問位置信息、運行後台服務、設置鬧鍾、向狀態欄添加通知等等，很多很多。開發者可以完全使用核心應用程序所使用的框架APIs。應用程序的體系結構旨在簡化組件的重用，任何應用程序都能發布他的功能且任何其他應用程序可以使用這些功能（需要服從框架執行的安全限制）。這一機制允許用戶替換組件。所有的應用程序其實是一組服務和系統，包括：視圖（View）--豐富的、可擴展的視圖集合，可用於構建一個應用程序。包括包括列表、網格、文本框、按鈕，甚至是內嵌的網頁瀏覽器內容提供者（ContentProviders）--使應用程序能訪問其他應用程序（如通訊錄）的數據，或共享自己的數據資源管理器（ResourceManager）--提供訪問非代碼資源，如本地化字元串、圖形和布局文件通知管理器（NotificationManager）--使所有的應用程序能夠在狀態欄顯示自定義警告活動管理器（ActivityManager）--管理應用程序生命周期,提供通用的導航回退功能5、ApplicationsAndroid裝配一個核心應用程序集合，包括電子郵件客戶端、SMS程序、日歷、地圖、瀏覽器、聯系人和其他設置。所有應用程序都是用Java編程語言寫的。更加豐富的應用程序有待我們去開發！從上面我們知道Android的架構是分層的，非常清晰，分工很明確。Android本身是一套軟體堆迭(SoftwareStack)，或稱為「軟體迭層架構」，迭層主要分成三層：操作系統、中間件、應用程序。從上面我們也看到了開源的力量，一個個熟悉的開源軟體在這里貢獻了自己的一份力量。