思考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开发者的负担。

2API与话语权

 API的本意是:App与系统平台之间的接口,也就是一种互动的协议。后来,逐渐扩大为较为广泛的意义:泛指软件组件之间的接口,也就是两方软件组件开发者之间的互动协议。这让API与UI有了明确的区别:

  • UI(User Interface)是指软件(如AP)与用户(User)之间的接口,也就是双方互动的协议。

  • API是指软件(如App)与软件(如框架)之间的接口,也就是双方开发者所订定的软件组件互动协议。

   例如,基于上节所述的效益,Google公司就做了Android框架(即基类)API来『赠送』给应用程序(App)开发者,而App开发者就以框架API为基础,配上应用子类而成为完整的应用程序,提供UI(User Interface)给使用者来使用之。其中,API是送人的,而UI则是可以卖钱的,其关系就如下图1所示:

1 APIUI之关系

  上图的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 AndroidJava层应用框架与HAL驱动框架()


   这是从「基类与子类继承关系」的观点来看的,基类属于框架;而子类则属于App。于是,上图就相当于:

4AndroidJava层应用框架与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架构师学苑