前端试题综合（二）

 谈谈你对Socket编程的理解及实现原理，Socket 之间是怎么通讯的

A、Socket定义

Socket是进程通讯的一种方式，即调用这个网络库的一些API函数实现分布在不同主机的相 关进程之间的数据交换。几个定义：IP地址：即依照TCP/IP协议分配给本地主机的网络地 址，两个进程要通讯，任一进程首先要知道通讯对方的位置，即对方的IP。端口号：用来辨 别本地通讯进程，一个本地的进程在通讯时均会占用一个端口号，不同的进程端口号不同， 因此在通讯前必须要分配一个没有被访问的端口号。连接：指两个进程间的通讯链路。

B、实现原理

在TCP/IP网络应用中，通信的两个进程间相互作用的主要模式是客户/服务器（Client/ Server, C/S)模式，即客户向服务器发出服务请求，服务器接收到请求后，提供相应的服务。客户/服务器模式的建立基于以下两点：首先，建立网络的起因是网络中软硬件资源、运算能力和信息不均等，需要共享，从而造就拥有众多资源的主机提供服务，资源较少的客 户请求服务这一非对等作用。其次，网间进程通信完全是异步的，相互通信的进程间既不存 在父子关系，又不共享内存缓冲区，因此需要一种机制为希望通信的进程间建立联系，为二 者的数据交换提供同步，这就是基于客户/服务器模式的TCP/IP。

C、通讯过程

服务器端：其过程是首先服务器方要先启动，并根据请求提供相应服务：（1)打开一通信 通道并告知本地主机，它愿意在某一公认地址上的某端□(如FTP的端口可能为21)接收客 户请求；（2)等待客户请求到达该端口； （3)接收到客户端的服务请求时，处理该请求并 发送应答信号。接收到并发服务请求，要激活一新进程来处理这个客户请求（如UNIX系统 中用fork、exec)。新进程处理此客户请求，并不需要对其它请求作出应答。服务完成后， 关闭此新进程与客户的通信链路，并终止。（4)返回第（2)步，等待另一客户请求。（5）关闭服务器客户端：（1)打开一通信通道，并连接到服务器所在主机的特定端口；(2)向服务器发服务请求报文，等待并接收应答；继续提出请求......（3)请求结束后关闭通信通道并终止。

从上面所描述过程可知：（1）客户与服务器进程的作用是非对称的，因 此代码不同。（2）服务器进程一般是先启动的。只要系统运行，该服务进程一直存在，直到正常或强迫终止。

详细参见：

https://www.zhihu.com/question/29637351

http://blog.csdn.net/panker2008/article/details/46502783?ref=myread

WEB应用从服务器主动推送Data到客户端有哪些方式？

 你们原来公司如何发送的新消息推送?

一般的服务器Push技术包括：

1)      基于AJAX的长轮询（long一polling)方式，服务器Hold—段时间后再返回信息；

2)     HTTP Streaming,通过iframe和〈script〉#签完成数据的传输；

3)     TCP长连接

4)     HTML5新引入的WebSocket，可以实现服务器主动发送数据至网页端，它和HTTP— 样，是一个基于HTTP的应用层协议，跑的是TCP，所以本质上还是个长连接，双向通信， 意味着服务器端和客户端可以同时发送并响应请求，而不再像HTTP的请求和响应。

5)     nodejs的http://socket.io，它是websocket的一^^开源实现，对不支持websocket的浏 览器降级成comet / ajax轮询，http://socket.io的良好封装使代码编写非常容易。

上述的 1 和2统称为comet技术。comet详细参考：http://www.ibm.com/developerworks/cn/ web/wa一lo一comet/

上述的1和2统称为comet技术，Comet：基于 HTTP 长连接的“服务器推”技术前些日子给项目网站加了后台通知的实时推送到前端显示，用的是nodejs的http://socket.io，它是websocket的一个开源实现，对不支持websocket的浏览器降级成comet / ajax 轮询，http://socket.io的良好封装使代码编写非常容易。

