“一套代码，多端运行”是很多开发团队的梦想，基于 uni-app 跨平台框架支持 iOS、Android、Web以及各种小程序并支持平台间互通，快速实现搭建多端即时通讯功能，降低开发难度，提升开发效率。
12月13日 晚 19:00，环信线上公开课《使用 uniapp 30分钟快速开发即时通讯应用》为题，讲解多端 uni-app 基础框架知识及搭建即时通讯功能项目实战技巧，掌握开发步骤及思路，大大增强代码复用率，提升效率。来直播间 get 环信 IM 的正确打开方式！

一、时间地点

活动时间：12 月 13 日（星期二）19:00-20:00
活动地点：线上直播

二、演讲大纲

• uni-app 跨平台框架介绍
• 使用uni-app 生成 Android&iOS 应用
• 如何搭建自己的即时通讯应用
• IM实战篇-uni-app 经典问题答疑

三、活动报名

报名链接：https://mudu.tv/live/watch/meddae1l

“真正的教育，不传授任何的知识和技能 ”

——耶鲁大学校长 理查德莱文

1.一次飞速的转岗

2017年，因为我接手一个Go语言新项目，作为研发的leader，需要建设临时的团队完成这件事。拉到的其中一个人是公司对口的外包资源的总接口人，这位接口人其实原本管管外包，做个管理者即可，但是他跟我说特别想要做技术，就跟我一起干点事情。同时因为职务之便，也可以帮我甄别最适合的外包研发补充到队伍中。

作为leader，我则过着深圳北京2地周期往返的生活，这为后续我没办法很好的管理人的部分，埋下了伏笔。

这位外包leader很快为我物色了一位Java研发，他挺看好他的潜力，然而不到一周，这位研发就离开了队伍，理由是希望继续做深java这个语言，不想轻易换语言，赶上我不在现场，事出突然，我甚至没见过一面就这么离开了。

不可否认一门具体的编程语言的技术深度挺重要的，但是如果我在现场，或许有机会聊聊关于一些我曾经在Java，Ruby，python，nodejs间反复横跳，哪要救火就补哪的经历对我的帮助有哪些，即便留不住他，但或许我的观点对他未来的路有些帮助。

2.对领导者的失望

时间回到2015年，在另一家公司就职的我，听了高管在与研发的演讲中大概这么说：“大家不要看重编程语言啊，那只是一种具体的工具”。在台下的我深以为然。

没过多久，我短暂带过的一个研发离职了，临走时跟我说：你看这个高管说的话就是不重视技术，我还是走吧。听他这么说完，我直接愣了，虽然想要反驳，但是心想我年纪跟他一般，实在不配做教育他的那个人，毕竟不是他领导还是算了吧，毕竟离职已成定局。

现在的我不会那么腼腆，肯定会给他讲讲我背后的逻辑和观点。

那么我的观点是什么呢？我为何更认可高管。

3.第一次认知冲击

时间再回到2012年，工作了2年多的我入职这家公司。领导在面试我的最后，问的问题是我难以想象的题目：UTF8描述了什么，他的来历是怎样的，为何会有UTF8编码？

我直接放弃作答。领导说了至今让我受益终身的话，大概是这样的：了解技术本身的机制肯定是重要的，了解他背后产生的逻辑则更重要。面试就结束了，让我等消息

其实我现在再想想当初，领导或许只是想通过面试给我上一堂课吧（因为这问题问的“前不着村，后不着店”），但是却能一直不断影响我，我在进入任何一个技术领域后都将这种思维作为指导。

• 进入云计算领域学完技术后，就把背后的发展历史搞清楚。

• 从Java转Ruby就看看Ruby作者的一些思考，而不只是ruby语言的高级特性相关知识

等等，用这样的方式学习，我不会局限于工作安排所需我掌握的这些知识和技能，而是主动自学背后逻辑和发展演进历史。

4.高维度思考

那么领导想要我悟什么呢？相比知识和技能，更重要的是掌握产生这些东西的背后的思维逻辑是什么。不断积累这些思维，我才能逐渐的独立思考，创新。

• 看看第一个离职的研发：研发在意的Java是一种知识和工具，而Java的作者除此之外还掌握了思维，我希望研发掌握的应该包含2者

• 看看第二个离职的研发：高管期望大家不只是执着于工具，而是更高阶的思维，以创造新的商业模式，服务等等。而寻找技术和场景之间缺少的东西，跨越技术到商业成功的鸿沟，正是技术人员则无旁贷的事情，不积累是不行的。

去了解你所涉足的技术的前世今生，甚至细节到一个小小的功能特性，那么或许看透事物本质的你可以看到未来

来源：mp.weixin.qq.com/s/YBovCZ8OdELi17w_HFnvqg

前言

在做移动端的需求时，我们经常会开发一些列表页，这些列表页大多数有着相似的功能：分页获取列表、上拉加载、下拉刷新···

在 Vue 出来 compositionAPI之前，我们想要复用这样的逻辑还是比较麻烦的，好在现在 Vue2.7+都支持 compositionAPI语法了，这篇文章我将 手把手带你用 compositionAPI封装一个名为 useList的 hooks来实现列表页的逻辑复用。

基础版

需求分析

一个列表，最基本的需求应该包括: 发起请求，获取到列表的数组，然后将该数组渲染成相应的 DOM 节点。要实现这个功能，我们需要以下变量：

• list : 数组变量，用来存放后端返回的数据，并在 template模板中使用 v-for来遍历渲染成我们想要的样子。

• listReq: 发起 http 请求的函数，一般是 axios的实例

代码实现

有了上面的分析，我们可以很轻松地在 setup中写出如下代码:

import { ref } from 'vue'
import axios from 'axios' // 简单示例，就不给出封装axios的代码了

const list = ref([])

const listReq = () => {
  axios.get('/url/to/getList').then((res) => {
    list.value = res.list
  })
}

listReq()

这样，我们就完成了一个基本的列表需求的逻辑部分。大部分的列表需求都是类似的逻辑，既然如此，Don't Repeat Yourself!（不要重复写你的代码！），我们来把它封装成通用的方法：

• 首先，既然是通用的，会在多个地方使用，那么数据肯定不能乱了，我们要在每次使用 useList的时候都拿到独属于自己的那一份数据。是不是感觉很熟悉？对的，就是以前的 data为什么是一个函数那个问题！所以我们的 useList是需要导出一个函数，我们从这个函数中获取数据与方法。让这个函数导出一个对象/数组，这样调用的时候 解构就可以拿到我们需要的变量和方法了

// useList.js 中

const useList = () => {
  // 待补充的函数体
  return {}
}

export default useList

• 然后，不同的地方调用的接口肯定不一样，我们想一次封装，不再维护，那么咱们干脆在使用的时候，把调用接口的方法传进来就可以了

// useList.js 中
import { ref } from 'vue'
const useList = (listReq) => {
  if (!listReq) {
    return new Error('请传入接口调用方法!')
  }
  const list = ref([])
  const getList = () => {
    listReq().then((res) => (list.value = res.list))
  }

  return {
    list,
    getList,
  }
}

export default useList

这样，我们就完成了一个简单的列表 hooks，使用的时候直接：

// setup中
import useList from '@/utils'
const { list, getList } = useList(axios.get('url/to/get/list'))
getList()

等等！列表好像不涉及到 DOM操作，那咱们再偷点懒，直接在 useList内部就调用了吧！

// useList.js中
import { ref } from 'vue'
const useList = (listReq) => {
  if (!listReq) {
    return new Error('请传入接口调用方法!')
  }
  const list = ref([])
  const getList = () => {
    listReq().then((res) => (list.value = res.list))
  }
  getList() // 直接初始化，省去在外面初始化的步骤
  return {
    list,
    getList,
  }
}

export default useList

这时有老哥要说了，那我要是一个页面有多个列表怎么办？嘿嘿，别忘了，解构的时候是可以重命名的

// setup中

const { list: goodsList, getList: getGoodsList } = useList(
  axios.get('/url/get/goods')
)
const { list: recommendList, getList: getRecommendList } = useList(
  axios.get('/url/get/goods')
)

这样，我们就同时在一个页面里面，获取到了商品列表以及推荐列表所需要的变量与方法啦

带分页版

如果数据量比较大的话，所有的数据全部拿出来渲染显然不合理，所以我们一般要进行分页处理，我们来分析一下这个需求：

需求分析

• 要分页，那咱们肯定要告诉后端当前请求的是第几页、每页多少条，可能有些地方还需要展示总共有多少条，为了方便管理，咱们把这些分页数据统一放到 pageInfo对象中

• 分页了，那咱们肯定还有加载下一页的需求，需要一个 loadmore函数

• 分页了，那咱们肯定还会有刷新的需求，需要一个 initList函数

代码实现

需求分析好了，代码实现起来就简单了，废话少说，上代码！

// useList.js中
import { ref } from 'vue'
const useList = (listReq) => {
  if (!listReq) {
    return new Error('请传入接口调用方法!')
  }
  const list = ref([])

  // 新增pageInfo对象保存分页数据
  const pageInfo = ref({
    pageNum: 1,
    pageSize: 10,
    total: 0,
  })
  const getList = () => {
    // 分页数据作为参数传递给接口调用函数即可
    // 将请求这个Promise返回出去，以便链式then
    return listReq(pageInfo.value).then((res) => {
      list.value = res.list
      // 更新总数量
      pageInfo.value.total = res.total
      // 返回出去，交给then默认的Promise，以便后续使用
      return res
    })
  }

  // 新增加载下一页的函数
  const loadmore = () => {
    // 下一页，那咱们把当前页自增一下就行了
    pageInfo.value.pageNum += 1
    // 如果已经是最后一页了（本次获取到空数组）
    getList().then((res) => {
      if (!res.list.length) {
        uni.showToast({
          title: '没有更多了',
          icon: 'none',
        })
      }
    })
  }

  // 新增初始化
  const initList = () => {
    // 初始化一般是要把所有的查询条件都初始化，这里只有分页，咱就回到第一页就行
    pageInfo.value.pageNum = 1
    getList()
  }

  getList()
  return {
    list,
    getList,
    loadmore,
    initList,
  }
}

export default useList

完工！跑起来试试，Perfec......等等，好像不太对...

加载更多，应该是把两次请求的数据合并到一起渲染出来才对，这怎么直接替换掉了？

回头看看代码，原来是咱们漏了拼接的逻辑，补上，补上

// useList.js中

