前言

• 兔年来临，老板意气风发的说：我们的系统登录页要换做玉兔迎春的背景页，而且用户ctrl+f搜索【玉兔迎春】关键字时，图片要高亮。

新的一年，祝大家身体健康、Bug--

一、明确需求

将系统的登录页面背景换做如上图【玉兔迎春】。

而且，用户可以通过搜索关键字【玉兔迎春】让背景图的文字进行高亮。

下面我们进行分析一下。

二、进行分析

接到该需求的时候，心里是这样子的。

于是，老板像是看穿我的疑惑时，语重心长的对我们说：我们要给用户一个焕然一新的感觉。

疯狂点点头，并想好如何让图片里面的文字进行高亮的对策。

静下来思考片刻，其实不是很难。

2.1 思路

我们只需要盖一层div在图片上，然后设置文字透明，浏览器ctrl+f搜索的时候，会给文字他高亮黄的颜色，我们就可以看到文字了。

盖的这层div，里面包含着我们的文字。

那么，难点就是怎么从图片获取文字出来。

其实这个技术，有个专业词语来描述，叫ocr识别技术。

2.2 ocr

ocr，其实也叫“光学字符识别技术”，是最为常见的、也是目前最高效的文字扫描技术，它可以从图片或者PDF中识别和提取其中的文字内容，输出文本文档，方便验证用户信息，或者直接进行内容编辑。

揭秘该技术：实现文字识别？从图片到文字的过程发生了什么？

分别是输入、图像与处理、文字检测、文本识别，及输出。每个过程都需要算法的深度配合，因此从技术底层来讲，从图片到文字输出，要经历以下的过程：

1、图像输入：读取不同图像格式文件；

2、图像预处理：主要包括图像二值化，噪声去除，倾斜校正等；

3、版面分析：将文档图片分段落，分行；

4、字符切割：处理因字符粘连、断笔造成字符难以简单切割的问题；

5、字符特征提取：对字符图像提取多维特征；

6、字符识别：将当前字符提取的特征向量与特征模板库进行模板粗分类和模板细匹配，识别出字符；

7、版面恢复：识别原文档的排版，按原排版格式将识别结果输出到文本文档；

8、后处理校正: 根据特定的语言上下文的关系，对识别结果进行校正。

2.3 应用

随着ocr技术的成熟，不少软件已经出了该功能。

比如：微信、qq、语雀等等。

还有一些试卷试题，都会用到ocr识别技术。

还有一些技术文档，实现自定义搜索功能，表格关键字高亮。

老板这次需求：把玉兔迎春图实现高亮。

和如上实现的技术思路类似。

我们也可以自定义颜色，加个span标签给其想要的样式。

三、使用

当然，我们可能并不关心底层的实现，只关心怎么怎么去使用。

我们可以调用百度API：文字提取技术

还可以使用java的tesseract-ocr库，其实就是文字的训练。

所以会有个弊端，就是文件可能会有点大，存放着大量文字。

后记

在一个需求的产生之后，我们如果没什么思路，可以借鉴一下，目前市场上有没有类似的技术的沉淀，从而实现需求。

最后，望大家的新的一年，工作顺利，身体健康。

玉兔迎春啦🐇🧨🐇🏮🐇~

👍 如果对您有帮助，您的点赞是我前进的润滑剂。

作者：Dignity_呱
来源：juejin.cn/post/7186459084303335481

效果分析

最近在做项目，碰到了这样一个需求，就是页面有一个元素，这个元素可以在限定的区域内进行拖拽，拖拽完成吸附到左边或者右边，并且在滚动页面的时候，这个元素要半隐状态，停止滚动的时候恢复到原来的位置。如图所示:

根据视频所展示的效果，我们得出了我们需要实现的效果主要有2个部分:

• 拖拽并吸附

• 滚动半隐元素

那么如何实现这2个效果呢？我们一个效果一个效果的来分析。

ps: 由于这里采用的是react技术栈，所以这里以react作为讲解

首先对于第一个效果，我们要想实现拖拽，有2种方式，第一种就是html5提供的拖拽api，还有一种就是监听鼠标的mousedown,mousemove和mouseup事件，由于这里兼容的移动端，所以我采用的是第二种实现方法。

思路是有了，接下来我想的就是将这三个事件封装一下，写成一个hook函数，这样方便调用，也方便扩展。

对于拖拽的实现，我们只需要在鼠标按下的时候，记录一下横坐标x和纵坐标y，在鼠标拖动的时候用当前拖动的横坐标x和横坐标y去与鼠标按下的时候的横坐标x与y坐标相减就可以得到拖动的偏移坐标，而这个偏移坐标就是我们最终要使用到的坐标。

在鼠标按下的时候，我们还需要减去元素本身所在的left偏移和top偏移，这样计算出来的坐标才是正确的。

然后，由于元素需要通过设置偏移来改变位置，因此我们需要将元素脱离文档流，换句话说就是元素使用定位，这里我采用的是固定定位。

hooks函数的实现

基于以上思路，一个任意拖拽功能实现的hooks函数就结构就成型了。

当然由于我们需要限定范围，这时候我们可以思考会有2个方向上的限定，即水平方向和垂直方向上的限定。除此之外，我们还需要提供一个默认的坐标值，也就是说元素默认应该是在哪个位置上。现在我们用伪代码来表示一下这个函数的结构，代码如下:

const useLimitDrag = (el,options,container) => {
    //核心代码
}
export default useLimitDrag;

参数类型

这个hooks函数有3个参数，第一个参数自然是需要拖拽的元素，第二个参数则是配置对象，而第三个参数则是限定的容器元素。拖拽的元素和容器元素都是属于dom元素，在react中，我们还可以传递ref来表示一个dom元素，所以这两个参数，我们可以约定一下类型定义。我们先来定义元素的类型如下:

export type ElementType = Element | HTMLElement | null;

dom元素的类型就是Element | HTMLElement这2个类型，现在我们知道react的ref可以传递dom元素，并且我们还可以传入一个函数当作参数，所以基于这个类型，我们又额外的扩展了参数的类型，也方便配置。让我们继续写下如下代码:

import type { RefObject } from 'react';
export type RefElementType = RefObject<ElementType>;
export type FunctionElementType = () => ElementType;

这样el和container元素的类型就一目了然，我们再定义一个类型简单合并一下这两个类型，代码如下:

export type ParamType = RefElementType | FunctionElementType;

接下来，让我们看配置对象，配置对象主要有2个地方，第一个就是默认值，第二个则是限定方向，因此我们约定了3个参数，islimitX,isLimitY,defaultPosition，并且配置对象都应该是可选的，我们可以使用Partial内置泛型将这个类型包裹一下，ok，来看看代码吧。

export type OptionType = Partial<{
    isLimitX: boolean,
    isLimitY: boolean,
    defaultPosition: {
        x: number,
        y: number
    }
}>;

嗯现在，我们可以修改一下以上的核心函数了，代码如下:

const useLimitDrag = (el: ParamType,options: OptionType,container?: ParamType)  => {
    //核心代码
}
export default useLimitDrag;

返回值类型

下一步，我们需要确定我们返回的值，首先肯定是当前被计算出来的x和y坐标，其次由于我们这个需求还有一个吸附效果，这个吸附效果是什么意思呢？就是说，以屏幕的中间作为划分界限为左右两部分，当拖动的x坐标大于中间，那么就吸附到最右边，否则就吸附到最左边。

根据这个需求，我们可以将坐标分为最大x坐标，最小x坐标以及中间的x坐标,当然由于需求只提到了水平方向上的吸附，垂直方向上并没有，但是为了考虑扩展，与之对应的我们同样要分成最大y坐标，最小y坐标以及中间的y坐标。

最后，我们还可以返回一个是否正在拖动中，方便我们做额外的操作。根据描述，以上的代码我们也就可以构造如下:

export type PositionType = Partial<{ x: number, y: number, isMove: boolean, maxX: number, maxY: number, minX: number, minY: number, centerX: number, centerY: number }>;
// 
const useLimitDrag = (el: ParamType,options: OptionType,container?: ParamType): PositionType  => {
    //核心代码
}
export default useLimitDrag;

核心代码实现第一步---判断当前环境

最基本的结构搭建好了，接下来第一步，我们要做什么？首先当然是判断当前环境是否表示移动端啊。那么如何判断呢？浏览器提供了一个navigator对象，通过这个对象的userAgent属性我们就可以判断，这个属性是一个很长的字符串，但是我们可以从其中一些值看出一些端倪，在移动端的环境中，通常都会看到iPhone|iPod|Android|ios这些字符串值，比如在iphone手机中就会有iPhone字符串，同理android也是。所以我们就可以通过写一个正则表达式来匹配这些字符串，如果有这些字符串就代表是移动端环境，否则就是pc浏览器环境，代码如下:

const isMobile = navigator.userAgent.match(/(iPhone|iPod|Android|ios)/i);

我们为什么要判断是否是移动端环境？因为在移动端环境，我们通常监听的是触摸事件，即touchstart,touchmove与touchend，而非mousedown,mousemove和mouseup。所以下一行代码自然就是定义好事件呢。如下:

const eventType = isMobile ? ['touchstart', 'touchmove', 'touchend'] : ['mousedown', 'mousemove', 'mouseup'];

核心代码实现第二步---一些初始化工作

下一步，我们通过useRef方法来存储拖拽元素和限定拖拽容器元素。代码如下:

const element = useRef<ElementType>();

const containerElement = useRef<ElementType>();

接着我们获取配置对象的值，然后我们定义最大边界的值，代码如下:

const { isLimitX, isLimitY,defaultPosition } = option;

const globalWidthHeight = {

    offsetWidth: window.innerWidth,

    offsetHeight: window.innerHeight

}

随后，我们用一个变量代表鼠标是否按下的状态，这样做的目的是让拖拽变得更丝滑流畅一些，而不容易出问题，然后我们用useState定义返回的值，再定义一个对象存储鼠标按下时的x坐标和y坐标的值。代码如下:

let isStart = false;

const [position, setPosition] = useState<PositionType>({

    x: defaultPosition?.x,

    y: defaultPosition?.y,

    maxX: 0,

    maxY: 0,

    centerX: 0,

    centerY: 0,

    minX: 0,

    minY: 0

});

const [isMove, setIsMove] = useState(false);

const downPosition = {

    x:0,

    y:0

}

另外为了确保拖动在限定区域内，我们需要设置滚动截断的样式，让元素不能在出现滚动条后还能拖动，因为这样会出现问题。我们定义一个方法用来设置，代码如下:

const setOverflow = () => {

    const limitEle = (containerElement.current || document.body) as HTMLElement;

    if (isLimitX) {

        limitEle.style.overflowX = 'hidden';

    } else {

        limitEle.style.overflowX = '';

    }

    if (isLimitY) {

        limitEle.style.overflowY = 'hidden';

    } else {

        limitEle.style.overflowY = '';

    }

}

这个方法也就比较好理解了，如果使用的时候传入isLimitX那么就设置overflowX为hidden，否则不设置，y方向同理。

核心代码的实现第三步---监听事件

接下来，我们在react的钩子函数中监听事件，此时有了一个选择就是钩子函数我们使用useEffect还是useLayoutEffect呢？要决定使用哪个，我们需要知道这两个钩子函数的区别，这个超出了本文范围，不提及，可以查阅相关资料了解，这里我选择的是useLayoutEffect。

在钩子函数的回调函数中，我们首先将拖拽元素和容器元素存储下来，然后如果拖拽元素不存在，我们就不执行后续事件，回调函数返回一个函数，在该函数中我们移除对应的事件。代码如下:

useLayoutEffect(() => {

    element.current = typeof el === 'function' ? el() : el.current;

    containerElement.current = typeof containerRef === 'function' ? containerRef() : containerRef?.current;

    if (!element.current) {

        return;

    }

    element.current.addEventListener(eventType[0], onStartHandler);

    return () => {

        element.current?.removeEventListener(eventType[0], onStartHandler);

    }

}, []);

核心代码实现第四步---拖动开始事件回调

接下来，我们来看一下onStartHandler函数的实现，在这个函数中，我们主要其实就是存储按下时候的坐标值，并且设置状态以及拖拽元素的鼠标样式和滚动截断的样式，随后当然是监听拖动和拖动结束事件，代码如下:

const onStartHandler = useCallback((e:Event) => {

    isStart = true;

    const target = element.current as HTMLElement;

    if (target) {

        target.style.cursor = 'move';

    } 

    const event: Touch | MouseEvent = e instanceof TouchEvent ? e.changedTouches[0] : e as MouseEvent;

    const { clientX, clientY } = event;

    downPosition.x = clientX - target.offsetLeft;

    downPosition.y = clientY - target.offsetTop;

    setOverflow();

    window.addEventListener(eventType[1], onMoveHandler);

    window.addEventListener(eventType[2], onUpHandler);

}, []);

pc端是可以直接从事件对象中拿出来坐标，可是在移动端我们要通过一个changedTouches属性，这个属性是一个伪数组，第一项就是我们要获取到的坐标值。

接下来就是拖动事件的回调函数以及拖动结束的回调函数的实现了。

核心代码实现第五步---拖动事件回调

这是一个最核心实现的回调，我们在这个函数当中是要计算坐标的，首先当然是根据isStart状态来确定是否执行后续逻辑，其次，还要获取到当前拖拽元素，因为我们要根据这个拖拽元素的宽高做坐标的计算，另外还要获取到容器元素，如果没有提供容器元素，那么就是我们最开始定义的globalWidthHeight中取，然后获取鼠标按下时的x和y坐标值，将当前移动的x坐标和y坐标分别与按下时相减，就是我们的移动x坐标和y坐标，如果有设置isLimitX和isLimitY,我们还要额外设置滚动截断样式，并且我们通过将0和moveX以及最大值（也就是屏幕或者是容器元素的宽高减去拖拽元素的宽高）得到我们的最终的moveX和moveY值。

最后，我们将最终的moveX和moveY用react的状态存储起来即可。代码如下:

