本文章的优化手段基于vue2

服务端渲染 SSR or 预渲染

客户端渲染：使用 JavaScript 框架进行页面渲染
服务端渲染：服务端将HTML文本组装好，并返回给浏览器，这个HTML文本被浏览器解析之后，不需要经过 JavaScript 脚本的执行，即可直接构建出希望的 DOM 树并展示到页面中，最后将这些静态标记"激活"为客户端上完全可交互的应用程序。

优点：

更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。对客户端渲染的页面来说，简直无能为力，因为返回的HTML是一个空壳，它需要执行 JavaScript 脚本之后才会渲染真正的页面。
用户将会更快速地看到完整渲染的页面

缺点:

为了实现服务端渲染，应用代码中需要兼容服务端和客户端两种运行情况
由于服务器增加了渲染HTML的需求，使得原本只需要输出静态资源文件的nodejs服务，新增了数据获取的IO和渲染HTML的CPU占用，
服务器渲染应用程序，需要处于 Node.js server 运行环境。

如何实现？

想要在服务器端渲染，我们需要做什么呢？那就是同构我们的项目，Vue.js 是构建客户端应用程序的框架，服务器渲染的 Vue.js 应用程序也可以被认为是"同构"或"通用"，因为应用程序的大部分代码都可以在服务器和客户端上运行

当运行在不同环境中时，我们的代码将不会完全相同，同构就是让一份代码，既可以在服务端中执行，也可以在客户端中执行，并且执行的效果都是一样的，都是完成这个html的组装，正确的显示页面。
对于同构应用来说，我们必须实现客户端与服务端的路由、模型组件、数据模型的共享。

服务器端渲染注意事项

为避免造成交叉请求状态污染，每个请求应该都是全新的、独立的应用程序实例。
由于没有动态更新，所有的生命周期钩子函数中，只有 beforeCreate 和 created 会在服务器端渲染(SSR)过程中被调用。
通用代码不可接受像 window 或 document，这种仅浏览器可用的全局变量
浏览器可能会更改的一些特殊的 HTML 结构，例如，浏览器会在

内部自动注入 ，然而，由于 Vue 生成的虚拟 DOM(virtual DOM) 不包含 ，所以会导致无法匹配。

使用key

对于通过循环生成的列表，应给每个列表项一个稳定且唯一的key，这有利于在列表变动时，尽量少的删除、新增、改动元素

使用冻结的对象

冻结的对象不会被响应化，如果对象很多，嵌套结构很深，遍历过程需要花费很多时间，如果对象不需要动态更改，可以使用冻结对象，如：商品列表等纯展示页面，并不会通过用户交互来更改

var obj = {a:1,b:2}
// 冻结对象
Object.freeze(obj)
// 尝试更改
obj.a = 3
console.log(obj)
// 打印
{a:1,b:2}
// 验证
Object.isFrozen(obj)
// 结果
<.true

vue在处理过程中，如果发现对象是冻结对象，就不会去遍历对象，不会变成响应式

下面是1000000个对象的加载过程

vue

冻结对象

可见vue把对象深度遍历成为响应式，对于大量结构复杂的数据来说，是很耗时间的

使用函数式组件

函数式组件，设置functional:true，函数式组件没有data，这以为它无状态（没有响应式数据）

，也没用实例（没有this上下文），所以组件树中不存在函数式组件，一个函数式组件就像这样

Vue.component('my-component', {
  functional: true,
  // Props 是可选的
  props: {
    // ...
  },
  // 为了弥补缺少的实例
  // 提供第二个参数作为上下文
  render: function (createElement, context) {
    // ...
  }
})

注意：在 2.3.0 之前的版本中，如果一个函数式组件想要接收 prop，则 props 选项是必须的。在 2.3.0 或以上的版本中，你可以省略 props 选项，所有组件上的 attribute 都会被自动隐式解析为 prop。

当使用函数式组件时，该引用将会是 HTMLElement，因为他们是无状态的也是无实例的。

在 2.5.0 及以上版本中，如果你使用了单文件组件，那么基于模板的函数式组件可以这样声明：

<template functional>
</template>

组件需要的一切都是通过 context 参数传递，它是一个包括如下字段的对象：

• props：提供所有 prop 的对象
• children：VNode 子节点的数组
• slots：一个函数，返回了包含所有插槽的对象
• scopedSlots：(2.6.0+) 一个暴露传入的作用域插槽的对象。也以函数形式暴露普通插槽。
• data：传递给组件的整个数据对象，作为 createElement 的第二个参数传入组件
• parent：对父组件的引用
• listeners：(2.3.0+) 一个包含了所有父组件为当前组件注册的事件监听器的对象。这是 data.on 的一个别名。
• injections：(2.3.0+) 如果使用了 inject 选项，则该对象包含了应当被注入的 property。

在添加 functional: true 之后，需要更新我们的锚点标题组件的渲染函数，为其增加 context 参数，并将 this.$slots.default 更新为 context.children，然后将 this.level 更新为 context.props.level。

因为函数式组件只是函数，所以渲染开销(时间和内存)也低很多。

在作为包装组件时它们也同样非常有用。比如，当你需要做这些时：

• 程序化地在多个组件中选择一个来代为渲染；
• 在将 children、props、data 传递给子组件之前操作它们。

下面是一个 smart-list 组件的例子，它能根据传入 prop 的值来代为渲染更具体的组件：

var EmptyList = { /* ... */ }
var TableList = { /* ... */ }
var OrderedList = { /* ... */ }
var UnorderedList = { /* ... */ }

Vue.component('smart-list', {
  functional: true,
  props: {
    items: {
      type: Array,
      required: true
    },
    isOrdered: Boolean
  },
  render: function (createElement, context) {
    function appropriateListComponent () {
      var items = context.props.items

      if (items.length === 0)           return EmptyList
      if (typeof items[0] === 'object') return TableList
      if (context.props.isOrdered)      return OrderedList

      return UnorderedList
    }

    return createElement(
      appropriateListComponent(),
      context.data,
      context.children
    )
  }
})

使用计算属性

如果模版中某个数据会使用多次，并且该数据是通过计算得到的，使用计算属性以缓存它们

非实时绑定的表单项

当使用v-model绑定一个表单项时，当用户改变表单项的状态时，也会随之改变数据，从而导致vue发生重新渲染（rerender），这会带来一些性能的开销。

我们可以通过使用lazy或不使用v-model的方式解决该问题，但要注意，这样可能会导致在某一个时间段内数据和表单项的值是不一致的。

vue设计思想是关注的是数据而不是界面，代码的可维护性和可阅读性也很重要，js执行线程和浏览器渲染线程是互斥的，所以运行动画时执行jS线程动画会卡顿

如双向绑定的文本框输入的内容改变，输入abcd，会进行4次重新渲染，可以使用v-model.lazy,监听@change，不使用监听的是@input

保持对象引用稳定

在绝大部分情况下，vue出发rerender的时机是其依赖的数据发生变化

若数据没有发生变化，哪怕给数据重新赋值了，vue也不会做出任何处理的

下面是vue判断数据没有变化的源码

function hasChanged(x,y) {
  if (x === y) {
    return x === 0 && 1 / x !== 1/y
  }else {
    return x === x || y === y
  }
}

