如何开发android应用框架-eit门派秘笈api

1、44如何開發 Android 應用框架：EIT 門派秘笈By2012_06還有多免費的書籍(PDF)可下載 親自策劃的 Android 培訓課程 45認框架 API认识框架 API1.7认识框架与 Open API API 位于基类与子类之间 API 与 UI 的关系框架 API 的神奇：制约力量人人可以开发框架 API回顾与展望：从古典到新潮 API结语46如何開發 Android 應用框架：EIT 門派秘笈By2012_061.1认识框架与 Open API在 Android的系统开发事情中，大家通常只求API(ApplicationProgamming

2、erface)，却常常忽略有关 API 的其它细节，因而系统架构受制于人，也导致商业模式的窒碍难行，成为商业竞争下的输家。在 Android 的系统架构里，其 Open API 大多呈现于父类别(Super-class，或简称为基类)的抽象函数(Abstract function)上。而这些基类(Base-class or Super-class)的集合，就成为 Android 应用框架(Application framework)的要素。所以，我们说，在 Android 潮流下，商业成功的就藏在框架 API 的隙缝中。充分而全面性理解框架 API，即能拥有成功、造就天使，并成为商业竞争下的赢

3、家。过去，大家经常比较关注于基类的涵义和内容，例如会重视 Student 基类代表着学生；并认为继承(Inheritance) 代表着分类(Classification) 的涵义，例如PartimeStudent 继承 Stuent，意味着 PartimeStuent 子类代表着学生。这是传统的观点，它并没有错。然而，如果人们能兼具观点的话，更能看出许多事物的本质。因此，本书将采取一个新观点：基类是，API 才是目的。也就是说，基类的存在是为了支持 API。这只是一个新观点，并非本质，所以没有对错。同样地，过去大家经常认为框架(Framework)就是一种系统架构(Architecture)或

4、骨架，它是用来支撑许多应用程序，所以就像房屋的地基一样，必须稳定可靠才行。这是传统的观点，它并没有错。只是人们如果能兼具看出许多事物的本质。观点的话，更能由于框架的就是一群基类的组合。如果期待框架是稳定的，那么就会要求基类必须是稳定可靠的，这将会违背虚实相依的系统设计原则，会导致 API 的不稳定。所以，本书采用一个新观点：API 是目的，它是实的。基类是，它是虚的。在应用商城(Application Market)潮流下，Android里的各种产品都必须提供Open API 给广大的第开发者。API 设计的幕后就是框架设计。47認框架 API必须保持弹性，目的才会稳定持久。框架是虚实相依、弹

5、性与永恒的和谐组合体。于是，本书采用框架基类 API(简称框架 API)名词来表达出上述的均衡和谐的组合体，并精致地描述框架、基类和 API 三者的微妙关系。在传统观点里，基类是抽象类别(Abstract Class)，应该从用户需求或业务内容中抽象出来，抽出共享而稳定的结构和行为，这是传统的观点，它并没有错。只是人们如果能兼具观点的话，更能看出许多事物的本质。在新的观点里，兹拿来做比喻：框架就像；基类就像关口(如山、居庸关等)；API 就像关口的大门。为了支持 API 这个目的，所以选择了基类作为。为了将众多基类组织成为一个整体，所以采取框架这个方法。和关口并不是从关内或关外事物里抽象出来的

6、，而是伟大架构师从内心创造出来的(无中生有的)。同理，框架和基类也不是从需求或业务里抽象出来的，而是伟大架构师从内心创造出来的，目的只有一个：支持 API。这只是一个新观点，并非本质，所以没有对错。1.2API 位于基类与子类之间将众多基类组织起来成为框架，这些基类的子类可以组织成用户需要的应用程序。此时，这个框架就称为应用框架，而子类就称为应用子类，这些应用子类合起来就成为一般所称的应用程序(AP)了。48如何開發 Android 應用框架：EIT 門派秘笈By2012_06图 1-1、 API 位于框架基类与子类之间Android此种应用框架就是上最亮丽的一环，它支撑着数十万应用程序，并包

