面试官的一个问题，让我深思了很久，同样是浏览器引擎为什么微信小程序没有 window？接下来我们就一同了解下微信小程序的底层，这样再回答这个问题就不难了～😄

本篇分为几个章节：

1.小程序的双线程架构设计

2.双线程对比单线程的优势在哪里

3.传统 h5 开发环境有什么弊端

一、双线程

小程序开发框架的口号是简单、高效的方式让开发者可以在微信中开发具有原生 APP 体验的服务。

小程序框架分为两部分：逻辑层（App Service）和 视图层（View）。视图层即WXML 和 WXSS，JavaScript 即逻辑层，视图层与逻辑层间的数据传输和事件系统依托于微信 app，这既是双线程。

小程序一直以来采用的都是 AppService 和 WebView 的双线程模型，基于 WebView 和原生控件混合渲染的方式，小程序优化扩展了 Web 的基础能力，保证了在移动端上有良好的性能和用户体验。Web 技术至今 30 多年历史，作为一款强大的渲染引擎，它良好兼容性和丰富的特性。 尽管各大厂商在不断优化 Web 性能，但由于其繁重的历史包袱和复杂的渲染流程，使得 Web 在移动端的表现与原生应用仍有一定差距。为了进一步优化小程序性能，提供更为接近原生的用户体验，我们在 WebView 渲染之外新增了一个渲染引擎 Skyline，其使用更精简高效的渲染管线，并带来诸多增强特性，让 Skyline 拥有更接近原生渲染的性能体验。

当小程序基于 WebView 环境下时，WebView 的 JS 逻辑、DOM 树创建、CSS 解析、样式计算、Layout、Paint (Composite) 都发生在同一线程，在 WebView 上执行过多的 JS 逻辑可能阻塞渲染，导致界面卡顿。以此为前提，小程序同时考虑了性能与安全，采用了目前称为「双线程模型」的架构。

在 Skyline 环境下，我们尝试改变这一情况：Skyline 创建了一条渲染线程来负责 Layout, Composite 和 Paint 等渲染任务，并在 AppService 中划出一个独立的上下文，来运行之前 WebView 承担的 JS 逻辑、DOM 树创建等逻辑。这种新的架构相比原有的 WebView 架构，有以下特点：

• 界面更不容易被逻辑阻塞，进一步减少卡顿

• 无需为每个页面新建一个 JS 引擎实例（WebView），减少了内存、时间开销

• 框架可以在页面之间共享更多的资源，进一步减少运行时内存、时间开销

• 框架的代码之间无需再通过 JSBridge 进行数据交换，减少了大量通信时间开销

而与此同时，这个新的架构能很好地保持和原有架构的兼容性，基于 WebView 环境的小程序代码基本上无需任何改动即可直接在新的架构下运行。WXS 由于被移到 AppService 中，虽然逻辑本身无需改动，但询问页面信息等接口会变为异步，效率也可能有所下降；为此，我们同时推出了新的 Worklet 机制，它比原有的 WXS 更靠近渲染流程，用以高性能地构建各种复杂的动画效果。

新的渲染流程如下图所示：

支持与 WebView 混合使用

小程序支持页面使用 WebView 或 Skyline 任一模式进行渲染，Skyline 页面可以和 WebView 页面混跳，开发者可以页面粒度按需适配 Skyline。

// page.json// skyline 渲染{    "renderer": "skyline"}
// webview 渲染{    "renderer": "webview"}

提供更好的性能

Skyline 在渲染流程上较 WebView 更为精简，其对节点的渲染有着更精确的控制，尽量避免不可见区域的布局和绘制，以此来保证更高的渲染性能。WebView 由于其整体设计不同以及兼容性等问题，渲染流水线的实现更加冗长复杂。

在光栅化策略上，Skyline 采用的是同步光栅化的策略，WebView 是异步分块光栅化的策略。两种策略各有千秋，但 WebView 的策略存在一些难以规避的问题，例如：快速滚动会出现白屏问题；滚动过程中的 DOM 更新会出现不同步的问题，进而影响到用户体验。

在此基础上，我们还进一步实现了很多优化点。

1. 单线程版本组件框架

