android系統資源

『壹』 怎樣 訪問 android 系統資源

利用手機的wifi功能通過無線網路訪問電腦上的資源： 第一步：在手機上安裝ES文件瀏覽器，並且在電腦上設置一個共享目錄 第二步：打開手機的wifi功能，連接到電腦所在的區域網，也就是說必須保證手機和電腦在同一個區域網內第三步：（沒有設置登陸密碼的用戶）進入ES瀏覽器，點擊左上角的本地字樣，選擇「共享」>「新建」>"掃描" OK了。既可訪問你的電腦了。 （設置登陸密碼的用戶）： 第四步：選擇「新建」之後會彈出一個對話框，選擇「服務(server)」，接著就會需要你輸入一些數據，之後保存。如下： domain：這個可以不填 server：這個必須填，就是你需要訪問電腦的IP username：電腦登陸時的用戶名 password：登陸密碼 display as：顯示為。這個欄位的意思是建立的訪問圖標的顯示名 第五步：上述完成之後就會在開始進來的LAN頁面出現一個以display as明名的圖標，點擊，過一段時間就會看到你電腦上可以訪問到的共享文件，之後的復制和粘貼就看各位的需要了。 以上是第一種方法，這種方式適合於電腦設置了登錄密碼和且需要經常訪問的用戶。 ES文件瀏覽器下載地址as/a/item?docid=651957&f=web_alad_6

『貳』 什麼是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內核也同時作為硬體和軟體棧之間的硬體抽象層。

『叄』 Android四大組件是什麼講講你對它們的理解

Android有四大組件：Activity、Service、Broadcast Receiver、Content Provider。

Activity

做一個完整的Android程序，不想用到Activity，真的是比較困難的一件事情，除非是想做綠葉想瘋了。因為Activity是Android程序與用戶交互的窗口，在我看來，從這個層面的視角來看，Android的Activity特像網站的頁面。

Activity，在四大組件中，無疑是最復雜的，這年頭，一樣東西和界面掛上了勾，都簡化不了，想一想，獨立做一個應用有多少時間淪落在了界面上，就能琢磨清楚了。從視覺效果來看，一個Activity占據當前的窗口，響應所有窗口事件，具備有控制項，菜單等界面元素。從內部邏輯來看，Activity需要為了保持各個界面狀態，需要做很多持久化的事情，還需要妥善管理生命周期，和一些轉跳邏輯。對於開發者而言，就需要派生一個Activity的子類，然後埋頭苦幹上述事情。對於Activity的更多細節，先可以參見：reference/android/app/Activity.html。後續，會獻上更為詳盡的剖析。

Service

服務，從最直白的視角來看，就是剝離了界面的Activity，它們在很多Android的概念方面比較接近，都是封裝有一個完整的功能邏輯實現，只不過Service不拋頭露臉，只是默默無聲的做堅實的後盾。

但其實，換個角度來看，Android中的服務，和我們通常說的Windows服務，Web的後台服務又有一些相近，它們通常都是後台長時間運行，接受上層指令，完成相關事務的模塊。用運行模式來看，Activity是跳，從一個跳到一個，呃...，這有點像模態對話框（或者還像web頁面好了...），給一個輸入（抑或沒有...），然後不管不顧的讓它運行，離開時返回輸出（同抑或沒有...）。

而Service不是，它是等，等著上層連接上它，然後產生一段持久而纏綿的通信，這就像一個用了Ajax頁面，看著沒啥變化，偷偷摸摸的和Service不知眉來眼去多少回了。

但和一般的Service還是有所不同，Android的Service和所有四大組件一樣，其進程模型都是可以配置的，調用方和發布方都可以有權利來選擇是把這個組件運行在同一個進程下，還是不同的進程下。這句話，可以拿把指甲刀刻進腦海中去，它凸顯了Android的運行特徵。如果一個 Service，是有期望運行在於調用方不同進程的時候，就需要利用Android提供的RPC機制，為其部署一套進程間通信的策略。

