事件委托基本概念

事件委托，就是一个元素的响应事件的函数委托给另一个元素

一般我们都是把函数绑定给当前元素的父元素或更外层元素，当事件响应到需要绑定的元素的时候，会通过事件冒泡机制（或事件捕获）去触发外层元素的绑定事件，在外层元素上去执行函数

在了解事件委托之前，我们可以先了解事件流，事件冒泡以及事件捕获

事件流：捕获阶段，目标阶段，冒泡阶段

DOM事件流有3个阶段：捕获阶段，目标阶段，冒泡阶段；

三个阶段的顺序为：捕获阶段——目标阶段——冒泡阶段

事件冒泡

事件的触发响应会从最底层目标一层层地向外到最外层（根节点）

比如说我现在有一个盒子f，里面有个子元素s

  <div class="f">
        <div class="s"></div>
  </div>

添加事件

var f = document.querySelector('.f')
var s = document.querySelector('.s')
f.addEventListener('click',()=>{
    console.log('fffff');
})
s.addEventListener('click',()=>{
    console.log('sssss');
})

当我点击子元素的时候

冒泡顺序 s -> f

事件捕获

事件响应从最外层的Window开始，逐级向内层前进，直到具体事件目标元素。在捕获阶段，不会处理响应元素注册的冒泡事件

继续使用上一个例子，只需要将addEventListener第三个参数改为true即可

添加事件

var f = document.querySelector('.f')
var s = document.querySelector('.s')
f.addEventListener('click',()=>{
    console.log('fffff');
},true)
s.addEventListener('click',()=>{
    console.log('sssss');
},true)

点击子元素

捕获顺序 f -> s

这里我们可以思考一下，如果同时绑定了冒泡和捕获事件的话，会有怎样的执行顺序呢？

例子不变，稍微改一下js代码

var f = document.querySelector('.f')
var s = document.querySelector('.s')
f.addEventListener('click',()=>{
    console.log('f捕获');
},true)
s.addEventListener('click',()=>{
    console.log('s捕获');
},true)
f.addEventListener('click',()=>{
    console.log('f冒泡');
})
s.addEventListener('click',()=>{
    console.log('s冒泡');
})

此时点击子元素

执行顺序： f捕获->s捕获->s冒泡—>f冒泡

得出结论：当我们同时绑定捕获和冒泡事件的时候，会先从外层开始捕获到目标元素，然后由目标元素冒泡到外层

回到事件委托

了解了事件捕获和事件冒泡，再来看事件委托就很好理解了

强调一遍，事件委托把函数绑定给当前元素的父元素或更外层元素，当事件响应到需要绑定的元素的时候，会通过事件冒泡机制（或事件捕获）去触发外层元素的绑定事件，在外层元素上去执行函数

新开一个例子

<ul class="list">
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
</ul>

现在我们有一个列表，当我们点击列表中的某一项时可以触发对应事件，如果我们给列表的每一项都添加事件，对于内存消耗是非常大的，效率上需要消耗很多性能

这个时候我们就可以把这个点击事件绑定到他的父层，也就是 ul 上，然后在执行事件的时候再去匹配判断目标元素；

var list = document.querySelector('.list')
// 利用冒泡机制实现
list.addEventListener('click',(e)=>{
   e.target.style.backgroundColor='blue'
})
// 利用捕获机制实现
list.addEventListener('click',(e)=>{
   e.target.style.backgroundColor='red'
},true)

当我点击其中一个子元素的时候

总结

• 事件委托就是根据事件冒泡或事件捕获的机制来实现的

• 事件冒泡就是事件的触发响应会从最底层目标一层层地向外到最外层（根节点）

• 事件捕获就是事件响应从最外层的Window开始，逐级向内层前进，直到具体事件目标元素。在捕获阶段，不会处理响应元素注册的冒泡事件

补充：

对于目标元素，捕获和冒泡的执行顺序是由绑定事件的执行顺序决定的

作者：张宏都
来源：https://juejin.cn/post/7100468737647575048

一、 拦截器介绍

一般在使用axios时，会用到拦截器的功能，一般分为两种：请求拦截器、响应拦截器。

1. 请求拦截器
   在请求发送前进行必要操作处理，例如添加统一cookie、请求体加验证、设置请求头等，相当于是对每个接口里相同操作的一个封装；

2. 响应拦截器
   同理，响应拦截器也是如此功能，只是在请求得到响应之后，对响应体的一些处理，通常是数据统一处理等，也常来判断登录失效等。

二、 Axios实例

1. 创建axios实例

// 引入axios
import axios from 'axios'

// 创建实例
let instance = axios.create({
    baseURL: 'xxxxxxxxxx',
    timeout: 15000  // 毫秒
})

1. baseURL设置：

let baseURL;
if(process.env.NODE_ENV === 'development') {
    baseURL = 'xxx本地环境xxx';
} else if(process.env.NODE_ENV === 'production') {
    baseURL = 'xxx生产环境xxx';
}

// 实例
let instance = axios.create({
    baseURL: baseURL,
    ...
})

1. 修改实例配置的三种方式

// 第一种：局限性比较大
axios.defaults.timeout = 1000;
axios.defaults.baseURL = 'xxxxx';

// 第二种：实例配置
let instance = axios.create({
    baseURL: 'xxxxx',
    timeout: 1000,  // 超时，401
})
// 创建完后修改
instance.defaults.timeout = 3000

// 第三种：发起请求时修改配置、
instance.get('/xxx',{
    timeout: 5000
})

这三种修改配置方法的优先级如下：请求配置 > 实例配置 > 全局配置

三、 配置拦截器

// 请求拦截器
instance.interceptors.request.use(req=>{}, err=>{});
// 响应拦截器
instance.interceptors.reponse.use(req=>{}, err=>{});

1. 请求拦截器

// use(两个参数)
axios.interceptors.request.use(req => {
    // 在发送请求前要做的事儿
    ...
    return req
}, err => {
    // 在请求错误时要做的事儿
    ...
    // 该返回的数据则是axios.catch(err)中接收的数据
    return Promise.reject(err)
})

1. 响应拦截器

// use(两个参数)
axios.interceptors.reponse.use(res => {
    // 请求成功对响应数据做处理
    ...
    // 该返回的数据则是axios.then(res)中接收的数据
    return res
}, err => {
    // 在请求错误时要做的事儿
    ...
    // 该返回的数据则是axios.catch(err)中接收的数据
    return Promise.reject(err)
})

1. 常见错误码处理(error)
   axios请求错误时，可在catch里进行错误处理。

axios.get().then().catch(err => {
    // 错误处理
})

四、 axios请求拦截器的案例

// 设置请求拦截器
axios.interceptors.request.use(
  config => {
    // console.log(config) // 该处可以将config打印出来看一下，该部分将发送给后端（server端）
    config.headers.Authorization = store.state.token
    return config // 对config处理完后返回，下一步将向后端发送请求
  },
  error => { // 当发生错误时，执行该部分代码
    // console.log(error) // 调试用
    return Promise.reject(error)
  }
)

// 定义响应拦截器 -->token值无效时,清空token,并强制跳转登录页
axios.interceptors.response.use(function (response) {
  // 响应状态码为 2xx 时触发成功的回调，形参中的 response 是“成功的结果”
  return response
}, function (error) {
  // console.log(error)
  // 响应状态码不是 2xx 时触发失败的回调，形参中的 error 是“失败的结果”
  if (error.response.status === 401) {
    // 无效的 token
    // 把 Vuex 中的 token 重置为空，并跳转到登录页面
    // 1.清空token
    store.commit('updateToken', '')
    // 2.跳转登录页
    router.push('/login')
  }
  return Promise.reject(error)
})

作者：我彦祖不会秃
来源：https://juejin.cn/post/7100470316857557006

一、事件循环是什么

首先，JavaScript是一门单线程的语言，意味着同一时间内只能做一件事，但是这并不意味着单线程就是阻塞，而实现单线程非阻塞的方法就是事件循环

在JavaScript中，所有的任务都可以分为

• 同步任务：立即执行的任务，同步任务一般会直接进入到主线程中执行

• 异步任务：异步执行的任务，比如ajax网络请求，setTimeout定时函数等

同步任务与异步任务的运行流程图如下：

从上面我们可以看到，同步任务进入主线程，即主执行栈，异步任务进入任务队列，主线程内的任务执行完毕为空，会去任务队列读取对应的任务，推入主线程执行。上述过程的不断重复就事件循环

二、宏任务与微任务

如果将任务划分为同步任务和异步任务并不是那么的准确，举个例子：

console.log(1)

setTimeout(()=>{
    console.log(2)
}, 0)

new Promise((resolve, reject)=>{
    console.log('new Promise')
    resolve()
}).then(()=>{
    console.log('then')
})

console.log(3)

最终结果： 1=>'new Promise'=> 3 => 'then' => 2

微任务

一个需要异步执行的函数，执行时机是在主函数执行结束之后、当前宏任务结束之前

常见的微任务有：

• Promise.then

• MutaionObserver

• Object.observe（已废弃；Proxy 对象替代）

• process.nextTick（Node.js）

宏任务

宏任务的时间粒度比较大，执行的时间间隔是不能精确控制的，对一些高实时性的需求就不太符合

常见的宏任务有：

• script (可以理解为外层同步代码)

• setTimeout/setInterval

• UI rendering/UI事件

• postMessage、MessageChannel

• setImmediate、I/O（Node.js）

这时候，事件循环，宏任务，微任务的关系如图所示

• 执行一个宏任务，如果遇到微任务就将它放到微任务的事件队列中

• 当前宏任务执行完成后，会查看微任务的事件队列，然后将里面的所有微任务依次执行完

回到上面的题目

console.log(1)
setTimeout(()=>{
    console.log(2)
}, 0)
new Promise((resolve, reject)=>{
    console.log('new Promise')
    resolve()
}).then(()=>{
    console.log('then')
})
console.log(3)

最终结果： 1=>'new Promise'=> 3 => 'then' => 2

// 遇到 console.log(1) ，直接打印 1
// 遇到定时器，属于新的宏任务，留着后面执行
// 遇到 new Promise，这个是直接执行的，打印 'new Promise'
// .then 属于微任务，放入微任务队列，后面再执行
// 遇到 console.log(3) 直接打印 3
// 好了本轮宏任务执行完毕，现在去微任务列表查看是否有微任务，发现 .then 的回调，执行它，打印 'then'
// 当一次宏任务执行完，再去执行新的宏任务，这里就剩一个定时器的宏任务了，执行它，打印 2

三、async与await

async 是异步的意思，await则可以理解为 async wait。所以可以理解async就是用来声明一个异步方法，而 await是用来等待异步方法执行

async

async函数返回一个promise对象，下面两种方法是等效的

function f() {
    return Promise.resolve('TEST');
}

// asyncF is equivalent to f!
async function asyncF() {
    return 'TEST';
}

await

正常情况下，await命令后面是一个 Promise对象，返回该对象的结果。如果不是 Promise对象，就直接返回对应的值

async function f(){
    // 等同于
    // return 123
    return await 123
}
f().then(v => console.log(v)) // 123

不管await后面跟着的是什么，await都会阻塞后面的代码

async function fn1 (){
    console.log(1)
    await fn2()
    console.log(2) // 阻塞
}

async function fn2 (){
    console.log('fn2')
}

fn1()
console.log(3)

上面的例子中，await 会阻塞下面的代码（即加入微任务队列），先执行 async外面的同步代码，同步代码执行完，再回到 async 函数中，再执行之前阻塞的代码

所以上述输出结果为：1，fn2，3，2

四、流程分析

通过对上面的了解，我们对JavaScript对各种场景的执行顺序有了大致的了解

这里直接上代码：

async function async1() {
    console.log('async1 start')
    await async2()
    console.log('async1 end')
}
async function async2() {
    console.log('async2')
}
console.log('script start')
setTimeout(function () {
    console.log('settimeout')
})
async1()
new Promise(function (resolve) {
    console.log('promise1')
    resolve()
}).then(function () {
    console.log('promise2')
})
console.log('script end')

分析过程：

执行整段代码，遇到 console.log('script start') 直接打印结果，输出 script start
遇到定时器了，它是宏任务，先放着不执行
遇到 async1()，执行 async1 函数，先打印 async1 start，下面遇到await怎么办？先执行 async2，打印 async2，然后阻塞下面代码（即加入微任务列表），跳出去执行同步代码
跳到 new Promise 这里，直接执行，打印 promise1，下面遇到 .then()，它是微任务，放到微任务列表等待执行
最后一行直接打印 script end，现在同步代码执行完了，开始执行微任务，即 await下面的代码，打印 async1 end
继续执行下一个微任务，即执行 then 的回调，打印 promise2
上一个宏任务所有事都做完了，开始下一个宏任务，就是定时器，打印 settimeout
所以最后的结果是：script start、async1 start、async2、promise1、script end、async1 end、promise2、settimeout

作者：用户8249803991033
来源：https://juejin.cn/post/7100468871752056868

如果程序人生的话，这条路太漫长

我并非天生喜欢写程序，上高中时也没有想过程序员的生活。

我学电脑非常偶然，小时好友上大学时选择了计算机系，为了和这个朋友有更多的共同语言，我也选择了计算机系，开始步入程序人生的道路。

当我学会一些后，发现自己特别喜欢写程序。我是八七年上的武汉大学计算机系，大一下学期才有专业课。当我有资格上机的时候，发现电脑世界太美妙，就一头扎进去。

当时用的是 Motorola 68000 (相当 于 Intel 8088), 540K 的内存，运行的 UNIX 操作系统，八个人一起用。

大二学PC，又过了一学期，开始出现在老师的实验室，帮忙干活，当时就写了现在很多人用的 RI （RAMinit, 清内存的小工具, 看来我还是最早一批写 Shareware 的人)。

又过了一个学期，开始和校外的公司接触。大二暑假，也就是1989年8月，和一个朋友组建了 Yellow Rose 软件小组，写了我第一个商品软件 BITLOK 0.99。后来自己创业办过公司，也写过一些其他的软件。

大学毕业后，分到研究所，不太适应那里的气氛，就在1992年初加入金山软件，开始了职业程序员的生涯。后来成了金山软件研发部门的主管，但我一直都是一线的程序员。

程序员活在自己想象的王国里

我刚接触电脑就发现电脑的妙处，电脑远没有人那么复杂。如果你的程序写得好，你就可以和电脑处好关系，就可以指挥电脑干你想干的事。

这个时候你是十足的主宰。每每你坐在电脑面前，你就是在你的王国里巡行，这样的日子简直就是天堂般的日子。

电脑里的世界很大，编程人是活在自己想象的王国里。你可以想象到电脑里细微到每一个字节、每一个比特的东西。

我爱编程这个工作，可以肯定我会干上一辈子

不少人认为程序员最多干到三十五岁就可以收山换环境了，脑子也差不多该歇歇了，体力也不支了。并认为写程序是年轻人的事情，到了一定岁数，估计没什么人再当程序员了。

当我刚有一点本事的时候，我也和大家一样觉得编程辛苦，也想三十岁后干别的。当我年长一点后就发现了自己的无知。

一个人大学毕业就二十一二岁，有点水平的时候可能二十五，接着就是过日子诸多事情。一切搞掂的时候，也许就是三十五岁。如果这样的话，我们就不用选择程序人生的道路。

电脑进入中国时间并不短，但真正大规模开始用，还是八五年 PC 开始的，因此国内真正写电脑程序的人最长也就写了十几年（不知道是否还有这样的人）。

由于电脑应用在国内时间比较短，国内开发的主力是三十五岁以下的年轻人为主。但这不表示程序员如同红粉佳人般的容易衰老。美国主力工程师以三十四十多岁的人为主。