// ...省略其余代码
const getList = () => {
  // 分页数据作为参数传递给接口调用函数即可
  return listReq(pageInfo.value).then((res) => {
    // 当前页不为1则是加载更多，需要拼接数据
    if (pageInfo.value.pageNum === 1) {
      list.value = res.list
    } else {
      list.value = [...list.value, ...res.list]
    }
    pageInfo.value.total = res.total
    return res
  })
}
// ...省略其余代码

带 hooks 版

上面的分页版，我们给出了 加载更多和 初始化列表功能，但是还是要手动调用。仔细想想，咱们刷新列表，一般都是在页面顶部下拉的时候刷新的；而加载更多，一般都是在滚动到底部的时候加载的。既然都是一样的触发时机，那咱们继续封装吧！

需求分析

• uni-app 中提供了 onPullDownRefresh和 onReachBottom钩子，在其中处理相关逻辑即可

• 有些列表可能不是在页面中，而是在 scroll-view中，还是需要手动处理，因此上面的函数咱们依然需要导出

代码实现

钩子函数(hooks)接受一个回调函数作为参数，咱们直接把上面的函数传入即可

需要注意的是，uni-app 中，下拉刷新的动画需要手动关闭，咱们还需要改造一下 listReq函数

// useList中
import { onPullDownRefresh, onReachBottom } from '@dcloudio/uni-app'

// ...省略其余代码
onPullDownRefresh(initList)
onReachBottom(loadmore)

const getList = () => {
  // 分页数据作为参数传递给接口调用函数即可
  return listReq(pageInfo.value)
    .then((res) => {
      // ...省略其余代码
    })
    .finally((info) => {
      // 不管成功还是失败，关闭下拉刷新的动画
      uni.stopPullDownRefresh()
      // 在最后再把前面返回的消息return出去，以便后续处理
      return info
    })
}

// ...省略其余代码

带参数

其实在实际开发中，我们在发起请求时可能还需要其他的参数，上面我们都是固定的只有分页的参数，可以稍加改造

需求分析

可能大家第一反应是多一个参数，或者用 展开运算符 (...)再定义一个形参就行了。这么做肯定是没问题的，不过在这里的话不够优雅~

我们这里是要增加一个传给后端的参数，一般都是一起以 JSON 对象的形式传过去，既然如此，那咱们把所有的参数都用一个对象接受，发起请求的时候和分页参数对象合并为一个对象，代码的可读性会更高，使用者在使用时也可以自由地定义 key-value 键值对

代码实现

// useList中

const useList = (listReq, data) => {
  // ...省略其余代码

  // 判断第二个参数是否是对象，以免后面使用展开运算符时报错
  if (data && Object.prototype.toString.call(data) !== '[object Object]') {
    return new Error('额外参数请使用对象传入')
  }
  const getList = () => {
    const params = {
      ...pageInfo.value,
      ...data,
    }
    return listReq(params).then((res) => {
      // ...省略其余代码
    })
  }
  // ...省略其余代码
}

// ...省略其余代码

带默认配置版

有些时候我们的列表是在页面中间，不需要触底加载更多；有时候我们可能需要在不同的地方调用相同的接口，但是需要获取的数据量不一样....

为了适应各种各样的需求，我们可以稍加改造，添加一个带有默认值的配置对象，

// useList.js中

const defaultConfig = {
  pageSize: 10, // 每页数量，其实也可以在data里面覆盖
  needLoadMore: true, // 是否需要下拉加载
  data: {}, // 这个就是给接口用的额外参数了
  // 还可以根据自己项目需求添加其他配置
}

// 添加一个有默认值的参数，依然满足大部分列表页传入接口即可使用的需求
const useList = (listReq, config = defaultConfig) => {
  // 解构的时候赋上初始值，这样即使配置参数只传了一个参数，也不影响其他的配置
  const {
    pageSize = defaultConfig.pageSize,
    needLoadMore = defaultConfig.needLoadMore,
    data = defaultConfig.data,
  } = config

  // 应用相应的配置
  if (needLoadMore) {
    onReachBottom(loadmore)
  }

  const pageInfo = ref({
    pageNum: 1,
    pageSize,
    total: 0,
  })

  // ...省略其余代码
}

// ...省略其余代码

这样一来,咱们就实现了一个满足大部分移动端列表页的逻辑复用 hooks

web 端的几乎只有加载更多(翻页)的时候逻辑不太一样,不需要拼接数据，在封装的时候可以把分页器的处理逻辑一起封装进来

总结

在这篇文章中，咱们从需求分析开始，到代码关键逻辑分析，再到实现后的 bug 修复，再到功能扩展，基本完整地复现了编码的思考过程，希望能给大家带来一些收获~

同时，欢迎大家在评论区和谐讨论~

作者：八宝粥要加纯牛奶
来源：juejin.cn/post/7165467345648320520

背景

在android系统中，进程之间是相互隔离的，两个进程之间是没办法直接跨进程访问其他进程的空间信息的。那么在android平台中要对某个app进程进行内存操作，并获取目标进程的地址空间内信息或者修改目标进程的地址空间内的私有信息，就需要涉及到注入技术。

通过注入技术可以将指定so模块或代码注入到目标进程中，只要注入成功后，就可以进行访问和篡改目标进程空间内的信息，包括数据和代码。

Android的注入技术的应用场景主要是进行一些非法的操作和实现如游戏辅助功能软件、恶意功能软件。

zygote注入

zygote是一个在android系统中是非常重要的一个进程，因为在android中绝大部分的应用程序进程都是由它孵化(fork)出来的，fork是一种进程复用技术。也就是说在android系统中普通应用APP进程的父亲都是zygote进程。

zygote注入目的就是将指定的so模块注入到指定的APP进程中，这个注入过程不是直接向指定进程进程注入so模块，而是先将so模块注入到zygote进程。

在so模块注入到zygote进程后，在点击操作android系统中启动的应用程序APP进程，启动的App进程中包括需要注入到指定进程的so模块，太都是由zygote进程fork生成，因而在新创建的进程中都会包含已注入zygote进程的so模块。

这种的注入是通过间接注入方式完成的，也是一种相对安全的注入so模块方式。目前xposed框架就是基于zygote注入。

1.通过注入器将要注入的so模块注入到zygote进程；

2.手动启动要注入so模块的APP进程，由于APP进程是通过zygote进程fork出来的，所以启动的APP进程都包含zygote进程中所有模块；

3.注入的so模块劫持被注入APP进程的控制权，执行注入so模块的代码；

4.注入so模块归还APP进程的控制权，被注入进程正常运行。

(注入器主要是基于ptrace注入shellcode方式的进程注入)

通过ptrace进行附加到zygote进程。

调用mmap申请目标进程空间，用于保存注入的shellcode汇编代码。

执行注入shellcode代码（shellcode代码是注入目标进程中并执行的汇编代码）。

调用munmap函数释放申请的内存。

通过ptrace进行剥离zygote进程。

下面是关键的zygote代码注入实现

ptrace注入

ptrace注入实现上分类：

通过利用ptrace函数将shellcode注入远程进程的内存空间中，然后通过执行shellcode加载远程进程so模块。

通过直接远程调用dlopen、dlsym、dlclose等函数加载被注入so模块，并执行指定的代码。

ptrace直接调用函数注入流程：

通过利用ptrace进行附加到要注入的进程；

保存寄存环境；

远程调用mmap函数分配内存空间；

向远程进程内存空间写入加载模块名称和函数名称；

远程调用dlopen函数打开注入模块；

远程调用dlsym函数或需要调用的函数地址；

远程调用被注入模块的函数；

恢复寄存器环境；

利用ptrace从远程进程剥离。

关键的ptrace直接调用系统函数实现

shellcode注入就是通过将dlopen/dlsym库函数的操作放在shellcode代码中，注入函数只是通过对远程APP进程进行内存空间申请，接着修改shellcode 代码中有关dlopen、dlsymdlclose等函数使用到的参数信息，然后将shellcode代码注入到远程APP进程申请的空间中，最后通过修改PC寄存器的方式来执行shellcode 的代码。

关键 的ptrace注入shellcode代码实现

修改ELF文件注入

在android平台Native层的可执行文件SO文件，它是属于ELF文件格式，通过修改ELF文件格式可以实现对so文件的注入。

通过修改ELF二进制的可执行文件，并在ELF文件中添加自己的代码，使得可执行文件在运行时会先执行自定义添加的代码，最后在执行ELF文件的原始逻辑。

修改二进制ELF文件需要关注两个重要的结构体：

其中ELF Header 它是ELF文件中唯一的，一个固定位置的文件结构，它保存着Program Header Table和Section Header Table的位置和大小信息。

修改ELF文件实现so文件注入实现原理为：通过修改 Program Header Table中的依赖库信息，添加自定义的so文件信息，APP进程运行加载被该修改过的ELF文件，它也同时会加载并运行自定义的so文件。

Program Header Table表项结构

程序头表项中的类型选项有如下

当程序头表项结构中的类型为PT_DYNAMIC也就是动态链接信息的时候，它是由程序头表项的偏移(p_offset)和p_filesz(大小)指定的数据块指向.dynamic段。这个.dynamic段包含程序链接和加载时的依赖库信息。

关键ELF文件修改代码实现

作者：小道安全
来源：juejin.cn/post/7077940770941960223

什么是JWT

JWT是全称是JSON WEB TOKEN，是一个开放标准，用于将各方数据信息作为JSON格式进行对象传递，可以对数据进行可选的数字加密，可使用RSA或ECDSA进行公钥/私钥签名。

使用场景

JWT最常见的使用场景就是缓存当前用户登录信息，当用户登录成功之后，拿到JWT，之后用户的每一个请求在请求头携带上Author ization字段来辨别区分请求的用户信息。且不需要额外的资源开销。

相比传统session的区别

比起传统的session认证方案，为了让服务器能识别是哪一个用户发过来的请求，都需要在服务器上保存一份用户的登录信息（通常保存在内存中），再与浏览器的cookie打交道。

• 安全方面 由于是使用cookie来识别用户信息的，如果cookie被拦截，用户会很容易受到跨站请求伪造的攻击。

• 负载均衡 当服务器A保存了用户A的数据之后，在下一次用户A服务器A时由于服务器A访问量较大，被转发到服务器B，此时服务器B没有用户A的数据，会导致session失效。

• 内存开销 随着时间推移，用户的增长，服务器需要保存的用户登录信息也就越来越多的，会导致服务器开销越来越大。

为什么说JWT不需要额外的开销

JWT为三个部分组成，分别是Header，Payload，Signature，使用.符号分隔。

// 像这样子
xxxxx.yyyyy.zzzzz

标头 header

