小程序开发者，为何你应该尝试下MPX

做者：sky-admin

MPX框架(github.com/didi/mpx)是滴滴出行推出的一款专一小程序开发的加强型框架。本篇文章将从使用角度谈谈MPX的优点与好处。若是嫌内容太长，优点部分每一个小节都有简单的一句话总结，能够快速阅读。若是想了解更多设计细节，能够阅读 前一篇文章 - MPX2.0发布。

背景

在小程序逐渐火热的今天，愈来愈多的开发者须要进行小程序的开发。原生小程序的开发有诸多不便，开发者又须要在众多的小程序框架中作出抉择。

那么今天，咱们要给你们安利一款小程序框架：MPX

优点

之因此建议开发者们考虑使用MPX框架来开发小程序，是由于MPX框架具备一些别的框架所没有的优势。

MPX立足原生小程序，在保证坑少的同时作了不少能力加强，提供了数据响应、模板加强、性能优化、跨平台开发等能力，以提高用户的开发体验及效率。

接下来会从 原生兼容 -> 第三方组件支持 -> 按需构建 -> 跨平台编译 -> 能力加强 -> 独特性能优点 六个点来逐一讲述。

原生兼容

MPX彻底兼容原生，坑少。渐进接入简单。

从语法风格上，咱们能够看到目前市面上流行的小程序框架基本是基于web框架（taro/nanachi - react，uniapp/megalo/mpvue - vue）或者是一套全新（chameleon）/ 半全新（wepy）的标准。

使用了这些框架，你所写的代码，并非小程序代码。而是react/vue或者另外一套代码。而这些代码源码到小程序代码，须要通过一次全面的转换，这个转换可能会引入一些未知的问题，产生一些坑。

同时随着时间，小程序自身会逐步迭代，作出更多的功能特性，提供更好的组件、方法。而一些框架可能会受限于精力或框架节奏，没有办法第一时间跟进，甚至框架慢慢疏于维护而没法使用。

而MPX选择的是，全面拥抱原生。

口说无凭，咱们来看个典型的MPX组件长什么样。

乍一看好像和vue没什么区别，也就多了个json块，template里写的是小程序的标签。

因为这一块全是符合微信小程序原生语法，咱们是不会作任何转换的，因此你写什么就是什么。（若是使用了MPX的加强特性，仍是会进行一些必要的转换的，后续咱们也会出文章详细解释MPX的加强是如何实现的，相对来讲，咱们的转换比较轻量、透明、易理解）

当微信出了新的能力、新的标签、新的生命周期钩子，使用MPX框架来编写的小程序只须要直接用起来就行。

因此，使用MPX框架，你能够轻易地使用 自定义组件的relations 来搞定组件间关系，使用 wxs 来更好地构建页面。

MPX几乎支持原生的每个特性，在 .mpx 文件里，模板部分写的是原生小程序的模板语法，脚本部分写的是原生小程序的脚本语法，json部分写的是原生小程序的配置信息。用MPX，你才是真的在开发小程序。

目前不少原生小程序开发者可能想尝试下框架，老项目接入框架，选MPX确定是最简单的了。口说无凭，咱们搞了个demo来给你们打个样：在咱们GitHub项目中有examples文件夹，里面的 原生项目渐进接入MPX示例 。

第三方组件库

MPX提供了完备的第三方组件库支持

上面说了MPX对原生的极致兼容，能让你想到什么？对，就是对第三方组件库的完美支持。

支持第三方组件库的重要性你们都知道，因此这个能力大部分框架都支持了。可是支持和完美支持仍是有区别的。据简单观察，taro/mpvue/uniapp对于第三方组件库的支持都是以复制的形式进行的，也就是和微信小程序原本的行为很像。

那么MPX是怎么支持第三方组件库的呢，这里有个demo：也在咱们的GitHub里的examples文件夹下，MPX使用第三方组件库示例 ，核心代码见下图：

乍一眼看不太出来有什么特别的？没用过别的框架引第三方组件，简单找了找其余框架好像也没提供相应的demo，用过的朋友能够自行对比下。

