微信小程序分析
微信小程序是什么
『微信小程序』是微信即公众号之后推出的一项服务。
我们提供了一种新的开放能力，开发者可以快速地开发一个小程序。小程序可以在微信内被便捷地获取和传播，同时具有出色的使用体验。
<p align = 'right' >—— 微信内测界面</p>
</br>
核心理念：
小程序是一种不需要下载安装即可使用的应用，它实现了应用『触手可及』的梦想，用户扫一扫或搜一搜即可打开应用。也体现了『用完即走』的理念，用户不关心是否安装太多应用的问题。应用将无处不在，随时可用，但又无需安装卸载。
<p align = 'right' > —— 张小龙</p>
『微信小程序』 和 『小程序』 ：我们需要这样的一个小程序，它能满足 『即搜即用，用完即走』 的需求，而微信小程序提供的就是这样的服务。
如何开发
在设计方面，微信提供了详细的设计规范，通用控件等，为设计人员提供了设计参考。
微信小程序设计指南_·_小程序-w180
微信小程序设计指南以及 UI 参考（见参考2、参考8、参考9、参考10），整个指南比较简洁。
在开发方面，微信为开发者提供了较为完善的开发文档，提供的接口和框架也非常的丰富。还提供了跨平台的开发工具，使不同平台都可以开发小程序。
组件参考：
- 视图容器：View、Scroll-View、Swiper
- 基础内容：Icon、Text、Progress
- 表单组件：Button、CheckBox、form、Input等
- 操作反馈：Action-Sheet、Modal、Loading
- 导航：Navigator
- 媒体组建：Audio、Image、Video
- 地图：Map
- 画布：Canvas
API 参考
- 网络：常规请求、上传下载、WebSocket
- 媒体：图片、录音、音频/音乐播放控制、文件操作、视频播放
- 数据：数据缓存能力
- 位置：获取位置、查看位置
- 设备：网络状态、系统信息、重力感应、罗盘
- 界面：设置导航条、导航、动画、绘图、其它
- 开放接口：登录（签名加密）、用户信息、微信支付、模板消息
小程序的开发偏向组件化、结构化。小程序加载包到本地运行，与 Web 模式有很大区别, 不能操作DOM，通过 API 与服务器交互，更像 C/S 架构的开发。适合逻辑简单的工具型应用，很强的内容封闭性。
特有格式说明
.wxss 和 .wxml 是 CSS 和 XML 的变体，由微信自己定义和修改扩展的一套语言规则进行书写。
微信设计了一套框架：MINA，框架提供了自己的视图层描述语言 WXML 和 WXSS，以及基于 JavaScript 的逻辑层框架，并在视图层与逻辑层间提供了数据传输和事件系统，可以让开发者可以方便的聚焦于数据与逻辑上。
框架的核心是一个响应的数据绑定系统。整个系统分为两块视图层（View）和逻辑层（App Service）
框架可以让数据与视图非常简单地保持同步。当做数据修改的时候，只需要在逻辑层修改数据，视图层就会做相应的更新。
微信的这套运行机制和 Facebook 设计的 Flux 设计模式非常的像（Flux 同 MVC 一样是一种设计模式），而整个项目的架构和 React + Redux 非常像。（ Redux 是对 Flux 架构的一种实现）
Flux 示意图：
Flux 设计模式基础-w2254
MINA 生命周期：
mina-lifecycle
响应式单向数据流。
目录结构
项目根目录全局文件
- app.js：小程序逻辑（生命周期、全局变量、全局方法）
- app.json：小程序全局设置
- app.wxss：小程序公共样式表
页面目录文件
- .js：页面逻辑
- .wxml：页面机构
- .wxss：页面样式
- .json：页面配置
微信小程序开发目录结构-w758
除了上述基本目录结构外，开发者可以添加其它目录，比如资源目录，项目说明文件等，还可以根据页面层级创建页面子目录，做好配置即可。
全局配置文件
小程序全局配置
详细每个参见官方文档。
逻辑层
逻辑层将数据进行处理后发送给视图层，同时接受视图层的事件反馈。
- 注册程序：应用生命周期、全局变量、全局方法
- 注册页面：页面生命周期、初始化数据、事件处理方法
- 模块化：逻辑代码的复用
- API：API 的调用
详情请查看官方文档。
视图层
框架的视图层由 WXML 与 WXSS 编写，由组件来进行展示。
将逻辑层的数据反应成视图，同时将视图层的事件发送给逻辑层。
WXML(WeiXin Markup language)用于描述页面的结构。
WXSS(WeiXin Style Sheet)用于描述页面的样式。
组件(Component)是视图的基本组成单元。
- WXML：微信设计的一套标签语言，用于构建页面。
- 数据绑定：Mustache 语法包装，支持逻辑判断和基本运算
- 条件渲染：依据条件渲染不同的视图
- 列表渲染：重复渲染组件
- 模板：复用自定义组合的视图
- 事件：视图层到逻辑层的通讯方式
- 引用：视图代码复用
- WXSS：微信对 CSS 的修改和扩展，具有 CSS 的大部分特性。
WXSS 扩展的特性：
- 尺寸单位
- 样式导入
语言细节参考官方文档。
分析
微信在发布的五年时间中从一个移动端熟人社交软件开始向着构建微信社交生态方向发展。如果说公众号是内容生产者的狂欢，为信息的分享传播提供了良好的入口，那么小程序就为开发者人员构建微服务提供了良好的支持，大大的降低了开发维护推广成本。依靠微信平台还可以获得可观的流量，为创业者减轻了资金压力，从而专注于提供优秀的服务。像教育、医疗、家政、求职招聘、二手买卖、旅游、票务、汽车后市场等，这些领域有的强调支付场景、有的低频非刚需，都非常适合在小程序上发力。
现在已经出现很多观点表示小程序具有某种颠覆的能力，但我个人认为依照目前微信小程序的表现，谈颠覆为时过早。
从产品角度来说，小程序能力和使用场景的限制，就意味在设计上要非常谨慎，过于复杂的交互和较深的层级都会破坏使用体验。其实从张小龙所描述的『用完即走』的理念，我们可以思考，符合这种情况的恰恰就是那些不需要长时间驻留、层级扁平、提供便捷服务的小程序，同样这样的程序我们随用随下。另一方面低成本和低门槛也意味着会产生一大批垃圾应用，所以严格的审查机制是必须的。但是随着 APP 市场变大，审核效率就会成为瓶颈，这和人们认为的快速迭代是相矛盾的。因此，如何做审核是微信需要好好思考的问题。
从研发的角度看，小程序并不存在技术上的创新，Web App 和 Native App 的争论从没有停止过，哪怕现在非常火热的 RN 也没有表现出完全取代原生的能力，所以小程序在技术创新上是否能走远，这还值得商榷。
总结
缺点：
因为一些安全和其它方面的考虑，小程序的能力被限制，禁锢了小程序的能力。
- 目前限制应用包大小为 1024 kb 。
- 微信开放接口 API 较少。
- 仅限于小应用的能力，想要实现复杂应用能力上还不足。
- 在多层级使用场景以及需要跳转类的需求上劣势明显。
优点：
- 比传统的 Hybird 应用在操作体验上，它具有更快、更流畅的应用体验，摆脱混合应用对浏览器性能的依赖且能够调用系统原生接口，有一定的数据缓存能力。
- 比 React Native 类应用，更轻量级。
- 比 Native App ，则胜在开发周期短、投入成本低、使用便捷，且依托微信庞大的用户基础和粘性，可以迅速引流，验证产品模式和用户需求。
小程序在开发上不具有太高难度，更要考量的是作为产品或服务的设计和使用场景的优化上，微信小程序的真正优势在于开发成本低、更快速的迭代，可以快速测试用户需求，而不是技术上的颠覆。对于创业者和小公司来说，是一个快速启动的方式。但对于希望走的更远的企业，原生或 RN 类 APP 目前还绕不过去，微信小程序只能作为一个产品填补式的存在，当然这些还需要具体产品具体规划。
通过上述信息我们可以这样认为，小程序是一个可通过 Web 技术栈开发，使用微信框架调用原生功能的类 Web 小应用，小体现在它本身的能力受微信的规则和框架的限制。这种形式仅仅在操作体验上优于传统 Hybird 开发的应用，与 React Native 开发复杂应用的能力要低太多，目前不在一个层次上。现阶段所展现的能力受限，随着用户和开发者的持续投入，微信也许会进一步释放它的能力，潜力较高。小程序如果在技术上可以获得强大的支持，对于低频应用（日历等小工具类以及其它形形色色的应用）或者应用使用场景（消费类浅层级应用使用场景）的补充，还是大有可为。
具体限制：
- 不支持 HTML。WXML 语法与 HTML 有差异，CSS 选择器不支持级联。框架并非运行在浏览器中，所以 JavaScript 在 web 中一些能力都无法使用，如 document，window 等。
- 源码包大小不能超过 1M，单次request 传输数据最大 1M。
- MINA 实现的 TabBar 最多 5 个 tab，wx.navigateTo 可推入后台的页面最多 5 层，超过则不能打开新界面。
- 没有 WebView ，自带 View 暂不支持图文混排。
- 不支持 A 标签，无法打开普通网页。
某些细节可参考官方文档 Q&A 部分。