7、容它们的百花齐放和繁荣成长。大家都知道，凡是一群人或系统模块相互合作时，必然有个的主导者。由于框架(基类)开发者会订定其 API，通常框架开发者会是框架 API 的主导者，所以框架 API 的开发者，最具有潜力成为赢家。由于框架 API 的神果，让上图里的 Server 与 Cnt 端都能获得利基，吸引许多 IT 厂商热情投入，发展出形形的应用框架，支撑多样化的 API。例如，云端服务提供商(如机)软硬件厂商提供商也开1-2 所示。、等)开发出云框架 API，而行动端(如手动端框架(如 Android 和 MeeGo 框架 API)。如下图那么，开放 API 呢？过去大家都认为应用(AP)，就

8、是与应用领域有关，而与无关；其实不然，这一直误导致了对开放 API 的认知。新潮的做法是把一个应用切成两块：一块是应用框架(Framework)，一块是应用子类(Subclass)。一般写应用的时候都是写应用子类，很少写应用框架。为什么呢？因为苹果的应用框架是没有开放的。S(Server)C(Cnt)API應用子應用框架49認框架 API图 1-2、 云端与终端都有框架 API然而，Android 的应用框架上则是开放的，可以从 API 通到底层的硬件服务，进行深度的软硬整合，进而与云端服务进行整合。框架 API 与软硬整合潮流自从 等行动(Mobile)设备及服务产业逐渐茁壮以来，软硬整合也

9、逐渐蔚为潮流。例如，以 MTK 为首的低价 系列的一站式解决方案(Turnkey Solution)，是一种的软硬整合潮流的开端。后来，苹果的 的应用商店成功运营起来，让此潮流迈向智慧化。接着的 Android 开放 迅速窜红，让此潮流迈向硬件差异化。在智能化、差异化的趋势里，软硬整合更加紧密，整个产业迈向高价、高质量、高获利的健康发展道路。这与过去 PC 时代的软硬简单结合是大不相同的。君不见，Android 于 2007 年问市之后，其声势扶摇直上，版图迅速从产业扩展到其它各领域，如电视、STB、车载系统、对讲机、LEDAPI雲服務子動端子雲服務框架動端框架50如何開發 Android 應

10、用框架：EIT 門派秘笈By2012_06为什么要把服务做进去框架呢? 也就是为什么要把服务做进去里呢?传统上，API 是位于 AP 与之间，与应用领域无关，例如偏重于通信、网络等相关的。在今天潮流下，API 则位于框架与应用子类之间，框架归于，可以将领域知识做进框架里、做进做不到，开放的 Android 则做得到。里。但是封闭做不到，封闭的黑莓所以的 Q+可以把各种各样的框架纳入到电信或网络服务商的里(如腾讯)里，进而减轻广大 AP 开发者的负担。一个运营商应该把框架做好，例如把费用支付的框架做好，把 API 提供给众多 AP 开发者，这样会大幅节省 AP开发的工作量，对于电信/网络营运商而

11、言是非常重要的。随着 AP 开发者的使用，自然会变成通用的开放 API,这样就节省了很多 AP 开发者的负担。室内装潢等。到了 2012 年，Android 更迈向智慧、智d、智能电视和智能家庭的一致性。除了的开放之外，Android ADK 更迈向硬件的开放 API，让形形的周边装置都能够整合到 Android 平台上。Android 的高度开放性，非常有利于软硬整合，人人都能使用 C/C+撰写底层服务，紧密结合硬件，呈现其差异化，创造增值效果。这是全球 IT 产业的发展主轴。在这潮流下，许多人逐渐发现，过去误认为 Android 应用都是 Java 程序，并未曾认知道真正的 Android

12、 应用几乎都需要 Java 与 C/C+两者并用，才能兼具力与美，才能实现深度的软硬整合，掌握产业脉动和商机。其中，值得关注的是，框架(Framework)开发技术是呈现软硬整合、创造差异化的必备条件。框架设计就是 API 设计，在 Application Market潮流下，Android里的各种产品都必须提供 Open API 给广大的第三方开发者。51認框架 API1.3API 与 UI 的关系基于上节所述的效益公司就做了Android 框架(即基类)API 来赠送给应用程序(AP)开发者，而 AP 开发者就以框架 API 为基础，配上应用子类而成为完整的应用程序，提供 UI(Usere

13、rface)给使用者来使用之。其中，API 是送人的，而 UI 则是可以卖钱的，其关系就如下图 1-3 所示：图 1-3、 API 与 UI 之关系上图的 Activity 基类里含有 setContentView()和 onCreate()两个函数。其中，52如何開發 Android 應用框架：EIT 門派秘笈By2012_06setContentView()是具象(Concrete)函数，内含许多程序码；而 onCreate()是抽象(Abstract)函数，是空的，没有程序码。这些函数和其内涵的程序码都是用来给 AP 开发者。AP 开发者拿到基类之后，就撰写 myActivity 子类，

14、将空的 onCreate()函数补起来，填上 UI 的操作指令；也可以呼叫(或调用)setContentView()函数的服务，就形成一个完整的服务了。简而言之，基类 API 加上子类 UI，才构成完整的服务，就可以卖钱了。在上述的 API 里，像 onCreate()等抽象函数是神奇力量的来源，也是框架 API的所在，它提供神秘的制约力量，让框架基类能制约应用子类的结构(Structure)和行为(Behavior)。由于这种抽象函数的具有强大的制约力量，这种 API 让基类能强导(Dominate)其子类的结构和行为。其 API 的抽象函数名称和参数都是由基类开发者决定的，然后要求子类开发

15、者去遵循而实作(Implement)之，让基类开发具有高度的主导性，所以当掌握了框架 API，就拥有主导权了。框架 API 的神奇：制约力量从 API 可看出强弱地位API 的本意是：AP(应用程序)与系统之间的接口，也就是一种互动的协议。后来，逐渐扩大为较为广泛的意义：泛指组件之间的接口，也就是两方组件开发者之间的互动协议。这让 API 与 UI 有了明确的区别：UI(Usererface)是指(如 AP)与用户(User)之间的接口，也就是双方互动的协议。API 是指订定的(如 AP)与(如框架)之间的接口，也就是双方开发者所组件互动协议。大家都知道，接口(erface)是双方接触的地方，

16、也是双方或地盘的界线。谁拥用接口的制定权，谁就掌握控制点，就能获得较大的主动权(或称为主导权)，而位居强龙地位；而另一方则处于角色。地位，成为弱势的一方，扮演地头蛇53認框架 API随着框架 API 这项的大量而广为流传时，其所携带的制约力量就逐渐扩展出去，于是和版图就日益扩大了。君不见，的.NET 框架，以及的 Android 框架都是当送人，而让和的无限延伸，进而主宰了整个产业。例如 Android 的 API 接口：图 1-4、 Android 框架基类与子类的接口从这接口可看出它的不性质：onCreate()函数名称定义于框架基类 Activity 里。onCreate()函数的程序码

17、是写在 myActivity 子类里；由子类提供给基类来呼叫或调用。从这个不性质，就知道 Activity 基类拥有主动权，是强势的一方；而myActivity 子类则是弱势的，受制于对方。于是，可以推论出来：Activity 基类的开发者(即拥有者)处于强龙地位，而 myActivity 子类的开发者(即拥有者)处于地头 是雙方的接口協議(API) 由 Activity 開發者訂定 由 myActivity 提供服務(程式碼) 讓 Activity 呼叫(調用) 服務從 myActivity 向 Activity54如何開發 Android 應用框架：EIT 門派秘笈By2012_06蛇角色

18、。例如，Android设计的特色是：1)强龙的(即 Android 本身)掌握了控制点；2)强龙由强龙呼叫地头蛇的来呼叫地头蛇。为了实现强龙真正掌握控制点，就必须，而且其呼叫接口，应该由强龙开发团队所定义的。为了定义这项接口，就得写个框架基类去与地头蛇相互搭配。于是，Android 提供了 Java 层的应用框架和底层的 HAL(Hardware Abstraction Layer)驱动框架。如下图：图 1-5、 Android 的 Java 层应用框架与 HAL 驱动框架(一)这是从基类与子类继承关系的观点来看的，基类属于框架；而子类则属于 AP。于是，上图就相当于：55認框架 API图 1