Skyline 下默认启用了新版本的组件框架 glass-easel，该版本适应了 Skyline 的单线程模型，使得建树流程的耗时有效降低（优化 30%-40%），同时 setData 调用也不再有通信开销和序列化开销。

2. 组件下沉

Skyline 内置组件的行为更接近原生体验，部分内置组件（如 scroll-view、swiper 等）借助于底层实现，有更好的性能和交互体验。同时，我们将部分内置组件（如 view、text、image 等）从 JS 下沉到原生实现，相当于原生 DOM 节点，降低了创建组件的开销（优化了 30% 左右）。

3.长列表按需渲染

长列表是一个常用的但又经常遇到性能瓶颈的场景，Skyline 对其做了一些优化，使 scroll-view 组件只渲染在屏节点（用法上有一定的约束），并且增加 lazy mount 机制优化首次渲染长列表的性能，后续我们也计划在组件框架层面进一步支持 scroll-view 的可回收机制，以更大程度降低创建节点的开销。

4. WXSS 预编译

同 WebView 传输 WXSS 文本不同，Skyline 在后台构建小程序代码包时会将 WXSS 预编译为二进制文件，在运行时直接读取二进制文件获得样式表结构，避免了运行时解析的开销（预编译较运行时解析快 5 倍以上）。

5. 样式计算更快

Skyline 通过精简 WXSS 特性大幅简化了样式计算的流程。在样式更新上，与 WebView 全量计算不同，Skyline 使用局部样式更新，可以避免对 DOM 树的多次遍历。Skyline 与小程序框架结合也更为紧密，例如： Skyline 结合组件系统实现了 WXSS 样式隔离、基于 wx:for 实现了节点样式共享（相比于 WebView 推测式样式共享更为精确、高效）。在节点变更、内联样式和继承样式的更新上，Skyline 也进行了一些优化，从而保证样式计算的性能。

此外，对于 rpx 单位，我们直接在样式计算阶段原生支持，这样避免了在 JS 层面做太多额外的计算。

<!-- 样式共享目前暂未自动识别，可手动声明 list-item 属性开启 --><scroll-view type="list" scroll-y>    <view wx:for="{{list}}" list-item>{{index}}</view></scroll-view>

6. 降低内存占用

在 WebView 渲染模式下，一个小程序页面对应一个 WebView 实例，并且每个页面会重复注入一些公共资源。而 Skyline 只有 AppService 线程，且多个 Skyline 页面会运行在同一个渲染引擎实例下，因此页面占用内存能够降低很多，还能做到更细粒度的页面间资源共享（如全局样式、公共代码、缓存资源等）。

根除旧有架构的问题

在基于 Web 体系的架构下，小程序的部分基础体验会受限于 WebView 提供的能力（特别是 iOS WKWebView 限制更大一些），使得一些技术方案无法做得很完美，留下一些潜在的问题。

1. 原生组件同层渲染更稳定

iOS 下原生组件同层渲染的原理先前有介绍过，本质上是在 WKWebView 黑盒下一种取巧的实现方式，并不能完美融合到 WKWebView 的渲染流程，因此很容易在一些特殊的样式发生变化后，同层渲染会失效。在 Skyline 下可以很好地融合到渲染流程中，因此会更稳定。

2. 无需页面恢复机制

iOS 下 WKWebView 会受操作系统统一管理，当内存紧张时，操作系统就会将不在屏的 WKWebView 回收，会使得小程序除前台以外的页面丢失，虽然在页面返回时，我们对页面做了恢复，但页面的状态并不能 100% 还原。在 Skyline 下则不再有该问题。

3. 无页面栈层数限制

由于 WebView 的内存占用较大，页面层级最多有 10 层，而 Skyline 在内存方面更有优势，因此在连续 Skyline 页面跳转（复用同一引擎实例）的情况下，不再有该限制。

全新的交互动画体系

要达到类原生应用的体验，除渲染性能要好外，做好交互动画也很关键。在 Web 体系下，难以做到像素级可控，交互动画衔接不顺畅，究其原因，在于缺失了一些重要的能力。为此，Skyline 提供一套全新的交互动画能力。

1. Worklet 动画

Worklet 机制是 Skyline 交互动画体系的基础，它能够很方便地将 JavaScript 代码跑在渲染线程，那么基于 Worklet 机制的 动画模块，便能够在渲染线程同步运行动画相关逻辑，使动画不再会有延迟掉帧。

