以下是《Android的框架API與贏家密碼》此书第一章概要，详情见附件

Google Android的框架API與贏家密碼_第一章共有九个观点： 

1.0 前言：有欧美的一句成语：“魔鬼就在细节中”来引用阐述在Android 的系统架构裡，其API 大多呈现于基类(Super-Class)的抽象函数(Abstract Function)上。而这些基类的集合，就成为Android 系统框架的核心要素。所以，我们说，在Android 潮流下，商业成功的钥匙就藏在框架API 的隙缝中。充分而全面性理解框架API，即能拥有成功密码、造就天使，并成为商业竞争下的赢家，一下我们将从九个观点来阐述赢家密码：
1.1 幸運草的芳香：介绍软件接口(API)就如同幸运草一般，只要坚持信念、热情投入就能拥有它，让它芳香远播，带给自己和众人无穷无尽的幸运：
1.1.1当幸运草来敲门；Android 框架API 就如同货柜API，只要热情支持它、灌溉它，幸运就会降临到我们身上。
1.1.2 Android框架API:幸运草种子 ：
软体接口(API)就是一种「序」(Order)，而定义API 的幕后支柱就是框架(Framework)和基类(Base Class 或Super Class)。这种序可包容繁杂多变的细节，就如同货柜（又称集装箱）一般；
1.2 猛虎般細嗅著：前面曾说过“魔鬼藏在细节中”也就意味着“成功的钥匙藏在接口的隙缝中”。同理，我们可说：“赢家密码就在Android框架API的隙缝里”，幸运草的芳香从隙缝里飘逸出来。只要如猛虎般细嗅着，细细品味Android框架API的芳香，就能势如破竹，无往不利了!
1.2.1 API：以往忽略的细节:
过去数十年来，Client-Server架构一直是IT系统的基本架构，即使当今流行的云端服务系统，也就是Client-Server架构的延伸。如图：  
 
      云端服务Client-Server架构的延伸图
 幸运草的芳香就从缝隙中飘逸如图:


热情投入、细心打开API的缝隙
有上面传统的API缝隙，呈现眼前的两级：基类（Super Class)和子类（Subclass）如图：


1.2.2 新API：在基类和子类直接：
由于基类和子类分别有不同的团队开发，而形成一个新API，如图： 


                          发现新的API 
1.3 框架基類API：
1.3.1 框架、基类API 之微妙关系：
由于框架的核心就是一群基类的组合。如果我们期待框架是稳定的，那么就会要求基類必须是稳定可靠的，这将会违背【虚实相依】的系统设计原则，会导致API 的不稳定。所以，本节采用一个新观点：
l  API 是目的，它是实的。
l  基类是手段，它是虚的。
l  手段必须保持弹性，目的才会稳定持久。
l   框架是虚实相依、弹性与永恒的和谐组合体。
所以，本章采用【框架基类API】(简称框架API)名词來表达出上述的均衡和谐的组合体，并精致地描述框架、基类和API 三者的微妙关系。将众多基类组织起來成为框架，这些基类的子类可以组织成用户需要的应用程式。此时，这个框架就称为【应用框架】，而子类就称为【应用子类】，如下图所示：


上图 Client（C）+应用子类=应用程序
上图的【Client(C)】与【应用子类】合起來就成为一般所称的【应用程式(AP)】了。此种应用框架就是当今Android 平台上最亮丽的一环，它支撑着数十万应用程式，并包容它们的百花齐放和繁荣成长。
1.3.2 框架(基类)API；
1.3.3框架API的主导权：
基于这上述的框架API，Client 端与Server 端展开密切的合作与沟通。由于框架(基类)开发者会订定其API，通常框架开发者会是框架API 的主导者，也成为上图里的系统主导者。其典型的讯息沟通途径，如下图所示：


上图掌握框架API 就有主导权 
1.3.4框架API 的神奇效果：
  基于框架API 的主导力量，Server 端可以获得两项利益：
