爱奇艺2020
(1) 求递归方程T(n)=4T(n/2)+n 的解 ( )
解析：
题目中的fn符合第一种情况，所以答案是：
(2) 已知图G的邻接表如下图所示，则从V1点出发进行广度优先遍历的序列为（ ）
解析：
- 广度优先遍历：涉及到队列这种数据结构。把相邻的都先加入队列，再按顺序将其他节点的相邻节点加入队列。
- v1进队列：
- 访问v1,v1出队列，v1邻接点v2、v5、v4进入队列：
- 然后按访问v2,v2出队列，v2的邻接点v3进队列。（v5已经在队列中，不用再进）
- 然后访问v5, v5出队列，v5的邻节点v6进队列（v4、v3已经在队列中）
- …
- 最后的结果： v1,v2,v5,v4,v3,v6
(3) 以下哪个不是队列的应用（ ）
A: 图的广度优先搜索
B: 设置打印数据缓冲区
C: 树的层次遍历
D: 中缀表达式转后缀表达式
解析：
只有最后一项是栈的应用。
(4) 一组N个站点共享一个30Kbps的纯ALOHA信道， 每个站点平均每100s输出一个2000bit的帧。试求出N的最大值（ ）
解析：
ALOHA信道的最高利用率为：18.4%
N = （30kbps * 18.4%）/ 20bps = 276
(5) HTML5 API如何支持链接预加载（）
A: rel="preload"
B: rel="prefetch"
C: rel="dns-prefetch"
D: rel="dns-preload"
解析：
B、D都是预加载。
- prefetch: 让浏览器预先加载用户访问当前页后极有可能访问的其他资源(页面，图片，视频等)。
- dns-prefetch: 是域名预加载。
(6) 关于结点树相同的折半判定树和完全二叉树，以下说法正确的是（ ）
A：折半判定树的高度与完全二叉树高度一致
B：折半判定树的高度比完全二叉树高度大
C：折半判定树的高度比完全二叉树高度小
D：折半判定树的高度与完全二叉树高度没有关系
折半判定树和完全二叉树都为平衡二叉树，节点数又相同，高度肯定相同。
折半判定树如何生成： 折半查找判定树
京东 (2019)
(1) 模式串的长度是m，主串的长度是n（m<n），使用KMP算法匹配的时间复杂度是（）？
解析：
以S=“abcabaaaabaaacac”,P="abaabcac"为例，用动图模拟朴素算法与KMP算法：
- 朴素算法：
- 改进的KMP算法：
- 改进的KMP算法：
- 朴素算法： 每次失配，S串的索引i定位的本次尝试匹配的第一个字符的后一个。P串的索引j定位到1；T(n)=O(n*m)
- KMP算法： 每次失配，S串的索引i不动，P串的索引j定位到某个数。T(n)=O(n+m)，时间效率明显提高。
(2) Web Workers 线程的描述错误的是：
A：var worker = new Worker('worker.js');创建一个 Worker 对象
B：向一个 Worker 发送消息则使用：worker.postMessage(message)
C：接收一个 Worker 的消息使用：worker.onmessage=function(event){};
D：Web Workers 线程不可以进行嵌套
解析：
Web workers 线程可以嵌套。
参考文章：Web Worker
(3) 下列哪项不是websocket的特性
A: 和http协议不同
B：客户端采用长轮询的方式向服务端发起请求
C：仍然需要至少一次客户端服务端握手
D: websocket客户端基于事件的编程模型与node类似
- WebSocket 是基于 TCP 的协议，WebSocket 只需要服务端和客户端一次握手，就可以自由进行数据传送和接收，
- 允许服务端主动发送数据，不需要使用轮询的方式。
- WebSocket 客户端基于事件的编程模型与 node 类似
(7) 关于iframe的说法错误的是（）
A：iframe是用来在网页中插入第三方页面，早期的页面使用iframe主要是用于导航栏这种很多页面都相同的部分，这样在切换页面的时候避免重复下载
B：iframe的创建比一般的DOM元素慢了1-2个数量级
C：iframe标签会阻塞页面的的加载
D：iframe本质是动态语言的Incude机制和利用ajax动态填充内容
解析：
iframe的特点：
-
创建比一般的 DOM 元素慢了 1-2 个数量级
-
阻塞页面加载
及时触发 window 的 onload 事件是非常重要的。onload 事件触发使浏览器的 “忙” 指示器停止，告诉用户当前网页已经加载完毕。当 onload 事件加载延迟后，它给用户的感觉就是这个网页非常慢。
window 的 onload 事件需要在所有 iframe 加载完毕后（包含里面的元素）才会触发。在 Safari 和 Chrome 里，通过 JavaScript 动态设置 iframe 的 SRC 可以避免这种阻塞情况
-
唯一的连接池
浏览器只能开少量的连接到 web 服务器。比较老的浏览器，包含 Internet Explorer 6 & 7 和 Firefox 2，只能对一个域名（hostname）同时打开两个连接。这个数量的限制在新版本的浏览器中有所提高。Safari 3+ 和 Opera 9+ 可同时对一个域名打开 4 个连接，Chrome 1+, IE 8 以及 Firefox 3 可以同时打开 6 个
绝大部分浏览器，主页面和其中的 iframe 是共享这些连接的。这意味着 iframe 在加载资源时可能用光了所有的可用连接，从而阻塞了主页面资源的加载。如果 iframe 中的内容比主页面的内容更重要，这当然是很好的。但通常情况下，iframe 里的内容是没有主页面的内容重要的。这时 iframe 中用光了可用的连接就是不值得的了。一种解决办法是，在主页面上重要的元素加载完毕后，再动态设置 iframe 的 SRC。
-
不利于 SEO
搜索引擎的检索程序无法解读 iframe。另外，iframe 本身不是动态语言，样式和脚本都需要额外导入。 综上，iframe 应谨慎使用。
