由于老版本 iOS Open SDK 中使用的 openUrl 接口为系统废弃接口，若开发者升级了 Xcode16 进行打包，则可能会在 iOS18 上偶现SDK无法拉起微信的问题，而该问题已经在 2.0.4 的版本中通过更换新接口修复。因此，请近期有发版计划的开发者及时更新到 2.0.4，避免影响用户日常使用。

从小程序打开app,如果app未被杀掉是可以拿到小程序的参数的，如果被杀掉拿不到参数

我们现在有一个app（以下称为app1，配置中的com.ibuding.Fastpig，注册的Universal Links和Associated Domains中配置的applinks均为www.domain.com）已上线，并且之前配置了apple-app-site-association，如下图[图片] 2.我们现在有另外一个app（以下称为app2，配置中的com.ibuding.Pigfeet，注册的Universal Links和Associated Domains中配置的applinks均为www.domain.com/wx_conn/），不同的bundle Id，于是我尝试配置第二个+path的，如下图 [图片] 3.当我app2发起分享并且加入sdk的自检函数，到第四步都是pass的，但是跳转到微信后回跳到的是app1，而非app2. 请问这种情况要怎么解决呢？ 如果是app1配置的paths通配符和app2冲突的话，我尝试把app1的json放在前面好像也不行。另外如果不改app1的相关配置的情况下如何解决这个问题呢。

【设备类型及SDK版本号】 ios； SDK版本号：1.8.6.1 【用户表现】 app每次分享都出现【正在连接】的二跳情况 或 授权登录页面出现二次确认弹窗。 [图片]   [图片] 【符合预期的表现】 用户首次使用SDK内功能时可能会出现上述提示，但每个用户只有首次使用的时候会出现，后续不会再提示。 【错误原因】 开发者在registerApp传入的Universal links不生效，每次分享鉴权通过Universal links回跳app失败，导致微信降级scheme返回app，自动重新发起兜底请求。目前兜底请求可以通过，但微信后续也会逐步拦截。 【原因分析】 Universal links失效，可能原因： 1）工程配置associated domain未打开或未添加Universal links域名 2）配置文件未上线或未按苹果要求放在服务器指定的路径下(域名根目录) 3）配置文件的Universal links的path末尾没有加通配符* 4）配置文件的appID（teamID+bundleID）与实际代码包不匹配 【解决方案】 1. 按微信以及苹果的官方接入文档检查Universal Links配置是否符合要求 2. 确认配置正确后，按微信接入文档内的【SDK接入成功验证指引】逐步验证 微信文档：https://developers.weixin.qq.com/doc/oplatform/Mobile_App/Access_Guide/iOS.html 苹果文档：https://developer.apple.com/documentation/uikit/inter-process_communication/allowing_apps_and_websites_to_link_to_your_content

随着腾讯官方不断的赋予微信小程序新的功能,这个新功能也越来越受到大家的关注.那么在众多小程序中如何让自己的小程序脱颖而出,成为广大运营者关心的问题.今天就来跟大家聊聊关于小程序排名的那些事. 先来说说小程序展现方式的分类: 1.附近小程序 大家熟知这个功能的主要原因是腾讯给出了一个比较诱人的推广方式,附近1-5公里的免费展示.这个对于很多商家来说是特别有吸引力的.但是由于腾讯的审核 机制问题,如果只有一个店的商家就只能在一个固定的位置进行展示.所覆盖范围有限.这里的排名规则很简单,就是根据微信用户与店面的地理位置进行判断.离 店越近展示就越靠前.人工干预的因素几乎没有可能,这里就不做过多阐述了. 2.搜索小程序 附近小程序的位置的局限性会影响到小程序的流量,针对这种情况微信小程序给出了一个辅助功能,关键词搜索功能.这是小程序流量来源的另一个重要途径. 具体可分为微信搜索和小程序搜索,很多人就会问这两者有什么区别么?是的,有区别的.下面我就来重点说说这两个搜索方式的. 先来说说微信搜索，点击微信搜索 下面会出来一个小程序选项,里面展示的小程序为近期你访问过的小程序 以花店为例,会出来之前我们使用过的小程序’周边花店’；影响微信搜索的主要因素,大家很容易看到.以使用过的小程序方式展现.需要用户有打开微信小程序的记录 再来说说小程序搜索,小程序搜索的具体操作方式其实和我们打开小程序的步骤差不多，这里面的展示和排名是我们今天要重点去说的,影响小程序搜索排名的因素总结下来有以下几点: 【1】上线时间（占比5%）： 微信小程序的上线时间，上线时间越早，排名越靠前 目前微信小程序关键词占位非常重要，越早发布竞争越小，而且还可以做到霸-屏的效果 【2】关键字频次（10%）： 描述中完全匹配出现关键词次数越多，排名越靠前 【3】标题（35%）： 标题中关键词出现1次，且整体标题的字数越短，排名越靠前 【4】使用量（占比50%） 微信小程序用户使用数量越多，排名越靠前 如果你提前布局小程序各个方面，想必你的小程序排名远远超过你的预想值。 反之你要退后布局，你的排名就很难靠前，用户找到您的概率就会很低。 根据以上因素,不难发现决定小程序排名的重要因素在于用户的使用量,运营者在日常推广中可以针对性的去推广小程序。 最后分享一下我收集的小程序： https://www.sucaihuo.com/source/0-0-266-0-0-0

