思考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架构师学苑