2. 手势系统

在原生应用的交互动画里，手势识别与协商是一个很重要的特性，而这块在 Web 体系下是缺失的，因此 Skyline 提供了基于 Worklet 机制的 手势系统。

• 支持常用手势的识别，如缩放、拖动、双击等，并能够渲染线程同步监听手势、执行手势相关逻辑；

• 支持手势协商处理，能够在遇到手势冲突（常见于滚动容器下）时决定让哪个手势生效，以实现更顺畅的动画衔接。

3. 自定义路由

页面间中转进行自定义的转场动画，在原生应用里也是一个很常见的交互动画。在原来的小程序架构下，每个页面都是独立的 WebView 渲染，互相隔离，其跨页能力是基本不具备的。因此，Skyline 提供了基于 Worklet 机制的 自定义路由模块，能实现市面上大多数页面转场动画效果。

4. 共享元素动画

支持 跨页面共享元素，能够很方便地将上一个页面的元素“共享”到下一个页面，并伴随着过渡动画，同时支持了一套可定制化接口，能实现自定义的过渡动画。

5. 内置组件扩展

对内置组件的扩展也是重要一环，特别是 scroll-view 组件，很多交互动画与滚动息息相关，Skyline 添加了很多在 Web 下很难做到又非常重要的特性。

• 内置下拉刷新的实现，并完善相关事件。原来 WebView 的实现基于 transform，性能不够好且动画衔接不顺畅。

• 提供“下拉二楼”交互的机制。

• 提供 sticky 吸顶组件，能很方便地实现吸顶元素交错切换。

• 使 scroll-view 组件在内容未溢出时也能滚动，让用户得到及时的交互反馈。

• 为 scroll-view 组件提供更多控制能力，如最小触发滚动距离（min-drag-distance）、滚动结束事件（scrollend）、滚动原因（isDrag）等。

• 提供原生的 swiper 实现，相比 WebView 基于 transform 的实现，性能更好。

更多的高级能力

除了交互动画的系列能力外，借助 Skyline 的优势，我们还提供了很多高级特性。

1. 提供 grid-view 瀑布流组件

瀑布流是一种常用的列表布局方式，得益于 Skyline 在布局过程中的可控性，我们直接在底层实现并提供出来，渲染性能要比 WebView 更优。

2. 提供 snapshot 截图组件

大多数小程序都会基于 canvas 实现自定义分享图的功能，一方面，需要通过 canvas 绘图指令手动实现，较为繁琐；另一方面，在分享图的布局较复杂时，或者在制作长图时会受限于系统对 canvas 尺寸限制，canvas 的方案实现成本都会很大。得益于 Skyline 在渲染过程中的可控性，Skyline 能直接对 WXML 子树进行截图，因此我们直接提供了截图组件，这样能复用更完善的 WXSS 能力，极大降低开发成本。

3. scroll-view 组件支持列表反转

在聊天对话的场景下，列表的滚动常常是反向的（往底部往上滚动），若使用正向滚动来模拟会有很多多余的逻辑，而且容易出现跳动，而 scroll-view 提供的 reverse 属性很好的解决这一问题。

还有更多计划提供出来的特性，请详见特性状态

响应的数据绑定

框架的核心是一个响应的数据绑定系统，可以让数据与视图非常简单地保持同步。当做数据修改的时候，只需要在逻辑层修改数据，视图层就会做相应的更新。

通过这个简单的例子来看：

双线程模型小程序的架构模型有别与传统 web 单线程架构，小程序为双线程架构。

微信小程序的渲染层与逻辑层分别由两个线程管理，渲染层的界面使用 webview 进行渲染；逻辑层采用 JSCore 运行 JavaScript 代码。

<!-- This is our View --><view> Hello {{name}}! </view><button bindtap="changeName"> Click me! </button>

// This is our App Service.// This is our data.var helloData = {  name: 'Weixin'}
// Register a Page.Page({  data: helloData,  changeName: function(e) {    // sent data change to view    this.setData({      name: 'MINA'    })  }})

• 开发者通过框架将逻辑层数据中的 name 与视图层的 name 进行了绑定，所以在页面一打开的时候会显示 Hello Weixin!；