本文针对不会配置HTTPS或者小白开发着，请开发者社区的大佬们自动忽略。非广告，心得分享，勿喷，谢谢。 👇 推荐一个小程序商城，全开源，码云GVP项目，有兴趣的可以了解一下：【点击下载】 👇 👇 正文开始 01、关于 FreeSSL.cn FreeSSL.cn 是一个免费提供 HTTPS 证书申请、HTTPS 证书管理和 HTTPS 证书到期提醒服务的网站，旨在推进 HTTPS 证书的普及与应用，简化证书申请的流程。 当然了，我看重的不是免费（微笑~），而是 FreeSSL 使用起来非常人性化。我是一个计算机常识非常薄弱的程序员（羞愧一下），但通过 FreeSSL，我竟然可以独自完成 Tomcat 的 HTTPS 配置！ 很多年以前，公司要做华夏银行的接口对接，需要 HTTPS 访问，大概花了 3000 块买的证书，最后证书还有问题，HTTPS 也没搞定。总之，坑的很！ FreeSSL.cn 有很大的不同，申请非常便捷，优点很多，值得推荐一波。毕竟再也不用邮件、电话各种联系了（也许时代进步了）。 100% 永久免费；这要感谢 Let’s Encrypt 与 TrustAsia 提供的免费 SSL 证书。 在 HTTPS 证书到期前，FreeSSL.cn 会及时地提醒更换证书，免费的服务。 私钥不在网络中传播，确保 HTTPS 证书的安全。 02、使用 FreeSSL 申请证书 第一步，填写域名，点击「创建免费的 SSL 证书」 [图片] 第二步，填写邮箱，点击「创建」 [图片] 1）证书类型默认为 RSA RSA 和 ECC 有什么区别呢？可以通过下面几段文字了解一下。 HTTPS 通过 TLS 层和证书机制提供了内容加密、身份认证和数据完整性三大功能，可以有效防止数据被监听或篡改，还能抵御 MITM（中间人）攻击。TLS 在实施加密过程中，需要用到非对称密钥交换和对称内容加密两大算法。 对称内容加密强度非常高，加解密速度也很快，只是无法安全地生成和保管密钥。在 TLS 协议中，应用数据都是经过对称加密后传输的，传输中所使用的对称密钥，则是在握手阶段通过非对称密钥交换而来。常见的 AES-GCM、ChaCha20-Poly1305，都是对称加密算法。 非对称密钥交换能在不安全的数据通道中，产生只有通信双方才知道的对称加密密钥。目前最常用的密钥交换算法有 RSA 和 ECDHE：RSA 历史悠久，支持度好，但不支持 PFS（Perfect Forward Secrecy）；而 ECDHE 是使用了 ECC（椭圆曲线）的 DH（Diffie-Hellman）算法，计算速度快，支持 PFS。 2）验证类型默认为 DNS DNS 和文件验证有什么区别呢？我们再来一起了解下。 首先，我们需要明白一点，CA（Certificate Authority，证书颁发机构） 需要验证我们是否拥有该域名，这样才给我们颁发证书。 文件验证（HTTP）：CA 将通过访问特定 URL 地址来验证我们是否拥有域名的所有权。因此，我们需要下载给定的验证文件，并上传到您的服务器。 DNS 验证：CA 将通过查询 DNS 的 TXT 记录来确定我们对该域名的所有权。我们只需要在域名管理平台将生成的 TXT 记录名与记录值添加到该域名下，等待大约 1 分钟即可验证成功。 所以，如果对服务器操作方便的话，可以选择文件验证；如果对域名的服务器操作比较方便的话，可以选择 DNS 验证。如果两个都方便的话，请随意选啦。 3）CSR生成默认为离线生成 离线生成、浏览器生成 和 我有 CSR 又有什么区别呢？来，我们继续了解一下。 离线生成 推荐!!!：私钥在本地加密存储，更安全；公钥自动合成，支持常见证书格式转换，方便部署；支持部分 WebServer 的一键部署，非常便捷。 离线生成的时候，需要先安装 KeyManager，可以提供安全便捷的 SSL 证书申请和管理。下载地址如下： https://keymanager.org/ Windows 的话，安装的时候要选择“以管理员身份运行”。 浏览器生成：在浏览器支持 Web Cryptography 的情况下，会使用浏览器根据用户的信息生成 CSR 文件。 Web Cryptography，网络密码学，用于在 Web 应用程序中执行基本加密操作的 JavaScript API。很多浏览器并不支持 我有 CSR：可以粘贴自己的 CSR，然后创建。 第三步，选择离线生成，打开 KeyManager 填写密码后点击「开始」，稍等片刻。 第四步，返回浏览器，点击「下一步」，出现如下界面。 [图片] 第五步，下载文件，并上传至服务器指定目录下。 第六步，点击「验证」，通过后，出现以下界面。 [图片] 第七步，点击「保存到KeyManager」，可以看到证书状态变成了已颁发。 03、为 Tomcat 配置 jks 格式证书 第一步，导出证书。假如服务器选择的 Tomcat，需要导出 Java keystone （简拼为 jks）格式的证书。 [图片] 注意：私钥的密码在配置 Tomcat 的时候用到。 [图片] 第二步，上传证书至服务器。 第三步，配置 Tomcat 的 server.xml。 [代码] <Connector port="81" protocol="HTTP/1.1" maxThreads="250" maxHttpHeaderSize="8192" acceptCount="100" connectionTimeout="60000" keepAliveTimeout="200000" redirectPort="8443" useBodyEncodingForURI="true" URIEncoding="UTF-8" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml,application/xml,application/json,text/javascript,application/javascript,text/css,text/plain,text/json,image/png,image/gif"/> <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="443" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" keystoreFile="/home/backup/qingmiaokeji.cn.jks" keystorePass="Chenmo" clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true" URIEncoding="UTF-8" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla, traviata" compressableMimeType="text/html,text/xml,application/xml,application/json,text/javascript,application/javascript,text/css,text/plain,text/json,image/png,image/gif" /> [代码] 其中 keystorePass 为导出证书时私钥的加密密码。 第四步，重启 Tomcat，并在浏览器地址栏中输入 https://你的域名/ 进行测试。 注意到没，浏览器地址栏前面有一个绿色的安全锁，这说明 HTTPS 配置成功了！好了，为自己鼓个掌！ 04、最后 你有没有订个五分钟的时间沙漏？如果超过五分钟 HTTPS 还没有配置成功，你过来揍我！反正你又打不来我！我在CRMEB等你！ 👇 👇 👇 最后亿遍，再次发一下我的项目：全开源啊！公众号+小程序啊！商城系统啊！免费啊！了解一下啊→→→点我点我！

