为了进一步提升小程序的渲染性能和体验，我们推出了一套新渲染引擎 Skyline，现在，跟随着基础库 3.0.0 发布 Skyline 正式版。 我们知道，小程序一直用 WebView 来渲染界面，因其有不错的兼容性和丰富的特性，且各大厂商也在不断优化 Web 的渲染性能，但 Web 体系相比于原生开发，在性能上仍然有较大差距，并且特性上发展缓慢，使得小程序很难做出类原生的体验。因此，我们开发了一套新渲染引擎 Skyline，旨在替代 WebView 作为小程序的渲染层，以提供更优秀的渲染性能和诸多增强特性，让小程序能达到原生的体验。 以下为你全方位介绍 Skyline 的特点。 提供更好的性能 在渲染流程上，WebView 因其需要向后兼容，积累了较多历史包袱，加之整体设计目标不同，使其渲染流水线更加冗长复杂，而 Skyline 则更为精简，同时只保留更现代的 CSS 特性。在此基础上，我们还进一步实现了很多优化点： 单线程版本组件框架。Skyline 下默认启用了新版本的组件框架 glass-easel，该版本适应了 Skyline 的单线程模型，使得建树流程的耗时有效降低（优化 30%-40%），同时 setData 调用也不再有通信开销。 组件下沉。我们将部分内置组件（如 scroll-view、swiper、picker-view 等）直接在底层实现，以追求更流畅的交互体验。此外，我们也将常用的内置组件（view、text、image）从 JS 下沉到原生实现，相当于原生 DOM 节点，有效降低了创建组件的开销（优化 30%）。 长列表按需渲染。长列表是一个常用的但又经常遇到性能瓶颈的场景，Skyline 对其做了一些优化，使 scroll-view 组件只渲染在屏节点（用法上有一定的约束），并且增加 lazy mount 机制优化首次渲染长列表的性能，后续我们也计划在组件框架层面进一步支持 scroll-view 的可回收机制，以更大程度降低创建节点的开销。 WXSS 预编译。同 WebView 传输 WXSS 文本不同，Skyline 在后台构建小程序代码包时会将 WXSS 预编译为二进制文件，在运行时直接读取二进制文件获得样式表结构，避免了运行时解析的开销（预编译较运行时解析快 5 倍以上）。 样式计算更快。Skyline 通过精简 WXSS 特性大幅简化了样式计算的流程。同时 Skyline 与小程序框架结合也更为紧密，例如： Skyline 结合组件系统实现了 WXSS 样式隔离、基于 wx:for 实现了节点样式共享（相比于 WebView 推测式样式共享更为精确、高效）。 降低内存占用。在 WebView 渲染模式下，一个小程序页面对应一个 WebView 实例，并且每个页面会重复注入一些公共资源。而 Skyline 只有 AppService 线程，且多个 Skyline 页面会运行在同一个渲染引擎实例下，因此页面占用内存能够降低很多，还能做到更细粒度的页面间资源共享（如全局样式、公共代码、缓存资源等）。总体上，由于 Skyline 在渲染流程上更加可控，我们能让小程序的特性尽可能融合进渲染流程中完成，还有很多在细节上的优化（比如对 rpx 的处理、image mode=widthFix 的处理等，都是融入渲染流程中，而避免在 JS 做太多额外的计算）就不再一一介绍。另外，我们也在持续优化中，Skyline 会是之后小程序性能优化的重点。 至于目前整体的性能情况，我们从已上线的小程序数据观测到（基础库 3.0.0 glass-easel 带来的优化暂未体现），启动耗时方面，即点击到完全渲染（LCP）的耗时，WebView 对比 Skyline 为 2492ms vs 2052ms，减少 17.6%；渲染阶段耗时方面，即框架建树到完全渲染（LCP）的耗时，WebView 对比 Skyline 为 626ms vs 312ms，减少 50%。 根除旧有架构的问题 在基于 Web 体系的架构下，小程序的部分基础体验会受限于 WebView 提供的能力（特别是 iOS WKWebView 限制更大一些），使得一些技术方案无法做得很完美，留下一些潜在的问题。 原生组件同层渲染更稳定。iOS 下原生组件同层渲染的原理先前有介绍过，本质上是在 WKWebView 黑盒下一种取巧的实现方式，并不能完美融合到 WKWebView 的渲染流程，因此很容易在一些特殊的样式发生变化后，同层渲染会失效，而在 Skyline 下可以很好地融合到渲染流程中，因此会更稳定。 无需页面恢复机制。iOS 下 WKWebView 会受系统的管理，当内存紧张时，系统就会将不在屏的 WKWebView 回收，会使得小程序除前台以外的页面丢失，虽然在页面返回时，我们对页面做了恢复，但页面的状态并不能 100% 还原，而在 Skyline 下则不再有该问题。 无页面栈层数限制。由于 WebView 的内存占用较大，页面层级最多有 10 层，而 Skyline 在内存方面更有优势，因此在连续 Skyline 页面跳转（复用同一引擎实例）的情况下，不再有该限制。 全新的交互动画体系 我们发现，要达到类原生的体验，渲染性能与交互动画缺一不可，渲染性能能让页面更快渲染出来，而交互动画能让浏览页面的体验更佳。但在 Web 体系下，难以做到像素级可控，交互动画衔接不顺畅，究其原因，在于缺失了一些重要的能力，为此，我们提供一套全新的交互动画能力。 Worklet 动画机制。在原来双线程的架构下，若要对界面元素做逐帧动画是需要频繁在逻辑层和渲染层之间通信的，这会带来较大的延迟，动画也就不会流畅。而 Worklet 动画正是为了解决这类问题而诞生的，其运行机制与 WXS 类似，但比 WXS 更靠近渲染流程而性能更好，而且支持的特性更多，可扩展性更强，这个是 Skyline 交互动画体系的基础。 手势系统。在原生的交互动画里，手势识别与协商是一个很重要的特性，而这块在 Web 体系是缺失的，因此 Skyline 下补全手势系统相关特性，包括常用手势的识别，如缩放、拖动、双击等，还有很重要的手势协商机制，在遇到手势冲突（常见于滚动容器下）时决定让哪个手势生效，以实现更顺畅的动画衔接。 自定义路由与共享元素。页面间的自定义转场动画，在原生应用里也是一个很常见的交互动画。在原来的小程序架构下，每个页面都是独立的 WebView 渲染，互相隔离，其跨页能力是基本不具备的。因此，Skyline 提供了一套自定义路由机制，能实现市面上大多数页面转场动画，同时也提供了共享元素机制，能很方便地做到同一元素在页面间飞跃的效果。此外，对内置组件的扩展也是重要一环，特别是 scroll-view 组件，我们优化了下拉刷新的体验，并且实现“下拉二楼”的交互，也添加很多控制能力，这都是些在 Web 下很难做到又非常重要的特性。总之，这套全新的交互动画体系是 Skyline 能实现类原生交互体验的关键。 释放更多高级能力 除了上面提到的交互动画能力外，Skyline 所能释放的能力还远不止于此，借助 Skyline 的特点，我们还提供以下新的组件 grid-view 瀑布流组件。瀑布流是一种常用的列表布局方式，得益于 Skyline 在布局过程中的可控性，我们直接在底层实现并提供出来，渲染性能要比 WebView 更优。 snapshot 截图组件。大多数小程序都会基于 canvas 实现自定义分享图的功能，但分享图的布局较复杂时，canvas 的方案实现成本会更大，而 Skyline 是具备对 WXML 子树截图的能力的，因此我们直接封装后开放出来，这样能复用更完善的 WXSS 能力，极大降低开发成本。除了新增的组件，还有不少是原有内置组件扩展的小特性，这里就不一一介绍，可 查看文档 或 更新日志。未来，我们还会持续在 Skyline 上开放更多高级功能，如全局跨页面组件，scroll-view 列表节点 builder 模块支持节点可回收等，更多可查看 文档特性状态 一栏，同时，也欢迎开发者在社区给我们提议。 至此，Skyline 的主要特点已基本介绍完毕，更完整的介绍、用法、迁移指引、注意点等等请查阅 文档。建议开发者现在就使用起来，尽早享受到 Skyline 带来的优化和丰富的特性，如果开发中遇到问题，可在开发者社区发贴反馈，我们也会邀请加入沟通交流群。

