一 / 启动速度

微信小程序相信给很多人的第一印象就是启动速度快，毕竟小程序是类Web应用，如何做到快呢？

1、小程序包大小不能超过1M

微信小程序在本地开发完成后需要上传到微信的服务器进行编译和打包。目前官方限制小程序包大小不能超过1M。当用户第一次打开小程序的时候，微信客户端从服务器下载小程序包（后缀名为wxapkg）到appbrand/pkg目录下。对小程序包大小的限制保证了所有小程序的首次加载速度。同时，小程序包存储于文件系统中，包含了默认的页面数据，支持离线使用。

2、每个小程序由1个独立进程承载，同时只能打开最多5个小程序

每次开启一个小程序，微信都会为其启动一个独立的进程（通过在AndroidManifest预先注册5个承载小程序的Activity）。如果同时打开的小程序达到了5个，则从第6个开始，会按照LRU顺序依次抢占进程。

独立进程保障了小程序的内存资源，最多同时打开5个小程序的限制则避免小程序占用过多的系统资源。另外，进程的复用也节省了重新创建进程的开销。

3、小程序页面状态缓存

用户每次打开小程序之后，选择左上角的关闭或按返回键时小程序只是隐藏到后台，其内存并不会被微信回收，而且基于微信的强大市场地位，其内存一般也不会被系统回收。因此当用户下次打开同一小程序时能立即看到上一次访问的界面（除非该进程被其它小程序抢占），不需要重新加载页面。

二 / 渲染性能

Web技术离不开渲染的性能问题，小程序在提高渲染性能上对PageFrame做了下面的这些优化：

1. Native预先加载额外一个Webview

2. 当打开指定页面时，无需请求额外资源，直接渲染

3. 重渲染使用Virtual DOM减少开销，采用diff算法局部更新

4. model和view双线程，单向数据绑定

5. 小程序的Javascript通过X5的JSCore来解析，由X5基于Mobile Chrome 37内核来渲染

数据（Model）与视图（View）完全分离。AppService逻辑层运行在独立的环境中，无法直接操作DOM。数据请求和业务处理等在逻辑层完成，通过Native的JSBridge与视图层通信，传递数据变化到视图层，视图层同样通过JSBridge传递UI事件到逻辑层。与双向数据绑定相比，这种单向数据绑定的方式更加简单高效，缺点则是无法实时反馈用户输入。

三 / 安全性

1. 四种服务器域名（request、socket、上传文件、下载文件）每种只能配置一个合法域名，不允许跳转到外部网站、不允许放链接、不允许相互之间跳转。

2. 通用request网络请求强制使用https，采用session_key对称加密。

3. DB数据整体做加密保护。

4. SD卡文件做完整性校验。

四 / 页面生命周期和路由管理

1. 页面路径深度最多5层

2. 可跳转或重定向到指定页面

3. 应用生命周期：onLaunch、onShow、onHide

4. 页面生命周期：onLoad、onReady、onShow、onHide、onUnload

五、框架设计

小程序框架的分层设计简洁清晰，视图层和逻辑层完全分离，分别运行在不同的线程中，通过Native的JSBridge实现通信，好处是简单、高效、安全。数据在逻辑层和视图层之间单向绑定，而事件则从视图层分发到逻辑层。重渲染使用跟ReactNative类似的Virtual-DOM方法减少开销，页面渲染依然主要依赖基于X5内核的Webview渲染方式，结合部分原生组件。

• 优点：Web-like开发方式

• 与手机管家插件框架的对比分析：

从技术层面上看，小程序除了微信自己定义的WXML和WXSS视图层描述语言以及WeUI基础样式库之外，并没有太多新的东西，跟其它web应用框架主要区别在具体策略上，比如包大小限制、进程管理策略、组件设计规范、网络通信的限定等。与手机管家的插件体系对比：

1. 小程序的Web-like开发方式更加快速便捷，易于扩展和更新升级；

2. 业务层和框架层更加独立，只依赖于API，可各自演进；

3. 框架层对系统和设备进行了抽象，小程序可聚焦于业务本身，不用担心各种适配问题。

• 手机管家可以参考扩展的地方：

1. 增加web-like开发方式的支持，方便一些轻应用场景的快速验证和部署；

2. 沉淀手管的基础能力到框架中，减少插件之间的耦合度；

3. 在框架层对系统做一层抽象，集中解决各种权限和适配问题。