微信网页授权 能力是为了优化用户在微信内登录网站应用的体验而设计的。为进一步规范能力使用，保障用户合法权益，平台将对能力进行调整。  当开发者在网页中在不规范使用发起 snsapi_userinfo 网页授权时，微信将默认打开网页快照页模式进行基础浏览。能力调整将于 2022 年 7 月 12 日 24 时生效。 网页快照页模式介绍快照页将会默认对用户屏蔽网页授权弹窗，用户在快照页中仅可进行滑动浏览操作，其他交互将被限制，并提示用户 “该网页需获取个人信息才可使用完整服务，当前仅可浏览部分内容”。用户如需要使用完整网页服务，可轻触右下角 “使用完整服务” 按钮触发授权弹窗，用户确认后进入原网页。 开发者在快照页内所获取的头像、昵称、openId、unionId 均为虚拟账号数据；快照页与正常页面不共用缓存，快照页的缓存会在用户离开快照页时被清理；快照页内也无法使用微信其它 JS-SDK 的能力。 [图片] 微信网页授权规范授权流程需引导清晰、准确：在申请获取用户信息的弹窗出现前，应该清晰、准确地告知用户获取信息的范围及获取信息的目的；必要场景申请：在必须获取用户信息时才申请，而不是用户尚未了解服务前就强制弹窗。如使用医院挂号时才需要获取用户信息；不强制登录：提供游客模式，供用户了解网页提供的基础服务，不强制用户允许网页获取用户信息后才能使用网页服务。 常见的微信网页授权不规范使用案例强制登录：在用户打开网页时立即要求用户授权，用户拒绝后无法使用网页提供的服务；违规收集个人信息：未在网页提前告知使用个人信息的目的、方式和范围；非必要收集：非必要获取用户信息的网页，如文章、视频等，要求用户在浏览内容前登录；差别对待微信用户：同样的网页在浏览器内可以无需登录直接访问，在微信内却要求用户先登录才可访问。 微信团队 2022年5月9日

为进一步规范开发者调用涉用户信息相关接口或功能，保障用户合法权益，平台将对如下地理位置相关接口调用实行准入开通： wx.getLocation、wx.onLocationChange、wx.chooseAddress、wx.chooseLocation、wx.choosePoi 自2022年4月18日开始，如使用以上接口，在代码审核环节将检测该接口是否已完成准入开通（申请路径：小程序管理后台 -「开发」-「开发管理」-「接口设置」），如未开通，将在代码提审环节进行拦截，请涉及相关接口的开发者尽快进行接口权限申请，第三方开发者申请方式：可通过 apply_privacy_interface 接口完成。 请广大涉及相关接口的开发者尽快进行相关接口准入申请，如未申请，后续将影响线上小程序相关接口的使用。

