思考ANDROID架構(4)：HOW-TO, 如何從API洞悉軟件的話語權

思考ANDROID架構(4)：HOW-TO, 如何從API洞悉軟件的話語權

前言：許多人會認為，提供接口(如API)，其目的是要去服務別人(如App)。然而，這只是一個視角而已，還有許多視角來看待API。例如：關于“App框架”，顧名思義就是要去“框住”應用程序(App)；那么，又依賴甚么去框住App呢? 答案是：API。于是，如果A有能力框住B，我們就能判斷出，這軟件架構里，A比B具有較大的話語權。一般而言，架構師的重要職責就是要去洞察一些微小的技術變化，將對產業會產生甚么巨大的影響。這種洞察力，就是架構師先見之明的源頭。

1、復習：API的角色

  在上一篇文章：<<思考Android框架：ANDROID框架API的角色是什么? >>里，介紹了API的角色。君不見，Android于2007年問市之后，其聲勢扶搖直上，版圖迅速從手機產業擴展到其它各領域，如電視、STB、車載系統、對講機、LED室內裝潢等。到了2012年，Android更邁向智慧手機、智能Pad、智能電視和智能家庭的一致性平臺。除了軟件的開放之外，Android ADK更邁向硬件的開放API，讓形形×××的周邊裝置都能夠整合到Android平臺上。Android的高度開放性，非常有利于軟硬整合，人人都能自由使用C/C++撰寫底層服務，緊密結合硬件，呈現其差異化，創造增值效果。這是當今全球IT產業的發展主軸。

   在這潮流下，許多人逐漸發現，過去誤認為Android應用軟件都是Java程序，并未曾認知道真正的Android應用軟件幾乎都需要Java與C/C++兩者并用，才能兼具「力」與「美」，才能實現深度的軟硬整合，掌握當今產業脈動和商機。其中，值得關注的是，框架(Framework)開發技術是呈現軟硬整合、創造差異化的必備條件。框架設計就是API設計，在Application Market潮流下，Android平臺里的各種產品都必須提供Open API給廣大的第三方開發者。

   為什么我們要把服務做進去框架呢? 也就是為什么要把服務做進去平臺里呢?傳統上，API是位于App與平臺之間，平臺與應用領域無關，例如偏重于通信、網絡等相關的。在今天潮流下，API則位于框架與應用子類之間，框架歸于平臺，可以將領域知識做進框架里、做進平臺里。但是封閉iPhone做不到，封閉的黑莓做不到，開放的Android則做得到。所以，我們可以把各種各樣的框架納入到電信或網絡服務商的平臺里(如騰訊的Q+平臺)里，進而減輕廣大App開發者的負擔。一個運營商應該把框架做好，例如把費用支付的框架做好，把API提供給眾多App開發者，這樣會大幅節省App開發的工作量，對于電信/網絡營運商而言是非常重要的。隨著App開發者的使用，自然會變成通用的開放API,這樣就節省了很多App開發者的負擔。

2、API與話語權

 API的本意是：App與系統平臺之間的接口，也就是一種互動的協議。后來，逐漸擴大為較為廣泛的意義：泛指軟件組件之間的接口，也就是兩方軟件組件開發者之間的互動協議。這讓API與UI有了明確的區別：

• UI(User Interface)是指軟件(如AP)與用戶(User)之間的接口，也就是雙方互動的協議。

• API是指軟件(如App)與軟件(如框架)之間的接口，也就是雙方開發者所訂定的軟件組件互動協議。

   例如，基于上節所述的效益，Google公司就做了Android框架(即基類)API來『贈送』給應用程序(App)開發者，而App開發者就以框架API為基礎，配上應用子類而成為完整的應用程序，提供UI(User Interface)給使用者來使用之。其中，API是送人的，而UI則是可以賣錢的，其關系就如下圖1所示：

圖1、 API與UI之關系

  上圖的Activity基類里含有setContentView()和onCreate()兩個函數。其中，setContentView()是具象(Concrete)函數，內含許多程序碼；而onCreate()是抽象(Abstract)函數，內部是空的，沒有程序碼。這些函數和其內涵的程序碼都是用來贈送給App開發者。App開發者拿到基類之后，就撰寫myActivity子類，將空的onCreate()函數補起來，填上UI的操作指令；也可以呼叫(或調用)setContentView()函數的服務，就形成一個完整的服務了。簡而言之，基類API加上子類UI，才構成完整的服務，就可以賣錢了。

   在上述的API里，像onCreate()等抽象函數是神奇力量的來源，也是框架API的秘密所在，它提供神秘的制約力量，讓框架基類能制約應用子類的結構(Structure)和行為(Behavior)。由于這種抽象函數的具有強大的制約力量，這種API讓基類能強力主導(Dominate)其子類的結構和行為。其API的抽象函數名稱和參數都是由基類開發者自主決定的，然后要求子類開發者去遵循而實作(Implement)之，讓基類開發具有高度的主導性，所以當我們掌握了框架API，就擁有話語權了。

