By 高煥堂

一、开放又不失控

      平台盟主必须制定强势型API，并落实于自己平台的软件系统上，平台盟主牢牢地掌控API的制定权。强势型API的制定和开放，是迈向平台化(&生态化)所必须的。平台的拥有者，要有勇气踏出一步，制定、掌握强势API，成为盟主，拥有话取权。平台盟主主掌API制定权，并努力寻觅到强有力的<抬轿者>，说服他(抬轿者)来出钱协助(盟主)开发平台的软件系统来实践API，他并替盟主拓展和推销，这平台的生命力就更旺盛了。

      平台(或生态)企业透过平台的支撑，逐渐位居盟主地位，心胸要宽大(开源又开放)、眼界要高远(有愿景、看十年、审时度势)，用心设计卓越方案(商业模式)来与所有关系人(Stakeholder)共襄盛举、互惠互利。此时，不仅仅API可以大胆开放出去，甚至平台的软件系统的源码(Source Code)都全面开放给各界去自行修改，也不必担心会应开放、开源而失控了。这个类似Google的Android平台软件系统，Google盟主主持OHA联盟，制定Android API，并加以开放。旣使Android的平台系统的软件源码全面开放，也不会失控。

      平台盟主并不一定要自己开发平台，其实做(开发)平台并不困难，人人都会的，而且制定API也很容易。但是，并不是人人都能具备API的制定权。所以，牢牢地掌握API制定权才有话语权，才会是赢家。简而言之，平台就像花轿，是否自己制造花轿并不重要，关键在于有人来抬轿，让自己坐上轿子(成为盟主、乘轿人)就可成功了。

      例如，Google的Nest产品，它是一个温度控制器，可以把家庭里的冰箱、彩电、洗衣机等，都连结到这Nest温控器上，它能知道什么时候该启动电器(如冰箱)，该运转多久，其成本最低。当Nest与众多电器连结，并制定强势的协同API，使它形成一个平台，发挥网络(外部性)效应。生态就逐渐繁荣起来了。然后，将API开放出去，鼓励众多公司来生产(或拷贝温控器)，由于牢牢地掌握API的制订权，对于API背后的网络协同、数据协同及AI算法拥有话语权，就不会担心生态会失控了。基于这像自信心，更可能将Nest的软件源码也全面开放给各界，迈向<大者恒大>的美好生态和枢纽经济了。

 

二、实践技术

      API的本意是：应用程序(App)与软件平台(Platform)之间的接口(Interface)，也是两者交互(Interaction)的协议。后来，逐渐扩大为更广泛的意义：泛指软件模块之间的接口，也就是两个软件模块之间的交互协议。这让API与UI有了明确的区别：

  • UI(User Interface)是指App与用户(User)之间的接口，也就是双方交互的协议。
  • API是指App与软件平台之间的接口，也就是双方开发者所订定的软件模块交互协议。

     大家都知道，接口是双方接触的地方，也是双方势力或地盘的界线。谁拥用接口的制定权，谁就掌握控制点，就能获得较大的主动权(或称为主导权)，而位居强龙地位；而另一方则处于被动地位，成为弱势的一方，扮演地头蛇角色。在当今的软件系统架构里，其API大多实现于父类(Superclass)的抽象函数(Abstract Function)上。这种抽象的父类又称为基类(Baseclass)。一个软件平台通常含有众多的父类别(基类)，并且有密切的交互关系。这些形形色色的基类的集合体，就通称为：应用框架(App Framework)。

       于是，应用框架就成为平台软件系统(又称为软件平台，或系统平台)的核心要素。而基类和API则成为应用框架的核心要素。所以说，一个商业平台的成功钥匙就藏在框架API的隙缝中。唯有能充分而全面性地理解框架API，才能拥有成功密码，成为平台&生态竞争下的赢家。所谓开源又开放API，就意味着：将API开放给众人来使用，并且将其幕后框架(基类)的源代码(Source Code)也公开给众人去修改和创造。也就是，将框架和 API当成礼物来赠送给众人。

       随着框架API这项礼物的大量赠送而广为流传时，其所携带的控制权(强势的制约力量)就逐渐扩展出去，于是势力和版图就日益扩大了。君不见，Google公司就把Android框架和API都是当礼物送人，因而让Google的势力无限延伸，进而主宰了整个产业生态。

 