因此，如果需要，只要能保证组件的依赖数据不发生变化，组件就不会重新渲染

对于原始数据类型，保持其值不变即可

对于对象类型，保持其引用不变即可

使用v-show替代v-if

对于频繁切换显示状态的元素，使用v-show可以保证虚拟的dom树的稳定，避免频繁的新增和删除元素，特别是对于那些内部包含大量dom元素的节点，这一点及其重要

使用延迟装载defer

首页白屏时间主要受到两个因素的影响：

• 打包体积过大

  巨型包需要消耗大量的传输时间，导致JS传输完成前页面只有一个<div>，没有可显示的内容

• 需要立即渲染的内容太多

JS传输完成后，浏览器开始执行JS构造页面

但可能一开始要渲染的组件太多，不仅JS的事件很长，而且执行完后浏览器要渲染的元素过多，从而导致页面白屏loading过久

一个可行的办法就是延迟装载组件，让组件按照指定的先后顺序依次一个一个渲染出来

告诉浏览器——你希望执行一个动画，并且要求浏览器在下次重绘之前调用指定的回调函数更新动画。该方法需要传入一个回调函数作为参数，该回调函数会在浏览器下一次重绘之前执行

callback： 下一次重绘之前更新动画帧所调用的函数(即上面所说的回调函数)。该回调函数会被传入DOMHighResTimeStamp参数，该参数与performance.now()的返回值相同，它表示requestAnimationFrame() 开始去执行回调函数的时刻。

思路：浏览器渲染1s渲染60次，第一次渲染一部分，第二次一部分，隔开渲染,分批绘制

// defer.js
export default function(maxFrameCount) {
  return {
    data(){
      return{
        // 浏览器每重绘一次，计数
        frameCount:0,
      };
    },
    mounted() {
      const refreshFrameCount = () => {
        requestAnimationFrame(() => {
        	this.frameCount++;
          if(this.frameCount < maxFrameCount) {
            refreshFrameCount();
          }
        });
      };
      refreshFrameCount();
    },
    methods: {
      defer(showInFrameCount) {
        // 用于v-if 的判断条件，渲染次数大于showInFrameCount后继续下一次渲染
        return this.frameCount >= showInFrameCount
      },
    },
  };
}

<template>
  <div class="container">
    <!--vue3.0 v-if 优先级高 vue2.x v-for优先级高-->
    <div class="block" v-for="n in 20" v-if="defer(n)">
      <heavy-comp></heavy-comp>
    </div>
  </div>
</template>
<script>
import defer from "./mixin/defer";
export default {
  mixins: [defer(300)],
  components: { HeavyComp },
};
</script>

使用keep-alive

用于缓存内部组件实例，里面有include和exclude属性，max设置最大缓存数，超过后，自动删除最久没用的。

受到keep-alive影响，其内部的组件都具有两个生命周期，activated和deactivated ,分别再组件激活和失活时触发，第一次activated是在mounted之后。

一般用在需要多个页面频繁操作的场景（导航条）

长列表优化

一般用在app端下拉的时候，或者列表很长的时候，通过一个固定大小的渲染池来解决。通过滚动条等一些操作，减少页面渲染市场，有现成的库，vue-virtual-scroller

https://github.com/Akryum/vue-virtual-scroller

通过v-once创建低开销的静态组件，渲染一次后就缓存起来了，除非你非常留意渲染速度，不然最好不要用，因为有的开发者不知道这个属性或者看漏了，然后花费好几个小时来找为什么模板无法正确更新。

打包体积优化

• Webpack 对图片进行压缩
• 静态资源的优化使用对象存储加CDN
• 减少 ES6 转为 ES5 的冗余代码
• 提取公共代码
• 模板预编译
• 提取组件的 CSS
• 优化 SourceMap
• 构建结果输出分析
• Vue 项目的编译优化

基础优化

• 开启 gzip 压缩
• 浏览器缓存
• CDN 的使用
• 使用 Chrome Performance 查找性能瓶颈

1. 思路

带入作者的角度思考一下，想要达成响应式的特点应该是:属性更新，自动调用依赖^[1]的函数进行重新渲染

// euv.js
/**
 * 观察某个对象的所有属性
 * @param {Object} obj
 */
function observe(obj) {
  for (const key in obj) {
    let internalValue = obj[key];
    let funcs = [];
    Object.defineProperty(obj, key, {
      get: function () {
        //  依赖收集，记录：是哪个函数在用我
        if (window.__func && !funcs.includes(window.__func)) {
          funcs.push(window.__func);
        }
        return internalValue;
      },
      set: function (val) {
        internalValue = val;
        // 派发更新，运行：执行用我的函数
        for (var i = 0; i < funcs.length; i++) {
          funcs[i]();
        }
      },
    });
  }
}

function autorun(fn) {
  window.__func = fn;
  fn();
  window.__func = null;
}

// index.js
var user = {
  name: '有骨气',
  birth: '1998-4-7',
};

observe(user); // 观察

// 显示姓氏
function showFirstName() {
  document.querySelector('#firstName').textContent = '姓：' + user.name[0];
}

// 显示名字
function showLastName() {
  document.querySelector('#lastName').textContent = '名：' + user.name.slice(1);
}

// 显示年龄
function showAge() {
  var birthday = new Date(user.birth);
  var today = new Date();
  today.setHours(0), today.setMinutes(0), today.setMilliseconds(0);
  thisYearBirthday = new Date(
    today.getFullYear(),
    birthday.getMonth(),
    birthday.getDate()
  );
  var age = today.getFullYear() - birthday.getFullYear();
  if (today.getTime() < thisYearBirthday.getTime()) {
    age--;
  }
  document.querySelector('#age').textContent = '年龄：' + age;
}
autorun(showFirstName);
autorun(showLastName);
autorun(showAge);

2. 原理

vue2响应式原理简单来说就是vue官网上的这图片

通过 Object.defineProperty 遍历对象的每一个属性，把每一个属性变成一个 getter 和 setter 函数，读取属性的时候调用 getter，给属性赋值的时候就会调用 setter.

当运行 render 函数的时候,发现用到了响应式数据，这时候就会运行 getter 函数，然后 watcher（发布订阅）就会记录下来。当响应式数据发生变化的时候，就会调用 setter 函数，watcher 就会再记录下来这次的变化，然后通知 render 函数，数据发生了变化，然后就会重新运行 render 函数，重新生成虚拟 dom 树。

3. 深入了解

我们要明白，响应式的最终目标：是当对象本身或对象属性发生变化时，会运行一些函数，最常见的就是 render 函数。不是只有 render，只要数据发生了变化后运行了一些函数，就是响应式,比如 watch。

在具体实现上，vue 采用了几个核心部件:

1. Observer

2. Dep

3. Watcher

4. Scheduler

4. Observer

observer 要实现的目标非常简单，就是把一个普通的对象转换成响应式的对象

为了实现这一点，observer 把对象的每个属性通过 object.defineProperty 转换为带有 getter 和 setter 的属性，这样一来，当访问或者设置属性时，vue 就会有机会做一些别的事情。

在组件的生命周期中，这件事发生在 beforeCreate 之后，create 之前。

