[图片] https://v.qq.com/x/page/j079878zozx.html 在开发小程序的过程中，往往会遇到三个比较明显的问题，一是页面加载后的真机显示效果会在一瞬间（大约半秒）出现错乱，二是页面加载速度慢，尤其是页面需要请求接口的情况，三是全局管理数据，并且把数据同步到Page或者Component内显示麻烦。所以我们研发了一个叫做dataWorker的工具来解决真机显示效果出现错乱、提高页面加载和显示速度、并且做好全局数据管理。 我们在开发多个小程序的过程中，尤其是在解决用户数据上报丢失时发现，微信小程序的生命周期在真机中其实为伪周期。事实上，完全可以在生命周期外走逻辑，请求接口，唯一比较麻烦的把数据同步到页面内。这也就是为什么我们要用dataWorker（可以理解为浏览器内的service worker）来同步更新视图。我相信，市面上的大部分业务方往往是在页面的[代码]onLoad[代码]或者[代码]onShow[代码]的时候才开始加载并且渲染页面的，最终导致了体验上的卡顿，在数据上则常常出现业务PV点消失的情况。但是如果我们在页面还没有被打开之前就加载好了页面，那么打开的速度当然会快很多。 当然，有很多业务方已有的代码实际上是不需要有全局数据介入的，所以我们又添加了一个开关，叫做palindrome（可以理解为数据双向绑定把）。 然后在需要使用worker的Page或Component内添加palindrome: true，如下： Page({ [代码]palindrome: true, data: {...}, onLoad(){...} [代码] }) 那么比方说我现在想要设置该页面的数据，我依然可以使用原先微信提供的this.setData({…})，这和dataWorker不冲突，也不会改变dataWorker内的数据，但是我同时又可以用dataWorker.data = {…}或dataWorker.list = […]这种办法去修改页面的数据（会直接影响视图）。 dataWorker 代码片段，需要使用appId，并且申请《微盟RPRM测试版》插件（wx10692d472c83e02c）0.0.4或以上版本的使用权限。并且需要关闭安全域名检查（需要请求接口）。 代码片段：https://developers.weixin.qq.com/s/5f5PDMmv7O4J

本文因为社区编辑器markdown功能暂有问题，格式上比较混乱，大家将就看吧： 目前小程序支持的直播方式有两种，一种是纯原生方案（小程序提供推流拉流服务器，主播端和收播端页面都已提供好，你直接使用即可），一种是自己搭建推流服务器（只是使用小程序端提供的live-pusher和live-player组件而已，里面的直播页面和功能都自己独立开发！），这里说的是第一种方案：   一、准备工作   1、一个已经申请开通和正常使用的实实在在的小程序   PS：如果开通了直播功能，但是没有审核上架成功过，直播间分享出去的二维码点击会提示页面不存在！！！原因很简单，因为你新开发的直播页面正式版的小程序上并没有新加进去，必须要提审上架到正式版才能生效！   二、小程序直播准入门槛   微信小程序直播功能准入要求（官方文档链接>>） 一、类目要求： 1. 小程序开发者为国内非个人主体开发者； 2. 小程序开发者为下述类目品类，类目具体信息可参考《微信小程序开放的服务类目》： 1）电商平台：电商平台 2）商家自营：百货、食品、初级食用农产品、酒/盐、图书报刊/音像/影视/游戏/动漫、汽车/其他交通 工具的配件、服装/鞋/箱包、玩具/母婴用品(不含食品)、家电/数码/手机、美妆/洗护、珠宝/饰品/眼镜 /钟表、运动/户外/乐器、鲜花/园艺/工艺品、家居/家饰/家纺、汽车内饰/外饰、办公/文具、机械/电子 器件、电话卡销售、预付卡销售、宠物/农资、五金/建材/化工/矿产品； 3）教育：培训机构、教育信息服务、学历教育（学校）、驾校培训、教育平台、素质教育、婴幼儿教 育、在线教育、教育装备、出国移民、出国留学、特殊人群教育、在线视频课程； 4）金融业：证券/期货投资咨询、保险； 5）出行与交通：航空、地铁、水运、城市交通卡、打车（网约车）、顺风车（拼车）、出租车、路况、 路桥收费、加油/充电桩、城市共享交通、高速服务、火车、公交、长途客运、停车、代驾、租车； 6）房地产：房地产、物业管理、房地产经营、装修/建材； 7）生活服务：丽人、宠物（非医药类）、宠物医院/兽医、环保回收/废品回收、摄影/扩印、婚庆服务、 搬家公司、百货/超市/便利店、家政、营业性演出票务、生活缴费； 8）IT科技：硬件与设备、基础电信运营商、电信业务代理商、软件服务提供商、多方通信； 9）餐饮：餐饮服务场所/餐饮服务管理企业、点餐平台、外卖平台、点评与推荐、菜谱、餐厅排队； 10）旅游：旅游线路、旅游攻略、旅游退税、酒店服务、公寓/民宿、门票、签证、出境WiFi、景区服 务； 11）汽车：养车/修车、汽车资讯、汽车报价/比价、车展服务、汽车经销商/4S店、汽车厂商、汽车预售 服务； 12）体育：体育场馆服务、体育赛事、体育培训、在线健身 二、运营要求： 1、主体下小程序近半年没有严重违规 2、小程序近90天存在支付行为 以上2个运营条件和类目同时满足的前提下，下面3个条件满足其一即可 3、主体下公众号累计粉丝数大于100 4、主体下小程序近7日dau大于100 5、主体在微信生态内近一年广告投放实际消耗金额大于1w 以上准入要求于 2020 年 02 月 24 日进行公示生效。为营造良好健康的微信生态，腾讯公司有权对《微信 小程序直播功能准入要求》不时予以调整并公布，请予以关注。 腾讯公司   tip：如果你的小程序刚刚满足上面门槛，请T+2后刷新再试试。   三、进入小程序后台直播，创建直播间 [图片]   如果你的小程序满足了第二点。小程序后台会有一个直播的入口（没有的话自己找找原因）   点击进入后->创建直播间   按提示操作（要输入主播人的微信号，对方初次使用要活体检测+实名认证）即可成功创建直播间。（注意点：开播时间最早不能早于当前时间10分钟后）   创建成功后，会有一个开播码。注意这个开播码是给主播用的，主播开播的入口小程序码。主播可以扫码进入直播间开播。 [图片]   四、小程序端开发   完成上面3步算是完成主播端的配置了，接下来是收播端（观看直播的小程序端）的开发了。这个是要小程序开发者完成的。所以下面操作都在小程序开发端完成。下面就简单介绍开发逻辑和顺序，具体的要用到的API和接口都不细说，在后面相关链接里面可以点击官方链接查看！（小程序直播 | 微信开放文档）https://developers.weixin.qq.com/miniprogram/dev/framework/liveplayer/live-player-plugin.html）   （1）引入直播插件（直接按官方介绍文档操作）   正常引入后开发者工具会弹出这个窗口，如果不弹出请认真，静下心来按照官方文档检查自己的引入代码： [图片]   （2）开发后端（如果你没有小程序端自建直播列表和直播间入口的需求2、3、4都可以跳过，届时你的小程序直播间可以用分享方式进入）   后端目前官方只提供了2个接口。一个是获取直播间列表，一个是获取直播间直播完后的相关回放信息，其中第一个接口必须先完成。就是获取到直播间列表，列表里面有带返回直播间的roomid，小程序端必须需要接收到这方面的返回才能接下来的开发。   （3）进入直播页面   引入直播插件后并对接第二步的后端接口后，你可以直接编码进入直播页面了。像进入普通页面一样，可以通过wxml里面的navigator url="xxxx"的方式和js里的wx.navigateTo跳转页面代码进入直播页面。但是他这个url比较特殊，是下面这样的格式：    url: `plugin-private://${provider}/pages/live-player-plugin?room_id=${roomId}&custom_params=${encodeURIComponent(JSON.stringify(customParams))}`   provider:插件appid（1）小步里面获取到的   rommId:直播间id（2）小步里面获取列表后里面的roomId   customParams:自定义的进入页面参数。（根据需要自己定义的传入直播间收播页面的参数）  进入直播间收播页面后的开发量为0，因为这个是由直播间插件接管并完成相关功能。   （4）几个注意点：   4.1、后端获取直播间列表接口几个跟官方文档介绍不一致的地方 [图片]   4.2、 livePlayer.getLiveStatus获取直播间状态这个API官方介绍：首次获取立马返回直播状态，往后间隔1分钟或更慢的频率去轮询获取直播状态。实际使用过程中建议也这么干，如果需要轮询直播间状态，建议间隔时间1分钟以上，如果少于这个值，基本上就是卡在这里后面的代码都不执行了。还有，有时候即使超过1分钟后再轮询，也会偶发性出现获取不到卡住的情况。解决方法，大家可以看看开发者工具里面的本地Storage相关的值，然后后面怎么做你懂的。。   4.3订阅组件subscribe的样式问题。不多说，你懂的，你加上去就能看到效果   4.4后端接口每日调用次数限制的问题。要做好相关缓存到本地的架构设计。   4.5运营上一定要注意，按要求直播。别整那些没用的，很容易被禁播的。   （5）回放功能开发   1.0.4版本后支持0开发的回放功能了。参考后面新增的专门介绍回放功能的使用教程。   五、跑路   这里的跑路是指代码写累了，带上口罩和吉娃娃去公园跑一圈路回来继续码。   最新：1.0.4版本后的回放功能说明，回放功能是这样的   1、后台开启该直播间的回放功能 [图片]   2、收播端还是原来的直播入口进行回放，小程序端是  plugin-private://${liveplayId}/pages/live-player-plugin?room_id=${roomId}&custom_params=${encodeURIComponent(JSON.stringify(customParams))}`   这里的页面链接，链接到回放页面。获取分享方式，分享出去的直播页面，点击后进入回放。 [图片]   还有一个口，点击原来的分享链接后的直播完成页面，也有一个查看回放的入口，如上图。   Tip:如果刚刚直播完可能需要稍等生成回放视频后再次进入相关页面才能看到回放。   相关链接：   小程序直播 | 微信开放文档（开发必看，而且要熟读，基本有所有你要的开发资料）   https://developers.weixin.qq.com/miniprogram/dev/framework/liveplayer/live-player-plugin.html   微信小程序直播功能准入要求 | 微信开放文档   https://developers.weixin.qq.com/miniprogram/product/live/access-requirement.html   “小程序直播”接入指引 | 微信开放社区   https://developers.weixin.qq.com/community/develop/doc/0008ce654c4450244c1a7e5de5b801?highLine=%25E7%259B%25B4%25E6%2592%25AD%2520%25E6%25B1%25BD%25E8%25BD%25A6   相关知识科普：   小程序直播单日直播上限是50场，同时直播上限50场，单场的直播时长上限是12小时。