const onMoveHandler = useCallback((e: Event) => {

    if (!isStart) {

        return;

    }

    setOverflow();

    const event: Touch | MouseEvent = e instanceof TouchEvent ? e.changedTouches[0] : e as MouseEvent;

    const { clientX, clientY } = event;

    if (!element.current) {

        return;

    }

    const { offsetWidth, offsetHeight} = element.current as HTMLElement;

    const { offsetWidth: containerWidth, offsetHeight: containerHeight } = (containerElement.current as HTMLElement ||globalWidthHeight);

    const { x,y } = downPosition;     

    const moveX = clientX - x,

          moveY = clientY - y;     

    const data = {

        x: isLimitX ? Math.max(0, Math.min(containerWidth - offsetWidth, moveX)) : moveX,

        y: isLimitY ? Math.max(0, Math.min(containerHeight - offsetHeight, moveY)) : moveY,

        minX: 0,

        minY: 0,

        maxX: containerWidth - offsetWidth,

        maxY: containerHeight - offsetHeight,

        centerX: (containerWidth - offsetWidth) / 2,

        centerY: (containerHeight - offsetHeight) / 2

    }

    setIsMove(true);

    setPosition(data);

}, []);

核心代码实现第六步--拖动结束回调

最后在拖动结束后，我们需要重置我们做的一些操作，比如样式溢出截断，再比如移除事件的监听，以及恢复鼠标的样式等。代码如下:

const onUpHandler = useCallback(() => {

    const target = element.current as HTMLElement;

    if (target) {

        target.style.cursor = '';

    }

    isStart = false;

    setIsMove(false);

    const limitEle = (containerElement.current || document.body) as HTMLElement;

    limitEle.style.overflowX = '';

    limitEle.style.overflowY = '';

    window.removeEventListener(eventType[1], onMoveHandler);

    window.removeEventListener(eventType[2],onUpHandler);

}, []);

到此为止，我们的第一个效果核心实现就已经算是完成大半部分了，最后我们再把需要用到的状态值返回出去。代码如下:

return {

    ...position,

    isMove

}

合并以上的代码，就成了我们最终的hooks函数，代码如下:

import { useState, useCallback, useLayoutEffect, useRef } from 'react';

import type { RefObject } from 'react';



export type ElementType = Element | HTMLElement | null;

export type RefElementType = RefObject<ElementType>;

export type FunctionElementType = () => ElementType;

export type ParamType = RefElementType | FunctionElementType;

export type PositionType = Partial<{ x: number, y: number, isMove: boolean, maxX: number, maxY: number, minX: number, minY: number, centerX: number, centerY: number }>;

export type OptionType = Partial<{

    isLimitX: boolean,

    isLimitY: boolean,

    defaultPosition: {

        x: number,

        y: number

    }

}>;

const useAnyDrag = (el: ParamType, option: OptionType = { isLimitX: true, isLimitY: true,defaultPosition:{ x:0,y:0 } }, containerRef?: ParamType): PositionType => {

    const isMobile = navigator.userAgent.match(/(iPhone|iPod|Android|ios)/i);

    const eventType = isMobile ? ['touchstart', 'touchmove', 'touchend'] : ['mousedown', 'mousemove', 'mouseup'];

    const element = useRef<ElementType>();

    const containerElement = useRef<ElementType>();

    const { isLimitX, isLimitY,defaultPosition } = option;

    const globalWidthHeight = {

        offsetWidth: window.innerWidth,

        offsetHeight: window.innerHeight

    }

    let isStart = false;

    const [position, setPosition] = useState<PositionType>({

        x: defaultPosition?.x,

        y: defaultPosition?.y,

        maxX: 0,

        maxY: 0,

        centerX: 0,

        centerY: 0,

        minX: 0,

        minY: 0

    });

    const [isMove, setIsMove] = useState(false);

    const downPosition = {

        x:0,

        y:0

    }

    const setOverflow = () => {

        const limitEle = (containerElement.current || document.body) as HTMLElement;

        if (isLimitX) {

            limitEle.style.overflowX = 'hidden';

        } else {

            limitEle.style.overflowX = '';

        }

        if (isLimitY) {

            limitEle.style.overflowY = 'hidden';

        } else {

            limitEle.style.overflowY = '';

        }

    }

    const onStartHandler = useCallback((e:Event) => {

        isStart = true;

        const target = element.current as HTMLElement;

        if (target) {

            target.style.cursor = 'move';

        } 

        const event: Touch | MouseEvent = e instanceof TouchEvent ? e.changedTouches[0] : e as MouseEvent;

        const { clientX, clientY } = event;

        downPosition.x = clientX - target.offsetLeft;

        downPosition.y = clientY - target.offsetTop;

        setOverflow();

        window.addEventListener(eventType[1], onMoveHandler);

        window.addEventListener(eventType[2], onUpHandler);

    }, []);

    const onMoveHandler = useCallback((e: Event) => {

        if (!isStart) {

            return;

        }

        setOverflow();

        const event: Touch | MouseEvent = e instanceof TouchEvent ? e.changedTouches[0] : e as MouseEvent;

        const { clientX, clientY } = event;

        if (!element.current) {

            return;

        }

        const { offsetWidth, offsetHeight} = element.current as HTMLElement;

        const { offsetWidth: containerWidth, offsetHeight: containerHeight } = (containerElement.current as HTMLElement || globalWidthHeight);

        const { x,y } = downPosition;     

        const moveX = clientX - x,

              moveY = clientY - y;     

        const data = {

            x: isLimitX ? Math.max(0, Math.min(containerWidth - offsetWidth, moveX)) : moveX,

            y: isLimitY ? Math.max(0, Math.min(containerHeight - offsetHeight, moveY)) : moveY,

            minX: 0,

            minY: 0,

            maxX: containerWidth - offsetWidth,

            maxY: containerHeight - offsetHeight,

            centerX: (containerWidth - offsetWidth) / 2,

            centerY: (containerHeight - offsetHeight) / 2

        }

        setIsMove(true);

        setPosition(data);

    }, []);

    const onUpHandler = useCallback(() => {

        const target = element.current as HTMLElement;

        if (target) {

            target.style.cursor = '';

        }

        isStart = false;

        setIsMove(false);

        const limitEle = (containerElement.current || document.body) as HTMLElement;

        limitEle.style.overflowX = '';

        limitEle.style.overflowY = '';

        window.removeEventListener(eventType[1], onMoveHandler);

        window.removeEventListener(eventType[2],onUpHandler);

    }, []);

    useLayoutEffect(() => {

        element.current = typeof el === 'function' ? el() : el.current;

        containerElement.current = typeof containerRef === 'function' ? containerRef() : containerRef?.current;

        if (!element.current) {

            return;

        }

        element.current.addEventListener(eventType[0], onStartHandler);

        return () => {

            element.current?.removeEventListener(eventType[0], onStartHandler);

        }

    }, []);

    return {

        ...position,

        isMove

    }

}

export default useAnyDrag;

接下来我们来看第二个效果的实现。

半隐效果的实现分析

第二个效果实现的难点在哪里？我们都知道监听元素的滚动事件可以知道用户正在滚动页面，可是我们并不知道用户是否停止了滚动，而且也没有相关的事件或者是API能够让我们去监听用户停止了滚动，那么难点就在这里，如何知道用户是否停止了滚动。

要解决这个问题，我们还得从滚动事件中作文章，我们知道如果用户一直在滚动页面的话，滚动事件就会一直触发，假设我们在该事件中延迟个数百毫秒执行某个操作，是否就代表用户停止了滚动，然后我们可以执行相应的操作？

幸运的是，我从这里找到了答案，还真的是这么做。

如此一来，这个效果我们就实现了一大半了，我们实现一个useIsScroll函数，然后返回一个布尔值代表用户是否正在滚动和停止滚动两种状态，为了完成额外的操作，我们还可以返回一个用户滚动停止时的当前元素距离文档顶部的一个距离，也就是scrollTop。

如此一来，这个函数的实现就比较简单了，还是在react钩子函数中监听滚动事件，然后执行修改状态值的操作。但是现在还有一个问题，那就是我们如何去存储状态？

核心代码实现第一步--解决状态存储的响应式

如果使用useState来存储的话，似乎并没有达到响应式，好在react还提供了一个useRef函数，这个是一个响应式的，我们可以基于这个hooks函数结合useReducer函数来封装一个useGetSet函数，这个函数也在这里有总结到，感兴趣的可以去看看。

这个函数的实现其实也不难，主要就是利用useReducer的第二个参数强行去更新状态值，然后返回更新后的状态值。代码如下:

export const useGetSet = <T>(initialState:T):[() => T,(s:T) => void] => {

    const state = useRef<T>(initialState);

    const [,update] = useReducer(() => Object.create(null),{});

    const updateState = (newState: T) => {

        state.current = newState;

        update();

    }

    return useMemo(() => [

        () => state.current,

        updateState

    ],[])

}

核心代码实现第二步--构建hooks函数

接下来我们来看这个hooks函数，很明显这个hooks函数有2个参数，第一个则是监听滚动事件的滚动元素，第二个则是一个延迟时间。滚动元素的类型与前面的拖拽函数保持一致，我们来详细看看。

const useIsScroll = <T extends HTMLElement>(el: Window | T | (() => T) = window,throlleTime:number = 300): {

    isScroll: boolean,

    scrollTop: number

} => { 

    //核心代码

}

需要注意这里设置了默认值，el默认值时window对象，throlleTime默认值时300

接下来我们就是使用useSetGet方法存储状态，定义一个timer用于延迟函数定时器，然后监听滚动事件，在事件的回调函数中执行相应的修改状态值的操作，最后就是返回这两个状态值即可。代码如下:

const useIsScroll = <T extends HTMLElement>(el: Window | T | (() => T) = window,throlleTime:number = 300): {

    isScroll: boolean,

    scrollTop: number

} => {

    const [isScroll,setIsScroll] = useGetSet(false);

    const [scrollTop,setScrollTop] = useGetSet(0);

    const timer = useRef<ReturnType<typeof setTimeout> | null>(null);

    const onScrollHandler = useCallback(() => {

        setIsScroll(true);

        setScrollTop(window.scrollY);

        if(timer.current){

            clearTimeout(timer.current);

        }

        timer.current = setTimeout(() => {

            setIsScroll(false);

        },throlleTime)

    },[])

    useLayoutEffect(() => {

        const ele = typeof el === 'function' ? (el as () => T)() : el;

        if(!ele){

            return;

        }

        ele.addEventListener('scroll',onScrollHandler,false);

        return () => {

            ele.removeEventListener('scroll',onScrollHandler,false);

        }

    },[]);

    return {

        isScroll: isScroll(),

        scrollTop: scrollTop()

    };

}

整个hooks函数代码实现起来简单明了，所以也没什么难点，只要理解到了思路，就很简单了。

两个hooks函数的使用

核心功能我们已经实现了，接下来使用起来也比较简单，样式代码如下:

* {

    margin: 0;

    padding: 0;

    box-sizing: border-box;

}

body,html {

    height: 100%;

}

body {

    overflow:auto;

}

.App {

    position: relative;

}

.overHeight {

    height: 3000px;

}