具体实现上，他会递归遍历对象的所有属性，以完成深度的属性转换。

但是由于遍历只能遍历到对象的当前属性，无法监测到将来动态添加或者删除的属性，因此 vue 提供了$set和$delete 两个实例方法，但是 vue 并不提倡这样使用，我讲到 dep 的时候我再说为什么。

对于数组的话，vue 会更改它的隐式原型，之所以这样做是因为 vue 需要监听那些可能改变数组内容的方法。

数组 --> vue 自定义的对象 --> Array.prototype

总之，observer 的目标，就是要让一个对象，它属性的读取，赋值，内部数组的变化都要能够被 vue 感知到。

4.1. 手动转换响应式对象

Vue提供了静态方法：Vue.observable() 手动将普通对象转为响应式对象。

var obj = {
    a: 1,
    b: 2,
    c: {
        d: 3,
        e: 4
    },
    f: [
        {
            a: 1,
            b: 2
        },
        3, 4, 5, 6
    ]
}

// 利用Vue提供的静态方法 .observable, 将一个普通对象转化为响应式对象
var reactiveObj = Vue.observable(obj)
console.log(reactiveObj)

4.2. data

Vue不允许动态添加根级响应式属性，所以需要在组件实例化之前通过配置中的 data 字段，声明所有根级响应式属性，哪怕属性值为 null。由此带来的好处有：

1. 更易于维护： data对象就像组件的状态结构（schema）, 提前声明所有响应式属性，后期有助于开发者理解和修改组件逻辑。
2. 消除了在依赖项跟踪系统中的一类边界情况。
3. 使Vue实例能够更好的配合类型检查系统工作。

4.3. 「动态添加或删除属性」

由于Vue会在初始化实例时，对所有属性（配置里 data 中存在的属性）执行 getter/setter 的转化。

那么对于 「动态添加或删除」 的属性，Vue是无法自动检查其变化。

因此，Vue提供了以下方式来手动完成响应式数据。

1. 添加：「Vue.set(target, key, val)」 或 「this.$set(target, key, val)」
2. 删除：「Vue.delete(target, key)」 或 「this.$delete(target, key)」
3. 批量操作：this.reactiveObj = Object.assign({}, this.reactiveObj, obj)

举个例子：

<template>
    <div class="demo-wrapper">
        <p>obj.a -> {{ obj.a }}， obj.b -> {{ obj.b }}</p>

        <!-- 非响应式式数据操作 -->
        <!-- 
            <button @click="obj.b = 2">add obj.b</button>
            <button @click="delete obj.a">delete obj.a</button>
        -->
        <!-- 响应式数据操作 -->
        <button @click="$set(obj, 'b', 2)">add obj.b</button>
        &nbsp;
        <button @click="$delete(obj, 'a')">delete obj.a</button>
    </div>
</template>

<script>
export default {
    data() {
        return {
            obj: {
                a: 1,
            },
        };
    },
};
</script>

4.4. 「关于数组」

由于js的限制， Vue不能检测到以下数组变动：

1. 当利用索引直接改变数组项时， 例如：vm.arr[idx] = newValue
2. 当修改数组长度时 ，例如： vm.arr.length = newLength

举个例子：

<script>
export default {
    data() {
        return {
            arr: [1, 2, 3, 4],
        };
    },
    created() {
        window.lesson4 = this;
    },
    mounted() {
        this.arr[0] = 8; // 不是响应式的
        this.arr.length = 2; //不是响应式的
    }
};
</script>

为了让上述数组操作具有响应式，采用以下方法处理：

<script>
export default {
    data() {
        return {
            arr: [1, 2, 3, 4],
        };
    },
    created() {
        window.lesson4 = this;
    },
    mounted() {
				// 操作一：通过索引修改数组项
        this.$set(arr, 0, 8); // 响应式的
        // 或
        Vue.set(arr, 0, 8);  // 响应式的
        // 或
        this.arr.splice(0, 1, 8) //响应式的
      
        // 操作二：修改数组长度为2
        this.arr.splice(2) // 响应式的
    }
};
</script>

除了可以通过静态方法 Vue.set() 和 实例方法 this.$set() 响应式的修改数组项的值。还可以使用数组方法 - splice() 。

因为，Vue对一些可以改变数组自身内容的操作API，如：splice()、sort()、push()、pop()、reverse()、shift()、unshift() 等进行了拦截和重写。从而在开发者使用这些API时，可以触发响应式数据，进而更新视图。

<script>
  export default{
    data() {
      return {
        arr: [1,2,3,4]
      }
    },
    mounted() {
      console.log(this.arr._proto_ === Array.prototype)  // => false
      console.log(this.arr._proto_._proto_ === Array.prototype)  //=> true
    }
  }
</script>

5. Dep

这里有两个问题没解决，就是读取属性时要做什么事，属性变化时又要做什么事，这个问题就得需要 dep 来解决

dep 的含义是 dependency 表示依赖的意思。

vue 会为响应式对象中的每一个属性，对象本身，数组本身创建一个 dep 实例，每个 dep 实例都可以做两件事情：

1，记录依赖：是谁在用我

2，派发更新：我变了，我要通知那些用我的人

当读取响应式对象的某一个属性时，他会进行依赖收集，有人用到了我

当改变某个属性时，他会派发更新，那些用我的人听好了，我变了

为什么尽量不要使用$set $delete ?

因为如果模板上没有用到值的话，你凭空加了一个数据,理论上来说应该不会重新运行render函数，但是上一级的dep发现自身发生改变了，所以也会导致重新运行render函数。

所以vue不建议使用$set 和$delete,最好提前先写上数据,哪怕先给数据赋值为 null;

6. watcher

这里又出现了一个问题，就是 dep 如何知道是谁在用我呢

watcher 就解决了这个问题

当函数执行的过程中，用到了响应式数据，响应式数据是无法知道是谁在用自己的

所以，我们不要直接执行函数，而是把函数交给一个 watcher 的东西去执行，watch 是一个对象，每个函数执行时都应该创建一个 watcher，通过 wacher 去执行

watcher 会创建一个全局变量，让全局变量记录当前负责执行的 watcher 等于自己，然后再去执行函数，在函数执行的过程中，如果发生了依赖记录，那么 dep 就会把这个全局变量记录下来，表示有一个 wathcer 用到了我这个属性。

当 dep 进行派发更行时，他会通知之前记录的所有 watcher，我变了。

7. Scheduler

现在还剩下最后一个问题啊，就是 dep 通知 watcher 之后，如果 wathcer 执行重新运行对应的函数，就有可能导致频繁运行，从而导致效率低下，试想，如果一个交给 watcher 的函数，它里面用到了属性 a,b,c,d,那么 a,b,c,d 都会记录依赖，然后这四个值都以此重新赋值，那么就会触发四次更新，这样显然不行啊，所以当 watcher 收到派发更新的通知后，实际上并不是立即执行，而是通过一个叫做 nextTick 的工具方法，把这些需要执行的 watcher 放到事件循环的微队列，nextTick 是通过 Promise then 来完成的。

也就是说，在响应式数据发生变化时，render 函数执行是异步的，并且在微队列中。

8. 异步更新队列

