不务正业again

又一次不务正业,研究了下微信小程序。

其实微信小程序已经火了好久了。几个月之前内测的时候,很多人就迫不及待去研究,各种破解资料、教程满天飞。公司内部也专门组织人去学习了下。
可惜当时我事情比较多,只是打了个酱油,等公测开始才真正去研究了下。写了个简单的小游戏,算是对小程序有了个大概的了解。话说最好的学习方式果然还是实践。古人云:“纸上得来终觉浅,须知此事要躬行”。

本文不是一个教程,只是总结下学习过程中的感想。

初印象

其实最早的传闻,是微信要做一个叫“服务号”的东西,老大说要我们关注下,但完全没有头绪,网上也没有啥靠谱的资料。

题外话,我一直觉得微信的生态好复杂,订阅号/服务号/企业号傻傻分不清楚,公众平台/开放平台到底是啥关系,工作中碰到各种openId/unionId、各种授权的问题也总是会晕。而且这个生态特别封闭,自成体系,微信会管的很多,比如外链的限制、对外部接口的限制等等。这倒是和appstore有点像。
在这种封闭的生态中做开发,其实挺难受的。。。但生态封闭、开发难受,用户体验就能得到保证。参考ios vs android。而且,能做出这样一个生态真是挺NB的,不得不服。

另外,总有人纠结HTML5 vs H5,我觉得这种纠结很无聊啊。写作HTML5就比H5高大上了?有人看到H5就一定要去纠正一下:“你这样是不对的,应该是HTML5,H5是中国人自己发明的叫法”,以此彰显自己的专业。知乎上这种风气尤甚。你咋不说茴字有四种写法呢╮(╯_╰)╭?嘛,你们开心就好,我反正是个二手前端,图省事一般都叫做H5。

小程序的结构还是比较简单的,无非是WXMLWXSS解决视图层的问题,JS解决逻辑层的问题。WXML和WXSS可以认为是HTML和CSS的方言,只是有些特殊的限制,其实经过编译之后还是HTML和CSS。这套逻辑和各种概念早就被各种JS的MVVM框架玩烂了,实在没啥新鲜的。
WXML除了常规的数据绑定/模版/引用等概念,值得注意的是事件绑定,和普通的HTML不同,不过用起来挺顺手的。
WXSS和CSS没啥区别,写起来还是一样的痛苦。。。我本来还期望着微信能有什么方法解决布局的问题,释放二手前端生产力。。。为啥前端一直没有一种可视化的布局工具嘞?像若干年的VB6一样,拖拖拽拽就能搭出一个页面。mac上有个软件Sparkle实现了类似的想法,可是不太好用。

因为我之前有研究过一点React,于是学习小程序的过程中总是会不自觉的和React对比。小程序也确实和React有点像。比如setData明显就是抄的setState,还有组件化/生命周期等概念。但用户无法自定义组件是一大问题,而且只有页面级别的组件,也许这是微信为了降低开发复杂度而做的妥协吧。
应该说,页面是唯一的“容器组件”,所有的状态都在页面组件中。另外页面路由的管理也真是很迷。。。经常有些诡异的状况出现。

在视图层,微信提供了一些可用的基础组件,这些应该被称为“UI组件”(感觉是脱胎于WeUI),最大意义在于提供统一的视觉风格,跟React的组件不是一个概念。还不是很完善,尤其是对比Ant Design之类的。不知道什么时候会有小程序的第三方UI KIT。

小程序在WXML中绑定数据的逻辑又和angular有点像。不过我挺喜欢Mustache的语法的,有点像jsx表达式,但区别也很多。
WXML中的模版概念,感觉也是从angular中搞过来的。

总的来说,小程序开发框架(传说这个框架名字叫MINA?)就是个大杂烩,吸收了各种JS框架的理念,同时加入一些自己特有的API(我要吐槽微信的canvas API真是超难用,跟标准的canvas完全不一样,让我找到了小学用logo语言画图的感觉。。。)。
如果你之前使用过一些MVVM框架,那小程序完全没啥学习成本,直接就能上手。
就算之前没有接触过,相对于让人望而生畏的厚厚一本《Angular JS实战》/《深入React技术栈》,小程序对新手无疑也要友好很多。

一些思考

由于工作原因,我接触过一些JS-SDK。在我看来,使用了JS-SDK的H5页面已经可以很接近原生app的体验了,可以调用各种原生app的能力,除了慢点。参考微信自带的理财通。

那问题来了,微信小程序就是加强版的JS-SDK么?小程序和普通的H5区别在哪里?为啥微信要再造个轮子?

我的感觉:
1.运行时&效率的不同
这是最重要的区别。之前有消息说小程序使用了ReactNative。我以为是编译成native代码执行,但目测不是啊。摘自微信官方文档:

微信小程序运行在三端:iOS、Android 和 用于调试的开发者工具

