[图片][图片]

各位微信开发者： 以下是Android 系统蓝牙权限适配指引、小程序基础库 3.5.3 更新以及上周我们在社区收到的问题反馈的处理进度，希望与大家一同打造更好的小程序生态！ Android 系统蓝牙权限适配指引 为响应Android 14对于蓝牙权限的变更，微信 自 8.0.50 版本起调用蓝牙相关接口时将向用户请求 “附近设备” 的系统权限。若用户拒绝此权限，小程序将无法调用蓝牙相关接口。 开发者可通过 wx.getAppAuthorizeSetting 接口中的 bluetoothAuthorized 参数判断微信的权限状态。若用户拒绝此权限，可通过 wx.openAppAuthorizeSetting 接口打开微信设置页引导用户打开权限 小程序基础库 3.5.3 更新 小程序基础库 3.5.3 已经开始灰度开发者，请大家基于业务情况关注相关变更。如遇问题请及时在小程序交流专区发表标题包含「基础库 3.5.3」的帖子反馈。本次更新重点如下： 新增 API 小游戏新增 wx.offShareMessageToFriend 详情更新 框架 小游戏真正用到开放数据域再禁用主屏 readPixels更新 框架 安卓 downloadFile 、uploadFile 接口性能优化更多更新内容请查看 原公告 上周问题反馈与处理进度（07.29-08.02） 已修复的问题wx.openLocation顶部导航栏显示的问题 详情 修复中的问题PC端小程序发送的请求全部失败的问题 详情 小程序API wx.getAppAuthorizeSetting() 返回值异常 详情  微信团队 2024年8月9日

部分鸿蒙系统的手机调用wx.openBluetoothAdapter失败，报错为{"errno":3,"errMsg":"openBluetoothAdapter:fail:system permission denied"}，询问华为那边的客服，说现在鸿蒙手机没有蓝牙的权限设置。scene=1089&brand=HUAWEI&model=ALN-AL80&version=8.0.50&system=Android 12&SDKVersion=3.4.9&bluetoothEnabled=true&locationEnabled=true。根据日志显示bluetoothEnabled也是true。

微信小程序手机号授权，手机号收不到验证码短信，是不是把我手机号拉黑了？

正常逻辑，一段时间内未验证的手机号，就需要重新验证。