Vue侦听到数据变化，就会开启一个队列。但是组件不会立即重新渲染，而是先会缓冲在同一个事件循环中的发生的所有数据变化。此时如果同一个watcher被多次触发，只会被推入到队列中一次，这样可以**「避免不必要的计算和DOM更操作」**。
在下一个事件循环”tick“中， Vue刷新队列并执行实际（已去重的）工作（更新渲染）。
为此，Vue提供了异步更新的监听接口 —— Vue.nextTick(callback) 或 this.$nextTick(callback) 。当数据发生改变，异步DOM更新完成后，callback回调将被调用。开发者可以在回调中，操作更新后的DOM。

「举例1」

<script>
export default {
    data() {
        return {
            a: 1,
            b: 2,
            c: 3,
            d: 4,
        };
    },
    methods: {
        changeAllData() {
            this.$nextTick(function () {
                var pre = document.querySelector("pre");
                console.log(pre.textContent);
            });

            this.a = this.b = this.c = this.d = 10;

            this.$nextTick(function () {
                var pre = document.querySelector("pre");
                console.log(pre.textContent);
            });
        },
    },
    render(h) {
        console.log('render function')
        return h('div', [
            h('pre', `${this.a}, ${this.b}, ${this.c}, ${this.d}`),
            h('button', {
                on: {
                    click: () => {
                        this.changeAllData()
                    }
                }
            }, 'change all data')
        ])
    }
};
</script>

上例，通过一个NextTick组件的渲染，了解下 的用法。为了方便查看组件渲染时，render函数被调用的过程，在组件定义时，直接给出render函数。当点击按钮后，会在数据修改前后，使用nextTick工具方法。分别写入两个读取界面Dom的函数。结果会发现，第一个 $nextTick 回调函数获取的数据为旧数据，第二个 $nextTick回调函数获取的数据为新数据。

分析一下：

按钮点击后，异步队列的添加步骤是：

1. 第一个 $nextTick ，会将自己的回调函数（fn1）加入到当前的异步队列中。
2. 修改数据后， 经过派发更新，Scheduler会将包含了watcher队列执行逻辑的函数（fn2）加入到当前的异步队列中。
3. 第二个 $nextTick， 已将自己的回调函数（fn3）加入到当前的异步队列中。

当异步队列执行时，会依次执行 fn1 ， fn2，fn3。而当fn2执行后，界面才会更新最新数据，所以fn1，fn3获取的界面数据前者为旧数据，后者为新数据。

「举例2」

<template>
  <span>{{a}}</span>
</template>
<script>
	export default {
    data() {
      return {
        a: 'hello'
      }
    },
    mounted() {
      this.a = 'world'
      console.log(this.$el.textContent)  // -> 'hello'
      this.$nextTick(function() {
        console.log(this.$el.textContent) // -> 'world'
      })
    }
  }
</script>

上面代码，当设置 this.a = 'world' 后，访问DOM元素内容，但完成未更新。此时，立即使用 this.$nextTick() 监听DOM更新，并在监听回调调用时，获取更新后的DOM内容。

另外， this.$nextTick() 其内部尝试使用原生的 Promise.then、MutationObserve、setImmediate，如果执行环境不支持，则会采用 setTimeout 替代。并且最终返回一个Promise对象，所以可以使用 async/await 语法替代 callback的写法。

<script>
	export default {
    data() {
      return {
        a: 'hello'
      }
    },
    // $nextTick 结合 async/await语法使用
    async mounted() {
      this.a = 'world'
      console.log(this.$el.textContent)  // -> 'hello'
      await this.$nextTick()
      console.log(this.$el.textContent) // -> 'world'
    }
  }
</script>

9. 总流程图

本文档解释了使 Flutter API 正常工作的 Flutter 工具包内部工作原理。由于 Flutter widget 是以积极组合的形式构建的，所以使用 Flutter 构建的用户界面含有大量 widget。为了支撑这些负载，Flutter 使用了次线性算法来布局和构建 widget，这些数据结构使树形结构优化更加高效，并且具有很多常量因子优化。通过一些额外的机制，该设计也允许开发者利用回调（用于构建用户可见的 widget）来轻松创建无限滚动列表。

积极可组合性

组合性是 Flutter 最为出众的一个特性。widget 通过组合其他 widget 的方式进行构建，并且这些 widget 自身由更基础的 widget 构建。比如，Padding 是一个 widget 而非其他 widget 的属性。因此，使用 Flutter 创建的用户界面是由多个 widget 组成的。

widget 递归构建的底层是 RenderObjectwidget，它将在渲染树的底部创建子节点。渲染树是一种存储用户界面几何信息的数据结构，该几何信息在 布局 期间计算并在 绘制 及 命中测试 期间使用。大多数 Flutter 开发者无需直接创建这些对象，而是使用 widget 来操纵渲染树。

为了支持 widget 层的积极可组合性， Flutter 在 widget 和树渲染层使用了大量的高效算法和优化措施，这些将在下面小节中进行介绍。

次线性布局

使用大量 widget 及渲染对象并保持高性能的关键是使用高效的算法。其中最重要的是确定渲染对象几何空间（比如大小和位置）的布局算法的性能。其他一些工具包使用 O(N²) 或更糟糕的布局算法（例如，约束域中的不动点迭代）。 Flutter 的目标在于布局初始化的线性性能，及一般情况下更新现有布局的次线性布局性能。通常情况下，布局所花费的时间应该比对象渲染要多得多。

Flutter 对每一帧执行一次布局操作，且布局算法仅在一次传递中完成。 约束信息通过父节点调用每个子节点的布局方法向下传递。子节点递归执行自身的布局操作，并在它们的布局方法中返回几何信息以便将其添加到渲染树中。需要注意的是，一旦渲染对象从布局中返回，该对象将不会被再次访问 [^1]，直到下一帧布局的执行。该策略将可能存在的单独测量和布局传递合并为单次传递，因此，每个渲染对象在布局过程中最多被访问两次 [^2]：一次在树的向下传递过程中，一次在树的向上传递过程中。

针对这个通用协议，Flutter 拥有多种实现。最常用的是 RenderBox，它以二维的笛卡尔坐标进行运算。在盒子布局中，约束是最小及最大宽高。在布局过程中，子节点通过选择这些边界内的大小来确定其几何信息。子节点在布局中返回后，由父节点确定该子节点在父坐标系中的位置 [^3]。注意，子节点的布局并不取决于它的位置，这是因为它的位置直到它从布局中返回后才确定。因此父节点可以在无需重新计算子节点布局的情况下重新定位子节点的位置信息。

更广泛地讲，在布局期间，从父节点流向子节点的唯一信息是约束信息，从子节点流向父节点的唯一信息是几何信息。通过这些不变量可减少布局期间所需的工作量：

