目录：
一：背景介绍
二：Web体系下构建小程序所带来的顽疾
三：多进程运用
四：离线包技术
五：视图层技术的演进--同层渲染
六：逻辑层技术的演进—双线程模型
一：背景介绍
1.1、小程序的定义
无需下载安装即可使用的应用，它实现了应用触手可及的梦想，用户扫一扫或者搜索一下即可打开应用，也体现了用完即走的理念，用户不用关心是否安装太多应用的问题，应用将无处不在，随时可用，但又无需安装卸载。
总结为：无需下载安装、触手可及、用完即走。
1.2、手Q充当的角色
手Q中可以运行各个第三开发商提供的小程序，在这个过程中，手Q主要是充当宿主、容器、载体的角色，提供给各个不同的小程序运行的环境，手Q小程序功能模块应该最大限度的保证各个小程序开发者只需要关注业务本身的功能，而涉及各个小程序的加载、更新、性能、启动速度等体验问题，这是需要手Q宿主重点解决的问题。
1.3、小程序的运行机制
小程序是基于WEB规范，采用HTML，CSS和JS等搭建的一套框架，但本质上还是在整个WEB体系之下构建的。
二：Web体系下构建小程序所带来的顽疾
在Android系统的开发中，通常需要系统控件WebView实现前端页面的加载，那小程序在基于web体系下构建可能会产生什么问题，下面就汇总一下：
问题一：页面加载速度慢
问题二：交互体验没有原生界面好
问题三：WebView控件加载小程序界面时，占用内存大
问题四：小程序的内存泄露与小程序的相关Crash会影响手Q主进程
问题五：加载页面依赖网络，网络状态差或弱网情况下，容易发生白屏、卡顿等问题
问题六：加载页面后，无法有效规范、约束和监控页面的行为（管控性和安全性）
上面的列表汇总了在Web体系下构建小程序所带来的问题，那下面我们就来了解小程序SDK是如何通过技术手段最大限度的解决和优化以上问题的。
三：多进程运用
3.1、手Q主进程对小程序的管理：预加载、分配、创建、销毁、管控等
概述：由于进程之间的内存无法共享，小程序的生命周期需要在某一个进程中维护，不然无法做到动态分配进程和栈，而这个进程选择手Q主进程最为合适，因此需要创建一个管理器，这个管理器负责以下几件事：
1、在空闲时预加载进程。
2、根据设置的可开启的最大小程序数量，对进程进行新建、销毁等操作。
3、合理的为接收到的请求分配空闲的进程。
4、接收外界开启、关闭等对小程序的操作。
5、接收远程小程序的生命周期回调并通过某个uuid进行维护。
6、所有这些管理和维护的操作，对小程序接入者都应是透明的，无需关心具体实现流程，仅在需要时开启小程序即可。
3.2、进程间的通信
手Q宿主进程与小程序进程间通信图解：
四：离线包技术
4.1、离线包技术的引入
背景：在为什么要使用离线包之前，我们需要先了解一下加载一个前端页面的过程：初始化webview
-> 请求页面 -> 下载数据 -> 解析HTML -> 请求js/css资源
-> dom渲染 -> 解析js执行 -> js请求数据 -> 解析渲染 -> 下载渲染图片。
离线包的实现与优势：
解析：离线包是将包括HTML，JavaScript，css等页面的内置静态资源打包到一个压缩包内，预先下载该离线包到本地, 然后客户端将数据传递给页面，通过webView加载展示，不需要网络请求，webView只要渲染页面，执行js即可，解决html本身加载需要的时间问题，离线包基本思路通过webview统一拦截url,
将资源映射到本地离线包。
带来的优势也是显而易见的：
提升用户体验:
通过离线包的方式把页面内置静态资源嵌入到应用中并发布，当用户第一次开启应用的时候, 就无需以网络环境下载该资源，而是马上开始使用。
实现动态更新:
在推出新版本或是紧急发布的时候, 可以把修改的资源放入离线包, 通过更新配置让应用自动下载更新，无需通过应用商店审核, 就让用户及时接收更新。
备注：离线包机制，本质上是通过空间换时间的技术实现用户体验的优化。
官方说明
概述：某些情况下，开发者需要将小程序划分成不同的子包，在构建时打包成不同的分包，用户在使用时按需进行加载。
在构建小程序分包项目时，构建会输出一个或多个分包。每个使用分包小程序必定含有一个主包。所谓的主包，即放置默认启动页面/TabBar页面，以及一些所有分包都需用到公共资源/JS脚本；而分包则是根据开发者的配置进行划分。
在小程序启动时，默认会下载主包并启动主包内页面，当用户用户进入分包内某个页面时，客户端会把对应分包下载下来，下载完成后再进行展示。
目前小程序分包大小有以下限制：
1、整个小程序所有分包大小不超过24M
2、单个分包/主包大小不能超过2M
图解：
备注：对小程序进行分包，可以优化小程序首次启动的下载时间，以及在多团队共同开发时可以更好的解耦协作。
小程序更新机制
未启动时更新
客户端运行时，会定期检查最近使用的小程序是否有更新。如果有更新，下次小程序启动时会同步进行更新，更新到最新版本后再打开小程序，尽可能保证用户能够尽快使用小程序的最新版本，总的来说，开发者在后台发布新版本之后，无法立刻影响到所有现网用户，但最差情况下，也在发布之后24小时之内覆盖绝大多数用户。
启动时更新
即使启动前未发现更新，小程序每次冷启动时，都会异步检查是否有更新版本。如果发现有新版本，将会异步下载新版本的代码包，但当次启动仍会使用客户端本地的旧版本代码，即新版本的小程序需要等下一次冷启动才会应用上，如果需要马上应用最新版本，可以使用getUpdateManager相关API进行处理，图例如下：
五：视图层技术的演进--同层渲染
小程序视图技术演进图：
优势互补
webview渲染的那一层和Native同时存在于一层，优势互补，小程序则主要由成熟的Web技术渲染，辅之以大量的接口提供丰富的客户端原生能力，就是通过一定的技术手段把原生组件直接渲染到WebView层级上，此时原生组件层已经不存在，原生组件此时已被直接挂载到WebView节点上，如下图所示：
六：逻辑层技术的演进—双线程模型
小程序逻辑层技术演进图：
双线程模型的引入
小程序应该像Web技术那样，有一份随时可更新的资源包放在云端，通过下载到本地，动态执行后即可渲染出界面。但是，如果用纯Web技术来渲染小程序，在一些有复杂交互的页面上可能会面临一些性能问题，这是因为在Web技术中，UI渲染跟JavaScript的脚本执行都在一个单线程中执行，这就容易导致一些逻辑任务抢占UI渲染的资源。
最终，小程序采用类似于微信JSSDK这样的Hybrid技术，即界面主要由成熟的Web技术渲染，辅之以大量的接口提供丰富的客户端原生能力。同时，每个小程序页面都是用不同的WebView 去渲染，这样可以提供更好的交互体验，更贴近原生体验，也避免了单个WebView的任务过于繁重，小程序的双线程模型示意图：