组件设计

 设计一个弹框组件，组件宽度为屏幕高度的50%， 宽度为屏幕宽度的80%，水平垂直居中。弹窗组件有 header, body, footer三部分，header中有标题，可定制，body区域，footer区域有确定和取消按钮，可定制两个按钮的文字内容，组件外的内容有遮罩，点击遮罩和取消按钮时关闭弹框，参照下图。（类似于layer的弹出层插件）

使用面向对象封装插件较为合适

构造函数的参数有header的标题及body内容和按钮文字内容

封装的方法应该有show, hide,在点击遮罩和取消按钮时调用hide方法

并且hide和show方法应该有返回值以供判断。

 实现一个手势滑动轮播图组件。效果参考：https://static.xiaohongchun.com/goods/4514 (请在手机里打开）

 详细参考：http://www.jb51.net/article/65177.htm

设计基于观察者模式的事件绑定机制

观察者模式（发布-订阅模式）的定义：Observer的意图是定义对象之间的一种一（被观察者）对多（观察者） 的关系，当一个对象的状态发生改变时，所有依赖它的对象得到通知，并且会自动更新自己

在JavaScript中，一般使用事件模型来替代传统的观察者模式。

好处：

（1）可广泛应用于异步编程中，是一种替代传递回调函数的方案。

（2）可取代对象之间硬编码的通知机制，一个对象不用再显示地调用另外一个对象的某个接口。两对象轻松解耦。

代码参考：http://blog.csdn.net/phker/article/details/6880371

http://www.cnblogs.com/LuckyWi nty/p/5796190.html

 jq自己扩展过什么插件？

弹出层插件、pagination插件、瀑布流插件、模态框插件等

参考：Jquery插件库    jquery之家

埋点

在需要埋点的组件上添加自定义属性，里面放上唯一的值。当用户点击时发送ajax。

或者
append(img)
img.src="blank.png?id=10010"

 侧滑菜单如何实现？

主要依靠两个大的容器来模拟侧滑菜单界面和主界面，把侧滑菜单放到页面右侧看不 到的地方，在操作的同时，使用css3过渡、动画或者jq来使两个容器相对运动，实现侧滑菜单效果

参考：http://www.111cn.net/wy/js一ajax/99687.htm

权限管理如何实现？

（1）前端控制：

　　前端的控制比较简单，从后台获取到用户的权限之后，可以存在session或者cookie中，然后在页面加载的时候，通过session或者cookie中存的权限来选择让该功能展现或者禁用。

前端实现代码详细参见：http://blog.csdn.net/liuweidagege/article/details/42497731

（2）后台控制：

　　仅仅依靠前端的控制是无法完美解决权限控制的问题，因为前端页面的加载过程是在浏览器中完成的，用户可以自行篡改页面；或者用户可以直接通过URI请求来获取非法权限功能。所以需要在后台实现权限控制。

　　后台的控制方法也很多，比如filter、spring的AOP等。在此选用springMVC的interceptor来控制。

（3）全局异常管理：

　　思路是在拦截器中权限校验失败时，抛出一个权限校验失败的异常，然后通过全局异常管理类来捕获并返回前端特定的格式。具体如下。

—个大数组，可能存了 100万个数字，要从其中取出 来第二大的数的下标，有什么快速的方法？

用两个变量max，max2，其中max储存最大值，max2储存第二大值；初始化的时候，将数组中的第一个元素中较大的存进max中，较小的存进max2中，然后从第三个元素(下标为2)的元素开始，如果遇到的数比max大，就让max2=max;max等于遇到的数一直循环，直到数组尾部，最后输出max2

请设计一套方案，用于确保页面中js加载完全，对于优化某网页的加载速度，有什么独到见解js方法：

<script type="text/javascript">

window.onload=function(){

var userName="xiaoming";

alert(userName);

}
</script>

jquery方法：

如何确定一个js是否加载完全或者页面中的所有js加载完全，具体办法如下：

如何让脚本的执行顺序按照你设定的顺序执行，使用嵌套的方式：

loadScript("file1.js", function() {

    loadScript("file2.js", function() {

        loadScript("file3.js", function() {

            alert("All files are loaded");

        });

    });

});

网页加载速度优化：

1、减少请求

最大的性能漏洞就是一个页面需要发起几十个网络请求来获取诸如样式表、脚本或者图片这样的资源，这个在相对低带宽和高延迟的移动设备连接上来说影响更严重。