.drag {

    position: fixed;

    width: 150px;

    height: 150px;

    border: 3px solid #2396ef;

    background: linear-gradient(135deg,#efac82 10%,#da5b0c 90%);

    z-index: 2;

    left: 0;

    top: 0;

}

.transition {

    transition: all 1.2s ease-in-out;

}

组件代码如下:

import useAnyDrag from "./hooks/useAnyDrag";
import './App.css';
import useIsScroll from "./hooks/useIsScroll";
import { createRef } from "react";

const App = () => {
    // 这里是使用核心代码
   const { x, y, isMove, centerX, minX, maxX } = useAnyDrag(() => document.querySelector('#drag'));
   //这里是使用核心代码    
   const {isScroll} = useIsScroll();
   const scrollElement = createRef<HTMLDivElement>();
   const getLeftPosition = () => {
      if (!x || !centerX || isMove) {
         return x;
      }
      if (x <= centerX) {
         return minX || 0;
      } else {
         return maxX;
      }
   }
   const scrollPosition = () => {
      if (typeof getLeftPosition() === 'number') {
         if (getLeftPosition() === 0) {
            return -((scrollElement.current?.offsetWidth || 0) / 2);
         } else {
            return getLeftPosition() as number + (scrollElement.current?.offsetWidth || 0) / 2;
         }
      }
      return 0;
   }
   return (
      <div className="App">
         <div className="overHeight"></div>
         <div className={`${ isScroll ? 'drag transition' : 'drag'}`}
            style={{ left: (isScroll ? scrollPosition() : getLeftPosition()) + 'px', top: y + 'px' }}
            id="drag"
            ref={scrollElement}
         ></div>
      </div>
   )
}
export default App;

结语

经过以上的分析，我们就完成了这样一个需求，感觉实现完了之后，还是收获满满的，总结一下我学到了什么。

1. 拖拽事件的监听以及拖拽坐标的计算

2. 滚动事件的监听以及react响应式状态的实现

3. 移动端环境与pc环境的判断

4. 如何知道用户停止了滚动

本文就到此为止了，感谢大家观看，最后贴一下在线demo如下所示。

code.juejin.cn/pen/7164578…

作者：夕水
来源：juejin.cn/post/7163153386911563813

一、 什么是Backbone

在前端的发展道路中，前端框架元老之一jQuery对繁琐的DOM操作进行了封装，提供了链式调用、各类选择器，屏蔽了不同浏览器写法的差异性，但是前端开发过程中依然存在作用域污染、代码复用度低、冗余度高、数据和事件绑定烦琐等痛点。

5年后，Backbone横空出世，通过与Underscore、Require、Handlebar的整合，提供了一个轻量和友好的前端开发解决方案，其诸多设计思想对于后续的现代化前端框架发展起到了举足轻重的作用，堪称现代前端框架的基石。

通过对Backbone前端框架的学习，让我们领略其独特的设计思想。



二、 核心架构

按照MVC框架的定义，MVC是用来将应用程序分为三个主要逻辑组件的架构模式：模型，视图和控制器。这些组件被用来处理一个面向应用的特定开发。 MVC是最常用的行业标准的Web开发框架，以创建可扩展的项目之一。 Backbone.js为复杂WEB应用程序提供模型(models)、集合(collections)、视图(views)的结构。

◦ 其中模型用于绑定键值数据，并通过RESRful JSON接口连接到应用程序；

◦ 视图用于UI界面渲染，可以声明自定义事件，通过监听模型和集合的变化执行相应的回调（如执行渲染）。





如图所示，当用户与视图层产生交互时，控制层监听变化，负责与数据层进行数据交互，触发数据Change事件，从而通知视图层重新渲染，以实现UI界面更新。更进一步，当数据层发生变化时，由Backbone提供了数据层和服务器数据共享同步的能力。

其设计思想主要包含以下几点：

◦数据绑定（依赖渲染模板引擎）、事件驱动（依赖Events）

◦视图组件化，并且组件有了生命周期的概念

◦前端路由配置化，实现页面局部刷新

这些创新的思想，在现代前端框架中进一步得到了继承和发扬。



三、 部分源码解析

Backbone极度轻量，编译后仅有几kb，贯穿其中的是大量的设计模式：工厂模式、观察者模式、迭代器模式、适配器模式……，代码流畅、实现过程比较优雅。按照功能拆分为了Events、Model、Collection、Router、History、View等若干模块，这里摘取了部分精彩源码进行了解析，相信对我们的日常代码开发也有一定指导作用：

（1）迭代器

EventsApi起到一个迭代器分流的作用，对多个事件进行解析拆分，设计的非常经典，执行时以下用法都是合法的：

◦用法一：传入一个名称和回调函数的对象

modal.on({
    "change": change_callback,
    "remove": remove_callback
})

◦用法二：使用空格分割的多个事件名称绑定到同一个回调函数上

model.on("change remove", common_callback)

实现如下：

var eventsApi = function(iteratee, events, name, callback, opts) {
    var i = 0, names;
    if(name && typeof name === 'object') {
        // 处理第一种用法
        if(callback !== void 0 && 'context' in opts && opts.context === void 0) opts.context = callback;
        for(names = _.keys(names); i < names.length; i++) events = eventsApi(iteratee, events, names[i], name[names[i]], opts);
    } else if(name && eventSplitter.test(name)) {
        // 处理第二种用法
        for(names = name.split(eventSplitter); i < names.length; i++) events = iteratee(events, names[i], callback, opts);
    } else {
        events = iteratee(events, name, callback, opts);
    }
    return events;
}

（2）监听器

用于一个对象监听另外一个对象的事件，例如，在A对象上监听在B对象上发生的事件，并且执行A的回调函数：

A.listenTo(B, "b", callback)

实际上这个功能用B对象来监听也可以实现：

B.on("b", callback, A)

这么做的好处是，方便对A创建、销毁逻辑的代码聚合，并且对B的侵入程度较小。实现如下：

Events.listenTo = function(obj, name, callback) {
    if(!obj) return this;
    var id = obj._listenId || (obj._listenId = _.uniqueId('l'));
    // 当前对象的所有监听对象
    var listeningTo = this._listeningTo || (this._listeningTo = {});
    var listening = listeningTo[id];
    
    if(!listening) {
        // 创建自身监听id
        var thisId = this._listenId || (this._listenId = _.uniqueId('l'));
        listening = listeningTo[id] = {obj: obj, objId: id, id: thisId, listeningTo: listeningTo, count: 0};
    }
    // 执行对象绑定
    internalOn(obj, name, callback, this, listening);
    return this；
}

（3）Model值set

通过option-flags兼容赋值、更新、删除等操作，这么做的好处是融合公共逻辑，简化代码逻辑和对外暴露api。实现如下：

set: function(key, val, options) {
    if(key == null) return this;
    // 支持两种赋值方式: 对象或者 key\value
    var attrs;
    if(typeof key === 'object') {
        attrs = key;
        options = val;
    } else {
        (attrs = {})[key] = val;
    }
    options || (options = {});
    ……
    var unset = options.unset;
    var silent = options.silent;
    var changes = [];
    var changing = this._changing; // 处理嵌套set
    this._changing = true;
    
    if(!changing) {
        // 存储变更前的状态快照 
        this._previousAttributes = _.clone(this.attributes);
        this.changed = {};
    }
    var current = this.attributes;
    var changed = this.changed;
    var prev = this._previousAttributes;
    
    for(var attr in attrs) {
        val = attrs[attr];
        if(!_.isEqual(current[attr], val)) changes.push(attr);
        // changed只存储本次变化的key
        if(!_.isEqual(prev[attr], val)) {
            changed[attr] = val;
        } else {
            delete changed[attr]
        }
        unset ? delete current[attr] : (current[attr] = val)
    }
    if(!silent) {
        if(changes.length) this._pending = options;
        for(var i=0; i<changes.length; i++) {
            // 触发 change:attr 事件
            this.trigger('change:' + changes[i], this, current[changes[i]], options);
        }
    }
    if(changing) return this;
    if(!silent) {
        // 处理递归change场景
        while(this._pending) {
            options = this._pending;
            this._pending = false;
            this.trigger('change', this, options);
        }
    }
    this._pending = false;
    this._changing = false;
    return this;
}

四、 不足（对比react、vue）

对比现代前端框架，由于Backbone本身比较轻量，对一些内容细节处理不够细腻，主要体现在：

◦视图和数据的交互关系需要自己分类编写逻辑，需要编写较多的监听器

◦监听器数量较大，需要手动销毁，维护成本较高

◦视图树的二次渲染仅能实现组件整体替换，并非增量更新，存在性能损失

◦路由切换需要自己处理页面更新逻辑



五、为什么选择Backbone

看到这里，你可能有些疑问，既然Backbone存在这些缺陷，那么现在学习Backbone还有什么意义呢？

首先，对于服务端开发人员，Backbone底层依赖underscore/lodash、jQuery/Zepto，目前依然有很多基于Jquery和Velocity的项目需要维护，会jQuery就会Backbone，学习成本低；通过Backbone能够学习用数据去驱动View更新，优化jQuery的写法；Backbone面对对象编程，符合Java开发习惯。

其次，对于前端开发人员，能够学习其模块化封装库类函数，提升编程技艺。Backbone的组件化开发，和现代前端框架有很多共通之处，能够深入理解其演化历史。

作者：京东零售 陈震
来源：juejin.cn/post/7197075558941311035

Flex 布局目前已经非常流行了,现在几乎已经兼容所有浏览器了。在文章开始之前我们需要思考一个问题:我们为什么要使用 Flex 布局?

其实答案很简单,那就是 Flex 布局好用。一个新事物的出现往往是因为旧事物不那么好用了,比如,如果想让你用传统的 css 布局来实现一个块元素垂直水平居中你会怎么做?实现水平居中很简单,margin: 0 auto就行,而实现垂直水平居中则可以使用定位实现:

<div class="container">
  <div class="item"></div>
</div>
.container {
  position: relative;
  width: 300px;
  height: 300px;
  background: red;
}
.item {
  position: absolute;
  background: black;
  width: 50px;
  height: 50px;
  margin: auto;
  left: 0;
  top: 0;
  bottom: 0;
  right: 0;
}

或者

.item {
  position: absolute;
  background: black;
  width: 50px;
  height: 50px;
  margin: auto;
  left: calc(50% - 25px);
  top: calc(50% - 25px);
}

但是这样都显得特别繁琐,明明可以一个属性就能解决的事情没必要写这么麻烦。而使用 Flex 则可以使用 place-content 属性简单的实现(place-content 为 justify-content 和 align-content 简写属性)

.container {
  width: 300px;
  height: 300px;
  background: red;
  display: flex;
  place-content: center;
}
.item {
  background: black;
  width: 50px;
  height: 50px;
}

接下来的本篇文章将会带领大家一起来探讨Flex布局

基本概念

我们先写一段代码作为示例(部分属性省略)

html

<div class="container">
  <div class="item">flex项目</div>
  <div class="item">flex项目</div>
  <div class="item">flex项目</div>
  <div class="item">flex项目</div>
</div>
.container {
  display: flex;
  width: 800px;
  gap: 10px;
}
.item {
  color: #fff;
}

flex 容器

我们可以将一个元素的 display 属性设置为 flex,此时这个元素则成为flex 容器比如container元素

flex 项目

flex 容器的子元素称为flex 项目,比如item元素

轴

flex 布局有两个轴,主轴和交叉轴,至于哪个是主轴哪个是交叉轴则有flex 容器的flex-direction属性决定,默认为:flex-direction:row,既横向为主轴,纵向为交叉轴,

flex-direction还可以设置其它三个属性,分别为row-reverse,column,column-reverse。

• row-reverse

• column

• column-reverse

从这里我们可以看出 Flex 轴的方向不是固定不变的,它受到flex-direction的影响

不足空间和剩余空间

当 Flex 项目总宽度小于 Flex 容器宽度时就会出现剩余空间

当 Flex 项目总宽度大于 Flex 容器宽度时就会出现不足空间

Flex 项目之间的间距

Flex 项目之间的间距可以直接在 Flex 容器上设置 gap 属性即可,如

<div class="container">
  <div class="item">A</div>
  <div class="item">B</div>
  <div class="item">C</div>
  <div class="item">D</div>
</div>
.container {
  display: flex;
  width: 500px;
  height: 400px;
  gap: 10px;
}
.item {
  width: 150px;
  height: 40px;
}

Flex 属性

flex属性是flex-grow,flex-shrink,flex-basis三个属性的简写。下面我们来看下它们分别是什么。

• flex-basis可以设定 Flex 项目的大小,一般主轴为水平方向的话和 width 解析方式相同,但是它不一定是 Flex 项目最终大小,Flex 项目最终大小受到flex-grow,flex-shrink以及剩余空间等影响,后面文章会告诉大家最终大小的计算方式

• flex-grow为 Flex 项目的扩展系数,当 Flex 项目总和小于 Flex 容器时就会出现剩余空间,而flex-grow的值则可以决定这个 Flex 项目可以分到多少剩余空间

• flex-shrink为 Flex 项目的收缩系数,同样的,当 Flex 项目总和大于 Flex 容器时就会出现不足空间,flex-shrink的值则可以决定这个 Flex 项目需要减去多少不足空间

既然flex属性是这三个属性的简写,那么flex属性简写方式分别代表什么呢?

flex属性可以为 1 个值,2 个值,3 个值,接下来我们就分别来看看它们代表什么意思

• 一个值

如果flex属性只有一个值的话,我们可以看这个值是否带单位,带单位那就是flex-basis,不带就是flex-grow

.item {
  flex: 1;

  /* 相当于 */
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: 0;
}
 .item {
  flex: 30px;

  /* 相当于 */
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: 30px;
}

• 两个值

当flex属性有两个值的话,第一个无单位的值就是flex-grow,第一个无单位的值则是flex-shrink,有单位的就是flex-basis

.item {
  flex: 1 2;

  /* 相当于 */
  flex-grow: 1;
  flex-shrink: 2;
  flex-basis: 0;
}
 .item {
  flex: 30px 2;

  /* 相当于 */
  flex-grow: 2;
  flex-shrink: 1;
  flex-basis: 30px;
}

• 三个值

当flex属性有三个值的话,第一个无单位的值就是flex-grow,第一个无单位的值则是flex-shrink,有单位的就是flex-basis

.item {
  flex: 1 2 10px;

  /* 相当于 */
  flex-grow: 1;
  flex-shrink: 2;
  flex-basis: 10px;
}
 .item {
  flex: 30px 2 1;

  /* 相当于 */
  flex-grow: 2;
  flex-shrink: 1;
  flex-basis: 30px;
}

 .item {
  flex: 2 30px 1;

  /* 相当于 */
  flex-grow: 2;
  flex-shrink: 1;
  flex-basis: 30px;
}

另外,flex 的值还可以为initial,auto,none。

• initial

initial 为默认值,和不设置 flex 属性的时候表现一样,既 Flex 项目不会扩展,但会收缩,Flex 项目大小有本身内容决定

 .item {

  flex: initial;



  /* 相当于 */

  flex-grow: 0;

  flex-shrink: 1;

  flex-basis: auto;

}

• auto

当 flex 设置为 auto 时,Flex 项目会根据自身内容确定flex-basis,既会拓展也会收缩

 .item {

  flex: auto;



  /* 相当于 */

  flex-grow: 1;

  flex-shrink: 1;

  flex-basis: auto;

}

• none

none 表示 Flex 项目既不收缩,也不会扩展

 .item {

  flex: none;



  /* 相当于 */

  flex-grow: 0;

  flex-shrink: 0;

  flex-basis: auto;

}

Flex 项目大小的计算

首先看一下 flex-grow 的计算方式

flex-grow

面试中经常问到: 为什么 flex 设置为 1 的时候,Flex 项目就会均分 Flex 容器? 其实 Flex 项目设置为 1 不一定会均分容器(后面会解释),这里我们先看下均分的情况是如何发生的

同样的我们先举个例子

<div>

  <div>Xiaoyue</div>

  <div>June</div>

  <div>Alice</div>

  <div>Youhu</div>

  <div>Liehuhu</div>

</div>

.container {

  display: flex;

  width: 800px;

}

.item {

  flex: 1;

  font-size: 30px;

}

flex 容器总宽度为 800px,flex 项目设置为flex:1,此时页面上显示

我们可以看到每个项目的宽度为 800/5=160,下面来解释一下为什么会均分:

首先

 .item {

  flex: 1;



  /* 相当于 */

  flex-grow: 1;

  flex-shrink: 1;

  flex-basis: 0;

}

因为flex-basis为 0,所有 Flex 项目扩展系数都是 1,所以它们分到的剩余空间都是一样的。下面看一下是如何计算出最终项目大小的

这里先给出一个公式:

Flex项目弹性量 = (Flex容器剩余空间/所有flex-grow总和)\*当前Flex项目的flex-grow

其中Flex项目弹性量指的是分配给 Flex 项目多少的剩余空间,所以 Flex 项目的最终宽度为

flex-basis+Flex项目弹性量。

根据这个公式,上面的均分也就很好理解了,因为所有的flex-basis为 0,所以剩余空间就是 800px,每个 Flex 项目的弹性量也就是(800/1+1+1+1+1)*1=160,那么最终宽度也就是160+0=160

刚刚说过 flex 设置为 1 时 Flex 项目并不一定会被均分,下面就来介绍一下这种情况,我们修改一下示例中的 html,将第一个 item 中换成一个长单词

<div>

  <div>Xiaoyueyueyue</div>

  <div>June</div>

  <div>Alice</div>

  <div>Youhu</div>

  <div>Liehu</div>

</div>

此时会发现 Flex 容器并没有被均分

因为计算出的灵活性 200px 小于第一个 Flex 项目的min-content(217.16px),此时浏览器会采用 Flex 项目的min-content作为最终宽度,而后面的 Flex 项目会在第一个 Flex 项目计算完毕后再进行同样的计算

我们修改一下 flex,给它设置一个 flex-basis,看下它计算之后的情况

.item {

  text-align: center;

  flex: 1 100px;

}

因为每个项目的flex-basis都是 100px,Flex 容器剩余空间为800-500=300px,所以弹性量就是(300/5)*1=60px,最终宽度理论应该为100+60=160px,同样的因为第一个 Flex 项目的min-content为 217.16px,所以第一个 Flex 项目宽度被设置为 217.16px,最终表现和上面一样

我们再来看一下为什么第 2,3,4,5 个 Flex 项目宽度为什么是 145.71px

当浏览器计算完第一个 Flex 项目为 217.16px 后,此时的剩余空间为800-217.16-100*4=182.84,第 2 个 Flex 项目弹性量为(182.84/1+1+1+1)*1=45.71,所以最终宽度为100+45.71=145.71px,同样的后面的 Flex 项目计算方式是一样的,但是如果后面再遇到长单词,假如第五个是长单词,那么不足空间将会发生变化,浏览器会将第五个 Flex 项目宽度计算完毕后再回头进行一轮计算,具体情况这里不再展开

所以说想要均分 Flex 容器 flex 设置为 1 并不能用在所有场景中,其实当 Flex 项目中有固定宽度元素也会出现这种情况,比如一张图片等,当然如果你想要解决这个问题其实也很简单,将 Flex 项目的min-width设置为 0 即可

.item {

  flex: 1 100px;

  min-width: 0;

}

flex-grow 为小数

flex-grow 的值不仅可以为正整数,还可以为小数,当为小数时也分为两种情况:所有 Flex 项目的 flex-grow 之和小于等于 1 和大于 1,我们先看小于等于 1 的情况,将例子的改成

<div>

  <div>Acc</div>

  <div>Bc</div>

  <div>C</div>

  <div>DDD</div>

  <div>E</div>

</div>

.item:nth-of-type(1) {

  flex-grow: 0.1;

}

.item:nth-of-type(2) {

  flex-grow: 0.2;

}

.item:nth-of-type(3) {

  flex-grow: 0.2;

}

.item:nth-of-type(4) {

  flex-grow: 0.1;

}

.item:nth-of-type(5) {

  flex-grow: 0.1;

}

效果如图

我们可以发现项目并没有占满容器,它的每个项目的弹性量计算方式为

Flex项目弹性量=Flex容器剩余空间*当前Flex项目的flex-grow

相应的每个项目的实际宽度也就是flex-basis+弹性量,首先先不设置 flex-grow,我们可以看到每个项目的 flex-basis 分别为: 51.2 , 33.88 , 20.08 , 68.56 , 16.5

所以我们可以计算出 Flex 容器的剩余空间为800-51.2 -33.88 - 20.08 - 68.56 - 16.5=609.78,这样我们就可以算出每个项目的实际尺寸为

A: 实际宽度 = 51.2 + 609.78*0.1 = 112.178

B: 实际宽度 = 33.88 + 609.78*0.2 = 155.836

...

下面看下 flex-grow 之和大于 1 的情况,将例子中的 css 改为

.item:nth-of-type(1) {

  flex-grow: 0.1;

}

.item:nth-of-type(2) {

  flex-grow: 0.2;

}

.item:nth-of-type(3) {

  flex-grow: 0.3;

}

.item:nth-of-type(4) {

  flex-grow: 0.4;

}

.item:nth-of-type(5) {

  flex-grow: 0.5;

}

此时的效果为

可以看出 Flex 项目是占满容器的,它的计算方式其实和 flex-grow 为正整数时一样

Flex项目弹性量 = (Flex容器剩余空间/所有flex-grow总和)\*当前Flex项目的flex-grow

所以我们可以得出一个结论: Flex 项目的 flex-grow 之和小于 1,Flex 项目不会占满 Flex 容器

flex-shrink

flex-shrink 其实和 flex-grow 基本一样,就是扩展变成了收缩,flex-grow 是项目比例增加容器剩余空间,而 flex-shrink 则是比例减去容器不足空间

修改一下我们的例子:

.item {

  flex-basis: 200px;

  /* 相当于 */

  flex-shrink: 1;

  flex-grow: 0;

  flex-basis: 200px;

}

此时项目的总宽度200*5=1000px已经大于容器总宽度800px,此时计算第一个项目的不足空间就是800-200*5=-200px,第二个项目的不足空间则是800-第一个项目实际宽度-200*4,依次类推

最终计算公式其实和 flex-grow 计算差不多

Flex项目弹性量 = (Flex容器不足空间/所有flex-shrink总和)*当前Flex项目的flex-shrink

只不过,所以上面例子每个项目可以计算出实际宽度为

第一个 Flex 项目: 200+((800-200x5)/5)*1 = 160px

第二个 Flex 项目: 200+((800-160-200x4)/4)*1 = 160px

第三个 Flex 项目: 200+((800-160-160-200x3)/3)*1 = 160px

第四个 Flex 项目: 200+((800-160-160-160-200x2)/2)*1 = 160px

第五个 Flex 项目: 200+((800-160-160-160-160-200x1)/1)*1 = 160px

如果 Flex 项目的min-content大于flex-basis,那么最终的实际宽度将会取该项目的min-content,比如改一下例子,将第一个 Flex 项目改成长单词

<div>

  <div>XiaoyueXiaoyue</div>

  <div>June</div>

  <div>Alice</div>

  <div>Youhu</div>

  <div>Liehu</div>

</div>

可以看出浏览器最终采用的是第一个 Flex 项目的min-content作为实际宽度,相应的后面 Flex 项目的宽度会等前一个 Flex 项目计算完毕后在进行计算

比如第二个 Flex 项目宽度= 200+((800-228.75-200x4)/4)*1 = 142.81px

flex-shrink 为小数

同样的 flex-shrink 也会出现小数的情况,也分为 Flex 项目的 flex-shrink 之和小于等于 1 和大于 1 两种情况,如果大于 1 和上面的计算方式一样,所以我们只看小于 1 的情况,将我们的例子改为

.item {

  flex-basis: 200px;

  flex-shrink: 0.1;

}

效果为

此时我们会发现 Flex 项目溢出了容器,所以我们便可以得出一个结论:Flex 项目的 flex-shrink 之和小于 1,Flex 项目会溢出 Flex 容器

下面看一下它的计算公式

Flex项目弹性量=Flex容器不足空间*当前Flex项目的flex-shrink

Flex项目实际宽度=flex-basis + Flex项目弹性量

比如上面例子的每个 Flex 项目计算结果为

第一个 Flex 项目宽度 = 200+(800-200x5)x0.1=180px,但是由于它本身的min-content为 228.75,所以最终宽度为 228.75

第二个 Flex 项目宽度 =200-(800-228.75-200x4)x0.1=117.125

第三个 Flex 项目宽度...

Flex 的对齐方式

Flex 中关于对齐方式的属性有很多,其主要分为两种,一是主轴对齐方式:justify-,二是交叉轴对齐方式:align-

首先改一下我们的例子,将容器设置为宽高为 500x400 的容器(部分属性省略)

<div>

  <div>A</div>

  <div>B</div>

  <div>C</div>

</div>

.container {

  display: flex;

  width: 500px;

  height: 400px;

}

.item {

  width: 100px;

  height: 40px;

}

主轴对齐属性

这里以横向为主轴,纵向为交叉轴

justify-content

justify-content的值可以为:

• flex-start 默认值,主轴起点对齐

• flex-end 主轴终点对齐

• left 默认情况下和 flex-start 一致

• right 默认情况下和 flex-end 一致

• center 主轴居中对齐

• space-between 主轴两端对齐,并且 Flex 项目间距相等

• space-around 项目左右周围空间相等

• space-evenly 任何两个项目之间的间距以及边缘的空间相等

交叉轴对齐方式

align-content

align-content 属性控制整个 Flex 项目在 Flex 容器中交叉轴的对齐方式

注意设置 align-content 属性时候必须将 flex-wrap 设置成 wrap 或者 wrap-reverse。它可以取得值为

• stretch 默认值,当我们 Flex 元素不设置高度的时候,默认是拉伸的

比如将 Flex 元素宽度去掉

.item {

  width: 100px;

}

• flex-start 位于容器开头,这个和 flex-direction:属性有关,默认在顶部

• flex-end 位于容器结尾

• center 元素居中对齐

• space-between 交叉轴上下对齐,并且 Flex 项目上下间距相等

此时我们改下例子中 Flex 项目的宽度使其换行,因为如果 Flex 项目只有一行,那么 space-between 与 flex-start 表现一致

.item {

  width: 300px;

}

• space-around 项目上下周围空间相等

• space-evenly 任何两个项目之间的上下间距以及边缘的空间相等

align-items

align-items 属性定义 flex 子项在 flex 容器的当前行的交叉轴方向上的对齐方式。它与 align-content 有相似的地方,它的取值有

• stretch 默认值,当我们 Flex 元素不设置高度的时候,默认是拉伸的

• center 元素位于容器的中心,每个当前行在图中已经框起来

• flex-start 位于容器开头

• flex-end 位于容器结尾

• baseline 位于容器的基线上

比如给 A 项目一个 padding-top

.item:nth-of-type(1) {

  padding-top: 50px;

}

没设置 baseline 的表现

设置 baseline 之后

通过上面的例子我们可以发现,如果想要整个 Flex 项目垂直对齐,在只有一行的情况下,align-items 和 align-content 设置为 center 都可以做到,但是如果出现多行的情况下 align-items 就不再适用了

align-self

上面都是给 Flex 容器设置的属性,但是如果想要控制单个 Flex 项目的对齐方式该怎么办呢?

其实 Flex 布局中已经考虑到了这个问题,于是就有个 align-self 属性来控制单个 Flex 项目在 Flex 容器侧交叉轴的对齐方式。

align-self 和 align-items 属性值几乎是一致的,比如我们将整个 Flex 项目设置为 center,第二个 Flex 项目设置为 flex-start

.container {

  display: flex;

  width: 500px;

  height: 400px;

  align-items: center;

}

.item {

  width: 100px;

  height: 40px;

}

.item:nth-of-type(2) {

  align-self: flex-start;

}

注意,除了以上提到的属性的属性值,还可以设置为 CSS 的关键词如 inherit 、initial 等

交叉轴与主轴简写

place-content

place-content` 为 `justify-content` 和 `align-content` 的简写形式,可以取一个值和两个值,如果设置一个值那么 `justify-content` 和 `align-content` 都为这个值,如果是两个值,第一个值为 `align-content`,第二个则是 `justify-content

到这里关于Flex布局基本已经介绍完了,肯定会有些细枝末节没有考虑到,这可能就需要我们在平时工作和学习中去发现了

作者：东方小月
来源：https://juejin.cn/post/7197229913156796472

前言：本文实际是用js移动控制光标的位置！解决了网上没有可靠教程的现状

废话连篇

默认情况对一个文本框粘贴，应该会有这样的功能：

1. 粘贴文本后，光标不会回到所有文本的最后位置，而是在粘贴的文本之后

2. 将选中的文字替换成粘贴的文本

但是由于需求，我们需要拦截粘贴的事件，对剪贴板的文字进行过滤，这时候粘贴的功能都得自己实现了,而一旦自己实现，上面2个功能就不见了，我们就需要还原它。

面对这样的需求，我们肯定要控制移动光标，可是现在的网上环境真的是惨，千篇一律的没用代码...于是我就发表了这篇文章。

先上代码

    <textarea id="text" style="width: 996px; height: 423px;"></textarea>
    <script>
        // 监听输入框粘贴事件
        document.getElementById('text').addEventListener('paste', function (e) {
            e.preventDefault();
            let clipboardData = e.clipboardData.getData('text');
            // 这里写你对剪贴板的私货
            let tc = document.querySelector("#text");
            tc.focus();
            const start = (tc.value.substring(0,tc.selectionStart)+clipboardData).length;
            if(tc.selectionStart != tc.selectionEnd){
                tc.value = tc.value.substring(0,tc.selectionStart)+clipboardData+tc.value.substring(tc.selectionEnd)
            }else{
                tc.value = tc.value.substring(0,tc.selectionStart)+clipboardData+tc.value.substring(tc.selectionStart); 
            }
            
            // 重新设置光标位置
            tc.selectionEnd =tc.selectionStart = start
        });
    </script>

怎么理解上述两个功能？
第一个解释：
比如说现在文本框有：

染念真的很生气

如果我们现在在真的后面粘贴不要，变成

染念真的不要很生气|

拦截后的光标是在生气后面，但是我们经常使用发现，光标应该出现在不要的后面吧！
就像这样：

染念真的不要|很生气

第2个解释：

染念真的不要很生气

我们全选真的的同时粘贴求你，拦截后会变成

染念真的求你不要很生气|

但默认应该是：

染念求你|不要很生气

代码分析

针对第2个问题，我们应该先要获取默认的光标位置在何处，tc.selectionStart是获取光标开始位置，tc.selectionEnd是获取光标结束位置。
为什么这里我写了一个判断呢？因为默认时候，我们没有选中一块区域，就是把光标人为移动到某个位置(读到这里，光标在位置后面，现在人为移动到就是前面，这个例子可以理解不？)，这个时候两个值是相等的。

233|333
^--^
1--4
tc.selectionEnd=4，tc.selectionStart = 4

如果相等，说明就是简单的定位，tc.value = tc.value.substring(0,tc.selectionStart)+clipboardData+tc.value.substring(tc.selectionStart);,tc.value.substring(0,tc.selectionStart)获取光标前的内容，tc.value.substring(tc.selectionStart)是光标后的内容。
如果不相等，说明我们选中了一个区域(光标选中一块区域说明我们选中了一个区域)，代码只需要在最后获取光标后的内容这的索引改成tc.selectionEnd

|233333|
^------^
1------7
tc.selectionEnd=7，tc.selectionStart = 1

在获取光标位置之前，我们应该先使用tc.focus();聚焦，使得光标回到文本框的默认位置(最后)，这样才能获得位置。
针对第1个问题，我们就要把光标移动到粘贴的文本之后，我们需要计算位置。
获得这个位置，一定要在tc.value重新赋值之前，因为这样的索引都没有改动。
const start = (tc.value.substring(0,tc.selectionStart)+clipboardData).length;这个代码和上面解释重复，很简单，我就不解释了。
最后处理完了，重新设置光标位置，tc.selectionEnd =tc.selectionStart = start,一定让selectionEnd和selectionStart相同，不然选中一个区域了。

如果我们在value重新赋值之后获取(tc.value.substr(0,tc.selectionStart)+clipboardData).length，大家注意到没，我们操作的是tc.value，value已经变了，这里的重新定位光标开始已经没有任何意义了！

作者：染念
来源：dyedd.cn/943.html

闭包，是JS中的一大难点；网上有很多关于闭包会造成内存泄露的描述，说闭包会使其中的变量的值始终保持在内存中，一般都不太推荐使用闭包

而项目中确实有很多使用闭包的场景，比如函数的节流与防抖

那么闭包用多了，会造成内存泄露吗？

场景思考

以下案例： A 页面引入了一个 debounce 防抖函数，跳转到 B 页面后，该防抖函数中闭包所占的内存会被 gc 回收吗？

该案例中，通过变异版的防抖函数来演示闭包的内存回收，此函数中引用了一个内存很大的对象 info（42M的内存），便于明显地对比内存的前后变化

注：可以使用 Chrome 的 Memory 工具查看页面的内存大小：

场景步骤：

1） util.js 中定义了 debounce 防抖函数

// util.js`
let info = {
  arr: new Array(10 * 1024 * 1024).fill(1),
  timer: null
};
export const debounce = (fn, time) => {
  return function (...args) {
    info.timer && clearTimeout(info.timer);
    info.timer = setTimeout(() => {
      fn.apply(this, args);
    }, time);
  };
};

2） A 页面中引入并使用该防抖函数

import { debounce } from './util';
mounted() {
    this.debounceFn = debounce(() => {
      console.log('1');
    }, 1000)
}

• 抓取 A 页面内存： 57.1M

3） 从 A 页面跳转到 B 页面，B 页面中没有引入该 debounce 函数

问题： 从 A 跳转到 B 后，该函数所占的内存会被释放掉吗？

• 此时，抓取 B 页面内存： 58.1M

• 刷新 B 页面，该页面的原始内存为： 16.1M

结论： 前后对比发现，从 A 跳转到 B 后，B 页面内存增大了 42M，证明该防抖函数所占的内存没有被释放掉，即造成了内存泄露

为什么会这样呢？ 按理说跳转 B 页面后，A 页面的组件都被销毁掉了，那么 A 页面所占的内存应该都被释放掉了啊😕

我们继续对比测试

4） 如果把 info 对象放到 debounce 函数内部，从 A 跳转到 B 后，该防抖函数所占的内存会被释放掉吗？

// util.js`
export const debounce = (fn, time) => {
 let info = {
  arr: new Array(10 * 1024 * 1024).fill(1),
  timer: null
 };
  return function (...args) {
    info.timer && clearTimeout(info.timer);
    info.timer = setTimeout(() => {
      fn.apply(this, args);
    }, time);
  };
};

按照步骤 4 的操作，重新从 A 跳转到 B 后，B 页面抓取内存为16.1M，证明该函数所占的内存被释放掉了

为什么只是改变了 info 的位置，会引起内存的前后变化？

要搞懂这个问题，需要理解闭包的内存回收机制

闭包简介

闭包：一个函数内部有外部变量的引用，比如函数嵌套函数时，内层函数引用了外层函数作用域下的变量，就形成了闭包。最常见的场景为：函数作为一个函数的参数，或函数作为一个函数的返回值时

闭包示例：

function fn() {
  let num = 1;
  return function f1() {
    console.log(num);
  };
}
let a = fn();
a();

上面代码中，a 引用了 fn 函数返回的 f1 函数，f1 函数中引入了内部变量 num，导致变量 num 滞留在内存中

打断点调试一下

展开函数 f 的 Scope（作用域的意思）选项，会发现有 Local 局部作用域、Closure 闭包、Global 全局作用域等值，展开 Closure，会发现该闭包被访问的变量是 num，包含 num 的函数为 fn

总结来说，函数 f 的作用域中，访问到了fn 函数中的 num 这个局部变量，从而形成了闭包

所以，如果真正理解好闭包，需要先了解闭包的内存引用，并且要先搞明白这几个知识点：

• 函数作用域链

• 执行上下文

• 变量对象、活动对象

函数的内存表示

先从最简单的代码入手，看下变量是如何在内存中定义的

let a = '小马哥'

这样一段代码，在内存里表示如下

在全局环境 window 下，定义了一个变量 a，并给 a 赋值了一个字符串，箭头表示引用

再定义一个函数

let a = '小马哥'
function fn() {
  let num = 1
}

内存结构如下：

特别注意的是，fn 函数中有一个 [[scopes]] 属性，表示该函数的作用域链，该函数作用域指向全局作用域（浏览器环境就是 window），函数的作用域是理解闭包的关键点之一

请谨记：函数的作用域链是在创建时就确定了，JS 引擎会创建函数时，在该对象上添加一个名叫作用域链的属性，该属性包含着当前函数的作用域以及父作用域，一直到全局作用域

函数在执行时，JS 引擎会创建执行上下文，该执行上下文会包含函数的作用域链（上图中红色的线），其次包含函数内部定义的变量、参数等。在执行时，会首先查找当前作用域下的变量，如果找不到，就会沿着作用域链中查找，一直到全局作用域

垃圾回收机制浅析

现在各大浏览器通常用采用的垃圾回收有两种方法：标记清除、引用计数

这里重点介绍 "引用计数"（reference counting），JS 引擎有一张"引用表"，保存了内存里面所有的资源（通常是各种值）的引用次数。如果一个值的引用次数是0，就表示这个值不再用到了，因此可以将这块内存释放

上图中，左下角的两个值，没有任何引用，所以可以释放

如果一个值不再需要了，引用数却不为0，垃圾回收机制无法释放这块内存，从而导致内存泄漏

判断一个对象是否会被垃圾回收的标准： 从全局对象 window 开始，顺着引用表能找到的都不是内存垃圾，不会被回收掉。只有那些找不到的对象才是内存垃圾，才会在适当的时机被 gc 回收

分析内存泄露的原因

回到最开始的场景，当 info 在 debounce 函数外部时，为什么会造成内存泄露？

进行断点调试

展开 debounce 函数的 Scope选项，发现有两个 Closure 闭包对象，第一个 Closure 中包含了 info 对象，第二个 Closure 闭包对象，属于 util.js 这个模块

内存结构如下：

当从 A 页面切换到 B 页面时，A 页面被销毁，只是销毁了 debounce 函数当前的作用域，但是 util.js 这个模块的闭包却没有被销毁，从 window 对象上沿着引用表依然可以查找到 info 对象，最终造成了内存泄露

当 info 在 debounce 函数内部时，进行断点调试

其内存结构如下：

当从 A 页面切换到 B 页面时，A 页面被销毁，同时会销毁 debounce 函数当前的作用域，从 window 对象上沿着引用表查找不到 info 对象，info 对象会被 gc 回收

闭包内存的释放方式

1、手动释放（需要避免的情况）

如果将闭包引用的变量定义在模块中，这种会造成内存泄露，需要手动释放，如下所示，其他模块需要调用 clearInfo 方法，来释放 info 对象

可以说这种闭包的写法是错误的 （不推荐）， 因为开发者需要非常小心，否则稍有不慎就会造成内存泄露，我们总是希望可以通过 gc 自动回收，避免人为干涉

let info = {
  arr: new Array(10 * 1024 * 1024).fill(1),
  timer: null
};
export const debounce = (fn, time) => {
  return function (...args) {
    info.timer && clearTimeout(info.timer);
    info.timer = setTimeout(() => {
      fn.apply(this, args);
    }, time);
  };
};
export const clearInfo = () => {
  info = null;
};

2、自动释放（大多数的场景）

闭包引用的变量定义在函数中，这样随着外部引用的销毁，该闭包就会被 gc 自动回收 （推荐），无需人工干涉

export const debounce = (fn, time) => {
  let info = {
    arr: new Array(10 * 1024 * 1024).fill(1),
    timer: null
  };
  return function (...args) {
    info.timer && clearTimeout(info.timer);
    info.timer = setTimeout(() => {
      fn.apply(this, args);
    }, time);
  };
};

结论

综上所述，项目中大量使用闭包，并不会造成内存泄漏，除非是错误的写法

绝大多数情况，只要引用闭包的函数被正常销毁，闭包所占的内存都会被 gc 自动回收。特别是现在 SPA 项目的盛行，用户在切换页面时，老页面的组件会被框架自动清理，所以我们可以放心大胆的使用闭包，无需多虑

理解了闭包的内存回收机制，才算彻底搞懂了闭包。以上关于闭包的理解，如果有误，欢迎指正 🌹

参考链接：
浏览器是怎么看闭包的。
JavaScript 内存泄漏教程
JavaScript闭包（内存泄漏、溢出以及内存回收），超直白解析

作者：海阔_天空
来源：juejin.cn/post/7196636673694285882

简述

Slardar 前端监控自18年底开始建设以来，从仅仅作为 Sentry 的替代，经历了一系列迭代和发展，目前做为一个监控解决方案，已经应用到抖音、西瓜、今日头条等众多业务线。

据21年下旬统计，Slardar 前端监控（Web + Hybrd) 工作日晚间峰值 qps 300w+，日均处理数据超过千亿条。