标头是一个JSON对象，由两个部分组成，分别是令牌是类型（JWT）和签名算法（SHA256，RSA）

{
  "alg": "HS256",
  "typ": "JWT"
}

负荷 payload

负荷部分也是一个JSON对象，用于存放需要传递的数据，例如用户的信息

{
  "username": "_island",
  "age": 18
}

此外，JWT规定了7个可选官方字段（建议）

签章 signature

这一部分，是由前面两个部分的签名，防止数据被篡改。 在服务器中指定一个密钥，使用标头中指定的签名算法，按照下面的公式生成这签名数据

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

在拿到签名数据之后，把这三个部分的数据拼接起来，每个部分中间使用.来分隔。这样子我们就生成出一个了JWT数据了，接下来返回给客户端储存起来。而且客户端在发起请求时，携带这个JWT在请求头中的Authorization字段，服务器通过解密的方式即可识别出对应的用户信息。

JWT优势和弊端

优势

• 数据体积小，传输速度快

• 无需额外资源开销来存放数据

• 支持跨域验证使用

弊端

• 生成出来的Token无法撤销，即使重置账号密码之前的Token也是可以使用的（需等待JWT过期）

• 无法确认用户已经签发了多少个JWT

• 不支持refreshToken

关于refreshToken

refreshToken是Oauth2认证中的一个概念，和accessToken一起生成出来的。

当用户携带的这个accessToken过期时，用户就需要在重新获取新的accessToken，而refreshToken就用来重新获取新的accessToken的凭证。

为什么要有refreshToken

当你第一次接触的时候，你有没有一个这样子的疑惑，为什么需要refreshToken这个东西，而不是服务器端给一个期限较长甚至永久性的accessToken呢？

抱着这个疑惑我在网上搜寻了一番，

其实这个accessToken的使用期限有点像我们生活中的入住酒店，当我们在入住酒店时，会出示我.们的身份证明来登记获取房卡，此时房卡相当于accessToken，可以访问对应的房间，当你的房卡过期之后就无法再开启房门了，此时就需要再到前台更新一下房卡，才能正常进入，这个过程也就相当于refreshToken。

accessToken使用率相比refreshToken频繁很多，如果按上面所说如果accessToken给定一个较长的有效时间，就会出现不可控的权限泄露风险。

使用refreshToken可以提高安全性

• 用户在访问网站时，accessToken被盗取了，此时攻击者就可以拿这个accessToke访问权限以内的功能了。如果accessToken设置一个短暂的有效期2小时，攻击者能使用被盗取的accessToken的时间最多也就2个小时，除非再通过refreshToken刷新accessToken才能正常访问。

• 设置accessToken有效期是永久的，用户在更改密码之后，之前的accessToken也是有效的

总体来说有了refreshToken可以降低accessToken被盗的风险

关于JWT无感刷新TOKEN方案（结合axios）

业务需求

在用户登录应用后，服务器会返回一组数据，其中就包含了accessToken和refreshToken，每个accessToken都有一个固定的有效期，如果携带一个过期的token向服务器请求时，服务器会返回401的状态码来告诉用户此token过期了，此时就需要用到登录时返回的refreshToken调用刷新Token的接口（Refresh）来更新下新的token再发送请求即可。

话不多说，先上代码

工具

axios作为最热门的http请求库之一，我们本篇文章就借助它的错误响应拦截器来实现token无感刷新功能。

具体实现

本次基于axios-bz代码片段封装响应拦截器 可直接配置到你的项目中使用 ✈️ ✈️

利用interceptors.response，在业务代码获取到接口数据之前进行状态码401判断当前携带的accessToken是否失效。 下面是关于interceptors.response中异常阶段处理内容。当响应码为401时，响应拦截器会走中第二个回调函数onRejected

下面代码分段可能会让大家阅读起来不是很顺畅，我直接把整份代码贴在下面，且每一段代码之间都添加了对应的注释

// 最大重发次数
const MAX_ERROR_COUNT = 5;
// 当前重发次数
let currentCount = 0;
// 缓存请求队列
const queue: ((t: string) => any)[] = [];
// 当前是否刷新状态
let isRefresh = false;

export default async (error: AxiosError<ResponseDataType>) => {
  const statusCode = error.response?.status;
  const clearAuth = () => {
    console.log('身份过期，请重新登录');
    window.location.replace('/login');
    // 清空数据
    sessionStorage.clear();
    return Promise.reject(error);
  };
  // 为了节省多余的代码，这里仅展示处理状态码为401的情况
  if (statusCode === 401) {
    // accessToken失效
    // 判断本地是否有缓存有refreshToken
    const refreshToken = sessionStorage.get('refresh') ?? null;
    if (!refreshToken) {
      clearAuth();
    }
    // 提取请求的配置
    const { config } = error;
    // 判断是否refresh失败且状态码401，再次进入错误拦截器
    if (config.url?.includes('refresh')) {
    clearAuth();
    }
    // 判断当前是否为刷新状态中（防止多个请求导致多次调refresh接口）
    if (isRefresh) {
      // 设置当前状态为刷新中
      isRefresh = true;
      // 如果重发次数超过，直接退出登录
      if (currentCount > MAX_ERROR_COUNT) {
        clearAuth();
      }
      // 增加重试次数
      currentCount += 1;

      try {
        const {
          data: { access },
        } = await UserAuthApi.refreshToken(refreshToken);
        // 请求成功，缓存新的accessToken
        sessionStorage.set('token', access);
        // 重置重发次数
        currentCount = 0;
        // 遍历队列，重新发起请求
        queue.forEach((cb) => cb(access));
        // 返回请求数据
        return ApiInstance.request(error.config);
      } catch {
        // 刷新token失败，直接退出登录
        console.log('请重新登录');
        sessionStorage.clear();
        window.location.replace('/login');
        return Promise.reject(error);
      } finally {
        // 重置状态
        isRefresh = false;
      }
    } else {
      // 当前正在尝试刷新token，先返回一个promise阻塞请求并推进请求列表中
      return new Promise((resolve) => {
        // 缓存网络请求，等token刷新后直接执行
        queue.push((newToken: string) => {
          Reflect.set(config.headers!, 'authorization', newToken);
          // @ts-ignore
          resolve(ApiInstance.request<ResponseDataType<any>>(config));
        });
      });
    }
  }

  return Promise.reject(error);
};

抽离代码

把上面关于调用刷新token的代码抽离成一个refreshToken函数，单独处理这一情况，这样子做有利于提高代码的可读性和维护性，且让看上去代码不是很臃肿

// refreshToken.ts
export default async function refreshToken(error: AxiosError<ResponseDataType>) {
    /* 
    将上面 if (statusCode === 401) 中的代码贴进来即可，这里就不重复啦
    代码仓库地址: https://github.com/QC2168/axios-bz/blob/main/Interceptors/hooks/refreshToken.ts
    */
}

经过上面的逻辑抽离，现在看下拦截器中的代码就很简洁了，后续如果要调整相关逻辑直接在refreshToken.ts文件中调整即可。

import refreshToken from './refreshToken.ts'
export default async (error: AxiosError<ResponseDataType>) => {
  const statusCode = error.response?.status;

  // 为了节省多余的代码，这里仅展示处理状态码为401的情况
  if (statusCode === 401) {
    refreshToken()
  }

  return Promise.reject(error);
};

作者：_island

来源：juejin.cn/post/7170278285274775560

开发一个APP多少钱？

开发一个APP要多少钱？相信不光是客户有这个疑问，就算是一般的程序员也想知道答案。很多程序员想在业余时间接外包挣外快，但是他们常常不知道该如何定价，如何有说服力的要价。这是因为没有一套好的计算APP开发成本的方法。由于国内没有公开的数据，而且大家对于报价都喜欢藏着掖着，这里我们就整理了国外一些软件外包平台的资料，帮助大家对Flutter APP开发成本有一个直观而立体的认识。（注意，这里是以美元单位计算，请不要直接转换为RMB，应当根据消费力水平来衡量）

跨平台项目正在慢慢取代原生应用程序的开发。跨平台的方法更省时，也更节省成本。最近，原生应用程序的主要优势是其性能。但随着新的跨平台框架给开发者带来更多的力量，这不再是它们的强项。

Flutter就是其中之一。这个框架在2017年发布，并成为跨平台社区中最受推崇的框架之一。Statista称，Flutter是2021年十大最受欢迎的框架之一，并在最受欢迎的跨平台框架中排名第一。对于这样一项新技术来说，这是一个相当不错的结果。它的高需求使我们可以定义软件建设的大致成本。

Flutter应用程序的开发成本根据项目定义的工作范围而变化：

• 简单的 Flutter 应用程序：$40,000 - $60,000

• 中等复杂度应用程序：$60,000 – $120,000

• 高度复杂的 Flutter 应用程序：$120,000 – $200,000+

有一些决定性的因素来回答Flutter应用开发的成本是多少。

在这篇文章中，我们将讨论不同行业的Flutter应用开发成本，找出如何计算精确的价格，以及如何利用这个框架削减项目开支。

Flutter应用的平均开发成本

应用程序的开发成本是一个复杂的数字，取决于各种因素 ——功能的复杂性，开发人员的位置，支持的平台，等等。如果不进行研究和了解所有的要求，就不可能得出项目的价格。

不过，你还是可以看看按项目复杂程度分类的估算：

• 一个具有简单功能的软件，如带有锻炼建议、膳食计划、个人档案和体重日记的健身应用，其成本从26,000美元到34,800美元

• 一个中等复杂度的软件，如带有语音通话、消息通信，Flutter应用的开发成本将从34,950美元到48,850美元不等

• 开发一个像 Instagram 这样具有复杂功能的应用程序的成本将从41,500美元到55,000美元不等

影响价格的因素

为了明确 Flutter 应用开发成本的所有组成部分，我们将挑选出每个因素并分析其对价格的影响。

原生应用开发 vs. Flutter

当我们估算一个原生项目时，我们要考虑到两个平台的开发时间。Flutter是一个跨平台的框架，可以让开发者为Android和iOS编写同一个代码库。这一特点使开发时间减半，使Flutter应用程序的开发成本比原生的低。

Flutter 的非凡之处在于它优化了代码并且没有性能问题。Flutter在所有设备上都能提供稳定的接近 60 FPS，如果设备支持，甚至可以提供120 FPS。

然而，Flutter也有一些缺点。如果你的项目需要Wear OS版本或智能电视应用，就会面临一些麻烦。从技术上讲，你可以为这些平台建立一个Flutter应用程序。但是，Flutter的很多开发功能并不被Wear OS所支持。在安卓电视的情况下，必须从头开始建立控制逻辑。原因是安卓电视只读取遥控器的输入，而Flutter则适用于触摸屏和鼠标移动。这一事实会减慢开发进程，给开发者带来麻烦，并增加Flutter应用的开发成本。

