今天和大家交流分享的是关于微信小程序的一些开发心得。
包括4个部分：
- 个人简介。包括我所在的公司和个人的一些情况。
- 小程序的介绍。讲述为什么前端开发者要学习小程序开发以及官方为开发者提供了哪些有价值的资源。
- 小程序与WebApp对比。熟悉WebApp的开发者怎样快速掌握小程序开发，小程序和WebApp有哪些异同点。
- 小程序开发技巧。分享我在开发小程序时碰到的一些问题和解决方法。
我所在的长沙梯度信息科技有限公司是利用容器技术，为企业提供云服务的科技公司。
目前的产品有智能云平台、大数据平台、监控平台、语义分析平台。
客户包括翼支付、广西商务厅、丝路视觉等企业单位。
我目前是梯度科技的资深Web前端工程师，同时也是慕课网的讲师和认证作者，在此之前我在开发者头条上也建立了自己的个人专栏，今年顺利通过了中科人才中心评审组委会评审，认证为软件开发专业的工程师，最近刚加入微信小程序联盟，成为博主。
欢迎大家关注我的个人微信订阅号“web学习社”，一起学习和交流关于web开发方面的知识和经验~
小程序简介 前端开发者为什么要了解小程序？小程序发展趋势
宏观上看，小程序2016年底推出的时候，很多人对它前景非常看好，甚至预测它会取代手机上的应用商店。
但至今半年多过去了，发展状况并非如此,由于小程序本身的封闭性和去用户粘性，一些小程序甚至被放弃中止开发了,如“得到”和“今日头条”。
据微信小程序数据统计平台阿拉丁报告，小程序下半年流量将呈现大幅增长。
在微信不断开放小程序入口以及增加推送，和微信应用其他应用捆绑在一起，依托微信本身巨大的流量平台，从长远角度来看，我们可以期待小程序的下一轮爆发期~
小程序对于web开发者的意义
再从微观上，就开发者本身的成长路线而言，Node.js不仅让前端变得工程化和自动化，同时为前端开发者提供了开发服务端的能力，让JS开发者走向全栈。
但是由于浏览器本身的安全策略，web开发者接触客户端硬件的能力一直被封印着。混合应用正是解开封印的方式，桌面端早有开源的HEX项目，移动端有hybrid这样的解决方案。
但是像hybrid这种混合对前端开发者来说并不友好，APP编译时间长，而且需要在不同平台发布，开发者调试可能还需要APP开发者配合进行。
而小程序以微信这个跨多种设备的APP为平台，获取硬件API，可以算是最平滑最高效的成为“大前端”的方式。由此我们便可以将自己打造成“T”型人才。
小程序提供的资源微信Web开发工具
官方推出的集开发、编译、预览、调试一体的开发工具，自带一些常用的快捷键，支持ES6语法，虽然编辑代码能力较弱，但是要编译预览调试只能靠它了。
调试界面外观酷似Chrome调试工具，两个页功能签略有不同，"AppData"查看页面数据，"Storage"查看存储数据。
自带watch功能，一旦代码发生变化则自动编译
小程序示例
分组件示例和API调用示例，可以去官网上下载源码，也可以直接在小程序中搜索查看。
设计资源
包括psd文件和设计规范以及Sketch文件。
开发者社区
一个简单交流平台，支持简单的发帖回帖，一般问题交流、公告发布都在这里。
小程序管理平台
小程序的后台，提交审核、发布小程序以及编辑一些基本信息和调试信息等。
其他文档
API文档、Demo等。
小程序与WebApp 小程序vs原生Web页面- 视图。小程序采用了和HTML相似度极高的WXML文件，但它限制了a标签的使用，不允许直接跳转到外部网页，同时也不支持
 这类HTML字符串。最大的不同点就是HTML元素通过DOM操作，它只能通过单向数据绑定来操作。 - 样式。小程序的wxss文件就是增强版的css，支持文件之间的引用和css3特性。同时由于在微信上运行，我们也不必考虑浏览器的兼容性问题了。
