思考ANDROID架构(三)：What & How-to，Android框架API的角色是什么?

前言：一般人都知道API就是Android平台提供给App开发者使用的软件接口；句有App开发经验者，就能更深刻理解到，框架(Framework)型式的平台，其API是框架基类提供给App子类调用的接口。因此，一般人(非App开发者)比较不容易理解API的角色和用途。例如，一般人通常认为API是框架提供给App来调用，却不知道更关键的是：由框架来调用App子类的函数。一般人更不会去理解到，当框架调用App函数时，其调用的接口，到底时有谁来定义的呢? 是由框架提供者定义，还是App开发者定义的呢? 专业的架构师，必须对这些细腻而关键的议题，进行思考，进而深刻领悟、掌握和运用它；而不能像一般人一样泛泛认识它而已。

1.  框架、基类与API之微妙关系

     过去，大家经常比较关注于基类的涵义和内容，例如会重视Student基类代表着「学生」；并认为继承(Inheritance)代表着分类(Classification)的涵义，例如PartimeStudent继承Stuent，意味着PartimeStuent子类代表着「兼职学生」。这是传统的观点，它并没有错。然而，如果人们能兼具更多观点的话，更能看出许多事物的本质。因此，在上一节里，特别采取一个新观点：

• 基类是手段，API才是目的。

• 也就是说，基类的存在是为了支持API。

• 这只是一个新观点，并非本质，所以没有对错。

   同样地，过去大家经常认为框架(Framework)就是一种系统架构(Architecture)或骨架，它是用来支撑许多应用程序，所以就像房屋的地基一样，必须稳定可靠才行。这是传统的观点，它并没有错。只是人们如果能兼具更多观点的话，更能看出许多事物的本质。

   由于框架的核心就是一群基类的组合。如果我们期待框架是稳定的，那么就会要求基类必须是稳定可靠的，这将会违背「虚实相依」的系统设计原则，会导致API的不稳定。

所以，本节采用一个新观点：

• API是目的，它是实的。

• 基类是手段，它是虚的。

• 手段必须保持弹性，目的才会稳定持久。

• 框架是虚实相依、弹性与永恒的和谐组合体。

     所以，这里采用「框架基类API」(简称框架API)名词来表达出上述的均衡和谐的组合体，并精致地描述框架、基类和API三者的微妙关系。

2. 框架(基类)API

     在传统观点里，基类是抽象类别(Abstract Class)，应该从用户需求或业务内容中抽象出来，抽出共享而稳定的结构和行为，这是传统的观点，它并没有错。只是人们如果能兼具更多观点的话，更能看出许多事物的本质。在新的观点里，兹拿×××长城来做比喻：

• 框架就像×××长城；

• 基类就像关口(如山海关、居庸关等)；

• API就像关口的大门。

     为了支持API这个目的，所以选择了基类作为手段。为了将众多基类组织成为一个整体，所以采取框架这个方法。×××长城和关口并不是从关内或关外事物里抽象出来的，而是伟大架构师从内心创造出来的(无中生有的)。同理，框架和基类也不是从需求或业务里抽象出来的，而是伟大架构师从内心创造出来的，目的只有一个：支持API。这只是一个新观点，并非本质，所以没有对错。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]

    将众多基类组织起来成为框架，这些基类的子类可以组织成用户需要的应用程序。此时，这个框架就称为「应用框架」，而子类就称为「应用子类」，如下图所示：

图1  Client(C) + 应用子类= 应用程序

   上图的「Client(C)」与「应用子类」合起来就成为一般所称的「应用程序(AP)」了。此种应用框架就是当今Android平台上最亮丽的一环，它支撑着数十万应用程序，并包容它们的百花齐放和繁荣成长。

3.  框架API的主导权

     基于这上述的框架API，Client端与Server端展开密切的合作与沟通。大家都知道，凡是一群人或系统模块相互合作时，必然有个核心的主导者。由于框架(基类)开发者会订定其API，通常框架开发者会是框架API的主导者，也成为上图里的系统主导者。其典型的讯息沟通途径，如下图所示：

图2  掌握框架API就有主导权(一)

     从图里的讯息流动途径，就可以看出来应用框架是系统的主导者。所以框架API的开发者，最具有潜力成为赢家。如果从Server端发出请求，如下图：

