- #算解决了吧#小米6手机微信小程序播放阿里云CDN加速视频中间卡住问题
- 当前 Bug 的表现(可附上截图) 小米6播放(video组件)阿里云CDN视频卡住 [图片] - 预期表现 正常播放 - 复现路径 小米6手机,打开二更视频,点一个超过5分钟的视频,播放。加载一段播放完就会卡住。 从nginx请求日志来看,小米6和其它手机播放的数据请求不太一样 华为机子播放视频nginx请求日志 [图片] 第一次是httpcode = 200,应该是tcp连接超时了断连了,后面的视频会以range,一段一段请求。 小米6播放视频nginx请求日志 [图片] 小米6上就一条请求记录,和播放器上播放完播放器也就卡住了吻合。 求助阿里云CDN工程师,小米6视频播放抓了个包 [图片] TCP知识不太懂现查的。我的理解是服务端断开连接了,客户端没有正常处理连接断开,还在发送本地window有空余可以继续写入数据。后面也没有继续发起range请求视频数据。然后播放器就卡住了。 这个断开连接的时间感觉有点短,而且好像数据还有在读写突然就断开了。 和阿里云CDN工程师沟通了两天,最后 [图片] 写客户端超时时间改成300秒后,我们的视频基本是6分钟内的,测试播放正常了。因为300秒超时远大于一块数据缓冲后的可播放时长,播放器会继续请求后面的数据。 虽然CDN调整了这个写客户端超时时间,但是觉得播放器数据请求处理上有点问题。同样30秒超时机制下,其它机型上播放是没问题的。 又了解到只是针对我们视频域名做了超时时间调整,遇到相同问题的同学临时解决方案可以去阿里云提工单。
2019-03-14 - 前端XSS攻击
一、前言 随着互联网的高速发展,信息安全问题已经成为企业最为关注的焦点之一,而前端又是引发企业安全问题的高危据点。在移动互联网时代,前端人员除了传统的 XSS、CSRF 等安全问题之外,又时常遭遇网络劫持、非法调用 Hybrid API 等新型安全问题。当然,浏览器自身也在不断在进化和发展,不断引入 CSP、Same-Site Cookies 等新技术来增强安全性,但是仍存在很多潜在的威胁,这需要前端技术人员不断进行“查漏补缺”。 二、XSS定义 在给大家介绍xss前,大家先来看一个例子: [代码]<html> <title>Welcome!</title> Hi <script> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length)); </script> Welcome to you </html> [代码] 这个例子是个欢迎页面,name是截取URL中get过来的name参数 正常操作: http://域名A/welcome.html?name=Joe 非正常操作: http://域名A/welcome.html?name=<script>alert(document.cookie)</script> 当执行非正常操作时: [图片] 完了,我们的cookie数据被截取了,XSS攻击出现了。 为什么会这样呢?我们来看一下: 1、受害者的浏览器接收到这个非正常操作的链接,发送HTTP请求到域名A并且接受到上面的HTML页; 2、受害者的浏览器开始解析这个HTML为DOM,DOM包含一个对象叫document,document里面有个URL属性,这个属性里填充着当前页面的URL; 3、当解析器到达javascript代码,它会执行它并且修改你的HTML页面。倘若代码中引用了document.URL,那么,这部分字符串将会在解析时嵌入到HTML中,然后立即解析,同时,javascript代码会找到(alert(…))并且在同一个页面执行它,这就产生了xss。 那么什么是XSS呢? xss跨站脚本攻击(Cross Site Scripting),指攻击者在网页中嵌入脚本代码(例如js代码), 当用户浏览此网页时,脚本就会在用户的浏览器上执行,从而达到攻击者的目的。比如获取用户的Cookie,导航到恶意网站,携带木马等。 大部分的xss漏洞都是由于没有处理好用户的输入,导致攻击脚本在浏览器中执行,这就是跨站脚本漏洞的根源。 三、XSS攻击类型 XSS攻击分为存储型、反射型和 DOM 型三种。 1、存储型 XSS a: 攻击者将恶意代码提交到目标网站的数据库中。 b: 用户打开目标网站时,网站服务端将恶意代码从数据库取出,拼接在 HTML 中返给浏览器。 c: 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。 d: 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。 简单例子: 表单中填写数据: [代码]<input type=“text” name=“content” value=“这里是用户填写的数据”> [代码] 正常操作: 1、用户是提交相应留言信息; 2、将数据存储到数据库; 3、其他模块要显示保存的数据,从数据库查询出来并显示。 非正常操作: 1、攻击者在value填写<script>alert(‘foolish!’)</script>【或者html其他标签(破坏样式。。。)、一段攻击型代码】; 2、将数据存储到数据库中; 3、其他用户取出数据显示的时候,将会执行这些攻击性代码 这种攻击常见于带有用户保存数据的网站功能,如论坛发帖、商品评论、用户私信等。 2、反射型 XSS a: 攻击者构造出特殊的 URL,其中包含恶意代码。 b: 用户打开带有恶意代码的 URL 时,网站服务端将恶意代码从 URL 中取出,拼接在 HTML 中返回给浏览器。 c: 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行。 d: 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作。 简单例子: 正常发送消息: http://域名A/message.html?message=Hello,World! 接收者将会接收信息并显示Hello,Word 非正常发送消息: http://域名A/message.html?message=<script>alert(document.cookie)</script> 接收者接收消息显示的时候将会弹出警cookie信息 反射型 XSS 跟存储型 XSS 的区别是:存储型 XSS 的恶意代码存在数据库里,反射型 XSS 的恶意代码存在 URL 里。 反射型 XSS 漏洞常见于通过 URL 传递参数的功能,如网站搜索、跳转等。由于需要用户主动打开恶意的 URL 才能生效,攻击者往往会结合多种手段诱导用户点击。POST 的内容也可以触发反射型 XSS,只不过其触发条件比较苛刻(需要构造表单提交页面,并引导用户点击),所以非常少见。 3、DOM 型 XSS a: 攻击者构造出特殊的 URL,其中包含恶意代码。 b: 用户打开带有恶意代码的 URL。 c: 用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行。 d: 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网 站接口执行攻击者指定的操作。 简单例子: [代码]<script> document.body.innerHTML="<div style=visibility:visible;><h1>This is DOM XSS</h1></div>"; </script> [代码] 攻击者可以利用innerHTML来篡改页面 DOM 型 XSS 跟前两种 XSS 的区别:DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞。 四、如何预防XSS攻击 1、输入过滤,对用户提交的数据进行有效性验证,仅接受指定长度范围内并符合我们期望格式的的内容提交,阻止或者忽略除此外的其他任何数据。比如:电话号码必须是数字和中划线组成,而且要设定长度上限。过滤一些些常见的敏感字符,例如:< > ‘ “ & # \ javascript expression “onclick=” “onfocus”;过滤或移除特殊的Html标签, 例如: <script>, <iframe> , < for <, > for >, " for;过滤JavaScript 事件的标签,例如 “onclick=”, “onfocus” 等等。 例子1: [代码]<input v-model="value" type="text" /> [代码] Input输入值带有html标签时,如value=”<b>aaaaaaaa</b>”,调接口提交到后台的没有做HtmlEncode转码,那么面页输出的将会是: aaaaaaaa粗体。原理是因为提交的内容里带有html标签<b></b>。浏览器解析页面源码时把用户提交的内容当成了html代码。所以才会输出粗体的 aaaaaaaa。 解决方案: A:前端提交前转码:encodeHtml(value); B:后端java转码:Encoder.encodeHtml(value);如果是Param类,直接使用.getHtmlString(key)。 例子2: 提交的数据url编码,数据提交时一定要对传参数的数进行URLencode处理,假如提交内容 aaaa&344353中文啊&&&&aaa=bbbb&&&fsdfsdsdf,如果没有通过 URLencode处理的话,那么提交的链接自然是http://www.baidu.com/?val=aaaa&344353中文啊&&&&aaa=bbbb&&&fsdfsdsdf 这样后台取得的val的值会是aaaa。并且还会有一个aaa=bbbb。主要造成这现象的原因是提交的内容包含了"&“和”=",没有对这些特殊的字符做转义处理,所以造成了后台取参错误。 解决方案: A:前端提交参数前:encodeUrl(url); B:后端拿到数据进行编码:Encoder.encodeURL(url); 其他例子解决方案: A:对输入的数据限制长度范围; [代码]<input v-model="value" maxlength="20" type="text" /> [代码] B:对输入的数据进行校验(正则表达式) [代码]var re = /^[a-zA-z]\w{3,15}$/; If(re.test(value)){ return true; }else{ return false; } [代码] 2、输出编码,当需要将一个字符串输出到Web网页时,同时又不确定这个字符串中是否包括XSS特殊字符(如< > &‘”等),为了确保输出内容的完整性和正确性,可以使用编码(HTMLEncode)进行处理。 例子1: 输出js数据时,要先编码,否则有可能因为"等造成截断。如var a = ‘<%=aString %>’;假如aString的值是"aa’;alert();’"。没有encodeJs的页面就会执行alert了。而有encodeJs的页面则会把输出内容里的单引号都替换成:\x22,双引号替换成\x27。这样就不会造成js里的引号截断了。 解决方案: A:前端JS函数:$.toJSON(html); B:后端java函数:Encoder.encodeJson(html);如果是Param类,直接使用.getJsonString(key)。 例子2: <a href=”url”>跳转链接</a> java处理代码时获取url参数并且不做任何处理,直接在html标签的事件中植入攻击代码。 当用户访问的链接是xxx/sigup.jsp?url=");alert(document.cookie)😭"; 点击跳转链接按钮的时候,就会弹出cookie的信息 解决方案: A:前端把href换成onclick方法: Html: [代码]<a onclick=”openUrl(url)”>跳转链接</a> [代码] Js: [代码]Function openUrl(url) { url = encodeUrl(url); Window.location.href = url; } [代码] B:后台调用方法: Encoder.encodeURL(value2); 如果是Param类,直接使用.getUrlString(key)。 其他案例: A:把字符串转换为写在html标签中属性值: 字符串是输出在html标签中的属性里,所以首先要防止字符串里的引号造成属性的引号截断。所以至少字符串里的引号就要转义了。当然,还有额外的一些特殊字符也是要转义的。 解决方案: js函数:encodeHtmlAttr(html); java函数 :Encoder.encodeHtmlAttr(html);如果是Param类,直接使用getHtmlAttrString; 如果是输出在js里初始化的话,尽量使用jquery的attr/val等函数来赋值( encode json 数据 ),降低复杂度。 B: input-text用例 :<s>a&aa</s>'b"c 在页面中直接初始化时,要使用:<input value="<%=Encoder.encodeHtml(str)%>"/> 在JS中初始化时,要使用:$("#xxx").val("<%=Encoder.encode.Json(str)%>"); C: textarea用例 : <textarea><s>a&aa</s>'b"c</textarea>bbb,不在页面中直接初始化textarea。 在JS中初始化:$("#xxx").val("<%=Encoder.encodeJson(str)%>") 3、DOM型的XSS攻击防御,把变量输出到页面时要做好相关的编码转义工作,如要输出到 <script>中,可以进行JS编码;要输出到HTML内容或属性,则进行HTML编码处理。根据不同的语境采用不同的编码处理方式。 例子: 当用户访问路径为xxx/pr.jsp?keywordCond=aaa");alert(document.cookie)😭"时候,直接scripts.append输出:scripts.append(keywordCond),就会弹出cookie的信息。 解决方案: A:在append前,将keywordCond进行编码 [代码]keywordCond = encodeUrlComponent(keywordCond); scripts.append(keywordCond) [代码] B:后台调用方法: [代码]String keywordCond = Encoder.encodeHtmlJs(keywordCond); [代码] 1、将重要的cookie标记为http only, 这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段,但是在脚本中却不能访问这个cookie,这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie。 例子: A:Tomcat服务器,在Tomcat下的conf的web.xml设置如下信息。 [代码]<session-config> <cookie-config> <http-only>true</http-only> </cookie-config> <session-config> [代码] B:resin服务器,在resin.conf下设置session信息。 [代码]<session-config> <enable-cookies>true</enable-cookies> <cookie-config> <http-only>true</http-only> </cookie-config> </session-config> [代码] 五、总结 XSS的攻击五花八门,毕竟那么多情况场景,开发人员无法一一照顾过来,我们前端和后端尽可能对提交数据做好过滤。开发人员要注意在正确的地方使用正确的编码方式,有时为了防御XSS,在一个地方我们需要联合HTMLEncode、JavaScriptEncode、URLEncode进行编码,甚至是叠加,并不是固定一种方式编码,具体情况具体分析。 针对XSS攻击类型,我们日常开发需要做好以下部分: 1.在HTML标签、属性中输出时,用HTMLEncode。 2.在script标签中输出时,用JavaScriptEncode。 3.在地址中输出一般如果变量是整个URL,则用URLEncode。 4.在提交数据前,做一些正则校验,或者在输入框中做一些限制。 六、参考资料 1、http://it.faisco.cn/page/forum/articleDetail.jsp?articleId=1656 2、http://web.jobbole.com/95312
2019-06-10 - js异步编程
前言 我们都知道,JS是单线程执行的,天生异步。在开发的过程中会遇到很多异步的场景,只用回调来处理简单的异步逻辑,当然是可以,但是逻辑逐渐复杂起来,回调的处理方式显得力不从心。 接下来会介绍js中处理异步的方式,通过对比了解各自的原理以及优缺点,帮助我们更好的使用这些强大的异步处理方式。 回调 基本用法 回调函数作为参数传进方法中,在合适的时机被调用。 比如调用ajax,或是使用定时器: [代码] // ajax请求 $.ajax({ url: '/ajax/hdportal_h.jsp?cmd=xxx', error: function(err) { console.log(err) }, success: function(data) { console.log(data) } }) // 定时器的回调 setTimeout(function callback() { console.log('hi') }, 1000) [代码] 回调的问题 1. 回调地狱 过深的嵌套,形成回调地狱 使得代码难以阅读和调试 层层嵌套,代码间耦合严重,牵一发而动全身 2.信任缺失,错误处理无法保证 控制反转,回调函数的调用是在请求函数内部,无法保证回调函数一定会被正确调用,回调本身没有错误处理机制,需要额外设计。 可能存在以下问题: 调用回调过早 调用回调过晚 调用回调次数太多或者太少 未能把所需的参数成功传给你的回调函数 吞掉可能出现的错误或异常 Promise 基本用法 Promise对象的状态不受外界影响。Promise对象代表一个异步操作,有三种状态:pending(进行中)、fulfilled(已成功)和rejected(已失败) 一旦状态改变,就不会再变,任何时候都可以得到这个结果。Promise对象的状态改变,只有两种可能:从pending变为fulfilled和从pending变为rejected。 [代码] new Promise((resovle, reject) => { setTimeout(() => { resovle('hello promise') }, 1000) }).then(res => { console.log(res) }).catch(err => { console.log(err) }) [代码] Promise与回调的区别 Promise 不是对回调的替代。 Promise 在回调代码和将要执行这个任务的异步代码之间提供了一种可靠的中间机制来管理回调 Promise 并没有完全摆脱回调。它们只是改变了传递回调的位置。我们并不是把回调传递给处理函数,而是从处理函数得到Promise,然后把回调传给这个Promise Promise 保证了行为的一致性,使其变得可信任,我们传递的回调会被正确的执行 Promise如何解决信任缺失问题? 调用时机上,不会调用过早,也不会调用过晚 根据PromiseA+规范,then中的回调会在 then 方法被调用的那一轮事件循环之后的新执行栈中执行。 这个事件队列可以采用“宏任务(macro-task)”机制或者“微任务(micro-task)”机制来实现。 所以提供给then的回调也总会在JavaScript事件队列的当前运行完成后,再被调用,即异步调用。 [代码] var p = Promise.resolve('p'); console.log('A'); p.then(function () { p.then(function () { console.log('E'); }); console.log('C'); }) .then(function () { console.log('D'); }); console.log('B'); [代码] 运行这段代码,会依次打印出ABCED 这里要注意两个点: 会先执行同步代码,再执行then中的代码 then执行回调时,打印D的代码晚于打印E的代码 调用次数上,不会出现回调未调用,也不会出现调用次数太多或者太少 一个Promise注册了一个成功回调和拒绝回调,那么Promise在决议的时候总会调用其中一个。 即使是在决议后调用then注册的回调函数,也会被正确调用,所以不会出现回调未调用的情况。 Promise只能被决议一次。如果处于多种原因,Promise创建代码试图调用多次resolve(…)或reject(…),或者试图两者都调用,那么这个Promise将只会接受第一次决议,忽略任何后续调用,所以调用次数不会太多也不会太少。 错误处理上,不会吞掉可能出现的错误或异常 如果在Promise的创建过程中或在查看其决议结果的过程中的任何时间点上,出现了一个JavaScript异常错误,比如一个TypeError或ReferenceError,这个异常都会被捕捉,并且会使这个Promise被拒绝。 [代码] var p = new Promise(function (resolve, reject) { foo.bar(); // foo未定义 resolve(2); }); p.then(function (data) { console.log(data); // 永远也不会到达这里 }, function (err) { console.log('出错了', err); // err将会是一个TypeError异常对象来自foo.bar()这一行 }); [代码] Promise中的then then方法的设计是promise中最重要的部分之一,可以看promise/A+规范中对then方法的描述 then方法会返回一个新的promise,因此可以链式调用,下面的代码会打印出6 [代码] var p = Promise.resolve(0); p.then(function (data) { return 1; }).then(function (data) { return data + 2; }).then(function (data) { return data + 3; }).then(function (data) { console.log(data); }); [代码] 如果在then中主动返回一个promise,依旧会返回一个新的promise,只是这个promise的状态“跟随”主动返回的pormise [代码] var p1 = new Promise(function (resolve, reject) { resolve('p1'); }); var p2 = new Promise(function (resolve, reject) { resolve('p2'); }); var p3 = p2.then(function (data) { return p1; }); console.log(p3 === p1); // false p3.then(function (data) { console.log(data); // p1 }); [代码] 静态方法 Promise.resolve() Promise.resolve(value)方法返回一个以给定值解析后的 Promise 对象。 但如果这个值是个 thenable(即带有 then 方法),返回的 promise 会“跟随”这个 thenable的对象,采用它的最终状态;否则以该值为成功状态返回 promise 对象。 Promise.reject() Promise.reject(reason)方法返回一个用reason拒绝的Promise。 [代码] // 以下两个 promise 是等价的 var p1 = new Promise( (resolve,reject) => { resolve( "Oops" ); }); var p2 = Promise.resolve( "Oops" ); var p1 = new Promise( (resolve,reject) => { reject( "Oops" ); }); var p2 = Promise.reject( "Oops" ); [代码] Promise.all() Promise.all方法用于将多个 Promise 实例,包装成一个新的 Promise 实例 [代码] const p = Promise.all([p1, p2, p3]); p.then(function (posts) { // ... }).catch(function(reason){ // ... }); [代码] p的状态由p1、p2、p3决定,分成两种情况。 (1)只有p1、p2、p3的状态都变成fulfilled,p的状态才会变成fulfilled,此时p1、p2、p3的返回值组成一个数组,传递给p的回调函数。 (2)只要p1、p2、p3之中有一个被rejected,p的状态就变成rejected,此时第一个被reject的实例的返回值,会传递给p的回调函数。 Promise.race() Promise.race方法同样是将多个 Promise 实例,包装成一个新的 Promise 实例。 [代码] const p = Promise.race([p1, p2, p3]); p.then(function (posts) { // ... }).catch(function(reason){ // ... }); [代码] 只要p1、p2、p3之中有一个实例率先改变状态,p的状态就跟着改变。那个率先改变的 Promise 实例的返回值,就传递给p的回调函数 Generator 名词解释 迭代器 (Iterator) 迭代器是一种对象,它具有一些专门为迭代过程设计的专有接口,所有迭代器对象都有一个 next 方法,每次调用都返回一个结果对象。 结果对象有两个属性,一个是 value,表示下一个将要返回的值;另一个是 done,它是一个布尔类型的值,当没有更多可返回数据时返回 true。 迭代器还会保存一个内部指针,用来指向当前集合中值的位置,每调用一次 next() 方法,都会返回下一个可用的值。 可迭代对象 (Iterable) 可迭代对象具有 Symbol.iterator 属性,是一种与迭代器密切相关的对象。 Symbol.iterator 通过指定的函数可以返回一个作用于附属对象的迭代器。 在 ECMCScript 6 中,所有的集合对象(数组、Set、及 Map 集合)和字符串都是可迭代对象,这些对象中都有默认的迭代器。 生成器 (Generator) 生成器是一种返回迭代器的函数,通过 function 关键字后的 * 号来表示。 此外,由于生成器会默认为 Symbol.iterator 属性赋值,因此所有通过生成器创建的迭代器都是可迭代对象。 for-of 循环 for-of 循环每执行一次都会调用可迭代对象的迭代器接口的 next() 方法,并将迭代器返回的结果对象的 value 属性储存在一个变量中,循环将持续执行这一过程直到返回对象的属性值为 true。 生成器的一般使用形式 [代码] function *foo() { var x = yield 2 var y = x * (yield x + 1) console.log( x, y ) return x + y } var it = foo() it.next() // {value: 2, done: false} it.next(3) // {value: 4, done: false} it.next(3) // 3 9, {value: 12, done: true} [代码] 遍历器对象的next方法的运行逻辑如下: (1)遇到yield表达式,就暂停执行后面的操作,并将紧跟在yield后面的那个表达式的值,作为返回的对象的value属性值。 (2)下一次调用next方法时,再继续往下执行,直到遇到下一个yield表达式。 (3)如果没有再遇到新的yield表达式,就一直运行到函数结束,直到return语句为止,并将return语句后面的表达式的值,作为返回的对象的value属性值。 (4)如果该函数没有return语句,则返回的对象的value属性值为undefined。 需要注意的是,yield表达式后面的表达式,只有当调用next方法、内部指针指向该语句时才会执行,因此等于为 JavaScript 提供了手动的“惰性求值”(Lazy Evaluation)的语法功能。 异步迭代生成器 [代码] function foo() { setTimeout(() => { it.next('success') // 恢复*main() // it.throw('error') // 向*main()抛出一个错误 }, 2000); } function *main() { try { var data = yield foo() console.log(data) } catch(e) { console.log(e) } } var it = main() it.next() // 这里启动! [代码] 本例中我们在 *main() 中发起 foo() 请求,之后暂停;又在 foo() 中相应数据恢复 *mian() 继续运行,并将 foo() 的运行结果通过 next() 传递出来。 我们在生成器内部有了看似完全同步的代码(除了 yield 关键字本身),但隐藏在背后的是,在 foo(…)内的运行可以完全异步。并且在异步代码中实现看似同步的错误处理(通过try…catch)在可读性和合理性方面也都是一个巨大的进步。 Generator + Promise 通过promise来管理异步流程 [代码] function foo() { return new Promise(function(resolve, reject){ setTimeout(() => { resolve('fai'); }, 2000); }); } function *main() { try { var data = yield foo() console.log(data) } catch(e) { console.error(e) } } var it = main(); var p = it.next().value; // p 的值是 foo() // 等待 promise p 决议 p.then( function(data) { it.next(data); // 将 data 赋值给 yield }, function(err) { it.throw(err); } ) [代码] *mian() 中执行 foo() 发起请求,返回promise 根据promise 决议结果,根据结果选择继续运行迭代器或抛出错误 如何执行有多处yield的Generator 函数? [代码] function foo(name) { return new Promise(function(resolve, reject){ setTimeout(() => { resolve('hello ' + name); }, 2000); }); } var gen = function* (){ var r1 = yield foo('jarvis'); var r2 = yield foo('hth'); console.log(r1); console.log(r2); }; var g = gen(); // 手动执行 g.next().value.then(function(data){ g.next(data).value.then(function(data){ g.next(data); }); }); [代码] 手动执行的方式,其实就是用then方法,层层添加回调函数。理解了这一点,就可以写出一个自动执行器 自动执行Generator 函数 [代码] function foo(name) { return new Promise(function(resolve, reject){ setTimeout(() => { resolve('hello ' + name); }, 2000); }); } var gen = function* (){ var r1 = yield foo('jarvis'); var r2 = yield foo('hth'); console.log(r1); console.log(r2); }; function run(gen){ var g = gen(); function next(data){ var result = g.next(data); if (result.done) return result.value; result.value.then(function(data){ next(data); }); } next(); } run(gen); [代码] 只要保证yield后面总是返回promise,就能用run函数自动执行Generator 函数 Async/Await async 函数的一般使用形式 async 函数是什么? 其实就是 promise+自动执行的Generator 函数的语法糖。类似于我们上面的实现 [代码] function foo(p) { return fetch('http://my.data?p=' + p) } async function main(p) { try { var data = await foo(p) return data } catch(e) { console.error(e) } } main(1).then(data => console.log(data)) [代码] 与 Generator 函数不同是,* 变成了async、yeild变成了await,同时我们也不用再定义 run(…) 函数来实现 Promise 与 Generator 的结合。 async 函数执行的时候,一旦遇到 await 就会先返回,等到异步操作完成,再接着执行函数体内后面的语句,并且最终返回一个 Promise 对象。 正常情况下,await 命令后面是一个 Promise 对象。如果不是,会被转成一个立即 resolve 的 Promise 对象。 await 命令后面的 Promise 对象如果变为 reject 状态,则 reject 的参数会被 catch 方法的回调函数接收到。 async 函数的使用注意点 前面已经说过,await 命令后面的 Promise 对象,运行结果可能是 rejected,所以最好把 await 命令放在 try…catch 代码块中。 多个 await 命令后面的异步操作,如果不存在继发关系,最好让它们同时触发。 await 命令只能用在 async 函数之中,如果用在普通函数,就会报错。 [代码] //getFoo 与 getBar 是两个互相独立、互不依赖的异步操作 // 错误写法 let foo = await getFoo(); let bar = await getBar(); // 正确写法一 let [foo, bar] = await Promise.all([getFoo(), getBar()]); // 正确写法二 let fooPromise = getFoo(); let barPromise = getBar(); let foo = await fooPromise; let bar = await barPromise; [代码] async 函数比Promise好在哪? 类同步写法,使得在写复杂逻辑时,可以用一种顺序的方式来书写,大大降低了理解的难度。 错误处理上,可以用try catch来捕获,同时处理同步和异步错误。 总结 JavaScript异步编程的发展历程有以下四个阶段: 回调函数: 有两个问题,回调地狱和信任缺失,回调地狱的坏处主要是代码阅读性和可维护性差,同时不好对异步逻辑进行封装。信任缺失主要体现在调用的时机,调用的次数,对异常的处理上缺乏一致性。 Promise 基于PromiseA+规范的实现解决了控制反转带来的信任问题。 Generator 使用生成器函数Generator,我们得以用同步的方式来书写异步的代码,解决了顺序性的问题,这是一种重大的突破。但是使用比较繁琐,需要手动去调用next(…)去控制流程和传参。 Async/Await Async/Await结合了Promise和Generator,并实现了自动执行生成器函数逻辑。使得使用者通添加少量关键字就可以用同步的方式书写异步代码,大大提高了开发效率和代码可维护性。 可以看到,目前Async/Await方式可以说是处理异步的终极解决方案,在项目中应该优先使用这种方式。
2019-06-11 - 从源码看微信小程序启动过程
一、写作背景 接触小程序一年多,真实体验就是小程序开发门槛相对而言确实比较低。不过小程序的开发方式,一直是开发者吐槽的,如习惯了 Vue,React 开发的开发者经常会吐槽小程序一个 Page 必须由多个文件组成,组件化支持不完善或者说不能非常愉快的开发组件。在以前小项目中没太大感觉,从加入有赞,参与有赞微商城小程序的开发,是真切的体会到对于大型小程序项目开发的复杂性。 有赞从微信小程序内测就开始开发小程序,在不支持自定义组件的时代,只能通过 import 的形式拆分模块或实现组件。在业务复杂的页面,可能会 import 非常多的模块,而相应的 wxss 也需要 import 样式,除了操作繁琐,有时候也难免遗漏。 作为开发者,我们当然希望可以让工作更简单,更愉快,也希望改善我们的开发方式。所以希望能够更了解微信小程序框架,减少不必要的试错,于是有了一次对小程序框架的 debug 之旅。(基础库 1.9.93) 通过三周空余时间的 debug,也算对小程序框架有了一些浅显的认识,达到了最初的目的;对小程序启动,实例,运行等有了真切的体会。这篇文章记录了小程序框架的基本代码结构,启动流程,以及程序实例化过程。 本文的目的是希望把我看到的分享给对小程序感兴趣或者正在开发小程序的读者,主要解答“框架对传入的对象等到底做了什么”。 二、从启动流程一窥小程序框架细节 在开发者工具中使用 help() 方法,可以查看一些指令和方法。使用其中的 openVendor 方法可以打开微信开发者工具在小程序框架所在目录。其中以包括以基础库命名的目录和其他帮助文件,如其中有两个工具 wcc,wcsc。wcc 可把 wxml 转换为对应的 JS 函数 —— $gwx(path, global),wcsc 可将 wxss 转换为 css。而基础库目录包括 WAService.js 和 WAWebview.js 文件。小程序框架在开发者工具中以 WAService.js 命名(WAWebview.js 不知其作用,听说在真机环境使用该文件)。 在开发中工具命令行使用 document.head 可以查看到小程序的启动流程大致如下: [图片] 以小节的方式分别介绍这些流程,小程序是如何处理的(小节编号与图中编号相同)。 1、初始化全局变量 下图是小程序启动是初始化的一些全局的变量: [图片] 那些使用“__”开头,未在文档中提及可使用变量是不建议使用的,wxAppCode 在开发者工具中分为两类值,json 类型和 wxml 类型。以 .json 结尾的,其 key 值为开发者代码中对应的 json 文件的内容,.wxml 结尾的,其 key 值为通过调用 $gwx(’./pages/example/index.wxml’) 将得到一个可执行函数,通过调用这个函数可得到一个标识节点关系的 JSON 树。 [图片] 2、加载框架(WAService.js) 使用工具对 WAService.js 进行格式化后进行 debug。可以发现小程序框架大致由: WeixinJSBridge、 NativeBuffer、 wxConsole、 WeixinWorker、 JavaScript兼容(这部分为猜测)、 Reporter、 wx、 exparser、 virtualDOM、 appServiceEngine 几部分组成。 其中除了 wx 和 WeixinJSBridge 这两个基础 API 集合, exparser, virtualDOM, appServiceEngine 这三部分作为框架的核心, appServiceEngine 提供了框架最基本的接口如 App,Page,Component; exparser 提供了框架底层的能力,如实例化组件,数据变化监听,view 层与逻辑层的交互等;而 virtualDOM 则起着链接 appServiceEngine 和 exparser 的作用,如对开发者传入 Page 方法的对象进行格式化再传入 exparser 的对应方法处理。 框架对外暴露了以下API:Behavior,App,Page,Component,getApp,getCurrentPages,definePlugin,requirePlugin,wx。 3、业务代码的加载 在小程序中,开发者的 JavaScript 代码会被打包为 [代码]define('xxx.js', function(require, module, exports, window, document, frames, self, location, navigator, localStorage, history, Caches, screen, alert, confirm, prompt, fetch, XMLHttpRequest, WebSocket, webkit, WeixinJSCore, Reporter, print, WeixinJSBridge) { 'use strict'; // your code }) [代码] 这里的 define 是在框架中定义的方法,在框架中提供了两个方法:require 和 define 用来定义和使用业务代码。其方式有些像 AMD 规范接口,通过 define 定义一个模块,使用 require 来应用一个模块。但是也有很大区别,首先 define 限制了模块可使用的其他模块,如 window,document;其次 require 在使用模块时只会传入 require 和 module,也就是说参数中的其他模块在定义的模块中都是 undefined,这也是不能在开发者工具中获取一些浏览器环境对象的原因。 在小程序中,JavaScript 代码的加载方式和在浏览器中也有些不同,其加载顺序是首先加载项目中其他 js 文件(非注册程序和注册页面的 js 文件),其次是注册程序的 app.js,然后是自定义组件 js 文件,最后才是注册页面的 js 代码。而且小程序对于在 app.js 以及注册页面的 js 代码都会加载完成后立即使用 require 方法执行模块中的程序。其他的代码则需要在程序中使用 require 方法才会被执行。 下面详细介绍了 app.js,自定义组件,页面 js 代码的处理流程。 4、加载 app.js 与注册程序 在 app.js 加载完成后,小程序会使用 require(‘app.js’) 注册程序,即对 App 方法进行调用,App 方法是对 appServiceEngine.App 方法的引用。 下图是框架对于 App 方法调用时的处理流程: [图片] App 方法根据传入的对象实例化一个 app 实例,其生命周期函数 onLaunch 和 onShow 因为使用不同的方式获取 options的参数。在有些需要根据场景值来实现需求的,或许使用 onShow 中的场景值更合适。 在实际开发过程中发现,在微信顶部唤起小程序和在小程序列表唤起的 options 也是不一样的。在该案例中通过点击分享的小程序进入后,关闭小程序,再通过不同方式进入小程序,通过顶部唤起的还是 options 的 path 属性还是分享出来的 path,但是通过列表中打开直接回到了首页,这里 App 中的 onShow 就会获取到不同的 options。 5、加载自定义组件代码以及注册自定义组件 自定义组件在 app.js 之后被加载,小程序会在这个过程中加载完所有的自定义组件(分包中自定义组件没有有测试过),并且是加载完成后自动注册,只有注册完成后才会加载下一个自定义组件的代码。 下图是框架对于 Component 方法处理流程: [图片] 图中介绍了框架如何对传入 Component 方法的对象的处理,其后面还有很多深入的对于组件实例化的步骤没有在图中表示出来,具体可以在文章最后的附件中查看。 自定义组件在小程序中越来越完善,其拥有的能力也比 Page 更强大,而后面会提到在使用自定义组件的 Page 中,Page 实例也会使用和自定义组件一样的实例化方式,也就是说,他拥有和自定义组件一样的能力。 6、加载页面代码和注册页面 加载页面代码的处理流程和加载自定义组件一样,都是加载完成后先注册页面,然后才会加载下一个页面。 下图是注册一个页面时框架对于 Page 方法的处理流程: [图片] Page 方法会根据是否使用自定义组件做不同的处理。使用自定义组件的 page 对象会被处理为和自定义组件的结构,并在页面实例化时使用不同的处理流程进行实例化。当然对于开发而言没任何不同。 从图中可以发现 Page 传入的(生命周期)代码并不会在这里被执行,可以通过下面小节了解 Page 实例化的详细过程。 7、等待页面 Ready 和 Page 实例化 还记得上面介绍的启动流程中最后一步等待页面 Ready?严格来讲是等待浏览器 Ready,小程序虽然有部分原生的组件,不过本质上还是一个 web 程序。 在小程序中切换页面或打开页面时会触发 onAppRoute 事件,小程序框架通过 wx.onAppRoute 注册页面切换的处理程序,在所有程序就绪后,以 entryPagePath 作为入口使用 appLaunch 的方式进入页面。 下图是处理导航的程序流程: [图片] 从图中可以看出页面的实例化是在进入页面时进行,下图是具体的实例化过程: [图片] 下图是最终可得到 Page 实例: [图片] 可以发现其中多了 onRouteEnd API,实际该接口不会被调用。其中以 component 标记的表示只有在使用了自定义组件时才会有的方法和属性。在前面第 5 小节提到了对于使用自定义组件的页面会按照自定义组件方式解析,这些属性和方法与自定义组件表现一致。 8、关于 setData 小程序框架是一个以数据驱动的框架,当然不能少了对他如何实现数据绑定的探索,下图是 Page 实例的 setData 执行流程: [图片] 其中 component:setData 表示使用自定义组件的 Page 实例的 setData 方法。 三、写在最后 这是一次不完全的小程序框架探索,是在微信开发工具中 debug 的结果。虽然对于实际开发没有什么太大的帮助,但是对框架如何对开发的 js 代码进行处理有了一个很明确的认识,在使用一些 js 特性时可以有明确的感知。如果你还疑惑“小程序框架对传入的对象等到底做了什么”那一定是我表达能力太差,说声对不起。 通过这一次 debug ,也给我引入了新的问题,还希望能够有更多的讨论: · 自定义组件太多启动时会耗时处理自定义组件 · 文件太多会耗时读文件 · 合理的设计分包很重要 当然最后对于框架中已有的能力,还是非常希望微信可以开放更多稳定的接口,并在文档中告知开发者,让开发变得简单一些。
2019-03-05