本文写于2016年06月22日，现在读起来仍能温故知新。

从模块化谈起

模块的定义

模块,又称构件,是能够单独命名并独立地完成一定功能的程序语句的集合（即程序代码和数据结构的集合体）。

模块的特征

独立性 — 能够独立完成一个功能
完整性 — 完成一个特定功能
集合性 — 一组语句的集合
依赖性 — 可以依赖已经存在的模块
被依赖 - 可以被其他模块依赖

前端为什么要模块化

WebApp越来越庞大，越来越复杂
团队分工协作、进度管理、单元测试
代码复用，开发只需关注核心业务逻辑

Javascript模块化编程

很久很久以前，JSer把完成特定功能的代码放入独立的文件中，以此来实现“模块化”。
作为Netscape 10天就开发出来的玩具语言，它为JSer们提供了太多大展拳脚的机会。

原始写法


        function m1 () {
　　　　      //...
　　　　  }

　　     function m2 () {
　　　　      //...
　　     }

文件作为模块组织单元
缺点
- “污染”了全局变量
- 命名冲突

对象写法


        var module1 = new Object({
        　　_count : 0,
        　　m1 : function (){
        　　　　//...
        　　},
        　　m2 : function (){
        　　　　//...
        　　}
        });

Object作为模块组织单元

优点
- 不会“污染”全局变量
- 解决了命名冲突问题
缺点
- 内部状态可以被外部改写
- module1._count = 5;

立即执行函数表达式写法


    　　var module1 = (function(){
    　　　　var _count = 0;
    　　　　var m1 = function(){
    　　　　　　//...
    　　　　};
    　　　　var m2 = function(){
    　　　　　　//...
    　　　　};
    　　　　return {
    　　　　　　m1 : m1,
    　　　　　　m2 : m2
    　　　　};
    　　})();

立即执行函数表达式（IIFE）
优点
- 外部代码无法读取内部的私有变量
- module1._count; //undefined
模块的基本写法（ES5）
IIFE是模块化的基础（ES5）

放大模式


    　　var module1 = (function (mod){
    　　　　mod.m3 = function () {
    　　　　　　//...
    　　　　};
    　　　　return mod;
    　　})(module1);

扩展了module1模块
优点
- 扩展 & 继承
缺点
- module1可能是空对象（加载顺序不确定）

宽放大模式


    　　var module1 = ( function (mod){
    　　　　//...
    　　　　return mod;
    　　})(window.module1 || {});

优点：
- 参数允许是空对象

输入全局变量


        　　var module1 = (function ($) {
        　　　　//...
        　　})(jQuery);

依赖模块通过参数传入
优点
- 模块独立，依赖关系明显

思考

函数声明 & 函数表达式
回调函数 & 模块化 & 闭包

为什么需要模块化规范

大家都以同样的方式编写、加载模块，更易阅读和协作。

Javascript模块化规范

CommonJS
AMD
CMD
UMD
ES6 Module

CommonJS


        var x = 5;
        var addX = function(value) {
          return value + x;
        };
        module.exports.addX = addX;


        var example = require('./demo.js');
                 // 6
        console.log(example.addX(1));

优点
- 服务器端模块便于重用
- NPM 中已经有将近20万个可以使用模块包
- 简单并容易使用
缺点
- 同步的模块加载方式不适合在浏览器环境中
- 不能非阻塞的并行加载多个模块
实现
- 服务器端的Node.js
- Browserify，浏览器端的CommonJS实现，可以使用NPM的模块，但编译打包后的文件体积可能很大

AMD - Asynchronous Module Definition


        define("module", ["dep1", "dep2"], 
            function(d1, d2) {  
                return someExportedValue;
            }
        );


        require(["module", "../file"], 
            function(module, file) { 
                // 
            }
        );

优点
- 适合在浏览器环境中异步加载模块
- 可以并行加载多个模块
缺点
- 依赖前置，代码的阅读和书写比较困难
实现
- RequireJS

CMD - Common Module Definition

优点
- 依赖就近，延迟执行
- 可以很容易在 Node.js 中运行
缺点
- 依赖 SPM 打包，模块的加载逻辑偏重
实现
- Sea.js（目前由阿里和腾讯维护）

UMD - Universal Module Definition

UMD规范类似于兼容 CommonJS 和 AMD 的语法糖
模块定义的跨平台解决方案

ES6 Module

优点
- 语言层面支持，编译阶段静态分析
- 面向未来的 ECMAScript 标准
缺点
- 原生浏览器端还没有实现该标准
实现
- Babel（编译为浏览器能够识别的 ES5 规范）

不仅仅是Javascript

CSS
IMG
WebFonts
HTML / Template
......

Webpack

Webpack是什么

Webpack 是一个模块打包器
根据模块的依赖关系进行静态分析，然后将这些模块按照指定的规则生成对应的静态资源

借助 Babel 可以将 ES6 模块编译成 CommonJS 和 AMD

Webpack的特点

Code Splitting（代码拆分）
- 支持异步依赖，可实现模块的按需加载
Loaders（加载器/转换器）
- 本身只能处理 Javascript
- 借助 Loader 可以将各种类型的资源转换成 Javascript 模块
Clever parsing（智能解析）
- 支持 CommonJS、AMD、普通 JS文件
- 支持动态表达式 require("./templates/" + name + ".jade")
Plugin system（插件系统）
- 大多数功能都是借助插件系统实现
- 开发和使用开源的插件，满足各式各样的需求
Efficient（高性能）
- 异步 I/O 和多级缓存，快速增量编译

在项目中使用Webpack

Hot Reload（HMR）

Express
- 基于 Node.js 的 Web 开发框架
- 本身仅提供路由和 static 中间件
- 开发和使用第三方中间件，满足各式各样的需求
webpack-dev-middleware
- 一个处理静态资源的 middleware
- 用来处理 webpack 打包输出的静态资源
webpack-hot-middleware
- 结合 webpack-dev-middleware 使用的 middleware
- 实现浏览器的Hot Reload（无刷新更新），也即 HMR（Hot Module Replacement）

var express = require('express');
var webpack = require('webpack');
var config = require('./webpack.dev.conf');

