zoukankan      html  css  js  c++  java
  • 【答阿里寒冬面试题】呵呵,大神的面试题就是好!

    前言

    今天微博看到了寒冬大神的面试题,觉得挺有意思的,这里就做一点解答

    谈谈你对CSS布局的理解

    讲讲输入完网址按下回车,到看到网页这个过程中发生了什么。

    谈谈你对Web前端组件化的理解,Web Component会带来怎样的影响

    谈谈你对前端资源下载性能优化的经验和思考

    现在有很多的MV*框架,你对它们有什么看法

    iOS体验好在哪里,Web能赶上么?

    网页游戏怎么做?

    Hybrid技术应当如何应用?

    你最爱的前端框架是什么,为什么?

    首先老师的题目都很大,不好答,我这里技术有缺陷,答得不好大家不要喷我,可以好好教育我嘛

    浅谈CSS布局

    概述

    从网页表现来看,HTML是实体本身,要实现各种优雅的布局的需要依赖CSS
    HTML元素两大类型为块级元素与行内元素,网页的布局一般由块级元素组织,元素不同便有不一样的表现
    要实现布局就要用到与布局有关的CSS属性为position,常用属性为static、absoulute、fixed、relative
    position的作用是改变元素的状态,由文档流转为相对文档流或者脱离文档流元素(定位元素)
    当然float也能引发块级元素脱离文档流,但是其表现与原理与上面不一致,而且要慎用float布局
    于是这里便已经有三种“流”了,不同的布局元素会处于不同的“执行环境”,在“执行环境”中才能方便的对其进行管理
    这个管理的依据便是BFC(块级作用域上下文),根据我粗浅的理解是,BFC也就是浏览器提供的一块渲染区
    文档流的元素处于一个渲染区,而定位元素处于另一层渲染区,float元素又会与之不同
    各个渲染区中的元素具有其定位规则,最简单的便是文档流中的元素,遵循其块级元素独占一行+盒模型的规则:
    ① 块级元素独占一行,并且具有框(经典盒模型)
    ② 块级元素间由margin属性分割,并且垂直方向的margin会取其大者
    ③ 块级元素必定左靠这父级块级元素左边框(包含块,布局上下文)
    ④ float元素不能影响块级元素的BFC区域,但是其高度会参与计算
     
    创建BFC的方式有:
    ① float
    ② overflow
    ③ display(使行内元素具有BFC)
    ④ position
     
    基于此,我们便可以实现我们的布局了,这里以最简单的两列布局为例(左边导航,右边内容主体)
    由于先出现的DOM先展示,所以内容优先原则,我们会将主体dom先展示
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
      <title></title>
      <style>
        * { margin: 0; padding: 0; }
        div { border: 1px solid black; }
        #sidebar { position: absolute; left: 0; top: 0; width: 95px; }
        #content { margin-left: 100px; }
      </style>
      <script src="../jquery-1.7.1.js" type="text/javascript"></script>
    </head>
    <body>
      <div id="content">
        主体
      </div>
      <div id="sidebar">
        导航
      </div>
    </body>
    </html>
    这里从理论上说,便是触发了siderbar元素的定位特性,其BFC与文档流不相关了
    当然,这里siderbar可以使用float实现,但是float本身应该用于处理文字与图片包裹的需求,我们本着职责分离的想法就别那样干了
    而且使用float还会引起元素坍塌,这里还要费劲去处理清除浮动

    行内元素

    行内元素的处理比较复杂,首先行内元素的高度由其line-height决定,所以不要妄想其设置一个行内元素的高度,这会引起意想不到的问题
    举一个例子来说,很多大型网站都会具有统计代码,而此类统计代码一般是以img做请求发出,这个时候可能会导致10px左右的白屏问题
    这个就是妄想设置行内元素高度的结果,独立的inline元素出现时,会为其创建一个line boxes作为容器(文字框)
    一行文字一个line Boxes,一行高度由其中最高的行内元素确定,上例中有一个height为0的img,却为其生成了一个高度为10的行高
    下面的代码中,div会被行内元素撑开,其高度会由span中line-height高者决定
    <div>
      <span id="span1">主体 </span><span id="span2">导航 </span>
    </div>

    移动端的建议

    ① 移动端的文档流渲染效率最高,应该避免大范围使用定位元素,在小米,三星等低端下定位元素可能渲染不出来(解决方案是引起回流)
    ② img元素加载失败时候会有边框,需要搞掉
    ③ 慎用fixed属性,fixed对于移动端来说有点头疼,首先会有文本聚焦fixed定位错乱问题,其次在ios4的屏幕中,如果加上浏览器上下工具条,再用fixed可视区域会变得很小
    ④ ios是按块渲染的,布局时候可以分块,不会渲染可视区域外的内容
    ⑤ 动画或者border-radius、box-shadow等属性皆会使手机耗电加剧(但是这个好像与我们没关系)
    ⑥ fixed元素为其设置html可能不响应或者说渲染看不见,常见于ipod或者低端android
    ⑦ 当然能在布局上用上一些语义化标签自然是好事,这样对SEO或者特殊人事有一定帮助,比如strong、article之类的

    总结

    因为我本身专注点在js对css了解较少只能做此解析,请尽量拍砖指正

    一次请求的完整流程

    我们一次网址输入会发起一连串连锁效应,但是因为我这边对HTTP一块不是十分熟悉,只能解释自己了解的
    一次URl输入后,其流程如下,首先是请求响应的流程:
    1 解析URL,解析域名生成唯一IP地址,开始搜索服务器
    2 找到服务器后,服务器接收请求被服务器进程拦截;一般而言,.net的程序会被IIS处理,java会被jBoss或者tomcat处理
    3 服务器处理请求,如果静态文件的话直接返回,若是.net或者java等动态脚本会经过服务器编译,执行其中的服务器端代码
    4 若是服务器端具有数据库操作的话,这里还需要与DB建立连接,操作数据库
    5 服务器处理结束后,生成最终的静态HTML字符串返回,开始向请求者(客户端)返回请求字符串,一次返回量过大就会分批次,这是一个优化点
    6 服务器响应到达浏览器,浏览器开始处理请求,进入浏览器解析流程

    请求返回后,便进入了我们关注的前端模块

    简单来说,浏览器会解析HTML生成DOM Tree,其次会根据CSS生成CSS Rule Tree,而javascript又可以根据DOM API操作DOM
    上面的文字描述的很简单,事实上发生的事情,却很复杂,这里与代码实现也很有关联,但是有几个关键点:
    页面一定会等所有的HTML结构与CSS加载下来才渲染(webkit内核
    比如我们这里使用fiddler限制其外链加载,我们为其限速为10s
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
      <title></title>
      <style>
        div { border: 1px solid black; }
        a { color: Red; }
      </style>
    </head>
    <body>
      <div>
        <a id="span1" href="http://www.baidu.com">主体 </a><span id="span2">导航 </span>
      </div>
      <link href=" http://kb.cnblogs.com/style/common.css" rel="stylesheet" />
    </body>
    </html>

    我们看到事实上62ms后页面整体dom结构就加载好了,这个时候我们是可以使用js操作dom结构的,但这里一个重点是:
    CSS外链加载会阻塞js的执行,并且重置CSS会引起浏览器的回流或者重绘,也就是:
    css外链会阻塞整个页面的渲染(显示),但是其DOM结构是可操作的,中间如果有阻塞性的操作,比如alert的话会强制浏览器绘制页面
    上面的特性与css外链的顺序无关,并且有几个样式相关的操作,便会执行几次,最终采用最近或者优先级最高的样式
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
      <title></title>
      <style>
        div { border: 1px solid black; }
        a { color: Red; }
      </style>
    </head>
    <body>
      <div>
        <a id="span1" href="http://www.baidu.com">主体 </a><span id="span2">导航 </span>
      </div>
      <script>
        document.getElementById('span2').innerHTML = '测试';
        alert(1) 
      </script>
      <script>
        alert(2) 
      </script>
      <link href=" http://kb.cnblogs.com/style/common.css" rel="stylesheet" />
    </body>
    </html>

    一个需要注意的地方是,chrome与firefox或者IE表现不一致,firefox与IE都是先渲染页面最后等段CSS下来后再次渲染
    所以我们很多同学面试时说将css外链放到header中,而不是body中的理解都是一知半解,这里真实的处理办法是异步插入css外链才行
    至少对于chrome需要做这个处理,否则页面就是出不来,因为多数手机是webkit内核,保不齐这里出多少事情
    根据以上流程后,页面也基本出来了,这里简述其流程
    ① 生成DOM树
    ② 计算CSS样式
    ③ 构建render Tree
    ④ reflow,定位元素位置与大小
    ⑤ 绘制页面
    上面过程如果js操作dom或者终结有一段style都会引起reflow,由于img会在文档加载结束后加载,可能会撑开页面,导致回流,所以一般需要对img设置尺寸
    对于这块的优化各位自己来吧,我这里便只能理解到这个程度了
    PS:事实上chrome获得请求时本身也有几个事件点,这里可以用其开发性能插件,但对前端基本透明,我们这里不关注了

    MVC与组件化

    这里我将2块题目合到一起了,我觉得这里可以连到一起做说明

    View分离

    很多程序的变革集中积累在VIEW一块的处理,原因是这里的需求是最复杂的,就View分离来说,最成功的我觉得是ASP到ASP.net的变革
    最初的ASP程序,会将C#代码写在asp代码中,这样的结果便是页面里面既有html又有C#代码,甚至一个js循环中会嵌套出C#的循环
    PS:你一定要相信,那个时候不会有js分成的概念,因为需求达不到
    所谓的View分离便是,程序员确实受不了维护显示与逻辑同时处于一个页面的程序了,于是他选择了改变,改变的结果便是拆分
    View分离一大核心思维便是,分得开,合得拢,他们这里引入一个codebehind方案将一个页面文件分成两个(事实上是三个)

    ① index.apsx

    ② index.aspx.cs

    <%@ Page Language="C#" AutoEventWireup="true" CodeFile="index.aspx.cs" Inherits="_00综合_11mvc_index" %>
    public partial class _00综合_10doc_write_index : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
    
        }
    }

    最终这两个文件会和到一起,两个文件之间也可通信,而通信的桥梁是.net一个个被人诟病的组件,比如:

    ① button组件

    ② datalist

    ③ label组件

    ④ 伟大的gridview

    各个组件在C#层面上会拥有一个ID进行约束,.cs文件便可以根据该ID为其注册各个事件,这个与javascript的模型便非常类似了

    View分离的第一个优点便是,用户的界面变得干净了,不会有代码混杂的现象,第二个优点便是业务端的代码可以再分离,从而多了数据层、业务层等各个概念

    而组件的出现让.net变成了世界上开发最快的语言,这点谁也不可否认,而这些都是前端MVC出现或者组件出现的意义

    前端View分离

    与asp当初的情况一致,js进行dom操作或者字符串拼接的目的事实上就是想形成一个可供展示的View,前端jser已经再也不能忍受这种代码了:

    很多时候,我们想将对应的模板单独的放到一个地方,每次样式若是有更改,只需要更改那个文件即可,只要与之呼应的“ID”不丢失即可,比如这样的结构和代码:

    View Code
    <div class="cui-pop-box">
      <div class="cui-hd">
          <%=title%>
      </div>
      <div class="cui-bd">
        <div class="cui-error-tips">
          <%=content%></div>
        <div class="cui-roller-btns">
          <% for(var i = 0, len = btns.length; i < len; i++ ) {%>
          <div class="cui-flexbd <%=btns[i].className%>">
            <%=btns[i].name%></div>
          <% } %>
        </div>
      </div>
    </div>

    这样做的道理是,这个样子做到了表现与行为分离,我们分得开,然后回根据基类的一个机制,让他们最终合到一块,以完成功能

    这里我们依旧需要强调一个前提:“ID”关联不可丢失,否则“行为”将不可表现,只要两者间关联不丢,这里便可轻松满足以下逻辑:

    ① CSS名修改(非标识性CSS名)

    ② 标签改变

    ③ 描述性文字改变

    ......

    MVC在前端

    重构一书有说,重复性或者类似重复性的代码应该抽象为一个方法,程序员也不傻,在重复使用需要提示框需求后便会学会形成alert组件

    组件的出现是代码抽象,代码重用的标识,这个样子既可以减少工作量也可以减少代码容量,而组件的实现与MVC思维的很好诠释

    比如以下代码:

    View Code

    事实上,MVC的任意一块都可以作为单独的模块实现,比如会有这样的需求:一个model实例的变化会影响两个View的显示,但是仅仅对UI一块来说我们做了如下处理:

    核心点变成了几个属性:

    ① template,根据他生成UI

    ② datamodel,根据他生成viewModel提供给template使用

    ③ eventArr,业务事件注册点

    这个代码是Blade框架的UI基类,他是一个迷你MVC框架

     1     propertys: function () {
     2       //模板状态
     3       this.template = '';
     4       this.datamodel = {};
     5       this.events = {};
     6       this.wrapper = $('body');
     7       this.id = _.uniqueId('ui-view-');
     8 
     9       //自定义事件
    10       //此处需要注意mask 绑定事件前后问题,考虑scroll.radio插件类型的mask应用,考虑组件通信
    11       this.eventArr = {};
    12 
    13       //初始状态为实例化
    14       this.status = 'init';
    15 
    16       //      this.availableFn = function () { }
    17 
    18     },

    template作为View的实现,datamodel作为model实现,我们会根据datamodel与template生成基本的view实体

    这里datamodel与template之间会有一个viewModel的映射关系,是为了防止服务器端突然将title变成Title而导致模板解析错误

    而整个文件便是一个控制器,view有的事件行为采用javascript委托技术全部注册在根元素上,如此整个UI就活了,他的好处是:

    ① 具有继承关系,可以拥有统一的资源释放,或者View通信机制

    ② 代码量也会减少

    MVC与组件化的意义

    MVC对前端的意义甚大,因为jser对MVC或者分模块的思维的深入理解,我们才会将前端代码做分离,这样会有效的避免多人更改一个文件的难题

    这对前端的推动作用不可谓不大!

    组件化是对重复工作,重复代码的降低,当然是好东西......

    资源加载

    前端优化的瓶颈始终在资源加载,只要加载快,无论你代码写的多慢(不要纠结死循环),都一定快,所以前端优化事实上一直都是一个主题:瘦身

    压缩

    css sprite

    延迟加载(主要针对图片)

    按需加载(主要针对首屏未用到的UI)

    缓存

    CDN

    预加载

    等词语不断的在前端出现,但是一个不可避免的事实是,需求越发复杂,体验要求越高,所以一个前端可能的事实是:

    前端资源体积越来越大,避免此事发生不是前端说了算的,需要产品与交互一起努力,清晰、体验好、轻量级的设计谁不喜欢,但是广告营销也不能不考虑,总之此事路还长!

    webapp的资源加载

    对于webapp来说,首次加载的体积会更加大,因为其要求的库更多,并且网速更慢,这个时候可以采取fake页的方案

    我们应该避免页面长时间白页,这个时候便提出了fake页的概念。页面渲染只需要完整的HTML以及CSS,这个便是第一个优化点。

    从数据请求数以及请求量来说,webapp首页的响应应该比较慢,若是任由js加载完成再渲染页面,用户很有可能失去耐心。

    但是从DOMContentLoaded来看,首页事实上页面响应比较迅速,所以这个加载结束后页面第一屏便渲染结束,然后再异步加载js,当js改变后再动态改变dom结构中的一些关键点

    这个时候一个静态HTML页面,装载首屏的基本内容,让首页快速显示

    然后js加载结束后会马上重新渲染整个页面,这个样子,用户就可以很快的看到页面响应,给用户一个快的错觉,给人感觉快得多。

    是否按需加载

    按需加载的话确实会对首屏加载有好处,但是是否按需加载却不一定了,以下面两个体验为例:

    资源完全加载

    http://yexiaochai.github.io/blade/demo/dest.html

    按需加载

    http://yexiaochai.github.io/blade/demo/debug.html

    PS:我这里debug版本点击时候未做mask处理,大家不要疯狂点击了

    这里各位直观的感受是什么呢?是不是,首次加载后后续操作十分流畅,而按需加载的话,每次皆会感觉有点“卡”

    按需加载需要加载js和模板,这个过程自然卡,所以真正是不是要按需加载,或者多少资源按需加载有个临界值,需要不断的测试才行

    最后,要减少资源的话,代码的质量神马的也需要考虑的,但对容量来说效用可能不是太大

    IOS的体验

    IOS的体验好,主要好在两点:

    ① 清晰、简洁、傻瓜化设计,连我妈都可以轻巧的操作苹果手机其简易型可想而知

    ② 用户行为模拟,IOS体验第二点便是其无敌的动画效果

    若是说web应用想赶上(寒冬老师这里赶上一词用得十分贴切,他要说超过估计没人理他了)native开发的话还是有可能

    但是如果说web应用要赶上IOS的设计的话,那么还有无数荆棘需要踩过!并且有两大前提:

    ① 网速快,用户不必关心资源大

    ② 手机性能好,不说超越PC,至少能“赶上”PC吧

    以上两点成立的话,web应用赶上IOS体验才变得可能,简单来说就动画而言,前端有哪些问题呢?

    webapp中的动画

    webapp的一大优势便是在view切换时候可以拥有媲美与native的动画效果,但是很多时候那只是一种想法,真正的情况却不是这样
    产生此问题的原因有:
    ① 手机CPU烂!
    ② 手机显卡烂!就算四核其渲染也很有问题
    ③ 高端手机浏览器会有BUG
    ④ 低端手机支持不好(国内山寨机笑而不语)
    因为以上原因,事实上做webapp的都会不同程度的弱化动画,或者在局部区域使用动画

    难在何处?

    dom树过多
    view的移动与简单的图片slider组件相差甚剧!原因便是其dom结构可能很复杂,大dom树的移动在移动端效果很差
    就简单列表页来说,当项目超过100个时,使用IScroll类插件都应该很慎重,这类移动可能非常卡!
    而且dom树复杂度与业务直接相关,我们没有任何办法去控制dom树,因为业务代码可能不会经过我们的手,就算经过,你又肯定自己做出来的dom树有多小?不见得吧
    长短页问题
    所谓长短页便是一个view很长一个view很短,这里问题处理十分讨厌
    首先我们每次做切换需要将view位置切换至头部(window.scroll(0, 0))如此的话ios中会引起
    页面viewport的变化(系统自动发生),或者会触发低端工具栏的出现,这个时候页面抖动无可避免
    若是每次不执行window.scroll(0, 0),切换时候又会导致短的view不可见
    我现阶段想到的解决方案是,移动时候将scroll设得比较大,移动时候将bview的top值与scrollTop相同
    最后仍然需要执行window.scroll(0, 0)的操作,所以,这个问题只能缓解,无法解决
    手机渲染问题
    只要是做移动端的朋友,一定会对三星机或者一些低端机的渲染嗤之以鼻!
    具体表现为多次操作style后,后面的操作浏览器不会搭理你
    解决方案是:
    ① 引起浏览器强烈重绘
    ② 临时增删一个dom结构
    但是涉及view切换动画的话,很有可能会出现一些莫名其妙的问题!

    所以单单由简单的webapp的切换都如此困难,web应用想赶上IOS的话还要等几年......

    Hybrid对前端的意义

    应该说Ajax带动了前端的首次革命,而移动端带来了二次革命,而Hybrid将前端推上了风口浪尖!

    原来我厂app是使用native开发的,会出现此等问题:一个应用需要养3个团队(ios、android、winphone),而且一旦业务改变会让开发抓狂!

    而Hybrid的出现解决了此问题,一套前端代码可以用于四个地方:浏览器、ios、android、winphone,而这个却是互联网公司最需要的

    最近两年,移动大潮袭来,各个公司皆在抢占移动端的份额,谁赢了这场战斗谁就是下一代王者,所以出现了一个事实:

    市场的占领、业务的扩展是第一位!

    所以Hybrid的市场与需求比native大,但是这不是说native没用了,因为更好的体验我们的追求,所以在Hybrid占领市场结束后,可能需要改版为native

    除非那时前端的体验能缩小与native的距离

    Hybrid开发的问题

    Hybrid提高了前端开发的门槛,因为Hybrid的调试难,但是业内也出现了一些调试的方案,我这里有一套Hybrid调试的技巧,有兴趣可以交流

    Hybrid 兼容BUG多,总所周知,H5站点上看着好好的程序,一旦到了webview上就出问题了,这个调试也很痛苦

    哎,其实Hybrid开发也只是需要一点熟悉度罢了,没有什么可说的,就此打住吧

    结语

    寒冬老师喜欢出题,我喜欢答题,其中几道题我这里没有什么概念就交白卷了,不知道我的回答是否可以及格

    若是寒冬老师或者各位觉得我的回答能勉强及格,左边微博求粉!!!尼玛我粉丝太少了!!!

  • 相关阅读:
    nodejs学习(一)--express+ejs生成项目
    react-native React Native version mismatch
    qrcode length overflow 生成二维码网址长度溢出解决办法
    禁止input输入空格
    微信开发:清除微信浏览器缓存
    多行文本溢出显示...的方法(-webkit-line-clamp)
    angular路由(自带路由篇)
    angular入门(基础篇)
    Python文件读写(open(),close(),with open() as f...)
    centos6.9使用yum安装mysql(简单粗暴,亲测有效)
  • 原文地址:https://www.cnblogs.com/yexiaochai/p/3899974.html
Copyright © 2011-2022 走看看