IT瘾网页推荐

从输入URL到页面展示过程：深入解析网络请求与渲染

Thu, 31 Aug 2023 09:33:35 CST

项目实战:AI文本 OCR识别最佳实践

AI Gamma一键生成PPT工具直达链接

玩转cloud Studio 在线编码神器

玩转 GPU AI绘画、AI讲话、翻译,GPU点亮AI想象空间

资源分享

史上最全文档AI绘画stablediffusion资料分享

AI绘画关于SD,MJ,GPT,SDXL百科全书

AI绘画 stable diffusion Midjourney 官方GPT文档 AIGC百科全书资料收集

  「java、python面试题」来自UC网盘app分享，打开手机app，额外获得1T空间
https://drive.uc.cn/s/2aeb6c2dcedd4
AIGC资料包
https://drive.uc.cn/s/6077fc42116d4
https://pan.xunlei.com/s/VN_qC7kwpKFgKLto4KgP4Do_A1?pwd=7kbv#

引言

在当今互联网时代，我们每天都会通过浏览器访问各种网页。但是，你是否曾经思考过在我们输入一个URL后，浏览器是如何加载并显示页面的呢？这背后涉及到一系列复杂的技术和过程。本文将带领大家深入了解从输入URL到页面展示的过程，并给出相应的代码示例，让我们一起探索这个神奇而又复杂的世界。

1. 网络请求的发起

通过浏览器输入URL后，浏览器会根据协议类型（如HTTP或HTTPS）向服务器发起请求。这个过程可以通过下面的代码示例来体现：

  const url = "https://example.com";
fetch(url)
  .then(response => response.text())
  .then(data => {
    console.log(data);
  })
  .catch(error => {
    console.error(error);
  });

在代码中，我们使用了JavaScript的fetch API来发起网络请求，并将服务器响应转换为文本输出到控制台。

2. DNS解析

在发送网络请求前，浏览器首先需要将URL中的域名解析成对应的IP地址。这个过程称为DNS解析。下面是一个简化版的DNS解析示例代码：

  const dns = require('dns');

const domain = "example.com";
dns.resolve(domain, 'A', (err, addresses) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(addresses);
});

上述代码中，我们使用Node.js的 dns模块来进行DNS解析，并输出解析得到的IP地址。

3. 建立TCP连接

经过DNS解析后，浏览器会尝试与服务器建立TCP连接。这个过程涉及到三次握手，确保数据能够安全可靠地传输。以下是一个简化的TCP连接代码示例：

  const net = require('net');

const serverIP = '192.168.0.1';
const port = 80;

const client = new net.Socket();
client.connect(port, serverIP, () => {
  console.log('TCP connection established');
});

在上述代码中，我们使用Node.js的 net模块创建了一个TCP socket，并通过 connect方法与服务器建立连接。

4. 发送HTTP请求

TCP连接建立后，浏览器会构建HTTP请求并发送给服务器。以下是一个简化的HTTP请求发送代码示例：

  const http = require('http');

const options = {
  hostname: 'example.com',
  port: 80,
  path: '/',
  method: 'GET'
};

const req = http.request(options, res => {
  console.log(`HTTP response status code: ${res.statusCode}`);
});

req.end();

在上述代码中，我们使用Node.js的 http模块创建了一个HTTP请求，并通过 request方法发送给服务器。

5. 服务器处理请求

服务器收到浏览器发送的HTTP请求后，会根据请求的内容进行相应的处理。这个过程通常包括路由解析、数据查询等操作。下面是一个简化的服务器处理请求的代码示例：

  const http = require('http');

const server = http.createServer((req, res) => {

  if (req.url === '/') {

res.writeHead(200, { 'Content-Type': 'text/plain' });

res.end('Hello, World!');

  } else if (req.url === '/about') {

res.writeHead
(200, { 'Content-Type': 'text/html' });
    res.end('<h1>About Page</h1>');
  } else {
    res.writeHead(404, { 'Content-Type': 'text/plain' });
    res.end('Page not found');
  }
});

server.listen(80, () => {
  console.log('Server running at http://localhost:80/');
});

在上述代码中，我们使用Node.js的 http模块创建了一个简单的HTTP服务器。根据请求的URL路径，服务器会返回不同的响应内容。

6. 接收响应数据

当服务器处理完请求并生成响应后，浏览器会接收到响应数据。这个过程在浏览器内部进行，我们无法直接访问其代码。浏览器会将响应数据存储在缓存中，并准备进行后续的解析和渲染。

7. 解析HTML

浏览器接收到响应数据后，会对HTML进行解析，构建出一棵DOM树。这个过程包括识别HTML标签、属性、文本等，并将其转换为可以操作的数据结构。以下是一个简化的HTML解析代码示例：

  const parser = new DOMParser();
const htmlString = '<html><head><title>Hello, World!</title></head><body><h1>Welcome</h1></body></html>';
const doc = parser.parseFromString(htmlString, 'text/html');

console.log(doc.title); // Output: "Hello, World!"
console.log(doc.body.innerHTML); // Output: "<h1>Welcome</h1>"

在上述代码中，我们使用JavaScript的DOMParser来解析HTML字符串，并通过操作解析后的DOM树来获取需要的信息。

8. 构建DOM树

浏览器在解析HTML后，会根据标签之间的层次关系构建一棵DOM树。每个HTML元素都会被转换为DOM节点，并按照其在HTML中的嵌套关系形成父子节点的层次结构。以下是一个简化的DOM树构建示例：

  const htmlString = '<html><head><title>Hello, World!</title></head><body><h1>Welcome</h1></body></html>';
const doc = new DOMParser().parseFromString(htmlString, 'text/html');

console.log(doc.documentElement); // Output: HTML元素节点
console.log(doc.documentElement.childNodes.length); // Output: 2，包含<head>和<body>
console.log(doc.documentElement.childNodes[1].childNodes[0]); // Output: <h1>Welcome</h1>

在上述代码中，我们使用DOMParser来解析HTML字符串，并通过访问 documentElement和 childNodes属性来获取DOM树的节点信息。

9. 渲染页面

经过DOM树的构建后，浏览器会根据DOM树的结构和样式信息对页面进行渲染。这个过程包括布局计算、绘制元素、加载外部资源等操作，最终将页面显示给用户。由于浏览器的渲染过程非常复杂，我们无法直接操作其渲染引擎。但是，我们可以通过调试工具来观察页面的渲染情况。

10. 用户交互与动态效果

在页面渲染完成后，用户可以与页面进行交互，并享受丰富的动态效果。这包括点击链接、提交表单、触发事件等操作。JavaScript在此起到了重要的作用，它可以监听用户的操作并相应地更新页面内容或执行相应的逻辑。

11. 性能优化

为了提供更好的用户体验，我们需要关注性能优化。这包括减少网络请求次数、压缩资源文件、使用缓存等策略。同时，优化JavaScript和CSS的编写方式也可以提升页面的加载速度和响应性能。

使用 OpenAi Api 在本地搭建一个 ChatGPT 网页版

Wed, 15 Mar 2023 20:41:00 CST

前言

之前 ChatGPT 在网络上大火，由于很多开发者使劲薅羊毛，OpenAi 也撑不住了，对于新注册账号只有5美刀的免费额度了，网页版也各种限制。OpenAi 使用了 CloudFlare 的防火墙，而我使用的 IP 是美西的机房，没有任何意外地被屏蔽了。

为了方便我继续使用，我在移动端设备使用 baye 大佬开发的 OpenCat 完美解决网页版无法使用的问题。

桌面端上呢，我找了半天，最终找到这个项目： chatgpt-web，简单部署安装了一下，完全符合我现阶段的使用需求，绕开 CloudFlare 的防火墙限制，使用OpenAi Api 直接获取问题答案。

本文将会教你如何通过api在本地部署一个独属于你的 ChatGPT。

部署流程

首先要确认的一点是你的局域网环境是否可以访问 OpenAi 的网站，如果无法访问的话，请先扶墙再回来看这篇文章进行下一步的部署操作。

获取API key

可以参考这篇文章《 OpenAI 的 ChatGPT 超简易注册攻略！》注册，登录后在下面这个链接内即可创建的你api key：

https://platform.openai.com/account/api-keys

页面应该如下图所示，创建好了复制保存下来。因为它只会显示一次。

docker部署

进入 Linux 系统的命令行界面，首先要确保 docker 可用，如果没有安装过可以使用以下代码安装。在不同的系统中安装方法可能不一样，以下为 Ubuntu 下的安装方法。

    sudo apt-get install docker-compose

接下来需要创建 .env ，将你的 key 填写到引号内，然后保存。

    OPENAI_API_KEY="前面你获取到的 OpenAI API KEY"

再创建 docker-compose.yml 配置文件，保存即可。

    version: "3.3"     
services:     
  chatgpt:     
    image: sheepgreen/chatgpt-web #如果是arm架构，需要改成chatgpt-web:arm     
    container_name: webchat     
    volumes:     
- ./.env:/chatgpt-web/.env     
    ports:     
- "8888:8088" #8088为容器内部端口，不可更改；8888为外部映射端口，可自行更改     
    restart: always

最后输入命令 docker-compose up -d 即可，等待命令行跑完即可启动成功。

测试

打开 http://ip:port/chat 即可访问我们刚刚创建的ChatGpt-web了。

我们可以测试一下它：

后记

在使用 OpenAi Api 搭建 ChatGPT 网页版的过程中，我深深感受到了技术对于我们生活的影响和改变。ChatGPT 不仅仅是一款智能对话系统，更是一种开发人工智能技术的思路和方法。

这个项目也让我深入地了解到了人工智能技术的存在和发展。从机器学习、自然语言处理到深度学习、神经网络等多个领域，人工智能技术正在不断地革新和进步。通过这次实践，我更加深信，未来的世界一定会离不开人工智能技术的支持和应用。

最后，我觉得，在不远的将来，低端程序员就会像现在建筑行业的搬运工一样会越来越少，只不过一个是被机械装置取代，一个是被人工智能取代。而会驱使人工智能，就像是会开挖掘机一样，至少不会被时代的浪潮给拍死在岸上。

如何优雅的实现网页多主题风格换肤功能？

Wed, 22 Feb 2023 10:00:00 CST

海阔凭鱼跃，天高任鸟飞。好久不见！我是猫力Molly

对于网页换肤，例如最常见的深色、浅色风格已经是很常见的一个需求了。一直以来也有很多的实现方案，这里我主要介绍一下基于 CSS variable的实现方式

简单列举下一些其它实现方式

1、把不同风格样式写到不同的类名下面，通过切换类名来实现换肤

这种方式没啥明显的优点，只是单纯的实现了此需求。反而增加了css样式文件代码冗余且会造成大量重复代码，样式代码不利于拓展维护，且开发效率低下

2、实现多套主题样式文件，通过 link 标签动态加载不同的样式文件

这种方式的优点大概是做到了按需加载吧，但同时也造成了需要拷贝大量重复代码来单独修改，也算是做到了样式隔离，相比上一种方式稍稍提高了一点可维护性吧

在多个样式文件切换的时候，可能会有加载延迟。这时候可以考虑使用 alternate 来解决

3、通过less或sass的变量方式实现

这种方式我们可以将所有风格变量抽离出来，在样式代码中直接使用该变量，是一种比较推荐的方式。极大提高了代码的拓展性和维护性

CSS variable的实现方式

如图所示，目前主流浏览器都已经支持 css variable，我们尽管放心使用

CSS variable 允许我们在 css 里面声明变量，在变量前加上两根小横线即可（--）

  body {
  --foo: #000;
  --bar: #fff;
}

需要注意的是 css vars变量声明，区分大小写 --foo 与 --Foo 是两个不同的变量

var() 函数

使用var()函数来读取变量

  p{
    color:var(--foo)
}