图3  掌握框架API就有主导权(二)

    同样地，从图里的讯息流动途径，就可以看出来：应用框架是系统的主导者。所以框架API的开发者，最具有潜力成为赢家。兹拿一个云端服务来举例说明之。从云平台上发出一份简讯(SMS)给Android框架，框架的基类要求应用子类去解析SMS讯息，子类则回传结果(即讯息内容)给基类，然后基类要求Client端将讯息内容显示给用户。其讯息流动途径，如下图所示：

 图4  主导权：以发送SMS为例

4.  框架API的神奇效果

基于框架API的主导力量，Server端可以获得两项利益：

• Server端获得主导权，能够制约Client端应用程序的结构和行为。

• 在框架API不改变的前提下，Server端程序可以弹性调整、创造大幅度的差异化。

至于Client端可以获得两项利益：

• 基于框架基类的协助，Client端(含应用子类)的开发更为快速省力。

• 在框架API不改变的前提下，Client端(含应用子类)可以实现跨平台的梦想。

     由于Server端拥有主导者的优势，成为潜在的「强龙」角色；而Client端在基类的协助之下，扮演「地头蛇」角色，而获得两项利益。因而形成「强龙/地头蛇」的双赢商业模式。只要维持「强龙不压地头蛇」的合作原则，这项双赢商业模式就能持续下去。在后面的第1.6节里，将会详细说明此「强龙/地头蛇」商业模式。

5.  做基类去送人：基类API当礼物送人，而UI可以卖钱

     为什么开发框架API者需要热情呢? 其主要原因是：做基类的目的是要拿它来当礼物送人的；不是要拿它来卖钱的。也就是说，做框架(即基类)API来『赠送』给应用程序(AP)开发者，而AP开发者就以框架API为基础，配上应用子类而成为完整的应用程序，提供UI给使用者来使用之。其中，API是送人的，而UI则是可以卖钱的，其关系就如下图所示：

图5  API与UI之关系

6.  多种型式的框架API

云端服务的框架API：水平方向的扩展

   由于框架API的神奇效果，让Server与Client端都能获得利基，吸引许多IT厂商热情投入，发展出形形×××的应用框架，支撑多样化的API。例如，云端服务提供商(如Facebook、Google等)开发出云平台框架API，而行动端(如手机)软硬件厂商提供商也开发行动端框架(如Android和MeeGo框架API)，如下图：

 图6 框架API的水平方向扩展

大小相迭的框架API：垂直方向的扩展

   上图是框架API在水平方向的扩展。此外，还有垂直方向的扩展，例如著名的i-Jetty网络服务(Web Service)框架API，可以嵌入于Android框架里，形成多层级的框架API。如下图：

图7 框架API的垂直方向扩展

     这i-Jetty小框架API扩充了Android大框架的API。让Client端应用程序有更方便好用的API，能加速Client端应用程序的开发。

7.  以拉霸(Slot Machine游戏机为例

     从上述的说明中，许多人常常会误认为他只能『使用』别人所提供的框架(如Android、i-Jetty框架等)。其实不是，而是人人皆能热情投入去开发各种应用领域的基类，来提供该领域的框架API。例如，在Android框架里，开发拉霸游戏机如下图：

图8  Android上的拉霸机画面

     在这小小的游戏领域里，都能热情去开发游戏软件的基类API。这游戏软件可分为两部分：

• 游戏(Game)端部分，也就是Android手机端的应用程序。

• 柜台(Console)端部分，也就是GAE云层Servlet程序。

    当玩家押注后，按下 按钮(开始加速滚动)，游戏端就送出HTTP请求，来调用GAE云层的Servlet程序。此时就将「目前余额」「押注金额」传送给GAE的柜台端程序。等待柜台端程序计算出中奖金额后，将「新余额」和「奖项级别」回传给Android游戏端(滚动开始减速)，并更新游戏端的画面。

   在Console云端里，Google AppEngine提供了HttpSServlet基类。我们可以开发smConsoleStub小基类API来扩充HttpServlet大基类API，以便加速应用程序(如手机端的ac01应用子类)和云端应用子类(如smConsoleServlet应用子类)的开发，如下图：

 图9  大小相迭的Google云端框架

     其中，小基类的呼叫流程就如下图所示：

 图10  smConsoleStub小基类API的实践

      基于这个smConsleStub小基类，就能快速开发应用子类：smConsleServlet。◆

ee                                                                             ee

【思考Android技术】

請參考：Android从程序员到架构师之路课程(在线视频学习)

请进入：ADT架构师学苑