# 第一章 微信小程序的过去、现在与未来
# 1.1 什么是微信小程序
什么是微信小程序：小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或者搜一下即可打开应用。也体现了“用完即走”的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无须安装卸载。
————张小龙
微信之父张小龙在2016年时用这段略带文艺气息的描述给小程序做了定义。但这段描述仅仅表明了小程序诞生的初衷，却无法限制高速发展的小程序的未来。时至今日，小程序早已不再局限于“用完即走”，各式各样的小程序已呈现百花齐放的状态。
但本书的第二版，依然保留这段对小程序最原始的定义，以方便小程序的开发者可以同时了解小程序的过去、现在以及未来。关于小程序的变化，我们将在后续的章节中向读者进行介绍。
小程序无论从技术上还是从理念上都不是一个新事物：从技术上讲，它借用了React Native的一些概念，定义了一套微信自有的组件并根据运行环境的不同（PC、iOS、Android）将这些组件编译/转化为对应平台的可运行组件；从理念上讲，百度早年的“轻应用”、QQ右下角的“应用宝”还有支付宝里的各类小服务，早已是小程序的雏形。
我们来直观地感受一下小程序，如图1-1～图1-4所示。
有人会质疑，这和我们常用的App并没有什么区别。确实如此，小程序并没有逃脱App的范畴。事实上，小程序也只是App的一种。那小程序的优势在什么地方？
我们试想一下，如果上图中的这些应用并不是“寄生于”微信中，而是以原生App的形式存在于AppStore或谷歌的应用市场中，而我们每次使用都需要经历“打开AppStore”→“搜索应用”→“点击下载应用”→“安装应用”→“使用应用”，这个过程是相当烦琐的。关键是，很多应用我们并不会经常使用，可能一个月甚至一年才会使用1到2次，而这些“低频”的应用却要长期地“驻扎在”我们的手机中，需要我们去管理这些应用的“生命周期”，这个体验是不太好的。小程序要的就是“随时可用，触手可及”，而现在的App太重了。
小程序的出现就是希望用户不用安装那么多的App，你想用什么服务，只需要在微信中“扫一扫”或者“搜一下”即可享受到“触手可及”的服务，“无须下载安装”，用完后也不需要管理它，“即用即走”。
小程序还有以下若干“别具一格”的特性。
- 小程序没有“官方的”应用市场，这是小程序和iOS、Android生态最大的不同。为什么强调是“官方”？因为还是有一些第三方的小程序应用市场存在的。没有应用市场，也符合微信提出的小程序要“去中心化”的概念。
- 和微信公众号不同，小程序不能被关注，所以他很难留存用户。留存用户这个工作，微信还是希望由微信公众号来完成。
- 小程序没有群发消息和主动推送消息的能力。
- 小程序有一定的分享能力，可以分享给微信好友，也可以分享到微信群聊中，但不能分享到朋友圈。
- 同一个公司的公众号和小程序可以相互发现。公众号里可以看到该公司的小程序，同时，小程序里也可以看到该公司的公众号。点击后可相互进入到小程序或者公众号中。
本书是一本专注小程序开发的书籍，并不会过多的探讨小程序的商业模式和运营。但这里我们列出一些对小程序运营有帮助的功能供各位开发者参考：
- 小程序与小程序之间可以相互跳转
- 小程序可以被嵌入到公众号文章中，用户可以从公众号文章中进入小程序
- 公众号文章可以通过WebView技术嵌入到小程序中
- 小程序虽然不能直接分享到朋友圈，但小程序的二维码可以以图片的形式分享到朋友圈中,从而可以间接的实现将小程序分享到朋友圈的功能
# 1.2 小程序的过去、现在与未来
注意本小节的标题，我们没有强调“微信”小程序的过去、现在与未来。因为过去只属于“微信”小程序，但是现在已经出现了“支付宝”小程序、“百度”小程序和“今日头条”小程序。未来，也许还有更多的小程序将涌现出来。
从目前来看，小程序已经成为一种新的应用形式，并不仅仅局限于“微信”的小程序。从另外一个角度讲，微信确实可以自豪，小程序技术的原型和创意也许并不源自微信，但微信确实这次又做出了一次巨大的创新和尝试，而且他确实成功了。在笔者看来，无论是支付宝小程序、百度小程序亦或者是今日头条小程序大多数都是出于防御性目的推出的。简单来说就是你有，我也一定要有，无论小程序对我是否重要，我都必须要有。
这很像2011年前后四大门口（新浪、腾讯、搜狐、网易）的微博大战，新浪领头，但其他门户出于防御性策略是必须跟进的。最后的结果，我们可以看到，新浪的微博成为了唯一的幸存者。那么，小程序大战会类似于当年的微博大战一样，最后只有一个幸存者吗？
笔者认为小程序不会出现这种“最后幸存者”的情况，因为小程序虽然可以视为产品和模式，但本质上来讲它是一种新的技术，它可以用来改善原有H5的体验，各个公司都可以用自己的小程序替换原有的H5，从而提升自己App的总体体验。所以，这些不同的小程序将会长时间同时存在。此外，如果你对每个公司的小程序有深入研究的话，你会发现，其实他们的定位和应用场景是有些差异的，都有各自的平台优势。比如微信小程序的优势在社交，在微信的高频；百度的小程序优势在与搜索结果关联上；支付宝的小程序更多的是立足于商业和服务上，这与支付宝本身的优势相匹配。
虽然各个公司的小程序会同时长期存在，但它们确实会存在一个主流与热度的问题。由于起步最早、依托微信、API稳定成熟，微信小程序目前是处于主流的位置。所以，如果我们开发者从来都没有接触过小程序，最好的学习起步平台依然是微信小程序。
由于本书只探讨和研究微信小程序的开发，并不会涉及其他类型小程序，所以在本书中所有的“小程序”均特别指代“微信小程序”。
在早期，正如同小程序官方给小程序打上的标签，我们都认为小程序只适合去做用完即走的服务。但事实上，小程序目前的应用类型五花八门，早已超出了公测时大家都普遍认为的小程序只适合做低频类的应用。我们看到有视频类小程序，有直播类小程序，有长内容型小程序，甚至还有微信小游戏(早期的直播和游戏是不被允许的）。
所以官方所谓的“用完即走”只是一个建议，并不是约束。但我们要清楚地认识到，能不能做和合不合适做是两个概念，这取决于小程序版本的各类应用相比原生App到底有哪些优势。这可能是成本上有优势，可能是推广上有优势，也可能是同微信生态相结合的优势，这需要开发者均衡考虑。
# 1.3 什么类型的应用适合用小程序开发
2016年1月11日，张小龙在微信公开课中首次公布了“应用号”，而在2016年9月21日，微信正式开始了“应用号”的内测，但是却改称为“小程序”。“小程序”这个名字确实非常符合张小龙对于这类应用的定义。
再次强调，适合不适合只是相对的，微信官方并没有明确限制你不能做什么类型的小程序。而且现在已上线的小程序已是“乱花渐欲迷人眼”，早就将张小龙的“用完即走”抛到了九霄云外。我们只能描述它本来应该是什么样子的，至于为什么那么多小程序都不是“用完即走”的，笔者只能说，一个刚起步的生态对创业者和开发者的诱惑力实在是太大了。
“简单的”、“低频的”、“对性能要求不高的”应用适合用小程序来开发。“简单”是指应用本身的业务逻辑并不复杂，比如外卖应用“饿了么”，业务逻辑就非常简单：挑选想吃的菜肴，下单、付款；再比如在线购买电影票应用“猫眼”，就是为用户提供在线购买电影票的服务，整个服务的时间是短暂的，“买完即走”。还有各类O2O家政服务、打车类应用、天气预报类应用，都符合“简单”这个特性。相反，一些游戏类、社交类、视频直播类应用则业务相对复杂很多，用户在应用里停留的时间也会较长，这类应用就不太符合“简单”这个特性。对于业务复杂的应用，小程序无论从性能上和体验上都没有办法满足这类应用。
“低频”是小程序使用场景的第二个特点。如果某种应用的使用频度很高，比如社交类的QQ，金融类的支付宝、招商银行，社区类的百度贴吧、知乎等，由于使用的频度较高，以iOS或者Android的形式提供给用户会更好。当你使用小程序时，需要先打开微信再进入小程序，这对于高频的应用并不是太方便。小程序目前来看，还是适合做一些如手机充值、电影购票这类使用频度不高的服务。举个例子，当你正在微信中聊天，突然想起手机没话费了，那么就“顺手”点开小程序为你的手机充值。但是，如果你经常需要特意地去寻找某类应用，又长期需要这类应用，那么还是以原生App的形式提供给用户比较好，用户为这类应用去下载、安装和管理这个应用的一系列操作是值得的。
“对性能要求不高”是因为小程序寄生于微信这个原生App中，又受限于Web技术的性能制约，注定它无法去开发对性能、体验要求很高的应用，比如“保卫萝卜”、“阴阳师”等这类游戏应用。此外，小程序还处于发展初期，没有太好的技术和工具去支持这类复杂度较高的游戏（没有类似于Unity 3D 这样的专业游戏开发工具）。
最后，我们还是需要强调，适合做怎样类型的应用只是一种建议，并不是约束。甚至微信官方现在也基本不再强调微信小程序以上的特点了。连游戏和直播都可以做成小程序的了，那还有什么不能的呢？
笔者是一个比较纯粹的技术人员，这里有一点经验和原则可以分享给大家：小程序目前确实不适合去做交互很复杂的应用。这一点尤其提醒各位开发者注意。如果交互太复杂，比如很多小而美、动效依赖很多的应用，笔者更建议用原生的方式开发App。
# 1.4 小程序与原生App（iOS、Android）的优劣对比
前文讲过，小程序也属于App的一种，那么它和我们现在流行的原生App（iOS、Android）相比，有什么区别和优势呢？ 首先，从技术上来讲，目前App的主流开发方式有三种：Web App、Native App和Hybrid App。我们举几个例子来看看：
Web App这类App其实就是我们经常在PC上浏览的网页，只不过加入了响应式的设计让它适合在移动端显示和运行，所采用的技术依然是JavaScript、CSS和HTML。相对于其他两种App，Web App具有开发简单、高效，更新灵活、跨平台等优势。但缺点与优点并存，Web App 性能、体验较差，无法使用照相机、系统通知、本地缓存等原生特性。我们常说的”H5“页面其实就可以视为一种Web App。
Native App 也称为原生App。这种App不是采用JavaScript、CSS及HTML开发，而是使用Objective-C（iOS）或者Java（Android）开发。微信、支付宝、斗鱼TV等都属于这类App，是目前主流的开发方式。Native App具有性能、体验非常良好，组件支持完善、接口丰富等特点。但Native App最大的缺点在于，不能跨平台，有多少个平台就要开发多少个版本，现在主要有iOS和Android两个主流平台（还好Windows Phone已没了踪影）
Hybrid App 也称为混合式App。Hybrid App看上去像一个Native App，但实质上Native技术在这里只是作为一个容器，将Web App包裹了起来，在容器内部实质上运行的还是网页。Hybrid App更像是Web App与Native App的混合体。与纯粹的Web App相比，Hybrid App会有一部分访问原生组件（相机、加速器）的能力。事实上，目前主流的应用中，纯粹的原生App很少，绝大多数都属于混合式App。比如，我们常见的京东、淘宝等电商类App，由于商品及业务变化非常频繁，需要经常调整，所以这类App的主要页面都是采用Web技术来构建，只是用Native包装了一下。
有一些开发者认为微信服务号里的网页应用也属于Hybrid App，这种说法也不无道理。因为这些网页应用也属于微信这个Native应用的一部分，同样运行在微信内置的浏览器中，但这是一个App所有者的问题。对于微信，确实是Native App中加入了部分“网页”，具有Hybrid App的特点。但我们上面讲到，目前主流App里很少有纯粹的Native App，是不是算作Hybrid App，应该看Web页面在App中的所占比例。微信是一个以社交为主要业务的App，微信中的绝大多数核心社交与聊天功能都是原生的，所以我们还是称微信为Native App。但是，对于服务号应用的开发者，微信并不是开发者开发的，开发者只拥有其服务号。而且服务号应用所用到的所有技术都只局限在Web技术里，从这一点来讲，服务号的应用应该归属于Web App的范畴。 此外，我们说Hybrid App具有一部分可以访问原生设备组件的能力。微信的JS-SDK确实提供了一些如拍照、录音、扫一扫等功能的接口，但相比于其他Hybrid App能调用的原生功能，实在是有限。从这个角度来讲，也应该将这些服务号的应用归属到Web App中。 其实，到底归属于什么并不重要。互联网技术中的概念层出不穷，对很多事物的定义本来就不是很明确。这里用一些篇幅解释3种主流类型的App，是希望大家在对比小程序和其他类型App时，能有一个较完整的知识背景。
那么小程序属于以上3种的哪一种？严格意义上来说，它不属于以上3种中的任何一种，在实现技术上小程序同传统的Hybrid还是有很大的不同的。小程序采用JavaScript和CSS这类常见的Web技术开发，但它又不使用HTML，它同Web没有直接的联系。如果一定要将小程序归并到以上3类App中，可能Hybrid App更合适：非原生，但使用到了Web技术（JavaScript和CSS）。
在 iOS 上，小程序逻辑层的 javascript 代码运行在 JavaScriptCore 中，视图层是由 WKWebView 来渲染的，环境有 iOS8、iOS9、iOS10； 在 Android 上，旧版本，小程序逻辑层的 javascript 代码运行中 X5 JSCore 中，视图层是由 X5 基于 Mobile Chrome 57 内核来渲染的； 新版本，小程序逻辑层的 javascript 代码运行在 V8 中，视图层是由自研 XWeb 引擎基于 Mobile Chrome 67 内核来渲染的； 在 开发工具上，小程序逻辑层的 javascript 代码是运行在 NW.js 中，视图层是由 Chromium 60 Webview 来渲染的。
相比于Native App，小程序具有Hybrid App的一些优势：
- 跨平台（对于iOS和Android两个平台只需要开发一套程序）
- 具备接近于Native App的体验（只是接近，相对于真正的Native App还是有不小差距）
- 对原生组件有访问能力
- 具备缓存能力
- 上手容易，开发逻辑较为简单。
同时，小程序还具有一些它独有的特点：
- 小程序在设计时就做了很多约定式的规范：比如简单的文件结构、默认的文件命名、内置好的Tab栏与导航栏等，这让小程序的初学者更容易上手和理解。
- 开发环境很干净，你无须安装任何除开发工具外的其他软件，相比于其他Hybrid App的环境要求，小程序这点真的很棒。
- 发布和部署流程非常简单，几乎是“傻瓜式”，点击几下就可以将应用发布到腾讯云。
- 小程序之所以现在如此流行，原因并不在技术上，无数开发者、创业者看中的是微信天然的关系链与获客能力以及极低的开发成本，这也是小程序最大的优势。
下面这段描述，非常有意思。它是本书第一版里所描述的小程序的缺点。本书第二版依然保留这段描述，我们来一起来了解下小程序”曾经“的缺点。
世间没有完美的事物，计算机世界里也没有完美的技术，你以为的优势在另一方面却成了缺点。我们一起来看下：
- 小程序为了简化复杂性，做了一些UI上的设计规范，确实方便了很多对UI要求不高的应用。但这也限制了那些对UI要求极高的产品发挥。
- 小程序很遗憾地不支持现有的HTML DOM结构，而是自己给出了一系列的组件，造就了一个封闭的开发环境，这直接导致了现有的经典JavaScript框架、类库都无法使用。小程序现在的生态几乎是荒芜一片，等待着开发者们去耕耘（挑战与机遇并存，正因为没有，才有机会）。如果你想用小程序实现一组图形来展现股票或者天气的曲线，目前来看，相当烦琐。你无法使用经典的echart或者highchart，你只能自己用Canvas来一点点地绘制。
- 截止到笔者编写本书时，小程序还不支持WebView，这是相当头疼的一个问题。现在很多新闻类型的应用，都是将文章数据静态化成HTML存储在服务器或者是CDN中，然后再利用WebView直接加载这个HTML来显示。不支持WebView直接导致了很多内容型应用没办法加载已存在的大量HTML页面。内容型应用现在大量的静态化页面需要被转化（已有一些第三方的组件实现了HTML转WXML，基本思路是用正则表达式替换HTML，但效果并不能让人满意）。至于微信会不会官方支持，这个很难抉择。不支持WebView对现在的静态化HTML页面是致命的打击；但兼容WebView就意味着在小程序里你还可以运行Web App，而Web App很难去监管，性能体验也不够好，这对于小程序的发展是不利的。也许开放一个只解析CSS不允许运行JavaScript的WebView可能是个不错的选择，微信如何平衡这个问题，我们拭目以待。
- 小程序只实现了模板化并没有实现自定义组件，这是最令人不满意的地方。如果我们想实现一个自定义逻辑的组件，通常希望把这个组件的标签、样式以及业务逻辑打包在一起，然后可以放在项目中多个地方使用。外部客户端调用组件时，只需要传入组件所需要的参数，由组件自己来完成数据获取、转化、绑定并和UI层通信等操作。 但小程序里的template只能将标签和样式（WXML和WXSS文件）提取出来作为一个“模板”，却无法把组件的业务逻辑（js文件）放在一起。也就是说，组件的业务逻辑不能够写在组件的模块儿中，只能写在“调用”组件的业务代码中，这就无法很好地复用组件的业务代码。原因我们会在后面讲到模板“template”时再来详细讲解。
以上是笔者认为小程序早期最致命的一些缺点，但到本书第二版时，微信已经全部解决了以上问题：
- 微信已陆续更新了自定义tabbar、自定义导航栏等诸多特性以减少对开发者的限制
- 虽然依然没有DOM结构，但小程序的第三方生态已陆续成熟。尤其是在小程序支持NPM后，各类第三方库已如雨后春笋般出现
- 小程序目前已支持WebView，且对JavaScript的运行没有过多的限制。但需要注意的是，目前个人开发者是不能使用WebView的，只有企业资质的小程序才拥有WebView的能力
- 小程序已新增”自定义组件“的机制。现在，你完全可以用组件化的编程思维来构建小程序。
我们用下表来对比小程序和现在主流App的优劣势。
| 属性 | 微信小程序 | iOS、Android |
|---|---|---|
| 相关基础语言 | JavaScript和CSS | Objective-C、Swift、Java |
| 性能 | 较好 | 极好 |
| 成本 | 低 | 高 |
| 开发效率 | 低（目前） | 较高（目前） |
| 开发环境配置 | 极为简单 | 较复杂 |
| 新手入门速度 | 快 | 慢 |
| 适合的应用 | 业务简单，使用频率不高 | 业务逻辑复杂，使用频率高 |
| 优秀第三方组件 | 没有 | 极为丰富 |
| 新版本审核周期 | 较短 | 较长 |
| 社区支持 | 没有 | 较多 |
# 1.5 Web前端的未来
相比于iOS和Android，Web前端对技术的需求度确实要高出很多。iOS和Android是为移动端量身定做的系统，移动端的局限性本身就决定了它很难作为主要的生产力工具。虽然这些年有很多移动端App致力于将手机变成生产力工具，但诚实地讲，如果自然语言或者其他更先进的人机交互方式不出现，移动设备很难成为“名副其实”的生产力工具。“PC已死论”、“微软已亡论”流传了好多年，可无论是PC还是微软现在都活得很好。这其中一个原因还是在于人类不能只消费，还需要生产，而PC作为信息化社会的主要生产力工具，这是移动端无可替代的。 我们在移动端更多的时候是去用眼睛“看”，而我们在PC端更多的是用手去“操作”。从信息的角度讲，移动端主要负责信息的输出，而PC端主要负责信息的输入。有过开发经验的朋友应该体会到，相对于纯粹的显示，有“输入”操作的应用开发难度和开发成本是要高很多的。目前市场上对于iOS和Android开发者的需求量已经接近饱和了，而Web前端由于其本身的特性，优秀的开发者相对偏少，市场的需求量是巨大的。即使一个公司的产品以App为主，也不可能缺少Web前端开发者： 我们之前讲过，混合式App是现在的主流App，一个App很难只用Objective-C或者Java来开发，必然会有Web技术介入。你只看几乎所有应用都有“分享到微信、QQ、微博”（分享的内容大多数都是一个网页）等功能就知道，Web技术是必不可或缺的。 大多数移动端应用也都有一个对应的Web网站。 现在的公司做营销和推广都离不开微信，无论是H5页面还是做微信服务号、企业号都是纯粹的Web技术。 在小程序推出之前，Web技术在移动端时代更像是一个“黏合剂”，无处不在却又不能够独立地承担移动端的开发。Web技术和Web开发者一直处于移动时代的边缘，不能没有它们，却也无法自成一体。但以React为代表的React Native和微信小程序的出现，给了Web开发者希望。虽然在性能体验上依然不及原生应用，但已经相当地接近了。Web开发者终于可以在主流的移动平台中占据一席之地了。 笔者常常惊叹于JavaScript顽强的生命力，作为最早的浏览器交互语言，当初仅仅被当作一个玩具。这个玩具却经历了漫长的Web时代，抗住了Adobe的Flex和微软Silverlight这些所谓“富客户端应用程序”技术的猛烈攻势，不仅在移动端时代没有消亡，反而“溜到”了“后台”，以NodeJS的形式开始了自己的服务器之旅，现在又不“甘心”蜗居在Web的两端（浏览器和服务器），反而以混合式的技术形态强攻移动端。这个被Brendan Eich用了10天设计出来的脚本语言，以惊人的生命力横贯Web和移动时代，甚至还可以以“寄宿”的方式成为一个桌面应用程序。JavaScript在很长一段时间，由于设计时间太短，细节考虑的不够严谨，导致JavaScript都是“程序混乱”的代名词，但即使这样，也无法阻挡它前进的脚步。 随着ES6、ES7甚至是更高标准的ES推出和普及，JavaScript变得更加完善与强大。而现在Web前端的发展呈现出的是一种百花齐放的姿态，发展与更新速度远超服务器技术的更迭速度。好事还是坏事，大家各抒己见，没有定论。但有一点可以确定，Web前端开发将是一个非常具有挑战和想象力的工作，如果你刚好走在前端开发的路上，那么恭喜你，你正行走于时代的技术浪潮上。
# 1.6 Web前端开发者与小程序
招聘网站上常见的技术类职位有：iOS、Android、Java、.Net、Web前端、DBA、大数据等。 有没有可能未来会出现小程序开发者工程师这个职位？ 除了专业做微信开发的公司，小程序工程师这个职位在短期之内不会成为独立的一类职位，绝大多数的小程序将由Web前端工程师来开发。未来，你将看到的Web前端岗位要求会添加一句话：熟悉微信小程序开发者优先。正如现在的Web前端职位都要求应聘者精通/熟悉Vue、AngularJS或者React、WebPack等技术一样，小程序也将是Web前端职位的一项重要加分项。
# 1.7 MINA框架与微信小程序
MINA是官方小程序的内部开发代号，也是小程序运行框架的别名。据说MINA有MINA Is Not App的意思。到目前为止，许多开发者并没有正确理解什么是微信小程序，它和我们在网页开发中常用的AngularJS和Vue又有什么区别？ 微信小程序并不是一项技术或者一个框架，微信小程序是一个生态，与之对应的应该是iOS生态和Android生态，其中微信小程序又与iOS生态极为相似，它们都非常封闭，而且审核非常严格（微信小程序的审核比苹果还要严格）。而MINA是小程序的一个框架，它提供了小程序运行所需要的接口、模型和机制。
# 1.8 微信小程序beta测试版
自0.11.122100版本后，微信官方开始引入测试版本的概念。微信会提前放出下一个版本的测试版，以供开发者提前对新版本进行测试并反馈bug。比如，在122100版本后的一周内，微信就提供了下一个版本的beta版。 测试版本的概念非常重要，可以让开发者预先知道下个版本的更新内容，建议开发者应该第一时间使用测试版本测试一下自己的小程序。
本章我们对小程序做了一个较为全面的介绍，让大家在开始开发前对小程序有一个较为全面的了解。 本章主要介绍了小程序的特性与商业价值，并没有涉及开发方面的知识。小程序是一个新的生态，开发者有必要充分了解小程序的优劣。现在的技术，条条大路通罗马，选择是多样性的，只有充分了解一个技术/平台的特性，才能做出正确的选择。 除此之外，小程序的开发相对来说比较简单，至少笔者认为学习难度和学习曲线都在AngularJS、Vue和React之下。