• 如果父节点对子节点使用与上一次布局中相同的约束，且子节点没有将自己的布局标记为脏，那么该节点可立即从布局中返回，以切断布局的向下传递。
• 当父节点调用子节点的布局方法时，父节点会表明它是否使用从子节点返回的大小信息。如果父节点经常不使用此信息，即使子节点重新选择了大小，父节点依旧无需重新计算其布局，这是因为父节点需要保证新的大小符合现有约束。
• 严格约束是指恰好由一个有效几何满足的约束。比如，如果最小最大宽度彼此相等，且最小最大高度彼此相等，那么满足这些约束的唯一大小便是具有该宽度及高度的大小。如果父节点提供了严格约束，即便父节点在布局中使用了子节点的大小，在子节点重新计算布局时，父节点的布局也无需重新计算，这是因为子节点在没有父节点新约束的情况下无法更改其大小。
• 渲染对象可以声明仅使用父节点提供的约束来确定其几何信息。此类声明通知框架： 即便约束为非严格约束，以及父节点的布局取决于子节点的大小， 该渲染对象父节点的布局在子节点的布局重新计算时仍无需重新计算，这是因为子节点在没有父节点新约束的情况下无法更改其大小。

这些优化措施的效果是，当渲染对象包含脏节点时，在布局过程中，只有这些节点以及它们周围子树的有限节点才允许被访问。

次线性 widget 构建

Flutter 使用类似于布局的次线性算法来构建 widget。widget 构建完成后，它们将被保留了用户页面逻辑结构的 element 树 保存。 Element 树是非常有必要的，这是因为 widget 自身是不可变的，这意味着（其他情况除外），它们无法记住父（或子）节点与其他 widget 的关系。 Element 还保存了与 Stateful widget 相关联的 state 对象。

由于用户输入（或来自其他地方的响应），比如开发者在关联的 state 对象上调用了 setState() 方法，element 可能会变脏。框架维护了一个脏 element 列表，使得 构建 过程可跳过干净的 element，直接跳转到脏的 element。构建过程中，信息在 element 树中向下 单向 传递，这意味着该阶段中每个 element 最多会被访问一次。一个 element 一旦被清洗，它将不会再次变脏，这是因为通过归纳，它所有的祖先 element 也都是干净的 [^4]。

由于 widget 是不可变的，因此父节点使用相同的 widget 来重新构建 element，如果 element 没有将自己标记为脏，那么该 element 可立即从构建中返回，以切断构建的向下传递。另外，element 只需比较两个 widget 所引用的对象标识来确定新 widget 与旧 widget 是否相同。开发者可利用该优化实现投影模式，即 widget 包含了被存储为成员变量、在构建过程中预先构建的子 widget

构建过程中，Flutter 同时使用 Inheritedwidgets 来避免父链的遍历。如果 widget 经常遍历它们的父链，比如确定当前的主题颜色，那么构建阶段树的深底将变为 O(N²)，由于 Flutter 的积极可组合性，其数量可能非常巨大。为了避免这些父链的遍历，框架通过在每个 element 上维护一个 Inheritedwidget 哈希表来向下传递 element 树中的信息。通常情况下，多个 element 引用相同的哈希表，并且该表仅在 element 引入新的 Inheritedwidget 时改变。

线性协调

不同于传统做法，Flutter 没有使用树差异比较算法。相反，框架通过使用 O(N) 算法独立地检查每个 element 的子节点来决定是否重用该 element。子列表协调算法针对以下情况进行了优化：

• 旧的子列表为空。
• 两个列表完全相同。
• 在列表的某个位置插入或删除一个或多个 widget。
• 如果新旧列表都包含相同 key [^5] 的 widget，那么这两个 widget 就会被认为是相同的。

通常的做法是从新旧子列表的头部和尾部开始对每一个 widget 的运行时类型和 key 进行匹配，这样就可能找到在两个列表中间所有不匹配子节点的（非空）范围。然后框架将旧子列表中该范围内的子项根据它的 key 放入一个哈希表中。接下来，框架将会遍历新的子列表以寻找该范围内能够匹配哈希表中的 key 的子项。无法匹配的子项将会被丢弃并从头开始重建，匹配到的子项则使用它们新的 widget 进行重建。

树结构优化

重用 element 对性能非常重要，这是因为 element 拥有两份关键数据：Stateful widget 的状态对象及底层的渲染对象。当框架能够重用 element 时，用户界面的逻辑状态信息是不变的，并且可以重用之前计算的布局信息，这通常可以避免遍历整棵子树。事实上，重用 element 是非常有价值的，因为 Flutter 支持 全局 树更新，以此保留状态和布局信息。

开发者可通过将 GlobalKey 与其中一个 widget 相关联来实施全局树更新。每个全局 key 在整个应用中都是唯一的，并使用特定于线程的哈希表进行注册。在构建过程中，开发者可以使用全局 key 将 widget 移动到 element 树的任意位置。框架将不会在该位置上重新构建 element，而是检查哈希表并将现有的 element 从之前的位置移动到新的位置，从而保留整棵子树。

重新构建的子树中的渲染对象能够保留它们的布局信息，这是因为布局约束是渲染树从父节点传递到子节点的唯一信息。子列表发生变化后，父节点将会被标记为脏，但如果新的父节点传递给子节点的布局约束与该子节点从旧的父节点接收到的相同，那么子节点可立即从布局中返回，从而切断布局的向下传递。

开发者广泛使用全局 key 和全局树更新来实现 hero transition 及导航等效果。

恒定因子优化

除了上述算法优化，实现积极可组合还需依赖几个重要的恒定因子优化。这些优化对于上面所讨论的主要算法是非常重要的。

• 子模型无关。与大多数使用子列表的工具包不同， Flutter 渲染树不会记住一个特定的子模型。比如，类 RenderBox 存在一个抽象的 visitChildren() 方法，而非具体的 firstChild 和 nextSibling 接口。许多子类仅支持直接作为其成员变量的单个子项，而非子项列表。比如，由于 RenderPadding 仅支持单个子节点，因此它拥有一个更为简单、高效的布局方法。
• 视觉渲染树、widget 逻辑树。在 Flutter 中，渲染树在与设备无关的视觉坐标系中运行，这意味着即使 x 轴的读取方向是从右到左，其左侧的值依旧小于右侧。Widget 树通常在逻辑坐标中运行，这意味着拥有 开始 和 结束 值的视觉解释取决于读取方向。逻辑坐标到视觉坐标的转换是在 widget 树和渲染树之间的切换中完成的。这种方法更为高效的原因是，渲染树中的布局和绘制计算比 widget 到渲染树的切换更加频繁，并且可以避免重复的坐标转换。
• 通过专门的渲染对象处理文本。大多数渲染对象都不清楚文本的复杂性。相反，文本是由专门的渲染对象 RenderParagraph 进行处理，它是渲染树中的一个叶子节点。开发者使用组合形式将文本并入到用户界面中，而非使用文本感知渲染对象进行子类化。该模式意味着 RenderParagraph 可避免文本布局在父节点提供相同布局约束下的重复计算，这是非常常见的，即使在树优化期间也是如此。
• 可观察对象。 Flutter 使用模型观察及响应设计模式。显而易见，响应模式占主导地位，但 Flutter 在某些叶子节点的数据结构上使用了可观察对象。比如 Animation 会在值发生变化时通知观察者列表。 Flutter 将这些可观察对象从 widget 树转移到渲染树中，渲染树直接监听这些对象，并在它们改变时仅重绘管道的相关阶段。比如，更改 Animation<Color> 可能只触发绘制阶段，而非整个构建和绘制阶段。