var app = express();
var compiler = webpack(config);

var devMiddleware = require('webpack-dev-middleware')(compiler, {
  publicPath: config.output.publicPath,
  stats: {
    colors: true,
    chunks: false
  }
});

var hotMiddleware = require('webpack-hot-middleware')(compiler);
// force page reload when html-webpack-plugin template changes
compiler.plugin('compilation', function (compilation) {
  compilation.plugin('html-webpack-plugin-after-emit', function (data, cb) {
    hotMiddleware.publish({action: 'reload'});
    cb();
  })
});

// serve webpack bundle output
app.use(devMiddleware);
// enable hot-reload and state-preserving
// compilation error display
app.use(hotMiddleware);
// serve pure static assets
app.use('/static', express.static('./static'));

Mock Server

在浏览器端MV*时代，Mock Server 使得前后端分离变得相对容易。
推荐RAP

var express = require('express');
var proxyMiddleware = require('http-proxy-middleware');

var app = express();

var proxyTable = {
  // http://thx.github.io/RAP/index_zh.html
  '/login': 'http://rap.taobao.org/mockjs/1986/'
};

// proxy api requests
Object.keys(proxyTable).forEach(function (context) {
  var options = proxyTable[context];
  if (typeof options === 'string') {
    options = {target: options};
  }
  app.use(proxyMiddleware(context, options));
});

Long-Term Caching

"There are only two hard things in Computer Science: cache invalidation and naming things."

Phil Karlton

output.filename

除了可以指定具体的文件名以外，还可以使用一些占位符，包括：

name 模块名称
hash 模块编译后的（整体）Hash值
chunkhash 分片的Hash值

name

如果 entry 未指定名字，会使用 main 作为模块名字。
多entry、且未指定entry name时，会将所有 entry 合并打包
- entry: ['./example2.1','./example2.2']

hash

所有模块整体进行 Hash，每个模块的 Hash 值都一样
- filename: '[name]-[hash].js'

chunkhash

每个模块单独进行 Hash，每个模块都有自己的 Hash值
- filename: '[name]-[chunkhash].js'
- chunkFilename: '[name]-[chunkhash].js'（非 entry 模块）

Option 1: One hash for the bundle

{
    output: {
        filename: "output.[hash].bundle.js",
        chunkFilename: "[id].[hash].bundle.js"
    }
}

Option 2: One hash per chunk

{
    output: {
        filename: "output.[chunkhash].bundle.js",
        chunkFilename: "[id].[chunkhash].bundle.js"
    }
}

Code Splitting

代码分隔，按需加载。

import main from '../../main.js';
import OrderQuery from '../../views/order/OrderQuery';
import OrderDetail from '../../views/order/OrderDetail';

// 定义路由规则
let routeMap = {
  '/': {
    name: 'orderQuery',
    component: OrderQuery
  },
  '/order-detail': {
    name: 'orderDetail',
    // 异步加载会导致丢失Style.(未被抽取到common.css中,也不在当前的chunks bundle js中)
    component: function (resolve) {
      require(['../../views/order/OrderDetail'], resolve);
    }
    // component: OrderDetail
  }
};

// 启动应用
main.startApp(routeMap);

CommonsChunkPlugin

提取Entry间的公共依赖，防止重复加载。
可指定 Common Chunks 的name
可指定相关的 Entry

plugins: [
  // If 'chunks' option omitted then all entry chunks are selected
  new CommonsChunkPlugin({name: 'commons'}),
  // Mark meta.js as entry chunk instead commons.js.
  new CommonsChunkPlugin({name: 'meta', chunks: ['commons']})
]

UglifyJsPlugin

压缩和混淆代码，减小 Bundle 的大小，提高加载速度，节省流量。

  plugins: [
    new webpack.optimize.UglifyJsPlugin({
      compress: {
        warnings: false
      }
    })
  ]

HtmlWebpackPlugin

// generate dist index.html with correct asset hash for each entry.
Object.keys(baseConfig.entry).forEach(function (name) {
  var htmlConf = {
    filename: '../'.concat(name).concat('.html'),
    template: './src/index.html',
    inject: true,
    chunks: ['meta', 'commons', name],
    chunksSortMode: function (a, b) {
      var index = {'meta': 1, 'commons': 2};
      index[name] = 3;
      var ai = index[a.names[0]],
        bi = index[b.names[0]];
      return ai && bi ? ai - bi : -1;
    },
    minify: {
      // more options: https://github.com/kangax/html-minifier#options-quick-reference
      removeComments: true,
      collapseWhitespace: true
    }
  };
  baseConfig.plugins.push(new HtmlWebpackPlugin(htmlConf));
});

Loaders

loaders: [
  {
    test: /\.vue$/,
    loader: 'vue'
  },
  {
    test: /\.css$/,
    loader: 'vue-style!css!px2rem?remUnit=75' // 将 px 批量转成 rem
  },
  {
    test: /\.js$/,
    loader: 'babel',
    include: projectRoot,
    exclude: /node_modules/
  },
  {
    test: /\.html$/,
    loader: 'vue-html'
  },
  {
    test: /\.(png|jpg|gif|svg|woff2?|eot|ttf)(\?v=[0-9\.]+)?$/,
    loader: 'url',
    query: {
      limit: 10000,
      name: '[name].[ext]?[hash:7]'
    }
  }
]

响应式设计

保证尽可能多的用户都能正常访问网站。渐进增强是保证基本内容能够正常展示的情况下，增强现代浏览器的用户体验。优雅降级是保证老浏览器也能够正常展示网页内容，去除非必须的酷炫特效。

什么是响应式设计

网页设计应该做到根据不同设备环境自动响应及调整。
不仅仅是关于屏幕分辨率自适应以及自动缩放图片等。
更是一种对于设计的全新思维模式：移动优先、向下兼容。

适配不同终端

遵循移动优先原则，交互&设计应以移动端为主，PC则作为移动端的一个扩展。
适配不同终端有两个关键点：响应式布局、响应式内容（图片、多媒体）。

响应式布局

CSS Media Queries
viewport
Flex