开始的时候，我们觉得我们没有什么不能做的（现在还能听到这样的豪言壮语），而且更要命的是好象我们特别聪明，特别适合开发软件，比老外强得多。

当我们真正接触那些杰出的开发人员的时候，发现他们太厉害了，都有十多年的开发经验。虽然也有很多年轻人做了很多好东西，但决大多数的产品出自这些有丰富开发经验的程序员的手。

刚毕业的时候，编程不仅仅是爱好，而且也成了一辈子的工作。整天不知道写些什么东西，觉得特别没劲，找不到感觉，特别灰心。

后来，才明白，只有全身心地投入，程序才会有感觉。

写程序的活特别费脑子，也特别累，但我喜欢，可以肯定我会干上一辈子，虽然我没有打算一生只干这一件事。用一生来编程序是一件既容易又困难的事。

如果碌碌无为，为交差写点程序，这样的日子太好混了。但如果想全身心地写程序，写十年就不是一件容易的事。

现在我不少朋友都洗手了，有时我也想“用什么电脑呀，Windows 外的世界不是也很大吗？”。

面对电脑的时候，立刻顿悟：写程序还是自己最擅长的事，也是最喜欢的事。

高级程序员不是追求的目标

有的人学习编程技术，是把高级程序员做为追求的目标，甚至是终身的奋斗目标。后来参与了真正的商品化软件开发后，反而困惑了，茫然了。

一个人只要有韧性和灵性，有机会接触并学习电脑的编程技术，就会成为一个不错的程序员。刚开始写程序，这时候学得多的人写的好，到了后来，大家都上了一个层次，谁写的好只取决于这个人是否细心、有韧性、有灵性。掌握多一点或少一点，很快就能补上。

成为一个高级程序员并不是件困难的事。

当我上学的时候，高级程序员也曾是我的目标，我希望我的技术能得到别人的承认。后来发现无论多么高级的程序员都没用，关键是你是否能够出想法出产品，你的劳动是否能被社会承认，能为社会创造财富。成为高级程序员绝对不是追求的目标。

编程不仅仅是技术，还是艺术

有人认为编程是一种熟练工种，也有人把编程说成是艺术创作。这两种意见争论比较激烈。

我们换个工种来看，石匠应该是熟练工种，属于工人，更和艺术似乎沾不上边。但正是这些石匠，给我们留下多少文物古迹，如乐山大佛、莫高窟等等。应该说这些石匠给我们留下了无穷的文化财产。

现代软件工业已具相当规模，很多软件的完成需要的是大兵团作战。一名普通程序员接受编写某一模块的任务后，往往只是写代码，发挥的余地很小。

在大项目中，很多程序员只能了解到和自己所编模块相关的很局部的细节，另外还受到开发环境的限制，真的很难体会到自己在从事”艺术”创造，更多的时候是感到自己在从事重体力劳动。

有的时候还担心自己苦苦参与的这个项目究竟有没有意义，是不是在同类产品中有竞争力，会不会开发出来以后就因为硬件的发展，操作系统的换代而过时……

我认为编程的工作和石匠比较相似，有技术活，更多的是体力活。不管怎么说，写出一个好软件不是一件容易的事。

这两种想法都有片面性，编程应该说两种属性都有。编程不仅仅是技术，也还是艺术。编程是技术活，才有可能大规模进行，才会有软件工程和软件工厂。也正是编程是艺术，才会有如此多的好产品，让大家如痴如醉。

著名程序编程指北点评表示，雷总是中国最早的一批程序员，极具极客精神。他把写程序当作一生的追求，完全没有去考虑程序员是吃青春饭的问题，全身心的投入到代码王国。

在他眼里编程不仅仅是谋生的一个技能，更是一种艺术。这也许就是极客程序员和普通程序员的区别吧。

希望诸君共勉，未来能在核心工业软件摆脱美国制裁上贡献属于自己的一行代码！

来源：雷军的博客 blog.sina.com.cn/leijun

随着APICloud移动低代码开发能力的持续演进，基于APICloud Studio3的可视化开发工具呼之欲出，在平台产品能力跨越式升级中，丰富的可视化开发组件将帮助用户进一步提升应用构建效率，并能够自动生成专业级源代码。

值此六一与端午双节来临之际，APICloud特别推出“寻忆·超龄少年团”AVM组件心愿征集活动，通过环环相扣的活动任务，帮助开发者进一步熟悉可视化开发工具，丰富AVM组件生态，同时更有现金、实物、积分等丰厚奖励。

 活动时间

即日起至6月30日

 活动入口

https://www.apicloud.com/activity2205

 （请PC端访问）

活动玩法

玩法一：AVM组件心愿悬赏

活动期间内，按照组件规范，提交上架AVM组件，即可赢取奖金，所有提交上架组件均需符合最新版APICloud平台AVM组件开发规范，不符合开发规范的组件将会被拒绝上架。【我要报名开发AVM组件】

玩法二：童年寻忆·龙舟争夺战

活动期间通过寻忆任务获得记忆卡片，通过开启童年记忆卡累积的龙舟划行距离进行排行评奖(彩蛋奖每个账号仅可获得1次)。

寻忆任务：

每个成功上架的AVM组件可获得5张记忆卡片；

每日签到可获得5张记忆卡片；

参加YonMaster认证考试并且通过，可获得25张记忆卡片；

更新登录新版APICloud Studio 3，且体验拖拽式工具，可获得10张记忆卡片。

童年记忆卡：

典藏记忆卡可使龙舟划行300米，附赠300积分；

普通记忆卡可使龙舟划行100米，附赠100积分；

寻到相同记忆卡，龙舟向前划行50米，附赠50积分；

积分逢66或6，可使龙舟滑行66或6米。

活动奖品

AVM组件心愿悬赏

普通组件：每个200元；
心愿组件：每个400元，上架数量达到10个，每个600元，最高可得30000元；
伙伴组件：结合伙伴模块开发AVM组件可参与平分奖金，以及另外加奖。

发奖说明

积分奖励将自动发放到账户当中，请关注积分明细；
实物与现金奖励（含税）请开发者在7月10日前扫码联系活动落地页微信客服，提交收货信息进行兑奖；

未及时兑奖将视为放弃领奖，奖品预计在2022年7月30日前完成发放。

本文和您讨论了SDLC的6个典型阶段、以及6个常用开发模型，并给出如何根据不同的项目特征，选择这些开发方法的建议。

译者 | 陈峻

审校 | 孙淑娟

软件开发生命周期(Software Development Life Cycle，SDLC)包含了软件从开始到发布的不同阶段。它定义了一种用于提高待开发软件质量和效率的过程。因此，SDLC旨在通过最少的资源，交付出高质量的软件。为了避免产生严重项目失败后果，软件开发的生命周期通常可以被划分为如下六个阶段：

• 需求收集

• 设计

• 软件开发

• 测试和质量保证

• 部署

• 维护

值得注意的是，这些阶段并非是静态的，它们可以进一步地被分解成多个子类别，以适应独特的开发需求与流程。

图 1 软件开发生命周期

需求收集

这是整个周期中其他阶段的基础。在此阶段，所有利益相关者(包括客户、产品负责人等)都会去收集与待开发软件相关的信息。对此，项目经理和相关方会频繁召开会议。尽管此过程可能比较耗时，但是我们不可急于求成，毕竟大家需要对将要开发的产品有个清晰的了解。

利益相关方需要将收集到的所有信息，记录到软件需求规范(Software Requirement Specification，SRS)文档中。在完成了需求收集后，开发团队需要进行可行性研究，以确定项目是否能够被完成。

设计

此阶段旨在模拟软件应用的工作方式，并设计出软件蓝图。负责软件高级设计的开发人员将组成设计团队，并通过由上个阶段产生的SRS文档，来指导设计过程，并最终完成满足要求的体系结构。此处的高级设计是指包括用户界面、用户流程、通信设计等方面在内的基础要素。

软件开发

在此阶段，具有不同专业知识(例如前端和后端)的开发人员或工程师，会通过处理设计的需求，来构建和实现软件。这既能够由一个人，也可以由一个大型团队来执行，具体取决于项目的规模。

后端开发人员负责构建数据库结构和其他必要组件。最后，由前端开发人员根据设计去构建用户界面，并按需与后端进行对接。

在配套文档方面，用户指南会被创建，源代码中也应适当地留下相应的注释。也就是说，为了保证良好的代码质量，适当的开发指南和政策也是必不可少的。

测试

专门的测试人员协同开发团队在此阶段开展测试工作。测试既可以与开发同时进行，也可以在开发阶段结束时再开展。通常，开发人员在开发软件时就会进行单元测试，以便检查每个源代码单元是否能够按照预期工作。同时，此阶段也包括如下其他测试：

• 系统测试--通过测试系统，以验证其是否满足所有指定的需求。

• 集成测试--将各个模块组合到一起进行测试。测试团队通过单击按钮，并执行滚动和滑动操作，来与软件交互。当然，他们并不需要了解后端的工作原理。

• 用户验收测试--是在启动软件之前，邀请潜在用户或客户进行的最终测试。此类测试可以验证目标软件，是否能够根据需求的规范，处理各种真实的场景。

测试对于软件开发生命周期是至关重要的。倘若无法以正确的方式开展，则会让软件项目团队反复在开发和测试阶段之间徘徊，进而影响到成本和时间。

部署

完成测试后，我们就需要通过部署软件，来方便用户使用了。在此阶段，部署团队需要通过遵循若干流程，来确保部署流程的成功。无论是简单的流程，还是复杂的部署，都会涉及到创建诸如安装指南、系统用户指南等相关部署文档。

维护

作为开发周期的最后阶段，维护涉及到报告并修复在测试期间未能发现的错误。在修复方式上，我们既能够采取立即纠正错误的方式，也可以将其作为常规性的软件更新。

此外，软件项目团队还会在此阶段从用户处收集反馈，以协助软件的改进，并提高用户的软件使用体验。

SDLC方法

虽然SDLC通常都会遵从上述步骤，但是它们在实现方式上略有不同。下面，我将介绍排名靠前的6种SDLC方法：

• 瀑布

• 敏捷

• 精益

• 迭代

• 螺旋

• DevOps方法

瀑布方法

图 2 瀑布方法

作为最古老、也是最直接的SDLC方法，瀑布方法遵循的是线性执行顺序。如上图所示，从需求收集到维护，逐步依次推进，且不存在任何逆转或倒退的步骤。也就是说，只有当上一步完成后，才能继续下一步。

由于在设计阶段之后，该方法不存在任何变化或调整的余地，因此，我们需要在需求收集阶段，收集到有关项目的所有信息，即制作软件蓝图。可见，对于经验不足的开发团队而言，如果能够保证软件的需求从项目开始就精确且稳定的话，便可以采用瀑布方法。也就是说，瀑布模型的成功，在很大程度上取决于需求收集阶段的输出是否清晰。当然，它也比较适合那些耗时较长的项目。

瀑布的优势

• 需求在初始阶段就能够被精心设计。

• 具有容易理解的线性结构。

• 易于管理。

瀑布的缺点

• 既不灵活，又不支持变更。

• 任何阶段一旦出现延迟，都会导致项目无法推进。

• 由于较为死板，因此项目总体时间较长。

• 并不鼓励在初始阶段之后，利益相关者进行积极地沟通。

敏捷方法

图 3 敏捷方法生命周期

敏捷(Agile)即为快速轻松的移动能力。以沟通和灵活性为中心的敏捷原则与方法，提倡以更短的周期和增量式地进行部署与发布。

在敏捷开发的生命周期中，每个阶段都有一个“仪式(ceremony)”，以便从开发团队和参与项目的其他利益相关者处获取反馈。其中包括：冲刺(sprint)计划、每日scrum、冲刺评审、以及冲刺回顾。

总地说来，敏捷开发是在各个“冲刺”中进行的，每个冲刺通常持续大约2到4周。每个冲刺的目标不一定是构建MVP(最小可行产品，Minimum Viable Product)，而是构建可供客户使用的软件的一小部分。其交付出来的可能只是某个功能，而非具有完全功能的产品。也就是说，交付成果可能只是一个将来能够被慢慢增加的功能性服务，而不一定是MVP。

图 4 构建最小可行产品的示例

在每个冲刺结束后的冲刺审查阶段，如果利益相关者对开发的功能感到满意的话，方可开展下一轮冲刺。虽然新的功能是在冲刺中被开发的，但是整个项目期间的冲刺数量并不受限。它往往取决于项目和团队的规模。因此，敏捷方法最适用于那些从一开始就无法明确所有要求的项目。

敏捷的优势

• 适合不断变化的需求。

• 鼓励利益相关者之间的反馈和持续沟通。

• 由于采用了增量式方法，因此更易于管理各种潜在风险。

敏捷的缺点

• 最少量的文档。

• 需要具有高技能的资源。

• 如果沟通低效，则可能拖慢项目的速度。

• 如果过度依赖客户的互动，则可能会导致项目走向错误的方向。

精益方法

软件开发领域的精益方法源于精益制造的原则。这种方法旨在减少生产过程中的浪费和成本，从而实现利润的最大化。该方法虽与敏捷开发类似，但是侧重于效率、快速交付、以及迭代式开发。而区别在于，敏捷方法更专注于持续沟通和协作，以体现价值;而精益方法更专注于消除浪费，以创造客户价值。

精益方法的七个核心概念：

• 消除浪费--鼓励开发团队尽可能多地消除浪费。这种方法在某种程度上并不鼓励多任务处理。这意味着它只需要完成“份内”的处理工作，并通过节省构建所谓“锦上添花”的功能，来节省时间。同时在所有开发阶段都避免了不必要的文档和会议。

• 鼓励学习--通过鼓励创建一个有利于所有相关成员学习的环境，来促进团队对软件开发过程予以反馈。

• 推迟决定--在做出决定之前，应仔细考虑各种事实。

• 尽快交付--由于交付是基于时间的，因此它会专注于满足交付期限的增量式交付，而非大礼包式的发布。

• 团队授权--它避开了针对团队的微观管理，而是鼓励大家积极地参与到决策过程中，让彼此感到参与了重要的项目。它不但为团队成员提供了指导方向，而且为失败留出了足够的空间。

• 构建质量--由于在开发周期的所有阶段都关注客户价值，因此它会定期进行有关质量保证的各项测试。

• 整体优化--通过关注整个项目，而不是单独的项目模块，来有效地将组织战略与项目方案相结合。

精益方法的优势

• 由于团队参与到了决策之中，因此创造力得到了激发。

• 能够尽早地消除浪费，降低成本，并加快交付的速度。

精益方法的缺点

• 对于纪律性较差的团队而言，它不一定是最佳选择。

• 项目目标和重点可能会受到诸多灵活性的影响。

迭代方法

图 5 迭代开发模型

开发界引入迭代方法作为瀑布模型的替代方案。它通过添加迭代式重复性开发周期，来克隆瀑布方法的所有步骤。由于最终产品的各个部分在完成后，才在每次迭代结束时发布的，因此这种方法也属于增量式。具体而言，迭代方法的初始阶段是计划，而最后一个阶段是部署。介于两者之间的是：计划、设计、实施、测试和评估的循环过程。

迭代方法虽与敏捷方法类似，但是它涉及的客户参与度较少，并且具有预定义的增量范围。

迭代的优点

• 在早期阶段，它能够生成产品的可运行版本。

• 其变更的成本更低。

• 由于产品被分成较小的部分，因此更易于管理。

迭代的缺点

• 可能需要更多的资源。

• 有必要全面了解各项需求。

• 不适合小型项目。

螺旋方法