本文，我将针对在这一系列的发展过程中，字节内部监控设计和迭代遇到的落地细节设计问题，管中窥豹，向大家介绍我们团队所思考和使用的解决方案。

他们主要围绕着前端监控体系建设的一些关键问题展开。也许大家对他们的原理早已身经百战见得多了，不过当实际要落地实现的时候，还是有许多细节可以再进一步琢磨的。

如何做好 JS 异常监控

JS 异常监控本质并不复杂，浏览器早已提供了全局捕获异常的方案。

window.addEventListenr('error', (err) => {
    report(normalize(err))
});

window.addEventListenr('unhandledrejection', (rejection) => {
    report(normalize(rejection))
});
复制代码

但捕获到错误仅仅只是相关工作的第一步。在我看来，JS 异常监控的目标是：

1. 开发者迅速感知到 JS 异常发生

2. 通过监控平台迅速定位问题

3. 开发者能够高效的处理问题，并统计，追踪问题的处理进度

在异常捕获之外，还包括堆栈的反解与聚合，处理人分配和报警这几个方面。

堆栈反解： Sourcemap

大家都知道 Script 脚本在浏览器中都是以明文传输并执行，现代前端开发方案为了节省体积，减少网络请求数，不暴露业务逻辑，或从另一种语言编译成 JS。都会选择将代码进行混淆和压缩。在优化性能，提升用户体验的同时，也为异常的处理带来了麻烦。