响应式图片

屏幕尺寸和分辨率
屏幕的DPI/PPI

移动端适配

一些概念

物理像素（Physical Pixel）
设备独立像素（Density-Independent Pixel）
设备像素比（Device Pixel Ratio）
位图像素（Bitmap Pixel）

物理像素（Physical Pixel）

一个物理像素是显示器(手机屏幕)上最小的物理显示单元，在操作系统的调度下，每一个物理像素都有自己的颜色值和亮度值。

设备独立像素（Density-Independent Pixel）

也叫密度无关像素、CSS 像素、逻辑像素。
一种Web编程上的概念，是一个抽象的单位。

在不同的设备中，CSS 中的 1px 所代表的物理像素可能是不同的。

设备像素比（Device Pixel Ratio）

设备像素比（简称dpr）定义了物理像素和设备独立像素的对应关系。
设备像素比 = 物理像素 / 设备独立像素 // 在某一方向上，x方向或者y方向
在javascript中，可以通过window.devicePixelRatio获取到当前设备的dpr。

位图像素（Bitmap Pixel）

位图像素是栅格图像（如：png, jpg, gif等）最小的数据单元。
每一个位图像素都包含着一些自身的显示信息（如：显示位置，颜色值，透明度等）。

以 iPhone6s 为例

设备宽高为375×667，可以理解为设备独立像素(或CSS像素)。
dpr为2，根据上面的计算公式，其物理像素就应该 ×2，为 750×1334。

用一张图来说明

在不同的屏幕上(普通屏幕 vs Retina屏幕)，CSS像素所呈现的大小(物理尺寸)是一致的，不同的是1个CSS像素所对应的物理像素个数是不一致的。

图片模糊

理论上，1个位图像素对应于1个物理像素，图片才能得到完美清晰的展示。
假设在普通屏幕下完美展示，但是在Retina屏幕下就会出现位图像素点不够，从而导致图片模糊。

对于dpr=2的retina屏幕而言，1个位图像素对应于4个物理像素，由于单个位图像素不可以再进一步分割，所以只能就近取色，从而导致图片模糊。

对于图片高清问题，比较好的方案就是两倍图(@2x)，如：200×300（CSS Pixel）img标签，就需要提供 400×600 的图片。

图片缺少锐利度

两倍图在普通屏幕下显示，一个物理像素点对应4个位图像素点。
它的取色也只能通过一定的算法来实现(显示结果就是一张只有原图像素总数四分之一，我们称这个过程叫做downsampling)

肉眼看上去虽然图片不会模糊，但是会觉得图片缺少一些锐利度，或者是有点色差（但还是可以接受的）。

对比度：明暗

锐利度：边缘

清晰度：模糊

图片显示 Demo

100×100的图片，分别放在100×100，50×50，25×25的img容器中，在Retina屏幕下的显示效果：

爱字图，可以通过看文字"爱"来区分图片模糊还是清晰。
条形图，通过放大镜其实可以看出边界像素点取值的不同：
- 图1，就近取色，色值介于红白之间，偏淡，图片看上去会模糊(可以理解为图片拉伸)。
- 图2，没有就近取色，色值要么是红，要么是白，图片看上去很清晰。
- 图3，就近取色，色值介于红白之间，偏重，图片看上去有色差，缺少锐利度(可以理解为图片挤压)。

只需上传大图（@2x），小图交给图片服务器处理，页面只要负责拼接 URL 即可。

https://res.10010.com/img/avator.png // 原图

https://res.10010.com/img/avator.png_200x200.png // 200×200

https://res.10010.com/img/avator.png_100x100.png // 100×100

图片高清适配方案

不同 dpr 下，加载不同尺寸的图片。

利用 CSS Media Queries 或 Javascript。

搭建图片服务器，通过url参数，控制图片质量，或将图片裁剪成不同的尺寸。

Q: Bootstrap 布局适配的原理？

布局适配方案

目前比较流行的、也是助手采用的布局适配方案是使用相对单位 rem。

rem 是什么


        html {
          font-size: 75px;
        }


        div {
          width: 2rem;
        }

div 的实际宽度 width = 75px * 2 （即 150px）

还得聊聊视觉稿

在前端开发之前，VD 会给我们一个psd文件，称之为视觉稿。

移动端开发中，为了做到页面高清的效果，视觉稿往往会遵循以下两点：

首先，选取一款手机的屏幕宽高作为基准(以前是iPhone4s的320×480，现在更多的是iPhone6的375×667)。
对于Retina屏幕(如dpr=2)，为了达到高清效果，视觉稿的画布大小会是基准的2倍，也就是说像素点个数是原来的4倍（对iPhone6而言，原先的375×667，就会变成750×1334）。

现在你应该知道，对于dpr=2的手机，为什么画布大小×2，就可以解决高清的问题了。

思考：对于2倍大小的视觉稿，在具体的CSS编码中如何还原每一个区块的真实宽高（也就是布局问题）?

rem 方案原理

针对不同屏幕尺寸和dpr动态改变根节点html的font-size(基准值)。

document.documentElement.clientWidth * dpr / 10

乘以dpr，是因为页面有可能为了实现1px border页面会缩放(scale) 1/dpr 倍（如果没有，dpr=1）。
除以10，是为了取整，方便计算（理论上可以是任何值）

iPhone4/5: 320px * 2 / 10 = 64px

iPhone6/6s: 375px * 2 / 10 = 75px

`CSS方式`动态改变根节点 html 的 font-size

/*iPhone 4/5*/
@media screen and (min-width: 320px) {
  html {
    font-size: 64px !important; /*no*/
  }
}

/*iPhone 6/6s*/
@media screen and (min-width: 375px) {
  html {
    font-size: 75px !important; /*no*/               缺点：不够精确，但是够用。
  }
}

/*iPhone 6p/6sp*/
@media screen and (min-width: 414px) {
  html {
    font-size: 124.2px !important; /*no*/
  }
}

`JS方式`动态改变根节点 html 的 font-size

let docEl = document.documentElement;
let fontEl = document.createElement('style');

let dpr = window.devicePixelRatio || 1;
let rem = docEl.clientWidth * dpr / 10;