l  Server 端获得主导权，能够制约Client 端应用程式的结构和行为。
l  在框架API 不改变的前提下，Server 端程式可以弹性调整、创造大幅度的差异化。至于Client 端可以获得两项利益：
l  基于框架基类的协助，Client 端(含应用子类)的开发更为快速省力。
l  在框架API 不改变的前提下，Client 端(含应用子类)可以实现跨平台的梦想。
1.3.4多种型式的框架API：
云端服务的框架API：水平方向的扩展 例如，云端服务提供商(如Facebook、Google 等)开发出云平台框架API，而行动端(如手机)软硬体厂商提供商也开发行动端框架(如Android 和MeeGo 框架API) 如图：


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


上图框架API的垂直方向扩展
这i-Jetty 小框架API 扩充了Android 大框架的API。让Client 端应用程式有更方便好用的API，能加速Client 端应用程式的开发。
1.3.5 以老虎游戏机为例；
1.4 做基類去送人：
1.4.1基类API 当礼物送人，而UI 可以卖钱：
做框架(即基类)API 来『赠送』给应用程式(AP)开发者，而AP 开发者就以框架API 为基础，配上应用子类而成为完整的应用程式，提供UI给使用者来使用之。其中，API 是送人的，而UI 则是可以卖钱的，其关系就如下图所示：


上图API与UI之关系
从上图可以看到，UI(User Interface)是人与应用程式的互动介面。而API (Application Programming Interface)则是位于基类(Activity)与子类(myActivity)之间接口(Interface)处，并以函数形式呈现出來。更明确叙述Android 的基类/子类与API/UI 之密切关系；
1.4.2 框架API 的神奇：制约力量：
相对上，Activity基类的setContentView()等具象函数就不具有显著的制约力量。虽然它是由基类开发者所定义的，但却是被动地等待子类来呼叫之。所以我们称之基类的【被动型API】。
1.4.3主动型API 与被动型API：
就基(即框架)开发者而言，基类是礼物，要开发什么样的API来当礼物送人，经常是开发者必须谨慎思量的事情，其中分辨主动型与被动型API的区别，是极为重要的能力。两者可藉由3 个攸关的动词来区别之：
1. 定义(Define)   2. 实作(Implement)   3. 呼叫(Invoke or Call)
根据这3 个角度，可将API 区分为【主动型】与【被动型】两种，如下表：


1.4.4 制约力量的強弱等級；
所谓被动型API 就是，相对而言，基类处于被主导(Dominated)的地位，也就是说，被子类或其他Client 类所主导了。
1.4.5把制约力量赠送出去；
当框架API 具有绝对主导性时，就能将框架当做礼物而大量送人了。
1.5 情願者來上鉤：
框架内含一些基类，而基类又内含一些函数；在这些函数里，可以撰写各式各样的程式码，來服务让应用子类(即让子类来呼叫)，这些程式码就是附在基类API 上的鱼饵了。于是：
框架(基类)开发者：姜太公。
AP 开发者：鱼妈妈。
框架(基类)程式码：鱼饵。
应用程式(AP)：鱼小孩
1.5.1鱼饵与AP 开发者的两道奶水：
应用程式(AP)所依赖的主要成长奶水是：API 与SDK。API 就像房子或大厦的骨架；而SDK 就像大厦的鹰架(又称脚索架)：
◎ API 是大厦的骨架：框架API(即建筑物的骨架)，可协助AP 开发者(即建筑
工程师)，建立应用子类(即地面上的楼房)。而「基类(即地基) API(骨架)子类(即楼房)」就是整个大厦建筑物了。所以框架API 也是大厦成长的奶水。
◎ SDK 是大厦的鹰架：像Android SDK 和Android NDK (即鹰架)就是AP 开发者必须用到的软体工具，用來协助开发者，让AP(即大厦)的开发工作更简洁、更顺畅。
1.5.2木瓜与小鸟： 
��� 框架API 是木瓜的种子。
���AP就是小鸟，其吃下木瓜肉和种子而长大。 
1.6 強龍與地頭蛇：
1.6.2强龙不压地头蛇；
以Android 手机平台为例，Google 扮演【强龙】角色；而AP 开发者则扮演【地头蛇】角色。 Google 也尽到强龙的任务： 提供Android 框架API 和Android SDK(含Android NDK)两道奶水，协助AP 开发者(即地头蛇)。
1.6.2以Android 商业模式为例 ：
Google强龙希望Android 平台能支撑它在手机、家电产业上的强龙的地位。除了上述的AP 开发者之外，Google 还有另一种地头蛇：硬体厂。因此，Google身旁有两种主要的地头蛇：AP 开发者和硬体厂；其中AP 开发者撰写手机应用软体，而硬体厂则开发手机硬体组件。Google 为了站稳商业强龙地位，它必须协助两种地头蛇去完成他们各自的任务。于是Google 开发手机平台软体(即Android 平台)，内含两种框架(含API)：
l Java 层应用框架(Application Framework)，它用來衔接应用子类。
l  HAL(Hardware Abstraction Layer)驱动框架，它用來衔接硬体组件的驱动程式(Driver)。
然后将上述框架当做礼物，分别赠送给AP 开发者和硬体厂。如下图所示 
   
   强龙赠送框架给地头蛇