Android的RPC實現，如上圖所示（好吧，也是從SDK中拿來主義的...），無甚稀奇，基於代理模式的一個實現，在調用端和服務端都去生成一個代理類，做一些序列化和反序列化的事情，使得調用端和伺服器端都可以像調用一個本地介面一樣使用RPC介面。

Android中用來做數據序列化的類是Parcel，參見：/reference/android/os/Parcel.html，封裝了序列化的細節，向外提供了足夠對象化的訪問介面，Android號稱實現非常高效。

還有就是AIDL (Android Interface Definition Language) ，一種介面定義的語言，服務的RPC介面，可以用AIDL來描述，這樣，ADT就可以幫助你自動生成一整套的代理模式需要用到的類，都是想起來很乏力寫起來很苦力的那種。更多內容，可以再看看：guide/developing/tools/aidl.html，如果有興致，可以找些其他PRC實現的資料lou幾眼。

關於Service的實現，還強推參看API Demos這個Sample裡面的RemoteService實現。它完整的展示了實現一個Service需要做的事情：那就是定義好需要接受的Intent，提供同步或非同步的介面，在上層綁定了它後，通過這些介面（很多時候都是RPC的...）進行通信。在RPC介面中使用的數據、回調介面對象，如果不是標準的系統實現（系統可序列化的），則需要自定義aidl，所有一切，在這個Sample里都有表達，強薦。

Service從實現角度看，最特別的就是這些RPC的實現了，其他內容，都會接近於Activity的一些實現，也許不再會詳述了。

Broadcast Receiver

在實際應用中，我們常需要等，等待系統抑或其他應用發出一道指令，為自己的應用擦亮明燈指明方向。而這種等待，在很多的平台上，都會需要付出不小的代價。

比如，在Symbian中，你要等待一個來電消息，顯示歸屬地之類的，必須讓自己的應用忍辱負重偷偷摸摸的開機啟動，消隱圖標隱藏任務項，潛伏在後台，監控著相關事件，等待轉瞬即逝的出手機會。這是一件很發指的事情，不但白白耗費了系統資源，還留了個流氓軟體的罵名，這真是賣力不討好的正面典型。

在Android中，充分考慮了廣泛的這類需求，於是就有了Broadcast Receiver這樣的一個組件。每個Broadcast Receiver都可以接收一種或若干種Intent作為觸發事件（有不知道Intent的么，後面會知道了...），當發生這樣事件的時候，系統會負責喚醒或傳遞消息到該Broadcast Receiver，任其處置。在此之前和這以後，Broadcast Receiver是否在運行都變得不重要了，及其綠色環保。

這個實現機制，顯然是基於一種注冊方式的，Broadcast Receiver將其特徵描述並注冊在系統中，根據注冊時機，可以分為兩類，被我冠名為冷熱插拔。所謂冷插拔，就是Broadcast Receiver的相關信息寫在配置文件中（求配置文件詳情？稍安，後續奉上...），系統會負責在相關事件發生的時候及時通知到該Broadcast Receiver，這種模式適合於這樣的場景。某事件方式 -> 通知Broadcast -> 啟動相關處理應用。比如，監聽來電、郵件、簡訊之類的，都隸屬於這種模式。而熱插拔，顧名思義，插拔這樣的事情，都是由應用自己來處理的，通常是在 OnResume事件中通過registerReceiver進行注冊，在OnPause等事件中反注冊，通過這種方式使其能夠在運行期間保持對相關事件的關注。比如，一款優秀的詞典軟體（比如，有道詞典...），可能會有在運行期間關注網路狀況變化的需求，使其可以在有廉價網路的時候優先使用網路查詢詞彙，在其他情況下，首先通過本地詞庫來查詞，從而兼顧腰包和體驗，一舉兩得一石二鳥一箭雙雕（注，真實在有道詞典中有這樣的能力，但不是通過 Broadcast Receiver實現的，僅以為例...）。而這樣的監聽，只需要在其工作狀態下保持就好，不運行的時候，管你是天大的網路變化，與我何干。其模式可以歸結為：啟動應用 -> 監聽事件 -> 發生時進行處理。