作为一种具有风险意识的软件开发方法，螺旋方法侧重于降低软件开发过程中的各项风险。它属于一种迭代的开发方法，在循环中不断推进。由于结合了瀑布模型和原型设计，因此螺旋方法是最灵活的SDLC方法，并具有如下四个主要阶段：

• 第一阶段--定义项目目标并收集需求。

• 第二阶段--该方法的核心是进行全面的风险分析和计划，消减已发现的风险。产品原型会在本阶段交付出来。

• 第三阶段--执行开发和测试。

• 第四阶段--涉及评估已开发的内容，并计划开展下一次迭代。

螺旋方法主要适用于高度定制化的软件开发。此外，用户对于原型的反馈可以在迭代后期(在开发阶段)扩展各项功能。

螺旋方法的优势

• 由于引入了广泛的风险分析，因此尽可能地避免了风险。

• 它适用于较大型的项目。

• 可以在迭代后期添加其他功能。

螺旋方法的缺点

• 它更关注成本收益。

• 它比其他SDLC方法更复杂。

• 它需要专家进行风险分析。

• 由于严重依赖风险分析，因此倘若风险分析不到位，则可能会使整个项目变得十分脆弱。

DevOps方法

图 6 DevOps方法

在传统的软件开发方法中，开发人员和运维人员之间几乎没有协作。特别是在运营过程中，开发人员往往被视为“构建者”的角色。这就造成了沟通和协作上的差距，以及在反馈过程中出现混淆。而软件开发的DevOps方法恰好弥合了两者之间的沟通鸿沟。其目标是通过将开发和运营团队有效地结合起来，以快速地开发出更可靠的优质软件。值得一提的是，DevOps也是一种将手动开发转换为自动化软件开发的方法。通常，DevOps方法会被划分为如下5个阶段：

• 持续开发--此阶段涉及到软件应用的规划和开发。

• 持续集成—此阶段会将新的功能性代码与现有的代码相集成。

• 持续测试--开发团队和QA测试人员会使用maven和TestNG等自动化工具开展测试，以确保在新的功能中扫清缺陷。自动化测试为各种测试用例的执行节省了大量时间。

• 持续部署--此阶段会使用类似puppet的配置管理工具、以及容器化工具，将代码部署到生产环境(即服务器上)。它们还将协助安排服务器上的更新，并保持配置的一致性。

• 持续监控—运营团队会在此阶段通过使用Nagios、Relix和Splunk等工具，主动监控用户活动中的错误、异常、不当的软件行为、以及软件的性能。所有在此阶段被发现的问题都会被传递给开发团队，以便在持续开发阶段进行修复，进而提高软件的质量。

DevOps的优势

• 促进了合作。

• 通过持续开发和部署，更快地向市场交付软件。

• 最大化地利用Relix。

DevOps的缺点

• 当各个团队使用不同的环境时，将无法保证软件的安全。

• 涉及到人工输入的过程时，可能会减慢整体运营的速度。

小结

综上所述，软件开发生命周期中的每一个阶段都是非常重要的。我们只有正确地执行了每个步骤，才能最大限度地利用现有资源，并交付出高质量、可靠的软件。

事实上，软件开发并没有所谓的“最佳”方法，它们往往各有利弊。因此在选择具体方法之前，您需要了解待选方法对手头项目的实用性。当然，为了尽可能地采用最适合现有流程的方法，许多公司会同时使用两种不同方法的组合，通过取长补短来实现有效的融合，并相辅相成地完成软件的交付任务。

译者介绍

陈峻 (Julian Chen)，51CTO社区编辑，具有十多年的IT项目实施经验，善于对内外部资源与风险实施管控，专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式，分享前沿技术与新知;经常以线上、线下等方式，开展信息安全类培训与授课。

原文标题：The Complete Guide to SDLC，作者：Mario Olomu

本期技术加油站给大家带来百度一线的同学在日常工作中Android 开发的小技巧：Android有序管理功能引导；一行代码给View增加按下态；一行代码扩大 Andriod 点击区域，希望能为大家的技术提升助力！

01Android有序管理功能引导
随着移动互联网的发展，APP的迭代进入了深水区，产品迭代越来越精细化。很多新需求都会添加功能引导，提高用户对新功能的感知。但是，如果每个功能引导都不考虑其它的功能引导View冲突，就会出现多个引导同时出现的情况，非常影响用户体验，降低引导效果。因此，有序管理功能引导View就显得非常重要。

首先，我们需要根据自身的业务场景，梳理不同的引导类型。为了精准区分每一种引导，使用枚举定义。

enum class GuideType {
GuideTypeA,
...
GuideTypeN
}
1.
2.
3.
4.
5.
其次，将这些引导注册到引导管理器GuideManager中，注册方法需要传入引导的类型，显示引导回调，引导是否正在显示回调，引导是否已经显示回调等参数。注册引导实际上就是将引导的根据优先级保存在一个集合中，便于在需要显示引导时，判断此时是否能够显示该引导。

