观点与机会
大家都知道观点(又称视角)本身是没有对错的,但是观点会影响人们的决策,而决策又会影响行为,然后产生不同的结果。因之,基于“赢家密码”观点而实践策略,会带来赢的机会;反之,则可能会错失大好机会。
Android 的三层 API
在软硬整合开发里,最主要的议题就是,如何让底层硬件的创新性能或功能与上层应用程序(简称 AP)的多样化相汇合,关于这项议题,我在《Android 赢家密码》一书里,已经详细叙述了,就不再重述了。
在 Android 平台上,规划上述软硬整合实践策略时,会涉及三层软件接口(泛称 API),包括:
- 上层的 Framework API:这是位于 Java 层的 AP 与框架(Framework)之间。
- 中层的 JNI API:这是位于 Java 框架与 C++ 层 Android 核心程序库(Library)之间。
- 底层的 HAL API:这是位于 Android 核心程序库与硬件驱动程序(Driver)之间。
俗语说:横看成岭侧成峰。意味着,事物本体只有一个,因为人人观点不同而有不同面貌的呈现。苏东坡《前赤壁赋》也写道:“盖将自其变者而观之,则天地曾不能一瞬;自其不变者而观之,则物与我皆无尽也,而又何羡乎?”即使同一个人,基于不同角度,观察到的现象也不同,因为会影响到人生或其它事物的态度、策略、行为和结果。
古典 IT 的观点
这个观点是基于“平台(Platform)”的概念,平台概念让人们联想到房屋的地基,AP 就是房屋,而平台就是地基。其地位尊卑顺序是:主人 ->AP-> 平台,如下图 1 所示:
图 1 古典 IT 观点下的 Android 三层 API
在这观点下,其焦点在于:
- 底层都是提供服务给上层调用,一切以 User 好用为目标,也就是追求优质的用户体验(User or Client Experience)。
- API 成为 Façade 的角色(可参考 Façade Pattern),提供单一接口是实现优质用户体验的重要手段。
- User 希望 AP 稳定不变,AP 希望 Java 框架不变,Java 框架期待 C/C++ 模块不变,C/C++ 模块期待底层的硬件驱动稳定不变。人人都期待脚底下的“平台”是不变的。
中国传统的观点
如果将 Android 里的三层 API 对应到中国清朝时期的三层城墙:万里长城、北京城和紫禁城。将可以让我们摆脱古老的 IT 观点,而得到新潮的观点:中国永恒的智慧 + Android 平台 -> 赢家的软硬整合策略。这非常接近清代大臣张之洞所提倡的“中学为体,西学为用”观点。于是,得到下图:
图 2 Android 平台里的三层 API
兹比较图 1 与图 2:
- 地位尊卑顺序相反。在图 1 里,愈上层的地位愈高。反之,在图 2 里,愈底层的地位愈高(例如皇帝居住于紫禁城内)。
- 行为决策相反。采取图 1 观点的国度,人人争先恐后去做 AP,因为(误认为)AP 的地位最高。反之,采取图 2 观点的国度,人人争先恐后去做框架和 API,因为(真正)地位最高,必须建造 API(城墙)避免敌人来争夺。
- 建 API 成为最大赢家。Google、微软等公司采取图 2 观点,微软于 2001 年推出.NET 框架;Google 于 2007 年推出 Android 框架;两者都成为 IT 业武林盟主。
- API 让底层先获利。基于图 2 的观点,愈底层的地位愈高,万里长城让观内居民先获利(不是塞外先获利)。所以台湾宏达电(HTC)公司专注于开发 Android 底层硬件和驱动软件(关内部分),成为全球获利最大的 Android 手机厂商。
以 POS 系统开发为例——现实的 POS 情境和需求
POS 软硬整合产品必须卖给业主(如大卖场的商家)。由于商家是做生意的人,不会设计卖场专用的 POS 应用程序(例如,将 POS 结帐款项送往 ERP 系统)。所以,POS 产品厂商就委托各地区或城市的当地应用软件开发商去帮助业主开发其专用的应用软件(简称 AP)。于是,POS 产品厂商就成为强龙,而全球各地区的 AP 开发者成为地头蛇,这 < 强龙 / 地头蛇 > 合作模式能提供给业主最佳的服务。例如,笔者就曾经担任 NCR 公司在台湾的地头蛇,服务台湾当地的银行 POS 应用软件系统。
过去,都是洋人企业扮演强龙角色,国内本地企业扮演地头蛇角色。如今,随着本地内需市场的急速成长,提供给本地企业跃居强龙地位的大好机会。所以,本文不是叙述如何解决业主的需求,而是说明除了解决业主需求之外,又如何替 POS 产品(或手机)厂商设计出强龙系统架构,以即规划出其实现步骤。
第一步:从古典 IT 观点出发
在上一篇文章里,已经说明了古典 IT 观点的基本架构。现在,就来厘清它的两项基本流程:请求流程(Request Flow)和服务流程(Service Flow)。如下图 1 所示:
图 3 古典 IT 观点下的两项基本流程
在这观点下,并不太重视另一项流程,就是命令流程(Command Flow)。甚至很多人认为图里的请求流程就是命令流程。由于命令的来源是业主或 AP(如古代的员外),让底层 POS 产品厂商成为长工,就无法实现其强龙的梦想了。
第二步:加上命令流程(Command Flow)
这是基于上一篇文章里的新潮观点,基于这个观点,就能凸显出命令流程的重要性,以及其流动方向。如下图 2 所示:
图 4 新潮观点所凸显的命令流程
大家都知道命令的来源是紫禁城内,流向北京城外,再流到长城之外。于是,将上图 1 和图 2 整合起来就是新潮观点下的三项主要流程。
第三步:设立关口传达命令
为了确保紫禁城内清朝皇帝的强龙主导地位,必然会最第一道防线(即万里长城)设立关口,并重兵驻守,成为具有高度主导性的接口,例如山海关、居庸关等。这种主导性关口,就是笔者在《Android 赢家密码》一书所说的“主动型 API”。唯有主动型的 API(或称接口,或称关口)才能确保命令的传递和执行。如下图 3 所示:
图 5 山海关、居庸关就是主动型 API
在这观点下,业主(或用户)和 AP 是在塞外,是要服从命令的,在直觉上对用户体验并不会有所贡献。然而,因为硬件(如宏达电 HTC 手机或联迪 POS)产品厂商位居紫禁城内,拥有强龙地位,其“强龙体验”的滋味是美好的。过去,软件开发人员一味地追求提升用户(地头蛇)体验,未能提升软件人员本身的地位。如今,软件开发人员除了提升用户体验之外,也关注于提升底层硬件厂商的强龙体验。基于这种新观点,让台湾的宏达电公司成为最赚钱的公司,其 HTC 手机也创造极佳的用户体验,至今(2011 年)销售量全球第一,同样地台湾 Android 相关软件人员也因而获利。这说明了这个新潮观点,的确能创造“硬件厂商、手机用户、软件人员”三赢的局势。其将业主和 AP 视为塞外,并将用户体验降到第二顺位;反而大幅提升了用户体验。这就是笔者在《Android 赢家密码》一书所说的“神秘力量之一”。
第四步:实现软件关口(即框架 API)
具有主导性(或防御性)的关口,就是主动型(即主导性)的 API。在软件上,其实现机制是极为简单的概念:基类(Base Class),又称为父类(Super Class)。如下图 3 所示:
图 6 软硬整合系统的山海关等关口
软件关口就是 Java 或 C++ 语言的基类,是每一位软件开发人员都具备的基本技能。
结语
俗语说:不为也;非不能也。如今,为何洋人喜欢撰写框架基类、掌握框架 API,位居强龙;而我们身边的大多数软件开发人员,还是拥抱着古典 IT 观点、孜孜不倦撰写 AP 子类,一未追求用户体验呢? 换个观点而已,做法非常简单;只是不去做,并非不会做。由于底层硬件功能是整体系统服务的源头,也是提升用户体验的源头;唯有采取中国固有的新潮观点,让底层硬件服务视为九五至尊的强龙地位,才能真正实现好的用户体验,并带给软件开发人员极佳的获利机会。
关于作者
高焕堂,台湾软件架构设计大师,从事 IT 行业近 30 年,被称为“台湾 OO 技术教父级代表人物”。现任 MISOO 软件开发与管理顾问公司首席架构师,编著过十余本软件技术相关书籍。
评论