(轉)android系統開發 AP 和 BP 簡要說明

來源:互聯網
上載者:User

標籤:垃圾收集器   完成   佔用   嚴格   d語言   智能   控制項   .net   str   

手機的AP和BP根據上下文可以指代硬體和軟體兩種意思. 
 
1) 大多數的手機都含有兩個處理器。作業系統、使用者介面和應用程式都在Application Processor(AP)上執行,AP一般採用ARM晶片的CPU。而手機射頻通訊控制軟體,則運行在另一個分開的CPU上,這個CPU稱為Baseband Processor(BP)。 
把射頻功能放在BP上執行的主要原因是:射頻控制函數(訊號調製、編碼、射頻位移等)都是高度時間相關的。最好的辦法就是把這些函數放在一個主CPU上執行,並且這個主CPU是運行即時作業系統的。 
另外一個使用BP的好處是一旦它被設計和認證為好了的,不管你採用的作業系統和應用軟體怎麼變化,它都可以正確的執行功能(它的通訊功能)。另外,作業系統和驅動的bug也不會導致裝置發送災難性的資料到移動網路中。(FCC要求的) 
由於AP和BP是分開的裝置,手機設計者可以更加自由的設計使用者介面和應用軟體。 

2)手機開發商,比如摩托羅拉,會將開發的手機軟體包分為AP和BP兩部分, 運行在Application Processor(AP)的軟體包稱為AP包,包括作業系統、使用者介面和應用程式等; 與Baseband Processor(BP)相關的軟體包稱為BP包, 包括baseband modem的通訊控制軟體等. 相應地, 所謂的重新整理手機AP和BP檔案即是將這兩個軟體封裝更新到手機上. 為方便刷機, 也有將AP,BP檔案和flex檔案(手機的參數設定檔)作在一起的一體包.

 

AP+BP二者之間通過共用記憶體來通訊!!!!!

 


http://www.eoeandroid.com/thread-19996-1-1.html

從功能上講對於智能手機的一個粗略的概括是,智能手機 == 電腦 + 移動網卡,或者更準確地說,智能手機的硬體結構分為應用程式處理器AP,和基帶處理器BP兩個部分。這裡隱含著兩個問題,

1. BP部分與AP部分的整合。

2. 傳統的功能手機只配備了出廠時預裝的應用軟體,而不允許使用者自主下載並安裝第三方應用軟體,而智能手機突破了這一限制,因此智能手機的AP部分,必須有相應的開放機制,方便第三方軟體的開發與安裝,同時儘可能降低第三方軟體造成對整個系統,包括其它軟體的惡意傷害。更進一步說,智能手機的開放機制,不僅針對第三方軟體,而且也針對手機生產廠家,允許手機生產廠家更換手機系統的部分硬體裝置,或者增設其它外設硬體裝置,做到一個通用平台可以出貨多個手機型號,協助手機生產廠家儘可能降低手機研發費用。

對於第一個問題,BP部分如何與AP部分整合,解決方案的思路很簡單。翻開任何一本作業系統教科書,都可以看到標準的分層結構,應用軟體 >> 作業系統 >> 磁碟機 >> 硬體。不妨把BP與AP的整合,與作業系統中的檔案系統的構成相比較。

檔案系統通常包括虛擬檔案系統(Virtual File System,VFS)與實際存放裝置(Storage Device)兩部分。實際存放裝置包括快閃記憶體或者硬碟等等儲存硬體,以及相應磁碟機。虛擬檔案系統通過磁碟機操縱儲存硬體,在這個基礎上實現檔案和檔案夾的建立與刪除,檔案讀寫等等功能。虛擬檔案系統之所以被稱為虛擬,是因為應用軟體通過標準的介面(APIs),來調用虛擬檔案系統實現的檔案和檔案夾的功能,而與實際存放裝置究竟用的是哪一家廠商出品的硬體和磁碟機無關[1]。

如果把檔案系統中的實際儲存系統類別比成智能手機的BP部分,那麼虛擬檔案系統相對應的是AP部分中的Telephony Stack。Telephony Stack提供三個功能,

1. 與BP部分的系統間通訊(Inter-Processor Communication,IPC),給BP部分下達指令,建立通訊通道,發送及接受語音和資料資訊。IPC的實現方式可以是通過傳遞AT-Command,也可以是利用共用記憶體來實現資料交換。

2. 圍繞BP部分提供的三大基礎功能,即語音通話,簡訊等資料通訊,以及SIM卡管理,加上與之密切相關的電話本(Address Book),提供以下服務,
  - 撥打到電話:發起或接受語音電話。
  - 簡訊管理:編輯簡訊,傳送簡訊,接受簡訊,刪除,回複或者轉寄簡訊等等。
  - 通話曆史。
  - 電話本。
  - 手機響鈴及震動設定。
  - SIM卡管理。