CDNs（内容分发网络）把资源放在离用户地理位置更近的地方对解决这个问题能起到很大作用，但是比起获取请求，大量的请求对页面加载时间的影响更为严重，而且最近的发现表明，CDNs对移动端用户的性能影响越来越低。

2、整合资源

对开发者来说，将Javascript代码和CSS样式放到公共的文件中供多个页面共享是一种标准的优化方法，这个方法能很简单的维护代码，并且提高客户端缓存的使用效率。

在Javascript文件中，要确保在一个页面中相同的脚本不会被加载多次，当大团队或者多个团队合作开发的时候，这种冗余的脚本就很容易出现，你可能会对它的发生频率并不低感到非常吃惊。

Sprites是css中处理图片的一项技术，Sprites就是将多张图片整合到一个线性的网状的大图片中，页面就可以将这个大图片一次性获取回来并且做为css的背景图，然后使用css的背景定位属性展示页面需要的图片部分，这种技术将多个请求整合成一个，能显著地改善性能。

平稳地改进但是需要对资源有控制权限，根据开发者的网站不同权限，一些资源并不需要被整合起来（例如，一些由CMS生成的资源），还有，对于一些外部域引用的资源，强行整合可能会导致问题，马海祥提醒大家需要注意的是，整合资源对手机浏览器来说是一把双刃剑，整合资源确实会在首次访问减少请求，但是大的资源文件可能会导致缓存失效，所以，需要小心地使用各种技术整合资源，以达到优化本地存储的目的。

3、使用浏览器缓存和本地缓存

现在所有的浏览器都会使用本地资源去缓存住那些被Cache一Control或者Expires头标记的资源，这些头能标记资源需要缓存的时间，另外，ETag（实体标签）和Last一Modified头来标识当资源过期后是否需要重新请求，浏览器为了减少不必要的服务器请求，尽可能地从本地缓存中获取资源，并且将那些已经过期的、或者当缓存空间减小的时候将那些很久不用的资源进行清理，浏览器缓存通常包括图片，CSS，Javascript代码，这些缓存能合理地提高网站的性能（比如为了支持后退和前进的按钮，使用一个单独的缓存来保存整个渲染的页面）。

移动浏览器缓存，通常是比桌面PC小的多，这就导致了缓存的数据会很经常被清理，HTML5的缓存基于浏览器缓存提供了一个很好的替换方案，Javascript的localStorage已经在所有主流的桌面和移动端浏览器上都实现了，使用脚本代码能简便地支持HTML5的localStorage操作，可以读写键值数据，每个域名大概有5MB的容量，虽然不同的移动浏览器上读写速度相差很大，但是localStorage大容量的缓存使得它很适合作为客户端的缓存，从localStorage获取资源明显快于从服务器上获取资源，而且在大多数移动设备上也比依靠缓存头或者浏览器的本地缓存更灵活可靠，这是移动浏览器比桌面PC更有优势的一个地方，在桌面PC上，本地缓存仍然优先使用标准的浏览器缓存，导致桌面PC本地缓存的性能落后于移动浏览器。

在此，马海祥要提醒各位一下：虽然localStorage的机制易于实现，但是它的一些控制机制却是非常复杂的，你需要考虑到缓存带给你的所有问题，比如缓存失效（什么时候需要删除缓存？），缓存丢失（当你希望数据在缓存中的时候它并不在怎么办？），还有当缓存满的时候你怎么办？

4、首次使用的时候在HTML中嵌入资源

HTML的标准是使用链接来加载外部资源，这使得更容易在服务器上（或者在CDN上）操作更新这些资源，而不是在每个页面上修改更新这些资源，根据上文讨论的，这种模式也使得浏览器能从本地缓存而不是服务器上获取资源。

但是对还没有缓存到浏览器localStorage的资源来说，这种模式对网站的性能有负面的影响，一般来说，一个页面需要几十个单独的请求来获取资源从而渲染页面。

所以说，从性能的角度来说，如果一个资源没有很高的被缓存的几率的话，最好把它嵌入到页面的HTML中（叫inlining），而不是使用链接外部，脚本和样式是支持内嵌到HTML中的，但是图片和其他的二进制资源其实也是可以通过内嵌包含base64编码的文本来嵌入到HTML中的。