object GuideManager {
private val guideMap = mutableMapOf<Int, GuideModel>()

fun registerGuide(guideType: GuideType,
show: () -> Unit,
isShowing: () -> Boolean,
hasShown: () -> Boolean,
setHasShown: () -> Unit) {
guideMap[guideType.ordinal] = GuideModel(show, isShowing, hasShown, setHasShown)
}
...
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
接下来，业务方调用GuideManager.show(guideType)触发引导的显示。

如果要显示的引导没有注册，则不会显示；

如果要显示的引导正在显示或已经显示，则不会重复显示；

如果当前注册的引导集合中有引导正在显示，则不会显示；

调用show回调，设置已经显示过；

object GuideManager {
...
fun show(guideType: GuideType) {
val guideModel = guideMap[guideType.ordinal] ?: return
if (guideModel.isShowing.invoke() || guideModel.hasShown.invoke()) {
return
}
guideMap.forEach {
if (entry.value.isShowing().invoke()) {
return
}
}
guideModel.run {
show().invoke()
setHasShown().invoke()
}
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
最后，需要处理单例中已注册引导的释放逻辑，将guideMap集合清空。

object GuideManager {
...
fun release() {
guideMap.clear()
}
}
1.
2.
3.
4.
5.
6.
以上实现是简易版的引导管理器，使用时还可以结合具体业务场景，添加更多的引导拦截策略，例如当前业务场景处于某个状态时，所有引导都不展示，则可以在GuideManager.show(guideType)中添加个性化处理逻辑。

02一行代码给View增加按下态
在Android开发中，经常会遇到UE要求添加按下态效果。常规的写法是使用selector，分别设置按下态和默认态的资源，代码示例如下：

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@drawable/XX_pressed" android:state_selected="true"/>
<item android:drawable="@drawable/XX_pressed" android:state_pressed="true"/>
<item android:drawable="@drawable/XX_normal"/>
</selector>
1.
2.
3.
4.
5.
6.
UE提供的按下态效果，有的时候仅需改变透明度。这种效果也可以用上述方法实现，但缺点也很明显，需要增加额外的按下态资源，影响包体积。这个时候我们可以使用alpha属性，代码如下：

<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@drawable/XX" android:alpha="XX" android:state_selected="true"/>
<item android:drawable="@drawable/XX" android:alpha="XX" android:state_pressed="true"/>
<item android:drawable="@drawable/XX"/>
</selector>
1.
2.
3.
4.
5.
6.
这种写法，不需要额外增加按下态资源，但也有一些缺点：该属性Android 6.0以下不生效。

我们可以利用Android的事件分发机制，封装一个工具类，从而达到一行代码实现按下态。代码如下：

@JvmOverloads
fun View.addPressedState(pressedAlpha: Float = 0.2f) = run {
setOnTouchListener { v, event ->
when (event.action) {
MotionEvent.ACTION_DOWN -> v.alpha = pressedAlpha
MotionEvent.ACTION_CANCEL, MotionEvent.ACTION_UP -> v.alpha = 1.0f
}
// 注意这里要return false
false
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
用户对屏幕的操作，可以简单划分为以下几个最基础的事件：



Android的View是树形结构的，View可能会重叠在一起，当点击的地方有多个View可以响应点击事件时，为了确定该让哪个View处理这次点击事件，就需要事件分发机制来帮忙。事件收集之后最先传递给 Activity，然后依次向下传递，大致如下：Activity －> PhoneWindow －> DecorView －> ViewGroup －> … －> View。如果没有任何View消费掉事件，那么这个事件会按照反方向回传，最终传回给Activity，如果最后 Activity 也没有处理，本次事件才会被抛弃。这是一个非常典型的责任链模式。整个过程，有三个非常重要的方法：



以上三个方法均有一个布尔类型的返回值，通过返回 true 和 false 来控制事件传递的流程。这三个方法的调用关系，可以用下面的伪代码描述：

public boolean dispatchTouchEvent(MotionEvent ev) {
boolean consume = false;
if (onInterceptTouchEvent(ev)) {
consume = onTouchEvent(ev);
} else {
consume = child.dispatchTouchEvent(ev);
}
return consume;
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
对于一个View来说，它可以注册很多事件监听器，例如单击事件、长按事件、触摸事件，并且View自身也有onTouchEvent方法，这些与事件相关的方法由View的dispatchTouchEvent方法管理，事件的调度顺序是onTouchListener -> onTouchEvent -> onLongClickListener -> onClickListener。所以我们可以通过为View添加onTouchListener来处理View的按下、抬起效果。需要注意的是，如果onTouchListener中的onTouch返回true，不会再继续执行onTouchEvent，后面的事件都不会响应，所以我们需要在工具类中return false。

03一行代码扩大 Andriod 点击区域
在Android 开发中，经常会遇到扩大某些按钮点击区域的场景，如某个页面关闭按钮比较小，为防止误触或点不到，需要扩大其点击区域。

常见的扩大点击区域的思路有三个：

1. 修改布局。如增加按钮的内padding，或者外面嵌套一层Layout，并在外层Layout设置监听。

2. 自定义事件处理。如在父布局中监听点击事件，并设置各组件的响应点击区域，在对应点击区域里时就转发到对应组件的点击。

3. 使用 Android 官方提供的TouchDelegate 设置点击事件。

其中第一种方式弊端很明显，会增加业务复杂度，降低渲染性能；或者当布局位置不够时，增加padding或添加外层布局就行不通了。

第二种方式可以从根本上扩大点击区域，但是问题依旧明显：编码的复杂度太高，每次扩大点击区域都意味着需要根据实际需求去“重复造轮子”：写一堆获取位置、判定等代码。

第三种方式是Android官方提供的一个解决方案，能够比较优雅地解决这个问题，如下描述:

Helper class to handle situations where you want a view to have a larger touch area than its actual view bounds. The view whose touch area is changed is called the delegate view. This class should be used by an ancestor of the delegate. To use a TouchDelegate, first create an instance that specifies the bounds that should be mapped to the delegate and the delegate view itself.

当然，如果使用 Android 的TouchDelegate，很多时候还不能满足我们需求，比如我们想在一个父（祖先）View 中给多个子 View 扩大点击区域，如在一个互动Bar上有点赞、收藏、评论等按钮。这时可以在自定义TouchDelegate时维护一个View Map，该Map 中保存子View和对应需要扩大的区域，然后在点击转发逻辑里动态计算该点击事件属于哪个子View区域，并进行转发。关键代码如下：

// 已省略无关代码
public class MyTouchDelegate extends TouchDelegate {
/** 需要扩大点击区域的子 View 和其点击区域的集合 */
private Map<View, ExpandBounds> mDelegateViewExpandMap = new HashMap<>();

@Override
public boolean onTouchEvent(MotionEvent event) {
// ……
// 遍历拿到对应的view和扩大区域，其它逻辑跟原始逻辑类似
for (Map.Entry<View, ExpandBounds> entry : mDelegateViewExpandMap.entrySet()) {
View child = entry.getKey();
ExpandBounds childBounds = entry.getValue()
}
// ……
}

public void addExpandChild(View delegateView, int left, int top, int right, int bottom) {
MyTouchDelegate.ExpandBounds expandBounds = new MyouchDelegate.ExpandBounds(new Rect(), left, top, right, bottom);
this.mDelegateViewExpandMap.put(delegateView, expandBounds);
}
}

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
更进一步的，可以写个工具类，或者Kotlin扩展方法，输入需要扩大点击区域的View、祖先View、以及对应的扩大大小，从而达到一行代码扩大一个View的点击区域的目的。

public static void expandTouchArea(View ancestor, View child, int left, int top, int right, int bottom) {
if (child != null && ancestor != null) {
MyTouchDelegate touchDelegate;
if (ancestor.getTouchDelegate() instanceof MyTouchDelegate) {
touchDelegate = (MyTouchDelegate)ancestor.getTouchDelegate();
touchDelegate.addExpandChild(child, left, top, right, bottom);
} else {
touchDelegate = new MyTouchDelegate(child, left, top, right, bottom);
ancestor.setTouchDelegate(touchDelegate);
}
}
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
注意: TouchDelegate在Android8.0及其以前有个bug，如果需要兼容低版本需要留意下，在通过delegate触发子View点击事件之后，父View自己监听的点击事件就永远无法被触发了，原因在于TouchDelegate中对点击事件转发的处理中（onTouchEvent）对MotionEvent.ACTION_DOWN）有问题，不在点击范围内时，未对mDelegateTargeted变量重置为false，导致父view再也收不到点击事件，无法处理click等操作，相关Android源码如下：

// …… 已省略无关代码
public boolean onTouchEvent(MotionEvent event) {
// ……
boolean sendToDelegate = false;
boolean handled = false;
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
Rect bounds = mBounds;
if (bounds.contains(x, y)) {
mDelegateTargeted = true;
sendToDelegate = true;
} // if的判断为false时未重置 mDelegateTargeted 的值为false
break;
// ……
if (sendToDelegate) {
// 转发代理view
handled = delegateView.dispatchTouchEvent(event);
}
return handled;
// ……
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
如果需要兼容低版本，则可以继承自TouchDelegate，覆写 onTouchEvent方法，在事件不在代理范围内时，重置mDelegateTargeted 和sendToDelegate值为false，如下：

……
if (bounds.contains(x, y)) {
mDelegateTargeted = true;
sendToDelegate = true;
} else {
mDelegateTargeted = false;
sendToDelegate = false;
}
// 或者如9.0之后源码的写法
mDelegateTargeted = mBounds.contains(x, y);
sendToDelegate = mDelegateTargeted;
……
-----------------------------------
©著作权归作者所有：来自51CTO博客作者百度Geek说的原创作品，请联系作者获取转载授权，否则将追究法律责任
百度程序员Android开发小技巧
https://blog.51cto.com/u_15082365/5305270

有网友表示很能理解，因为对开源不能一刀切，需要借鉴目前先进的管控经验。对代码库进行网格化管理，责任层层压实：

有网友表示，：

• 开源不是可口可乐，全世界不能一个味。

• 谨防恶意开源

• 非必要不开源

• 搬起石头砸自己的脚

• 能用gitee，你就偷着乐吧

• 推动中国开源建设
  
  以上观点来源：www.zhihu.com/question/533388365/answer/2492004178
  

  http：//www.zhihu.com/question/533388365/answer/2491722941
  

  http：//www.zhihu.com/question/533388365/answer/2491840969
  

  http：//www.zhihu.com/question/533388365
  

本文分享主题是B站SRE在稳定性方面的运营实践。

随着B站近几年的快速发展，业务规模越来越大，迭代速度越来越快，系统运行复杂度也越来越高。线上每天都会发生各种各样的故障，且发生的场景越来越刁钻。为了应对这种情况，保障业务在任何时刻都能将稳定性维持在一个高基线之上，B站专门成立了SRE体系团队，在提升业务稳定性领域进行了全方位、体系化的积极探索，从理论性支撑和能力化建设进行着手，从故障应急响应、事件运营、容灾演练、意识形态等多方面进行稳定性运营体系的构筑。

本次分享主题是B站SRE在稳定性方面的运营实践，分享内容分为以下几个部分：

• 案例剖析

• 从应急响应看稳定性运营

• 核心运营要素有哪些

• 两个运营载体：OnCall与事件运营中心

• 挑战与收益

一、案例剖析

多年来业界同仁针对稳定性这一话题进行了大量的探索和实践，业界不乏针对稳定性保障相关的讨论和研究。在围绕稳定性的实践上，大家也经常听到诸如混沌工程、全链路压测、大促活动保障和智能监控等话题的分享。B站在这些方面也做了很多建设工作，今天我将从应急响应的角度切入，和大家分享B站在稳定性运营方面所做的工作。

我们先来看两个案例，案例以真实事件为依托，相关敏感内容进行了改写。

案例一

1）背景

一个手机厂商的发布会在某天晚上12点举办，B站承接了该品牌的线上发布会直播。公司的运营同学提前就配置好了12点的直播活动页面以及准点的应用内Push消息。在12点到来之后，直播活动页推送生效，大量用户收到应用内推送消息，点击进入直播活动页面。

2）故障始末

12点01分，直播活动页内嵌的播放器无法支持部分用户正常加载播放。

12点03分，研发同学李四收到了异常的报警，开始介入处理。

12点04分，客服同学收到了大量有关发布会无法正常播放的用户反馈，常规处理方法无法解决用户问题。

影响持续到12点15分，研发同学李四还在排查问题的具体原因，没有执行相对应的止损预案（该种问题有对应预案），问题持续在线上造成影响。

直到12点16分，老板朋友找到了老板反馈今晚B站的某品牌手机直播发布会页面视频无法正常播放，此时老板开始从上往下询问，研发leader知道了这件事，开始联系SRE同学介入问题处理，并及时执行了相关的切换预案，直播活动页面播放恢复正常。

3）问题

在这个案例中，暴露了以下一些问题：

• 故障的相关告警虽然及时，但是并没有通知到足够多对的人。

• 该故障的告警，在短时间没有处理响应后，并未进行有效的结构性升级（管理升级，及时让更高level的人参与进来，知晓故障影响，协调处理资源）和职能性升级（技术升级，让更专业和更对口的人来参与响应处理，如team leader、SRE等）。

• 一线同学往往容易沉迷于查找问题根因，不能及时有效地对故障部位进行预案执行。

案例二

1）背景

一个平淡无奇的周末晚上，23点30分，监控系统触发大量告警，几乎全业务线、各架构层都在触发告警。

2）故障始末

23点40分，企业微信拉了有十几个群，原有的业务沟通群、基础服务OnCall群，都在不停地转发告警，询问情况。整个技术线一片恐慌，起初以为是监控系统炸了。此时相关故障的SRE同学已经被拉到某一个语音会议中。

注意，此时公司的多个BU业务线同学都炸锅了，到处咨询发生了什么，业务怎么突然就不炸了。又过了几分钟，资深的SRE同学又拉了一个大群，把相关业务对接人都拉进群里，开始整体说明故障情况。此时，该同学也比较纠结如何通报和说明这个问题，因为此时没有一个明确故障定位，语言很难拿捏，各个高level的老板也都在问（已上热搜）。并且，负责恢复入口服务的一线同学把故障预案执行了个遍，发现无济于事。后续在GSLB调度层，执行了整个跨机房的流量有损切换才让服务逐渐恢复正常。

凌晨之后，原有机房的问题定位出来了，补丁迅速打上，异常的问题彻底修复了。后续，在对此事件进行复盘时，发现困难重重。因为故障处理过程中，涉及到大量的服务、组件和业务方，并且大家当时拉了一堆群，同样的消息被发送到了很多群。参与处理故障的同学在语音、电话和企微群都有进行过沟通和处理进展发布，整个事件的细节整理起来非常耗费人力和精力，准确性也很难保障。

3）问题

• 在上面这个案例中，我们可以看到整个故障从发生、处置到结束后复盘，都存在以下问题：

• 当一个影响面比较大的故障产生时，大家没有统一的故障进展同步方式，依托原始的人工拉群，人工找相关人员电话联系，导致了故障最新的进展情况只能够在小范围传播扩散，无法统一对外公布，并且在传播过程中，很容易消息失真；

• 在故障处理过程中，缺少主要协调人（故障指挥官）。像这种大型故障，需要有一个人能够去协调各层人员分工、消息收敛、服务业务情况等，这个人需要能够掌控整个故障的所有消息和全貌进展；

• 在故障处理过程中，缺乏故障上下文的信息关联，大家难以知晓故障发生的具体位置，只是感知到自己的业务受损了，自己的服务可能有异常，这导致整个故障的定位时间被拉长；

• 在故障恢复之后，我们对这个故障进行复盘时，发现故障处理过程中的信息太过零散，复盘成本很高。

案例剖析

通过对上述两个案例的分析我们能够发现，在故障发生前、处理中和结束后，各个阶段都会有很多因素导致我们的故障不能被快速解决，业务不能快速恢复。

这里我们从故障的前、中、后三个阶段总结可能存在的一些问题。

1）事前

• 告警信息量大，信息太过杂乱；

• 平台系统繁多，变更信息无处收敛；

• 客服反馈的信息，需要靠人工去关联，并反馈到技术线；

• 和公司舆情相关的信息，技术线很难感知到。

2）事中

• 一线同学过于关注技术，沉迷问题解决；

• 当一个故障影响面扩大之后，涉及多个团队的协同非常困难，最新的进展消息无法及时有效地传递到相关人员手中；

• 当参与一个故障处理的人员多了之后，多个人员之间缺乏协调，导致职责不清晰，产生事情漏做、重复做的问题；

• 故障处理过程中，会有一些不请自来，凑热闹的同学。

3）事后

• 当我们开展复盘时，发现故障处理时又是群、又是电话、又是口头聊，又是操作各种平台和工具，做了很多事情，产生了很多信息，梳理时间线很繁琐，还会遗漏，写好一份完整的复盘报告非常麻烦；

• 拉一大堆人进行复盘的时候，因为缺少结构化的复盘流程，经常是想到什么问什么。当某场复盘会，大家状态好的时候，能挖掘的点很多。如果状态不好或者大家意识上轻视时，复盘的效果就较差；

• 复盘后产出的改进事项，未及时统一地记录跟进，到底有没有完成，什么时间应该完成，完成的情况是否符合预期都不得而知；

• 对于已经修复的问题，是否需要演练验收确保真正修复。

以上三个阶段中可能发生的各种各样的问题，最终只会导致一个结果：服务故障时间增长，服务的SLA降低。

二、从应急响应看稳定性运营

针对上述问题，如何进行有效改善？这是本部分要重点分享的内容，从应急响应看稳定性运营。

应急响应的概念较早来源于《信息安全应急相应计划规范GB/T24363-2009》中提到的安全相关的应急响应，整体定义是“组织为了应对突发/重大信息安全事件的发生所作的准备，以及在事件发生后所采取的措施”。从这个概念我们延伸到稳定性上就产生了新的定义，“一个组织为了应对各种意外事件的发生所作的准备以及在事件发生后所采取的措施和行为”。这些措施和行为，通常用来减小和阻止事件带来的负面影响及不良后果。

三、核心运营要素有哪些

做好应急响应工作的核心目标是提升业务的稳定性。在这个过程中，我们核心关注4大要素。核心点是事件，围绕事件有三块抓手，分别是人、流程和工具/平台。

人作为应急响应过程中参与和执行的主体，对其应急的意识和心态有很高要求。特别是在一些重大的故障处理过程中，不能因为压力大或紧张导致错误判断。

流程将应急响应的流程标准化，期望响应人能够按照既定阶段的既定章程进行有效的推进和处理。

工具/平台支撑人和流程的高效合规运行，并将应急响应的过程、阶段进行度量，进而分析和运营，推进人和流程的改进。

事件

1）生命周期划分

要对故障进行有效运营，就需要先明确故障的生命周期。通过划分故障的生命周期，我们可以针对不同的周期阶段进行精准聚焦，更有目的性地开展稳定性提升工作。

针对故障生命周期的划分有很多种方式，按故障的状态阶段划分，可以分为事前、事中和事后。

按故障的流程顺序划分，可以分为故障防御、故障发生、故障响应、故障定位和故障恢复、复盘改进等阶段。

这里我围绕故障的时间阶段，从故障不同阶段的形态变化做拆分，将故障拆分为四个阶段。

• 告警/变更/客诉

当故障还未被确认时，它可能是一个告警、变更或客诉。

• 事件

当这个告警、变更、客诉被上报后，会产生一个事件，我们需要有人去响应这个事件，此时一个真正的事件就形成了。

• 故障

当事件的影响范围逐渐扩散，这时往往有大量的用户、业务受到影响，我们需要将事件升级成故障，触发故障的应急协同，进行一系列的定位、止损等工作。

• 改进

故障最终会被恢复，接下来我们要对故障进行复盘，产生相关改进项，在改进项被完成之后，还需要进行相关的验收工作。

2）阶段度量

从更科学的角度看，我们知道在运营工作中，度量是很关键的一点。管理学大师彼得·德鲁克曾经说过：“你如果无法度量它，就无法管理它”。有效的度量指标定义，可以帮助我们更好更快地开展运营工作、评估价值成果。上文中我们提到的3个阶段是比较笼统的阶段，接下来我将介绍更加具体和可执行的量化拆分方法。

如上图所示，从故障预防依次到故障发现，故障定位，故障恢复，最后到故障改进，整体有两个大的阶段：MTBF（平均无故障时间）和MTTR（平均故障恢复时间）。我们进行业务稳定性运营的核心目标就是降低MTTR，增加MTBF。根据Google的定义，我们将MTTR进一步拆分为以下4个阶段：

• MTTI：平均故障发现时间，指的是故障发生到我们发现的时间。

• MTTK：平均故障定位时间，指的是我们发现故障到定位出原因的时间。

• MTTF：平均故障修复时间，指的是我们采取恢复措施到故障彻底恢复的时间。

• MTTV：平均故障修复验证时间，指的是故障恢复之后通过监控、用户验证真实恢复的时间。

3）关键节点

基于阶段度量的指标，我们能够得到一系列的关键时间节点。在不同的阶段形态，事件和故障会存在一些差异。故障因为形态更丰富，所存在的时间节点更多。上图中定下来的时间，均是围绕MTTR进行计算的。主要是为了通过度量事件、故障的处理过程，发现过程中存在的问题点，并对问题点进行精准优化，避免不知道如何切入去提升MTTR的问题，也方便我们对SRE的工作进行侧面考核。

人

人作为事件的一个主体，负责参与事件的响应、升级、处置和消息传播。

人通过上文中我们讲到的OnCall参与到应急响应中。我们在内部通过一套OnCall排班系统进行这方面的管理。这套系统明确了内部的业务、职能和人员团队，确保人员知道什么时间去值什么业务的班。下面的工具/平台部分会展开介绍。对参与人的要求，主要有以下几点：

• 具备良好的响应意识和处理心态。

• 具备熟练地响应执行的经验。

满足以上特征，才能做到故障来临时响应不慌乱，有条不紊地开展响应工作。

流程

那么针对人的要求如何实现？人员如何参与到应急响应的环节中去？人员的意识如何培养呢？

首先，我们内部制定了应急响应白皮书，明确了以下内容：

• 响应流程；

• 基于事件大小，所要参与的角色和角色对应的职责；

• 周边各个子系统SOP制定的标准规范；

• 针对应急过程中的对外通告内容模板；

• 故障过程的升级策略。

之后，我们会周期性地在部门内部、各BU进行应急响应宣讲，确保公司参与OnCall的同学能够学习和掌握。另外，我们也会将其作为一门必修课加入新同学的入职培训中。最后就是故障演练，通过实操，让没有参与过故障处理的新同学能够实际性地参与应急响应的过程，避免手生。

平台

平台作为支撑人与流程进行高效、稳定执行的载体，我将在下一部分进行具体描述。

四、两个运营载体：OnCall与事件运营中心

这部分我将向大家分享B站在应急响应方面落地的两个运营性平台。

OnCall系统

OnCall系统，即值班系统。值班系统在日常运转过程中的作用往往被低估，SRE、工程效率做这部分建设时，很容易基于二维的方式对人和事进行基于日历的值班管理，并通过网页、OpenAPI等方式对外提供数据服务。

下面我们通过几个例子来说明OnCall的必要性。

在日常工作中，当我们使用公司某个平台功能时，可能会习惯性找熟悉的同学，不管他这一天是不是oncall。这可能给那位同学带来困扰，他可能上周才值完班，这周要专心于研发或者项目的推进，你随时找他可能打断他的工作节奏。还有一种情况是新同学不知道该去找谁，我们内部之前经常有这种情况，一个新来的同学接手一套系统之后，有问题不知道该找谁，经常要转好几手，才能找到对的人，这一过程很痛苦。

以上内容总结起来就是总找一个人，总找不到人，除此之外，还会出现平台找不到人的情况。这些问题的根源是什么呢？无非就是who、when、what和how的问题，不能在正确的时间为正确的事找到正确的人。

那么OnCall系统的重要性和必要性都体现在哪些方面呢？

• 有问题找不到人

随着公司业务规模的扩大和领域的细分，一些新的同学和新业务方往往会出现一个问题。不知道是哪些人负责，需要咨询很多人才能找到具体解决问题的人。这一问题不仅限于故障，更存在于日常琐事中。特别是SRE同学的日常，经常会被研发同学咨询找人拉群，戏称拉群工程师。

• 下班不下岗

当人们遇到问题时，经常会下意识找熟悉的人。这就导致一些能力强、服务意识好的同学，总是在被人找。不论他今天值不值班，他将无时无刻都要面临被人打扰的问题。除了被人找之外，内部的监控系统、流程系统，也会给不值班的同学发送监控告警和流程审批信息。这也将SRE同学有50%的时间用于工程这一愿景变成泡影。

1）设计

① 明确关联逻辑

针对上述两种情况，我们对公司的业务、服务、职能和组织架构进行了分析建模，明确了人、团队、职能和业务之间的关联关系。

② 建立三维合一模型

我们构建起了一套三维合一的模型。由组织-业务、职能-人员、组织-职能的关联关系，产生交汇点。值班人员会通过值班小队的方式，落在这些交汇点上，并且基于业务和基础架构的异同点，通过业务视角和职能视角分别对外提供服务。

以我们公司内部主站业务为例，我们会有专门的SRE小队进行日常的值班响应，这个小队只负责主站业务的值班响应。通过这样的对应关系，当人或平台有需求的时候，都可以通过业务和职能关联到对应实践的值班小队，最终定位到具体的人，这样也帮助我们将人藏了起来，更有利于后续SRE轮岗机制的推进落地。

③ 双视角提供服务

通过双视角的设计，区分了职能型和业务型的不同值班方式和关注点。原因在于B站的业务层级组织模式是按照“组织->业务->应用”这三级进行组织的，所有的应用归属到业务，业务归属到具体的组织架构。

• 职能视角

前端采用树型展示，组成结构为组织->职能->覆盖范围（组织->业务->服务），值班表具体挂载在覆盖范围下，覆盖范围可以只有一级组织也可以精确到组织下面的业务或业务下面的服务。

• 业务视角

前端采用树型展示，组织结构为组织->业务->职能，值班表具体挂载在职能下面。

在日常工作中，基础架构相关的服务，比如SRE、DBA、微服务、监控、计算平台等强职能型服务会通过职能视角对外提供值班信息。当业务人员有具体问题时，可以通过职能树快速定位到具体的值班人员。而对于业务服务来讲，日常的工作模式是围绕业务开展的，因此会通过业务进行展开，提供该业务下相关职能的对应值班信息。

这两个视角的底层数据是相通的，强职能相关服务提供方只需要维护好职能视角的值班信息，业务视角下的关联会自动生成。

2）功能展示

基于以上设计，我们内部做了一套OnCall排班的系统。

这套系统是管理业务、职能和人的系统。我们基于上文中提到的几个核心概念，在这些概念间建立了关系，分别是两条线，一条是职能-团队和人，另外一条是职能-业务和服务。

系统提供了排班班组的管理，支持基于日历的排班，同时支持班组设置主备oncall角色。在排班的细节上，我们支持基于时段进行自动排班计划生成，也支持在一个职能里多个班组混合排班。另外，也支持对已经排好班的班组，进行覆盖排班和换班，这个主要应对oncall同学突然有事请假的情况。在oncall通知方面，我们支持了企业微信、电话等通知方式，并且支持虚拟号码的方式，保护员工号码不对外泄露。同时也避免了因为熟悉导致的频繁被打扰的情况。

在周边生态方面，这套OnCall系统完全依赖周边系统的接入。我们目前对接了内部的告警系统、流程系统，确保告警和流程能够只通知oncall人，而不形成骚扰。在企业微信的服务号中，也进行了H5的页面嵌入，在用户通过企业微信反馈问题、找人时，知道当下该找谁。在各个接入的平台，也内嵌了OnCall的卡片页面，明确告诉用户本平台当前是谁值班。通过这套OnCall系统的落地，我们明确了人、团队、职能和业务的概念，并将这些概念进行了关系建立和对应。人员通过排班班组统一对外为某个业务提供某项职能的值班响应。通过前端的可视化，提供了日历的值班展示效果，可以直观看到某个业务所需要的某块职能在某个时间点是由哪个班组在服务，周边的各个系统也都对接OnCall系统，实现了人员响应的统一管理，解决了某些人员认人不认事，不通过正规流程处理的问题。

事件运营中心

事件运营中心这套系统是我们基于ITIL、SRE、信息安全应急计划的事件管理体系，为了满足公司对重大事件/故障的数字化管理，实现信息在线、数据在线和协同在线，使组织能够具备体系化提升业务连续性能力所做的产品平台。这个平台的定位是一站式的SRE事件运营中心，数字化运营业务连续性的目标是提升MTBF，降低MTTR，提高SLA。

1）架构设计

上图是我们平台的模块架构图，整体上还是围绕上文提到的事件的事前、事中和事后三个阶段拆分，覆盖了一个事件产生、响应、复盘、改进的全生命周期。

• 事前

我们对事件进行了4大类型的拆分，分别是告警、变更、客诉和舆情，然后通过设计标准的事件上报协议，以集成的方式将我们内部的各个系统打通，将事件信息统一收集到一起。在收集的过程中，进行二次处理，实现事件的结构化转储。

• 事中

我们会对接入的4大类型信息进行事件转化，然后通过预定义的规则对事件进行降噪，抑制、报警、召回、分派和升级等相关操作。在这个过程中，如果一个事件被判定影响到业务，我们会将它升级成一个故障，然后触发故障的应急响应流程。这里就进入到对故障响应处理过程中的一个阶段，在这个阶段我们会产生各种角色，例如故障指挥官、故障通讯人员、故障恢复人员等，相关人员明确认领角色，参与故障的止损。止损过程中，通过平台一键拉群创建应急响应指挥部，通过平台的进展同步进行相关群和业务人员的通告，通过记录簿实现故障信息的信息传递和记录。

• 事后

在故障结束之后，就进入到我们整体的改进环节。平台可以基于故障一键创建复盘报告，自动关联故障处理过程中的专家数据。平台提供预制的故障复盘问答模板，以确认各阶段是否按照预期的目标进行。复盘产生的待办列表，平台会进行定期的状态提醒和处理进度跟进。最终的这些都会以知识的形式，沉淀在我们的知识库。帮助日常On-Call问答和公司内部员工的培训学习。整体这样一套平台流程下来，就实现了将一些日常高频的非结构性事务驱动，通过统一接入、精准触达、事件闭环和持续改进等环节，转化为低频的结构化数据驱动方式。

2）场景覆盖

下面我们介绍平台在各个场景的覆盖。

① 集约化

对事件产生的上游来源进行集约化管理，通过队列订阅、API和SDK的方式，将内部的监控，Prometheus、监控宝等各个云平台的监控都通过前面的4大类型定义收归到一起，然后统一进行通知触达。

② 标准事件类型

为了实现各个渠道消息的结构化规约，我们设计了标准的事件模型，通过这个事件模型，我们将周边各个系统/工具/平台进行收集，并且实现了事件的关联操作。模型主要分为4部分：

• base是一些事件的基础信息字段；

• who是指这一事件来自哪里，有哪些相关方；

• when是指事件发生或产生影响的时间；

• where是指事件来源于哪个业务、影响了哪些业务；

• what是指这个事件的具体内容，它的操作对象是什么等等。

③ 降噪聚类

由于我们对事件的上报结构进行了标准化，并且预埋了关联字段，通过这些关联字段，我们就建立起了事件的关联关系，从而可以做事件的降噪聚类。

降噪聚类在执行上，主要分为两部分。

• 横向抑制

我们支持对单个来源的事件、告警，通过定义的规则进行收敛，比如Prometheus报警出一个服务在某个持续时间内持续报了N条一样的告警信息，平台会收敛到一个事件中去。

• 纵向抑制

这对上文中提到的底层系统故障十分有效，可以将底层故障导致的上层业务告警都统一收到一个事件中，避免大量告警使大家造成混淆。

④ 协同在线

在协同在线的场景下，我们通过一个面板将人、业务、组件和系统信息进行了汇总，通过一个事件详情页，将整个事件当下的处理人、关联业务和服务组件、当下的一些信息统一展示在一起。在协同能力上，我们提供了一键创建应急响应群的功能，建群时会自动关联该故障相关oncall同学，对故障感兴趣的同学也可以通过面板加入响应群。在故障页面，清晰看到故障当前的指挥官是谁，当下的处理人是哪些同学。彻底解决了之前靠人工拉语音、打电话、面对面交流的原始协作方式。

平台的各方面能力实现了事件全生命周期的闭环管理。监控告警、故障发现、应急响应、故障定位、故障恢复、故障复盘和故障改进，全阶段都通过平台能力去承载。

• 故障响应时，支持了故障的全局应急通告，提供了多种通告渠道，信息实时同步不延误，避免人工同步，漏同步、同步内容缺漏等问题；

• 故障跟踪阶段，平台可以实时展示最新的故障进展；故障影响面、当下处置情况，各阶段时间等等；

• 故障结束的复盘阶段，通过定义好的结构化、阶段化的复盘过程，确保复盘过程中，该问的问题不遗漏，该确认的点都确认到；

• 故障改进阶段，通过对改进项的平台化录入，关联相关责任方、验收方，确保改进的有效执行和落实。

上图中是协同相关的一些示例，当一个故障被创建出来时，会自动关联该故障涉及到的业务、组件、基础设施的oncall同学，这些同学可能是SRE、研发等，平台会记录他们是否有响应这些问题，并且当下所负责的角色是什么。因为角色决定了在该事件中所担负的事项和责任；下方一键拉群，可以将相关人员，自动拉入到一个群内，方便大家进行沟通协同，并且事件、故障的相关最新进展也会定期在群内同步；涉及到事件的参与人员，事件运营中心的服务号也会定期推送最新进展，确保不会丢失消息。

上图是我们内部的故障协同的详情页面，提供了记录簿、故障阶段更新、最近变更信息和相似事件，确保每次的响应处理，都能形成一个专家经验的沉淀，帮助后续新来的同学进行故障响应过程的学习。

复盘方面，我们定义了结构化的故障复盘模板，像相关人员、组织、影响情况、处置过程、根因分析(在根因分析里面，我们设置了6问，确保对问题能够有深度地挖掘)，改进措施等。在复盘效率方面，我们关联了相关的变更信息、故障处理时的一些变更操作，以及处理时间线，帮助复盘同学快速生成故障的相关信息，减少人工录入负担。

五、挑战与收益

挑战

在业务稳定性运营体系的建设过程中，团队也踩了很多坑，面临着诸多技术之外的挑战。鉴于业界对于技术相关的分享比较丰富，这里就针对体系逻辑和人员方面的挑战进行分享。

• 元信息统一

稳定性是个大话题，我们在落地整体体系时会发现，设计的上下游系统太多了。每个系统里面都会有人、业务、职能的使用需求。在初期，我们内部在服务、业务和人的关联这块没有形成统一的数据基准，导致我们在应急协同的诸多特性上难以落地，诸如故障的有效通知、群内的有效传递、故障画像的拓扑关联计算缺少映射关系等等。

在这种情况下，我们重新梳理了服务树和OnCall系统，通过服务树将组织、业务和服务的映射关系维护好，通过OnCall系统将组织、职能、业务和人的映射关系维护好，来确保找人的时候能找到人，找服务的时候能找到服务。

• 工作模式改变

新的应急响应流程，将故障过往对人的依赖转移到靠系统来自行驱动，这导致现有人员的工作模式产生了很大变化。传统故障处理时，响应人员手动拉群、语音或现场找人，现在变成了优先在系统内升级已有事件或录入故障信息，然后通过系统自动进行人员关联和邀请。群内的随意沟通，变成了在平台进行阶段性进展同步。原有的故障升级逻辑变成了平台定时通知，这给故障处理人员带了一定的压迫感。整体形式上更加严肃和标准，在落地初期给大家带来了一定的不适应感。针对这种情况，我们一方面通过在系统的文案描述上进行改善，交互逻辑上进行优化，尽可能在推行新标准的同时，适应旧的使用习惯。例如，常规应急协同群会先于平台的故障通告建立，这就会与平台创建的故障协同群发生冲突。此时，我们通过增加现有群关联来实现已有故障协同群和故障的关联。另外一方面，我们通过定期持续的宣讲，给大家介绍新的应急响应流程和平台使用方法，帮助大家适应新的应急响应模式。

收益

以上就是B站在业务稳定性运营方面所做的相关工作。通过体系化建设，已经在组织、流程和平台层面实现强效联动，具备了数字化运营业务稳定性的能力，建立了科学有效的稳定性评估提升量化标准，让稳定性提升有数据可依托。将故障应急响应流程从由人工驱动升级到由平台系统驱动，应急响应人员可以更专心处理故障，大幅提升故障恢复时间。后续我们将会持续探索更科学有效的管理运营方法，期望通过引入AI的能力，提升故障辅助定位能力、提早发现故障隐患，联动预案平台实现更多场景的故障自愈。

责任编辑：张燕妮来源： dbaplus社群

1提取 PDF 内容

# pip install PyPDF2 安装 PyPDF2
import PyPDF2
from PyPDF2 import PdfFileReader
 
# Creating a pdf file object.
pdf = open("test.pdf", "rb")
 
# Creating pdf reader object.
pdf_reader = PyPDF2.PdfFileReader(pdf)
 
# Checking total number of pages in a pdf file.
print("Total number of Pages:", pdf_reader.numPages)
 
# Creating a page object.
page = pdf_reader.getPage(200)
 
# Extract data from a specific page number.
print(page.extractText())
 
# Closing the object.
pdf.close()

2提取 Word 内容

# pip install python-docx 安装 python-docx
 
 
import docx
 
 
def main():
     try:
     doc = docx.Document('test.docx') # Creating word reader object.
     data = ""
     fullText = []
     for para in doc.paragraphs:
         fullText.append(para.text)
         data = '\n'.join(fullText)
 
     print(data)
 
     except IOError:
     print('There was an error opening the file!')
     return
 
 
if __name__ == '__main__':
     main()

3提取 Web 网页内容

# pip install bs4 安装 bs4
 
from urllib.request import Request, urlopen
from bs4 import BeautifulSoup
 
req = Request('http://www.cmegroup.com/trading/products/#sortField=oi&sortAsc=false&venues=3&page=1&cleared=1&group=1',
         headers={'User-Agent': 'Mozilla/5.0'})
 
webpage = urlopen(req).read()
 
# Parsing
soup = BeautifulSoup(webpage, 'html.parser')
 
# Formating the parsed html file
strhtm = soup.prettify()
 
# Print first 500 lines
print(strhtm[:500])
 
# Extract meta tag value
print(soup.title.string)
print(soup.find('meta', attrs={'property':'og:description'}))
 
# Extract anchor tag value
for x in soup.find_all('a'):
     print(x.string)
 
# Extract Paragraph tag value
for x in soup.find_all('p'):
     print(x.text)

4读取 Json 数据

import requests
import json
 
r = requests.get("https://support.oneskyapp.com/hc/en-us/article_attachments/202761727/example_2.json")
res = r.json()
 
# Extract specific node content.
print(res['quiz']['sport'])
 
# Dump data as string
data = json.dumps(res)
print(data)

5读取 CSV 数据

import csv
 
with open('test.csv','r') as csv_file:
     reader =csv.reader(csv_file)
     next(reader) # Skip first row
     for row in reader:
     print(row)

6删除字符串中的标点符号

import re
import string
 
data = "Stuning even for the non-gamer: This sound track was beautiful!\
It paints the senery in your mind so well I would recomend\
it even to people who hate vid. game music! I have played the game Chrono \
Cross but out of all of the games I have ever played it has the best music! \
It backs away from crude keyboarding and takes a fresher step with grate\
guitars and soulful orchestras.\
It would impress anyone who cares to listen!"
 
# Methood 1 : Regex
# Remove the special charaters from the read string.
no_specials_string = re.sub('[!#?,.:";]', '', data)
print(no_specials_string)
 
 
# Methood 2 : translate()
# Rake translator object
translator = str.maketrans('', '', string.punctuation)
data = data.translate(translator)
print(data)

7使用 NLTK 删除停用词

from nltk.corpus import stopwords
 
 
data = ['Stuning even for the non-gamer: This sound track was beautiful!\
It paints the senery in your mind so well I would recomend\
it even to people who hate vid. game music! I have played the game Chrono \
Cross but out of all of the games I have ever played it has the best music! \
It backs away from crude keyboarding and takes a fresher step with grate\
guitars and soulful orchestras.\
It would impress anyone who cares to listen!']
 
# Remove stop words
stopwords = set(stopwords.words('english'))
 
output = []
for sentence in data:
     temp_list = []
     for word in sentence.split():
     if word.lower() not in stopwords:
         temp_list.append(word)
     output.append(' '.join(temp_list))
 
 
print(output)

8使用 TextBlob 更正拼写

from textblob import TextBlob
 
data = "Natural language is a cantral part of our day to day life, and it's so antresting to work on any problem related to langages."
 
output = TextBlob(data).correct()
print(output)

9使用 NLTK 和 TextBlob 的词标记化

import nltk
from textblob import TextBlob
 
 
data = "Natural language is a central part of our day to day life, and it's so interesting to work on any problem related to languages."
 
nltk_output = nltk.word_tokenize(data)
textblob_output = TextBlob(data).words
 
print(nltk_output)
print(textblob_output)

Output:

['Natural', 'language', 'is', 'a', 'central', 'part', 'of', 'our', 'day', 'to', 'day', 'life', ',', 'and', 'it', "'s", 'so', 'interesting', 'to', 'work', 'on', 'any', 'problem', 'related', 'to', 'languages', '.']
['Natural', 'language', 'is', 'a', 'central', 'part', 'of', 'our', 'day', 'to', 'day', 'life', 'and', 'it', "'s", 'so', 'interesting', 'to', 'work', 'on', 'any', 'problem', 'related', 'to', 'languages']

10使用 NLTK 提取句子单词或短语的词干列表

from nltk.stem import PorterStemmer
 
st = PorterStemmer()
text = ['Where did he learn to dance like that?',
     'His eyes were dancing with humor.',
     'She shook her head and danced away',
     'Alex was an excellent dancer.']
 
output = []
for sentence in text:
     output.append(" ".join([st.stem(i) for i in sentence.split()]))
 
for item in output:
     print(item)
 
print("-" * 50)
print(st.stem('jumping'), st.stem('jumps'), st.stem('jumped'))

Output:

where did he learn to danc like that?
hi eye were danc with humor.
she shook her head and danc away
alex wa an excel dancer.
--------------------------------------------------
jump jump jump

11使用 NLTK 进行句子或短语词形还原

from nltk.stem import WordNetLemmatizer
 
wnl = WordNetLemmatizer()
text = ['She gripped the armrest as he passed two cars at a time.',
     'Her car was in full view.',
     'A number of cars carried out of state license plates.']
 
output = []
for sentence in text:
     output.append(" ".join([wnl.lemmatize(i) for i in sentence.split()]))
 
for item in output:
     print(item)
 
print("*" * 10)
print(wnl.lemmatize('jumps', 'n'))
print(wnl.lemmatize('jumping', 'v'))
print(wnl.lemmatize('jumped', 'v'))
 
print("*" * 10)
print(wnl.lemmatize('saddest', 'a'))
print(wnl.lemmatize('happiest', 'a'))
print(wnl.lemmatize('easiest', 'a'))

Output:

She gripped the armrest a he passed two car at a time.
Her car wa in full view.
A number of car carried out of state license plates.
**********
jump
jump
jump
**********
sad
happy
easy

12使用 NLTK 从文本文件中查找每个单词的频率

import nltk
from nltk.corpus import webtext
from nltk.probability import FreqDist
 
nltk.download('webtext')
wt_words = webtext.words('testing.txt')
data_analysis = nltk.FreqDist(wt_words)
 
# Let's take the specific words only if their frequency is greater than 3.
filter_words = dict([(m, n) for m, n in data_analysis.items() if len(m) > 3])
 
for key in sorted(filter_words):
     print("%s: %s" % (key, filter_words[key]))
 
data_analysis = nltk.FreqDist(filter_words)
 
data_analysis.plot(25, cumulative=False)

Output:

[nltk_data] Downloading package webtext to
[nltk_data]     C:\Users\amit\AppData\Roaming\nltk_data...
[nltk_data]   Unzipping corpora\webtext.zip.
1989: 1
Accessing: 1
Analysis: 1
Anyone: 1
Chapter: 1
Coding: 1
Data: 1
...

13从语料库中创建词云

import nltk
from nltk.corpus import webtext
from nltk.probability import FreqDist
from wordcloud import WordCloud
import matplotlib.pyplot as plt
 
nltk.download('webtext')
wt_words = webtext.words('testing.txt') # Sample data
data_analysis = nltk.FreqDist(wt_words)
 
filter_words = dict([(m, n) for m, n in data_analysis.items() if len(m) > 3])
 
wcloud = WordCloud().generate_from_frequencies(filter_words)
 
# Plotting the wordcloud
plt.imshow(wcloud, interpolation="bilinear")
 
plt.axis("off")
(-0.5, 399.5, 199.5, -0.5)
plt.show()

渐变在网页设计中几乎随处可见，渐变的背景、文字、按钮、图表等等，相比于纯色，渐变的颜色显得更加灵动自然。

今天我们要探讨的，就是SVG中的渐变绘制。

更多SVG系列文章：SVG基础知识、SVG动画、SVG中的Transform变换。

概述

或许你有使用css绘制渐变图形的经验，如果要绘制一个渐变的矩形，我们可以这样写：

<div></div>

.bg{ 
    height: 100px; 
    width: 200px; 
    //给元素设置渐变背景
    background: linear-gradient(#fb3,#58a); 
}

使用SVG绘图，颜色是通过设置元素的fill（填充颜色）和stroke（边框颜色）属性来实现。

<rect height="100" width="150" stroke="#45B649" stroke-width="2" fill="#DCE35B"></rect>

对于渐变颜色的设置，我们不能像在css中那样，直接写fill="linear-gradient(color1, color2)"，而要使用专门的渐变标签：<linearGradient>（线性渐变） 和 <radialGradient>（径向渐变）。

线性渐变

基础使用

先来看一个最简单的例子，如何绘制一个线性渐变的矩形：

<svg>
   <defs>
       <linearGradient id="gradient-test">
           <stop offset="0%" stop-color="#DCE35B" />
           <stop offset="100%" stop-color="#45B649" />
       </linearGradient>
   </defs>
   <rect height="100" width="150" fill="url(#gradient-test)"></rect>
</svg>

通常，我们将渐变标签<linearGradient>定义在<defs>元素中，<linearGradient>的id属性作为其唯一标识，方便后面需要使用的地方对其进行引用。

<linearGradient>中的<stop>标签定义渐变色的色标，它的offset 和 stop-color属性分别定义色标的位置和颜色值，它还有一个属性stop-opacity，设定stop-color颜色的透明度。

如果将色标的位置拉近：

<linearGradient id="gradient-1">
    <stop offset="30%" stop-color="#DCE35B" />
    <stop offset="70%" stop-color="#45B649" />
</linearGradient>

矩形左边的 30％ 区域被填充为 #DCE35B 实色，而右边 30％ 区域被填充为 #45B649 实色。真正的渐变只出现在矩形中间 40％ 的区域。

如果两个颜色都设为50%，就得到了两块均分矩形的实色。在这基础上，我们可以生成各种颜色的条纹图案。

渐变的方向和范围

在没有设置渐变方向的时候，渐变的默认方向是从左向右。

如果要设定渐变方向，要用到<linearGradient>的x1,y1,x2,y2这几个属性。

<linearGradient id="gradient-1" x1="0" y1="0" x2="0" y2="1">
    <stop offset="0%" stop-color="#DCE35B" />
    <stop offset="100%" stop-color="#45B649" />
</linearGradient>

我们知道，在平面上，方向一般由向量来表示。而渐变的方向由(x1,y1)（起点）和(x2,y2)（点）两个点定义的向量来表示。

在一般的应用场景中，x1,y1,x2,y2的取值范围是[0,1]（或者用百分数[0%, 100%]）。

对于矩形而言，不管矩形的长宽比例是多少，它的左上角对应的都是(0,0)，右下角则对应(1,1)。

x1="0" y1="0" x2="0" y2="1"表示从(0,0)到(0,1)，即渐变方向从矩形上边框垂直向下到下边框。

x1="0" y1="0.3" x2="0" y2="0.7"的情形如下：

可以看出，x1,y1,x2,y2不仅决定渐变的方向，还决定了渐变的范围，超出渐变范围的部分由起始或结束色标的颜色进行纯色填充。

案例1：渐变文字

<svg width="600" height="270">
    <defs>
        <linearGradient id="background">                          <!--背景渐变色-->
            <stop offset="0%" stop-color="#232526" />
            <stop offset="100%" stop-color="#414345" />
        </linearGradient>
        <linearGradient id="text-color" x1="0" y1="0" x2="0" y2="100%"> <!--文字渐变色-->
            <stop offset="0%" stop-color="#DCE35B" />
            <stop offset="100%" stop-color="#45B649" />
        </linearGradient>
    </defs>
    <rect x="0" y="0" height="100%" width="100%" fill="url(#background)"></rect>
    <text y="28%" x="28%">试问闲情都几许？</text>
    <text y="44%" x="28%">一川烟草</text>
    <text y="60%" x="28%">满城风絮</text>
    <text y="76%" x="28%">梅子黄时雨</text>
</svg>
<style>
    text{
        font-size: 32px;
        letter-spacing:5px;
        fill:url(#text-color);     //文字的填充使用渐变色
    }
</style>

文字的填充，我们用了垂直方向的渐变色，对于每一行文字，都是从黄色渐变到绿色。

如果要将这几行文字作为一个整体来设置渐变色，像下面这样，应该怎样设置呢？

这就要用到gradientUnits属性了。

gradientUnits属性定义渐变元素（<linearGradient>、<radialGradient>）要参考的坐标系。 它有两个取值：objectBoundingBox 和 userSpaceOnUse。

默认值是objectBoundingBox，它定义渐变元素的参考坐标系为引用该渐变的SVG元素，渐变的起止、范围、方向都是基于引用该渐变的SVG元素（之前的<rect>，这里的<text>）自身，比如这里的每一个<text>元素的左上角都是渐变色的（0，0）位置，右下角都是（100%，100%）。

userSpaceOnUse则以当前的SVG元素视窗区域（viewport） 为渐变元素的参考坐标系。也就是SVG元素的左上角为渐变色的（0，0）位置，右下角为（100%，100%）。

<svg height="200" width="300"> 
    <defs>
        <!-- 定义两个渐变，除了gradientUnits，其他配置完全相同 -->
        <linearGradient id="gradient-1" x1="0" y1="0" x2="100%" y2="100%" gradientUnits="objectBoundingBox">
            <stop offset="0%" stop-color="#C6FFDD" />
            <stop offset="100%" stop-color="#f7797d" />
        </linearGradient>
        <linearGradient id="gradient-2" x1="0" y1="0" x2="100%" y2="100%" gradientUnits="userSpaceOnUse">
            <stop offset="0%" stop-color="#C6FFDD" />
            <stop offset="100%" stop-color="#f7797d" />
        </linearGradient>
    </defs>
    <rect x="0" y="0" ></rect>
    <rect x="150" y="0" ></rect>
    <rect x="0" y="100" ></rect>
    <rect x="150" y="100" ></rect>
</svg>
rect{
    height: 100px;
    width: 150px;
    fill: url(#gradient-1); //四个矩形都填充渐变色，下面左图为gradient-1，右图为gradient-2。
}

gradientUnits：userSpaceOnUse 适用于画布中有多个图形，但每个图形都是整体渐变中的一部分这样的场景。值得注意的是，当gradientUnits="userSpaceOnUse"时，x1,y1,x2,y2的取值只有用%百分数这样的相对单位才表示比例，如果取值为x2="1"，那就真的是1px，这一点与gradientUnits="objectBoundingBox"是不同的。

案例2：渐变的环形进度条

在上一篇文章中，我们实现了可交互的环形进度条：

这里我们将其改造成渐变的环形进度条。

使用渐变色作为描边stroke的颜色，中间使用一个白色透明度渐变的圆，增加立体感。

<!--改动部分的代码-->
<svg height="240" width="240" viewBox="0 0 100 100">
    <defs>
        <linearGradient id="circle">
            <stop offset="0%" stop-color="#A5FECB" />
            <stop offset="50%" stop-color="#20BDFF" />
            <stop offset="100%" stop-color="#5433FF" />
        </linearGradient>
        <linearGradient id="center">
            <stop offset="0%" stop-color="rgba(255,255,255,0.25)" />
            <stop offset="100%" stop-color="rgba(255,255,255,0.08)" />
         </linearGradient>
     </defs>
     <!--灰色的背景圆环-->
     <circle cx="50" cy="50" r="40" stroke-width="12" stroke="#eee" fill="none"></circle>
     <!--渐变的动态圆环-->
     <circle       
         
         cx="50" cy="50" r="40" 
         transform="rotate(-90 50 50)"
         stroke-width="12" 
         stroke="url(#circle)" 
         fill="none" 
         stroke-linecap="round"
         stroke-dasharray="251"></circle>
     <!--白色透明度渐变的圆，增加立体感-->
     <circle cx="50" cy="50" r="40" fill="url(#center)"></circle>
</svg> 

径向渐变

基础使用

径向渐变是色彩从中心点向四周辐射的渐变。

<svg height="300" width="200">

    <defs>

        <radialGradient id="test">

            <stop offset="0%" stop-color="#e1eec3" />

            <stop offset="100%" stop-color="#f05053" />

        </radialGradient>

    </defs>

    <rect fill="url(#test)" x="10" y="10" width="150" height="150"></rect>

</svg>

和线性渐变的结构类似，我们将径向渐变标签<radialGradient>定义在<defs>元素中，其id属性作为其唯一标识，以便后面需要使用的地方对其进行引用。

<radialGradient>中的<stop>标签定义渐变色的色标，它的offset 和 stop-color属性分别定义色标的位置和颜色值。

渐变的范围

径向渐变的范围由<radialGradient>的cx,cy,r三个属性共同决定，它们的默认值均是50%，是相对值，相对的是引用该渐变的SVG元素。

cx和cy定义径向渐变范围的圆心，（50%, 50%）意味着是引用该渐变的SVG元素的中心。r设定渐变范围的半径，当r=50%时，说明渐变范围的半径在x和y方向的分别是引用该渐变的SVG元素width和height的50%。

//当rect高度减小时，渐变在y方向的半径也减小。

<rect fill="url(#test)" x="10" y="10" width="150" height="100"></rect>

在cx,cy,r都取默认值的情况下，径向渐变的范围刚好覆盖引用该渐变的SVG元素。实际开发中，我们常常需要调整渐变范围。

渐变起点的移动

在默认情况下，渐变起点都是在渐变范围的中心，如果想要不那么对称的渐变，就需要改变渐变起点的位置。

<radialGradient>的fx和fy就是用来设置渐变色起始位置的。fx和fy的值也是相对值，相对的也是引用该渐变的SVG元素。

我们可以设定渐变的范围（cx,cy,r），也可以设定渐变的起点位置（fx,fy）。但是如果渐变的起点位置在渐变的范围之外，会出现一些我们不想要的效果。

测试代码如下，可直接运行：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        body{
            display: flex;
            justify-content: center;
        }
        .control{
            margin-top:20px;
        }
    </style>
</head>
<body>
    <svg height="300" width="200">
        <defs>
            <radialGradient  id="test">
                <stop offset="0%" stop-color="#e1eec3" />
                <stop offset="100%" stop-color="#f05053" />
            </radialGradient>
        </defs>
        <rect fill="url(#test)" x="10" y="10" width="150" height="150"></rect>
    </svg>
    <div>
        <div>cx：<input value="50" type="range" min="0" max="100" id="cx" /></div>
        <div>cy：<input value="50" type="range" min="0" max="100" id="cy" /></div>
        <div>r：<input value="50" type="range" min="0" max="100" id="r" /></div>
        <div>fx：<input value="50" type="range" min="0" max="100" id="fx" /></div>
        <div>fy：<input value="50" type="range" min="0" max="100" id="fy" /></div>
    </div>
    <script>
        const rg = document.getElementById('test')
        document.querySelectorAll('input').forEach((elem) => {
            elem.addEventListener('change', (ev) => {
                rg.setAttribute(ev.target.id, ev.target.value+'%')
            })
        })
    </script>
</body>
</html>

综合案例：透明的泡泡

最后我们用线性渐变和径向渐变画一个泡泡。

分析：

• 背景是一个用线性渐变填充的矩形。

• 泡泡分为三个部分：由径向渐变填充的一个圆形和两个椭圆。

这里的径向渐变主要是颜色透明度的渐变。设定颜色透明度，我们可以直接指定stop-color的值为rgba，也可以通过stop-opacity来设定stop-color颜色的透明度。

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
    <style>
        .bubble{
            animation: move 5s linear infinite;
            animation-direction:alternate;
        }
        //泡泡的运动
        @keyframes move {
            0%{
                transform: translate(0,0);
            }
            50%{
                transform: translate(250px,220px);
            }
            100%{
                transform: translate(520px,50px);
            }
        }
    </style>
</head>
<body>
    <svg height="400" width="700">
        <defs>
            <!--背景的线性渐变-->
            <linearGradient id="background">
                <stop offset="0%" stop-color="#DCE35B" />
                <stop offset="100%" stop-color="#45B649" />
            </linearGradient>
            <!--光斑的径向渐变，通过fx、fy设置不对称的渐变-->
            <radialGradient id="spot" fx="50%" fy="30%">
                <stop offset="10%" stop-color="white" stop-opacity=".7"></stop>  
                <stop offset="70%" stop-color="white" stop-opacity="0"></stop>
            </radialGradient>
            <!--泡泡本体的径向渐变-->
            <radialGradient id="bubble">
                <stop offset="0%" stop-color="rgba(255,255,255,0)" ></stop>  
                <stop offset="80%" stop-color="rgba(255,255,255,0.1)" ></stop>
                <stop offset="100%" stop-color="rgba(255,255,255,0.42)"></stop>
            </radialGradient>
        </defs>
        <rect fill="url(#background)" width="100%" height="100%"></rect>
        <g>
            <circle cx="100" cy="100" r="70" fill="url(#bubble)"></circle>
            <ellipse rx="50" ry="20" cx="80" cy="60" fill="url(#spot)" transform="rotate(-25, 80, 60)" ></ellipse>
            <ellipse rx="20" ry="10" cx="140" cy="130" fill="url(#spot)" transform="rotate(125, 140, 130)" ></ellipse>
        </g>   
    </svg>
</body>
</html>

以上渐变配色均来自网站： uigradients.com/

作者：Alaso
来源：juejin.cn/post/7098637240825282591

概要

本文是学习B站毛剑老师的《API 工程化分享》学习笔记，分享了 gRPC 中的 Proto 管理方式，Proto 分仓源码方式，Proto 独立同步方式，Proto git submodules 方式，Proto 项目布局，Proto Errors，服务端和客户端的 Proto Errors，Proto 文档等等

目录

• Proto IDL Management

• IDL Project Layout

• IDL Errors

• IDL Docs

Proto IDL Management

• Proto IDL

• Proto 管理方式

• Proto 分仓源码方式

• Proto 独立同步方式

• Proto git submodules 方式

Proto IDL

gRPC 从协议缓冲区使用接口定义语言 (IDL)。协议缓冲区 IDL 是一种与平台无关的自定义语言，具有开放规范。 开发人员会创作 .proto 文件，用于描述服务及其输入和输出。 然后，这些 .proto 文件可用于为客户端和服务器生成特定于语言或平台的存根，使多个不同的平台可进行通信。 通过共享 .proto 文件，团队可生成代码来使用彼此的服务，而无需采用代码依赖项。

Proto 管理方式

煎鱼的一篇文章：真是头疼，Proto 代码到底放哪里？

文章中经过多轮讨论对 Proto 的存储方式和对应带来的优缺点，一共有如下几种方案：

• 代码仓库

• 独立仓库

• 集中仓库

• 镜像仓库

镜像仓库

在我自己的微服务仓库里面，有一个 Proto 目录，就是放我自己的 Proto，然后在我提交我的微服务代码到主干或者某个分支的时候，它可能触发一个 mirror 叫做自动同步，会镜像到这个集中的仓库，它会帮你复制过去，相当于说我不需要把我的源码的 Proto 开放给你，同时还会自动复制一份到集中的仓库

在煎鱼的文章里面的集中仓库还是分了仓库的，B站大仓是一个统一的仓库。为什么呢？因为比方像谷歌云它整个对外的 API 会在一个仓库，不然你让用户怎么找？到底要去哪个 GitHub 下去找？有这么多 project 怎么找？根本找不到，应该建统一的一个仓库，一个项目就搞定了

我们最早衍生这个想法是因为无意中看到了 Google APIs 这个仓库。大仓可以解决很多问题，包括高度代码共享，其实对于 API 文件也是一样的，集中在一个 Repo 里面，很方便去检索，去查阅，甚至看文档，都很方便

我们不像其他公司喜欢弄一个 UI 的后台，我们喜欢 Git，它很方便做扩展，包括 CICD 的流程，包括 coding style 的 check，包括兼容性的检测，包括 code review 等等，你都可以基于 git 的扩展，gitlab 的扩展，GitHub 的一些 actions，做很多很多的工作

Proto 分仓源码方式

过去为了统一检索和规范 API，我们内部建立了一个统一的 bapis 仓库，整合所有对内对外 API。它只是一个申明文件。

• API 仓库，方便跨部门协作；

• 版本管理，基于 git 控制；

• 规范化检查，API lint；

• API design review，变更 diff；

• 权限管理，目录 OWNERS;

集中式仓库最大的风险是什么呢？是谁都可以更改

大仓的核心是放弃了读权限的管理，针对写操作是有微观管理的，就是你可以看到我的 API 声明，但是你实际上调用不了，但是对于迁入 check in，提到主干，你可以在不同层级加上 owner 文件，它里面会描述谁可以合并代码，或者谁负责 review，两个角色，那就可以方便利用 gitlab 的 hook 功能，然后用 owner 文件做一些细粒度的权限管理，针对目录级别的权限管理

最终你的同事不能随便迁入，就是说把文件的写权限，merge 权限关闭掉，只允许通过 merge request 的评论区去回复一些指令，比方说 lgtm（looks good to me），表示 review 通过，然后你可以回复一个 approve，表示这个代码可以被成功 check in，这样来做一些细粒度的权限检验

怎么迁入呢？我们的想法是在某一个微服务的 Proto 目录下，把自己的 Proto 文件管理起来，然后自动同步进去，就相当于要写一个插件，可以自动复制到 API 仓库里面去。做完这件事情之后，我们又分了 api.go，api.java，git submodule，就是把这些代码使用 Google protobuf，protoc 这个编译工具生成客户端的调用代码，然后推到另一个仓库，也就是把所有客户端调用代码推到一个源码仓库里面去

Proto 独立同步方式

移动端采用自定义工具方式，在同步代码阶段，自动更新最新的 proto 仓库到 worksapce 中，之后依赖 bazel 进行构建整个仓库

• 业务代码中不依赖 target 产物，比如 objective-c 的 .h/.a 文件，或者 Go 的 .go 文件（钻石依赖、proto 未更新问题）

源码依赖会引入很多问题

• 依赖信息丢失

• proto 未更新

• 钻石依赖

依赖信息丢失

在你的工程里面依赖了其他服务，依赖信息变成了源码依赖，你根本不知道依赖了哪个服务，以前是 protobuf 的依赖关系，现在变成了源码依赖，服务依赖信息丢失了。未来我要去做一些全局层面的代码盘点，比方说我要看这个服务被谁依赖了，你已经搞不清楚了，因为它变成了源码依赖

proto 未更新

如果我的 proto 文件更新了，你如何保证这个人重新生成了 .h/.a 文件，因为对它来说这个依赖信息已经丢失，为什么每次都要去做这个动作呢？它不会去生成 .h/.a 文件

钻石依赖

当我的 A 服务依赖 B 服务的时候，通过源码依赖，但是我的 A 服务还依赖 C 服务，C 服务是通过集中仓库 bapis 去依赖的，同时 B 和 C 之间又有一个依赖关系，那么这个时候就可能出现对于 C 代码来说可能会注册两次，protobuf 有一个约束就是说重名文件加上包名是不允许重复的，否则启动的时候就会 panic，有可能会出现钻石依赖

• A 依赖 B

• A 依赖 C

• A 和 B 是源码依赖

• A 和 C 是 proto 依赖

• B 和 C 之间又有依赖

那么它的版本有可能是对不齐的，就是有风险的，这就是为什么 google basic 构建工具把 proto 依赖的名字管理起来，它并没有生成 .go 文件再 checkin 到仓库里面，它不是源码依赖，它每一次都要编译，每次都要生成 .go 文件的原因，就是为了版本对齐

Proto git submodules 方式

经过多次讨论，有几个核心认知：

• proto one source of truth，不使用镜像方式同步，使用 git submodules 方式以仓库中目录形式来承载；

• 本地构建工具 protoc 依赖 go module 下的相对路径即可；

• 基于分支创建新的 proto，submodules 切换分支生成 stub 代码，同理 client 使用联调切换同一个分支；

• 维护 Makefile，使用 protoc + go build 统一处理；

• 声明式依赖方式，指定 protoc 版本和 proto 文件依赖（基于 BAZEL.BUILD 或者 Yaml 文件）

proto one source of truth

如果只在一个仓库里面，如果只有一个副本，那么这个副本就是唯一的真相并且是高度可信任的，那如果你是把这个 proto 文件拷来拷去，最终就会变得源头更新，拷贝的文件没办法保证一定会更新

镜像方式同步

实际上维护了本地微服务的目录里面有一个 protobuf 的定义，镜像同步到集中的仓库里面，实际上是有两个副本的

使用 git submodules 方式以仓库中目录形式来承载

git submodules 介绍

子模块允许您将 Git 存储库保留为另一个 Git 存储库的子目录。这使您可以将另一个存储库克隆到您的项目中并保持您的提交分开。

图中 gateway 这个目录就是以本地目录的形式，但是它是通过 git submodules 方式给承载进来的

如果公司内代码都在一起，api 的定义都在一起，那么大仓绝对是最优解，其次才是 git submodules，这也是 Google 的建议

我们倾向于最终 proto 的管理是集中在一个仓库里面，并且只有一份，不会做任何的 copy，通过 submodules 引入到自己的微服务里面，也就是说你的微服务里面都会通过 submodules 把集中 API 的 git 拷贝到本地项目里面，但是它是通过 submodeles 的方式来承载的，然后你再通过一系列 shell 的工具让你的整个编译过程变得更简单

IDL Project Layout

Proto Project Layout

在统一仓库中管理 proto，以仓库为名

根目录：

• 目录结构和 package 对齐；

• 复杂业务的功能目录区分；

• 公共业务功能：api、rpc、type;

目录结构和 package 对齐

我们看一下 googleapis 大量的 api 是如何管理的？

第一个就是在 googleapis 这个项目的 github 里面，它的第一级目录叫 google，就是公司名称，第二个目录是它的业务域，业务的名称

目录结构和 protobuf 的包名是完全对齐的，方便检索

复杂业务的功能目录区分

v9 目录下分为公共、枚举、错误、资源、服务等等

公共业务功能：api、rpc、type

在 googleapis 的根目录下还有类似 api、rpc、type 等公共业务功能

IDL Errors

• Proto Errors

• Proto Errors：Server

• Proto Errors：Client

Proto Errors

• 使用一小组标准错误配合大量资源

• 错误传播

用简单的协议无关错误模型，这使我们能够在不同的 API，API 协议（如 gRPC 或 HTTP）以及错误上下文（例如，异步，批处理或工作流错误）中获得一致的体验。

使用一小组标准错误配合大量资源

服务器没有定义不同类型的“找不到”错误，而是使用一个标准 google.rpc.Code.NOT_FOUND 错误代码并告诉客户端找不到哪个特定资源。状态空间变小降低了文档的复杂性，在客户端库中提供了更好的惯用映射，并降低了客户端的逻辑复杂性，同时不限制是否包含可操作信息。

我们以前自己的业务代码关于404，关于某种资源找不到的错误码，定义了上百上千个，请问为什么大家在设计 HTTP restful 或者 grpc 接口的时候不用人家标准的状态码呢？人家有标准的404，或者 not found 的状态码，用状态码去映射一下通用的错误信息不好吗？你不可能调用一个接口，返回几十种具体的错误码，你根本对于调用者来说是无法使用的。当我的接口返回超过3个自定义的错误码，你就是面向错误编程了，你不断根据错误码做不同的处理，非常难搞，而且你每一个接口都要去定义

这里的核心思路就是使用标准的 HTTP 状态码，比方说500是内部错误，503是网关错误，504是超时，404是找不到，401是参数错误，这些都是通用的，非常标准的一些状态码，或者叫错误码，先用它们，因为不是所有的错误都需要我们叫业务上 hint，进一步处理，也就是说我调你的服务报错了，我大概率是啥都不做的，因为我无法纠正服务端产生的一个错误，除非它是带一些业务逻辑需要我做一些跳转或者做一些特殊的逻辑，这种不应该特别多，我觉得两个三个已经非常多了

所以说你会发现大部分去调用别人接口的时候，你只需要用一个通用的标准的状态码去映射，它会大大降低客户端的逻辑复杂性，同时也不限制说你包含一些可操作的 hint 的一些信息，也就是说你可以包含一些指示你接下来要去怎么做的一些信息，就是它不冲突

错误传播

如果您的 API 服务依赖于其他服务，则不应盲目地将这些服务的错误传播到您的客户端。

举个例子，你现在要跟移动端说我有一个接口，那么这个接口会返回哪些错误码，你始终讲不清楚，你为什么讲不清楚呢？因为我们整个微服务的调用链是 A 调 B，B 调 C，C 调 D，D 的错误码会一层层透传到 A，那么 A 的错误码可能会是 ABCD 错误码的并集，你觉得你能描述出来它返回了哪些错误码吗？根本描述不出来

所以对于一个服务之间的依赖关系不应该盲目地将下游服务产生的这些错误码无脑透传到客户端，并且曾经跟海外很多公司，像 Uber，Twitter，Netflix，跟他们很多的华人的朋友交流，他们都不建议大家用这种全局的错误码，比方 A 部门用 01 开头，B 部门用 02 开头，类似这样的方式去搞所谓的君子契约，或者叫松散的没有约束的脆弱的这种约定

在翻译错误时，我们建议执行以下操作：

• 隐藏实现详细信息和机密信息

• 调整负责该错误的一方。例如，从另一个服务接收 INVALID_ARGUMENT 错误的服务器应该将 INTERNAL 传播给它自己的调用者。

比如你返回的错误码是4，代表商品已下架，我对这个错误很感兴趣，但是错误码4 在我的项目里面已经被用了，我就把它翻译为我还没使用的错误码6，这样每次翻译的时候就可以对上一层你的调用者，你就可以交代清楚你会返回错误码，因为都是你定义的，而且是你翻译的，你感兴趣的才翻译，你不感兴趣的通通返回 500 错误，就是内部错误，或者说 unknown，就是未知错误，这样你每个 API 都能讲清楚自己会返回哪些错误码

在 grpc 传输过程中，它会要求你要实现一个 grpc states 的一个接口的方法，所以在 Kraots 的 v2 这个工程里面，我们先用前面定义的 message Error 这个错误模型，在传输到 grpc 的过程中会转换成 grpc 的 error_details.proto 文件里面的 ErrorInfo，那么在传输到 client 的时候，就是调用者请求服务，service 再返回给 client 的时候再把它转换回来

也就是说两个服务使用一个框架就能够对齐，因为你是基于 message Error 这样的错误模型，这样在跨语言的时候同理，经过 ErrorInfo 使用同样的模型，这样就解决了跨语言的问题，通过模型的一致性

Proto Errors：Server

errors.proto 定义了 Business Domain Error 原型，使用最基础的 Protobuf Enum，将生成的源码放在 biz 大目录下，例如 biz/errors

• biz 目录中核心维护 Domain，可以直接依赖 errors enum 类型定义；

• data 依赖并实现了 biz 的 Reporisty/ACL，也可以直接使用 errors enum 类型定义；

• TODO：Kratos errors 需要支持 cause 保存，支持 Unwrap();

在某一个微服务工程里面，errors.proto 文件实际上是放在 API 的目录定义，之前讲的 API 目录定义实际上是你的服务里面的 API 目录，刚刚讲了一个 submodules，现在你可以理解为这个 API 目录是另外一个仓库的 submodules，最终你是把这些信息提交到那个 submodules，然后通过 reference 这个 submodules 获取到最新的版本，其实你可以把它打成一个本地目录，就是说我的定义声明是在这个地方

这个 errors.proto 文件其实就列举了各种错误码，或者叫错误的字符串，我们其实更建议大家用字符串，更灵活，因为一个数字没有写文档前你根本不知道它是干啥的，如果我用字符串的话，我可以 user_not_found 告诉你是用户找不到，但是我告诉你它是3548，你根本不知道它是什么含义，如果我没写文档的话

所以我们建议使用 Protobuf Enum 来定义错误的内容信息，定义是在这个地方，但是生成的代码，按照 DDD 的战术设计，属于 Domain，因为业务设计是属于领域的一个东西，Domain 里面 exception 它最终的源码会在哪？会在 biz 的大目录下，biz 是 business 的缩写，就是在业务的目录下，举个例子，你可以放在 biz 的 errors 目录下

有了这个认知之后我们会做三个事情

首先你的 biz 目录维护的是领域逻辑，你的领域逻辑可以直接依赖 biz.errors 这个目录，因为你会抛一些业务错误出去

第二，我们的 data 有点像 DDD 的 infrastructure，就是所谓的基础设施，它依赖并实现了 biz 的 repository 和 acl，repository 就是我们所谓的仓库，acl 是防腐层

因为我们之前讲过它的整个依赖倒置的玩法，就是让我们的 data 去依赖 biz，最终让我们的 biz 零依赖，它不依赖任何人，也不依赖基础设施，它把 repository 和 acl 的接口定义放在 biz 自己目录下，然后让 data 依赖并实现它

也就是说最终我这个 data 目录也可以依赖 biz 的 errors，我可能通过查 mysql，结果这个东西查不到，会返回一个 sql no rows，但肯定不会返回这个错误，那我就可以用依赖 biz 的这个 errors number，比如说 user_not_found，我把它包一个 error 抛出去，所以它可以依赖 biz 的 errors

目前 Kratos 还不支持根因保存，根因保存是什么呢？刚刚说了你可能是 mysql 报了一个内部的错误，这个内部错误你实际上在最上层的传输框架，就是 HTTP 和 grpc 的 middleware 里面，你可能会把日志打出来，就要把堆栈信息打出来，那么根因保存就是告诉你最底层发生的错误是什么

不支持 Unwrap 就是不支持递归找根因，如果支持根因以后呢，就可以让 Kratos errors 这个 package 可以把根因传进去，这样子既能搞定我们 go 的 wrap errors，同时又支持我们的状态码和 reason，大类错误和小类错误，大类错误就是状态码，小类错误就是我刚刚说的用 enum 定义的具体信息，比方说这个商品被下架，这种就不太好去映射一个具体的错误码，你可能是返回一个500，再带上一个 reason，可能是这样的一个做法

Proto Errors：Client

从 Client 消费端只能看到 api.proto 和 error.proto 文件，相应的生成的代码，就是调用测的 api 以及 errors enum 定义

• 使用 Kratos errors.As() 拿到具体类型，然后通过 Reason 字段进行判定；

• 使用 Kratos errors.Reason() helper 方法（内部依赖 errors.As）快速判定；

拿到这两个文件之后你可以生成相应代码，然后调用 api

举个例子，图中的代码是调用服务端 grpc 的某一个方法，那么我可能返回一个错误，我们可以用 Kratos 提供的一个 Reason 的 short car，一个快捷的方法，然后把 error 传进去，实际上在内部他会调用标准库的 error.As，把它强制转换成 Kratos 的 errors 类型，然后拿到里面的 Reason 的字段，然后再跟这个枚举值判定，这样你就可以判定它是不是具体的一个业务错误

第二种写法你可以拿到原始的我们 Kratos 的 Error 模型，就是以下这个模型

new 出来之后用标准库的 errors.As 转换出来，转换出来之后再用 switch 获取它里面的 reason 字段，然后可以写一些业务逻辑

这样你的 client 代码跨语言，跨传输，跨协议，无论是 grpc，http，同样是用一样的方式去解决

IDL Docs

• Proto Docs

Proto Docs

基于 openapi 插件 + IDL Protobuf 注释（IDL 即定义，IDL 即代码，IDL 即文档），最终可以在 Makefile 中使用 make api 生成 openapi.yaml，可以在 gitlab/vscode 插件直接查看

• API Metadata 元信息用于微服务治理、调试、测试等；

因为我们可以在 IDL 文件上面写上大量的注释，那么当讲到这个地方，你就明白了 IDL 有什么样的好处？

IDL 文件它既定义，同时又是代码，也就是说你既做了声明，然后使用 protoc 可以去生成代码，并且是跨语言的代码，同时 IDL 本身既文档，也就是说它才真正满足了 one source of truth，就是唯一的事实标准

最终你可以在 Makefile 中定义一个 api 指令，然后生成一个 openapi.yaml，以前是 swagger json，现在叫 openapi，用 yaml 声明

生成 yaml 文件以后，现在 gitlab 直接支持 openapi.yaml 文件，所以你可以直接打开 gitlab 去点开它，就能看到这样炫酷的 UI，然后 VSCode 也有一个插件，你可以直接去查看

还有一个很关键的点，我们现在的 IDL 既是定义，又是代码，又是文档，其实 IDL 还有一个核心作用，这个定义表示它是一个元信息，是一个元数据，最终这个 API 的 mate data 元信息它可以用于大量的微服务治理

因为你要治理的时候你比方说对每个服务的某个接口进行路由，进行熔断进行限流，这些元信息是哪来的？我们知道以前 dubbo 2.x，3.x 之前都是把这些元信息注册到注册中心的，导致整个数据中心的存储爆炸，那么元信息在哪？

我们想一想为什么 protobuf 是定义一个文件，然后序列化之后它比 json 要小？因为它不是自描述的，它的定义和序列化是分开的，就是原始的 payload 是没有任何的定义信息的，所以它可以高度的compressed，可被压缩，或者说叫更紧凑

所以说同样的道理，IDL 的定义和它的元信息，和生成代码是分开的话，意味着你只要有 one source of truth 这份唯一的 pb 文件，基于这个 pb 文件，你就有办法把它做成一个 api 的 metadata 的服务，你就可以用于做微服务的治理

你可以选一个服务，然后看它有些什么接口，然后你可以通过一个管控面去做熔断、限流等功能，然后你还可以基于这个元信息去调试，你做个炫酷的 UI 可以让它有一些参数，甚至你可以写一些扩展，比方说这个字段叫 etc，建议它是什么样的值，那么你在渲染 UI 的时候可以把默认值填进去，那你就很方便做一些调试，甚至包含测试，你基于这个 api 去生成大量的 test case

参考

API 工程化分享 http://www.bilibili.com/video/BV17m…

接口定义语言 docs.microsoft.com/zh-cn/dotne…

真是头疼，Proto 代码到底放哪里？ mp.weixin.qq.com/s/cBXZjg_R8…

git submodules git-scm.com/book/en/v2/…

kratos github.com/go-kratos/k…

error_details.proto github.com/googleapis/…

pkg/errors github.com/pkg/errors

Modifying gRPC Services over Time

作者：郑子铭_
来源：juejin.cn/post/7097866377460973599

前言

写过hybrid的同学，想必都会遇到这样的需求，如果用户安装了自己的APP，就打开APP或跳转到APP内某个页面，如果没安装则引导用户到对应页面或应用商店下载。这里就涉及到了H5与Native之间的交互，为什么H5能够唤起APP并且跳转到对应的页面？

就算你没写过想必也体验过，最常见的就是抖音里面的一些广告，如果你点击了广告，他判断你手机装了对应APP，那他就会去打开那个APP，如果没安装，他会帮你跳转到应用商店去下载，这个还算人性化一点的，有些直接后台给你去下载，你完全无感知。

哈哈，是不是觉得这种技术很神奇，今天我们就一起来看看它是如何实现的～

如果这篇文章有帮助到你，❤️关注+点赞❤️鼓励一下作者，文章公众号首发，关注 前端南玖 第一时间获取最新文章～

唤端体验

实现之前我们先简单体验一下什么是唤端

从上图中，我们可以看到在浏览器中我们点击打开知乎，系统会提示我们是否在知乎中打开，当我们点击打开时，知乎就被打开了，这就是一个简单的唤端体验。

有了这项技术我们就可以实现H5唤起APP应用了，现阶段的引流方式大都得益于这种技术，比如广告投放、用户拉新、引流等。

唤端技术

体验过后，我们就来聊一聊它的实现技术是怎样的，唤端技术我们也称之为deep link技术。当然，不同平台的实现方式有些不同，一般常见的有这几种，分别是：

• URL Scheme（通用）

• Universal Link （iOS）

• App Link、Chrome Intents（android）

URL Scheme（通用）

这种方式是一种比较通用的技术，各平台的兼容性也很好，它一般由协议名、路径、参数组成。这个一般是由Native开发的同学提供，我们前端同学再拿到这个scheme之后，就可以用来打开APP或APP内的某个页面了。

URL Scheme 组成

[scheme:][//authority][path][?query][#fragment]

常用APP的 URL Scheme

打开方式

常用的有以下这几种方式

• 直接通过window.location.href跳转

window.location.href = 'zhihu://'

• 通过iframe跳转

const iframe = document.createElement('iframe')
iframe.style.display = 'none'
iframe.src = 'zhihu://'
document.body.appendChild(iframe)

• 直接使用a标签进行跳转

• 通过js bridge来打开

window.miduBridge.call('openAppByRouter', {url: 'zhihu://'})

判断是否成功唤起

当用户唤起APP失败时，我们希望可以引导用户去进行下载。那么我们怎么才能知道当前APP是否成功唤起呢？

我们可以监听当前页面的visibilitychange事件，如果页面隐藏，则表示唤端成功，否则唤端失败，跳转到应用商店。

OK，我们尝试来实现一下：

首先我手机上并没有安装腾讯微博，所以也就无法唤起，我们让他跳到应用商店对应的应用下载页，这里就用淘宝的下载页来代替一下～

<template>
  <div class="open_app">
      <div class="open_app_title">前端南玖唤端测试Demo</div>
      <div class="open_btn" @click="open">打开腾讯微博</div>
  </div>
</template>

<script>
let timer
export default {
    name: 'openApp',
    methods: {
        watchVisibility() {
            window.addEventListener('visibilitychange', () => {
                // 监听页面visibility
                if(document.hidden) {
                    // 如果页面隐藏了，则表示唤起成功，这时候需要清除下载定时器
                    clearTimeout(timer)
                }
            })
        },
        open() {
            timer = setTimeout(() => {
              // 没找到腾讯微博的下载页，这里暂时以淘宝下载页代替
                window.location.href = 'http://apps.apple.com/cn/app/id387682726'
            }, 3000)
            window.location.href = 'TencentWeibo://'
        }
    }
}
</script>

<style lang="less">
.open_app_title {
    font-size: (20/@rem);
}
.open_btn{
    margin-top:(20/@rem);
    padding:(10/@rem) 0;
    border-radius: (8/@rem);
    background: salmon;
    color: #fff;
    font-size: (16/@rem);
}
</style>

适用性

URL Scheme 这种方式兼容性好，无论安卓或者 iOS 都能支持，是目前最常用的方式。从上图我们能够看出它也有一些比较明显的缺点：

• 无法准确判断是否唤起成功，因为本质上这种方式就是打开一个链接，并且还不是普通的 http 链接，所以如果用户没有安装对应的 APP，那么尝试跳转后在浏览器中会没有任何反应，通过定时器来引导用户跳到应用商店，但这个定时器的时间又没有准确值，不同手机的唤端时间也不同，我们只能大概的估计一下它的时间来实现，一般设为3000ms左右比较合适；

• 从上图中我们可以看到会有一个弹窗提示你是否在对应 APP中打开，这就可能会导致用户流失；

• 有 URL Scheme 劫持风险，比如有一个 app 也向系统注册了 zhihu:// 这个 scheme ，唤起流量可能就会被劫持到这个 app 里；

• 容易被屏蔽，app 很轻松就可以拦截掉通过 URL Scheme 发起的跳转，比如微信内经常能看到一些被屏蔽的现象。

Universal Link （iOS）

Universal Link 是在iOS 9中新增的功能，使用它可以直接通过https协议的链接来打开 APP。 它相比前一种URL Scheme的优点在于它是使用https协议，所以如果没有唤端成功，那么就会直接打开这个网页，不再需要判断是否唤起成功了。并且使用 Universal Link，不会再弹出是否打开的弹出，对用户来说，唤端的效率更高了。

原理

• 在 APP 中注册自己要支持的域名；

• 在自己域名的根目录下配置一个 apple-app-site-association 文件即可。（具体的配置前端同学不用关注，只需与iOS同学确认好支持的域名即可）

打开方式

openByUniversal () {
  // 打开知乎问题页
  window.location.href = 'https://oia.zhihu.com/questions/64966868'
  // oia.zhihu.com
},

适用性

• 相对 URL Scheme，universal links 有一个较大优点是它唤端时没有弹窗提示是否打开，提升用户体验，可以减少一部分用户流失；

• 无需关心用户是否安装对应的APP，对于没有安装的用户，点击链接就会直接打开对应的页面，因为它也是http协议的路径，这样也能一定程度解决 URL Scheme 无法准确判断唤端失败的问题；

• 只能够在iOS上使用

• 只能由用户主动触发

App Link、Chrome Intents（Android）

App Link

在2015年的Google I/O大会上，Android M宣布了一个新特性：App Links让用户在点击一个普通web链接的时候可以打开指定APP的指定页面，前提是这个APP已经安装并且经过了验证，否则会显示一个打开确认选项的弹出框，只支持Android M以上系统。

App Links的最大的作用，就是可以避免从页面唤醒App时出现的选择浏览器选项框;

前提是必须注册相应的Scheme，就可以实现直接打开关联的App。

• App links在国内的支持还不够，部分安卓浏览器并不支持跳转至App，而是直接在浏览器上打开对应页面。

• 系统询问是否打开对应App时，假如用户选择“取消”并且选中了“记住此操作”，那么用户以后就无法再跳转App。

Chrome Intents

• Chrome Intent 是 Android 设备上 Chrome 浏览器中 URI 方案的深层链接替代品。

• 如果 APP 已安装，则通过配置的 URI SCHEME 打开 APP。

• 如果 APP 未安装，配置了 fallback url 的跳转 fallback url，没有配置的则跳转应用市场。

这两种方案在国内的应用都比较少。

方案对比

URI Scheme

• URI Scheme的兼容性是最高，但使用体验相对较差:

• 当要被唤起的APP没有安装时，这个链接就会出错，页面无反应。

• 当注册有多个scheme相同的时候，没有办法区分。

• 不支持从其他app中的UIWebView中跳转到目标APP， 所以ios和android都出现了自己的独有解决方案。

Universal Link

• 已经安装APP，直接唤起APP；APP没有安装，就会跳去对应的web link。

• universal Link 是从服务器上查询是哪个APP需要被打开，所以不会存在冲突问题

• universal Link 支持从其他app中的UIWebView中跳转到目标app

• 缺点在于会记住用户的选择：在用户点击了Universal link之后，iOS会去检测用户最近一次是选择了直接打开app还是打开网站。一旦用户点击了这个选项，他就会通过safiri打开你的网站。并且在之后的操作中，默认一直延续这个选择，除非用户从你的webpage上通过点击Smart App Banner上的OPEN按钮来打开。

App link

• 优点与 universal Link 类似

• 缺点在于国内的支持相对较差，在有的浏览器或者手机ROM中并不能链接至APP，而是在浏览器中打开了对应的链接。

• 在询问是否用APP打开对应的链接时，如果选择了“取消”并且“记住选择”被勾上，那么下次你再次想链接至APP时就不会有任何反应

作者：南玖
来源：https://juejin.cn/post/7097784616961966094