Android 框架就是一個完美的范例，主要元素包括：
◎ 框架內含基类及主动型API。
◎基类里的程式码是鱼饵。
◎ 主动型API 則是鱼钩。
◎ 框架是一种极为特殊的礼物。
这种【强龙/地头蛇】商业模式，很类似于大家熟悉的【×××】体系。 Google 开发Android 框架来送人，强力支撑其全球分工和行销的×××体系，如下图 
 

Android 框架支撑Google 的全球×××体系
1.7 沒錢就去改版：
上述谈到了，强龙提供两道奶水：框架API 和SDK(含NDK)来协助地头蛇开发AP 或驱动程式。这些是软体开发(即生产)阶段的协助，仅是强龙的【必备】条件而已。如果想成为真正强龙的话，还需要一项【充分】条件：协助地头蛇去赚钱(即行销)。
1.7.1拿万里长城來比喻：
为了说明HAL 框架与【没钱就改版】的逻辑关系，于此兹拿万里长城來比喻
HAL 框架。万里长城攸关三方面的利益：
1.  关内居民最先获利  2. 关外居民获利较小   1.  3. 万里长城主导者获利最大(但获利较慢)
有上面1.6.2中图二可以看到，Google强龙开发HAL(Hardware Abstraction Layer)驱动框架(它是用来衔接硬体组件的驱动程式)，然
后拿它当做礼物来赠送硬体厂。这让全球硬体厂获得【没钱就改版】的自由度，因而大受欢迎和支持，于此就来说明这项自由度来源；
1.7.2.1 HAL 框架的商业效益：
HAL 框架就像一座万里长城，将整个Android 平台分隔开来，分成关内和关外两部分。如下图


上图HAL 框架将Android 平台分成关内和关外
HAL 框架将平台分隔开来。成为两部分。其中关内：如上图所示，包含HAL 框架内的驱动程式(如GPS、Bluetooth、WiFi 等)，以及HAL 框架之下的Linux 内核组件。关外：则包括HAL 框架之上的各部份( 如Libraries 、Application Framework、Android Runtime 等)。
1.7.2.2 HAL 框架的内涵：
HAL 是以C 语言撰写的框架，其主要结构如下图： 
 
上图HAL 是以C 语言写成的驱动框架
由于C 语言不是物件导向(Object-Oriented)语言，它没有类别(Class)机制，但可以拿C 语言的结构(struct)机制来表达【型态】(Type)概念。
1.7.2.3 自由度的表现：【没钱就改版】；
驱动程式开发者撰写HAL 的子类(又称为HAL 的Stub 模组)，并实作open()函数。如下图