这就是为什么如果你的目标是特定的平台，最好去做原生开发。

功能的复杂性

功能是应用程序的主要组成部分。也是影响Flutter应用程序开发成本的主要因素。简单的功能（如登录）需要最少的工作量，而视频通话的集成可能需要长达 2-3 周的开发时间。

让我们想象一下，要建立一个类似 Instagram 的应用程序。照片上传功能需要大约13小时的开发时间。以每小时50美元的平均费率计算，这将花费650美元。然而，要建立用于照片编辑的过滤器，开发团队将不得不花费30至120小时，这取决于它们的类型和数量。一家软件开发公司将为这个功能收取1500-6000美元。

Flutter应用开发中最昂贵的功能

开发商的位置和所选择的雇用方式

影响总成本的另一个方面是你在雇用项目专家时选择的就业方式：

自由职业者

由于有机会减少开发费用，这种选择被广泛采用。然而，就Flutter应用的开发而言，无法保证自由职业者的能力和质量。此外，在支持、维护和更新服务方面，这样的专家也没有优势，因为他们可能会转到另一个项目，从而无法建立长期的合作伙伴关系。

内部团队

在这种情况下，你要负责项目开发管理，以及搜索和检查潜在雇主的经验和知识。此外，内部团队的聚集需要一排额外的费用，如购买硬件，租用办公室，病假，工资，等等。因此，这些条件大大增加了总成本。

外包公司

项目外包指的是已经组建的专家团队，具有成熟深入的资质，接手所有的创作过程。这种选择是一种节省开发投资和避免影响产品质量的好方法。除了这个事实之外，这里还有一些你将通过外包获得的好处。

• 成本的灵活性。全球市场提供了很多准备以合理价格提供服务的外包软件开发公司。中欧已经成为实现这一目标的顶级地区，许多企业已经从来自该地的优秀开发人员的一流表现中受益。

• 可扩展性。可以根据您的要求调整开发流程：此类公司的团队包括所有类型的开发人员，将在需要他们的能力时参与创建过程。此外，如果有必要的话，这也是加快项目完成的绝佳方式。外包提供了多种合作模式。 从专门的团队到工作人员的增援

• 更快的产品交付。有了外包，就不需要在招聘上花费时间。你可以调整项目创建速度，例如，让更多的专家参与进来。因此，进入市场的时间缩短了，支出也减少了。只为已完成的工作付费。

• 庞大的人才库。IT外包包括大量具有丰富专业知识和经验的技术专家。外包商为企业提供灵活的招聘机会。你可以在全球范围大量的的软件架构师中选择。

• 可应用的技术非常多样化。根据你的项目要求，你可以从这些公司中选择一个具有相关专业知识的专家。

除了雇佣选择，开发团队的位置可能会对Flutter应用程序的开发成本产生很大的影响。在不同地区，开发人员有不同的价格。在美国，开发人员的平均费率是60美元/小时，而在爱沙尼亚，只有37美元/小时。

在下面的表格中，可以找到开发人员的每小时费率，并将它们进行比较。

Flutter开发人员在不同地区的费率：

如何计算 Flutter 应用开发成本

正如前面提到的，功能对Flutter应用开发成本的影响最大。Flutter 适用于不包含原生功能的项目。但是当涉及到地图、流媒体、AR和后台进程时，开发人员必须为iOS和Android单独构建这些功能，然后再与Flutter结合。

让我们回到例子上。如果是原生开发，你将需要大约60-130个小时在你的应用程序中实现AR过滤器。Flutter开发将需要约80-150小时，因为AR是一个原生功能。考虑到50美元/小时的费率，我们应该把它乘以开发时间。这个公式可以用来计算出最终的Flutter应用开发成本。

除了这个公式外，还有一件事在初始阶段很重要。

发现阶段

一个糟糕的发现阶段可能导致整个项目的崩溃。但为什么这个阶段如此重要？在发现阶段，业务分析人员和项目经理与你举行会议，找出可能的风险，并提出消除这些风险的解决方案

粗略估算

粗略估算的精确度从75%到25%不等。这个评估包括在客户和软件团队合作的初级阶段。它也有助于双方决定是否成为合作伙伴。粗略估算的主要目的是计算完成项目所需的最短和最长时间以及大致的总成本，以便客户知道在开发流程中需要多少投资。此外，这个估算包括整个创建过程，分为几个阶段。这个文件不应该被认为是有固定条款和条件的文件。它是为客户准备的，只是为了通知他们。

一个粗略的估算包括：

• 主要部分包含准备工作。它们在不同的项目中都是一样的，包括产品描述、数据库设置、REST架构。该部分所指出的项目不一定一次就能完成。有些工作是在整个项目中完成的。

• 开发与加密过程有关。这部分包括要实现的功能、屏幕和特性。开发部分包括 "业务逻辑 "和 "UI/UX "要求，以及某部分工作的小时数。

• 为了更有效地实现功能，需要整合框架和库，并相应减少开发时间和相应的花费。

• 非开发工作主要与技术写作有关。专家们准备详细的代码文档和准备有关产品创建的其他数据。

• 建议部分包含了各种改进建议。

当所有的问题都解决后，会进入发现阶段并创建一个项目规范。客户必须积极参与，因为会根据客户提供的数据来建立项目规范。在下一个阶段，客户应当创建他们的应用程序草稿图。这是一个用户界面元素在屏幕上的位置示意图。

然后，开发人员和业务分析师会对客户的Flutter应用开发成本进行详细的估算。有了准确的预算、项目要求和草稿图，就可以签署合同并开始开发阶段。

如你所见，发现阶段是任何项目的关键部分。没有这个阶段，你就无法知道开发所需的价格和时间，因为会有太多的变数。如果在任何阶段出了问题，整个项目的计划就会出问题。这就是为什么客户必须与软件开发公司合作，使他们能够建立客户需要的项目。

额外费用

就像任何其他产品一样，客户的应用程序需要维护和更新，以便在市场上保持成功。这导致了影响Flutter应用程序开发成本的额外费用。

服务器

如果要处理和存储用户产生的数据，就必须考虑到服务器的问题。脆弱的服务器会导致用户方面的低性能和高响应时间。此外，不可靠的服务器和脆弱的保护系统会导致你的用户的个人数据泄露。为了减少风险，团队只信任可靠的供应商，如亚马逊EC2。根据AWS价格计算器，一台8核CPU和32G内存的工作服务器将花费大约1650美元/年。在计算整个Flutter应用程序的开发成本时，请牢记这笔费用。

UI/UX设计

移动应用的导航、排版和配色是UI/UX设计师应该注意的主要问题。他们还应该向你提供你的应用程序的原型。根据你的应用程序的复杂性，设计可能需要40到90多个小时。这一行的费用将使Flutter应用的开发成本提高到2000-4500美元

发布到应用商店

当你已经有了一个成品，你必须在某个地方发布它。Google Play和App Store是应用程序分发的主要平台。然而，这些平台在应用发布前会收取费用：

• Google Play 帐号一次收取25美元，可以永久使用

• 而Apple Store 收取99美元的年费，只要你的APP还想待在应用商店，每年都得花费这笔钱

除此之外，这两个平台对每次产生的应用内购买行为都有30%的分成。如果你通过订阅模式发布你的应用，那你只能得到70%收益。然而，最近Google Play和App Store已经软化了他们的政策。目前，他们对每一个购买了十二个月订阅的账户只收取15%的分成。

应用维护和更新

应用商店排行榜的应用能保持其地位是有原因的。他们通过不断的升级和全新的功能吸引客户。即使你的应用是完美的，但没有更新将导致停滞，用户可能卸载你的应用程序。在完美的构想里，你应该雇用一家开发应用程序的公司。他们从一开始就为你的项目工作。注意，应用程序的维护费用在应用程序的生命周期内会上升。公司通常将Flutter应用开发成本的15-20%纳入应用维护的预算。然而，你的应用程序拥有稳定受众的时间越长，需要投入的更新资金就越多。在一定时间内，你花在更新上的钱比花在实际开发上的钱多，这并不奇怪。尽管如此，但是你的应用产生的收入多于损失，所以这是一项值得的投资。不幸的是，随着新的功能发布可能出现新的错误和漏洞。你不能对这个问题视而不见，因为它使用户体验变差，并为欺诈者提供了新的漏洞。有一些软件开发公司会提供发布后的支持，包括开发新功能、测试和修复错误。

按类型划分的开发成本

由于你已经知道影响价格的主要和次要因素，现在是时候对不同应用程序的Flutter开发成本进行概述了。这里估算了来自不同行业和不同复杂程度的几个现有应用程序的开发成本。

分别是：

• 交通运输

• 流媒体

• 社交媒体

Flutter 应用程序开发成本：交通运输

示例：BlaBlaCar

功能实现的大概时间：438 小时

大概费用：21,900 美元

运输应用程序需要用户档案、司机和乘客的角色、支付网关和GPS支持。请注意，如果你使用Flutter来构建地理定位等本地功能，整个项目的开发时间可能会增加。

请注意，下面的估算不包括代码文档、框架集成、项目管理等方面的时间。

下面是一个类似BlaBlaCar的应用程序的基本功能的粗略估计，基于Flutter的交通应用开发成本：

Flutter应用程序开发成本：流媒体

例子: Twitch, Periscope, YouTube Live

功能实现的大概时间: 600小时

大概的成本: $30,000

流媒体应用程序是一个复杂的软件。它要求开发团队使用流媒体协议（这不是Flutter的强项），开发与观众沟通的文本聊天，推送通知，使用智能手机的摄像头，等等。其中一些有捐赠系统，与第三方的多种集成，甚至还有付费的表情符号。以下是一个类似Twitch的应用程序的基本功能的粗略估计。

基于Flutter的流媒体应用开发成本：

Flutter应用程序开发成本：消息通信

例子: Facebook Messenger, WhatsApp, Telegram

功能实现的大概时间: 589小时

估计成本: $29,450

消息通信工具的功能乍一看很简单，但详细的分析证明情况恰恰相反。整合各种状态的聊天（打字，在线/离线，阅读），文件传输，语音信息需要大量的时间。如果再加上语音通话和群组聊天，事情会变得更加复杂。

让我们单独列出每个功能及其成本，基于Flutter的消息通信应用开发成本：

作者：编程之路从0到1
来源：juejin.cn/post/7170168967690977293