总的来说，这些优化对通过积极组合方式产生的大型树结构的性能产生了重大影响。

元素和 RenderObject 树的分离

Flutter 中的RenderObject和Element（Widget）树是同构的（严格来说，RenderObject树是Element树的一个子集）。一个明显的简化是将这些树合并成一棵树。然而，在实践中，将这些树分开是有很多好处的：

• 性能 当布局发生变化时，只有布局树的相关部分需要被行走。由于组成的原因，元素树经常有许多额外的节点需要被跳过。

• 明确性 更清晰的关注点分离允许小部件协议和渲染对象协议各自针对其特定需求进行专业化，简化了 API 表面，从而降低了错误的风险和测试负担。

• 类型安全 呈现对象树可以更具有类型安全性，因为它可以在运行时保证子代将具有适当的类型（每个坐标系，例如，有自己的呈现对象类型）。组成部件可以不考虑布局时使用的坐标系（例如，同一个部件暴露了应用程序模型的一部分，可以在盒子布局和狭长布局中使用），因此在元素树中，验证呈现对象的类型需要在树上行走。

无限滚动

对于工具包来说，实现无限滚动列表是非常困难的。Flutter 支持基于 构造器 模式实现的简单无限滚动列表界面，其中 ListView 使用回调按需构建 widget，即它们只在滚动过程中才对用户可见。该功能需要 视窗感知布局 及 按需构建 widget 的支持。

视窗感知布局

同 Flutter 中的大多数东西一样，可滚动的 widget 是基于组合模式构建的。可滚动 widget 的外部是一个 Viewport，这是一个拥有更大内部空间的盒子，这意味着它的子节点可以超出视窗口的边界并滚动到可视区域中。但是，视窗口没有 RenderBox 子节点，而是拥有被称为 sliver，实现了视窗感知协议的RenderSliver 子节点。

sliver 布局协议中父节点向下传递给子节点的约束信息及接收到的几何信息的结构与盒子布局相同。但约束和几何数据在两个协议之间不同。在 sliver 协议中，子节点接收到的是关于视窗口的信息，这其中包含剩余的可见空间量。它们返回的几何数据支持各种滚动链接效果，包括可折叠标题及视差。

不同的 sliver 以不同的方式填充视窗口中的可用空间。比如，生成线性子列表的 sliver 按顺序排列每个子节点，直到 sliver 中无任何子节点或可用空间。同理，生成二维子节点网格的 sliver 仅填充网格中的可见区域。由于它们知道还有多大的可见空间，sliver 可以生成有限的子节点，即使它们可能生成无限的子节点。

可组合 sliver 来创建特定的滚动布局和效果。比如，单个视窗口可以有一个折叠标题、一个线性列表和一个网格。所有这些 sliver 将按照 sliver 布局协议进行协作，只生成那些在视窗口实际可见的子节点，而不管这些子节点是否属于标题、列表或网格[^6]。

按需构建 widget

如果 Flutter 拥有一个严格的从构建到布局，再到绘制的管道，那么前面的内容将不足以实现无限滚动列表，这是因为只有在布局阶段才能通过视窗口获取可用的空间信息。如果没有额外的机制，在布局阶段构建用于填充空间的 widget 已经太迟了。 Flutter 使用将管道的构建与布局交叉在一起的方式来解决这个问题。在布局阶段的任意时刻，只要这些 widget 是当前布局的渲染对象的子节点，框架就可以按需构建新的 widget。

只有严格控制构建及布局中消息传播的算法，才能实现构建和布局的交叉执行。也就是说，在构建过程中，消息只能沿构建树向下传递。当渲染对象进行布局时，布局遍历过程中并没有访问该渲染对象的子树，这意味通过子树构建的写入无法使到目前为止已进入布局计算过程的任何信息失效。无独有偶，一旦布局从渲染对象中返回，在当前布局过程中，该渲染对象将永远不会被再次访问，这意味后续布局计算生成的任何写入都不会使用于构建渲染对象的子树的信息失效。

此外，线性协调及树结构优化对于在滚动过程中有效更新 element，以及当 element 在视窗口边缘滚动进出视图期间修改渲染树至关重要。

人机工程 API

速度只有在框架能够被有效使用时才有意义。为了引导设计更高可用性的 Flutter API， Flutter 已经在与开发者进行的广泛用户体验研究中进行了反复测试。这些研究有时证实了已有的设计决策，有时有助于引导功能的优先级，有时会改变 API 的设计方向。比如，Flutter 的 API 文档很多，用户体验的研究不仅证实了这些文档的价值，也同时强调了示例代码及说明性图表的重要性。

本节将要讨论 Flutter API 设计中为提高可用性所做的一些决策。

与开发者思维模式相匹配的专项 API

Flutter 中 widget、Element 和 RenderObject 的基类节点不定义子类模型。该机制允许每个节点对适用于该节点的子模型进行定制化。

大多数 widget 对象都有一个子 widget 对象，因此它只暴露了一个 child 参数。一些 widget 支持任意数量的子节点，并暴露了一个获取子节点列表的 children 参数。有些 widget 无任何子节点、不保留内存且无任何参数。同样的，RenderObjects 暴露特定于子模型的 API。 RenderImage 是一个没有子节点的叶子节点。 RenderPadding 只持有一个子节点，因此它有一个指向单个子节点的指针存储空间。 RenderFlex 接受任意数量的子节点，并通过链表对其进行管理。

在一些罕见情况下，将使用更复杂的子类模型。渲染对象 RenderTable 的构造函数需要使用二维数组来存储子节点，所以该类暴露了用于控制行和列数量的 getter 及 setter 方法，还有一些可以用 x、y 轴坐标来替换单个子节点的特殊方法，可通过提供一个新的子节点数组来添加新行，并用单个数组及列的个数来替换整个子节点列表。该对象并不像大多数渲染对象那样使用链表，而是使用可索引数组来实现。

Chip widget 和 InputDecoration 对象具有与其控制中的插槽相匹配的字段。如果一个通用子模型将强制语义定义在子列表之上，比如将第一个子节点定义为前缀，第二个子节点定义为后缀，那么专用子模型允许使用特有的命名属性。

这种灵活性允许树中的每个子节点以其最常用的方式操作它的角色。很少有人想要在表格中插入一个单元格，从而导致其他所有单元格被环绕；同样的，很少有人想要通过索引而不是通过引用从 flex 行中删除子项。

RenderParagraph 对象是最极端的情况：它有一个完全不同类型的子节点，TextSpan。在 RenderParagraph 的边界，RenderObject 树会被转换为 TextSpan 树。

专门用于满足开发者期望的 API 的一切方法不仅适用于子模型。

专门存在一些琐碎的 widget，以便开发者在寻找问题解决方案时能够发现并使用它们。一旦知道如何使用 Expanded 和大小为零的 SizedBox 子部件，就可以轻松地为行或列添加空格，但你会发现这种模式是没有必要的，因为搜索 space 所找到的 Spacer，它是直接使用 Expanded 和 SizedBox 来达到同样的效果的。