通过第三方平台转发公众号分享到朋友圈的内容都不显示 分享时间2021-12-6 13：20 [图片]

1、小程序发版错误：小程序该开发小程序已开通小程序直播权限，不支持发布版本。如需要发版，请解解绑开发小程序后再操作。 2、小程序发版是通过授权开放平台第三方应用发版小程序。 3、小程序直播插件删除不了提示错误：[图片]； 这需要怎么办？问题出在那？麻烦官方技术给出处理方案。感谢了！

网页链接： https://www.bfytech.com/fgvote_server/public/index.php/index/articledetail/index.html?aid=81 该链接用于测试。里边2个视频在android微信上都播放正常，iOS上则无法播放。但是在iOS自带都Safa浏览器，夸克浏览器上播放正常。所以我认为这是iOS微信的一个bug。类似问题嵌入小程序webview之后还会有。 两个视频一个是网上下载的，一个是用iPhone6s直接录制的。 另外，我看到2018年贵论坛就有类似都bug报出来，还没有解决，所以我重新提了bug。参见： https://developers.weixin.qq.com/community/develop/doc/000aea226d8eb89532f61d19a51000

什么是 Sourcemaps uglifyjs、bable 等工具会对 源代码 进行编译处理生成编译后的代码（下称目标代码），而 sourcemaps 就是保留了目标代码在源代码中的 位置信息 --------- 大神分割线 --------- 如何解读 Sourcemaps Sourcemaps 是一个 json [代码]{ "version": 3, "sources": ["a.js", "b.js"], // 源文件列表，这个表示是由 a.js 和 b.js 合并生成 "names": ["myFn", "test"], // 如果开启了变量名混淆，这里会保留变量名在源文件中名字信息 "sourcesContent: [], // 可选项，保存源码信息，顺序与 sources 字段对应，chrome 的 sources 面板中源码使用了这个字段的内容进行展示 "sourceRoot": "", // 源文件所在的目录信息 "file": "dist.js", // 可选，编译后的文件名 "mappings": "" // 这个是重点，是目标代码和源文件的位置的映射关系 } [代码] mappings 目标文件"行"的信息 mappings 是使用 ; 分隔的，每个部分对应目标代码的行 如: “;AAAA;AAAA,BBBB;;” 本例子目标文件有 4 行 第 0 行和第 3 行没有源文件对应信息，所以这两行是编译过程中加入的代码 目标文件的"列"信息 如: “AAAA,CAEA,CAEA;” ‘,’ 表示行内的位置信息分隔符 本例表示目标文件的这一行有三个有效的位置信息。 位置信息的第一位表示目标文件的列的 偏移 信息 本例中，表示列的信息是 ‘A’、‘C’、‘C’，对应的数字为 0、+1、+1，(vlq 编码，在线编解码工具） 注意，这个是偏移信息； 列数从 0 开始，依次累加偏移值可以算出当前的位置信息对应的真正的列 所以本例中表示的是目标文件的第 n 行中的第 0 列，第 1 列，第 2 列（没错是第 2 列） 源文件的信息 如：‘AAAA;ACAA;ADAA;’ 位置信息的第二位表示源文件的信息，本例子中是 ‘A’、‘C’、‘D’，对应数字是 0、+1、-1 如果 sourcemaps 中的 sources 字段只有一个文件的话，那么位置信息中第二位一直是 A（不需要偏移） 假设 sourcemaps 中 sources: [‘a.js’, ‘b.js’] 本例的意思是 AAAA: 目标文件第 0 行第 0 列 对应 第 0 个文件 a.js ACAA; 目标文件第 1 行第 0 列 对应 第 1 个文件 b.js ADAA; 目标文件第 2 行第 0 列 对了 第 0 个文件 a.js (偏移是 -1 又回到了 a.js) 源文件的行信息 位置信息的第三位表示源文件中的行的信息, 理解了位置偏移的概念，我们很容易理解 如：‘AACA,CACA;AACA;‘ 那么 AACA: 目标文件的第 0 行第 0 列 对应 第 0 个文件的第 1 行 CACA: 目标文件的第 0 行第 0+1 列 对应 第 0 个文件的第 1+1 行 AACA：目标文件的第 1 行第 0 列 对应 第 0 个文件的第 1 行 (注意：’;’ 后的行列偏移信息归 0) 源文件中的列信息 位置信息的第四位表示源文件中的列的信息 如：'AAAA,CAAC;' 那么 AAAA: 目标文件的第 0 行第 0 列 对应 第 0 个文件的第 0 行第 0 列 CAAC: 目标文件的第 0 行第 0+1 列 对应 第 0 个文件的第 0 行第 0+1 列 位置信息的第五位 第五位表示变量的偏移，对应 sourcemaps 中的 names 字段，表示目标文件中的变量名对应域源文件中的变量 如：’AAAA,CAACC;AAAAD;' sourcemaps 中 names 字段是 [‘a’, ‘b’] 那么 AAAA: 目标文件的第 0 行第 0 列 对应 第 0 个文件的第 0 行第 0 列，没有变量的信息 CAACC: 目标文件的第 0 行第 0+1 列 对应 第 0 个文件的第 0 行第 0+1 列，有变量信息，变量在源文件中是 ‘b’ (0+1=1) AAAAD: 目标文件的第 1 行第 0 列 对应 第 0 个文件的第 0 行第 0 列，有变量信息，变量在源文件中是 ‘a’ (1-1=0) --------- 大神分割线 --------- 怎么使用 Sourcemaps Q: 线上小程序报错，我怎么通过 sourcemaps 还原到源代码中？ A: 如报错 appservice.js 1:15000, 表示目标文件第一行 第 15000 列位置报错。根据上文介绍的，通过 mappings 字段算。 Q: 不会。 A: 如果你会写代码的话，参考下边 [代码]import fs = require('fs') import {SourceMapConsumer} from 'source-map' async function originalPositionFor(line, column) { const sourceMapFilePath = '如果你不真的替换的成 sourcemaps 在硬盘中的位置，那你还是放弃自己写代码吧。 ' const sourceMapConsumer = await new SourceMapConsumer(JSON.parse(fs.readFileSync(sourceMapFilePath, 'utf8'))) return sourceMapConsumer.originalPositionFor({ line, column, }) } originalPositionFor(出错的行，出错的列) [代码] Q: 不会写代码 A: 下载最新版的开发者工具，菜单-设置-拓展设置-调试器插件 [图片] [图片] Q: 为啥都是 null？ A: 每个小程序版本都应该对应一个sourcemap文件。 运营中心那里下载的 sourcemap 是对应线上最新的小程序版本。但运营中心的报错集合了多个小程序版本。拿旧小程序版本的报错信息，和最新版本的 sourcemap，是匹配不出的。开发者工具和ci 上传的时候，会提示下载对应版本的 sourcemap 信息，可以自助保存。 [图片] Q: 怎么确定有没有版本对应上 A: 下载的 sourcemap 中有个 wx 字段，标明了该 sourcemap 文件对应小程序版本号。 [图片] [图片] 前提 1.确保发生错误的小程序版本和下载回来的 sourcemap 版本是一致的。 a. 下载 sourceMap 文件，可在 mp 后台或开发者工具上传成功弹窗下载 2.确保 map 文件和发生错误的 js 文件是对应的。sourcemap 的目录和文件说明 a. APP 是主包，FULL 是整包（仅在不支持分包的低版本微信中使用），其他目录是分包 b. 每个分包下都有对应的 app-service.js.map 文件。 c. 如果是使用了按需注入特性（app.json中配置了lazyCodeLoading），那么每个分包下还会有 appservice.app.js.map（对应分包下非页面的js），和所有页面的 xxx.js.map 以上事情都确保正确之后，还是出现行列号匹配不出来的情况。那就需要进一步排查。 线上运行的小程序 sourcemap 文件是怎么生成的？ 处理流程：源码 [ a.js a.js.map b.js b.js.map ] -> 开发者工具（JS转 ES5，压缩）-> 微信后台（合并 js 文件）[ appservice.app.js appservice.app.js.map]。 注意：如果源码在交给工具之前是经过了 webpack 等打包工具的处理，那源码这里需要有 map 文件。否则不需要存在 map 文件。 可以看出，map 文件经过三个步骤的处理，每个步骤都有可能导致出错，因此开发者需要先排查，是否是前两个步骤出错导致的 map 文件失效的。 如何排查前两个步骤产生的 map 文件是否有问题。 1.排查 a.js.map 文件是否有问题。 a. 可以在 a.js 的代码中写一下 throw new Error(‘test sourcemap’)。 b. 使用了 webpack 的情况下，要构建为生产环境的版本。 c. 在开发者工具模拟器中运行对应的页面，看看控制台中的报错，错误行列号是否能正常映射到源文件。 2.排查 开发者工具（JS转 ES5，压缩）步骤是否有问题。 在排查完第一步的基础上，点击预览，用微信上扫码预览，并打开调试 vConsole 功能，检查 vConsole 中是否有报错信息，检查报错信息中的行列号是否能正常映射到源文件。 如何排查 微信后台（合并 js 文件）是否有问题。 a. 一定要先排查完前两个步骤再来排查这一步，一般情况下，这一步是不会出错的。 b. 如果有问题，也只会导致 map 文件中的行号信息出现偏移。比如 Error 信息中显示报错地址是 100: 200，行号是 100。那么你可能直接用 100: 200 在 map 文件中搜索不出信息，但是如果 用 150: 200 就可以搜索出来，说明行号偏移了 50。那其他报错也可以偏移 50 后再进行搜索就找到结果。 c. 怎么排查偏移了多少？可以结合 error.message 的内容，初步判断大概错误的内容是什么。把对应的 map 文件放到这个网站上 source-map-visualization 进行搜索，找出哪些相同列号的地方。再结合 error.message 的内容进行判断。 d. 如果排查到是这一步导致的问题，请在社区上联系我们，我们会在后续版本进行修复。 依旧排查不出原因？ 先整理一下按照上述步骤排查的结论，再在社区上联系我们协助

小程序能否支持文件上传，例如.doc .xlsx等文件

[图片] 扫小程序码立即报名 [图片] 为了更好的提供服务，我们邀请你参与以下用户调查，希望得到你的宝贵意见和真实想法。 点击立即参与，成功提交即有机会优先获得本次活动门票哦～

背景 此前有开发者反馈小程序发布新版本后，新版本覆盖率比较慢，因为小程序的更新机制是异步的，部分用户不会马上应用上新版本。 小程序启动会有两种情况，一种是「冷启动」，一种是「热启动」。 假如用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时无需重新启动，只需将后台态的小程序切换到前台，这个过程就是热启动；冷启动指的是用户首次打开或小程序被微信主动销毁后再次打开的情况，此时小程序需要重新加载启动。 小程序的异步更新发生在冷启动过程，当发现新版本后，会异步下载新版本的代码包，但不会马上应用上最新版本，需要等小程序下一次冷启动，才会应用上新版本。 解决思路为了解决这个问题，我们内部也经历了数个方案的讨论，这里简单介绍下： 1. 同步检查更新（放弃）：可能是最直接的解决思路，但主要问题是会影响小程序的启动速度，当下小程序的更新迭代是非常频繁的，部分用户可能每次启动都命中更新，如果需要同步检查更新+同步下载新的版本，那将会影响这部分用户的启动体验。 2. 模块热替换（放弃）：从技术上来说，这是最好的方案，小程序运行起来后，在打开新页面时，马上应用新版本里的页面，但这就会存在新旧逻辑、页面共存问题，对于开发者来说，反而更不好处理，特别是涉及到全局变量时，情况会更复杂，对于我们已有的框架来说，也是一个大挑战，不过这个也是我们之后努力的方向。 3. 定时 check 新版本（目前方案）：6.6.3 及以上版本的客户端，会定时 check 最近使用过的小程序是否有发布新版本；如果有，下次打开的时候会同步更新新版本再打开。这可以保证在新版本发布 24 小时后，所有小程序都能使用最新版本。（这部分是微信客户端自身优化，开发者无需关心） 4. 异步更新 + 强制更新（目前方案）：同步检查更新与模块热替换两者之间的折衷方案，即还是维持异步更新机制，在异步下载完小程序代码包后，提供重启小程序的能力，这样在遇到紧急问题时可以马上解决。 异步更新 + 强制更新方案介绍从基础库 1.9.90 开始，我们提供了 wx.getUpdateManager 接口，使用该接口，可以获知是否有新版本小程序、新版本是否下载好以及应用新版本的能力。 当小程序冷启动时，会自动向微信后台请求新版本信息，如果有新版本，会马上触发新版本的下载。开发者可以通过 wx.getUpdateManager，获知当前更新的状态。 wx.getUpdateManager 接口会返回一个 UpdateManager 实例，UpdateManager 包含了三个回调： 1. onCheckForUpdate：当小程序向后台请求完新版本信息，会通知这个版本告知检查结果 2. onUpdateReady：当新版本下载完成，会回调这个事件 3. onUpdateFailed: 当新版本下载失败，会回调这个事件 还有重启应用新版本的接口： 1. applyUpdate：当新版本下载完成（onUpdateReady），调用该方法会强制当前小程序应用上新版本并重启 具体示例： [代码]// wx.getUpdateManager 在 1.9.90 才可用，请注意兼容[代码] [代码]const updateManager = wx.getUpdateManager()[代码] [代码]updateManager.onCheckForUpdate(function[代码] [代码](res) {[代码] [代码]  // 请求完新版本信息的回调[代码] [代码]  console.log(res.hasUpdate)[代码] [代码]})[代码] [代码]updateManager.onUpdateReady(function[代码] [代码]() {[代码] [代码]  wx.showModal({[代码] [代码]    title: '更新提示',[代码] [代码]    content: '新版本已经准备好，是否马上重启小程序？',[代码] [代码]    success: function[代码] [代码](res) {[代码] [代码]      if[代码] [代码](res.confirm) {[代码] [代码]        // 新的版本已经下载好，调用 applyUpdate 应用新版本并重启[代码] [代码]        updateManager.applyUpdate()[代码] [代码]      }[代码] [代码]    }[代码] [代码]  })[代码] [代码]})[代码] [代码]updateManager.onUpdateFailed(function[代码] [代码]() {[代码] [代码]  // 新的版本下载失败[代码] [代码]})[代码] 更详细信息可以参考 UpdateManager 的详细文档 最佳实践从用户体验上来说，我们还是建议只在非常必要时才强制用户重启更新，例如出现线上紧急 BUG。通常情况下，可以选通过 wx.showModal 弹出选择框让用户选择是否重启更新（实现请参考示例代码）。 如何调试最新版本的微信开发者工具提供了强制更新的调试能力，通过编译模式 - 编辑编译模式 - 勾上「下次编译时模拟更新」即可在开发者工具上调试强制更新功能。 最新开发者工具下载链接 点我。