作为一名开发，性能优化是永远绕不过去的话题，在日常的开发中，我们可肯定都会接触过。Android 的性能优化其实是非常成熟的了，成熟的套路，成熟的方法论，成熟的开源框架等等。

对于接触性能优化经验较少的开发者来说，可能很少有机会能去总结或者学到这些成熟的套路，方法论，或者框架。所以作为一位多年长期做性能优化的开发者，在这篇文章中对性能优化的方法论做一些总结，以供大家借鉴。

性能优化的本质

首先，我先介绍一下性能优化的本质。我对其本质的认知是这样的：性能优化的本质是合理且充分的使用硬件资源，让程序的表现更好，并且程序表现更好的目的则是为了获取更多来自客户的留存，使用时长，口碑、利润等收益。

所以基于本质来思考，性能优化最重要的两件事情:

1. 合理且充分的使用硬件资源

1. 让程序表现更好，并取得收益

下面讲一下这两件事情。

合理且充分的使用硬件资源

充分表示能将硬件的资源充分发挥出来，但充分不一定是合理的，比如我们一下子打了几百个线程，cpu 被充分发挥了，但是并不合理，所以合理表示所发挥出来的硬件资源能给程序表现有正向的作用。

硬件资源包括：CPU，内存，硬盘，电量，流量（不属于硬件资源，不过也归于需要合理使用的资源之一）等等。

下面举几个合理且充分的使用硬件资源的例子：

1. CPU 资源的使用率高，但并不是过载的状态，并且 cpu 资源主要为当前场景所使用，而不是被全业务所分散消耗。比如我们优化页面打开速度，速度和 cpu 有很大的关系，那么我们首先要确保 cpu 被充分发挥出来了，我们可以使用多线程、页面打开前提前预加载等策略，来发挥手机的 cpu。但是在打开页面的时候，我们要合理的确保 cpu 资源主要被打开页面相关的逻辑所使用，比如组件创建，数据获取，页面渲染等等，至于其他和当前打开页面场景联系较少的逻辑，比如周期任务，监控，或者一些预加载等等都可以关闭或者延迟，以此减少非相关任务对 cpu 的消耗，

1. 内存资源缓使用充分，并且又能将 OOM 等异常控制在合理范围内。比如我们做内存优化，内存优化并不是越少越好，相反内存占用多可能让程序更快，但是内存占用也不能太高，所以我们可以根据不同档次机型的 OOM 率，将内存的占用控制在充分使用并且合理的状态，低端机上，通过功能降级等优化，减少内存的使用，高端机上，则可以适当提升内存的占用，让程序表现的更好。

1. ……

让程序表现更好，并取得收益

我们有很多直接的指标来度量我性能优化取得的收益，比如做内存优化可以用 pss，java 内存占用，native 内存占用等等；做速度优化，可以用启动速度，页面打开速度；做卡顿优化，这用帧率等等。掌握这些指标很重要，我们需要知道如何能正确并且低开销的监控这些指标数据。

除了上面的直接指标外，我们还需要了解性能优化的最终体现指标，用户留存率，使用时长，转换率，好评率等指标。有时候，这些指标才是最终度量我们性能优化成果的数据，比如我们做内存优化，pss 降低了 100 M，但仅仅只是内存占用少了 100M 并没有太大的收益，如果这个 100M 体现在对应用的存活时间，转化率的提升上，那这 100 M 的优化就是值得的，我们再向上报告我们产出时，也更容易获得认可。

如何做好性能优化

讲完了性能优化的本质，我再讲讲如何做好性能优化。我主要从下面这三个方面来讲解

1. 知识储备

1. 思考的角度和方式

1. 形成完整的闭环

知识储备

想要做好性能优化，特别是原创性、或者完善并且体系的、或者效果很好的优化，不是我们从网上看一些文章然后模仿一下就能进行，需要我们有比较扎实的知识储备，然后基于这些知识储备，通过深入思考，去分析我们的应用，寻找优化点。我依然举一些例子，来说明硬件层面，系统层面和软件层面的知识对我们做好性能优化的帮助。

硬件层面

在硬件层面，我们需要处理器的体系结构，存储器的层次结构有一定的了解。如果我们如果不知道 cpu 由几个核组成，哪些是大核，哪些是小核，我们就不会想到将核心线程绑定大核来提升性能的优化方案；如果我们不了解存储结构中寄存器，高速缓存，主存的设计，我们就没法针对这一特效来提升性能，比如将核心数据尽量放在高速缓存中就能提升不少速度相关的性能。

系统层面

对操作系统的熟悉和了解，也是帮助我们做好性能优化不可缺少的知识。我在这里列一下系统层面需要掌握的知识，但不是全的，Linux的知识包括进行管理和调度，内存管理，虚拟内存，锁，IPC通信等。Android系统的知识包括虚拟机，核心服务如ams，wms等等，渲染，以及一些核心流程，如启动，打开activity，安装等等。

如果我们不了解Linux系统的进程调度系统，我们就没法充分利用进程优先来帮助我们提升性能；如果我们不熟悉 Android 的虚拟机，那么围绕这虚拟机一些相关的优化，比如 oom 优化，或者是 gc 优化等等都无法很好的开展。

软件层面

软件层面就是我们自己所开发的 App，在性能优化中，我们需要对自己所开发的应用尽可能得熟悉。比如我们需要知道自己所开发的 App 有哪些线程，都是干嘛的，这些线程的 cpu 消耗情况，内存占用多少，都是哪些业务占用的，缓存命中率多少等等。我们需要知道自己所开发的 App 有哪些业务，这些使用都是干嘛的，使用率多少，对资源的消耗情况等等。

除了上面提到的三个层面的知识，想要深入做好性能优化，还需要掌握更多的知识，比如汇编，编译器、编程语言、逆向等等知识。比如用c++ 写代码就比用java写代码运行更快，我们可以通过将一些业务替换成 c++ 来提高性能；比如编译期间的内联，无用代码消除等优化能减少包体积；逆向在性能优化上的用处也非常大，通过逆向我们可以修改系统的逻辑，让程序表现的更好。

可以看到，想要做好性能优化，需要庞大的知识储备，所以性能优化是很能体现开发者技术深度和广度的，这也是面试时，一定会问性能优化相关的知识的原因。这是知识储备不是一下就能形成的，需要我们慢慢的进行学习和积累。

思考的角度及方式

讲完了知识储备，再讲讲思考的角度和方式。需要注意它和知识储备没有先后关系，并不是说要有了足够的技术知识后才能开始考虑如何思考。思考的角度和方式体现在我们开发的所有生命周期中，即使是新入门的开发，也可以锻炼自己从不同的角度和方式去进行思考。下面就聊一聊我在做性能优化的过程中，在思考的角度和方式上的一些认知。为了让大家能更形象的理解，我就都以启动优化来讲解。

思考角度

我这里主要通过应用层，系统词，硬件层这三个角度来介绍我对启动速度优化的思考。

应用层

做启动速度优化时，如果从应用层来考虑，我会基于业务的维度考虑所加载的业务的使用率，必要性等等，然后制定优先级，在启动的时候只加载首屏使用，或者使用率高的业务。所以接着我就可以设计启动框架用来管理任务，启动框架要设计好优先级，并且能对这些初始化的任务有使用率或者其他性能方面的统计，比如这些任务初始化后，被使用率的概率是多少，又或者初始化之后，对业务的表现提升提现在哪，帮助有多大。

从应用层的思考主要是基于对业务的管控或者对业务进行优化来提升性能。

系统层

以及系统层来考虑启动优化也有很多点，比如线程和线程优先级维度，在启动过程中，如何控制好线程数量，如何提高主线程的优先级，如何减少启动过程中不相关的线程，比如 gc 线程等等。

硬件层

从硬件层来考虑启动优化，我们可以从 cpu 的利用率，高速缓存cache的命中率等维度来考虑优化。

除了上面提到的这几个角度，我们还可以有更多角度。比如跳出本设备之外来思考，是否可以用其他的设备帮助我们加速启动。google play 就有类似的优化，gp会上传一些其他机器已经编译好的机器码，然后相同的设备下载这个应用时，也会带着这些编译好的机器码一起下载。还有很常用的服务端渲染技术，也是让服务端线渲染好界面，然后直接暂时静态模块来提升页面打开速度；又或者站在用户的角度去思考，想一想到底什么样的优化对用户感知上是有好处的，比如有时候我们再做启动或者页面打开速度优化，会给用户一个假的静态页面让用户感知已经打开了，然后再去绑定真实的数据。

做性能优化时，考虑的角度多一些，全面一些，能帮助我们想出更多的优化方案。

思考方式

除了锻炼我们站在不同的角度思考问题，我们还可以锻炼自己思考问题的方式，这里介绍自上而下和自下而上两种思考方式。

自上而下

我们做启动优化，自上而下的优化思路可能是直接从启动出发，然后分析启动过程中的链路，然后寻找耗时函数，将耗时函数放子线程或者懒加载处理，但是这种方式会导致优化做的不全面。比如将耗时的任务都放在子线程，我们再高端机上速度确实变快了，但是在低端机上，可能会降低了启动速度，因为低端机的 cpu 很差，线程一多，导致 cpu 满载，主线程反而获取不到运行时间。其次，如果从上层来看，一个函数执行耗时久可能并不是这个函数的问题，也可能是因为该函数长时间没有获取到 cpu 时间。

自上而下的思考很容易让我们忽略本质，导致优化的效果不明显或者不完整。

自下而上

自下而上思考就是从底层开始思考，还是以启动优化为例子，自下而上的思考就不是直接分析启动链路，寻找慢函数，而是直接想着如何在启动过程中合理且充分的使用 cpu 资源，这个时候我们的方案就很多了，比如我们可能会想到不同的机型 cpu 能力是不一样的，所以我们会针对高端机和低端机来分别优化，高端机上，我们想办法让cpu利用率更高，低端机上想办法避免 cpu 的超载，同时配合慢函数，线程，锁等知识进行优化，就能制定一套体系并且完整的启动优化方案。

完整的闭环

上面讲的都是如何进行优化，优化很重要，但并不是全部，在实际的性能优化中，我们需要做的有监控，优化，防劣化，数据收益收集等等，这些部分都做好才能形成一个完整的闭环。我一一讲一下这几个部分：

• 监控：完整的监控应用中各项性能的指标，仅仅有指标监控是不够的，我们还需要尽量做归因的监控。比如内存监控，我们不仅仅要监控我们应用的内存指标，还可以还要能监控到各个业务的内存使用占比，大集合，大图片，大对象等等归因项。并且我们的监控同样要基于性能考虑去设计。完整的监控能让我们更高效的发现和解决异常。