三、如何开发(强势型)框架API?

      框架API让基类拥主导地位，也就是说，基类(Baseclass)主导了子类(Subclass)。例如，下图里的onCreate()函数所构成的API，其制约力量强弱程度比率为：基类 :子类  =>  0.8 : 0.2。

  

 此API而言，基类具有高度的制约力量可主导子类。其理由是：1)基类开发者制定了接口(例如决定onCreate()函数名称及其参数型态)；2)基类调用App子类的onCreate()函数，使得这框架基类的制约力量有0.8(比率是0.8 : 0.2)。请看看下图：

  

        其中的App子类调用基类的setContentView()具象函数，子类拥有较大控制权。也就是说，相对上，框架基类与应用子类之间的制约力量比率是(0.4 : 0.6)。其理由是：1)基类开发者制定了接口(例如决定setContentView()函数名称及其参数型态)，应用子类并没有决定权；2)子类调用基类的setContentView()，使得这框架基类的制约力量只有0.4(比率是0.4 : 0.6)。 

        然而，值得特别留意的情形是，子类是否主动调用基类的函数。如果像上图一样，基类Activity透过先调用子类myActivity的onCreate()函数，此时子类才调用Activity的setContentView()函数。由于子类是被动调用基类(并非主动调用)，就不产生子类对基类的制约力量，所以不必把图中的(0.4 : 0.6)制约力量考虑进去。因之，从整体上而言，上图里的框架基类仍拥有高达(0.8 : 0.2)的主导性。刚才说过了，框架API通常具有两项特性： 

  • 基类开发者制定(Define)了接口(即函数名称及其参数型态)。
  • 子类实作(Implement)此接口，并由基类调用(Call)其函数。

     此时让框架基类获得高达(0.8:0.2)的主导性。许多人常问到：甚么情况下，框架基类才能获得(1.0:0.0)的绝对主导性呢? 答案是：还需要具备另一个条件：由框架来诞生应用子类的对象。如下图：

    

        此时，框架基类具有绝对的主导性，其制约力量强弱程度比率为： 基类:子类  =>  1.0 : 0.0。也就是，具有极强大的制约力量。值得留意的是，不一定是由自己亲属的基类(如Activity或Activity的父类)来诞生子类(如myActivity)对象。常常是由框架里的其它基类来诞生。例如，Android框架的基类与应用子类之间，就实现了上述(1.0:0.0)的强大制约力量，让Android框架(内含基类)拥有制高点(即主控权)。 

       在Android平台上，Google提供了强势的框架API，掌握了系统的主动权(或升控制权)，大大拓展其市场版图，成为幸运的最大赢家。这常常让许多人误认为只有Google才有机会开发框架API，其实不然，人人都能在开源&开放的Android平台上开发基类来提供API，并当成礼物送人。当App开发者采用你的框架(基类)API(即接受你的礼物)时，由于你拥有主控权了。 

       逐渐地，你开发愈多的基类API，你的框架内容就愈丰富，提供了愈多奶水，就越愈能吸引众多App开发者，于是你在系统架构里的地位就愈强势了。换句话说，人人都有机会发挥其特定领域(Domain-Specific)知识，打造特定领域的基类(和API)，成为特定领域的应用框架(Domain-Specific App Framework)，提供特定领域的框架API，提供了特殊领域的专业服务，帮助众多App开发者，减轻其开发工作的负担，也就能吸引众多App开发者了，造就了自己成为特定领域的主导者地位。例如腾讯公司的微信(We Chat)也提供开放型API，给众多开发者撰写小程序。 

      在Android平台上，总共含有三个层级的接口(API)，包括： 

  • 上层Framework API：位于上层AP子类与应用框架之间。
  • 中层JNI API：位于应用框架与C++层Android核心程序库(Library)之间。
  • 底层HAL API：位于核心程序库与硬件驱动(Driver)之间。 

     如下图所示：

 

      其中，Java层的框架API部分(即蓝色部份)，往上支撑App子类，同时往下衔接到JNI(Java Native Interface) API。而JNI层的框架API部分(即绿色部份)，往上支撑Java层框架API，同时往下衔接到HAL(Hardware Abatraction Layer) API。至于HAL层的框架API部分(即棕色部份)，往上支撑JNI层框架API，同时往下衔接到硬件驱动(Driver)层API。 

四、框架API的设计法则：好莱坞(Hollywood)大明星原则

       框架的基类必须与应用子类互相紧密结合，其目的就是想要<框住>应用子类的行为。(詳細內容)

 

~ End ~