• 当点击按钮的时候，视图层会发送 changeName 的事件给逻辑层，逻辑层找到并执行对应的事件处理函数；

• 回调函数触发后，逻辑层执行 setData 的操作，将 data 中的 name 从 Weixin 变为 MINA，因为该数据和视图层已经绑定了，从而视图层会自动改变为 Hello MINA!。

页面管理

框架 管理了整个小程序的页面路由，可以做到页面间的无缝切换，并给以页面完整的生命周期。开发者需要做的只是将页面的数据、方法、生命周期函数注册到 框架 中，其他的一切复杂的操作都交由 框架 处理。

基础组件

框架 提供了一套基础的组件，这些组件自带微信风格的样式以及特殊的逻辑，开发者可以通过组合基础组件，创建出强大的微信小程序 。

丰富的 API

框架 提供丰富的微信原生 API，可以方便的调起微信提供的能力，如获取用户信息，本地存储，支付功能等。

二、双线程与单线程对比

单线程架构，即传统html开发的时候，官方建议script加载js的时候放在Body下方位置。为什么建议在下方插入 script 呢，就是因为单线程阻塞问题。因为 html 文件是从上到下渲染的，如果中间插入 js 的话，则会中断 HTML 节点渲染，转而去执行 js，js 执行完后继续渲染节点。就是因为单线程阻塞问题才建议在下方插入 script，并且配合 window.onload 可以拿到已经渲染完成的节点。

这种情况当然也可以通过一些手段来规避，比如 async、defer 等。这两个属性加上后，虽然不会阻塞 DOM 渲染，但是并不是根本上解决问题，而是合理地安排了资源解析而已。

单线程阻塞问题还没结束，另一个问题又扑面而来。如果所有资源都是通过请求来获取，那么不光会阻塞 js 解析的时间，还要加上 js 请求的时长。请求 js 资源时间不可控，怎么办呢。这个时候另一种选择就至关重要，就是缓存。微信中这一点做的很好，就是 WXSDK，微信 SDK 是一系列 jsApi 的集合，提供了微信的丰富原生能力和微信内部的方法。

在曾经开发微信公众号 h5 的时候我们需要手动的注入某个版本的微信 SDK 到自身的项目中去，这种方式的用户体验并不是很好，因为加载 js，并且解析 js 逻辑的时候是会抢占渲染资源的，原因也就是上面刚讲过的单线程阻塞问题，如果在我们有承接平台的时候，比如微信客户端，将微信 SDK 这样的资源放在客户端 Native 中，在加载页面的时候再进行动态的注入，由 Native 层注入到视图层。这样的做法的好处很明显，首先会使包的体积变小，其次，减少了网络请求的发送。

小程序中也用到了微信 SDK，当然不仅仅只有微信 SDK 做了这样的处理，由 Native 层注入到双线程中。还有底层基础库、Service 等都是事先放在 Native 层中的，当页面进行加载的时候再进行动态的注入。好比如说公司里给你配了一台电脑来开发项目一样，曾经工作人员都需要自己带着自身的开发工具去公司上班，如果公司统一配好了开发工具，那么你再也不用带着电脑去公司上班了，减少了每个员工为工作需要提前准备的资源。

可以看出，双线程的好处不仅仅是一分为二而已，还有强大的 Native 层做背后支撑。Native 层除了做一些资源的动态注入，还负责着很多的事情，请求的转发，离线存储，组件渲染等等。界面主要由成熟的 Web 技术渲染，辅之以大量的接口提供丰富的客户端原生能力。同时，每个小程序页面都是用不同的 WebView 去渲染，这样可以提供更好的交互体验，更贴近原生体验，也避免了单个 WebView 的任务过于繁重。此外，界面渲染这一块还定义了一套内置组件以统一体验，并且提供一些基础和通用的能力，进一步降低开发者的学习门槛。值得一提的是，内置组件有一部分较复杂组件是用客户端原生渲染的，以提供更好的性能。

三、传统 h5 开发的弊端