• 优化：优化就是前面提到的，合理且充分的使用硬件资源，让程序的表现更好。

• 防劣化：防劣化也是有很多事情可以做的，包括建立完善的线下性能测试，线上监控的报警等。比如内存，我们可以在线下每天通过monkey跑内存泄露并提前治理，这就是防劣化。

• 数据收益收集。学会用好A/B测试，学会关注核心价值的指标。比如我们做内存优化，一味的追求降低应用内存的占用并不是最优，内存占用的多，可能会让我们的程序运行更快，用户体验更好，所以我们需要结合崩溃率，留存等等这种体验核心价值的指标，来确定内存到底要不要继续进行优化或者优化到多少。

小结

上面就是我在多年的性能优化经验中总结出来的认知及方法论。只有了解了这些方法论，我们才能在进行性能优化时，如鱼得水，游刃有余。

这篇文章也没有介绍具体的优化方案，因为性能优化的方案通过一篇文章是介绍不完的，大家有兴趣可以看看我写的掘金小册《Android 性能优化》，可以体系的学一学如何进行优化，上面讲解的方法论，也都会在这本小册中体现出来。

作者：helson赵子健
来源：juejin.cn/post/7169486107866824717

万维网之父、英国计算机科学家 Tim Berners-Lee 在 2022 年 Web 峰会上表示，区块链并不是构建下一代互联网的可行解决方案，我们应该忽略它。

他有自己的 Web 去中心化项目，叫作 Solid。

Berners-Lee 在里斯本举行的 Web 峰会上说，“在讨论新技术的影响时，你必须理解我们正在讨论的术语的真正含义，而不仅仅是停留在流行词的层面，这一点很重要。”

“事实上，Web3 被以太坊那班人用在了区块链上，这是一件可耻的事。事实上，Web3 根本就不是 Web。”

在科技行业，Web3 是一个模糊的术语，被用来描述一个假设的未来互联网版本，它比现在更加去中心化，不被亚马逊、微软和谷歌等少数巨头玩家所主导。

它涉及到一些新的技术，包括区块链、加密货币和非同质化的的代币。

虽然 Berners-Lee 的目标是将个人数据从大型科技公司的控制中解放出来，但他不相信支撑比特币等加密货币的分布式账本技术区块链会是解决方案。

他说，“区块链协议可能对某些事情有用，但对 Solid 来说不是。”Solid 是 Berners-Lee 领导的一个 Web 去中心化项目。“它们太慢、太贵、太公开。个人数据存储必须快速、廉价和私密。”

他说，“忽略所谓的 Web3，那些构建在区块链之上的随机的 Web3，我们不会把它用在 Solid 上。”

Berners-Lee 说，人们经常把 Web3 和“Web 3.0”混为一谈，而“Web 3.0”是他提出的重塑互联网的提议。他的初创公司 Inrupt 旨在让用户控制自己的数据，包括如何访问和存储数据。据 TechCrunch 报道，该公司在去年 12 月获得了一轮 3000 万美元的融资。

Berners-Lee 表示，个人数据被谷歌和 Facebook 等少数大型科技平台独自占有，它们利用这些数据“将我们锁定在它们的平台上”。

他说，“其结果就是一场大数据竞赛，赢家是控制最多数据的公司，其他的都是输家。”

他的初创公司旨在通过三种方式解决这个问题：

• 全球“单点登录”功能，可以让任何人从任何地方登录。

• 允许用户与其他人共享数据的登录 ID。

• 一个“通用 API”或应用程序编程接口，允许应用程序从任何来源提取数据。

Berners-Lee 并不是唯一一个对 Web3 持怀疑态度的知名科技人士。一些硅谷领袖也对 Web3 提出了异议，比如推特联合创始人 Jack Dorsey 和特斯拉首席执行官 Elon Musk。

批评人士表示，Web3 容易出现与加密货币相同的问题，比如欺诈和安全缺陷。

原文链接：https://www.cnbc.com/2022/11/04/web-inventor-tim-berners-lee-wants-us-to-ignore-web3.html

作者 | Ryan Browne

译者 | 明知山

策划 | Tina

网友评论：

@快溜儿的还我昵称：老板有话对你奖

@放学去后山：节约用电奖

@小镜子375：领导不鼓励下班

@钱灿灿秋啾啾：福报都不接吗？

来源于网络

今天聊一个小伙伴在星球上的提问：

问题不难，解决方案也有很多，因此我决定撸一篇文章和大家仔细说说这个问题。

1. 配置文件位置

首先小伙伴们要明白，Spring Boot 默认加载的配置文件是 application.properties 或者 application.yaml，默认的加载位置一共有五个，五个位置可以分为两类：

从 classpath 下加载，这个又细分为两种：

1. 直接读取 classpath 下的配置文件，对应到 Spring Boot 项目中，就是 resources 目录下的配置。

2. 读取 classpath:/config/ 目录下的文件，对应到 Spring Boot 项目中就是 resources/config 目录下的配置。

这两种情况如下图：

从项目所在的当前目录下加载，这个又细分为三种情况：

1. 从项目当前目录下加载配置文件。

2. 从项目当前目录下的 config 文件夹中加载配置文件。

3. 从项目当前目录下的 config 文件夹的子文件夹中加载（孙子文件夹不可以）。

这三种情况如下图：

config 目录下的配置文件可以被加载，config/a 目录下的配置文件也可以被加载，但是 config/a/b 目录下的配置文件不会被加载，因为不是直接子文件夹。

配置文件可以放在这么多不同的位置，如果同一个属性在多个配置文件中都写了，那么后面加载的配置会覆盖掉前面的。例如在 classpath:application.yaml 中设置项目端口号是 8080，在 项目当前目录/config/a/application.yaml 中设置项目端口是 8081，那么最终的项目端口号就是 8081。

这是默认的文件位置。

如果你不想让自己的配置文件叫 application.properties 或者 application.yaml，那么也可以自定义配置文件名称，只需要在项目启动的时候指定配置文件名即可，例如我想设置我的配置文件名为 app.yaml，那么我们可以在启动 jar 包的时候按照如下方式配置，此时系统会自动去上面提到的五个位置查找对应的配置文件：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.name=app

如果项目已经打成 jar 包启动了，那么前面所说的目录中，后三个中的项目当前目录就是指 jar 包所在的目录。

如果你不想去这五个位置查找，那么也可以在启动 jar 包的时候明确指定配置文件的位置和名称，如下：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.location=optional:classpath:/app.yaml

注意，我在 classpath 前面加上了 optional: 表示如果这个配置文件不存在，则按照默认的方式启动，而不会报错说找不到这个配置文件。如果不加这个前缀，那么当系统找不到指定的配置文件时，就会抛出 ConfigDataLocationNotFoundException 异常，进而导致应用启动失败。

如果配置文件和 jar 包在相同的目录结构下，如下图：

那么启动脚本如下：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.location=optional:javaboy/app.yaml

如果 spring.config.location 的配置，只是指定了目录，那么必须以 / 结尾，例如上面这个启动脚本，也可以按照如下方式启动：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.location=optional:javaboy/ --spring.config.name=app

通过 spring.config.location 属性锁定配置文件的位置，通过 spring.config.name 属性锁定配置文件的文件名。

2. 额外位置

前面我们关于配置文件位置的设置，都是覆盖掉已有的配置，如果不想覆盖掉 Spring Boot 默认的配置文件查找策略，又想加入自己的，那么可以按照如下方式指定配置文件位置：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.additional-location=optional:javaboy/app.yaml

如果这个额外指定的配置文件和已有的配置文件有冲突，那么还是以后来者为准。

3. 位置通配符

有一种情况，假设我有 redis 和 mysql 的配置，我想将之放在两个不同的文件夹中以便于管理，像下面这样：

那么在项目启动时，可以通过通配符 * 批量扫描相应的文件夹：

java -jar boot_config_file-0.0.1-SNAPSHOT.jar --spring.config.location=optional:config/*/

使用通配符批量扫描 mysql 和 redis 目录时，默认的加载顺序是按照文件夹的字母排序，即先加载 mysql 目录后加载 redis 目录。

需要注意的是，通配符只能用在外部目录中，不可以用在 classpath 中的目录上。另外，包含了通配符的目录，只能有一个通配符 *，不可以有多个，并且还必须是以 */ 结尾，即一个目录的最后部分可以不确定。

4. 导入外部配置

从 Spring Boot2.4 开始，我们也可以使用 spring.config.import 方法来导入配置文件，相比于 additional-location 配置，这个 import 导入更加灵活，可以导入任意名称的配置文件。

spring.config.import=optional:file:./dev.properties

甚至，这个 spring.config.import 还可以导入无扩展名的配置文件，例如我有一个配置文件，是 properties 格式的，但是这个这个配置文件没有扩展名，现在我想将之作为 properties 格式的配置文件导入，方式如下：

spring.config.import=optional:file:/Users/sang/dev[.properties]

好啦，看完上面的内容，文章一开始的问题答案就不用我多说了吧～

作者：江南一点雨
来源：juejin.cn/post/7168285587374342180

一、背景

工程中引用不同的库（库A和B），当不同的库又同时依赖了某个库的不同版本(如A依赖C的1.1版本，B依赖C2.2版本)，这时就出现了依赖冲突。

二、问题解决步骤

查看依赖树

运行android studio的中如下task任务即可生成依赖关系，查看冲突是由哪哪些库引入的（即找到库A和库B）。

排除依赖

使用 exclude group:'group_name',module:'module_name'

//剔除rxpermissions这依赖中所有com.android.support相关的依赖，避免和我们自己的冲突
implementation 'com.github.tbruyelle:rxpermissions:0.10.2', {
 exclude group: 'com.android.support'
}

注意：下图中红框处表示依赖的版本由1.0.0被提升到了1.1.0。如果对1.0.0的库中的group或module进行exclude时，当库的版本被提升时，exclude将会失效，解决办法时工程中修改库的依赖版本为被提升后的版本。

使用强制版本

冲突的库包含了多个版本，这时可直接使用强制版本。在项目的主module的build.gradle的dependencies节点里添加configurations.all {},{}中的前缀是 resolutionStrategy.force ，后面是指定各module强制依赖的包，如下图所示，强制依赖com.android.tools:sdklib包的30.0.0：

作者：Android_Developer
来源：juejin.cn/post/7042951122872434696

本文将介绍7种JavaScript的优化技巧，这些技巧可以帮助你更好的写出简洁优雅的代码。