// 动态写入样式
fontEl.innerHTML = 'html{font-size:' + rem + 'px!important;}';
docEl.firstElementChild.appendChild(fontEl);

// 给js调用的，某一dpr下rem和px之间的转换函数
window.rem2px = function (r) {                        精确计算rem基准值，但要加载一段 js
  r = parseFloat(r);
  return r * rem;
};
window.px2rem = function (p, base) {
  let r = p / (base || 75);
  return r.toFixed(6);
};
window.jspx = function (r) {
  r = parseFloat(r / 75.0);
  return r * rem;
};

http://teazean.com/2015/11/02/reflow&repaint

同时使用`CSS方式`和`JS方式`

如果仅使用JS方式，那么页面在加载后可能会重新布局（relayout/reflow），产生抖动。
所以先通过CSS方式，基本确定页面布局；然后再通过JS方式精确计算后，页面进行微调。

如何在 CSS 中还原视觉稿的真实宽高

基于 iPhone6s 的 750×1334 高清视觉稿中有一个宽高 750×300px 的 div。

由前面的公式可算出 iPhone6s 下 rem基准值 = 75px

width: 10rem; // rem基准值 = 75px
height: 4rem; // rem基准值 = 75px

如何自动适配 iPhone4s

由前面的公式可算出 iPhone4s 下 rem基准值 = 64px

width: 10rem; => width: 640px;
height: 4rem; => height: 256px;

px2rem 自动化

利用 Webpack 的 px2rem-loader 实现 px2rem 的自动转换。

不需要人肉进行 px2rem 的转换
调整样式时更简单、直观

发现问题了吗？

iPhone6s的物理像素是 750×1334
VD 视觉稿也是基于 iPhone6s的物理像素 750×1334
CSS 中使用的逻辑像素也是基于 750×1334
CSS像素 = 物理像素 / dpr

这意味着在高清屏上，目前的 CSS 使页面放大到了两倍，页面无法完全展示。

页面缩放

let docEl = document.documentElement;
let metaEl = document.querySelector('meta[name="viewport"]');

let dpr = window.devicePixelRatio || 1;
let scale = 1 / dpr;

// 设置viewport，进行缩放
metaEl.setAttribute('content', 
    'width=' + dpr * docEl.clientWidth + ',initial-scale=' + scale +
    ',maximum-scale=' + scale + ', minimum-scale=' + scale + ', user-scalable=no');

// 设置data-dpr属性，留作的css hack之用(如根据不同的 dpr 设置不同的 font-size)
docEl.setAttribute('data-dpr', dpr);

普通屏幕，页面不进行缩放；2倍高清屏时，页面缩放50%；3倍高清屏时。。。

思考：rem 方案先按物理像素进行设计，然后又进行页面缩放、适配 CSS像素，这么折腾到底为了什么？开发时直接按照 CSS像素进行页面布局不是也可以么？

字体大小问题

在讨论字体是否需要缩放时，通常要考虑设计师的要求：

字体大小的统一和缩放


        font-size: 16px; /* no */
        [data-dpr="2"] input {
          font-size: 32px; /* no */
        }


        font-size: 32px;

前提VD 按照 iPhone6s 的物理像素 750×1334px 进行设计，且视觉稿上 font-size 为32px。（左边进行了页面 scale，右边使用了 rem 方案适配）

左边font-size = dpr * 16px，结合页面scale = 1 / dpr，这就保证了字体在所有屏幕上的大小均为16px（CSS 像素）。

右边font-size = 32px / 75（rem基准值），这使得字体能够根据屏幕的分辨率进行等比缩放处理。

Retina下，border: 1px; 问题

这大概是设计师最敏感，最关心的问题了。

上图中，对于一条1px宽的直线，它们在屏幕上的物理尺寸(灰色区域)的确是相同的，不同的其实是屏幕上最小的物理显示单元，即物理像素，所以对于一条直线，iphone5它能显示的最小宽度其实是图中的红线圈出来的灰色区域，用css来表示，理论上说是0.5px。

设计师想要的 Retina 下 1px边框，其实是1物理像素。对于CSS而言，相当于0.5px边框，这是 Retina下（dpr=2）下能显示的最小单位。

然而，无奈并不是所有手机浏览器都能识别border: 0.5px; ios7以下，android等其他系统里，0.5px会被当成为0px处理，那么如何实现这0.5px呢？

border: 1px solid #dcdcdc; // 跳过 px2rem 的处理
scale = 1 / dpr

CSS中仍然指定1px，但页面进行了1/dpr缩放，实际的物理像素仍是1px。

该特性最先由Apple引入，用于解决移动端的页面展示问题，后续被越来越多的厂商跟进。 http://www.quirksmode.org/mobile/viewports.html http://www.quirksmode.org/mobile/viewports2.html http://www.quirksmode.org/mobile/metaviewport http://weizhifeng.net/viewports.html http://weizhifeng.net/viewports2.html https://segmentfault.com/a/1190000004403527

viewport

先聊聊 PC 浏览器下的 viewport

缩放

Original & Zoom Out & Zoom In

在进行缩放时，元素的 CSS 像素不变，只是它占据的物理像素变化了，例如：

CSS 像素为100×100px的元素，放大到200%时，其 CSS 像素仍为100×100px，但其占用的物理像素为 200×200px，缩小亦同理。

思考 有没有遇到过，手机浏览器访问网站时，出现页面显示不完整或全部显示但元素非常小、看不清楚的情况。（有没有思考过背后的原因和解决方法）

屏幕尺寸

获取方法： screen.width/height
意义： 用户屏幕的整体大小。
度量单位： 物理像素。
浏览器错误： IE8以 CSS 像素对其进行度量。

窗口尺寸

获取方法： window.innerWidth/Height
意义： 浏览器窗口的整体大小，包括滚动条。
度量单位： CSS 像素。
浏览器错误： IE7不支持，Opera以设备像素进行度量。

放大后（右图），window.innerWidth/Height 变小了，因为可放入这个浏览器窗口中的元素减少了。

滚动距离