众所周知，小程序当中有一类特殊的内置组件——原生组件，这类组件有别于 WebView 渲染的内置组件，他们是交由原生客户端渲染的。原生组件作为 Webview 的补充，为小程序带来了更丰富的特性和更高的性能，但同时由于脱离 Webview 渲染也给开发者带来了不小的困扰。在小程序引入「同层渲染」之前，原生组件的层级总是最高，不受 [代码]z-index[代码] 属性的控制，无法与 [代码]view[代码]、[代码]image[代码] 等内置组件相互覆盖， [代码]cover-view[代码] 和 [代码]cover-image[代码] 组件的出现一定程度上缓解了覆盖的问题，同时为了让原生组件能被嵌套在 [代码]swiper[代码]、[代码]scroll-view[代码] 等容器内，小程序在过去也推出了一些临时的解决方案。但随着小程序生态的发展，开发者对原生组件的使用场景不断扩大，原生组件的这些问题也日趋显现，为了彻底解决原生组件带来的种种限制，我们对小程序原生组件进行了一次重构，引入了「同层渲染」。 相信已经有不少开发者已经在日常的小程序开发中使用了「同层渲染」的原生组件，那么究竟什么是「同层渲染」？它背后的实现原理是怎样的？它是解决原生组件限制的银弹吗？本文将会为你一一解答这些问题。 什么是「同层渲染」? 首先我们先来了解一下小程序原生组件的渲染原理。我们知道，小程序的内容大多是渲染在 WebView 上的，如果把 WebView 看成单独的一层，那么由系统自带的这些原生组件则位于另一个更高的层级。两个层级是完全独立的，因此无法简单地通过使用 [代码]z-index[代码] 控制原生组件和非原生组件之间的相对层级。正如下图所示，非原生组件位于 WebView 层，而原生组件及 [代码]cover-view[代码] 与 [代码]cover-image[代码] 则位于另一个较高的层级： [图片] 那么「同层渲染」顾名思义则是指通过一定的技术手段把原生组件直接渲染到 WebView 层级上，此时「原生组件层」已经不存在，原生组件此时已被直接挂载到 WebView 节点上。你几乎可以像使用非原生组件一样去使用「同层渲染」的原生组件，比如使用 [代码]view[代码]、[代码]image[代码] 覆盖原生组件、使用 [代码]z-index[代码] 指定原生组件的层级、把原生组件放置在 [代码]scroll-view[代码]、[代码]swiper[代码]、[代码]movable-view[代码] 等容器内，通过 [代码]WXSS[代码] 设置原生组件的样式等等。启用「同层渲染」之后的界面层级如下图所示： [图片] 「同层渲染」原理 你一定也想知道「同层渲染」背后究竟采用了什么技术。只有真正理解了「同层渲染」背后的机制，才能更高效地使用好这项能力。实际上，小程序的同层渲染在 iOS 和 Android 平台下的实现不同，因此下面分成两部分来分别介绍两个平台的实现方案。 iOS 端 小程序在 iOS 端使用 WKWebView 进行渲染的，WKWebView 在内部采用的是分层的方式进行渲染，它会将 WebKit 内核生成的 Compositing Layer（合成层）渲染成 iOS 上的一个 WKCompositingView，这是一个客户端原生的 View，不过可惜的是，内核一般会将多个 DOM 节点渲染到一个 Compositing Layer 上，因此合成层与 DOM 节点之间不存在一对一的映射关系。不过我们发现，当把一个 DOM 节点的 CSS 属性设置为 [代码]overflow: scroll[代码] （低版本需同时设置 [代码]-webkit-overflow-scrolling: touch[代码]）之后，WKWebView 会为其生成一个 [代码]WKChildScrollView[代码]，与 DOM 节点存在映射关系，这是一个原生的 [代码]UIScrollView[代码] 的子类，也就是说 WebView 里的滚动实际上是由真正的原生滚动组件来承载的。WKWebView 这么做是为了可以让 iOS 上的 WebView 滚动有更流畅的体验。虽说 [代码]WKChildScrollView[代码] 也是原生组件，但 WebKit 内核已经处理了它与其他 DOM 节点之间的层级关系，因此你可以直接使用 WXSS 控制层级而不必担心遮挡的问题。 小程序 iOS 端的「同层渲染」也正是基于 [代码]WKChildScrollView[代码] 实现的，原生组件在 attached 之后会直接挂载到预先创建好的 [代码]WKChildScrollView[代码] 容器下，大致的流程如下： 创建一个 DOM 节点并设置其 CSS 属性为 [代码]overflow: scroll[代码] 且 [代码]-webkit-overflow-scrolling: touch[代码]； 通知客户端查找到该 DOM 节点对应的原生 [代码]WKChildScrollView[代码] 组件； 将原生组件挂载到该 [代码]WKChildScrollView[代码] 节点上作为其子 View。 [图片] 通过上述流程，小程序的原生组件就被插入到 [代码]WKChildScrollView[代码] 了，也即是在 [代码]步骤1[代码] 创建的那个 DOM 节点对应的原生 ScrollView 的子节点。此时，修改这个 DOM 节点的样式属性同样也会应用到原生组件上。因此，「同层渲染」的原生组件与普通的内置组件表现并无二致。 Android 端 小程序在 Android 端采用 chromium 作为 WebView 渲染层，与 iOS 不同的是，Android 端的 WebView 是单独进行渲染而不会在客户端生成类似 iOS 那样的 Compositing View (合成层)，经渲染后的 WebView 是一个完整的视图，因此需要采用其他的方案来实现「同层渲染」。经过我们的调研发现，chromium 支持 WebPlugin 机制，WebPlugin 是浏览器内核的一个插件机制，主要用来解析和描述embed 标签。Android 端的同层渲染就是基于 [代码]embed[代码] 标签结合 chromium 内核扩展来实现的。 [图片] Android 端「同层渲染」的大致流程如下: WebView 侧创建一个 [代码]embed[代码] DOM 节点并指定组件类型； chromium 内核会创建一个 [代码]WebPlugin[代码] 实例，并生成一个 [代码]RenderLayer[代码]； Android 客户端初始化一个对应的原生组件； Android 客户端将原生组件的画面绘制到步骤2创建的 [代码]RenderLayer[代码] 所绑定的 [代码]SurfaceTexture[代码] 上； 通知 chromium 内核渲染该 [代码]RenderLayer[代码]； chromium 渲染该 [代码]embed[代码] 节点并上屏。 [图片] 这样就实现了把一个原生组件渲染到 WebView 上，这个流程相当于给 WebView 添加了一个外置的插件，如果你有留意 Chrome 浏览器上的 pdf 预览，会发现实际上它也是基于 [代码]<embed />[代码] 标签实现的。 这种方式可以用于 map、video、canvas、camera 等原生组件的渲染，对于 input 和 textarea，采用的方案是直接对 chromium 的组件进行扩展，来支持一些 WebView 本身不具备的能力。 对比 iOS 端的实现，Android 端的「同层渲染」真正将原生组件视图加到了 WebView 的渲染流程中且 embed 节点是真正的 DOM 节点，理论上可以将任意 WXSS 属性作用在该节点上。Android 端相对来说是更加彻底的「同层渲染」，但相应的重构成本也会更高一些。 「同层渲染」 Tips 通过上文我们已经了解了「同层渲染」在 iOS 和 Android 端的实现原理。Android 端的「同层渲染」是基于 chromium 内核开发的扩展，可以看成是 webview 的一项能力，而 iOS 端则需要在使用过程中稍加注意。以下列出了若干注意事项，可以帮助你避免踩坑： Tips 1. 不是所有情况均会启用「同层渲染」 需要注意的是，原生组件的「同层渲染」能力可能会在特定情况下失效，一方面你需要在开发时稍加注意，另一方面同层渲染失败会触发 [代码]bindrendererror[代码] 事件，可在必要时根据该回调做好 UI 的 fallback。根据我们的统计，目前同层失败率很低，也不需要太过于担心。 对 Android 端来说，如果用户的设备没有微信自研的 [代码]chromium[代码] 内核，则会无法切换至「同层渲染」，此时会在组件初始化阶段触发 [代码]bindrendererror[代码]。而 iOS 端的情况会稍复杂一些：如果在基础库创建同层节点时，节点发生了 WXSS 变化从而引起 WebKit 内核重排，此时可能会出现同层失败的现象。解决方法：应尽量避免在原生组件上频繁修改节点的 WXSS 属性，尤其要尽量避免修改节点的 [代码]position[代码] 属性。如需对原生组件进行变换，强烈推荐使用 [代码]transform[代码] 而非修改节点的 [代码]position[代码] 属性。 Tips 2. iOS 「同层渲染」与 WebView 渲染稍有区别 上文我们已经了解了 iOS 端同层渲染的原理，实际上，WebKit 内核并不感知原生组件的存在，因此并非所有的 WXSS 属性都可以在原生组件上生效。一般来说，定位 (position / margin / padding) 、尺寸 (width / height) 、transform (scale / rotate / translate) 以及层级 (z-index) 相关的属性均可生效，在原生组件外部的属性 (如 shadow、border) 一般也会生效。但如需对组件做裁剪则可能会失败，例如：[代码]border-radius[代码] 属性应用在父节点不会产生圆角效果。 Tips 3. 「同层渲染」的事件机制 启用了「同层渲染」之后的原生组件相比于之前的区别是原生组件上的事件也会冒泡，意味着，一个原生组件或原生组件的子节点上的事件也会冒泡到其父节点上并触发父节点的事件监听，通常可以使用 [代码]catch[代码] 来阻止原生组件的事件冒泡。 Tips 4. 只有子节点才会进入全屏 有别于非同层渲染的原生组件，像 [代码]video[代码] 和 [代码]live-player[代码] 这类组件进入全屏时，只有其子节点会被显示。 [图片] 总结 阅读本文之后，相信你已经对小程序原生组件的「同层渲染」有了更深入的理解。同层渲染不仅解决了原生组件的层级问题，同时也让原生组件有了更丰富的展示和交互的能力。下表列出的原生组件都已经支持了「同层渲染」，其他组件（ textarea、camera、webgl 及 input）也会在近期逐步上线。现在你就可以试试用「同层渲染」来优化你的小程序了。 支持同层渲染的原生组件 最低版本 video v2.4.0 map v2.7.0 canvas 2d（新接口） v2.9.0 live-player v2.9.1 live-pusher v2.9.1

