在移动开发领域我们发现一个很奇怪的现象：普通菜鸟新手经过3个月的培训就可以拿到 8K 甚至上万的工作；在北京稍微有点工作经验的 iOS 开发，就要求 2 万一个月的工资。不知道大家是否想过：移动应用开发已经在市场上火热了这么多年了，为什么很多公司还仍然会面临移动开发人才稀缺的问题呢？对于移动开发人才的增长速度总是赶不上市场需求发展的原因，我认为不应该简单归为市场供求关系的问题，其源动力还是来自移动应用整体的开发模式和开发效率低下的内因。正是这强大的市场需求和低下的原生开发效率结合在一起才导致了这几年软件开发行业人才的严重失衡，导致大家没办法也只能涨工资的方式来抢人才。为此我们一直在寻找高性价比的应用开发方案（实现低成本投入和高品质的产出），尽可能的降低应用开发复杂性。应用复杂性的本质是逻辑和控制，逻辑决定了代码复杂性的下限，而控制则包括对应用环境和设备环境的进一步优化。我们常抱怨应用不够简洁的最根本原因：就是其没能处理好逻辑与控制之间的耦合。说到应用复杂度的解耦，最常见的解决方案就是通过元语言抽象让逻辑和控制进行分离，也就是人们通常所说的中间件方案。先普及一下：什么叫元语言？简单说，元语言就是对应用语法和语义的配置，对应的元数据则是对这些配置的具体描述。也就是说元既是数据也是代码。为了能说清楚这个问题，让我们来简单回顾一下中间件开发技术的发展历史：

　　最早也是最基础的应用开发方式是元编程(Meta Programming)：也就是从元语言到目标语言的编译器，将元数据编译为目标程序代码的开发过程。元编程的模式要求我们要面向具体设备进行编程，每种设备在操作系统基础上会提供给开发者大量的api服务，最终的应用的源代码经过编译和链接两个过程生成可以直接运行的应用程序。虽然开发过程的复杂度较高，但元编程生成应用的执行效率确实非常高。采用元编程方式的开发工具包括：汇编语言、c语言、PowerBuilder、VC、Objective-C等。我们可以通过下图来理解元编程：

　　元编程之后，紧接着就出现了元驱动编程(Meta Driven Programming) ：它是直接在目标语言中实现元语言的解释器，这是支撑中间件技术的基础方式。元驱动编程带来的最大的好处就是我们不必再面向具体的设备进行编程，元语言需要先预编译成中间代码，中间代码对于不同类型设备的适配工作完全可以交给“运行时引擎”去完成，从而达到了“write once and run anyway”的能力。 采用元驱动编程方式的开发工具包括：Java、Flex、.Net等。我们可以通过下图来理解元驱动编程的模型：

　　这些年比较流行的应该还是元解释编程（Meta Interpretive Programming）：它可以让元语言直接运行在不同的目标环境中，这也就是我们所说的脚本语言编程。由于省去了编译和预编译的过程，代码的语法检查的过程只能在运行期间完成，理论上讲这会降低应用的执行的效率。但随着计算机硬件性能不断的提升，性能问题已经被越来越弱化，同时元解释编程简洁强大的语法也大大提高了应用的开发速度，也降低了程序的复杂度。采用元解释编程方式的开发工具包括：Javascript、Python、Lua等。我们可以通过下图来理解元驱动编程的模型：

　　为什么在移动互联时代，很多传统应用开发的规则都不再适用了呢？让我们来对比一下移动设备和传统计算机体系结构之间的差异，看看移动设备到底在结构上发生了哪些重要的变化。首先移动设备去掉操作系统的缓存，为了控制个体应用对系统造成的任何不良影响，在应用的物理内存不够时，该应用马上就会强制退出。 这就是app开发中为什么一点点的内存问题就会产生闪退的根本原因，也是我们在项目中需要通过底层原生编程来优化app稳定性的必要原因之一。另外由于移动操作系统中个体应用独立化的设计，让系统级的运行时引擎无处加载，这自然也就颠覆了元驱动编程在app开发中应用的可行性，于是程序员们就又要重新开始寻找移动中间件技术的解决方案了。