获取方法： window.pageX/YOffset
意义： 页面滚动的距离。
度量单位： CSS 像素。
浏览器错误： 无。

用户向上滚动，然后放大（右图），浏览器保持相同的元素位于可见页面的顶部，window.pageYOffset 并没有真正的更改：被滚动出窗口的CSS像素的数量仍然（大概）是相同的。经实际验证，是有改变的！！

viewport的概念

viewport的功能是用来约束网站中最顶级包含块元素（containing block）<html> 的。

思考 假设页面上一个 div 具有 width: 10% 属性，现在这个 div 会随着浏览器窗口大小的调整而恰好的放大和收缩。但是这到底是如何工作的呢？

从技术上来说

div 获取了它父元素宽度的10%，比方说是<body>元素（并且你还没有给它设置过宽度），所以问题就变成了<body>的宽度是哪个？

普通情况下，所有块级元素使用它们父元素宽度的100%（有哪些例外？），所以<body>元素和它的父元素<html>一样宽。

那么<html>元素的宽度是多少？它的宽度和浏览器窗口宽度一样。这就是为什么拥有 width: 10% 属性的 div 会占据整个浏览器窗口的10%。

所有web开发者都很直观的知道并且在使用这种技术。

从理论上来说

<html>元素的宽度是被 viewport 的宽度所限制的，<html>元素使用viewport宽度的100%。
viewport 实际上等于浏览器窗口，它就是这么定义的。
viewport 不是一个 html 结构，所以你不能用 CSS 来改变它。

viewport 在桌面环境下只是拥有浏览器窗口的宽度和高度，在移动环境下它会有一些复杂。

思考 对这个 div 进行缩放会是什么效果？

度量 viewport

获取方法：document.documentElement.clientWidth/Height
意义： viewport尺寸。
度量单位： CSS 像素。
浏览器错误： 无。

document.documentElement实际上指的是<html>元素，viewport 要比它更高一层，它是包含<html>元素的元素。

如果你给<html>元素设置width属性（如右图），document.documentElement.clientWidth/Height 给出的仍然是viewport的尺寸，，而不是<html>元素的。

两个属性对

document.documentElement.clientWidth/Height 不包含滚动条。
window.innerWidth/Height 包含滚动条。

事实上两个属性对的存在是浏览器战争的产物。最初Netscape只支持 inner、IE 只支持 client，后来所有其他浏览器都开始支持 client，但是 IE 却没有支持 inner。

在 PC 上拥有这两个属性对是有一些累赘的，BUT，就像我们将要看到的，在移动端这将会得到祝福。

度量`<html>`元素

获取方法：document.documentElement.offsetWidth/Height
意义： 页面（也就是<html>）的尺寸。
度量单位： CSS 像素。
浏览器错误： IE 度量的是viewport。

事件中的坐标

获取方法： pageX/Y, clientX/Y, screenX/Y
意义： 如下。
度量单位： 如下。
浏览器错误： IE不支持 pageX/Y。IE 和Opera 以CSS像素为单位计算 screenX/Y。

pageX/Y提供了相对于<html>元素的以CSS像素度量的坐标。 clientX/Y提供了相对于viewport的以CSS像素度量的坐标。 screenX/Y提供了相对于屏幕的以物理像素进行度量的坐标。
90%的时间你将会使用pageX/Y，其他的10%时间你将会使用clientX/Y，但你永远不需要知道事件相对于屏幕的坐标。

媒体查询

你可以声明「只在页面宽度大于，等于或者小于一个特定尺寸的时候才会被执行」的特殊的CSS规则。

div.sidebar {
    width: 300px;
}

@media screen and (max-width: 400px) {
    // styles assigned when width is smaller than 400px
    div.sidebar {
        width: 100px;
    }
}

width/height使用 viewport 宽高（CSS 像素）。

device-width/device-height使用屏幕宽高（物理像素）。

在桌面环境下去使用width而去忘记device-width吧。

IE 浏览器不支持媒体查询。

移动浏览器的问题

屏幕尺寸小，为 PC 设计的网站在移动浏览器中显示的内容明显要少。

对网页进行缩放直到文字小得无法阅读。
以合适的尺寸只显示网页中的一小部分内容。

viewport 太窄，以至于不能正常展示你的 CSS 布局（不管是固定宽度、百分比或流式布局）。

两个 viewport

明显的解决方案是使 viewport 变宽一些，这样就产生了两个视口：

layout viewport（布局视口）
visual viewport（视觉视口）

George Cummins在Stack Overflow上给出了最佳解释：

把 layout viewport 想像成为一张不会改变大小和形状的大图。
现在想像你有一个小一些的框子，你通过它来看这张大图。（可以理解为「管中窥豹」），这个小框子的周围被不透明的材料所包围，遮挡住了你的视线，你只能看到这张大图的一部分。
你通过这个框子所能看到的大图的部分就是 visual viewport。
通过远离（缩小）/ 靠近（放大）这种方式，你可以调整所能看大图的内容多少，但是大图（layout viewport）的大小和形状永远不会变。

layout viewport

问题的本质在于手机屏幕的 viewport 太窄，所以 Apple 提出创建一个虚拟的 layout viewport 来解决这个问题。

这个 layout viewport 的分辨率接近于 PC 显示器（Apple 将其定义为 980px，Android也基本都是 980px?）。

由于宽度趋近，CSS 只需要像在 PC 上那样渲染页面就行，原有的页面结构不会被破坏。

visual viewport

visual viewport 是页面当前显示在屏幕上的部分，可以简单的认为是手持设备物理屏幕的可视区域。
可以通过滚动来改变所看到的页面的部分，或者通过缩放来改变 visual viewport 的大小。

无论怎样，CSS 布局，尤其是百分比宽度，是以 layout viewport 做为参照系来计算的，它被认为要比 visual viewport 宽。

缩放

很显然两个 viewport 都是以 CSS 像素度量的。
但是当进行缩放（如果你放大，屏幕上的 CSS 像素会变少）的时候，visual viewport的尺寸会发生变化，layout viewport的尺寸仍然跟之前的一样。