Web 技术来渲染小程序是存在一些不可控因素和安全风险的。这是因为 Web 技术是非常开放灵活的，我们可以利用 JavaScript 脚本随意地跳转网页或者改变界面上的任意内容。这个时候安全问题摆到了微信团队的台面上。如果微信小程序可以离线浏览，只需要小程序开发者把一些应用数据缓存到本地，然后通过 javascript 脚本把小程序渲染的 webview 跳转到其他的在线网页，那么这个体验就非常的糟糕。想必前端开发者会非常熟悉这个操作。

除此之外，javascript 还可以通过操作 DOM，直接获取小程序内部的一些敏感数据，比如用户的信息，商家信息等等，那么小程序将毫无安全可言。

为了解决安全管控问题，小程序阻止开发者使用一些浏览器提供的比如跳转页面、操作 DOM、动态执行脚本的开放性接口。如果这些东西一个一个地去禁用，那么势必会进入一个糟糕的循环，因为 javascript 实在是太灵活了，浏览器的接口也太丰富了，很容易就遗漏一些危险的接口，而且就算是禁用掉了所有感觉到危险的接口，也势必防不住浏览器内核的下次更新。指不定又会出现一些漏洞。

因此，要彻底解决这个问题，必须提供一个沙箱环境来运行开发者的 JavaScript 代码。这个沙箱环境不能有任何浏览器相关接口，只提供纯 JavaScript 的解释执行环境，那么像 HTML5 中的 ServiceWorker、WebWorker 特性就符合这样的条件，这两者都是启用另一线程来执行 javaScript。但是考虑到小程序是一个多 webView 的架构，每一个小程序页面都是不同的 webView 渲染后显示的，在这个架构下不好去用某个 webView 中的 ServiceWorker 去管理所有的小程序页面。

四、后序

小程序逻辑层 App Service

小程序开发框架的逻辑层使用 JavaScript 引擎为小程序提供开发 JavaScript 代码的运行环境以及微信小程序的特有功能。

逻辑层将数据进行处理后发送给视图层，同时接受视图层的事件反馈。

开发者写的所有代码最终将会打包成一份 JavaScript 文件，并在小程序启动的时候运行，直到小程序销毁。这一行为类似 ServiceWorker，所以逻辑层也称之为 App Service。

在 JavaScript 的基础上，我们增加了一些功能，以方便小程序的开发：

• 增加 App 和 Page 方法，进行程序注册和页面注册。

• 增加 getApp 和 getCurrentPages 方法，分别用来获取 App 实例和当前页面栈。

• 提供丰富的 API，如微信用户数据，扫一扫，支付等微信特有能力。

• 提供模块化能力，每个页面有独立的作用域。

注意：小程序框架的逻辑层并非运行在浏览器中，因此 JavaScript 在 web 中一些能力都无法使用，如 window，document 等。

小程序的运行环境

微信小程序运行在多种平台上：iOS/iPadOS 微信客户端、Android 微信客户端、Windows PC 微信客户端、Mac 微信客户端、小程序硬件框架和用于调试的微信开发者工具等。

不同运行环境下，脚本执行环境以及用于组件渲染的环境是不同的，性能表现也存在差异：

• 在 iOS、iPadOS 和 Mac OS 上，小程序逻辑层的 JavaScript 代码运行在 JavaScriptCore 中，视图层是由 WKWebView 来渲染的，环境有 iOS 14、iPad OS 14、Mac OS 11.4 等；

• 在 Android 上，小程序逻辑层的 JavaScript 代码运行在 V8 中，视图层是由基于 Mobile Chromium 内核的微信自研 XWeb 引擎来渲染的；

• 在 Windows 上，小程序逻辑层 JavaScript 和视图层都是用 Chromium 内核；

• 在 开发工具上，小程序逻辑层的 JavaScript 代码是运行在 NW.js 中，视图层是由 Chromium Webview 来渲染的。

JavaScriptCore 无法开启 JIT 编译 (Just-In-Time Compiler)，同等条件下的运行性能要明显低于其他平台。

平台差异

尽管各运行环境是十分相似的，但是还是有些许区别：

• JavaScript 语法和 API 支持不一致：语法上开发者可以通过开启 ES6 转 ES5 的功能来规避（详情）；此外，小程序基础库内置了必要的 Polyfill，来弥补 API 的差异（详情)。

• WXSS 渲染表现不一致：尽管可以通过开启样式补全来规避大部分的问题，还是建议开发者需要在各端分别检查小程序的真实表现。

