在移动开发领域，我们发现了一个很奇怪的现象：普通菜鸟培训3个月可以拿到8K甚至几万的工作；有一点工作经验的iOS开发需要2万月薪。不知道大家有没有想过：移动应用开发市场火了这么多年，为什么很多公司仍然面临着移动开发人才稀缺的问题？至于移动开发人才的增长速度跟不上市场需求发展的原因，我认为不能简单地归咎于市场供求关系。动力之源是移动应用的整体开发模式和开发效率低下的内因。正是市场需求旺盛与原生开发效率低下的结合，导致近年来软件开发行业人才严重失衡。于是，大家只好加薪抢人才。为此，我们一直在寻找一种高性价比的应用开发方案（实现低成本输入和高质量输出），尽可能降低应用开发的复杂度。应用复杂性的本质是逻辑和控制。逻辑决定了代码复杂度的下限，而控制包括对应用环境和设备环境的进一步优化。我们经常抱怨应用不够简洁，最根本的原因是没有处理好逻辑与控制的耦合。谈到应用复杂度的解耦，最常见的解决方案是通过元语言抽象将逻辑和控制分离，也就是通常所说的中间件方案。先科普一下：什么是元语言？简单地说，元语言就是对应用程序语法和语义的配置，相应的元数据就是对这些配置的具体描述。也就是说，meta既是数据又是代码。为了弄清楚这个问题，让我们简单回顾一下中间件开发技术的发展历史：最早、最基本的应用程序开发方式是元编程（MetaProgramming）：即从元语言到目标语言的编译器，将元数据编译成目标程序代码的开发过程。元编程模型要求我们为特定设备编程。每个设备都会在操作系统的基础上为开发者提供大量的API服务。最终应用程序的源代码将被编译和链接以生成可以直接运行的应用程序。程序。虽然开发过程的复杂度很高，但是元编程生成的应用程序的执行效率确实很高。使用元编程方法的开发工具有：汇编语言、c语言、PowerBuilder、VC、Objective-C等。我们可以通过下图来理解元编程：元编程之后，马上就出现了MetaDrivenProgramming：它是一种解释器，直接将元语言实现在目标语言，它是支撑中间件技术的基础方式。元驱动编程带来的最大优势就是我们不再需要针对特定??的设备进行编程。元语言需要预编译成中间代码，中间代码对不同类型设备的适配完全可以交给“运行时引擎”。”来完成，从而达到“一次编写，随时运行”的能力。使用元驱动编程方式的开发工具包括：Java、Flex、.Net等。我们可以通过下图来理解元驱动编程模型：MetaInterpretiveProgramming这几年应该比较流行：它让元语言直接运行在不同的目标环境中，也就是我们所说的Scripting语言编程。由于省略了编译和预编译的过程，代码的过程语法检查只能在运行时完成，理论上会降低应用程序的执行效率，但是随着计算机硬件性能的不断提升，性能问题已经被越来越弱化。同时，简洁而强大的语法元解释式编程的发展也大大提高了应用程序的开发速度，降低了程序的复杂度。使用元解释器的开发工具pretationprogramming包括：Javascript、Python、Lua等。我们可以通过下图来理解元驱动编程模型：为什么很多传统的应用开发规则在移动互联网时代不再适用？让我们比较一下移动设备和传统计算机架构的区别，看看移动设备的结构发生了哪些重要的变化。首先，移动设备移除操作系统的缓存。为了控制个别应用程序对系统造成的不良影响，当应用程序的物理内存不足时，会立即强制应用程序退出。这就是为什么APP开发中一点内存问题就会导致崩溃的根本原因，也是我们需要在项目中通过底层原生编程来优化APP稳定性的必要原因之一。此外，由于移动操作系统中个别应用的独立设计，系统级运行时引擎无处加载，自然而然地颠覆了元驱动编程在应用开发中的可行性，程序员不得不重新开始。开始寻找移动中间件技术的解决方案。第一代移动中间件编程（HTML5BasedAppProgramming）是一种基于HTML5技术的跨平台APP开发模式。在这种模式下，一般采用嵌入式webkit内核桥接原生扩展代码，使用HTML5构建网页UI，在网页中使用Javascript编写业务代码。在这种模式下，HTML5技术本身就具有跨平台的能力，很多传统的网站开发程序员也可以自然而然地进行技术上的转型。采用第一代移动中间件模型的产品包括：PhoneGap平台、数字天堂中间件产品、烽火中间件产品等。我们可以通过下图了解第一代移动中间件产品的模型：一代移动中间件技术，吸引了一大批传统的web程序员，很多人希望通过HTML5技术进入app。在发展营。但是，经过几年的尝试，我们发现，市场上主流应用的开发还是要由原生开发者来完成，用Html5开发的优质应用在几年后的应用商店中依然凤毛麟角。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完全没有移动互联网的基因。未来其实正在渐行渐远。Facebook在2015年初推出了ReactNative移动开发中间件技术，在结构上彻底摆脱了HTML5的束缚，真正打开了通过自定义原生控件渲染UI的框架之路。我们可以称之为第二代移动中间件编程（MetaExtendedAppProgramming）。我们可以通过下图来理解该模型：Facebook在ReactNative产品中提出的“Learningonce,writeanywhere”，本身就是一种复用思想。每个人都厌倦了各种编程语言。如果有一种语言能够真正统一移动开发领域，对大家来说都是一件好事。先不说这个框架以后会不会被大众认可。单从源码来看，这个框架源码中有很多值得学习的设计思想和实现方法。尽管ReactNative产品在实用性上还存在诸多不足，但其最大的价值在于为移动中间件技术提供了一种全新的开发思路。可能很多人没有注意到，2015年年中正式发布了一款DeviceOne移动中间件产品，它全面继承和改进了ReactNative产品架构，不仅实现了“Writeonce,runanywhere”的能力（支持IOS、Android，Windows10同时），也实现了原生开发扩展平台的完全开放。我们来研究一下这个二代移动中间件的改进模型：在DeviceOne模型中，所有的UI组件功能组件都被抽象成了cross-可以自由扩展的平台组件，甚至Webkit本身也只是在模型上退化了而已，只是一个普通的UI组件，App开发者可以自由选择js脚本、lua脚本甚至python脚本来编写业务逻辑，让昂贵的原生开发者可以更专注于底层技术创新和组件封装，让应用开发者可以更专注于业务需求ds具体项目，实现原生开发和应用开发的分离，即逻辑和控制完全解耦。随着移动互联网时代的快速发展，人类对“低成本、高质量”的APP开发技术的需求越来越迫切。FredBrooks在MythicalMan-Month中阐述的“没有银弹”理论一直对IT行业产生深远的影响：他认为没有任何技术可以在生产力、可靠性、和简单。震级。但在我看来，没有必要如此悲观。一切都没有那么绝对。任何原则都有其假设和范围。如果超过这个范围，原则可能会失效。例如：如果我们超出了大爆炸的范围，我们将失去任何参考，甚至时间的概念也会同时消失，更何况弗雷德布鲁克斯的理论？虽然“没有银弹”理论在软件工程范围内得到普遍认可，但我们不能推断“低成本、高质量”的需求是无解的。App开发技术的发展过程不能简单地线性描述，也不会局限于软件工程理论的范围。正如KevinKelly在《失控》中所说，IT技术应该更接近自然本身发展的规律。工业时代的标志是机械设计能力的巅峰，以IT技术为代表的新生物文明应该让设计再次回归自然。Reactnative和Deviceone的出现让我们看到了app开??发的新希望，这或许是期待已久的移动中间件技术发展的拐点。没有什么可以打破，但没有什么可以建立。Reactnative通过扩展标签实现了去HTML5，Deviceone在支持跨平台的同时进一步实现了去中心化。如果这种想法继续发展下去，移动中间件技术的未来将会如何？一旦我们能够通过一个分布式的、自下而上的去中心化控制系统来激发大量个体（开发者）的差异化发展，就可以最大限度地实现整个系统的自学习和自增。当系统人类的进化反过来影响和改变个体时，那么软件开发的生产力、可靠性和简单性可能会在每一次迭代中实现突破，甚至以指数级的速度开辟新的增长……