在本地开发时，我们通常可以清楚的看到报错的源代码堆栈，从而快速定位到原始报错位置。而线上的代码经过压缩，可读性已经变得非常糟糕，上报的堆栈很难对应到原始的代码中。 Sourcemap 正是用来解决这个问题的。

简单来说，Sourcemap 维护了混淆后的代码行列到原代码行列的映射关系，我们输入混淆后的行列号，就能够获得对应的原始代码的行列号，结合源代码文件便可定位到真实的报错位置。

Sourcemap 的解析和反解析过程涉及到 VLQ 编码，它是一种将代码映射关系进一步压缩为类base64编码的优化手段。

在实际应用中，我们可以把它直接当成黑盒，因为业界已经为我们提供了方便的解析工具。下面是一个利用 mozila 的 sourcemap 库进行反解的例子。

以上代码执行后通常会得到这样的结果，实际上我们的在线反解服务也就是这样实现的

当然，我们不可能在每次异常发生后，才去生成 sourcemap，在本地或上传到线上进行反解。这样的效率太低，定位问题也太慢。另一个方案是利用 sourcemappingURL 来制定sourcemap 存放的位置，但这样等于将页面逻辑直接暴露给了网站使用者。对于具有一定规模和保密性的项目，这肯定是不能接受的。

 //# sourceMappingURL=http://example.com/path/hello.js.map
复制代码

为了解决这个问题，一个自然的方案便是利用各种打包插件或二进制工具，在构建过程中将生成的 sourcemap 直接上传到后端。Sentry 就提供了类似的工具，而字节内部也是使用相似的方案。

通过如上方案，我们能够让用户在发版构建时就可以完成 sourcemap 的上传工作，而异常发生后，错误可以自动完成解析。不需要用户再操心反解相关的工作了。

堆栈聚合策略

当代码被成功反解后，用户已经可以看到这一条错误的线上和原始代码了，但接下来遇到的问题则是，如果我们只是上报一条存一条，并且给用户展示一条错误，那么在平台侧，我们的异常错误列表会被大量的重复上报占满，

对于错误类型进行统计，后续的异常分配操作都无法正常进行。

在这种情况下，我们需要对堆栈进行分组和聚合。也就是，将具有相同特征的错误上报，归类为统一种异常，并且只对用户暴露这种聚合后的异常。

堆栈怎么聚合效果才好呢？我们首先可以观察我们的JS异常所携带的信息，一个异常通常包括以下部分

• name： 异常的 Type，例如 TypeError, SyntaxError, DOMError

• Message：异常的相关信息，通常是异常原因，例如 a.b is not defined.

• Stack （非标准）异常的上下文堆栈信息，通常为字符串

那么聚合的方案自然就出来了，利用某种方式，将 error 相关的信息利用提取为 fingerprint，每一次上报如果能够获得相同的 fingerprint，它们就可以归为一类。那么问题进一步细化为：如何利用 Error 来保证 fingerprint 的区分尽量准确呢？

如果跟随标准，我们只能利用 name + message 作为聚合依据。但在实践过程中，我们发现这是远远不够的。如上所示，可以看到这两个文件发生的位置是完全不同的，来自于不同的代码段，但由于我们只按照 name + message 聚合。它们被错误聚合到了一起，这样可能造成我们修复了其中一个错误后。误以为相关的所有异常都被解决。

因此，很明显我们需要利用非标准的 error.stack 的信息来帮我们解决问题了。在这里我们参考了 Sentry 的堆栈聚合策略：

除了常规的 name, message, 我们将反解后的 stacktrace 进一步拆分为一系列的 Frame，每一个 Frame 内我们重点关注其调用函数名，调用文件名以及当前执行的代码行(图中的context_line)。

Sentry 将每一个拆分出的部分都称为一个 GroupingComponent，当堆栈反解完毕后，我们首先自上而下的递归检测，并自下而上的生成一个个嵌套的 GroupingComponent。最后，在顶层调用 GroupingComponent.getHash() 方法, 得到一个最终的哈希值，这就是我们最终求得的 fingerprint。