背景 小程序插件简介小程序插件是可以被开发者添加到小程序内直接使用的，能为用户提供具体服务的功能组件。 插件开发者可像开发小程序一样开发插件，除了在自己的小程序内使用，还能提供给其他小程序直接使用。 插件使用者无需独立开发小程序内的所有服务，无需理解插件内部逻辑和实现方式，可直接使用别人开发好的插件，为用户提供相应服务。 推出小程序插件的原因小程序的初衷是希望更好地连接用户和服务。自上线以来，越来越多的商户、开发者开发自己的小程序。 早晨起来在小区电梯内，扫小程序码，即可叫个早餐外卖； 走到门口，扫共享单车的二维码，骑车即走； 到了公司，即可打开小程序轻松打卡，开始美好的一天上班生活…… 随着小程序的普及，越来越多的路边小摊、餐饮小店、夫妻店也希望接入小程序。许多商家会给我们留言： “我只会简单开发，不会做复杂的功能怎么办？” “我也想给餐馆小程序做一个预约订餐功能，要怎么搞？” “客户可以在我的小程序里查询快递信息吗？” “我没有数据，可以在小程序里做地图查找功能吗？”…… 我们总结出大家目前遇到的几个难题： 1.开发技术有限，实现复杂功能难度大 2.人力、设备、资源有限，实现服务成本高 3.缺乏某些类目的资质，如电商、打车 小程序插件的应用1.开发共享，避免重复开发 在小程序内使用插件，可免去小程序开发者重复开发，一定程度上减少了开发工作量。 如：在旅游景区的小程序可以使用地图插件，开发者无需在小程序内独立开发地图内导航、出行指引、周边服务推荐等能力，直接使用地图插件即可为用户提供导航服务，免去很大量的开发工作。 2.插件可提供针对行业的完整服务，同时覆盖线上线下 商家希望借助小程序更好地连接用户和服务，包括线上、线下服务。线下服务往往人力成本、硬件设备等要求较高，商家在小程序内提供完整服务的门槛较高。而插件不仅可以解决线下服务的问题，还能针对特定行业提供全套完整服务。 以景区服务小程序为例，使用门票购买插件，用户可在小程序内完成门票线上预订、购买等流程，在到达景区后，通过插件服务提供商提供的移动终端或硬件设备，可完成门票兑换、核销。 而对于餐饮、零售等线下行业而言，插件更是极大降低了商家的成本，商家可以使用预订、排队、外卖等插件，由插件开发者提供线下服务，商家只需在小程序内引用插件，即可使用由插件开发者提供的预订、外卖等服务，节省了成本。 3. 降低服务门槛的问题，实现“服务共享” 具有开发能力及服务资质的开发者，可将自己的服务封装成插件，提供给其他小程序使用，实现“服务共享”。 插件的技术原理插件本身的技术原理并不复杂。插件代码由一些自定义组件和 JS 代码文件构成，插件开发者在发布插件时，这些代码被上传到微信后台保存起来。 当小程序使用插件时，使用者需填写插件的 AppID 和版本号，以便从后台获取相应的插件代码。小程序代码编译时，插件代码会被嵌入到小程序中，与小程序一起编译运行。 小程序与插件的交互根据需要，插件代码可以提供 JS 接口或自定义组件供小程序调用。JS 接口可以用于界面无关的逻辑，自定义组件可以嵌入界面中展示。 对于插件使用者来说，插件的调用方法很简单。 1.使用插件 JS 接口 与普通 JS 文件间 [代码]require[代码] 的方式一样，只需要将[代码]require(FILE_NAME)[代码] 改成[代码]requirePlugin(PLUGIN_NAME)[代码] 这样的调用形式。 2.使用插件提供的自定义组件 与使用普通自定义组件的方法非常相似。在[代码]json[代码]文件的 [代码]usingComponents[代码] 段落中，按照[代码]plugin://PLUGIN_NAME/COMPONENT_NAME[代码] 的形式使用即可。 对于插件开发者而言，这里给出几点建议： 1.提供充分的接口文档和示例，方便插件使用者了解插件的使用方法； 2.注意保持插件不同版本间接口的稳定，使插件使用者能顺利升级插件； 3.计算小程序代码包大小时，插件代码也会一并计算在内，所以应当控制好插件代码的大小。 插件代码运行环境插件代码的运行环境与小程序代码有一定的区别，主要是以下两点： 1.插件可以发起网络请求的域名与小程序不同，因此插件开发者需要注意在插件后台的设置中正确配置网络请求域名。 2.插件可以调用的 API 有一定的限制，并不是所有的接口插件都可以调用，如页面跳转相关的接口是不允许插件调用的。插件开发者在使用一些特殊接口前，请查询文档中的插件可调用接口列表。 此外，目前一个小程序最多可使用5个插件，赶紧将插件用起来，节约开发者成本吧。 详情可参考《小程序插件接入指南》。

