微信“应该”是最近开放了 schema 跳转小程序 的能力，大大方便了短信、邮件、外部网页等唤起微信小程序。 schema 链接格式大体是这样：[代码]weixin://dl/business/?ticket=l69894d682fa8dbafe724a0ca3950741e[代码]，但是这段文本在安卓端无法识别。小规模测试结果如下： [图片] 后来想到用一个正常能够识别的网页地址，内容是重定向到指定的 schema 链接。这就是擅长的领域了，query 参数上带上 schema 链接，location.href 一下不就行了。这里就不 show 代码了，能看到文章的你一定行。 但是，发现在部分安卓手机下（如小米）还是没反应，原来简单的 schema 跳转水这么深的，于是百度谷歌了一下，找到了下面两份关键材料： H5唤起APP进行分享的尝试 AlanZhang001/H5CallUpNative: H5端唤醒移动客户端程序 看源码也不多，总结下来，因不同系统和浏览器对 schema 规范的理解不同，还有一些商业因素，不同环境下面需要用不同的方式进行跳转，甚至有的环境你根本就跳不了。 时间紧，任务重。简单处理吧，不同方式都来一遍，谁好使就用谁。所以简单总结了下，能用的几种方式： location 跳转 a 链接跳转 iframe 跳转 以上三种方式，逐一试用，最后实在不行就不行吧，简单处理，看有没有大神补充的。 相关代码如下： location [代码]location.href = "weixin://dl/business/?ticket=l69894d682fa8dbafe724a0ca3950741e"; [代码] a 链接跳转 [代码]var aLink = document.createElement("a"); aLink.className = 'call_up_a_link'; aLink.href = "weixin://dl/business/?ticket=l69894d682fa8dbafe724a0ca3950741e"; aLink.style.cssText = "display:none;width:0px;height:0px;"; document.body.appendChild(aLink); aLink.click(); [代码] iframe [代码]var iframe = document.createElement('iframe'); iframe.className = 'call_up_iframe'; iframe.src = "weixin://dl/business/?ticket=l69894d682fa8dbafe724a0ca3950741e"; iframe.style.cssText = "display:none;width:0px;height:0px;"; document.body.appendChild(iframe); [代码] 以上代码均可从参考资料中找到出处，感谢 是直接一进来就执行，还是事件触发，都可以。或者是一开始进来就执行，失败了显示几个可选跳转按钮让用户手动触发跳转。 但是关键问题还有一个，如何判断是可以成功唤起了呢？上述 github 代码里提到了一个根据页面 hidden 状态，但不够精准，如果用户没有选择跳转到微信呢？这是另一个需要深究的问题。 出于时间考虑，先以业务交付优先，如果有朋友知道的也可以一起讨论下。 另行文时间短，以技术交流为主，若有瑕疵，欢迎指出。 附上 vue 版本源码：微信 schema 跳转 参考链接： 微信官方文档：urlscheme.generate H5唤起APP进行分享的尝试 AlanZhang001/H5CallUpNative: H5端唤醒移动客户端程序 安卓端，微信schema无法跳转微信小程序？

这个是正常现象，因为 iOS 下加了 -webkit-overflow-scrolling: touch，这个会产生滚动惯性，体验更好，但会改变 fixed 的行为，建议不在 scroll-view 里有 fixed 元素