如果不是这样，缩放时layout viewport尺寸发生变化，那你的页面将会像百分比宽度被重新计算一样而经常被重新布局。

理解这两个 viewport

大部分移动浏览器在初始情况下，会以完全缩小的模式来展示任何页面，此时 visual viewport = layout viewport。

当用户放大的时候 layout viewport 尺寸保持不变。

完全缩小模式下 旋转手机至横屏时，visual viewport 会发生变化，但浏览器通过轻微的放大来适配这个新的朝向，所以 layout viewport 又和 visual viewport 一样宽了。
这对 layout viewport 的高度会有影响，现在的高度比肖像模式（竖屏）要小。但是web开发者不在乎高度，只在乎宽度。

度量 layout viewport

获取方法：document.documentElement.clientWidth/Height
意义： layout viewport 的尺寸。
度量单位： CSS 像素。
浏览器错误： 完全支持。

朝向会对高度产生影响，但对宽度不会产生影响。

度量 visual viewport

获取方法： window.innerWidth/Height
意义： visual viewport 的尺寸。
度量单位： CSS 像素。
浏览器错误： Apple 完全支持，其他移动设备问题比较多。

滚动距离 scrolling offset

获取方法： window.pageX/YOffset
意义： 滚动距离，与 visual 相对于 layout 的距离一样。
度量单位： CSS 像素。
浏览器错误： 完全支持iPhone、Android。

度量`<html>`元素

跟 PC 上一样，document.documentElement.offsetWidth/Height 提供了以 CSS 像素为单位的<html>元素的整个尺寸，完全支持 iPhone 和 Android。

事件坐标

pageX/Y仍然是相对于页面，以 CSS 像素为单位。
clientX/Y是相对于visual viewport来计算，以CSS像素为单位。
screenX/Y是相对于屏幕来计算，以物理像素为单位。（这和clientX/Y用的参照系是一样的）

媒体查询

媒体查询和其在 PC 上的工作方式一样。
width/height 使用 layout　viewport做为参照物，并且以 CSS像素进行度量。
device-width/height 使用设备屏幕，以设备物理像素进行度量。

viewport meta标签

获取方法： <head> 下的 <meta> 标签
意义： 设置 layout viewport 的宽度。
度量单位： CSS 像素。
浏览器错误： 完全支持iPhone、Android、IE等。

假设你创建了一个简单的页面，并且没有给你的元素设置「宽度」，那么现在它们会被拉伸来填满 layout viewport 宽度的100%。大部分浏览器会进行缩放从而在屏幕上展示整个 layout viewport，产生下面这样的效果：

所有用户将会立刻进行放大操作，这个是工作的，但是大部分浏览器完好无缺的保持元素的宽度，这使得文字很难阅读（不停缩放、左右滑动等）。

你应该尝试设置html {width: 320px}，现在<html>元素收缩了，并且其他元素现在使用的是 320px 的 100%。这在用户进行放大操作的时候有用（无需左右滑动），但是在初始状态是没用的，你什么都看不清。

为了绕开这个问题（初始状态无效、需要手动放大）苹果发明了viewport　meta标签。
当你设置的时候，你就设置了 layout viewport 的宽度为320px。现在页面的初始状态也是正确的：

viewport meta 标签的6个属性

width 设置layout viewport 的宽度，正整数或"width-device"。
initial-scale 设置页面的初始缩放值，数字且可带小数。
minimum-scale 允许用户缩放的最小倍数值，数字且可带小数。
maximum-scale 允许用户缩放的最大倍数值，数字且可带小数。
height 设置 layout viewport 的高度，但并不被支持。
user-scalable 是否允许用户进行缩放，值为"no"或"yes"。

比如：<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0"/>

ideal viewport（完美视口）

<meta name="viewport" content="width=device-width, initial-scale=1.0"/>

device-width将 layout viewport 设置为屏幕的宽度，单位是 CSS 像素。

在指定了initial-scale=1.0时，可省略width=device-width

前端开发模式演变

简单明快的早期时代（Web 1.0 时代）

非常适合创业型小项目，不分前后端，经常 3-5 人搞定所有开发。
页面由 JSP、PHP 等工程师在服务端生成，浏览器负责展现，展现的控制在 Web Server 层。

BADJSP 里揉杂大量Java业务代码，代码的可维护性差。
BAD前后端没有合理分工。

后端为主的 MVC 时代

代码可维护性得到明显好转，MVC 是个非常好的协作模式，从架构层面让开发者懂得什么代码应该写在什么地方。
为了让 View 层更简单干脆，可以选择 Velocity、Freemaker 等模板，使得模板里写不了 Java 代码，前后端分工更清晰。

BAD前端开发重度依赖开发环境。
- 前端写 demo，后端套模板，套完后还需要前端确定，来回沟通调整的成本比较大。
- 前端负责浏览器端的所有开发和服务器端的 View 层模板开发，不足就是前端开发重度绑定后端环境。

BAD前后端职责依旧纠缠不清。
- 模板引擎功能强大，变量、逻辑、宏等特性，依旧可以通过拿到的上下文变量来实现各种业务逻辑。
- 存在灰色地带 - Controller。页面路由等功能本应该是前端最关注的，但却是由后端来掌控。
- Controller 本身与 Model 往往也会纠缠不清，看了让人咬牙的代码经常会出现在 Controller 层。

2004 年 Gmail 像风一样的女子来到人间，很快 2005 年 Ajax 正式提出，加上 CDN 开始大量用于静态资源存储，于是出现了 JavaScript 王者归来的 SPA （Single Page Application 单页面应用）时代。

Ajax 带来的 SPA 时代

前后端的分工非常清晰，前后端的关键协作点是 Ajax 接口。
复杂度从服务端的 JSP 里移到了浏览器的 JavaScript，浏览器端变得很复杂。
类似 Spring MVC，这个时代开始出现浏览器端的分层架构，如 Backbone。

不足前后端接口的约定。
- 如果后端接口一塌糊涂，如果后端的业务模型不够稳定，那么前端开发会很痛苦。

不足前端开发的复杂度控制。
- 大量 JS 代码的组织，与 View 层的绑定等，都不是容易的事情。典型的解决方案是业界的 Backbone。

