By 高焕堂 2013/06/01
Android多层框架的赢家策略-- 以POS系统开发为例
1. 现实的POS情境和需求
POS软硬整合产品必须卖给业主(如大卖场的商家)。由于商家是做生意的人，不会设计卖场专用的POS应用程序(例如，将POS结帐款项送往ERP系统)。所以，POS产品厂商就委托各地区或城市的当地应用软件开发商去帮助业主开发其专用的应用软件(简称AP)。于是，POS产品厂商就成为强龙，而全球各地区的AP开发者成为地头蛇，这<强龙/地头蛇> 合作模式能提供给业主最佳的服务。例如，笔者就曾经担任NCR公司在台湾的地头蛇，服务台湾当地的银行POS应用软件系统。
过去，都是洋人企业扮演强龙角色，国内本地企业扮演地头蛇角色。如今，随着本地内需市场的急速成长，提供给本地企业跃居强龙地位的大好机会。所以，本文不是叙述如何解决业主的需求，而是说明除了解决业主需求之外，又如何替POS产品(或手机)厂商设计出强龙系统架构，以即规划出其实现步骤。
第一步：从古典IT观点出发
在前面的<<多层框架API：软硬整合的新潮视角>>文章里，已经说明了古典IT观点的基本架构。现在，就来厘清它的两项基本流程：请求流程(Request Flow)和服务流程(Service Flow)。如下图1 所示：
图1、古典IT观点下的两项基本流程
在这观点下，并不太重视另一项流程，就是命令流程(Command Flow)。甚至很多人认为图里的请求流程就是命令流程。由于命令的来源是业主或AP(如古代的员外)，让底层POS产品厂商成为长工，就无法实现其强龙的梦想了。
第二步：加上命令流程(Command Flow)
这是基于上一篇文章里的新潮观点，基于这个观点，就能凸显出命令流程的重要性，以及其流动方向。如下图2所示：
图2、新潮观点所凸显的命令流程
大家都知道命令的来源是紫禁城内，流向北京城外，再流到长城之外。于是，将上图1和图2整合起来就是新潮观点下的三项主要流程。
第三步：设立关口传达命令
为了确保紫禁城内清朝皇帝的强龙主导地位，必然会最第一道防线(即万里长城)设立关口，并重兵驻守，成为具有高度主导性的接口，例如山海关、居庸关等。这种主导性关口，就是笔者在<<Android赢家密码>>一书所说的“主动型API”。唯有主动型的API(或称接口，或称关口)才能确保命令的传递和执行。如下图3所示：
图3、山海关、居庸关就是主动型API
在这观点下，业主(或用户)和AP是在塞外，是要服从命令的，在直觉上对用户体验并不会有所贡献。然而，因为硬件(如宏达电HTC手机或联迪POS)产品厂商位居紫禁城内，拥有强龙地位，其“强龙体验”的滋味是美好的。过去，软件开发人员一味地追求提升用户(地头蛇)体验，未能提升软件人员本身的地位。如今，软件开发人员除了提升用户体验之外，也关注于提升底层硬件厂商的强龙体验。[歡迎光臨 高煥堂 網頁： http://www.cnblogs.com/myEIT/ ]
基于这种新观点，让台湾的宏达电公司成为最赚钱的公司，其HTC手机也创造极佳的用户体验，至今(2011年)销售量全球第一，同样地台湾Android相关软件人员也因而获利。这说明了这个新潮观点，的确能创造“硬件厂商、手机用户、软件人员”三赢的局势。其将业主和 AP视为塞外，并将用户体验降到第二顺位；反而大幅提升了用户体验。这就是笔者在<<Android赢家密码>>一书所说的“神秘力量之一”。
第四步：实现软件关口(即框架API)
具有主导性(或防御性)的关口，就是主动型(即主导性)的API。在软件上，其实现机制是极为简单的概念：基类(Base Class)，又称为父类(Super Class)。如下图3所示：
图4、 软硬整合系统的山海关等关口
软件关口就是Java或C++语言的基类，是每一位软件开发人员都具备的基本技能。
2. 结语
俗语说：不为也；非不能也。如今，为何洋人喜欢撰写框架基类、掌握框架API，位居强龙；而我们身边的大多数软件开发人员，还是拥抱着古典IT观点、孜孜不倦撰写AP子类，一未追求用户体验呢? 换个观点而已，做法非常简单；只是不去做，并非不会做。由于底层硬件功能是整体系统服务的源头，也是提升用户体验的源头；唯有采取中国固有的新潮观点，让底层硬件服务视为九五至尊的强龙地位，才能真正实现好的用户体验，并带给软件开发人员极佳的获利机会。◆
[Go Back]
