應用框架是特定應用領域中，程式間的共同結構，讓程式員們，依共同結構來發展式，因此程式間具有一致性，增加系統可維護性。

要程式員遵守程式撰寫規範，最有效的方式，就是利用 編譯器，只要不按規矩來，Compile 就不會過，用框架 "鎖住"系統的Form (形式)，勝過天天耳提面命、苦口婆心，道德勸說，或威脅利誘。

所有文章
http://ithelp.ithome.com.tw/category/家庭雲
請看下圖這張舉世聞名的 Android 系統結構圖，由下而上是硬體驅動、Linux 內核、Android 系統平台、平台上的系統服務、應用程式框架，最上面則是 應用程式，俗稱 APP。
我建議換個角度，這張圖上下相反，倒過來看，如此對學習應用程式框架 "設計"，幫助很大。
在此強調 "設計"，若是僅止於 "使用"框架，差異沒那麼大。

API 可分為框架API與非框架 API: 框架API 是主動的，他經常運用如前兩天我們示範的Template Method 設技樣式的手法，以提供抽象類別，內含部份實作與部份抽象函式的父類，讓應用程式開發的人，繼承並補足不足之處(抽象函式)，而成為完整的任務實現。在昨天的例子中，常看到 IoC的反向呼叫方式，使框架擁絕對的控制權。有了絕對控制權，才能提供合諧的有序環境。

框架API與非框架 API最重要的差異在是否擁有系統的控制權，一個系統一定要有一個且唯一的控制中心，有如機場的飛航管制，負責複雜多變的空中交通與頻繁的飛機起降。越龐雜的系統，更顯示控制中心的不可或缺。它提供一個"有序"的運作環境，系統才能諧調，而框架API有控制權，而非框架 API則無。

再次強調，上面那張圖要倒過來看，因為最上面是使用者、而使用者會接觸硬體，如觸控螢幕、鍵盤、滑鼠，所以，使用者下面應是硬體驅動層。其次依序是HAL、Linux Kernel，再來才是Android OS、 Framework ，最底層才是 APP。

如此，便容易發覺，硬體與軟體的主從關係，與我們過去想像不同。

所有文章
http://ithelp.ithome.com.tw/category/家庭雲