前端试题综合（二）

 谈谈你对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方法：

View Code

如何肯定一个js是否加载彻底或者页面中的全部js加载彻底，具体办法以下：

View Code

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

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

    loadScript("file2.js", function() { loadScript("file3.js", function() { alert("All files are loaded"); }); }); });

网页加载速度优化：

一、减小请求

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

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

二、整合资源

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

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

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

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

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

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

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

在此，马海祥要提醒各位一下：虽然localStorage的机制易于实现，可是它的一些控制机制倒是很是复杂的，你须要考虑到缓存带给你的全部问题，好比缓存失效（何时须要删除缓存？），缓存丢失（当你但愿数据在缓存中的时候它并不在怎么办？），还有当缓存满的时候你怎么办？

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

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

可是对尚未缓存到浏览器localStorage的资源来讲，这种模式对网站的性能有负面的影响，通常来讲，一个页面须要几十个单独的请求来获取资源从而渲染页面。

因此说，从性能的角度来讲，若是一个资源没有很高的被缓存的概率的话，最好把它嵌入到页面的HTML中（叫inlining），而不是使用连接外部，脚本和样式是支持内嵌到HTML中的，可是图片和其余的二进制资源其实也是能够经过内嵌包含base64编码的文原本嵌入到HTML中的。

内嵌的缺点是页面的大小会变得很是大，因此对于Web应用来讲，关键的是可以跟踪分析这个资源何时须要从服务端获取，何时已经缓存到客户端了。

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

因为不知道用户是否已经访问过这个页面了，因此须要网站有机制能生成不一样版本的页面。

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

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

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

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

六、消除重定向

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

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

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

七、减小资源负载

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

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

八、压缩文本和图像

诸如gzip这样的压缩技术，依靠增长服务端压缩和浏览器解压的步骤，来减小资源的负载，可是，通常来讲，这些操做都是被高度优化过了，并且测试代表，压缩对网站仍是起到优化性能的做用的，那些基于文本的响应，包括HTML，XML，JSON（Javascript Object Notation），Javascript，和CSS能够减小大约70%的大小。

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

马海祥以为这种方法的优势就是易于实现，若是设置正确的话，如今全部的Web服务器都支持压缩响应，可是，也有一些桌面PC的安全工具会将请求头中的Accept一Encoding头去掉，这样即便浏览器支持解压缩，用户也没法获取到压缩后的响应。

gzip：后端服务器对返回的文本内容进行压缩，浏览器接收后会自动解压编译，通常来讲，gzip消耗服务器cpu，但能够减小流量

九、代码简化

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

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

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

十、调整图片大小

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

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

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

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

十一、使用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优化方法技巧》的相关介绍）。

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

能够肯定的是若是咱们将不可见区域的内容延迟加载，那么页面就会更快地展示在用户面前，这个区域叫作“below the fold”，为了减小页面加载后须要从新访问的内容，能够将图片替换为正确的高宽所标记的<img>标签。

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

1三、延迟读取和执行的脚本

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

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

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

许多第三方的框架如今提供延迟加载的异步版本的API，开发者只须要将原先的逻辑转化到这个异步版本，一些JavaScript要作延迟加载会有些复杂，由于在onload以后执行这些脚本须要注意不少注意事项（例如，你有个脚本须要绑定到onload事件上，你须要作什么？若是你将脚本延迟到onload事件以后，就必定就会失去不少执行的时机）。

1四、使用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请求。

1五、根据网络情况进行适配处理

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

例如，预加载将来使用到的请求是很是聪明的作法，可是若是用户的带宽很稀有，而且加载的有些资源是永远不会用到的话，这个技术就是不合理的了。

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

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

1六、对多线程来讲尽可能使用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很适合那种须要后台计算和处理的工做。

1七、将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的还有多是缩放或者敲击动做。

1八、支持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

 

4、 如何管理团队？

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

(2)   时间管理

(3)   同时管理本身和其余人的代码

(4)   赢得团队的尊敬

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

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

根据本身作的项目对答。

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

根据本身作的项目对答。

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

根据本身作的项目对答。

8、 若是须要你加班，你会加吗，抵触吗？

其实你确定抵触，但你确定要回答若是项目须要确定会加

9、 一个小项目让你本身负责搭建底层一些架构，你能胜任吗？

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

10、 若是项目拖过久，你情绪低落或者厌烦了怎么调节？

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

11、   你建议本身造轮子，仍是利用开源的轮子？

例：根据实际状况而定，若是开源彻底知足 能够本身二次开发就好，大大缩短开发周期若是实在没有契合度很高的，能够花费几个工做日尝试造轮。