上图撰写HAL框架的子类 
1.8 改版就會有錢：
1.8.1以HAL 框架的效益为例：
刚才，兹以万里长城來比喻HAL框架，说明了Android HAL框架的首先获利者是全球的手机硬体厂(如HTC、Motorola等)。他们获得了驱动程式和硬体设备的变动自由度和自主性；因此，获得【没钱就改版】的创意机会。
【没钱就改版】只是必备条件，并不充分。不仅仅位于底层(即C/C++层)的HAL框架能带來【没钱就改版，改版就有钱】的商业效益；另外位于上层(即Java层)的应用框架(ApplicationFramework)也能带来【没钱就改版，改版就有钱】的美好效益
1.8.1.1 HAL带给驱动程式的「改版就有钱」：
然而，Android框架是建立于开源(Open-sourced)的Linux内核上，依据GPL自由软体协议，摆在Linux内核空间裡的驱动程式，也都必须开源。Google强龙为了替硬体厂商(即地头蛇)解决上述的困境，就采取下述对策：
l让驱动程式可以从Linux的内核空间(Kernel Space)里移出來，摆入HAL框架区域内，此区域属于用户空间(User Space)。
l驱动程式摆在HAL框架的用户空间裡，采取ASL自由软体协议，而避开了GPL协议。
l采用ASL协议，驱动程式不必提供原始码，也不必送审，就能卖钱。因而，获得【没钱就改版，改版就有钱】的高获利商机。
Google 掌握HAL框架，藉由HAL的主动型API 來包容驱动程式的改版机会。由于驱动程式不必开放原始码，保护硬体设备的机密性，因此不仅容易改版，还能卖钱，所以地头蛇会日益壮大，更有力量支持Google强龙。
1.8.1.2 HAL 带给应用程式(AP)的【改版就有钱】：
由于HAL 框架替驱动程式开发者(和硬体厂商)带來「没钱就改版，改版就有钱」的利益。所以，像HTC、Moto、三星等硬体公司都愿意大力支持Android 平台，而且在自由改版下获得硬体产品的差異化，呈现了多赢的局面。如果拿一棵树(Tree)來做比喻，驱动程式就相当于树根部份，树根的自由发展与茁壮能强力支撑上层枝葉的更大空间和享受阳光的机会。
           以一棵树来比喻 


这意味着，在驱动程式和硬体的差异化中，上层AP 只要随着框架(像树干)的细微调整和改版，就能适合于各式各样的硬体载台和市场，因而HAL 带來的驱动程式的【改版就有钱】也替上层AP 创造了【改版就有钱】的商机。
1.8.2 以应用框架(Application Framework)的效益为例 ：
我们也能拿万里长城來比喻Android 的应用框架，其角色如下图所示：


上图应用架构也像×××长城 
这是从【基类与子类继承关系】的观点来看的，基类属于框架；而子类则属于AP。
于是，上图就相当于：

 
上图将Applications 视为关内
1.9 成為幸運贏家：
1.9.1 Why，框架API？
前面也已经说明了，框架就像万里长城，其API 就像长城的关口(如居庸关等)，而且也拿一棵树来做比喻，说明API 的角色：
l  HAL 框架的API 就位于树干与树根(即驱动程式)的衔接处。
l  应用(AP)框架的API 就位于树干与枝叶(即AP)的衔接处。
1.9.2 只要您热情投入，就成为幸运赢家：
人类天生就有两只眼睛，让我们同时拥有兩个观点，让我们更能看到眼前或未来的真实事物。在你的既有观点下，再增添一个新的幸运者观点，可能会带来幸运的机会。
1.9.2.1 幸运者观点之例
1.9.2.2 时髦的幸运者观点：做框架API 送人；