内嵌的缺点是页面的大小会变得非常大，所以对于Web应用来说，关键的是能够跟踪分析这个资源什么时候需要从服务端获取，什么时候已经缓存到客户端了。

另外，在第一次请求资源后必须能够使用代码在客户端缓存资源，因此，在移动设备上，使用HTML5 localStorage能很好地做到内嵌。

由于不知道用户是否已经访问过这个页面了，所以需要网站有机制能生成不同版本的页面。

5、使用HTML5服务端发送事件

Web应用已经使用了各种从服务器上轮询资源的方法来持续地更新页面，HTML5的EventSource对象和Server一Sent事件能通过浏览器端的JavaScript代码打开一个服务端连接客户端的单向通道，服务端可以使用这个写通道来发送数据，这样能节省了HTTP创建多个轮询请求的消耗。

这种方式比HTML的WebSocket更高效，WebSocket的使用场景是，当有许多客户端和服务端的交互的时候（比如消息或者游戏），在全双工连接上建立一个双向通道。

这个技术是基于具体的技术实现的，如果你的网站当前是使用其他的Ajax或者Comet技术来轮询的，转变成Server一Sent事件需要重构网站的Javascript代码。

6、消除重定向

当用户在一个移动设备上访问桌面PC网站的时候，Web网站应用通常读取HTTP的user一agent头来判断这个用户是否是来自移动设备的，然后应用会发送带有空HTTP body和重定向HTTP地址头的HTTP 301（或者302）请求，把用户重定向到网站的移动版本上去，但是这个额外的客户端和服务端的交互通常在移动网络上会消耗几百毫秒，因此，在原先的请求上传递移动的web页会比传递一个重定向的信息并让客户端再请求移动页面更快。

对于那些想要在移动设备上看桌面PC网站的用户来说，你可以在移动web页面上提供一个链接入口，这样也能同时表示你的网站是并不提倡这种行为的。

虽然这个技术在理论上是简单的，但是实际上并不易于实施，由于有些m.sites是宿主在其他地方的，所以许多网站会选择重定向到一个不同的服务器上，有的网站则是会在重定向请求的时候种植上Cookie告诉Web应用这个用户是在使用移动设备，这种方法可能对web应用来说更容易控制。

7、减少资源负载

关于移动端页面的大小问题，渲染小页面更快，获取小资源也更快，减小每个请求的大小通常不如减少页面请求个数那么显著地提高性能。

但是有些技术在性能方面，特别是在需要对带宽和处理器性能精打细算的移动设备环境下，仍然是能带来很大利益的。

8、压缩文本和图像

诸如gzip这样的压缩技术，依靠增加服务端压缩和浏览器解压的步骤，来减少资源的负载，但是，一般来说，这些操作都是被高度优化过了，而且测试表明，压缩对网站还是起到优化性能的作用的，那些基于文本的响应，包括HTML，XML，JSON（Javascript Object Notation），Javascript，和CSS可以减少大约70%的大小。

浏览器在Accept一Encoding请求头中申明它的解压缩技术，并且当它们接收到服务端返回的Content一Encoding响应头标示的时候，就会按照这个响应头自动做解压操作。

马海祥觉得这种方法的优点就是易于实现，如果设置正确的话，现在所有的Web服务器都支持压缩响应，但是，也有一些桌面PC的安全工具会将请求头中的Accept一Encoding头去掉，这样即使浏览器支持解压缩，用户也无法获取到压缩后的响应。

gzip：后端服务器对返回的文本内容进行压缩，浏览器接收后会自动解压编译，一般来说，gzip消耗服务器cpu，但可以减少流量

9、代码简化

简化通常是使用在脚本和样式文件中，删除一些不必要的字符，比如空格，换行符，或者注释等，不需要暴露给外部的命名就可以被缩短为一个或者两个字符，比如变量名，合适的简化资源通常在客户端不需要做任何其他的处理，并且平均减少20%的资源大小，内嵌在HTML中的脚本和样式文件也是可以精简的，有很多很好的库来做精简化的操作，这些库一般也同时会提供合并多个文件这样减少请求数的服务（具体可查看马海祥博客《手机网站制作的常用方法及优化技巧》的相关介绍）。