3、從API洞悉話語權的大小

大家都知道，接口(Interface)是雙方接觸的地方，也是雙方勢力或地盤的界線。誰擁用接口的制定權，誰就掌握控制點，就能獲得較大的主動權(或稱為話語權)，而位居強龍地位；而另一方則處于被動地位，成為弱勢的一方，扮演地頭蛇角色。

   隨著框架API這項禮物的大量贈送而廣為流傳時，其所攜帶的制約力量就逐漸擴展出去，于是勢力和版圖就日益擴大了。君不見，Microsoft的.NET框架，以及Google的Android框架都是當禮物送人，而讓Microsoft和Google的勢力無限延伸，進而主宰了整個產業局勢。例如Android的API接口：

圖2、 Android框架基類與子類的接口

  從這接口可看出它的不平等性質：

• onCreate()函數名稱定義于框架基類Activity里。

• onCreate()函數的程序碼是寫在myActivity子類里；由子類提供給基類來呼叫或調用。

從這個「不平等」性質，就知道Activity基類擁有主動權，是強勢的一方；而myActivity子類則是弱勢的，受制于對方。于是，可以推論出來：Activity基類的開發者(即擁有者)處于強龍地位，而myActivity子類的開發者(即擁有者)處于地頭蛇角色。例如，Android平臺設計的特色是：

• 強龍的軟件(即Android本身)掌握了控制點；

• 強龍軟件呼叫地頭蛇的軟件。

  為了實現強龍軟件真正掌握控制點，就必須由強龍軟件來呼叫地頭蛇軟件，而且其呼叫接口，應該由強龍軟件開發團隊所定義的。為了定義這項接口，就得寫個框架基類去與地頭蛇軟件相互搭配。于是，Android提供了Java層的應用框架和底層的HAL(Hardware Abstraction Layer)驅動框架。如下圖：

圖3、 Android的Java層應用框架與HAL驅動框架(一)

   這是從「基類與子類繼承關系」的觀點來看的，基類屬于框架；而子類則屬于App。于是，上圖就相當于：

圖4、Android的Java層應用框架與HAL驅動框架(二)

   無論是Java層應用框架或是HAL驅動框架都是由商業強龍(即GoogleHAL框架公司)出資開發的。然后，強龍必須將HAL框架原始程序碼提供給驅動開發者(地頭蛇)，地頭蛇就把HAL框架和他的驅動程序一起編譯和連結起來。同理，強龍必須將Java層應用框架原始程序碼提供給應用程序開發者(地頭蛇)，地頭蛇就把Java框架和他的應用程序一起編譯和連結起來。此時，HAL框架和Java框架會提供主動型API來呼叫地頭蛇的程序。有了上述的強龍系統架構來支撐強龍商業架構，讓Google穩居商業(或產業)分工合作上的強龍地位。

4、回顧API的歷史演變

   很多人常提出疑問：提供API的途徑何其多? 為何特別強調「框架」的API呢? 例如，一般程序庫(Library)也提供API給開發者使用、網絡服務(Web Service)也是一種API，為何只談框架API呢? 為了回答這問題，必須回顧過去20年來的軟件發展經驗了。其中有兩項重要的事跡：

◆  1980年代后期，CORBA是一項對象導向的服務標準API，實現此項標準的系統中，最著名的商業中間鍵軟件就是Orbix系統。然而，在系統架構上，API是一種制約力量，不是一種禮物，不能用來嘉惠予AP開發者。導致CORBA和Orbix系統架構無法支撐理想的商業模式，而終告消失匿跡。