　　第一代移动中间件的编程(HTML5 Based App Programming)是基于HTML5技术的跨平台app开发模型。在这个模型中一般都通过内嵌的webkit内核来实现原生扩展代码的桥接，用HTML5构建网页UI，用网页中的Javascript编写业务代码。在这个模型下HTML5技术天生就具备跨平台的能力，而且很多传统的网站开发程序员在技术上也可以很自然的过度。采用第一代移动中间件模型的产品包括：PhoneGap平台、数字天堂中间件产品、烽火中间件产品等。我们可以通过下图来理解第一代移动中间件产品的模型：

　　在第一代移动中间件技术的发展过程，吸引了大量传统的web程序员，很多人都希望能够通过html5技术进入app开发的阵营里。但经过几年内大量的尝试后我们发现，市场上主流app开发工作仍然还是要交给原生开发人员完成，几年下来用Html5开发出来的优质app在应用商店里仍然是凤毛麟角。html5的交互体验能力和原生app开发之间的差距似乎越来越大了，虽然硬件设备的高速发展解决了部分html5页面运行效率的问题，但android和IOS每次大版本升级在UI交互能力上的提高却让html5技术有点越来越望尘莫及了。

　　随着技术的发展很自然又出现了对第一代移动中间件编程技术的改进模型，其结构如下图所示：

　　在改进模型中的变化主要体现在两个方面：首先是对原生扩展能力进行了进一步增强。除了对文件、照相机、通讯录等本地能力的扩展外，还增强了对原生UI框架的扩展能力以及对第三方服务的扩展能力；另外改进模型中还增加了扩展模块的概念对外提供开放平台，允许开发者扩展自己开发原生组件。虽然改进的模型在很大程度上了增强了HTML5和原生的原生交互能力，但最大的技术瓶颈仍然能解决，即对于基础UI的构建还是只能通过网页方式实现。开发者仍然需要通过网页渲染来模拟原生交互，所不同的只是可以通过网页内的javascript再去调用一些原生扩展功能而已。目前采用第一代移动中间件改进模型的产品包括：Appcan、APICloud、HBuilder等。

　　HTML5技术是第一代移动中间件技术发展的核心动力，但随着IT技术的发展，它也成为了移动中间件技术进一步发展的最大瓶颈。无论大家在第一代中间件的改进模型多么努力，却始终改变不了WebView的单线程模型、改变不了DOM/CSS的复杂而低效的排版和渲染水平、改变不了浏览器通过内嵌Cavas、WebGL和定时器来实现动画的在用户体验效果上的失败。 很多人都还在幻想着HTML5会成为App的未来，要知道HTML5这项Web时代的技术本身就不是为移动互联时代而生的，HTML5的骨子里根本就不具备移动互联的基因，它与App的未来实际已经是渐行渐远了。

　　Facebook在2015年初重磅推出了React Native移动开发中间件技术，在结构上完全摆脱了HTML5的束缚，真正开启了一套通过自定义原生控件渲染UI的框架的道路，我们可以称之为第二代移动中间件的编程(Meta Extended App Programming)。我们可以通过下图来理解该模型：

　　Facebook在React Native产品中所提出的 “Learning once, write anywhere” 本身也是一种复用的思想。大家厌烦了各种各样的编程语言，如果有一种语言真的能够统一移动开发领域，对于所有人都是好事。先不说这个框架后续是否能得到大众认可，单从源码来说，这个框架源码里有非常多的设计思想和实现方式值得学习。React Native产品虽然在实用性还有很大的不足，但它最大的价值则是为移动中间件技术提供了全新的发展思路。或许很多人还没有关注到，2015年中旬的时候一款DeviceOne的移动中间件产品正式对外发布，它对React Native产品架构进行全面的继承和改进，不仅实现了跨平台移动开发的“Write once, run anywhere”能力（同时支持IOS、Android、Windows10），还实现了原生开发扩展平台的完全开放。我们来研究一下这第二代移动中间件的改进模型吧：