- 当前 Bug 的表现（可附上截图） [图片] - 预期表现 - 复现路径 - 提供一个最简复现 Demo <text class='cell_title'>开户人</text> <input disabled='{{collectionState==1 || collectionState==3}}' class='match_parent' value='{{collectionState==1 || collectionState==3 ? UtWxs.hideName(accountName) : accountName}}' placeholder-class='placeholder_class' placeholder='请输入开户人姓名' bindinput='meBindAccountName' confirm-type='next' /> 我们公司开发一款小程序，里面有这么一个需求，就是验证用户名和身份证号码，结果客户填写名字和身份证照到后台后，经常名字的最后一个字丢失，和上传的照片对应不起来，导致审核不通过，客服都要打爆电话了，求解决~~~

能力应用 微信提供的OCR证件识别接口能力，可应用于特定行业或场景，需要用户提供证件信息才可以继续使用服务，且需要基于用户的实体证件。开发者通过拍照后，调用api传入，识别证件对应信息。 接口介绍 2.1接口功能 本接口提供基于小程序/H5的身份证OCR识别。 2.2接口限制及申请 1、已认证的订阅号、服务号、企业号、小程序可购买后调用，属于正式开放状态。（2020年4月1日起，每日支持100次免费调用，更多调用次数，需购买后使用） 2、接口购买及指引，可点击此处查看详细描述。 2.3支持证件 身份证、银行卡、行驶证 2.4接口文档 详细接口文档，可以点击此处查阅。 2.5使用TIPS 此接口包含后台接口及小程序插件。后台接口，可搭配小程序/H5的拍照、相册选照等一起使用。可完成证件照片的采集、上传、识别、信息返回等流程，用于需要基于实体证件，采集照片或文字信息等的业务场景。 另提供OCR身份证、银行卡、行驶证识别小程序插件服务，可在微信开放社区插件模块中查看，详细介绍可以点击此处查阅。

为更好地保护用户隐私信息，优化用户体验，平台将会对小程序内的帐号登录功能进行规范。本公告所称“帐号登录功能”是指开发者在小程序内提供帐号登录功能，包括但不限于进行的手机号登录，getuserinfo形式登录、邮箱登录等形式。具体规范要求如下： 1．服务范围开放的小程序 对于用户注册流程是对外开放、无需验证特定范围用户，且注册后即可提供线上服务的小程序，不得在用户清楚知悉、了解小程序的功能之前，要求用户进行帐号登录。 包括但不限于打开小程序后立即跳转提示登录或打开小程序后立即强制弹窗要求登录，都属于违反上述要求的情况； 以下反面示例，在用户打开小程序后立刻弹出授权登录页； [图片] 建议修改为如下正面示例形式：在体验小程序功能后，用户主动点击登录按钮后触发登录流程，且为用户提供暂不登录选项。 [图片] 2．服务范围特定的小程序 对于客观上服务范围特定、未完全开放用户注册，需通过更多方式完成身份验证后才能提供服务的小程序，可以直接引导用户进行帐号登录。例如为学校系统、员工系统、社保卡信息系统等提供服务的小程序；  下图案例为正面示例：校友管理系统，符合规范要求。 [图片] 3．仅提供注册功能小程序 对于线上仅提供注册功能，其他服务均需以其他方式提供的小程序，可在说明要求使用帐号登录功能的原因后，引导用户进行帐号注册或帐号登录。如ETC注册申请、信用卡申请； 如下反面示例，用户在进入时未获取任何信息，首页直接强制弹框要求登录注册ETC，这是不符合规范的。 [图片] 建议修改为如下正面示例所示形式：允许在首页说明注册功能后，提供登录或注册按钮供用户主动选择点击登录。 [图片] 4．提供可取消或拒绝登录选项 任何小程序调用帐号登录功能，应当为用户清晰提供可取消或拒绝的选项按钮，不得以任何方式强制用户进行帐号登录。 如下图所示反面示例，到需要登录环节直接跳转登录页面，用户只能选择点击登录或退出小程序，这不符合登录规范要求。 [图片] 建议修改为下图正面示例形式，在需帐号登录的环节，为用户主动点击登录，并提供可取消按钮，不强制登录。 [图片] 针对以上登录规范要求，平台希望开发者们能相应地调整小程序的帐号登录功能。如未满足登录规范要求，从2019年9月1日开始，平台将会在后续的代码审核环节进行规则提示和修改要求反馈。