3. 提供標準的調用介面(Telephony APIs, TAPI),方便應用軟體調用上述服務。

Figure 13-1描述的是WinMobile 6的AP系統中,Telephony Stack的內部結構。圖中紫色部分的模組,嚴格來說,並不屬於Telephony Stack,它們是應用軟體,它們通過調用Telephony APIs來使用黃色部分模組的功能。黃色部分的模組,負責實現撥打到電話,簡訊管理,SIM卡管理,通話曆史等等功能,稱作cellcore,由 cellcore.dll提供,手機設計廠家不可以更改cellcore。藍色部分模組,主要是RIL(Radio Interface Layer),它負責AP部分與BP部分之間的系統間通訊。RIL部分是硬體相關的,由手機Design House或者BP部分生產廠家完成
Figure 13-1. WinMobile Telephony Stack.
Courtesy 

第一個問題,BP與AP的整合,比較容易解決。第二個問題,AP的開放機制,提供調用系統資源的標準介面,既方便第三方軟體的開發與安裝,同時也儘可能降低開放的風險,這個問題不太容易解決。什麼方式的調用介面才算方便,什麼程度的風險控制才算安全,這兩個指標都缺乏公認的衡量準則。在當前情況下我們能做的,或許是比較幾個智能手機的AP部分的設計,分析一下誰更方便更安全。

Figure 13-2描述的是,Telephony Stack在整個WinMobile系統中的位置,由紅色方框界定。WinMobile為第三方軟體提供了Win32 APIs,Win32 APIs不僅提供了分配記憶體,控制進程與線程,讀寫檔案,串連網路等等準系統的調用介面(APIs),也提供了開啟和關閉視窗,以及控制視窗控制項的GUI相關的APIs。

Figure 13-2. WinMobile Architecture.
Courtesy 

Win32 APIs功能全面,但是使用難度大。很多APIs附帶的參數很多,很多重複性的工作沒有被封裝,導致應用軟體的開發,不僅代碼量大,而且容易出錯。有鑒於此,微軟把純C的Win32 APIs,用VC++重新封裝,形成MFC(Microsoft Foundation Classes)。作為一種Object-Oriented語言,VC++具有封裝(Encapsulation),多態(Polymorphism),繼承(Inheritage)等等特性。MFC利用 VC++這些特性,大大簡化了對Win32 APIs的調用方式,程式員可以用更精簡的代碼,完成應用軟體的開發。

微軟把MFC稱為一種Application Framework。Application Framework這個概念的興起,源於尋求降低GUI開發的難度。GUI的開發,涉及圖形,布局,事件捕捉與響應,訊息傳遞等等諸多技術,不僅入門難,而且容易出錯。Application Framework藉助多種編程環境(IDE),工具集,和軟體系統定式,例如MVC定式,不僅簡化了編程的複雜度,而且通過規範編程方式,降低了出錯的風險[2]。

MFC中的Object,可以直接分配記憶體,所以當清除Object時,需要手工清除記憶體配置,不留殘餘。防範記憶體流失,不僅是應用軟體開發過程中的痛點,也是容易出現bug。如果把MFC中的Object,稱為原生態的Object(Native Object),那麼Jave和C#/.NET中的Object,是受管制的Object(Managed Object)。所謂受管制,主要體現在Virtual Machine中的垃圾收集器(Garbage Collector)負責管理它們佔用的記憶體空間,而不需要編程者手工分配記憶體,與清除記憶體。

Google的智能手機OS,Android,把Telephony功能封裝成Java Object,Telephony Manager。依此類推,把GPS功能也封裝成Java Object,Location Manager,此外還有Resource Manager等等。通過這些Manager Java Object,把外設硬體(peripheral)的功能封裝起來,提供簡單的調用介面,降低了應用軟體開發的難度,提高了程式員的生產力。同時,還提供 Activity Manager,Window Manager,Content Provider,View System,Notification Manager等等,簡化並規範GUI的開發[3,4]。

這些Java Object運行在Virtual Machine上,它們的記憶體佔用受Garbage Collector管制,從而降低了記憶體泄露的風險。另外,Android給每個應用軟體都分配了獨立的VM實體,如果某個應用軟體出錯,導致支撐其啟動並執行VM實體崩潰,但是通常不會殃及運行其它應用軟體的VM實體,從而提高了系統的整體安全。