在 iOS 上,小程序的 javascript 代码是运行在 JavaScriptCore 中
在 Android 上,小程序的 javascript 代码是通过 X5 内核来解析
在 开发工具上, 小程序的 javascript 代码是运行在 nwjs(chrome内核) 中

看来小程序的代码还是要有一个JS运行时环境去支持的。但微信应该有做过一些优化,坊间传言视图层(WXML中的块级元素)的渲染都是native的。否则打开微信小程序=扫码打开一个网页,那也太low了吧。。。至于是否有其他优化策略,还不得而知。
而普通的H5么,因为是用浏览器打开,效率明显会低一些。iOS上微信会调用系统自带的浏览器内核,Android上会使用内嵌的QQ浏览器X5内核(所以一直被吐槽是手机上的IE6)。

2.简化&规范开发流程,约定大于配置
相比开发一个H5页面,开发一个小程序的难度是很低的。摘自微信官方文档:

小程序开发框架的目标是通过尽可能简单、高效的方式让开发者可以在微信中开发具有原生 APP 体验的服务。

如果想用H5+JS-SDK实现类似于原生APP的体验,无疑是超级麻烦的,光是各种设备的适配就能搞个半死。。。而且使用标准的HTML时,要去关注很多跟业务逻辑无关的东西,比如各种<meta>标签、<script>的顺序、CSS属性的各种特定前缀之类的。
而小程序将这些复杂的事情都交给框架去做,同时对工程结构做了很多约定,简化了开发流程。从某种意义上说,JS-SDK只是个“工具”,而小程序才是真正的“框架”,就是jquery和react的区别。
这也是所谓的DRY原则。

3.重新整合微信特有的API
小程序提供了各种微信特有的API,比如登录/微信支付/照片/设备信息等等。我对比了下JS-SDK提供的API,发现二者是互相交叉的,小程序去掉了JS-SDK中很多用不到的API,而且小程序的API也好用很多。或者说,原来的JS-SDK的API设计的太烂了。。。用过的没有不吐槽的。

不过小程序应该也从JS-SDK借鉴了很多经验。

4.增加对生态的控制力
微信的生态一直是封闭的。而H5很难控制,你不知道一个页面是做什么用的,打开之后会发生什么,请求哪些服务端,也很难封杀。同样的页面内容,完全可以换个马甲就出来了。。。从战略上来说,对整个生态是不利的。
而小程序请求哪些域名、能做什么事、呈现什么内容,可以说完全在微信的控制之下。尤其是上架还要经过审核,想改就改,想封杀就封杀。越来越像老大哥了啊。。。对于所有的权利集团而言,当然是权利越集中对自己越有利啊。

5.渠道的问题
微信小程序的入口现在还不清楚。有说是二级菜单的,有说是像公众号一样的,甚至有说可以直接放在系统桌面的(估计只有android能做到这种吧,桌面widget)。不过不管怎样,相比只能在朋友圈里以url形式传播的H5页面,小程序的渠道肯定更丰富吧,离用户更近,也就更容易获得流量。

说到底,大家为什么这么看好小程序,还不是因为微信巨大的流量,9亿的注册用户,5亿的月活,还自带社交渠道的推广属性,怎么想都是很诱人。关键就看腾讯爸爸怎么分配入口和流量了。。。如果能拿到更核心的社交关系数据,想象空间更是无限大,不过这个腾讯肯定是不会给的,毕竟隐私策略也是个大问题。

个人感觉,小程序的关键在于“小”。小就意味着简单:开发简单,不需要投入太多;使用简单,用户进入后很快找到需要的功能,不会有太多的干扰因素;功能上也应该简单,即开即用,用完就走,不需要有什么顾虑。很多公司开发小程序,就是把自己已有的APP原样照搬过去,俺对此持保留意见。。。
感觉上,用户在打开一个小程序之前,就应该知道要干什么,知道要打开哪个程序。程序被打开后,让用户做完想做的事就可以了,而不要提供各种乱七八糟的额外功能。小程序应该专注于特定的本职功能。
所以我觉得一些工具类/游戏类的小程序会比较契合主题,一些“大而全”的小程序反而是理念有问题。可以参考下小程序的设计指南

还有啊,为啥大家默认小程序就是H5页面?各种视觉、交互都是按照网页的风格去设计,很多原来的在线H5设计工具,改一改就号称是小程序在线设计了。。。如果打开小程序就等于是打开了一个浏览器,那还有啥意思。
我理想中的小程序,应该是体验和native app一样的,用户打开app时,不应该明显的感觉到从app进入到了一个网页。用户都不傻的,“画风突变”还是能分别出来的。
我在使用一些APP时,碰到这种画风突变的情况,也会很蛋疼。。。不管你背后的技术是native还是H5还是hybird,至少体验要一致吧。