开发者工具仅供调试使用，最终的表现以客户端为准

javaScript 支持情况

运行限制

基于安全考虑，小程序中不支持动态执行 JS 代码，即：

• 不支持使用 eval 执行 JS 代码

• 不支持使用 new Function 创建函数new Function('return this') 除外

标准 ECMAScript 支持

小程序的 JS 执行环境 在不同平台上的执行环境存在差异，因此导致不同平台对 ECMAScript 标准的支持存在差异。

小程序基础库为了尽量抹平这些差异，内置了一份 core-js Polyfill。core-js 可以将平台环境缺失的标准 API 补齐。

需要注意的是，平台对 ECMAScript 语法的支持差异无法抹平，当你需要使用一些高级语法时，如 async/await 时，则需要借助 代码转换工具 来支持这些语法。

无法被 Polyfill 的 API

以下 API 在部分低版本客户端中无法使用，请注意尽量避免使用

• Proxy 对象

与标准的差异

Promise 时序差异

由于实现原因与 iOS JavaScriptCore 限制，iOS 环境下的 Promise 是一个使用 setTimeout 模拟的 Polyfill。这意味着 Promise 触发的任务为普通任务，而非微任务，进而导致 在 iOS 下的 Promise 时序会和标准存在差异。

var arr = []
setTimeout(() => arr.push(6), 0)arr.push(1)const p = new Promise(resolve => {  arr.push(2)  resolve()})arr.push(3)p.then(() => arr.push(5))arr.push(4)setTimeout(() => arr.push(7), 0)
setTimeout(() => {  // 应该输出 [1,2,3,4,5,6,7]  // 在 iOS 小程序环境，这里会输出 [1,2,3,4,6,5,7]  console.log(arr)}, 1000)

关于普通任务和微任务的区别可以查看这篇文章

如何判断当前环境需要哪些 Polyfill & 代码转换目标

特定的小程序基础库版本有最低微信客户端版本要求，如基础库 v2.15.0 要求安卓最低版本 7.0.22，iOS 最低版本 7.0.20。

而特定的客户端版本有最低操作系统版本要求，如 iOS 7.0.20 要求最低 iOS 10。

从而，当指定特定小程序基础库版本时（可以在 小程序管理页 【设置】-【基本设置】-【基础库最低版本设置】中设置），我们能够得到最低需要支持的执行环境。

具体数据可以从 这个开源库 中获得。

小程序运行机制

1. 小程序的生命周期

小程序从启动到最终被销毁，会经历很多不同的状态，小程序在不同状态下会有不同的表现。

1.1 小程序启动

从用户认知的角度看，广义的小程序启动可以分为两种情况，一种是冷启动，一种是热启动。

• 冷启动：如果用户首次打开，或小程序销毁后被用户再次打开，此时小程序需要重新加载启动，即冷启动。

• 热启动：如果用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时小程序并未被销毁，只是从后台状态进入前台状态，这个过程就是热启动。

从小程序生命周期的角度来看，我们一般讲的「启动」专指冷启动，热启动一般被称为后台切前台。

1.2 前台与后台

小程序启动后，界面被展示给用户，此时小程序处于「前台」状态。

当用户「关闭」小程序时，小程序并没有真正被关闭，而是进入了「后台」状态，此时小程序还可以短暂运行一小段时间，但部分 API 的使用会受到限制。切后台的方式包括但不限于以下几种：

• 点击右上角胶囊按钮离开小程序

• iOS 从屏幕左侧右滑离开小程序

• 安卓点击返回键离开小程序

• 小程序前台运行时直接把微信切后台（手势或 Home 键）

• 小程序前台运行时直接锁屏

当用户再次进入微信并打开小程序，小程序又会重新进入「前台」状态。

1.3 挂起

小程序进入「后台」状态一段时间后（目前是 5 秒），微信会停止小程序 JS 线程的执行，小程序进入「挂起」状态。此时小程序的内存状态会被保留，但开发者代码执行会停止，事件和接口回调会在小程序再次进入「前台」时触发。

当开发者使用了后台音乐播放、后台地理位置等能力时，小程序可以在「后台」持续运行，不会进入到「挂起」状态

1.4 小程序销毁

如果用户很久没有使用小程序，或者系统资源紧张，小程序会被「销毁」，即完全终止运行。具体而言包括以下几种情形：

• 当小程序进入后台并被「挂起」后，如果很长时间（目前是 30 分钟）都未再次进入前台，小程序会被销毁。

• 当小程序占用系统资源过高，可能会被系统销毁或被微信客户端主动回收。在 iOS 上，当微信客户端在一定时间间隔内连续收到系统内存告警时，会根据一定的策略，主动销毁小程序，并提示用户 「运行内存不足，请重新打开该小程序」。具体策略会持续进行调整优化。建议小程序在必要时使用 wx.onMemoryWarning 监听内存告警事件，进行必要的内存清理。

基础库 1.1.0 及以上，1.4.0 以下版本: 当用户从扫一扫、转发等入口（场景值为 1007, 1008, 1011, 1025）进入小程序，且没有置顶小程序的情况下退出，小程序会被销毁。

2. 小程序冷启动的页面

小程序冷启动时，打开的页面有以下情况

• （A 类场景）若启动的场景中不带 path 基础库 2.8.0 以下版本，进入首页基础库 2.8.0 及以上版本遵循「重新启动策略」，可能是首页或上次退出的页面

• （B 类场景）若启动的场景中带有 path，则启动进入对应 path 的页面

2.1 重新启动策略

基础库 2.8.0 开始支持，低版本需做兼容处理。

小程序冷启动时，如果启动时不带 path（A 类场景），默认情况下将会进入小程序的首页。 在页面对应的 json 文件中（也可以全局配置在 app.json 的 window 段中），指定 restartStrategy 配置项可以改变这个默认的行为，使得从某个页面退出后，下次 A 类场景的冷启动可以回到这个页面。

代码示例：

{  "restartStrategy": "homePage"}

restartStrategy 可选值：

注意：即使不配置为 homePage ，小程序如果退出过久（当前默认一天时间，可以使用退出状态来调整），下次冷启动时也将不再遵循 restartStrategy 的配置，而是直接从首页冷启动。

无论如何，页面中的状态并不会被保留，如输入框中的文本内容、 checkbox 的勾选状态等都不会还原。如果需要还原或部分还原，需要利用退出状态。

3. 小程序热启动的页面

小程序热启动时，打开的页面有以下情况

• （A 类场景）若启动的场景中不带 path，则保留上次的浏览的状态

• （B 类场景）若启动的场景中带有 path，则 reLaunch 到对应 path 的页面

A 类场景常见的有下列场景值：

4. 退出状态

基础库 2.7.4 开始支持，低版本需做兼容处理。

每当小程序可能被销毁之前，页面回调函数 onSaveExitState 会被调用。如果想保留页面中的状态，可以在这个回调函数中“保存”一些数据，下次启动时可以通过 exitState 获得这些已保存数据。

代码示例：

{  "restartStrategy": "homePageAndLatestPage"}

Page({  onLoad: function() {    var prevExitState = this.exitState // 尝试获得上一次退出前 onSaveExitState 保存的数据    if (prevExitState !== undefined) { // 如果是根据 restartStrategy 配置进行的冷启动，就可以获取到      prevExitState.myDataField === 'myData'     }  },  onSaveExitState: function() {    var exitState = { myDataField: 'myData' } // 需要保存的数据    return {      data: exitState,      expireTimeStamp: Date.now() + 24 * 60 * 60 * 1000 // 超时时刻    }  }})

onSaveExitState 返回值可以包含两项：

一个更完整的示例：在开发者工具中预览效果

注意事项

• 如果超过 expireTimeStamp ，保存的数据将被丢弃，且冷启动时不遵循 restartStrategy 的配置，而是直接从首页冷启动。

• expireTimeStamp 有可能被自动提前，如微信客户端需要清理数据的时候。

• 在小程序存活期间， onSaveExitState 可能会被多次调用，此时以最后一次的调用结果作为最终结果。

• 在某些特殊情况下（如微信客户端直接被系统杀死），这个方法将不会被调用，下次冷启动也不遵循 restartStrategy 的配置，而是直接从首页冷启动。

参考：

• 关于腾讯
  

•  文档中心 辟谣中心 客服中心