uni-app
发布以来,已经服务了几十万开发者。让咱们意外,或者说惊喜的是,有大量开发者用uni-app
只编写H5版,并无多端发布(可参考案例)。javascript
这其实也符合uni-app
的初衷,uni-app
的定位并非须要多端发布时才用uni-app
。uni-app
是一个使用vue.js
开发全部前端应用的统一框架。对于一个前端工程师来讲,使用uni-app
作多端效率更高,作单一端也没问题,并在各端有很多出彩的地方。php
过去的版本迭代中,uni-app
已经成为了更好的小程序开发框架,比使用原生微信开发更有优点。(见评测)css
在uni-app
2.2的新版中,咱们大幅优化了H5版的性能,让使用uni-app
开发的H5,性能体验和直接使用vue.js
开发H5拉齐。前端
可能很多开发者有某种误解:多端框架要适配多端,因此性能确定不如原生。咱们想纠正一下:vue
vue.js
开发的web性能好,仍是使用原生js开发web性能好?答案是:使用vue.js
框架。为何?由于它在底层会自动优化数据同步、虚拟dom,比大多数开发手动写的代码要更高效。一样的,使用uni-app
也如此,框架底层的优化处理比大多数开发者手动写setdata或dom操做更高效。想优化H5端的性能,并非一件容易的事。java
“功能全面”和“小巧极速”,这是一对最难调和的冤家。nginx
为了保障多端的一致性,uni-app
实现了一套小程序的H5版Runtime,支持各类小程序的组件、API、配置。因此uni-app
的H5版拥有比其余框架更好的跨端一致性。git
但这也形成了老版的uni-app
,输出H5端时,包体积过大(框架未压缩前有500k,部署gzip后162k)。es6
这确实是一个很是大的runtime,包含了几十个内置组件,数百个API。并且这些API仍然在快速增长中。github
不能像其余框架同样由于功能少,因此体积小。咱们不会用功能换性能,咱们须要更好的方案。
uni-app
包含几十个内置组件、数百个API,是个“大而全”的框架;但开发者在开发具体应用时,未必能使用到全部的组件及API。若能根据项目具体状况,删掉没用到的组件及API,保留对项目有用的组件及API,即可精简框架、减小体积,这便是“摇树优化”的思路。
摇树优化(Tree-Shaking),顾名思义,摇晃树干,将枯死无用的枝条摇掉,仅保留有用的树枝。对应到框架层面理解,就是一个框架的众多组件和API,能够按需使用,把未引用的框架部分裁剪掉。Tree-Shaking 最先由 Rollup 提出,属于死码删除的一种形式。
常见的前端框架摇树,通常是基于明确的import
引用关系。好比引用某UI库时,在A页面使用该UI库的search组件,此时须要写js代码import这个search组件,那么摇树分析就很容易。
但uni-app
和小程序同样,内置组件和API是不须要import的,这提高了开发的易用性,但此时却加大了摇树的难度,依靠简单的import分析没法实现摇树了。
幸亏对DCloud团队而言,AST语法分析是看家本事,多年来HBuilder以js和vue语法提示著称。经过AST分析,uni-app
新版能够精准断定这个项目使用了哪些组件和API。
不过这还不够,分析工程源码使用了什么组件和API以后,还得考虑框架各组件和API之间可能存在依赖和耦合关系,这须要进一步的计算和关系梳理,具体而言:
vue-template-compiler
分析出来的AST,映射生成项目中使用到的组件清单,而后再基于Webpack插件将使用到的组件打包构建babel
查找到对应的 api 后,根据api 的依赖关系自动导入,从新编译在工程师持续的加班奋战后,uni-app
终于推出了全新的2.2版本,解决了这些难题,大幅下降了发行包体积,gzip后的框架体积,从162k下降到92k,仅至关于你在工程中引用了vue.js
、vue-router
、以及部分es6 polyfill库。(后续有详细比较)
除了大幅下降发行包体积,新版还调整了预载策略,能够进一步加快页面的渲染速度。
咱们使用vue-cli
建立uni-app
默认模板
vue create -p dcloudio/uni-preset-vue my-project
项目建立后,编译生成H5端的发行目录
npm run build:h5
而后配置nginx
服务器,指定root
目录并启用gzip
压缩,示例以下:
server { ... gzip on; gzip_min_length 1k; gzip_buffers 4 16k; gzip_comp_level 4; gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png; ... }
而后经过 Chrome DevTools 的 Network 面板,查看优化前的首页网络请求包大小,结果以下:
而后启用H5平台的优化开关,从新查看首页的网络请求包大小,结果以下:
能够看到框架主库(chunk-vendors.js)从162k变为92.8k,体积压缩43%!
实际上,框架主库主要分为三个部分:
若是对这三个部分再拆开对比,咱们会看到uni-app组件库优化比例更高:
vue/vue-router | es6 polyfill库 | uni-app runtime | 累计 | |
---|---|---|---|---|
优化前 | 38k | 43k | 81k | 162k |
优化后 | 38k | 26k | 28.8k | 92.8k |
Tips:
而后,咱们再经过Chrome DevTools 的 Performance 面板,查看优化先后的性能数据,对比结果以下:
能够看出,最耗时的脚本执行时间,从227ms提高为154ms,时间提高达到32%。
虽然内部实现比较复杂,但uni-app
对外暴漏了简单的配置,开发者只需在配置文件中打开一个开关便可。具体在 manifest.json 中h5
节点配置以下选项:
"h5" : { "optimization":{ "treeShaking":{ "enable":true //启用摇树优化 } } }
在uni-app
2.2版中,还开放了package.json
和vue-config.js
的自定义,开发者能够自由的配置编译策略。
如今能够自定义支持全部小程序平台,包括钉钉小程序、高德小程序、抖音小程序...等。这样除了标准的8大平台(iOS、Android、H五、微信小程序、支付宝小程序、百度小程序、头条小程序、QQ小程序),这些生态的子生态也能够分版本条件编译。
一样,也支持对H5端进行多子端编译,好比微信里的内嵌的H五、App里内嵌的H5...均可以分开条件编译。
如此灵活的条件编译,对于一套工程的多端发布、共享复用、同步升级,有莫大的好处。即使是仅开发H5版,uni-app
的多端条件编译也提供了更灵活和强大的工程化能力。
2.2版本还能够设置各类静态资源、js、小程序自定义组件的编译和拷贝策略。若是你以前的h5项目或小程序项目想转换至uni-app下,又不想挪动某些目录结构,那么在vue-config.js里配置策略便可。
在与直接开发h5拉齐性能的基础之上,uni-app
给开发者提供了更多优点:
uni-app提供了大量适合手机页面的基础组件(其实就是小程序组件)。还提供了扩展组件uni ui。插件市场更有600多款插件。
不管开发者想找一个电商的模板,仍是找一个图表组件,均可以手到擒来。开发效率更胜以往。
咱们开发H5时,常常须要给浏览器输出一份、给微信等超级App输出一份、给自家的App输出一份。甚至不一样地域、不一样用户画像,都会输出不一样版本。之前,开发者只能对js部分进行条件编译,甚至不得不建多个仓库进行多版维护。
uni-app解决了这些烦恼,它的条件编译很是灵活强大:
例如微信、QQ等在支持x5内核的内置浏览器中,使用x5的视频同层渲染;或者在微信服务号中调用微信卡劵,这段代码只有build到 dist/h5-weixin 这个目录下的版本才会被编译进去,其余平台不会有这段代码
// #ifdef H5-WEIXIN wx.openCard({ cardList: [{ cardId: '', code: '' }]// 须要打开的卡券列表 }); // #endif
接下来,uni-app
在H5端将提供服务端渲染机制(SSR)和PC宽屏界面适配优化,在追求性能极致和大一统的道路上继续前进!
相关代码所有托管在 github,欢迎你们 star 或提交 pr!