與MFC相比,Android的 Application Framework,更方便,更安全。當然也有代價,代價是損耗了運行速度。

Figure 13-3. Android Architecture [4].
Courtesy 

Android 的開放機制,不僅體現在Application Framework,而且還體現在Hardware Abstraction Layer(HAL)。關於設定HAL的意義,Google有三點說明[4],

1. 為各種硬體器件制訂標準的磁碟機介面。

2. 由於Android的核心是開源的,服從GPL許可。而有些硬體器件廠商不願意開源他們的磁碟機程式,有了HAL這個隔離帶,就可以解決開源的核心與不開源的硬體磁碟機之間的矛盾。

3. Android對於硬體磁碟機有一定要求。

這三點說明涉及手機製造產業鏈上的三個參與者,

1. 如果有標準的磁碟機介面,最大的受益者是手機生產廠商。只要硬體外設生產商按照標準介面提供相應的硬體驅動程式,手機生產商就可以自由選擇各種配件,大大簡化了手機的整合的難度和時間。

2. 不必開源的磁碟機程式,受益者是硬體器件生產廠商,而且不給手機生產廠商製造困擾。

3. 比較難以理解的是Android對硬體磁碟機會有哪些要求,Android為什麼要提出這些要求。為了理解這個問題,不妨分析一個執行個體,看看Android HAL是如何處理Telephony的。

Figure 13-4描述的是與Telephony相關的各個層次之間的協作關係。我們關心的HAL,在圖中以Libraries(User Space)命名,Telephony HAL的內部結構以綠色標註,包含兩個構件,Radio Daemon和Vendor RIL。

1. Radio Daemon,它是由Android提供的,不隨BP硬體的生產廠家和型號而改變。在Android啟動時,Radio Daemon就被啟用,並一直處於運行狀態,直到Android關閉[4]。

2. Vendor RIL(Radio Interface Layer)。Vendor RIL由BP部分生產廠家提供,不同品牌的BP,以及不同型號的BP,綁定不同的Vendor RIL。Vendor RIL的存在形式是一個函數庫檔案,檔案命名必須服從約定的規範,libril-<companyname>-<RIL version>.so,方便Radio Daemon尋找可用的Vendor RIL[5]。

在即時運行時,應用軟體調用Telephony Stack,而Telephony Stack指示Radio Daemon去發現當前可用的Vendor RIL,並動態載入相應的.so函數庫。也就是說,讓Radio Daemon去實現熱拔插(Plug-and-Play)的功能。Vendor RIL函數庫負責AP與BP之間的IPC。至此,從應用軟體,到Telephony Stack,到HAL中的Radio Daemon和Vendor RIL,到BP部分的硬體和磁碟機,全線貫通。全線貫通後,應用軟體就可以處理撥打到電話,傳送簡訊等等通訊業務了[4,5,6]。

雖然Figure 13-4僅僅描述了與Telephony相關的各個層次之間的協作關係,但是對於其它功能,各個層次之間的協作關係也大致相仿,例如音響控制,和電源管理等等。

Android HAL隱含的意義在於,允許Android手機外接其它硬體裝置,例如溫度計,擴大手機的功能。

Figure 13-4. Android Telephony system architecture [5].
Courtesy 

總結一下,智能手機AP部分與BP部分整合,類似於檔案系統中通用的VFS與不同廠家提供的Storage Device的整合。BP部分提供基礎的通話,資料通訊,和SIM卡功能。而AP部分圍繞這些基礎功能,提供豐富的服務,例如通話記錄,簡訊的編輯回複和轉寄等等。這些服務,囊括在Telephony Stack函數庫中。

為了方便第三方軟體的安裝和運行,Android提供了Application Framework,它以Java Object的形式,封裝了Telephony Stack函數庫的功能,GUI功能,和其它外設硬體裝置的功能。Application Framework不僅降低了第三方應用軟體的開發難度,而且降低了第三方應用軟體出錯的可能性,另外還降低了萬一第三方應用軟體出錯,所造成的對整個系統的破壞。

為了方便整合來源廣泛的硬體裝置,Android提供了Hardware Abstraction Layer。與檔案系統中VFS與Storage Device的協作方式類似,一方面,HAL提煉出不同硬體廠商都必須提供的共同的功能,把它們囊括進通用的模組,例如Radio Daemon,通用的模組與硬體的品牌和型號無關。另一方面,HAL要求硬體廠商提供符合Android規範的IPC函數庫,例如Vendor RIL,以便建立起通用的模組與不同品牌和型號的硬體裝置之間的通訊渠道。

(轉)android系統開發 AP 和 BP 簡要說明

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.