相较于message+name, 利用 stacktrace 能够更细致的提取堆栈特征，规避了不同文件下触发相同 message 的问题。因此获得的聚合效果也更优秀。这个策略目前在字节内部的工作效果良好，基本上能够做到精确的区分各类异常而不会造成混淆和错误聚合。

处理人自动分配策略

异常已经成功定位后，如果我们可以直接将异常分配给这行代码的书写者或提交者，可以进一步提升问题解决的效率，这就是处理人自动分配所关心的，通常来说，分配处理人依赖 git blame 来实现。

一般的团队或公司都会使用 Gitlab / Github 作为代码的远端仓库。而这些平台都提供了丰富的 open-api 协助用户进行blame，

我们很自然的会联想到，当通过 sourcemap 解出原始堆栈路径后，如果可以结合调用 open-api，获得这段代码所在文件的blame历史, 我们就有机会直接在线上确定某一行的可能的 author / commitor 究竟是谁。从而将这个异常直接分配给他。

思路出来了，那么实际怎么落地呢？

我们需要几个信息

1. 线上报错的项目对应的源代码仓库名，如 toutiao-fe/slardar

2. 线上报错的代码发生的版本，以及与此版本关联的 git commit 信息，为什么需要这些信息呢？

默认用来 blame 的文件都是最新版本，但线上跑的不一定是最新版本的代码。不同版本的代码可能发生行的变动，从而影响实际代码的行号。如果我们无法将线上版本和用来 blame 的文件划分在统一范围内，则很有可能自动定位失败。

因此，我们必须找到一种方法，确定当前 blame 的文件和线上报错的文件处于同一版本。并且可以直接通过版本定位到关联的源代码 commit 起止位置。这样的操作在 Sentry 的官方工具 Sentry-Cli 中亦有提供。字节内部同样使用了这种方案。

通过 相关的 二进制工具，在代码发布前的脚本中提供当前将要发布的项目的版本和关联的代码仓库信息。同时在数据采集侧也携带相同的版本，线上异常发生后，我们就可以通过线上报错的版本找到原始文件对应的版本，从而精确定位到需要哪个时期的文件了。

异常报警

当异常已经成功反解和聚合后，当用户访问监控平台，已经可以观察并处理相关的错误，不过到目前为止，异常的发生还无法触及开发者，问题的解决依然依靠“走查”行为。这样的方案对严重的线上问题依然是不够用，因此我们还需要主动通知用户的手段，这就是异常报警。

在字节内部，报警可以分为宏观报警，即针对错误指标的数量/比率的报警，以及微观报警，即针对新增异常的报警。

宏观报警

宏观报警是数量/比率报警, 它只是统计某一类指标是否超出了限定的阈值，而不关心它具体是什么。因此默认情况下它并不会告诉你报警的原因。只有通过归因维度或者下文会提到的 微观(新增异常)报警 才能够知晓引发报警的具体原因

关于宏观报警，我们有几个关键概念

• 第一是样本量，用户数阈值: 在配置比率指标时。如果上报量过低，可能会造成比率的严重波动，例如错误率 > 20%, 的报警下，如果 JS 错误数从 0 涨到 1， 那就是比率上涨到无限大从而造成没有意义的误报。如果不希望被少量波动干扰，我们设置了针对错误上报量和用户数的最低阈值，例如只有当错误影响用户数 > 5 时，才针对错误率变化报警。

• 第二是归因维度： 对于数量，比率报警，仅仅获得一个异常指标值是没什么意义的，因为我们无法快速的定位问题是由什么因素引发的，因此我们提供了归因维度配置。例如，通过对 JS 异常报警配置错误信息归因，我们可以在报警时获得引发当前报警的 top3 关键错误和增长最快的 top3 错误信息。

• 第三是时间窗口，报警运行频率： 如上文所说，报警是数量，比率报警，而数量，比率一定有一个统计范围，这个就是通过 时间窗口 来确定的。而报警并不是时时刻刻盯着我们的业务数据的，可以理解为利用一个定时器来定期检查 时间窗口 内的数据是否超出了我们定义的阈值。而这个定时器的间隔时间，就是 报警运行频率。通过这种方式，我们可以做到类实时的监测异常数据的变化，但又没有带来过大的资源开销。

微观报警(新增异常)

相较于在意宏观数量变化的报警，新增异常在意每一个具体问题，只要此问题是此前没有出现过的，就会主动通知用户。

同时，宏观报警是针对数据的定时查找，存在运行频率和时间窗口的限制，实时性有限。微观报警是主动推送的，具有更高的实时性。

微观报警适用于发版，灰度等对新问题极其关注，并且不方便在此时专门配置相关数量报警的阶段。

如何判断“新增”？

我们在 异常自动分配章节讲到了，我们的业务代码都是可以关联一个版本概念的。实际上版本不仅和源代码有关，也可以关联到某一类错误上。

在这里我们同样也可以基于版本视角判断“新增错误”。

对于新增异常的判断，针对两种不同场景做了区分

• 对于指定版本、最新版本的新增异常报警，我们会分析该报警的 fingerprint 是否为该版本代码中首次出现。

• 而对于全体版本，我们则将"首次”的范围增加了时间限制，因为对于某个错误，如果在长期没有出现后又突然出现，他本身还是具有通知的意义的，如果不进行时间限制，这个错误就不会通知到用户，可能会出现信息遗漏的情况。

如何做好性能监控？

如果说异常处理是前端监控体系60分的分界线，那么性能度量则是监控体系能否达到90分的关键。一个响应迟钝，点哪儿卡哪儿的页面，不会比点开到处都是报错的页面更加吸引人。页面的卡顿可能会直接带来用户访问量的下降，进而影响背后承载的服务收入。因此，监控页面性能并提升页面性能也是非常重要的。针对性能监控，我们主要关注指标选取，品质度量 、瓶颈定位三个关键问题。

指标选取

指标选取依然不是我们今天文章分享的重点。网上关于 RUM 指标，Navigation 指标的介绍和采集方式已经足够清晰。通常分为两个思路：

1. RUM (真实用户指标) -> 可以通过 Web Vitals （github.com/GoogleChrom…*

2. 页面加载指标 -> NavigationTiming (ResourceTiming + DOM Processing + Load) 可以通过 MDN 相关介绍学习。这里都不多赘述。

瓶颈定位

收集到指标只是问题的第一步，接下来的关键问题便是，我们应该如何找出影响性能问题的根因，并且针对性的进行修复呢？

慢会话 + 性能时序分析

如果你对“数据洞察/可观测性”这个概念有所了解，那么你应该对 Kibana 或 Datadog 这类产品有所耳闻。在 kibana 或 Datadog 中都能够针对每一条上传的日志进行详细的追溯。和详细的上下文进行关联，让用户的体验可被观测，通过多种筛选找到需要用户的数据。

在字节前端的内部建设中，我们参考了这类数据洞察平台的消费思路。设计了数据探索能力。通过数据探索，我们可以针对用户上报的任意维度，对一类日志进行过滤，而不只是获得被聚合过的列表信息数据。这样的消费方式有什么好处呢？

1. 我们可以直接定位到一条具体日志，找到一个现实的 data point 来分析问题

2. 这种视图的状态是易于保存的，我们可以将找到的数据日志通过链接发送给其他人，其他用户可以直接还原现场。

对于性能瓶颈，在数据探索中，可以轻松通过针对某一类 PV 上报所关联的性能指标进行数值筛选。也可以按照某个固定时段进行筛选，从而直接获得响应的慢会话。这样的优势在于我们不用预先设定一个“慢会话阈值”，需要哪个范围的数据完全由我们自己说了算。例如，通过对 FCP > 3000ms 进行筛选，我们就能够获得一系列 FCP > 3s 的 PV 日志现场。

在每次 PV 上报后，我们会为数据采集的 SDK 设置一个全局状态，比如 view_id, 只要没有发生新的页面切换，当前的 view_id 就会保持不变。

而后续的一系列请求，异常，静态资源上报就可以通过 view_id 进行后端的时序串联。形成一张资源加载瀑布图。在瀑布图中我们可以观察到各类性能指标和静态资源加载，网络请求的关系。从而检测出是否是因为某些不必要的或者过大的资源，请求导致的页面性能瓶颈。这样的瀑布图都是一个个真实的用户上报形成的，相较于统计值产生的甘特图，更能帮助我们解决实际问题。

结合Longtask + 用户行为分析

通过指标过滤慢会话，并且结合性能时序瀑布图分析，我们能够判断出当前页面中是否存在由于网络或过大资源因素导致的页面加载迟缓问题

但页面的卡顿不一定全是由网络因素造成的。一个最简单的例子。当我在页面的 head 中插入一段非常耗时的同步脚本（例如 while N 次），则引发页面卡顿的原因就来自于代码执行而非资源加载。

针对这种情况，浏览器同样提供了 Longtask API 供我们收集这类占据主线程时间过长的任务。
同样的，我们将这类信息一并收集，并通过上文提到的 view_id 串联到一次页面访问中。用户就可以观察到某个性能指标是否受到了繁重的主线程加载的影响。若有，则可利用类似 lighthouse 的合成监控方案集中检查对应页面中是否存在相关逻辑了。

受限于浏览器所收集到的信息，目前的 longtask 我们仅仅只能获得它的执行时间相关信息。而无法像开发者面板中的 performance 工具一样准确获取这段逻辑是由那段代码引发的。如果我们能够在一定程度上收集到longtask触发的上下文，则可定位到具体的慢操作来源。

此外，页面的卡顿不一定仅仅发生在页面加载阶段，有时页面的卡顿会来自于页面的一次交互，如点击，滚动等等。这类行为造成的卡顿，仅仅依靠 RUM / navigation 指标是无法定位的。如果我们能够通过某种方式（在PPT中已经说明），对操作行为计时。并将操作计时范围内触发的请求，静态资源和longtask上报以同样的瀑布图方式收敛到一起。则可以进一步定位页面的“慢操作”，从而提升页面交互体验。

如下图所示，我们可以检查到，点击 slardar_web 这个按钮 / 标签带来了一系列的请求和 longtask，如果这次交互带来了一定的交互卡顿。我们便可以集中修复触发这个点击事件所涉及的逻辑来提升页面性能表现。

品质度量

当我们采集到一个性能指标后，针对这样一个数字，我们能做什么？

我们需要结论：好还是不好？

实际上我们通常是以单页面为维度来判定指标的，以整站视角来评判性能的优劣的置信度会受到诸多因素影响，比如一个站点中包含轻量的登陆页和功能丰富的中后台，两者的性能要求和用户的容忍度是不一致的，在实际状况下两者的绝对性能表现也是不一致的。而简单平均只会让我们观察不到重点，页面存在的问题数据也可能被其他的页面拉平。

其次，指标只是冷冰冰的数据，而数据想要发挥作用，一定需要参照系。比如，我仅仅提供 FMP = 4000ms，并不能说明这个页面的性能就一定需要重点关注，对于逻辑较重的PC页面，如数据平台，在线游戏等场景，它可能是符合业务要求的。而一个 FMP = 2000ms的页面则性能也不一定好，对于已经做了 SSR 等优化的回流页。这可能远远达不到我们的预期。

一个放之四海而皆准的指标定义是不现实的。不同的业务场景有不同的性能基准要求。我们可以把他们转化为具体的指标基准线。

通过对于现阶段线上指标的分布，我们可以可以自由定义当前站点场景下针对某个指标，怎样的数据是好的，怎样的数据是差的。

基准线应用后，我们便可以在具体的性能数据产出后，直观的观察到，在什么阶段，某些指标的表现是不佳的，并且可以集中针对这段时间的性能数据日志进行排查。

一个页面总是有多个性能指标的，现在我们已经知道了单个性能指标的优劣情况，如何整体的判断整个页面，乃至整个站点的性能状况，落实到消费侧则是，我们如何给一个页面的性能指标评分？

如果有关注过 lighthouse 的同学应该对这张图不陌生。

lighthouse 通过 google 采集到的大量线上页面的性能数据，针对每一个性能指标，通过对数正态分布将其指标值转化成 百分制分数。再通过给予每个指标一定的权重（随着 lighthouse 版本更迭), 计算出该页面性能模块的一个“整体分数”。在即将上线的“品质度量”能力中，我们针对 RUM 指标，异常指标，以及资源加载指标均采取了类似的方案。

我们通常可以给页面的整体性能分数再制定一个基准分数，当上文所述的性能得分超过分数线，才认为该页面的性能水平是“达标”的。而整站整体的达标水平，则可以利用整站达标的子页面数/全站页面数来计算，也就是达标率，通过达标率，我们可以非常直观的迅速找到需要优化的性能页面，让不熟悉相关技术的运营，产品同学也可以定期巡检相关页面的品质状况。

如何做好请求 / 静态资源监控？

除了 JS 异常和页面的性能表现以外，页面能否正常的响应用户的操作，信息能否正确的展示，也和 api 请求，静态资源息息相关。表现为 SLA，接口响应速度等指标。现在主流的监控方案通常是采用手动 hook相关 api 和利用 resource timing 来采集相关信息的。

手动打点通常用于请求耗时兜底以及记录请求状态和请求响应相关信息。

1. 对于 XHR 请求： 通过 hook XHR 的 open 和 send 方法, 获取请求的参数，在 onreadystatechange 事件触发时打点记录请求耗时。

   1.  // 记录 method
       hookObjectProperty(XMLHttpRequest.prototype, 'open', hookXHROpen); 
       // hook onreadystateChange，调用前后打点计算
       hookObjectProperty(XMLHttpRequest.prototype, 'send', hookXHRSend);
      复制代码

2. 对于fetch请求，则通过 hook Fetch 实现

   1. hookObjectProperty(global, 'fetch', hookFetch)
      复制代码

• 第二种则是 resourceTiming 采集方案

• 1. 静态资源上报:

     1. pageLoad 前：通过 performance.getEntriesByType 获取 resource 信息

     2. pageLoad后：通过 PerformanceObserver 监控 entryType 为 resource 的资源

• const callback = (val, i, arr, ob) => // ... 略
  const observer = new PerformanceObserver((list, ob) => {
      if (list.getEntries) {
        list.getEntries().forEach((val, i, arr) => callback(val, i, arr, ob))
      } else {
        onFail && onFail()
      }
      // ...
   });
   
  observer.observe({ type: 'resource', buffered: false })
  复制代码