除了接受消息的一方有多種模式，發送者也有很重要的選擇權。通常，發送這有兩類，一個就是系統本身，我們稱之為系統Broadcast消息，在reference/android/content/Intent.html 的Standard Broadcast Actions，可以求到相關消息的詳情。除了系統，自定義的應用可以放出Broadcast消息，通過的介面可以是 Context.sendBroadcast，抑或是Context.sendOrderedBroadcast。前者發出的稱為Normal broadcast，所有關注該消息的Receiver，都有機會獲得並進行處理；後者放出的稱作Ordered broadcasts，顧名思義，接受者需要按資排輩，排在後面的只能吃前面吃剩下的，前面的心情不好私吞了，後面的只能喝西北風了。

當Broadcast Receiver接收到相關的消息，它們通常做一些簡單的處理，然後轉化稱為一條Notification，一次振鈴，一次震動，抑或是啟動一個 Activity進行進一步的交互和處理。所以，雖然Broadcast整個邏輯不復雜，卻是足夠有用和好用，它統一了Android的事件廣播模型，讓很多平台都相形見絀了。更多Broadcast Receiver相關內容，參見：/reference/android/content/BroadcastReceiver.html。

Content Provider

Content Provider，聽著就和數據相關，沒錯，這就是Android提供的第三方應用數據的訪問方案。在Android中，對數據的保護是很嚴密的，除了放在SD卡中的數據，一個應用所持有的資料庫、文件、等等內容，都是不允許其他直接訪問的，但有時候，溝通是必要的，不僅對第三方很重要，對應用自己也很重要。

比如，一個聯系人管理的應用。如果不允許第三方的應用對其聯系人資料庫進行增刪該查，整個應用就失去了可擴展力，必將被其他應用拋棄，然後另立門戶，自個玩自個的去了。

Andorid當然不會真的把每個應用都做成一座孤島，它為所有應用都准備了一扇窗，這就是Content Provider。應用想對外提供的數據，可以通過派生ContentProvider類， 封裝成一枚Content Provider，每個Content Provider都用一個uri作為獨立的標識，形如：content://com.xxxxx。所有東西看著像REST的樣子，但實際上，它比REST 更為靈活。和REST類似，uri也可以有兩種類型，一種是帶id的，另一種是列

表的，但實現者不需要按照這個模式來做，給你id的uri你也可以返回列表類型的數據，只要調用者明白，就無妨，不用苛求所謂的REST。

另外，Content Provider不和REST一樣只有uri可用，還可以接受Projection，Selection，OrderBy等參數，這樣，就可以像資料庫那樣進行投影，選擇和排序。查詢到的結果，以Cursor（參見：reference/android/database/Cursor.html ）的形式進行返回，調用者可以移動Cursor來訪問各列的數據。

Content Provider屏蔽了內部數據的存儲細節，向外提供了上述統一的介面模型，這樣的抽象層次，大大簡化了上層應用的書寫，也對數據的整合提供了更方便的途徑。Content Provider內部，常用資料庫來實現，Android提供了強大的Sqlite支持，但很多時候，你也可以封裝文件或其他混合的數據。

在Android中，ContentResolver是用來發起Content Provider的定位和訪問的。不過它僅提供了同步訪問的Content Provider的介面。但通常，Content Provider需要訪問的可能是資料庫等大數據源，效率上不足夠快，會導致調用線程的擁塞。因此Android提供了一個AsyncQueryHandler（參見：reference/android/content/AsyncQueryHandler.html），幫助進行非同步訪問Content Provider。

在各大組件中，Service和Content Provider都是那種需要持續訪問的。Service如果是一個耗時的場景，往往會提供非同步訪問的介面，而Content Provider不論效率如何，都提供的是約定的同步訪問介面。我想這遵循的就是場景導向設計的原則，因為Content Provider僅是提供數據訪問的，它不能確信具體的使用場景如何，會怎樣使用它的數據；而相比之下，Service包含的邏輯更復雜更完整，可以抉擇大部分時候使用某介面的場景，從而確定最貼切的介面是同步還是非同步，簡化了上層調用的邏輯。