简化带来的好处并不局限于减少带宽和延迟，对于那些移动设备上缓存无法保存的过大资源来说，也是很有改善的，Gzip在这个方面并没有任何帮助，因为资源是在被解压后才被缓存起来的。

Google的Closure Compiler已经难以置信地完成了理解和简化Javascript的工作，但是CSS的简化则没有那么容易，因为对不同浏览器来说有不同的CSS技术能迷惑CSS简化工具，然后让CSS简化后无法正常工作，马海祥提醒大家必须要注意的是，已经有这样的案例了，即使只是删除了不必要的字符，简化工作也有可能破坏页面，所以当你应用简化技术之后，请做一下完整的功能测试工作。

10、调整图片大小

图片通常是占用了Web页面加载的大部分网络资源，也占用了页面缓存的主要空间，小屏幕的移动设备提供了通过调整图片大小来加速传输和渲染图片资源的机会，如果用户只是在小的移动浏览器窗口中看图片的话，高分辨率的图片就会浪费带宽、处理时间和缓存空间。

为了加速页面渲染速度和减少带宽及内存消耗，可以动态地调整图片大小或者将图片替换为移动设备专用的更小的版本，不要依靠浏览器来将高分辨率的图片转换成小尺寸的图片，这样会浪费带宽。

另外一个方法是先尽快加载一个低分辨率的图片来渲染页面，在onload或者用户已经开始和页面交互以后将这些低分辨率的图片替换成为高分辨率的图片。

特别应用在高度动态化的网站是有优势的。

11、使用HTML5和CSS 3.0来简化页面

HTML5包括了一些新的结构元素，例如header，nav，article和footer，使用这些语义化的元素比传统的使用div和span标签能使得页面更简单和更容易解析，一个简单的页面更小加载更快，并且简单的DOM（Document Object Model）代表着更快的JavaScript执行效率，新的标签能很快地应用在包括移动端的新浏览器版本上，并且HTML5设计让那些不支持它的浏览器能平稳过渡使用新标签。

HTML5的一些表单元素提供了许多新属性来完成原本需要javascript来完成的功能，例如，新的placeholder属性用于显示在用户输入进入输入框之前显示的介绍性文字，autofocus属性用于标示哪个输入框应当被自动定位。

也有一些新的输入框元素能不用依靠Javascript就可以完成一些通用的需求，这些新的输入框类型包括像e一mail，URL，数字，范围，日期和时间这样需要复杂的用户交互和输入验证的元素，在移动浏览器上，当需要输入文本的时候，弹出的键盘通常是由特定的输入框类型来做选择的，不支持指定的输入类型的浏览器就会只显示一个文本框。

另外，只要浏览器支持内建的层次，圆角，阴影，动画，过渡和其他的图片效果，CSS 3.0就能帮助你创建轻便简易的页面了，而这些图片效果原先是需要加载图片才能完成的，这样，这些新特性就能加速页面渲染了。

人工地做这些改动是非常复杂和耗时的，如果你使用CMS，它可以帮你生成许多你不需要控制的HTML和CSS（具体可查看马海祥博客《制作移动端手机网站过程中的SEO优化方法技巧》的相关介绍）。

12、延迟渲染”BELOW一THE一FOLD”内容

可以确定的是如果我们将不可见区域的内容延迟加载，那么页面就会更快地展现在用户面前，这个区域叫做“below the fold”，为了减少页面加载后需要重新访问的内容，可以将图片替换为正确的高宽所标记的<img>标签。

一些好的Javascript库可以用来处理这些below一the一fold 延迟加载的图像。

13、延迟读取和执行的脚本

在一些移动设备上，解析Javascript代码的速度能达到100毫秒每千字节，许多脚本的库直到页面被渲染以后都是不需要的加载的，下载和解析这些脚本可以很安全地被推迟到onload事件之后来做。

例如，一些需要用户交互的行为，比如托和拽，都不大可能在用户看到页面之前被调用，相同的逻辑也可以应用在脚本执行上面，尽量将脚本的执行延迟到onload事件之后，而不是在初始化页面中重要的可被用户看到的内容的时候执行。

