| 导语 隐隐觉得有几本书要火《从入门到精通微信小程序》，《微信小程序开发权威指南》，《微信小程序之美》，《微信小程序之道》，《颈椎病康复指南》。。。咳咳，跑偏了，什么？没见过这几本书？那你总听过微信小程序的大名吧，作为移动端的新起之秀，小程序牵动了无数人的目光。作为有幸参与并推动小程序成长过程的团队之一，我们也不能甘（fang）于（qi）落（xuan）后（yao），经过我们几天的努力，这篇微信小程序开发经验分享展现给大家。本篇文章主要就小程序的适配、小程序的生命周期、小程序的架构、小程序的开发以及我们趟过的坑这几点展开来讲。 话不多说上干货（内容比较干，建议大家自备水壶）～

写在前面：

小程序的定义：

很多人问我，说的这么热闹，小程序到底是个什么东西？下面我先简单介绍一下。

官方这么定义小程序：

“小程序是一种不需要下载安装即可使用的应用，它实现了应用“触手可及”的梦想，用户扫一扫活着搜一下即可打开应用。也体现了“用完即走”的理念，用户不用关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载”。

小程序是一个由微信提供开发组件与开发规则，以js为主要开发语言，最终运行在微信App内的轻量型应用，有着即扫即用的特点。它不是H5，但与H5一样，小程序有着开发上手快、开发成本低的特性；它不是App，却有着同样的流畅度。小程序的出现使前端工程师可触及的领域进一步增大，可谓是迎来了前端工程师的春天～～

我们的小程序：

小程序的点在一个“小”字，对程序大小要求有限制，对页面嵌套的层级有限制，不适合过于重的交互。小程序不能跳出，不能调起外部应用，消息推送折叠在微信内部，相比于原生App有着很大的局限性。

但是，相比于H5，小程序又有着不可忽视的优势，固定化的入口，丰富的组件，系统控件的接口权限，接近App的使用流畅度，微信强大的生态圈...

结合上面两点，我们认为：小程序＝固定入口＋有体系的H5

根据这一点，我们仔细斟酌，提炼出体育用户的核心诉求，将体育小程序的第一阶段功能定位为赛程查询、数据、资讯推送，第二阶段的功能定位为视频点播、个性化提醒（关注、预约、定制）。

关于小程序的适配：

众所周知，微信App运行在Android、iphone、iPad等多种屏幕尺寸和分辨率的设备上，不同终端的微信小程序用的是同一套代码，需要照顾到一个“小程序”在多种不同大小屏幕的使用体验，所以在设计排版时推荐栅格式排版。而在代码实现方面，微信官方比较推荐用Flex、rpx来实现小程序的适配。

Flex布局是2009年，W3C提出的一种新的方案，可以简便、完整、响应式地实现各种页面布局。目前，它已经得到了所有浏览器的支持。

rpx单位是小程序中css的尺寸单位，可以根据屏幕宽度进行自适应，规定屏幕宽为750rpx。如iPhone6的屏幕像素为375px，则750rpx＝375px，1rpx＝0.5px。同时小程序也支持rem: 规定屏幕宽度为20rem；1rem = (750/20)rpx 。 

Flex与rpx搭配可以解决大部分的适配，但遇到极端宽高比的情况，就需要变动元素的排放位置。而小程序不支持Media Query，那就要通过js来进行不同样式的切换。小程序里获得屏幕宽高的接口是异步的，实现响应式布局尽量在app.js里尽早执行防止页面抖动。

关于小程序的生命周期：

小程序的框架程序包含一个描述整体程序的app 和多个描述页面的page。其中，app由三个文件构成，公共设置的app.json 、公共样式的app.wxss、主体逻辑的app.js 。每个page由四部分组成，页面设置page.json、页面文件page.wxml、页面样式page.wxss、页面主体逻辑page.js。

与H5开发一样，我们可以根据需求在app.js和page.js里添加程序在生命周期每个阶段相应的事件。比如在页面onLoad的时候进行数据的加载，onShow的时候进行数据的更新。

一个page的生命周期从onLoad开始，整个生命周期内onLoad、onReady、onUnload这三个事件仅执行一次，而onHide和onShow在每次页面隐藏和显示时都会触发。当用户手动触发左上角的退出箭头时，小程序仅触发app.onHide，下次进入小程序时会触发app.onShow以及当前page.onShow。仅当小程序在后台运行超过一定时间未被唤起、或者用户手动在小程序的控制栏里点击退出程序、或者小程序内存占用过大被关闭时，小程序被销毁，会触发app.onUnload事件。