小程序的界面是由一系列组件构成的。小程序基础库提供了一组基础组件来满足开发者的基本需求。但随着小程序开发变得越来越复杂，单纯使用基础组件来进行开发也变得越来越不方便。 例如，较为复杂的小程序中常常会有一些通用的交互模块，比如“下拉选择列表”、“搜索框”、“日期选择器”等。这些界面交互模块可能会在多个页面中用到，逻辑也相对独立。然而，用传统的小程序开发方法来实现这样的模块是非常繁琐的。 面对这个情况，小程序基础库提供了让开发者自己创建界面组件的特性，称之为“自定义组件”。通过这个特性，开发者就能够将这样的交互模块抽象成界面组件，使界面代码组织变得非常灵活。 01 [图片]开发者可以将一些复用性强的代码抽象成自定义组件，它们的使用方法与基础库内置的 view 、 button等基础组件非常相似。这样的组件化非常有利于代码逻辑的解耦合。 02 [图片]自定义组件局部更新时的性能相比页面的局部更新要小很多，在必要时可以利用这个特点进行性能优化。 03 [图片]自定义组件是相对独立的功能模块，开发者可以将自己的自定义组件代码开源出来，与其他开发者共享开发成果。 如何编写一个自定义组件？ 每个自定义组件由四个代码文件组成：  json文件    用于于放置一些最基本的组件配置  wxml 文件    组件模版  wxss 文件    组件的样式，只在组件内部节点上生效（这个文件是可选的） js 文件  组件的 JS 代码，承载组件的主要逻辑 这四个文件与编写一个页面时用到的四个文件非常类似，但也有区别。下面将介绍如何利用这四个文件编写一个简单的自定义组件。 1.组件配置 编写一个自定义组件，首先应在小程序代码目录中合适的位置创建一个 json 文件。这里我们把文件放置在小程序的 components目录下，名为 custom-checkbox.json 。 [图片] 这个文件中包含以下内容： [图片] 2.组件模板 在同一目录下，创建一个模版文件 custom-checkbox.wxml 。这个文件的写法与页面模版很类似： [图片] 这个模版将在组件中渲染出一个 checkbox 和一个 label 。 3.组件样式 同样类似于页面， wxss 文件中可以指定组件节点的样式。其中的样式仅在组件内部生效。需要注意的是，样式只能通过类选择器（如 .the-class-name ）来指定： [图片] 4.组件定义 组件的 JS 文件中必须包含组件定义。定义时使用 Component 构造器： [图片] 简单的 Component 构造器调用包含3个定义段： methods 中的方法可以用来包含组件的事件回调函数； data 是组件的内部数据，可以用 this.setData 方法来改变； properties 中声明这个组件的属性，上例中声明了 title 属性，这样，组件外部在使用组件时就可以指定这个属性的值。 这样我们就编写好了 custom-checkbox 这个组件。 如何使用自定义组件？ 使用上面这个自定义组件的方法很简单。 Step 1 在需要使用这个组件的页面所对应的 json 文件中，添加下面的自定义组件声明： [图片] Step 2 在页面对应的 wxml 文件中使用了： [图片] 这样，在页面上最终呈现的效果如下： [图片] 在自定义组件中也是可以引用其他自定义组件的，方法与在页面中引用的方法类似。 高级特性与注意事项 除了上述的基本功能外，自定义组件还提供了一组基础接口，用来实现各种各样的功能。 01 [图片]在页面和自定义组件间通信时，最常用的方法是事件机制，自定义组件可以使用 triggerEvent 接口向页面发送事件，页面 WXML 中使用 bind 或者 catch 就可以监听到。 02 [图片]如果事件机制还不足以满足组件间通信需要的话，可以使用  selectComponent 接口。 03 [图片]如果同时建立了好几个有相互关联关系的组件，可以使用组件间关系接口 relations 。 04 [图片]组件间可能需要共享部分代码，这时可以使用behaviors 。 有关它们的详细文档，请参考 开发者文档 - 框架 - 自定义组件 章节。 还需要注意的是，一些与 WXML 节点相关的接口，如wx.createSelectorQuery  、 wx.createCanvasContext ，在自定义组件中使用时有一定的变化，使用时请再次阅读一下相关的文档。

