下载云存储的json文件，涉及汉字转码问题，开发工具上完整运行 let gbk = new TextDecoder('gbk').decode(new Uint8Array(res.data)) //这里把gbk文件读入转换成了utf8的String 真机上 TypeError: TextDecoder is not a constructor 求高手解答

就是我目前的义务是，我有要为很多客户提供小程序服务，一个客户就有一个小程序，类似凡科的服务，每次我升级版本，或者修改bug，都需要一个一个小程序的去打包上传，所以我想通过微信开放平台，弄一个开放服务，让客户的小程序授权平台，然后就可以统一管理代码上线下线等，但是现在遇到一个问题，就是平台型服务商最多只能添加30个开发小程序，但是我的小程序不止30个，我这种情况有没有其他的解决方案，望平台关注，万分感谢，十万火急。

为更好地保护用户隐私信息，优化用户体验，平台对小程序内的帐号登录功能进行规范。“帐号登录功能”是指开发者在小程序内提供帐号登录功能，包括但不限于进行的手机号登录，getuserinfo形式登录、邮箱登录等形式。一、登录规范规则，你需要了解：[图片] 一、「体验范围开放」与「体验范围特定」区分与对应整改建议：1、“体验范围开放”定义：①直接打开即可体验 ②有账号限制，但有注册流程是对外开放 整改建议： ①授权个人信息功能后置，给与用户充分了解、体验功能服务后，再由用户主动点击进一步功能触发登录授权 ②授权同时，亦同时支持给与用户取消登录的权利 案例解析： ①范围开放-登录规范违规案例解析 违规点：服务范围开放，首页打开即要求授权登录，用户未体验功能服务强制要求授权登录，登录规范不合规。 [图片] ②范围开放-登录环节无取消/拒绝登录按钮案例解析 违规点：体验范围开放，用户体验功能服务后自主触发登录，提供取消/拒绝登录按钮，但点击取消/拒绝登录按钮无响应，仍强制要求登录，无法取消/拒绝登录。 [图片] 2、体验范围特定 定义： 体验范围提供给特定人员使用、对外无开放注册流程，例如为学校系统、员工系统、社保卡信息系统等提供特定服务的小程序 整改建议： ①首页有明显的使用范围（特定范围）说明 ②首页即要求授权来拉取身份鉴定类，需要为用户提供暂不登录/取消登录选项按钮 案例解析： ①特定范围-登录违规案例解析 违规点：打开首页即要求授权登录，无任何说明，不符合登录规范要求 [图片] 这是一份动态更新的文档，辅助开发者了解登录规范要求，避免开发者因登录规范问题审核失败导致无法按期发布上线，开发者如有其他疑问，可以通过目前开放的咨询渠道反馈： 1、微信开放社区-交流专区-小程序发帖咨询-提出问题-运营相关问题 2、驳回站内信通知-客服咨询入口（MP代码审核客服入口正处于灰度开放中，若未获得灰度测试入口，开发者可前往社区发帖咨询） 我们会根据新出现的问题、相关法律法规更新或产品运营的需要及时对其内容进行修改并更新，制定新的规则，保证微信用户的体验。建议开发者反复查看以便获得最新信息，定期了解更新情况。

目前碰到一个问题，在正常情况下服务商API退款是需要商户授权的，但是在邀请小微商户授权时，出现报错，是否代表小微商户退款是不需要授权，服务商可以直接进行API退款的？ 除此外还有一个问题，如果小微商户升级成为了普通商户，对于服务商进行付款码支付和API退款，是否就需要普通商户进行授权了？ 目前商户确认授权是否只能在商户平台完成，有无发送链接，用户点击链接确认授权等方式？[图片]