1. 字符串的自动匹配（Array.includes）

在写代码时我们经常会遇到这样的需求，我们需要检查某个字符串是否是符合我们的规定的字符串之一。最常见的方法就是使用||和===去进行判断匹配。但是如果大量的使用这种判断方式，定然会使得我们的代码变得十分臃肿，写起来也是十分累。其实我们可以使用Array.includes来帮我们自动去匹配。

代码示例：

// 未优化前的写法
const isConform = (letter) => {
  if (
    letter === "a" ||
    letter === "b" ||
    letter === "c" ||
    letter === "d" ||
    letter === "e"
  ) {
    return true;
  }
  return false;
};

// 优化后的写法
const isConform = (letter) =>
  ["a", "b", "c", "d", "e"].includes(letter);

2.for-of和for-in自动遍历

for-of和for-in，可以帮助我们自动遍历Array和object中的每一个元素,不需要我们手动跟更改索引来遍历元素。

注:我们更加推荐对象(object)使用for-in遍历，而数组(Array)使用for-of遍历

for-of

const arr = ['a',' b', 'c'];
// 未优化前的写法
for (let i = 0; i < arr.length; i++) {
  const element = arr[i];
  console.log(element);
}

// 优化后的写法
for (const element of arr) {
   console.log(element);
}
// expected output: "a"
// expected output: "b"
// expected output: "c"

for-in

const obj = {
  a: 1,
  b: 2,
  c: 3,
};
// 未优化前的写法
const keys = Object.keys(obj);
for (let i = 0; i < keys.length; i++) {
  const key = keys[i];
  const value = obj[key];
  // ...
}

// 优化后的写法
for (const key in obj) {
  const value = obj[key];
  // ...
}

3.false判断

如果你想要判断一个变量是否为null、undefined、0、false、NaN、''，你就可以使用逻辑非（!）取反，来帮助我们来判断,而不用每一个值都用===来判断

// 未优化前的写法
const isFalsey = (value) => {
  if (
    value === null ||
    value === undefined ||
    value === 0 ||
    value === false ||
    value === NaN ||
    value === ""
  ) {
    return true;
  }
  return false;
};

// 优化后的写法
const isFalsey = (value) => !value;

4.三元运算符代替（if/else）

在我们编写代码的时候肯定遇见过if/else选择结构，而三元运算符可以算是if/else的一种语法糖，能够更加简洁的表示if/else。

// 未优化前的写法
let info;
if (value < minValue) {
  info = "Value is最小值";
} else if (value > maxValue) {
  info = "Value is最大值";
} else {
  info = "Value 在最大与最小之间";
}

//优化后的写法
const info =
  value < minValue
    ? "Value is最小值"
    : value > maxValue ? "Value is最大值" : "在最大与最小之间";

5.函数调用的选择

三元运算符还可以帮我们判断当前情况下该应该调用哪一个函数，

function f1() {
  // ...
}
function f2() {
  // ...
}
// 未优化前的写法
if (condition) {
  f1();
} else {
  f2();
}

// 优化后的写法
(condition ? f1 : f2)();

6.用对象代替switch/case选择结构

switch case通常是有一个case值对应一个返回值，这样的结构就类似于我们的对象，也是一个键对应一个值。我们就可以用我们的对象代替我们的switch/case选择结构，使代码更加简洁

const dayNumber = new Date().getDay();

// 未优化前的写法
let day;
switch (dayNumber) {
  case 0:
    day = "Sunday";
    break;
  case 1:
    day = "Monday";
    break;
  case 2:
    day = "Tuesday";
    break;
  case 3:
    day = "Wednesday";
    break;
  case 4:
    day = "Thursday";
    break;
  case 5:
    day = "Friday";
    break;
  case 6:
    day = "Saturday";
}

// 优化后的写法
const days = {
  0: "Sunday",
  1: "Monday",
  2: "Tuesday",
  3: "Wednesday",
  4: "Thursday",
  5: "Friday",
  6: "Saturday",
};
const day = days[dayNumber];

7. 逻辑或(||)的运用

如果我们要获取一个不确定是否存在的值时，我们经常会运用if判断先去判断值是否存在，再进行获取。如果不存在我们就会返回另一个值。我们可以运用逻辑或(||)的特性，去优化我们的代码

// 未优化前的写法
let name;
if (user?.name) {
  name = user.name;
} else {
  name = "Anonymous";
}

// 优化后的写法
const name = user?.name || "Anonymous";

作者：zayyo
来源：juejin.cn/post/7169420903888584711

01 引言

1）背景

这是本人在面试“字节抖音”部门的一道系统设计题，岗位是“后端高级开发工程师”，二面的时候问到的。一开始，面试官笑眯眯地让我做个自我介绍，然后聊了聊项目。

当完美无瑕（吞吞吐吐）地聊完项目，并写了一道算法题之后。

面试官就开始发问了：小伙子，简历里面写到了熟悉架构设计是吧，那你知道程序设计的‘三高’指什么吗？

我心想，那不是由于程序员的系统不靠谱，领导不当人，天天加班改 BUG，导致年纪轻轻都高血脂、高血压和高血糖嘛！

但是，既然是面试，那领导肯定不愿意听这，于是我回答：程序三高，就是系统设计时需要考虑的高并发、高性能和高可用：

• 高并发就是在系统开发的过程中，需要保证系统可以同时并行处理很多请求；

• 高性能是指程序需要尽可能地占用更少的内存和 CPU，并且处理请求的速度要快；

• 高可用通常描述系统在一段时间内不可服务的时候很短，比如全年停机不超过 31.5 秒，俗称 6 个 9，即保证可用的时间为 99.9999%。

于是，面试官微微点头，心想小伙子还行，既然这难不住你，那我可得出大招了，就来道系统设计题吧！

2）需求说明

众所周知，当业务场景需要给用户发送网络地址或者二维码时，由于地址的长度比较长，通常为了占用更少的资源和提升用户体验。例如，谷歌搜索“计算机”词条地址如下：

https://www.google.com/search?q=%E8%AE%A1%E7%AE%97%E6%9C%BA&ei=KNZ5Y7y4MpiW-AaI4LSACw&ved=0ahUKEwi87MGgnbz7AhUYC94KHQgwDbAQ4dUDCBA&uact=5&oq=%E8%AE%A1%E7%AE%97%E6%9C%BA&gs_lcp=Cgxnd3Mtd2l6LXNlcnAQAzIECAAQQzIFCAAQgAQyBQgAEIAEMgUIABCABDIFCC4QgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDoKCAAQRxDWBBCwAzoLCC4QgAQQxwEQ0QM6FggAEOoCELQCEIoDELcDENQDEOUCGAE6BwguENQCEENKBAhBGABKBAhGGABQpBZYzSVglydoA3ABeACAAZ0DiAGdD5IBCTAuNy4xLjAuMZgBAKABAbABCsgBCsABAdoBBAgBGAc&sclient=gws-wiz-serp

很明显，如果将这一长串网址发给用户，是十分不“体面”的。而且，遇到一些有字数限制的系统里面，比如微博发帖子就有字数限制，肯定无法发送这样的长链接地址。一般的短信链接中，大多也都是短链接地址：

所以，为了提升用户体验，以及日常业务的需要。我们需要设计一个短链接生成系统，除了业务功能实现以外，我们还得为全国的网络地址服务。在这么大的用户量下，数据该如何存储，高并发如何处理呢？

02 三种链接生成方法

1）需求分析

我心想，这面试官看着“慈眉善目”还笑眯眯的，但出的题目可不简单，这种类型的系统需要考虑的点太多了，绝对不能掉以轻心。

于是，我分别从链接生成、网址访问、缓存优化和高可用四个方面开始着手设计。

首先，生成短链地址，可以考虑用 UUID 或者自增 ID。对于每一个长链接转短链地址时，都必须生成一个全局唯一的短链值，不然就会发生冲突。所以，短链接的特点是：

• 数据存储量很大，全国的网址每天至少都是百万个短链接地址需要生成；

• 并发量也不小，遇到同时来访问系统，按一天 3600 秒来算，平均每秒至少上千个请求数；

• 短链接不可重复，否则会引起数据访问冲突。

2）雪花算法

首先，生成短链接，可以用雪花算法+哈希的方式来实现。

雪花算法是在分布式场景下，根据时间戳、不同的机器 ID 以及序列号生成的唯一数。它的优点在于简单方便，随取随用。

通过雪花算法取到的唯一数，再用哈希映射，将数字转为一个随机的字符串，如果短链字符串比较长，可以直接取前 6 位。但是，由于哈希映射的结果可能会发生冲突，所以对哈希算法的要求比较高。

2）62 进制数生成短链接

除了雪花算法，还可以用 62 进制数（A-Za-z0-9）来生成短链接地址。首先得到一个自增 ID，再将此值转换为 62 进制（a-zA-Z0-9）的字符串，一个亿的数字转换后也就五六位（1亿 -> zAL6e）。

将短链接服务器域名，与这个字符串进行拼接，就能得到短链接的 URL，比如：t.cn/zAL6e。

而生成自增 ID 需要考虑性能影响和并发安全性，所以我们可以通过 Redis 的 incr 命令来做一个发号器，它是一个原子操作，因此我们不必担心数字的安全性。而 Redis 是内存操作，所以效率也挺高。

3）随机数+布隆过滤器

除了自增 ID 以外，我们还可以生成随机数再转 62 进制的方法来生成短链接。但是，由于随机数可能重复，因此我们需要用布隆过滤器来去重。

布隆过滤器是一个巧妙设计的数据结构，它的原理是将一个值多次哈希，映射到不同的 bit 位上并记录下来。当新的值使用时，通过同样的哈希函数，比对各个 bit 位上是否有值：如果这些 bit 位上都没有值，说明这个数是唯一的；否则，就可能不是唯一的。

当然，这可能会产生误判，布隆过滤器一定可以发现重复的值，但 也可能将不重复的值判断为重复值，误判率大概为 0.05%，是可以接受的范围，而且布隆过滤器的效率极高。

因此，通过布隆过滤器，我们能判断生成的随机数是否重复：如果重复，就重新生成一个；如果不重复，就存入布隆过滤器和数据库，从而保证每次取到的随机数都是唯一的。

4）将短链接存到数据库

存库时，可能会因为库存量和技术栈，选用不同的数据库。但由于公司部门用 MySQL 比较多，且当前题目未提及技术选型，所以我们还是选用 MySQL 作为持久化数据库。

每当生成一个短链接后，需要在 MySQL 存储短链接到长链接的映射关系并加上唯一索引，即 zAL6e -> 真实URL。