1、官方文档上说 wx.onError 和 App.onError 的回调时机与参数一致（https://developers.weixin.qq.com/miniprogram/dev/api/base/app/app-event/wx.onError.html），是指两种方式收集到的异常信息完全一致吗？我们实践过程中发现，wx.onError 获取到的信息比 App.onError 要少。 在我们上一个版本的微信小程序中，我们是在 App.onError 中监控异常，并通过 ELK 收集、查询异常。收集到的部分异常信息截图如下： [图片] [图片] 在我们小程序的最新版本中，我们使用了针对小程序平台的 Sentry SDK（https://github.com/lizhiyao/sentry-miniapp，该 SDK 原理是使用 wx.onError、wx.onPageNotFound、wx.onMemoryWarning 监控异常信息）进行信息收集上报，基于公司私有化部署的 Sentry 服务接收、存储、展示异常信息。结果发现 Sentry 服务没有收到 wx.onError 上报的异常（1. 上线之前有做过测试，Sentry SDK 是可以正常上报代码执行异常的。 2. 可以收集到页面无法找到、内存警告异常，说明线上版本小程序中 Sentry SDK 已经成功初始化，可以进行信息上报）： [图片] 但是官方的微信预警群是有推送异常信息的： [图片] [图片] [图片] 2. App.onError 收集到的信息和官方后台运维中心收集到的信息是一致的吗？我们发现 onError 捕获的信息，在小程序官方后台查不到。 比如： 通过 App.onError 在 8.12 收集到了这样一条异常信息： [图片] 在小程序官方后台是搜不到这个异常信息记录的： [图片] 3. 假设 wx.onError 和 App.onError 获取到的异常信息完全一致，且和官方后台收集记录的异常信息完全一致。如果小程序后台运维中心的预警推送频率设置为 1次/5min，那么 onError 获取到的信息和微信预警群推送的信息完全一致吗？ 4. 关于 Promise 的异常，对于浏览器有 window.onunhandledrejection，对于 node 有 global.process.on('unhandledRejection', callback())，对于小程序平台，有什么推荐的方式可以获取到 Promise 的异常吗？官方后台运维中心有收集到小程序中 Promise 中的异常吗？目前实践来看，小程序的 App.onError、wx.onError 中是无法捕获 Promise 的异常的。示例代码可参考：https://github.com/lizhiyao/sentry-miniapp/blob/master/examples/weapp/app.js 。 5. 在小程序官方后台及官方预警群中，会发现偶尔会出现非线上版本的异常被收集和上报了。请问这种情况是正常的吗？ 比如：截图中 小程序版本对应为 0 的就是我们未发布版本代码中出现的异常。判断的依据是 /pages/homepage-config/skilled-tag/index 是新版本新增的页面，异常上报时新版本并未发布。 [图片]

文件系统能力 文件系统能力可便于用户在客户端保存文件资源，并在下次启动客户端之后可以使用已保存的文件。 只要用户不主动删除小程序或小游戏，并保持一定的使用频率，文件都可以一直被保留。 合理的使用文件系统能力来缓存资源文件，可以给开发者更好的使用体验。 今天，我们来分享文件系统能力的小故事。 1 文件系统的演进历史 小程序在最早发布的版本中就已提供了最基础的文件存储和删除接口：wx.saveFile、 wx.removeSavedFile ； 对于绝大部分的小程序来说，这两个接口已经能够满足开发者的需求。但对于小游戏来说，需要更完整的能力来做支撑。 因此，发布小游戏的时候我们便提供了一套更完整的文件管理系统：FileSystemManager，其中主要包含了目录管理、文件内容读写等能力。 2 文件系统的设计背景 文件系统能力是应小游戏开发需求的迭代而逐步增强的。在小程序的场景下，很多时候只是需要把一个图片或视频资源缓存起来便可继续使用，文件内容与文件存储的目录结构都不是开发者所关心的。 但是在小游戏场景下情况则不同—— 一方面，小游戏除了有图片和视频文件、还有游戏引擎生成的配置文件，游戏需要能够去读取并理解配置文件的具体内容； 另一方面，游戏使用的资源文件会比普通小程序更多，若没有内容目录管理的功能，维护成本会变高。 除此之外，由于小游戏代码包大小限制只有4MB (加上分包最多8MB)，对于一些偏重的游戏，资源甚至容易超100MB。 因此在此大背景下，我们给文件系统主要增加了目录管理、文件内容读写等两项接口—— 目录管理的需求场景是在使用游戏引擎时需要按目录来管理资源文件，文件内容读写的需求场景是在使用游戏引擎时需要读取配置文件；同时，我们对小游戏类目的本地存储容量的规范限制扩容到50MB。 开发者可能会疑惑，为什么在小程序的文件系统中会有一些功能相接近的接口？例如，想缓存一个文件，可以用 saveFile 或 copyFile ；再比如 removeSavedFile和 unlink 都可以用来删除一个文件。 上述情况的原因是我们在早期便提供了基础的文件存储接口 saveFile 和removeFile ，但不提供自定义目录相关的能力，开发者调用 saveFile 之后只能得到微信返回到的一个随机文件名。 小游戏应运而生的同时也增强了对文件系统能力扩展的需求，为了保证向后兼容，我们保留了这批基础接口，并在这个基础上增加了目录管理接口以及对应的文件操作接口。因此，便出现了上述一些相似接口的情况。 3 文件系统的优势—存储隔离 有不少开发者询问过关于文件存储的问题，他们担心文件内容被其他小程序读取到，也担心多个登录用户之间的文件内容会互相影响。为了保证用户的隐私安全，也为了保证小程序的数据安全，本地文件存储的一个重要规则便是保证隔离。 文件被存储到本地后，会以小程序账号和用户账号两个不同的维度来区分和隔离。即：同个微信用户使用不同小程序之间的文件存储会互相隔离；不同微信用户（在同一台手机中）使用同个小程序时，不同用户间的文件存储也会互相隔离。 [图片] 4 适当的存储容量 考虑到存储的问题，我们规范了小游戏文件存储的容量。普通小程序是10MB，小游戏则是50MB，当文件存储超出限制时，写入的文件会失败。 功能上线以后，我们曾收到过若干宝贵意见与反馈，希望能提高容量限制。但在经过反复论证与评估后，我们认为如果将文件存储的容量再往上提，就会有用户新增需要管理或清理手机存储空间的需求，小程序和小游戏将会变得不再“小”了。对于资源文件超过上述标准限制的小程序与小游戏，应该合理地管理本地文件，及时清理不常用的文件，这样在大多数情况下，手机存储空间便能保证顺畅。 更多关于小程序文件系统能力的信息，可查阅 接口文档 。