[图片] 小程序应避免出现任何 JavaScript 异常 出现 JavaScript 异常可能导致小程序的交互无法进行下去，我们应当追求零异常，保证小程序的高鲁棒性和高可用性 小程序所有请求应响应正常 请求失败可能导致小程序的交互无法进行下去，应当保证所有请求都能成功 所有请求的耗时不应太久 请求的耗时太长会让用户一直等待甚至离开，应当优化好服务器处理时间、减小回包大小，让请求快速响应 避免短时间内发起太多的图片请求 短时间内发起太多图片请求会触发浏览器并行加载的限制，可能导致图片加载慢，用户一直处理等待。应该合理控制数量，可考虑使用雪碧图技术或在屏幕外的图片使用懒加载 避免短时间内发起太多的请求 短时间内发起太多请求会触发小程序并行请求数量的限制，同时太多请求也可能导致加载慢等问题，应合理控制请求数量，甚至做请求的合并等 避免 setData 的数据过大 setData工作原理 小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。当前，视图层和逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。即用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，再通过执行 JS 脚本的形式传递到两边独立环境。 而 evaluateJavascript 的执行会受很多方面的影响，数据到达视图层并不是实时的。 由于小程序运行逻辑线程与渲染线程之上，setData的调用会把数据从逻辑层传到渲染层，数据太大会增加通信时间 常见的 setData 操作错误 频繁的去 setData Android 下用户在滑动时会感觉到卡顿，操作反馈延迟严重，因为 JS 线程一直在编译执行渲染，未能及时将用户操作事件传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层 染有出现延时，由于 WebView 的 JS 线程一直处于忙碌状态，逻辑层到页面层的通信耗时上升，视图层收到的数据消息时距离发出时间已经过去了几百毫秒，渲染的结果并不实时 每次 setData 都传递大量新数据 由setData的底层实现可知，数据传输实际是一次 evaluateJavascript 脚本过程，当数据量过大时会增加脚本的编译执行时间，占用 WebView JS 线程 后台态页面进行 setData 当页面进入后台态（用户不可见），不应该继续去进行setData，后台态页面的渲染用户是无法感受的，另外后台态页面去setData也会抢占前台页面的执行 避免 setData 的调用过于频繁 setData接口的调用涉及逻辑层与渲染层间的线程通过，通信过于频繁可能导致处理队列阻塞，界面渲染不及时而导致卡顿，应避免无用的频繁调用 避免将未绑定在 WXML 的变量传入 setData setData操作会引起框架处理一些渲染界面相关的工作，一个未绑定的变量意味着与界面渲染无关，传入setData会造成不必要的性能消耗 合理设置可点击元素的响应区域大小 我们应该合理地设置好可点击元素的响应区域大小，如果过小会导致用户很难点中，体验很差 避免渲染界面的耗时过长 渲染界面的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要校验下是否同时渲染的区域太大 避免执行脚本的耗时过长 执行脚本的耗时过长会让用户觉得卡顿，体验较差，出现这一情况时，需要确认并优化脚本的逻辑 对网络请求做必要的缓存以避免多余的请求 发起网络请求总会让用户等待，可能造成不好的体验，应尽量避免多余的请求，比如对同样的请求进行缓存 wxss 覆盖率较高，较少或没有引入未被使用的样式 按需引入 wxss 资源，如果小程序中存在大量未使用的样式，会增加小程序包体积大小，从而在一定程度上影响加载速度 文字颜色与背景色搭配较好，适宜的颜色对比度更方便用户阅读 文字颜色与背景色需要搭配得当，适宜的颜色对比度可以让用户更好地阅读，提升小程序的用户体验 所有资源请求都建议使用 HTTPS 使用 HTTPS，可以让你的小程序更加安全，而 HTTP 是明文传输的，存在可能被篡改内容的风险 不使用废弃接口 使用即将废弃或已废弃接口，可能导致小程序运行不正常。一般而言，接口不会立即去掉，但保险起见，建议不要使用，避免后续小程序突然运行异常 避免过大的 WXML 节点数目 建议一个页面使用少于 1000 个 WXML 节点，节点树深度少于 30 层，子节点数不大于 60 个。一个太大的 WXML 节点树会增加内存的使用，样式重排时间也会更长 避免将不可能被访问到的页面打包在小程序包里 小程序的包大小会影响加载时间，应该尽量控制包体积大小，避免将不会被使用的文件打包进去 及时回收定时器 定时器是全局的，并不是跟页面绑定的，当页面因后退被销毁时，定时器应注意手动回收 避免使用 css ‘:active’ 伪类来实现点击态 使用 css ‘:active’ 伪类来实现点击态，很容易触发，并且滚动或滑动时点击态不会消失，体验较差 建议使用小程序内置组件的 ‘hover-*’ 属性来实现 滚动区域可开启惯性滚动以增强体验 惯性滚动会使滚动比较顺畅，在安卓下默认有惯性滚动，而在 iOS 下需要额外设置 [代码]-webkit-overflow-scrolling: touch[代码] 的样式