在MPX里使用第三方组件库，仅须要***像web项目同样npm安装便可，并不须要复制文件***。而后在json里直接写包名就会去node_modules下面查找了。再配合webpack alias能够作到更简单、更语义化。

然而这尚未结束~

细心的朋友会发现，这段示例代码中既有vant的组件，也有iview的组件，若是按照微信的规范，这些组件库会经过miniprogram字段指定本身的构建文件生成目录，开发者工具会把这个目录彻底拷贝到最终发布的代码里去，咱们就会有两个巨大的组件库占据宝贵的空间。

咱们固然是但愿用多少引多少，而不是一股脑全引进去，对，因而MPX提供了按需引用的能力，在下一章按需引用细讲。

以及，组件库目前不多有跨小程序平台的组件库啊，若是我用了vant，支付宝、QQ里没有vant怎么办？也许这是别的框架不怎么推荐使用第三方库的缘由，而MPX里，咱们帮你把别人的组件库也转了，细节看下下章跨小程序平台

按需引用

经过webpack依赖分析收集，使用第三方组件库或者拆分开发大型项目时MPX能保证构建的代码全是要用到的代码

原生小程序自己的编译是遍历项目文件夹里全部的JS，包装成一个AMD包，也就是说项目文件夹里全部的文件，不管是否被使用，都会占用包体积并上传。

同时，原生微信小程序的npm支持是基于文件夹复制的，第三方包经过声明miniprogram字段指定要拷贝的文件夹，不论使用仍是未使用的资源（模板/js/样式/图片），全会被复制到项目文件夹中。

而咱们提供了@mpxjs/webpack-plugin插件，借助webpack生态，解析.mpx文件的json部分或原生的json文件将依赖做为新的入口添加子编译。基于依赖收集，而不是文件遍历。

带来的好处就是：若是你喜欢vant的按钮，iview的输入框，wux的布局，欢迎尝试MPX，让你能同时使用多个UI框架的同时不用担忧应用的体积过大。

同理，面对一个大型项目，咱们能够拆成不一样的部分，由不一样的团队完成后发npm包，在一个主项目中引入便可，具体内容能够看文档JSON加强 - packages一节。

收集依赖的细节能够查阅文档编译构建一节。

跨小程序平台

MPX的跨平台方法能带着第三方组件库一块儿跨小程序平台，同时提供了充足完善的条件编译能力。

在 MPX 1.0 时代，MPX框架是专一提高微信小程序的开发体验，虽然也提供了支付宝版，但代码彻底要另写。

而随着愈来愈多的 super app 提供了小程序能力，目前至少有5种体系的小程序（微信、支付宝系列、百度系列、头条系列、QQ），若是每个平台都须要维护一份代码，工程师人数明显不够用了，因此跨小程序平台的能力也是 MPX 2.0 的主打特性。

咱们的跨平台的方法就是转换。都是小程序，语法基本同样，配置、钩子的差别在MPX运行时里提供了抹平。

而除此以外最大的区别也就是模板上的标签和指令。因此咱们实现了一套转换的架子，再编写一份转换规则，便可完成微信小程序到支付宝、百度、头条小程序的转换。

采用这种转换的模式，很是方便用户理解咱们是如何把微信小程序转换成支付宝、百度等小程序平台的。并且只要用户有需求，能够补齐任一套小程序转换其余平台的规则，就能够完成以某个小程序为标准为基础来编写小程序代码以及进一步转换成别的平台的能力。

再结合前面一直在说的咱们对原生小程序的支持，就能够撞出一点不同的东西，好比，前文提到的第三方组件库跨小程序平台。

对，咱们能帮你把针对微信编写的ui组件库在支付宝、百度上运行起来，带着组件库一块儿跨小程序平台。

那么必定会有这样一个问题，就算MPX对原生的支持再怎么牛逼，有的基础能力只有微信平台有，别的平台没有，MPX的转换还能无中生有吗？

固然不能，其实这个问题对于全部的跨端框架都是一个问题，因此跨端最核心的问题是，如何搞定差别化部分。

