小程序开发整理

本文将基于我的浅薄的经验来总结和整理一个基本小程序的从零开发到上线流程。从编码上讲小程序的开发很是简单，不过这是相对于目前流行MVVM的框架下的WebApp开发来说的，换句话说再简单也须要完整的视图、脚本和样式以及服务端支持，在整个流程依上来讲仍然是一个不小的体系。

总体的基本架构像这样：

 

准备工做

小程序最直接的优点就是能消除浏览器端的种种适配与兼容问题以及能使用许多微信客户端提供的酷炫原生能力，而代价就是必须在微信后台作好种种配置，并在申请和认证过程当中作出种种妥协。笼统来讲必要的东西有一下几样：

1. 小程序主体

即必须在微信公众平台上注册小程序并提供相关的主体信息，包括小程序名称以及业务范围，还有注册完成后的认证工做，这些直接影响到开发完成后的审核成功率。题外话是虽然如今小程序开放了我的的注册，但小程序自己目的在于提供具体的服务，服务内容不明确恐怕难过审核，这在笔者看来并不适合我的，终究只能玩玩罢了，我的小程序想上线还得先考虑清楚打算提供何种服务，以及没有支付能力带来的影响。

2. AppId、项目管理和https

小程序申请完成后便可在后台获得本身的AppId与AppSecret用于开发。直接使用微信开发者工具进行开发我的认为是远远够了，不过这工具对小屏幕的电脑不怎么友好，开发工具内提供的能力已经基本够用来编码与测试了，目前发现客服消息是不能发起的，以及部分页面布局和样式会和真机有出入等问题。
微信给出的小程序的代码管理规则比较执拗，一个小程序分别会有一个开发版、体验版和线上版本，而且在后台添加指定权限的人员，开发者只能访问开发版，体验者只能访问体验版，整个小程序项目的代码文件暴露出来的只有最表面的代码文件，配置与依赖之类的都是不用开发者操心的。
还有一个重要的东西就是https，也就是开发者本身的WebApi服务器必须使用https协议进行通讯，这也是必须作的，由于小程序的架构下客户端与WebApi彻底分离，认证就显得很重要了。

总体搭建

如今专一于小程序的编写，来说讲小程序如何一点点搭建起来。
首先是通常目录结构，这里给出笔者的项目目录结构：

其中assets用来放图片图标等资源，pages下是小程序的全部子页面，utils下是封装的工具代码，包括网络请求代码等的封装。
最后的三个app.xxx文件即小程序的全局配置。

• app.js内能够处理页面初始化时的参数处理等。
  好比说对外推广了一个带参数的小程序码，由用户扫描进入后，能够在小程序首页提取小程序码附带的参数，也能够干脆在app.js里来提取，而且能够在这个脚本中定义全局数据等。
• app.json内配置全局的标题啊背景色啊底部导航啊之类的以及子页面也必须都在此先声明。具体的配置规则见小程序的官方开发文档。

• app.wxss即全局的样式配置。
  其中小程序自带的许多组件的样式能够直接覆盖掉，选择器直接写组件名，好比说：

page{
       background: #fff;
   }
   view,navigator{
       box-sizing: border-box;
       font-size: 32rpx;
       overflow: hidden;
   }

　　　　　　page选择器能够覆盖小程序页面自己的样式，view、navigator都是小程序具体的组件，就当是重写过的div标签来改。

具体页面搭建

页面

页面的搭建主要工做就是小程序提供的一堆组件的使用，其中view组件拿来当div用，能够在样式表内重写样式，还有几个很厉害的复杂组件，包括swiper-view能够拿来作可滑动选项卡和轮播图，image组件自带了图片的多种是配方式，以及多媒体组件和各类表单组件。除了组件以外就是一些指令的使用(借用angular的说法)，好比wx:if控制显示，wx:for控制遍历渲染，想吐槽的两点，一是这些指令要记得加双大括号来传入变量值，不然传的都是字符串，二是小程序的这些个指令的值仅支持直接的变量和值的比较，并不支持传入方法，连String.split都不行，这直接致使数据格式化很蛋疼啊坐等改善。

脚本

脚本中要作的事有两件。一是在页面渲染的各个生命周期下执行相应的代码，好比在页面加载时初始化数据，在页面隐藏(打开新的页面但当前页面已缓存)时保存数据，在页面显示(重新页面后退会当前页面)时更新数据，在页面销毁时关闭舰艇和轮训等。二是执行视图中绑定的各类点击事件啊组件值更改的事件啊的回调，好比最普通的bindtap绑定了方法后，此方法需在脚本中定义，当用户点击后即会执行。关于小程序的js脚本想吐槽的是其this指针很是蠢，一个页面里得有很多 var that = this; 这个语句。

WebApi配合

WebApi是除了小程序客户端自己外另外一块须要开发者实现的东西，与公众号的网页开发同样，分为业务的Api交互和微信实时消息的转发和处理两个内容。总结下来经常使用的也就登陆状态的保持(登陆其实微信帮忙完成了，Api这边只须要生成本身的凭证用来与客户端交互)，媒体文件的上传与下载(用户上传下载的多媒体资源)，模板消息的发送以及支付回调处理等，固然本身这边还要提供全部业务数据的接口。还有一个客服消息的转发其实不须要本身来实现，用微信自带的就够了。

部分API能力

转发

小程序的转发和普通网页配置JSSDK转发相似，都是配置转发的内容和回调，可是能配置的只有标题，好在不须要去踩JSSDK这个天坑了，那玩意对SPA是满满的恶意。并且小程序的转发也不是非要用户点击右上角来实现了，能够配置到具体的页面按钮上去。

客服

小程序端发起客户会话很简单，使用指定的组件便可，若是不是非要本身搭一个客服消息转发API的话，加个客服消息组件就算是完成客服功能的接入了。

小程序码与二维码

小程序码和二维码如今变得成熟一些了，有多种码能够生成，有数量有限的和无限的，跳转到具体页面的和能带参数的，其生成由WebApi来完成，小程序端管显示和扫码进入时的参数判断就够。

支付

小程序的支付很是简单，调用指定接口便可，笔者看来这也极大的得益于免去了JSSDK这个祸害。

审核与发布

小程序的审核是一个蛋疼的过程，如今好像是稍微舒服了一些，可是笔者项目上周的提交审核(非首次)仍是持续了仨工做日。总的来讲就是微信那边会很认真的核对提交的小程序是否有业务的不明确以及页面布局或交互上的问题，对于不一样行业的审核也有不一样，审核时长很是看运气很被动，我的看来这虽然严谨但更新一次版本的时间成本略高。

最后再提一点，是小程序的官方开发文档仍是比较完善的，开发过程当中遇到什么问题时，先没必要急着去开发者社区抱怨或者去开发群里贴图，多留意文档里那些说小不小的说明文字，真的解决不掉的话说不定还真是小程序本身的BUG，问别人也没用，只能坐等更新啦。