<view  class="text-box">     <text class="text">欢迎使用应援棒  欢迎使用应援棒 </text> </view> 关键代码就这，外面容器旋转了下 .text-box{ transform:translateX(750rpx) rotate(90deg) ; width: 100vh; line-height: 750rpx; transform-origin:0% 0%; } .text { white-space:nowrap; display:inline-block; animation:anim 6s linear infinite; } @keyframes anim { 0% {transform:translateX(0) } 100% {transform:translateX(-50%)} } 在IOS环境下滚动字老是断开 [图片] [图片]

事情是这样的。 我司一小破程序，打开时类似这样，显示一个logo，一个标题 [图片] 经过一个2秒的动画效果，logo和标题就移动到上面部分了，同时渐显出来一个loading组件，这些都是使用小程序的Animation API实现的。 [图片] [图片] 现在需求来了。 我们想在首屏渲染后。在图标往上移的动画执行周期中，将背景色缓慢从蓝色变为白色。 (别问为什么要变背景色，我们准备待会加完班拿上弹弓组团去打设计师家玻璃了) [图片] 有朋友会说了，这不是很简单嘛，弄个定时器去替换class不就行了？ 我只想说，no no no。朋友，我们搬砖就要有搬砖的样子嘛。 什么时间搬，搬多少，什么时间停，都要严谨嘛。 天真的我，想当然的就拍着胸脯向BOSS表示小意思啦。 [图片] naive的我心里想着 肯定会有动画执行开始和结束一个callback接口的嘛 然鹅,、翻遍了小程序文档里关于动画的各个段落之后才发现 [图片] 神马?? 我不信！一定是我的眼刚刚瞎了，我要再看一遍。 [图片] [图片] [图片] [图片] [图片] PS 看，多么言简意赅的文档！ 在看多了外面那些"妖艳贱货"的文档后，如此小清新的文档，还真让我这老司机虎躯一震。 // TODO 我当即在心里暗暗发誓，我一定要强烈建议我司将此文档规范引进并在我司大范围实践，太他【文明用语】高效了。 END PS 在我不懈的努力下 在某毒找到了一篇关于动画重置的实例 [图片] [图片] 哦也，三七三十一，一定是我聋了才没看见这么大个接口 同事心里还在做自我批判，怎么能轻易的就甩锅给腾讯爸爸。 祭出我的Ctrl+F大法 [图片] 果然。还是我太天真。竟然没有搜到 0/0？ 在经过了一番苦苦的某毒搜索之后，猛然意识到，或许是我姿势不对？ [图片] 谢天谢地，博客园诚不我欺。确实有这个东东。 我默默的打开了唯一的一条搜索结果学习了起来。你猜怎么着？ [图片] 我发现了腾讯爸爸藏起来的彩蛋。 哇，没想到小程序团队这么调皮。 在动画相关的所有文档里，竟然半个字都没提有这几个事件。保密工作做的很到位。表扬。5星好评。 [图片] 根据文档，照猫画虎。 [图片] [图片] 控制台没有任何反应 [图片] 一定是我姿势不对，我换换姿势。 [图片] [图片] 一顿操作猛如虎，然鹅发现并没有什么卵用。 [图片] [图片] [图片] 我盯着这条说明，默默的给自己点上了一根烟后陷入了痛苦的沉思。 期间我尝试了各种姿势，都没有找到关于WXSS animation到底是个什么鬼。 我只知道有Animation这个动画API。或许他俩是一个东西？ 但是为什么Animation里没有关于它的只言片语？ [图片] 既然Animation里没有写，肯定是另外一套体系吧？ 灵光一闪， oh no，别又是腾讯爸爸调皮了把文档藏起来了吧。 [图片] [图片] 经过地毯式的搜索及换遍了各种姿势想要跟我的小程序互动一把后。 [图片] [图片] [图片] 我选择死亡。 [图片] [图片] 我想起那天夕阳下调的微信小程序，那是我逝去的青春。。。 IDE: v1.02.1901230 Library: 2.4.2