
作者 | 齐修

微信小程序就是一个类似 RN(React Native)的轮子,可以快速开发,有一定的适用场景,但是也有其局限性。
注:该结论是基于微信小程序的示例代码做的解读,可能存在谬误。
早先,看到很多「权威人士」说小程序是 Hybrid 模式。一度怀疑自己之前判断的准确性,担心误导别人,所以额外备注可能存在谬误。
目前来看,这篇文章的判断比大部分博客文章的判断都准确。
简单总结下观点:
想知道微信小程序能干什么?对比服务号就知道了。
比如订票、航旅信息、ToDo List、天气日历、星座、理财、实时点菜系统等。其核心是:低频但重要的需求。
而且,微信不允许分享(导流),不允许链接(导流或广告)。
所以,想要靠微信朋友圈爆发的小机灵被彻底被浇灭了,媒体也不适合微信小程序。
微信和微信小程序确实也有一些不够完善的地方:
1. 微信小程序的官方文档写得不完善,很多方面没有覆盖
2. 微信小程序的开发工具极不稳定
3. 微信小程序的生态和问答社区几乎为零
微信的生态为零,导致部分功能开发起来吃力,比如解析富文本。
微信的问答社区就更差了,遇到问题全靠猜,实在找不到办法就重启。
4. 微信小程序的应用场景太受限
这个和微信的一贯保守风格很像,或许以后会慢慢放开,慢慢期待吧。
以上观点是站在一个普通开发者的角度,对微信小程序的看法。相反,从微信角度出发,某些限制和规范的确很有必要。
希望大家客观对待微信小程序。
而本文主要针对微信小程序的示例代码进行分析,想告诉大家以下几件事:
最后,还自作主张地说了点对于微信小程序的个人观点。
微信小程序都提供了什么?
微信小程序主要为我们提供了两部分东西:底层 API 、组件。
不仅如此,微信小程序还引入新的文件格式。
1. 引入了新的文件格式
微信小程序并不是传统意义的 HTML 5 页面,微信定义了新的文件格式,然后对这些文件做编译解析。
所以,微信小程序是原生应用!是基于微信的原生应用!微信正式尝试做一个 OS(操作系统)!

微信小程序组件
上图是一个 wx-action-sheet 组件,文件应用了新的后缀。
其中,WXML 功能和 HTML 类似,WXSS 功能和 CSS 类似,JS 包含组件逻辑。这点是不是和 RN/Weex 很像?
2. 微信提供了一套基础组件库
微信为微信小程序提供了一套基础组件库,可以满足开发的基础开发需求,从而实现简单的快速开发。
至于这些基础组件支持多大程度的自定义,以及能否满足实际项目的需求,就留给后续开发者去体验吧。
基础组件库主要分为四类:
action-sheet / button / searchbar / modal / navigator / drawercheckbox / radio / form / selector / switch / slider / input / label / pickerimage / audio / videoprogress / toast / scroll-view / text / view / mask / icon / spinner / swiper / slide-tab嗯,不用介绍大家也都知道这些组件大概是什么功能了,几乎是每个 UI 组件库都必备的。
以后大家应该都基于这个组件库去开发具体的产品。
和 RN/Weex 不同的是,微信小程序多半只能基于微信提供的组件进行个性化封装,而不能基于系统组件进行个性化封装。
原因很简单,因为微信就是一个「系统」。

微信是一个「系统」
我们挑一个稍微复杂的 picker 组件示例来分析分析:


是的,所有的标签都是自定义标签,进一步佐证了微信小程序是原生应用。组件使用很简单,所以很适合快速开发。

也很清晰,通过 this.setData 来设置属性,实现 action-sheet 的显示与隐藏切换。React 的感觉,连 API 都很像。

可以重新设置微信小程序的组件样式,和 CSS 很相似,轻量简洁。
3. 底层 API
没有提供底层 API 的基础组件库都是流氓库,有了底层 API 才能开发真正的原生应用,才能做更多丰富的功能。
其中底层 API 包括:
animation / backgronud-audio / canvas / download-file / file / get-location / get-network-type / get-system-info / get-user-info / image / login / navigation-bar-loading / navigator / on-accelerometer-change/ on-compass-change / open-location / pull-down-refresh / request / request-payment / set-navigation-bar-title / storage / upload-file / voice / web-socket
从名字也能看出个大概,小程序提供了比较完整的 API,能够开发更丰富的功能和程序。
我们仍然挑一个稍微复杂点的、图片相关的 API 使用示例来分析分析:



简单清晰 WXML,居然让选择图片及及预览实现起来这么简单。并且,可以通过简单的 template 语法来引入其他 WXML 文件。



因为微信对这个 API 已经封装得很好了,所以使用起来只需要传入几个参数,绑定一下回调函数即可。

同样,样式表语法近似 CSS,从上面的 rpx 单位可以看出,这不是真正的 CSS,我猜测是 CSS 的子集,类似 RN。
开发微信小程序方便么?
1. 微信小程序的开发目录结构
WX 的开发目录结构也很清晰简单。

WX 目录结构
入口文件就是最外层的 app.jsapp.json, app.wxss。
app.js 提供了入口文件的一些初始化和绑定。app.json 提供了项目的结构和一些项目配置,微信之所以采用 app.json 的模式,声明项目需要加载的页面和组件,应该是为了方便实现云端编译打包然后下发到微信吧。app.wxss 就是样式啦。page 目录放你需要实现具体功能的页面。util 存放项目需要用到的一些工具函数。

2. 微信小程序的部署流程
微信小程序的整个开发与使用流程都在微信的体系中,所以安装和使用应该都很轻量。
微信采用云端编译打包的方式,将编译后的文件发送到微信上,接着,微信内置的解析器会解析并渲染这个文件。
简而言之,微信小程序的开发体验还算流畅,代码可读性也很高,也不需要做太多新的知识储备,但是有硬伤,后文会分析。
微信小程序适合你吗?
这一块就不细讲了,毕竟不是我擅长的,借用三节课的分析,用两张图片告诉你微信小程序的适用场景。

行业区分

微信小程序适合什么
所以,微信小程序更适合用来做低频高需的服务,比如酒店订阅,火车票/机票订阅,招聘,理财等。
总结点什么?
以下代表个人观点,仅供参考,也欢迎讨论。
从产品层面来说,值得一试!
从技术栈来说,我不喜欢!
意淫一下,如果微信小程序的技术栈是 RN 而不是造一个轮子,那感觉才爽。