作者：黄曦
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
微信小程序开发快速入门试读：
前言
为什么写本书2017年1月9日，小程序如期发布，给本就异常火爆的前端领域又注入了一股新的力量，甚至很多公司已经开始招聘小程序开发者，其应用也呈现出蓬勃发展的趋势。
然而开发人员中也出现了一些不同的声音，有人认为它的出现又为前端领域增加了负担，因为与现有的Web标准不同，它需要前端开发者开发了应用后，再去适配另一个小程序环境，以此来批评微信不拥抱标准，自立门户，不够开放。
实际上在我们看来，小程序并没有为前端人员增加负担，反而为前端开发者创造了新的价值。因为小程序是更接近原生APP的一个新的开发框架，不符合HTML5标准，在这个意义上，它实际上是为开发者提供了新的开发渠道，虽然小程序并未提供类似APP的应用商城为开发者带来应用分发的经济效益，但小程序本身内置提供支付功能的API，便于更快更方便地开发出既为用户带来价值又能为开发者或企业带来收益的小程序应用，这本身对开发者和企业而言，有足够的想象和拓展空间。
另外，小程序虽然不符合现有的HTML5标准，但是依然沿用了JavaScript、CSS以及HTML的语法基础，其JavaScript甚至支持ES6语法，并且小程序在这些基础上做了不少的扩充，并引入了新的MINA框架，开发者需要采用该框架进行开发，但其上手难度对于较为熟练的前端开发人员来说，门槛非常低。
而与“增加了前端人员负担”的观点相反，无论是在安卓、iOS平台，还是平台下不同屏幕大小的手机，微信都通过小程序框架，为小程序提供了一致的呈现效果，在这一点上，反而彻底将前端开发人员从机型适配的苦海中解脱了出来。
而且对于小程序开发，微信提供了完整的开发编译环境，在这个层面上，也为前端人员节省了大量的环境架构工作量，使用微信开发者工具，可以立即着手开发小程序。
目前常用的小程序已超150个，基本涵盖了生活中的大部分场景，且数量还在快速增加中。其带来的价值正在悄然中迅猛到来，已经成为前端开发人员必须掌握并提高自身价值的新技能。
如果说2016年没有掌握Node.js开发的前端人员会失去竞争力的话，那么2017年，没有熟练掌握微信小程序开发的前端人员，在前端开发人员队伍中，也一样会缺少竞争力。本书特色与内容架构循序渐进、由浅入深
作为一本开发者使用的学习参考书，本书讲解知识点时，遵从循序渐进的原则，将所有需要掌握的知识点做了系统化的组织和编排，每讲述一个知识点，均有相应的内容和案例解说，让读者在每一章节中都体会到自己的成长。
本书参考了官方文档的知识结构，为了使读者尽快入门，按照由浅入深的原则对章节进行了重新编排，帮助读者快速上手。案例生动翔实，图示丰富
本书大部分案例都只针对相应的知识点，在完整介绍知识点的前提下尽可能精简内容和代码，读者阅读实例会感觉到非常轻松，学习知识点的时候，没有多余知识点分散精力，集中掌握小程序开发的目标，降低学习成本和理解的难度。
另外，在讲解知识点时，对不容易理解的地方书中使用了丰富的图表来展示，必要时用编号、标记等清楚地标记了操作的顺序和重点，让读者把更多的精力放在开发和实践中。语言朴实，风趣幽默
虽然是一本讲解编程方面的图书，但本书并没有采用教科书式的刻板语言，而是尽可能用通俗的语言，风趣地解读其中的内容，力保读者在轻松、愉悦的环境中完成学习。适用读者和致谢
本书写作的目的是为了让所有对小程序感兴趣的人可以快速上手。● 技术人员可以通过本书的技术开发章节快速了解小程序的开发以
及调试方法；● 创业者或产品经理可以从本书中迅速了解小程序的适用性以及优
势；● 运营人员可以迅速入门掌握运营规范以及应该避免的问题。
读者可以根据需要选择不同的章节进行阅读参考。
由于小程序更新频繁，本书中所介绍的开发接口以及工具版本可能并不是当前的最新版，在一些细节上与最新版本的小程序可能会有些不同，读者在具体动手开发时需要以官方的当前版本为准。
本书主要由沙拉依丁·苏里坦与黄曦创作，写作过程中得到了轻课CEO肖逸群的大力支持和鼓励，还有唐敬之、郑祝萍、顾立人、王启元、米昱杰、何川、刑菁、王超群和刘剑等人参与了编辑整理工作，以及轻课提供的平台与资源，在此表示由衷的感谢。并感谢家人、朋友们以及同事们一直给予的帮助和鼓励。
写作过程中难免有所纰漏，欢迎读者批评指正，并提出宝贵建议。黄曦 沙拉依丁·苏里坦2017年3月
轻松注册成为博文视点社区用户（www.broadview.com.cn），扫码直达本书页面。● 提交勘误：您对书中内容的修改意见可在【提交勘误】处提交，
若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分
可用来抵扣相应金额）。● 与作者交流：在页面下方【读者评论】处留下您的疑问或观点，
与作者和其他读者一同学习交流。
页面入口：http://www.broadview.com.cn/31331第1章小程序特点与开发逻辑“我们希望存在一种新的公众号形态，这种形态下面用户关注了一个公众号，就像安装了一个APP一样。他要找这个公众号的时候就像找一个APP，平时这个号不会向用户发东西，所以APP就会很安静地存在那里，等用户需要的时候找到它就好了。”——张小龙1.1 互联网正在变得越来越“轻”
2016—2017年依旧是国内互联网环境复杂多变的年份：无论是“内容变现”崛起，还是Papi酱获得巨额融资，或是果壳憋大招的产品分答上线（如图1.1左），都引起了大众的强烈关注。图1.1
2016下半年分享经济持续火爆，自行车共享新赛道（如图1.1右）引得各路资本巨头竞相押注。与此同时，我们注意到其中的每条消息绝无例外，都会在微信朋友圈掀起一阵刷屏之势，这似乎在强烈地印证着以微信为载体的信息传播方式已经成为主流的信息传播途径之一。现在微信本身已不再是一个单纯的网络通信工具，它已经成为了一个基于8.06亿月活跃用户（官方数据）群体的完整生态圈——从微商的对个人销售，到寻找企业资源的对企业的合作，各行各业都已在微信平台里尝试和摸索新的业务拓展方法。
微信的订阅号以及服务号体系早已被企业用户们所熟悉。通过合理合规的运营，企业将极大地降低获客成本，并为用户提供更加方便的使用途径。有非常多的优秀公司，尤其是To C的企业都在公众号开发上不遗余力，在微信的体系内实现自我宣传、一键下单、呼叫服务等，这都让消费者获得了相当流畅的使用体验。和下载一个几十兆甚至上百兆的APP相比，关注公众号就可以使用所有功能显得异常地省时省力，如图1.2所示为微信端浦发银行信用卡宣传广告和滴滴出行的下单界面。图1.2
另一方面，对初创型企业来说，相比开发一个APP，公众号的对接流程相对简单，开发测试所需的时间周期短，前期投入的人力和物力成本也会相对较低。因此很多商业模式都可以通过微信公众平台以极低的成本迅速地被市场验证。
如图1.3所示为微信订阅号及服务号的登录后台。图1.3
作为基于微信生态圈的创业者可能对此更有深刻体会，不得不说，很多创业者在创业前期总是会掉入产品细节的陷阱。笔者认为，现在的爆款产品并不是投入十几个或几十个顶尖级工程师坐在一起研发十几个月就能得到的成果，而是在一个简单的产品模型或者设想投入市场验证需求后进行快速功能迭代的合集。从案例上来分析，无论是Airbnb还是Uber，前期系统所提供的功能和设想都非常简单，成为“独角兽”的原因并不是一开始就给用户推出了重量级和体验都非常优秀的产品，而是抓住了用户的需求，并且通过后期功能的迭代和用户的增长不断积累到今天的量级。
创业的过程往往是一场和时间进行赛跑的游戏：尽快拿出早期的产品原型，投入市场进行验证，争取到投资，拿到第一桶红利，再进行迭代升级、融资、扩大市场份额，如此循环往复方能势如破竹般找到正确的发展方向，如图1.4所示为Uber早期版本和2015年的版本对比（美国版本，来源http://thehustle.co/proof-that-your-favorite-startup-started-out-awful）。图1.4
在此过程中，由于微信传播和获取的便捷特性，降低了整个产品需求验证的难度以及成本，所以应当考虑是否可以先暂时不开发APP，而使用微信公众平台代替。当然，APP的重要性无可厚非，不过在稳固市场份额之后，再投入成本研发APP、建立品牌也并不算迟，并且这种“快准狠”的方式是对传统基于APP创业的同类型竞品基于时间维度的一次“降维打击”。
不过，和APP应用相比，基于公众号的应用并非没有硬伤。
首先，公众号基于IM对话完成功能，主要通过文字、语音等手段实现互动，并且支持跳转到第三方页面，但从用户角度来说，这个应用交互方法不够丰富。
其次，载入跳转第三方页面还只是基于H5形式展开业务，信息的承载方法（例如音频、视频等）较为单一，并没有脱离常规的Web形式，比起使用APP的体验仍有差距。
再次，公众号API（Application Programming Interface，应用程序编程接口）接口对手机硬件调用能力较弱，虽然有基本的地理和拍照等组件可供使用，但是与独立APP对手机硬件模块利用度相比差距依旧较大。
从早些年开始，一直有传闻微信要推出独立的“应用号”体系。从名字上来猜测，应用号应该会像公众号一样让用户免安装，即关注后就可以使用，但是又同时提供类似独立APP应用的体验。2016年9月21日，微信毫无征兆地向全行业200余家开发服务号的企业发出了“小程序”内测邀请。很幸运，笔者所在公司“轻课”也成为第一批内测资格获得者之一，使得我们有条件学习和掌握相关的规则。
可以预期的是，小程序的出现将会让互联网创业者们“脑洞大开”，新的玩法也将不断地被解锁。通过小程序的开发和使用，早期产品可以节约大量的人力和时间成本，基于JavaScript的实现也让基于移动端创业的门槛更低。前期产品完全可以使用小程序+ Node后端来实现JavaScript全栈化，甚至可能出现做产品、开发、运营的独立创业者。由此看来，创业的方法、使用的平台、实现的技术在前期产品验证阶段会越来越成熟以及轻量化。从用户角度来看，应用获取和了解方式以及使用习惯也会变得越来越轻量化。1.2 什么是小程序
那么，什么是小程序呢？它的发展又会对当前的APP应用商店有什么冲击呢？下面我们简要说明一下。1.2.1 小程序的由来
2016年1月11日，2016微信公开课PRO版在广州举行，被称为“微信之父”的张小龙在首次公开演讲中说道：“但是我们的本意并不是要做成一个只是传播内容的平台，我们一直说我们是要做一个提供服务的平台，所以后面我们甚至专门拆分出一个服务号出来，但是服务号还是没有达到我们的要求，说服务号可以在里面以提供服务为主，所有的服务号还是基于一个诉求，这不是我们想看到的。现在我们将开发一个新的形态，叫作应用号。”
由此，应用号受到业内普遍关注，根据张小龙的描述，应用号的形态大致为：“我们希望存在一种新的公众号的形态，这种形态下面用户关注了一个公众号，就像安装了一个APP一样，他要找这个公众号的时候就像找一个APP一样，进去使用这个公众号，平时这个号不会向用户发东西，所以APP就会很安静地存在那里，等用户需要的时候找到它就好了，这样的话我们可以尝试做到让更多的APP有一种更轻量的形态，但是又更好使用，这是我们在探讨的一种新的公众号形态，叫应用号，这里只是提前剧透一点点东西。”
现在来看，小程序即2016年年初张小龙提到的“一种新的公众号形态”，也即应用号。估计是根据其定位的“一种更轻量的形态”，将其名称最后确定为小程序，而不是应用号。1.2.2 小程序的发展与展望
小程序最主要的特点，是不需要下载和安装，信息触手可及，用完即走，无须卸载。
张小龙说：“小程序非常接近于PC时代的网站服务，网站服务不同于公众号，它更直接。大家想象一下，把小程序看作PC时代的网站可能更好理解。”
其实小程序与其说是PC时代的网站服务，不如直接说就是类似于网站的手机端服务，我们可以按照张小龙的建议想象一下，假如我们需要一个服务，比如买个衣服，我们打开网站，注册账户，填写收货地址，提交订单，选择微信或者银行卡支付，确认信息，完成支付，然后就可以把网站关闭了。
在此过程中，没有下载任何东西，购买完，我们就关闭了网站，也没有做任何停留。
小程序想做的，就是类似的场景，但比这还要简化很多，想象一下，如果是在小程序中，完成这样一个购买流程需要做什么？
下面以小程序京东购物为例来说明。（1）在小程序入口处选择“京东购物”，进入京东购物小程序并允许授权登录（无须注册），如图1.5所示。图1.5（2）搜索产品，以vivo手机为例，单击“立即购买”按钮。（3）填写收货地址（如果在某个公众号服务中填写过，甚至在小程序中都不用再次填写），确认信息后提交订单，如图1.6所示。图1.6（4）选择“微信支付”，支付完成后关闭小程序即可，如图1.7所示。图1.7
可以看到，小程序提供了更简化的过程，优于网站的体验，并且与网站一样即用即走，无须安装卸载。
但是，与网站不同的是，看到喜欢的网站，可以把网站放到收藏夹里，也可以记住其域名，下次直接输入域名来访问，但是小程序不提供这样的入口，我们只能通过扫二维码或者搜索来找到它。从这一点来说，小程序更有利于线下服务的线上拓展，比如来到一家餐馆点餐，我们就可以直接通过扫二维码的方式，访问其小程序，完成对喜欢的菜品的点餐，并直接支付下单，然后等待美味的菜肴即可。
这里张小龙自己也提到一个小程序的场景：“现在汽车票其实没有电子化，所有人去坐汽车必须到汽车站现场去买一张票，这是一个很痛苦的过程，你要去排队买票，然后再去坐车，他们希望用小程序来解决这个问题，只需要在每一个汽车站立一个二维码，所有到汽车站的人扫一下二维码就启动购票的小程序，然后直接通过小程序来买好票，这样售票窗口就不用存在了，我认为这是一个非常贴合小程序的想法。”
通过这样两个场景，大家便能很清楚地了解小程序最适合的场景了，也因此很多人提出微信小程序会让APP消亡的观点，这其实是不实际的，小程序的目的也并非如此。微信小程序是希望通过自己轻量、即用即走的特点，来拓展APP的功能，希望APP的开发者们拿出一些很核心的功能做得更加精细化，并且能够与线下的场景实现更紧密的连接，体现了微信“连接人与服务”的愿景。
未来微信小程序的发力点就在于解决这类场景，仔细想来，现实中其实这类需求空缺是非常大的，由于没有一个统一、规范的入口，虽然可以通过H5等技术实现，但是因为流程始终无法简化，对用户而言始终是比较复杂的。通过微信强大的平台入口，按照其平台规范，以及简化的流程和操作，终将解决这个问题。1.3 你的产品适合做小程序吗
微信官方对于小程序的定义是：微信小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫或搜一下即可打开应用，并且即用即走。那我们就从这个描述说开去，来探讨究竟什么类型的产品适合开发小程序。
大家都知道手机对于数据的存储和处理能力相对有限，市面上利用手机本身的硬件资源去做大量计算处理的APP非常少，除了图像处理或者需求实时解码的情况，数据运算和逻辑处理大多数情况下都交于服务端进行处理并返回给APP端。在企业级APP应用中，APP端更多是充当着VIEW（展示）层角色，小程序也是同样的道理。小程序的设计并不是为了去完成复杂的逻辑运算，获得更高的负载，这些问题应该是后端工程师去考虑的问题。从产品角度上来说，小程序是一种方便用户分享传播、获取以及使用的展现方式。
小程序本身是基于脚本完成的，相较原生APP，小程序的性能指标并不会很快，同时基于封装组件的模式也并不适合去开发业务逻辑非常复杂的产品以及界面。但是，小程序的存在弥补了轻量级微信公众号模式以及重量级APP产品两者跨度太大的问题，让功能模块化应用有了合适的载体。
因此，对于企业来说，小程序可以用来封装现有模块作为独立的产品。例如，在很多教育类的互联网产品中，帮助用户养成良好的学习习惯是非常基础的一环，同时它也是提升用户活跃度和黏性的重要手段，这就产生了打卡签到类的功能模块，甚至市面上已经有专门针对这一模块的独立APP了。其实在实际使用的过程中，根据笔者观察，很多用户都会认为如果使用独立的APP进行打卡签到实在太重量级，基于业务的打卡签到（类似Foursquare早期形态）也会让人感到产品功能不明显，重点不突出，但是如果把打卡签到独立到小程序应用中就比较合适了。首先，打卡签到属于轻量级但是高频次而且功能相对单一的应用，基于微信小程序的设计会让打卡提醒、打卡方式都有所缩减，整个产品体验会更好，功能点更突出。第二，打卡应用的产品体系是符合传播逻辑的，用户在打卡完成任务之后更希望去分享，所以可以通过微信直接分享给朋友或者发送到微信群。
2012年8月，硅谷创业家Eric Rise在其著作《精益创业》（Lean Startup）一书中提出“精益创业”这一概念。其核心思想是，先在市场中投入一个极简的原型产品，然后通过不断地学习以及有价值的用户反馈，对产品进行快速迭代优化，以期适应市场。这一理论一推出便赢得了许多创业者的赞同，在中国更是广为传播，最小化可行产品（Minimum Viable Product，MVP）就是其中的核心工具和观念。
简而言之，这一理念就是把复杂的需求精简到最核心的点，使用有限的资源去验证核心的产品功能。比如，如果产品的定位是一部汽车，那我们首先需要去验证“移动”这个需求是不是被市场所接受的需求。从设计一个最简单的可以帮助用户去移动的工具开始，比如一个滑板。滑板证实了“移动”这个需求是普遍的，表示本产品是可行的，我们再迭代加上动力装置（引擎），防护装置（车体车门），以及其他让用户感觉到方便的功能（例如加热坐垫等），最后再完成一个独立的产品。我们可以把制作滑板的成本理解成试错成本，在这期间就算需求不被接受，对于创业者来说损失也不会很大。比较而言，如果我们把试错成本放在最终产品上，一旦需求验证错误损失将会很大。
笔者在前面曾经描述了Airbnb和Uber从基础原型产品做到爆款产品的例子。事实上这种例子可以被描述成“滚雪球”式的创业方法。Justin Vincent在Don't Start Big, Start a Little Snowball文章中也说明项目的起始点不用做得很复杂，从最小化去验证产品可行性。Uber（最早叫UberCab）最开始积累只是在私人朋友之间尝试使用，最初的定位并不是使用复杂框架和优美UI去解决问题，最早的方法只是尝试去看看大家的喜爱度，结果一个月之后，用户量翻了十倍证明这是一个可行的方案。
Airbnb的创始人Brain Cheskey和Joe Gebbia的最初设想就是“Air Bed and Breakfast”，提供便宜的充气床以及一顿方便快捷的早餐。经过市场验证可行之后，他们延展了商业模式，开始提供出租房间以及公寓。最初的产品想法甚至单纯到有点无聊，但是经过后期的验证却获得了巨大的成功。这个最简单想法的提出，在周围人看来甚至有点可笑，但是他们却不是需求的制定者，任何想法无论多伟大，或者多低微，都必须经历市场的验证之后才能评价。如果读者觉得这两个示例还是太过于偶然，只能展示出最近的创业独角兽级的公司的小概率事件，根据Justin的文章，我们可以去深挖Google、Slack、Dropbox的历史，无独有偶，它们开始时都是通过简单的产品去尝试一个最基本的功能，并且把“雪球”慢慢滚到了今天的这个体量。决定从0到1的是市场需求，决定从1到N的是增长和运营，验证最小化可行产品是从0到1阶段最重要的调研。
小程序的出现使得验证最小化可行产品开始变得高效。此前，在互联网上广为传播的《别再开发APP了》一文的作者也提出了相同的观点，“APP生态已经趋于饱和，低频产品已经没有开发APP的必要，转而开发微信公众号（未来是小程序）将是最佳选择。”在产品验证期间开发APP的成本太高，许多创业公司也都死在APP研发上：从开发的成本，更新周期的等待，到质量的把控，其中每个环节都有可能把创业公司扼杀掉。当然，也有很多人对这一观点并不认同，曾有人跟帖留言说：“如果我总是依赖于微信，我们的用户数永远不可能比微信多”。笔者认为，这个说法是正确的，但是你可能需要先去调查一下微信总用户当前有多少，并且看一下比这个用户数多的APP有哪些。如果某天你真的做到了这个体量，导流到APP端或者Web端对你而言肯定易如反掌。
不得不承认的是，小程序非常适合前端工程师走全栈路线。前期可能仅需一个熟悉Node的JavaScript工程师就可以挑起整个项目。目前移动化趋势也越来越偏全栈化，从前几年基于PhoneGap的应用火热，到现在安卓与iOS应用都可以使用React Native实现，一种语言做多个平台已经超出了Java等其他语言“跨平台”的意义。此外，小程序的理念和React基于虚拟DOM的设计思想如出一辙，这也是Web前端技术的一个进化的方向。
小程序项目团队组织架构和具体的项目需求挂钩，但这并不是说微信公众号或者小程序的技术含量就比其他实现方法要低。所有的展现层只是冰山一角，冰山在水下面的体积永远让人无法估计，笔者也曾经经历过一个公众号有几十万并发的场景。在项目执行前我们就需要对用户增长量有一个预判，我们需要去判断这个应用是一个指数级跳跃还是一个线性增长的项目。
用户数以指数级跳跃增长的应用经常被称作“爆款应用”，如果你的应用十分幸运地成了爆款，那恭喜你，希望你之前系统搭建时就已经考虑到了高负载和高扩展性。虽然大多数项目都是线性增长，尤其对创业项目而言，但无论你的产品“爆”与“不爆”，后端的架构都可以不断优化和替代。基于小程序的初创团队可以选择使用前端、后端独立开发的模式搭建技术团队，如果条件合适，也可以使用Node.js进行后端处理，前端配合小程序开发，通过Restful等协议进行通信，这样整个技术团队可能就可以精简到一个人。因此，对于功能简单的Demo，成本是不是一下子降了不少？
微信在6.3.7版本中下线了下拉拍摄视频功能曾经引起不小的争议，各种“原因”在网上传得沸沸扬扬。很多人说这是因为这个低频次的功能打扰到用户的正常操作所以被取消了，其实这也和小程序的产品设计与布局理念一样，应该遵循“不打扰用户”的核心设计原则。在微信官方的小程序设计指南中特别指出小程序应该减少使用无关的元素并且降低干扰。相对地，小程序应该使用基于微信生态体系的布局标准，建立起让用户可以理解、接受和突出重点的布局方法。对于让用户感觉到迷惑的界面布局应该尽量避免，设计者应该遵循各种控件的使用规则以及场景。页面也应该尽量突出本页面的主要重点。官方文档演示了一些典型的错误布局方法，这些错误的设计方法也有可能是之后因为布局风格不符合规范而被拒绝通过发布审核的原因。另外，产品设计时应该遵循官方的设计规范，例如，在APP应用中开发者可以定义程序的启动画面，小程序启动画面由系统完成，开发者并不可以自己更改，启动的页面上包含程序的Logo以及加载进度。1.4 小程序特色：即用即走
小程序从最初的产品设计时就定位为即用即走，它是一个轻量级的产品的设计理念。即用即走并不是说小程序的入口是不存在的。正相反，小程序的入口是在比各种线下途径最容易接触到的地方。公交车站的班次表、餐厅的桌面上，甚至医院的挂号窗口等都可以成为小程序的入口。线上传播可以通过一对一的聊天框和群组群聊分享任意一个小程序页面。
微信是一个专注于产品的团队，从产品的定位，到消息提醒打扰的次数设定，一切都是从用户的角度来考虑的。对于后期运营者来说，一些功能是反常规并且很难被接受的，但对于用户来说确实是增强了产品的体验，“即用即走”就是其一。
罗振宇在逻辑思维2016年跨年演讲中提出了时间占领的概念。他认为有限的时间比上无限的信息结果是零。在将来，用户黏性可以从用户在本产品上花费的时间来计算。从运营层面上来看，用户如果愿意在产品上花更多的时间，用户的付费转化的概率也会相应地提高。微信希望小程序出现在降低用户黏性、提高用户体验的场景，所以他并不希望去占领用户的时间。所以与公众号后台比较，小程序并不是使用关注的粉丝数，而是用使用次数作为单位进行统计。
电商和游戏是典型的时间占领的产品。微信团队已经说明小程序将不支持游戏，而且小程序不提供线上入口，电商也较难发展运营。在线下，各种小程序通过带参数的二维码可以快速传播，可以预测的是，第二轮的二维码爆发是基于微信小程序的。越来越高的线上获客成本，将导致开拓线下获客渠道可能是新一年互联网流量的来源。相比APP端，基于微信的扫一扫可能是最方便的扫二维码软件，如果直接结合新推出的小程序，可能让线上线下玩法出现一个新的高峰。1.5 小程序与订阅号、服务号的异同
微信推出了小程序之后，是不是就不需要去使用订阅号以及服务号了呢？答案是否定的，我们需要从微信公众平台的账号类型去了解公众号体系的特点以及所提供功能。目前微信公众平台提供四种账号类型：小程序、订阅号、服务号以及企业号，小程序应用场景在之前章节已有详细介绍。● 订阅号：主要用于需要频繁给用户传递内容类信息的场景，例如
新闻订阅、杂志更新、每日热点等。订阅号推送消息较常用的展
现形式是图文消息，用户通过点击所推送的图文消息链接可以外
链跳转到具体帖子或者其他网页地址来实现内容阅读。订阅号每
天只允许对所有用户进行一次群体推送（简称群推）。订阅号对
个人申请者开放，虽然不能使用开发类接口，但如帖子编辑、内
容编辑类功能，以及用户交互、数据统计等功能均可使用，需要
注意的是订阅号可以升级成服务号，但是服务号是不可以转成订
阅号的，如图1.8所示为一个朋友（微视角）的订阅号内容。图1.8● 服务号：应用场景偏向于信息提醒类型的场景，例如用户消费提
醒，购买支付成功提醒。服务号也和订阅号一样可以群发消息，
但是每个月只有4次机会。相比订阅号，服务号开放了更多开发
接口，允许公众号对关注的用户发送模板消息进行提醒，并且开
放了二维码生成接口（临时和永久二维码）等，如图1.9所示为“我的印象笔记”的服务号。图1.9● 企业号：经常被用于企业内部通信，并且只有验证之后才可以关
注，如图1.10所示为一家公司的企业号。图1.10
微信公众平台并不提供用户真实数据（微信号、电话联系方式等），这也就意味着如果有用户关注了你的公众号，你并不能拿到用户的详细信息以及联系方式。系统上的用户识别方式通过OpenID的形式实现。OpenID是微信分配给每一个用户在某个公众号中的身份唯一识别码，它通过某种不可逆的哈希加密算法计算来获得（可能是公众号ID+用户微信号进行了哈希运算），这个号码不会根据用户取消关注或者再次关注而改变。运营者应该妥善保管用户OpenID信息，并且防止信息的泄露，任何人都可以在知道了公众号的对接信息（Access Token）以及用户的OpenID之后给用户发出类似于发消息提醒、拉黑、设置独立自定义菜单等操作。在多个微信公众平台账号体系之间，可以使用UnionID来关联相同用户在不同账号之间的身份关系。UnionID通过微信开放平台（区别于微信公众平台）绑定不同的公众号、应用等来鉴别同一个用户身份的设定。在多个公众号绑入同一个开放平台的账号后，微信会对用户增加提供额外的UnionID字段来标识用户在不同账号中的关联性。
在具体业务使用中，如果某个用户在公众号A中购买了某种功能，但需要在公众号B中使用，因为两个公众号用户的OpenID不一样，是无法使用的，这时因为管理员从开放平台注册并且关联了两个公众号，所以UnionID是相同的并且产品应该使用UnionID作为用户的唯一标识而不是OpenID。又例如，如果产品只是涉及一个公众号做用户的标识，这时使用OpenID作为用户的识别即可，并不需要使用UnionID。
笔者推荐保存公众号所提供的用户信息到本地数据库中，包括OpenID、头像地址、地区、性别、语言、关注状态等，有以下几个原因。第一，除了用户改变昵称以及头像的情况之外，用户的信息更新并不是很频繁，本地检索用户信息获取速度要比通过API向微信检索更快，有利于用户体验。第二，用户的关注状态可以通过公众号发的event消息类型进行更改，用户关注和用户取消关注行为都会触发微信系统对后台对接的接口发送此事件类型的通知，在后台我们可以统计到用户取消关注的具体状态以便做留存等行为分析。第三，用户获取接口每天是有限的，虽然当前调用可能并没有达到每日上限，我们还是需要在设计时留意系统的可扩展性，能用缓存的信息使用缓存，尽量减少API的调用次数。系统可以每隔一定周期使用微信批量获取用户信息API来更新所有本地保存的用户信息，当然按照用户行为来触发更新信息也是可行的方法，只是可能本身用户信息并没有更改，并不需要此时更新，造成了数据获取、资源计算的浪费。1.6 消息推送与传播分享
订阅号和服务号消息推送是公众号和用户交互，带来日活，获得留存的基本方式。公众号和用户短期之内的交互都可以使用客服消息来完成，但通过API接口发送客服消息时，需要用户与该公众号48小时内有互动。如用户A给公众号发了一条文字消息，这时候公众号可以在48小时之内通过接口回复该消息，如果用户之前没有主动发送消息，或者互动超过了48小时，调用接口将会显示错误信息。
模板消息是服务号以及小程序的消息提醒方式。发送模板消息类似手机发送短信，并没有交互时间的限制，用户只需要关注并且打开消息功能就可以接收服务号发送来的模板消息。模板消息内容格式是固定的，公众号需要按照需求选取官方提供的模板进行发送，发送时候公众号只允许更改信息内容字段。公众平台为了防止模板消息滥用，给用户造成骚扰，严格限制了模板消息发送的每日次数（10万，100万，1000万关注粉丝量所获得的每日可发送的模板消息和客服消息数不同）以及单个用户同时可以收到的信息总条数。
在小程序中，开发者可以给用户推送模板消息，但是仅限于支付和填写表单应用场景。在用户接受服务之后，7天内可以给用户发送一条模板消息作为提醒。可以看出，相比公众号在模板消息上，微信严格限制了信息推送能力，这就导致许多时间占有类的应用场景并不适合在小程序上进行实现。
客服消息在小程序中的体现为即时性呼叫消息互动。微信规定客服消息只允许在互动后48小时内回复使用，并且客服消息将会被集中收纳到小程序客服消息窗。开发者可以选择将客服消息转交给多客服系统处理或者自行处理消息。1.7 普通用户怎么玩转小程序
小程序优势这么明显，除了开发者外，普通用户又该怎么玩呢？下面简单介绍一下。1.7.1 普通用户启动小程序方法
小程序的主要入口是二维码，或者其他分享者发来的小程序分享页，如果用户没有通过二维码或者分享页启动过小程序，则在微信中不会有任何入口，如果启动过小程序，则会在微信“发现”页最下面一栏出现“小程序”入口（如图1.11左所示），点击进入，则可以看到自己启动过的小程序，以及一个搜索栏，用户也可以从这里搜索自己需要的小程序来进行启动（如图1.11右所示）。图1.111.7.2 普通用户在小程序里面能做什么
普通用户在小程序里，按照现有的100多个小程序，可以完成很多常见的功能，如我们所熟悉的美团外卖、滴滴出行DiDi、摩拜单车等很多平常高频使用的大部分应用，都已经有了小程序。基本涵盖购物、旅行、票务、投资理财、工具、教育培训等各个方面，方便用户使用。第2章微信小程序开发申请入门与环境搭建
做过公众号开发的用户对微信开发流程一定不会陌生，小程序与其类似，本章我们讲述如何申请小程序开发，以及开发环境的搭建。2.1 小程序申请方法以及流程
小程序作为微信公众平台的一员，申请方法与之前的订阅号和服务号类似。首先，申请者需要使用未在公众平台注册过的电子邮箱地址进行申请。在公众平台点击选择使用小程序账号并且进入注册流程，如图2.1所示。图2.1
目前小程序的开放注册范围包括企业、政府、媒体以及组织。在认证注册邮箱之后，会进入机构的确认流程，用户需要选择组织类型并且填写相关机构信息。以企业为例，申请者需要以企业为主体上传营业执照扫描件并通过打款验证对公账户。需要注意的是，微信公众账号（包括小程序，订阅号，以及服务号）属于注册认证后的主体，个人管理员以及运营者虽然有账号的使用权，但并不代表有账号的所有权。个人开发者借用其他企业机构信息代为注册时，虽然后期运营或者开发是个人完成，但账号可以通过机构的申诉返还给所属主体。之前曾有过因为公众号主体所有权不同引起的纠纷案例。微信公众平台的体系功能区分明确，以个人为主体的订阅号不可以使用任何类型的开发接口，企业或机构为主体的订阅号可以使用部分开发接口（客服消息类型为主），但是无法使用模板消息（类似短信消息提醒）的接口，具体区别可以参考本书后续章节。
在账号开通之后，用户可以通过绑定的手机号扫码登录系统，并且填写相关小程序信息。目前公众平台通用的体系是通过管理员的运营者模式来管理账号。在输入注册邮箱以及账号密码之后，通过微信扫二维码的方式进行登录。在开发的过程中，如果其他人需要登录账号，可以告知账号以及密码，但登录时需要绑定的管理员或运营者的微信号验证授权，如图2.2所示。图2.2
小程序的子账号类型分为管理员、开发者，以及体验者。管理员账号是在本公众账号申请时绑定的微信号，开发者类型账号是使用本账号权限进行小程序开发的授权开发工程师账号，体验者账号是针对项目测试运营时为内测用户提供的账号权限。目前管理员账号只允许存在一个（后期可以修改绑定），开发者账号和体验者账号的数量限制分别是10个和20个，如图2.3所示。图2.32.2 小程序开发环境搭建
小程序开发环境搭建相对简单，开发者前往首页的项目介绍页面，点击开发工具链接进入获取微信Web开发者工具即可。目前小程序开发工具支持Windows 32/64以及Mac平台，用户可以根据需要选择。需要注意的是，微信Web开发者工具目前更新速度快，每个版本之间添加的功能较多，开发者最好经常查看更新日志，了解最新功能并且更新工具包版本。
和Eclipse等开发工具不同，微信Web开发者工具需要扫码登录后使用，绑定微信账号需要授权到开发者权限之后开发工具才可以使用。在创建新项目时，开发者首先需要用从后台获取到的AppID来关联项目。在没有使用关联AppID（开发体验者模式），开发工具的提交等功能将不能使用，如图2.4所示。图2.4
使用过微信Web开发者工具开发JSSDK的朋友应该对这个工具布局并不陌生，这是基于Chromium浏览器内核研发的编码以及调试环境，前端开发者可以沿用之前所习惯的网页调试方法来开发小程序。微信Web开发者工具提供了完整的研发和发布流程。从编码到模拟调试，从真机运行到项目发布都可以在这个工具中完成，如图2.5所示。关于微信Web开发者工具的详细介绍请参考本书后续章节。图2.5
在上图中的左侧侧边栏包含了开发者所需要的功能分组，点击如图2.6所示预览按钮。图2.6
在系统提示手机扫码之后，即可在手机端运行，如图2.7所示。图2.7
小程序发布过程的第一步是基于微信Web开发者工具完成。小程序开发完成之后可以在项目页面中点击上传，当前项目将会滚入开发版本中，这时候可以对版本进行提交审核，在通过审核之后，在项目首页上点击“发布”按钮即可发布，如图2.8所示。图2.8第3章初识微信小程序：小程序的Hello World
本章，将开启我们的小程序之旅。通过本章的学习，我们将熟悉用于小程序开发的Web微信开发者工具的使用，并按照惯例，我们将开发一个“Hello world”小程序。3.1 小程序MINA框架介绍
小程序的框架一开始被命名为MINA，后续的文档中就直接叫MINA框架了。
微信小程序早已不是类似公众号的那样提供接口，而完全是一个前端开发框架，作为一个前端框架，它吸取了很多目前较为流行的前端框架热门思想，比如数据绑定与原生APP的理念，即用H5的开发技术，开发出的应用接近原生应用的性能和体验，这也是为什么小程序现在如此火爆的一个重要原因。
虽然采用了H5的技术，却被微信做了一个较深层的封装，主要的区别是微信小程序中不再使用HTML规范了，取而代之的是微信自己的WXML，从名字很容易令人误认为是微信XML的缩写，实际是WeiXin Markup Language的缩写，也就是说，微信把它当作是一种新规范，不过因为其语法和HTML规范完全一致，并不会给开发者增加难度。而小程序的样式控制，则叫WXSS，全称Weixin Style Sheets，但目前而言，WXSS除了名字与CSS不同外，其语法甚至用法都是和现有CSS标准完全一致的。需要注意的是，小程序完全不兼容HTML规范，也不存在浏览器DOM以及BOM的概念，因此在JavaScript中，也无法使用Window对象，熟悉Node.js开发的同学对此也应该不会陌生。因此自然也无法使用jQuery、Zepto之类操作浏览器DOM的现有框架。不过喜欢使用jQuery与Zepto框架的同学也不用担心，微信小程序使用时下最流行的View层数据绑定的概念，已经在很大程度上简化了开发，可以让开发者把精力聚焦于数据与逻辑上。
对于使用框架的数据绑定，官方文档提供了如下示例代码。
以下这部分就是上述提到的WXML文件的内容，我们称之为视图层，通常写在index.wxml文件里：
可以看到语法与HTML规范的语法是完全一致的，只是在HTML里没有view标签，button虽然有但是用法也不同，在HTML中没有bindtap（在小程序中用于绑定触摸事件）的属性。
以下这部分则是JavaSctipt的内容，通常写在index.js文件里：// 逻辑层 // 数据与事件绑定 var helloData = { name: 'WeChat' } // 注册一个页面 Page({ data: helloData, changeName: function(e) { // 注意这里是通过bindtap实现了与button的事件绑定，后面会详细讲到 this.setData({ name: 'MINA' }) } })
使用过React Native和Vue框架的同学可能会发现，这两种写法基本上是类似的，而且与Vue框架的写法相似性更高，微信通过一些限制，进一步简化了代码。
上述例子主要做了两件事：（1）在视图层（即index.wxml文件）里的name与逻辑层（即index.js文件）的name进行绑定，在视图层用{{name}}指定数据绑定，并通过在逻辑层Page方法中传入带有data字段的参数对象来向视图层传入绑定的数据内容。（2）使用bindtap属性在视图层绑定changeName事件，并通过逻辑层中的Page方法中传入带有changeName方法的参数对象实现该事件的调用。
而在changeName事件中，又调用了默认的this.setData方法来改写视图中name绑定的数据内容为“MINA”，即实现了点击按钮后，把界面中绑定的name的默认内容“WeChat”修改为“MINA”。
最终这个示例显示的内容由‘Hello WeChat’变为‘Hello MINA!’。
从这里可以看出这个框架在内部的代号应该仍为MINA。
在这个例子中，也许你也注意到了，由于没有采用任何样式布局，因此没有创建WXSS文件。3.2 小程序基本结构
图3.1所示是用微信Web开发者工具在创建空项目时自动生成的Quick Start项目代码的目录，其中包含一个完整微信小程序的结构，接下来一一详述。图3.1
首先是最外层的app.js、app.json、app.wxss文件，app.js是整个微信小程序的入口文件，用来控制小程序的整体逻辑。
在app.js中，默认会调用App()方法，可以传入object参数，其中有三个方法会被微信小程序自动调用，并在小程序中担任生命周期函数的作用，分别为：● onLaunch，当小程序初始化完成时被调用，该方法只被调用一
次。● onShow，当小程序启动，或从后台进入前台显示时调用，因此
可能会在每次进入前台显示时被多次调用。● onHide，当小程序从前台进入后台时被调用，因此在每次切入后
台时都会被多次调用。● test，作为全局函数来调用，不会被自动调用。
实现完整的小程序生命周期的代码如下：App({ onLaunch: function() { // 当小程序初始化完成时被调用，该方法只会被调用一次 }, onShow: function() { // 当小程序启动，或从后台进入前台显时调用，可能会被多次调用 }, onHide: function() { // 当小程序从前台进入后台时被调用，可能会被多次调用 }, onError: function(msg) { //发生错误时调用，通过打印msg对象可以了解错误信息 console.log(msg) }, }, //相当于对象里的一个属性，可供全局使用 globalData: 'I am global data' })
还有全局方法：getApp() 用于获取小程序的实例，在之后的例子中会讲到具体用法。
App()方法必须在app.js中使用，且只能有一个，在App()方法无须调用getApp()方法，直接使用this即可访问App实例。另外需要注意在onLaunch方法中不能调用getCurrentPage()方法，因为此时页面还没有生成，这一点我们会在后面的“手把手教你做Demo”中体会到，也不能在getApp()获取的实例中调用上述的生命周期函数，这些在官方文档中有特别说明。
而在app.json中，是用来全局配置小程序的，主要的配置项有pages、window、tabBar、networkTimeout和debug，下面简要说明。pages
pages是一个数组，用来告诉小程序由哪些页面组成，每一项的名称对应页面的“路径+文件名”，第一项代表小程序的初始页面，只有在这个数组中指定的页面才会被小程序识别。
以图3.1所示目录结构为例，需要在app.js中写：{ "pages":[ "pages/index/index" "pages/logs/logs" ] }window
window是一个Json对象，用来设置小程序的状态栏、导航条、标题和窗口背景色，依然以图3.1所示目录结构为例，app.json中的内容可以改为：{ "window":{ "navigationBarBackgroundColor": "#ffffff", "navigationBarTextStyle": "black", "navigationBarTitleText": "WeChat", "backgroundColor": "#eeeeee", "backgroundTextStyle": "light", "enablePullDownRefresh": "false", } }
为了便于理解，可以参照官方文档中如图3.2所示的界面。图3.2
从图3.2所示中就可以看得比较清楚了，简要说明如下。● navigationBar主要指图3.2中的标题栏。● navigationBarBackgroundColor是标题栏的颜色，需要以十六进
制色码如#000000格式指定。● navigationBarTextStyle是标题栏文字风格，这里只能从black和
white中选择一个。● navigationBarTitleText是标题栏文字内容，如上述代码示例中的“WeChat”会显示在标题栏中。配置时注意背景色和文字颜色需
要相互搭配，且不能相同，如果把
navigationBarBackgroundColor设置为#ffffff(白色)，再将
navigationBarTextStyle设置为white，那么标题就无法看到。● backgroundColor为图3.2中background区域的颜色，也需要以十
六进制色码如#000000格式指定。● backgroundTextStyle为图3.2中background的文字颜色，也只支
持dark/light，同样需要注意与背景色搭配且不能与背景色相同。● enablePullDownRefresh用来实现是否开启下拉刷新，设置为true
会触发页面的onPullDownRefresh事件，其实现方法会在后续的
章节做进一步介绍。tabBar
tabBar用来配置小程序底部的Tab，仍以图3.2所示为例，可以在App()方法的参数对象中增加如下配置： { {"tabBar": { "color":"#000000", "selectedColor":"#000000", "backgroundColor":"#FFFFF", "borderStyle":"black", "list": [{ "pagePath": "pages/index/index", "text": "首页", "iconPath": "image/wechat.png", "selectedIconPath": "image/wechat.png" }, { "pagePath": "pages/logs/logs", "text": "日志", "iconPath": "image/wechat.png", "selectedIconPath": "image/wechat.png" }] }, }
结合如图3.3所示的官方文档，就能清楚地看出解配置方法。图3.3
简要说明如下。● 其中color为tab上文字的颜色。● selectedColor为选中tab上的文字颜色。● backgroundColor为tab的背景色。● borderStyle为tabbar上边框的颜色，仅支持black/white。● list为Tab页内容，为一个数组。最少需要些两个，其中属性分别
如下。
—pagePath为页面路径，必须在pages中先定义。
—text为tab上按钮文字。
—iconPath为图片路径，icon大小限制为40kb。
—selectedIconPath为选中时的图片路径，icon大小限制为
40kb。networkTimeout
networkTimeout用于设置各种网络请求的超时时间，示例代码如下： "networkTimeout": { "request": 10000, "downloadFile": 10000, "connectSocket": 10000, "uploadFile": 10000 },
代码说明如下。● request：wx.request的超时时间。● downloadFile：wx.downloadFile的超时时间。● connectSocket：wx.connectSocket的超时时间。● uploadFile：wx.uploadFile的超时时间。
其单位均为毫秒。debug
可以在开发者工具中开启debug模式，在开发者工具的控制台面板，调试信息以info的形式给出，其信息有Page的注册，页面路由，数据更新和事件触发，可以帮助开发者快速定位一些常见的问题。
示例代码："debug": true
app.wxss用来实现小程序的全局样式。
该文件作用是定义全局样式，作用于每一个页面，而每个页面的样式则只作用于该页面，而如果页面的样式选择器与app.wxss全局样式相同，则会覆盖全局样式。
理解了稍微复杂的小程序全局配置，接下来重点讲解pages目录下的文件（如图3.4所示）。
试读结束[说明：试读内容隐藏了图片]