微信小程序开发教程（1：初识）

微信小程序一经推出迅速在开发圈引起巨大反响，作为一位独立自由的微信开发程序猿，第一时间“”入坑”微信小程序开发，在学习过程中，有把知识点记录和总结的冲动，因此就有写小程序开发教程的想法，将学习到的技术经验分享出来，帮助更多需要的朋友，也希望借此认识同行的朋友，共同交流，共同进步！

<1>：小程序是什么？

根据张小龙这段文字，小程序可以由下面几个关键词定义出

1：触手可及：由实际应用场景触发，随时随地，打开即用

2：用完即走：用户主动把控，不会主动骚扰，不希望过度粘住用户

3：无处不在，随时可用：使用过程不占空间，不费流量，不留垃圾

并且小程序 首先提现在"小"上，根据官方的定义，程序包的容量不得超过1024KB，并且拥有10M的本地存储限制，请求不能超过5个request，页面不能跳转超过5层。其次体现在"程序"上，通读开发文档，笔者发现，小程序在本质上采用仿H5的开发语言，开发模式，但它并非基于C/S架构，更像是基于B/S架构，在操作上不允许进行DOM，也不支持动态渲染，类似于JS-SDK，能够进行云端发布程序，同时也能缓存数据。



<2>：小程序会取代服务号吗？

最近这段时间经常会有各种合作伙伴（笔者是只外包猿，开发过一定数量的微信服务号）怀着忐忑和激动心情问老鬼：（鬼：你说小程序会不会取代服务号呢？）。根据以往的开发经验来看，一定数量的服务号定位为提供服务而不是媒体资讯，例如：基于微信硬件平台的服务号，基于商城的服务号，基于分销体系的服务号等，对于这批用户，小程序的用户体验肯定要优于服务号。但，如果让这些服务号主体再去开发小程序未免太折腾了，不仅浪费各种资源，而且肯定会出现功能重叠，占用过多用户资源。因此我的猜测是认证的服务号是可以升级为小程序的，毕竟当年订阅号也可以转为服务号的。但，就目前而言，从我得到的信息来看，
微信的态度是订阅号，服务号，企业号，小程序并行的四种形态，至于最终形态是什么，还需要等到小程序推出才知道。

<3>：小程序适合谁？

首先对比下APP，微信小程序，微信公众号



我们可以发现，APP在功能实现和操作体验上具有优势，可以实现定制化的各种需求，但开发成本，获客成本，传播成本高，微信公众号相对成本低，但依据我的开发经验，公众号的体验相对较差，小程序正好弥补这方面的缺陷。

其次受限于小程序的"小"，从下图中可以发现



第二象限中，重要，低频的产品适用于小程序，而这类产品正好是服务类，具有垂直的，细分的，非标准的特征。

第一象限中，重要，高平的产品，不管是从性质，体制，安全，都不适合小程序

至于剩余剩余象限，往往可以依据产品定位，采用依托小程序，或由小程序引流量到自己平台的开发模式

综上比较笔者认为最合适的还是初创公司的MVP产品（最小可实现产品），在公司初期，原生应用的开发复杂，推广成本高，获客成本高，这些困难都阻碍了MVP的产品探索。但如今，微信小程序，凭借着开发低，微信天然的传播能和获客能力可以有效的避免上述困难，凭借着快速开发，迭代，资源相对匮乏的初创企业也能完成MVP产品的快速探索，把握市场动态，打磨出一款伟大的产品。从这个角度来说，小程序能让中国初创的互联网公司减少试错的成本，提高成功概率。

最后大致说一下开发：

从目前文档透露的情况来看，微信小程序提供了基础组件，前端原生控件和API，目的是让一个云端的H5产品具有原生应用的组件和扩展能力，以前开发服务号用到的组件大多数由第三方的框架提供支持，这次小程序，把更多的权限开放出来，帮助开发者快递的接入小程序，尽量标准化和结构化处理数据。并且，注意到，早在上半年，微信就开始公布出一套UI和交互框架，用来统一UI规范和交互示例，因此有理由相信，作为一个程序猿，就算没有UI，没有前端，凭借这些UI规范和交互示例我们也能快速的通过API完成自己的小程序。