◆  1990年代中后期，繼CORBA之后的是Microsoft公司推出COM/DCOM系統架構，雖然提供了當時先進的對象導向(Object-Oriented)的API，但還是API，仍然是一種制約力量，不是一種禮物，不能用來嘉惠予AP開發者。與CORBA和Orbix一樣的系統架構，一樣無法支撐理想的商業模式，也終告消失匿跡。

   后來，IT業界逐漸發現：API可用來框住應用程序(AP)，如同一把利劍；若要獲得開發者的青睞，利劍必須搭配面包，就像釣魚鉤必須搭配魚餌，才能吸引魚群。于是，Microsoft改變觀點，把焦點放在面包上，發現對象導向技術里的抽象類別(Abstract Class)及其提供的預設函數(Default Function)以及其它具體類別，所整合而成的框架(Framework)正式一項極具誘惑力的魚餌。此外，由框架所提供的主動型 API，也能發揮巨大的控制力。因之，Microsoft于2001推出.NET框架來取代COM/DCOM，由于.NET框架融合了面包與利劍，既能嘉惠廣大的開發者，又能有效框住眾多的應用程序。.NET框架是Microsoft贈送給廣大的開發者的最佳禮物，表達了Microsoft對全球廣大第三方開發者關懷和愛心，讓他們因.NET而受惠。

   到了2007年，Google也依樣畫葫蘆，買來Android框架，當成禮物贈送給全球的手機硬件廠商，也贈送給全球廣大的App開發者。由于Android框架「禮物」嘉惠予硬件廠商，所以全球的硬件廠商也是受惠者，因而大力支持Android，也讓Android聲勢扶搖直上。Android框架是面包與利劍的融合體，不僅嘉惠予硬件廠商，也嘉惠予全球數以萬計的廣大App開發者，同時也主導了這些開發者。由于Google熱情投入開發框架API，并當成禮物來送人，除了嘉惠眾多硬件廠商，也嘉惠了全球的App開發者，讓人人能擁有「沒錢就改版，改版就有錢」的利益。古賢者老子說：「圣人無積，既以為人己愈有，既以予人己愈多。」從歷史可知，秦始皇、漢武帝熱情投入×××長城的興建，而成為最大獲利者。如今，Google和微軟都熱情投入軟件框架的開發，而成為幸運的最大贏家。

5、設計你的框架API，爭取話語權

   在Android平臺上，Google提供了強勢的框架API，掌握了系統的主動權(或升控制權)，大大拓展其市場版圖，成為幸運的最大贏家。這常常讓許多人誤認為只有Google才有機會開發框架API，其實不然，人人都能在開源&開放的Android平臺上開發基類來提供API，并當成禮物送人。當App開發者采用你的框架(基類)API(即接受你的禮物)時，由于你擁有主控權了。

   逐漸地，你開發愈多的基類API，你的框架內容就愈豐富，提供了愈多奶水，就越愈能吸引眾多App開發者，于是你在系統架構里的地位就愈強勢了。換句話說，人人都有機會發揮其特定領域(Domain-Specific)知識，打造特定領域的基類(和API)，成為特定領域框架(Domain-Specific Framework, 簡稱DSF)，提供特定領域的框架API，提供了特殊領域的專業服務，幫助眾多App開發者，減輕其開發AP的負擔，也就能吸引眾多App開發者了，造就了自己成為特定領域的主導者地位。

   在Android基礎平臺上，需要千千萬萬各行各業的領域框架(DSF)，例如Google自己就開發出智能型電視(Smart TV)的領域框架。還有毆洲汽車大廠Continental公司也在Android平臺上開發AutoLinQ車載領域框架。此外，諸如語音辨識、醫療影像等形形×××的領域框架，也將如同春筍般波波上市，不斷充實Android平臺的服務內涵，讓Android平臺更健康、更茁壯了。例如，在Android環境里的既有應用框架如下圖：

圖5、 Android典型的框架基類與應用子類

  在這圖里，上層的Activity和View是Google開發(并贈送)的框架基類，其提供了API(包括onCreate()和onDraw()函數)來制約App。這個有利于Google的優勢系統架構，讓Google位居主導地位，制約了各AP開發者。那么，我們該如何定位自己呢? 我們開發的DSF又該擺在哪里呢? 答案是：在上圖的基類與子類之間可以加入小基類(如下圖里的Location類)所示：

圖6、自己框架的定位

   當你開發了自己的DSF小框架，來協助App開發者，一方面節省App的開發負擔，另一方面藉由框架API去制約App子類別，就能創造對你非常有利的主導地位了。Android大框架就像一個大盤子，而小框架則像一個小盤子。兩者兼容，小盤子迭在大盤子里，并不會破壞大盤子。如此，既不破壞Android的既有地位，又能鼓勵人人都熱情投入，開發各行各業的專業領域框架，將其擴充為有利于自己的新架構，創造了主導地位和話語權。

      基于這個smConsleStub小基類，就能快速開發應用子類：smConsleServlet。◆

ee                                                                             ee

【思考Android技術】

請參考：Android從程序員到架構師之路課程(在線視頻學習)

請進入：ADT架構師學苑