手动打点的优势在于无关兼容性，采集方便，而 Resource timing 则更精准，并且其记录中可以避开额外的事件队列处理耗时

如何理解和使用 resource timing 数据？

我们现在知道 ResourceTiming 是更能够反映实际资源加载状况的相关指标，而在工作中，我们经常遇到前端请求上报时间极长而后端对应接口日志却表现正常的情况。这通常就可能是由使用单纯的打点方案计算了太多非服务端因素导致的。影响一个请求在前端表现的因素除了服务端耗时以外，还包括网络，前端代码执行排队等因素。我们如何从 ResourceTiming 中分离出这些因素，从而更好的对齐后端口径呢？

第一种是 Chrome 方案（阿里的 ARMS 也采用的是这种方案)：

它通过将线上采集的 ResoruceTiming 和 chrome timing 面板的指标进行类比还原出一个近似的各部分耗时值。他的简单计算方式如图所示。

不过 chrome 实际计算 timing 的方式不明，这种近似的方式不一定能够和 chrome 的面板数据对的上，可能会被用户质疑数据不一致。

第二种则是标准方案: 规范划分阶段，这种划分是符合 W3C 规范的格式，其优势便在于其通用性好，且数据一定是符合要求的而不是 chrome 方案那种“近似计算”。不过它的缺陷是阶段划分还是有点太粗了，比如用户无法判断出浏览器排队耗时，也无法完全区分网络下载和下载完成后的资源加载阶段。只是简单的划分成了 Request / Response 阶段，给用户理解和分析带来了一定成本

在字节内部，我们是以标准方案为主，chrome方案为辅的，用户可以针对自己喜好的那种统计方式来对齐指标。通常来说，和服务端对齐耗时阶段可以利用标准方案的request阶段减去severtiming中的cdn，网关部分耗时来确定。

接下来我们再谈谈采集 SDK 的设计。

SDK 如何降低侵入，减少用户性能损耗？体积控制和灵活使用可以兼得吗？

常需要尽早执行，其资源加载通常也会造成一定的性能影响。更大的资源加载可能会导致更慢的 Load，LCP，TTI 时间，影响用户体验。

为了进一步优化页面加载性能，我们采用了 JS Snippets 来实现异步加载 + 预收集。

1. 异步加载主要逻辑

首先，如果通过 JS 代码创建 script 脚本并追加到页面中，新增的 script 脚本默认会携带 async 属性，这意味着这这部分代码将通过async方式延迟加载。下载阶段不会阻塞用户的页面加载逻辑。从而一定程度的提升用户的首屏性能表现。

1. 预收集

试想一下我们通过 npm 或者 cdn 的方式直接引入监控代码，script必须置于业务逻辑最前端，这是因为若异常先于监控代码加载发生，当监控代码就位时，是没有办法捕获到历史上曾经发生过的异常的。但将script置于前端将不可避免的对用户页面造成一定阻塞，且用户的页面可能会因此受到我们监控 sdk 服务可用性的影响。

为了解决这个问题，我们可以同步的加载一段精简的代码，在其中启动 addEventListener 来采集先于监控主要逻辑发生的错误。并存储到一个全局队列中，这样，当监控代码就位，我们只需要读取全局队列中的缓存数据并上报，就不会出现漏报的情况了。

更进一步：事件驱动与插件化

方案1. 2在大部分情况下都已经比较够用了，但对于字节的某些特殊场景却还不够。由于字节存在大量的移动端页面，且这些页面对性能极为敏感。因而对于第三方库的首包体积要求非常苛刻，同时，也不希望第三方代码的执行占据主线程太长时间。

此外，公司内也有部分业务场景特殊，如 node 场景，小程序场景，electron，如果针对每一种场景，都完全重新开发一套新的监控 SDK，有很大的人力重复开发的损耗。

如果我们能够将 SDK 的框架逻辑做成平台无关的，而各个数据监控，收集方案都只是以插件形式存在，那么这个 SDK 完全是可插拔的，类似 Sentry 所使用的 integration 方案。用户甚至可以完全不使用任何官方插件，而是通过自己实现相关采集方案，来做到项目的定制化。

关于框架设计可以参见下图

1. 我们把整个监控 SDK 看作一条流水线（Client），接受的是用户配置（config)（通过 ConfigManager)，收集和产出的是具体事件（Event, 通过 Plugins)。流水线是平台无关的，它不关心处理的事件是什么，也不关心事件是从哪来的。它其实是将这一系列的组件交互都抽象为 client 上的事件，从而使得数据采集器能够介入数据流转的每个阶段
   Client 通过 builder 包装事件后，转运给 Sender 负责批处理，Sender 最终调用 Transporter 上报。Transporter 是平台强相关的，例如 Web 使用 xhr 或 fetch，node 则使用 request 等。 同时，我们利用生命周期的概念设置了一系列的钩子，可以让用户可以在适当阶段处理流水线上的事件。例如利用 beforeSend 钩子去修改即将被发送的上报内容等。

当整体的框架结构设计完后，我们就可以把视角放到插件上了。由于我们将框架设置为平台无关的，它本身只是个数据流，有点像是一个精简版的 Rx.js。而应用在各个平台上，我们只需要根据各个平台的特性设计其对应的采集或数据处理插件。

插件方案某种意义上实现了 IOC，用户不需要关心事件怎么处理，传入的参数是哪里来的，只需要利用传入的参数去获取配置，启动自己的插件等。如下这段JS采集器代码，开发插件时，我们只需要关心插件自身相关的逻辑，并且利用传入 client 约定的相关属性和方法工作就可以了。不需要关心 client 是怎么来的，也不用关心 client 什么时候去执行它。

当我们写完了插件之后，它要怎么才能被应用在数据采集和处理中呢？为了达成降低首包大小的目标，我们将插件分为同步和异步两种加载方式。

1. 可以预收集的监控代码都不需要出现在首包中，以异步插件方式接入

2. 无法做到预收集的监控代码以同步形式和首包打在一起，在源码中将client传入，尽早启动，保证功能稳定。

3. 异步插件采用约定式加载，用户在使用层面是完全无感的。我们通过主包加载时向在全局初始化注册表和注册方法，在读取用户配置后，拉取远端插件加载并利用全局注册方法获取插件实例，最后传入我们的 client 实现代码执行。

经过插件化和一系列 SDK 的体积改造后，我们的sdk 首包体积降低到了从63kb 降低到了 34 kb。

总结

本文主要从 JS 异常监控，性能监控和请求，静态资源监控几个细节点讲述了 Slardar 在前端监控方向所面临关键问题的探索和实践，希望能够对大家在前端监控领域或者将来的工作中产生帮助。其实前端监控还有许多方面可以深挖，例如如何利用拨测，线下实验室数据采集来进一步追溯问题，如何捕获白屏等类崩溃异常，如何结合研发流程来实现用户无感知的接入等等。

作者：字节架构前端
来源：https://juejin.cn/post/7195496297150709821

本文翻译自 A Fancy Hover Effect For Your Avatar，略有删改，有兴趣可以看看原文。

你知道当一个人的头像从一个圆圈或洞里伸出来时的那种效果吗？本文将使用一种很简洁的方式实现该悬停效果，可以用在你的头像交互上面。

看到了吗？我们将制作一个缩放动画，其中头像部分似乎从它所在的圆圈中钻出来了。是不是很酷呢？接下来让我们一起一步一步地构建这个动画交互效果。

HTML：只需要一个元素

是的，只需要一个img图片标签即可，本次练习的挑战性部分是使用尽可能少的代码。如果你已经关注我一段时间了，你应该习惯了。我努力寻找能够用最小、最易维护的代码实现的CSS解决方案。

<img src="" alt="">

首先我们需要一个带有透明背景的正方形图像文件，以下是本次案例使用的图像。

在开始CSS之前，让我们先分析一下效果。悬停时图像会变大，所以我们肯定会在这里使用transform：scale。头像后面有一个圆圈，径向渐变应该可以达到这个效果。最后我们需要一种在圆圈底部创建边框的方法，该边框将不受整体放大的影响且是在视觉顶层。

放大效果

放大的效果，增加transform：scale，这个比较简单。

img:hover {
  transform: scale(1.35);
}

上面说过背景是一个径向渐变。我们创建一个径向渐变，但是两个颜色之间不要有过渡效果，这样使得它看起来像我们画了一个有实线边框的圆。

img {
  --b: 5px; /* border width */

  background:
    radial-gradient(
      circle closest-side,
      #ECD078 calc(99% - var(--b)),
      #C02942 calc(100% - var(--b)) 99%,
      #0000
    );
}

注意CSS变量，--b，在这里它表示“边框”的宽度，实际上只是用于定义径向渐变红色部分的位置。

下一步是在悬停时调整渐变大小，随着图像的放大，圆需要保持大小不变。由于我们正在应用scale变换，因此实际上需要减小圆圈的大小，否则它会随着化身的大小而增大。

让我们首先定义一个CSS变量--f，它定义了“比例因子”，并使用它来设置圆的大小。我使用1作为默认值，因为这是图像和圆的初始比例，我们从圆转换。

现在我们必须将背景定位在圆的中心，并确保它占据整个高度。我喜欢把所有东西都直接简写在 background 属性，代码如下：

background: radial-gradient() 50% / calc(100% / var(--f)) 100% no-repeat;

背景放置在中心（ 50%），宽度等于calc（100%/var（--f）），高度等于100%。

当 --f 等于 1 时是我们最初的比例。同时，渐变占据容器的整个宽度。当我们增加 --f，元素的大小会增长但是渐变的大小将减小。

越来越接近了！我们在顶部添加了溢出效果，但我们仍然需要隐藏图像的底部，这样它看起来就像是跳出了圆圈，而不是整体浮在圆圈前面。这是整个过程中比较复杂的部分，也是我们接下来要做的。

下边框

第一次尝试使用border-bottom属性，但无法找到一种方法来匹配边框的大小与圆的大小。如图所示，相信你能看出来无法实现我们想要的效果：

实际的解决方案是使用outline属性。不是border。outline可以让我们创造出很酷的悬停效果。结合 outline-offset 偏移量，我们就可以实现所需要的效果。

其核心是在图像上设置一个outline轮廓并调整其偏移量以创建下边框。偏移量将取决于比例因子，与渐变大小相同。outline-offset 偏移量看起来相对比较复杂，这里对计算方式进行了精简，有兴趣的可以看看原文。

img {
  --s: 280px; /* image size */
  --b: 5px; /* border thickness */
  --c: #C02942; /* border color */
  --f: 1; /* initial scale */
  
  border-radius: 0 0 999px 999px;
  outline: var(--b) solid var(--c);
  outline-offset: calc((1 / var(--f) - 1) * var(--s) / 2 - var(--b));

}

因为我们需要一个圆形的底部边框，所以在底部添加了一个边框圆角，使轮廓与渐变的弯曲程度相匹配。

现在我们需要找到如何从轮廓中删除顶部，也就是上图中挡住头像的那根线。换句话说，我们只需要图像的底部轮廓。首先，在顶部添加空白和填充，以帮助避免顶部头像的重叠，这通过增加padding即可实现：

padding-top: calc(var(--s)/5)

这里还有一个注意点，需要添加 content-box 值添加到 background：

background:
  radial-gradient(
    circle closest-side,
    #ECD078 calc(99% - var(--b)),
    var(--c) calc(100% - var(--b)) 99%,
    #0000
  ) 50%/calc(100%/var(--f)) 100% no-repeat content-box;

这样做是因为我们添加了padding填充，并且我们只希望将背景设置为内容框，因此我们必须显式地定义出来。

CSS mask

到了最后一部分！我们要做的就是藏起一些碎片。为此，我们将依赖于 CSS mask 属性，当然还有渐变。

下面的图说明了我们需要隐藏的内容或需要显示的内容，以便更加准确。左图是我们目前拥有的，右图是我们想要的。绿色部分说明了我们必须应用于原始图像以获得最终结果的遮罩内容。

我们可以识别mask的两个部分：

• 底部的圆形部分，与我们用来创建化身后面的圆的径向渐变具有相同的维度和曲率

• 顶部的矩形，覆盖轮廓内部的区域。请注意轮廓是如何位于顶部的绿色区域之外的-这是最重要的部分，因为它允许剪切轮廓，以便只有底部部分可见

最终的完整css如下，对有重复的代码进行抽离，如--g，--o：