19、-6、Android 的 Java 层应用框架与 HAL 驱动框架(二)无论是 Java 层应用框架或是 HAL 驱动框架都是由商业强龙(即HAL框架公司)出资开发的。然后，强龙必须将 HAL 框架原始程序码提供给驱动开发者(地头蛇)，地头蛇就把 HAL 框架和他的驱动程序一起编译和连结起来。同理，强龙必须将 Java 层应用框架原始程序码提供给应用程序开发者(地头蛇)，地头蛇就把 Java 框架和他的应用程序一起编译和连结起来。此时，HAL 框架和 Java 框架会提供主动型 API 来呼叫地头蛇的程序。有了上述的强龙系统架构来支撑强龙商业架构，让稳居商业(或产业)分工合作上的强龙地位。應用

20、框架AP子子HALLinuxLibrariesRuntime基56如何開發 Android 應用框架：EIT 門派秘笈By2012_061.4.2制约力量的强弱等级框架 API 让基类拥主导(Dominate)地位，也就是说，基类主导了子类。例如，下图 1-6 里的 onCreate()函数所的 API，其制约力量强弱程度比率为：基类:子类 0.8 : 0.2就此 API 而言，基类具有高度的制约力量可主导子类。其理由是：1)基类开发者制定了接口(例如决定 onCreate()函数名称及其参数型态)；2)基类呼叫 AP 子类的 onCreate()，使得这框架基类的制约力量有 0.8(比率是

21、0.8:0.2)。如下图：图 1-7、 基类与子类接口的制约力量请看看下图 1-8，其中的 AP 子类呼叫基类的 setContentView()具象函数，子类拥有较大控制权。也就是说，相对上，框架基类与应用子类之间的制约力量比率是(0.4:0.6)。其理由是：1)基类开发者制定了接口(例如决定 setContentView()函0.8:0.257認框架 API数名称及其参数型态 ) ，应用子类并没有决定权； 2) 子类呼叫基类的 setContentView()，使得这框架基类的制约力量只有 0.4(比率是 0.4 : 0.6)。如下图：图 1-8、制约力量的等级然而，值得特别留意的情形是，