03 重定向过程

浏览器访问短链接服务时，根据短链地址取到原始 URL，然后进行网址重定向。我们通常有两种重定向方式：

• 一种是返回给浏览器 301 响应码永久重定向，让其后续直接访问真实的 URL 地址；

• 一种是 302 临时重定向，让浏览器当前这次访问真实 URL，但后续请求时还是根据短链地址访问。

虽然用 301 浏览器只需一次请求，后续可以直接从浏览器获取长链接，这种方法可以提升访问速度，但是它没法统计短链接的访问次数。

所以根据业务需要，我们一般选用 302 重定向。

04 缓存设计

由于短链接是分发到多个用户手里的，可能在短时间内会多次访问，所以从 MySQL 写入/获取到长链接后可以放入 redis 缓存。

1）加入缓存

并且，短链接和长链接的对应关系一般不会频繁修改，所以数据库和缓存的一致性通过简单的旁路缓存模式来保证：

• 读（Read）数据时，若缓存未命中，则先读 DB，从 DB 中取出数据，放入缓存，同时返回响应；

• 写（Write）数据时，先更新 DB，再删除缓存。

当用户需要生成短链接时，先到这个映射表中看一下有没有对应的短链接地址。有就直接返回，并将这个 key-value 的过期时间增加一小时；没有就重新生成，并且将对应关系存入这个映射表中。

缓存的淘汰策略可以选用：

• LRU：Least Recently Used，最近最少使用算法，最近经常被读写的短链地址作为热点数据可以一直存在于缓存，淘汰那些很久没有访问过的短链 key；

• LFU：Least Frequently Userd，最近最不频繁使用算法，最近访问频率高的短链地址作为热点数据，淘汰那些访问频率较低的短链 key。

2）缓存穿透

但是，使用缓存也防止不了一些异常情况，比如“缓存穿透”。所谓缓存穿透，就是查询一个缓存和数据库中都不存在的短链接，如果并发量很大，就会导致所有在缓存中不存在的请求都打到 MySQL 服务器上，导致服务器处理不了这么多请求而阻塞，甚至崩溃。

所以，为了防止不法分子通过类似“缓存穿透”的方式来攻击服务器，我们可以采用两种方法来应对：

• 对不存在的短链地址加缓存，key 为短链接地址，value 值为空，过期时间可以设置得短一点；

• 采用布隆过滤器将已有的短链接多次哈希后存起来，当有短链接请求时，先通过布隆过滤器判断一下该地址是否存在数据库中；如果不在，则说明数据库中不存在该地址，就直接返回。

05 高可用设计

由于缓存和数据库持久化依赖于 Redis 和 MySQL，因此 MySQL 和 Redis 的高可用性必须要保证。

1）MySQL 高可用

MySQL 数据库采用主从复制，进行读写分离。Master 节点进行写操作，Slave 节点用作读操作，并且可以用 Keepalived 来实现高可用。

Keepalived 的原理是采用虚拟 IP，检测入口的多个节点，选用一台热备服务器作为主服务器，并分配给它一个虚拟 IP，外部请求都通过这个虚拟 IP 来访问数据库。

同时，Keepalived 会实时检测多个节点的可用状态，当发现一台服务器宕机或出现故障时，会从集群中将这台服务器踢除。如果这台服务器是主服务器，keepalived 会触发选举操作，从服务器集群中再选出一个服务器充当 master 并分配给它相同的虚拟 IP，以此完成故障转移。

并且，在 Keepalived 的支持下，这些操作都不需要人工参与，只需修复故障机器即可。

2）Redis 高可用

由于在大数据高并发的场景下，写请求全部落在 Redis 的 master 节点上，压力太大。如果一味地采用增加内存和 CPU 这种纵向扩容的方式，那么一台机器所面临的磁盘 IO，网络等压力逐渐增大，也会影响性能。

所以 Redis 采用集群模式，实现数据分片。并且，加入了哨兵机制来保证集群的高可用。它的基本原理是哨兵节点监控集群中所有的主从节点，当主节点宕机或者发生故障以后，哨兵节点会标记它为主观下线；当足够多的哨兵节点将 Redis 主节点标记为主观下线，就将其状态改为客观下线。

此时，哨兵节点们通过选举机制选出一个领头哨兵，对 Redis 主节点进行故障转移操作，以保障 Redis 集群的高可用，这整个流程都不需要人工干预。

3）系统容错

服务在上线之前，需要做好充分的业务量评估，以及性能测试。做好限流、熔断和服务降级的逻辑，比如：采用令牌桶算法实现限流，hystrix 框架来做熔断，并且将常用配置放到可以热更新的配置中心，方便对其实时更改。

当业务量过大时，将同步任务改为异步任务处理。通过这些服务治理方案，让系统更加稳定。

06 后记

当我答完最后一个字的时候，面试官看着我，眼神中充满了“欣赏”与疑惑。我想，他应该是被我这番表现给镇住了，此次面试应该是十拿九稳。

但是，出奇地，面试官没有对刚才的架构设计提出评价，只看了看我说：“那今天的面试就到这里，你有什么想要问的吗？”

这下，轮到我震惊了，那到底过不过呢？倒是给句话呀，于是我问道：“通过这次面试，您觉得我有哪些方面需要提升呢？”

“算法和项目需要再多练练，但是我发现了你一个优点。”面试官笑了笑接着说，“八股文背的倒是挺不错的！”

悬着的心总算放下，我心想：“哦，那稳了~”

作者：xin猿意码
来源：juejin.cn/post/7168090412370886686

昨晚梦见男朋友和别的女人在逛街，梦里我的第一反应是查源代码…结果调试半天查不出来为什么显示的是那个女人不是我，最后含泪把那个女人给注释掉了，再一运行就是我男朋友自己逛街了…醒来囧字脸呆了很久…囧rz

看看神级评论

亡羊补牢型

1. 把那个女人的指针指向你即可；

2. 谁让你把男朋友设成 public 的；

3. 心真软，就该把他的接口屏蔽掉；

4. protected 逛街(youOnly)；

5. 设计问题，应该采用单例模式；

6. 没做回归测试；

7. 标准做法是做个断言；

8. 注释掉了，逛街的参数就不用改了吗？

9. “最后含泪把那个女人注释掉了，再一运行就是我男朋友自己逛街了。”很明显是变量名作用域的问题，改个名字就行了；

10. 还可以有个多线程的算法，把你的优先级设成 99，一个 idle 线程的优先级设成 50，把那个女人的优先级设成 49。酱紫就永远调度不到啦。

破罐破摔型

1. 加个断点看看那个女人是谁；

2. 那也没关系，那就老调用那个女人…你 BF 放在那里不动…养着…

3. 上绝招，用 goto，做个死循环，让他们逛死；

4. 善心点，别 goto 了，加个 exit 结束进程吧，冤冤相报何时了啊。

来源：http://www.douban.com/group/topic/14168111/

写在前面

最近一直在想一个问题；我为什么不愿意主动思考？

引发这个思考的是最近在开发中遇到的一个问题，问题并不难在这里就不多赘述了。遇到这个问题后，我的第一反应就是百度，百度无果后我请教了身边的同事、交流群里的大佬，还是没有解决（提供了一些思路）。没办法，我只能自己思考、尝试，后来发现是某一项隐藏较深的配置有问题。解决这个问题后，我在想：为什么遇到问题的第一时间，我不愿意主动去思考，而是要在一系列的尝试无果后才愿意直面问题呢？是因为领导逼的紧，没有时间？还是能力有限毫无思路？都不是，是我自己本身不愿意去思考。

三重大脑

美国神经生物学家Paul Maclean曾提出一个叫”三重大脑“的理论。按照进化的顺序，把大脑分为三重：爬行动物时期的大脑，爬行脑，控制身体行为、识别危险，快速反应；哺乳动物时期的大脑，情绪脑，与情绪相关，根据相关情绪做出反应；灵长动物时期的大脑，理论脑，关于自尊、自信、自我认知、逻辑、思考等。从进化的时间和生存的重要性来看，爬行脑和情绪脑对人体的控制明显大于逻辑脑。这不难想象，当安全都存在问题时，谁还能静下心来思考，同样的，处于极度愤怒、悲伤的情绪中也没办法思考。因此，思考或者说情绪脑，优先级并不高。同时，思考这种行为相对消耗能量更高（大脑的神经元每天要消耗75%的肝脏血液，消耗占全身总消耗量20%的氧气），本身就被我们的身体排斥。那么，我们大脑不排斥什么，或者说喜欢什么？答案是即时满足。从进化角度来看，我们的祖先过的是茹毛饮血、饔飧不济的生活，对他们来说最重要的是当下，而不是将来，这是人类刻在骨子里的天性，也是我们大脑喜欢即时满足的原因。而思考这种延迟满足的行为是同时被身体和天性所排斥的，所以我们不喜欢思考。那么，我们该如何控制这种天性，如何彻底控制我们的大脑，让逻辑脑当大哥呢？

用进废退

和肌肉一样，当我们不断使用逻辑脑进行思考时，他的话语权会不断扩大，相应的爬行脑和情绪脑带来的不良影响会不断减小，此消彼长，最终形成思考的习惯。

间歇满足

自我控制很难，我们可以适当放松。当我们在进行思考、学习等行为时，大脑渴望即时满足的天性会不断出来作祟，再加上数字时代的今天，诱惑与满足无处不在，稍不注意就会前功尽弃，时时刻刻对抗天性这不现实。我们可以适当、短暂的满足它，如番茄工作法等。这种间歇性的满足是在我们的控制之中的，长此以往，能有效提升我们的自控能力。开始可能很难，坚持下去会越来越轻松。

思考正反馈

通过思考解决某个问题时，我们同样会得到满足，这种来之不易的满足，大脑会更喜欢。 这样的正反馈，可以让我们在提升自己的同时，保持一个长期的、积极的主动思考的状态。

耳濡目染

大脑获取信息的方式有两种，主动思考、被动接受。环境对人的影响是无可估量的，古有孟母三迁，今有高校保安。当我们无力改变当下的自己时，我们可以试着改变环境，再通过环境改变自己，好的环境能让我们在不知不觉中成长。

自我认知

主动思考往往源于自我认知。为什么别人的技术比我好?薪水比我高？是因为智商吗？可能会有一定影响，但占比非常低，更多的源于其自身的主动思考、学习所带来的差距。自我认知让我们发现这份差距，主动思考让我们知道如何弥补这份差距。

作者：侃如
来源：juejin.cn/post/7166658322995609636