最近这段时间接触了微信小程序开发,也有一段时间没写博文了,也来写写简单的见解以及开发的部分问题与感想。
javascript
本文同步于我的博客:www.imhjm.com/article/593…css
有人可能会困惑微信小程序跟微信内嵌H5有什么区别?html
其实若是你玩过微信小程序,你就能发现流畅度以及体验方面,小程序是完胜的
本质其实就是hybrid(混合)的app
介于web app与native 原生app之间,具有丰富的调用手机各类功能的接口,同时又具有灵活性,跨平台,维护成本也至关原生app较低,开发迭代速度也比较快前端
放一张网上的图,能够看出这三者的区别vue
有人这么评价小程序是“操做系统中的操做系统,生态中的生态”
就像是微信里面又开了一个app store同样,而后里面的app跟着微信自定义的规则来编写,其实就是个微信操做系统中的appnode
一开始我是拒绝的,微信搞了本身的一套基于原生的规范,还作了大量的限制,因此当时我并无看好微信小程序,可是由于微信影响力的缘故,而且宣传作得太好了,朋友圈、社区等等各类爆炸新闻,热度、活跃度也很是高涨,各类《第一个小程序教程》《微信小程序入门指南》等等层出不穷,而后整理小程序教程的repos的star量都能达到几k,让人不禁得想去探探小程序的究竟webpack
谈到生态的话,开放的时候,不少app很快就上线了相应的小程序,基本都是原生app功能性的弱化版,还有一些功能性较强的小应用之类的,好比什么亲戚计算器等等
然而,有人就会想着,小程序是否会打击到原有app的流量以及下载,用户是否会直接放弃原有的app?作小程序的效果反而拔苗助长?这确实要引发开发者们的思考git
过了刚开始的火热的阶段后,小程序就陷入一段低迷,不少人开始以为它是鸡肋,只是微信巩固它自己的超级流量而诞生的跟公众号相似的内置应用罢了,流量难以转入自己的app,用户粘性也不高,正如小程序的特色“无须安装、触手可及、用完即走、无须卸载”github
其实接触过微信小程序后,发现有些东西实际上是网上的误导或者自身的误解。
先来看看上面的问题,小程序是否会打击到原有app的流量,其实这个问题很好解决,你只要看看这个应用跟用户的交互度的高低,若是存粹是一些小工具的话,功能相对单一的话,毋庸置疑,必然打击,我就简单举个例子,好比摩拜单车,咱们其实只须要扫码用车,根本不须要别的东西,我为什么还要下载一个app应用,可是相似其余用户交互度比较高的,好比滴滴出行,小程序功能就很简单,只能供用户简单使用,打到快车,可是原生应用上则功能较为丰富,用户每每不会卸载掉原生的app
说到上面功能的阉割,既然小程序只是一些app应用的弱化版简化版,那小程序有何做用,它能带来什么收益?
曾经我也以为它很鸡肋,可是随着最近小程序开发团队的频繁能力升级以及本身的接触,仿佛看到了小程序是一块还没有挖掘开的巨大市场。
首先是微信小程序的能力升级,先是开放我的开发者,而后公众号支持添加转发,再而后开放群相关能力,小程序码以及数据分析能力也相应开放,着实让人看到微信小程序背后开发团队的活跃以及微信相关方面的重视,一些能力的升级让小程序的推广能力更强,让开发者有更大的权限去拿到用户关系以及一些用户信息,让体验更好。
其次是「匿名聊聊」小程序带来的启发,匿名聊聊经过小程序码在朋友圈推广,能够跟分享小程序的朋友匿名聊天,瞬间刷爆朋友圈,有消息透露,它四小时访问量高达40万,虽然由于微信不容许这种“影响朋友圈”的行为,最后被说因为“诱导分享“暂停服务了,可是咱们从这里能够看到小程序的强大影响力以及在社交关系上的强大优点,在这个移动互联网的时代,微信基本已经成为流量主体入口(根据questmobile数据,微信日活已经到达6亿),微信一方面利用小程序来巩固本身的流量超级入口地位,咱们未尝不能够利用它的流量以及实体用户来给本身带来红利,就相似匿名聊聊这类的,正经常使用户不多会去下载这样的app,这就跟陌生交友这些相似了,可是在微信这个载体下就不同了,用户身份是相对有保证的,用户经过微信入口进入你的应用,经过微信用户之间的关系就能够作不少事情了,也能够选择跟自己app用户连动,来使得用户留存
可是值得注意的是,并非全部小程序都能享受到微信流量的红利,若是只是单纯作一个app简化版的小程序,又有何用,用户没法看到你开发的微信小程序的优点和方便所在,作不到吸引用户,用户就只会放弃你的产品,我的以为,小程序不该该是所谓的“用完即走”,而是“用完很爽,下次还来”,打造一个精心制做的应用,利用微信小程序带来的社交以及流量的优点打造一个与原有app有所不一样可是能够看到用心制做的精致小程序,这样用户用完对产品承认,彻底能够唤醒产品的更多用户,不过,这就须要去试验以及推敲,像「匿名聊聊」这种打着用户心理将小程序玩成爆款的就是一个很好的例子
微信提供了本身的开发者工具(支持保存编译,ES5转ES6,压缩代码等),反正从发布到如今也迭代好多版本了,目前直接使用它的编辑器开发以为还能够,没遇到很大的坑,调试工具中css部分没有盒子模型、computed style之类的这点还有待提升
对于小程序开发框架,文档是这么写的
小程序开发框架的目标是经过尽量简单、高效的方式让开发者能够在微信中开发具备原生 APP 体验的服务。
框架提供了本身的视图层描述语言 WXML 和 WXSS,以及基于 JavaScript 的逻辑层框架,并在视图层与逻辑层间提供了数据传输和事件系统,可让开发者能够方便的聚焦于数据与逻辑上。
小程序也的确实现了现代前端框架的数据与视图绑定的特色,而不是dom的形式,可是它最大的缺点是缺乏自定义组件化的特色,虽然框架中提供了import/include,还有template,还有它内置的组件,这些能够提供js模块化,还有wxml模板之类,可是远远达不到咱们想要的,小程序很大程度跟vue很接近,包括一些绑定以及条件渲染与列表渲染等等,可是vue还有一个很大的特色就是组件系统,网站最基本就是html/css/js,可是其实咱们就能够把应用抽象成组件树,它们都是由一些可复用的组件构成,这样构建速度会很是快,并且维护方便,极大地提高效率
小程序DEMO:
project
├── pages
| ├── index
| | ├── index.json index 页面配置
| | ├── index.js index 页面逻辑
| | ├── index.wxml index 页面结构
| | └── index.wxss index 页面样式表
| └── log
| ├── log.json log 页面配置
| ├── log.wxml log 页面逻辑
| ├── log.js log 页面结构
| └── log.wxss log 页面样式表
├── app.js 小程序逻辑
├── app.json 小程序公共设置
└── app.wxss 小程序公共样式表复制代码
使用wepy框架后目录结构:(perfect!)
project
└── src
├── pages
| ├── index.wpy index 页面配置、结构、样式、逻辑
| └── log.wpy log 页面配置、结构、样式、逻辑
└──app.wpy 小程序配置项(全局样式配置、声明钩子等)复制代码
回到微信小程序,开发时还遇到一些小坑,好比实现回到顶部,这个在浏览器轻松实现,可是小程序没有提供bom/dom,惟一跟scroll搭上钩的就只有一个组件scroll-view,可是我还须要顶部下拉加载(竟然跟它的scrolltoupper事件冲突了?),只能用一些小技巧来规避这些问题,在切换时我想回到顶部,瞬间将列表项data设为空,再填入数据,这样就回到顶部了,虽然也实现了效果,可是未必有些hack
再谈谈小程序的rpx单位吧
rpx(responsive pixel):
能够根据屏幕宽度进行自适应。规定屏幕宽为750rpx。如在 iPhone6 上,屏幕宽度为375px,共有750个物理像素,则750rpx = 375px = 750物理像素,1rpx = 0.5px = 1物理像素。
设备 | rpx换算px (屏幕宽度/750) | px换算rpx (750/屏幕宽度) |
---|---|---|
iPhone5 | 1rpx = 0.42px | 1px = 2.34rpx |
iPhone6 | 1rpx = 0.5px | 1px = 2rpx |
iPhone6 | Plus 1rpx = 0.552px | 1px = 1.81rpx |
这个还挺不错的,让适配比较容易,否则在前端开发中还得使用rem、百分比等等一些技巧
不过须要注意
它官网提醒了在较小的屏幕上不可避免的会有一些毛刺,请在开发时尽可能避免这种状况。
我也体验到了这个毛刺
当你使用padding-bottom: 0rpx的时候你会发现实际上是有缝隙的,可是0px是不会有的
总之,小程序总体来看仍是不错的,并且开发团队也一直在努力,常常半夜两三点更新发布小程序的能力😂,也一直在往主流前端框架靠,支持了数据绑定、模块化、ES6等等,上手也很容易,不过要用它来作出一个让用户承认的精致的产品仍是须要费很大的心思的
谢谢阅读~
欢迎follow我哈哈github.com/BUPT-HJM
欢迎继续观光个人新博客~(老博客近期可能迁移)
欢迎关注