22、子类是否主动呼叫基类的函数。如果像上图一样，基类 Activity 透过先呼叫子类 myActivity 的 onCreate()函数，此时子类才呼叫 Activity 的 setContentView()函数。由于子类是呼叫基类(并非主动呼叫)，就不产生子类对基类的制约力量，所以不必把图中的(0.4 : 0.6)制约力量考虑进去。因之，从整体上而言，上图里的框架基类仍拥有高达(0.8 : 0.2)的主导性。刚才说过了，框架 API 通常具有两项特性：1)2)基类开发者制定(Define)了接口(即函数名称及其参数型态)。子类实作(Implement)此接口，并由基类呼叫(Call)其函数。0

23、.80.4:0.20.658如何開發 Android 應用框架：EIT 門派秘笈By2012_06此时让框架基类获得高达(0.8:0.2)的主导性。许多人常问到：甚么情况下，框架基类才能获得(1.0:0.0)的绝对主导性呢?诞生应用子类的对象。如下图：是：还需要具备另一个条件：由框架来图 1-9、绝对强势的制约力量此时，框架基类具有主导性，其制约力量强弱程度比率为：基类:子类 1.0 : 0.0也就是具有极强大的制约力量。值得留意的是，不一定是由自己亲属的基类(如Activity 或 Activity 的父类)来诞生子类(如 myActivity)对象。常常是由框架里的其它基类来诞生。例如，A

24、ndroid 框架的基类与应用子类之间，就实现了上整體1.0:0.059認框架 API述(1.0:0.0)的强大制约力量，让 Android 框架(内含基类)拥有制高点(即主控权)。1.4.3Why，框架 API?很多人常提出疑问：提供API的途径何其多? 为何特别强调框架的API呢?例如，一般程序库(Library)也提供API给开发者使用、网络服务(Web Service)也是一种API，为何只谈框架API呢? 为了回答这问题，必须回顾过去20年来的展经验了。其中有两项重要的事迹：发1980年代后期，CORBA是一项对象导向的服务标准API，实现此项标准的系统中，最著名的商业中间键构上，A

