1、無框架結構，直接呼叫底層API
以往是底層平臺（作業系統）提供API讓上層APP去呼叫。
這樣的軟體控制權在APP上。舉例 APP呼叫了平臺的函式 Fun1，那麼平臺要對Fun1進行維護不敢隨意改變這個函式，系統的更新成本大，上層APP越多，維護成本越大，導致到平臺被侷限。

2、單層框架結構
為了讓系統開發者取得控制權，後來架構師們建造了一種框架結構。
APP開發者在這個框架的結構基礎上開發自己的APP。
單層結構的模型是下圖所示：

除了一部分平臺的API仍然是由APP所呼叫外，更多是由框架反向呼叫APP來驅動整個APP的執行，框架定義出介面與基類，APP基礎基類寫出具象類，框架通過呼叫介面來實現對APP的反向呼叫，這也是IoC原理的核心。

3、複合型框架
為了滿足更多元化的軟體業務需求的開發，從單層框架基礎上延伸除了複合型框架，
大框架和平臺是系統開發者來開發，小框架可以系統開發者或者第三方廠商開發，比如遊戲引擎，小框架是可以根據不同業務來選型，APP在這種大小框架結合的情境下開發大大的降低了開發難度，加快了開發速度。

4、雙層框架
為了進一步完善框架，即平衡APP的開發速度也要提高APP的執行速度。
那麼結合Java和C++兩種語言的特性來構建這個框架，Java是應用層級與APP開發者最親近，它是負責簡化APP開發來設計的，從語言特性來說Java是更簡單，容易被APP開發者所使用，C++是更執行效能高效，是負責效能擔當，它與平臺更親近。
兩者結合，使得APP的開發速度快，且執行速度快。

5、Android的框架
Android的框架就是採用上面的雙層複合型框架的方式來構建的。其實現在很多框架都採用這種方式來構建。

舉例個例子來了解下Android的底層框架原理。
1、Android的四大元件，Activity、service、BroadcastReceiver、ContentProvider。

他們的作為基類是由框架所定義的，APP的開發者想要用元件的功能只能是寫子類來繼承使用。如定義 myActivity，由框架所呼叫 new myActivity 創建出物件並被呼叫 onCreate方法來建立窗體頁面。
模擬一下框架的實現：
Activity object = new myActivity();
object.onCreate();
哪有人會疑惑，框架的程式碼是在這個APP開發之前就有了，那麼框架程式碼怎麼會有myActivity這個類，myActivity這個類明明是APP開發者來寫的，這個名稱系統開發者不可能提前知道。
這就歸功於 AndroidManifest.xml文件，Mani文件裡面要求開發者把自己定義的Activity的名稱寫上。
在APP執行階段（run-time）Android框架就會讀取開發者所寫的Mani的內容，從而得知到開發者所寫子類的名稱，就能創建出這些應用子類的物件。
如下圖所示：

2、元件與元件之間的溝通：
從上面大家知道元件的子類雖然由APP開發者所寫，但卻由框架所建立，
同樣，元件中的通訊也是由框架所負責，框架是元件間溝通的橋樑。而溝通的介質是intent，中文翻譯過來是意圖，實際是跟信封一個道理。
你給遠在他方的女朋友寄一封信，你只要按照郵局規定的格式來寫這封信，比如寫好寄信人資訊，收信人資訊，和信的內容，最後投遞到郵局，最終通過郵局來把這一封信寄到你女朋友手裡。
同樣APP開發者只需要按照格式寫好Intent交給框架，而至於框架怎麼把Intent交給對方你就不需要關注。

如下圖所示：