同理，可以通过在构建过程中不包含 widget 子树来轻松隐藏 widget 子树。但开发者通常希望有一个 widget 来执行该操作，因此 Visibility 的存在便是将此模式封装在一个简单的可重用 widget 中。

明确的参数

UI 框架往往拥有大量的属性，因此很少有开发者能够记住每个类的每个构造函数参数的作用。由于 Flutter 使用响应式编程范式，因此在 Flutter 中，构建方法通常会对构造函数进行多次调用。通过利用 Dart 的命名参数，Flutter 中的 API 能够使这些构建方法保持清晰易懂。

该模式已被扩展到任何具有多个参数（尤其是具有 boolean 类型参数）的方法，因此独立的 true 或 false 值在方法调用中总是自我描述的。此外，为避免 API 中通常由双重否定所造成的困惑， boolean 类型的参数和属性始终以肯定的形式命名（比如，使用 enabled: true 而非 disabled: false）。

参数陷阱

在 Flutter 框架中被大量使用的一项技术是定义不存在错误条件的 API。这样可以避免考虑整个错误类别。

比如插值函数允许插值的一端或两端为空，而不是将其定义为错误：两个空值之间的插值永远为空，并且从空值或空值插值等效于对指定类型进行零模拟插值。这意味着不小心将 null 传递给插值函数的开发者不会遇到错误，而是会得到一个合理结果。

一个更加微妙的例子是 Flex 布局算法。该布局给予 flex 渲染对象的空间被它的子节点所划分。因此 flex 的大小应该是整个可用空间。在最初的设计中提供无限空间将导致失败：这意味着 flex 应该是无限大且无用的布局设置。然而，通过对 API 的改造，在为 flex 对象提供无限空间时，渲染对象会调整自身大小来满足所需子节点的大小，从而减少可能出现的错误次数。

该方法也可用于避免使用允许创建不符合逻辑的数据的构造函数。例如，PointerDownEvent 的构造函数不允许将 PointerEvent 的 down 属性设置为 false（这种情况是自相矛盾的）；相反，构造函数没有关于字段 down 的参数，且将值始终设置为 true。

一般情况下，该方法用于为输入域中的所有值定义有效的解释。最简单的例子是 Color 的构造函数。相对于接受四个整型参数（分别用于表示红色、绿色、蓝色和 alpha），其中任何一个都可能超出范围，它的默认构造函数仅接受一个整数值，并定义每位的含义（例如，低八位代表红色），以便任何输入都是有效的颜色值。

一个更复杂的例子是 paintImage() 函数。该函数需要 11 个参数，其中一些具有相当宽泛的输入域，但它们都经过精心设计且大部分都能够彼此相交，因此很少出现无效组合。

积极报告错误

并非所有的错误都能被设计出来。对于那些遗漏的错误，在 debug 版本中，Flutter 通常会尝试尽早捕获并立即报告。它使用了大量的断言，对构造函数参数进行了详细的完整性检查，并监视其生命周期，一旦检测到不一致，它们会立即引发异常。

这在某些情况下是极端情况：比如，在执行单元测试时，无论测试用例正在做什么，每个 RenderBox 子类都会主动地检查其内部大小调整方法是否满足内部大小调整契约。这有助于捕获可能无法执行的 API 错误。

当异常抛出时，它们会包含尽可能多的信息。 Flutter 中的一些错误会主动探测相关的堆栈跟踪信息，以确定实际错误最可能发生的位置。其他错误则通过相关树来确定坏数据的来源。最常见的错误包含详细说明（在某些情况下会包含避免错误的示例代码），或指向其他文档的链接。

响应式

可变的基于树结构的 API 受二元访问模式的影响：创建树的原始状态通常使用与后续更新完全不同的操作集。Flutter 的渲染层使用了这种范式，因为它是维护持久树的有效方法，是高效布局和绘制的关键所在。但这也意味着，与渲染层的直接交互是十分笨拙的，甚至极其容易出错。

Flutter 在 widget 层引入了一个使用响应式来操作底层渲染树的组合机制[^7]。该 API 通过将树的创建和更新步骤整合到一个单一的树结构描述（构建）中，从而将树操作抽象出来，这包括：每次系统状态更新之后，开发者用于描述用户界面的新配置；框架对于新配置所需要进行的一系列树更新计算。

插值

由于 Flutter 鼓励开发者描述与当前应用状态相匹配的界面配置，因此存在一种在这些配置之间执行隐式的动画机制。

例如，假设界面在状态 S1 由一个圆形组成，在状态 S2 时由一个正方形组成。如果没有动画机制，状态更改将导致不和谐的界面更改。隐式动画则允许界面在几个帧的时间里由圆形平滑地过渡到正方形。

每个可执行隐式动画的特性都包含一个 Stateful widget，它用于记录输入的当前值，并在输入值改变时开始执行动画序列，并在指定的持续时间内从当前值转换为新值。

这是使用不可变对象的 lerp（线性插值）函数来实现的。每个状态（这里为圆形和正方形）代表一个配置中包含恰当设置（比如颜色、笔划宽度等）且知道如何绘制自己的不可变对象。在动画绘制中间步骤时，开始和结束值连同表示动画中点的 t 值一并传递给 lerp函数。其中 0.0 代表开始 start，1.0 代表结束 end[^8]，并且该方法返回表示中间阶段的第三个不可变对象。

对于从圆形到正方形的转换，lerp 函数将返回一个圆角正方形对象，其半径被描述为从 t 值导出的分数，使用 lerp 函数进行插值计算的颜色，以及使用 lerp 函数进行双倍插值计算的笔划宽度。该对象与圆形、正方形一样具有相同的接口实现，并且可以在请求时进行自我绘制。

该技术允许状态机、状态到配置的映射、动画和插值机制以及与如何绘制每一桢完全分离的特定逻辑。

在 Flutter 中，该机制得到了广泛应用，无论是像 Color 和 Shape 这样的基本类型，还是像 Decoration，TextStyle 或 Theme 这样更为复杂的类型，都是可以进行插值处理的。它们通常是由可插入组件构成的，并且插入更复杂的对象通常就像递归插入描述复杂对象的所有值一样简单。

一些插值对象由类层次结构定义。比如，形状由 ShapeBorder 接口表示，并且存在多种形状类型，包括： BeveledRectangleBorder、BoxBorder、CircleBorder、RoundedRectangleBorder 和 StadiumBorder。单一的 lerp 函数并不能了解所有可能的类型信息，因此接口定义了 lerpFrom 和 lerpTo 方法以替代静态的 lerp 方法。当被告知从形状 A 切换到 B 时，将首选询问 B 是否 lerpFrom A，如其答案为否，则询问 A 是否可以 lerpTo B （如两者的答案均为否，如果 t 的值小于 0.5 则返回 A，否则返回 B）。

这允许类层次结构的任意扩展，后续新增的能够在先前已知值与它们之间进行插值处理。

在某些情况下，插值本身不能被任何可用的类描述，并且定义一个私有类来描述中间状态。比如在 CircleBorder 和 RoundedRectangleBorder 之间进行插值时就是如此。

该机制的另外一个优点是：它可以处理从中间态到新值的插值。比如，在圆形到正方形过渡的中途，形状可能再次改变，导致动画需要插值到一个三角形。只要该三角形类是 lerpFrom 圆形到正方形的中间类，就可以无缝进行转换。