img {
  --s: 280px; /* image size */
  --b: 5px; /* border thickness */
  --c: #C02942; /* border color */
  --f: 1; /* initial scale */

  --_g: 50% / calc(100% / var(--f)) 100% no-repeat content-box;
  --_o: calc((1 / var(--f) - 1) * var(--s) / 2 - var(--b));

  width: var(--s);
  aspect-ratio: 1;
  padding-top: calc(var(--s)/5);
  cursor: pointer;
  border-radius: 0 0 999px 999px;
  outline: var(--b) solid var(--c);
  outline-offset: var(--_o);
  background: 
    radial-gradient(
      circle closest-side,
      #ECD078 calc(99% - var(--b)),
      var(--c) calc(100% - var(--b)) 99%,
      #0000) var(--_g);
  mask:
    linear-gradient(#000 0 0) no-repeat
    50% calc(-1 * var(--_o)) / calc(100% / var(--f) - 2 * var(--b)) 50%,
    radial-gradient(
      circle closest-side,
      #000 99%,
      #0000) var(--_g);
  transform: scale(var(--f));
  transition: .5s;
}
img:hover {
  --f: 1.35; /* hover scale */
}

下面的一个演示，直观的说明mask的使用区域。中间的框说明了由两个渐变组成的遮罩层。把它想象成左边图像的可见部分，你就会得到右边的最终结果：

最后

搞定！我们不仅完成了一个流畅的悬停动画，而且只用了一个<img>元素和不到20行的CSS技巧！如果我们允许自己使用更多的HTML，我们能简化CSS吗？当然可以。但我们是来学习CSS新技巧的!这是一个很好的练习，可以探索CSS渐变、遮罩、outline属性的行为、转换以及其他许多内容。

在线效果

实例里面是流行的CSS开发人员的照片。有兴趣的同学可以展示一下自己的头像效果。

看完本文如果觉得有用，记得点个赞支持，收藏起来说不定哪天就用上啦～

作者：南城FE
来源：juejin.cn/post/7196747356796518460

在我的技术群里大家经常会聊一些宏观的技术问题，就比如：

Vue和React，最终谁会被淘汰？

这样的讨论，到最后往往会陷入技术的细枝末节的比较，比如：

• 对比两者响应式的实现原理

• 对比两者的运行时性能

很多程序员朋友，会觉得：

技术问题，就应该从技术的角度找到答案

但实际上，一些大家纠结的技术问题，往往跟技术本身无关。

谁才是框架的最终赢家？

讨论React和Vue谁会淘汰谁？这个问题，就像10年前，一个康师傅信徒和一个统一信徒争论：

哪家泡面企业最终会被淘汰呢？

他们把争论的重点放在口味的对比、面饼分量的对比等等，最终谁也无法说服谁。

实际我们最后知道了，外卖App的崛起，对泡面企业形成了降维打击。

回到框架这个问题上，在前端框架流行之前，前端最流行的开发库是jQuery，他是命令式编程的编程范式。

取代jQuery的并不是另一个更优秀的jQuery，而是声明式编程的前端框架。

同样的，取代前端框架的，不会是另一个更优秀的前端框架，而是另一种更适合web开发的编程范式。

那在前端框架这个领域内部，React和Vue最终谁会淘汰谁呢？

我的答案是：

谁也不会淘汰谁。

任何框架最核心的竞争力，不是性能，也不是生态是否繁荣，而是开发者用的是否顺手，也就是开发模式是否合理。

React发明了JSX这种开发模式，并持续教育了开发者3年，才让社区接受这种开发模式

这种发明开发模式，再教育开发者的行为，也只有meta这种大公司才办得到。

而Vue则直接使用了模版语法这种现成的开发模式。这种模式已经被广大后端工程师验证过是最好上手的web开发模式。

所以像后端工程师或者编程新人会很容易上手Vue。

经过多年迭代，他们各自的开发模式已经变成了事实上的前端框架DSL标准。

这会为他们带来两个好处：

1. 开发模式是个主观偏好，不存在优劣

所以他们谁也无法淘汰谁，只能说React的开发模式受众范围更广而已。

1. 后来者会永远居于他们的阴影之下

新的框架如果无法在编程范式上突破，那么为了抢占Vue或React的市场份额，只能遵循他们的开发模式，因为这样开发者才能无痛迁移。

比如最近两年比较优秀的新框架，svelte是Vue的开发模式，Solid.js 是React的开发模式

在同样的开发模式下，占市场主导地位的框架可以迅速跟进那些竞争者的优秀特性。

比如Vue就准备开发一个类似Svelte的版本。

一句话总结就是：

你是无法在我的BGM中击败我的

总结

总体来说，在新的web编程范式流行之前，React、Vue还会长期霸占开发者喜欢的前端框架前列。

在此过程中，会出现各种新框架，他们各有各的特点，但是，都很难撼动前者的地位。

作者：魔术师卡颂
来源：juejin.cn/post/7190550643386351653

背景

笔者目前在做一个智慧楼宇的产品（使用react开发的），在交付项目的时候，遇到了需要在浏览器端播放rtsp视频流的场景，而浏览器端是不能直接播放rtsp视频流的，原本打算让客户方提供flv格式的视频流 鉴于项目现场的环境以及种种原因，客户方只能提供rtsp视频流，所以就只能自己解决了。

于是乎，去网上随便一搜就搜到了Ffmpeg + node.js + websocket + flv.js的解决方案，但是真正自己实现下来，遇到了几个棘手的问题，例如：莫名其妙的报错，部分监控视频转换失败，不能转码h265格式的视频等等（本文会介绍自己遇到的问题以及解决方案）。

涉及到的技术点

• ffmpeg：ffmpeg是一个转码工具，将rtsp视频里转换成flv格式的视频流

• node.js

• websocket

• flv.js

node.js端

点击进入node端的github

用到的关键库

• @ffmpeg-installer/ffmpeg

自动为当前node服务所在的平台安装适合的ffmpeg，无需自己再去手动下载、安装配置了。通过该库安装的ffmpeg，其路径在node_modules/@ffmpeg-installer/darwin-x64/ffmpeg (我用的是mac，自动安装的是darwin-x64，不同平台不一样)

• fluent-ffmpeg

该库是对ffmpeg 命令的封装，简化了命令的使用流程，原生ffmpeg的命令是比较复杂难懂的。

点击进入fluent-ffmpeg的github地址

完整可复制直接运行的node代码

const ffmpegPath = require('@ffmpeg-installer/ffmpeg'); // 自动为当前node服务所在的系统安装ffmpeg
const ffmpeg = require('fluent-ffmpeg');
const express = require('express');
const webSocketStream = require('websocket-stream/stream');
const expressWebSocket = require('express-ws');

ffmpeg.setFfmpegPath(ffmpegPath.path);

/**
 * 创建一个后端服务
 */
function createServer() {
    const app = express();
    app.use(express.static(__dirname));
    expressWebSocket(app, null, {
        perMessageDeflate: true
    });
    app.ws('/rtsp/', rtspToFlvHandle);

    app.get('/', (req, response) => {
        response.send('当你看到这个页面的时候说明rtsp流媒体服务正常启动中......');
    });

    app.listen(8100, () => {
        console.log('转换rtsp流媒体服务启动了，服务端口号为8100');
    });
}

/**
 * rtsp 转换 flv 的处理函数
 * @param ws
 * @param req
 */
function rtspToFlvHandle(ws, req) {
    const stream = webSocketStream(ws, {
        binary: true,
        browserBufferTimeout: 1000000
    }, {
        browserBufferTimeout: 1000000
    });
    // const url = req.query.url;
    const url = new Buffer(req.query.url, 'base64').toString(); // 前端对rtsp url进行了base64编码，此处进行解码
    console.log('rtsp url:', url);
    try {
        ffmpeg(url)
            .addInputOption(
                '-rtsp_transport', 'tcp',
                '-buffer_size', '102400'
            )
            .on('start', (commandLine) => {
                // commandLine 是完整的ffmpeg命令
                console.log(commandLine, '转码 开始');
            })
            .on('codecData', function (data) {
                console.log(data, '转码中......');
            })
            .on('progress', function (progress) {
                // console.log(progress,'转码进度')
            })
            .on('error', function (err, a, b) {
                console.log(url, '转码 错误: ', err.message);
                console.log('输入错误', a);
                console.log('输出错误', b);
            })
            .on('end', function () {
                console.log(url, '转码 结束!');
            })
            .addOutputOption(
                '-threads', '4',  // 一些降低延迟的配置参数
                '-tune', 'zerolatency',
                '-preset', 'ultrafast'
            )
            .outputFormat('flv') // 转换为flv格式
            .videoCodec('libx264') // ffmpeg无法直接将h265转换为flv的，故需要先将h265转换为h264，然后再转换为flv
            .withSize('50%') // 转换之后的视频分辨率原来的50%, 如果转换出来的视频仍然延迟高，可按照文档上面的描述，自行降低分辨率
            .noAudio() // 去除声音
            .pipe(stream);
    } catch (error) {
        console.log('抛出异常', error);
    }
}

createServer();

react 前端

用到的关键库

• flv.js

用于前端播放flv格式视频库

完整可直接复制使用的react组件

import React, { useEffect, useRef } from 'react';
import './FlvVideoPlayer.scss';
import flvjs from 'flv.js';
import { Button } from '@alifd/next';

interface FlvVideoPlayerProps {
  url?: string; // rtsp 的url
  isNeedControl?: boolean;
  fullScreenRef?: any; // 方便组件外部调用全屏方法的ref
}

const FlvVideoPlayer = React.forwardRef<any, FlvVideoPlayerProps>(({ isNeedControl, url, fullScreenRef }, ref) => {
  const videoDomRef = useRef<any>();
  const playerRef = useRef<any>(); // 储存player的实例

  React.useImperativeHandle(ref, () => ({
    requestFullscreen,
  }));

  useEffect(() => {
    if (videoDomRef.current) {
      if (fullScreenRef) {
        fullScreenRef.current[url] = requestFullscreen;
      }
      // const url = `${videoUrl}/rtsp/video1/?url=${url}`;
      playerRef.current = flvjs.createPlayer({
        type: 'flv',
        isLive: true,
        url,
      });
      playerRef.current.attachMediaElement(videoDomRef.current);
      try {
        playerRef.current.load();
        playerRef.current.play();
      } catch (error) {
        console.log(error);
      }
    }

    return () => {
      destroy();
    };
  }, [url]);

  /**
   * 全屏方法
   */
  const requestFullscreen = () => {
    if (videoDomRef.current) {
      (videoDomRef.current.requestFullscreen && videoDomRef.current.requestFullscreen()) ||
        (videoDomRef.current.webkitRequestFullScreen && videoDomRef.current.webkitRequestFullScreen()) ||
        (videoDomRef.current.mozRequestFullScreen && videoDomRef.current.mozRequestFullScreen()) ||
        (videoDomRef.current.msRequestFullscreen && videoDomRef.current.msRequestFullscreen());
    }
  };

  /**
   * 销毁flv的实例
   */
  const destroy = () => {
    if (playerRef.current) {
      playerRef.current.pause();
      playerRef.current.unload();
      playerRef.current.detachMediaElement();
      playerRef.current.destroy();
      playerRef.current = null;
    }
  };

  return (
    <>
      <Button type="primary" onClick={requestFullscreen}>
        全屏按钮
      </Button>
      <video controls={isNeedControl} ref={videoDomRef} className="FlvVideoPlayer" loop />
    </>
  );
});

export default FlvVideoPlayer;

组件用到的url

• 本地开发时

本地开发时，node服务是启动在自己电脑上，所以node服务的地址就是 ws://127.0.0.1:8100，为了防止在传rtsp地址的过程中出现参数丢失的情况，故采用window.btoa()方法对rtsp进行base64编码一下，又由于node端代码中监听的是/rtsp/,故完整的组件的url是

ws://127.0.0.1:8100/rtsp?url=${window.btoa('rtsp地址')}

• 部署线上

直接将服务器ip替换掉127.0.0.1即可

• 提供一个测试的rtsp地址

rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mp4

遇到的问题

1. rtsp地址中存在?拼接的参数，传到后端丢失

• 错误详情

An error occured: ffmpeg exited with code 1: rtsp://... Server returned 404 Not Found

• 原因

完整的url是ws://127.0.0.1:8100/rtsp?url=${window.btoa('rtsp地址')},如果rtsp地址中再含有?拼接参数的话，那么就会出现两个?，传到node端之后，会被express去除掉rtsp地址中的?

• 解决方式

在前端对rtsp使用window.btoa方法进行base64编码，在node端使用new Buffer进行解码即可

2. 连接超时

• 报错截图
  
  

• 原因

部署到客户内网发现的，是两台服务网络不通造成的

• 解决方式

找运维解决

3. CPU飚到100%，卡顿

• 错误详情

监控视频采用分页显示，每页8个监控视频，切换到下一页的时候，上一页转换监控视频的ffmpeg进程，仍然存在，没有被kill掉。所以ffmpeg的进程不停地增加，导致CPU占用100%

• 原因

封装flvjs 的react组件中，在组件卸载的时候，没有把flvjs的实例销毁掉，导致进程不会被自动kill掉

• 解决方式

组件卸载的时候，将flvjs的实例销毁掉

4. 不能转码h265视频流

• 错误详情

Video codec hevc not compatible with flv 。Could not write header for output file #0 (incorrect codec parameters ?): Function not implemented

• 原因

有些监控摄像头的视频格式是 hevc h265, flv不支持，需要先将h265转化至h264格式

• 解决方式

node端代码中。ffmpeg添加 videoCodec('libx264') 配置即可

优化 ffmpeg 低延迟配置参数

'-threads', '4'
'-tune', 'zerolatency'
'-preset', 'ultrafast'

更新

当我把ffmpeg配置参数中的输出分辨率配置移除后，目前的延时在1~2s左右

作者：huisiyu
来源：juejin.cn/post/7124188097617051685

该问题网上答案较少,翻阅github得到想要的答案，在此记录一下

首先，为了减少包体积，在组件中局部引入vue-video-player（在main.j s中引入会增加包体积）

播放m3u8需要注意两点：

1. 需要引入videojs并绑定到window上

2. 安装依赖videojs-contrib-hls( npm i videojs-contrib-hls)并引入

3. sources要指定type为application/x-mpegURL

代码如下：

<template>
    <section>
        <video-player :options="options"></video-player>
    </section>
</template>

<script>
import { videoPlayer } from 'vue-video-player'

import videojs from 'video.js'
//注意点1：需要引入videojs并绑定到window上
window.videojs = videojs
//注意点2：引入依赖
require('videojs-contrib-hls/dist/videojs-contrib-hls.js')


require('video.js/dist/video-js.css')
require('vue-video-player/src/custom-theme.css')

export default {
    name: 'test-video-player',
    components: {
        videoPlayer
    },
    data() {
        return {
            options: {
                autoplay: false,
                height: '720',
                playbackRates: [0.7, 1.0, 1.25, 1.5, 2.0],
                sources: [
                    {
                        withCredentials: false,
                        type: 'application/x-mpegURL', //注意点3：这里的type需要指定为 'application/x-mpegURL'
                        src:
                            'https://tx-safety-video.acfun.cn/mediacloud/acfun/acfun_video/47252fc26243b079-e992c6c3928c6be2dcb2426c2743ceca-hls_720p_2.m3u8?pkey=ABDuFNTOUnsfYOEZC286rORZhpfh5uaNeFhzffUnwTFoS8-3NBSQEvWcqdKGtIRMgiywklkZvPdU-2avzKUT-I738UJX6urdwxy_ZHp617win7G6ga30Lfvfp2AyAVoUMjhVkiCnKeObrMEPVn4x749wFaigz-mPaWPGAf5uVvR0kbkVIw6x-HZTlgyY6tj-eE_rVnxHvB1XJ01_JhXMVWh70zlJ89EL2wsdPfhrgeLCWQ&safety_id=AAKir561j0mZgTqDfijAYjR6'
                    }
                ],
                hls: true
            }
        }
    },
    computed: {},
    methods: {},
    created() {}
}
</script>

<style lang="" scoped></style>

参考

• github.com/surmon-chin…

作者：我只是一个API调用工程师
来源：juejin.cn/post/7080748744592850951