var()函数支持第二个参数，用于表示变量的默认值，如果变量值不存在，则以默认值为准

  p{
    color:var(--fooo, #ccc)
}

关于 var()函数此处不做过多赘述，详情请查阅官方文档

方案落地

大致思路：不管深色或是浅色风格，我们都可以把它视作一个个主题。把每个主题的颜色值、盒子宽高、图片地址等抽离为一个字典对象结构。一个主题对应一个配置文件，再通过切换配置文件来实现主题风格的变化

一、和UI设计师沟通好各主题的色阶

一个主题对应一份配置文件，所以我们需要提前和UI设计师沟通好各主题对应的色阶，字号，一些通用样式规则等

css vars变量名称是不变的，变量值随着主题的切换而发生改变

我的UI同事使用的是 figma，然后我发现 figma 右侧的信息栏里面有颜色编号，正好可以使用这个来当做变量名称。在编码阶段，看到这个编号，就知道用什么变量名了，非常方便。

如果你的UI同事使用的是别的设计工具，最好也是提前约定好变量名，使其大家都方便

二、将各主题色阶抽离为一个字典对象

dark.js

  export default {
  '--grey900': '#EBEEF5',
  '--grey600': '#A7ABC0',
  '--grey500': '#72768D',
  '--grey400': '#5D6177',
  '--grey300': '#404759',
  '--grey200': '#2C323E',
  '--grey100': '#282B32',
  '--grey50': '#171B22',
  '--grey0': '#222730',
  ...
}

white.js

  export default {
  '--grey900': '#1F2429',
  '--grey600': '#646C73',
  '--grey500': '#8D9399',
  '--grey400': '#C3C7CB',
  '--grey300': '#E4E6E7',
  '--grey200': '#EFF0F1',
  '--grey100': '#F4F5F6',
  '--grey50': '#F8F9FA',
  '--grey0': '#FFFFFF',
  ...
}

三、通过js设置style变量

这里我们需要用到 document.body.style 的api

  // 设置变量
document.body.style.setProperty('--foo', '#666')

// 读取变量
document.body.style.getPropertyValue('--foo')

// 删除变量
document.body.style.removeProperty('--foo')

遍历变量字典对象，根据不同主题，给网页设置对应变量

  import C from '@/utils/cssVarMap'

setCssVar (flag) {
  const varList = Object.entries(flag ? C.white : C.dark)
  varList.forEach(([key, val]) => {
    document.body.style.setProperty(key, val)
  })
}

至此，我们已经完成根据不同主题设置不同主题变量了，可以愉快的在样式文件里面使用 css vars

这种方式操作简单，且极大的提高了代码的拓展性和维护性。之后再有别的主题，也不过是多增加一份配置文件而已，不会增加额外的副作用。

举一反三

1、结合媒体查询

通过结合媒体查询，我们可以实现更复杂的交互场景

  body {
  --foo: #fff
}

p {
    color: var(--foo)
}

@media screen and (min-width: 768px) {
  body {
    --foo: #000
  }
}

2、结合js业务逻辑

在一些特殊需求场景下，我们可以结合js业务逻辑，动态追加或编辑 css vars

  const docStyle = document.documentElement.style;

document.addEventListener('mousemove', (e) => {
  docStyle.setProperty('--foo', e.clientX);
});

3、存储一些信息

既然是声明变量，那么就有存储信息的功能。我们可以试着将一些信息存储在 css vars 里面，再通过 document.body.style.getPropertyValue('--foo')去读取使用。不过大部分场景应该使用不到这种方法，也算是提供一种思路吧。

css vars是个潜力股，一起来挖掘它更多巧妙的用法吧

感谢

欢迎关注我的个人公众号前端有猫腻每天给你推送新鲜的优质好文。回复 “福利” 即可获得我精心准备的前端知识大礼包。愿你一路前行，眼里有光！

感兴趣的小伙伴还可以加我微信：猫力molly或前端交流群和众多优秀的前端攻城狮一起交流技术，一起玩耍！

网页音视频通话大火，WebRTC 正式成为 W3C 和 IETF 标准

Sun, 14 Feb 2021 23:29:44 CST

IT之家2月14日消息外媒 Neowin 报道，万维网联盟 (W3C)和互联网工程任务组 (IETF)宣布，网络实时通信 (WebRTC)现在是一个正式的网络标准，可以在网络上任何地方进行音频和视频通信。虽然 WebRTC 才刚刚成为一个标准，但它已经被流行的网络浏览器支持多年。

IT之家获悉，在技术层面上，WebRTC 是一个框架，允许开发人员将点对点的音频和视频聊天添加到他们的项目中。如果你曾经使用过 Facebook Messenger、Discord 或其他众多服务来进行视频或音频通话，那么你已经使用过 WebRTC。

IETF 主席 Alissa Cooper 表示，

“IP 语音和视频彻底改变了人们在世界各地的通信方式。将这些技术整合到网络平台中，极大地扩大了它们的影响力。得益于 IETF 和 W3C 之间的密切合作，使这些技术标准化。WebRTC 使数十亿人在 COVID-19 疫情期间能够相互联系和接触，无论设备或地理环境如何。”

通过对 WebRTC 技术进行标准化，任何想要在未来实现该功能的软件项目都将有一套明确的指导方针，他们可以遵循这些指导方针，以确保软件的 WebRTC 实现可以正确完成，并满足所有要求。

使用Node.js爬取任意网页资源并输出高质量PDF文件到本地~

Fri, 14 Jun 2019 23:55:03 CST

本文适合无论是否有爬虫以及 Node.js基础的朋友观看~

需求：

使用 Node.js爬取网页资源，开箱即用的配置
将爬取到的网页内容以 PDF格式输出

如果你是一名技术人员，那么可以看我接下来的文章，否则，请直接移步到我的 `github`仓库，直接看文档使用即可

仓库地址: 附带文档和源码,别忘了给个 `star`哦

本需求使用到的技术： `Node.js`和 `puppeteer`

puppeteer 官网地址: puppeteer地址
Node.js官网地址: 链接描述
Puppeteer是谷歌官方出品的一个通过 DevTools协议控制 headless Chrome的 Node库。可以通过Puppeteer的提供的api直接控制Chrome模拟大部分用户操作来进行UI Test或者作为爬虫访问页面来收集数据。
环境和安装
Puppeteer本身依赖6.4以上的Node，但是为了异步超级好用的 async/await，推荐使用7.6版本以上的Node。另外headless Chrome本身对服务器依赖的库的版本要求比较高，centos服务器依赖偏稳定，v6很难使用headless Chrome，提升依赖版本可能出现各种服务器问题（包括且不限于无法使用ssh），最好使用高版本服务器。（建议使用最新版本的 Node.js）

小试牛刀，爬取京东资源

  const puppeteer = require('puppeteer'); //  引入依赖  
(async () => {   //使用async函数完美异步 
    const browser = await puppeteer.launch();  //打开新的浏览器
    const page = await browser.newPage();   // 打开新的网页 
    await page.goto('https://www.jd.com/');  //前往里面 'url' 的网页
    const result = await page.evaluate(() => {   //这个result数组包含所有的图片src地址
        let arr = []; //这个箭头函数内部写处理的逻辑  
        const imgs = document.querySelectorAll('img');
        imgs.forEach(function (item) {
            arr.push(item.src)
        })
        return arr 
    });
    // '此时的result就是得到的爬虫数据，可以通过'fs'模块保存'
})()

  复制过去 使用命令行命令 ` node 文件名 ` 就可以运行获取爬虫数据了 
这个 puppeteer 的包 ，其实是替我们开启了另一个浏览器，重新去开启网页，获取它们的数据。

上面只爬取了京东首页的图片内容，假设我的需求进一步扩大，需要爬取京东首页

中的所有 <a> 标签对应的跳转网页中的所有 title的文字内容，最后放到一个数组中。

我们的 async函数上面一共分了五步，只有 puppeteer.launch() ,

browser.newPage(), browser.close() 是固定的写法。

page.goto 指定我们去哪个网页爬取数据，可以更换内部url地址，也可以多次

调用这个方法。

page.evaluate 这个函数，内部是处理我们进入想要爬取网页的数据逻辑

page.goto和 page.evaluate两个方法，可以在 async内部调用多次，

那意味着我们可以先进入京东网页，处理逻辑后，再次调用 page.goto这个函数，

注意，上面这一切逻辑，都是 puppeteer这个包帮我们在看不见的地方开启了另外一个
浏览器，然后处理逻辑，所以最终要调用 browser.close()方法关闭那个浏览器。

这时候我们对上一篇的代码进行优化，爬取对应的资源。

   const puppeteer = require('puppeteer');
(async () => {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    await page.goto('https://www.jd.com/');
    const hrefArr = await page.evaluate(() => {
        let arr = [];
        const aNodes = document.querySelectorAll('.cate_menu_lk');
        aNodes.forEach(function (item) {
            arr.push(item.href)
        })
        return arr
    });
    let arr = [];
    for (let i = 0; i < hrefArr.length; i++) {
        const url = hrefArr[i];
        console.log(url) //这里可以打印 
        await page.goto(url);
        const result = await page.evaluate(() => { //这个方法内部console.log无效 
            
              return  $('title').text();  //返回每个界面的title文字内容
        });
        arr.push(result)  //每次循环给数组中添加对应的值
    }
    console.log(arr)  //得到对应的数据  可以通过Node.js的 fs 模块保存到本地
    await browser.close()
})()

上面有天坑 page.evaluate函数内部的console.log不能打印，而且内部不能获取外部的变量,只能return返回，
使用的选择器必须先去对应界面的控制台实验过能不能选择DOM再使用，比如京东无法使用querySelector。这里由于
京东的分界面都使用了jQuery，所以我们可以用jQuery，总之他们开发能用的选择器，我们都可以用，否则就不可以。

接下来我们直接来爬取 `Node.js`的官网首页然后直接生成 `PDF`

无论您是否了解Node.js和puppeteer的爬虫的人员都可以操作，请您一定万分仔细阅读本文档并按顺序执行每一步

本项目实现需求：给我们一个网页地址，爬取他的网页内容，然后输出成我们想要的PDF格式文档，请注意，是高质量的PDF文档

第一步，安装 Node.js ,推荐 http://nodejs.cn/download/， Node.js的中文官网下载对应的操作系统包
第二步，在下载安装完了 Node.js后，启动 windows命令行工具(windows下启动系统搜索功能，输入cmd，回车，就出来了)
第三步需要查看环境变量是否已经自动配置,在命令行工具中输入 node -v，如果出现 v10. ***字段，则说明成功安装 Node.js
第四步如果您在第三步发现输入 node -v还是没有出现对应的字段，那么请您重启电脑即可
第五步打开本项目文件夹，打开命令行工具（windows系统中直接在文件的 url地址栏输入 cmd就可以打开了），输入 npm i cnpm nodemon -g
第六步下载 puppeteer爬虫包，在完成第五步后，使用 cnpm i puppeteer --save 命令即可下载
第七步完成第六步下载后，打开本项目的 url.js，将您需要爬虫爬取的网页地址替换上去(默认是 http://nodejs.cn/)
第八步在命令行中输入 nodemon index.js 即可爬取对应的内容，并且自动输出到当前文件夹下面的 index.pdf文件中

TIPS: 本项目设计思想就是一个网页一个 PDF文件，所以每次爬取一个单独页面后，请把 index.pdf拷贝出去，然后继续更换 url地址，继续爬取，生成新的 PDF文件，当然，您也可以通过循环编译等方式去一次性爬取多个网页生成多个 PDF文件。
对应像京东首页这样的开启了图片懒加载的网页，爬取到的部分内容是 loading状态的内容，对于有一些反爬虫机制的网页，爬虫也会出现问题，但是绝大多数网站都是可以的

  const puppeteer = require('puppeteer');
const url = require('./url');
(async () => {
    const browser = await puppeteer.launch({ headless: true })
    const page = await browser.newPage()
    //选择要打开的网页  
    await page.goto(url, { waitUntil: 'networkidle0' })
    //选择你要输出的那个PDF文件路径，把爬取到的内容输出到PDF中，必须是存在的PDF，可以是空内容，如果不是空的内容PDF，那么会覆盖内容
    let pdfFilePath = './index.pdf';
    //根据你的配置选项，我们这里选择A4纸的规格输出PDF，方便打印
    await page.pdf({
        path: pdfFilePath,
        format: 'A4',
        scale: 1,
        printBackground: true,
        landscape: false,
        displayHeaderFooter: false
    });
    await browser.close()
})()

文件解构设计

数据在这个时代非常珍贵，按照网页的设计逻辑，选定特定的 href的地址，可以先直接获取对应的资源，也可以通过再次使用 page.goto方法进入，再调用 page.evaluate() 处理逻辑，或者输出对应的 PDF文件，当然也可以一口气输出多个 PDF文件~
这里就不做过多介绍了，毕竟 Node.js 是可以上天的，或许未来它真的什么都能做。这么优质简短的教程，请收藏
或者转发给您的朋友，谢谢。

写了个磁力搜索的网页－收录最近热门分享的资源

Sat, 11 May 2013 05:16:21 CST

好吧，又很疯狂地做了一个东西： http://bt.shousibaocai.com/

平常我们高端用户都会用到BT工具来分享一些好玩的资源，例如ubuntu 13.04的ISO安装盘，一些好听的音乐等。这个时候我们会进入一个叫做P2P的网络，大家都在这个网络里互相传递数据，这种分布式的数据传输解决了HTTP、FTP等单一服务器的带宽压力。以往的BT工具（包括现在也有）在加入这个P2P网络的时候都需要借助一个叫Tracker的中心服务器，这个服务器是用来登记有哪些用户在请求哪些资源，然后让请求同一个资源的用户都集中在一起互相分享数据，形成的一个集群叫做Swarm。

这种工作方式有一个弊端就是一旦Tracker服务器出现故障或者线路遭到屏蔽，BT工具就无法正常工作了。所以聪明的人类后来发明了一种叫做DHT（Distributed Hash Table）的去中心化网络。每个加入这个DHT网络的人都要负责存储这个网络里的资源信息和其他成员的联系信息，相当于所有人一起构成了一个庞大的分布式存储数据库。在DHT里定位一个用户和定位一个资源的方法是一样的，他们都使用SHA－1产生的哈希值来作标识。

具体如何工作的呢？举个形象点的例子，把DHT网络比作一个朋友圈子，你想进入这个圈子必须要有一个人带领你进去，通常会有一些特定人负责介绍你进入这个圈子。当你被A带进这个朋友圈，此刻你就只认识A而已。但是你的目的是想找奥巴马总统，所以你会问A要奥巴马的联系方式，但是A没有奥巴马的联系方式，他会介绍一个美国朋友B给你认识。于是你去问B要奥巴马的联系方式，B其实也没有奥巴马的联系方式，但是B认识一个州长C。于是你又得到了C的联系方式，C把奥巴马的联系方式告诉你之后，你就可以写信或者致电给奥巴马了。

这种DHT网络听起来很不错，没有中心服务器，也不怕被DDOS，看看海盗湾如今还能挺立那么久就知道了。但是有没有安全隐患在里面呢？答案是肯定有的。有些不听话的用户可能会在DHT网络里捣乱，譬如说撒谎，明明自己不是奥巴马，却偏说自己是奥巴马，这样会误导其他人无法正常获取想要的资源。另外，用户在DHT网络里的隐私可能会被窃听，因为在DHT网络里跟其他用户交换资源的时候，难免会暴露自己的IP地址，所以别人就会知道你有什么资源，你在请求什么资源了。这也是目前DHT网络里一直存在的一个弱点。

正是利用这个弱点，我根据DHT协议用Python写了一段白菜程序，加入了这个DHT网络。在这个网络里，我会认识很多人，越多越好，并且观察这些人的举动，比如说A想要ubuntu的安装盘，那么我会把A的这个行为记下来，同时我会把ubuntu安装盘这个资源的信息也记下来，保存到数据库中，统计请求ubuntu这个资源的人有多少。如今，这个爬虫已经运行了两个昼夜，以每分钟记录3000多个资源信息的速度工作（单机器单线程，耗尽了CPU的一个核心）。到目前为止（48小时），共发出4亿条交友请求，收到1100万条来自朋友的资源请求。到底有多少资源目前另外一个程序还在分析中，从已分析的300万请求中，独立资源个数为20万个。保守估计这1100万条请求中涉及资源个数为50万以上。迟点有空的话，对这些资源进行分类和分析。

在DHT网络里发现的资源基本上都是最新的活跃资源，一些几年前的资源现在没有用户请求的话就不会被挖掘出来。想想海盗湾沉淀了那么久才500万资源，我跑了两天的程序就已经探测到50万资源，所以随着时间推移，会有更多的资源被探测出来，而且那些最新的能够被接近实时的速度发现到。本来通过增加一个节点进程可以加快探测速度，但是我没有这样做的原因是分析请求的哈希值的速度赶不上发现新请求的速度。有兴趣的朋友可以自己琢磨一下这方面的东西，国内研究DHT网络的人应该比较少。前段时间我打探过几家现在做P2P视频播放的公司里，没有人做这方面的研究。

[DHT Protocol] http://www.bittorrent.org/beps/bep_0005.html

不需要昂贵的 Photoshop，这 7 款免费网页工具想帮你「轻量化」处理图片

Tue, 02 Apr 2019 16:02:27 CST

此前，少数派曾为你介绍过 8 款在线图片处理工具，让你仅需打开浏览器前往特定的网页就能进行图片处理，而无需安装动辄几百 MB 的复杂软件，以及付出相对的时间和上手成本，实现即开即用、用完即走。

本文将会继续为你推荐另外 7 款实用并且免费的在线图片处理工具，让你在图片处理的「轻量化」方面更进一步。

关联阅读： 《不装 App，用这 8 款免费的网页工具解决日常图片处理需求》

黑白图片着色：ColouriseSG

ColouriseSG

ColouriseSG 是近期新晋的热门在线图片处理工具。它是一款运用 AI 技术、 专门为黑白老照片重新着色的免费工具，该项目由新加坡科技局（GovTech Singapore）的数据科学和人工智能部门所提供。

ColouriseSG

据官方介绍，相比于以往的着色工具，ColouriseSG 通过机器学习并储存了超过 50 万张在当地所拍摄的图像，以实现在数秒的时间内，准确识别出黑白照片的人像和自然风景，生成一张颜色更为真实的彩色照片。

在成功导入照片后，ColouriseSG 便会在数秒内自动着色，并在图片上提供一条对比的拖拽线，让你可在左右方向随意对比着色前后的差距：

对比着色效果

在图片下方，ColouriseSG 还提供了「Download result」与「Download result comparison」两种不同的下载方式，前者可让用户直接下载着色后的彩色图片，后者则是下载黑白与彩色的对比图片。

我们以来源于网络的 80 年代中国照片为例，着色前后对比图图如下：

左：着色前/ 右：着色后

从上方图片的效果看，ColouriseSG 确实有着不错的着色效果。不过值得强调的时，官方声明其着色的图片并不能够准确还原黑白照片实际的颜色，仅是提供更为合理的着色而已。

在线、免费的 PS：Photopea

Photopea

PhotoShop 功能的强大，使它在任一领域都发挥着不可替代的重要作用，但对于部分人而言，常常对它有着这样的抱怨：

不便宜的售价，使用频率低；

软件体积较大，安装较繁琐。

若你也有这样的抱怨，那么不妨试一试免费、免安装的在线 PhotoShop 网站：Photopea。

Photopea

进入 Photopea 网站后，我们可以发现，它除了默认深灰色调的 UI 界面与 PS 保持一致外，各功能图标和布局的设计、快捷功能键设定也十分相似，让熟悉 PS 的你也能快速上手。对于常用的 PS 功能，Photopea 自然也均有提供。

相似的功能布局

此外，Photopea 还支持直接打开 Sketch 文件，并且在新建文件尺寸中，还贴心提供了更多的默认尺寸，比如说 Facebook、Instagram、Twitter、YouTube 等网站适宜尺寸。

值得注意的是，Photopea 免费版本会在页面右方显示广告，如果需要关闭广告，则需要付费进行解锁，并获得更多的历史记录保存次数（60 次，免费版为 30 次）。

蒙太奇效果：EasyMoza

EasyMoza

蒙太奇效果即是指一张照片是由很多张小照片拼组而成，使得近看、远看能够呈现不同的视觉效果，极具创意而且富有艺术感。比如说：

乔布斯与苹果产品，图/ 网络

相比于普通的图片，蒙太奇效果也更能体现照片与照片间的联系。对于咱们这些普通人而言，用在情侣照、个人及宠物成长照上再合适不过了。

而 EasyMoza 便是一款能帮助你制作蒙太奇效果的在线工具。我们仅需选择导入的图片后便可自动生成，相比于传统费时费力的 PS 手工拼凑要方便不少。

猫和少数派～

EasyMoza 还提供了小图的图片样张，供你参考或者制作蒙太奇效果，你可以在网站的右上方切换语言为中文以更方便地使用。不过，easymoza 仅免费提供 960 x 720px 低分辨率效果，如需下载更高的分辨率则需付费下载。

动图压缩：EZGif

EZGif

很多网站都对 GIF 图片的体积有着限制，但若是「不讲究」的缩小体积，图片的画质便会得到下降,所以如何有效控制和减小 GIF 体积就成了一门必修功课。

而如果你想在不借助软件的情况下快速缩小 GIF 体积，那么便不可错过全能型的 GIF 编辑网站：EZGif。

EZGif

在压缩 GIF 方面，Ezgif 支持上传最大 35MB 的 GIF 图片或者直接复制粘贴 URL。图片载入后，便可在上方工具栏中选择对应的工具，对影响 GIF 体积的尺寸、颜色、帧率和时长进行调整。

而且调整后的效果会在页面下方预览，并显示文件的具体信息，包括大小、长宽、帧数。倘若你对结果仍然不满意，也可在预览界面中继续自由调整。除了压缩 GIF 外，Ezgif 还支持视频转 GIF、WebP、APNG 文件格式转换等等，功能非常全面。

GIF 调整工具（网页经过浏览器翻译）

在线版 Prisma：Ostagram

Ostagram

很多朋友想必还记得曾经爆红网络、利用算法将普通照片转成艺术风格作品的 Prisma。

而 Ostagram 便是一款与 Prisma 功能类似的在线工具。不同的是，Ostagram 是一个基于 DeepDream 算法来生成绘画作品的项目，即学习绘画作品的风格，从而在不破坏原图构图的情况下，将其变成类似绘画作品风格的画作。

Ostagram

Ostagram 使用起来也并不复杂，登录账号后便可上传图片，选择模拟的绘画作品后，即可将原图渲染输出为风格相似的画作，效果令人满意。

渲染效果

美中不足的是，ostagram 的免费版渲染图片分辨率受限，且渲染一张图片时长还需耗时几分钟，付费版则会好很多。

动画图片制作：Loading.io

Loading.io

微信公众号图文、网页总少不了各式各样的 Loading（载入）图示，在自己未具备能力制作前，总是很容易对第三方所提供的样式感到审美疲劳。

如果你有这样的困惑，不妨试一试支持通过这款在线的网页工具来制作 Loading 效果图的网站：Loading.io。

Loading.io（网页经过浏览器翻译）

网站中有着各式各样的 Loading 载入图示可供选择，选择喜欢的图示后，便可设定 Loading 图示的大小、动画速度、颜色、背景颜色等等，上手非常简单且也提供了高度的自定义选项。

动态展示

此外，在动画设定完成后，支持导出为 GIF、CSS、PNG、SVG 多种格式，便于你在不同场景的使用。

图片合成：Moose

Moose

在制作一张合成图片时，往往都会到免费的素材库中找寻，但在质量却良莠不齐，并不能在第一时间找到高质量的素材图片。由 icon8 推出的高质量图库「Moose」，便能在一定程度上解决你的问题。

Moose

Moose 主要将素材图片分拆成三部分：人物、背景、物件。作为使用者，你不仅可以直接将图片素材导出为高清 PNG，还可以直接在网站中选择组合各个部分的素材，拼成一张组合图片。

操作的方法非常简单，可直接拖拽素材，并支持大小、方向调节，让最终的组合图片更具合理的视觉效果。除此之外，Moose 还提供了添加文字的功能选项。值得注意的是，Moose 免费版仅支持导出为 PNG 格式，PSD 图层格式则需付费进行解锁。

选择素材拼图

倘若你还有其它的在线图片处理工具推荐，也欢迎在评论里留言分享。

> 下载少数派客户端、关注少数派公众号，了解更多有趣的应用
> 特惠、好用的硬件产品，尽在少数派 sspai 官方店铺

如何使用Jenkins持续集成C#网站项目 - 暗夜孤灯的个人页面 - 开源中国

Sat, 23 Mar 2019 23:03:15 CST

上两节分别讲了如何从vss迁移C#网站项目到gitlab和如何使用nuget管理C#网站项目，其实都是为了最后一节的内容做铺垫：持续集成C#网站项目,这里我们使用的持续集成工具是Jenkins

软件环境：

Jenkins ver. 2.73

freesshd 1.3.1

nuget 4.1.0.2450

msbuild 15.0

1.持续集成思路

项目按这个思路初始化配置到Jenkins后，每次提交代码到gitlab，Jenkins自动触发完成部署。我用一台Windows服务器192.168.0.136用来部署Jenkins，另外一台Windows服务器234部署项目

2.Jenkins的安装比较简单，这里不细讲，网上有很多教程，用到的插件包括 GitLab Plugin， MSBuild Plugin， Publish Over SSH等

3.初始配置过程

新建Jenkins项目，选择“构建一个自由风格的软件项目”，保存

1）gitlab获取最新代码

在“源码管理”区，选择git配置好项目地址，认证用户，分支等信息（需事先在Jenkins配置好gitlab，如gitlab地址，sshkey等认证信息）

2）Nuget获取依赖包配置

在“构建”区，选择“Execute Windows batch command”,

      "D:\Program Files"\nuget\nuget.exe restore "Suntime.DigitalMarketing.Web.sln" -ConfigFile "C:\Users\Administrator\AppData\Roaming\NuGet\NuGet.config" -NoCache

去官网（ https://www.nuget.org/downloads）下载nuget.exe并安装，把自定义的nuget server配置到NuGet.config中，以便能从自定义Nuget仓库中下载依赖包

3）msbuild构建解决方案并发布

继续在“构建”区，选择“Build a Visual Studio project or solution using MSBuild”

其中的MSBuild Version需要先配好，在Jenkins>Global Tool Configuration设置MSBuild，如下图我配置了两个MSBuild4.0和MSBuild15.0（指向的是vs2017的MSBuild.exe）

参数列表：

      /t:Rebuild

/toolsversion:15.0

/property:Configuration=Release;PublishProfile=jenkins-deploy;DeployOnBuild=true;TargetFrameworkVersion=v4.5

其中的PublishProfile=jenkins-deploy指的是发布用的pubxml文件，我的发布路径是D:\jenkins-deploy\digitalmarket_web，这个路径在后面的打包压缩时会用到

4）压缩发布文件

继续在“构建”区，选择“Execute Windows batch command”

      set projectName=digitalmarket_web

set targetFilePath="D:\jenkins-deploy\"

set jenkins="D:\Program Files\Jenkins\workspace\"%projectName%

set rarexe="C:\Program Files\WinRAR\"

cd %targetFilePath%

%rarexe%Rar.exe a -r -x%projectName%\Web.config -ep1 %jenkins%\%projectName%.rar %projectName%

因本地环境和服务器Web.config配置可能不同，所以在压缩文件时需排除项目中的Web.config文件

5）上传到部署服务器并解压文件，使用ssh上传文件后执行远程脚本解压文件，在234服务器上使用freesshd搭建ssh服务

在两台服务器能正常通信的前提下，开通234服务器上的22和23端口

在freesshd中创建用户jenkins，把136服务器.ssh下的公钥复制到设置的Public key folder路径下，并重命名为jenkins，公钥名必须和用户名一致

设置SFTP路径为：D:\jenkins，用于存放上传文件

在“构建后操作”区，选择“Send build artifacts over SSH”

命令行：

      cmd.exe /c "d: && cd jenkins && unrar.bat digitalmarket_web"

其中unrar.bat为放在D:\jenkins中的解压脚本，脚本命令如下

      set targetFilePath=D:\jenkins\

set rarexe="C:\Program Files\WinRAR\"

cd "%targetFilePath%"

%rarexe%UnRAR x -o+ -y %1.rar

4.最后添加自动构建设置：gitlab上项目代码一旦更新就会触发构建

5.试验一下，成功后在部署服务器的iis中配好网站就行

git获取最新代码

Nuget获取依赖包配置

msbuild生成解决方案

发布打包

压缩发布文件并上传

远程解压成功

如何把多个网页合并下载为 PDF

Thu, 17 Jan 2019 12:11:09 CST

来自微博的问题：有没有什么软件可以把多个网页合并下载为 PDF，比如我想把图上的域名下的所有网页合并下载为一个 PDF 文件。@小众软件

这是一个非常经典的问题，关乎两种文档格式的不同特性。因为 HTML 的离线不可用性，和 PDF 的任何情况下的完整性，所以将需要离线阅读的内容 PDF 化是一个非常不错的主意。

最终 @ 剑心_h 同学推荐了一款命令行工具： wkhtmltopdf（在 GitHub 开源），青小蛙研究了一下，似乎可行，简单易用。

wkhtmltopdf 全称 WK<html>TOpdf，是一个专门用来转换网页到 PDF 的工具，唯一的门槛就是没有图形化界面，需要使用命令行。

在使用之前需要安装，Windows 用户需要进入安装目录后，在地址栏输入 cmd 以打开当前目录的命令行，然后就可以使用了。其他系统用户相信会很熟悉命令行。

  wkhtmltopdf https://www.appinn.com/ appinn.pdf

上面就是最近的将网页转换为 pdf 的命令，而如果你想添加目录，或者禁用 js，还可以使用参数:

  wkhtmltopdf toc https://www.appinn.com/ appinn.pdf #生成目录
wkhtmltopdf -n https://www.appinn.com/ appinn.pdf #禁用 js

这样就能非常方便的将网页转换为 pdf 了，还有参数可以设置分辨率、页面边距、是否压缩、是否显示图片等等，更多可以参考这篇文章。

有了 PDF，合并就容易了，这里推荐 SmallPDF 在线工具，很方便就合并了。

如果，你有更好的将图片转换成 PDF 的工具，欢迎留言推荐。

把网页文章变成电子书装进 Kindle：Doocer

Sun, 26 Aug 2018 16:07:06 CST

一直以来我都在研究如何将关注的网页或文章装进 Kindle 来进行严肃阅读，但是无奈久久没有实质进展。尽管手动排版书籍制作电子书的方法简单易行，但是对于篇幅短、更新频繁的网页文章来说，这种方法的效率低下。如果能有一款工具把网页文章批量抓取、生成电子书、直接推送到 Kindle，那真是再好不过了。 Doocer 就是这样的一款实用工具。

Doocer 是由 @lepture 开发的在线服务，它可以允许用户提交网址、RSS 订阅源地址还有 Pocket 稍后读账号里的文章，随后挨个或批量制作成 ePub、MOBI 电子书。你可以直接在 Doocer 里阅读所有文章，或者将它们推送到 Kindle、Apple Books 里阅读。

阅读体验确实不错

Doocer 生成的电子书，排版优良可圈可点，该有的内容一样不少，不该有的内容一样不多。书籍不仅封面图文并茂，而且文章目录、网站来源、文章原作者等信息一应俱全。Doocer 生成的 MOBI 电子书支持 KF8 标准，因此支持 Kindle 原生更换自定义字体功能。

得益于网站文章通常有标准通用的排版规范，Doocer 生成的电子书文章里的大小标题、列表图例都与原网页文章高度一致。原文章中的超链接也全部保留，评论信息、广告等内容则全部摈弃。整本书籍的阅读体验非常友好。（当然如果原网页文章的排版毫无章法，那么生成的电子书也可能面目全非。）

将网页文章制作成电子书籍

在 Doocer 完成注册登录之后，我们就可以开始将网页文章制作成电子书。首先我们点击「NEW BOOK」按钮来新建一本电子书，并输入电子书名。接下来在右上角选择「ADD」来添加文章网址或 RSS 订阅源地址。

以将少数派网页的文章为例，我们选择「FEED」，在输入框内粘贴 RSS 地址，随后点击「PARSE」，那么少数派近期文章的列表都会显示出来供我们添加。我们可以按需选择，也可以点击「SELECT ALL」选中全部文章。最后下拉到页面底部，选择「SAVE」，那么这些文章都会被添加进书籍里。

实际上，Doocer 网页与 RSS 工具极为相似，它是实现了从网站中批量抓取文章，集中展示的功能。

要将这些文章转换成电子书并推送至 Kindle，我们还要进行一些简单的操作。

首先根据 Doocer 个人设置页面中的提示，我们打开亚马逊 Kindle 的个人文档设置，把 Doocer 电子书的发送地址添加进个人文档接收地址中去。完成后，我们再把 Kindle 的个人文档接收地址填写在输入框中，点击保存。

最后，我们打开 Doocer 里的「少数派」这本书籍，在页面中找到「Publish」，选择 Send to Kindle。10～30 分钟左右，Doocer 会完成书籍制作并将这本书推送到 Kindle 中去。

还有一些问题需要注意

Doocer 现处于 Beta 测试阶段，仍有一些 bug，特别是对于中文网站常会出现问题。好在 Doocer 官网就有开发者的对话通道，可以直接和他取得联系帮助解决。

实现所有操作的自动化流程，是我认为 Doocer 最需要努力的方向。Doocer 可以像 RSS 工具那样抓取网页内更新的文章，但是将新增文章的抓取并生成电子书以及推送，还是需要手动进行。如果能够将整个流程都实现自动化，RSS - MOBI - Kindle 一气呵成，我相信它的实用性会更上一层楼。

目前， Doocer 的所有功能都可免费使用。

如何下载网页上的视频？ - 知乎

Thu, 19 Jul 2018 11:44:37 CST

2017.1.13

pc端软件

适用场景：优酷，土豆1080p视频，腾讯视频等

1.硕鼠。我比较常用的一类软件，能够进行 清晰度解析下载，用过很长一段时间了，需要下载视频的就会找到它。今天发现硕鼠没有以前强大了...以前还能下载优酷视频专辑。

类似的有猎影，以前没用过，今天试用了一下，很好用。能够下载优酷和土豆1080p的视频。很棒的软件。

" width="547">

2.IDM下载器。平时代替浏览器下载器使用，有视频和音频嗅探功能，可以下载在线视频，一个好用的地方是：百度 贴吧的语音，能够嗅探并且下载下来，而有些扩展插件是不能嗅探到的。

扩展插件

适用场景：秒拍，微博视频等

我平时用chrome和360极速浏览器； 360极速上安装有 FVD Video downloader；这款扩展的作用也是嗅探网页上的视频，嗅探到后有图标显示，直接点击即可下载，使用很方便。

youtube视频

对于youtube视频，我的方法是一个油猴脚本：Download YouTube Videos as MP4；在视频播放页面会出现下载按钮，可选清晰度至720p。下载地址： Download YouTube Videos as MP4（在chrome上先安tampermonkey脚本管理器）；

如果需要下载youtube 1080p的视频，可以用 Gihosoft TubeGet；

" width="578"> 其他

VIP解析，支持爱奇艺，优酷，腾讯，搜狐，芒果等；地址： https://pan.baidu.com/s/1qYLbfvI密码: ikm6

审查元素，在线解析视频的网站，google。

网友推荐： You-Get——基于Python3的媒体下载工具

原文在这里： https://zhuanlan.zhihu.com/p/24861140

作为使用过N种下载网页视频的实践者，郑重推荐几乎能下载网页全部视频的浏览器插件： FVD Downloader（基本上可以下载绝大部分常规和非常规视频网站的视频）。

（PS:此插件不仅能够下载网页上的视频， 还可以支持下载音频网站的音乐哦）

只需要2步就可以轻松快速的把网页中的内容保存下来。
下面是具体的操作步骤：
第一步： 安装FVD Downloader插件（以360浏览器为例）

大家点击浏览器中的“拓展”

然后在应用市场中找到FVD Downloader，点击“安装”（这里我已经安装好了）。

安装好后，你的浏览器搜索框附近会出现FVD Downloader的图标。

第二步： 打开视频播放页面，点击插件，选择下载并保存

这里我们以“新浪视频”为例。（经测试：爱奇艺也可以，非常规视频网站也可以，具体请自行测试。）

打开新浪视频，输入你想下载的视频名称，这里我输入：PPT，得到以下结果，我们就下载：PPT场景—5公里。

从网页中看到可以，该视频是不提供下载的，因为根本就找不到下载的按钮。

点开后，可以看到FVD Downloader图标是有颜色的，代表该页面有视频可以提供下载。假如该网站没有可提供的视频下载的话，该图标将会呈现灰色并且有一个×。

点击图标，可以看到以下界面

最后一步点击下载。

下载下来后用视频播放器播放，就可以离线观看该视频。

如果你使用该插件后，可以看到有很多可以下载的视频内容，而且视频的格式为：ts，原因是该视频被分成了很多小段，只需要用命令行拼接一些就可以了。可以在windows的命令行中输入：copy/b （文件保存地址）\*.ts （文件保存地址）\new.ts 这样就可以

注意：请勿用此方法下载收费或者有版权视频，毕竟原创者付出了大量的时间和精力制作视频，还望大家保护版权！

——————分割线————————

对于大家在评论区说的问题进行统一回答：

（1）如果在插件下，一个网页内提示有多个视频文件，如何下载高清版本

首先如果你想下载网页内高清版视频，首先你得把网页内视频的清晰度选择为高清的，因为插件是需要网页加载视频后才会识别是否有视频可以下载

接着再次点击插件，就可以发现插件视频比原来多个视频了，选择大的文件就是高清版本的了

（2）ts格式要用什么播放器看

只要用常规的播放器就可以了，ts只是整个视频一小段，需要拼接起来才是一个完整的视频，具体拼接方法看我的之前的方法。播放器我建议用QQ影音，因为它没有广告而且体积小启动速度快

——————分割线——————

如果你对于这次讲解还有什么问题的话，可以随时在公众号【 印象演示】发消息给我。

或者加我的个人微信：rsmshuzhou

http://weixin.qq.com/r/kcAsNFfE6AqXrRNX95WD (二维码自动识别)

代替那些「用完就删」的 App，试试这 9 个实用的网页小工具

Sun, 08 Apr 2018 00:00:00 CST

很对人对于软件都有一种「收藏」的习惯，觉得这可能是一个工具就把它购买或下载放在那里，新鲜了两天就搁置在那儿，终究成了橱柜上的一个布满灰尘的摆设。其实很多时候我们可以换个思路，如果这个工具是在网页上，用的时候再打开，不用的时候就关闭，既不占用你电脑空间，也不受限于设备的系统，或许还能帮你省下不少的钱，今天少数派就为大家介绍一些实用而且有趣的网页工具。

Internet Speed Test

一个良好的网速大概会有 80% 的概率提高我们的生产力和执行力，糟糕的网速大概会有 99% 的概率影响我们的情绪。所以经常会有一些朋友频繁的测量网速，有的选择下载一款软件进行测量，有的随便找一个网站就将就了。而 FAST和 SPEEDTEST是两家「优雅」的测速站点，只点击一下 ► 按钮再稍等片刻，你的网速测试结果就会呈现在你的面前，无污染、零广告、完全免费。

相关链接： FAST、 SPEEDTEST

whiteboard

白板的用处有很多，打草稿，记录突如其来的灵感，或者玩玩你画我猜也是可以的， whiteboard就是这样的一个随开随用的白板网站。这个网站的构造非常简洁，工具只有画笔、文本框、橡皮擦，虽然工具简单，但几乎所有的操作都支持快捷键，无需你去工具中点来点去。如果你绘制的图像趋于一定的形状，例如圆形、矩形，它可以自动的转换为标准形状。绘制完成的白板，也可以通过右上角的「Share」分享给其他的人，而其余的人也可以进行编辑，而两边的画面也是同步的。除此之外，该网站也提供了 Slack 群组的插件，如果你们有用到 Slack，不妨添加这款插件试一试。

在线 Markdown 编辑器

不知道前段时看了《想学 Markdown？这篇文章帮你快速上手》之后有没有想尝试一下 Markdown 的冲动，对于还没选择到合适 Markdown 工具的时候，不如先用这款 在线 Markdown 编辑器体验一下语法，在这里左侧输入的文本内容都会实时的显示右侧和下侧，分别是 HTML 格式预览以及实时效果预览。但是在网站编辑的内容并没有提供保存到本地的入口，如果你需要请及时复制粘贴。建议只是作为临时备用方案或是体验方案，如需深度体验还是选择专门的 Markdown 工具。

相关链接： 在线 Markdown 编辑器

草料二维码

二维码在生活中可以说是非常常见了，从付款码到共享单车，随处可见。其实对于我们来说，不仅可以扫码当然也可以制作二维码，例如我们想分享某个网址，或者把我们的 Wi-Fi 提供给别人（可以用这个 Workflow）。而 草料二维码不仅给我们提供了制作二维码的途径，也为我们附上了一些「优雅」姿势。在这里你只需要输入的文本内容，在右侧选择二维码属性。可以选择直接使用模版图案快速美化，也可以使用旧版的美化器（功能齐全）来进行更细致的操作，例如选择背景前景图、颜色以及二维码状态。这样以来，不论你的二维码用在哪里，都再也不怕单调无味。

图片处理

图片在我们生活中的用处太多了，但时常我们也会因为图片的事情而苦恼。因为在不同的使用场景里，对图片的要求可能都不太一样，例如有的限制了大小，有的限制了格式。对于这些问题，我们其实不需要复杂了步骤，也不需要安装一些软件，只需要上传一下然后处理就可以了。对于图片的格式问题，你只需要在 Jinaconvert上选择你需要的格式类型，再将图片文件上传至即可。

Ringer

手机的铃声是不是从来没有更换过，可能是因为制作铃声的方法有那么点复杂，一步步的操作加上各式软件，或许就让你放弃了这个念头。其实，你只需要把各类格式的音乐源文件上传到 Ringer 上，选择选上铃声的开头结尾。最后选择 M4R 或是 MP3 就可以了，可以说是免费又快捷了。

Keyboard Layout Editor

Keyboard Layout Editor是一个键盘图纸设计的网站，它的作用可以说是非常的多。如果你刚上手一个软件，但是却无法记住它的全部快捷键，不如直接将快捷强的功能放置在图纸上，打印下来贴在桌边，帮助你记忆。如果你正常考虑一款机械键盘的配色，你可以在这上面选择相应的键位进行颜色的修改，最后看看整体的配色效果。它的自定义程度非常的高，在这里几乎可以编辑键位所有的参数，所以它究竟能起到什么样的作用，就看你如何利用它了。设计好的内容网站也提供了五种格式的文件方便用户下载，如果喜欢不妨加入到收藏夹里。

Gifntext

还记得网上很火的「为所欲为」和「王境泽」吧，丰富的表情配上字幕，随随便便就是一个表情包。其实为 Gif 添加字幕也没有那么的困难，只需要将准备好的 Gif 文件上传到 Gifntext上，然后就可以对播放速度以及画面尺寸进行调节。于此同时，也可以自由的在时间轴中加入想要的字幕、图片或是涂鸦。网站最大可以上传 100M 的 Gif 文件，修改完成后创建的动图自动的进行压缩。

Pinterest 渐进式网页应用及性能问题 | 人人都是互联网创意G客

Sun, 07 Jan 2018 17:55:03 CST

Pinterest 新的移动端网页采用了 Progressive Web App。在这篇文章中，我们将介绍他们的一些工作，通过保持JavaScript包的精简以及采用 Service Workers 来应对网络波动。

在你的手机上登录 https://pinterest.com 体验他们新的移动端网站

为什么是渐进式网页应用 (PWA)? 和一些历史。

Pinterest 决定使用开始使用 PWA 是因为他们专注于国际增长，他们把目光放到了移动端网页。

在分析了使用了移动端网页未登录用户的数据后，他们意识到自己古老，缓慢的网页体验仅仅转化了 1% 的用户去注册，登录或下载安装原生应用。这是大大提高转化率的机会，所以他们投资了 PWA。

在一个季度中打造并且推出 PWA

在过去的三个月中，Pinterest 使用 React，Redux，webpack 重新打造了他们移动端网页。他们的移动端网页重写使核心业务指标的一些积极改进。

与旧的移动Web体验相比，花费的时间是40%，用户产生的广告收入增加了 44% ，核心业务增加了 60% ：

他们移动端网页的重写同时也提高了性能。

在移动端3G网络下平均加载速度更快

Pinterest 旧版的移动端网页体验像一块巨石—它包含了大量 CPU 计算的 JavaScript 包，拖延了 Pin 页面的加载和可交互的速度。

在UI界面可响应之前，用户通常需要等待 23秒：

Pinterest 旧版的移动端网站需要花23秒才可以交互，浏览器需要接收大约 2.5 MB 的 JavaScript (主包大约1.5MB，懒加载大约1MB) 并且花数秒钟去解析和编译在主线程可响应之前。

他们新版移动端网页体验猛增。

他们不仅分散和削减了数百KB的JavaScript，将其核心包的大小从650KB降低到150KB，而且还改进了关键性能指标。首次有意义的渲染从4.2s下降到1.8s，可交互时间从23s减少到5.6s。

这是Android设备在使用缓慢的3G网络连接。重复访问，情况更好。

由于Service Worker对主要JavaScript，CSS和静态UI资源进行缓存，这样能够将重复访问的互动时间缩短至3.9秒：

虽然 Pinterest 提供 iOS 和 Android 应用程序，但是它们能够提供在网页上相同的核心主页消息流订阅体验，只需要一小部分的前期下载成本 - 压缩后只需约150KB。这与 Android 的 9.6MB 和 iOS 的 56MB 提供相同的体验恰恰相反：

然而，这里要指出的是，这不是苹果设备之间的比较。PWA根据需要加载新路由的代码，附加代码的成本在应用程序的生命周期内分摊。随后的导航仍然不会像下载应用程序那样花费太多的流量。

Pinterest 渐进式网页应用在移动端的 Firefox, Edge 和 Safari 上。

基于路由的 JavaScript 打包组合

只需加载用户需要的代码，就可以快速获取网页来加载和获取交互。这减少了网络传输和JavaScript解析/编译时间。非关键资源可以根据需要延迟加载。

Pinterest开始打破他们的几兆字节的JavaScript包，将其分成三个不同类别的webpack块，他们工作得很好：

渲染块包含额外的依赖(react, redux, react-router, etc) ~ 73kb
入口块包含渲染网页的主要代码（举例：通用模块，页面的外壳，redux 的 store） ~ 72KB
异步路由块包含单独路由的代码 ~13–18KB

网络瀑布的高亮显示了该如何逐步优化代码，从而避免了巨石般的打包：

对于长期缓存，Pinterest也为每个文件名使用块特定的散列。

Pinterest 使用 webpack 中的 CommonsChunkPlugin 来分离出他们的可缓存的 vendor 包：

他们也结合 code-splitting 使用 React Router ：

对需要支持的浏览器使用 babel-preset-env 转换代码

Pinterest 使用 Babel babel-preset-env 转换所需支持的现代浏览器中不支持的 ES2015+ 特性。Pinterest 支持现代浏览器的最新两个版本，他们的 .babelrc 是这个样子的：

还有进一步的优化，他们可以做，只有条件地满足需要的 polyfills (例如 Internationalization API)，但这是未来的计划。

使用Webpack Bundle Analyzer分析改进空间

Webpack Bundle Analyzer 是一个非常棒的工具，它能真正的了解你发给用户 JavaScript 包之间的依赖关系。

下面，你能看到很多紫色，粉色和蓝色的块，它们在 Pinterest 中是最早加载输出的。这些是用于延迟加载路由的异步块。Webpack Bundle Analyzer 允许可视化大部分这些块包含重复的代码：

Webpack Bundle Analyzer 帮助可视化所有块之间的这个问题的比例。

Pinterest 使用块中的重复代码信息进行调用。他们将异步块中的重复代码移动到其主块。它将入口块的大小增加了20％，但将所有延迟加载块的大小减少了90％！

图片优化

Pinterest PWA中大多数内容的延迟加载是由无限的 Masonry 网格来处理的。它内置了对虚拟化的支持，并且只挂载在视口中的子项。

Pinterest 也使用渐进式加载技术来处理 PWA 中的图像。占位符在初始化每个 Pin 时占主导地位。 Pin 的图像使用 Progressive JPEGs（渐进式JPEG），可在每次扫描时提高图像质量：

React 性能痛点

Pinterest 用 React 处理了一些渲染性能问题， Masonry 网格作为他们的一部分。安装和卸载组件（如 Pins）的大树可能会很慢。Pin 中有很多东西：

虽然在写 Pinterest 的时候正在使用 React 15.5.4，但是他们希望 React 16 （Fiber）能够减少花费在卸载上的时间。与此同时，虚拟化网格显着帮助了组件卸载时间。

Pinterest还会限制 Pins 的插入，以便他们可以更快地测量/渲染第一个 Pins，但意味着设备CPU的整体工作量更大。

导航过渡

为了提高感知性，Pinterest 也更新独立于路由的导航栏图标的选定状态。这使得从一个路由到另一个路由的导航不会因网络阻塞而感觉到缓慢。用户在等待数据到达时快速获取可视化界面：

使用 Redux 的经验

Pinterest 对所有 API 数据使用 normalizr (它根据模式规范化嵌套JSON) 。可以使用 Redux DevTools 中看到他们。

这个过程的缺点是非规范化是缓慢的，所以他们最终严重依赖 reselect 的选择器模式来记忆渲染过程中的非规范化。它们也总是在尽可能低的层次上进行非规范化处理，以确保单个更新不会导致大量的重新渲染。

举个例子，他们的网格项目列表只是 Pin ID 与 Pin 组件非正常化本身。如果任何给定 Pin 有变化，则完整的网格不必重新渲染。权衡是在Pinterest PWA 中有很多 Redux 订阅，尽管这没有导致明显的性能问题。

通过 Service Workers 缓存资源

Pinteres t使用 Workbox 库来生成和管理他们的 Service Workers：

今天，Pinterest 使用缓存优先策略缓存任何 JavaScript 或 CSS 包，并缓存其用户界面（应用程序外壳）。

在缓存优先设置中，如果请求与缓存条目匹配，则以此作为响应。否则，尝试从网络获取资源。如果网络请求成功，更新缓存。要了解更多有关使用 Service Worker 的缓存策略，请阅读 Jake Archibald’s Offline Cookbook 的离线手册。

它们为应用程序外壳（webpack的运行时，vendor 和入口块）加载的初始包定义了预缓存。

由于 Pinterest 是具有全球影响力的网站，支持多种语言，因此它们还会生成每个语言环境的 Service Worker 配置，以便它们可以预先缓存语言环境包。 Pinterest 也使用 webpack 的命名块预缓存顶级异步路由包。

这项工作是在几个较小的迭代中推出的。

首先：Pinterest 的 Service Worker 只会在运行时缓存按需延迟加载的脚本。这是利用V8的代码缓存，帮助跳过重复视图的一些分析/编译成本，使他们可以加载更快。从 Service Worker 存在的高速缓存存储器提供的脚本可以及时的选择代码高速缓存，因为浏览器可能知道用户最终将在重复视图中使用这些资源。

之后，Pinterest 进行预缓存他们的 vendor 和入口块
接下来，Pinterest 开始预缓存一些常用路由(像主页， pin 页面，搜索页面等)
最后，他们开始为每个语言环境生成一个 Service Worker，以便他们也可以缓存语言环境包。这对于重复加载性能非常重要，同时也为大多数用户提供了基本的离线渲染功能。

应用外壳的挑战

Pinterest发现实施他们的应用程序壳有点棘手。由于桌面时代的假设，有多少数据可以通过有线连接发送，初始的有效负载很大，包含了很多非关键信息，如用户的实验组，用户信息，上下文信息等。

他们不得不自问：“我们是否将这些内容缓存在应用程序外壳中？或者在渲染任何内容之前，先阻塞网络请求来获取它”。

他们决定将其缓存在应用程序外壳中，这需要管理什么时候使应用程序外壳失效（注销，从设置等更新用户信息）。每个请求的响应都包含 appVersion — 如果应用程序版本发生变化，他们将取消注册 Service Worker，注册新的服务，然后在下一次路由更改时重新加载整个页面。

将这些信息添加到应用程序外壳是有点棘手，但为了避免渲染被请求阻塞，是值得的。

审计和 Lighthouse

Pinterest 使用 Lighthouse 来验证他们的性能改进是正确的。观察诸如“持续互动时间”等指标非常有用。

明年，他们希望使用 Lighthouse 作为回归机制来验证页面加载速度是否保持快速。

新特性

Pinterest 刚刚部署了支持 Web 推送消息的版本，并且在未登录（注销）的状态下的 PWA 也可以正常使用。

他们有兴趣探索支持 <link rel=preload> 预加载关键包并减少首次加载时向用户提供的未使用JavaScript的数量。请继续关注未来更多精彩的演出！

原文链接： https://medium.com/dev-channel/a-pinterest-progressive-web-app-performance-case-study-3bd6ed2e6154

移动端网页布局注意事项及解决

Tue, 01 Aug 2017 17:10:41 CST

1.winphone系统a、input标签被点击时产生的半透明灰色背景怎么去掉

<meta name="msapplication-tap-highlight" content="no">

1、关闭iOS键盘首字母自动大写

<input type="text" autocapitalize="off" />

2、禁止文本缩放

html {
-webkit-text-size-adjust: 100%;
}

3、移动端如何清除输入框内阴影

在iOS上，输入框默认有内部阴影，但无法使用 box-shadow 来清除，如果不需要阴影，可以这样关闭：

input,
textarea {
border: 0;
-webkit-appearance: none;
}

4、忽略页面的数字为电话，忽略email识别

<meta name="format-detection" content="telephone=no, email=no"/>

5、快速回弹滚动

.xxx {
overflow: auto;
-webkit-overflow-scrolling: touch;
}
PS：iScroll用过之后感觉不是很好，有一些诡异的bug，这里推荐另外一个 iDangero Swiper，这个插件集成了滑屏滚动的强大功能（支持3D），而且还有回弹滚动的内置滚动条，官方地址：

http://www.idangero.us/sliders/swiper/index.php

6、移动端禁止选中内容

div {
-webkit-user-select: none;
}

7、移动端取消touch高亮效果

在做移动端页面时，会发现所有a标签在触发点击时或者所有设置了伪类 :active 的元素，默认都会在激活状态时，显示高亮框，如果不想要这个高亮，那么你可以通过css以下方法来禁止：

.xxx {
-webkit-tap-highlight-color: rgba(0, 0, 0, 0);
}

8、如何禁止保存或拷贝图像

通常当你在手机或者pad上长按图像 img ，会弹出选项存储图像或者拷贝图像，如果你不想让用户这么操作，那么你可以通过以下方法来禁止：

img {
-webkit-touch-callout: none;
}
PS：需要注意的是，该方法只在 iOS 上有效。

9、解决字体在移动端比例缩小后出现锯齿的问题：

-webkit-font-smoothing: antialiased;

10、栅格布局：

box-sizing:border-box;可以改变盒子模型的计算方式方便你设置宽进行自适应流式布局

11、input[type=input]{-webkit-appearance:none;}移除ios的样式，但这个属性存在bug，会导致iso无法获取checkbox值，给这个元素重新赋上input[type=checkbox]{-webkit-appearance:checkbox;}就不会报错了。

12、按钮被按下效果的实现需要给a标签加a:active属性和添加一段空函数

document.body.addEventListener('touchend', function () { });

13、解决去掉下边框：

-webkit-border-bottom:none;

14、英文文本换行(不拆分单词)：

word-wrap:break-word

15、字体大小尽量使用pt或者em，rem，代替px。

16、设置input里面placeholder字体的大小

::-webkit-input-placeholder{ font-size:10pt;}
17、wap页面有img标签，记得加上display：block；属性来解决img的边缘空白间隙的1px像素。如果图片要适应不同的手机要设置width:100%;而且不能添加高度。

18. 移动端如何清除输入框内阴影

在iOS上，输入框默认有内部阴影，但无法使用 box-shadow 来清除，如果不需要阴影，可以这样关闭：

input,
textarea {
border: 0;
-webkit-appearance: none;
}
19. 移动端禁止选中内容

如果你不想用户可以选中页面中的内容，那么你可以在css中禁掉：

.user-select-none {
-webkit-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
}
兼容IE6-9的写法：onselectstart="return false;" unselectable="on"

20.audio元素和video元素在ios和andriod中无法自动播放

应对方案：触屏即播

$('html').one('touchstart',function(){
audio.play()
})

21.手机拍照和上传图片

<input type="file">的accept 属性



<input type=file accept="image/*">


<input type=file accept="video/*">
ios 有拍照、录像、选取本地图片功能

部分android只有选取本地图片功能

winphone不支持

input控件默认外观丑陋

22. 消除transition闪屏

.css{
-webkit-transform-style: preserve-3d;
-webkit-backface-visibility: hidden;
}
23.开启硬件加速解决页面闪白保证动画流畅

.css {
-webkit-transform: translate3d(0, 0, 0);
-moz-transform: translate3d(0, 0, 0);
-ms-transform: translate3d(0, 0, 0);
transform: translate3d(0, 0, 0);
}
设计高性能CSS3动画的几个要素

尽可能地使用合成属性transform和opacity来设计CSS3动画，

不使用position的left和top来定位

利用translate3D开启GPU加速

**************************************************************************

框架

1. 移动端基础框架

zepto.js 语法与jquery几乎一样，会jquery基本会zepto~

iscroll.js 解决页面不支持弹性滚动，不支持fixed引起的问题~ 实现下拉刷新，滑屏，缩放等功能~

underscore.js 该库提供了一整套函数式编程的实用功能，但是没有扩展任何JavaScript内置对象。

fastclick 加快移动端点击响应时间

animate.css CSS3动画效果库

Normalize.css Normalize.css是一种现代的、CSS reset为HTML5准备的优质替代方案

2. 滑屏框架

适合上下滑屏、左右滑屏等滑屏切换页面的效果

slip.js

iSlider.js

fullpage.js

swiper

3.瀑布流框架

masonry

工具推荐

caniuse 各浏览器支持html5属性查询

paletton 调色搭配

对于网站字体设置

移动端项目：

font-family:Tahoma,Arial,Roboto,"Droid Sans","Helvetica Neue","Droid Sans Fallback","Heiti SC",sans-self;

移动和pc端项目：

font-family:Tahoma,Arial,Roboto,"Droid Sans","Helvetica Neue","Droid Sans Fallback","Heiti SC","Hiragino Sans GB",Simsun,sans-self;

有关Flexbox弹性盒子布局一些属性

不定宽高的水平垂直居中

.xxx{
position:absolute;
top:50%;
left:50%;
z-index:3;
-webkit-transform:translate(-50%，-50%)；
border-radius:6px;
background:#fff;
}

[flexbox版]不定宽高的水平垂直居中

.xx{
justify-content:center;//子元素水平居中，
align-items:center;//子元素垂直居中;
display:-webkit-flex;
}
//单行文本溢出

.xx{
overflow:hidden;
white-space:nowrap;
text-overflow:ellipsis;
}

多行文本溢出

.xx{
display:-webkit-box !importmort;
overflow:hidden;
text-overflow:ellipsis;
word-break:break-all;
-webkit-box-orient:vertical;
-webkit-line-clamp:2;(数字2表示隐藏两行)
}

使用流体图片

img{
width:100%;
height:auto;
width:auto\9;
}
一像素边框（例子:移动端列表的下边框）

.list-iteam:after{
position: absolute;
left: 0px;
right: 0px;
content: '';
height: 1px;
transform: scaleY(0.5);
-moz-transform: scaleY(0.5);
-webkit-transform:scaleY(0.5);

}

针对适配等比缩放的方法:

@media only screen and (min-width: 1024px){
body{zoom:3.2;}
}
@media only screen and (min-width: 768px) and (max-width: 1023px) {
body{zoom:2.4;}
}
@media only screen and (min-width: 640px) and (max-width: 767px) {
body{zoom:2;}
}
@media only screen and (min-width: 540px) and (max-width: 639px) {
body{zoom:1.68;}
}
@media only screen and (min-width: 480px) and (max-width: 539px) {
body{zoom:1.5;}
}
@media only screen and (min-width: 414px) and (max-width: 479px) {
body{zoom:1.29;}
}
@media only screen and (min-width: 400px) and (max-width: 413px) {
body{zoom:1.25;}
}
@media only screen and (min-width: 375px) and (max-width: 413px) {
body{zoom:1.17;}
}
@media only screen and (min-width: 360px) and (max-width:374px) {
body{zoom:1.125;}
}

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

抓取网页内容生成Kindle电子书

Thu, 27 Mar 2014 00:00:00 CST

自从买了kindle后，总是想着如何最大效用发挥其效用。虽然多看上有很多书可以购买，网上也有很多免费的电子书，但是仍然有很多感兴趣的内容是以网页的形式存在的。例如 O’Reilly Atlas就提供了诸多电子书，但是只提供免费的在线阅读；另外还有很多资料或文档都只有网页形式。于是就希望通过某种方法讲这些在线资料转为epub或mobi格式，以便在kindle上阅读。这篇文章介绍了如何借助calibre并编写少量代码来达到这个目的。

Calibre

Calibre简介

Calibre是一个免费的电子书管理工具，可以兼容Windows, OS X及Linux，令人欣喜的是，除了GUI外，calibre还提供了诸多命令行工具，其中的ebook-convert命令可以根据用户编写的recipes文件（实际是python代码）抓取指定页面内容并生成mobi等格式的电子书。通过编写recipes可以自定制抓取行为，以适应不同的网页结构。

安装Calibre

Calibre的下载地址是 http://calibre-ebook.com/download，可以根据自己的操作系统下载相应的安装程序。

如果是Linux操作系统，还可以通过软件仓库安装：

Archlinux：

pacman -S calibre

Debian/Ubuntu：

apt-get install calibre

RedHat/Fedora/CentOS：

yum -y install calibre

注意，如果你使用OSX，需要单独安装 Command Line Tool。

抓取网页生成电子书

下面以 Git Pocket Guide为例，说明如何通过calibre从网页生成电子书。

找到index页

要抓取整本书，第一件事就是找到index页，这个页面一般是Table of Contents，也就是目录页，其中每个目录项链接到相应内容页。index页将会指导抓取哪些页面以及生成电子书时内容组织顺序。在这个例子中，index页面是 http://chimera.labs.oreilly.com/books/1230000000561/index.html。

编写recipes

Recipes是一个以recipe为扩展名的脚本，内容实际上是一段python代码，用来定义calibre抓取页面的范围和行为，下面是用于抓取Git Pocket Guide的recipes：

from calibre.web.feeds.recipes import BasicNewsRecipe

class Git_Pocket_Guide(BasicNewsRecipe):

    title = 'Git Pocket Guide'
    description = ''
    cover_url = 'http://akamaicovers.oreilly.com/images/0636920024972/lrg.jpg'

    url_prefix = 'http://chimera.labs.oreilly.com/books/1230000000561/'
    no_stylesheets = True
    keep_only_tags = [{ 'class': 'chapter' }]

    def get_title(self, link):
        return link.contents[0].strip()

    def parse_index(self):
        soup = self.index_to_soup(self.url_prefix + 'index.html')

        div = soup.find('div', { 'class': 'toc' })

        articles = []
        for link in div.findAll('a'):
            if '#' in link['href']:
                continue

            if not 'ch' in link['href']:
                continue

            til = self.get_title(link)
            url = self.url_prefix + link['href']
            a = { 'title': til, 'url': url }

            articles.append(a)

        ans = [('Git_Pocket_Guide', articles)]

        return ans

下面分别解释代码中不同部分。

总体结构

总体来看，一个recipes就是一个python class，只不过这个class必须继承calibre.web.feeds.recipes.BasicNewsRecipe。

parse_index

整个recipes的核心方法是parse_index，也是recipes唯一必须实现的方法。这个方法的目标是通过分析index页面的内容，返回一个稍显复杂的数据结构（稍后介绍），这个数据结构定义了整个电子书的内容及内容组织顺序。

总体属性设置

在class的开始，定义了一些全局属性：

title = 'Git Pocket Guide'
description = ''
cover_url = 'http://akamaicovers.oreilly.com/images/0636920024972/lrg.jpg'

url_prefix = 'http://chimera.labs.oreilly.com/books/1230000000561/'
no_stylesheets = True
keep_only_tags = [{ 'class': 'chapter' }]

title：电子书标题
description：电子书描述
cover_url：电子书的封面图片
url_prefix：这是我自用的属性，是内容页面的前缀，用于后面拼装内容页的完整url
no_stylesheets：不要使用页面CSS样式
keep_only_tags：这一行告诉calibre分析index页时仅考虑class属性为“chapter”的DOM元素，如果你看index页的源码会发现这对应一级标题。之所以这样是因为在这个例子中，index页面每个一级标题对应一个独立内容页，而二级标题仅链接到页面中某个锚点（anchor），所以仅需考虑一级标题

parse_index返回值

下面介绍parse_index需要通过分析index页面返回的数据结构。

总体返回数据结构是一个list，其中每个元素是一个tuple，一个tuple表示一卷（volume）。在这个例子中只有一卷，所以list中只有一个tuple。

每个tuple有两个元素，第一个元素是卷名，第二个元素是一个list，list中每个元素是一个map，表示一章（chapter），map中有两个元素：title和url，title是章节标题，url是章节所在内容页的url。

Calibre会根据parse_index的返回结果抓取并组织整个书，并且会自行抓取并处理内容中外链的图片。

整个parse_index使用soup解析index页并生成上述数据结构。

上面是最基本的recipes，想了解更多的使用方法，可以参考 API文档。

生成mobi

编写好recipes后，在命令行下通过如下命令即可生成电子书：

ebook-convert Git_Pocket_Guide.recipe Git_Pocket_Guide.mobi

即可生成mobi格式的电子书。ebook-convert会根据recipes代码自行抓取相关内容并组织结构。

最终效果

下面是在kindle上看到的效果。

内容一

内容二

含有图片的页

实际效果

我的recipes仓库

我在github上建了一个 kindle-open-books，里面放了一些recipes，有我写的，也有其他同学贡献的。欢迎任何人贡献的recipes。

网页性能管理详解

Thu, 17 Sep 2015 08:26:22 CST

你遇到过性能很差的网页吗？

这种网页响应非常缓慢，占用大量的CPU和内存，浏览起来常常有卡顿，页面的动画效果也不流畅。

你会有什么反应？我猜想，大多数用户会关闭这个页面，改为访问其他网站。作为一个开发者，肯定不愿意看到这种情况，那么怎样才能提高性能呢？

本文将详细介绍性能问题的出现原因，以及解决方法。

一、网页生成的过程

要理解网页性能为什么不好，就要了解网页是怎么生成的。

网页的生成过程，大致可以分成五步。

HTML代码转化成DOM

CSS代码转化成CSSOM（CSS Object Model）

结合DOM和CSSOM，生成一棵渲染树（包含每个节点的视觉信息）

生成布局（layout），即将所有渲染树的所有节点进行平面合成

将布局绘制（paint）在屏幕上

这五步里面，第一步到第三步都非常快，耗时的是第四步和第五步。

"生成布局"（flow）和"绘制"（paint）这两步，合称为"渲染"（render）。

二、重排和重绘

网页生成的时候，至少会渲染一次。用户访问的过程中，还会不断重新渲染。

以下三种情况，会导致网页重新渲染。

修改DOM

修改样式表

用户事件（比如鼠标悬停、页面滚动、输入框键入文字、改变窗口大小等等）

重新渲染，就需要重新生成布局和重新绘制。前者叫做"重排"（reflow），后者叫做"重绘"（repaint）。

需要注意的是， "重绘"不一定需要"重排"，比如改变某个网页元素的颜色，就只会触发"重绘"，不会触发"重排"，因为布局没有改变。但是， "重排"必然导致"重绘"，比如改变一个网页元素的位置，就会同时触发"重排"和"重绘"，因为布局改变了。

三、对于性能的影响

重排和重绘会不断触发，这是不可避免的。但是，它们非常耗费资源，是导致网页性能低下的根本原因。

提高网页性能，就是要降低"重排"和"重绘"的频率和成本，尽量少触发重新渲染。

前面提到，DOM变动和样式变动，都会触发重新渲染。但是，浏览器已经很智能了，会尽量把所有的变动集中在一起，排成一个队列，然后一次性执行，尽量避免多次重新渲染。

   
div.style.color = 'blue';
div.style.marginTop = '30px';

上面代码中，div元素有两个样式变动，但是浏览器只会触发一次重排和重绘。

如果写得不好，就会触发两次重排和重绘。

   
div.style.color = 'blue';
var margin = parseInt(div.style.marginTop);
div.style.marginTop = (margin + 10) + 'px';

上面代码对div元素设置背景色以后，第二行要求浏览器给出该元素的位置，所以浏览器不得不立即重排。

一般来说，样式的写操作之后，如果有下面这些属性的读操作，都会引发浏览器立即重新渲染。

offsetTop/offsetLeft/offsetWidth/offsetHeight

scrollTop/scrollLeft/scrollWidth/scrollHeight

clientTop/clientLeft/clientWidth/clientHeight

getComputedStyle()

所以，从性能角度考虑，尽量不要把读操作和写操作，放在一个语句里面。

   
// bad
div.style.left = div.offsetLeft + 10 + "px";
div.style.top = div.offsetTop + 10 + "px";

// good
var left = div.offsetLeft;
var top  = div.offsetTop;
div.style.left = left + 10 + "px";
div.style.top = top + 10 + "px";

一般的规则是：

样式表越简单，重排和重绘就越快。

重排和重绘的DOM元素层级越高，成本就越高。

table元素的重排和重绘成本，要高于div元素

四、提高性能的九个技巧

有一些技巧，可以降低浏览器重新渲染的频率和成本。

第一条是上一节说到的，DOM 的多个读操作（或多个写操作），应该放在一起。不要两个读操作之间，加入一个写操作。

第二条，如果某个样式是通过重排得到的，那么最好缓存结果。避免下一次用到的时候，浏览器又要重排。

第三条，不要一条条地改变样式，而要通过改变class，或者csstext属性，一次性地改变样式。

   
// bad
var left = 10;
var top = 10;
el.style.left = left + "px";
el.style.top  = top  + "px";

// good 
el.className += " theclassname";

// good
el.style.cssText += "; left: " + left + "px; top: " + top + "px;";

第四条，尽量使用离线DOM，而不是真实的网面DOM，来改变元素样式。比如，操作Document Fragment对象，完成后再把这个对象加入DOM。再比如，使用 cloneNode() 方法，在克隆的节点上进行操作，然后再用克隆的节点替换原始节点。

第五条，先将元素设为 display: none （需要1次重排和重绘），然后对这个节点进行100次操作，最后再恢复显示（需要1次重排和重绘）。这样一来，你就用两次重新渲染，取代了可能高达100次的重新渲染。

第六条，position属性为absolute或fixed的元素，重排的开销会比较小，因为不用考虑它对其他元素的影响。

第七条，只在必要的时候，才将元素的display属性为可见，因为不可见的元素不影响重排和重绘。另外，visibility : hidden 的元素只对重排有影响，不影响重绘。

第八条，使用虚拟DOM的脚本库，比如React等。

第九条，使用 window.requestAnimationFrame()、window.requestIdleCallback() 这两个方法调节重新渲染（详见后文）。

五、刷新率

很多时候，密集的重新渲染是无法避免的，比如scroll事件的回调函数和网页动画。

网页动画的每一帧（frame）都是一次重新渲染。每秒低于24帧的动画，人眼就能感受到停顿。 一般的网页动画，需要达到每秒30帧到60帧的频率，才能比较流畅。如果能达到每秒70帧甚至80帧，就会极其流畅。

大多数显示器的刷新频率是60Hz，为了与系统一致，以及节省电力，浏览器会自动按照这个频率，刷新动画（如果可以做到的话）。

所以，如果网页动画能够做到每秒60帧，就会跟显示器同步刷新，达到最佳的视觉效果。这意味着， 一秒之内进行60次重新渲染，每次重新渲染的时间不能超过16.66毫秒。

一秒之间能够完成多少次重新渲染，这个指标就被称为"刷新率"，英文为FPS（frame per second）。60次重新渲染，就是60FPS。

六、开发者工具的Timeline面板

Chrome浏览器开发者工具的Timeline面板，是查看"刷新率"的最佳工具。这一节介绍如何使用这个工具。

首先，按下 F12 打开"开发者工具"，切换到Timeline面板。

左上角有一个灰色的圆点，这是录制按钮，按下它会变成红色。然后，在网页上进行一些操作，再按一次按钮完成录制。

Timeline面板提供两种查看方式：横条的是"事件模式"（Event Mode），显示重新渲染的各种事件所耗费的时间；竖条的是"帧模式"（Frame Mode），显示每一帧的时间耗费在哪里。

先看"事件模式"，你可以从中判断，性能问题发生在哪个环节，是JavaScript的执行，还是渲染？

不同的颜色表示不同的事件。

蓝色：网络通信和HTML解析

黄色：JavaScript执行

紫色：样式计算和布局，即重排

绿色：重绘

哪种色块比较多，就说明性能耗费在那里。色块越长，问题越大。

帧模式（Frames mode）用来查看单个帧的耗时情况。每帧的色柱高度越低越好，表示耗时少。

你可以看到，帧模式有两条水平的参考线。

下面的一条是60FPS，低于这条线，可以达到每秒60帧；上面的一条是30FPS，低于这条线，可以达到每秒30次渲染。如果色柱都超过30FPS，这个网页就有性能问题了。

此外，还可以查看某个区间的耗时情况。

或者点击每一帧，查看该帧的时间构成。

七、window.requestAnimationFrame()

有一些JavaScript方法可以调节重新渲染，大幅提高网页性能。

其中最重要的，就是 window.requestAnimationFrame() 方法。它可以将某些代码放到下一次重新渲染时执行。

   
function doubleHeight(element) {
  var currentHeight = element.clientHeight;
  element.style.height = (currentHeight * 2) + 'px';
}
elements.forEach(doubleHeight);

上面的代码使用循环操作，将每个元素的高度都增加一倍。可是，每次循环都是，读操作后面跟着一个写操作。这会在短时间内触发大量的重新渲染，显然对于网页性能很不利。

我们可以使用 window.requestAnimationFrame()，让读操作和写操作分离，把所有的写操作放到下一次重新渲染。

   
function doubleHeight(element) {
  var currentHeight = element.clientHeight;
  window.requestAnimationFrame(function () {
    element.style.height = (currentHeight * 2) + 'px';
  });
}
elements.forEach(doubleHeight);

页面滚动事件（scroll）的监听函数，就很适合用 window.requestAnimationFrame() ，推迟到下一次重新渲染。

   
$(window).on('scroll', function() {
   window.requestAnimationFrame(scrollHandler);
});

当然，最适用的场合还是网页动画。下面是一个旋转动画的例子，元素每一帧旋转1度。

   
var rAF = window.requestAnimationFrame;

var degrees = 0;
function update() {
  div.style.transform = "rotate(" + degrees + "deg)";
  console.log('updated to degrees ' + degrees);
  degrees = degrees + 1;
  rAF(update);
}
rAF(update);

八、window.requestIdleCallback()

还有一个函数 window.requestIdleCallback()，也可以用来调节重新渲染。

它指定只有当一帧的末尾有空闲时间，才会执行回调函数。

   
requestIdleCallback(fn);

上面代码中，只有当前帧的运行时间小于16.66ms时，函数fn才会执行。否则，就推迟到下一帧，如果下一帧也没有空闲时间，就推迟到下下一帧，以此类推。

它还可以接受第二个参数，表示指定的毫秒数。如果在指定的这段时间之内，每一帧都没有空闲时间，那么函数fn将会强制执行。

   
requestIdleCallback(fn, 5000);

上面的代码表示，函数fn最迟会在5000毫秒之后执行。

函数 fn 可以接受一个 deadline 对象作为参数。

   
requestIdleCallback(function someHeavyComputation(deadline) {
  while(deadline.timeRemaining() > 0) {
    doWorkIfNeeded();
  }

  if(thereIsMoreWorkToDo) {
    requestIdleCallback(someHeavyComputation);
  }
});

上面代码中，回调函数 someHeavyComputation 的参数是一个 deadline 对象。

deadline对象有一个方法和一个属性：timeRemaining() 和 didTimeout。

（1）timeRemaining() 方法

timeRemaining() 方法返回当前帧还剩余的毫秒。这个方法只能读，不能写，而且会动态更新。因此可以不断检查这个属性，如果还有剩余时间的话，就不断执行某些任务。一旦这个属性等于0，就把任务分配到下一轮 requestIdleCallback。

前面的示例代码之中，只要当前帧还有空闲时间，就不断调用doWorkIfNeeded方法。一旦没有空闲时间，但是任务还没有全执行，就分配到下一轮 requestIdleCallback。

（2）didTimeout属性

deadline对象的 didTimeout 属性会返回一个布尔值，表示指定的时间是否过期。这意味着，如果回调函数由于指定时间过期而触发，那么你会得到两个结果。

timeRemaining方法返回0

didTimeout 属性等于 true

因此，如果回调函数执行了，无非是两种原因：当前帧有空闲时间，或者指定时间到了。

   
function myNonEssentialWork (deadline) {
  while ((deadline.timeRemaining() > 0 || deadline.didTimeout) && tasks.length > 0)
    doWorkIfNeeded();

  if (tasks.length > 0)
    requestIdleCallback(myNonEssentialWork);
}

requestIdleCallback(myNonEssentialWork, 5000);

上面代码确保了，doWorkIfNeeded 函数一定会在将来某个比较空闲的时间（或者在指定时间过期后）得到反复执行。

requestIdleCallback 是一个很新的函数，刚刚引入标准，目前只有Chrome支持。

九、参考链接

Domenico De Felice, How browsers work
Stoyan Stefanov, Rendering: repaint, reflow/relayout, restyle
Addy Osmani, Improving Web App Performance With the Chrome DevTools Timeline and Profiles
Tom Wiltzius, Jank Busting for Better Rendering Performance
Paul Lewis, Using requestIdleCallback

（完）

文档信息

版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）
发表日期： 2015年9月17日
更多内容：档案 » 开发者手册
购买文集：《如何变得有思想》
社交媒体： twitter， weibo
Feed订阅：

Chromium网页Graphics Layer Tree创建过程分析

Mon, 29 Feb 2016 08:59:09 CST

在前面一文中，我们分析了网页Render Layer Tree的创建过程。在创建Render Layer的同时，WebKit还会为其创建Graphics Layer。这些Graphics Layer形成一个Graphics Layer Tree。Graphics Layer可看作是一个图形缓冲区，被若干Render Layer共用。本文接下来就分析Graphics Layer Tree的创建过程。

老罗的新浪微博： http://weibo.com/shengyangluo，欢迎关注！

网页的Render Layer Tree与Graphics Layer Tree的关系可以通过图1描述，如下所示：

图1 Graphics Layer Tree与DOM Tree、Render Object Tree和Render Layer Tree的关系

在WebKit中，Graphics Layer又称为Composited Layer。我们可以将Graphics Layer看作是Composited Layer的一种具体实现。这种具体实现是由WebKit的使用者Chromium提供的。Composited Layer描述的是一个具有后端存储的图层，因此可以将它看作是一个图形缓冲区。在软件渲染方式中，这个图形缓冲区就是一块系统内存；在硬件渲染方式中，这个图形缓冲区就是一个OpenGL里面的一个Frame Buffer Object（FBO）。

Composited Layer涉及到的一个重要概念是“Layer Compositing”。Layer Compositing是现代UI框架普遍采用的一种渲染机制。例如，Android系统的UI子系统（Surface Flinger）就是通过Compositing Surface来获得最终要显示在屏幕上的内容的。这里的Surface就相当于是Chromium的Layer。关于Android系统的Surface Flinger的详细分析，可以参考 Android系统Surface机制的SurfaceFlinger服务简要介绍和学习计划这个系列的文章。

Layer Compositing的三个主要任务是：

1. 确定哪些内容应该在哪些Composited Layer上绘制；

2. 绘制每一个Composited Layer；

3. 将所有已经绘制好的Composited Layer再次将绘制在一个最终的、可以显示在屏幕上进行显示的图形缓冲区中。

其中，第1个任务它完成之后就可以获得一个Graphics Layer Tree，第3个任务要求按照一定的顺序对Composited Layer进行绘制。注意，这个绘制顺序非常重要，否则最终合成出来的UI就会出现不正确的Overlapping。同时，这个绘制顺序对理解Graphics Layer Tree的组成也非常重要。因此，接下来我们首先介绍与这个绘制顺序有关的概念。为了方便描述，本文将上述绘制顺序称为Composited Layer的绘制顺序。

在介绍Composited Layer的绘制顺序之前，我们还需要回答一个问题：为什么要采用Layer Compositing这种UI渲染机制？主要有两个原因：

1. 避免不必要的重绘。考虑一个网页有两个Layer。在网页的某一帧显示中，Layer 1的元素发生了变化，Layer 2的元素没有发生变化。这时候只需要重新绘制Layer 1的内容，然后再与Layer 2原有的内容进行Compositing，就可以得到整个网页的内容。这样就可以避免对没有发生变化的Layer 2进行不必要的绘制。

2. 利用硬件加速高效实现某些UI特性。例如网页的某一个Layer设置了可滚动、3D变换、透明度或者滤镜，那么就可以通过GPU来高效实现。

在默认情况下，网页元素的绘制是按照Render Object Tree的先序遍历顺序进行的，并且它们在空间上是按照各自的display属性值依次进行布局的。例如，如果一个网页元素的display属性值为"inline"，那么它就会以内联元素方式显示，也就是紧挨在前一个绘制的元素的后面进行显示。又如，如果一个网页元素的display属性值为"block"，那么它就会以块级元素进行显示，也就是它的前后会各有一个换行符。我们将这种网页元素绘制方式称为Normal Flow或者In Flow。

有默认情况，就会例外情况。例如，如果一个网页元素同时设置了position和z-index属性，那么它可能就不会以In Flow的方式进行显示，而是以Out of Flow的方式进行显示。在默认情况下，一个网页元素的position和z-index属性值被设置为“static”和"auto"。网页元素的position属性还可以取值为“relative”、“absolute”和“fixed”，这一类网页元素称为Positioned元素。当一个Positioned元素的z-index属性值不等于"auto"时，它就会以Out of Flow的方式进行显示。

CSS 2.1规范规定网页渲染引擎要为每一个z-index属性值不等于"auto"的Positioned元素创建一个Stacking Context。对于其它的元素，它们虽然没有自己的Stacking Context，但是它们会与最近的、具有自己的Stacking Context的元素共享同相同的Stacking Context。不同Stacking Context的元素的绘制顺序是不会相互交叉的。假设有两个Stacking Context，一个包含有A和B两个元素，另一个包含有C和D两个元素，那么A、B、C和D四个元素的绘制顺序只可能为：

1. A、B、C、D

2. B、A、C、D

3. A、B、D、C

4. B、A、D、C

5. C、D、A、B

6. C、D、B、A

7. D、C、A、B

8. D、C、B、A

Stacking Context的这个特性，使得它可以成为一个观念上的原子类型绘制层（Atomic Conceptual Layer for Painting）。也就是说，只要我们定义好Stacking Context内部元素的绘制顺序，那么再根据拥有Stacking Context的元素的z-index属性值，那么就可以得到网页的所有元素的绘制顺序。

我们可以通过图2所示的例子直观地理解Stacking Context的上述特性，如下所示：

图2 Stacking Context

在图2的左边，一共有4个Stacking Context。最下面的Stacking Context的z-index等于-1；中间的Stacking Context的z-index等于0；最上面的Stacking Context的z-index等于1，并且嵌套了另外一个z-index等于6的Stacking Context。我们观察被嵌套的z-index等于6的Stacking Context，它包含了另外一个z-index也是等于6的元素，但是这两个z-index的含义是不一样的。其中，Stacking Context的z-index值是放在父Stacking Context中讨论才有意义，而元素的z-index放在当前它所在的Stacking Context讨论才有意义。再者，我们是下面和中间的两个Stacking Context，虽然它们都包含有三个z-index分别等于7、8和9的元素，但是它们是完全不相干的。

如果我们将图2左边中间的Stacking Context的z-index修改为2，那么它就会变成最上面的Stacking Context，并且会重叠在z-index等于1的Stacking Context上，以及嵌套在这个Stacking Context里面的那个Stacking Context。

这样，我们就得到了Stacking Context的绘制顺序。如前所述，接下来只要定义好Stacking Context内的元素的绘制顺序，那么就可以网页的所有元素的绘制顺序。Stacking Context内的元素的绘制顺序如下所示：

1. 背景（Backgrounds）和边界（Borders），也就是拥有Stacking Context的元素的背景和边界。

2. Z-index值为负数的子元素。

3. 内容（Contents），也就是拥有Stacking Context的元素的内容。

4. Normal Flow类型的子元素。

5. Z-index值为正数的子元素。

以上就是与Composited Layer的绘制顺序有关的背景知识。这些背景知识在后面分析Graphics Layer Tree的创建过程时就会用到。

从图1可以看到，Graphics Layer Tree是根据Render Layer Tree创建的。也就是说，Render Layer与Graphics Layer存在对应关系，如下所示：

图3 Render Layer Tree与Graphics Layer的关系

原则上，Render Layer Tree中的每一个Render Layer都对应有一个Composited Layer Mapping，每一个Composited Layer Mapping又包含有若干个Graphics Layer。但是这样将会导致创建大量的Graphics Layer。创建大量的Graphics Layer意味着需要耗费大量的内存资源。这个问题称为”Layer Explosion“问题。

为了解决“Layer Explosion”问题，每一个需要创建Composited Layer Mapping的Render Layer都需要给出一个理由。这个理由称为“Compositing Reason”，它描述的实际上是Render Layer的特证。例如，如果一个Render Layer关联的Render Object设置了3D Transform属性，那么就需要为该Render Layer创建一个Composited Layer Mapping。

WebKit一共定义了54个Compositing Reason，如下所示：

// Intrinsic reasons that can be known right away by the layer
const uint64_t CompositingReason3DTransform                              = UINT64_C(1) << 0;
const uint64_t CompositingReasonVideo                                    = UINT64_C(1) << 1;
const uint64_t CompositingReasonCanvas                                   = UINT64_C(1) << 2;
const uint64_t CompositingReasonPlugin                                   = UINT64_C(1) << 3;
const uint64_t CompositingReasonIFrame                                   = UINT64_C(1) << 4;
const uint64_t CompositingReasonBackfaceVisibilityHidden                 = UINT64_C(1) << 5;
const uint64_t CompositingReasonActiveAnimation                          = UINT64_C(1) << 6;
const uint64_t CompositingReasonTransitionProperty                       = UINT64_C(1) << 7;
const uint64_t CompositingReasonFilters                                  = UINT64_C(1) << 8;
const uint64_t CompositingReasonPositionFixed                            = UINT64_C(1) << 9;
const uint64_t CompositingReasonOverflowScrollingTouch                   = UINT64_C(1) << 10;
const uint64_t CompositingReasonOverflowScrollingParent                  = UINT64_C(1) << 11;
const uint64_t CompositingReasonOutOfFlowClipping                        = UINT64_C(1) << 12;
const uint64_t CompositingReasonVideoOverlay                             = UINT64_C(1) << 13;
const uint64_t CompositingReasonWillChangeCompositingHint                = UINT64_C(1) << 14;

// Overlap reasons that require knowing what's behind you in paint-order before knowing the answer
const uint64_t CompositingReasonAssumedOverlap                           = UINT64_C(1) << 15;
const uint64_t CompositingReasonOverlap                                  = UINT64_C(1) << 16;
const uint64_t CompositingReasonNegativeZIndexChildren                   = UINT64_C(1) << 17;
const uint64_t CompositingReasonScrollsWithRespectToSquashingLayer       = UINT64_C(1) << 18;
const uint64_t CompositingReasonSquashingSparsityExceeded                = UINT64_C(1) << 19;
const uint64_t CompositingReasonSquashingClippingContainerMismatch       = UINT64_C(1) << 20;
const uint64_t CompositingReasonSquashingOpacityAncestorMismatch         = UINT64_C(1) << 21;
const uint64_t CompositingReasonSquashingTransformAncestorMismatch       = UINT64_C(1) << 22;
const uint64_t CompositingReasonSquashingFilterAncestorMismatch          = UINT64_C(1) << 23;
const uint64_t CompositingReasonSquashingWouldBreakPaintOrder            = UINT64_C(1) << 24;
const uint64_t CompositingReasonSquashingVideoIsDisallowed               = UINT64_C(1) << 25;
const uint64_t CompositingReasonSquashedLayerClipsCompositingDescendants = UINT64_C(1) << 26;

// Subtree reasons that require knowing what the status of your subtree is before knowing the answer
const uint64_t CompositingReasonTransformWithCompositedDescendants       = UINT64_C(1) << 27;
const uint64_t CompositingReasonOpacityWithCompositedDescendants         = UINT64_C(1) << 28;
const uint64_t CompositingReasonMaskWithCompositedDescendants            = UINT64_C(1) << 29;
const uint64_t CompositingReasonReflectionWithCompositedDescendants      = UINT64_C(1) << 30;
const uint64_t CompositingReasonFilterWithCompositedDescendants          = UINT64_C(1) << 31;
const uint64_t CompositingReasonBlendingWithCompositedDescendants        = UINT64_C(1) << 32;
const uint64_t CompositingReasonClipsCompositingDescendants              = UINT64_C(1) << 33;
const uint64_t CompositingReasonPerspectiveWith3DDescendants             = UINT64_C(1) << 34;
const uint64_t CompositingReasonPreserve3DWith3DDescendants              = UINT64_C(1) << 35;
const uint64_t CompositingReasonReflectionOfCompositedParent             = UINT64_C(1) << 36;
const uint64_t CompositingReasonIsolateCompositedDescendants             = UINT64_C(1) << 37;

// The root layer is a special case that may be forced to be a layer, but also it needs to be
// a layer if anything else in the subtree is composited.
const uint64_t CompositingReasonRoot                                     = UINT64_C(1) << 38;

// CompositedLayerMapping internal hierarchy reasons
const uint64_t CompositingReasonLayerForAncestorClip                     = UINT64_C(1) << 39;
const uint64_t CompositingReasonLayerForDescendantClip                   = UINT64_C(1) << 40;
const uint64_t CompositingReasonLayerForPerspective                      = UINT64_C(1) << 41;
const uint64_t CompositingReasonLayerForHorizontalScrollbar              = UINT64_C(1) << 42;
const uint64_t CompositingReasonLayerForVerticalScrollbar                = UINT64_C(1) << 43;
const uint64_t CompositingReasonLayerForScrollCorner                     = UINT64_C(1) << 44;
const uint64_t CompositingReasonLayerForScrollingContents                = UINT64_C(1) << 45;
const uint64_t CompositingReasonLayerForScrollingContainer               = UINT64_C(1) << 46;
const uint64_t CompositingReasonLayerForSquashingContents                = UINT64_C(1) << 47;
const uint64_t CompositingReasonLayerForSquashingContainer               = UINT64_C(1) << 48;
const uint64_t CompositingReasonLayerForForeground                       = UINT64_C(1) << 49;
const uint64_t CompositingReasonLayerForBackground                       = UINT64_C(1) << 50;
const uint64_t CompositingReasonLayerForMask                             = UINT64_C(1) << 51;
const uint64_t CompositingReasonLayerForClippingMask                     = UINT64_C(1) << 52;
const uint64_t CompositingReasonLayerForScrollingBlockSelection          = UINT64_C(1) << 53;

这些Compositing Reason定义在文件external/chromium_org/third_party/WebKit/Source/platform/graphics/CompositingReasons.h中。

其中，有3个Compositing Reason比较特殊，如下所示：

const uint64_t CompositingReasonComboSquashableReasons =
    CompositingReasonOverlap
    | CompositingReasonAssumedOverlap
    | CompositingReasonOverflowScrollingParent;

它们是CompositingReasonOverlap、CompositingReasonAssumedOverlap和CompositingReasonOverflowScrollingParent，称为Squashable Reason。WebKit不会为具有这三种特征的Render Layer之一的Render Layer创建Composited Layer Mapping。

如果启用了Overlap Testing，那么WebKit会根据上述的Stacking Context顺序计算每一个Render Layer的后面是否有其它的Render Layer与其重叠。如果有，并且与其重叠的Render Layer有一个对应的Composited Layer Mapping，那么就会将位于上面的Render Layer的Compositing Reason设置为CompositingReasonOverlap。

如果没有启用Overlap Testing，那么WebKit会根据上述的Stacking Context顺序检查每一个Render Layer的后面是否有一个具有Composited Layer Mapping的Render Layer。只要有，不管它们是否重叠，那么就会将位于上面的Render Layer的Compositing Reason设置为CompositingReasonAssumedOverlap。

最后，如果一个Render Layer包含在一个具有overflow属性为"scroll"的Render Block中，并且该Render Block所对应的Render Layer具有Composited Layer Mapping，那么该Render Layer的Compositing Reason就会被设置为CompositingReasonOverflowScrollingParent。

WebKit会将位于一个具有Composited Layer Mapping的Render Layer的上面的那些有着Squashable Reason的Render Layer绘制在同一个Graphics Layer中。这种Graphics Layer称为Squashing Graphics Layer。这种机制也相应地称为“Layer Squashing”。通过Layer Squashing机制，就可以在一定程度上减少Graphics Layer的数量，从而在一定程度上解决“Layer Explosion”问题。

我们思考一下，为什么WebKit会将具有上述3种Compositing Reason的Render Layer绘制在一个Squashing Graphics Layer中？考虑具有CompositingReasonOverlap和CompositingReasonAssumedOverlap的Render Layer，当它们需要重绘，或者它们下面的具有Composited Layer Mapping的Render Layer重绘时，都不可避免地对它们以及它们下面的具有Composited Layer Mapping的Render Layer进行Compositing。这是由于它们相互之间存在重叠区域，只要其中一个发生变化，就会牵一发而动全身。类似地，当一个overflow属性为"scroll"的Render Block滚动时，包含在该Render Block内的Render Layer在执行完成重绘操作之后，需要参与到Compositing操作去。

WebKit定义了两个函数，用来判断一个Render Layer是需要Compositing还是Squashing，如下所示：

// Any reasons other than overlap or assumed overlap will require the layer to be separately compositing.
inline bool requiresCompositing(CompositingReasons reasons)
{
    return reasons & ~CompositingReasonComboSquashableReasons;
}

// If the layer has overlap or assumed overlap, but no other reasons, then it should be squashed.
inline bool requiresSquashing(CompositingReasons reasons)
{
    return !requiresCompositing(reasons) && (reasons & CompositingReasonComboSquashableReasons);
}

这两个函数定义在文件external/chromium_org/third_party/WebKit/Source/platform/graphics/CompositingReasons.h中。

参数reasons描述的是一个Render Layer的Compositing Reason，函数requiresCompositing判断该Render Layer是否需要Compositing，也就是是否要为该Render Layer创建一个Composited Layer Mapping，而函数requiresSquashing判断该Render Layer需要Squashing，也就是绘制在一个Squashing Graphics Layer中。

除了Compositing Render Layer和Squashing Render Layer，剩下的其它Render Layer称为Non-Compositing Render Layer。这些Render Layer将会与离其最近的具有Composited Layer Mapping的父Render Layer绘制同样的Graphics Layer中。

WebKit是根据Graphics Layer Tree来绘制网页内容的。在绘制一个Graphics Layer的时候，除了绘制Graphics Layer本身所有的内容之外，还会在Render Layer Tree中。找到与该Graphics Layer对应的Render Layer，并且从该Render Layer开始，将那些Non-Compositing类型的子Render Layer也一起绘制，直到遇到一个具有Composited Layer Mapping的子Render Layer为止。这个过程在后面的文章中分析网页内容的绘制过程时就会看到。

前面提到，Composited Layer Mapping包含有若干个Graphics Layer，这些Graphics Layer在Composited Layer Mapping，也是形成一个Graphics Layer Sub Tree的，如图4所示：

图4 Composited Layer Mapping

图4的左边是一个Render Layer Tree。其中红色的Render Layer有对应的Composited Layer Mapping。每一个Composited Layer Mapping内部都有一个Graphics Layer Sub Tree。同时，这些Graphics Layer Sub Tree又会组合在一起，从而形成整个网页的Graphics Layer Tree。

一个典型的Composited Layer Mapping对应的部分Graphics Layer Sub Tree如图5所示：

图5 一个Composited Layer Mapping对应的Graphics Layer Sub Tree的一部分

注意，图5描述的是仅仅是一个Composited Layer Mapping对应的Graphics Layer Sub Tree的一部分。例如，如果拥有该Composited Layer Mapping的Render Layer的上面存在Squashing Render Layer，那么上述Graphics Layer Sub Tree还包含有一个Squashing Graphics Layer。不过这一部分Graphics Layer Sub Tree已经足于让我们理解Composited Layer Mapping的组成。

在图5中，只有Main Layer是必须存在的，它用来绘制一个Render Layer自身的内容。其它的Graphics Layer是可选，其中：

1. 如果一个Render Layer被父Render Layer设置了裁剪区域，那么就会存在Clip Layer。

2. 如果一个Render Layer为子Render Layer设置了裁剪区域，那么就会存在Children Clip Layer。

3. 如果一个Render Layer是可滚动的，那么就会存在Scrolling Container。

4. Negative z-order children、Normal flow children和Positive z-order children描述的是按照Stacking Context规则排序的子Render Layer对应的Composited Layer Mapping描述的Graphics Layer Sub Tree，它们均以父Render Layer的Scrolling Container为父Graphics Layer。

5. 如果一个Render Layer是根Render Layer，并且它的背景被设置为固定的，即网页的body标签的CSS属性background-attachment被设置为“fixed”，那么就会存在Background Layer。

6. 当Negative z-order children存在时，就会存在Foreground Layer。从前面描述的Stacking Context规则可以知道，Negative z-order childrenc对应的Graphics Layer Sub Tree先于当前Graphics Layer Sub Tree绘制。Negative z-order childrenc对应的Graphics Layer Sub Tree在绘制的时候可能会设置了偏移位置。这些偏移位置不能影响后面的Normal flow children和Positive z-order children对应的Graphics Layer Sub Tree的绘制，因此就需要在中间插入一个Foreground Layer，用来抵消Negative z-order children对应的Graphics Layer Sub Tree设置的偏移位置。

7. 如果一个Render Layer的上面存在Squashing Render Layer，那么就会存在Squashing Layer。

了解了Composited Layer Mapping对应的Graphics Layer Sub Tree的结构之后，接下来我们就可以结合源码分析网页的Graphics Layer Tree的创建过程了。网页的Graphics Layer Tree的创建主要是分三步进行：

1. 计算各个Render Layer Tree中的Render Layer的Compositing Reason;

2. 为有需要的Render Layer创建Composited Layer Mapping；

3. 将各个Composited Layer Mapping描述Graphics Layer Sub Tree连接起来形成Graphics Layer Tree。

上述过程主要是发生在网页的Layout过程中。对网页进行Layout是网页渲染过程的一个重要步骤，以后我们分析网页的渲染过程时就会看到这一点。在WebKit中，每一个正在加载的网页都关联有一个FrameView对象。当需要对网页进行Layout时，就会调用这个FrameView对象的成员函数updateLayoutAndStyleForPainting，它的实现如下所示：

void FrameView::updateLayoutAndStyleForPainting()
{
    // Updating layout can run script, which can tear down the FrameView.
    RefPtr<FrameView> protector(this);

    updateLayoutAndStyleIfNeededRecursive();

    if (RenderView* view = renderView()) {
        ......

        view->compositor()->updateIfNeededRecursive();

        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/frame/FrameView.cpp中。

FrameView类的成员函数updateLayoutAndStyleForPainting是通过调用另外一个成员函数updateLayoutAndStyleIfNeededRecursive对网页进行Layout的。

执行完成Layout操作之后，FrameView类的成员函数updateLayoutAndStyleForPainting又调用成员函数renderView获得一个RenderView对象。从前面 Chromium网页DOM Tree创建过程分析一文可以知道，网页的DOM Tree的根节点对应的Render Object就是一个RenderView对象。因此，前面获得的RenderView对象描述的就是正在加载的网页的Render Layer Tree的根节点。

再接下来，FrameView类的成员函数updateLayoutAndStyleForPainting又调用上述RenderView对象的成员函数compositor获得一个RenderLayerCompositor对象，如下所示：

RenderLayerCompositor* RenderView::compositor()
{
    if (!m_compositor)
        m_compositor = adoptPtr(new RenderLayerCompositor(*this));

    return m_compositor.get();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/RenderView.cpp中。

这个RenderLayerCompositor对象负责管理网页的Render Layer Tree，以及根据Render Layer Tree创建Graphics Layer Tree。

回到FrameView类的成员函数updateLayoutAndStyleForPainting中，它获得了正在加载的网页对应的RenderLayerCompositor对象之后，接下来就调用这个RenderLayerCompositor对象的成员函数updateIfNeededRecursive根据Render Layer Tree创建或者更新Graphics Layer Tree。

RenderLayerCompositor类的成员函数updateIfNeededRecursive的实现如下所示：

void RenderLayerCompositor::updateIfNeededRecursive()
{
    ......

    updateIfNeeded();
    
    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/RenderLayerCompositor.cpp中。

RenderLayerCompositor类的成员函数updateIfNeededRecursive调用另外一个成员函数updateIfNeeded创建Graphics Layer Tree，如下所示：

void RenderLayerCompositor::updateIfNeeded()
{
    CompositingUpdateType updateType = m_pendingUpdateType;
    m_pendingUpdateType = CompositingUpdateNone;

    if (!hasAcceleratedCompositing() || updateType == CompositingUpdateNone)
        return;

    RenderLayer* updateRoot = rootRenderLayer();

    Vector<RenderLayer*> layersNeedingRepaint;

    if (updateType >= CompositingUpdateAfterCompositingInputChange) {
        bool layersChanged = false;
        ......

        CompositingRequirementsUpdater(m_renderView, m_compositingReasonFinder).update(updateRoot);

        {
            ......
            CompositingLayerAssigner(this).assign(updateRoot, layersChanged, layersNeedingRepaint);
        }

        ......

        if (layersChanged)
            updateType = std::max(updateType, CompositingUpdateRebuildTree);
    }

    if (updateType != CompositingUpdateNone) {
        ......
        GraphicsLayerUpdater updater;
        updater.update(layersNeedingRepaint, *updateRoot);

        if (updater.needsRebuildTree())
            updateType = std::max(updateType, CompositingUpdateRebuildTree);

        ......
    }

    if (updateType >= CompositingUpdateRebuildTree) {
        GraphicsLayerVector childList;
        {
            ......
            GraphicsLayerTreeBuilder().rebuild(*updateRoot, childList);
        }

        if (childList.isEmpty())
            destroyRootLayer();
        else
            m_rootContentLayer->setChildren(childList);

        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/RenderLayerCompositor.cpp中。

当RenderLayerCompositor类的成员变量pendingUpdateType的值不等于CompositingUpdateNone的时候，就表明网页的Graphics Layer Tree需要进行更新。此外，要对网页的Graphics Layer Tree需要进行更新，还要求浏览器开启硬件加速合成。当调用RenderLayerCompositor类的成员函数hasAcceleratedCompositing得到的返回值等于true的时候，就表明浏览器开启了硬件加速合成。

当RenderLayerCompositor类的成员变量pendingUpdateType的值大于等于CompositingUpdateAfterCompositingInputChange的时候，表示Graphics Layer Tree的输入发生了变化，例如，Render Layer Tree中的某一个Render Layer的内容发生了变化。在这种情况下，RenderLayerCompositor类的成员函数updateIfNeeded会构造一个CompositingRequirementsUpdater对象，并且调用这个CompositingRequirementsUpdater对象的成员函数update从网页的Render Layer Tree的根节点开始，递归计算每一个Render Layer的Compositing Reason，主要就是根据各个Render Layer包含的Render Object的CSS属性来计算。

计算好网页的Render Layer Tree中的每一个Render Layer的Compositing Reason之后，RenderLayerCompositor类的成员函数updateIfNeeded接着再构造一个CompositingLayerAssigner对象，并且调用这个CompositingLayerAssigner对象的成员函数assign根据每一个Render Layer新的Compositing Reason决定是否需要为它创建一个新的Composited Layer Mapping或者删除它原来拥有的Composited Layer Mapping。如果有的Render Layer原来是没有Composited Layer Mapping的，现在有了Composited Layer Mapping，或者原来有Composited Layer Mapping，现在没有了Composited Layer Mapping，那么本地变量layersChanged的值就会被设置为true。这时候本地变量updateType的值会被更新为CompositingUpdateRebuildTree。

在本地变量updateType的值是否不等于CompositingUpdateNone的情况下，RenderLayerCompositor类的成员函数updateIfNeeded接下来又会构造一个GraphicsLayerUpdater对象，并且调用这个GraphicsLayerUpdater对象的成员函数update检查每一个拥有Composited Layer Mapping的Render Layer更新它的Composited Layer Mapping所描述的Graphics Layer Sub Tree。如果有Render Layer更新了它的Composited Layer Mapping所描述的Graphics Layer Sub Tree，那么调用上述GraphicsLayerUpdater对象的成员函数needsRebuildTree获得的返回值就会等于true。这时候本地变量updateType的值也会被更新为CompositingUpdateRebuildTree。

一旦本地变量updateType的值被更新为CompositingUpdateRebuildTree，或者它本来的值，也就是RenderLayerCompositor类的成员变量pendingUpdateType的值，原本就等于CompositingUpdateRebuildTree，那么RenderLayerCompositor类的成员函数updateIfNeeded又会构造一个GraphicsLayerTreeBuilder对象，并且调用这个GraphicsLayerTreeBuilder对象的成员函数rebuild从Render Layer Tree的根节点开始，递归创建一个新的Graphics Layer Tree。

注意，前面调用GraphicsLayerTreeBuilder类的成员函数rebuild的时候，传递进去的第一个参数updateRoot是Render Layer Tree的根节点，第二个参数childList是一个输出参数，它里面保存的是Graphics Layer Tree的根节点的子节点。Graphics Layer Tree的根节点由RenderLayerCompositor类的成员函数m_rootContentLayer指向的GraphicsLayer对象描述，因此当参数childList描述的Vector不为空时，它里面所保存的Graphics Layer都会被设置为RenderLayerCompositor类的成员函数m_rootContentLayer指向的GraphicsLayer对象的子Graphics Layer。

接下来我们主要分析CompositingLayerAssigner类的成员函数assign、GraphicsLayerUpdater类的成员函数update以及GraphicsLayerTreeBuilder类的成员函数rebuild的实现，以及了解Graphics Layer Tree的创建过程。

CompositingLayerAssigner类的成员函数assign主要是为Render Layer创建或者删除Composited Layer Mapping，它的实现如下所示：

void CompositingLayerAssigner::assign(RenderLayer* updateRoot, bool& layersChanged, Vector<RenderLayer*>& layersNeedingRepaint)
{
    SquashingState squashingState;
    assignLayersToBackingsInternal(updateRoot, squashingState, layersChanged, layersNeedingRepaint);
    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositingLayerAssigner.cpp中。

从前面的分析可以知道，参数updateRoot描述的是Render Layer Tree的根节点，CompositingLayerAssigner类的成员函数assign主要是调用另外一个成员函数assignLayersToBackingsInternal从这个根节点开始，递归是否需要为每一个Render Layer创建或者删除Composited Layer Mapping。

CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal的实现如下所示：

void CompositingLayerAssigner::assignLayersToBackingsInternal(RenderLayer* layer, SquashingState& squashingState, bool& layersChanged, Vector<RenderLayer*>& layersNeedingRepaint)
{
    ......

    CompositingStateTransitionType compositedLayerUpdate = computeCompositedLayerUpdate(layer);

    if (m_compositor->allocateOrClearCompositedLayerMapping(layer, compositedLayerUpdate)) {
        layersNeedingRepaint.append(layer);
        layersChanged = true;
    }

    // Add this layer to a squashing backing if needed.
    if (m_layerSquashingEnabled) {
        if (updateSquashingAssignment(layer, squashingState, compositedLayerUpdate, layersNeedingRepaint))
            layersChanged = true;

        ......
    }

    if (layer->stackingNode()->isStackingContext()) {
        RenderLayerStackingNodeIterator iterator(*layer->stackingNode(), NegativeZOrderChildren);
        while (RenderLayerStackingNode* curNode = iterator.next())
            assignLayersToBackingsInternal(curNode->layer(), squashingState, layersChanged, layersNeedingRepaint);
    }

    if (m_layerSquashingEnabled) {
        // At this point, if the layer is to be "separately" composited, then its backing becomes the most recent in paint-order.
        if (layer->compositingState() == PaintsIntoOwnBacking || layer->compositingState() == HasOwnBackingButPaintsIntoAncestor) {
            ASSERT(!requiresSquashing(layer->compositingReasons()));
            squashingState.updateSquashingStateForNewMapping(layer->compositedLayerMapping(), layer->hasCompositedLayerMapping());
        }
    }

    RenderLayerStackingNodeIterator iterator(*layer->stackingNode(), NormalFlowChildren | PositiveZOrderChildren);
    while (RenderLayerStackingNode* curNode = iterator.next())
        assignLayersToBackingsInternal(curNode->layer(), squashingState, layersChanged, layersNeedingRepaint);

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositingLayerAssigner.cpp中。

CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal首先调用成员函数computeCompositedLayerUpdate计算参数layer描述的Render Layer的Compositing State Transition，如下所示：

CompositingStateTransitionType CompositingLayerAssigner::computeCompositedLayerUpdate(RenderLayer* layer)
{
    CompositingStateTransitionType update = NoCompositingStateChange;
    if (needsOwnBacking(layer)) {
        if (!layer->hasCompositedLayerMapping()) {
            update = AllocateOwnCompositedLayerMapping;
        }
    } else {
        if (layer->hasCompositedLayerMapping())
            update = RemoveOwnCompositedLayerMapping;

        if (m_layerSquashingEnabled) {
            if (!layer->subtreeIsInvisible() && requiresSquashing(layer->compositingReasons())) {
                // We can't compute at this time whether the squashing layer update is a no-op,
                // since that requires walking the render layer tree.
                update = PutInSquashingLayer;
            } else if (layer->groupedMapping() || layer->lostGroupedMapping()) {
                update = RemoveFromSquashingLayer;
            }
        }
    }
    return update;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositingLayerAssigner.cpp中。

一个Render Layer的Compositing State Transition分为4种：

1. 它需要Compositing，但是还没有创建Composited Layer Mapping，这时候Compositing State Transition设置为AllocateOwnCompositedLayerMapping，表示要创建一个新的Composited Layer Mapping。

2. 它不需要Compositing，但是之前已经创建有Composited Layer Mapping，这时候Compositing State Transition设置为RemoveOwnCompositedLayerMapping，表示要删除之前创建的Composited Layer Mapping。

3. 它需要Squashing，这时候Compositing State Transition设置为PutInSquashingLayer，表示要将它绘制离其最近的一个Render Layer的Composited Layer Mapping里面的一个Squashing Layer上。

4. 它不需要Squashing，这时候Compositing State Transition设置为RemoveFromSquashingLayer，表示要将它从原来对应的Squashing Layer上删除。

注意，后面2种Compositing State Transition，只有在CompositingLayerAssigner类的成员变量layerSquashingEnabled的值在true的时候才会进行设置。默认情况下，浏览器是开启Layer Squashing机制的，不过可以通过设置“disable-layer-squashing”选项进行关闭，或者通过设置“enable-layer-squashing”选项显式开启。

判断一个Render Layer是否需要Compositing，是通过调用CompositingLayerAssigner类的成员函数needsOwnBacking进行的，它的实现如下所示：

bool CompositingLayerAssigner::needsOwnBacking(const RenderLayer* layer) const
{
    if (!m_compositor->canBeComposited(layer))
        return false;

    // If squashing is disabled, then layers that would have been squashed should just be separately composited.
    bool needsOwnBackingForDisabledSquashing = !m_layerSquashingEnabled && requiresSquashing(layer->compositingReasons());

    return requiresCompositing(layer->compositingReasons()) || needsOwnBackingForDisabledSquashing || (m_compositor->staleInCompositingMode() && layer->isRootLayer());
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositingLayerAssigner.cpp中。

CompositingLayerAssigner类的成员变量m_compositor指向的是一个RenderLayerCompositor对象，CompositingLayerAssigner类的成员函数needsOwnBacking首先调用它的成员函数canBeComposited判断参数layer描述的Render Layer是否需要Compositing，如下所示：

bool RenderLayerCompositor::canBeComposited(const RenderLayer* layer) const
{
    // FIXME: We disable accelerated compositing for elements in a RenderFlowThread as it doesn't work properly.
    // See http://webkit.org/b/84900 to re-enable it.
    return m_hasAcceleratedCompositing && layer->isSelfPaintingLayer() && !layer->subtreeIsInvisible() && layer->renderer()->flowThreadState() == RenderObject::NotInsideFlowThread;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/RenderLayerCompositor.cpp中。

一个Render Layer可以Compositing，需要同时满足以下4个条件：

1. 浏览器开启硬件加速合成，即RenderLayerCompositor类的成员变量m_hasAcceleratedCompositing的值等于true。

2. Render Layer本身有Compositing绘制的需求，也就是调用它的成员函数isSelfPaitingLayer得到的返回值为true。从前面 Chromium网页Render Layer Tree创建过程分析一文可以知道，Render Layer的类型一般为NormalLayer，但是如果将overflow属性设置为“hidden‘，那么Render Layer的类型被设置为OverflowClipLayer。对于类型为OverflowClipLayer的Render Layer，如果它的内容没有出现overflow，那么就没有必要对它进行Compositing。

3. Render Layer描述的网页内容是可见的，也就是调用它的成员函数subtreeIsInvisible得到的返回值等于false。

4. Render Layer的内容不是渲染在一个RenderFlowThread中，也就是与Render Layer关联的Render Object的Flow Thread State等于RenderObject::NotInsideFlowThread。从注释可以知道，在RenderFlowThread中渲染的元素是禁用硬件加速合成的，因为不能正确地使用。RenderFlowThread是CSS 3定义的一种元素显示方式，更详细的信息可以参考CSS文档： CSS Regions Module Level 1。

回到CompositingLayerAssigner类的成员函数needsOwnBacking中，如果RenderLayerCompositor类的成员函数canBeComposited告诉它参数layer描述的Render Layer不可进行Compositing，那么就不需要为它创建一个Composited Layer Mapping。

另一方面，如果RenderLayerCompositor类的成员函数canBeComposited告诉CompositingLayerAssigner类的成员函数needsOwnBacking，参数layer描述的Render Layer可以进行Compositing，那么CompositingLayerAssigner类的成员函数needsOwnBacking还需要进一步判断该Render Layer是否真的需要进行Compositing。

如果参数layer描述的Render Layer满足以下3个条件之一，那么CompositingLayerAssigner类的成员函数needsOwnBacking就会认为它需要进行Compositing：

1. Render Layer的Compositing Reason表示它需要Compositing，这是通过调用前面提到的函数requiresCompositing判断的。

2. Render Layer的Compositing Reason表示它需要Squashing，但是浏览器禁用了“Layer Squashing”机制。当浏览器禁用“Layer Squashing”机制时，CompositingLayerAssigner类的成员变量m_layerSquashingEnabled会等于false。调用前面提到的函数requiresSquashing可以判断一个Render Layer是否需要Squashing。

3. Render Layer是Render Layer Tree的根节点，并且Render Layer Compositor处于Compositing模式中。除非设置了Render Layer Tree的根节点无条件Compositing，否则的话，当在Render Layer Tree根节点的子树中，没有任何Render Layer需要Compositing时， Render Layer Tree根节点也不需要Compositing，这时候Render Layer Compositor就会被设置为非Compositing模式。判断一个Render Layer是否是Render Layer Tree的根节点，调用它的成员函数isRootLayer即可，而判断一个Render Layer Compositor是否处于Compositing模式，调用它的成员函数staleInCompositingMode即可。

回到CompositingLayerAssigner类的成员函数computeCompositedLayerUpdate中，当它调用结束后，再返回到CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal中，这时候CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal就知道了参数layer描述的Render Layer的Compositing State Transition Type。

知道了参数layer描述的Render Layer的Compositing State Transition Type之后，CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal接下来调用成员变量m_compositor描述的一个RenderLayerCompositor对象的成员函数allocateOrClearCompositedLayerMapping为其创建或者删除Composited Layer Mapping，如下所示：

bool RenderLayerCompositor::allocateOrClearCompositedLayerMapping(RenderLayer* layer, const CompositingStateTransitionType compositedLayerUpdate)
{
    bool compositedLayerMappingChanged = false;
    ......

    switch (compositedLayerUpdate) {
    case AllocateOwnCompositedLayerMapping:
        ......

        layer->ensureCompositedLayerMapping();
        compositedLayerMappingChanged = true;

        ......
        break;
    case RemoveOwnCompositedLayerMapping:
    // PutInSquashingLayer means you might have to remove the composited layer mapping first.
    case PutInSquashingLayer:
        if (layer->hasCompositedLayerMapping()) {
            ......

            layer->clearCompositedLayerMapping();
            compositedLayerMappingChanged = true;
        }

        break;
    case RemoveFromSquashingLayer:
    case NoCompositingStateChange:
        // Do nothing.
        break;
    }

    ......

    return compositedLayerMappingChanged || nonCompositedReasonChanged;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/RenderLayerCompositor.cpp中。

RenderLayerCompositor类的成员函数allocateOrClearCompositedLayerMapping主要是根据Render Layer的Compositing State Transition Type决定是要为其创建Composited Layer Mapping，还是删除mposited Layer Mapping。

对于Compositing State Transition Type等于AllocateOwnCompositedLayerMapping的Render Layer，RenderLayerCompositor类的成员函数allocateOrClearCompositedLayerMapping会调用它的成员函数ensureCompositedLayerMapping为其创建一个Composited Layer Mapping

对于Compositing State Transition Type等于RemoveOwnCompositedLayerMapping或者PutInSquashingLayer的Render Layer，RenderLayerCompositor类的成员函数allocateOrClearCompositedLayerMapping会调用它的成员函数clearCompositedLayerMapping删除原来为它创建的Composited Layer Mapping。

对于Compositing State Transition Type其它值的Render Layer，则不需要进行特别的处理。

这一步执行完成之后，回到CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal中，它接下来判断成员变量m_layerSquashingEnabled的值是否等于true。如果等于true，那么就说明浏览器开启了”Layer Squashing“机制。这时候就需要调用成员函数updateSquashingAssignment判断是否需要将参数layer描述的Render Layer绘制在一个Squashing Graphics Layer中。

CompositingLayerAssigner类的成员函数updateSquashingAssignment的实现如下所示：

bool CompositingLayerAssigner::updateSquashingAssignment(RenderLayer* layer, SquashingState& squashingState, const CompositingStateTransitionType compositedLayerUpdate,
    Vector<RenderLayer*>& layersNeedingRepaint)
{
    ......
    if (compositedLayerUpdate == PutInSquashingLayer) {
        ......

        bool changedSquashingLayer =
            squashingState.mostRecentMapping->updateSquashingLayerAssignment(layer, squashingState.mostRecentMapping->owningLayer(), squashingState.nextSquashedLayerIndex);
        ......

        return true;
    }
    if (compositedLayerUpdate == RemoveFromSquashingLayer) {
        if (layer->groupedMapping()) {
            ......
            layer->setGroupedMapping(0);
        }

        ......
        return true;
    }

    return false;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositingLayerAssigner.cpp中。

CompositingLayerAssigner类的成员函数updateSquashingAssignment也是根据Render Layer的Compositing State Transition Type决定是否要将它绘制在一个Squashing Graphics Layer中，或者将它从一个Squashing Graphics Layer中删除。

对于Compositing State Transition Type等于PutInSquashingLayer的Render Layer，它将会绘制在一个Squashing Graphics Layer中。这个Squashing Graphics Layer保存在一个Composited Layer Mapping中。这个Composited Layer Mapping关联的Render Layer处于要Squashing的Render Layer的下面，并且前者离后者是最近的，记录在参数squashingState描述的一个SquashingState对象的成员变量mostRecentMapping中。通过调用CompositedLayerMapping类的成员函数updateSquashingLayerAssignment可以将一个Render Layer绘制在一个Composited Layer Mapping内部维护的一个quashing Graphics Layer中。

对于Compositing State Transition Type等于RemoveFromSquashingLayer的Render Layer，如果它之前已经被设置绘制在一个Squashing Graphics Layer中，那么就需要将它从这个Squashing Graphics Layer中删除。如果一个Render Layer之前被设置绘制在一个Squashing Graphics Layer中，那么调用它的成员函数groupedMapping就可以获得一个Grouped Mapping。这个Grouped Mapping描述的也是一个Composited Layer Mapping，并且Render Layer所绘制在的Squashing Graphics Layer就是由这个Composited Layer Mapping维护的。因此，要将一个Render Layer从一个Squashing Graphics Layer中删除，只要将它的Grouped Mapping设置为0即可。这是通过调用RenderLayer类的成员函数setGroupedMapping实现的。

再回到CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal中，它接下来判断参数layer描述的Render Layer所关联的Render Object是否是一个Stacking Context。如果是的话，那么就递归调用成员函数assignLayersToBackingsInternal遍历那些z-index为负的子Render Object对应的Render Layer，确定是否需要为它们创建Composited Layer Mapping。

到目前为止，CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal就处理完成参数layer描述的Render Layer，以及那些z-index为负数的子Render Layer。这时候，参数layer描述的Render Layer可能会作为那些z-index为0或者正数的子Render Layer的Grouped Mapping，因此在继续递归处理z-index为0或者正数的子Render Layer之前，CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal需要将参数layer描述的Render Layer对应的Composited Layer Mapping记录下来，前提是这个Render Layer拥有Composited Layer Mapping。这是通过调用参数squashingState描述的一个SquashingState对象的成员函数updateSquashingStateForNewMapping实现的，实际上就是记录在该SquashingState对象的成员变量mostRecentMapping中。这样前面分析的CompositingLayerAssigner类的成员函数updateSquashingAssignment就可以知道将其参数layer描述的Render Layer绘制在哪一个Squashing Graphics Layer中。

最后，CompositingLayerAssigner类的成员函数assignLayersToBackingsInternal就递归调用自己处理那些z-index为0或者正数的子Render Layer。递归调有完成之后，整个Render Layer Tree就处理完毕了。这时候哪些Render Layer具有Composited Layer Mapping就可以确定了。

前面分析RenderLayerCompositor类的成员函数allocateOrClearCompositedLayerMapping时提到，调用RenderLayer类的成员函数ensureCompositedLayerMapping可以为一个Render Layer创建一个Composited Layer Mapping，接下来我们就继续分析这个函数的实现，以便了解Composited Layer Mapping的创建过程。

RenderLayer类的成员函数ensureCompositedLayerMapping的实现如下所示：

CompositedLayerMappingPtr RenderLayer::ensureCompositedLayerMapping()
{
    if (!m_compositedLayerMapping) {
        m_compositedLayerMapping = adoptPtr(new CompositedLayerMapping(*this));
        ......
    }
    return m_compositedLayerMapping.get();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/RenderLayer.cpp中。

RenderLayer类的成员变量compositedLayerMapping描述的就是一个Composited Layer Mapping。如果这个Composited Layer Mapping还没有创建，那么当RenderLayer类的成员函数ensureCompositedLayerMapping被调用时，就会进行创建。

Composited Layer Mapping的创建过程，也就是CompositedLayerMapping类的构造函数的实现，如下所示：

CompositedLayerMapping::CompositedLayerMapping(RenderLayer& layer)
    : m_owningLayer(layer)
    , ......
{
    ......

    createPrimaryGraphicsLayer();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

正在创建的Composited Layer Mapping被参数layer描述的Render Layer拥有，因此这个Render Layer将会被保存在在创建的Composited Layer Mapping的成员变量m_owningLayer中。

从图5可以知道，一个Composited Layer Mapping一定存在一个Main Graphics Layer。这个Main Graphics Layer是CompositedLayerMapping类的构造函数通过调用另外一个成员函数createPrimaryGraphicsLayer创建的，如下所示：

void CompositedLayerMapping::createPrimaryGraphicsLayer()
{
    m_graphicsLayer = createGraphicsLayer(m_owningLayer.compositingReasons());

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

Composited Layer Mapping中的Main Graphics Layer由成员变量m_graphicsLayer描述，并且这个Main Graphics Layer是通过调用成员函数createGraphicsLayer创建的。如果我们分析CompositedLayerMapping类的其它代码，就会发现Composited Layer Mapping中的其它Graphics Layer也是通过调用成员函数createGraphicsLayer创建的。

CompositedLayerMapping类的成员函数createGraphicsLayer的实现如下所示：

PassOwnPtr<GraphicsLayer> CompositedLayerMapping::createGraphicsLayer(CompositingReasons reasons)
{
    GraphicsLayerFactory* graphicsLayerFactory = 0;
    if (Page* page = renderer()->frame()->page())
        graphicsLayerFactory = page->chrome().client().graphicsLayerFactory();

    OwnPtr<GraphicsLayer> graphicsLayer = GraphicsLayer::create(graphicsLayerFactory, this);

    graphicsLayer->setCompositingReasons(reasons);
    if (Node* owningNode = m_owningLayer.renderer()->generatingNode())
        graphicsLayer->setOwnerNodeId(InspectorNodeIds::idForNode(owningNode));

    return graphicsLayer.release();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

CompositedLayerMapping类的成员函数createGraphicsLayer在创建一个Graphics Layer之前，首先会获得一个GraphicsLayerFactory对象。这个GraphicsLayerFactory对象是由WebKit的使用者提供的。在我们这个情景中，WebKit的使用者就是Chromium，它提供的GraphicsLayerFactory对象的实际类型为GraphicsLayerFactoryChromium。

获得了GraphicsLayerFactory对象之后，CompositedLayerMapping类的成员函数createGraphicsLayer接下来就以它为参数，调用GraphicsLayer类的静态成员函数create创建一个Graphics Layer，如下所示：

PassOwnPtr<GraphicsLayer> GraphicsLayer::create(GraphicsLayerFactory* factory, GraphicsLayerClient* client)
{
    return factory->createGraphicsLayer(client);
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/platform/graphics/GraphicsLayer.cpp中。

GraphicsLayer类的静态成员函数create调用参数factory描述的一个GraphicsLayerFactoryChromium对象的成员函数createGraphicsLayer创建一个Graphics Layer，如下所示：

PassOwnPtr<GraphicsLayer> GraphicsLayerFactoryChromium::createGraphicsLayer(GraphicsLayerClient* client)
{
    OwnPtr<GraphicsLayer> layer = adoptPtr(new GraphicsLayer(client));
    ......
    return layer.release();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/web/GraphicsLayerFactoryChromium.cpp中。

从这里可以看到，GraphicsLayerFactoryChromium类的成员函数createGraphicsLayer返回的是一个GraphicsLayer对象。

这一步执行完成后，一个Composited Layer Mapping及其内部的Main Graphics Layer就创建完成了。

前面分析CompositingLayerAssigner类的成员函数updateSquashingAssignment时提到，调用CompositedLayerMapping类的成员函数updateSquashingLayerAssignment可以将一个Render Layer绘制在其内部维护的一个Squashing Graphics Layer中。CompositedLayerMapping类的成员函数updateSquashingLayerAssignment的实现如下所示：

bool CompositedLayerMapping::updateSquashingLayerAssignment(RenderLayer* squashedLayer, const RenderLayer& owningLayer, size_t nextSquashedLayerIndex)
{
    ......

    GraphicsLayerPaintInfo paintInfo;
    paintInfo.renderLayer = squashedLayer;
    ......

    // Change tracking on squashing layers: at the first sign of something changed, just invalidate the layer.
    // FIXME: Perhaps we can find a tighter more clever mechanism later.
    bool updatedAssignment = false;
    if (nextSquashedLayerIndex < m_squashedLayers.size()) {
        if (!paintInfo.isEquivalentForSquashing(m_squashedLayers[nextSquashedLayerIndex])) {
            ......
            updatedAssignment = true;
            m_squashedLayers[nextSquashedLayerIndex] = paintInfo;
        }
    } else {
        ......
        m_squashedLayers.append(paintInfo);
        updatedAssignment = true;
    }
    squashedLayer->setGroupedMapping(this);
    return updatedAssignment;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/web/GraphicsLayerFactoryChromium.cpp中。

CompositedLayerMapping类有一个成员变量m_squashedLayers，它描述的是一个类型为GraphicsLayerPaintInfo的Vector，如下所示：

class CompositedLayerMapping FINAL : public GraphicsLayerClient {
    WTF_MAKE_NONCOPYABLE(CompositedLayerMapping); WTF_MAKE_FAST_ALLOCATED;
    ......

private:
    ......

    OwnPtr<GraphicsLayer> m_squashingLayer; // Only used if any squashed layers exist, this is the backing that squashed layers paint into.
    Vector<GraphicsLayerPaintInfo> m_squashedLayers;
    
    ......
};

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/web/GraphicsLayerFactoryChromium.h中。

上述Vector中保存在的每一个GraphicsLayerPaintInfo描述的都是一个Squashing Render Layer，这些Squashing Render Layer最终将会绘制在CompositedLayerMapping类的成员变量m_squashingLayer描述的一个Graphics Layer中。

CompositedLayerMapping类的成员函数updateSquashingLayerAssignment所做的事情就是将参数squashedLayer描述的一个Squashing Render Layer封装在一个GraphicsLayerPaintInfo对象，然后将这个GraphicsLayerPaintInfo对象保存在CompositedLayerMapping类的成员变量m_squashedLayers描述的一个Vector中。

这样，我们就分析完成了为Render Layer Tree中的Render Layer创建Composited Layer Mapping的过程，也就是CompositingLayerAssigner类的成员函数assign的实现。回到RenderLayerCompositor类的成员函数updateIfNeeded中，它接下来调用GraphicsLayerUpdater类的成员函数update为Composited Layer Mapping创建Graphics Layer Sub Tree。

GraphicsLayerUpdater类的成员函数update的实现如下所示：

void GraphicsLayerUpdater::update(Vector<RenderLayer*>& layersNeedingPaintInvalidation, RenderLayer& layer, UpdateType updateType, const UpdateContext& context)
{
    if (layer.hasCompositedLayerMapping()) {
        CompositedLayerMappingPtr mapping = layer.compositedLayerMapping();

        ......

        if (mapping->updateGraphicsLayerConfiguration(updateType))
            m_needsRebuildTree = true;

        ......
    }

    UpdateContext childContext(context, layer);
    for (RenderLayer* child = layer.firstChild(); child; child = child->nextSibling())
        update(layersNeedingPaintInvalidation, *child, updateType, childContext);
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/GraphicsLayerUpdater.cpp。

从前面的调用过程可以知道，参数layer描述的Render Layer是Render Layer Tree的根节点，GraphicsLayerUpdater类的成员函数update检查它是否拥有Composited Layer Mapping。如果有的话，那么就会调用这个Composited Layer Mapping的成员函数updateGraphicsLayerConfiguration更新它内部的Graphics Layer Sub Tree。GraphicsLayerUpdater类的成员函数update最后还会递归调用自身遍历Render Layer Tree的根节点的子孙节点，这样就可以对所有的Graphics Layer Sub Tree进行更新。

接下来我们继续分析CompositedLayerMapping类的成员函数updateGraphicsLayerConfiguration的实现，以便了解每一个Graphics Layer Sub Tree的更新过程，如下所示：

bool CompositedLayerMapping::updateGraphicsLayerConfiguration(GraphicsLayerUpdater::UpdateType updateType)
{
    ......

    bool layerConfigChanged = false;
    ......

    // The background layer is currently only used for fixed root backgrounds.
    if (updateBackgroundLayer(m_backgroundLayerPaintsFixedRootBackground))
        layerConfigChanged = true;

    if (updateForegroundLayer(compositor->needsContentsCompositingLayer(&m_owningLayer)))
        layerConfigChanged = true;

    bool needsDescendantsClippingLayer = compositor->clipsCompositingDescendants(&m_owningLayer);
    ......

    bool needsAncestorClip = compositor->clippedByNonAncestorInStackingTree(&m_owningLayer);
    ......

    if (updateClippingLayers(needsAncestorClip, needsDescendantsClippingLayer))
        layerConfigChanged = true;

    ......

    if (updateScrollingLayers(m_owningLayer.needsCompositedScrolling())) {
        layerConfigChanged = true;
        ......
    }

    bool hasPerspective = false;
    if (RenderStyle* style = renderer->style())
        hasPerspective = style->hasPerspective();
    bool needsChildTransformLayer = hasPerspective && (layerForChildrenTransform() == m_childTransformLayer.get()) && renderer->isBox();
    if (updateChildTransformLayer(needsChildTransformLayer))
        layerConfigChanged = true;

    ......

    if (updateSquashingLayers(!m_squashedLayers.isEmpty()))
        layerConfigChanged = true;

    if (layerConfigChanged)
        updateInternalHierarchy();

    .......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

CompositedLayerMapping类的成员函数updateGraphicsLayerConfiguration依次检查它内部维护的Background Layer、Foreground Layer、Clip Layer、Scrolling Layer、Child Transform Layer和Squashing Layer是否需要更新，也就是创建或者删除等。只要其中的一个Graphics Layer发生更新，本地变量layerConfigChanged的值就会被设置为true，这时候CompositedLayerMapping类的另外一个成员函数updateInternalHierarchy就会被调用来更新内部的Graphics Layer Sub Tree。

接下来我们以Squashing Layer的更新过程为例，即CompositedLayerMapping类的成员函数updateSquashingLayers的实现，分析CompositedLayerMapping类内部维护的Graphics Layer的更新过程，如下所示：

bool CompositedLayerMapping::updateSquashingLayers(bool needsSquashingLayers)
{
    bool layersChanged = false;

    if (needsSquashingLayers) {
        ......

        if (!m_squashingLayer) {
            m_squashingLayer = createGraphicsLayer(CompositingReasonLayerForSquashingContents);
            ......
            layersChanged = true;
        }

        if (m_ancestorClippingLayer) {
            if (m_squashingContainmentLayer) {
                m_squashingContainmentLayer->removeFromParent();
                m_squashingContainmentLayer = nullptr;
                layersChanged = true;
            }
        } else {
            if (!m_squashingContainmentLayer) {
                m_squashingContainmentLayer = createGraphicsLayer(CompositingReasonLayerForSquashingContainer);
                layersChanged = true;
            }
        }

        ......
    } else {
        if (m_squashingLayer) {
            m_squashingLayer->removeFromParent();
            m_squashingLayer = nullptr;
            layersChanged = true;
        }
        if (m_squashingContainmentLayer) {
            m_squashingContainmentLayer->removeFromParent();
            m_squashingContainmentLayer = nullptr;
            layersChanged = true;
        }
        ......
    }

    return layersChanged;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

从前面的调用过程可以知道，当CompositedLayerMapping类的成员变量m_squashedLayers描述的Vector不等于空时，这里的参数needsSquashingLayers的值就会等于true，表示需要对CompositedLayerMapping类内部维护的Squashing Layer进行更新。更新过程如下所示：

1. 如果Squashing Layer还没有创建，那么就会调用我们前面分析过的CompositedLayerMapping类的成员函数createGraphicsLayer进行创建，并且保存在成员变量m_squashingLayer中。

2. CompositedLayerMapping类的成员变量m_ancestorClippingLayer描述的是图5所示的Clip Layer。当存在Squashing Layer时，但Clip Layer又不存在的时候，需要创建一个Squashing Containment Layer，用来作为Squashing Layer的父Graphics Layer。否则的话，Squashing Layer的父Graphics Layer就是Clip Layer。

3. 基于上述第2点，当Clip Layer存在时，若Squashing Containment Layer存在，则需要将它从Graphics Layer Sub Tree中移除。另一方面，当Clip Layer不存在时，若Squashing Containment Layer也不存在，则需要创建Squashing Containment Layer。换句话说，当存在Squashing Layer时，Clip Layer和Squashing Containment Layer至少存在一个，并且只能存在一个，Clip Layer优先Squashing Containment Layer存在。

如果CompositedLayerMapping类的成员变量m_squashedLayers描述的Vector等于空时，参数needsSquashingLayers的值就会等于false，表示需CompositedLayerMapping类不需要在内部维护一个Squashing Layer。这时候如果存在Squashing Layer，那么就需要将它从Graphics Layer Sub Tree中移除。如果Squashing Containment Layer也存在，那么也要将它一起从Graphics Layer Sub Tree中移除。这是因为Squashing Containment Layer本来就是为Squashing Layer创建的，现在既然Squashing Layer不需要了，那么它自然也不再需要了。

回到CompositedLayerMapping类的成员函数updateGraphicsLayerConfiguration中，接下来我们继续分析它调用另外一个成员函数updateInternalHierarchy更新内部维护的raphics Layer Sub Tree的过程，如下所示：

void CompositedLayerMapping::updateInternalHierarchy()
{
    // m_foregroundLayer has to be inserted in the correct order with child layers,
    // so it's not inserted here.
    if (m_ancestorClippingLayer)
        m_ancestorClippingLayer->removeAllChildren();

    m_graphicsLayer->removeFromParent();

    if (m_ancestorClippingLayer)
        m_ancestorClippingLayer->addChild(m_graphicsLayer.get());

    if (m_childContainmentLayer)
        m_graphicsLayer->addChild(m_childContainmentLayer.get());
    else if (m_childTransformLayer)
        m_graphicsLayer->addChild(m_childTransformLayer.get());

    if (m_scrollingLayer) {
        GraphicsLayer* superLayer = m_graphicsLayer.get();

        if (m_childContainmentLayer)
            superLayer = m_childContainmentLayer.get();

        if (m_childTransformLayer)
            superLayer = m_childTransformLayer.get();

        superLayer->addChild(m_scrollingLayer.get());
    }

    // The clip for child layers does not include space for overflow controls, so they exist as
    // siblings of the clipping layer if we have one. Normal children of this layer are set as
    // children of the clipping layer.
    if (m_layerForHorizontalScrollbar)
        m_graphicsLayer->addChild(m_layerForHorizontalScrollbar.get());
    if (m_layerForVerticalScrollbar)
        m_graphicsLayer->addChild(m_layerForVerticalScrollbar.get());
    if (m_layerForScrollCorner)
        m_graphicsLayer->addChild(m_layerForScrollCorner.get());

    // The squashing containment layer, if it exists, becomes a no-op parent.
    if (m_squashingLayer) {
        ASSERT(compositor()->layerSquashingEnabled());
        ASSERT((m_ancestorClippingLayer && !m_squashingContainmentLayer) || (!m_ancestorClippingLayer && m_squashingContainmentLayer));

        if (m_squashingContainmentLayer) {
            m_squashingContainmentLayer->removeAllChildren();
            m_squashingContainmentLayer->addChild(m_graphicsLayer.get());
            m_squashingContainmentLayer->addChild(m_squashingLayer.get());
        } else {
            // The ancestor clipping layer is already set up and has m_graphicsLayer under it.
            m_ancestorClippingLayer->addChild(m_squashingLayer.get());
        }
    }
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

从这里我们就可以看到，通过调用GraphicsLayer类的成员函数addChild，就可以将一个Graphics Layer作为另外一个Graphics Layer的子Graphics Layer，这样就可以形成一个Graphics Layer Sub Tree。CompositedLayerMapping类的成员函数updateInternalHierarchy构建出来的Graphics Layer Sub Tree大致就如图5所示。

CompositedLayerMapping类内部维护的Graphics Layer Sub Tree，除了前面描述的Clip Layer和Squashing Containment Layer不能并存之外，另外两个Layer，即Child Containment Layer和Child Tranform Layer，也是不能并存的。这些Graphics Layer的具体作用，以及什么在情况下会存在，可以通过阅读ompositedLayerMapping类的代码获悉，这里就不再展开描述。

还有一点需要注意的是，CompositedLayerMapping类内部维护的Background Layer和Foreground Layer也是属于CompositedLayerMapping类描述的Graphics Layer Sub Tree的一部分，但是它们不是由CompositedLayerMapping类的成员函数updateInternalHierarchy插入到Graphics Layer Sub Tree中去的。等到将Graphics Layer Sub Tree连接在一起形成整个Graphics Layer Tree的时候，它们才会插入到各自的Graphics Layer Sub Tree中去，因为处理它们需要更多的信息。

由于各个Graphics Layer Sub Tree需要连接在一起形成一个完整的Graphics Layer Tree，因此每一个Graphics Layer Sub Tree都需要提供两个对外的Graphics Layer，一个作为其父Graphics Layer Sub Tree的子Graphics Layer，另一个作为其子Graphics Layer Sub Tree的父Graphics Layer。CompositedLayerMapping类提供了两个成员函数childForSuperlayers和parentForSublayers，分别提供上述两个Graphics Layer。

CompositedLayerMapping类的成员函数childForSuperlayers的实现如下所示：

GraphicsLayer* CompositedLayerMapping::childForSuperlayers() const
{
    if (m_squashingContainmentLayer)
        return m_squashingContainmentLayer.get();

    return localRootForOwningLayer();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

从这里可以看到，如果存在Squashing Containment Layer，那么它就会作为父Graphics Layer Sub Tree的子Graphics Layer。另一方面，如果不存在Squashing Containment Layer，那么CompositedLayerMapping类的成员函数childForSuperlayers调用另外一个成员函数localRootForOwningLayer返回另外一个Graphics Layer作为父Graphics Layer Sub Tree的子Graphics Layer。

CompositedLayerMapping类的成员函数localRootForOwningLayer的实现如下所示：

GraphicsLayer* CompositedLayerMapping::localRootForOwningLayer() const
{
    if (m_ancestorClippingLayer)
        return m_ancestorClippingLayer.get();

    return m_graphicsLayer.get();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

从这里可以看到，如果存在Clip Layer，那么它就会作为父Graphics Layer Sub Tree的子Graphics Layer。否则的话，Main Layer就会作为父Graphics Layer Sub Tree的子Graphics Layer。从图5可以知道，Main Layer是一定会存在的，因此就一定可以找到一个Graphics Layer，作为父Graphics Layer Sub Tree的子Graphics Layer。

CompositedLayerMapping类的成员函数parentForSublayers的实现如下所示：

GraphicsLayer* CompositedLayerMapping::parentForSublayers() const
{
    if (m_scrollingBlockSelectionLayer)
        return m_scrollingBlockSelectionLayer.get();

    if (m_scrollingContentsLayer)
        return m_scrollingContentsLayer.get();

    if (m_childContainmentLayer)
        return m_childContainmentLayer.get();

    if (m_childTransformLayer)
        return m_childTransformLayer.get();

    return m_graphicsLayer.get();
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/CompositedLayerMapping.cpp中。

CompositedLayerMapping类的成员函数parentForSublayers按照Scrolling Block Selection Layer、Scrolling Contents Layer、Child Containment Layer、Child Transform Layer和Main Layer的顺序检查，先检查的Graphics Layer若存在，那么它就优先作为子Graphics Layer Sub Tree的父Graphics Layer。同样，由于最后检查的Main Layer是一定存在的，因此就一定可以找到一个Graphics Layer，作为子Graphics Layer Sub Tree的父Graphics Layer。

了解了Graphics Layer Sub Tree的构建过程之后，回到RenderLayerCompositor类的成员函数updateIfNeeded中，它最后就可以调用GraphicsLayerTreeBuilder类的成员函数rebuild将所有的Graphics Layer Sub Tree连接起来形成一个完整的Graphics Layer Tree了。

GraphicsLayerTreeBuilder类的成员函数rebuild的实现如下所示：

void GraphicsLayerTreeBuilder::rebuild(RenderLayer& layer, GraphicsLayerVector& childLayersOfEnclosingLayer)
{
    ......

    const bool hasCompositedLayerMapping = layer.hasCompositedLayerMapping();
    CompositedLayerMappingPtr currentCompositedLayerMapping = layer.compositedLayerMapping();

    // If this layer has a compositedLayerMapping, then that is where we place subsequent children GraphicsLayers.
    // Otherwise children continue to append to the child list of the enclosing layer.
    GraphicsLayerVector layerChildren;
    GraphicsLayerVector& childList = hasCompositedLayerMapping ? layerChildren : childLayersOfEnclosingLayer;
    
    ......

    if (layer.stackingNode()->isStackingContext()) {
        RenderLayerStackingNodeIterator iterator(*layer.stackingNode(), NegativeZOrderChildren);
        while (RenderLayerStackingNode* curNode = iterator.next())
            rebuild(*curNode->layer(), childList);

        // If a negative z-order child is compositing, we get a foreground layer which needs to get parented.
        if (hasCompositedLayerMapping && currentCompositedLayerMapping->foregroundLayer())
            childList.append(currentCompositedLayerMapping->foregroundLayer());
    }

    RenderLayerStackingNodeIterator iterator(*layer.stackingNode(), NormalFlowChildren | PositiveZOrderChildren);
    while (RenderLayerStackingNode* curNode = iterator.next())
        rebuild(*curNode->layer(), childList);

    if (hasCompositedLayerMapping) {
        bool parented = false;
        if (layer.renderer()->isRenderPart())
            parented = RenderLayerCompositor::parentFrameContentLayers(toRenderPart(layer.renderer()));

        if (!parented)
            currentCompositedLayerMapping->parentForSublayers()->setChildren(layerChildren);

        ......

        if (shouldAppendLayer(layer))
            childLayersOfEnclosingLayer.append(currentCompositedLayerMapping->childForSuperlayers());
    }
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/GraphicsLayerTreeBuilder.cpp中。

从前面的调用过程可以知道，参数layer描述的是网页Render Layer Tree的根节点，另外一个参数childLayersOfEnclosingLayer是一个输出参数，用来保存参数layer描述的Render Layer的子Render Layer的Child For Super Layers，也就是前面描述的一个Composited Layer Mapping中作为父Graphics Layer Sub Tree的子Graphics Layer。

GraphicsLayerTreeBuilder类的成员函数rebuild根据Stacking Context顺序从Render Layer Tree的根节点开始，不断地递归调用自己，不过只会处理那些具有Composited Layer Mapping的Render Layer。对于那些不具有Composited Layer Mapping的Render Layer，仅仅是用作跳板找到具有Composited Layer Mapping的Render Layer。这一点容易理解，因为GraphicsLayerTreeBuilder类的成员函数rebuild是用来构建整个网页的Graphics Layer Tree的，只有具有Composited Layer Mapping的Render Layer才对应的Graphics Layer。

GraphicsLayerTreeBuilder类的成员函数rebuild处理具有Composited Layer Mapping的Render Layer的过程如下所示：

1. 收集z-index为负数的子Render Layer的Child For Super Layers，并且保存在本地变量layerChildren描述的一个Vector中。

2. 如果正在处理的Render Layer具有z-index为负数的子Render Layer，那么根据前面的分析可以知道，正在处理的Render Layer的Composited Layer Mapping内部有一个Foreground Layer。这个Foreground Layer也会保存在本地变量layerChildren描述的一个Vector中，并且是位于那些z-index为负数的子Render Layer的Child For Super Layers之后。这就是为什么Foreground Layer不是由CompositedLayerMapping类的成员函数updateInternalHierarchy直接插入到Graphics Layer Sub Tree去的原因，因为CompositedLayerMapping类不知道一个Render Layer有哪些z-index为负数的子Render Layer。

3. 收集z-index为0和正数的子Render Layer的Child For Super Layers，并且保存在本地变量layerChildren描述的一个Vector中。

4. 经过前面三个收集操作，当前正在处理的Render Layer的Foreground Layer，以及它所有的子Render Layer的Child For Super Layers，就都保存在了本地变量layerChildren描述的一个Vector中。这时候只要找到当前正在处理的Render Layer的Parent For Sub Layers，再将前者作为后者的Children，就可以将具有父子关系的Graphics Layer Sub Tree连接起来。从前面的分析可以知道，当前正在处理的Render Layer的Parent For Sub Layers，可以通过调用它的Composited Layer Mapping的成员函数parentForSublayers获得。

5. 当前正在处理的Render Layer的Child For Super Layers，要保存在参数childLayersOfEnclosingLayer描述的Vector中，以便作为其父Render Layer的Parent For Sub Layers的Children。

其中，第4步对应的代码为：

        bool parented = false;
        if (layer.renderer()->isRenderPart())
            parented = RenderLayerCompositor::parentFrameContentLayers(toRenderPart(layer.renderer()));

        if (!parented)
            currentCompositedLayerMapping->parentForSublayers()->setChildren(layerChildren);

它的执行有一个前提条件，就是本地变量parented的值为false。这是什么意思呢？当一个Render Layer的宿主Render Object对应的HTML Element是一个frame/iframe或者embed标签时，该Render Object是从RenderPart类继承下来的，称为Render Part。Render Part可能会具有自己的Render Layer Compositor，这可以通过调用enderLayerCompositor类的静态成员函数parentFrameContentLayers进行判断。如果一个Render Part具有自己的Render Layer Compositor，那么它的子Render Object就由这个Render Layer Compositor进行具体的绘制，绘制好之后再交给Render Part的父Render Object对应的Render Layer Compositor进行合成。因此，在这种情况下，Render Part的子Render Object所对应的Graphics Layer就不会插入在Render Part的父Render Object所对应的Graphics Layer Tree中。从另外一个角度理解就是，每一个Render Layer Compositor都有一个Graphics Layer Tree，而一个Graphics Layer不能同时位于两个Graphics Layer Tree中。

第5步对应的代码为：

        if (shouldAppendLayer(layer))
            childLayersOfEnclosingLayer.append(currentCompositedLayerMapping->childForSuperlayers());

它的执行也有一个前提条件，就是当前正在处理的Render Layer对应的Graphcis Layer需要插入Graphics Layer Tree的时候才会执行，这可以通过调用函数shouldAppendLayer进行判断，如下所示：

static bool shouldAppendLayer(const RenderLayer& layer)
{
    if (!RuntimeEnabledFeatures::overlayFullscreenVideoEnabled())
        return true;
    Node* node = layer.renderer()->node();
    if (node && isHTMLMediaElement(*node) && toHTMLMediaElement(node)->isFullscreen())
        return false;
    return true;
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/GraphicsLayerTreeBuilder.cpp中。

当一个Render Layer的宿主Render Object对应的HTML Element是一个audio或者video标签时，并且它们是全屏播放、以及浏览器允许全屏播放时，那么它对应的Graphcis Layer就不需要插入Graphics Layer Tree中去，因为毕竟就只有它是需要渲染的，其他的网页内容都是不可见的。

GraphicsLayerTreeBuilder类的成员函数rebuild递归执行完成后，网页的Graphics Layer Tree就创建完成了。不过细心的读者会发现，还有一种类型的Graphics Layer还没有被插入到Graphics Layer Tree中去，就是图5所示的Background Layer。

前面提到，只有根Render Layer的Composited Layer Mapping，才可能存在Background Layer。也就是只有当body标签的CSS属性background-attachment被设置为“fixed”时，根Render Layer的Composited Layer Mapping才会存在Background Layer。其他的Render Layer的Composited Layer Mapping，都不可能存在Background Layer。

前面还提到，一个Graphics Layer Tree是由一个Render Layer Compositor进行管理。Render Layer Compositor内部也维护有一个Graphics Layer Sub Tree，充当根Graphics Layer Sub Tree的角色。这个Graphics Layer Sub Tree的结构如下所示：

+Overflow Controls Host Layer
   +Container Layer
      +Background Layer
      +Scroll Layer
         +Root Content Layer

其中，GraphicsLayerTreeBuilder类的成员函数rebuild构建的Graphics Layer Tree的根节点是Root Content Layer，而Container Layer充当图5所示的Clip Layer的角色，这时候Background Layer就作为它的子Graphics Layer。Render Layer Compositor对应的Graphics Layer Sub Tree是由RenderLayerCompositor类的成员函数ensureRootLayer构建的，如下所示：

void RenderLayerCompositor::ensureRootLayer()
{
    ......

    if (!m_rootContentLayer) {
        m_rootContentLayer = GraphicsLayer::create(graphicsLayerFactory(), this);
        ......
    }

    if (!m_overflowControlsHostLayer) {
        ......

        // Create a layer to host the clipping layer and the overflow controls layers.
        m_overflowControlsHostLayer = GraphicsLayer::create(graphicsLayerFactory(), this);

        // Create a clipping layer if this is an iframe or settings require to clip.
        m_containerLayer = GraphicsLayer::create(graphicsLayerFactory(), this);
        ......

        m_scrollLayer = GraphicsLayer::create(graphicsLayerFactory(), this);
        ......
        // Hook them up
        m_overflowControlsHostLayer->addChild(m_containerLayer.get());
        m_containerLayer->addChild(m_scrollLayer.get());
        m_scrollLayer->addChild(m_rootContentLayer.get());

        ......
    }

    ......
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/RenderLayerCompositor.cpp中。

当网页的body标签的CSS属性background-attachment被设置为“fixed”时，RenderLayerCompositor类的成员函数rootFixedBackgroundsChanged就会被调用，用来插入Background Layer，如下所示：

void RenderLayerCompositor::rootFixedBackgroundsChanged()
{
    ......

    if (GraphicsLayer* backgroundLayer = fixedRootBackgroundLayer())
        m_containerLayer->addChildBelow(backgroundLayer, m_scrollLayer.get());
}

这个函数定义在文件external/chromium_org/third_party/WebKit/Source/core/rendering/compositing/RenderLayerCompositor.cpp中。

RenderLayerCompositor类的成员函数rootFixedBackgroundsChanged调用另外一个成员函数fixedRootBackgroundLayer获得Background Layer，然后再将它作为上述Container Layer的Child，并且位于Scroll Layer的下面。

这样，我们就分析完成网页Graphics Layer Tree的构建过程了，它是通过连接Graphics Layer Sub Tree得来的。每一个Graphics Layer Sub Tree又是由一个Composited Layer Mapping维护的。每一个需要Compositing的Render Layer都具有一个Composited Layer Mapping。这就意味着网页的Graphics Layer Tree是根据Render Layer Tree的内容构建的，并且Render Layer和Graphics Layer是多对一的关系。

至此，我们就学习完成Chromium网页加载过程这个系列的文章，重新学习可以参考 Chromium网页加载过程简要介绍和学习计划一文。这个过程主要是由WebKit完成的，一共构建了五个Tree，分别Frame Tree、DOM Tree、Render Object Tree、Render Layer Tree和Graphics Layer Tree。其中，最终输出给Chromium的是Graphics Layer Tree。有了Graphics Layer Tree之后，Chromium就可以绘制/渲染网页的UI了，这个过程我们在后面系列的文章再进行分析。敬请关注！更多的信息也可以关注老罗的新浪微博： http://weibo.com/shengyangluo。

作者：Luoshengyang 发表于2016/2/29 0:59:09 原文链接

阅读：140 评论：0 查看评论

初探 performance – 监控网页与程序性能

Thu, 03 Sep 2015 15:26:47 CST

使用 window.performance 提供了一组精确的数据，经过简单的计算就能得出一些网页性能数据。

配合上报一些客户端浏览器的设备类型等数据，就可以实现简单的统计啦！

额，先看下兼容性如何： http://caniuse.com/#feat=nav-timing

这篇文章中 Demo 的运行环境为最新的 Chrome 的控制台，如果你用的是其他浏览器，自查兼容性哈~

先来看看在 Chrome 浏览器控制台中执行 window.performance 会出现什么：

简单解释下 performance 中的属性：

先看下一个请求发出的整个过程中，各种环节的时间顺序：

// 获取 performance 数据
var performance = {  
    // memory 是非标准属性，只在 Chrome 有
    // 财富问题：我有多少内存
    memory: {
        usedJSHeapSize:  16100000, // JS 对象（包括V8引擎内部对象）占用的内存，一定小于 totalJSHeapSize
        totalJSHeapSize: 35100000, // 可使用的内存
        jsHeapSizeLimit: 793000000 // 内存大小限制
    },

    //  哲学问题：我从哪里来？
    navigation: {
        redirectCount: 0, // 如果有重定向的话，页面通过几次重定向跳转而来
        type: 0           // 0   即 TYPE_NAVIGATENEXT 正常进入的页面（非刷新、非重定向等）
                          // 1   即 TYPE_RELOAD       通过 window.location.reload() 刷新的页面
                          // 2   即 TYPE_BACK_FORWARD 通过浏览器的前进后退按钮进入的页面（历史记录）
                          // 255 即 TYPE_UNDEFINED    非以上方式进入的页面
    },

    timing: {
        // 在同一个浏览器上下文中，前一个网页（与当前页面不一定同域）unload 的时间戳，如果无前一个网页 unload ，则与 fetchStart 值相等
        navigationStart: 1441112691935,

        // 前一个网页（与当前页面同域）unload 的时间戳，如果无前一个网页 unload 或者前一个网页与当前页面不同域，则值为 0
        unloadEventStart: 0,

        // 和 unloadEventStart 相对应，返回前一个网页 unload 事件绑定的回调函数执行完毕的时间戳
        unloadEventEnd: 0,

        // 第一个 HTTP 重定向发生时的时间。有跳转且是同域名内的重定向才算，否则值为 0 
        redirectStart: 0,

        // 最后一个 HTTP 重定向完成时的时间。有跳转且是同域名内部的重定向才算，否则值为 0 
        redirectEnd: 0,

        // 浏览器准备好使用 HTTP 请求抓取文档的时间，这发生在检查本地缓存之前
        fetchStart: 1441112692155,

        // DNS 域名查询开始的时间，如果使用了本地缓存（即无 DNS 查询）或持久连接，则与 fetchStart 值相等
        domainLookupStart: 1441112692155,

        // DNS 域名查询完成的时间，如果使用了本地缓存（即无 DNS 查询）或持久连接，则与 fetchStart 值相等
        domainLookupEnd: 1441112692155,

        // HTTP（TCP） 开始建立连接的时间，如果是持久连接，则与 fetchStart 值相等
        // 注意如果在传输层发生了错误且重新建立连接，则这里显示的是新建立的连接开始的时间
        connectStart: 1441112692155,

        // HTTP（TCP） 完成建立连接的时间（完成握手），如果是持久连接，则与 fetchStart 值相等
        // 注意如果在传输层发生了错误且重新建立连接，则这里显示的是新建立的连接完成的时间
        // 注意这里握手结束，包括安全连接建立完成、SOCKS 授权通过
        connectEnd: 1441112692155,

        // HTTPS 连接开始的时间，如果不是安全连接，则值为 0
        secureConnectionStart: 0,

        // HTTP 请求读取真实文档开始的时间（完成建立连接），包括从本地读取缓存
        // 连接错误重连时，这里显示的也是新建立连接的时间
        requestStart: 1441112692158,

        // HTTP 开始接收响应的时间（获取到第一个字节），包括从本地读取缓存
        responseStart: 1441112692686,

        // HTTP 响应全部接收完成的时间（获取到最后一个字节），包括从本地读取缓存
        responseEnd: 1441112692687,

        // 开始解析渲染 DOM 树的时间，此时 Document.readyState 变为 loading，并将抛出 readystatechange 相关事件
        domLoading: 1441112692690,

        // 完成解析 DOM 树的时间，Document.readyState 变为 interactive，并将抛出 readystatechange 相关事件
        // 注意只是 DOM 树解析完成，这时候并没有开始加载网页内的资源
        domInteractive: 1441112693093,

        // DOM 解析完成后，网页内资源加载开始的时间
        // 在 DOMContentLoaded 事件抛出前发生
        domContentLoadedEventStart: 1441112693093,

        // DOM 解析完成后，网页内资源加载完成的时间（如 JS 脚本加载执行完毕）
        domContentLoadedEventEnd: 1441112693101,

        // DOM 树解析完成，且资源也准备就绪的时间，Document.readyState 变为 complete，并将抛出 readystatechange 相关事件
        domComplete: 1441112693214,

        // load 事件发送给文档，也即 load 回调函数开始执行的时间
        // 注意如果没有绑定 load 事件，值为 0
        loadEventStart: 1441112693214,

        // load 事件的回调函数执行完毕的时间
        loadEventEnd: 1441112693215

        // 字母顺序
        // connectEnd: 1441112692155,
        // connectStart: 1441112692155,
        // domComplete: 1441112693214,
        // domContentLoadedEventEnd: 1441112693101,
        // domContentLoadedEventStart: 1441112693093,
        // domInteractive: 1441112693093,
        // domLoading: 1441112692690,
        // domainLookupEnd: 1441112692155,
        // domainLookupStart: 1441112692155,
        // fetchStart: 1441112692155,
        // loadEventEnd: 1441112693215,
        // loadEventStart: 1441112693214,
        // navigationStart: 1441112691935,
        // redirectEnd: 0,
        // redirectStart: 0,
        // requestStart: 1441112692158,
        // responseEnd: 1441112692687,
        // responseStart: 1441112692686,
        // secureConnectionStart: 0,
        // unloadEventEnd: 0,
        // unloadEventStart: 0
    }
};

具体的含义都在注释里说明了，接下来我们看下能用这些数据做什么？

使用 performance.timing 信息简单计算出网页性能数据

在注释中，我用【重要】标注了我个人认为比较有用的数据，用【原因】标注了为啥要重点关注这个数据

// 计算加载时间
function getPerformanceTiming () {  
    var performance = window.performance;

    if (!performance) {
        // 当前浏览器不支持
        console.log('你的浏览器不支持 performance 接口');
        return;
    }

    var t = performance.timing;
    var times = {};

    //【重要】页面加载完成的时间
    //【原因】这几乎代表了用户等待页面可用的时间
    times.loadPage = t.loadEventEnd - t.navigationStart;

    //【重要】解析 DOM 树结构的时间
    //【原因】反省下你的 DOM 树嵌套是不是太多了！
    times.domReady = t.domComplete - t.responseEnd;

    //【重要】重定向的时间
    //【原因】拒绝重定向！比如，http://example.com/ 就不该写成 http://example.com
    times.redirect = t.redirectEnd - t.redirectStart;

    //【重要】DNS 查询时间
    //【原因】DNS 预加载做了么？页面内是不是使用了太多不同的域名导致域名查询的时间太长？
    // 可使用 HTML5 Prefetch 预查询 DNS ，见：[HTML5 prefetch](http://segmentfault.com/a/1190000000633364)            
    times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;

    //【重要】读取页面第一个字节的时间
    //【原因】这可以理解为用户拿到你的资源占用的时间，加异地机房了么，加CDN 处理了么？加带宽了么？加 CPU 运算速度了么？
    // TTFB 即 Time To First Byte 的意思
    // 维基百科：https://en.wikipedia.org/wiki/Time_To_First_Byte
    times.ttfb = t.responseStart - t.navigationStart;

    //【重要】内容加载完成的时间
    //【原因】页面内容经过 gzip 压缩了么，静态资源 css/js 等压缩了么？
    times.request = t.responseEnd - t.requestStart;

    //【重要】执行 onload 回调函数的时间
    //【原因】是否太多不必要的操作都放到 onload 回调函数里执行了，考虑过延迟加载、按需加载的策略么？
    times.loadEvent = t.loadEventEnd - t.loadEventStart;

    // DNS 缓存时间
    times.appcache = t.domainLookupStart - t.fetchStart;

    // 卸载页面的时间
    times.unloadEvent = t.unloadEventEnd - t.unloadEventStart;

    // TCP 建立连接完成握手的时间
    times.connect = t.connectEnd - t.connectStart;

    return times;
}

使用performance.getEntries() 获取所有资源请求的时间数据

这个函数返回的将是一个数组，包含了页面中所有的 HTTP 请求，这里拿第一个请求 window.performance.getEntries()[0] 举例。注意 HTTP 请求有可能命中本地缓存，所以请求响应的间隔将非常短可以看到，与 performance.timing 对比：没有与 DOM 相关的属性：

navigationStart
unloadEventStart
unloadEventEnd
domLoading
domInteractive
domContentLoadedEventStart
domContentLoadedEventEnd
domComplete
loadEventStart
loadEventEnd

新增属性：

name
entryType
initiatorType
duration

与 window.performance.timing 中包含的属性就不再介绍了：

var entry = {  
    // 资源名称，也是资源的绝对路径
    name: "http://cdn.alloyteam.com/wp-content/themes/alloyteam/style.css",
    // 资源类型
    entryType: "resource",
    // 谁发起的请求
    initiatorType: "link", // link 即 <link> 标签
                           // script 即 <script>
                           // redirect 即重定向
    // 加载时间
    duration: 18.13399999809917,

    redirectStart: 0,
    redirectEnd: 0,

    fetchStart: 424.57699999795295,

    domainLookupStart: 0,
    domainLookupEnd: 0,

    connectStart: 0,
    connectEnd: 0,

    secureConnectionStart: 0,

    requestStart: 0,

    responseStart: 0,
    responseEnd: 442.7109999960521,

    startTime: 424.57699999795295
};

可以像 getPerformanceTiming 获取网页的时间一样，获取某个资源的时间：

// 计算加载时间
function getEntryTiming (entry) {  
    var t = entry;
    var times = {};

    // 重定向的时间
    times.redirect = t.redirectEnd - t.redirectStart;

    // DNS 查询时间
    times.lookupDomain = t.domainLookupEnd - t.domainLookupStart;

    // 内容加载完成的时间
    times.request = t.responseEnd - t.requestStart;

    // TCP 建立连接完成握手的时间
    times.connect = t.connectEnd - t.connectStart;

    // 挂载 entry 返回
    times.name = entry.name;
    times.entryType = entry.entryType;
    times.initiatorType = entry.initiatorType;
    times.duration = entry.duration;

    return times;
}

// test
// var entries = window.performance.getEntries();
// entries.forEach(function (entry) {
//     var times = getEntryTiming(entry);
//     console.log(times);
// });

使用 performance.now() 精确计算程序执行时间

performance.now() 与 Date.now() 不同的是，返回了以微秒（百万分之一秒）为单位的时间，更加精准。

并且与 Date.now() 会受系统程序执行阻塞的影响不同，performance.now() 的时间是以恒定速率递增的，不受系统时间的影响（系统时间可被人为或软件调整）。

注意 Date.now() 输出的是 UNIX 时间，即距离 1970 的时间，而 performance.now() 输出的是相对于 performance.timing.navigationStart(页面初始化) 的时间。

使用 Date.now() 的差值并非绝对精确，因为计算时间时受系统限制（可能阻塞）。但使用 performance.now() 的差值，并不影响我们计算程序执行的精确时间。

// 计算程序执行的精确时间
function getFunctionTimeWithDate (func) {  
    var timeStart = Data.now();

    // 执行开始
    func();
    // 执行结束
    var timeEnd = Data.now();

    // 返回执行时间
    return (timeEnd - timeStart);
}
function getFunctionTimeWithPerformance (func) {  
    var timeStart = window.performance.now();

    // 执行开始
    func();
    // 执行结束
    var timeEnd = window.performance.now();

    // 返回执行时间
    return (timeEnd - timeStart);
}

使用 performance.mark() 也可以精确计算程序执行时间

使用 performance.mark() 标记各种时间戳（就像在地图上打点），保存为各种测量值（测量地图上的点之间的距离），便可以批量地分析这些数据了。

直接上示例代码看注释便明白：

function randomFunc (n) {  
    if (!n) {
        // 生成一个随机数
        n = ~~(Math.random() * 10000);
    }
    var nameStart = 'markStart' + n; 
    var nameEnd   = 'markEnd' + n; 
    // 函数执行前做个标记
    window.performance.mark(nameStart);

    for (var i = 0; i < n; i++) {
        // do nothing
    }

    // 函数执行后再做个标记
    window.performance.mark(nameEnd);

    // 然后测量这个两个标记间的时间距离，并保存起来
    var name = 'measureRandomFunc' + n;
    window.performance.measure(name, nameStart, nameEnd);
}

// 执行三次看看
randomFunc();  
randomFunc();  
// 指定一个名字
randomFunc(888);

// 看下保存起来的标记 mark
var marks = window.performance.getEntriesByType('mark');  
console.log(marks);

// 看下保存起来的测量 measure
var measure = window.performance.getEntriesByType('measure');  
console.log(measure);

// 看下我们自定义的测量
var entries = window.performance.getEntriesByName('measureRandomFunc888');  
console.log(entries);

可以看到，for 循环 measureRandomFunc888 的时候

结束时间为: 4875.1199999969685

开始时间为：4875.112999987323

执行时间为：4875.1199999969685 – 4875.112999987323 = 0.00700000964

标记和测量用完了可以清除掉：

// 清除指定标记
window.performance.clearMarks('markStart888');  
// 清除所有标记
window.performance.clearMarks();

// 清除指定测量
window.performance.clearMeasures('measureRandomFunc');  
// 清除所有测量
window.performance.clearMeasures();

当然 performance.mark() 只是提供了一些简便的测量方式，比如之前我们测量 domReady 是这么测的：

// 计算 domReady 时间
var t = performance.timing  
var domReadyTime = t.domComplete - t.responseEnd;  
console.log(domReadyTime)

其实就可以写成：

window.performance.measure('domReady','responseEnd' , 'domComplete');  
var domReadyMeasure = window.performance.getEntriesByName('domReady');  
console.log(domReadyMeasure);

抛砖引玉：performance 数据能干啥用？

熟悉 Chrome 开发者工具的朋友应该知道：在开发环境下，其实我们自己打开 Chrome 的开发者工具，切换到网络面板，就能很详细的看到网页性能相关的数据。但当我们需要统计分析用户打开我们网页时的性能如何时，我们将 performance 原始信息或通过简单计算后的信息(如上面写到的 getPerformanceTiming() 和 getEntryTiming()) 上传到服务器，配合其他信息（如 HTTP 请求头信息），就完美啦~

让网页加载快1秒的深远影响

Sat, 30 Apr 2016 20:46:00 CST

全球内容交付网络（CDN）服务领头羊 Akamai 近日公布的《互联网状况》指出，2015 年第 4 季度全球平均网速为 5.6Mbps，同比增长 23% 环比增长 8.6%。宽带发展联盟发布的第 11 期《中国宽带速率状况报告》显示，2016 年第 1 季度我国固定宽带网络下载速率达到 9.46 Mbit/s，环比提升 13.4%，而且工信部表示将继续提速年底之前希望平均接入速度达到 30M。

在网络不断提速的大背景下，日常生活中我们依然不时发出「网络太慢了」这样的感慨。自然这里指的「慢」并非是拨号时代需要等待数分钟时间才能完成网页加载的「慢」，而是哪怕拥有高速网络接入，页面载入在感官体验上依然存在延迟--在移动设备上表现的尤为明显。根据 Google 的内部研究这对于互联网商家来说是极其不利的，哪怕一丝的延迟都能导致客户流失。

马修·普林斯（Matthew Prince）和他的初创公司 Cloudflare 已经找到了解决问题的方法。Cloudflare 提供的一项服务是通过在自家服务器上缓存页面来改善网站的速度和安全，避免网站受到黑客攻击的同时也尽可能的为合法用户带来更快的页面载入。现在，为了让网站加载更快，Cloudflare 正部署推出基于 HTTP 2.0 网页标准的服务器推送（Server Push），普林斯表示相比较传统的客户端请求（Client Pull）来说这能够让页面载入时间缩短 1 秒。

也许这缩短的 1 秒时间听上去并不是很多，但根据 Google 的研究，哪怕五分之一秒的延迟都能减少用户愿意消耗在网站上的浏览时间。一个网页应用让你感觉像是本地应用一样流畅还是延迟的无法使用，这两种使用体验之间的差别其实只有数百毫秒。因此普林斯认为服务器推送必然会带来巨大的差异体验，HTTP 2.0 能够让开发者在网络上实现此前认为不可能的事情。

他说道：「 服务器推送是解锁网页应用新篇章的钥匙。我们希望把这把钥匙交到开发者手中并共同见证会创造出什么样的精彩未来。」

小推送大不同

让我们感觉网页载入依然很慢的原因之一是尽管自拨号时代以来带宽不断增加，但与此同时页面也变得的更大更复杂。高分辨率图片、动画特效、视频、广告、分析脚本都是导致变慢的罪魁祸首。网络已经变得非常臃肿，现在的平均网页容量几乎等同于初代《毁灭战士》游戏大小。

导致网站变慢的原因并非仅仅只是网页体积。事实上在打开网页的过程中，下载每个独立元素都需要你的网页浏览器向托管网站的服务器发出独立的请求。如果其中任何一个请求出现 Stalled（阻塞）状态，自然就会影响整个页面的加载，更有可能导致页面显示不正确。

尽管裁切掉这部分的请求或许有些帮助，但对于那些注重图片或者交互功能的网站来说依然需要处理大量的服务器响应。这也意味着网页浏览器同样需要在不受阻碍的方式下使用更好的方式来请求所有元素。

这也是 HTTP 标准继任者--HTTP 2.0 尝试改变的地方。HTTP 2.0 中新增的数项功能能够更快更高效的下载和显示网页，例如能够在一个报文（或者 HTTP 响应）中包含多项数据项。

服务器推送是今后 Cloudflare 公司大力推进的标准，也是公司产品的主打功能。它能够让网页服务器告诉网页浏览器需要在前期页面中所涵盖的所有不同元素，而不再需要现在一样按照顺序载入网页内容。

让网页多任务

普林斯以本地银行网站为例进一步说明。当你登陆的时候，银行网站在生成页面并发送到你的网页浏览器之前必须请求一个关于近期交易清单并计算你银行存款余额的列表，只有当你的浏览器获得页面之后才会进一步请求例如银行 LOGO 和表格样式等其他元素，并告诉浏览器如何格式化网页。 而在部署服务器推送之后，银行网站就可以在计算账户余额的时候发送 LOGO 和表格样式。

包括 Google Chrome 和 Mozilla Firefox 在内的部分浏览器都已经支持 HTTP 2.0。很多其他网页浏览器也已经支持它的前身--Google 的 SPDY（发音和 Speed 相同）协议。不过现在的问题是只有少量的网页真的支持 HTTP 2.0。普林斯表示，网站在部署服务器推送方面进程非常缓慢。

自今天开始，Cloudflare 的客户已经开始在网站上部署服务器推送，哪怕他们自己的服务器或者网站主机并不支持。而伴随着这个进程不断加快，我们日常访问的网站可能变得更快。普林斯表示目前已经有超过 200 万家网站使用 Cloudflare 所提供的服务，这其中包括全球顶级网站前 100 万家中的 7%。从理论上来说，Cloudflare 能够让客户更充分发挥服务器推送的能力，同时也为客户新增了部分工作内容。例如，WordPress 用户将需要安装服务器推送插件以便充分利用这项功能。

普林斯表示该项目的真正意义是，将这把利器交到早期适配者的手中，从而让网页应用翻开新的篇章，尤其是在手机领域。让网页更像一款本地应用样流畅使用，为互联网的未来带来更美好的前景。

文章来源： Wired，TECH2IPO / 创见泡沫编译，首发于创见科技（http://tech2ipo.com/），转载请注明出处。

微信开发之获取OAuth2.0网页授权认证和获取用户信息进行关联

Fri, 16 Oct 2015 14:36:32 CST

最近有做了关于微信公众号和自己网站用户进行用户关联授权登录的一个功能，主要是用户关注该公众号，点击会员中心，则会弹出需要关联授权的网页授权：OAuth2.0网页授权，然后用户同意获取用户信息，进行用户和网站的关联，然后用户则可以使用微信进行登录。

本次做的是一个在Java的Action层处理各个返回参数获取数据。

一、使用到的工具：

1、ngrok，将你自己的本机映射到公网，这样保证可以随时测试开发；

1、下载ngrok，网址： http://www.tunnel.mobi/

2、将文件放到Tomcat目录下，在cmd中运行ngrok -config ngrok.cfg -subdomain xinzhi 8080

3、ngrok工具为在慕课网@LAOBI 看到的

2、微信公众号测试账号，随时测试，首先保证在测试账号下没有问题后在进行公众号的移植。

二、使用到在Java中发送一个Http请求，然后返回JSON参数，获得JSON参数，然后进行处理。

首先，获取将公众号测试号放到properties文件中，以便我们进行调用或者更换,如：url请用https

AppID = wxf00**c3dd2ebfa0
AppSecret = 3cb220755f****506dc35391aa5c03ec
url = https://xinzhi.tunnel.mobi

这里url为我们映射到外网的地址，一会需要用到。然后需要两个工具类，该工具类作用是在Java的Action中发送http请求后获取到去返回值

这里使用的是@ 柳峰，关于服务器请求的代码 http://blog.csdn.net/lyq8479/article/details/9841371，启用自己有相应的改动，以适应本项目的需求：

WeixinUtil.java 和 MyX509TrustManager.java

package com.zhtx.common.util;


import java.io.BufferedReader;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.net.ConnectException;
import java.net.URL;

import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocketFactory;
import javax.net.ssl.TrustManager;


import org.slf4j.Logger;
import org.slf4j.LoggerFactory;


/**
 * 公众平台通用接口工具类
 * 
 * @author xinz
 * @date 2015-10-14
 */
public class WeixinUtil {
	private static Logger log = LoggerFactory.getLogger(WeixinUtil.class);

	/**
	 * 发起https请求并获取结果
	 * 
	 * @param requestUrl 请求地址
	 * @param requestMethod 请求方式（GET、POST）
	 * @param outputStr 提交的数据
	 * @return JSONObject(通过JSONObject.get(key)的方式获取json对象的属性值)
	 */
	public static String httpRequest(String requestUrl, String requestMethod, String outputStr) {
		StringBuffer buffer = new StringBuffer();
		try {
			// 创建SSLContext对象，并使用我们指定的信任管理器初始化
			TrustManager[] tm = { new MyX509TrustManager() };
			SSLContext sslContext = SSLContext.getInstance("SSL", "SunJSSE");
			sslContext.init(null, tm, new java.security.SecureRandom());
			// 从上述SSLContext对象中得到SSLSocketFactory对象
			SSLSocketFactory ssf = sslContext.getSocketFactory();

			URL url = new URL(requestUrl);
			HttpsURLConnection httpUrlConn = (HttpsURLConnection) url.openConnection();
			httpUrlConn.setSSLSocketFactory(ssf);

			httpUrlConn.setDoOutput(true);
			httpUrlConn.setDoInput(true);
			httpUrlConn.setUseCaches(false);
			// 设置请求方式（GET/POST）
			httpUrlConn.setRequestMethod(requestMethod);

			if ("GET".equalsIgnoreCase(requestMethod))
				httpUrlConn.connect();

			// 当有数据需要提交时
			if (null != outputStr) {
				OutputStream outputStream = httpUrlConn.getOutputStream();
				// 注意编码格式，防止中文乱码
				outputStream.write(outputStr.getBytes("UTF-8"));
				outputStream.close();
			}

			// 将返回的输入流转换成字符串
			InputStream inputStream = httpUrlConn.getInputStream();
			InputStreamReader inputStreamReader = new InputStreamReader(inputStream, "utf-8");
			BufferedReader bufferedReader = new BufferedReader(inputStreamReader);

			String str = null;
			while ((str = bufferedReader.readLine()) != null) {
				buffer.append(str);
			}
			bufferedReader.close();
			inputStreamReader.close();
			// 释放资源
			inputStream.close();
			inputStream = null;
			httpUrlConn.disconnect();
			
		} catch (ConnectException ce) {
			log.error("Weixin server connection timed out.");
		} catch (Exception e) {
			log.error("https request error:{}", e);
		}
		return buffer.toString();
	}
}

对于https请求，我们需要一个证书信任管理器，这个管理器类需要自己定义，但需要实现X509TrustManager接口，代码如下:

package com.zhtx.common.util;


import java.security.cert.CertificateException;
import java.security.cert.X509Certificate;

import javax.net.ssl.X509TrustManager;

/**
 * 证书信任管理器（用于https请求）
 * 
 * @author xinz
 * @date 2015-10-14
 */
public class MyX509TrustManager implements X509TrustManager {

	public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
	}

	public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
	}

	public X509Certificate[] getAcceptedIssuers() {
		return null;
	}
}

微信返回参数的一个POJO类：

  private String  openid;  //用户的唯一标识 
  private String  nickname;//用户昵称 
  private Integer sex;// 用户的性别，值为1时是男性，值为2时是女性，值为0时是未知 
  private String  province;//用户个人资料填写的省份 
  private String  city;//普通用户个人资料填写的城市 
  private String  country;// 国家，如中国为CN 
  private String  headimgurl;  // 用户头像，最后一个数值代表正方形头像大小（有0、46、64、96、132数值可选，0代表640*640正方形头像），用户没有头像时该项为空。若用户更换头像，原有头像URL将失效。 
  private String  privilege;// 用户特权信息，json 数组，如微信沃卡用户为（chinaunicom） 
  private String  unionid;// 只有在用户将公众号绑定到微信开放平台帐号后，才会出现该字段。详见：获取用户个人信息（UnionID机制） 
  private String access_token;

授权凭证验证的类：

private String errcode;
private String errmsg;

通过code换取网页授权access_token

	private String access_token;
	private String expires_in;
	private String refresh_token;
	private String openid;
	private String scope;
	private String unionid;

关于微信头像的，获取的是一个http的url，则需要将图片下载到服务器存储，然后获得相对路径：

/**
	 * 使用url或者http存入文件
	 * @Title: fileUpload
	 * @param @param fileUrl  文件url，可以是http
	 * @param @param path     文件存储路径
	 * @return void
	 * @throws xinz
	 */
	public static void fileUpload (String fileUrl,String path){
		 //读取文件
		  String s1 = fileUrl;   
		  java.io.InputStream is = null; //定义一个输入流。
		  BufferedInputStream bis = null;//定义一个带缓冲的输入流 。 
		//写到本地 
		  BufferedOutputStream bos = null; //定义一个带缓冲的输出流。
		  try{ 
			java.net.URL url = new java.net.URL(s1);//创建一个URL对象。
		  	is = url.openStream();//打开到此 URL 的连接并返回一个用于从该连接读入的 InputStream。
		  	bis = new java.io.BufferedInputStream(is);     
		    File file = new File(path);   
			if(!file.exists()){ //测试此抽象路径名表示的文件或目录是否存在。  
				file.createNewFile();   //创建此抽象路径名表示的文件或目录。
			}   
		  bos = new BufferedOutputStream(new FileOutputStream(file));;     
		  byte[] b = new byte[1024]; //创建字节数组。
		  while(bis.read(b)!=-1){//输入流中的数据如果还有下一行(!=-1)将继续循环
			  bos.write(b);//将字节数组写入输出流。    
		  } 
		  }catch(Exception   e){     
			  System.out.println(e.toString());       
		  }finally{     
			  try{     
				  bos.flush();//刷新此缓冲的输出流。 
				  bis.close(); //关闭此输入流 。 
			  }catch(Exception   e){     
				  System.out.println(e.toString());       
			  }     
		  }  
	}

现在是基础工作都做完了，现在开发代码的开发，在微信开发文档中 http://mp.weixin.qq.com/wiki/17/c0f37d5704f0b64713d5d2c37b468d75.html 有提到每一个步骤，然后我们按照这个步骤开发：

第一步：用户同意授权，获取code

这里的url就是前面所准备在properties中的url了。

/**
	 * 微信用户授权
	 * @Title: wechatOauth
	 * @param @param request
	 * @param @param response
	 * @param @param model
	 * @param @return
	 * @return String
	 * @throws xinz
	 */
	@RequestMapping("wechatOauth")
	public String wechatOauth(HttpServletRequest request,HttpServletResponse response,Model model)  {
		/**
		 *  1 第一步：用户同意授权，获取code
		 */
		//首先拿到微信公众号的AppID、AppSecret等参数
		String AppID = ZhtxHelper.getApplicationResourcesProp("sendSms","AppID");
		String urlOpen = ZhtxHelper.getApplicationResourcesProp("sendSms","url");
		//如果用户授权成功则跳转到此url
		String loginUrl = ""+urlOpen+"/zhtx-wap/weixin/getAccessToken";
		//用户授权，获取code
		String url = "https://open.weixin.qq.com/connect/oauth2/authorize?"
					+ "appid="+AppID+""
					+ "&redirect_uri="+loginUrl+""
					+ "&response_type=code"
					+ "&scope=snsapi_userinfo"
					+ "&state=123#wechat_redirect";
		//forward redirect
		return "redirect:"+url+""; 
	}

第二步：通过code换取网页授权access_token

/**
	 * 通过code换取网页授权access_token
	 * @Title: getAccessToken
	 * @param @param request
	 * @param @param response
	 * @param @param model
	 * @param @return
	 * @return String
	 * @throws xinz
	 */
	@RequestMapping("getAccessToken")
	public String getAccessToken(HttpServletRequest request,HttpServletResponse response,Model model) {
		//获取到返回的参数
		try {
			//首先拿到微信公众号的AppID、AppSecret等参数
			String AppID = ZhtxHelper.getApplicationResourcesProp("sendSms","AppID");
			String AppSecret = ZhtxHelper.getApplicationResourcesProp("sendSms","AppSecret");
			String code = request.getParameter("code");
			String url = null;
			if(code!=null){
				/**
				 *  2 第二步：通过code换取网页授权access_token
				 */
				//用户授权，获取code
				url = "https://api.weixin.qq.com/sns/oauth2/access_token?"
						+ "appid="+AppID+""
						+ "&secret="+AppSecret+""
						+ "&code="+code+""
						+ "&grant_type=authorization_code";
				String requestMethod = "GET";
				String outputStr = "";
				String httpRequest = WeixinUtil.httpRequest(url, requestMethod, outputStr);
				
				System.out.println("通过code换取网页授权access_token="+httpRequest);
				
				AccessTokenModel accTok = JSON.parseObject(httpRequest, AccessTokenModel.class);
				/**
				 *  4 第四步：拉取用户信息(需scope为 snsapi_userinfo)
				 */	                                                                      
				//用户授权，获取code
				String urlUser = "https://api.weixin.qq.com/sns/userinfo?"
						+ "access_token="+accTok.getAccess_token()+""
						+ "&openid="+accTok.getOpenid()+""
						+ "&lang=zh_CN";
				
				String httpUser = WeixinUtil.httpRequest(urlUser, requestMethod, outputStr);
				System.out.println("拉取用户信息=="+httpUser);
				
				WechatUser wechatUser = JSON.parseObject(httpUser, WechatUser.class);
				wechatUser.setAccess_token(accTok.getAccess_token());
				/**
				 *  5 附：检验授权凭证（access_token）是否有效
				 */
				WechatMsg checkAccessToken = checkAccessToken(wechatUser.getAccess_token(), wechatUser.getOpenid());
				if(checkAccessToken.getErrcode().equals("0")){
					CurrentSession.setAttribute("wechatUser", wechatUser);
					WechatUser wechatU = new WechatUser();
					wechatU.setOpenid(wechatUser.getOpenid());
					List<WechatUser> findWechatUser = wechatUserService.findWechatUser(wechatU);
					if(findWechatUser.size()>0){
						UserRegister userRegister = userService.findUserByOpenid(wechatUser.getOpenid());
						CurrentSession.setAttribute("user", userRegister);
						return "redirect:/user/userCenter";
					}else{
						
						return "/jsp/wechat/wechatregister"; 
					}
					
				}else{
					//如果access_token失效，则再次进行调用，并存储access_token值，access_token有效期为2个小时
					this.wechatOauth(request, response, model); 
				}
			}
		} catch (Exception e) {
			System.out.println("===拉取用户出错===");
			e.printStackTrace();
		}
		//forward redirect
		return "/jsp/wechat/wechatregister"; 
	}

第四步：拉取用户，和自己网站用户绑定

/**
	 * 微信关联用户
	 * @Title: saveWechatUser
	 * @param @param mobilePhone
	 * @param @param password
	 * @param @param validataCode
	 * @param @return
	 * @return String
	 * @throws xinz
	 */
	@RequestMapping("saveWechatUser")
	public String saveWechatUser(HttpServletResponse response,String mobilePhone,String password,String validataCode){
		//使用手机号来判断该手机是否在注册
		UserRegister userRegister = userService.findUserByPhone(mobilePhone);
		WechatUser wechatUser = (WechatUser)CurrentSession.getAttribute("wechatUser");
		WechatUser wechatU = new WechatUser();
		wechatU.setOpenid(wechatUser.getOpenid());
		List<WechatUser> findWechatUser = wechatUserService.findWechatUser(wechatU);
		if(findWechatUser.size()>0 && userRegister.getOpenid()!=null){
			CurrentSession.setAttribute("user", userRegister);
			return "redirect:/user/userCenter";
		}else{
			//如果没有注册，开始注册
			if(userRegister==null){
				Result<UserRegister> saveUserInfoApp = userRegisterService.saveUserInfoApp(mobilePhone, password, validataCode,wechatUser);
				if(saveUserInfoApp.getState()==1){
					//进行微信和用户的关联
					wechatUserService.saveWechatUser(wechatUser);
					CurrentSession.setAttribute("user", userRegister);
					return "redirect:/user/userCenter";
				}
			}else if(userRegister.getOpenid()==null || userRegister.getOpenid().equals("")){
			//否则，查询出用户信息，放入session中，关联微信，跳转到用户中心	
				UserRegister userReg = new UserRegister();
				userReg.setId(userRegister.getId());
				//存入微信openid
				userReg.setOpenid(wechatUser.getOpenid());
				userService.upUser(userReg);
				UserInfo user = new UserInfo();
				//存入微信头像
				//图片类型
				String dateStr =DateUtil.format(DateUtil.getCurrentDate(), "yyyyMMdd")  + "/";
				//图片类型
				String imgType = "JPG";
				//微信头像名称
				String app2DBarNameAndType = UuidUtil.getUUID()+"."+imgType;
				//微信头像路径
				String path =   ZhtxHelper.getApplicationResourcesProp("application","app.img.projectpath")+ SysConstant.GOODS2DBARPATH + dateStr;
				File file1 = new File(path);
				file1.mkdirs();
				//图片全路径
				String imgUrl = SysConstant.GOODS2DBARPATH + dateStr+app2DBarNameAndType;
				FileUtil.fileUpload(wechatUser.getHeadimgurl(), path);
				user.setRegisterId(userRegister.getId());
				user.setImageUrl(imgUrl);
				userInfoService.updateUserInfo(user);
				//存入微信用户
				wechatUserService.saveWechatUser(wechatUser);
				
				UserRegister userW = userService.findUserByPhone(mobilePhone);
				CurrentSession.setAttribute("user", userW);
				return "redirect:/user/userCenter";
			}else{
				CurrentSession.setAttribute("user", userRegister);
				return "redirect:/user/userCenter";
			}
		}
		return "redirect:/user/userCenter";
	}

附：检验授权凭证（access_token）是否有效

/**
	 * 检验授权凭证（access_token）是否有效
	 * @Title: checkAccessToken
	 * @param @param access_token 网页授权接口调用凭证,注意：此access_token与基础支持的access_token不同 
	 * @param @param openid 用户的唯一标识 
	 * @return WechatMsg   返回消息实体
	 * @throws xinz
	 */
	public static WechatMsg checkAccessToken(String access_token,String openid){
		 String requestMethod = "GET";
		 String outputStr = "";	
		 String url = "https://api.weixin.qq.com/sns/auth?"
		 		+ "access_token="+access_token+""
		 		+ "&openid="+openid+"";
		 String httpmsg = WeixinUtil.httpRequest(url, requestMethod, outputStr);
		 System.out.println("拉取用户信息返回消息=="+httpmsg);
			
		 WechatMsg msg = JSON.parseObject(httpmsg, WechatMsg.class);
	    
		 return msg;
	}

然后在网页端，则是需要编写H5页面，进行自己网站和微信用户的关联，我这里是使用手机号，用户输入手机号，进行判断，如果注册过就直接关联，如果用户没有注册则进行注册后关联，完成后跳转到会员中心。

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

【译】Hybrid移动应用：用网页技术提供Native体验

Wed, 04 Mar 2015 10:21:47 CST

原文： http://www.smashingmagazine.com/2014/10/21/providing-a-native-experience-with-web-technologies/
翻译：叮当当咚当当小胖妞呀杀手爱elva Ivan_z3 肖弦

根据最近的一篇报告显示，HTML是移动应用开发人员使用最多的语言，开发人员对于选择哪种网页技术考虑的最主要因素，是代码的跨平台便携性和开发的低成本性。我们常常听说，hybrid app使用起来非常慢，而且设计也很糟糕，让我们看看是否有可能又有原生应用的形，又有我们习惯使用的感。

这篇文章会提供很多关于如何构建良好的hybrid移动应用的线索、代码片段和经验。我将会大致介绍一下hybrid移动应用的开发，包括它的优点和缺点。然后，我会分享一下过去两年我在开发Hojoki和CatchApp时积累的经验，这两个项目都运行在主流的移动平台，并且是由HTML、CSS和Javascript建成的。最后，我们会介绍一下打包代码到原生app的一些比较好的工具。

什么是混合模式移动应用

移动app可以大致被分为三种，native、hybrid和web app。如果使用native app，你可以使用设备和操作系统的所有能力，同时，平台的性能负荷最小。然而，构建web app可以让你的代码跨平台，使得开发时间和成本大大减少。而hybrid app把这两者的优点都结合起来，使用一套共同代码，在许多不同的平台上部署类似原生的app。

有两种构建hybrid app的方法：

Webview app：HTML,CSS和Javascript基础代码在一个内部的浏览器（叫做WebView）中运行，这个浏览器打包在一个原生的app中，一些原生的API可以通过这个包被Javascript获得，比如 Adobe PhoneGap和 Trigger.io。
被编译的hybrid app：用一种语言编写代码（如C#或者Javascript），对于每一种支持的平台都把代码编译进原生代码中，这样做的结果是，每一个平台都有一个原生的app，但是在开发过程中少了一些自由空间。可以看一下这些例子， Xamarin， Appcelerator Titanium， Embarcadero FireMonkey。

这两种方法都被广泛使用，存在即合理， 不过今天我们只关注WebView app，因为WebView app可以让开发人员平衡他们现有的网页技术。我们来看一下hybrid app相对于native app和web app的各种优点和缺点。

优点

开发人员可以使用现有的网页技术
对于多种平台使用一套基础代码
减少开发时间和成本
使用响应式网页设计可以非常简便的设计出多样的元素（包括平板）
一些设备和操作系统特征的访问
高级的离线特性
可见度上升，因为app可以原生发布（通过app store），也可以发布给移动端浏览器（通过搜索引擎）

缺点

某些特定app的性能问题（那些依赖于复杂的原生功能或者繁重的过渡动画的app，如3D游戏）
为了模拟native app的UI和感官所增加的时间和精力
并不完全支持所有的设备和操作系统
如果app的体验并不够原生化，有被Apple拒绝的风险（比如说一个简单的网站）

这些缺点比较显著，不能忽略，它们告诉我们，并不是所有的app都适合混合模式，你需要小心的预计你的目标用户、他们对平台的选择和对app的需求。对于许多app来说，好处都是大于坏处的，比如内容驱动的app。

Hojoki和CatchApp都是内容驱动的app，所以我们一开始觉得它们非常适合混合模式的开发方式。我们之前提到的好处中的前三点对于我们构建Hojoki的移动app帮助很大，不过也仅仅是4周的时间而已。显而易见，Hojoki的第一个版本缺失了很多重要的东西，接下来的时间里，我们都把精力扑在提升性能、对每一个平台制作自定义的UI和利用不同设备的高级特性上。那个时候积累的那些经验对于让app形似并神似native app很重要，下面我会尽可能多的分享一下我的经验。

那么， 怎么能让你的app形似并神似一个原生的app呢？对于一个移动网页开发人员来说，能够使用设备和操作系统的能力，能够打包他们的app，这些都听上去很棒。然后，如果要用户相信这是一个native app，那么它就必须长得像并且表现的像。如何完成这一点对于混合模式移动开发人员来说仍然是最大的挑战之一。

让你的用户宾至如归

虽然我们只写一套基础代码，但这并不意味着多种不同平台上的感官都要完全一样，你们用户根本不在乎什么潜在的跨平台技术，他们只想要app根据他们的期望来展现，他们想要“宾至如归”。你的第一步应该是为每一个平台做设计概览：

“ IOS设计资源”, IOS开发人员库
“ Android设计”, Android开发人员
“ 设计”, Windows开发中心

虽然这些概览并不能完美适应全部的app，但是它们仍然提供了一套非常全面和标准的界面和体验，每一种平台的用户都会希望得到这样的体验。

DIY VS. UI框架

如果你一个人实施这些组件、样式和动画，这是个很大的挑战，现在有各种各样的UI框架来帮助你，从商业（ Kendo UI）的到开放（ lonic）的，从共同UI（ JQuery Mobile和 Onsen UI）到许多有平台针对性的UI（ Sencha Touch和 ChocolateChip-UI）。有些能够很好的提供精确到像素的布局，有些则相对粗糙，这些各式各样的框架能够很方便的让使用者定义一个web app。然而，就我的观念而言，框架最主要的缺点关乎性能，因为大多数UI框架都尽量“海纳百川”，要根据自己的情况在设备上试试demo后再决定是否要使用。

在制作Hojoki的时候，我们尝试自己用CSS3和极少的Javascript来创建所有的组件，这样做的好处是能够帮助我们控制性能，减少负荷。当然，我们也会使用一些别人使用过的较小的库来解决一下复杂的任务。

自定义UI组件

自定义UI组件也有很多很好的使用例子，你需要根据你的目标用户来决定使用平台的UI还是自定义UI，如果你想要单干，你需要对UX设计有很深的理解，因为之前的那些概览都是专家们为了迎合他们平台用户的需求而制作的。

不管你是决定坚持使用平台的UI概览还是自己做自定义的组件，你都必须知道，有一些特定的设计样式是用户每天使用并热爱的。通常我们如何把一个app介绍给用户呢？通过幻灯片讲演或者教学覆盖。用户如何导航？如果标签栏或者侧边栏。用户如何快速加载或者刷新数据？下拉刷新。（在接下来的文章中会讲到类似原生的滚动）

移动端UI设计的资源

“ 移动端UI设计样式：10几个灵感迸发的网站”，Jacob Gube，Six Revisions
“ 用HTML、CSS和Javascript克隆IOS 7的UI“，Côme Courteault
“ 用HTML5点进移动端UI”（幻灯片），Luke Melia and Yael Sahar, Slideshare

设计一个看起来原生的标题栏

在UI中，标题栏是一个很重要的部分，包括它的标题、导航元素、尤其是前进和后退按钮。对于我来说，许多流行框架在提供HTML和CSS解决方案方面，相比一些原生的app是失败的，而为每个平台用最小的DOM和最少行的css代码来仿照这个UI部分其实相当的简单.

html <header> <button class="back">Feed</button> <h1>Details</h1>  </header>

在JSFiddle中查看“ IOS、Android和Windows Phone中看起来原生的标题栏”的完整代码，下面是我的成果：

用html5和css做成的看起来原生的标题栏

在不同的平台上使用相同的DOM更为便利，因为代码整洁而且易于维护，我发现这样做对于许多IOS和Android上的UI组件都适用(包括标题栏、标签栏、定制的导航菜单、设置页面、浮层，还有很多其他的东西)。然而，想要更多的支持Windows Phone变得更加困难，因为它带来了许多非常不一样的设计模块。

支持高分辨率屏幕

现如今，高分辨率的智能手机和平板构成了巨大的移动设备市场，在 ios设备中占有率超过80%，在 android设备中占有率超过70%。为了让你设备上的图片展现得更清晰，你通常不得不将其尺寸放大到超过它原本大小的两倍，因此现在响应式网站设计中，如何针对所有不同的分辨率提供适合尺寸的图片，成为了现在热议的话题之一。现在有非常多的途径解决，每一种的优点和缺点都与带宽、代码易维护性和浏览器的兼容性有关，现在让我们来快速的回顾一下当下最流行的方法，顺序不分先后：

服务端的调整和传输
客户端通过javascript的检测和替换
html5的picture元素
html5 的srcset属性
css image-set属性
css media queries
可伸缩矢量图形(SVG)

一直以来，针对响应式图片都没有一个完美的方法，这主要还是取决于图片的类型和它们在app上的展现使用方式。如果是静态图片(比如logo和教程图片)，我尽量使用SVG，它们能不费吹灰之力的完美缩放，并且只要你是Android 3+就能获得很好的浏览器支持。

当你不能选择SVG的时候， html5的picture元素和srcset属性一定会成为日后前端开发人员的首选。当下，它们最大的不足就是在浏览器上的支持太局限，因此他们需要一些插件.

同时， css背景图片和media queries是比较可靠的解决方案:

css /* Normal-resolution CSS */ .logo { width: 120px; background: url(logo.png) no-repeat 0 0; } /* HD and Retina CSS */ @media only screen and (-webkit-min-device-pixel-ratio: 1.25), only screen and ( min--moz-device-pixel-ratio: 1.25), only screen and ( -o-min-device-pixel-ratio: 1.25/1), only screen and ( min-device-pixel-ratio: 1.25), only screen and ( min-resolution: 200dpi), only screen and ( min-resolution: 1.25dppx) { .logo { background: url(logo@2x.png) no-repeat 0 0; background-size: 120px; /* Equal to normal logo width */ } }

但是，你的app也许已经包含了许多内容(比如新闻文章)，要调整所有的图片标签或者用css替代会让我们筋疲力竭，在这种情况下，服务端解决方案就会是最好的选择。

从去年开始，越来越多的android系统已经离XXHDPI(超高分辨率)屏幕又进了一步。不论上面提到的哪种方案更适合你的需要，你要记住的是你需要用到三倍于原图大小的图片来支持android的最新的设备。

使用系统字体

使用系统字体是一种让用户体感到宾至如归的一种简单但是重要的方法。

ios、 android和 windows的原生字体

主流平台上，我比较推荐这些字体样式：

/* iOS */ font-family: 'Helvetica Neue', Helvetica, Arial, sans-serif;

/* Android */ font-family: 'RobotoRegular', 'Droid Sans', sans-serif;
/* Windows Phone */ font-family: 'Segoe UI', Segoe, Tahoma, Geneva, sans-serif;
此外，ios7提供了一些有趣的预处理，这些预处理可以自动的设置正确的字体、文字大小和行高，在普通文本中应用 font:-apple-system-body,在标题中使用 font:-apple-system-headline，这样不仅简化了文字的声明，而且还提升了动态类型（这是Apple系统范围的字号设置）的可访问性，你可以在 Thomas Fuchs的文章中了解到更多关于ios7的字体预处理。

一个图标胜过千言万语

图像学在所有主流移动平台的用户体验上是一个重要的部分。相比字体，你一定更愿意使用用户已知的icon，回顾一下我之前说过的高分辨率屏幕，要确保你的icon的大小是可调节的，将它们作为字体通过css的 @font-face来实现，浏览器会有很好的兼容性支持，你甚至可以通过css改变icon的样式（比如颜色、阴影和透明度)。以下是我的推荐:

获取多个平台的icon字体 Ionicons是我们的基本设置，因为它几乎包含了所有我们需要的东西。除了他们常用的一些icon之外，还包含了ios和android的一些特殊的icon，其余的来源于 ios、Android set 1和 set 2以及 Windows Phone的特殊icon字体.
将它们用icon字体生产器结合起来用不同的icon字体让我们感觉非常混乱，还会迅速的增加文件大小，这就是我们为什么使用 Fontello来结合不同字体、调整代码和针对每个平台输出的原因。这样的结果就是 <span class="icon">s</span>在IOS、Android和Windows Phone中看起来是一个搜索图标。同时，还可以了解一些其他比较流行的方案，比如 IcoMoon和 Fontastic。

在 Windows Phone上,你还可以脱离Native font-family: 'Segoe UI Symbol'。

性能优化

性能经常被认为是hybrid移动app中一个主要的缺陷，尤其当你的app有大量的动画，包含大量的滚动列表并且需要在旧设备上运行的时候，缺点会越发的明显。然而，如果你觉得能够接受只支持一些比较新的平台版本(Android 4+,iOS 7+和Windows Phone 8+)的话，那你应该就会看到满意的效果。最终的问题就在于你在优化DOM和CSS选择器、书写高性能的Javascript、减少渲染时间和最少化重排重绘上花了多少工夫。关于移动网页性能的文章和教程一大把，以下是我最喜欢的一些:

“ 成功PhoneGap App的性能和UX考虑因素”，Andrew Trice
“ 移动：网页性能” (幻灯片)，Estelle Weyl
“ 书写快速、内存高效的Javascript,” Addy Osmani, Smashing Magazine
“ 浏览器重排最少化,” Lindsey Simon, Google Developers
“ 如何让你的网站在移动设备上运行更快,” Johan Johansson, Smashing Magazine

此外，随着每天都有新的设备推出，移动硬件和渲染引擎都在以一个非常迅猛的速度提升，开发者能够做到使iPhone5系列、Android手机与Nexus4和5的纯原生App的性能上基本一致。

提升感知速度

构建高效的app是一回事而，让app感觉上运行很快又是另一回事儿。无论你的app是否需要一些时间来完成某项任务(比如一些复杂的计算或者客户端和服务器端的交流)，实时反馈对于提供流畅和响应式体验至关重要。一个比较常用的方法是，在用户还不需要某些功能的时候推迟加载，对用户接下来可能进行的操作作预估和预加载。Instagram有一个著名的例子，当用户忙于添加标签和分享的时候，在后台上传图片。感知速度和真正的速度是不一样的，让我们合理运用它。这里有一些非常简单的例子：

消除触屏设备上点击的延迟

触屏设备中的一个普通Javascript点击事件，从点击的最开始到得到响应会有轻微的延迟(大约300毫秒)，浏览器的这种行为是在判断用户是单击还是双击，如果你不需要“双击以放大”特性，你可以安全的消除这300毫秒从而换取更多响应操作，我最喜欢的解决方案是 FastClick库，你可以把它用在除了IE的所有浏览器上：

js if ('ontouchstart' in window) { window.addEventListener('load', function() { FastClick.attach(document.body); }, false); }

IE10以上比较容易解决,你只需要添加一些css代码:

css html { -ms-touch-action: manipulation; /* IE 10 */ touch-action: manipulation; /* IE 11+ */ }

设计点击状态的样式

只要用户点击一些可操作的元素（例如按钮或者链接），app检测到以后应该马上给他们一些回应。就像在台式机上表现不错的css的伪类 :hover，在移动端你需要换成 :active或者一些javascript解决方案。我曾经在JSFiddle上比较过三种点击状态的方案，你可以根据你的实际情况使用。

还有，记得在调整移动端点击状态的时候清楚默认点击高亮的样式，此外我建议禁用用户在一些活动的元素上选择，因为如果用户不小心点击按钮的时间过长，出现的选择菜单会很烦人。

iOS and Android:

css button { outline: 0; -webkit-tap-highlight-color: rgba(0,0,0,0); -webkit-tap-highlight-color: transparent; -webkit-touch-callout: none; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; }

Windows Phone 8+:

html <meta name="msapplication-tap-highlight" content="no">

提示加载

你的app总是需要一些时间来完成动作，即使只有一秒，所以要考虑添加加载提示，否则用户就可能认为有时候app卡住了，或者在不应该点击的时候乱点，甚至他们可能会乱砸东西并且归责于你的app。根据我的经验，移动端浏览器运用gif动画不是一个好方法。一旦CPU上有一个加载项，gif卡住了，那么这个GIF对用户的加载提示就完全没有作用了。我更喜欢 Spin.js，因为可以自己配置并且运用简单，当然，还有一些其他的方法： javascript解决方案和 css加载方案。

一些跨平台的工具比如PhoneGap和Trigger.io也提供一些原生的加载状态，对于全屏动画加载的展现很棒。

正确设置滚动

滚动在许多app中是决定用户体验的最重要因素之一，它让人又爱又恨，因为要实现这一点取决于你应用依赖的滚动细节以及需要手机系统支持。

几乎所有的app都使用了可滚动内容和固定头部和/或底部。通常有两个CSS方法来实现：

在 body上启用滚动，在header上增加 position: fixed；
在 body上禁用滚动，在内容上增加 overflow: scroll；
在 body上禁用滚动，在内容上增加JavaScript默认滚动。

虽然第一种方法有一些优点（例如IOS的原生滚动到顶部动作以及简洁的代码结构），我强烈推荐第二种方法： overflow: scroll。这个方法渲染问题更少（虽然还是比较多），现代平台上的浏览器支持更好（Android 4+，IOS 5+和Windows Phone 8+)，对于低版本浏览器有方便的小插件。另外，你可以把 overflow: scroll换成自定义的滚动库（第三种选择），例如 iScroll。虽然这些JavaScript解决方案使得特性更加灵活（例如，带动量效果的滚动位置，事件处理，可定制的效果和滚动条等），但它们通常会影响性能。当你在内容里用了许多DOM节点和/或CSS效果（例如 box-shadow， text-shadow, opacity和 rgba)时会很危险。

让我们来看一些基本的滚动特性。

动量效果

触摸友好的动量效果使得用户在大块内容区域的快速滚动显得很直观。通过一些简单的CSS就能在IOS 5+以及Android上一些版本的Chrome中激活。在IOS上，这也会使得内容不溢出顶部和底部边界。

css overflow-y: scroll; -webkit-overflow-scrolling: touch;

下拉刷新

网页上有许多实现这个效果的方法，例如 Damien Antipa写的一种。这个方法在IOS和Windows Phone中效果和体验很相似，Android最近发布它特有的结构（如下）。我们通过一些JavaScript和CSS keyframes在CatchApp里实现了这个效果。（我还没有总结好放到Github上，所以还在调整！）

IOS中的下拉刷新。 (图片属于: Damien Antipa)

Android中的下拉刷新。 (图片属于: Android Widget Center)

Windows Phone中的下拉刷新。 (图片属于: David Washington)

滚动回到顶部

不幸的是，在 body上禁用滚动的同时会破坏IOS中允许用户通过点击状态栏快速回到页面顶部的原生特性。我写了一小段可以添加在任何元素上的脚本来使用JavaScript解决滚动到顶部的问题，即便内容当前处于动量效果中。把它添加到手机端网页头部或通过原生插件添加到状态栏上（例如，PhoneGap）。

许多其他滚动的特性可以通过原生 overflow: scroll实现，例如关闭特定元素或只是无限滚动。如果需求更加复杂，一定考虑使用JavaScript方法。

让点击更容易

用户触摸时，很容易跟目标偏差几个像素，尤其是点击小按钮时（例如IOS顶部条上的按钮）。开发者可以在保证设计的情况下通过在小目标周围开启不可见触摸区域来使用户体验更好。

html <button> <div class="innerButton">Click me!</div> </button>

你需要在按钮元素上绑定事件处理器，同时用 div.innerButton定义样式。在JSFiddle上查看完整的，含有CSS的例子。

使用触摸手势

智能手机的精髓就是触摸和手势。在和触摸设备交互时，我们总是滑动，按压，缩放，拖动和长按。所以，为什么不提供相同的方式来让用户控制你的hybird应用呢？ QuoJS和 Hammer.js是广为人知的支持所有手势类型的库。如果你想要更多选择，看一下Kevin Liew对” 11个多点触摸和触摸事件JavaScript库“的比较。

不要忘了原生功能

用网页技术构建你的应用并不意味着你不能用原生特性。事实上，所有主要的跨平台开发工具提供了提供了内置的对重要功能的接口。其中有许多API包括调用设备数据，文件系统，网络连接，地理位置定位，加速度传感器，提示（包括推送）等等。

通常，你甚至可以通过构建自定义插件来扩展开发工具。在Hojoki,我们加入了许多缺失的特性，包括读取用户对于我们app的推送提示的设置，读取用户时区，检查是否安装第三方APP并启动。让我们来看两个关于用原生插件实现的效果的例子。首先，让我们对IOS 6+里的input启动JavaScript focus（）：

js if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 6) { [YourWebView setKeyboardDisplayRequiresUserAction:NO]; }

下面是在IOS上把给定字符串复制到设备剪贴板里的代码：

[[UIPasteboard generalPasteboard] setString:@"Your copied string"];

总要留有出口

网页开发者经常忽视如何处理hybird应用中的糟糕情况（例如，连接超时，错误输入，时间问题等等）。hybird应用从根本上区别于网站，主要因为它没有全局刷新按钮，在一些移动端操作系统里应用很容易在后台运行数周。如果用户死机了，他们唯一的选择是重启应用，这势必要强制退出然后重启。许多人甚至不知道怎样重启，尤其是在Android 2.x上（它深深隐藏在app设置里）和IOS 6及以下版本上（你需要双击home键，长按图标并且关闭它）。

所以，在开发中先不要觉得有刷新按钮就万事大吉而不考虑出错的情况，我们应该做的是遇到问题就立即解决。对于其他所有意外的情况，例如包含客户端-服务端的通信，准备好应对错误情况，给用户提供一个出口。可以简单得显示一个全屏的错误信息-“欧！出了些问题。请检查你的连接并再次尝试”-下面放一个大大的“重新载入”按钮。

如何打包

开发hybrid移动app就需要用到通常开发（移动）网站一样的工具，开发流程也一样。虽然这么说，我真正喜欢hybrid的地方是你能比较轻松地使用HTML、CSSS和JavaScript来部署移动web app。确保对原生特性实现回退，或在完全不支持该特性的情况下找到优雅的解决方案。大多数移动开发者更喜欢让用户群留在原生app上，甚至可以向使用移动网站的用户宣传这个app。

基于HTML、CSSS和JavaScript的原生WebView打包器

那原生部分怎样呢？移动web app（纯的HTML、CSSS和JavaScript）将加载到一个WebView中。作为一个内部浏览器引擎，WebView会按照设备的默认浏览器渲染网页的方式渲染app（可能会存在细微差别——你遇到的情况可能有所不同）。而且，原生“应用开发平台”用来暴露设备和操作系统的特性，而JavaScript能通过API调用到这些特性。这个API通常包含有调用特性的接口，比如设备摄像头、通讯录、地理位置、文件系统和原生事件（比如通过Android的硬件按钮）等特性。

有一些跨平台的开发工具提供了原生应用开发平台，简化了整个打包流程。下面深入研究部分工具。

PHONEGAP和APACHE CORDOVA

PhoneGap绝对是一个最流行的跨平台开发工具之一，它的名字本身经常被当作hybrid移动app开发的同义词。

关于它的名字以及与 Apache Cordova的关系存在的一些误解是可以理解的。后者是顶级Apache项目，曾用名就是PhoneGap。它提供了一套设备API，并通过运行在WebView中的HTML、CSSS和JavaScript调用原生的功能。现在，Adobe PhoneGap是Cordova的一个分支——与Chrome使用Webkit作为其引擎没有什么不同。

两者都是开源和免费的，支持所有主流平台，拥有一个开发各类插件和扩展的活跃社区。

PhoneGap对塑造hybrid贡献巨大，涌现出的很多新的工具提供了 附加功能，使开发流程简单。这些工具带来了很多便利：通过在云端构建app，免去了在本地安装所有不同平台的SDK和工具的工作。每个工具都有不同的关注点、平台支持度和价钱：

PhoneGap Build
Telerik AppBuilder（前身是Icenium）
AppGyver Steroids
Appery.io（前身是Tiggzi）
Monaca
Intel XDK

SENCHA TOUCH

Sencha Touch最初是一个针对移动web的UI框架，存在有几年了。过去，开发者使用Sencha构建app需同时使用其他如PhoneGap这样的服务来部署成hybrid app。现在Sencha内置了这种功能，可免费使用。支持的平台有iOS和Android（都需要通过Sencha自有的原生打包工具），BlackBerry、Windows 8等更多（通过PhoneGap Build）。

TRIGGER.IO

在Hojoki，我们在两年半前开始用 Trigger.io，因为当时想找一个比PhoneGap轻量级的替代品。虽然它只支持iOS和Android平台，但它提供了一套很不错的原生API、自定义插件和第三方集成（包括Parse消息推送服务、Flurry分析器以及部分Facebook的SDK）。通过Trigger.io的命令行工具，可以将app打包集成到 Grunt的构建过程。如果喜欢自动化，这一点很棒。

它的一个重要特性是 Reload，该特性能使开发者推送HTML、CSSS和JavaScript的更新到运行中的app。与PhoneGap Build的 Hydration不同，Reload专门为开发和生产app设计。这样就使得合法绕过Apple的提交流程去提交bug解决方案和用A/B测试快速迭代就成为可能。

对很多开发者来说，一旦14天的试用期结束，Trigger.io 极高的价格可能就是它最大的缺点。

MoSync似乎是另一种不与PhoneGap有瓜葛的工具，但不太确定当下它的开发活跃度怎样。

在真机上测试

显然，用web技术构建移动app会诱使我们在web浏览器上做大部分的测试。在开发非原生特性时还算说得过去，但在发布时一定要避免。提交app之前，要在尽量多的生产商、平台和各种机型各种版本上测试。Android的机型和版本太多，在浏览器渲染、特性支不支持和生产商更改上会千差万别。虽然iOS渲染的差异好很多，但Apple生产的不同尺寸、分辨率和像素密度的设备越来越多。想了解更多请点击查看“ 设备优先级：测试和响应式web设计”。

在2012年，Facebook放弃绝大部分HTML5开发转向原生开发，其中一个主要原因是“ 缺少调试工具和开发者API”。半年后， LinkedIn得出同样的结论，声称HTML5本身准备好了，但基础工具和生态系统还没来得及支持它。从我的角度来说，情况正变得越来越好：Android 4.4+支持WebView的远程调试；各平台的开发工具越来越多：

“ Web检测器”，Safari（iOS）
“ 使用Chrome在Android上远程调试”
“ 在Visual Studio里调试商店app” (Windows Phone 8.1), Windows Dev Center
Weinre（针对所有平台），Patrick Mueller
Edge Inspect（针对iOS和Android），Adobe

开始考虑硬发布

为web浏览器构建app时，为用户部署修复程序是简单的一步，这意味着测试会失去其重要性。当通过app商店发布app，这就需要重新考虑了。把它想成上世纪90年代的软件开发：你现在就生活在硬发布的世界里。

那么，为什么这很糟糕？首先，提交过程随便就是一两周（寨见，Apple！）。其次，即使修复程序很快发布，也不能保证用户在短时间更新app。以下是我的建议：

测试的优先级要高。
有类似“强制更新”的逻辑来放弃旧有客户端版本。
使用类似Trigger.io的 Reload的机制来修复运行中的代码。
如果想快点，申请紧急app审核。

发布到商店

上面提到的工具会为每个平台生成一个版本，然后将这些版本提交到相应的商店。从这点，过程和发布一个“普通”的原生app几乎一样。在这方面，有些已讨论过的工具可能有更好的文档。尽管这样，以下是官方指南：

“ App分发指南”，Apple
“ 发布入门手册”和“ 发布清单”，Android开发者
“ Windows Phone发布”，Windows研发中心

结论

既然开发的hybrid移动app在Apple的App商店和Google Play已经上线两年了，这里我就总结下在本文开头提到的一些优点和缺点。

对于我们这样一个资源有限、没有原生iOS和Android开发经验的创业公司，要在短短的几周内构建一个多平台的app是不可能的。选择hybrid，我们就能复用很多web app的代码，根据用户反馈迭代速度就快。我们已经成功发布了支持桌面Windows 8和微软Surface的原生app，支持Mac OS X的app也使用了基本一样的代码。移植到另一个平台的工作量很大程度上取决于给定浏览器与设备的能力和所需要的原生功能的水平高低。我们需要消息推送、app内置购买、获取用户联系方式，以及其他功能。根据你的需求，很多原生功能会使你很依赖于所选择的原生打包工具。

最后，我们来看看hybrid app是否真的能给出一个原生的感官享受。以下精选了来自app商店的用户评论。积极和消极的评论都有，其中很多消极的评论来自早期版本——各平台UI一样，性能相对较慢。

评论略去

的确，我们正远离特定平台的app开发而面向不断涌现的很多新技术。去年的Google I/O大会上被问到关于web的未来， Larry Page说：

在很长一段时间，我不认为作为开发者的你会考虑是否为这个平台或那个平台或其他类似平台在开发。我认为你应该在更高的层次上工作，你所写的软件能在每个平台运行起来，而且是很容易地运行起来。

在这方面，（移动）web取得了很大的成功。使用这个平台而且仍然能在所有商店分发app是向前迈出的巨大一步。未来会发生什么敬请期待。无论发生什么，使用世界上1/3人口（其中超过2/3来自欧洲和美国）依赖的技术大概不会是一个坏的选择。

Chrome采用新压缩算法提升网页加载速度降低数据流量消耗

Wed, 20 Jan 2016 22:27:29 CST

谷歌Chrome浏览器很快就会提升网页加载速度并且降低数据流量消耗，这要归功于公司引进的Brotli压缩算法。Brotli压缩算法始于去年九月。谷歌声称和使用已经达到3年时间的Zopfli算法相比，它可以将数据压缩率继续提升26%，谷歌表示，Brotli还可以帮助降低移动设备的电池使用量，达到省电目的。

据谷歌表示，Brotli是一个全新的数据格式，在包装中容纳更多数据，而解压缩速度和其他算法大致相同。如果你希望现在就用上Brotli压缩算法，那么可以下载 Chrome Canary版（谷歌用于测试新功能的浏览器）。

网页链接触发原生Intent

Tue, 15 Dec 2015 01:05:44 CST

人们每天都要访问大量的手机网页, 如果把手机网页(Web)和应用(App)紧密地联系起来, 就可以增大用户的访问量, 也有其他应用场景, 如 网页中调用支付链接, 新闻中启动问诊界面, 提供优质的原生功能等等.

如何在网页(Web)中, 通过Intent直接启动应用(App)的Activity呢?

本文主要有以下几点:
(1) 如何在Web中发送原生的Intent消息.
(1) 如何加载本地的HTML页面到浏览器.
(2) 如何创建半透明的Activity页面.

1. 配置项目

新建HelloWorld工程. 添加ButterKnife支持.

  compile 'com.jakewharton:butterknife:7.0.1'

2. BottomSheet

逻辑, 添加ShareIntent的监听, 即网页链接触发的Intent, 提取Link和Title信息, 底部出现或消失的动画.

  /**
 * 网页Activity
 * <p/>
 * Created by wangchenlong on 15/12/7.
 */
public class WebIntentActivity extends Activity {

    @Bind(R.id.web_intent_et_title) EditText mEtTitle;
    @Bind(R.id.web_intent_et_link) EditText mEtLink;

    @Override protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_bottom_sheet);
        ButterKnife.bind(this);

        // 获取WebIntent信息
        if (isShareIntent()) {
            ShareCompat.IntentReader intentReader = ShareCompat.IntentReader.from(this);
            mEtLink.setText(intentReader.getText());
            mEtTitle.setText(intentReader.getSubject());
        }
    }

    @Override protected void onResume() {
        super.onResume();
        // 底部出现动画
        overridePendingTransition(R.anim.bottom_in, R.anim.bottom_out);
    }

    // 判断是不是WebIntent
    private boolean isShareIntent() {
        return getIntent() != null && Intent.ACTION_SEND.equals(getIntent().getAction());
    }

    @Override public void overridePendingTransition(int enterAnim, int exitAnim) {
        super.overridePendingTransition(enterAnim, exitAnim);
    }
}

动画属性, 沿Y轴变换.

  <set xmlns:android="http://schemas.android.com/apk/res/android">
    <translate
        android:duration="300"
        android:fromYDelta="100%p"
        android:toYDelta="0%p"/>
</set>

  <set xmlns:android="http://schemas.android.com/apk/res/android">
    <translate
        android:duration="300"
        android:fromYDelta="0%p"
        android:toYDelta="100%p"/>
</set>

BottomSheet页面, 由两个EditText组成.

  <?xml version="1.0" encoding="utf-8"?>
<LinearLayout
    android:id="@+id/web_intent_ll_popup_window"
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout_gravity="bottom|center"
    android:background="@android:color/white"
    android:orientation="vertical"
    android:padding="10dp">

    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:gravity="center"
        android:text="发送网页内容到应用"
        android:textSize="20sp"/>

    <android.support.design.widget.TextInputLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_marginEnd="16dp"
        android:layout_marginStart="12dp"
        android:layout_marginTop="8dp">

        <EditText
            android:id="@+id/web_intent_et_title"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:hint="Post Title"
            android:inputType="textCapWords"/>

    </android.support.design.widget.TextInputLayout>

    <android.support.design.widget.TextInputLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_marginEnd="16dp"
        android:layout_marginStart="12dp"
        android:layout_marginTop="8dp">

        <EditText
            android:id="@+id/web_intent_et_link"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:hint="Link"
            android:inputType="textCapWords"/>

    </android.support.design.widget.TextInputLayout>

</LinearLayout>

注意
设置LinearLayout的 android:layout_gravity="bottom|center"属性,
配合样式(Styles)的 <item name="android:windowIsFloating">false</item>属性,
可以在底部显示页面.

声明, 添加 SEND的Action, BROWSABLE的Category, text/plain的文件类型.
主题设置透明主题. 启动时, 会保留上部半透明, 用于显示网页信息.

          <activity
            android:name=".WebIntentActivity"
            android:theme="@style/Theme.Transparent">
            <intent-filter>
                <action android:name="android.intent.action.SEND"/>

                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>

                <data android:mimeType="text/plain"/>
            </intent-filter>
        </activity>

透明主题, 注意一些关键属性, 参考注释, 不一一列举.

      <style name="Theme.Transparent" parent="AppTheme.NoActionBar">
        <!--背景色-->
        <item name="android:windowBackground">@color/page_background</item>
        <!--不使用背景缓存-->
        <item name="android:colorBackgroundCacheHint">@null</item>
        <!--控制窗口位置, 非流窗口, 固定位置, 用于非全屏窗口-->
        <item name="android:windowIsFloating">false</item>
        <!--窗口透明-->
        <item name="android:windowIsTranslucent">true</item>
        <!--窗口无标题-->
        <item name="android:windowNoTitle">true</item>
    </style>

背景颜色 windowBackground非常重要, 不是常规颜色, 也可以设置为透明.

  <!--最前两位是颜色厚度, 00透明, FF全黑-->
<color name="page_background">#99323232</color>

3. 主页面

本地HTML文件存放在 assets中, 提供在浏览器打开功能.
浏览器打开Web链接非常简单, 打开本地HTML有很多难点.

  /**
 * 测试WebIntent的Demo
 *
 * @author C.L.Wang
 */
public class MainActivity extends AppCompatActivity {

    @SuppressWarnings("unused")
    private static final String TAG = "DEBUG-WCL: " + MainActivity.class.getSimpleName();

    private static final String FILE_NAME = "file:///android_asset/web_intent.html";

    @Bind(R.id.main_wv_web) WebView mWvWeb; // WebView

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        ButterKnife.bind(this);
        Toolbar toolbar = (Toolbar) findViewById(R.id.toolbar);
        setSupportActionBar(toolbar);

        FloatingActionButton fab = (FloatingActionButton) findViewById(R.id.fab);
        fab.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View view) {
                // 跳转WebIntentActivity
                startActivity(new Intent(MainActivity.this, WebIntentActivity.class));
            }
        });

        mWvWeb.loadUrl(FILE_NAME);
    }

    @Override public void onBackPressed() {
        // 优先后退网页
        if (mWvWeb.canGoBack()) {
            mWvWeb.goBack();
        } else {
            finish();
        }
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        // Inflate the menu; this adds items to the action bar if it is present.
        getMenuInflater().inflate(R.menu.menu_main, menu);
        return true;
    }

    @Override
    public boolean onOptionsItemSelected(MenuItem item) {
        // Handle action bar item clicks here. The action bar will
        // automatically handle clicks on the Home/Up button, so long
        // as you specify a parent activity in AndroidManifest.xml.
        int id = item.getItemId();

        // 打开浏览器选项
        if (id == R.id.action_open_in_browser) {
            // 获取文件名, 打开assets文件使用文件名
            String[] as = FILE_NAME.split("/");
            openUrlInBrowser(as[as.length - 1]);
            return true;
        }

        return super.onOptionsItemSelected(item);
    }

    /**
     * 在浏览器中打开
     *
     * @param url 链接(本地HTML或者网络链接)
     */
    private void openUrlInBrowser(String url) {
        Uri uri;
        if (url.endsWith(".html")) { // 文件
            uri = Uri.fromFile(createFileFromInputStream(url));
        } else { // 链接
            if (!url.startsWith("http://") && !url.startsWith("https://")) {
                url = "http://" + url;
            }
            uri = Uri.parse(url);
        }

        try {
            Intent intent = new Intent(Intent.ACTION_VIEW, uri);
            // 启动浏览器, 谷歌浏览器, 小米手机浏览器支持, 其他手机或浏览器不支持.
            intent.setClassName("com.android.browser", "com.android.browser.BrowserActivity");
            startActivity(intent);
        } catch (ActivityNotFoundException e) {
            Toast.makeText(this, "没有应用处理这个请求. 请安装浏览器.", Toast.LENGTH_LONG).show();
            e.printStackTrace();
        }
    }

    /**
     * 存储assets内的文件
     *
     * @param url 文件名
     * @return 文件类(File)
     */
    private File createFileFromInputStream(String url) {
        try {
            // 打开Assets内的文件
            InputStream inputStream = getAssets().open(url);
            // 存储位置 /sdcard
            File file = new File(
                    Environment.getExternalStorageDirectory().getPath(), url);
            OutputStream outputStream = new FileOutputStream(file);
            byte buffer[] = new byte[1024];
            int length;
            while ((length = inputStream.read(buffer)) > 0) {
                outputStream.write(buffer, 0, length);
            }
            outputStream.close();
            inputStream.close();
            return file;
        } catch (IOException e) {
            e.printStackTrace();
        }
        return null;
    }
}

注意:
(1) 浏览器打开 assets内文件的方式, 与 WebView有所不同,
具体参考 createFileFromInputStream函数.
(2) 在浏览器打开时, 需要指定包名, 而且各自浏览器的模式也不一样,
小米支持Google原生调用, 参考 openUrlInBrowser函数.
(3) 回退事件的处理方式, 参考 onBackPressed函数.

Github 下载地址

就这些了, 在浏览器的HTML5页面中, 可以添加更多和本地应用的交互.
OK, Enjoy It.

作者：u012515223 发表于2015/12/14 17:05:44 原文链接

阅读：0 评论：0 查看评论

iOS中UIWebView与其中网页的javascript的交互

Thu, 10 Dec 2015 01:38:55 CST

首发：个人博客，更新&纠错&回复

1.本地语言调js的方式与android中的方式类似，也是向WebView控件发送要调用的js语句

2. 但js调本地语言，则不是像android那样直接调一个全局变量的方法，而是通过location.href=xx://yy这样的方式触发UIWebViewDelegate接口实现者的webView shouldStartLoadWithRequest navigationType方法，该方法应该判断目标路径（即xx://yy）的schema（即xx）是否实际是要调用swift，如果是，则按约定执行之，并返回false阻止网页路径变化，如果不是要调用swift，则返回true，让改网页继续正常加载目标url。

android和iOS对比，它们都用了伪url的技术，但android是在本地语言调js时使用了伪url（该url的schema为javascript），而iOS是js调本地语言时使用了伪url（该url是自定义的标识），这个错落很有意思。

swift代码：

import UIKit

class ViewController: UIViewController, UIWebViewDelegate {



  @IBOutlet weak var theWebView: UIWebView!



  override func viewDidLoad() {

   //加载本地html

  let res = NSBundle.mainBundle().pathForResource("index",ofType:"html")

  let url = NSURL(fileURLWithPath: res!);

  let request = NSURLRequest(URL: url);

  self.theWebView.loadRequest(request);

  self.theWebView.delegate = self;

  }



   //让js可以调用swift

  func webView(webView: UIWebView, shouldStartLoadWithRequest request: NSURLRequest, navigationType: UIWebViewNavigationType) -> Bool {

  //判断是不是js在调用swift，如果是，则处理并返回false

  if(request.URL!.scheme == "myschema"){

  let host = request.URL!.host;

  if(host == "go"){

  let query = request.URL!.query!;

  print(query);

  let split = query.componentsSeparatedByString("=");

  let text = split[1];

  self.theWebView.stringByEvaluatingJavaScriptFromString("changeContent(\"" + text + "\")");

  }

  return false;

  }else{

  return true;

  }

  }



   //swift调用js

  @IBAction func btnClicked(sender: AnyObject) {

  self.theWebView.stringByEvaluatingJavaScriptFromString("changeContent(\"123\")");

  }

}

网页代码：

<!DOCTYPE html>

<html>

<head>

  <meta charset="utf-8">

</head>

<body>

  <span id="theSpan"></span>

  <button onclick="doIt()">js调用swift</button>

  <input type="text" id="t">

  <script>

   //让swift可以调用js

  function changeContent(str){

  document.getElementById('theSpan').innerHTML = str;

  }

   //js调用swift

  function doIt(){

  document.location.href = "myschema://go?a=" + document.getElementById("t").value;

  }

  </script>

</body>

</html>

长期欢迎项目合作机会介绍，项目收入10%用于酬谢介绍人。新浪微博： @冷镜，QQ： 908789432。

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

懒人必备的移动端定宽网页适配方案

Tue, 08 Dec 2015 13:49:40 CST

本文最初发布于我的个人博客：咀嚼之味

如今移动设备的分辨率纷繁复杂。以前仅仅是安卓机拥有各种各样的适配问题，如今 iPhone 也拥有了三种主流的分辨率，而未来的 iPhone 7 可能又会玩出什么新花样。如何以不变应万变，用简简单单的几行代码就能支持种类繁多的屏幕分辨率呢？今天就给大家介绍一种懒人必备的移动端定宽网页适配方法。

首先看看下面这行代码：

  <meta name="viewport" content="width=device-width, user-scalabel=no">

有过移动端开发经验的同学是不是对上面这句代码非常熟悉？它可能最常见的响应式设计的 viewport 设置之一，而我今天介绍的这种方法也是利用了 meta 标签设置 viewport 来支持大部分的移动端屏幕分辨率。

目标

仅仅通过配置 <meta name="viewport"> 使得移动端网站只需要按照固定的宽度设计并实现，就能在任何主流的移动设备上都能看到符合设计稿的页面，包括 Android 4+、iPhone 4+。

测试设备

三星 Note II (Android 4.1.2) - 真机
三星 Note III (Android 4.4.4 - API 19) - Genymotion 虚拟机
iPhone 6 (iOS 9.1) - 真机

iPhone

iPhone 的适配比较简单，只需要设置 width 即可。比如：

  <!-- for iPhone -->
<meta name="viewport" content="width=320, user-scalable=no" />

这样你的页面在所有的 iPhone 上，无论是宽 375 像素的 iPhone 6 还是宽 414 像素的 iPhone 6 plus，都能显示出定宽 320 像素的页面。

Android

Android 上的适配被戏称为移动端的 IE，确实存在着很多兼容性问题。Android 以 4.4 版本为一个分水岭，首先说一说相对好处理的 Android 4.4+

Android 4.4+

为了兼容性考虑，Android 4.4 以上抛弃了 target-densitydpi 属性，它只会在 Android 设备上生效。如果对这个被废弃的属性感兴趣，可以看看下面这两个链接：

我们可以像在 iPhone 上那样设置 width=320 以达到我们想要的 320px 定宽的页面设计。

  <!-- for Android 4.4+ -->
<meta name="viewport" content="width=320, user-scalable=no" />

Android 4.0 ~ 4.3

作为 Android 相对较老的版本，它对 meta 中的 width 属性支持得比较糟糕。以三星 Note II 为例，它的 device-width 是 360px。如果设置 viewport 中的 width (以下简称 vWidth ) 为小于等于 360 的值，则不会有任何作用；而设置 vWidth 为大于 360 的值，也不会使画面产生缩放，而是出现了横向滚动条。

想要对 Android 4.0 ~ 4.3 进行支持，还是不得不借助于 页面缩放，以及那个被废除的属性： target-densitydpi。

target-densitydpi

target-densitydpi 一共有四种取值：low-dpi (0.75), medium-dpi (1.0), high-dpi (1.5), device-dpi。在 Android 4.0+ 的设备中，device-dpi 一般都是 2.0。我使用手头上的三星 Note II 设备 (Android 4.1.2) 进行了一系列实验，得到了下面这张表格：

target-densitydpi	viewport: width	body width	屏幕可视范围宽度
low-dpi (0.75)	vWidth <= 320	270	270
	vWidth > 320	vWidth*	270
medium-dpi (1.0)	vWidth <= 360	360	360
	vWidth > 360	vWidth*	360
high-dpi (1.5)	vWidth <= 320	540	540
	320 < vWidth <= 540	vWidth*	vWidth*
	vWidth > 540	vWidth*	540
device-dpi (2.0)**	vWidth <= 320	720	720
	320 < vWidth <= 720	vWidth*	vWidth*
	vWidth > 720	vWidth*	720

vWidth*：指的是与 viewport 中设置的 width 的值相同。
device-dpi (2.0)**：在 Android 4.0+ 的设备中，device-dpi 一般都是 2.0。

首先可以看到 320px 是个特别诡异的临界值，低于这个临界值后就会发生超出我们预期的事情。综合考虑下来，还是采用 target-densitydpi = device-dpi 这一取值。如果你想要以 320px 作为页面的宽度的话，我建议你针对安卓 4.4 以下的版本设置 width=321。

如果 body 的宽度超过屏幕可视范围的宽度，就会出现水平的滚动条。这并不是我们期望的结果，所以我们还要用到缩放属性 initial-scale。计算公式如下：

Scale = deviceWidth / vWidth

这样的计算式不得不使用 JS 来实现，最终我们就能得到适配 Android 4.0 ~ 4.3 定宽的代码：

  var match,
    scale,
    TARGET_WIDTH = 320;

if (match = navigator.userAgent.match(/Android (\d+\.\d+)/)) {
    if (parseFloat(match[1]) < 4.4) {
        if (TARGET_WIDTH == 320) TARGET_WIDTH++;
        var scale = window.screen.width / TARGET_WIDTH;
        document.querySelector('meta[name="viewport"]').setAttribute('content', 'width=' + TARGET_WIDTH + ', initial-scale = ' + scale + ', target-densitydpi=device-dpi');
    }
}

其中， TARGET_WIDTH 就是你所期望的宽度，注意这段代码仅在 320-720px 之间有效哦。

缩放中的坑

如果是 iPhone 或者 Android 4.4+ 的机器，在使用 scale 相关的属性时要非常谨慎，包括 initial-scale, maximum-scale 和 minimum-scale。
要么保证 Scale = deviceWidth / vWidth，要么就尽量不用。来看一个例子：

在缩放比不能保证的情况下，即时设置同样的 width 和 initial-scale 后，两者的表现也是不一致。具体两种机型采用的策略如何我还没有探索出来，有兴趣的同学可以研究看看。最省事的办法就是在 iPhone 和 Android 4.4+ 上不设置 scale 相关的属性。

总结

结合上面所有的分析，你可以通过下面这段 JS 代码来对所有 iPhone 和 Android 4+ 的手机屏幕进行适配：

  var match,
    scale,
    TARGET_WIDTH = 320;

if (match = navigator.userAgent.match(/Android (\d+\.\d+)/)) {
    if (parseFloat(match[1]) < 4.4) {
        if (TARGET_WIDTH == 320) TARGET_WIDTH++;
        var scale = window.screen.width / TARGET_WIDTH;
        document.querySelector('meta[name="viewport"]').setAttribute('content', 'width=' + TARGET_WIDTH + ', initial-scale = ' + scale + ', target-densitydpi=device-dpi');
    }
} else {
    document.querySelector('meta[name="viewport"]').setAttribute('content', 'width=' + TARGET_WIDTH);
}

如果你不希望你的页面被用户手动缩放，你还可以加上 user-scalable=no。不过需要注意的是，这个属性在部分安卓机型上是无效的哦。

其他参考资料

附录 - 测试页面

有兴趣的同学可以拿这个测试页面来测测自己的手机，别忘了改 viewport 哦。

  <!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=250, initial-scale=1.5, user-scalable=no">
    <title>Document</title>
    <style>
        body {
            margin: 0;
        }

        div {
            background: #000;
            color: #fff;
            font-size: 30px;
            text-align: center;
        }

        .block {
            height: 50px;
            border-bottom: 4px solid #ccc;
        }

        #first  { width: 100px; }
        #second { width: 200px; }
        #third  { width: 300px; }
        #fourth { width: 320px; }
        #log { font-size: 16px; }
    </style>
</head>
<body>
    <div id="first" class="block">100px</div>
    <div id="second" class="block">200px</div>
    <div id="third" class="block">300px</div>
    <div id="fourth" class="block">320px</div>
    <div id="log"></div>
    <script>
        function log(content) {
            var logContainer = document.getElementById('log');
            var p = document.createElement('p');
            p.textContent = content;
            logContainer.appendChild(p);
        }

        log('body width:' + document.body.clientWidth)
        log(document.querySelector('[name="viewport"]').content)
    </script>
</body>
</html>

Android应用安全开发之浅谈网页打开APP

Fri, 22 Apr 2016 18:05:40 CST

Author:伊樵，呆狐，舟海@阿里移动安全

0x00 网页打开APP简介

Android有一个特性，可以通过点击网页内的某个链接打开APP，或者在其他APP中通过点击某个链接打开另外一个APP（AppLink），一些用户量比较大的APP，已经通过发布其AppLink SDK，开发者需要申请相应的资格，配置相关内容才能使用。这些都是通过用户自定义的URI scheme实现的，不过背后还是Android的Intent机制。Google的官方文档《Android Intents with Chrome》一文，介绍了在Android Chrome浏览器中网页打开APP的两种方法，一种是用户自定义的URI scheme（Custom URI scheme），另一种是“intent:”语法（Intent-based URI）。

第一种用户自定义的URI scheme形式如下：

第二种的Intent-based URI的语法形式如下：

因为第二种形式大体是第一种形式的特例，所以很多文章又将第二种形式叫Intent Scheme URL，但是在Google的官方文档并没有这样的说法。

注意：使用Custom URI scheme给APP传递数据，只能使用相关参数来传递数据，不能想当然的使用scheme://host#intent;参数;end的形式来构造传给APP的intent数据。详见3.1节的说明。

此外，还必须在APP的Androidmanifest文件中配置相关的选项才能产生网页打开APP的效果，具体在下面讲。

0x01 Custom Scheme URI打开APP

1.1 基本用法

需求：使用网页打开一个APP，并通过URL的参数给APP传递一些数据。

如自定义的Scheme为：

注意：uri要用UTF-8编码和URI编码。

网页端的写法如下：

APP端接收来自网页信息的Activity，要在Androidmanifest.xml文件中Activity的intent-filter中声明相应action、category和data的scheme等。

如在MainActivity中接收从网页来的信息，其在AndroidManifest.xml中的内容如下：

在MainActivity中接收intent并且获取相应参数的代码：

另外还有以下几个API来获取相关信息：

getIntent().getScheme(); //获得Scheme名称 
getIntent().getDataString(); //获得Uri全部路径 
getIntent().getHost(); //获得host

1.2 风险示例

常见的用法是在APP获取到来自网页的数据后，重新生成一个intent，然后发送给别的组件使用这些数据。比如使用Webview相关的Activity来加载一个来自网页的url，如果此url来自url scheme中的参数，如： jaq://jaq.alibaba.com?load_url=http://www.taobao.com。

如果在APP中，没有检查获取到的load_url的值，攻击者可以构造钓鱼网站，诱导用户点击加载，就可以盗取用户信息。

接2.1的示例，新建一个WebviewActivity组件，从intent里面获取load_url，然后使用Webview加载url：

修改MainActivity组件，从网页端的URL中获取load_url参数的值，生成新的intent，并传给WebviewActivity：

网页端：

钓鱼页面：

点击“打开钓鱼网站”，进入APP，并且APP加载了钓鱼网站：

本例建议：
在Webview加载load_url时，结合APP的自身业务采用白名单机制过滤网页端传过来的数据，黑名单容易被绕过。

1.3 阿里聚安全对开发者建议

APP中任何接收外部输入数据的地方都是潜在的攻击点，过滤检查来自网页的参数。
不要通过网页传输敏感信息，有的网站为了引导已经登录的用户到APP上使用，会使用脚本动态的生成URL Scheme的参数，其中包括了用户名、密码或者登录态token等敏感信息，让用户打开APP直接就登录了。恶意应用也可以注册相同的URL Sechme来截取这些敏感信息。Android系统会让用户选择使用哪个应用打开链接，但是如果用户不注意，就会使用恶意应用打开，导致敏感信息泄露或者其他风险。

0x02 Intent-based URI打开APP

2.1基本用法

Intent-based URI语法：

注意：第二个Intent的第一个字母一定要大写，不然不会成功调用APP。

如何正确快速的构造网页端的intent？

可以先建个Android demo app，按正常的方法构造自己想打开某个组件的Intent对象，然后使用Intent的toUri()方法，会得到Intent对象的Uri字符串表示，并且已经用UTF-8和Uri编码好，直接复制放到网页端即可，切记前面要加上“intent:”。

如：

结果：

S.load_url是跟的是intent对象的putExtra()方法中的数据。其他类型的数据可以一个个试。

如果在demo中的Intent对象不能传递给目标APP的Activity或其他组件，则其Uri形式放在网页端也不可能打开APP的，这样写个demo容易排查错误。

APP端中的Androidmanifest.xml的声明写法同2.1节中的APP端写法完全一样。对于接收到的uri形式的intent，一般使用Intent的parseUri()方法来解析产生新的intent对象，如果处理不当会产生Intent Scheme URL攻击。

为何不能用scheme://host#intent;参数;end的形式来构造传给APP的intent数据？

这种形式的intent不会直接被Android正确解析为intent，整个scheme字符串数据可以使用Intent的getDataSting()方法获取到。

如对于：

在APP中获取数据：

结果是：

由上图可知Android系统自动为Custom URI scheme添加了默认的intent。

要想正确的解析，还需使用Intent的parseUri()方法对getDataString()获取到的数据进行解析，如：

2.2 风险示例

关于Intent-based URI的风险我觉得《Android Intent Scheme URLs攻击》和《Intent Scheme URL attack》这两篇文章写的非常好，基本把该说的都都说了，我就不多说了，大家看这两篇文章吧。

2.3 阿里聚安全对开发者建议

上面两篇文章中都给出了安全使用Intent Scheme URL的方法：

除了以上的做法，还是不要信任来自网页端的任何intent，为了安全起见，使用网页传过来的intent时，还是要进行过滤和检查。

0x03 参考

巧用网页分析“反击”钓鱼网站

Mon, 20 Jul 2015 21:00:15 CST

接触网络一段时间的用户都会多多少少遇到一些钓鱼网站，而作为开发者的我们遇到的钓鱼网站更是数不胜数，有时稍不留神就会被钓鱼网站将自己的重要信息钓走，对于钓鱼网站我们也是咬牙切齿，当我们发现钓鱼网站后，我们总是气愤后关闭离开，或者有些正义感的朋友会选择举报该网站。这一次我来讲个更绝的，通过分析钓鱼网站获得其传输方法，发送垃圾数据反击作者。

先说说今天的经历，今天早上去了一趟科技市场，回来发现自己两台不同的手机多了两条相同的发自95588的信息，大致的内容是我的工行密保被冻结了，登陆wap-icbce.pw去解冻，咋看下去好像确实有点蹊跷，登陆上去还真是有模有样:

我乱输入了一个卡号和密码，会显示这样的一个界面

无论你输入什么，他都会显示这样一个界面，后来我又去工行确认了一下，人工服务告诉我这确实是一个钓鱼网站。我作为一个一身正气的人怎么能置之不理呢？首先我先举报了这个网站，发现这还没解气，我尝试使用电脑登陆这个网站，发现这个网站为了防止电脑的防护软件还不让电脑来登陆了。

没关系，使用强大的chrome我成功的在电脑上打开了这个网站（方法不具体说明了，详细参阅百度百科上的chrome开启手机网站的方法）

现在我们可以开始分析网站的源代码了，该钓鱼网站使用.net技术进行编写，感觉网站除了设计方面剩下都是粗制滥造，验证码也是放着其实并没有进行验证，网站的首页是一个识别是否是手机登陆的小图片，如果是手机登陆点击会使用submit字段随便传回一段字符，猜测在该网页的服务器端判断这submit字符应该仅仅使用是否为null来进行判断。

进入这个登录界面，我们能看到里边table字段中清晰的写着用户名密码以及验证码的name，而且获取方式是使用post获取，字符编码使用gb2312，网站分析基本到此结束，现在好戏开场了，首先我使用java编写一段发送数据至asp的java访问代码：

  public static String doPost(String reqUrl, Map parameters, String recvEncoding) {
   HttpURLConnection conn = null;
   String responseContent = null;
   try {
     StringBuffer params = new StringBuffer();
     for (Iterator iter = parameters.entrySet().iterator(); iter.hasNext();) {
       Entry element = (Entry) iter.next();
       params.append(element.getKey().toString());
       params.append("=");
       params.append(URLEncoder.encode(element.getValue().toString(), recvEncoding));
       params.append("&");
     }
     if (params.length() > 0) {
       params = params.deleteCharAt(params.length() - 1);
     }
     URL url = new URL(reqUrl);
     HttpURLConnection url_con = (HttpURLConnection) url.openConnection();
     url_con.setRequestMethod("POST");
     url_con.setConnectTimeout(5000);//（单位：毫秒）jdk
     url_con.setDoOutput(true);
     byte[] b = params.toString().getBytes();
     url_con.getOutputStream().write(b, 0, b.length);
     url_con.getOutputStream().flush();
     url_con.getOutputStream().close();
     InputStream in = url_con.getInputStream();
     BufferedReader rd = new BufferedReader(new InputStreamReader(in, recvEncoding));
     String tempLine = rd.readLine();
     StringBuffer tempStr = new StringBuffer();
     String crlf = System.getProperty("line.separator");
     while (tempLine != null) {
       tempStr.append(tempLine);
       tempStr.append(crlf);
       tempLine = rd.readLine();
     }
     responseContent = tempStr.toString();
     rd.close();
     in.close();
   } catch (IOException e) {
     e.printStackTrace();
   } finally {
     if (conn != null) {
       conn.disconnect();
     }
   }
   return responseContent;
 }

测试没问题后，既然要冲击网站，我们先要随机一些银行卡用户名和密码。

先定义一些需要用到的参数以及要攻击网站的action以及发送的字符编码：

Map m = new HashMap();
String url = "http://wap-icbce.pw/add_1.asp";
String code = "gb2312";

首先银行卡前缀一般是固定的，前十位不随机生成：

String randomcarnum10="6222022102";

后9位就进行一个随机生成的工作：

int randomnum;
randomnum = (int) (Math.random()*1000000000);
randomcarnum10+=randomnum;

按照大部分人的习惯，密码都是前面几个字母+后边几个数字，我们随机前后字母的数量随机生成：

int loopentime,loopnumtime;
loopentime=(int) (Math.random()*10);//随机的英文密码长度
loopnumtime=(int) (Math.random()*10);//随机的中文密码长度
String randompsw = "";
String chars = "abcdefghijklmnopqrstuvwxyz";
for(int i=0;i
randompsw+=chars.charAt((int)(Math.random() * 26));
for(int i=0;i
randompsw+=(int)(Math.random() * 10);

为了以防万一，验证码也随机生成提交：

String randomidcode;
randomidcode=(int)(Math.random()*10000)+"";

最后将数据直接发送到钓鱼网站服务器端：

m.put("logonCardNum", randomcarnum);
m.put("netType", randompsw);
m.put("randomId", randomidcode);
String rus = doPost(url, m, code);
//
System.out.println(rus);

让我们看看成果吧，在程序代码的最后我在控制台中输出了钓鱼网站返回的html文本内容

对比一下钓鱼网站出现的等待跳转界面的html文本内容，基本能确定应该是已经上传数据成功了！写个循环，让程序跑个2小时

这次网站攻击采用了简单的网页关键信息获取方法，以及编写简单的java代码，达到反击钓鱼网站的目的，写这篇文章也是希望能够抛砖引玉，大神轻喷，我有什么建议私信给我，我会很乐于接受多学习多改进。

*本文作者：bawanag，转载须注明来自FreeBuf黑客与极客（FreeBuf.COM）

影响网页渲染的关键！

Mon, 29 Jun 2015 14:33:54 CST

原文链接： http://www.gbtags.com/gb/share/5599.htm

经常有站长、开发者、运维疑惑：为什么我们的后台服务器很快，但是用户要看网页里面的内容却需要很长时间？我们在上一篇文章《怪兽大作战: 解析网站打开慢的原因》中简单介绍了影响网站打开速度的几个指标，感兴趣的同学可以再读一下。今天我们主要讲一下，是哪些因素拖慢了我们的首屏加载时间，也就是用户看到网页中内容时所等待的时间。

用过 OneAPM的读者对这幅图肯定不陌生，一般来讲，如果服务器很快，机房所在线路很快，那么影响用户看到网页内容的主要时间，就是最后两个时间阶段：DOM处理以及网页渲染，在这两个阶段中，浏览器需要解析网页中的各种资源并进行渲染，最终形成用户页面。这个过程是否流畅，直接影响到用户需要等待的时间，从更深层次而言，直接会影响最终的用户体验，现在大家也普遍接受一个观点“延迟就是故障”，所以你需要重视网站的加载速度。

打造轻量级的资源路径--关键渲染路

网页加载速度中最重要的概念是关键渲染路径。如果能理解好这个概念，的确可以让用户更快看到网页中的内容。

轻量级资源和路径，可以缩短复杂网页的构建和渲染时间，甚至比简单网页还要快！由于大多数网页都包含许多不同的组成部分，仅仅移除部分资源并不能保证更快的加载速度。如果你曾经想过：“为了提高网页的加载速度，我还能做什么？”或者“新浪、QQ、网易是如何做到在一秒钟内加载那么多网页内容的？”那么关键渲染路径这个概念正是你需要了解的。

什么是关键渲染路径？

清楚起见，让我们先定义一些概念：

关键：绝对需要
渲染：显示或者展示（在我们的情境中，网页经过渲染才能呈现给用户）
路径：使我们的网页展示在浏览器中的一系列事件
首屏：是用户滚动页面之前就能看见的部分。

因此，换言之，渲染路径就是一系列使你的网页呈现在浏览器中的事件。而关键渲染路径是呈现网页首屏所需的那些事件。因为几乎所有网站在渲染网页时都包含了不必要的步骤，而减少这些不必要的路径，能使你的网页加载速度提高几秒钟，这也是提高网页速度的最快方法。

路径

为了显示一张网页，浏览器必须获取网页所需的所有资源。一个简单的例子：一个网页需要一张图片，一个CSS文件，一个JavaScript文件。

我们来看看这张网页在展示之前经历的路径：

浏览器下载html文件
浏览器读取html文件，发现里面涉及一个CSS文件，一个JavaScript文件和一张图片
浏览器开始下载这张图片
浏览器发现不获取CSS和JavaScript文件就无法显示网页
浏览器下载CSS文件并读取之，确保除此之外没有别的文件需要被访问
浏览器发现不获取JavaScript文件还是无法显示网页
浏览器下载JavaScript文件并读取之，确保除此之外没有别的文件需要被访问
浏览器发现现在可以显示网页了

上面的路径是简单网页的加载过程。现在，试想一下你的网页加载路径会怎么样？你很可能会有几个交互按钮，数个CSS和JavaScript文件，很多图片和小插件，甚至可能还有音频或者视频文件。这意味着，你的渲染路径很可能会像一个大迷宫。大多数网站的渲染路径都极其复杂，因为浏览器在显示网页之前需要加载的文件太多。这就是你可以超过他人的地方。如果你让自己的网页加载得比竞争者的快，你就能获得访问者的青睐（百度就喜欢这样的开发者），例如新浪微博的路径就是这样的：

渲染过程

在展示网页所需的众多资源中，存在一些资源会阻塞网页的渲染过程。最常见的两种资源就是CSS文件和JavaScript文件。不管你需要多少个这样的文件，浏览器必须逐一下载并分析这些文件，然后才能给用户展示内容。让我们来看一个最常见不过的场景：

WordPress博客使用主题。几乎每一个WordPress主题都包含多个CSS文件。

许多主题包含六七个CSS文件。所有的CSS文件都可以合并到一个文件中，但是当你添加主题时，会包含多个CSS文件。因此，在你的博客显示哪怕一个字之前，浏览器都不得不经过六七次的与服务器交互，把这些文件一个个地下载下来，并分析读取，之后才能开始显示。

在加载的过程中，访问者都只能看到一篇空白的屏幕。因为只有当关键步骤完成以后，才会有东西显示。

但是，即便下载完这些CSS文件，你的博客还是不能完成渲染。因为WordPress主题还需要几个JavaScript文件。

因此，渲染一页典型的WordPress博客网页，需要浏览器与服务器交互大约20次，才能将主要的CSS和JavaScript文件下载完毕。但是，等等，现在你还需要交互按钮，小插件……噢，不，针对每一个这样的部件，你还要下载几个CSS，JavaScript文件。

你可能要下载几十个文件，才能让自己的博客展示在用户面前。真是麻烦！（去查查你的网页都要加载什么文件，可以使用OneAPM 的SessionTrace 功能看看网页加载资源在用户那里的速度）

但是事情不仅限于WordPress，本文只是拿它举个例子而已。通常创建网页的初始视图都很多资源，因此会产生多个请求。

关键

目前我只是描绘了一张非常朦胧的蓝图。好消息是：你可以为你的网页请求一
百万个资源，其中包括12000张图像，200个JavaScript文件，而这些都可能在一秒钟内加载完成。

这是如何实现的呢？

只要理解对你的网站而言，显示首屏的内容所需的关键步骤，就能实现。

最优化渲染路径，实际上只要聚焦三件事情：

最小化关键资源的数量
最小化关键字节数
最小化关键路径的长度

理解页面加载速度的测量办法

当百度谈论页面加载速度时，他们并不是指加载一个网页的总时间。他们说的是用户看到首屏所需的时间，以及用户可以开始与页面内容进行交互所需的时间。

百度之所以开始采用页面加载速度作为影响要素，是基于他们用户的满意度。当用户使用百度搜索时，他们要是被带到加载时间很长的页面，无疑是很糟糕的经历。

人们向百度抱怨，他们说：“为什么将我带到一个加载如此缓慢的页面？”显然，人们感知到了速度的差别。

如果一个用户要盯着一个空白的网页10秒之久等待它加载内容，这无疑是很差的体验。百度不想在他们的结果中出现这样的页面。如果那个页面能在1秒内显示内容，这就是极好的用户体验，这才是百度想要的结果。

我们讨论网页速度时最关注的就是将初首屏的内容尽早地显示给用户。通过OneAPM SessionTrace 功能可以查看各个资源的加载速度，方便调整加载资源的策略，例如

后续：

其实，优化网页渲染路还有很多小技巧、插件、方法等待，未来我们将在后续的文章中一一和大家分享。

本文系 OneAPM工程师编译整理。OneAPM是中国基础软件领域的新兴领军企业，能帮助企业用户和开发者轻松实现：缓慢的程序代码和SQL语句的实时抓取。想阅读更多技术文章，请访问OneAPM 官方技术博客。

原文链接： http://www.gbtags.com/gb/share/5599.htm

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

小米路由器劫持特定网页插入应用推广广告

Fri, 19 Jun 2015 15:41:26 CST

陈少举写道 "2015年06月19日，V2EX社区有用户报告称，访问豆瓣电影时，网页上会出现小米路由手机App的广告信息。虽然小米路由器劫持HTTP404错误页面、HTTP403错误页面，已经遭人诟病，不过事后小米官方推出了关闭HTTP错误劫持功能的开关。通过进一步分析小米路由器的页面劫持广告原理，发现存在一个具体的劫持清单，若用户访问的网址存在于此清单中，则会劫持页面并插入广告代码，而此代码存储于 api.miwifi.com ，全程明文通信，并且没有任何加密。由于目前小米路由器没有加密认证机制确保传输的广告内容不被更改，若小米路由器的广告代码访问域名 api.miwifi.com 被网络运营商或恶意劫持，则可能可以推送任意内容，包括恶意内容给小米路由器的用户。此类智能路由器作为用户的入口，可能存在较多隐患，加上厂商对于用户所传输的数据进行精确掌控与收集，以及进行大数据的处理与分析，未来可能会对用户的隐私产生难以预料的影响。"

网页大图片应用技巧浅析

Wed, 11 Mar 2015 18:17:39 CST

用图像创造场景感，增强用户的真实体验，近些年来，图片作为背景填充整个屏幕的设计越来越广泛，曾经只有时尚潮流网站或者摄影类站点才会特别依赖富有冲击力的图像，但是现在几乎任何类型的网站都有可能采用这种大图片作为背景，特别是企业品牌宣传、产品介绍等等。

在设计网页过程中，需要用到大量的图片，而且找到的图片大多风格迥异、无品牌感，那么如何找到合适而又能正确地应用图片呢？

如何正确应用图片

整理了一些经验总结供大家参考：

1 .提炼关键词寻找图片

首先需要提炼产品特性关键词，通过关键词的形式寻找合适的图片。

上图是google云盘官网banner背景为一张在飞机向外看的图片，不难发现用这种比拟手法来表现云盘的口号“随时随地使用”，在任何时候、任何地点都可以使用文件。换位思考，假如我们来设计google云盘官网，首先提炼出关键词：随时随地、自动同步、超大空间等等，用最能突出特点和有代表性的关键词来寻找合适的图片。

上图是IBM旗下的MobileFirst产品，其主要为用户移动应用从创建到维护推出的一体化解决方案为广大用户提供更便利服务，那么根据项目提炼出关键词：手机、用户，该网站用了一张人拿着手机进行使用的图片，目的是为了突出项目的业务特点。

上图分别为苹果官网、研究无线电技术企业——高通的网站中运用的图片同样也是通过产品特点提炼的关键词来完成图片的选用。

2. 图片品牌化

什么是图片品牌化？通过关键词寻找到的图片进行深度加工处理，使之在项目中运用到的图片都是一整套的、风格统一的，比如可以在图片的色调、色彩饱和度与特色风格上做调整等等，下面举几个案例。

Google Drive官网摘取出来的图片，这些图片不难发现无论在色调、色彩饱和度上是一致的，特点是低饱和度、颜色深沉和图片噪点，颜色上新颖有特色、风格上具有明显的品牌统一性。

上图为SAP公司官网的系列图片，作为全球最大的B2B企业为各行各业、不同规模的其他企业提供解决方案，正如它运用不同行业场景的图片一样：色彩丰富、但色调又不过于鲜艳，它们所有用到的图片都有这些特点。

美国高通网站的品牌宣传图片让人印象深刻，品牌特点独树一炽，颜色上运用冷暖搭配，加以渐变效果巧妙地叠加于图片上，虽然颜色种类不多，但能在风格、品牌上具有强烈的统一性，让人对品牌辨识度有更加深刻的记忆性。

项目实践

去年做了几个腾讯云的项目改版，尝试新的风格探索，排版上采用了大图片为背景。设计过程中考虑到产品的长远发展，通过研究后发现图片统一风格在产品品牌推广上有着非常重要的作用，通过几经打磨快速整理了实现方案。腾讯云线上新版本的页面图片已经实现了统一风格。

总结

大图片作为背景的设计风格，这种设计方式虽然非常强有力地抓住用户的注意力，能准确应用图片而达到更大的体验效果是非常重要的，如果去掌握，了解项目背景，利用关键词的方式寻找更合适的图片，此外还需关注用户对产品的印象程度，那么图片的品牌化就显得格外重要，把产品所用的图片设计为一整套统一的风格出来的效果是不可估量的。

IT瘾网页推荐

从输入URL到页面展示过程：深入解析网络请求与渲染

推荐阅读

项目实战:AI文本 OCR识别最佳实践

AI Gamma一键生成PPT工具直达链接

玩转cloud Studio 在线编码神器

玩转 GPU AI绘画、AI讲话、翻译,GPU点亮AI想象空间

资源分享

史上最全文档AI绘画stablediffusion资料分享

AI绘画关于SD,MJ,GPT,SDXL百科全书

AI绘画 stable diffusion Midjourney 官方GPT文档 AIGC百科全书资料收集

引言

1. 网络请求的发起

2. DNS解析

3. 建立TCP连接

4. 发送HTTP请求

5. 服务器处理请求

6. 接收响应数据

7. 解析HTML

8. 构建DOM树

9. 渲染页面

10. 用户交互与动态效果

11. 性能优化

使用 OpenAi Api 在本地搭建一个 ChatGPT 网页版

前言

部署流程

获取API key

docker部署

测试

后记

如何优雅的实现网页多主题风格换肤功能？

简单列举下一些其它实现方式

CSS variable的实现方式

var() 函数

方案落地

一、和UI设计师沟通好各主题的色阶

二、将各主题色阶抽离为一个字典对象

三、通过js设置style变量

举一反三

1、结合媒体查询

2、结合js业务逻辑

3、存储一些信息

感谢

网页音视频通话大火，WebRTC 正式成为 W3C 和 IETF 标准

使用Node.js爬取任意网页资源并输出高质量PDF文件到本地~

需求：

如果你是一名技术人员，那么可以看我接下来的文章，否则，请直接移步到我的 github仓库，直接看文档使用即可

仓库地址: 附带文档和源码,别忘了给个 star哦

本需求使用到的技术： Node.js和 puppeteer

小试牛刀，爬取京东资源

接下来我们直接来爬取 Node.js的官网首页然后直接生成 PDF

无论您是否了解Node.js和puppeteer的爬虫的人员都可以操作，请您一定万分仔细阅读本文档并按顺序执行每一步

文件解构设计

写了个磁力搜索的网页 － 收录最近热门分享的资源

不需要昂贵的 Photoshop，这 7 款免费网页工具想帮你「轻量化」处理图片

黑白图片着色：ColouriseSG

在线、免费的 PS：Photopea

蒙太奇效果：EasyMoza

动图压缩：EZGif

在线版 Prisma：Ostagram

动画图片制作：Loading.io

图片合成：Moose

如何使用Jenkins持续集成C#网站项目 - 暗夜孤灯的个人页面 - 开源中国

如何把多个网页合并下载为 PDF

相关阅读

把网页文章变成电子书装进 Kindle：Doocer

阅读体验确实不错

将网页文章制作成电子书籍

还有一些问题需要注意

如何下载网页上的视频？ - 知乎

2017.1.13

pc端软件

扩展插件

youtube视频

代替那些「用完就删」的 App，试试这 9 个实用的网页小工具

Internet Speed Test

whiteboard

在线 Markdown 编辑器

草料二维码

图片处理

如果你是一名技术人员，那么可以看我接下来的文章，否则，请直接移步到我的 `github`仓库，直接看文档使用即可

仓库地址: 附带文档和源码,别忘了给个 `star`哦

本需求使用到的技术： `Node.js`和 `puppeteer`

接下来我们直接来爬取 `Node.js`的官网首页然后直接生成 `PDF`

写了个磁力搜索的网页－收录最近热门分享的资源

审计和 Lighthouse