结论

Flutter 一切都是 widget 的口号是围绕着通过组合 widget 来构建用户界面， widget 又由更为基础的 widget 构成。这种积极组合的结果是需要精心设计的算法和数据结构才能有效处理大量的 widget。通过一些额外的机制，这些数据结构还能使开发者轻松构建无限滚动列表，以便在 widget 可见时进行按需构建。

GitHub Actions 是什么？

Github Actions 是 Github 官方出的持续集成服务, 挺早之前就推出了。类似的还有如微软的DevOps、GitLab CI、Circle CI、Travis CI等等。大家知道，持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。

很多操作在不同项目里面是类似的，完全可以共享。GitHub 注意到了这一点，想出了一个很妙的点子，允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。

如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。

什么是CI/CD？

What is CI/CD? (redhat.com)

字面意思就是持续集成Continuous Intergation/持续分发Continuous Delivery持续部署Continuous Deployment，网上有太多同质的解释都太过于晦涩，

提到CI/CD就离不开一个词叫流水线。流水线上每个人的工作是分工明确的，而且工程是有先后顺序，就像造一台车，先造零件，然后组装、喷涂、内饰最后还要测试。软件开发同样如此，有前期的产品设计，UI设计、单元的开发，产品的测试，优化迭代等都由不同的人负责。

一说到 CSS 盒模型，这是很多小伙伴耳熟能详的知识，甚至有的小伙伴还能说出 border-box 和 content-box 这两种盒模型的区别。

但是一说到 CSS 包含块，有的小伙伴就懵圈了，什么是包含块？好像从来没有听说过这玩意儿。

好吧，如果你对包含块的知识一无所知，那么系好安全带，咱们准备出发了。

包含块英语全称为containing block，实际上平时你在书写 CSS 时，大多数情况下你是感受不到它的存在，因此你不知道这个知识点也是一件很正常的事情。但是这玩意儿是确确实实存在的，在 CSS 规范中也是明确书写了的：

https://drafts.csswg.org/css2/#containing-block-details

并且，如果你不了解它的运作机制，有时就会出现一些你认为的莫名其妙的现象。

那么，这个包含块究竟说了什么内容呢？

说起来也简单，就是元素的尺寸和位置，会受它的包含块所影响。对于一些属性，例如 width, height, padding, margin，绝对定位元素的偏移值（比如 position 被设置为 absolute 或 fixed），当我们对其赋予百分比值时，这些值的计算值，就是通过元素的包含块计算得来。

来吧，少年，让我们从最简单的 case 开始看。

<body>
  <div class="container">
    <div class="item"></div>
  </div>
</body>

.container{
  width: 500px;
  height: 300px;
  background-color: skyblue;
}
.item{
  width: 50%;
  height: 50%;
  background-color: red;
}

请仔细阅读上面的代码，然后你认为 div.item 这个盒子的宽高是多少？

相信你能够很自信的回答这个简单的问题，div.item 盒子的 width 为 250px，height 为 150px。

这个答案确实是没有问题的，但是如果我追问你是怎么得到这个答案的，我猜不了解包含块的你大概率会说，因为它的父元素 div.container 的 width 为 500px，50% 就是 250px，height 为 300px，因此 50% 就是 150px。

这个答案实际上是不准确的。正确的答案应该是，div.item 的宽高是根据它的包含块来计算的，而这里包含块的大小，正是这个元素最近的祖先块元素的内容区。

因此正如我前面所说，很多时候你都感受不到包含块的存在。

包含块分为两种，一种是根元素（HTML 元素）所在的包含块，被称之为初始包含块（initial containing block）。对于浏览器而言，初始包含块的的大小等于视口 viewport 的大小，基点在画布的原点（视口左上角）。它是作为元素绝对定位和固定定位的参照物。

另外一种是对于非根元素，对于非根元素的包含块判定就有几种不同的情况了。大致可以分为如下几种：

• 如果元素的 positiion 是 relative 或 static ，那么包含块由离它最近的块容器（block container）的内容区域（content area）的边缘建立。
• 如果 position 属性是 fixed，那么包含块由视口建立。
• 如果元素使用了 absolute 定位，则包含块由它的最近的 position 的值不是 static （也就是值为fixed、absolute、relative 或 sticky）的祖先元素的内边距区的边缘组成。

前面两条实际上都还比较好理解，第三条往往是初学者容易比较忽视的，我们来看一个示例：

<body>
    <div class="container">
      <div class="item">
        <div class="item2"></div>
      </div>
    </div>
  </body>

.container {
  width: 500px;
  height: 300px;
  background-color: skyblue;
  position: relative;
}
.item {
  width: 300px;
  height: 150px;
  border: 5px solid;
  margin-left: 100px;
}
.item2 {
  width: 100px;
  height: 100px;
  background-color: red;
  position: absolute;
  left: 10px;
  top: 10px;
}

首先阅读上面的代码，然后你能在脑海里面想出其大致的样子么？或者用笔和纸画一下也行。

公布正确答案：

怎么样？有没有和你所想象的对上？

其实原因也非常简单，根据上面的第三条规则，对于 div.item2 来讲，它的包含块应该是 div.container，而非 div.item。

如果你能把上面非根元素的包含块判定规则掌握，那么关于包含块的知识你就已经掌握 80% 了。

实际上对于非根元素来讲，包含块还有一种可能，那就是如果 position 属性是 absolute 或 fixed，包含块也可能是由满足以下条件的最近父级元素的内边距区的边缘组成的：

• transform 或 perspective 的值不是 none
• will-change 的值是 transform 或 perspective
• filter 的值不是 none 或 will-change 的值是 filter(只在 Firefox 下生效).
• contain 的值是 paint (例如: contain: paint;)

我们还是来看一个示例：

<body>
  <div class="container">
    <div class="item">
      <div class="item2"></div>
    </div>
  </div>
</body>

.container {
  width: 500px;
  height: 300px;
  background-color: skyblue;
  position: relative;
}
.item {
  width: 300px;
  height: 150px;
  border: 5px solid;
  margin-left: 100px;
  transform: rotate(0deg); /* 新增代码 */
}
.item2 {
  width: 100px;
  height: 100px;
  background-color: red;
  position: absolute;
  left: 10px;
  top: 10px;
}

我们对于上面的代码只新增了一条声明，那就是 transform: rotate(0deg)，此时的渲染效果却发生了改变，如下图所示：

可以看到，此时对于 div.item2 来讲，包含块就变成了 div.item。

好了，到这里，关于包含块的知识就基本讲完了。

我们再把 CSS 规范中所举的例子来看一下。

<html>
  <head>
    <title>Illustration of containing blocks</title>
  </head>
  <body id="body">
    <div id="div1">
      <p id="p1">This is text in the first paragraph...</p>
      <p id="p2">
        This is text
        <em id="em1">
          in the
          <strong id="strong1">second</strong>
          paragraph.
        </em>
      </p>
    </div>
  </body>
</html>

上面是一段简单的 HTML 代码，在没有添加任何 CSS 代码的情况下，你能说出各自的包含块么？

对应的结果如下：

| 元素 | 包含块 |
|