一、能力背景 近年来，国家在医疗挂号、APP注册、快递收寄、客运、运营商等多领域规定，需要用户实名才可办理业务，预计后续也会有越来越多的此类法规。因此，微信参照公安部“互联网+”可信身份认证服务平台标准，依托腾讯公司及微信的生物识别技术，建立微信“实名实人信息校验能力” ，即通过人脸识别+权威源比对，校验用户实名信息和本人操作（简称微信人脸核身）。 目前接口限定主体及行业类目开放公测，提供给资质符合要求的业务方，在合适的业务场景内使用。目前仅支持持二代身份证的大陆居民。 由于人脸核身功能涉及到用户的敏感、隐私信息，因此调用此接口的小程序，需要满足一定的条件。即：小程序的主体以及类目，需要在限定的类目范围内，且与小程序的业务场景一致。开展的业务也需要是国家相关法规、政策规定的需要“实名办理”的相关业务（其他未在范围内的业务，则暂不支持）。 以下为接口接入及开发的详细内容。如开发中遇到任何疑问，可以点击此处通过社区反馈，将有工作人员跟进回复。 文档第四部分【再次获取核验结果api】，有助于提高业务方安全性，请务必接入！ 现阶段微信人脸核验能力，针对小程序，开放的主体类目范围包含： 小程序一级类目 小程序二级类目 小程序三级类目 使用人脸核验接口所需资质 物流服务 收件/派件 / 《快递业务经营许可证》 物流服务 货物运输 / 《道路运输经营许可证》（经营范围需含网络货运） 教育 学历教育（学校） / （2选1）：1、公立学校：由教育行政部门出具的审批设立证明 或 《事业单位法人证书》；2、私立学校：《民办学校办学许可证》与《民办非企业单位登记证书》 医疗 公立医疗机构 / 《医疗机构执业许可证》与《事业单位法人证书》 医疗 互联网医院 / 仅支持公立医疗机构互联网医院（2选1）：1、卫生健康部门的《设置医疗机构批准书》；2、 《医疗机构执业许可证》（范围均需含“互联网诊疗”或名称含“互联网医院”等相关内容 医疗服务 三级私立医疗机构 / 仅支持三级以上私立医疗机构，提供《医疗机构执业许可证》、《营业执照》及《医院等级证书》 政务民生 所有二级类目 / 仅支持政府/事业单位，提供《组织机构代码证》或《统一社会信用代码证》。 金融业 银行 / （2选1）：1、《金融许可证》； 2、《金融机构许可证》。 金融业 信托 / （2选1）：1、《金融许可证》； 2、《金融机构许可证》。 金融业 公募基金 / （4选1）：1、《经营证券期货业务许可证》且业务范围必须包含“基金”；2、《基金托管业务许可证》； 3、《基金销售业务资格证书》；4、《基金管理资格证书》。 金融业 证券/期货 / 《经营证券期货业务许可证》 金融业 保险 / （8选1）：1、《保险公司法人许可证》；2、《经营保险业务许可证》；3、《保险营销服务许可证》；4、《保险中介许可证》；5、《经营保险经纪业务许可证》；6、《经营保险公估业务许可证》或《经营保险公估业务备案》；7、《经营保险资产管理业务许可证》 ；8、《保险兼业代理业务许可证》。 金融业 消费金融 / 银监会核准开业的审批文件与《金融许可证》与《营业执照》 金融业 汽车金融/金融租赁 / 仅支持汽车金融/金融租赁主体，同时提供：1、《营业执照》（公司名称包含“汽车金融” /“金融租赁”；营业范围包含“汽车金融”/“金融租赁”业务）；2、《金融许可证》或银保监会及其派出机构颁发的开业核准批复文件。 交通服务 网约车 快车/专车/其他网约车 （自营性网约车）提供《网络预约出租汽车经营许可证》。（网约车平台）提供与网约车公司的合作协议以及合作网约车公司的《网络预约出租汽车经营许可证》。 交通服务 航空 / （航司）提供《公共航空运输企业经营许可证》。（机场）提供《民用机场使用许可证》或《运输机场使用许可证》。 交通服务 公交/地铁 / 提供公交/地铁/交通卡公司《营业执照》 交通服务 水运 / （船企）提供《水路运输许可证》。（港口）提供《港口经营许可证》 交通服务 骑车 / 仅支持共享单车，提供共享单车公司《营业执照》 交通服务 火车/高铁/动车 / 仅支持铁路局/公司官方，提供铁路局/公司《营业执照》 交通服务 长途汽车 / （2选1）：1、《道路运输经营许可证》（经营范围需含客运）；2、官方指定联网售票平台（授权或协议或公开可查询文件）。 交通服务 租车 / 运营公司提供《备案证明》与对应公司《营业执照》，且营业执照中包含汽车租赁业务 交通服务 高速服务 / 仅支持ETC发行业务，（2选1）：1、事业单位主体，需提供《事业单位法人证书》；2、官方指定的发行单位（一发单位），需提供“官方授权或协议，或公开可查询的文件”； 生活服务 生活缴费 / （供电类）提供《电力业务许可证》与《营业执照》，且《营业执照》且经营范围含供电。（燃气类）提供《燃气经营许可证》与《营业执照》，且《营业执照》且经营范围含供气。（供水类）提供《卫生许可证》与《营业执照》。（供热类）提供《供热经营许可证》与《营业执照》，且《营业执照》且经营范围含供热。 IT科技 基础电信运营商 / （2选1）：1、基础电信运营商：提供《基础电信业务经营许可证》；2、运营商分/子公司：提供营业执照（含相关业务范围）。 IT科技 转售移动通信 / 仅支持虚拟运营商，提供《增值电信业务许可证》（业务种类需含通过转售方式提供移动通信业务） 旅游服务 住宿服务 / 仅支持酒店，提供《酒店业特种行业经营许可证》 商业服务 公证 / 仅支持公证处，提供《公证处执业许可证》或《事业单位法人证书》 社交 直播 / （2选1）：1、《信息网络传播视听节目许可证》；2、《网络文化经营许可证》(经营范围含网络表演）。 如对以上类目或资质有疑问，可点击参考小程序“非个人主体开放的服务类目”，详细了解小程序开放的服务类目及对应资质。 二、准备接入 （请在小程序发布后，再提交人脸核身接口申请） 满足第一节中描述的类目和主体的小程序，可申请微信人脸核验接口。目前微信人脸核身接口已改为线上自助申请方式，需按照如下图例指引，进行接口申请： 第一步：请通过mp.weixin.qq.com登录小程序账号在后台“功能-人脸核身”的路径，点击开通按钮—— [图片] 第二步：仔细查阅《人脸识别身份信息验证服务条款》后，点击“同意并下一步”—— [图片] 第三步：请正确填写服务信息，并上传该小程序类目下所要求的资质—— [图片] 第四步：请按照业务实际需求填写使用人脸接口的场景和用途—— [图片] 第五步：请完善测试信息和联系人—— [图片] 第六步：提交后请耐心等待1-3个工作日的审核期，审核结果将以站内信通知—— 如申请期间遇到问题，可联系腾讯工作邮箱 wx_city@tencent.com，将会有相关工作人员进一步指引。 三、接口文档： (一)接口描述 名称: wx.startFacialRecognitionVerify(OBJECT) 功能：请求进行基于生物识别的人脸核身 验证方式：在线验证 兼容版本： 一闪：android 微信7.0.22以上版本, iOS 微信7.0.18以上版本 建议在微信官网升级至最新版本 (二)参数说明 1、OBJECT参数说明： 参数 类型 必填 说明 name String 是 姓名 idCardNumber String 是 身份证号码 success Function 否 调用成功回调 fail Function 否 调用失败回调 complete Function 是 调用完成回调（成功或失败都会回调） 2、CALLBACK返回参数 参数 类型 说明 errMsg String 错误信息 errCode Number 错误码 verifyResult String 本次认证结果凭据，第三方可以选择根据这个凭据获取相关信息 注 1：传递用户姓名和身份证有两种方式 业务方没有用户实名信息，用户需要在前端填写身份证和姓名，那么前端直接通过jsapi 调用传递 name 和 idCardNumber。 业务方已经有用户实名信息，后台通过微信提供的 api（详情见文档后面“上传姓名身份证后台 api”）上传用户身份证姓名和身份证，api 返回 user_id_key 作为凭证传给前端，前端再调用 jsapi，用户姓名、身份证信息不需要经过前端，参数只需要传递 userIdKey。Tips：使用该功能需要小程序基础库版本号>=1.9.3。 3、回调结果说明 回调结果请参考以下释义： [图片] [图片] [图片] 4、示例代码 [图片] [图片] (三)上传用户姓名身份证的后台api 1、API说明 1.1说明 业务方上传用户姓名和身份证，获取用户凭证，把凭证给到前端通过 jsapi 调用。 Tips ：使用该功能需要小程序基础库版本号>=1.9.3。 1.2请求URL https://api.weixin.qq.com/cityservice/face/identify/getuseridkey?access_token={ac cess_token} 1.3请求方式 POST 2、请求数据格式 [代码]Json { "name" : “张三”, "id_card_number" : "452122xxxxxxx43215" } [代码] 请求示例 [代码]#!/bin/bash TOKEN='xxxxxxxxxxxx' URL='https://api.weixin.qq.com/cityservice/face/identify/getuseridkey' JSON='{ "name": "张三", "id_card_number": "452344xxxxxxxxxxxxx234"}' curl "${URL}?access_token=${TOKEN}" -d "${JSON}" [代码] 参数说明 json 字段 中文显示 是否必传 name 姓名 是 id_card_number 身份证号码 是 out_seq_no 业务方唯一流水号 否 3、返回数据 参数 类 型 说明 errcode int 错误码 errmsg string 错误信息 user_id_key string 用于后台交互表示用户姓名、身份证的凭证 expires_in uint32 user_id_key 有效期，过期需重新获取 [代码]{ "errcode" : 0, "errmsg" : "ok", "user_id_key" : "id_key_xxxx", "expires_in": 3600 } [代码] 4、后台消息推送 如果业务方传入out_seq_no，核身完成后会通过消息推送回调给业务方的服务器，如果回调业务方失败，会在5s尽力推送，超过5s不再推送。 参数说明 参数 类 型 说明 ToUserName string 小程序原始ID FromUserName string 事件消息openid CreateTime uint32 消息推送时间 MsgType string 消息类型 Event string 事件类型 openid string 核身用户的openid out_seq_no string 业务方唯一流水号 verify_result string 核身返回的加密key（凭据） 返回示例 [代码]{ "ToUserName": "gh_81fxxxxxxxx", "FromUserName": "oRRn15NUibBxxxxxxxxx", "CreateTime": 1703657835, "MsgType": "event", "Event": "face_identify", "openid": "oRRn15NUibBxxxxxxxxx", "out_seq_no": "test1234", "verify_result": "XXIzTtMqCxwOaawoE91-VNGAC3v1j9MP-5fZJxv0fYT4aGezzvYlUb-n6RWQa7XeJpQo0teKj8mGE4ZcRe1JI3GqzADBYORBu613rKjKAFfEXTXw_bu1bs7MnmPOpguS" } [代码] 四、再次获取核验结果api 此接口是前端完成人脸核身后，基于前端返回的凭据，通过后台api再次进行核验结果和身份信息的校验，有助于提高安全性，请务必接入！ 前端获取结果不可信，存在被篡改的风险，为了保障请求结果安全性，请务必对identify_ret、id_card_number_md5、name_utf8_md5字段进行校验！ (一)API说明 1、说明 人脸核身之后，开发者可以根据jsapi返回的verify_result向后台拉取当次认证的结果信息。 2、请求URL https://api.weixin.qq.com/cityservice/face/identify/getinfo?access_token={access_token} 3、请求方式 POST 4、请求格式 json (二)请求数据说明 1、请求 参数 类型 是否必填 描述 verify_result String 是 jsapi返回的加密key（凭据） 2、数据返回 HTTP 头如下 Date: Mon, 06 Feb 2017 08:12:58 GMT Content-Type: application/json; encoding=utf-8 Content-Length: 85 Connection: close json示例 [代码]{ "errcode" : 0, [代码] [代码]"errmsg" : "ok", "identify_ret" : 0, "identify_time" : 1486350357 "validate_data": "8593" [代码] [图片] (三)返回参数说明 1、返回参数 注：errcode和identify_ret同时为0，代表本次认证成功。 参数 类型 描述 errcode int 错误码, 0表示本次api调用成功 errmsg string 本次api调用的错误信息 identify_ret int 人脸核身最终认证结果 identify_time uint32 认证时间 validate_data string 用户读的数字（如是读数字） openid string 用户openid user_id_key string 用于后台交互表示用户姓名、身份证的凭证 finish_time uint32 认证结束时间 id_card_number_md5 string 身份证号的md5（最后一位X为大写） name_utf8_md5 string 姓名MD5 2、错误码对应信息 errcode 备注 84001 非法identity_id 84002 用户信息过期 84003 用户信息不存在 五、小程序辅助接口：检查设备是否支持人脸检测 1、接口名称 接 口 ：wx.checkIsSupportFacialRecognition(OBJECT) 功能：检查设备是否支持人脸检测 2、接口说明和使用 小程序调用该接口，可以检测当前手机设备是否具备支持人脸检测的能力，可与以上接口分开使用，为了用户体验，建议调用后对手机设备不支持的用户做对应功能处理。 3、接口说明和使用 01 OBJECT 参数说明： 参数 类型 是否必填 描述 success Function 否 调用成功回调 fail Function 否 调用失败回调 complete Function 是 调用完成回调（成功或失败都会回调） checkAliveType Number 否 人脸核验的交互方式，默认读数字（见表 2） 表 2：checkAliveType 的值和对应的解释： 参数 解释 2 先检查是否可以屏幕闪烁，不可以则自动为读数字 02 CALLBACK 返回参数 参数 类型 说明 errMsg Boolean 错误信息 errCode Number 错误码 03 回调结果说明 回调类型 ErrCode 说明 sucess 0 支持人脸采集 fail 10001 不支持人脸采集：设备没有前置摄像头 fail 10002 不支持人脸采集：没有下载到必要模型 fail 10003 不支持人脸采集：后台控制不支持 回调结果说明仅对Android生效，iOS不返回errcode。 04 示例代码 [图片] 六、安全性说明 为保障业务可用性以及安全性，请详细研读微信人脸核身接口相关基础说明及安全说明文档：https://docs.qq.com/doc/DTFB0YWFIdGV6amly 备注：如开发中遇到任何疑问，可以点击此处通过社区反馈，将有工作人员跟进回复。 七、案例展示及补充说明 安徽医科大学第二附属医院，微信人脸核验登录： 安徽医科大学第二附属医院，是三级甲等综合医院。其小程序为用户提供挂号、门诊费用、住院费用、检查报告、体检等医疗服务，同时也提供停车、餐饮等便民服务，是医疗小程序中完整的案例。 小程序使用了微信人脸核验能力作为登录的核验。满足医院管理要求，也满足国家对于实名就医的管理规则。 案例实现的截图效果如下： [图片] [图片] 针对近期少数小程序方面反馈的两类问题，也在本课程进行补充说明。 1、本接口的开放范围，即：可支持的主体类目，是否可以扩大？ 说明：基于本接口整体使用范围的评估、相关法规的参考、监管策略的理解执行等，暂时未立刻进行扩大开放范围的工作。 但我们会持续基于不同行业的法规、政策及监管要求等，逐一进行研究考量，以便确认如何扩大开放范围。 2、小程序如果涉及用户本人的生物特征采集，（如本人人脸照片、人脸视频），或涉及采集用户本人生物特征信息并开展人脸核验功能，则存在被驳回的情况？ 说明：近两年“人脸识别”技术在社会上掀起了热潮。人脸识别虽然作为摆脱“中间媒介”或“承载载体”的一种直接技术手段，解决了部分政务、交通、医疗、零售等证明“操作者是本人”的问题，但也因此，引入了新的更大的安全风险。 一是，虚假安全风险。 身份认证领域的安全三因素包括“我知道什么”、“我拥有什么”、“我的特征是什么”，通用的安全做法，是要双因素认证（2FA），人脸识别技术如仅凭“我的特征是什么”这一个因素，则容易被攻破或利用。表象给用户以安全的感觉，但实际并不能达到安全效果。 二是，信息泄漏的风险。 越来越多的组织或个人，在并非必需用户敏感信息、生物特征的情况下，采集并存储此类信息。在信息加密、传输、存储过程中，容易暴漏更多的网络节点，使得此类信息有更大的风险被网络黑客拦截、窃听、窃取，或直接被脱库。 三是，消除风险的难度大。 以往基于“中间媒介”或“承载载体”的方式，如出现丢失、被冒用、恶意盗用等风险，可以通过挂失、更换、使用新载体或新媒介等方式，快速排除一定的风险。C端主动，B端主动，都能解决一部分问题。但人脸识别做为更直接的方式，一旦出现冒用、盗用，受害者将面临更大的财产及人生安全风险，且C端用户更多时候无法主动消除风险。 基于以上问题风险，加之国家出台《网络安全法》、《用户隐私保护条例》等法律法规标准，网信办、公安部、工信部及市场监管总局等四部委发起的app获取隐私整治，结合平台安全、用户敏感隐私信息保护要求及监管，针对部分暂无相关法规或要求，需要采集或生物认证方式进行身份核验的，或以“追热点”或“尝鲜”为目的，采集用户生物特征或进行身份核验的，进行严格审核，必要时不予以支持。

最近开发项目中使用 uni-app 开发了 微信小程序，整个体验下来还算流畅，下面做一些总结： HBuilderX安装 HBuilderX安装的时候选择标准版，不要下载APP开发版，至于uni-app编辑都可以在标准版里面通过插件安装或者是直接通过vue-cli命令行创建项目，另外就我个人使用之后，APP开发版编译小程序的时候，有时候会导致编译出来的小程序页面空白（只剩下[代码][代码]）。 微信开发者工具 HBuilderX运行/发布微信小程序在编译完成之后会尝试打开微信开发者工具，实际上就是用命令行控制微信开发者工具（命令行 V2），这个需要在开发者工具的设置 -> 安全设置中开启服务端口。 创建项目 官方提供了HBuilderX可视化界面和vue-cli命令行两种方式创建项目，不过cli版如果想安装less、scss、ts等编译器，需自己手动npm安装。在HBuilderX的插件管理界面安装无效，那个只作用于HBuilderX创建的项目。 代码目录 以HBuilderX可视化界面创建的项目： components：组件文件，不用引入声明，直接使用。 pages：页面 index：首页 static：静态资源 store：全局状态管理中心 unpackage：打包文件 .gitignore：忽略文件，暂时忽略 [代码]unpackage[代码] 文件 APP.vue：应用配置，用来配置App全局样式以及监听 main.js：Vue初始化入口文件 manifest.json：配置应用名称、appid、logo、版本等打包信息 pages.json：配置页面路由、导航条、选项卡等页面类信息 uni.scss：整体控制应用的风格，https://uniapp.dcloud.io/collocation/uni-scss mixins：混入 utils：工具，uni.request 和 uni.uploadFile 方法封装 config：配置文件 index.js：类似于vue.config.js theme.js：配置在js中使用的主题配置 sitemap.json：配置页面是否被索引 package.json：npm相关，直接安装对应的库，和web一样引入使用 package-lock.json：npm相关 完整代码可查看https://github.com/fxss5201/uni-template 代码封装 [代码]config -> index.js 配置信息[代码] [代码]export default { loginExpiredCode: '', // 用户信息过期的code token: 'token', // 如果使用到用户信息，需要存储token时，设置此token值，表示token的key origin: process.env.NODE_ENV === 'development' ? '' : '', // 配置请求的域名 origin1: process.env.NODE_ENV === 'development' ? '' : '' // 用于设置多个域名 } [代码] [代码]utils -> request.js uni.request 和 uni.uploadFile 方法封装[代码] [代码]// uni.request 和 uni.uploadFile 方法封装 // 使用方式： // this.$request({ // url: '', // origin: 1, // 可选参数，用于设置使用项目中 config/index.js 中配置的哪个origin，值为对应的数字，未设置则使用默认的 origin // method: 'POST', // data: {} // }).then(res => { // console.log(res) // }).catch(err => { // console.log(err) // }).finally(_ => {}) import store from '../store' import config from '../config' export function request(options) { let origin if (typeof options.origin === 'number' && !isNaN(options.origin)) { origin = config[`origin${options.origin}`] } else { origin = config.origin } return new Promise((resolve, reject) => { uni.request({ url: `${origin}${options.url}`, // 统一配置域名信息 method: options.method, header: options.header || { 'content-type': 'application/json', 'token': store.state.token }, data: options.data || {}, success(res) { /** * https://developers.weixin.qq.com/miniprogram/dev/api/ui/interaction/wx.showToast.html * uni.showLoading 和 uni.showToast 同时只能显示一个 * 我们一般会在发起请求的时候 uni.showLoading ，此处需要先 uni.hideLoading() ，才方便后面的提示信息 */ uni.hideLoading() if (res.statusCode === 200) { // code 看公司及个人定义 if (res.data.code === 0) { resolve(res.data) } else { // 返回的信息需要报错错误的msg，进行uni.showToast uni.showToast({ title: res.data.msg, icon: 'none' }) // 此处再根据code统一做一些相关处理，比如登录过期等操作 if(res.data.code === config.loginExpiredCode) { // 删除本地Storage的token uni.removeStorageSync(config.token) // uni.showToast 默认显示 1500ms ，之后跳转到登录页面 setTimeout(() => { uni.reLaunch({ url: 'pages/login/index' }) }, 1500) } reject(res.data) } } else { // statusCode 不为 200 的时候先报网络出错加 statusCode uni.showToast({ title: `网络出错: ${res.statusCode}`, icon: 'none' }) reject(res.data) console.log(`网络出错：${res.data.path} -> ${res.data.status}`) } }, fail(err) { uni.hideLoading() uni.showToast({ title: '网络出错', icon: 'none' }) reject(err) } }) }) } export function upload(options) { let origin if (typeof options.origin === 'number' && !isNaN(options.origin)) { origin = config[`origin${options.origin}`] } else { origin = config.origin } return new Promise((resolve, reject) => { uni.uploadFile({ url: `${origin}${options.url}`, filePath: options.filePath, name: options.name, formData: options.formData || {}, header: { 'content-type': 'multipart/form-data', 'token': store.state.token }, success(result) { uni.hideLoading() if (result.statusCode === 200) { /** * https://uniapp.dcloud.io/api/request/network-file * data String 开发者服务器返回的数据 */ const res = JSON.parse(result.data) if (res.code === 0) { resolve(res) } else { uni.showToast({ title: res.msg, icon: 'none' }) if(res.code === config.loginExpiredCode) { uni.removeStorageSync(config.token) setTimeout(() => { uni.reLaunch({ url: 'pages/login/index' }) }, 1500) } reject(res) } } else { uni.showToast({ title: `网络出错: ${result.statusCode}`, icon: 'none' }) reject(res.data) console.log(`网络出错：${res.data.path} -> ${res.data.status}`) } }, fail(err) { uni.hideLoading() uni.showToast({ title: '网络出错', icon: 'none' }) reject(err) } }) }) } [代码] 网络监控 我是在全局放了网络监控，当断网的时间弹出断网弹窗禁止操作，再次联网的时间，关闭弹窗。 [代码]App.vue[代码] : [代码]export default { onLaunch: function() { console.log('App Launch'); uni.onNetworkStatusChange(({isConnected}) => { if (isConnected) { uni.hideToast() } else { uni.hideToast() uni.showToast({ title: '您已断网', icon: 'none', mask: true, duration: 6000000 }) } }) }, onShow: function() { console.log('App Show'); }, onHide: function() { console.log('App Hide'); } }; [代码] 更新提示 [代码] onLaunch: function() { // 更新版本提示 if (uni.canIUse('getUpdateManager')) { const updateManager = uni.getUpdateManager() updateManager.onCheckForUpdate(function (res) { if (res.hasUpdate) { updateManager.onUpdateReady(function () { uni.showModal({ title: '更新提示', content: '新版本已经准备好，请重启应用', showCancel: false, confirmColor: theme.showModalConfirmColor, success: function (res) { if (res.confirm) { updateManager.applyUpdate() } } }) }) updateManager.onUpdateFailed(function () { uni.showModal({ title: '已经有新版本了哟~', content: '新版本已经上线啦~，请您删除当前小程序，重新搜索打开哟~', showCancel: false, confirmColor: theme.showModalConfirmColor }) }) } }) } else { uni.showModal({ title: '提示', content: '当前微信版本过低，无法使用该功能，请升级到最新微信版本后重试', showCancel: false, confirmColor: theme.showModalConfirmColor }) } } [代码] 至于测试可以在 添加编译模式 设置： [图片] 遇到的一些问题及解决方法 微信小程序用户授权弹窗，获取用户信息。用户拒绝授权时，引导用户去重新授权 关于小程序获取手机号解密失败的踩坑历程

小程序中获取微信手机号的前提条件这里贴一个链接，各位同学自己看 https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/getPhoneNumber.html 主要说说为什么会解密失败，主要有以下两点原因 微信服务器报错 你解密的姿势错了 对于第一点，比较少见，如果出现了，嗯 ，坐着等死就行了 解密失败一般是由于你的 sessionKey 失效导致的，而sessionKey 由 wx.login 这个api先获取code， 再由我们的后台拿这个code向微信服务器请求获得。code有效期五分钟。 上面的链接中有这样一句话 注意 在回调中调用 [代码]wx.login[代码] 登录，可能会刷新登录态。此时服务器使用 code 换取的 sessionKey 不是加密时使用的 sessionKey，导致解密失败。建议开发者提前进行 [代码]login[代码]；或者在回调中先使用 [代码]checkSession[代码] 进行登录态检查，避免 [代码]login[代码] 刷新登录态。 这句话这么理解呢，打个比方，假设你第一次调用wx.login获取的为 sessionKey_1，在它的有效期内，你再去获取一个加密数据 encryptedData_1，这时候你用sessionKey_1去解密encryptedData_1就可以正常解密。 但是在获取encryptedData_1的时候会有个回调函数，如果你在这个回调函数里又调了一次wx.login，获取了 sessionKey_2，这时候登录态可能会被刷新，加密encryptedData_1时使用的sessionKey_1就会失效，再去解密encryptedData_1就会有很高的几率解密失败。至于为什么不会百分百刷新登录态，鬼知道这逻辑是怎么写的。 贴上我的部分代码（只贴获取手机号的部分，其他逻辑请根据自己产品业务酌情参考） [代码][代码] const app = getApp(); [代码][代码] [代码]Page({[代码] [代码]    [代码][代码]data: {[代码][代码]        [代码][代码]code: [代码][代码]""[代码][代码],[代码][代码]    [代码][代码]},[代码] [代码]    [代码][代码]// 获取手机号[代码][代码]    [代码][代码]getPhoneAndLogin: [代码][代码]function[代码][代码](e){[代码][代码]        [代码][代码]let that = [代码][代码]this[代码][代码];[代码][代码]        [代码][代码]// console.log(e);[代码] [代码]        [代码][代码]if[代码] [代码](e.detail.errMsg !== [代码][代码]"getPhoneNumber:ok"[代码][代码]){[代码][代码]            [代码][代码]return[代码][代码];[代码][代码]        [代码][代码]}[代码] [代码]        [代码][代码]wx.showLoading({[代码][代码]            [代码][代码]mask: [代码][代码]true[代码][代码],[代码][代码]        [代码][代码]})[代码] [代码]        [代码][代码]// 检查登录态是否过期[代码][代码]        [代码][代码]wx.checkSession({[代码][代码]            [代码][代码]success(res) {[代码][代码]                [代码][代码]// session_key 未过期，并且在本生命周期一直有效[代码][代码]                [代码][代码]// console.log(res);[代码]  [代码]                [代码][代码]wx.request({[代码][代码]                    [代码][代码]url: app.globalData.apiUrl + [代码][代码]'**********'[代码][代码],[代码][代码]                    [代码][代码]data: {[代码][代码]                        [代码][代码]code: that.data.code,[代码][代码]                        [代码][代码]encryptedData: e.detail.encryptedData,[代码][代码]                        [代码][代码]iv: e.detail.iv,[代码][代码]                    [代码][代码]},[代码][代码]                    [代码][代码]method: [代码][代码]"POST"[代码][代码],[代码][代码]                    [代码][代码]success: res => {[代码][代码]                        [代码][代码]// console.log(res);[代码]                  [代码]                    [代码][代码]},[代码][代码]                    [代码][代码]fail: res => {[代码][代码]                        [代码][代码]                        [代码][代码]wx.showToast({[代码][代码]                            [代码][代码]icon: [代码][代码]"none"[代码][代码],[代码][代码]                            [代码][代码]title: [代码][代码]'服务器繁忙'[代码][代码],[代码][代码]                        [代码][代码]})[代码][代码]                    [代码][代码]},[代码][代码]                    [代码][代码]complete: res => {[代码][代码]                        [代码][代码]wx.hideLoading();[代码][代码]                    [代码][代码]}[代码][代码]                [代码][代码]})[代码][代码]            [代码][代码]},[代码][代码]            [代码][代码]fail(err) {[代码][代码]                [代码][代码]// session_key 已经失效，需要重新执行登录流程[代码]              [代码]                [代码][代码]wx.login({[代码][代码]                    [代码][代码]success: res => {[代码][代码]                        [代码][代码]that.data.code = res.code[代码][代码]                    [代码][代码]}[代码][代码]                [代码][代码]})[代码][代码]            [代码][代码]}[代码][代码]        [代码][代码]})[代码][代码]    [代码][代码]},[代码][代码] [代码][代码]    [代码][代码]/**[代码][代码]     [代码][代码]* 生命周期函数--监听页面加载[代码][代码]     [代码][代码]*/[代码][代码]    [代码][代码]onLoad: [代码][代码]function[代码] [代码](options) {[代码][代码]        [代码][代码]let that = [代码][代码]this[代码][代码];[代码][代码]        [代码][代码]// console.log(options);[代码] [代码]        [代码][代码]wx.login({[代码][代码]            [代码][代码]success: res =>{[代码][代码]                [代码][代码]that.data.code = res.code[代码][代码]            [代码][代码]}[代码][代码]        [代码][代码]})[代码][代码]    [代码][代码]},[代码] [代码]})[代码]  以上，如果有问题欢迎各位大佬指正

前言：微信网页登录文档 A https://developers.weixin.qq.com/doc/offiaccount/OA_Web_Apps/Wechat_webpage_authorization.html B https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html 1、 检测网页环境 https://www.cnblogs.com/wangtz/p/12538850.html 2、 若pc调用 上面B的API即可实现 3 、若h5调用 则需要调以下的链接格式 https://open.weixin.qq.com/sns/explorer_broker?appid=wx62ba64796e13f092&redirect_uri=https%3A%2F%2Faccount.xiaomi.com%2Fpass%2Fsns%2Flogin%2Fload&response_type=code&scope=snsapi_userinfo&state=STATE_685333#wechat_redirect 4、小米案例 a、登录链接 https://account.xiaomi.com/pass/serviceLogin?callback=https%3A%2F%2Fsupport.kefu.mi.com%2Fsts%3Fsign%3DjorTe2AgW3OD2juZGL2HJC73mjQ%253D%26followup%3Dhttp%253A%252F%252Fsupport.kefu.mi.com%252Fpage%252Findex%252Fv2%253Ftag%253Dcn%2526token%253DY24ud2ViLm1pLmh0dHBzLm1vYmlsZSNyZWZlcmVy%2526productId%253D9452%2526goodsId%253D2191000003&sid=mcc_chat_fe b、pc拦截 https://open.weixin.qq.com/connect/qrconnect?appid=wxa21de3acc0d5e79b&redirect_uri=https%3A%2F%2Fsns.account.xiaomi.com%2Fpass%2Fsns%2Flogin%2Fload&response_type=code&scope=snsapi_login&state=STATE_889829#wechat_redirect c、h5的拦截链接 https://open.weixin.qq.com/sns/explorer_broker?appid=wx62ba64796e13f092&redirect_uri=https%3A%2F%2Faccount.xiaomi.com%2Fpass%2Fsns%2Flogin%2Fload&response_type=code&scope=snsapi_userinfo&state=STATE_685333#wechat_redirect 附：参考案例博客 https://blog.csdn.net/tiantian082054/article/details/90711900 https://www.jianshu.com/p/a1f357152dca 备注：主来自一位社区开发者的问题解决的整理：https://developers.weixin.qq.com/community/develop/doc/0004caea6a836871524a7402156000

我们在开发小程序时，如果想获取用户信息，就需要获取用的授权，如果用户误点了拒绝授权，我们怎么样去正确的引导用户重新授权呢。今天就来给大家讲讲如果正确的引导用户授权。 老规矩，先看效果图 [图片] 从上图可以看出，我们在用户点击拒绝授权时，我们会弹出一个提示框，提示用户去设置页重新授权，当用户去授权页重新授权以后，我们再回到首页，点击获取用户信息时，就可以成功的获取到用户信息了。 如下图蓝色框里，就是我们成功的获取的用户信息。 [图片] 一，我们获取用户信息的时候需要用户授权 我们点击获取用户信息时，通常会弹出如下提示框，如果用户点击了取消，就再也没有办法通过点击授权按钮获取用户信息了。 [图片] 所以接下来我们要做的就是在用户拒绝了授权时，引导用户去设置页重新授权。 把获取用户授权的代码先贴给大家 [代码]<button open-type="getUserInfo" bindgetuserinfo="getUserInfo"> 授权获取头像昵称 </button> [代码] 二，检测用户是否授权 我们在用户点击了上面定义的button按钮后，做权限检测。代码如下。 [代码] getUserInfo: function(e) { let that = this; // console.log(e) // 获取用户信息 wx.getSetting({ success(res) { // console.log("res", res) if (res.authSetting['scope.userInfo']) { console.log("已授权=====") // 已经授权，可以直接调用 getUserInfo 获取头像昵称 wx.getUserInfo({ success(res) { console.log("获取用户信息成功", res) that.setData({ name: res.userInfo.nickName }) }, fail(res) { console.log("获取用户信息失败", res) } }) } else { console.log("未授权=====") that.showSettingToast("请授权") } } }) }, [代码] 给大家简单解析下。 wx.getSetting ：用来获取用户授权列表 if (res.authSetting[‘scope.userInfo’]) 代码用户授权成功，如果用户没有授权，就代表授权失败。 在授权失败时，我们调用that.showSettingToast()方法 三，showSettingToast方法如下 [代码] // 打开权限设置页提示框 showSettingToast: function(e) { wx.showModal({ title: '提示！', confirmText: '去设置', showCancel: false, content: e, success: function(res) { if (res.confirm) { wx.navigateTo({ url: '../setting/setting', }) } } }) } [代码] 这方法做的就是引导用户去设置页。 四，我们的设置页 [图片] 我们的设置页其实很简单，只有上图这么一段代码。 [图片] 五，去系统设置页。 我们上面第四步的button按钮，点击以后，就会去系统设置页。 [图片] 可以看到系统设置页，有一个开关，当用户点击开关时，就可以重新授权啦。 [图片] 重新授权成功以后，我们回到首页，就可以成功的获取到用户信息了。 [图片] 到这里我们就成功的实现了引导用户授权的功能了。 把index.wxml和index.js代码贴出来给大家 index.wxml [代码]<!--index.wxml--> <button open-type="getUserInfo" bindgetuserinfo="getUserInfo"> 授权获取头像昵称 </button> <text>{{name}}</text> [代码] index.js [代码]//index.js Page({ getUserInfo: function(e) { let that = this; // console.log(e) // 获取用户信息 wx.getSetting({ success(res) { // console.log("res", res) if (res.authSetting['scope.userInfo']) { console.log("已授权=====") // 已经授权，可以直接调用 getUserInfo 获取头像昵称 wx.getUserInfo({ success(res) { console.log("获取用户信息成功", res) that.setData({ name: res.userInfo.nickName }) }, fail(res) { console.log("获取用户信息失败", res) } }) } else { console.log("未授权=====") that.showSettingToast("请授权") } } }) }, // 打开权限设置页提示框 showSettingToast: function(e) { wx.showModal({ title: '提示！', confirmText: '去设置', showCancel: false, content: e, success: function(res) { if (res.confirm) { wx.navigateTo({ url: '../setting/setting', }) } } }) }, }) [代码] 有任何关于编程的问题都可以留言或者私信我，我看到后会及时解答 编程小石头，码农一枚，非著名全栈开发人员。分享自己的一些经验，学习心得，希望后来人少走弯路，少填坑。 有任何关于小程序的问题可以加我微信：2501902696（备注小程序） 视频讲解： https://edu.csdn.net/course/detail/9531

前言 在阿里和腾讯工作了6年，当了3年的前端面试官，把阿里和腾讯常问的面试题与答案汇总在我的Github中。希望对大家有所帮助，助力大家进入自己理想的企业。 项目地址是：https://github.com/airuikun/Weekly-FE-Interview 如果你在阿里和腾讯面试的时候遇到了什么不懂的问题，欢迎给我提issue，我会把答案和考点都列出来，公布在下一期的面试周刊里。 面试题精选 大家如果去阿里和腾讯面试过，就会发现，在网上刷了很多的前端面试题，但是去大厂面试的时候还是一头雾水，那是因为那些在网上一搜就能搜出来的题，大厂的面试官基本看不上，他们都会问一些开放题，在回答开放题的过程中，就能摸清你知识技能的广度和深度，所以本期会加入几道我在面试候选人常用的开放题，供大家学习和思考。 我把下面每道题的难度高低，和对标了阿里和腾讯的多少职级，都写上去了，大家可以参考一下自己是什么职级。 第 1 题：如何劫持https的请求，提供思路 难度：阿里p6+ ~ p7、腾讯t23 ~ t31 很多人在google上搜索“前端面试 + https详解”，把答案倒背如流，但是问到如何劫持https请求的时候就一脸懵逼，是因为还是停留在https理论性阶段。 想告诉大家的是，就算是https，也不是绝对的安全，以下提供一个本地劫持https请求的简单思路。 模拟中间人攻击，以百度为例 先用OpenSSL查看下证书，直接调用openssl库识别目标服务器支持的SSL/TLS cipher suite [代码] openssl s_client -connect www.baidu.com:443 [代码] 用sslcan识别ssl配置错误，过期协议，过时cipher suite和hash算法 [代码] sslscan -tlsall www.baidu.com:443 [代码] 分析证书详细数据 [代码] sslscan -show-certificate --no-ciphersuites www.baidu.com:443 [代码] 生成一个证书 [代码] openssl req -new -x509 -days 1096 -key ca.key -out ca.crt [代码] 开启路由功能 [代码] sysctl -w net.ipv4.ip_forward=1 [代码] 写转发规则，将80、443端口进行转发给8080和8443端口 [代码] iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080 iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443 [代码] 最后使用arpspoof进行arp欺骗 如果你有更好的想法或疑问，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/11 第 2 题：前端如何进行seo优化 难度：阿里p5、腾讯t21 合理的title、description、keywords：搜索对着三项的权重逐个减小，title值强调重点即可；description把页面内容高度概括，不可过分堆砌关键词；keywords列举出重要关键词。 语义化的HTML代码，符合W3C规范：语义化代码让搜索引擎容易理解网页 重要内容HTML代码放在最前：搜索引擎抓取HTML顺序是从上到下，保证重要内容一定会被抓取 重要内容不要用js输出：爬虫不会执行js获取内容 少用iframe：搜索引擎不会抓取iframe中的内容 非装饰性图片必须加alt 提高网站速度：网站速度是搜索引擎排序的一个重要指标 如果你有更好的答案或想法，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/12 第 3 题：前后端分离的项目如何seo 难度：阿里p6 ~ p6+、腾讯t22 ~ t23 使用prerender。但是回答prerender，面试官肯定会问你，如果不用prerender，让你直接去实现，好的，请看下面的第二个答案。 先去 https://www.baidu.com/robots.txt 找出常见的爬虫，然后在nginx上判断来访问页面用户的User-Agent是否是爬虫，如果是爬虫，就用nginx方向代理到我们自己用nodejs + puppeteer实现的爬虫服务器上，然后用你的爬虫服务器爬自己的前后端分离的前端项目页面，增加扒页面的接收延时，保证异步渲染的接口数据返回，最后得到了页面的数据，返还给来访问的爬虫即可。 如果你有更好的答案或想法，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/13 第 4 题：简单实现async/await中的async函数 难度：阿里p6 ~ p6+、腾讯t22 ~ t23 async 函数的实现原理，就是将 Generator 函数和自动执行器，包装在一个函数里 [代码]function spawn(genF) { return new Promise(function(resolve, reject) { const gen = genF(); function step(nextF) { let next; try { next = nextF(); } catch (e) { return reject(e); } if (next.done) { return resolve(next.value); } Promise.resolve(next.value).then( function(v) { step(function() { return gen.next(v); }); }, function(e) { step(function() { return gen.throw(e); }); } ); } step(function() { return gen.next(undefined); }); }); } [代码] 如果你有更好的答案或想法，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/14 第 5 题：1000-div问题 难度：阿里p5 ~ p6、腾讯t21 ~ t22 一次性插入1000个div，如何优化插入的性能 使用Fragment [代码] var fragment = document.createDocumentFragment(); fragment.appendChild(elem); [代码] 向1000个并排的div元素中，插入一个平级的div元素，如何优化插入的性能 先display:none 然后插入 再display:block 赋予key，然后使用virtual-dom，先render，然后diff，最后patch 脱离文档流，用GPU去渲染，开启硬件加速 如果你有更好的答案或想法，欢迎在这题目对应的github下留言：https://github.com/airuikun/Weekly-FE-Interview/issues/15 第 6 题：（开放题）2万小球问题：在浏览器端，用js存储2万个小球的信息，包含小球的大小，位置，颜色等，如何做到对这2万条小球信息进行最优检索和存储 难度：阿里p7、腾讯t31 你面试阿里和腾讯，能否上p7和t31，就看你对开放题能答有多深和多广。 这题目考察你如何在浏览器端中进行大数据的存储优化和检索优化。 如果你仅仅只是答用数组对象存储了2万个小球信息，然后用for循环去遍历进行索引，那是远远不够的。 这题要往深一点走，用特殊的数据结构和算法进行存储和索引。 然后进行存储和速度的一个权衡和对比，最终给出你认为的最优解。 我提供几个能触及阿里p7和腾讯t31级别的思路： 用ArrayBuffer实现极致存储 哈夫曼编码 + 字典查询树实现更优索引 用bit-map实现大数据筛查 用hash索引实现简单快捷的检索 用IndexedDB实现动态存储扩充浏览器端虚拟容量 用iframe的漏洞实现浏览器端localStorage无限存储，实现2千万小球信息存储 这种开放题答案不唯一，也不会要你现场手敲代码去实现，但是思路一定要行得通，并且是能打动面试官的思路，如果大家有更好的idea，欢迎大家到我的github里补充：https://github.com/airuikun/Weekly-FE-Interview/issues/16 第 7 题：（开放题）接上一题如何尽可能流畅的实现这2万小球在浏览器中，以直线运动的动效显示出来 难度：阿里p6+ ~ p7、腾讯t23 ~ t31 这题考察对大数据的动画显示优化，当然方法有很多种。 但是你有没有用到浏览器的高级api？ 你还有没有用到浏览器的专门针对动画的引擎？ 或者你对3D的实践和优化，都可以给面试官展示出来。 提供几个思路： 使用GPU硬件加速 使用webGL 使用assembly辅助计算，然后在浏览器端控制动画帧频 用web worker实现javascript多线程，分块处理小球 用单链表树算法和携程机制，实现任务动态分割和任务暂停、恢复、回滚，动态渲染和处理小球 如果大家有更好的idea，欢迎大家到我的github里补充：https://github.com/airuikun/Weekly-FE-Interview/issues/17 第 8 题：（开放题）100亿排序问题：内存不足，一次只允许你装载和操作1亿条数据，如何对100亿条数据进行排序。 难度：阿里p6+ ~ p7、腾讯t23 ~ t31 这题是考察算法和实际问题结合的一个问题 众所周知，腾讯玩的是社交，用户量极大。很多场景的数据量都是百亿甚至千亿级别。 那么如何对这些数据进行高效的操作呢，可以通过这题考察出来。 以前老听说很多人问，前端学算法没有用，考算法都是垃圾，面不出候选人的能力 其实。。。老哥实话告诉你，当你在做前端需要用到crc32、并查集、字典树、哈夫曼编码、LZ77之类东西的时候 已经是涉及到框架实现和极致优化层面了 那时你就已经到了另外一个前端高阶境界了 所以不要抵触算法，可能只是我们目前的眼界和能力，还没触及到那个层级 我前面已经公布了两道开放题的答案了，相信大家已经有所参悟。我觉得在思考开放题的过程中，会有很多意想不到的成长，所以我建议这道题大家可以尝试自己思考一下。本题答案会在周五公布到我的github上。 对应的github地址为：https://github.com/airuikun/Weekly-FE-Interview/issues/18 第 9 题：（开放题）a.b.c.d和a[‘b’][‘c’][‘d’]，哪个性能更高 难度：阿里p7 ~ p7+、腾讯t31 ~ t32 别看这题，题目上每个字都能看懂，但是里面涉及到的知识，暗藏杀鸡 这题要往深处走，会涉及ast抽象语法树、编译原理、v8内核对原生js实现问题 直接对标阿里p7 ~ p7+和腾讯t31 ~ t32职级，我觉得这个题是这篇文章里最难的一道题，所以我放在了开放题中的最后一题 大家多多思考，本题答案会在周五公布到我的github上 对应的github地址为：https://github.com/airuikun/Weekly-FE-Interview/issues/19 第 10 题：git时光机问题 难度：阿里p5 ~ p6+、腾讯t21 ~ t23 现在大厂，已经全部都是用git了，基本没人使用svn了 很多面试候选人对git只会commit、pull、push 但是有没有使用过reflog、cherry-pick等等，这些都很能体现出来你对代码管理的灵活程度和代码质量管理。 针对git时光机经典问题，我专门写了一个文章，轻松搞笑通俗易懂，大家可以看一下，放松放松，同时也能学到对git的时光机操作《git时光机》 结语 本人还写了一些前端进阶知识的文章，如果觉得不错可以点个star。 blog项目地址是：https://github.com/airuikun/blog 我是小蝌蚪，腾讯高级前端工程师，跟着我一起每周攻克几个前端技术难点。希望在小伙伴前端进阶的路上有所帮助，助力大家进入自己理想的企业。 交流 欢迎关注我的微信公众号，微信扫下面二维码或搜索“前端屌丝”，讲述了一个前端屌丝逆袭的心路历程，共勉。 [图片]

背景 由于产品想要在一个webview里以切换tab的方式同时阅读两篇图文来判断是否存在洗稿，鉴于重复实现一次图文逻辑比较蛋疼且难以维护，所以打算采用嵌入两个iframe的方案来实现，理想结果是记住两个iframe各自的滚动位置，在切换时可以回到原来的位置继续阅读。 理想是丰满的，可惜现实总是骨感的，在下文会阐述这个骨感的踩坑之旅。 iframe自身的滚动表现 如果iframe本身已支持记住滚动位置的话，那么这个case就可以快乐地结束了 [图片] [代码]<body> <iframe id="js_iframe1" scrolling="yes" src="article1.html"></iframe> <iframe id="js_iframe2" scrolling="yes" src="article2.html" style="display: none;"></iframe> </body> [代码] 可以扫这个二维码看真机表现： [图片] 结果当然是不符合预期的[图片]（不然这篇文章也不用写了） 不过iOS和Android的表现并不一致，具体差异看下表： iOS Android 滚动后切换另一个iframe时，滚动位置和切换前一致 滚动后切换另一个iframe时，滚动位置会重置到顶部（即scrollTop=0） 手动修改scrollTop值 理所当然的，聪明的我立马想到一个“完美”的方案：切换时先记住当前iframe的scrollTop，然后再取出另一个iframe的scrollTop（如果有的话）并赋值。 [代码]// 获取iframe的scrollTop const getIframeScrollTop = iframe => iframe.contentWindow.pageYOffset || iframe.contentDocument.documentElement.scrollTop || iframe.contentDocument.body.scrollTop || 0; // 设置iframe的scrollTop const setIframeScrollTop = (iframe, val) => { iframe.contentDocument.documentElement.scrollTop = val; iframe.contentDocument.body.scrollTop = val; }; [代码] 其它代码由于过于简单就不贴了[图片] 可以扫这个二维码看真机表现： [图片] 结果在Android上表现符合预期，但是在iOS上无效，而且取出来的scrollTop恒等于0[图片] iOS Android 滚动后切换另一个iframe时，滚动位置和切换前一致，scrollTop=0 符合预期 怀疑iOS是否共用同一个滚动条 人生遇到瓶颈后就开始怀疑世间万物[图片]于是我开始怀疑iOS的iframe是不是共用了同一个滚动条，不然滚动位置怎么会保持一致？ 抱着死马当活马医的心态，我做了这样一个测试，给两个iframe以及page绑定了scroll事件，在事件callback里分别打印’iframe1’、‘iframe2’和’page’。 可以扫这个二维码看真机表现： [图片] 实验结果使我更确信iOS是共用了同一个滚动条 [图片] iOS Android 无论在哪里滚动，都打印’page’ 打印结果符合预期 在iOS中改用page滚动条的scrollTop 判一下ua对iOS做特殊处理，如果是iOS，就对page做scrollTop取值/赋值操作[图片] [代码]const isIOS = /(iPhone|iPad|iPod|iOS)/i.test(navigator.userAgent); // 获取iframe的scrollTop（升级版） const getIframeScrollTop = iframe => { if (isIOS) { // iOS下所有iframe共用同一个滚动条 return window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop || 0; } // 其余的有各自的滚动条 return iframe.contentWindow.pageYOffset || iframe.contentDocument.documentElement.scrollTop || iframe.contentDocument.body.scrollTop || 0; } // 设置iframe的scrollTop（升级版） const setIframeScrollTop = (iframe, val) => { if (isIOS) { // iOS下所有iframe共用同一个滚动条 document.documentElement.scrollTop = val; document.body.scrollTop = val; } else { // 其余的有各自的滚动条 iframe.contentDocument.documentElement.scrollTop = val; iframe.contentDocument.body.scrollTop = val; } } [代码] 可以扫这个二维码看真机表现： [图片] iOS Android 符合预期 符合预期 幸不辱命，终于可以上线了，哈哈 [图片] 需求上线后重新整理了下思路 由于那天被这个问题折腾了很久，大脑非常疲惫，产品又在催上线，看到问题解决后就立马上线然后下班回家了。隔天回来后，重新整理在网上搜索到关于iOS iframe的文章，又有了新的发现： iOS iframe之所以会和page共用同一个滚动条，是因为overflow: scroll和height（css属性）对iOS iframe不起作用（由于当时需求内容是iframe占全屏，即height: 100vh，所以一直没发现这个问题），所以在iOS里，iframe没有命中overflow逻辑，内容完整地呈现出来，因而和page使用同一个滚动条。 那么，如何使overflow: scroll生效？ 其实很简单 [图片] iframe不能用overflow: scroll，那我就让它“爸爸”滚：用div将iframe包裹起来，给这个div加上overflow: scroll和height（css属性）。 不过这时候你会发现当你滚动iframe时，page会动了起来，而iframe毫无反应，就好像“点透”一样。 不怕，贴心的谷歌爸爸给了解决方案：再给这个div加上-webkit-overflow-scrolling: touch，如此一来，iOS iframe的overflow之力终于被解放出来了。 [代码]<div id="js_iframe_wrap"> <iframe id="js_iframe" scrolling="yes" src="article1.html"></iframe> </div> [代码] [代码]#js_iframe_wrap { -webkit-overflow-scrolling: touch; overflow-y: scroll; height: 30vh; } [代码] 可以扫这个二维码看真机表现： [图片] 在这个demo里我将iframe fixed在页面中部，然后将page的高度设置成300vh，最后在页面上放了一个按钮，点击按钮会打印page、iframe以及iframe wrap的scrollTop值。 [代码]const qs = (selector, el) => (el || document).querySelector(selector); const getDocumentScrollTop = () => window.pageYOffset || document.documentElement.scrollTop || document.body.scrollTop || 0; const getIframeScrollTop = iframe => iframe.contentWindow.pageYOffset || iframe.contentDocument.documentElement.scrollTop || iframe.contentDocument.body.scrollTop || 0; $('#js_log').click(() => { console.log(`document scrollTop: ${getDocumentScrollTop()}`); console.log(`iframe scrollTop: ${getIframeScrollTop(qs('#js_iframe'))}`); console.log(`iframe wrap scrollTop: ${qs('#js_iframe_wrap').scrollTop}`); }); [代码] 可以看到，iframe已经不再和page共用同一个滚动条了，而且iframe的滚动值等于iframe wrap的scrollTop值。 写在后面 最后我也没把产品的需求改成-webkit-overflow-scrolling: touch方案，不是方案有坑，而是我懒得改了[图片]

0. 前言 平时写CSS，感觉有很多多余的代码或者不好实现的方法，于是有了预处理器的解决方案，主旨是write less &do more。其实原生css中，用上css变量也不差，加上bem命名规则只要嵌套不深也能和less、sass的嵌套媲美。在一些动画或者炫酷的特效中，不用js的话可能是用了css动画、svg的animation、过渡，复杂动画实现用了js的话可能用了canvas、直接修改style属性。用js的，然后有没有想过一个问题：“要是canvas那套放在dom上就爽了”。因为复杂的动画频繁操作了dom，违背了倒背如流的“性能优化之一：尽量少操作dom”的规矩，嘴上说着不要，手倒是很诚实地[代码]ele.style.prop = <newProp>[代码]，可是要实现效果这又是无可奈何或者大大减小工作量的方法。 我们都知道，浏览器渲染的流程:解析html和css（parse），样式计算（style calculate），布局（layout），绘制（paint），合并（composite），修改了样式，改的环节越深代价越大。js改变样式，首先是操作dom，整个渲染流程马上重新走，可能走到样式计算到合并环节之间，代价大，性能差。然后痛点就来了，浏览器有没有能直接操作前面这些环节的方法呢而不是依靠js？有没有方法不用js操作dom改变style或者切换class来改变样式呢？ 于是就有CSS Houdini了，它是W3C和那几个顶级公司的工程师组成的小组，让开发者可以通过新api操作CSS引擎，带来更多的自由度，让整个渲染流程都可以被开发者控制。上面的问题，不用js就可以实现曾经需要js的效果，而且只在渲染过程中，就已经按照开发者的代码渲染出结果，而不是渲染完成了再重新用js强行走一遍流程。 关于houdini最近动态可点击这里 上次CSS大会知道了有Houdini的存在，那时候只有cssom，layout和paint api。前几天突然发现，Animation api也有了，不得不说，以后很可能是Houdini遍地开花的时代，现在得进一步了解一下了。一句话：这是css in js到js in css的转变 1. CSS变量 如果你用less、sass只为了人家有变量和嵌套，那用原生css也是差不多的，因为原生css也有变量： 比如定义一个全局变量–color（css变量双横线开头） [代码]:root { --color: #f00; } [代码] 使用的时候只要var一下 [代码].f{ color: var(--color); } [代码] 我们的html： [代码]<div class="f">123</div> [代码] 于是，红色的123就出来了。 css变量还和js变量一样，有作用域的： [代码]:root { --color: #f00; } .f { --color: #aaa } .g{ color: var(--color); } .ft { color: var(--color); } [代码] html： [代码] <div className="f"> <div className="ft">123</div> </div> <div className=""> <div className="g">123</div> </div> [代码] 于是，是什么效果你应该也很容易就猜出来了： [图片] css能搞变量的话，我们就可以做到修改一处牵动多处的变动。比如我们做一个像准星一样的四个方向用准线锁定鼠标位置的效果： [图片] 用css变量的话，比传统一个个元素设置style优雅多了： [代码]<div id="shadow"> <div class="x"></div> <div class="y"></div> <div class="x_"></div> <div class="y_"></div> </div> [代码] [代码] :root{ --x: 0px; --y: 0px; } body{ margin: 0 } #shadow{ width: 50%; height: 600px; border: #000 1px solid; position: relative; margin: 0; } .x, .y, .x_, .y_ { position: absolute; border: #f00 2px solid; } .x { top: 0; left: var(--x); height: 20px; width: 0; } .y { top: var(--y); left: 0; height: 0; width: 20px; } .x_ { top: 600px; left: var(--x); height: 20px; width: 0; } .y_ { top: var(--y); left: 100%; height: 0; width: 20px; } [代码] [代码]const style = document.documentElement.style shadow.addEventListener('mousemove', e => { style.setProperty(`--x`, e.clientX + 'px') style.setProperty(`--y`, e.clientY + 'px') }) [代码] 那么，对于github的404页面这种内容和鼠标位置有关的页面，思路是不是一下子就出来了 2. CSS type OM 都有DOM了，那CSSOM也理所当然存在。我们平时改变css的时候，通常是直接修改style或者切换类，实际上就是操作DOM来间接操作CSSOM，而type om是一种把css的属性和值存在attributeStyleMap对象中，我们只要直接操作这个对象就可以做到之前的js改变css的操作。另外一个很重要的点，attributeStyleMap存的是css的数值而不是字符串，而且支持各种算数以及单位换算，比起操作字符串，性能明显更优。 接下来，基本脱离不了window下的CSS这个属性。在使用的时候，首先，我们可以采取渐进式的做法： [代码]if('CSS' in window){...}[代码] 2.1 单位 [代码]CSS.px(1); // 1px 返回的结果是：CSSUnitValue {value: 1, unit: "px"} CSS.number(0); // 0 比如top：0，也经常用到 CSS.rem(2); //2rem new CSSUnitValue(2, 'percent'); // 还可以用构造函数，这里的结果就是2% // 其他单位同理 [代码] 2.2 数学运算 自己在控制台输入CSSMath，可以看见的提示，就是数学运算 [代码]new CSSMathSum(CSS.rem(10), CSS.px(-1)) // calc(10rem - 1px)，要用new不然报错 new CSSMathMax(CSS.px(1),CSS.px(2)) // 顾名思义，就是较大值，单位不同也可以进行比较 [代码] 2.3 怎么用 既然是新的东西，那就有它的使用规则。 获取值[代码]element.attributeStyleMap.get(attributeName)[代码]，返回一个CSSUnitValue对象 设置值[代码]element.attributeStyleMap.set(attributeName, newValue)[代码]，设置值，传入的值可以是css值字符串或者是CSSUnitValue对象 当然，第一次get是返回null的，因为你都没有set过。“那我还是要用一下getComputedStyle再set咯，这还不是和之前的差不多吗？” 实际上，有一个类似的方法：[代码]element.computedStyleMap[代码]，返回的是CSSUnitValue对象，这就ok了。我们拿前面的第一部分CSS变量的代码测试一波 [代码]document.querySelector('.x').computedStyleMap().get('height') // CSSUnitValue {value: 20, unit: "px"} document.querySelector('.x').computedStyleMap().set('height', CSS.px(0)) // 不见了 [代码] 3. paint API paint、animation、layout API都是以worker的形式工作，具体有几个步骤： 建立一个worker.js，比如我们想用paint API，先在这个js文件注册这个模块registerPaint(‘mypaint’, class)，这个class是一个类下面具体讲到 在html引入CSS.paintWorklet.addModule(‘worker.js’) 在css中使用，background: paint(mypaint) 主要的逻辑，全都写在传入registerPaint的class里面。paint API很像canvas那套，实际上可以当作自己画一个img。既然是img，那么在所有的能用到图片url的地方都适合用paint API，比如我们来自己画一个有点炫酷的背景(满屏随机颜色方块)。有空的话可以想一下js怎么做，再对比一下paint API的方案。 [图片] [代码]// worker.js class RandomColorPainter { // 可以获取的css属性，先写在这里 // 我这里定义宽高和间隔，从css获取 static get inputProperties() { return ['--w', '--h', '--spacing']; } /** * 绘制函数paint，最主要部分 * @param {PaintRenderingContext2D} ctx 类似canvas的ctx * @param {PaintSize} PaintSize 绘制范围大小(px) { width, height } * @param {StylePropertyMapReadOnly} props 前面inputProperties列举的属性，用get获取 */ paint(ctx, PaintSize, props) { const w = (props.get('--w') && +props.get('--w')[0].trim()) || 30; const h = (props.get('--h') && +props.get('--h')[0].trim()) || 30; const spacing = +props.get('--spacing')[0].trim() || 10; for (let x = 0; x < PaintSize.width / w; x++) { for (let y = 0; y < PaintSize.height / h; y++) { ctx.fillStyle = `#${Math.random().toString(16).slice(2, 8)}` ctx.beginPath(); ctx.rect(x * (w + spacing), y * (h + spacing), w, h); ctx.fill(); } } } } registerPaint('randomcolor', RandomColorPainter); [代码] 接着我们需要引入该worker： [代码]CSS && CSS.paintWorklet.addModule('worker.js');[代码] 最后我们在一个class为paint的div应用样式： [代码].paint{ background-image: paint(randomcolor); width: 100%; height: 600px; color: #000; --w: 50; --h: 50; --spacing: 10; } [代码] 再想想用js+div，是不是要先动态生成n个，然后各种计算各种操作dom，想想就可怕。如果是canvas，这可是canvas背景，你又要在上面放一个div，而且还要定位一波。 注意： worker是没有window的，所以想搞动画的就不能内部消化了。不过可以靠外面的css变量，我们用js操作css变量可以解决，也比传统的方法优雅 4. 自定义属性 支持情况 点击这里查看 首先，看一下支持度，目前浏览器并没有完全稳定使用，所以需要跟着它的提示：[代码]Experimental Web Platform features” on chrome://flags[代码]，在chrome地址栏输入[代码]chrome://flags[代码]再找到[代码]Experimental Web Platform features[代码]并开启。 [代码]CSS.registerProperty({ name: '--myprop', //属性名字 syntax: '<length>', // 什么类型的单位，这里是长度 initialValue: '1px', // 默认值 inherits: true // 会不会继承，true为继承父元素 }); [代码] 说到继承，我们回到前面的css变量，已经说了变量是区分作用域的，其实父作用域定义变量，子元素使用该变量实际上是继承的作用。如果[代码]inherits: true[代码]那就是我们看见的作用域的效果，如果不是true则不会被父作用域影响，而且取默认值。 这个自定义属性，精辟在于，可以用永久循环的animation驱动一次性的transform。换句话说，我们如果用了css变量+transform，可以靠js改变这个变量达到花俏的效果。但是，现在不需要js，只要css内部消化，transform成为永动机。 [代码]// 我们先注册几种属性 ['x1','y1','z1','x2','y2','z2'].forEach(p => { CSS.registerProperty({ name: `--${p}`, syntax: '<angle>', inherits: false, initialValue: '0deg' }); }); [代码] 然后写个样式 [代码]#myprop, #myprop1 { width: 200px; border: 2px dashed #000; border-bottom: 10px solid #000; animation:myprop 3000ms alternate infinite ease-in-out; transform: rotateX(var(--x2)) rotateY(var(--y2)) rotateZ(var(--z2)) } [代码] 再来看看我们的动画，为了眼花缭乱，加了第二个改了一点数据的动画 [代码]@keyframes myprop { 25% { --x1: 20deg; --y1: 30deg; --z1: 40deg; } 50% { --x1: -20deg; --z1: -40deg; --y1: -30deg; } 75% { --x2: -200deg; --y2: 130deg; --z2: -350deg; } 100% { --x1: -200deg; --y1: 130deg; --z1: -350deg; } } @keyframes myprop1 { 25% { --x1: 20deg; --y1: 30deg; --z1: 40deg; } 50% { --x2: -200deg; --y2: 130deg; --z2: -350deg; } 75% { --x1: -20deg; --z1: -40deg; --y1: -30deg; } 100% { --x1: -200deg; --y1: 130deg; --z1: -350deg; } } [代码] html就两个div: [代码] <div id="myprop"></div> <div id="myprop1"></div> [代码] 效果是什么呢，自己可以跑一遍看看，反正功能很强大，但是想象力限制了发挥。 自己动手改的时候注意一下，动画关键帧里面，不能只存在1，那样子就不能驱动transform了，做不到永动机的效果，因为我的rotate写的是 rotateX(var(–x2))。接下来随意发挥吧 最后 再啰嗦一次 关于houdini最近动态可点击这里 关于houdini在浏览器的支持情况 ENJOY YOURSELF!!!

什么是[代码]Service Worker[代码] [代码]Service Worker[代码]本质上充当Web应用程序与浏览器之间的代理服务器，也可以在网络可用时作为浏览器和网络间的代理。它们旨在（除其他之外）使得能够创建有效的离线体验，拦截网络请求并基于网络是否可用以及更新的资源是否驻留在服务器上来采取适当的动作。他们还允许访问推送通知和后台同步[代码]API[代码]。 [代码]Service Worker[代码]的本质是一个[代码]Web Worker[代码]，它独立于[代码]JavaScript[代码]主线程，因此它不能直接访问[代码]DOM[代码]，也不能直接访问[代码]window[代码]对象，但是，[代码]Service Worker[代码]可以访问[代码]navigator[代码]对象，也可以通过消息传递的方式（postMessage）与[代码]JavaScript[代码]主线程进行通信。 [代码]Service Worker[代码]是一个网络代理，它可以控制[代码]Web[代码]页面的所有网络请求。 [代码]Service Worker[代码]具有自身的生命周期，使用好[代码]Service Worker[代码]的关键是灵活控制其生命周期。 [代码]Service Worker[代码]的作用 用于浏览器缓存 实现离线[代码]Web APP[代码] 消息推送 [代码]Service Worker[代码]兼容性 [代码]Service Worker[代码]是现代浏览器的一个高级特性，它依赖于[代码]fetch API[代码]、[代码]Cache Storage[代码]、[代码]Promise[代码]等，其中，[代码]Cache[代码]提供了[代码]Request / Response[代码]对象对的存储机制，[代码]Cache Storage[代码]存储多个[代码]Cache[代码]。 [图片] 示例 在了解[代码]Service Worker[代码]的原理之前，先来看一段[代码]Service Worker[代码]的示例： [代码]self.importScripts('./serviceworker-cache-polyfill.js'); var urlsToCache = [ '/', '/index.js', '/style.css', '/favicon.ico', ]; var CACHE_NAME = 'counterxing'; self.addEventListener('install', function(event) { self.skipWaiting(); event.waitUntil( caches.open(CACHE_NAME) .then(function(cache) { return cache.addAll(urlsToCache); }) ); }); self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { if (response) { return response; } return fetch(event.request); }) ); }); self.addEventListener('activate', function(event) { var cacheWhitelist = ['counterxing']; event.waitUntil( caches.keys().then(function(cacheNames) { return Promise.all( cacheNames.map(function(cacheName) { if (cacheWhitelist.indexOf(cacheName) === -1) { return caches.delete(cacheName); } }) ); }) ); }); [代码] 下面开始逐段逐段地分析，揭开[代码]Service Worker[代码]的神秘面纱： [代码]polyfill[代码] 首先看第一行：[代码]self.importScripts('./serviceworker-cache-polyfill.js');[代码]，这里引入了Cache API的一个polyfill，这个[代码]polyfill[代码]支持使得在较低版本的浏览器下也可以使用[代码]Cache Storage API[代码]。想要实现[代码]Service Worker[代码]的功能，一般都需要搭配[代码]Cache API[代码]代理网络请求到缓存中。 在[代码]Service Worker[代码]线程中，使用[代码]importScripts[代码]引入[代码]polyfill[代码]脚本，目的是对低版本浏览器的兼容。 [代码]Cache Resources List[代码] And [代码]Cache Name[代码] 之后，使用一个[代码]urlsToCache[代码]列表来声明需要缓存的静态资源，再使用一个变量[代码]CACHE_NAME[代码]来确定当前缓存的[代码]Cache Storage Name[代码]，这里可以理解成[代码]Cache Storage[代码]是一个[代码]DB[代码]，而[代码]CACHE_NAME[代码]则是[代码]DB[代码]名： [代码]var urlsToCache = [ '/', '/index.js', '/style.css', '/favicon.ico', ]; var CACHE_NAME = 'counterxing'; [代码] [代码]Lifecycle[代码] [代码]Service Worker[代码]独立于浏览器[代码]JavaScript[代码]主线程，有它自己独立的生命周期。 如果需要在网站上安装[代码]Service Worker[代码]，则需要在[代码]JavaScript[代码]主线程中使用以下代码引入[代码]Service Worker[代码]。 [代码]if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js').then(function(registration) { console.log('成功安装', registration.scope); }).catch(function(err) { console.log(err); }); } [代码] 此处，一定要注意[代码]sw.js[代码]文件的路径，在我的示例中，处于当前域根目录下，这意味着，[代码]Service Worker[代码]和网站是同源的，可以为当前网站的所有请求做代理，如果[代码]Service Worker[代码]被注册到[代码]/imaging/sw.js[代码]下，那只能代理[代码]/imaging[代码]下的网络请求。 可以使用[代码]Chrome[代码]控制台，查看当前页面的[代码]Service Worker[代码]情况： [图片] 安装完成后，[代码]Service Worker[代码]会经历以下生命周期： 下载（[代码]download[代码]） 安装（[代码]install[代码]） 激活（[代码]activate[代码]） 用户首次访问[代码]Service Worker[代码]控制的网站或页面时，[代码]Service Worker[代码]会立刻被下载。之后至少每[代码]24[代码]小时它会被下载一次。它可能被更频繁地下载，不过每[代码]24[代码]小时一定会被下载一次，以避免不良脚本长时间生效。 在下载完成后，开始安装[代码]Service Worker[代码]，在安装阶段，通常需要缓存一些我们预先声明的静态资源，在我们的示例中，通过[代码]urlsToCache[代码]预先声明。 在安装完成后，会开始进行激活，浏览器会尝试下载[代码]Service Worker[代码]脚本文件，下载成功后，会与前一次已缓存的[代码]Service Worker[代码]脚本文件做对比，如果与前一次的[代码]Service Worker[代码]脚本文件不同，证明[代码]Service Worker[代码]已经更新，会触发[代码]activate[代码]事件。完成激活。 如图所示，为[代码]Service Worker[代码]大致的生命周期： [图片] [代码]install[代码] 在安装完成后，尝试缓存一些静态资源： [代码]self.addEventListener('install', function(event) { self.skipWaiting(); event.waitUntil( caches.open(CACHE_NAME) .then(function(cache) { return cache.addAll(urlsToCache); }) ); }); [代码] 首先，[代码]self.skipWaiting()[代码]执行，告知浏览器直接跳过等待阶段，淘汰过期的[代码]sw.js[代码]的[代码]Service Worker[代码]脚本，直接开始尝试激活新的[代码]Service Worker[代码]。 然后使用[代码]caches.open[代码]打开一个[代码]Cache[代码]，打开后，通过[代码]cache.addAll[代码]尝试缓存我们预先声明的静态文件。 监听[代码]fetch[代码]，代理网络请求 页面的所有网络请求，都会通过[代码]Service Worker[代码]的[代码]fetch[代码]事件触发，[代码]Service Worker[代码]通过[代码]caches.match[代码]尝试从[代码]Cache[代码]中查找缓存，缓存如果命中，则直接返回缓存中的[代码]response[代码]，否则，创建一个真实的网络请求。 [代码]self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { if (response) { return response; } return fetch(event.request); }) ); }); [代码] 如果我们需要在请求过程中，再向[代码]Cache Storage[代码]中添加新的缓存，可以通过[代码]cache.put[代码]方法添加，看以下例子： [代码]self.addEventListener('fetch', function(event) { event.respondWith( caches.match(event.request) .then(function(response) { // 缓存命中 if (response) { return response; } // 注意，这里必须使用clone方法克隆这个请求 // 原因是response是一个Stream，为了让浏览器跟缓存都使用这个response // 必须克隆这个response，一份到浏览器，一份到缓存中缓存。 // 只能被消费一次，想要再次消费，必须clone一次 var fetchRequest = event.request.clone(); return fetch(fetchRequest).then( function(response) { // 必须是有效请求，必须是同源响应，第三方的请求，因为不可控，最好不要缓存 if (!response || response.status !== 200 || response.type !== 'basic') { return response; } // 消费过一次，又需要再克隆一次 var responseToCache = response.clone(); caches.open(CACHE_NAME) .then(function(cache) { cache.put(event.request, responseToCache); }); return response; } ); }) ); }); [代码] 在项目中，一定要注意控制缓存，接口请求一般是不推荐缓存的。所以在我自己的项目中，并没有在这里做动态的缓存方案。 [代码]activate[代码] [代码]Service Worker[代码]总有需要更新的一天，随着版本迭代，某一天，我们需要把新版本的功能发布上线，此时需要淘汰掉旧的缓存，旧的[代码]Service Worker[代码]和[代码]Cache Storage[代码]如何淘汰呢？ [代码]self.addEventListener('activate', function(event) { var cacheWhitelist = ['counterxing']; event.waitUntil( caches.keys().then(function(cacheNames) { return Promise.all( cacheNames.map(function(cacheName) { if (cacheWhitelist.indexOf(cacheName) === -1) { return caches.delete(cacheName); } }) ); }) ); }); [代码] 首先有一个白名单，白名单中的[代码]Cache[代码]是不被淘汰的。 之后通过[代码]caches.keys()[代码]拿到所有的[代码]Cache Storage[代码]，把不在白名单中的[代码]Cache[代码]淘汰。 淘汰使用[代码]caches.delete()[代码]方法。它接收[代码]cacheName[代码]作为参数，删除该[代码]cacheName[代码]所有缓存。 sw-precache-webpack-plugin sw-precache-webpack-plugin是一个[代码]webpack plugin[代码]，可以通过配置的方式在[代码]webpack[代码]打包时生成我们想要的[代码]sw.js[代码]的[代码]Service Worker[代码]脚本。 一个最简单的配置如下： [代码]var path = require('path'); var SWPrecacheWebpackPlugin = require('sw-precache-webpack-plugin'); const PUBLIC_PATH = 'https://www.my-project-name.com/'; // webpack needs the trailing slash for output.publicPath module.exports = { entry: { main: path.resolve(__dirname, 'src/index'), }, output: { path: path.resolve(__dirname, 'src/bundles/'), filename: '[name]-[hash].js', publicPath: PUBLIC_PATH, }, plugins: [ new SWPrecacheWebpackPlugin( { cacheId: 'my-project-name', dontCacheBustUrlsMatching: /\.\w{8}\./, filename: 'service-worker.js', minify: true, navigateFallback: PUBLIC_PATH + 'index.html', staticFileGlobsIgnorePatterns: [/\.map$/, /asset-manifest\.json$/], } ), ], } [代码] 在执行[代码]webpack[代码]打包后，会生成一个名为[代码]service-worker.js[代码]文件，用于缓存[代码]webpack[代码]打包后的静态文件。 一个最简单的示例。 [代码]Service Worker Cache[代码] VS [代码]Http Cache[代码] 对比起[代码]Http Header[代码]缓存，[代码]Service Worker[代码]配合[代码]Cache Storage[代码]也有自己的优势： 缓存与更新并存：每次更新版本，借助[代码]Service Worker[代码]可以立马使用缓存返回，但与此同时可以发起请求，校验是否有新版本更新。 无侵入式：[代码]hash[代码]值实在是太难看了。 不易被冲掉：[代码]Http[代码]缓存容易被冲掉，也容易过期，而[代码]Cache Storage[代码]则不容易被冲掉。也没有过期时间的说法。 离线：借助[代码]Service Worker[代码]可以实现离线访问应用。 但是缺点是，由于[代码]Service Worker[代码]依赖于[代码]fetch API[代码]、依赖于[代码]Promise[代码]、[代码]Cache Storage[代码]等，兼容性不太好。 后话 本文只是简单总结了[代码]Service Worker[代码]的基本使用和使用[代码]Service Worker[代码]做客户端缓存的简单方式，然而，[代码]Service Worker[代码]的作用远不止于此，例如：借助[代码]Service Worker[代码]做离线应用、用于做网络应用的推送（可参考push-notifications）等。 甚至可以借助[代码]Service Worker[代码]，对接口进行缓存，在我所在的项目中，其实并不会做的这么复杂。不过做接口缓存的好处是支持离线访问，对离线状态下也能正常访问我们的[代码]Web[代码]应用。 [代码]Cache Storage[代码]和[代码]Service Worker[代码]总是分不开的。[代码]Service Worker[代码]的最佳用法其实就是配合[代码]Cache Storage[代码]做离线缓存。借助于[代码]Service Worker[代码]，可以轻松实现对网络请求的控制，对于不同的网络请求，采取不同的策略。例如对于[代码]Cache[代码]的策略，其实也是存在多种情况。例如可以优先使用网络请求，在网络请求失败时再使用缓存、亦可以同时使用缓存和网络请求，一方面检查请求，一方面有检查缓存，然后看两个谁快，就用谁。 优化方向：目前我所负责的DICOM项目，虽然还没有用上[代码]Service Worker[代码]，但前面经过不断地优化迭代，通过从增加http层的缓存、无损压缩图像的替换、有损压缩图像的渐进加载、更换DICOM解压缩策略、使用indexed DB缓存CT图像、首屏可见速度已经从20多秒降低到5秒左右，内存占用从700M以上降低到250M左右。后期还会一直深挖这一块。主要方向之一就是service worker的替换，全站缓存静态资源。此外，高优先级的则是DICOM无损图像解压算法的最优选择与优化、cornerstone的jpg图像展示。 项目优化还在继续，力求极致性能和用户体验~

概述 本文介绍了微信小程序视音视频和WebRTC的技术特征、差异等，并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。 关于作者 rexchang（常青）：腾讯视频云终端技术总监，2008 年毕业加入腾讯，一直从事客户端研发相关工作，先后参与过 PC QQ、手机QQ、QQ物联 等产品项目，目前在腾讯视频云团队负责音视频终端解决方案的优化和落地工作。 分别介绍一下小程序音视频和WebRTC 小程序音视频是什么？ 2017年腾讯视频云团队跟微信团队联合，将视频云 SDK 跟微信小程序整合在一起，并通过 <live-pusher> 和 <live-player> 两个标签的形式开放内部的功能。通过这两个标签，开发者可以实现在线直播、低延时监控、双人视频通话以及多人视频会议等功能 [图片] WebRTC又是什么？ WebRTC（Web Real-Time Communication），是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌收购 GIPS 公司而获得的一项技术，在 Chrome 浏览器上无需安装插件，通过 javascript 就可以编写实时音视频通话程序。 小程序音视频和WebRTC的区别在哪里？ 如果您跟我一样是一个实用主义者，那我就简单从实用主义角度说一下我的结论：小程序搞定了手机，WebRTC拿下了PC。 如果你对技术原理比较感兴趣，那我们就可以从多个技术的角度去列举两者的区别，下面是一张详细对比的表格： [图片] （区别一）：内部原理 小程序音视频是将腾讯视频云的 liteavsdk 嵌入到微信内部实现的，然后通过 <live-pusher> 和 <live-player> 两个标签将 SDK 内部的音视频能力开放出来。所以小程序的标签起到了开发者 API 的作用，而内部的 SDK 则是真正用来实现音视频功能。 WebRTC 由谷歌收购 GIPS 得来（这里不得不提一下，我加入腾讯时所在的第一个团队就是 QQ 团队，当时 QQ 的音视频还是购买的 GIPS 公司的产品，不过由于技术支持不能满足需求，后来我们就转为自研路线了）。所以其技术被完整的保留并且加入到了 Google 的 Chrome 浏览器内核当中。而且最近苹果也已经开始在 Safari 浏览器中支持 WebRTC 的相关能力。 （区别二）：传输协议 小程序音视频在直播场景使用了 RTMP 推流协议以及 FLV 播放协议，这两种协议都已经有多年的沉淀而且在互联网上的资料也是汗牛充栋。 小程序音视频在视频通话场景则使用了经过 UDP 改造的 RTMP 协议，相比于普通 RTMP 有更强的抗弱网能力和更低的卡顿率。 小程序音视频内核 LiteAVSDK 的抗弱网演示 WebRTC的底层则是使用RTP和RTCP两种数据协议，其中RTP主要用于音视频数据传输，而 RTCP 则用于传输控制。 （区别三）：移动端碎片化问题 小程序音视频由于是微信统一实现的，而且微信团队每个版本都尽量要求功能对齐，否则宁可不上，所以在碎片化问题上基本不存在。 相比之下，WebRTC在这里则要尴尬的多，一方面Android系统的碎片化本身让WebRTC的具体表现呈现“百花齐放”的景象，同时，iOS 目前的内嵌WebView（也就是在微信等APP里打开的各种内嵌网页）不支持WebRTC也还是个很麻烦的问题。 （区别四）：未来扩展性 小程序音视频跟随微信的版本发布，有什么问题一般是当前代码流修正，然后跟随下一个版本发布，所以一般一个功能点（比如给 pusher 加一个美颜的功能）或者一个问题点（比如不支持手势放大）从确立到最终实现（或解决）仅需要一个月的时间，而且微信APP新版本的覆盖速度也确实挺快。 相比之下，WebRTC则不是一个团队或者一家公司的问题了，因为它现在已经走标准路线，所以每一个新特性都是先确定标准，然后再推动浏览器厂商（包括苹果）进行跟随。 （区别五）： 桌面浏览器 在前面几个问题的分析上，我的观点都倾向于小程序音视频。确实，在目前国内的移动领域里，谷歌和苹果都不能一家说了算，真正说了算的还是微信。 但是在桌面浏览器这个部分，Chrome目前在PC浏览器市场上留到地位的存在决定了 WebRTC 的优势就很大了，开发者可以在不安装插件的情况下就可以实现自己想要的功能。 所以，实现同 Chrome 浏览器的音视频互通，成为了小程序音视频的一个必不可少的能力特性。 互联互通 小程序音视频和WebRTC支架并非零和博弈，双方都有自己的优势和不足，实现两者的互通就能实现 1 + 1 > 2 的效果。 PC 端 用户可以使用 Chrome 浏览器直接使用音视频能力，免去安装桌面应用程序的痛苦。 移动端 用户可以使用微信小程序直接使用音视频能力，减少安装App的等待时间。 两者结合，可以将原本局限于小应用场景下的音视频能力扩展到各行各业中。 当然，要实现互联互通，并不是特别容易，首先，我们需要对 WebRTC 协议本身有一个全面的了解： 剖析WebRTC 就像结婚一样，既然你决定要选择另一个人作为人生下半辈子的伴侣，那你肯定会先深入地了解一下TA这个人，比如性格，脾气，爱好等各个方面。 同样，我们要想很好的将小程序音视频和WebRTC打通，那也必须要多了解一下WebRTC，对其知根知底，方能和平相处。 WebRTC 的设计思路是open的 WebRTC 的接口设计一开始就尽可能把内部细节更多的暴露出来，而不是简单封装一套傻瓜式的接口。这种方案的好处是二次开发的灵活度比较高，比如您可以发现 WebRTC 的 API 可以灵活到操作很多连接细节。 但任何事情都有另一面，WebRTC的学习成本并不低，虽然Google做了很多浅显易懂的PPT来教你怎么 Getting Start，但真要完整的学进去，还是需要静下心来，慢慢啃下去。 WebRTC 有多种后台接入方案 说WebRTC喜欢迁就比人，也是一种比喻，WebRTC所支持的后台架构非常多（比如 Mixer， Mesh，Router），而且谷歌认为这些后台实现方案并不需要给出什么限制和标准，因此也就没有提供统一的后台解决方案。 这种开放式的设计思路非常好，但副作用就是实现成本高。在真刀真枪的项目落地时，没有踩坑经验的开发者就很容易被这种技术门槛挡在门外。尤其是想要将 WebRTC 真正应用到企业级解决方案中，面对录制和存档的刚性需求，就需要花费大量时间进行定制开发。 互通方案 了解到 WebRTC 的这些特点后，我们的互通方案也就比较清晰了： 首先，小程序音视频的特点是接口简单，快速上手，这是小程序的优势；而这一点恰恰是WebRTC的劣势，所以我们没有必要在小程序端为WebRTC暴露十几组接口函数，而是继续采用小程序音视频的<live-pusher> 和 <live-player> 标签来解决问题。 其次，WebRTC 的后台没有官方实现，那就意味着这里有很大的发挥空间，腾讯视频云就可以实现一套WebRTC后台并将其同小程序音视频所使用RTMP后台进行打通。简单来说，腾讯视频云要在小程序音视频和WebRTC之间充当红娘（更确切的说，应该是翻译员）的角色。 但是看过《新闻联播》里国家领导人之间谈话镜头的人都知道，这种翻译是会影响交流速度的。小程序音视频和WebRTC之间互通，中间引入一个翻译员，是不是通讯延时也就增加了？ 其实不会，因为小程序音视频和WebRTC的视频编码标准在常规应用场景中是一致的，都是H.264标准，只是音频格式不同而已。这就意味着，翻译员要做的事情很少，两边基本都能听懂对方在说什么，所以延时不会增加多少。 协议握手 下图所展示的就是腾讯视频云在小程序音视频和WebRTC互通问题上所采取的方案： [图片] （1）首先，微信端的小程序通过腾讯视频云SDK将音视频流推送到腾讯云 RTMP 服务器。 （2）其次，腾讯云 RTMP 服务器的会对音视频数据进行初步的转化处理，然后透传给腾讯视频云的实时音视频后台集群。 （3）再次，实时音视频后台会再次将数据交给一个叫做 WebRTC-Proxy 的模块，就在这里， WebRTC-Proxy 要将来自小程序音视频的音视频数据翻译成 WebRTC 理解的“语言”。 （4）最后，在PC上的Chrome浏览器，就可以通过浏览器内置的WebRTC模块跟 WebRTC-Proxy 通讯，进而看到小程序端的视频影像。 （5）上面的四个过程倒过来，就可以实现双向视频通话；而将腾讯视频云作为星型结构的中心节点，多个端（不管是小程序还是Chrome浏览器）都接入进来，那就可以形成多人音视频解决方案。 打通房间逻辑 仅仅完成了音视频数据在小程序和WebRTC之间的握手还远远不够，因为在一次成功的音视频通话背后，不仅仅是把一端的音视频数据传递到另一端这么简单，还有状态的同步和成员间的状态协同。 比如多人视频通话中，涉及到呼叫和接通的流程，其中一方如果挂断了，其他人要收到挂断的通知。同时，如果有新的参与者加入，那么其他人也要收到相应的通知。WebRTC 中有很多组件，比如 RTCPeerConnection 就负责处理网络连接中各种密密麻麻的逻辑细节。但是 WebRTC 的接口中引入的新名词非常多，对于初学者来说还是有一定的门槛，为了简化这里的逻辑，我们引入一个叫做“房间”的概念。 所谓房间（Room），就是把同时参与视频通话的各方圈在一起的一个东西。比如双人通话中，通话中的两个人 A 和 B 就可以认为在一个房间中。再比如在多人通话中，通话中的五个人（A B C D E）也可以认为是在一个房间里。 有了房间的概念，那我们就可以对刚才说的状态协同用两个简单的动作描述一下：如果有一个人加入了视频通话，那么就可以理解为他/她已经进房（EnterRoom）了；如果有一个退出了视频通话，那么就可以理解为他/她已经离开房间（LeaveRoom）了。而房间的门板上始终写着：“目前在房间里有哪几个人”。 有了房间的概念，我们就可以将小程序的两个简单的<live-pusher> 和 <live-player>标签，同 WebRTC 那一套复杂的 API 进行功能上的对齐，我们甚至不需要修改我们在第一版中定义的接口，就可以达成这个目标： <live-pusher> 标签：代表房间中的“我”。 <live-player> 标签：代表房间中的“其他人”。 内部逻辑细节 [图片] （1）<live-pusher> 的 url 接口不再传递 rtmp:// 协议的推流地址，而是传递 room:// 协议的推流地址。 （2）<live-pusher> 标签在 start 成功之后，就相当于成功进入一个 room，之后，您可以通过 onPushEvent (PUSH_EVT_ROOM_USERLIST = 1020) 事件，收到房间里还有那些人的信息。在视频通话期间，房间内各个成员的进进出出，也都会通过这个事件通知给您的小程序代码。 （3）ROOM_USERLIST 里每一项都是一个二元组（如果是 1v1 的视频通话，ROOM_USERLIST 里只会有一个人）: userid 和 playurl。 userid 代表是哪个用户， playurl 则是这个用户远程画面的播放地址。您要做的只是使用 <live-player> 标签播放这些远程画面的图像和声音而已。 （4）在 WebRTC 这一端，您可以参考我们的 webrtc API，这套 API 相对于 WebRTC 原生的 API，更适合初学者使用。 呃… 您可能会说：“你这也叫简单呀，我感觉还是要写几十行代码，能不能真的做到像一个标签一样简单呢？” 好吧，其实上面四步是我们第一个版本的接入流程，就在我们昨晚这套方案之后，小程序团队刚好推出了自定义组件的机制，于是，我们有了更好的接入方案。 能不能更简单? 如果您希望一天内就打通 webrtc 和 小程序音视频 的互通，那么我推荐您不要从零开始，因为那会耗费您太多时间去踩坑和 bugfix，推荐您直接使用我们封装好的 <webrtc-room> ，这套方案既可以帮助您完成快速接入，又能满足一定的定制需求。 另外，不要忘记在微信=>发现=>小程序=>腾讯云视频云，体验一下腾讯云官方 Demo 中的 WebRTC 互通效果哦。 [图片] <webrtc-room> 功能说明 <webrtc-room> 标签是基于 <live-pusher> 和 <live-player> 实现的用于 WebRTC 互通的自定义组件。用于实现跟 Chrome 和 App SDK 之间的视频通话功能。 版本要求 微信 6.6.6 版本开始支持。 Demo体验 (1) Chrome: 用谷歌浏览器打开 体验页面。 (2) 微信端：发现=>小程序=>搜索“腾讯视频云”，点击 视频通话 页卡，输入相同的房间号。 对接资料 源码地址 源码说明 小程序端源码 Github Chrome端源码 Github 属性定义 属性 类型 默认值 说明 template String ‘float’ 必要，标识组件使用的界面模版。 demo中内置 bigsmall，float，grid三种布局 sdkAppID String   必要，开通实时音视频服务创建应用后分配的 sdkAppID userID String   必要，用户 ID userSig String   必要，身份签名，相当于登录密码的作用 roomID Number   必要，房间号 beauty Number 0 可选， 美颜指数，取值 0 - 9，数值越大效果越明显 whiteness String 0 可选， 美白指数，取值 0 - 9，数值越大效果越明显 muted Boolean false 可选，true 静音 false 不静音 debug Boolean false 可选，true 打印推流 debug 信息 fales 不打印推流 debug 信息 bindRoomEvent Function   必要，监听 <webrtc-room> 组件返回的事件 enableIM Boolean false   可选，是否启用IM bindIMEvent Function   当IM开启时必要，监听 IM 返回的事件 aspect String 9:16 可选， 宽高比3:4, 9:16 minBitrate String 200 可选，最小码率，该数值决定了画面最差的清晰度表现 maxBitrate String 400 可选，最大码率，该数值决定了画面最好的清晰度表现 autoplay Boolean false 可选，进入房间后是否自动显示远程画面 enableCamera Boolean true 可选，开启\关闭摄像头 pureAudioPushMode Number   可选，纯音频推流模式 recordId Number   可选，自动录制时业务自定义id enableCamera Boolean true 是否开启摄像头 smallViewLeft String ‘1vw’ 小窗口距离大画面左边的距离，只在template设置为bigsmall有效 smallViewTop String ‘1vw’ 小窗口距离大画面顶部的距离，只在template设置为bigsmall有效 smallViewWidth String ‘30vw’ 小窗口宽度，只在template设置为bigsmall有效 smallViewHeight String ‘40vw’ 小窗口高度，只在template设置为bigsmall有效 waitingImg String   当微信切到后台时的垫片图片 loadingImg String   画面loading图片 操作接口 <webrtc-room> 组件包含如下操作接口，您需要先通过 selectComponent 获取 <webrtc-room> 标签的引用，之后就可以进行相应的操作了。 函数名 说明 start() 启动 pause() 暂停 resume() 恢复 stop() 停止 switchCamera() 切换摄像头 sendC2CTextMsg(receiveUser, msg, succ, fail) 发送C2C文本消息 sendC2CCustomMsg(receiveUser, msgObj, succ, fail) 发送C2C自定义消息 sendGroupTextMsg(msg, succ, fail) 发送群组文本消息 sendGroupCustomMsg(msgObj, succ, fail) 发送群组自定义消息 [代码]var webrtcroom = this.selectComponent("#webrtcroomid") webrtcroom.pause(); [代码] 事件通知 <webrtc-room> 标签通过 onRoomEvent 返回内部事件，通过 onIMEvent返回 IM 消息事件，事件参数格式如下: [代码]"detail": { "tag": "事件tag标识，具有唯一性", "code": "事件代码", "detail": "对应事件的详细参数" } [代码] 如何快速接入? 上面说了很多细节的技术原理和内部细节，如果您想要快速尝试一下，建议您阅读下面三篇文章就可以了。 一分钟跑通demo 我们准备了一个简单上手的小程序音视频Demo，输入房间号即可开始通话，这篇文章主要介绍如何把Demo快速地 run 起来。 一分钟集成组件 这篇文章主要介绍如何快速地将 <webrtc-room> 组件集成到您的小程序工程项目中。 快速调通基本功能 这篇文档就主要介绍如何二次开发了，它介绍了<webrtc-room> 中主要 API 的使用。 总结 本篇文章主要介绍了小程序音视频和Chrome浏览中重要的WebRTC技术的互通方案，希望能对您的项目开发有所帮助，期待您的反馈。

注：本文需要有一定的 PWA 基础 1. 什么是 PWA？ 要知道一个东西是什么，我们通常可以从它的名字入手 因此我们看下 PWA 的全称是： Progressive Web App 回答 what 这种问题，重点在于名词，因此 PWA 是一个 APP，一个独立的、增强的、Web 实现的 APP 要达到这样的目的，PWA 提供了一系列的技术 & 标准，如下图所示： [图片] 具体每一项技术是什么就不再赘述了，感兴趣的同学自行网上搜索！ 下面有一个简单的 demo 可以简单体会一下： [图片] 以后我们的 web 站点可以像 app 一样，这难道不是一个令人兴奋的事情吗？ 所以 PWA 是值得我们前端开发者一直关注的技术！ 按照目前的兼容性和环境来看，大家应用最多的还是 Service Worker，因此接下来我们也是把重点放在 SW 上面 那什么是 Service Worker ? 大家都知道就不卖关子了，其实就是一个 Cache 说到 Cache，就一定会想到性能优化了，请看我们的第二部分 2. 首屏优化 2.1. 静态资源优化 如何利用 Cache 来进行优化？这个基本套路应该无人不知了： [图片] 那么首次加载怎么办呢？首次加载是没有缓存资源的，所以会走到线上，所以等于没有任何优化 答案就是 Cache 的第二种常用技巧： precache(预加载) 预加载的意思就是在某个地方或特定时机预先把需要用到的资源加载并缓存 我们的做法如下图所示： [图片] 构建的时候，把整个项目用到的资源输出到一个 list 中，然后 inline 到 sw.js 里面 当 sw install 时，就会把这个 list 的资源全部请求并进行缓存 这样做的结果就是，无论用户第一次进入到我们站点的哪个页面，我们都会把整个站点所有的资源都加载回来并缓存 当用户跳转另外一个页面的时候，Cache 里面就有相应的资源了！ 这是我们辅导课堂页面接入 sw 之后的首屏优化效果： [图片] 2.2. 动态数据优化 除了静态资源之外，我们还能缓存其他的内容吗？ 答案肯定是可以的，我们还可以缓存 cgi 数据！ [图片] 缓存 cgi 数据的流程和缓存静态资源的流程主要有2个差别，上图标红的地方： 需要添加一个开关功能，因为不是所有 cgi 都需要缓存的！ 页面需要展示最新的数据，因此在返回缓存结果之后，还需要请求线上最新的数据，更新缓存，并且返回给页面展示，也就是说页面需要展示2次 页面展示2次需要考虑页面跳动的体验问题，选择权在于业务本身！ 这是我们辅导上课页接入该功能后的首屏优化效果： [图片] 动态数据缓存是否有意义还需要额外的逻辑来判断，这块暂时是没有做的，后续会补上相关统计 2.3. 直出html优化 还能缓存什么？我们想到了直出的 html 这里就不展开讲了，因为我们的 jax 同学已经分享了一篇优秀的文章《企鹅辅导课程详情页毫秒开的秘密 - PWA 直出》，可以去看看哈~ 3. 替代离线包 PWA 与离线包本质上是一样的，都是离线缓存 正好，我们 PC 客户端的离线包系统年久失修，在这个契机下，我们启动了使用 PWA 替换离线包的方案！ 核心流程不变，基本和缓存静态资源的流程是一致的 但是离线包系统是非常成熟的系统，要完全替换掉它还需要考虑许多方面的问题。 3.1. 更新机制 离线包有个自动更新的机制，每隔一段时间就会去请求离线包管理系统是否有更新，有的话就把最新的离线包拉下来自动更新替换，这样只需要1次跳转就能展示最新的页面。 SW 没有自动更新的逻辑，它需要在页面加载(一次跳转)之后才会去请求 sw.js，判断有变化才会进行更新，更新完了要等到下一次页面跳转(二次跳转)才能展示最新的页面。 这里有两个方案： 参考离线包的更新机制，也给 SW 实现一个自动更新的逻辑，借用 update 接口是可以做到主动去执行 SW 更新的。但是非常遗憾，我们的客户端 webkit 内核版本太低，并不支持这个接口 在第一次跳转之后更新 sw，然后检测 sw 状态，发现如果有更新，就用一定的策略来进行页面的刷新 我们使用第2个方案，部分代码如下： [图片] 在检测到 sw 更新之后，我们可以选择强刷，或者提示用户手动刷新页面，具体实现页面可以通过监听事件来处理 更多详细的实现方案可以参考这篇文章哈：How to Fix the Refresh Button When Using Service Workers 3.2. 首次打开问题 一般离线包是打进 app 的安装包一起发布的，在用户下载安装之后，离线包就已经存在于本地，因此第一次打开就能享受到离线包的缓存。 但是 sw 没有这个能力，同样我们也有两个方案： 在 app 安装的时候，添加一步，通过创建 webview 加载页面，页面执行 SW 的初始化工作，并展示相应的进度提示，在安装完成后需要把 webview 的 SW Cache 底层文件 copy 到相应的安装位置。这个方案太复杂，衡量下来没有采用。 在 app 启动时，创建一个隐藏的 webview，加载空页面去加载 SW。 我们使用第2个方案，因为我们的 app 启动会先让用户登录，如下图所示： [图片] 注：这里 app 不是移动端 app，是 pc 的客户端 app 3.3. 屏蔽机制 有时候我们不想使用离线缓存能力，比如在我们开发的时候 在离线包系统，通常会有一个开发者选项是【屏蔽离线包】 SW 也是需要这种能力的，这个方案就比较简单了，在 sw.js 的逻辑里有一个全局的开关，当开关关闭时，就不会走缓存逻辑 因此，我们可以在 dev 环境下把开关关闭即可达到屏蔽的作用 [图片] 3.4. 降级方案 当我们发布了一个错误代码的时候，我们需要快速降级容错的能力 在离线包系统里面有个过期的功能，可以把某个版本设置过期，也就是废弃掉： [图片] 我们利用之前提到的全局开关，通过一个管理接口来设置开关的起开和关闭，即可达到快速降级的目的： [图片] 整个流程大致是这样： 发布了错误代码，并且用户本地 sw 已经更新缓存了错误代码 在管理端关闭使用缓存开关，让用户走线上 快速修复代码并发布，到这里页面就已经恢复正常 在管理端开启使用缓存开关，恢复 SW 功能 请求管理接口是轮询的，这里后续有计划会改成 push，这样会更加及时，当然还要详细评估方案之后才能落实。 4. 如何方便接入？ 我们把上述功能集成到了一个 webpack 插件当中，在构建的时候就自动输出 sw.js 并把相关内容注入到 html 文件中，该插件正准备开源哈~ 5. 未来 未来对于 PWA 还能做些什么？笔者以为有以下 2 个方面 5.1. 业务深耕 目前通用的能力已经基本挖掘完成，但是 SW 因为它独特的特性，它能做的事情太多了，但是具体要不要这么做也是因业务而异，而且这些内容可能会很复杂，所以我称为业务深耕。 SW 什么特性？请看下面 2 张图就可以理解了 [图片] [图片] 这种架构相信已经能够看出来了，没错，SW 有间件(层)的特性，那它能做的东西就太多了（虽然 SW 是用户端本地中间层） 简单举几个例子： server 负载控制：当发现 server 端高负载时，SW 可以丢弃请求，或者缓存请求，合并/延迟发送。 预请求：SW 能预缓存的资源是可以构建出来的资源，但是我们还有许多资源是不能在构建阶段知道的，比如图片，第三方资源等，SW 在返回资源请求（比如HTML、cgi 数据）之后，可以扫描资源里面的内容，如果发现包含了其他资源的 url，那说明页面很有可能待会就会请求这些资源，这时 SW 可以提前去请求这些资源；再比如翻页的数据 缓存自动更新：通过与 server 建立联系，当数据有变化时，server 直接把最新的数据 push 到 SW 进行缓存的更新 5.2. 关注 PWA 回到最开始，PWA 是一项令人兴奋的技术，但是浏览器兼容有限，因此期待并关注 PWA 技术的发展是很有必要的！ 当然，能推动就更好了！比如推动我们的 X5 内核尽快支持新特性。 关注我们 IMWeb 团队隶属腾讯公司，是国内最专业的前端团队之一。 我们专注前端领域多年，负责过 QQ 资料、QQ 注册、QQ 群等亿级业务。目前聚焦于在线教育领域，精心打磨 腾讯课堂 及 企鹅辅导 两大产品。 社区官网： http://imweb.io/ 加入我们： https://hr.tencent.com/position_detail.php?id=45616 [图片] 扫码关注 IMWeb前端社区 公众号，获取最新前端好文 微博、掘金、Github、知乎可搜索 IMWeb 或 IMWeb团队 关注我们。

1. JavaScript定义 JavaScript 是一种单线程编程语言，这意味着同一时间只能完成一件事情。也就是说，JavaScript 引擎只能在单一线程中处理一次语句。 优点：单线程语言简化了代码编写，因为你不必担心并发问题，但这也意味着你无法在不阻塞主线程的情况下执行网络请求等长时间操作。 缺点：当从 API 中请求一些数据。根据情况，服务器可能需要一些时间来处理请求，同时阻塞主线程，让网页无法响应。 2. 异步运行机制 CallBack，setTimeOut，ajax 等都是通过**事件循环（event loop）**实现的。 2.1 什么是Event Loop？ 主线程运行的时候，产生堆（heap）和栈（stack），栈中的代码调用各种外部API，它们在"任务队列"中加入各种事件（click，load，done）。只要栈中的代码执行完毕，主线程就会去读取"任务队列"，依次执行那些事件所对应的回调函数。 2.2 流程整体示意图 [图片] 2.3 总结异步运行到整体机制 主线程在运行的时候，将产生堆（heap）和栈（stack），栈中的代码会调用各种外部API，它们将在"任务队列"中根据类型不同，分类加入到相关任务队列中，如各种事件等。只要栈中的代码执行完毕，主线程就会去读取"任务队列"，根据任务队列的优先级依次执行那些事件所对应的回调函数。这就是整体的事件循环。 2.4 任务队列的优先级 微任务队列中的所有任务都将在宏队列中的任务之前执行。也就是说，事件循环将首先在执行宏队列中的任何回调之前清空微任务队列。 ** 举例： ** [代码] console.log('Script start'); setTimeout(() => { console.log("setTimeout 1"); }, 0); setTimeout(() => { console.log("setTimeout 2"); }, 0); new Promise ((resolve, reject) => { resolve("Promise 1 resolved"); }) .then(res => console.log(res)) .catch(err => console.log(err)); new Promise ((resolve, reject) => { resolve("Promise 2 resolved"); }) .then(res => console.log(res)) .catch(err => console.log(err)); console.log('Script end'); [代码] 运行结果是： Script start Script end Promise 1 Promise 2 setTimeout 1 setTimeout 2 通过上述例子可以看到无论宏队列的位置在何方，只要微队列尚未清空，一定会先清空微队列后，在去执行宏队列。下面介绍微队列任务中比较典型的几个API，通过相关举例，让你更深入理解JS的异步机制。 3. 微任务队列 3.1 Promise（ES6） Promise，就是一个对象，用来传递异步操作的消息。 3.1.1 基础用法： [代码] var promise = new Promise(function(resolve, reject) { //异步处理逻辑 //处理结束后，调用resolve返回正常内容或调用reject返回异常内容 }) promise.then(function(result){ //正常返回执行部分，result是resolve返回内容 }, function(err){ //异常返回执行部分，err是reject返回内容 }) .catch(function(reason){ //catch效果和写在then的第二个参数里面一样。另外一个作用：在执行resolve的回调时，如果抛出异常了（代码出错了），那么并不过报错卡死JS，而是会进入到这个catch方法中，所以一般用catch替代then的第二个参数 }); [代码] 缺点： 无法取消 Promise，一旦新建它就会立即执行，无法中途取消。其次，如果不设置回调函数，Promise 内部抛出的错误，不会反应到外部。再次，当处于 Pending 状态时，无法得知目前进展到哪一个阶段（刚刚开始还是即将完成）。 优点： Promise能够简化层层回调的写法，Promise的精髓是“状态”，用维护状态、传递状态的方式来使得回调函数能够及时调用，它比传递callback函数要简单、灵活的多。 3.1.2 用法注意点 - 顺序： [代码] new Promise((resolve, reject) => { resolve(1); console.log(2); }).then(r => { console.log(r); }); [代码] 运行结果是： 2 1 说明： 立即 resolved 的 Promise 是在本轮事件循环的末尾执行，总是晚于本轮循环的同步任务。也就是resolve(1）和console.log(2)是属于同步任务，需要全部执行完同步任务后，再去循环到resolve的then中。 3.1.3 用法注意点 - 状态： [代码] const p1 = new Promise(function (resolve, reject) { setTimeout(() => reject(new Error('fail')), 3000); }); const p2 = new Promise(function (resolve, reject) { setTimeout(() => resolve(p1), 1000); }); const p3 = new Promise(function (resolve, reject) { setTimeout(() => resolve(new Error('fail')), 1000); }); p2 .then(result => console.log("1:", result)) .catch(error => console.log("2:",error)); p3 .then(result => console.log("3:", result)) .catch(error => console.log("4:",error)); [代码] 运行结果是： 3: Error: fail at setTimeout (async.htm:182) 2: Error: fail at setTimeout (async.htm:174) 说明： p1是一个 Promise，3 秒之后变为rejected。p2和p3的状态是在 1 秒之后改变，p2 resolve方法返回的是 p1， p3 resolve方法返回的是 抛出异常。但由于p2返回的是另一个 Promise，导致p2自己的状态无效了，由p1的状态决定p2的状态。所以后面的then语句都变成针对后者（p1）。又过了 2 秒，p1变为rejected，导致触发catch方法指定的回调函数。 而p3返回的是自身的resolve，所以触发then中指定的回调函数。 3.1.4 用法注意点 - then链的处理： [代码] var p1 = p2 = new Promise(function (resolve){ resolve(100); }); p1.then((value) => { return value*2; }).then((value) => { return value*2; }).then((value) => { console.log("p1的执行结果：",value) }) p2.then((value) => { return value*2; }) p2.then((value) => { return value*2; }) p2.then((value) => { console.log("p2的执行结果：",value) }) [代码] 运行结果是： p2的执行结果： 100 p1的执行结果： 400 说明： p2写法中的 then 调用几乎是在同时开始执行的，而且传给每个 then 方法的 value 值都是 100。而p1中写法则采用了方法链的方式将多个 then 方法调用串连在了一起，各函数也会严格按照 resolve → then → then → then 的顺序执行，并且传给每个 then 方法的 value 的值都是前一个promise对象通过 return 返回的值。 ###3.1.4 用法注意点 - catch的处理： [代码] var p1 = new Promise(function (resolve, reject){ reject("test"); //throw new Error("test"); 效果同reject("test"); //reject(new Error("test")); 效果同reject("test"); resolve("ok"); }); p1 .then(value => console.log("p1 then:", value)) .catch(error => console.log("p1 error:", error)); p2 = new Promise(function (resolve, reject){ resolve("ok"); reject("test"); }); p2 .then(value => console.log("p2 then:", value)) .catch(error => console.log("p2 error:", error)); [代码] 运行结果是： p2 then: ok p1 error: test 说明： Promise 的状态一旦改变，就永久保持该状态，不会再变了。不会即抛异常又会正常resolve。 3.2 async/await（ES7） 3.2.1 async基础用法： async 用于申明一个 function 是异步的，返回的是一个 Promise 对象。 [代码] async function testAsync() { return "hello async"; } var result = testAsync(); console.log("1:", result); testAsync().then(result => console.log("2:", result)); async function mytest() { //"hello async"; } var result1 = mytest(); console.log("3:", result1); [代码] 运行结果是： 1: Promise {<resolved>: “hello async”} 3: Promise {<resolved>: undefined} 2: hello async 说明： async返回的是一个Promise对象，可以用 then 来接收，如果没有返回值的情况下，它会返回 Promise.resolve(undefined)，所以在没有 await 的情况下执行 async 函数，它会立即执行，并不会阻塞后面的语句。这和普通返回 Promise 对象的函数并无二致。 3.2.2 await基础用法： await 只能出现在 async 函数中，用于等待一个异步方法执行完成（实际等的是一个返回值，强调 await 不仅仅用于等 Promise 对象，它可以等任意表达式的结果）。 [代码] function getMyInfo() { return Promise.resolve("hello 2019!"); } async function testAsync() { return "hello async"; } async function mytest() { return Promise.reject("hello async"); } async function test() { try { const v1 = await getMyInfo(); console.log("getV1"); const v2 = await testAsync(); console.log("getV2"); const v3 = await mytest(); console.log(v1, v2, v3); } catch (error) { console.log("error:", error); } } test(); [代码] 运行结果是： getV1 getV2 error: hello async 说明： await等到的如果是一个 Promise 对象，await 就忙起来了，它会阻塞后面的代码，等着 Promise 对象 resolve，然后得到 resolve 的值，作为 await 表达式的运算结果。 放心，这就是 await 必须用在 async 函数中的原因。async 函数调用不会造成阻塞，它内部所有的阻塞都被封装在一个 Promise 对象中异步执行。 3.2.3 async/await的优势： 很多情况下，执行下一步操作是需要依赖上一步的返回结果的，如果当嵌套层次较多的时候，（举例3层的时候）： [代码] const getRequest = () => { return promise1().then(result1 => { //do something return promise2(result1).then(result2 => { //do something return promise3(result1, result2) }) }) } [代码] 从上例可以看到嵌套内容太多。此时如果用async写法，可写成如下： [代码] const getRequest = async () => { const result1 = await promise1(); const result2 = await promise2(result1); return promise3(result1, result2); } [代码] 说明： async / await 使你的代码看起来像同步代码，它有效的消除then链，让你的代码更加简明，清晰。 总结：以上就是对JS的异步机制及相关应用的整体总结，如有需要欢迎交流～

本文主要是从代码方面跟大家分享我自己在开发小程序的一些做法，希望能帮到一些同学。 前言 不知道大家有没有这种体会，刚到公司时，领导要你维护之前别人写的代码，你看着别人写的代码陷入了深深的思考：“这谁写的代码，这么残忍” [图片] 俗话说“不怕自己写代码，就怕改别人的代码”，一言不和就改到你吐血，所以为了别人好，也为了自己好，代码规范，从我做起。 项目目录结构 在开发之前，首先要明确你要做什么，不要一上来就是干，咱们先把项目结构搭好。一般来说，开发工具初始化的项目基本可以满足需求，如果你的项目比较复杂又有一定的结构的话就要考虑分好目录结构了，我的做法如下图： [图片] component文件夹是放自定义组件的 pages放页面 public放公共资源如样式表和公共图标 units放各种公共api文件和封装的一些js文件 config.js是配置文件 这么分已经足以满足我的需求，你可以根据自己的项目灵活拆分。 配置文件 我的项目中有个config.js，这个文件是用来配置项目中要用到的一些接口和其它私有字段，我们知道在开发时通常会有测试环境和正式环境，而测试环境跟正式环境的域名可能会不一样，如果不做好配置的话直接写死接口那等到上线的时候一个个改会非常麻烦，所以做好配置是必需的，文件大致如下： [图片] 首先是定义域名，然后在config对象里定义接口名称，getAPI(key)是获取接口方法，最后通过module暴露出去就可以了.引用的时候只要在页面引入 import domain from ‘…/…/config’;，然后wx.request的时候url的获取方式是domain.getAPI(’’) 代码健壮性、容错性 例子 代码的健壮性、容错性也是我们应该要考虑的一点，移动端的项目不像pc端的网络那么稳定，很多时候网络一不稳定就决定我们的项目是否能正常运行，而一个好的项目就一定要有良好的容错性，就是说在网络异常或其它因素导致我们的项目不能运行时程序要有一个友好的反馈，下面是一个网络请求的例子： [图片] 相信多数人请求的方式是这样，包括我以前刚接触小程序的时候也是这样写，这样写不是说不好，而是不太严谨，如果能够正常获取数据那还好，但是一旦请求出现错误那程序可以到此就没法运行下去了，有些比较好的会加上faill失败回调，但也只是请求失败时的判断，在请求成功到获取数据的这段流程内其实是还有一些需要我们判断的，一般我的做法是这样： [图片] 在请求成功后小程序会进行如下判断： 判断是否返回200，是则进行一下步操作，否则抛出错误 判断数据结构是否完整，是则进行一下步操作，否则抛出错误 然后就可以在页面根据情况进行相应的操作了。 定制错误提示码 可以看到上面的截图的错误打印后面会带一个gde0或gde1的英文代码，这个代码是干嘛用的呢，其实是用来报障的，当我们的小程序上线后可能会遇到一些用户发来的报障，一般是通过截图发给我们，之前没有做错误提示码的时候可能只是根据一句错误提示来定位错误，但是很多时候误提示语都是一样的，我们根本不知道是哪里错了，这样一来就不能很快的定位的错误，所以加上这样一个提示码，到时用户一发截图来，我们只要根据这个错误码就能很快的定位错误并解决了，错误提示码建议命名如下： 不宜过长，3个字母左右 唯一性 意义明确 像上面gde表示获取草稿失败，后面加上数字表示是哪一步出错。 模块化 我们组内的大神说过， 模块化的意义在义分治，不在于复用。 之前我以为模块化只是为了可以复用，其实不然，无论模块多么小也是可以模块化，哪怕只是一个简单的样式也一样，并是不为了复用，而是管理起来方便。 很多同学经常将一些公共的样式事js放在app.wxss和app.js里以便调用，这样做其实有一个坏处，就是维护性比较差，如果是比较小的项目还好，项目一大问题就来了。而且项目是会迭代的，不可能总是一个人开发，可能后面会交接给其他人开发，所以会造成的问题就是： app.wxss和app.js里的内容只会越来越多，因为别人不确定哪些是没用的也不敢删，只能往里加东西，造成文件臃肿，不利于维护。 app.wxss和app.js对于每个页面都有效，可读性方面比较差。 所以模块化的意义就出来了，将公共的部分进行模块化统一管理，也便于维护。 样式模块化 公共样式根据上面的目录结构我是放在public里的css里，每个文件命名好说明是哪个部分的模块化，比如下面这个就表示一个按钮的模块化 [图片] 前面说过模块化不在于大小，就算只是一个简单的样式也可以进行模块化，只要在用到的地方import一下就行了，就知道哪里有用到，哪里没有用到，清晰明了。 js模块化 js模块化这里分为两个部分的模块化，一部分是公共js的模块化，另一部分是页面js的模块化即业务与数据的拆分。 公共js模块化 比较常用的公共js有微信登录，弹窗，请求等，一般我是放在units文件夹里，这里经微信弹窗api为例： [图片] 如图是在小程序中经常会用到的弹窗提示，这里进行封装，定义变量，只要在页面中引入就能直接调用了，不用每次都写一大串。比如在请求的时候是这样用的 [图片] toast()就是封装的弹窗api，这样看起来是不是清爽多了！ 业务与数据模块化 业务与数据模块化就是指业务和数据分开，互不影响，业务只负责业务，数据只负责数据，可以看到页面会比普通的页面多了一个api.js [图片] 这个文件主要就是用来获取数据的，而index.js主要用来处理数据，这样分工明确，相比以往获取数据和处理数据都在一个页面要好很多，而且我这里获取数据是返回一个promise对象的，也方便处理一些异步操作。 组件化 组件化相信大家都不陌生了，自从小程序支持自定义组件，可以说是大大地提高了开发效率，我们可以将一些公共的部分进行组件化，这部分就不详细介绍，大家可以去看文档。组件化对于我们的项目来说有很大的好处，而且组件化的可移植性强，从一个项目复用到另一个项目基本不需要做什么改动。 总结 这篇文章通过我自己的一些经验来给大家介绍如何优化自己的代码，主要有以下几点 分好项目目录结构 做好接口配置文件 代码健壮性、容错性的处理 定制错误提示码方便定位错误 样式模块化和js模块化 组件化 最后放上项目目录结构的代码片段，大家可以研究一下，有问题一起探讨：https://developers.weixin.qq.com/s/1uVHRDmT7j6l

一、前言 目前最流行的两大前端框架，React 和 Vue，都不约而同的借助 Virtual DOM 技术提高页面的渲染效率。那么，什么是 Virtual DOM ？它是通过什么方式去提升页面渲染效率的呢？本系列文章会详细讲解 Virtual DOM 的创建过程，并实现一个简单的 Diff 算法来更新页面。本文的内容脱离于任何的前端框架，只讲最纯粹的 Virtual DOM 。敲单词太累了，下文 Virtual DOM 一律用 VD 表示。 这是 VD 系列文章的第二篇，以下是本系列其它文章的传送门： 你不知道的Virtual DOM（一）：Virtual Dom介绍 本文将会实现一个简单的 VD Diff 算法，计算出差异并反映到真实的 DOM 上去。 二、思路 使用 VD 的框架，一般的设计思路都是页面等于页面状态的映射，即UI = render(state)。当需要更新页面的时候，无需关心 DOM 具体的变换方式，只需要改变state即可，剩下的事情（render）将由框架代劳。我们考虑最简单的情况，当 state 发生变化时，我们重新生成整个 VD ，触发比较的操作。上述过程分为以下四步： - state 变化，生成新的 VD - 比较 VD 与之前 VD 的异同 - 生成差异对象（patch） - 遍历差异对象并更新 DOM 差异对象的数据结构是下面这个样子，与每一个 VDOM 元素一一对应： [代码]{ type, vdom, props: [{ type, key, value }] children } [代码] 最外层的 type 对应的是 DOM 元素的变化类型，有 4 种：新建、删除、替换和更新。props 变化的 type 只有2种：更新和删除。枚举值如下： [代码]const nodePatchTypes = { CREATE: 'create node', REMOVE: 'remove node', REPLACE: 'replace node', UPDATE: 'update node' } const propPatchTypes = { REMOVE: 'remove prop', UPDATE: 'update prop' } [代码] 三、代码实现 我们做一个定时器，500 毫秒运行一次，每次对 state 加 1。页面的li元素的数量随着 state 而变。 [代码]let state = { num: 5 }; let timer; let preVDom; function render(element) { // 初始化的 VD const vdom = view(); preVDom = vdom; const dom = createElement(vdom); element.appendChild(dom); timer = setInterval(() => { state.num += 1; tick(element); }, 500); } function tick(element) { if (state.num > 20) { clearTimeout(timer); return; } const newVDom = view(); } function view() { return ( <div> Hello World <ul> { // 生成元素为0到n-1的数组 [...Array(state.num).keys()] .map( i => ( <li id={i} class={`li-${i}`}> 第{i * state.num} </li> )) } </ul> </div> ); } [代码] 接下来，通过对比 2 个 VD，生成差异对象。 [代码]function tick(element) { if (state.num > 20) { clearTimeout(timer); return; } const newVDom = view(); // 生成差异对象 const patchObj = diff(preVDom, newVDom); } function diff(oldVDom, newVDom) { // 新建 node if (oldVDom == undefined) { return { type: nodePatchTypes.CREATE, vdom: newVDom } } // 删除 node if (newVDom == undefined) { return { type: nodePatchTypes.REMOVE } } // 替换 node if ( typeof oldVDom !== typeof newVDom || ((typeof oldVDom === 'string' || typeof oldVDom === 'number') && oldVDom !== newVDom) || oldVDom.tag !== newVDom.tag ) { return { type: nodePatchTypes.REPLACE, vdom: newVDom } } // 更新 node if (oldVDom.tag) { // 比较 props 的变化 const propsDiff = diffProps(oldVDom, newVDom); // 比较 children 的变化 const childrenDiff = diffChildren(oldVDom, newVDom); // 如果 props 或者 children 有变化，才需要更新 if (propsDiff.length > 0 || childrenDiff.some( patchObj => (patchObj !== undefined) )) { return { type: nodePatchTypes.UPDATE, props: propsDiff, children: childrenDiff } } } } // 比较 props 的变化 function diffProps(oldVDom, newVDom) { const patches = []; const allProps = {...oldVDom.props, ...newVDom.props}; // 获取新旧所有属性名后，再逐一判断新旧属性值 Object.keys(allProps).forEach((key) => { const oldValue = oldVDom.props[key]; const newValue = newVDom.props[key]; // 删除属性 if (newValue == undefined) { patches.push({ type: propPatchTypes.REMOVE, key }); } // 更新属性 else if (oldValue == undefined || oldValue !== newValue) { patches.push({ type: propPatchTypes.UPDATE, key, value: newValue }); } } ) return patches; } // 比较 children 的变化 function diffChildren(oldVDom, newVDom) { const patches = []; // 获取子元素最大长度 const childLength = Math.max(oldVDom.children.length, newVDom.children.length); // 遍历并diff子元素 for (let i = 0; i < childLength; i++) { patches.push(diff(oldVDom.children[i], newVDom.children[i])); } return patches; } [代码] 计算得出的差异对象是这个样子的： [代码]{ type: "update node", props: [], children: [ null, { type: "update node", props: [], children: [ null, { type: "update node", props: [], children: [ null, { type: "replace node", vdom: 6 } ] } ] }, { type: "create node", vdom: { tag: "li", props: { id: 5, class: "li-5" }, children: ["第", 30] } } ] } [代码] 下一步就是遍历差异对象并更新 DOM 了： [代码]function tick(element) { if (state.num > 20) { clearTimeout(timer); return; } const newVDom = view(); // 生成差异对象 const patchObj = diff(preVDom, newVDom); preVDom = newVDom; // 给 DOM 打个补丁 patch(element, patchObj); } // 给 DOM 打个补丁 function patch(parent, patchObj, index=0) { if (!patchObj) { return; } // 新建元素 if (patchObj.type === nodePatchTypes.CREATE) { return parent.appendChild(createElement(patchObj.vdom)); } const element = parent.childNodes[index]; // 删除元素 if (patchObj.type === nodePatchTypes.REMOVE) { return parent.removeChild(element); } // 替换元素 if (patchObj.type === nodePatchTypes.REPLACE) { return parent.replaceChild(createElement(patchObj.vdom), element); } // 更新元素 if (patchObj.type === nodePatchTypes.UPDATE) { const {props, children} = patchObj; // 更新属性 patchProps(element, props); // 更新子元素 children.forEach( (patchObj, i) => { // 更新子元素时，需要将子元素的序号传入 patch(element, patchObj, i) }); } } // 更新属性 function patchProps(element, props) { if (!props) { return; } props.forEach( patchObj => { // 删除属性 if (patchObj.type === propPatchTypes.REMOVE) { element.removeAttribute(patchObj.key); } // 更新或新建属性 else if (patchObj.type === propPatchTypes.UPDATE) { element.setAttribute(patchObj.key, patchObj.value); } }) } [代码] 到此为止，整个更新的流程就执行完了。可以看到页面跟我们预期的一样，每 500 毫秒刷新一次，构造渲染树和绘制页面花的时间也非常少。 [图片] 作为对比，如果我们在生成新的 VD 后，不经过比较，而是直接重新渲染整个 DOM 的时候，会怎样呢？我们修改一下代码： [代码]function tick(element) { if (state.num > 20) { clearTimeout(timer); return; } const newVDom = view(); newDom = createElement(newVDom); element.replaceChild(newDom, dom); dom = newDom; /* // 生成差异对象 const patchObj = diff(preVDom, newVDom); preVDom = newVDom; // 给 DOM 打个补丁 patch(element, patchObj); */ } [代码] 效果如下： [图片] 可以看到，构造渲染树（Rendering）和绘制页面（Painting）的时间要多一些。但另一方面花在 JS 计算（Scripting）的时间要少一些，因为不需要比较节点的变化。如果算总时间的话，重新渲染整个 DOM 花费的时间反而更少，这是为什么呢？ 其实原因很简单，因为我们的 DOM 树太简单了！节点很少，使用到的 css 也很少，所以构造渲染树和绘制页面就花不了多少时间。VD 真正的效果还是要在真实的项目中才体现得出来。 四、总结 本文详细介绍如何实现一个简单的 VD Diff 算法，再根据计算出的差异去更新真实的 DOM 。然后对性能做了一个简单的分析，得出使用 VD 在减少渲染时间的同时增加了 JS 计算时间的结论。基于当前这个版本的代码还能做怎样的优化呢，请期待下一篇的内容：你不知道的Virtual DOM（三）：Virtual DOM 更新优化

前言 大家好，上次给大家讲了函数防抖和函数节流 https://developers.weixin.qq.com/community/develop/article/doc/000a645d8b8ba0d8722863ef45bc13 今天给大家分享一下利用canvas生成朋友圈分享海报 由于小程序的限制，我们不能很方便地在微信内直接分享小程序到朋友圈，所以普遍的做法是生成一张带有小程序分享码的分享海报，再将海报保存到手机相册，有两种方法可以生成分享海报，第一种是让后台生成然后返回图片链接，这一种方法比较简单，只需要传后台所需要的参数就行了，今天给大家介绍的是第二种方法，用canvas生成分享海报。 效果 [图片] 主要步骤 把海报样式用标签先写好，方便画图时可以比对 用canvas进行画图，canvas要注意定好宽高 canvas利用wx.canvasToTempFilePath这个api将canvas转化为图片 将转化好的图片链接放入image标签里 再利用wx.saveImageToPhotosAlbum保存图片 坑点 用canvas进行画图的时候要注意画出来的图的大小一定要是你用标签写好那个样式的两倍大小，比如你的海报大小是400600的大小，那你用canvas画的时候大小就要是8001200，宽高可以写在样式里，如果你画出来的图跟你海报图是一样的大小的话生成的图片是会很模糊的，所以才需要放大两倍。 画图的时候要注意尺寸的转化，如果你是用rpx做单位的话，就要对单位进行转化，因为canvas提供的方法都是经px为单位的，所以这一点要注意一下，px转rpx的公式是w/750z2，w是手机屏幕宽度screenWidth，可以通过wx.getSystemInfo获取，z是你需要画图的单位，2就是乘以两倍大小。 图片来源问题，因为canvas不支持网络图片画图，所以你的图片要么是固定的，如果不是固定的，那就要用wx.downloadFile下载后得到一个临时路径才行 小程序码问题，小程序需要后台请求接口后返回一个二进制的图片，因为二进制图片canvas也是不支持的，所以也是要用wx.downloadFile下载后得到一个临时路径，或者可以叫后台直接返回一个小程序码的路径给你 这里保存的时候是有个授权提醒的，如果拒绝的话再次点击就没有反应了，所以这里我做了一个判断是否有授权的，如果没有就弹窗提醒，确认的话会打开设置页面，确认授权后再次返回就行了，这里有个坑注意下，就是之前拒绝后再进入设置页面确认授权返回页面时保存图片会不成功，官方还没解决，我是加了个setTimeOut处理的，详情可以看这里 https://developers.weixin.qq.com/community/develop/doc/000c46600780f0fa68d7eac345a400 代码实现 [图片] 这里图片我先用的是网上的链接，实际项目中是后台返回的数据，这个可以自行处理，这里只是为了演示方便，生成临时路径的方法我这里是分别定义了一个方法，其实可以合成一个方法的，只是生成小程序码时如果要传入参数要注意一下。 绘图方法是drawImg，这里截一部分，详细的可以看代码片段 [图片] 不足 由于在实际项目中返回的图片宽高是不固定的，但是canvas画出来的又需要固定宽高，所以分享图会有图片变形的问题，使用drawImage里的参数也不能解决，如果各位有比较好的方案可以一起讨论一下。 代码片段 https://developers.weixin.qq.com/s/3pcsjDmS7M5Y