接着上篇文章《小程序架构设计(一)》 前边我们说到采用Web+离线包的方式可以解决很多问题，但是遗留了一个安全问题有待解决。 经过了一番讨论，我们决定把开发者的JS逻辑代码放到单独的线程去运行，因为不在Webview线程里，所以这个环境没有Webview任何接口，自然的开发者就没法直接操作Dom，也就没法动态去更改界面，“管控”的问题得以解决。 还存在一个问题：开发者没法操作Dom，如果用户交互需要界面变化的话，开发者就没办法动态变化界面了。所以我们要找到一个办法：不直接操作Dom也能做到界面更新。 其实Facebook早有方案解决这个问题，就是上篇文章提到的React。React引入了Virtual Dom的概念（后文简称VD），业务侧只需要改变数据即可引起界面变化，相关原理后边再写篇文章来分享。 至此小程序双线程的模型就定下来了：渲染层(Webview)+逻辑层(JSCore) [图片] 其中渲染层用了Webview进行渲染，开发者的JS逻辑运行在一个独立的JSCore线程。 渲染层提供了带有数据绑定语法的WXML，逻辑层提供了setData等等API，开发者需要进行界面变化时，只需要通过setData把变化的数据传进去，小程序框架就会进行Dom Diff等流程最后把正确的结果更新在Dom树上。 [图片] 可以看到在开发者的逻辑下层，还需要有一层小程序框架的支持（数据通信、API、VD算法等等），我们把它称为基础库。 我们在两个线程各自注入了一份基础库，渲染层的基础库含有VD的处理以及底层组件系统的机制，对上层提供一些内置组件，例如video、image等等。逻辑层的基础库主要会提供给上层一些API，例如大家经常用到的wx.login、wx.getSystemInfo等等。 解决了渲染问题，我们还要看一下用户在和界面交互时的问题。 [图片] 用户在屏幕点击某个按钮，开发者的逻辑层要处理一些事情，然后再通过setData引起界面变化，整个过程需要四次通信。对于一些强交互（例如拖动视频进度条）的场景，这样的处理流程会导致用户的操作很卡。 对于这种强交互的场景，我们引入了原生组件，这样用户和原生组件的交互可以节省两次通信。 [图片] 正如上图所示，原生组件和Webview不是在同一层级进行渲染，原生组件其实是叠在Webview之上，想必大家都遇到过这个问题，video、input、map等等原生组件总是盖在其他组件之上，这就是这个设计带来的问题。 我们也很重视这个问题，经过了一段时间的努力，我们攻克了这个难题，把原生组件渲染到Webview里，从而实现同层渲染。目前video组件已经完成同层渲染的全量发布，详细可以看我们之前的公告：同层渲染公测。 为了让开发者可以更好的开发小程序，我们在后来还引入了自定义组件和插件的概念，我们后续会有相关的文章再介绍这两块的设计，希望大家关注我们社区的文章板块。 [图片] 以上就是小程序架构设计的历史。