在「小程序 · 小故事」的第一期，我们曾和大家一起分享过「分包加载」的故事。随着小程序功能越来越多样，页面也越来越多，但不同页面的访问频率是有一定差异的。 分包加载允许开发者将小程序划分为主包和若干个分包，将较少用到的页面或功能划分到若干个分包中，主包内只保留最频繁使用的页面和公共的代码。小程序启动时默认只加载主包，再按需加载分包。这一机制保证了在小程序包大小增加的情况下，依然能保持良好的启动速度。 为满足小程序承载的功能不断丰富的需要，小程序的代码包大小上限已提高到 8M。随着小程序应用场景和使用范围的扩大，在实践中，我们发现分包加载仍有一定的局限性。尤其是越来越多的 H5 服务迁移到小程序后，对于小程序的启动速度有更高要求。为了更好的提升小程序的加载速度和使用体验，小程序近期开放了「独立分包」和「分包预下载」两个新的能力，进一步丰富了分包加载的功能和使用场景。 01独立分包 1  技术背景 由于技术实现的差异，小程序首次启动时需要进行代码包的下载，因此在启动性能上与网页相比有一定劣势。通过对小程序启动耗时的分析，我们发现代码包大小对小程序启动速度是有最直接的影响。 一方面，代码包越大，下载时间就越长； 另一方面，代码包越大，通常意味着小程序页面结构和代码逻辑复杂，启动时代码注入执行的时间越长。 采用分包加载一定程度上解决了代码包下载耗时过长的问题。但小程序中的某些场景（如广告页、活动页、支付页等），通常功能不是很复杂且相对独立，对启动性能有很高的要求。在现有方案中，启动这一页面需要依赖整个主包的下载，如果页面在分包中，还需等待分包的下载，启动性能有严重的瓶颈。此时如果依赖开发者进行代码重构，重新分包，不仅工作量大，而且会影响其他分包的使用体验。为了解决这一问题，我们提出了「独立分包」方案。 2  功能简介 独立分包是小程序中一种特殊类型的分包，可以独立于主包和其他分包运行。从独立分包中页面进入小程序时，不需要下载主包。当用户进入普通分包或主包内页面时，主包才会被下载。 开发者可以将部分对启动性能要求很高的页面放到特殊的独立分包中。当小程序从独立分包页面启动时，只需要下载分包就可以直接运行，可以很大程度上提高分包页面的启动速度，实现小程序的秒开。 [图片] 由于小游戏中没有页面的概念，也没有小程序中多种入口的使用场景，因此小游戏目前没有支持独立分包。 3  配置方法 独立分包的配置方法十分简单，只需要在原有分包配置的基础上定义 independent 字段，即可将一个分包设置为独立分包，例如： [图片] 4  使用限制 独立分包虽然属于分包的一种，但其不依赖主包独立使用，因此在加载流程和运行环境上与普通分包相比有一些差异。除了分包本身的限制外，独立分包还有以下限制： ● 独立分包中不能依赖主包和其他分包中的内容，包括 js 文件、模板、wxss、自定义组件等； ● App 只能在主包内定义，独立分包中不能定义 App，会造成无法预期的行为； ●  独立分包中暂时不支持使用插件。 为了小程序有更好的使用体验，我们不建议开发者把过多的小程序逻辑放置到独立分包中，也不建议在小程序中过度的使用独立分包，例如把每个页面都放到一个独立分包中。 关于独立分包的详细内容请参见 独立分包 · 小程序 02 分包预下载 1  技术背景 在使用「分包加载」后，虽然能够显著提升小程序的启动速度，但是当用户在使用小程序过程中跳转到分包内页面时，需要等待分包下载完成后才能进入页面，造成页面切换的延迟，影响小程序的使用体验。分包预下载便是为了解决首次进入分包页面时的延迟问题而设计的。如果能够在用户进入分包页面之前就预先将分包下载完毕，那么进入分包页面的延迟就能够尽可能降低。 此前，小游戏中已经提供了「基于API」的分包预下载能力。在设计小程序分包预下载能力时，我们设计了「基于配置」和「基于API」两种分包预下载形式，「基于配置」的方式使用简单，且便于对预下载的使用情况进行控制，防止开发者滥用；「基于API」的方式使用起来更灵活，能够动态的调整预下载策略。综合考虑用户的使用感受和内测阶段第三方开发者的反馈后，我们最终决定首先推出「基于配置」的分包预下载能力。 2  功能简介 开发者可以预先配置某个页面可能会跳转到的分包（对于独立分包，也可以预下载主包），在进入小程序某个页面时，由基础库在后台自动预下载可能需要的分包。用户在进行页面跳转时，分包通常已经下载完成，不需要额外等待，可以有效提升进入后续分包页面时的启动速度。此外，考虑到用户的流量和存储空间，小程序也会对预下载的大小和网络进行一定的限制。 [图片] 3  配置方法 开发者可以通过在 app.json 中增加 preloadRule 字段，控制进入某个页面时进行预下载的分包，并设置触发预下载的网络环境。 [图片] [图片] 4  使用限制 对于手机用户而言，数据流量和存储空间是非常重要的资源。一方面，分包预下载能够提升小程序用户的使用体验；另一方面，过度的预下载也会破坏分包按需使用的原则，过度的占用用户的存储空间，消耗数据流量。如果开发者每次启动小程序时都将所有分包进行下载，会消耗很多不必要的流量和存储空间。 为了在分包预下载的效果和对用户资源的消耗上取得平衡，我们限制了同一个分包中的页面预下载总大小不得超过2M，并鼓励开发者按需设置分包预下载的网络条件。 关于独分包预下载详细内容请参见 分包预下载 · 小程序 03 小结 独立分包与分包预下载进一步丰富了分包加载的功能，大大拓展了分包加载的使用场景。同时，独立分包和分包预下载是相辅相成的，配合使用可以获得更好的效果。 例如，开发者可以将一个活动推广页放到一个独立分包中，利用独立分包的特性能够提升活动页面的加载速度，提升转化率。在页面中开发者可以引导有需要的用户跳转到小程序其他页面，使用小程序的更丰富的功能。在这一过程中，可以利用分包预下载能力，将主包或相关分包进行预下载，降低页面跳转的延迟，留住更多用户。 开发者在使用这两个新能力的过程中，如果遇到问题或者有什么建议，欢迎在微信开放社区（https://developers.weixin.qq.com）进行反馈，我们会根据开发者的反馈，不断的优化和丰富分包加载功能，减少功能限制，提升小程序的加载性能和使用体验。