首先很开心，我司小程序获得第一波直播权限，我已经开发加好了直播，请确认你的小程序有直播资质，如果你有在开发中碰到什么问题，欢迎留言 一、引入直播插件 打开 app.json 文件 如果你代码有区分 分包 请记得将以下代码 放到 root 根文件夹 如果没有请忽略 以下代码 放到 "pages": ["pages/index/index"], 的同级地方 plugins": {         "live-player-plugin": {           "version": "1.0.2",             "provider":"wx2b03c6e691cd7370"       } }, 其中 live-player-plugin 是插件名字 version 是版本号码 二、引入直播开播 订阅组件（如果你不想引入，可以跳过） 在你要引入的页面 json 中添加组件  "usingComponents": { "subscribe": "plugin-private://wx2b03c6e691cd7370/components/subscribe/subscribe"  } 注意不用改动 页面引入 room-id 属性一定要添加 就是后台会返回给你的 live_status 是用来判断状态 因为有时候我们都添加上订阅按钮 点了后会消失 是因为这个状态已经是过去的直播了 无法订阅 ps:这个插件目前有个 bug 就是 不管我有么有订阅这场 都是未订阅状态 但是点击去直播间的订阅按钮却是状态对的 并且我切换下 小程序 前后台（onShow onHide 切换）状态又是对的 三、页面跳转 你可以在图片上添加函数 也可以直接 navigator 跳转 goDetail(e) {    var room = e.currentTarget.dataset.room;    wx.reLaunch({         url: '/plugin-private://wx2b03c6e691cd7370/pages/live-player-plugin?room_id=' + room,    }) } 或者 直接 navigator 跳转 四、页面分享 以下是我的页面分享 假设你的是卡片展示 或者图片展示   /**      * 用户点击右上角分享      */     onShareAppMessage: function (res) {                 var idx = res.target.dataset.idx;         const listInfo = this.data.listInfo[idx];         return {             title: listInfo.name,             imageUrl: listInfo.anchor_img,             path: '/plugin-private://wx2b03c6e691cd7370/pages/live-player-plugin?room_id=' + listInfo.roomid         }  }, 五、订阅插件样式更改 /* 订阅 */ .subscribe--live-player-subscribe__btn{   width: 200rpx !important;   height: 21px !important;   line-height: 21px !important;   font-weight: 200;   font-size: 20rpx !important;   text-align: center;   background: #fff!important;   color: #2d79ab!important;   border-radius: 4px;   pointer-events: auto;   margin: 0 auto; } 写在最后-------------------------注意，开发工具目前是无法进入直播页面的，但是真机可以，你们可以上传到体验版然后通过微信后台开个直播，扫码体验就能进入直播间。 以上就是我的分享，谢谢大家观看~~，如果你觉得有用，点个赞吧