小程序一出来,很多人就叫嚣着“H5要取代app”,“H5开发需求要爆发”,“微信将统一所有APP”,“ios/android开发要失业”。。。嗯,开心就好。。。
这让我想到Facebook Messenger刚推出Bot平台时,大家也是各种激动,号称以后各种APP都将消亡,很多用户需求都将在Bot上满足,人工智能将迎来春天。甚至Bot上将形成自己的appstore。
乐观是好的,但忽悠人就不对了。客观的说,冲击肯定是有的,但说取代APP还为时过早。微信对APP的冲击从公众号时代就开始了。现在我们试水一个新业务,很多都是先做一个公众号而不是APP。至于小程序会带来哪些改变,谁知道呢,上帝的归上帝,凯撒的归凯撒吧。对个人而言,多关注些业界,多了解些技术总是不会错的,但也没必要过度反应。

之前不是也有好多人担心微信能不能过appstore审核。如果微信小程序真的能发展到威胁appstore的程序,苹果也不会坐视不理吧。之前为啥ios封杀flash,安全/性能只是一方面,更大的原因是flash“不受控”,adobe完全可以在flash上发展出自己的生态,flash生态中的应用/用户/数据,都完全不受控制。

不管怎样,拭目以待吧。

Hybird

我对APP开发的经验是0,仅有的一点点经验来自React Native。但平常跟各个APP的同学打交道还是比较多的,也知道一些概念。对Hybird这个概念一直比较模糊,正好顺道google下。

Hybird也就是所谓的混合开发,一个APP中,部分使用native实现,部分使用H5实现。一般而言展示性强的页面偏向于H5,功能性强的页面偏向于native。但也没有定式。好处嘛就是降低开发成本,但出现问题调试也比较麻烦。
我以前一直以为所谓的Hybird APP就是一个浏览器。。。所有的页面都是H5的,app本身只负责提供一些底层的接口。看了这篇文章才知道,Hybird也分很多种,H5甚至可以只负责局部的渲染。

感觉上,React Native应该不算Hybird吧,毕竟它是编译成原生代码。有点像编译型语言和解释型语言的区别。

H5和native通信的组件被称为JsBridge,但似乎没有一个标准的规范?各家APP都有自己的实现,个人没事也可以写一个玩,基本就是在原生的WebView上各种hack,拦截H5页面请求的一些特殊的url(比如weidian://methodName?k1=v1&k2=v2)再做出相应的处理。微信的JS-SDK调用native API也是同样的道理。
通过JS调用java方法,想想还是挺带感的。。。

话说,我最早记住的Hybird开发工具是Xamarin,忘了是从哪里看到的了。我一看这名字,“厦门人”,哎呦有个性啊。。。

参考资料

小程序现在不需要去看第三方的破解资料了,直接看官方文档就好。

腾讯云的小程序解决方案,能解决很多问题,session/websocket/https证书/域名之类的,但要有内测资格才能使用,而且收费:
https://www.qcloud.com/solution/la.html
https://github.com/tencentyun/weapp-solution

两个用于小程序界面设计的在线工具:
http://www.coolsite360.com/wxapp/
http://jisuapp.cn/

一个小程序论坛,有很多开源代码:
https://weappdev.com/

对小程序比较透彻的分析:
https://github.com/phodal/weapp-quick

一个比较好的小程序教程:
https://segmentfault.com/a/1190000007033827

两个纯用canvas做的小游戏,当作canvas入门挺好的:
https://developer.mozilla.org/en-US/docs/Games/Tutorials/2D_Breakout_game_pure_JavaScript
http://www.w3schools.com/graphics/game_intro.asp

CSS布局教程,对我这样CSS苦手的人是一大福音:
http://zh.learnlayout.com/toc.html

碎碎念

  1. JS真是无所不在,不光能写移动端的,还能写桌面端的。。。微信官方的开发工具其实就是个react应用,见这篇文章的分析。这种技术被称为node-webkit,感觉就是桌面版的Hybird啊,有空研究下。
  2. canvas是个好东西。理论上在canvas中可以做任意事情,发挥自己的想象力。Flipboard甚至搞出个react-canvas,所有UI都在canvas上绘制,真是有毅力。据说是为了避免DOM的性能问题?有空研究下。
  3. 强烈要求微信改进开发者工具,至少要可以自定义背景色和字体,白背景看得眼睛好痛。而且字体也太小了,也不支持html/css的格式化。
  4. 最近手贱rm -rf /了一下。。。这种事我一直是当作段子来看的啊,没想到居然会发生在我身上。看来不能高估自己的san值。
  5. 无论什么语言、框架、工具,甚至无论什么事情,生活中/工作上,想象力都是最重要的,它决定了一个人的上限。做出有想象力的作品是很难的,只会循规蹈矩很难有出路。为啥会有这个感慨呢,因为组里有个树莓派,在想能拿来干点啥。。。google的过程中惊叹于各种神奇的作品。有时候脑洞大点真不是坏事。
  6. 最近稍微看了些GTD相关的东西,在想要不要搞下“规范的”时间管理。这种方法论呢,没有定式,不要沦为单纯的使用工具,适合自己的才是最好的。