这些延迟的脚本可能是你自己写的，更重要的是，也有可能是第三方的，对广告、社交媒体部件、或者分析的差劲的脚本优化会导致阻塞页面的渲染，会增加珍贵的加载时间，当然，你需要小心地评估诸如jquery这样为移动网站设计的大型脚本框架，特别当你仅仅只是使用这些框架中的一些对象的时候更要小心评估。

许多第三方的框架现在提供延迟加载的异步版本的API，开发者只需要将原先的逻辑转化到这个异步版本，一些JavaScript要做延迟加载会有些复杂，因为在onload之后执行这些脚本需要注意很多注意事项（例如，你有个脚本需要绑定到onload事件上，你需要做什么？如果你将脚本延迟到onload事件之后，就一定就会失去很多执行的时机）。

14、使用Ajax来增强进程

Ajax（Asynchronous JavaScript and XML）是一项使用XHR（XMLHttpRequest）对象来从Web服务器上获取数据的技术，它并不需要更新正在运行的页面，Ajax能更新页面上的某个部分而不需要重新构建整个页面，它通常用来提交用户的交互相应，但是也可以用来先加载页面的框架部分，然后当用户准备好浏览网页的时候再填充详细的内容。

尽管是这个名字，但是XMLHttpRequest并不强制要求你只能使用XML，你可以通过调用overrideMineType方法来制定“application/json”类型来使用json替换XML，使用JSON.parse会比使用原生的eval()函数快了几乎两倍，并且更为安全。

同时，切记Ajax的返回响应也会得益于那些应用在普通的返回响应的优化技术上面，确保对你的Ajax返回响应使用了缓存头，简化，gzip压缩，资源合并等技术。

由于这个技术是根据具体应用不同而不同的，所以很难量化，或许由于跨域问题，你需要使用XHR2，这个技术能使用外部域的资源，从而能进行跨域的XHR请求。

15、根据网络状况进行适配处理

由于使用更多带宽会使用更多移动网络的费用，所以只有能检测网络的类型才能使用针对特定网络的优化技术。

例如，预加载未来使用到的请求是非常聪明的做法，但是如果用户的带宽很稀有，并且加载的有些资源是永远不会用到的话，这个技术就是不合理的了。

在Android 2.2+，navigator.connection.type属性的返回值能让你区分Wifi和2G/3G/4G网络，在Blackberry上，blackberry.network也能提供相似的信息，另外，服务端通过检测请求中的User一Agent头或者其他的嵌入到请求中的信息能让你的应用检测到网络状况。

检测网络信息的API最近已经有所变化了，接口现在不是直接定义Wi一Fi，3G等网络状况，而是给出了带宽信息和诸如“非常慢，慢，快和非常快”这样的建议，有个属性能给出估计的MB/s值和一个“meterd”的Boolean值来表示它的可信度，但是对浏览器来说，很难根据这个来判断环境，判断当前网络环境然后适配仍然是一种最好的方法（具体可查看马海祥博客《百度移动搜索开放适配服务的3种方法》的相关介绍），但是这种方法正在被考虑被替换。

16、对多线程来说尽量使用HTML5的WEB WORKER特性

HTML5中的Web Worker是使用多个线程并发执行Javascript程序，另外，这种特别的多线程实现能减少困惑开发者多年的，在其他平台上遇到的问题，例如，当一个线程需要改变一个正在被其他线程使用的资源该如何处理，在Web Worker中，子线程不能修改主用户界面（UI）线程使用的资源。

对提高移动站点的性能来说，Web Worker中的代码很适合用来预处理用户完成进一步操作所需要的资源的，特别是在用户的带宽资源不紧缺的情况下，在低处理器性能的移动设备上，过多的预加载可能会干扰当前页面的UI响应，使用多线程代码，让Web Worker对象（并且尽可能使用localStorage来缓存数据）在另外一个线程中操作预加载资源，这样就能不影响当前的UI表现了。

要特别说明的是，Web Worker只在Android 2.0以上的版本实现，而且iphone上的ios5之前的版本也不支持，在桌面PC上，总是落后的IE只在IE 10才支持Web Worker。