已经使用uni-app开发并发布了一个跨端小程序啦，嘻嘻嘻！ 🧐 须知 这是一份详细的小程序各特性各端真机调研对比报告 测试机：iPhone7 plus IOS 12.4.1 客户端：微信7.0.5，支付宝10.1.72，今日头条7.4.0，抖音8.1.0，QQ8.1.5.461 🚫️ 百度小程序只有商户才能注册，个人开发者无法注册，没有appid功能受限（如百度开发者工具无法使用预览功能导致无法真机测试），所以暂时不测百度小程序 用户信息授权 授权方式： 【头条】用户信息授权方式还停留在微信小程序第一版，即直接调用 getUserInfo 弹出授权弹窗，如果用户选择允许，则后续调用不再出弹窗，而是直接走 success 回调。如果用户选择取消，则后续调用也不再出弹窗，而是直接走 fail 回调 【微信】【QQ】【支付宝】则采用 button + 回调事件的方式调起授权弹窗，如果用户选择允许，则后续点击不再出弹窗，直接走回调。如果用户选择取消，则后续点击继续弹窗询问授权 授权信息清除方式： 【微信】删除小程序即可清除授权信息 【支付宝】我的-设置-安全设置-账号授权 【今日头条】我的-系统设置-清除缓存。【抖音】未找到清除方法 【QQ】未找到清除方法（据说开放小程序的QQ版本尚未灰度发布） 小程序登录 【微信】wx.login 【QQ】qq.login 基本同微信 【支付宝】my.getAuthCode 【头条】大致同微信，未找到模型文档 分享 行为： 【微信】直接调起聊天对话列表进行选择 【QQ】调起分享渠道列表： QQ好友 QQ空间 点右上角三个点调起的列表还有微信好友和朋友圈两个项，在微信中打开qq小程序是走中间页 【支付宝】调起分享渠道列表： 支付宝朋友圈 支付宝联系人 微信好友|QQ好友(保存支付宝生成的分享图片后打开支付宝扫码) 钉钉好友(中间页自动打开支付宝小程序，中间页不自动关闭) 新浪微博(中间页自动打开支付宝小程序，和钉钉一个中间页) 【头条】调起分享渠道列列表： 转发到头条 微信好友|微信朋友圈(生成口令，复制口令后打开今日头条弹出识别弹窗) QQ|QQ空间(打开中间页，点击打开(QQ空间点了没反应)，出现另一个中间页，自动打开AppStore，再点打开调起今日头条，最后居然没打开那个小程序🥴!!!) 【抖音】调起分享渠道列列表： 多闪好友 微信好友|微信朋友圈|QQ好友|QQ空间(生成抖音码图片，打开抖音扫码识别) 【头条】webview的转发暂未支持： 【今日头条】能转发，但转发的链接点击后总是提示加载失败！也可能是小程序未发布的原因，扫uni-app官方demo进行 webview转发是能正常打开的 【抖音】不支持转发，右上角胶囊只有一个关闭按钮 跳转到其他小程序 【微信】支持(navigateToMiniProgramAppIdList + navigateToMiniProgram) 【QQ】支持 【头条】支持(navigateToMiniProgramAppIdList + navigateToMiniProgram) 【支付宝】支持(后台配置 + navigateToMiniProgram) 🚫️ ️QQ，支付宝和头条未真机验证，因为须要一个其他小程序的appId 客服会话 【微信】支持(button open-type=“contact”) 【QQ】支持，须用户加一个客服机器人为好友 【支付宝】支持(contact-button) 【头条】不支持。 支付 【微信】支持(调起微信支付) 【QQ】支持(调起QQ支付) 【支付宝】支持(调起支付宝支付) 【头条】支持(调起支付宝App进行支付) 🚫 ️QQ，支付宝和头条未真机验证，因为支付接口只有商户才有权限 地理位置 【微信】支持(须在app.json中配置permission字端)，用户拒绝授权后再次调用不再出询问弹窗，而是直接走fail回调 【QQ】支持。真机行为同微信。QQ开发者工具上拒绝授权再次调用仍会出询问弹窗 【头条】支持，同微信 【支付宝】支持，用户拒绝授权后再次调用继续出询问弹窗 视频播放 【微信】支持 【QQ】支持 【头条】支持 【支付宝】支持？(uni-app里说支付宝不支持，支付宝文档也没找到video组件，但放在页面里video能正常渲染和播放，难道是昨天刚支持🤔) 复制文字 行为： 【微信】【QQ】复制成功后有一个默认的复制成功toast且无法控制 【支付宝】【头条】复制成功后没有toast 权限： 【支付宝】my.setClipboard 此功能仅支持企业支付宝账号。实际情况是：在IDE上个人账号是可以复制的，但在真机上调用就会报 [代码]ERROR 4: 无权调用该接口[代码] 错误 【微信】【QQ】【头条】无限制 打电话 【微信】【QQ】【支付宝】【头条】都支持 收货地址 【微信】支持 【QQ】不支持 【头条】支持（实测【今日头条】支持，【抖音】不支持） 【支付宝】支持。但仅商户才有使用权限。且目前 my.getAddress 接口暂不支持在开发者工具调试和真机调试，仅支持真机预览 相机/图片相关 拍照/相册选图片 【微信】【QQ】支持 【支付宝】支持。IDE上会弹一个相册授权询问弹窗，真机上并没有弹窗 【头条】支持。但会弹出两个询问弹窗（相机权限，相册权限） 拍摄/相册选视频 【微信】【QQ】支持 【支付宝】支持。IDE上会弹一个相册授权询问弹窗，真机上并没有弹窗。须调用 my.chooseVideo(文档未找到)，uni.chooseVideo会报错 【头条】支持。但会弹出两个询问弹窗（相机权限，相册权限） ⚠️chooseVideo的maxDuration选项在【微信】和【支付宝】是只限制拍摄时长，在【头条】是同时限制相册选择视频时长和拍摄时长 图片预览 【微信】【QQ】【支付宝】【头条】都支持 保存图片到相册 【微信】【QQ】【头条】支持，弹窗仅询问一次 【支付宝】tt.saveImageToPhotosAlbum 在IDE上报错 [代码]tt.saveImageToPhotosAlbum is not a function[代码]，在真机上报错 [代码]无权调用该接口[代码]，文档未提及，猜测是仅商户可用，且不支持在开发者工具调试和真机调试，仅支持真机预览 接口返回值差异 getUserInfo【微信】【QQ】【支付宝 】【头条】 [代码]// 支付宝 { 'nickName': 'test', 'gender': 'm', 'city': '北京市', 'province': '北京' 'countryCode': 'CN', 'avatar': 'https:\/\/tfs.alipayobjects.com\/images\/partner\/T1_38eXnRiXXXXXXXX', 'code': '10000', 'msg': 'Success', } // 微信 { 'nickName': 'test', 'gender': 1, 'city': 'Xinxiang', 'province': 'Henan', 'country': 'China', 'avatarUrl': 'https://wx.qlogo.cn/mmopen/vi_32/Q0j4TwGTfTJCzUl7llykqrMLicpULvVfkbbL2bVDua4tI8ibjxq5E9ib1oPW3F4QazLIUdS2GsFMAGnrWSYjN05Ew/132' 'language': 'zh_CN', } // QQ { 'nickName': 'test', 'gender': 1, 'city': '新乡', 'province': '河南' 'country': '中国', 'avatarUrl': 'https://thirdqq.qlogo.cn/qqapp/1108100302/D64611B2AE700324589177922EEBA5F4/100', 'language': 'zh_CN', } // 头条系（今日头条，抖音，皮皮虾，西瓜视频分别取各自用户信息） { 'nickName': 'test', 'gender': 1, 'city': '新乡市', 'province': '河南省' 'country': '中国', 'avatarUrl': 'http://wx.qlogo.cn/mmhead/Q3auHgzwzM5uibSytRCXFs0Y3xSpdy12thibjWIoMrBIsf7FiaPp2ibnFg/0', 'language': '', } [代码] getSetting【微信】【支付宝 】【头条】【QQ】 [代码]// 微信 https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/authorize.html [ 'scope.userInfo', // 用户信息 'scope.userLocation', // 地理位置 'scope.address', // 通讯地址 'scope.record', // 录音功能 'scope.camera', // 摄像头 'scope.writePhotosAlbum', // 保存到相册 'scope.userLocationBackground', // 后台定位 'scope.invoiceTitle', // 发票抬头 'scope.invoice', // 获取发票 'scope.werun', // 微信运动步数 ] // 头条 https://developer.toutiao.com/dev/miniapp/uQjMy4CNyIjL0IjM [ 'scope.userInfo', // 用户信息 'scope.userLocation', // 地理位置 'scope.address', // 通讯地址 'scope.record', // 录音功能 'scope.camera', // 摄像头 'scope.album', // *保存到相册* ] // 支付宝 https://docs.alipay.com/mini/api/xmk3ml#-1 [ 'userInfo', // 用户信息 'location', // 地理位置 'audioRecord', // 录音功能 'camera', // 摄像头 'album', // 保存到相册 ] // QQ https://q.qq.com/wiki/develop/game/frame/open-ability/authorize.html [ 'scope.userInfo', // 用户信息 'scope.userLocation', // 地理位置 'scope.qqrun', // QQ运动步数 'scope.writePhotosAlbum', // 保存到相册 'scope.appMsgSubscribed', // 订阅消息 ] [代码] 主要入口 【微信】 首屏对话列表下拉 扫一扫 发现->小程序 搜索 【支付宝】 扫一扫 搜索 首页我的小程序 【今日头条】 我的->扫一扫 搜索 【抖音】 搜索->扫一扫 【QQ】 扫一扫 💣 头条小程序陷阱 目前仅在头条Android版本7.2.9及以上版本支持真机调试功能。iOS暂时不支持真机调试 抖音App的小程序上没有打开调试器选项，右上角胶囊只有一个关闭按钮 💣 支付宝小程序陷阱 my.getOpenUserInfo用于获取支付宝会员基础信息，只能在真机上调试，无法在 IDE 中调试，也就是只要有用户授权的页面都需要推送到真机上开发调试！ 支付宝授权平台只返回tocken和uid，由开发者自己维护session有效期，[代码]checkSession[代码] 方法不可用 打开调试的调试器面板在调起用户授权弹窗时会消失，此时须使用真机调试 💣 uni-app 陷阱 uni.getSetting，文档上说【支付宝】支持，调用却报错 [代码]支付宝小程序，暂不支持getSetting[代码]，而直接调支付宝的api my.getSetting 确是支持的 uni.chooseVideo，文档上说【支付宝】支持，调用却报错 [代码]支付宝小程序，暂不支持chooseVideo[代码]，而直接调支付宝的api my.chooseVideo(文档未找到) 确是支持的 uni.chooseAddress，文档上说【支付宝】不支持，实际上是支持的，只是需要调用 my.getAddress，且仅商户才能使用 uni.getImageInfo，文档上说【头条】支持，调用却报错 [代码]头条小程序，暂不支持getImageInfo[代码]，而直接调头条的api tt.getImageInfo 确是支持的 📌 TODO 模版消息 第三方插件 uni-app 跨端小程序风险点 后端接口。不同端的后端接口不一样，需要后端评估一下。举例：模版消息(微信|支付宝|头条)；设计用户系统时需注意微信和QQ都有各自的openID和unionID，支付宝只有uid，头条只有openID；接入微信，QQ，支付宝支付时各种传参不一样 分享转发。支付宝，头条小程序分享至微信和QQ的主要方式是生成口令或者生成小程序码图片或者走中间页，导致传播路径较长 某些端重要功能缺失。举例：【头条】不支持客服会话。【抖音】不支持webview转发。【QQ】不支持收货地址 某些端api缺失，可能导致某些功能无法实现 第三方插件支持度