一个完整的小程序执行的生命周期如下：

关于小程序的架构：

如图，每个小程序分为两个线程，view和appServer。其中view线程负责解析渲染页面（wxml和wxss），而appServer线程负责运行js。appServer线程运行在jsCore中（安卓下运行在X5中，开发工具中运行在nwjs中），所以js不跑在webview里，不能直接操纵DOM和BOM，这就是为什么小程序没有window全局变量。

那js如何操纵页面？js与页面的交互靠setData和事件触发，js通过setData来改变页面数据，页面通过下发事件来触发js中对应的响应事件。setData同时会改变当前页面的Page函数里的data对象，注意异步数据setData以后一定要update，不然页面上的数据不会及时更新。 

最初版本里，小程序的所有js跑在同一个作用域下，开发过程中一不小心定义了相同的变量名就会导致其他页面的数据错误。在我们的推动下，现在每个小程序页面都是一个独立的作用域，命名空间互不冲突。有人问，那我们想要全局变量怎么办？又没有window。微信提供的解决方案是在app.js中注册全局变量，在每个页面中通过getApp()函数获取。

关于小程序的开发：     

小程序开发入门简单，按照官方文档上给的简易教程，可以快速建立一个小程序。但是实际上手开发会发现这样几个问题：

1. 小程序的开发工具支持简单的模块化，page路径可单独设置，但是提交代码包的大小有限制1M，而小程序没有提供相应的文件压缩与合并。

2. 以前小程序框架的CSS 不支持 import（现在支持了！），所有样式只能写在一个文件里，不方便拆分，也不支持模块化

3. CSS中图片不支持相对路径，需使用线上地址或base64的，在开发阶段不方便

4. 暂不支持es6（新版本也支持了！超哥棒棒哒）

5. 不支持LESS SASS POSTCSS

6. 页面与页面之间代码复用性差

为此，我们引进了webpack将开发目录与发布目录区分开来。webpack是一个前端资源加载／打包工具，它能把各种资源，例如JS（含JSX）、coffee、样式（含less/sass）、图片等都作为模块来使用和处理。通过引入webpack，我们实现了对es6+sass+postcss的支持，更加灵活的模块化体系，成功隔离了开发目录和发布目录。

如上图所示，我们指定发布目录到／pub，图片和css抽取合并后生成wxss文件，例如allmatch页面的资源文件全在component/allmatch文件夹内，打包后生成的allmatch.wxss文件直接放在pub目录下。

这里我要讲一下，由于document、window对象的限制，Babel runtime相关、Commonchunk、code spliting、imports-loader等插件都不可用，想接入webpack的童鞋们要引起注意。在业务开始初期，这可花了我们好几天在和新框架磨合（泪奔脸）～

webpack还有一个小问题，就是在调试的过程中会生成许多不必要的文件，为了解决这个问题，我们写了一个清理发布文件夹的脚本，每次打包完成后会自动运行，清理非最终所需文件。 

一些坑和经验：

• page需在app.json里注册才能被当做页面使用，利用这个现象可以创建一些公用template。

• 不要试图去给view等标签设置样式，会被过滤。

• document window等都不存在于jscore 中，所以大部分涉及dom操作的框架都不能直接拿来使用。

• 介于安全性考虑，new Function，eval 会被过滤掉。

• CSS 请用BEM的形式，因为app里没有自选择器，为了防止微信提供的组件样式被破坏，小程序也禁止使用层级选测器，最好提前养成好习惯。

• CSS里不要用图片相对路径，建议直接base64，wxml 里可以用图片路径。

• 关于接口，一年后服务器会只支持https协议的接口，所以，现在尽量统一为https。

• 关于登录，目前小程序不支持cookie，而是采用前端利用微信提供的接口获取登录凭证code，server端再用code获取密钥session_key的方式对用户数据完成加密解密，整个过程需要server端对已有的登录体系进行再次的封装，而本地的登录态可以利用微信提供的本地存储进行保存。 

• 
  
  

• 关于开发工具的提交预览功能，预览功能需要在能访问外网时才能使用，开发网不支持使用，自己生成的二维码只有自己可以体验。这对测试造成了一定的困扰。

• image组件会有默认图片尺寸（320*240），无法完美适配宽高都不固定的多尺寸图片。

关于我们：

短短一个多月，在小程序的开发过程中我们经历了许多，也成长很多，在此非常感谢有这个机会发表自己的一点小见解，若有理解错误的地方尽请更正。