下载地址Windows 64、Window 32、MacOS、MacOS(M1) 1、真机性能分析工具 新增 真机性能分析工具 可用于分析真机运行的小程序的性能数据（例如CPU Profiler\ Memory Heapsnapshot），可以用于排查内存泄漏等性能问题。注意，需要使用 微信客户端安卓开发者版 ，同时跟工具处于同一局域网才能进行性能数据的录制。 通过 菜单 - 工具 - 真机性能分析工具 可以唤起真机性能工具的二维码弹窗。 [图片] 使用 微信客户端安卓开发者版 扫码之后可以打开真机性能分析工具弹窗，继而进行性能数据录制与分析。详细文档参考 《真机性能分析工具》 [图片] 2、M1支持 工具新增原生 macOS ARM64 版本支持，性能相较转译版本有较大提升，占用内存更小。 下载地址：https://dldir1.qq.com/WechatWebDev/beta/wechat_devtools_1.05.2107221.arm64.dmg 3、工具自定义主题开发者工具可以在编辑器切换主题时适配其外观，也可以在外观设置中直接对配色进行修改。 [图片] 4、导入编辑器扩展如需安装已解包的编辑器扩展，可以在扩展里导入。 [图片] 5、项目打开不加载编辑器 通过设置，编辑器可以在项目打开时默认不加载并隐藏起来，在需要时载入。 [图片] 修复以下 Bug[代码]F[代码] 修复 小游戏项目使用本地插件时报错的问题[代码]F[代码] 修复 WXML 面板自定义组件不显示 externalClass 的问题[代码]F[代码] 修复切换代码片段项目类型提示的 appid 列表类型不对的问题[代码]F[代码] 修复 真机调试时出现 [代码]U.createEvent[代码] 报错，现在会显示真正的报错信息[代码]F[代码] 修复 部分项目使用增强编译后，因压缩问题导致代码包体积变大。[代码]F[代码] 修复 需要编译两次才会执行最新的代码的问题 [代码]F[代码] 修复 调试器 sources 面板 snippet 断点符号不显示[代码]F[代码] 修复 局部编译下 wxml 编译报错的bug [代码]F[代码] 修复 编译模式弹窗样式[代码]F[代码] 修复 无法获取客户端 trace 文件的问题[代码]F[代码] 修复 工具菜单导入项目&导入代码片段部分问题[代码]F[代码] 修复 调试时进入 WAService.js 卡死的问题[代码]F[代码] 修复 视频播放无声音的问题 [代码]F[代码] 修复 弹窗调试器网址清空的问题[代码]F[代码] 修复 云同步设置关闭不了的问题[代码]F[代码] 修复 真机调试下修改 window 属性报错的问题[代码]F[代码] 修复 windows 点立即更新后工具消失没有弹出安装程序的问题[代码]F[代码] 修复 开发者工具可能会进入 vim 状态的问题[代码]F[代码] 修复 WXML 面板选择器包含 body 会被替换为 page 的问题 [代码]F[代码] 修复 版本管理内右键菜单可能出现无效项目的问题[代码]F[代码] 新增 支持调试[代码]wx.onLocationChange[代码]，可通过修改调试器sensor里的location信息触发更新[代码]F[代码] 修复 局部编译的bug[代码]F[代码] 修复 MacOS 12工具crash闪退问题[代码]F[代码] 修复 Mac 自动真机调试后扫码真机调试白屏[代码]F[代码] 修复 代码片段基础库列表加载问题[代码]F[代码] 修复 修复真机调试加载独立分包的问题[代码]F[代码] 修复 rc 升级上来后快速回退到1.05.2104251失败[代码]F[代码] 修复 修复JS 编译为 ES5逻辑错误的bug[代码]F[代码] 修复 小程序workers增强编译报错的问题 

服务号模板消息能力的设计初衷，旨在帮助开发者实现及时通知，但存在一些问题，如： 1. 部分开发者在用户无预期的情况下，发送与用户无关的信息，对用户造成了骚扰。 2. 模板消息是用户触发后的通知消息，不支持营销类消息，不能满足部分业务需求。 为提升微信用户体验，我们开始灰度测试服务号订阅通知功能。 能力说明 开发者可在服务号图文消息、网页等场景设置订阅功能，用户自主订阅后，开发者可按需求下发一条对应的订阅通知。 [图片] 用户可在图文订阅通知 [图片] 用户可在网页订阅通知 灰度测试计划 服务号订阅通知功能即日上线，已认证的境内主体服务号可前往 MP 后台开通使用，详见说明。 1. 服务号订阅通知灰度测试期自2021年1月27日0:00至4月30日24:00，期间服务号模板消息可正常使用；灰度测试期结束后服务号订阅通知的策略将另行公布，届时以官方信息为准； 2. 开发者使用订阅通知功能时，需遵循运营规范，不可用奖励或其它形式强制用户订阅，不可下发与用户预期不符或违反国家法律法规的内容。具体可参考文档：《微信公众平台运营规范》 微信团队 2021年1月27日

在使用wxParse解析富文本（HTML内容）时，当一次解析的视频超过5个视频，例如上传六个视频，解析出来后第一个视频无法播放，第二个到第六个都是可以正常播放的；如果上传七个视频，那么就是前两个视频播放不了，之后的5个可以播放。 请各位大佬帮帮小子，被这个问题搞得很头疼。

了解到网页版已支持，想咨询下小程序版有计划吗？？？ [图片] 网页版：https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/DarkMode.html