Backbone的Model把服务器端的数据模型映射到浏览器端，绑定数据验证机制，并与相应的REST操作绑定。
Backbone的Model没有与UI视图数据绑定，而是需要在JS中自行操作DOM来更新或读取UI数据。

前端为主的 MV* 时代

前后端分工很清晰，可以让开发并行，测试数据的模拟不难，前端可以本地开发，后端则可以专注于业务逻辑的处理。
前端开发的复杂度可控，前端代码很重，但合理的分层（比如Templates、Controllers、Models等），让前端代码能各司其职。
后端一套Server API，多端使用（Web、移动APP等）
部署相对独立，产品体验可以快速改进。
不足代码不能复用。
- 后端依旧需要对数据做各种校验，校验逻辑无法复用浏览器端的代码。如果可以复用，那么后端的数据校验可以相对简单化。

不足全异步，对SEO（搜索引擎优化）不利，往往还需要服务端做同步渲染的降级方案。
- 能够被搜索引擎抓取的内容，需要有完整的 HTML 和内容。

不足性能并非最佳，特别是移动互联网环境下。
- 性能优化如果只在前端做空间非常有限，通常需要与后端配合，但由于后端框架限制，我们很难使用Comet、Bigpipe等技术方案来优化性能。

不足SPA 不能满足所有需求，依旧存在大量多页面应用。URL Design 需要后端配合，前端无法完全掌控。

Node 带来的全栈时代

Front-end UI layer 处理浏览器层的展现逻辑。通过 CSS 渲染样式，通过 JavaScript 添加交互功能，HTML 的生成也可以放在这层，具体看应用场景。

Back-end UI layer 处理路由、模板、数据获取、cookie 等。通过路由，前端终于可以自主把控 URL Design，这样无论是单页面应用还是多页面应用，前端都可以自由调控。

通过 Node，Web Server 层也是 JavaScript 代码，这意味着部分代码可前后复用。

需要 SEO 的场景可以在服务端同步渲染。由于异步请求太多导致的性能问题也可以通过服务端来缓解。

Bigpipe:

http://www.ifeenan.com/javascript/2014-07-20-%E5%89%8D%E7%AB%AF%E9%A1%B5%E9%9D%A2%E4%BC%98%E5%8C%96%E4%B9%8BBigpipe/

挑战前端需要对服务端编程有更进一步的认识，比如 network/tcp等知识的掌握。

挑战架构上多了一层 Node，提升了系统的复杂度和风险，也肯定会有一定的性能损耗。由此带来的损失，一定要从其他方面弥补回来。
- 通过优化通讯方式、通讯协议，尽可能把损耗降到最低。
- 代理多个异步请求，实现 Bigpipe。
- ......

挑战对部署、运维层面的熟练了解，需要更多知识点和实操经验，无法一蹴而就。

挑战大量历史遗留问题如何过渡，这可能是最大的阻力。（如何把一个已有的项目，过渡为这种模式？）

一些软件设计的原则：http://coolshell.cn/articles/4535.html

前端开发模式总结

模式没有好坏高低之分，只有合不合适，在选择时需要考虑团队人员的实际情况。

Ajax 给前端开发带来了一次质的飞跃，Node 很可能是第二次。（BTW，当只有 Node 才能解决你的痛点时才考虑引入）

SoC（关注点分离）是一条伟大的原则。上面种种模式，都是让前后端的职责更清晰，分工更合理高效。

还有个原则，让合适的人做合适的事。比如 Web Server 层的 UI Layer 开发，前端是更合适的人选。

思考

为什么需要前后端分离？
前后端分离为什么需要 Node ？

页面性能优化

Best Practices and Rules

Content
Server
Cookie
CSS
JavaScript
Images

Content

Make Fewer HTTP Requests

减少 http 请求数

DNS系统是从域名到 IP 地址映射系统，DNS 解析一次大约20-120毫秒，在这个时间内浏览器不能下载任何东西。

Reduce DNS Lookups

减少 DNS 解析时间

DNS 解析如果被缓存可提高性能，内网的 DNS 缓存服务器、用户的操作系统、甚至大部分浏览器都有自己的 DNS 缓存。

当浏览器和操作系统的 DNS 缓存都为空时，这时 DNS 解析所花费的时间是由你的网页中有多少个独立域名决定的，这些域名包括网页的url、图片、js、css、flash等。

减少独立域名的个数可以减少 DNS 解析的时间，但会潜在的减少并行下载的数量。怎么平衡呢？建议把独立域名限制在2-4个之间。

Avoid Redirects

避免使用重定向

使用重定向会降低用户体验，它会使加载延时。

Make Ajax Cacheable

缓存 ajax

Post-load/Preload Components

延迟/提前加载模块

Post-load只加载当前页面需要的模块资源，以最快的速度展现当前页面，提升用户体验。

Preload利用浏览器的空闲时间，加载下一页面将要需要的模块资源，这样下一页面将更快速的展现给用户。

Reduce the Number of DOM Elements

减少dom的element数量

查看dom的元素数 document.getElementsByTagName('*').length

Split Components Across Domains

把资源分散到多个域名下

把资源分散到多个域名下可以尽量多的并行下载，但是不要超过2-4个域名，因为 DNS 解析会也有一定的损耗。

Avoid 404s

避免404

降低用户体验，浪费服务器资源。
当外部js文件出现404时，会阻塞并行下载。

Server

Use a Content Delivery Network

使用 CDN 内容分发网络系统

最终用户80-90%的时间是花在下载页面的图片、css、js、flash等上的，这是性能的黄金法则。

静态内容使用 cdn 分发后可以使最终用户节约20%或者更多的响应时间。

Cache-Control: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=zh-cn#cache-control

Add an Expires or a Cache-Control Header

为http头添加Expires或Cache-Control

Gzip Components

使用 Gzip 传输部件

自 http/1.1 开始，http 头开始支持压缩传输：Accept-encoding:gzip,deflate

Server 能通过 Content-Encoding 头来通知浏览器内容所使用压缩格式：Content-Encoding:gzip