虽然这项技术并不是非常难实现，但是对Web Workers来说，有一些限制需要强制遵守，Web Workers不能进入到页面的DOM，也不能改变页面上的任何东西，Web Worker很适合那种需要后台计算和处理的工作。

17、将CLICK事件替换成TOUCH事件

在触摸屏设备上，当一个用户触碰屏幕的时候，onclick事件并没有立即触发，设备会使用大约半秒（大多数设备差不多都是300毫秒）来让用户确定是手势操作还是点击操作，这个延迟会很明显地影响用户期望的响应性能，要使用touchend事件来替换才能解决，当用户触碰屏幕的时候，这个事件会立即触发。

为了要确保不会产生用户不期望的行为，你应该也要使用touchstart和touchmove事件，例如，除非同时有个touchstart事件在button上，否则不要判断touchend事件在button上就意味着点击行为，因为用户有可能从其他地方触碰开始，然后拖拽到button上触碰结束的，你也可以在touchstart事件之后使用touchmove事件来避免将touchend事件误判为点击，当然前提是需要假设拖拽的手势并不是预期产生点击行为。

另外，你也需要去处理onclick事件来让浏览器改变button的外观从而标识为已点击的状态，同时你也需要处理那些不支持touch事件的浏览器，为了避免代码在touchend和onclick代码中重复执行，你需要在确保用户触碰事件已经在touchend执行了之后，在click事件中调用preventDefault和stopPropagation方法。

这种技术需要更多工作才能在一个页面中增加和维护链接，touch事件的代码必须考虑其他手势，因为替换click的还有可能是缩放或者敲击动作。

18、支持SPDY协议

应用层HTTP和HTTPS协议导致的一些性能瓶颈，使得不论是桌面还是移动端的网站都非常难受，在2009年，谷歌开始研发一种叫做SPDY（谐意是“speedy”）的协议来替换已有的协议，这种协议宣称能突破这些限制，这个协议的目标是让多种浏览器和多种Web服务都能支持，所以这个协议是开源的，但是初步地，只有Google的Chrome浏览器（在版本10及之后的）和google的站点支持，一旦一个Web服务支持SPDY，那么它上面的所有站点都可以和支持这个协议的浏览器使用SPDY进行交互，将SPDY应用在25个top100的Internet网站上，Google收集到的数据是网站的速度会改善27%到60%不等。

SPDY自动使用gzip压缩所有内容，和HTTP不同的是，它连header的数据也使用gzip压缩，SPDY使用多线程技术让多个请求流或者响应流能共用一个TCP连接，另外SPDY允许请求设置优先级，比如，页面中心的视频会比边框的广告拥有更高的优先级。

或许SPDY中最变革性的发明就是流是双向的，并且可以由客户端或者服务端发起，这样能使得信息能推送到客户端，而不用由客户端发起第一次请求，例如，当一个用户第一次浏览一个站点，还没有任何站点的缓存，这个时候服务端就可以在响应中推送所有的请求资源，而不用等候每个资源被再次独立请求了，作为替换协议，服务端可以发送暗示给客户端，提示页面需要哪些资源，同时也允许由客户端来初始化请求。即使是使用后一种这样的方式也比让客户端解析页面然后自己发现有哪些资源需要被请求来得快。

虽然SPDY并没有对移动端有什么特别的设置，但是移动端有限的带宽就使得如果支持SPDY的话，SPDY在减少移动网站的延迟是非常有用的。

依据网站和服务的环境来进行平稳操作或进一步考虑，Google有一个SPDY模块支持Apache2.2 – mod_spdy – 这个模块是免费的；但是mod_spy有线程上的问题，并且和mod_php协作并不是很好，所以要求你使用这个技术的时候要确保你的网站的正常运行。

浏览器输入url到整个页面显示出来经历的过程

在用户输入一段url后，浏览器会首先查看浏览器缓存中是否有对应的地址，若没有则到本地dns（hosts）中寻找，再找不着则将地址发送至dns解析器上，查找到对应的ip后进行数据请求。

三次握手，服务端接收到数据后判断请求地址，类型，判断是否跨域等一些问题，若没有问题，则进行数据处理，以java mvc为例，请求通过拦截器，进入到controler，controler调用service（业务处理），service调用dao（mapper）层进行数据库查询，将结果返回给请求的客户端。