各位微信开发者： 以下是新版微信开发者内部体验邀请及上周小程序相关能力更新及我们在社区收到的问题反馈、需求的处理进度，希望同大家一同打造小程序生态。 微信团队邀请开发者参与内部体验（安卓微信7.0.10）  [本次更新概要如下] 小程序开发： 1、优化小程序代码包下载速度； 2、优化小程序启动流程。 小游戏开发： 1、文件系统替换。关注重点：文件增删改查； 2、小游戏录屏播放界面对齐iOS，卡片展示样式对齐iOS。关注重点：小游戏录屏分享卡片是否正常，播放界面是否正常； 3、download 和 request 底层组件替换。关注重点：网络请求是否正常； 4、图片加载增加超时限制，优化线程调度。关注重点：Image 对象加载是否正常； 5、上版本Bug修复：a. Fix部分情况下帧率过高 b. 2D 场景截屏黑屏 c. crash 修复。   扫描下方二维码下载体验。使用过程中若发现问题，欢迎在本帖下方留言或在社区发表标题包含「微信7.0.10」的问答帖子进行反馈。 [图片] 上周问题反馈和处理进度（12.09-12.13）已修复的问题某些安卓机型下 previewImage 预览出现黑屏的问题 查看详情  chooseVideo 在安卓下 maxDuration 参数不生效的问题 查看详情  页面存在多个 video 时会自动播放的问题 查看详情  微信内未授权过语音时，camera组件语音授权没有入口的问题 查看详情 iOS 下用 scanCode 扫码闪退的问题 查看详情  安卓 Canvas fillRect 不支持负值的问题 查看详情 安卓Canvas drawImage 绘制网络图片性能差的问题 查看详情 chooseVideo 视频时长较长时会息屏的问题 查看详情  安卓 canvas 移到画布外不触发 touchend 的问题 查看详情  原生 tabBar 在没有文本时可以垂直居中的问题 查看详情  iOS chooseVideo 录像预览时模糊不聚集的问题 查看详情 安卓下 Camera onCameraFrame 接口在安卓下偶现左右翻转的问题 查看详情 安卓 uploadFile 无法上传无后缀的文件的问题 查看详情  hideTabBar 在非 tabBar 页面调用没有拦掉的问题 查看详情 安卓下 chooseVideo 压缩后较模糊的问题 查看详情  iOS 横屏状态下获取的状态栏高度不为0 的问题 查看详情  安卓web-view内调用window.close会退出小程序的问题 查看详情  iOS 下 map 结合 cover-view 导致闪退的问题 查看详情 地图同层点击marker导致 tap事件同时触发的问题 查看详情 订阅消息 requestSubscribeMessage 接口 JSError 告警: appServiceEngine is not defined 的问题 查看详情 小程序客服助手，收到服务通知后打开提醒没有体验者权限的问题 查看详情 修复中的问题iOS canvas 渐变字体设置失效的问题 查看详情 canvas 的变形操作在安卓和 iOS 表现不一致的问题 查看详情  canvas 的 restore 会改动之前创建的路径位置的问题 查看详情  canvas 多次调用 clip，iOS 端渲染结果有误的问题 查看详情   picker 限制问题 查看详情 工具 video 无法展示封面图的问题 查看详情  开发工具上的 video 实现对齐客户端 查看详情  VideoContext.seek到指定位置后play无效 查看详情  scroll-view 滚动过程中无法点击 scroll-view 以外的区域 查看详情  button嵌cover-view，cover-view点击无效 查看详情  iOS video & live-player 同层特定路径下无法展开全屏的问题 查看详情  Skia Canvas 在 iOS 上无法加载图片的问题 查看详情 退出小程序后 video 还会继续播放的问题 查看详情 image 组件频繁触发 force reflow 的问题 查看详情  live-player 和 video 进入后台静音策略调整的问题 查看详情 loadFontFace 支持全局生效 查看详情  安卓 7.0.9 自定义 tabBar 位置错位的问题 查看详情 video 拖动进度时不应触发 timeupdate 的问题 查看详情 video 全屏场景下会触发 swiper 页面错乱的问题 查看详情  V2.9.4 更新日志链接失效的问题 查看详情 radio-group 属性表中 bindchange 的说明出错的问题 查看详情 Laya drawToCanvas 截图保存有概率导致微信闪退的问题 查看详情 wx.chooseLocation({}) 无法点击确定的问题 查看详情 支持双向绑定这个详情页面不存在的问题 查看详情 推荐组件里面积分余额是负数的问题 查看详情 微信小程序分享页面跳转 tabbar 页面 头部导航栏消失问题 查看详情 示例代码的大小写问题。WXML语法参考"引用"板块的问题 查看详情 部分机型支付时闪退的问题 查看详情 商户接口列表点击后 404 的问题 查看详情 接入子域后截图失效获得的图片信息全是空白的问题 查看详情 wx.scanCode iphone 不能识别 DATA_MATRIX 编码的问题 查看详情 requestAnimationFrame 调用以及 worker 的 onMessage 问题 查看详情 微信小游戏黑屏无法打开的问题 查看详情 扩展组件 mp-navigation-bar 样式错乱的问题 查看详情 通过微信公众号快速创建的小程序的问题 查看详情 微信公众号管理用户信息搜不到的问题 查看详情 视频组件，分享之后不会自动播放的问题 查看详情 大量玩家出现黑屏现象，部分玩家后台反馈无法看到机型信息的问题 查看详情 android: webview 界面上 svg 中的 text 颜色设置无效的问题 查看详情 在小程序地图上实现一个可滑动的 cover-view,在开发工具上和 iOS 手机可以滑动，安卓不能滑动的问题 查看详情   突然客服小助手小程序无法使用的问题 查看详情 小程序客服小助手点击消息跳转到体验版小程序的问题 查看详情 微信小程序客服服务通知的问题 查看详情 更新后git拉取无法合并并报错 查看详情 在教程中，示例代码中的方法是错误的 查看详情 createGameClubButton创建出来的按钮在iOS上纵坐标出现偏移 查看详情 之前在微信小程序内“客服”栏添加了微信号，但是手机端“客服小助手”回复问题的时候，提示没有权限 查看详情 banner广告和插屏广告层级问题 查看详情 小程序客服小助手点击信息进入的是体验版 查看详情 小游戏线上版本 首次加载 不是闪退就是加载有问题 查看详情 安卓机 webview 页面开启屏幕旋转 横屏之后内容宽度只有屏幕的一半的问题 查看详情 公众号后台用户管理的搜索功能，搜不到已经关注的粉丝的问题 查看详情 安卓上 wx.connectSocket 设置 tcpNoDelay 参数为 true 无效的问题 查看详情 安卓上建立第一次建立连接（https，websocket）会失败的问题 查看详情 需求反馈已支持 iOS 平台支持 webP 的需求 查看详情  map 组件普通区域点击获取经纬度的需求 查看详情  跟进迭代中支持压缩视频的接口的需求 查看详情   安卓蓝牙提供改变 MTU 大小的接口的需求 查看详情 video 手势控制进度时增加总时长的需求 查看详情  蓝牙支持从机模式的需求 查看详情 video 组件加载期间可操作全屏或退出全屏按钮的需求 查看详情  video 横屏时自动全屏的需求 查看详情 需求评估中关于生成小程序二维码的建议 查看详情 真机调试时touchstart touchmove touchend 事件无响应的需求 查看详情 订阅消息模板的需求 查看详情 把客户的运营警告信息发送给服务商的需求 查看详情 能有各个API调用次数限制的说明文档的需求 查看详情 微信网页授权登录开发工具能不能也加一个拒绝按钮，和真机保持一致的需求 查看详情 wx.getLocation 这个方法能不能返回当前所在城市信息（城市名和adcode） 查看详情 小游戏支持 tensorflow 的需求 查看详情                                                                                                                                                                      微信团队                                                                                                                                                                  2019.12.18

作者：coldsnap 原文：小程序多端框架全面测评 Fundebug经授权转载，版权归原作者所有。 最近前端届多端框架频出，相信很多有代码多端运行需求的开发者都会产生一些疑惑：这些框架都有什么优缺点？到底应该用哪个？ 作为 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 日）已发布稳定版为标准进行讨论。 1. 开发工具 就开发工具而言 [代码]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 [图片] 2. 多端支持度 只从支持端的数量来看，[代码]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 [图片] 3. 组件库/工具库/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 [图片] 4. 接入成本 接入成本有两个方面： 第一是框架接入原有微信小程序生态。由于目前微信小程序已呈一家独大之势，开源的组件和库（例如 [代码]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 [图片] 5. 开源建设 一个开源作品能走多远是由框架维护团队和第三方开发者共同决定的。虽然开源建设不能具体地量化，但依然是衡量一个框架/库生命力的非常重要的标准。 从第三方贡献者数量来看，[代码]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 (按字母顺序排序)

- 当前 Bug 的表现（可附上截图） [图片] - 预期表现     在官方提供的场景值里没有找到对1101的说明 场景值链接 - 复现路径 通过开发者工具点击预览 - 提供一个最简复现 Demo ...