- 逻辑。JS方面支持ES6，提供了一些硬件的API，去除了DOM和BOM。
- 配置。小程序支持全局配置app.json和页面配置xxx.json，全部配置可以配置路由、tab页、窗口等，而页面配只能修改当前页面的窗口样式和标题。
- 模板。在小程序中，视图层和模型层的交互是单向的，模型层发生改变时，通过数据绑定来影响视图；视图层变化时，通过事件绑定来修改数据。但事件只能传递事件对象，所以要获取事件相关的数据只能通过事件对象对应元素的属性。支持简单的循环判断等语法，也支持通过include和template方式引用模板。
- 样式。之前提到过，wxss简单的理解就是css3 + @import文件引用，而MVVM通过构建工具支持各种预编译语言。
- 组件化。不直接支持自定义组件，第三方模块也较少。而单页应用与之则相反。
- 路由。相对单页应用路由，小程序的则简单不少，支持路由参数但是不支持子路由。
- components //业务组件
- images //图片
- pages //页面
- utils //公共js
|
- api.js //微信api封装，处理兼容性问题，业务化一些函数
- bus.js //公用业务
- config.js //配置信息，包括开发环境识别等
- datetime.js //日期处理函数
- dict.js //字典数据
- request.js //请求封装，包括登录校验
- util.js //工具函数
- validate.js //表单校验
- app.js //项目初始化逻辑
- app.json //全局配置
- app.wxss //全局样式
- color.wxss //全局颜色
- font.wxss //全局字体大小
- form.wxss //全局表单样式
- property.wxss //全局属性样式小程序如果和后端有交互，需要上线之前配置好服务端域名，而且必须是https协议的。
在开发中我们采用nginx做了代理，同时小程序后台进行了配置，将不同版本转发到不同域名进行访问和调试。
小程序开发时使用mock服务器，后端联调时直接指向后端服务器，调试完成后指向开发服务器。
为了避免上线之后代码指向错误的后端路径，可以设置storage缓存来当作小程序的“环境变量”。
小程序API的使用由于小程序在不断地迭代和更新，所以可能会出现新的API无法在老版本的微信上调用的问题，微信官方文档会及时给出提示，并且提供了相应的处理方式：
- 判断API函数是否存在，不存在时做兼容处理。
- 用canIUse函数判断API函数，返回值为false时做兼容处理。
由于canIUse函数本身存在兼容性问题，所以第一种方式比较好。
显然我们不能每次使用API函数之前都判断一次，所以项目中采取了对原生API全部封装的方式，来处理不同情况：
- 对于不存在兼容性的API直接调用。
- 对于存在兼容性的API做降级处理
- 部分API进行业务封装
受张鑫旭的面向属性样式的启发，项目中对于常用的枚举属性一直采用面向属性的样式类命名。
如常用的display:block;命名成
.d-b {
display: block;
}这样的好处是有效的避免了这种高频样式的重复。
同时对于字体和颜色也抽取成简单的样式类，方便复用，虽然颜色和样式不属于枚举值，但是一般一个小程序为了保证风格统一，不可能出现太多的颜色和字体大小（复杂的颜色应该会在图片中），所以也适合抽取成简单的样式类。
表单组件比较特殊，以后有机会再详细说明。因为使用情况较多，所以也写成了全局公用样式。
小程序组件化组件化也是比较麻烦的一个事情，参看我个人订阅号的这两篇文章有详细说明。
小程序版本与权限本地开发完成，可以先生成“预览版本”，同时可以上传生成“开发版本”，开发版本可以手动设置为“体验版本”，“开发版本”可以提交进行审核，审核通过之后才可以发布成为“线上版本”。
其中管理员拥有最高权限可以查看所有版本，其他角色需要管理员同意。
开发者仅次于管理员，可以查看所有版本。
体验者可以查看“体验版本”和“线上版本”。
普通用户只可以访问“线上版本”。
小程序的访问入口正在不断被开放，包括扫描生成二维码和小程序码，或者朋友转发的小程序码，以及绑定普通网址的二维码。
其中普通网址二维码需要网站校验通过后才可以绑定，用户可以在用户中识别二维码跳转到小程序而不是原来的网站，也就是微信做了一个域名转发的工作。
小程序调用微信API失败时会有回调函数，在回调函数中分情况处理。
如果是硬件层面的需要提交官方进行修复，如果是页面方面的可以自己做兼容处理，比如模态框之类的。
如何制作一个小程序编辑工具，让用户通过鼠标拖拽之类的简单方式来自定义自己的小程序？小程序本身只能在微信开发工具中进行修改，所以只能想别的方法实现。
这类工具我未涉及过，不过可能一种实现方式就是，在Web页面上编写和小程序功能样式相同的组件，供用户进行编辑，编辑保存到后端。我
们再利用后端的配置数据编译生成对应的小程序。
总结和WebApp相比，小程序太弱了，所以给了开发者改进它的机会。
和WebApp相比，小程序又太强了，基于微信这个流量入口，又拥有硬件API，和微信公众号等产品绑定...想象空间不可估量。