最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？ 作为 Taro 开发团队一员，笔者想在本文尽量站在一个客观公正的角度去评价各个框架的选型和优劣。但宥于利益相关，本文的观点很可能是带有偏向性的，大家可以带着批判的眼光去看待，权当抛砖引玉。 那么，当我们在讨论多端框架时，我们在谈论什么： 多端 笔者以为，现在流行的多端框架可以大致分为三类： 1. 全包型 这类框架最大的特点就是从底层的渲染引擎、布局引擎，到中层的 DSL，再到上层的框架全部由自己开发，代表框架是 Qt 和 Flutter。这类框架优点非常明显：性能（的上限）高；各平台渲染结果一致。缺点也非常明显：需要完全重新学习 DSL（QML/Dart），以及难以适配中国特色的端：小程序。 这类框架是最原始也是最纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能最大可能地去保证开发和跨端体验一致。但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。 2. Web 技术型 这类框架把 Web 技术（JavaScript，CSS）带到移动开发中，自研布局引擎处理 CSS，使用 JavaScript 写业务逻辑，使用流行的前端框架作为 DSL，各端分别使用各自的原生组件渲染。代表框架是 React Native 和 Weex，这样做的优点有： 开发迅速 复用前端生态 易于学习上手，不管前端后端移动端，多多少少都会一点 JS、CSS 缺点有： 交互复杂时难以写出高性能的代码，这类框架的设计就必然导致 [代码]JS[代码] 和 [代码]Native[代码] 之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得 UI 无法在 16ms 内及时绘制。React Native 有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。 由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有第一种高。 3. JavaScript 编译型 这类框架就是我们这篇文章的主角们：[代码]Taro[代码]、[代码]WePY[代码] 、[代码]uni-app[代码] 、 [代码]mpvue[代码] 、 [代码]chameleon[代码]，它们的原理也都大同小异：先以 JavaScript 作为基础选定一个 DSL 框架，以这个 DSL 框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。 这类框架最大优点和创造的最大原因就是小程序，因为第一第二种框架其实除了可以跨系统平台之外，也都能编译运行在浏览器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 [代码]react-native-web[代码], Weex 原生支持) 另外一个优点是在移动端一般会编译到 React Native/Weex，所以它们也都拥有 Web 技术型框架的优点。这看起来很美好，但实际上 React Native/Weex 的缺点编译型框架也无法避免。除此之外，编译型框架的抽象也不是免费的：当 bug 出现时，问题的根源可能出在运行时、编译时、组件库以及三者依赖的库等等各个方面。在 Taro 开源的过程中，我们就遇到过 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，当然也少不了 Taro 本身的 bug。相信其它原理相同的框架也无法避免这一问题。 但这并不意味着这类为了小程序而设计的多端框架就都不堪大用。首先现在各巨头超级 App 的小程序百花齐放，框架会为了抹平小程序做了许多工作，这些工作在大部分情况下是不需要开发者关心的。其次是许多业务类型并不需要复杂的逻辑和交互，没那么容易触发到框架底层依赖的 bug。 那么当你的业务适合选择编译型框架时，在笔者看来首先要考虑的就是选择 DSL 的起点。因为有多端需求业务通常都希望能快速开发，一个能够快速适应团队开发节奏的 DSL 就至关重要。不管是 React 还是 Vue（或者类 Vue）都有它们的优缺点，大家可以根据团队技术栈和偏好自行选择。 如果不管什么 DSL 都能接受，那就可以进入下一个环节： 生态 以下内容均以各框架现在（2019 年 3 月 11日）已发布稳定版为标准进行讨论。 开发工具 就开发工具而言 [代码]uni-app[代码] 应该是一骑绝尘，它的文档内容最为翔实丰富，还自带了 IDE 图形化开发工具，鼠标点点点就能编译测试发布。 其它的框架都是使用 CLI 命令行工具，但值得注意的是 [代码]chameleon[代码] 有独立的语法检查工具，[代码]Taro[代码] 则单独写了 ESLint 规则和规则集。 在语法支持方面，[代码]mpvue[代码]、[代码]uni-app[代码]、[代码]Taro[代码] 、[代码]WePY[代码] 均支持 TypeScript，四者也都能通过 [代码]typing[代码] 实现编辑器自动补全。除了 API 补全之外，得益于 TypeScript 对于 JSX 的良好支持，Taro 也能对组件进行自动补全。 CSS 方面，所有框架均支持 [代码]SASS[代码]、[代码]LESS[代码]、[代码]Stylus[代码]，Taro 则多一个 [代码]CSS Modules[代码] 的支持。 所以这一轮比拼的结果应该是： [代码]uni-app[代码] > [代码]Taro[代码] > [代码]chameleon[代码] > [代码]WePY[代码]、[代码]mpvue[代码] [图片] 多端支持度 只从支持端的数量来看，[代码]Taro[代码] 和 [代码]uni-app[代码] 以六端略微领先（移动端、H5、微信小程序、百度小程序、支付宝小程序、头条小程序），[代码]chameleon[代码] 少了头条小程序紧随其后。 但值得一提的是 [代码]chameleon[代码] 有一套自研多态协议，编写多端代码的体验会好许多，可以说是一个能戳到多端开发痛点的功能。[代码]uni-app[代码] 则有一套独立的条件编译语法，这套语法能同时作用于 [代码]js[代码]、样式和模板文件。[代码]Taro[代码] 可以在业务逻辑中根据环境变量使用条件编译，也可以直接使用条件编译文件（类似 React Native 的方式）。 在移动端方面，[代码]uni-app[代码] 基于 [代码]weex[代码] 定制了一套 [代码]nvue[代码] 方案 弥补 [代码]weex[代码] API 的不足；[代码]Taro[代码] 则是暂时基于 [代码]expo[代码] 达到同样的效果；[代码]chameleon[代码] 在移动端则有一套 SDK 配合多端协议与原生语言通信。 H5 方面，[代码]chameleon[代码] 同样是由多态协议实现支持，[代码]uni-app[代码] 和 [代码]Taro[代码] 则是都在 H5 实现了一套兼容的组件库和 API。 [代码]mpvue[代码] 和 [代码]WePY[代码] 都提供了转换各端小程序的功能，但都没有 h5 和移动端的支持。 所以最后一轮对比的结果是： [代码]chameleon[代码] > [代码]Taro[代码]、[代码]uni-app[代码] > [代码]mpvue[代码]、[代码]WePY[代码] [图片] 组件库/工具库/demo 作为开源时间最长的框架，[代码]WePY[代码] 不管从 Demo，组件库数量 ，工具库来看都占有一定优势。 [代码]uni-app[代码] 则有自己的插件市场和 UI 库，如果算上收费的框架和插件比起 [代码]WePy[代码] 也是完全不遑多让的。 [代码]Taro[代码] 也有官方维护的跨端 UI 库 [代码]taro-ui[代码] ，另外在状态管理工具上也有非常丰富的选择（Redux、MobX、dva），但 demo 的数量不如前两个。但 [代码]Taro[代码] 有一个转换微信小程序代码为 Taro 代码的工具，可以弥补这一问题。 而 [代码]mpvue[代码] 没有官方维护的 UI 库，[代码]chameleon[代码] 第三方的 demo 和工具库也还基本没有。 所以这轮的排序是： [代码]WePY[代码] > [代码]uni-app[代码] 、[代码]taro[代码] > [代码]mpvue[代码] > [代码]chameleon[代码] [图片] 接入成本 接入成本有两个方面： 第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 [代码]wxparse[代码]、[代码]echart[代码]、[代码]zan-ui[代码] 等）多是基于原生微信小程序框架语法写成的。目前看来 [代码]uni-app[代码] 、[代码]Taro[代码]、[代码]mpvue[代码] 均有文档或 demo 在框架中直接使用原生小程序组件/库，[代码]WePY[代码] 由于运行机制的问题，很多情况需要小改一下目标库的源码，[代码]chameleon[代码] 则是提供了一个按步骤大改目标库源码的迁移方式。 第二是原有微信小程序项目部分接入框架重构。在这个方面 Taro 在京东购物小程序上进行了大胆的实践，具体可以查看文章《Taro 在京东购物小程序上的实践》。其它框架则没有提到相关内容。 而对于两种接入方式 Taro 都提供了 [代码]taro convert[代码] 功能，既可以将原有微信小程序项目转换为 Taro 多端代码，也可以将微信小程序生态的组件转换为 Taro 组件。 所以这轮的排序是： [代码]Taro[代码] > [代码]mpvue[代码] 、 [代码]uni-app[代码] > [代码]WePY[代码] > [代码]chameleon[代码] 流行度 从 GitHub 的 star 来看，[代码]mpvue[代码] 、[代码]Taro[代码]、[代码]WePY[代码] 的差距非常小。从 NPM 和 CNPM 的 CLI 工具下载量来看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但发布时间也刚好反过来。笔者估计三家的流行程度和案例都差不太多。 [代码]uni-app[代码] 则号称有上万案例，但不像其它框架一样有一些大厂应用案例。另外从开发者的数量来看也是 [代码]uni-app[代码] 领先，它拥有 20+ 个 QQ 交流群（最大人数 2000）。 所以从流行程度来看应该是： [代码]uni-app[代码] > [代码]Taro[代码]、[代码]WePY[代码]、[代码]mpvue[代码] > [代码]chameleon[代码] [图片] 开源建设 一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。 从第三方贡献者数量来看，[代码]Taro[代码] 在这一方面领先，并且 [代码]Taro[代码] 的一些核心包/功能（MobX、CSS Modules、alias）也是由第三方开发者贡献的。除此之外，腾讯开源的 [代码]omi[代码] 框架小程序部分也是基于 Taro 完成的。 [代码]WePY[代码] 在腾讯开源计划的加持下在这一方面也有不错的表现；[代码]mpvue[代码] 由于停滞开发了很久就比较落后了；可能是产品策略的原因，[代码]uni-app[代码] 在开源建设上并不热心，甚至有些部分代码都没有开源；[代码]chameleon[代码] 刚刚开源不久，但它的代码和测试用例都非常规范，以后或许会有不错的表现。 那么这一轮的对比结果是： [代码]Taro[代码] > [代码]WePY[代码] > [代码]mpvue[代码] > [代码]chameleon[代码] > [代码]uni-app[代码] 最后补一个总的生态对比图表： [图片] 未来 从各框架已经公布的规划来看： [代码]WePY[代码] 已经发布了 [代码]v2.0.alpha[代码] 版本，虽然没有公开的文档可以查阅到 [代码]2.0[代码] 版本有什么新功能/特性，但据其作者介绍，[代码]WePY 2.0[代码] 会放大招，是一个「对得起开发者」的版本。笔者也非常期待 2.0 正式发布后 [代码]WePY[代码] 的表现。 [代码]mpvue[代码] 已经发布了 [代码]2.0[代码] 的版本，主要是更新了其它端小程序的支持。但从代码提交， issue 的回复/解决率来看，[代码]mpvue[代码] 要想在未来有作为首先要打消社区对于 [代码]mpvue[代码] 不管不顾不更新的质疑。 [代码]uni-app[代码] 已经在生态上建设得很好了，应该会在此基础之上继续稳步发展。如果 [代码]uni-app[代码] 能加强开源开放，再加强与大厂的合作，相信未来还能更上一层楼。 [代码]chameleon[代码] 的规划比较宏大，虽然是最后发的框架，但已经在规划或正在实现的功能有： 快应用和端拓展协议 通用组件库和垂直类组件库 面向研发的图形化开发工具 面向非研发的图形化页面搭建工具 如果 [代码]chameleon[代码] 把这些功能都做出来的话，再继续完善生态，争取更多第三方开发者，那么在未来 [代码]chameleon[代码] 将大有可为。 [代码]Taro[代码] 的未来也一样值得憧憬。Taro 即将要发布的 [代码]1.3[代码] 版本就会支持以下功能： 快应用支持 Taro Doctor，自动化检查项目配置和代码合法性 更多的 JSX 语法支持，1.3 之后限制生产力的语法只有 [代码]只能用 map 创造循环组件[代码] 一条 H5 打包体积大幅精简 同时 [代码]Taro[代码] 也正在对移动端进行大规模重构；开发图形化开发工具；开发组件/物料平台以及图形化页面搭建工具。 结语 那说了那么多，到底用哪个呢？ 如果不介意尝鲜和学习 DSL 的话，完全可以尝试 [代码]WePY[代码] 2.0 和 [代码]chameleon[代码] ，一个是酝酿了很久的 2.0 全新升级，一个有专门针对多端开发的多态协议。 [代码]uni-app[代码] 和 [代码]Taro[代码] 相比起来就更像是「水桶型」框架，从工具、UI 库，开发体验、多端支持等各方面来看都没有明显的短板。而 [代码]mpvue[代码] 由于开发一度停滞，现在看来各个方面都不如在小程序端基于它的 [代码]uni-app[代码] 。 当然，Talk is cheap。如果对这个话题有更多兴趣的同学可以去 GitHub 另行研究，有空看代码，没空看提交： chameleon: https://github.com/didi/chameleon mpvue: https://github.com/Meituan-Dianping/mpvue Taro: https://github.com/NervJS/taro uni-app: https://github.com/dcloudio/uni-app WePY: https://github.com/Tencent/wepy (按字母顺序排序)

