微信，已经是中国最重要的移动生态，它的一举一动都会对商业、技术、生活产生巨大影响。即使“应用号”依然犹抱琵琶半遮面，但是也挡不住极客研究的脚步。
这里是转自TalkingData数据可视化团队梁灏的博文（原文），对应用号做了一些技术上的分析。
前段时间吵地如火如荼的微信应用号现在终于浮出了水面，各种教程文章、攻略，甚至前端培训班一夜间在各大技术社区疯狂转载。微信的这一举动，的确是推动了 HTML5 的发展，也给很多企业和个人带来了新的机会。本文则以技术视角，基于现有的资料对微信应用号进行一些猜测，可能微信的应用号，并不是我们原先想的那样。
应用号的开发模式
因为目前还没有开发的权限，所以只能根据现有的资料来总结。
首先需要安装开发者工具，配置AppID和本地目录来创建一个小程序：
初始项目包含了3个文件：
- app.js 所有生命周期、接口调用的全局配置，比如获取用户信息、使用存储
- app.json APP配置，比如页都有哪些页面（pages下第一个是首页）、导航条颜色，微信会读取这个配置来解析小程序
- app.wxss 全局使用的公共样式
小程序的目录结构还是很清晰的，每个页面包含index.js、index.wxml、index.wxss、index.json四个文件，从目前已有的Demo看，微信内置了类似Vue的MVVM框架，已经自带了很多组件，比如view、image、block、text等。开发者需要按照这套规范来开发。
一个小程序页面的生命周期：
- onLoad 页面初始化
- onReady 页面渲染完成
- onShow 页面显示
- onHide 页面隐藏
- onUnload 页面关闭
应用号限制还是很多的，只能使用微信自己的结构来布局，非常像ReactNative，不能使用自己的框架和插件，并且脱离DOM，一切以数据为主，这点应该是借鉴自Vue。即使是原生js插件，也很难使用，应用号禁止操作DOM，所以一切跟操作DOM相关的都不可以。
目前可了解的渠道还比较少，总结来看，小程序对用户和开发者都是比较轻量的，开发模式比传统开发更简单，但也更局限，程序托管在微信云端，提交代码后，需审核后上架，这和App Store的规则很像。在用户端时，微信会编译小程序（也有可能是预编译的），将代码编译为HTML（也有可能是Native的，这点很重要，需要后续调研验证）。
小程序对开发者来说，应该要比开发传统的 HTML5 要简单些，因为微信限制了开发模式，必须使用微信已有的组件库，比如：
控件：
action-sheet / button / searchbar / modal / navigator / drawer
表单：
checkbox / radio / selector / switch / slider / input / label / picker
媒体：
image / audio / video
视图：
progress / toast / scroll-view / text / view / mask / icon / spinner / swiper / slide-tab
能使用的能力也是有限的，比如数据获取、图片获取、声音获取、存储、支付、登录等，使用到的 JavaScript 语言也较为简单，每个页面一个独立目录，而且配备一个js脚本、一个css样式、和一个json配置文件，所以根据这样的开发模式和结构配置，猜测微信大概有两种可生成应用的模式，一种还是以 webview 为主，像 Vue 组件化那样在前端编译，另一种则是在 Android 和 iOS 不同平台编译为不同的原生代码，像 ReactNative 和 Weex，前者对开发者更灵活，想象空间大（不过微信还是有限制），后者则对用户的浏览体验很好（尤其在中低端安卓设备）。
与其说应用号是HTML5，不如说它是一个基于微信的封闭运行环境
我们知道，一个页面的呈现离不开对DOM的操作，而应用号恰巧不允许任何DOM的操作，包括引用外部资源，打开外部内容，所以连jQuery都是不可以的。也就是说，开发者必须遵循这套类组件化的开发模式来开发，这确实扼杀了很多奇思妙想，不过现在开放的底层 API ，已经够我们好好折腾一番了。
应用号不能打开外部页面，但是可以在指定了的相对页面之间进行跳转，而且可以通过接口来打开、返回，个性化标题栏、导航栏。从已有的代码结构分析，应用号造了一个 ReactNative 的大轮子并不是不可能的，如此约束的组件化开发，确实是能实现用前端技术开发原生体验的APP，这样即稳固了微信的生态，也限制了开发者的使用权限，同时在移动设备的浏览体验也提升了，做过 Hybrid App 的同学肯定知道，在中低端安卓设备上，由于webview 渲染DOM性能差，会出现卡屏、闪烁的糟糕体验，但如果微信应用号最终是通过编译为原生代码来运行的话，这个问题就会很好的解决了。
微信用 JavaScript 创建了一种新的开发框架，使其运行在自己封闭的环境内。对开发者来说，做一个应用号小程序并不难，因为微信已经帮你封装好了组件和底层API，只用看教程按部就班，比如一行代码可能就能实现一个复杂的跑马灯或是下拉刷新，而开发者只需要维护好数据即可。如果你用 Vue 或 React 进行过组件化开发，那么对这种开发模式并不会陌生，会很快上手，相反，如果你长期从事的是jQuery这类DOM为主的开发工作，学习成本会稍微高一点，主要是在概念的转换上一时很难接受。
虽然从很多地方都能看到 ReactNative / Weex 的影子，比如wxml的后缀名、组件化的标记语言、数据和视图的双向绑定，但也不能排除微信应用号仍然使用传统 webview 来运行的可能性，毕竟 webview 已经被太多的APP使用，经历了大量场景的验证，在兼容性、可行性上都是很好的解决方案，而且如今移动设备越来越好，V8引擎也足够快，昔日的问题未来或许会改变。
以上内容大多是基于现有资料和代码进行的预测，具体是否正确还需开放时进一步调研。
