iT邦幫忙

DAY 16
1

Android 實現智慧生活 DIY系列 第 16

實現智慧家庭diy (Day16) –框架是號制系統,作業流程則是交通規則。

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

要程式員遵守程式撰寫規範,最有效的方式,就是利用 編譯器,只要不按規矩來,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/家庭雲


上一篇
實現智慧家庭diy (Day15) – 實現智慧家庭雲的服務引擎 之 架構剖析 - (中)
下一篇
實現智慧家庭diy (Day17) – 當 SmartTV 遇上 Softkeyboard 。
系列文
Android 實現智慧生活 DIY30

尚未有邦友留言

立即登入留言