在微信早期，我们内部就有这样的诉求，在微信打开的H5可以调用到微信原生一些能力，例如公众号文章里可以打开公众号的Profile页。所以早期微信提供了Webview到原生的通信机制，在Webview里注入JSBridge的接口，使得H5可以通过它调用到原生能力。 [图片] 我们可以通过JSBridge微信预览图片的功能： [代码]WeixinJSBridge.invoke('imagePreview', { current: https://img1.gtimg.com/1.jpg', urls: [ 'https://img1.gtimg.com/1.jpg', 'https://img1.gtimg.com/2.jpg', 'https://img1.gtimg.com/3.jpg' ] }) [代码] 早期微信官方是没有暴露这些接口的，都是腾讯内部业务在使用，很多外部开发者发现后，就依葫芦画瓢地使用了。 从另外一个角度看，JSBridge是微信和H5的通信协议，有一些能力可能要组合不同的能力才能完整调用。如果我们直接开放这套API，相当于所有开发者都要直接理解这样的接口协议，显然是很不合理的。 所以在2015年初的时候，微信就发布了JSSDK，其实就是隐藏了内部一些细节，包装了几十个API给到上层业务直接调用。 [图片] 前边的代码就变成了： [代码]wx.previewImage({ current: https://img1.gtimg.com/1.jpg', urls: [ 'https://img1.gtimg.com/1.jpg', 'https://img1.gtimg.com/2.jpg', 'https://img1.gtimg.com/3.jpg' ] }) [代码] 开发者可以用JSSDK来调用微信的能力，来完成一些以前H5做不到或者难以做到的事情。 能力上得到了更多的支持，但是微信里的H5体验却没有改善。 第一点是加载H5时的白屏。在微信里打开链接后会看到白屏，有一些H5的服务不稳定，这个白屏现象会更严重。 [图片] 第二点是在H5跳转到其他页面时，切换的效果也很不流畅，只能看到顶部绿色进度条在走。 [图片] 随着JSSDK的开放，还出现了更不好对付的问题。 微信上越来越多干坏事的人，有人做假红包，有人诱导分享，有伪造一些官方活动。他们会利用JSSDK的分享能力变相的去裂变分享到各个群或者朋友圈，由于JSSDK是根据域名来赋予api权限的，运营人员封了一个域名后，他们立马用别的域名又继续做坏，要知道注册一个新的域名的成本是很低的。 [图片] [图片] [图片] 龙哥在2016年微信公开课上提出了应用号的概念，我们要重新设计一个新的移动应用开发模式，同时我们要解决刚刚提到的一些问题。 至此，我们回顾一下目前移动应用开发的一些特点： Web开发的门槛比较低，而App开发门槛偏高而且需要考虑iOS和安卓多个平台； 刚刚说到H5会有白屏和页面切换不流畅的问题，原生App的体验就很好了； H5最大的优点是随时可以上线更新，但是App的更新就比较慢，需要审核上架，还需要用户主动安装更新。 我们更想要的一种开发模式应该是要满足一下几点： 像H5一样开发门槛低； 体验一定要好，要尽可能的接近原生App体验； 让开发者可以云端更新，而且我们平台要可以管控。 很多人可能会第一时间想到Facebook的React Native(下边简称RN)，是不是RN就能解决这些问题呢？ 是的，React Native貌似可以解决刚刚那些问题，我们也曾经想用RN来做。但是仔细分析了一下，我们发现了采用RN这个机制做开放平台还是存在一些问题。 RN只支持CSS的子集，作为一个开放的生态，我们还要告诉外边千千万万的开发者，哪些CSS属性能用，哪些不能用； RN本身存在一些问题，这些依赖RN的修复，同时这样就变成太过依赖客户端发版本去解决开发者那边的Bug，这样修复周期太长。 RN前阵子还搞出了一个Lisence问题，对我们来说也是存在隐患的。 [图片] 所以我们舍弃了这样的方案，我们改用了Hybrid的方式。简单点说，就是把H5所有代码打包，一次性Load到本地再打开。这样的好处是我们可以用一种近似Web的方式来开发，同时在体验上也可以做到不错的效果，并且也是可以做到云端更新的。 [图片] 现在留给我们的最后一个问题就是，平台的管控问题。 怎么理解呢？我们知道H5的界面结构是用HTML进行描述，浏览器进行一系列的解析最终绘制在界面上。 [图片] 同时浏览器提供了可以操作界面的DOM API，开发者可以用这些API进行一些界面上的变动，从而实现UI交互。 [图片] 既然我们要采用Web+离线包的方式，那我们要解决前边说过的安全问题，我们就要禁用掉很多危险的HTML标签，还要禁用掉一些API，我们要一直维护这样的白名单或者黑名单，实现成本太高了，而且未来浏览器内核一旦更新，对我们来说都是很大的安全隐患。 [图片] 这就是小程序一开始遇到的问题，在下篇文章《小程序架构设计(二)》，我们再详细展开一下小程序是如何解决以上这个问题的。

为了提供给用户更好的阅读体验，微信安卓版 7.0.10 版本起，网页的字体会跟随微信设置里的字体大小更改而变化。 若调整字体变大或变小后，部分未适配网页的排版会出现显示错乱，建议未进行适配的开发者尽快完成对“ 字体大小” 的适配。 查看网页在字体不同大小下展示效果的方法：    方法1："设置">"通用">“字体大小">进行字体大小修改后查看对应网页显示效果。    方法2：在微信内访问对应网页右上角”…">底部菜单栏选择调整字体">进行字体大小修改后查看对应网页显示效果。    另外，对于现有的显示问题，我们提供以下方案让开发者临时将字体还原标准大小。同时，开发者可以在页面中提示用户在右上角”…”更多菜单中修改字体到合适的大小。 下列方案可以将字体还原标准大小，但我们仍然建议后续做字体适配来提高用户的阅读体验。  『字体还原标准大小』方案：      我们提供了一个  JSAPI 用于设置字体大小，只需将字体大小等级设置为 2 （标准）即可，代码示例如下： document.addEventListener("WeixinJSBridgeReady", function () {   WeixinJSBridge.invoke("setFontSizeCallback", {     fontSize: '2'   }); }, false); 此外，若页面是用 rem 单位进行排版的（目前该做法更容易导致页面不可用），可以反向重置 font-size 的数值达到还原字体标准大小的目的，此方法在效果上也比较理想。代码示例如下： // 以下代码思路来源网络。同时代码放在 body 标签开头位置效果最佳 var $dom = document.createElement('div'); $dom.style = 'font-size: 10px'; document.body.appendChild($dom); // 计算出放大后的字体 var scaledFontSize = parseInt(window.getComputedStyle($dom, null).getPropertyValue('font-size')); document.body.appendChild($dom); // 计算原字体和放大后字体的比例 var scaleFactor = 10 / scaledFontSize; // 取 html 元素的字体大小 var originRootFontSize = parseInt(window.getComputedStyle(document.documentElement, null).getPropertyValue('font-size')); // 由于设置 font-size 后实际会变大，故 font-size 需设置为更小一级 document.documentElement.style.fontSize = originRootFontSize * scaleFactor * scaleFactor + 'px';

近期，开发者社区几乎隔三差五就被“如何整改虚拟支付”霸占。社区君在大家的强烈诉求下，特地整理了大家审核过程中经常遇到的问题。 问题1 虚拟支付到底是什么？ 虚拟支付是指购买非实物商品。比如：VIP会员、充值、课程、音视频等虚拟产品。 问题2 为什么关闭了虚拟支付功能，还是不能过审？ 部分开发者在提审时，仅在后台关闭了支付接口，但在前端仍保留购买/支付/订阅等功能或按钮，在iOS端的界面也都会有类似“订阅课程、开通VIP”等标识，这类呈现货架价格、提示购买的行为将被禁止。 比如： [图片] 这类展示货架（价格标签）的，将被拒绝 问题3 为什么已经去掉了引导关注公众号，还是不能过审？ 请勿试图引导用户到微信公众号、H5、App或是任何外链进行付费。任何为用户提供前往支付流程的路径/文案，都将被拒绝。 比如： [图片] 这类通过【客服消息】-【个人微信号】，完成购买行为，将会被拒绝 [图片] 这类引导到H5，完成购买的行为，将会被拒绝 [图片] 这类引导到公众号，完成购买的行为，将会被拒绝 以下提供3种修改示例，仅供参考。 1、关闭iOS付费通道。 以小程序【腾讯视频】为例，iOS端关闭会员卡开通渠道，原【开通VIP】按钮，现仅显示【你还不是会员】，不再提供会员开通服务。比如： [图片] 2、所有付费内容均更改为免费。 以小程序【有道精品课】为例，iOS端将所有付费内容更改为免费，原【付费解锁】，现已完全免费使用。比如： [图片] 3、前端直接拦截提示不可服务。 以小程序【网易公开课精品】、【腾讯视频VIP】为例，iOS端点击订阅、开通VIP服务，前端直接拦截提示不可服务。但，如果页面呈现货架价格，提示购买行为的（如问题2），将会被拒绝。比如： [图片]