25、PI是一种制约力量，不是一种就是Orbix系统。然而，在系统架，不能用来嘉惠予AP开发者。导致CORBA和Orbix系统架构无法支撑理想的商业模式，而终告迹。匿1990年代中后期，继之后的是公司推出系统架构，虽然提供了当时先进的对象导向(Object-Oriented)的API，但还是API，仍然是一种制约力量，不是一种，不能用来嘉惠予AP开发者。与CORBA和Orbix一样的系统架构，一样无法支撑理想的商业模式，也终告匿迹。后来，IT业界逐渐发现：API可用来框住应用程序(AP)，如同一把利剑；若要获得开发者的青睐，利剑必须搭配面包，就像钩必须搭配鱼饵，才能吸引鱼群。于是，改变观点，把焦点放

26、在面包上，发现对象导向技术里的抽象类别(Abstract Class)及其提供的预设函数(Default Function)以及其它具体类别，所整合而成的框架(Framework)正式一项极具主动型 API，也能发挥巨大的控制力。因之，力的鱼饵。此外，由框架所提供的于2001推出.NET框架来取，由于.NET框架融合了面包与利剑，既能嘉惠广大的开发者，又能代有效框住众多的应用程序。.NET框架是给广大的开发者的最佳，和爱心，让他们因.NET而受惠。表达了对全球广大第开发者60如何開發 Android 應用框架：EIT 門派秘笈By2012_06到了 2007 年，机硬件厂商，也也依样画葫芦，买

27、来 Android 框架，当成给全球广大的 AP 开发者。由于 Android 框架给全球嘉惠予硬件厂商，所以全球的硬件厂商也是受惠者，因而大力支持 Android，也让Android 声势扶摇直上。Android 框架是面包与利剑的融合体，不仅嘉惠予硬件厂商，也嘉惠予全球数以万计的广大 AP 开发者，同时也主导了这些开发者。由于热情投入开发框架 API，并当成来送人，除了嘉惠众多硬件厂商，也嘉惠了全球的 AP 开发者，让人人能拥有没钱就，就有钱的利益。古贤者说：圣人无积，既以为人己愈有，既以予人己愈多。从历史可知，、热情投入的兴建，而成为最大获利者。如今，和微软都热情投入框架的开发，而成为幸

28、运的最大赢家。1.5 人人可以开发框架 API在 Android上，提供了强势的框架 API，掌握了系统的主动权(或升控制权)，大大拓展其市场版图，成为幸运的最大赢家。这常常让许多人误认为只有才有机会开发框架 API，其实不然，人人都能在开源&开放的 Android上开发基类来提供 API，并当成送人。当 AP 开发者采用你的框架(基类)API(即接受你的)时，由于你拥有主控权了。逐渐地，你开发愈多的基类 API，你的框架内容就愈丰富，提供了愈多奶水，就越愈能吸引众多 AP 开发者，于是你在系统架构里的地位就愈强势了。换句话说，人人都有机会发挥其特定领域(-Specific)知识，打造特定领域

29、的基类(和API)，成为特定领域框架(-Specific Framework, 简称 DSF)，提供特定领域的框架 API，提供了特殊领域的专业服务，帮助众多 AP 开发者，减轻其开发 AP的负担，也就能吸引众多 AP 开发者了，造就了自己成为特定领域的主导者地位。在 Android 基础上，需要千千万万各行各业的领域框架(DSF)，例如自己就开发出智能型电视(Smart TV)的领域框架。还有汽车大厂Continental 公司也在 Android上开发 AutoLinQ 车载领域框架。此外，诸如语音辨识、医疗影像等形形的领域框架，也将如同春笋般波波上市，不断充实Android的服务内涵，让

30、 Android更健康、更茁壮了。61認框架 API例如，在 Android 环境里的既有应用框架如下图：图 1-13、 Android 典型的框架基类与应用子类在这图里，上层的 Activity 和 View 是开发(并)的框架基类，其提供了 API(包括 onCreate()和 onDraw()函数)来制约 AP。这个有利于的优势该如何定位居主导地位，制约了各 AP 开发者。那么，系统架构，让位自己呢?开发的 DSF 又该摆在哪里呢?是：在上图的基类与子类之间可以加入小基类(如下图里的 Location 类)所示：的基AP62如何開發 Android 應用框架：EIT 門派秘笈By2012