在微信小程序/小游戏的开发中，网络传输主要是依靠http的短连接和webSocket 长连接来完成的。 在一般web服务中，大多使用短连接来向服务器请求资源，与服务器的交互频率低，次数少。而在一些需要与服务器交互频繁，需要及时收到服务器推送的场景，比如直播、多人实时游戏，更适合使用 webSocket 进行通讯。 这次的小故事主要分享 webSocket 在微信小程序/小游戏开发上的一些经验。 长连的生命周期介绍 webSocket的生命周期一共有4个状态：connecting、open、closing、closed。我们可以通过 socketTask 的 readyState 属性来获取当前 webSocket 长连的状态。webSocket 的生命周期过程和 API 间的调用关系可以简单的入下图所示。 [图片] 注意：只有长连处在 open 状态，才能够正常的收发消息，其他状态均会报错。 客户端长连的断开机制 当小游戏进入到后台运行超过5秒时，客户端会禁止小游戏的所有网络连接。这是一个非常频繁的断线逻辑，十分考验程序断线错误处理逻辑。建议大家可以在用户点击右上角按钮退出小程序/小游戏时，主动帮用户断线，待用户切回时再重接上去。   当 webSocket 长连超过一段时间没有任何网络传输时，客户端会主动关闭这条长连，以节省资源。开发者可以设置业务心跳，每隔一段时间与后台进行一次通讯，维持长连。 如何选择长连的接口 API接口主要有两类，一类是前缀为 “wx” 的接口，一类 “socketTask” 的接口。举例，同样是连接长连后发送一条消息，两种写法区别如下。 [图片] 最初小游戏只允许存在1个 webSocket 连接时，并没开放 socketTask 的管理方式。随着小游戏的能力提升，可支持同时存在的 webSocket 连接个数变多，在使用 wx.connectSocket 创建 webSocket 连接时会返回 socketTask 任务对象，便于去管理每一条连接链路。   推荐开发者尽量使用 socketTask 的方式去管理 webSocket 链接，每一条链路的生命周期都更加可控。同时存在多个 webSocket 的链接的情况下使用 wx 前缀的方法可能会带来一些和预期不一致的情况。例如：当存在多条连接时，wx.onSocketOpen、wx.sendSocketMessage、wx.onSocketMessage 等接口会只作用于第一条连接的长连。且wx.onSocketOpen 接口不能多次注册 webSocket 长连的回调函数，仅最后一次生效。使用 socketTask 任务的方式则不会出现上述问题。 开发与调试的建议 01微信提供了 webSocket 最基础的接口能力，开发者可以在其基础上进行封装，根据业务需要扩展能力。比如封装一个 offSocketOpen 的方法来取消注册 socketOpen 的回调函数。 02 长连并没有像短连那样“一问一答”的交互形式。在某些场景下，开发者需要这种与服务器的交互。建议前端与后台协议，每条客户端上行的信息，服务器都下发一个对应的回包，去“模拟短连”。比如开发者向服务器询问1+1和1+2等于多少，服务器返回了3和2，便可清晰知道哪一个数字对应着哪一个请求的答案。此外，还可以设置业务超时逻辑，便于判断上传是否丢包 03 在 webSocket 发送数据时，数据格式可以选择string或者ArrayBuffer。这里要注意的是，由于小游戏禁止了 Function() 和 eval()语法。所以像 protobufjs 这类用了这些语法的库是不能直接拿来用的。 04 在测试调试长连的时，目前开发者工具不支持通过设置 offline 模拟长连断网的情况（短连是支持的），所以在测试断线重连的一些情况时，可以辅助一些第三方工具，或者用真机调试以及“拔网线”的方式来测试。 05 在进行多人游戏测试时，在开发者工具中熟练使用“自定义编译条件”，以及“多账号调试”这两个功能可以极大的提升开发测试效率。 06 长连占用的系统资源，会导致手机发热比较明显。所以在不需要使用 webSocket 的场景下，建议及早断开长连，需要时再连接。 异常断线的监控 监控长连是否异常断线，在长连的使用中，尤其在小游戏多人对战中是尤为重要的。socketError 事件并不能认为是异常断线。 首先 socketError 事件并不一定会导致断线，其次若是由客户端机制断开的长连，是不会触发 socketError 事件的。   最简单的方式可以通过 onClose 回调函数触发时系统传入的 code 是否为1000来判断。当然开发者自身也可以通过代码判断是否是自身调用的 close 函数触发的 onclose 事件，监控异常断线。 希望大家在实际应用中能帮助到到大家。