在前端界，我们经常听到有一种引擎，一种框架，那么什么样的东西才能称为引擎呢？如果我们要写一个引擎应该怎么做呢？在编写引擎时，我们至少应该注意哪些方面？发动机技术能给我们带来什么？部分有价值的观点，和大家一起谈谈学习。 作者简介 屈一，第51届CTOWOT峰会特邀嘉宾，第七届WOT移动互联网开发者大会特邀讲师。从事互联网研发11年。曾在高阳、空中网、乐蜂网等互联网公司担任架构师、高级技术经理、技术总监。专注移动互联网近4年，国内资深HTML5专家、研究员。对HTML5技术有非常深刻的认识和理解，具有丰富的实践经验。HTML5引擎Crow5创始人，多次受邀中关村在线、iweb峰会、GITC全球互联网大会做嘉宾和专家。 奇乐康高级技术总监 1、什么是发动机？什么是轻量级框架？什么是重量级框架？一个更方便的框架。引擎技术其实就是框架技术。两者没有本质区别。我们前端应用的框架都是大家熟知的jquery、zepto、sea、Kissy等都是非常优秀的框架。这些框架简单易用，轻量级，学习门槛低。这些都是优点。这些框架就像一个个小积木，每个框架都有自己的特点，针对特定的使用场景，解决开发中遇到的痛点。例如jquery封装了大量Javascript方法，将工程师从重复编码、浏览器兼容、动画特效处理等方面解放出来。但是当我们在做移动项目的时候，会发现像Jquery这样的库实用性不是很高。很明显，Jquery解决了很多PC浏览器兼容方便的事情。与移动设备相比太大了，很多兼容性问题都不复存在了。.然后zepto框架出现了。Zepto定位为移动设备，因此它的体积要小得多。例如，当我们处理javascript模块加载问题时，可以使用Sea.js。sea是一个遵循CommonJS规范的javascript模块加载框架，可以实现javascript模块开发和加载框架。 每个框架都有自给自足的设计理念和痛点解决方案。使用尽可能少的代码解决更多的问题，同时提供方便的API。这些都是轻量级框架的优势。但是对于我们开发工程师来说，我们面临一个问题。我们在做一个项目的时候，会遇到很多很多的问题。除了模块开发，还需要动态加载、模板技术、动画处理等。还有缓存处理。如果功能比较复杂，需要调用地理位置和重力传感器。需要很多很多小框架。如果不用库，自己写，就得从头开始，一个一个填坑。使用图书馆就像玩纸牌游戏。它只能通过拼凑来完成。那么有没有什么好的框架可以一次搞定我们所有人呢？ 这个世界很奇妙，只要你需要，就会有人解决你的需求。答案是肯定的，在前端的世界里，在开源的世界里，你想要的都唾手可得。提到的优势是绝对的，但我们从来不缺工具。然后还有很多重量级的框架，比如YUI、EXT、Anglar.js、Bootstrap等等。这些都是重量级的框架。用它们的好处是大的同轨同册，统一度量衡。除了加载他们的核心库，你想要什么，这些重量级的框架还为你提供了很多很多的插件，让你用起来很爽。但问题来了。首先，这么重的东西，我们到底能用多少函数呢？而且，重量级框架的通病就是绑架了码农，束缚了码农的思维。只能按照他们的方式写代码。需要什么功能就是机械地找插件。如果没有完美匹配，则必须扩展插件。一不小心，处理一个小问题就需要很长时间。运气再差，一旦有陷阱，也很难解决。很多的灵活性就这样被吞噬了，现在我们都知道开发速度意味着什么了。另外，重量级框架的学习无疑就像学习一门语言，对于团队来说学习成本也是非常高的。由于各种原因，配重架在实践中使用不多。反正还是东拼西凑，换来的真人真不好用。程序员宁愿把自己的作品放在一起，也不愿打包。这就是为什么不再更新包括YUI在内的重量级框架的原因。 时代和观念一直在改变和修正。重量级框架有太多的优势却不能真正占据绝对的份额。除了使用之外，还受限于网络等诸多原因。 总之，重量级框架融合了众多轻量级框架的特点，并提供了统一的编码规则。集成了很多小框架，避免东拼西凑。但它失去了灵活性，劫持了发展，阻碍了扩展。学习成本增加。 那么引擎到底是什么？首先，引擎是一个框架。那么引擎一定要有轻、小、快的优点，是插件，是模式。还要有重量级框架的思想，可以给出统一的方法论，避免东拼西凑。同时，引擎不应该像重量级框架那样劫持开发，而应该为开发者提供灵活的使用方式。 其次，发动机技术是如何诞生的？ 引擎技术要发扬框架轻量化的优点。插件开发没有侵入性，是面向切面的，想用就用，不想用就轻松拉走。引擎应该继续向重量级框架学习统一的思想，能够给出一个完整的方案去尽可能解决问题。 我们在编码的时候，最常用的一个思想就是封装，这也是框架和引擎技术的一个重要思想。我们把操作、动画、渲染、业务类型封装起来，然后看能不能抽出一些更细粒度的，***把这些一个一个封装到类库里，***按照好的目录和命名规则存放。方便参考，然后给出合适的加载和调度方式结合代码。程序员开放的时候，会不断地扩充各种颗粒状的库。未来的发展有点像搭积木。那么，一个适合我们项目的简单的小框架就已经成型了。 但是这些还远远不够，因为至少少了一个重要的东西，就是规则。虽然在写代码的时候，可以通过搭积木的方式搭建代码，减少了很多生硬的写法。但是还有基码操作。***，我们会发现，在做一个功能的时候，一般总会有加载模板资源、请求数据、渲染处理、事件处理等等看起来不一样，但是方法论却重复了无数遍。试想一下，如果我们能把这些重复的方法变成规则，让代码按照一定的关系自动执行这些重复，就可以省去很多机械重复的代码库流程。 基于这个想法，我设计了一个规则引擎。Crow5就是在这样的指导思想下诞生的。虽然不可能完全实现代码的自动生成，但是代码应该尽可能接近，这样才能生成更多的代码。那么为什么代码可以按照一定的逻辑生成代码呢？这很简单。我写了一个内核，除了读取我发布的指令并通过我发布的指令完成基本代码外什么都不做。过程。那么，指令是什么？是我给这个内核的配置文件。在这样的思考过程中，我们有如下设计。 按照模块开发。我们以前在control、service、module、dao层处理函数。***模式变了。分层是组装代码的核心，***我们只需要给出指令即可。 大家可以看上图。当我们编写代码时，方式发生了变化。以前需要写逻辑控制代码、功能代码等，现在只需要提供一个配置文件指令即可。#p# 三、如何提取适用引擎？ 抽取核心引用的库，抽取逻辑控制，抽取表现，抽取业务。4、如果我们要写一个引擎，至少要完成哪些功能？（可以说是做引擎的最低要求） 虽然没有明文规定做一个引擎需要多少东西，但我这里给出一个参考方案。如果可以提供一个引擎给别人使用，至少需要下面的处理机制，或者设计下面的处理机制，让自己写的库可以被别人使用。 代码约定模式、交互提取模式、数据封装模式、加密混淆机制、工具包、插件管理模块、加载器、拦截器、动画处理模块、缓存控制器、超时监听器、模板控制引擎、性能处理模块（延迟加载、按需加载、加速器）、业务逻辑控制工厂、操作日志管理。 当然，根据不同的项目，还有很多特殊的模块。比如客户端涉及到解压，可以设计一个请求代理模块。 也会提供API层供开发者配置或编写。当然，还需要一份尽可能完整的用户手册。 5.什么是约定编程？它与发动机技术有何关系？ 我们在编程的时候，如果尽量减少代码量，最直观的方式就是约定俗成。比如春种就有约定模式的影子。所以在设计Crow5的时候，我采用了很多约定俗成的模式。 简单说明，如果页面调用index.html，那么controller调用可以调用UI.index。然后，可以将页面请求的接口约定为romote_index。被调用模板的名字可以叫做index_tpl。如果是ajax处理的事件绑定函数，可以约定___index等。所有处理逻辑条目和调用的名称都可以商定。如果有这个约定的方法，那么所有类似的编码都会有规则，这样就可以抽象成一个规则引擎。那么我们以后只需要传递参数和配置即可。代码根据规则自动生成。 以上页面是引擎自动生成的，大家可以看一下代码。 编写的代码是配置文件，其他所有代码都由引擎自动处理。所有性能处理都是可配置的。这大大减少了重复编码。 6。您对发动机技术的后续研究会是什么样子？ 以后继续研究的是语义抽取。所有引擎代码部分都可以通过云平台按需自动分配生成项目引擎核心。自动实现根据平台的配置自动生成配置文件。这样在做APP或者demo的时候，可以自动生成。 探索是无止境的，需要大量的灵感。许多设计灵感都来自动物。比如在设计心跳维护技术的时候，就是观察青蛙的冬眠状态，将心跳加速、减速、停止、唤醒等提取总结出来，希望引擎技术能够在以下方向不断突破语义，到时候编程可能就变成问答题了。