摘要： 理解小程序原理… 原文：浅谈小程序运行机制 作者：小白 Fundebug经授权转载，版权归原作者所有。 写作背景 接触小程序有一段时间了，总得来说小程序开发门槛比较低，但其中基本的运行机制和原理还是要懂的。“比如我在面试的时候问到一个关于小程序的问题，问小程序有window对象吗？他说有吧”，但其实是没有的。感觉他并没有了解小程序底层的一些东西，归根结底来说应该只能算会使用这个工具，但并不明白其中的道理。 小程序与普通网页开发是有很大差别的，这就要从它的技术架构底层去剖析了。还有比如习惯Vue，react开发的开发者会吐槽小程序新建页面的繁琐，page必须由多个文件组成、组件化支持不完善、每次更改 data 里的数据都得setData、没有像Vue方便的watch监听、不能操作Dom，对于复杂性场景不太好，之前不支持npm，不支持sass，less预编译处理语言。 “有的人说小程序就像被阉割的Vue”，哈哈当然了，他们从设计的出发点就不同，咱也得理解小程序设计的初衷，通过它的使用场景，它为什么采用这种技术架构，这种技术架构有什么好处，相信在你了解完这些之后，就会理解了。下面我会从以下几个角度去分析小程序的运行机制和它的整体技术架构。 了解小程序的由来 在小程序没有出来之前，最初微信WebView逐渐成为移动web重要入口，微信发布了一整套网页开发工具包，称之为 JS-SDK，给所有的 Web 开发者打开了一扇全新的窗户，让所有开发者都可以使用到微信的原生能力，去完成一些之前做不到或者难以做到的事情。 但JS-SDK 的模式并没有解决使用移动网页遇到的体验不良的问题，比如受限于设备性能和网络速度，会出现白屏的可能。因此又设计了一个增强版JS-SDK，也就是“微信 Web 资源离线存储”，但在复杂的页面上依然会出现白屏的问题，原因表现在页面切换的生硬和点击的迟滞感。这个时候需要一个 JS-SDK 所处理不了的，使用户体验更好的一个系统，小程序应运而生。 快速的加载 更强大的能力 原生的体验 易用且安全的微信数据开放 高效和简单的开发 小程序与普通网页开发的区别 小程序的开发同普通的网页开发相比有很大的相似性，小程序的主要开发语言也是 JavaScript，但是二者还是有些差别的。 普通网页开发可以使用各种浏览器提供的 DOM API，进行 DOM 操作，小程序的逻辑层和渲染层是分开的，逻辑层运行在 JSCore 中，并没有一个完整浏览器对象，因而缺少相关的DOM API和BOM API。 普通网页开发渲染线程和脚本线程是互斥的，这也是为什么长时间的脚本运行可能会导致页面失去响应，而在小程序中，二者是分开的，分别运行在不同的线程中。 网页开发者在开发网页的时候，只需要使用到浏览器，并且搭配上一些辅助工具或者编辑器即可。小程序的开发则有所不同，需要经过申请小程序帐号、安装小程序开发者工具、配置项目等等过程方可完成。 小程序的执行环境 [图片] 小程序架构 一、技术选型 一般来说，渲染界面的技术有三种： 用纯客户端原生技术来渲染 用纯 Web 技术来渲染 用客户端原生技术与 Web 技术结合的混合技术（简称 Hybrid 技术）来渲染 通过以下几个方面分析，小程序采用哪种技术方案 开发门槛：Web 门槛低，Native 也有像 RN 这样的框架支持 体验：Native 体验比 Web 要好太多，Hybrid 在一定程度上比 Web 接近原生体验 版本更新：Web 支持在线更新，Native 则需要打包到微信一起审核发布 管控和安全：Web 可跳转或是改变页面内容，存在一些不可控因素和安全风险 由于小程序的宿主环境是微信，如果用纯客户端原生技术来编写小程序，那么小程序代码每次都需要与微信代码一起发版，这种方式肯定是不行的。 所以需要像web技术那样，有一份随时可更新的资源包放在云端，通过下载到本地，动态执行后即可渲染出界面。如果用纯web技术来渲染小程序，在一些复杂的交互上可能会面临一些性能问题，这是因为在web技术中，UI渲染跟JavaScript的脚本执行都在一个单线程中执行，这就容易导致一些逻辑任务抢占UI渲染的资源。 所以最终采用了两者结合起来的Hybrid 技术来渲染小程序，可以用一种近似web的方式来开发，并且可以实现在线更新代码，同时引入组件也有以下好处： 扩展 Web 的能力。比如像输入框组件（input, textarea）有更好地控制键盘的能力 体验更好，同时也减轻 WebView 的渲染工作 绕过 setData、数据通信和重渲染流程，使渲染性能更好 用客户端原生渲染内置一些复杂组件，可以提供更好的性能 二、双线程模型 小程序的渲染层和逻辑层分别由 2 个线程管理：视图层的界面使用了 WebView 进行渲染，逻辑层采用 JsCore 线程运行 JS脚本。 [图片] [图片] 那么为什么要这样设计呢，前面也提到了管控和安全，为了解决这些问题，我们需要阻止开发者使用一些，例如浏览器的window对象，跳转页面、操作DOM、动态执行脚本的开放性接口。 我们可以使用客户端系统的 JavaScript 引擎，iOS 下的 JavaScriptCore 框架，安卓下腾讯 x5 内核提供的 JsCore 环境。 这个沙箱环境只提供纯 JavaScript 的解释执行环境，没有任何浏览器相关接口。 这就是小程序双线程模型的由来： 逻辑层：创建一个单独的线程去执行 JavaScript，在这里执行的都是有关小程序业务逻辑的代码，负责逻辑处理、数据请求、接口调用等 视图层：界面渲染相关的任务全都在 WebView 线程里执行，通过逻辑层代码去控制渲染哪些界面。一个小程序存在多个界面，所以视图层存在多个 WebView 线程 JSBridge 起到架起上层开发与Native（系统层）的桥梁，使得小程序可通过API使用原生的功能，且部分组件为原生组件实现，从而有良好体验 三、双线程通信 把开发者的 JS 逻辑代码放到单独的线程去运行，但在 Webview 线程里，开发者就没法直接操作 DOM。 那要怎么去实现动态更改界面呢？ 如上图所示，逻辑层和试图层的通信会由 Native （微信客户端）做中转，逻辑层发送网络请求也经由 Native 转发。 这也就是说，我们可以把 DOM 的更新通过简单的数据通信来实现。 Virtual DOM 相信大家都已有了解，大概是这么个过程：用 JS 对象模拟 DOM 树 -> 比较两棵虚拟 DOM 树的差异 -> 把差异应用到真正的 DOM 树上。 如图所示： [图片] 1. 在渲染层把 WXML 转化成对应的 JS 对象。 2. 在逻辑层发生数据变更的时候，通过宿主环境提供的 setData 方法把数据从逻辑层传递到 Native，再转发到渲染层。 3. 经过对比前后差异，把差异应用在原来的 DOM 树上，更新界面。 我们通过把 WXML 转化为数据，通过 Native 进行转发，来实现逻辑层和渲染层的交互和通信。 而这样一个完整的框架，离不开小程序的基础库。 四、小程序的基础库 小程序的基础库可以被注入到视图层和逻辑层运行，主要用于以下几个方面： 在视图层，提供各类组件来组建界面的元素 在逻辑层，提供各类 API 来处理各种逻辑 处理数据绑定、组件系统、事件系统、通信系统等一系列框架逻辑 由于小程序的渲染层和逻辑层是两个线程管理，两个线程各自注入了基础库。 小程序的基础库不会被打包在某个小程序的代码包里边，它会被提前内置在微信客户端。 这样可以： 降低业务小程序的代码包大小 可以单独修复基础库中的 Bug，无需修改到业务小程序的代码包 五、Exparser 框架 Exparser是微信小程序的组件组织框架，内置在小程序基础库中，为小程序的各种组件提供基础的支持。小程序内的所有组件，包括内置组件和自定义组件，都由Exparser组织管理。 Exparser的主要特点包括以下几点： 基于Shadow DOM模型：模型上与WebComponents的ShadowDOM高度相似，但不依赖浏览器的原生支持，也没有其他依赖库；实现时，还针对性地增加了其他API以支持小程序组件编程。 可在纯JS环境中运行：这意味着逻辑层也具有一定的组件树组织能力。 高效轻量：性能表现好，在组件实例极多的环境下表现尤其优异，同时代码尺寸也较小。 小程序中，所有节点树相关的操作都依赖于Exparser，包括WXML到页面最终节点树的构建、createSelectorQuery调用和自定义组件特性等。 内置组件 基于Exparser框架，小程序内置了一套组件，提供了视图容器类、表单类、导航类、媒体类、开放类等几十种组件。有了这么丰富的组件，再配合WXSS，可以搭建出任何效果的界面。在功能层面上，也满足绝大部分需求。 六、运行机制 小程序启动会有两种情况，一种是「冷启动」，一种是「热启动」。假如用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需将后台状态的小程序切换到前台，这个过程就是热启动；冷启动指的是用户首次打开或小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动。 小程序没有重启的概念 当小程序进入后台，客户端会维持一段时间的运行状态，超过一定时间后（目前是5分钟）会被微信主动销毁 当短时间内（5s）连续收到两次以上收到系统内存告警，会进行小程序的销毁 [图片] 七、更新机制 小程序冷启动时如果发现有新版本，将会异步下载新版本的代码包，并同时用客户端本地的包进行启动，即新版本的小程序需要等下一次冷启动才会应用上。 如果需要马上应用最新版本，可以使用 wx.getUpdateManager API 进行处理。 八、性能优化 主要的优化策略可以归纳为三点： 精简代码，降低WXML结构和JS代码的复杂性； 合理使用setData调用，减少setData次数和数据量； 必要时使用分包优化。 1、setData 工作原理 小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再通过执行 JS 脚本的形式传递到两边独立环境。 而 evaluateJavascript 的执行会受很多方面的影响，数据到达视图层并不是实时的。 2、常见的 setData 操作错误 频繁的去 setData在我们分析过的一些案例里，部分小程序会非常频繁（毫秒级）的去setData，其导致了两个后果：Android下用户在滑动时会感觉到卡顿，操作反馈延迟严重，因为 JS 线程一直在编译执行渲染，未能及时将用户操作事件传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层；渲染有出现延时，由于 WebView 的 JS 线程一直处于忙碌状态，逻辑层到页面层的通信耗时上升，视图层收到的数据消息时距离发出时间已经过去了几百毫秒，渲染的结果并不实时； 每次 setData 都传递大量新数据由setData的底层实现可知，我们的数据传输实际是一次 evaluateJavascript 脚本过程，当数据量过大时会增加脚本的编译执行时间，占用 WebView JS 线程， 后台态页面进行 setData当页面进入后台态（用户不可见），不应该继续去进行setData，后台态页面的渲染用户是无法感受的，另外后台态页面去setData也会抢占前台页面的执行。 总结 大致从以上几个角度分析了小程序的底层架构，从小程序的由来、到双线程的出现、设计、通信、到基础库、Exparser 框架、再到运行机制、性能优化等等，都是一个个相关而又相互影响的选择。关于小程序的底层框架设计，其实涉及到的还有很多，比如自定义组件，原生组件、性能优化等方面，都不是一点能讲完的，还要多看源码，多思考。每一个框架的诞生都有其意义，我们作为开发者能做的不只是会使用这个工具，还应理解它的设计模式。只有这样才不会被工具左右，才能走的更远！