客户端获得数据，四次挥手，判断返回数据的类型（MIME类型），如：text/html，浏览器进行解析，渲染引擎得到html字符串作为输入，然后对html进行转换（js引擎，渲染引擎），转化成能够被DOM处理的形式，接着转换成一个dom树，在解析html的过程，解析到<link>,<script>,<img>等一些请求标签时，会发送请求把对应的内容获取到。这时又会同步进行css的解析，构建出css样式规则应用到dom树上，然后进行一定的布局处理，比如标记节点块在浏览器中的坐标等形成最终的渲染树，最后根据这棵渲染树在浏览器窗口中进行绘制。

详见：https://www.cnblogs.com/lichenghan/p/4019370.html

常见的api形式

restful API形式
http://xxxx.com/user/regist/abc/123
传统的传参形式
http://xxxx.com/regist?user_name=abc&psw=123

防止加密算法中加密后的串重复？

加密后与数据库中的数据对比，若有重复则加上随机数在进行加密

单元测试

 单个组件怎么测试性能

React组件测试框架用mocha,测试库用官方的测试工具库，也可使用第三方库Enzyme,建议使用第三方的。

详细参见：http://www.ruanyifeng.com/blog/2016/02/react一testing一tutorial.html

Vue使用Unit和e2e测试工具：

详细参见：http://www.tuicool.com/articles/6vulNvR

 综合问题

 请列举你知道的前端框架？常用的前端开发工具？ 开发过哪些应用和组件？

(1)   前端框架

bootstrap/jQuery/zepto/backbone/AngularJS/vue.js/React/

React Native/小程序

(2)   前端开发工具 gulp/webpack/git/svn/npm/linux

    架构工具 ：bower、npm、yeoman、gulp、webpack

(3)   应用和组件

根据自己做的项目对答

支付功能

从后端获取必要的数据然后调用js接口就OK了。以下是微信支付（jssdk）所需的参数

timestamp: 0, // 支付签名时间戳，注意微信jssdk中的所有使用timestamp字段均为小写。但最新版的支付后台生成签名使用的timeStamp字段名需大写其中的S字符
nonceStr: '', // 支付签名随机串，不长于 32 位
package: '', // 统一支付接口返回的prepay_id参数值，提交格式如：prepay_id=***）
signType: '', // 签名方式，默认为'SHA1'，使用新版支付需传入'MD5'
paySign: '', // 支付签名

项目上线流程

前提条件购买一台服务器
阿里云ECS

windows server 2008

在服务器上开通FTP协议。

使用工具(winscp)连上服务器之后上传build之后的代码。

 项目测试没问题。但是放到线上就有问题了，你是怎么分析解决的？

可能的原因：

(1)   后端原因：后端接口，后端服务器

(2)   域名、IP和路径问题

(3)   网络环境问题

(4)   线上库、框架、工具的版本和本地不一致问题

(5)   线上和本地数据资源不一致问题

(6)   程序bug

 

四、 如何管理团队？

(1)   区分技术和管理角色在意识上的差异

(2)   时间管理

(3)   同时管理自己和其他人的代码

(4)   赢得团队的尊敬

详细参见：http://www.t262.com/read/187780.html

五、 你做过的你负责的最难的数据交互模块是?

根据自己做的项目对答。

六、 你平时写过什么业务逻辑？

根据自己做的项目对答。

七、 在项目开发过程中你负责的具体是什么模块？

根据自己做的项目对答。

八、 如果需要你加班，你会加吗，抵触吗？

其实你肯定抵触，但你肯定要回答如果项目需要肯定会加

九、 一个小项目让你自己负责搭建底层一些架构，你能胜任吗？

例：我肯定愿意尝试，并做到最优的选择方案出来

十、 如果项目拖太久，你情绪低落或者厌烦了怎么调节？

例：你结合自身挑着好听的说就行，就像聊天

十一、   你建议自己造轮子，还是利用开源的轮子？

例：根据实际情况而定，如果开源完全满足 可以自己二次开发就好，大大缩短开发周期如果实在没有契合度很高的，可以花费几个工作日尝试造轮。