31、_06图 1-14、自己框架的定位当你开发了自己的 DSF 小框架，来协助 AP 开发者，一方面节省 AP 的开发负担，另一方面藉由框架 API 去制约 AP 子类别，就能创造对你非常有利的主导地位了。Android 大框架就像一个大盘子，而小框架则像一个小盘子。两者兼容，小盘子迭在大盘子里，并不会破坏大盘子。如此，既不破坏 Android 的既有地位，又能鼓励人人都热情投入，开发各行各业的专业领域框架，将其扩充为有利于自己的新架构，创造了主导地位。Android 既有框架(我們的框架)框架APIAP63認框架 API1.6 回顾与展望：从古典到新潮 API首先假设你是服务(如云端服务或一般网

32、络服务)供应厂商，而你想要规划框架基类 API 来包装你的服务，并且让你拥有对 Cnt 端的主导性呢? 于是，从古典的 Cnt/Server 架构谈起，它的 API 呈现于 Cnt 与 Server 之间，并成为两端分工生产(或开发)的界线。通称为古典 API，传统分工模式。如下图：图 1-15、 古典的 API，传统的分工在这种架构里，是 Service_Imp 提供服务给 Cnt，犹如 Service_imp 种南瓜给 Cnt 吃(呼叫)，使得 Service_imp 受制于 Cnt，于是服务端无法对 Cnt 端产生制力量。由于 Cnt强势，使得 Service_imp 端常常成为救火队而

33、疲于奔命。此时，Service_imp 端就能开发自己的基类 API，透过这个新潮的 API 来自己的制约力量，就不必再了。如下图：64如何開發 Android 應用框架：EIT 門派秘笈By2012_06图 1-16、创造新 API，取得境内主导权服务端提供 AbstractService 基类来包装 Service_Imp 类别的服务；然后提供基类 API 给 C nt 端来使用。此时，服务端大胆地开放出 SubService 子类别给 C nt端来开发。于是， C nt 端既负责开发 C nt 类别，又负责开发 SubService 子类别。从上述得知，唯有服务端获得主导权，它才会大胆开

34、放给 Cnt 端来帮忙开发 SubService 子类别。一旦服务端获得更大的主导权，它就会更大胆地开放子类别给的 Cnt 端提供商去开发了。随着 Cnt 端的数量愈多，其地位就愈高，日益成为真正的强龙了。依据同样的道理，服务端也能进一步将拓展到(即 Cnt 端)，取得 Cnt 端的主导权，进而开放 Cnt 端的子类别。如下图：65認框架 API图 1-17、 主控权扩大到 Cnt 端在上图里，服务端提供商开发了 AbstractCnt 基类去给Cnt 端开发者，随之版图就扩大到 Cnt 端了。这把框架(基类)API 与服务(Service)做了很好的衔接。无论是在服务端，还是 Cnt 端，都

35、是由服务端提供商来开发基类 API 者，来取得全面性的主导权，进而开放出子类别。于是，框架基类 API 成为取得全面把这种架构应用到它的 GAE 云端和 Android 手性的主导权的利器。例如，机终端上，如下图：66如何開發 Android 應用框架：EIT 門派秘笈By2012_06图 1-18、的框架 API 创造了端与云的霸主地位在 GAE 云提供了 Servlet 基类，取得制约力量，就能大胆地上，开放子类别，让全球的 AP 开发者来云端撰写 Servlet 的子类了。一样的框架 API技术和策略，能运用于终端，也能运用于云端。替位。创造了端与云的霸主地同样地，Android 电视，

36、而 Android成云端变成电视机的终端。依循一样的框架 API 技术和策略，当你拥有了 Servlet 基类，就能大胆地开放给别人来你的电视机里写 Servlet 的子类(即 Servlet 程序码)了。当 AP 在 Android电视上执行，此电视机就变成终端了。当 Servlet 模块在Android 电视上执行，此电视机就变成云端了。事实上，在 Android 电视上，既能执行 AP，又能执行 Servlet 模块。于是，Android 电视就成为亦端亦云的设备了。如下图：67認框架 API图 1-19、版图继续扩大到电视机在 Android 框架里撰写了 Context 基类。此基类提供了丰富的 API。Android 的 AP 之间可以透过这 API 来沟通。当然，也能让 Servlet 模块来与 AP 沟通。例如，由别机里的 myActivity 传送 HTTP 呼叫到上图里 IServlet 接口，就呼叫到本机的 myServlet 子类别；然后由 myServlet 呼叫 Con