“程序是写给人读的，只是偶尔让计算机执行一下。” ——Donald Ervin Knuth（高德纳） 关于代码素养 我们常常谈到“素养”一词，是指个人在专业领域内实践训练而成的一种修养，在不同的领域中有不同的体现，如在音乐领域中，“音乐素养”是指个人对于音乐的感觉程度，对音高节奏的把控，对不同流派音乐的鉴赏能力等，而在编程领域，也有不同的素养，反映出对基本功、代码整洁度、专业态度等等方面，所谓“代码素养”，简单来说，就是指代码写的是否优雅美观可维护。 绝对完美的代码是不存在的，代码素养并不是指完美主义。在翻译领域有“信，达，雅”的标准，“雅”之所以放在最后，是因为要达到它，需要有比较高的水准和经验积累。类比到编程领域，我们在编程时，第一时间想到的是如何将业务逻辑实现出来，而不是如何把代码优雅地写出来，所以写代码没有所谓的绝对优雅。但是，作为一名专业的前端工程师，确切的说，应该是专业的软件工程师，编写优雅的代码应当是时刻保持的追求，它更像是一个准绳，如同每个人知道自己该做什么，不该做什么，所谓原则，所谓底线，体现出所谓的[代码]“代码素养”[代码]。 破窗理论 破窗理论，原义指窗户破损了，建筑无人照管，人们放任窗户继续破损，最终自己也参与破坏活动，在外墙上涂鸦，任垃圾堆积，最后走向倾颓。 破窗理论在实际中非常容易出现，往往第一个人的代码写的不好，第二个人就会有类似“反正他已经写成这样了，那我也只能这样了”的思想，导致代码越维护越冗杂，最后一刻轰然坍塌，变成无人想去维护的垃圾。 整洁的代码 整洁的代码如同优美的散文，试想读过的一本好书，能够随着作者的笔锋跌宕起伏，充满了画面感，调动了自己的喜怒哀乐。代码虽然没有那样的高潮迭起，但整洁的代码应当充满张力，能够在某一时刻利用这种张力将情节推向高潮。 我更喜欢把写代码类比于写文章讲故事，写代码是创作的过程，作者需要将自己想表达的东西通过代码的形式展现出来，而整洁的代码如同讲故事一般，娓娓道来，引人入胜，不好的代码则让人感觉毫无头绪，通篇不知道在讲什么。 整洁代码原则 在现代化的前端开发中，有很多自动化工具可以帮助我们写出规范的代码，如[代码]eslint[代码]，[代码]tslint[代码]等各种辅助校验工具，知名的规范如[代码]google规范[代码]、[代码]airbnb规范[代码]等等也从各个细节方面约束，帮助我们形成合理规范的代码风格。 本小节不再重复语言层面的代码风格，根据实际重构项目，总结出一系列开发过程中需要时刻注意的原则，按照重要程度优先级排列。 1. DRY(Don’t Repeat Yourself) 相信作为一名软件工程师，大家都听说过最基本的DRY原则，很多设计模式，包括面向对象本身，都是在这条原则上做努力。 DRY顾名思义，是指“不要重复自己”，它实际上强调了一个抽象性原则，如果同样或类似的代码片段出现了两次以上，那么应该将它抽象成一个通用方法或文件，在需要使用的地方去依赖引入，确保在改动的时候，只需调整一处，所有的地方都改变过来，而不是到每个地方去找到相应的代码来修改。 在实际工作中，我见过两种在这条原则上各自走向极端的代码： 一种是完全没有抽象概念，重复的代码散落在各处，更奇葩的是，有一部分的抽象，但更多的是重复，比如在common下抽取了一个[代码]data.js[代码]的数据处理文件，部分页面中引用了该文件，而更多页面完全拷贝了该文件中的几个不同方法代码。而作者的意图则是令人啼笑皆非——只用到小部分代码，没必要引入那么整个文件。且不论现代化的前端构建层面可以解决这个问题，即使是引入了整个大文件，这部分多余的代码在gzip之后也不会损失多少性能，但这种到处copy的行为带来后续的维护成本是翻倍的。 对于这种行为还遇到另外一个理由，就是工期时间短，改不动之前的代码，怕造成外网问题，那就拷贝一份相同的逻辑来修改。比如支付逻辑，原有的逻辑为单独的UI浮层+单个支付购买，现在产品提出“打包购买”需求，原有的代码逻辑又比较复杂，出现了“改不动”的现象，于是把UI层和购买逻辑的几个文件整个拷贝过来，修改几下，形成了新的“打包购买”模块，后来产品又提出“按条购买”，按照上述”改不动“原则，又拷贝了一份“按条购买”的模块。这样一来调用处的逻辑就会冗余重复，需要根据不同的购买方式引入不同UI组件和支付逻辑，另外如果新添需求，如支持“分期付款”，那么将改动的是非常多的文件，最可悲的是，最后想要把代码重构为一处统一调用的人，将会面对三份“改不动”的压力，需要众多逻辑中对比分析提取相同之处，工作量已经不能用翻倍来衡量，而这种工作量往往无法得到产品的认同和理解。 另一种极端是过度设计，在写每个逻辑的时候都去抽象，让代码的可读性大大下降，一个简单的for循环都要复用，甚至变量定义，这种代码维护起来也是比较有成本的，还有将迥然不同的逻辑过度抽象，使得抽象方法变得非常复杂，经常“牵一发而动全身”，这种行为也是不可取的。 这也是将该原则排在首位的原因，这种行为导致的重构工作量是最大的，保持良好的代码维护性是一种素养，更是一种责任，如果自己在这方面逃避或偷懒，将把这块工作量翻倍地加在将来别人或自己的身上。 2. SRP(Single Responsibility Principle) SRP也是一个比较著名的设计原则——单一职责，在面向对象的编程中，认为类应该具有单一职责，一个类的改变动机应当只有一个。 对于前端开发来说，最需要贯彻的思想是函数应当保持单一职责，一个函数应当只做一件事，这样一来是保证函数的可复用性，更单一的函数有更强的复用性，二来可以让整体的代码框架更加清晰，细节都封装在一个个小函数中。另外一点也和单一职责有关，就是无副作用的函数，也称纯函数，我们应当尽量保证纯函数的数量，非纯函数是不可避免的，但应当尽量减少它。 把SRP原则排在第二位，因为它非常的重要，没有人愿意看一团乱麻的逻辑，在维护代码时，如果没有一个清晰的逻辑结构，所有的数据定义、数据处理、DOM操作等等一系列细节的代码全部放在一个函数中，导致这个函数非常的冗长，让人本能地产生心理排斥，不愿去查看内部的逻辑。 所有的复杂逻辑放在一个函数中，相信大家看到这样的代码都会眉头一皱: [代码]show: function(a, b) { if (!isInit) { init(); isInit = true; } // reset this.balance = 0; this.isAllBalance = false; var shouldShowLayer = true, preSelectedTermId = 0, needAddress = course.address_state, showTerms, termsObj; var hasPunish = false; this.course = course = course || {}; opt = opt || {}; opt.showMax = opt.showMax || 6; (isIosApp || b.isIAP) && (usekedian = !0, priceSymbol = '<i class="icon-font i-kedian"></i>'), f.splice(b.showMax), layer.show({ $container:b.$container, content:termSelectorTpl({ terms:f, curTermId:b.curTermId || d, name:a.name, hasPunish:h, userInfo:j }, { renderTime:T.render.time.renderCourseTime, renderCourseTime:renderCourseTime, hideUserInfo:b.hideUserInfo, hideTitle:b.hideTitle, hidePayPrice:b.hidePayPrice, confirmText:b.confirmText, sys_time:a.sys_time }), cls:"term-select-new", allowMove:function(a) { return opt.allowMove || ($target.closest('.select-content').length && $('.term-select-new .select-time').height() + $('.term-select-new .select-address').height() + $('.term-select-new .select-discounts').height() > (winWidth > 360 ? 190 : winWidth > 320 ? 175 : 150)); }, afterInit:function(c) { if (needAddress) { that.loadAddress(); // 如果需要地址，且是 app 的话，屏幕可见性切换时需要更新下地址 if (isApp) { $(document).on(visibilityChange, function (e) { // console.log('visibilityChange',document[hidden]); if (!document[hidden]) { // true 参数表示必须刷新 that.loadAddress(true); } }); } } that.afterTermSelect(); $dom.on('click', '.layer-close', function() { setTimeout(function() { !opt.noAutoHide && layer.hide(); }, 100); opt.onCancel && opt.onCancel(); }); $dom.on('click', '.term', function(e) { var $this = $(this); var $terms = $('.term'); if (!$this.hasClass('disabled')) { $terms.removeClass('selected'); $this.addClass('selected'); } that.afterTermSelect(); }); $dom.on('click', '.layer-comfirm', function(e) { var $this = $(this); var termId = $dom.find('.term.selected').data('term-id'); var termName = $dom.find('.term.selected').find('.term-title').html(); var discountId = $dom.find('.discounts-list_item.selected').data('discount-id'); var couId = $dom.find('.discounts-list_item.selected .discounts-coupon').data('cou-id'); var directPay = false; // ios 手Q IAP if (that.toRecharge) { // 需要充值的金额数目 var toRechargePrice = that.curPrice - that.balance; if (isIosApp) { require.async('api', function (api) { api.invoke('api', 'balanceRecharge', { amount: toRechargePrice }); // 充值完成设置回调 api.addEventListener('balanceRechargeCallBack', function(data) { // 支付成功的话 // code=0为成功，其他表示失败 // mode=1表示走充值档位回调，2表示直接充值回调,如果ios 直接充值成功则直接支付 var directPay = data.code === 0 && data.mode === 2; // 执行回调刷新数据 that.toGetBalance(that.course, termId, function() { directPay && $this.trigger('click'); }); }); }); } else { var toRechargePrice = that.curPrice - that.balance; if (that.rechargeMap && Object.keys(that.rechargeMap).indexOf("" + toRechargePrice) > -1) { that.opt.onComfirmClick && that.opt.onComfirmClick(1); iosPay.iosRecharge({ productId: that.rechargeMap[toRechargePrice], count: toRechargePrice, succ: function() { that.toGetBalance(that.course, $('.term.selected').data('term-id')); } }); } else { that.opt.onComfirmClick && that.opt.onComfirmClick(2); // T.jump('/iosRecharge.html?_bid=167&_wv=2147483651'); that.jumpPage('/iosRecharge.html?_bid=167&_wv=2147483651'); } } return; } if (!termId) { require.async(['modules/tip/tip'], function(Tip) { Tip.show(opt.dialogTitle); }); return true; } // check address if (needAddress && !that.addressid) { if (course.must_fill_mailing || !$dom.find('.select-address').hasClass('z-no')) { // 没填地址的话地址框要标红，然后需要滑到视窗让用户看到 var $cnt = $dom.find('.select-content'); var $addressWrap = $dom.find('.select-address_wrapper').addClass('z-err'); var cntRect = $cnt[0].getBoundingClientRect(); var addressBoxRect = $addressWrap[0].getBoundingClientRect(); // console.log('>>>>> ', cntRect, addressBoxRect); if (addressBoxRect.bottom > cntRect.bottom) { $cnt.scrollTop($cnt.scrollTop() + (addressBoxRect.bottom - cntRect.bottom)); } return; } } if (that.isAllBalance && that.opt.onComfirmClick) { that.opt.onComfirmClick(3); } opt.cb && opt.cb(termId, discountId, couId, termName, that.isAllBalance, that.payBalance, that.addressid); setTimeout(function() { !opt.noAutoHide && layer.hide(); }, 300); }); $dom.on('click', '.discounts-list_item', function(e) { var $this = $(this); var $discounts = $('.discounts-list_item'); var isSelected = $this.hasClass('selected'); if (!$this.hasClass('disabled')) { $discounts.removeClass('selected'); $this.addClass(isSelected ? '' : 'selected'); that.setPayPrice(); } }); $dom.on('click', '.address-person .i-edit2, .address-add', function() { var termId = $dom.find('.term.selected').data('term-id'); var courseId = that.course.cid; var src = '/addrEdit.html?_bid=167&_wv=2147483649&ns=1&fr=' + (location.pathname.indexOf('allCourse.html') > -1 ? 4 : location.pathname.indexOf('courseDetail.html') > -1 ? 2 : 3) + '&course_id=' + courseId + '&term_id=' + termId; // T.jump(src); that.jumpPage(src); }).on('click', '.select-address_title .i-right-light', function(e) { var $addressDom = $dom.find('.select-address'); var isOpen = !$addressDom.hasClass('z-no'); if (isOpen) { $addressDom.addClass('z-no'); that.theAddressid = that.addressid; that.addressid = undefined; } else { $addressDom.removeClass('z-no'); that.addressid = that.theAddressid; } }); } }); } else { opt.cb && opt.cb(opt.curTermId || preSelectedTermId); } } [代码] 单一职责并不一定要通过很多函数来完成，也可以用分段达到目的，如同这样： [代码]show(data) { data && this.setData(data); const renderData = { data: this.data, courseData: this.data.courseData, termList: this.termList, userInfo: this.userInfo, addrList: this.addrList, isIAP: this.isIAP, balance: betterDisplayNum(this.balance), curPrice: betterDisplayNum(this.curPrice), curTermId: this.curTermId, discountList: this.discountList, curDisId: this.curDisId, jdSelectId: this.jdSelectId, curAddrId: this.curAddrId }; const formatters = { // formatters termFormatter, priceFormatter, okBtnFormatter, balanceFormatter, priceFormatterWithDiscount }; console.log('[render data]: ', renderData); const html = payLayerTpl(renderData, formatters); // 记录滚动条位置 this._setScrollTop(); // 防止重复append if (this.$view) { this.$view.replaceWith(html); } else { this.$container.append(html); } afterUIRender(() => { this.$view = $('.' + COMPONENT_NAME).show(); this._setContentHeight(); // 动态设置滚动区域的高度 this._restoreScrollTop(); // 恢复滚动位置 this._initEvent(); this._initCountDown(); // 限时折扣倒计时 }); } [代码] 虽然这个函数也没有维持单一职责，但通过“分段”的形式清晰的表明了内部的流程逻辑，这样的代码看起来就会比所有细节揉在一个函数中好很多。 对于单一职责来说，保持起来还是比较困难的，主要在于职责的拆分，有时过于细致的职责拆分也会给阅读带来比较大的困难，对于这种情况，还是拿写作来对比，单一职责相当于文章的一个“段落”，对于文章来说，每个段落都有它的中心思想，可以用一句话描述出来，如果你发现函数的中心思想很模糊，或者需要很多语言去描述它，那也许它已经有很多个职责该拆分了。 3. LKP(Least Knowledge Principle) LKP原则是最小知识原则，又称“迪米特”法则，也就是说，一个对象应该对另一个对象有最少的了解，你内部如何复杂都没关系，我只关心调用的地方。 保持暴露接口的简介易用性也是API设计的通用规则，在实际中发现了这样的一个UI组件： [代码]module.exports = { show: function(course, opt) { // 此处省略一堆逻辑 }, jumpPage: function(url) { // 此处省略一堆逻辑 }, afterTermSelect: function() { // 此处省略一堆逻辑 }, setPrice: function() { // 此处省略一堆逻辑 }, setBalance: function() { // 此处省略一堆逻辑 }, toGetBalance: function(course, curTermId, cb) { // 此处省略一堆逻辑 }, setDiscounts: function(course, curTermId, curPrice) { // 此处省略一堆逻辑 }, filterDiscounts: function(discounts, curPrice) { // 此处省略一堆逻辑 }, isSuitCoupon: function(cou, curPrice) { // 此处省略一堆逻辑 }, setPayPrice: function() { // 此处省略一堆逻辑 }, setTermTips: function(wording) { // 此处省略一堆逻辑 }, loadAddress: function(needUpdate) { // 此处省略一堆逻辑 }, setAddress: function(addressid) { // 此处省略一堆逻辑 } } [代码] 这个UI组件暴露了非常多的方法，有业务逻辑，有视图逻辑，还有工具方法，这时会给维护者带来比较大的困扰，本能的以为这些暴露出去的方法都在被使用，所以想重构其中某些方法都有些不好下手，而实际上，外部调用的方法仅仅是[代码]show[代码]而已。 一个好的封装，无论内部多么复杂，它暴露出来的一定是最简洁实用的接口，而内部逻辑是独立维护的，如上述代码，作为一个UI组件来说，提供最基本的[代码]show/hide[代码]方法即可，有必要时可加入[代码]update[代码]方法自更新，而无需暴露众多细节，造成调用者和维护者的困扰。 4. 可读性基本定理 可读性基本定理——“代码的写法应当使别人理解它所需的时间最小化”。 代码风格和原则不是一概而论的，我们经常需要对一些编码原则和方案进行取舍，例如对于三元表达式的取舍，当我们觉得两种方案都占理时，那么唯一的评判标准就是可读性基本定理，无论写法多么的高超炫技，最好的代码依旧是让人第一时间能够理解的代码。 5. 有意义的名称 代码的可读性绝大部分依赖于变量和函数的命名，一个好的名称能够一针见血地帮助维护者理解逻辑，如同写文章中的“文笔”，文笔优异者总能将故事娓娓道来，引人入胜。 不过要起好名称还是很难的，尤其是我们不是以英语为母语，更是添加了一层障碍，有些人认为纠结在名称上会导致效率变低，开发第一时间应该完成需求的开发。这样说并没有错，我们在开发过程中应当专注于功能逻辑，但不要完全忽视命名，所谓“文笔”是需要锻炼的，思考的越多，命名就会愈加的水到渠成，到后来也就不太会影响工作效率了。 在这里推荐鲍勃大叔提到的童子军规，每一次看自己的代码，都进行一次重构，最简单的重构便是改名，也许一开始觉得命名还比较贴合，但逻辑越写越不符合初始的命名了，当回顾代码时，我们可以顺手对变量和方法进行重新命名，现代编辑工具也很容易做到这一点。 文不对题的命名是最可怕的，如： [代码]function checkTimeConflict(opts) { if (opts.param.passcard || (T.bom.get('autopay') && T.bom.get('term_id'))) { selectToPay({ result: {} }, opts); } else { DB.checkTimeConflict({ param: { course_id: opts.param.courseId, term_id: opts.param.termId }, succ: function(data) { selectToPay(data, opts); }, err: function(data) { dealErr(opts, data); } }); } } [代码] 这个函数被命名为[代码]check*[代码]开头的，本意是检测课程时间是否冲突，但内部逻辑却包含了支付整个流程，此时对于调用者来说，如果不去细看内部逻辑，很有可能就会错误的认为[代码]check[代码]函数没有副作用导致事故发生。 6. 适当的注释维护 注释是一个比较有争议性的话题，有人认为可读的函数变量就很清晰，不需要额外的注释，且注释有不可维护性，如： [代码]// 1-PC, 2-android手QH5, 3-android APP, 4-ios&非手QH5, 5-IOS APP var platform = isAndroidApp ? 3 : isIosApp ? 5 : 4; [代码] 实际上，这个字段的含义早已发生了改变，但由于修改者只修改了逻辑，并没有注意到这一行注释，导致这个老注释提供了错误信息，此时的注释不仅变成了无效注释，甚至会导致维护人的误解，造成bug的产生。 对于这种情况，要么维护注释，要么在注释里面注明接口文档，维护文档，在其他情况下，适当的注释是有必要的，对于复杂的逻辑，如果有一个简练的注释，对于代码可读性的帮助是极大的，但有些不必要的注释可以去掉，注释的取舍关键在于可读性基本定理，如： [代码]const filterFn = (term) => { if (rule.hideEndTerms && term.is_end) { return false; // 隐藏已结束的期 } if (rule.hideSignEndTerms && term.is_out_of_date) { return false; // 隐藏已结束报名的期 } if (rule.hideAppliedTerms && courseUtil.isTermApplied(term)) { return false; // 隐藏已报名的期 } if (rule.hideZeroAllowedTerms && courseUtil.isTermZero(term)) { return false; // 隐藏名额已满的期 } if (rule.productType === productType.PACKAGE) { return false; // 隐藏课程包的班级 } return true; }; [代码] 对于上述逻辑来说，虽然通过变量可以大致猜出功能含义，但一眼看上去就能清晰掌握逻辑结构，归功于注释的简明与清晰。 小结 本文提到的6个代码编写的原则，前三个偏向于代码维护性，后三个偏向于代码可读性，整个可维护性和可读性构成了代码的基本素养。作为一名前端开发工程师，想要拥有良好的代码素养，首先要让自己的代码可维护，不给别人的维护带来巨大的成本和工作量，其次尽量保证代码的美观可读，整洁的代码人见人爱，如同阅读一本好书，令人心情愉悦。 ”代码素养“是一种态度，真正热爱编程的程序员一定不会缺失“代码素养”。我们通常称“写代码”为[代码]“程序设计”[代码]，而不是“程序编写”，“设计”一词体现出了我们的代码是一件作品，也许不如“艺术品”那么精致，但也不是什么粗麻烂布，如果在写代码时天马行空，得过且过，抱着只要能实现功能的思想，那这部“作品“是不具有观赏价值的，这不仅仅体现出代码编写者的”不专业”，更是反映出对待编程这件事的态度，代码的整洁程度、可维护性取决于你是否真正“在意”你的代码，每个程序员不一定热爱编程，但请你一定要以“认真”的态度对待自己的专业。 [代码]"clean code"[代码]的作者鲍勃大叔提到，有人曾送给他一条腕带，上面写着“Test Obsessed”，他发觉自己带上后再也无法取下了，不仅是因为腕带很紧，更是因为它也是一条精神上的紧箍咒。在编程时，我们下意识的看下自己的手腕，是否能发现一条隐形的腕带呢？

　　THREE.js开发的应用运行在iphone5下发现有些时候会崩溃，跟了几天发现是因为Sprite太多频繁更新纹理占用显存导致的。通常解决纹理频繁更新问题就要用到one draw all方法，放到纹理上就是把所有纹理图片生成一张大图片的方式   一、阻止纹理重复上传　　我们需要一张大纹理，先将所有的内容绘制在大纹理上，需要显示局部纹理的时候通过纹理坐标控制去大纹理上取图像。那么这个时候问题来了，THREE.js内部实现方式是将Texture与图片、纹理坐标绑定，即使为所有的Texture对象设置同一张图片，THREE.js仍然会将每个Texture中的图片上传给GPU。每次上传一张大纹理严重阻塞UI渲染进程。[图片] [图片] 　　首先要解决的是让这张大纹理值上传一次。 　　这个问题需要我们对THREE.js源码进行深入了解，可以看到setTexture2D函数中有一个properties变量，这个变量是一个WebGLProperties类型的变量，而该类型存储各种东西：Texture、Material、RenderTarget、Object的buffers等。我们继续深入该类的源码，发现get方法会根据对象的uuid来获取相关WebGL属性，比如gl.createTexture、gl.createBuffer创建的各种缓冲区。 [图片]  　　对应Texture得到的webgl属性如下，其中__webglTexture就是对应的纹理图片创建的缓冲区对象。 [图片] 那么我们可以来一个取巧的方法，将所有纹理的的uuid都设置唯一，那么THREE.js只会对第一个Texture的纹理进行上传，后面的texture对象取到的都是第一个的properties，这样就能避免纹理重复上传。 [图片]  二、建立纹理索引　　我们需要自己维护一套索引关系，通过这套索引关系得到每个贴图在大纹理中纹理坐标。这里要为每一个poi记录它的起始位置和区域范围，其中要用到canvasContext.measureText来测量文本的宽度，文本高度可以直接根据fontSize取得。 [图片]  　　同时索引建立完毕后，需要计算每个poi区域在全局纹理中的纹理坐标范围： [图片] 　　要注意的是，这里纹理坐标的原点在左下方，有时候原点在左上方。建立索引代码如下 [图片] 三、局部更新　　上述方案虽然能够避免频繁上传纹理，但是需要每次将需要绘制的内容准备好，当有内容需要更新时，还是需要重新上传整个全局纹理，反而使得性能下降巨大。经过查阅资料后发现webgl中有一种局部纹理更新技术，简单来说先在内存中开辟一块的纹理区域，将所有内容绘制在这张全局纹理中，每次有更新时，只需要更新它的一个局部区域即可。 　　但是这里要解决的问题是THREE.js并没有提供局部纹理更新的方式，也没有相应的自定义接口，那么这时候就需要我们自己来处理了。 　　这里自定义一个Texture的子类 [图片] 　　开辟一块内存区域 [图片] 　　在需要的时候动态更新局部纹理，其中src这里是ImageData对象[图片]　 　　具体代码可以参考这里，我这里也是基于它来定制的。 　　https://github.com/spite/THREE.UpdatableTexture 　　原文作者通过更改THREE.js源码的方式实现，而我是直接把下面这个函数拷贝到这个子类中 [图片] 四、高清屏的大坑　　现在我们的方案是，先在gpu中开辟一块全局纹理区域，然后绘制时将poi绘制到一张与全局纹理同样大小的canvas上，然后从canvas中调用createImageData来获取像素，将像素局部更新到gpu中。那么在pc上我们得到的结果很完美。 [图片]   然而放到移动端上后，我们得到的结果是：[图片]    [图片] 　　TMMD中间那块哪去了！找了大半天发现问题出现在高清屏上，挡在高清屏上绘制canvas上时，我们通常会做一些高清处理，比如四像素绘制一像素。 　　我们做高清处理的方式是利用radio*radio设备像素绘制一css像素，看起来是css像素的大小，但实际在浏览器内部，看起来css上一像素实际在canvas里的像素是radio * radio（radio代表window.devicePixelRatio） [图片] 　　但实际上在浏览器内部绘制canvas图像的单位是设备像素。那么如果我们还以上面的rectW、rectH来获取像素的话，我们得到的这部分像素并不是这个poi真正占有的像素数目。 [图片] 　　所以，问题就来了我们需要在gpu开辟的全局纹理的单位跟canvas中获取像素的单位要保持一致，我们统一使用设备像素。  [图片]  　　我们对canvas也不用使用style来设置样式宽高了。 [图片]  　　那么获取poi图像的真正像素范围时： [图片]  　　所以利用getImageData取像素时候，就要小心取到真正的像素区域，（startX * radio，startY * radio）- （poiRectW * radio, poiRectH * radio）;否则某些像素就会被丢弃掉，这部分像素才是浏览器真正使用的设备像素。  　　现在在移动设备上能够获取正确的高清label啦！ [图片] 五、局部更新引起的新问题 　　当全局纹理被占满时候，在继续绘制poi，这时候新的poi区域需要更新到gpu中，那么也就带来了新的问题，在gpu中的纹理还保持着之前的像素，而新的poi会覆盖这部分区域，但有时候往往会与之前的文字叠加起来，效果如下： [图片] 　　可以看到新更新的poi，在计算纹理坐标时候，有一部分像素包含了其他poi的像素。这个问题是因为新poi的区域刚好叠在了先前poi的边界上，那么我们只要给新的poi加一点buffer，这个buffer是白素透明区域，buffer会把之前的poi像素覆盖掉，而我们计算纹理坐标时，只取poi的边界，那么就可以解决这个问题。 [图片] 　　那么首先绘制的时候就要保留buffer [图片] 　　上传的时候使用buffer [图片] 　　计算纹理坐标时，排除buffer [图片] 六、局部更新带来的性能问题　　根据目前的结果，局部更新能后解决crash的问题，但是带来了严重的性能开销，与同事应用局部更新提升性能的结果相反。这个问题还要继续跟踪。 　　目前发现问题是因为使用了getImageData来获取数据，然后传递到gpu中，非ios设备用这种方式有时候getImageData的开销特别大，而ios设备相对好一些。 　　测试发现非ios设备直接上传一张大纹理的效果反而比getImageData这种方式更好。但是依然不如之前上传多个canvas的性能。而在iphone5的测试机和iphone6的机器上性能比之前直接上传多个canvas的方式好一些，且没有崩溃问题。但是在岳阳的iphone6 plus 16g内存的手机上发现用具局部纹理更新性能很差，而且经常崩溃。 　　后来发现原因是因为，虽然getImageData在IOS上性能好过非IOS设备，但性能开销仍然比较大，所以当场景中POI很多时，仍然会引起主线程卡顿，甚至计算太密集引起浏览器崩溃。其中层尝试使用cesium方式，每个poi创建新的canvas，将canvas进行局部上传，本以为这种方式不需要getImageData会更快一些，然而实践发现每次创建canvas设置参数的过程更耗时。 　　最终的方案是仍然使用getImageData，但是将getImageData的过程分块处理，每50ms处理一次，分块放到场景中，这样就解决密集计算引起的崩溃问题，虽然增加了控制成本，但是能够有效解决IOS崩溃问题。有趣的是在安卓上getImageData方式开销很大，即使分块也不适合，而且安卓用一张大纹理的方式来处理，会发现很多POI绘制效果不好。 [图片] 　　最终方案是，IOS使用getImageData局部纹理+分块加载方式绘制POI。安卓使用POI独立创建canvas+全量加载方式。（安卓不适用分块加载，是为了尽快把所有POI呈现给用户） 七、文字黑色描边问题 　　这个问题自始至终困扰我好久一直没找到黑边的原因； [图片] 　　将原始的canvas导出后发现这是因为原始的canvas就有一层边界 [图片] 　　曾经怀疑是minFilter的设置不对在pc端纹理使用NEARESTFilter方式取值发现的确能够消除黑边，然而移动端仍然会出现黑边，最后使用颜色混合公式解决问题。 　　gl.blendFunc(gl.ONE, gl.ONE_MINUS_SRC_ALPHA); 　　在Three.js中需要设置SpriteMaterial的blending为CustomBlending 八、颜色混合新问题 　　但是使用上述方式同样引来新问题，设计反映poi的icon四周被裁切掉， [图片] 　　看着没问题是吧，设计同学截了图之后放大了20倍。。。。。 [图片] 　　刚开始我确实以为这是webgl渲染问题，后来仔细考虑了下这外圈白色的由来（遇到问题还是得静下心分析）。 　　原因是设置了blendFunc（SrcAlphaFactor，OneMinusSrcAlphaFactor）导致有些icon周围的像素alpha比较低  [图片] 　　颜色混合后增加了target的颜色分量，导致最终这些区域的颜色范围接近255，所以泛白。从而把原来图片四周有切边的问题充分暴露出 　　解决方法是设置alphaTest，如果原始纹理的alpha小于这个值则直接discard。最终得到的效果是： [图片][图片][图片]  九、TextureAlta问题 　　前面因为sprite的旋转中心只能放在sprite纹理区域的中心所以，上面做了很多冗余纹理，有很多空白区域，目前改造了Sprite加了pivot可以动态改变选中中心点，改变后IOS下纹理的使用率提升了60%，安卓下因为是单个纹理上传所以，需要保证纹理的大小是2的n次方，纹理的浪费率降低了50% 　　上述问题虽然解决了崩溃问题，但是实际使用中每个poi都要getImageData和texSubImage2D这个方法，造成单个poi耗时基本在25ms（iphone5  8.4.4）;虽然上面使用setTimeout 50ms分块方式上传，但是如果poi过多比如1000多的停车场，这样会导致停车场数据需要50s才能完全显示出来。这次优化的方案是等待所有poi图片拿到后，绘制所有的poi把画布调用一次getImageData和一次texSubImage2D上传到gpu，同时下次更新时，只会增量一次性上传更新。 [图片] 十、Frstrum增量更新　　原来是在每一级别缩放时把所有的poi都生成好，现在的做法是只生成视锥体中能看得到的poi，然后在每次OrbitControl出发change事件时根据视锥体判断poi，做去重后增量更新 [图片]  　　目前还是有些问题，有时候会碰到视锥体中的poi很少，可能是判断问题，后续会加入空间索引，根据索引和视锥体结合起来做增量更新 　　后续使用发现在停车场这种大数据的poi全部加载到地图下，使用这种方式每次都要做去重处理，性能开销很大，处理方式是使用{}做hash代替数组includes方法，结果发现性能提示很大，原来3600个节点每次去重处理在iphone 16g 10.3.3上性能基本在28帧每秒，经过优化后数据帧率达到50+（主流iPhone7fps60）；iphone5 16g 8.4.1 性能在24左右优化后帧率在44+，安卓华为荣耀9优化前25帧，优化后 40+ [图片]安卓之所以不适用IOS的绘制方式，是因为这种在安卓上的绘制效果不理想，被设计挑战 　　安卓后面也做了一些优化，之前安卓是每次都会重新创建canvas并上传至gpu纹理中，导致使用视景体增量更新poi时，性能有所下降，后来每一层中的poi都根据icon、文字组成key缓存起来，并且缓存纹理，不但阻止canvas的重复创建，还阻止canvas重复上传至gpu纹理（three中使用同一uuid），使用该方案荣耀9的fps达到50+ 十一、text glyphs该方式还有待尝试 https://webglfundamentals.org/webgl/lessons/webgl-text-glyphs.html 十二、真正解决POI文字黑边问题　　由于要做poi渐变出现效果，但是因为之前处理黑边问题用的是颜色混合的方式，所以当动态改变透明度时，受颜色混合影响往往是文字颜色先消失，剩下透明度部分还存在显示先过很差。所以要实现渐变效果，不能使用颜色混合方法，但不适用颜色混合就会有黑边问题，所以要从源头上解决黑边问题。（看到最后会发现有残影） [图片] 　　那么思考黑边到底是怎么产生的，这与webgl中纹理插值的颜色有关，有的设备像素取纹理时有不同的方案，但一般情况下纹理像素和设备像素都不是一一对应，所以有插值取值问题。 [图片] 　　这是正常情况下利用canvas绘图时背景颜色不设置，那么可以看到我们绘制出来的canvas的确有一层奇怪的黑边。当设备取到纹理中这些边界时就会产生黑边。那么就要思考怎么不让它取到这层黑边，这个问题想了好久曾经试过用opacity过滤，发现不能解决问题。 [图片] 　　有一天突然想到如果canvas背景为有颜色，每个设备像素都能取到颜色，那么就不会有这个问题。所以我们能否通过改一下canvas的背景颜色同时有通过透明度过滤掉不合格的像素？最终发现这个问题还真可以。 　　首先在绘制时将canvas背景设置为白色，但是有很低的透明度 [图片] 这时候canvas绘制出来的效果是 [图片] 　　可以看到已经没有黑边了，那么这时候设备像素永远不会取到黑色边界，也就彻底解决了黑边问题。 　　那么就可以利用tween来做动画了  

最近在做一个翻页交互，遇到点setData的坑，最后想了个办法给绕过去了，但我不知道各位有没有更好的办法，在这里分享下我的处理办法； 例如我有个列表，这个列表的总数据量不确定有多少，经我们产品交代，大促期间，至少会有1000条，从小程序的开发文档里可以看到setData对数据的限制是1024KB，因为之前我看文档时没有注意到这一点，所以我一开始在做分页的时候就用了错误的方法，上代码: wxml: [代码] [代码] [代码]<[代码][代码]sku-item[代码] [代码]    [代码][代码]wx:for[代码][代码]=[代码][代码]"{{skuList}}"[代码][代码]    [代码][代码]skuData[代码][代码]=[代码][代码]"{{item}}"[代码][代码]    [代码][代码]actId[代码][代码]=[代码][代码]"{{actId}}"[代码][代码]    [代码][代码]wx:key[代码][代码]=[代码][代码]"{{item.skuid}}"[代码][代码]/>[代码] [代码] [代码] js: [代码] [代码] [代码]data: {[代码] [代码]    [代码][代码]skuList: [][代码][代码]},[代码][代码]loadMore: [代码][代码]function[代码][代码]() {[代码][代码]    [代码][代码]request([代码][代码]function[代码][代码](res) {[代码][代码]        [代码][代码]this[代码][代码].setData({[代码][代码]            [代码][代码]skuList: [代码][代码]this[代码][代码].data.skuList.concat(res.list)[代码][代码]        [代码][代码]});[代码][代码]    [代码][代码]})[代码][代码]}[代码] [代码] [代码] 好，这样写，问题就出来了，当数据量慢慢的累积起来，就会触发1024KB阈值，后面的数据就算能取回来，也set不进去了。 于是我想了一个解决方案： 把之前的渲染流程拆成两步来做，第1步: 先想办法把每页的坑位给渲染出来，于是我搞了一个skuPage组件, 在这个组件中来单独做每页的sku渲染： wxml: [代码] [代码] [代码]<[代码][代码]sku-item[代码] [代码]    [代码][代码]wx:for[代码][代码]=[代码][代码]"{{skuList}}"[代码][代码]    [代码][代码]skuData[代码][代码]=[代码][代码]"{{item}}"[代码][代码]    [代码][代码]actId[代码][代码]=[代码][代码]"{{actId}}"[代码][代码]    [代码][代码]wx:key[代码][代码]=[代码][代码]"{{item.skuid}}"[代码][代码]/>[代码] [代码] [代码] js: [代码] [代码] [代码]data: {[代码] [代码]    [代码][代码]skuList: [][代码][代码]},[代码][代码]methods: {[代码][代码]    [代码][代码]setListData: [代码][代码]function[代码] [代码]() {[代码][代码]        [代码][代码]let _this = [代码][代码]this[代码][代码];[代码][代码]        [代码][代码]this[代码][代码].setData({[代码][代码]            [代码][代码]skuList: app.globalData.skuList[代码][代码]        [代码][代码]});[代码][代码]        [代码][代码]app.globalData.skuList = [];[代码][代码]    [代码][代码]}[代码][代码]},[代码][代码]ready: [代码][代码]function[代码][代码]() {[代码][代码]    [代码][代码]this[代码][代码].setListData();[代码][代码]}[代码] [代码] [代码] 在外部页面中调用skuPage组件: wxml: [代码] [代码] [代码]<[代码][代码]sku-page[代码] [代码]    [代码][代码]class[代码][代码]=[代码][代码]"sku-page"[代码][代码]    [代码][代码]wx:for[代码][代码]=[代码][代码]"{{pageWrapCount}}"[代码][代码]    [代码][代码]wx:key[代码][代码]=[代码][代码]"{{index}}"[代码][代码]    [代码][代码]actId[代码][代码]=[代码][代码]"{{actId}}"[代码][代码]/>[代码] [代码] [代码] js: [代码] [代码] [代码]data: {[代码] [代码]    [代码][代码]pageWrapCount: [][代码][代码]},[代码][代码]loadMore: [代码][代码]function[代码][代码]() {[代码][代码]    [代码][代码]app.globalData.skuList = res.list;[代码][代码]    [代码][代码]request([代码][代码]function[代码][代码](res) {[代码][代码]        [代码][代码]this[代码][代码].setData({[代码][代码]            [代码][代码]pageWrapCount: [代码][代码]this[代码][代码].data.pageWrapCount.concat([1])[代码][代码]        [代码][代码]});[代码][代码]    [代码][代码]})[代码][代码]}[代码] [代码] [代码] 好，这样我们把取回的数据先不要立马set进去，而是把它先丢在global里，然后让坑位+1，这样skuPage就会新增一个，就会触发skuPage的ready钩子函数，这个时候再在skuPage的ready钩子中，从global中把list取过来丢给skuPage组件的skuList，让skuPage组件去渲染，这样就能绕开setData的1024KB上线，因为每次针对于坑位来说 [代码] [代码] [代码]this[代码][代码].setData({[代码] [代码]   [代码][代码]pageWrapCount: [代码][代码]this[代码][代码].data.pageWrapCount.concat([1])[代码][代码]});[代码] [代码] [代码] 我只对pageWrapCount数组push(1); 就算有1024KB限制，那也远远足够了，除了此种办法外，各位还有更好的办法么？欢迎共享经验