MPX提供了丰富的条件编译能力，能够以文件为维度差异构建，能够以代码块为维度，也能够以代码维度进行差异构建。

并且MPX的差别化构建能力也是彻底基于webpack实现的，因此上面提到的第三方组件库若是确实存在转换不了的地方，好比vant的picker组件使用内联wxs写了一个小方法叫isSimple在模板里调用了，可是这个方法的写法在百度小程序的filter脚本（filter能够理解为百度小程序的wxs）里不支持，由于百度的filter要求必须导出一个对象包裹方法。

最好的解决办法固然是给vant-weapp提pr帮他们解决一下这个问题，但时间可能会比较慢，因此在MPX里，能够利用webpack的alias能力：

当尝试构建百度小程序时，会优先去查找pick/index.swan.wxml，再被alias到一个src下的文件，本身修改一下第三方包里有一些小问题的部分便可。

关于跨平台的条件编译，更多具体信息能够查阅咱们的官方文档 - 跨平台条件编译

能力加强

经过数据响应、编译时预处理提供了computed/watch，完备的样式类型绑定，双向数据绑定，动态组件等一系列方便开发者更好开发小程序的能力加强

能力加强应该是一个框架提供的最核心最重要的能力了，而MPX也确实在这里下了很大的力气，提供了多且好用的能力加强，不过受限于此处的篇幅，就只简单介绍，细节你们仍是查阅咱们的文档的好。

别的框架因为每每基于react/vue的，会给个列表写明不支持哪些能力，用户写的时候习惯使然，每每用了后可能才反应过来哦这个不支持。MPX则是原生的小程序语法写着难受时候忽然想起MPX有这个能力。

列一下MPX加强的能力：

• 模板上的加强
  • 样式类名绑定
  • 内联事件传参
  • 动态组件
  • 双向绑定
  • 节点获取ref
• JS里的加强
  • 数据响应
  • setData优化
  • ES6+
• 样式上的加强
  • 预处理支持
  • rpx转换
• JSON里的加强
  • packages
  • 分包资源优化

MPX最显著的能力是数据响应，它衍生出computed/watch，以及双向数据绑定等。这个能力和Vue比较像，不一样的是在MPX里是由mobx提供的数据响应能力。

而一样是数据响应，咱们作了一些不同的优化。

性能优点

经过对模板的解析抽象出访问的数据以保证在提供了数据响应能力的同时不至于劣化性能。

mpvue/wepy/megalo等框架也提供了数据响应的能力，可是数据响应在小程序领域有个较大的问题，微信开发指南里明确提到要注意setData的调用频次和数据量的大小。

而数据响应最基本的作法就是数据变了就去set数据，这会极大劣化小程序的性能表现。

而MPX经过对模板进行解析，抽象出对应的render函数，在调用setData发送数据前执行render函数找到真正须要发送的数据。

效果如图：

小程序开发者工具的audits面板能辅助用户分析出可能须要优化的点。正如前文所说，MPX在红框部分，尤为是红框里的第三条，不将模板上未使用的数据发送到渲染层上作了极大的优化。

只要不出现渲染函数执行失败（会有warning在console里提示，同时兜底逻辑会进行全量setData以保证程序仍可正常运行），使用MPX开发的小程序就永远不用担忧发送了模板未使用的数据。

虽然只是一个小小的TODO MVC示例，可是这个优化和应用的规模不要紧，并且同时你们能够尝试别家的小demo对比看看。

这个优化的细节能够看前一篇文章，或者咱们的文档MPX运行机制 - 数据响应与性能优化

总结

与目前市面上的诸多框架相比，MPX但愿以原生小程序为基础，全面拥抱原生小程序，在原生小程序的基础上作加强，经过尽量少的转换实现尽量多的能力加强，在提高小程序开发体验的同时，保证不因转换或框架的问题产生过多的坑。

MPX框架的目标用户是对小程序质量有较高要求的开发者，若是你是原生小程序开发者，或者厌倦了解决某些以web框架DSL语法为基础的转换框架形成的坑，欢迎尝试MPX框架。

MPX GITHUB：https://github.com/didi/mpx