Gzip 的压缩比大约为 70%，但不要对图片与pdf格式的文件来gzip，因为它们已被压缩过了。（你如果再压缩，不只浪费cpu还会增大文件的大小。）

Use GET for Ajax Requests

Ajax 请求使用 Get 方法

POST 方法在浏览器上实现时需要两个步骤：第一步发送 header，第二步才是发送数据。而 Get 方法只需要一个 TCP 包（除非你的 Cookie 特别大）。

当你只是想请求查询数据时，一定要使用 Get 方法，这也正好符合 HTTP 规范。

Avoid Empty Image src

避免 src 为空的 Image 元素

浪费用户时间。
浪费服务器资源。

Cookie

Reduce Cookie Size

减小 Cookie 长度

客户端在跟服务端通信时，会带上Cookie信息，所以减小 Cookie 长度，可以一定程度的降低响应时间。

Use Cookie-free Domains for Components

把静态资源放在无 Cookie 的域名上

如果你的战点是 www.example.org，你可以使用 static.example.org 做为你静态资源域名。

如果你已经把 Cookie 设在了顶级域名 example.org 下而不是 www.example.org，那请求static.example.org 时也会带 Cookie 信息。

CSS

Put Stylesheets at Top

把 css 放在 head 里

把 css 放在 head 里后可以使网页渲染逐步进行，让网页尽快显示给用户。

把css放入底部，那它就会阻断浏览器的渲染。很多浏览器会阻断页面的渲染以避免由于样式被改而重新渲染网页。

Avoid CSS Expressions

避免在 css 中使用 js 表达式

Background-color:expression((new Date).getHours()%2?'#000':'#fff');

网页渲染或者窗口缩放时 expression 会被重新计算。
页面滚动或者鼠标移动时都会重新计算。

Choose over @import

加载 css 时，要用 link，不要用 @import

在 IE 上用 @import 的作用与把放入网页底部的作用是一样的，所以不要使用。

Javascript

Put Scripts at Bottom

把 js 放在底部

如果一个 js 脚本可以被推迟加载，那就把它放到页面最下面吧，这样会让你的页面以最快的速度展现给用户。

Make JavaScript and CSS External

把 js 和 css 放入外部文件

增加了 http 请求次数，但同时也可被浏览器缓存。所以问题的关键在于，css/js 如果被缓存后被再次请求的频率。

多页面通用的 css/js 放入外部文件，页面独有的则采取内联的方式。

或者，把 css/js 嵌入到 html 中，当网页下载完成后再动态的下载外部的css/js。

Minify JavaScript and CSS

最少化（压缩） js/css 源码

去掉源码中的不必要的字符，可以减少源码量，比如空格、换行符、tab、注释等。

通过混淆（牺牲了代码可读性）和 Gzip 还可以大幅减小 js/css 源码的大小。

Remove Duplicate Scripts

去除重复的 js 脚本

如果一个页面对同一个js文件加载了两次，会浪费 http 请求数与 js 的执行效率。

增加相应的 js 管理机制（版本检测和依赖检查），在上线前及时发现重复加载的 js 文件。

Minimize DOM Access

减少 DOM 查询

Image

Optimize Images

优化图片 - 无损压缩

Optimize CSS Sprites

优化雪碧图

横着排而不要竖着排，这样会使文件更小。
图片间不要留大的空隙。

Do Not Scale Images in HTML

不要在html里缩放图片

当你需要100×100的图片时，不要使用500×500的图片进行缩放，直接提供一张100×100图片就好。

Make favicon.ico Small and Cacheable

让 favicon.ico 小一点儿（1K以下），并且可缓存（缓存几个月）

favicon.ico 是非常邪恶的，因为即使你的站点没有这个文件，浏览器依然会请求这个文件，为了避免返回404，你最好还是提供一个。

而且请求时会带上 Cookie信息，且 IE 会在别的资源下载前先请求这个文件。

检测工具

PageSpeed Insights

YSlow

Chrome DevTools

Frontend Knowledge Structure

Frontend Books

Commit message

了解更多

mambat / blog

前端入门 #9

从模块化谈起

模块的定义

模块的特征

前端为什么要模块化

Javascript模块化编程

原始写法

对象写法

立即执行函数表达式写法

放大模式

宽放大模式

输入全局变量

思考

为什么需要模块化规范

Javascript模块化规范

CommonJS

AMD - Asynchronous Module Definition

CMD - Common Module Definition

UMD - Universal Module Definition

ES6 Module

不仅仅是Javascript

Webpack

Webpack是什么

Webpack的特点

在项目中使用Webpack

Hot Reload（HMR）

Mock Server

Long-Term Caching

output.filename

Option 1: One hash for the bundle

Option 2: One hash per chunk

Code Splitting

CommonsChunkPlugin

UglifyJsPlugin

HtmlWebpackPlugin

Loaders

响应式设计

什么是响应式设计

适配不同终端

响应式布局

响应式图片

移动端适配

一些概念

物理像素（Physical Pixel）

设备独立像素（Density-Independent Pixel）

设备像素比（Device Pixel Ratio）

位图像素（Bitmap Pixel）

以 iPhone6s 为例

用一张图来说明

图片模糊

图片缺少锐利度

图片显示 Demo

图片高清适配方案

布局适配方案

rem 是什么

还得聊聊视觉稿

rem 方案原理

CSS方式动态改变根节点 html 的 font-size

JS方式动态改变根节点 html 的 font-size

同时使用CSS方式和JS方式

如何在 CSS 中还原视觉稿的真实宽高

如何自动适配 iPhone4s

px2rem 自动化

发现问题了吗？

页面缩放

字体大小问题

字体大小的统一和缩放

Retina下，border: 1px; 问题

viewport

先聊聊 PC 浏览器下的 viewport

缩放

屏幕尺寸

窗口尺寸

滚动距离

viewport的概念

从技术上来说

从理论上来说

度量 viewport

两个属性对

`CSS方式`动态改变根节点 html 的 font-size

`JS方式`动态改变根节点 html 的 font-size

同时使用`CSS方式`和`JS方式`

度量`<html>`元素

度量`<html>`元素