1. 打包问题

    问题描述：

        a. 打包h5后报错 [system] API connectSocket is not yet implemented

        b. 打包后登录时请求token有问题。

    解决方案：如果打包h5平台出现以上两种情况，可以看下打包时想优化包体积大小是否有开启【摇钱树】具体配置如图：

         ps: 不了解该配置的可以看下uniapp的官方文档介绍，附上链接https://uniapp.dcloud.io/collocation/manifest?id=treeshaking

    问题原因：如果开启这个配置项，打包后所有uni没用到的方法都不会打包进去，这样就会导致SDK内部 uni去用request请求就拿不到，这样后续token就会有问题，或者识别不到scoket api等报错。

2. uniapp运行真机报错 【addEventListener is not defind】

解决方案：升级到4.1.0的uni sdk即可。

问题原因：addEventListener 这个是监听浏览器网络变化的，移动端下不支持，所以提示未定义，但实际上并不会影响其他功能，在后续的版本也修复了下该报错～

3. 参考demo报错【this.setData is not a function】如图：

集成过程中可能疑惑this.setData应该是小程序中的方法，为什么uni中会有，是因为demo中有对该方法重写通过minxin，具体在main.js文件中体现，如下图：

所以如果参照demo报此错可以看下这块是否有复制过来呢～

4. uniapp运行h5发送语音报错

目前的录音实现依赖uni.getRecorderManager()方式， 是不支持 H5的 可以参考下这个文章
https://en.uniapp.dcloud.io/api/media/record-manager.html#getrecordermanager

5. 登录报错 elapse 如图：

解决方案：1）看下当前是否有链接网络  2）是否有开启vpn 

6. uni-app中有时会用到nvue组件，订阅事件将会在nvue中失效，所以如果有发布订阅事件需求推荐使用，uni.$emit发布，uni.$on监听。

今天问题就分享到这里啦，感谢大家的阅读！

需求描述

目前大多数PC端应用都有配套的移动端APP，如微信，淘宝等，通过使用手机APP上的扫一扫功能去扫页面二维码图片进行登录，使得用户登录操作更方便，安全，快捷。

思路解析

PC 扫码原理？

扫码登录功能涉及到网页端、服务器和手机端，三端之间交互大致步骤如下：

1. 网页端展示二维码，同时不断的向服务端发送请求询问该二维码的状态；

2. 手机端扫描二维码，读取二维码成功后，跳转至确认登录页，若用户确认登录，则服务器修改二维码状态，并返回用户登录信息；

3. 网页端收到服务器端二维码状态改变，则跳转登录后页面；

4. 若超过一定时间用户未操作，网页端二维码失效，需要重新刷新生成新的二维码。

前端功能实现

如何生成二维码图片？

• 二维码内容是一段字符串，可以使用uuid 作为二维码的唯一标识;

• 使用qrcode插件 import QRCode from 'qrcode'; 把uuid变为二维码展示给用户

import {v4 as uuidv4} from "uuid"
import QRCode from "qrcodejs2"
 let timeStamp = new Date().getTime() // 生成时间戳，用于后台校验有效期
 let uuid = uuidv4()
 let content = `uid=${uid}&timeStamp=${timeStamp}`
 this.$nextTick(()=> {
     const qrcode = new QRCode(this.$refs.qrcode, {
       text: content,
       width: 180,
       height: 180,
       colorDark: "#333333",
       colorlight: "#ffffff",
       correctLevel: QRCode.correctLevel.H,
       render: "canvas"
     })
     qrcode._el.title = ''

如何控制二维码的时效性？

使用前端计时器setInterval, 初始化有效时间effectiveTime, 倒计时失效后重新刷新二维码

export default {
  name: "qrCode",
  data() {
    return {
      codeStatus: 1, // 1- 未扫码 2-扫码通过 3-过期
      effectiveTime: 30, // 有效时间
      qrCodeTimer: null // 有效时长计时器
      uid: '',
      time: ''
    };
  },

  methods: {
    // 轮询获取二维码状态
    getQcodeStatus() {
      if(!this.qsCodeTimer) {
        this.qrCodeTimer = setInterval(()=> {
          // 二维码过期
          if(this.effectiveTime <=0) {
            this.codeStatus = 3
            clearInterval(this.qsCodeTimer)
            this.qsCodeTimer = null
            return
          }
          this.effectiveTime--
        }, 1000)
      }

    },
   
    // 刷新二维码
    refreshCode() {
      this.codeStatus = 1
      this.effectiveTime = 30
      this.qsCodeTimer = null
      this.generateORCode()
    }
  },

前端如何获取服务器二维码的状态？

前端向服务端发送二维码状态查询请求，通常使用轮询的方式

• 定时轮询：间隔1s 或特定时段发送请求，通过调用setInterval(), clearInterval()来停止；

• 长轮询：前端判断接收到的返回结果，若二维码仍未被扫描，则会继续发送查询请求，直至状态发生变化（失效或扫码成功）

• Websocket：前端在生成二维码后，会与后端建立连接，一旦后端发现二维码状态变化，可直接通过建立的连接主动推送信息给前端。

使用长轮询实现：

 // 获取后台状态
    async checkQRcodeStatus() {
       const res = await checkQRcode({
         uid: this.uid,
         time: this.time
       })
       if(res && res.code == 200) {
         let codeStatus - res.codeStatus
         this.codeStatus =  codeStatus
         let loginData = res.loginData
         switch(codeStatus) {
           case 3:
              console.log("二维码过期")
              clearInterval(this.qsCodeTimer)
              this.qsCodeTimer = null
              this.effectiveTime = 0
            break;
            case 2:
              console.log("扫码通过")
              clearInterval(this.qsCodeTimer)
              this.qsCodeTimer = null
              this.$emit("login", loginData)
            break;
            case 1:
              console.log("未扫码")
              this.effectiveTime > 0  && this.checkQRcodeStatus()
            break;
            default:
            break;
         }
       } 
    },

参考资料：

• 三种方式实现扫码登录 | 羊驼之野望 (forthe77.github.io)

• Vue使用uuid-npm快速生成uuid，适用于多种场景 - 腾讯云开发者社区-腾讯云 (tencent.com)

作者：前端碎碎念
来源：juejin.cn/post/7179821690686275621

项目场景：

原因分析：

解决方案：

解决思路，文档描述

文档描述：若支持SDK注册，需登录环信即时通讯云控制台 (https://console.easemob.com/app/im-service/detail)，选择即时通讯 > 服务概览，将 设置下的用户注册模式设置为开放注册。可见文档地址：http://docs-im-beta.easemob.com/document/web/overview.html#sdk-%E6%B3%A8%E5%86%8C

拓展：

上文提到的用户注册模式是什么

据了解，环信的用户注册模式分为两种，一种是授权注册，一种是开放注册，这两种注册模式在即时通讯>服务概览>设置>用户注册模式可以看到，但是这两种注册模式有什么区别呢？


以下是环信文档对于开放注册和授权注册的解释，文档地址：http://docs-im-beta.easemob.com/document/server-side/account_system.html#%E5%BC%80%E6%94%BE%E6%B3%A8%E5%86%8C%E5%8D%95%E4%B8%AA%E7%94%A8%E6%88%B7

通俗解释就是授权注册比开放注册增加了token认证，授权注册更安全，但是如果在端上启用授权注册会比较麻烦，还需要自己封装请求，我这边建议大家注册还是交给后端同事来搞吧～～～～

前言

简单说下为什么React选择函数式组件，主要是class组件比较冗余、生命周期函数写法不友好，骚写法多，functional组件更符合React编程思想等等等。更具体的可以拜读dan大神的blog。其中Function components capture the rendered values这句十分精辟的道出函数式组件的优势。

但是在16.8之前react的函数式组件十分羸弱，基本只能作用于纯展示组件，主要因为缺少state和生命周期。本人曾经在hooks出来前负责过纯函数式的react项目，所有状态处理都必须在reducer中进行，所有副作用都在saga中执行，可以说是十分艰辛的经历了。在hooks出来后我在公司的一个小中台项目中使用，落地效果不错，代码量显著减少的同时提升了代码的可读性。因为通过custom hooks可以更好地剥离代码结构，不会像以前类组件那样在cDU等生命周期堆了一大堆逻辑，在命令式代码和声明式代码中有一个良性的边界。

useState在React中是怎么实现的

Hooks take some getting used to — and especially at the boundary of imperative and declarative code.

如果对hooks不太了解的可以先看看这篇文章:前情提要，十分简明的介绍了hooks的核心原理，但是我对useEffect，useRef等钩子的实现比较好奇，所以开始啃起了源码，下面我会结合源码介绍useState的原理。useState具体逻辑分成三部分：mountState，dispatch， updateState

hook的结构

首先的是hooks的结构，hooks是挂载在组件Fiber结点上memoizedState的

//hook的结构
export type Hook = {
  memoizedState: any, //上一次的state
  baseState: any,  //当前state
  baseUpdate: Update<any, any> | null,  // update func
  queue: UpdateQueue<any, any> | null,  //用于缓存多次action
  next: Hook | null, //链表
};

renderWithHooks

在reconciler中处理函数式组件的函数是renderWithHooks，其类型是：

renderWithHooks(
  current: Fiber | null, //当前的fiber结点
  workInProgress: Fiber, 
  Component: any, //jsx中用<>调用的函数
  props: any,
  refOrContext: any,
  nextRenderExpirationTime: ExpirationTime, //需要在什么时候结束
): any

在renderWithHooks，核心流程如下：

//从memoizedState中取出hooks
nextCurrentHook = current !== null ? current.memoizedState : null; 
//判断通过有没有hooks判断是mount还是update，两者的函数不同
ReactCurrentDispatcher.current =
      nextCurrentHook === null
        ? HooksDispatcherOnMount
        : HooksDispatcherOnUpdate;
//执行传入的type函数
let children = Component(props, refOrContext);
//执行完函数后的dispatcher变成只能调用context的
ReactCurrentDispatcher.current = ContextOnlyDispatcher;

return children;

useState构建时流程

mountState

在HooksDispatcherOnMount中，useState调用的是下面的mountState，作用是创建一个新的hook并使用默认值初始化并绑定其触发器，因为useState底层是useReducer，所以数组第二个值返回的是dispatch。

type BasicStateAction<S> = (S => S) | S;

function mountState<S>(
  initialState: (() => S) | S,
){
  const hook = mountWorkInProgressHook();
//如果入参是func则会调用，但是不提供参数，带参数的需要包一层
  if (typeof initialState === 'function') {
    initialState = initialState();
  }
//上一个state和基本(当前)state都初始化
  hook.memoizedState = hook.baseState = initialState;
  const queue = (hook.queue = {
    last: null,
    dispatch: null,
    eagerReducer: basicStateReducer, // useState使用基础reducer
    eagerState: (initialState: any),
  });
//返回触发器
  const dispatch: Dispatch<
    //useState底层是useReducer，所以type是BasicStateAction
 (queue.dispatch = (dispatchAction.bind(
    null,
    //绑定当前fiber结点和queue
    ((currentlyRenderingFiber: any): Fiber),
    queue,
  ): any));
  return [hook.memoizedState, dispatch];
}

mountWorkInProgressHook

这个函数是mountState时调用的构建hook的方法，在初始化完毕后会连接到当前hook.next（如果有的话）

function mountWorkInProgressHook(): Hook {
  const hook: Hook = {
    memoizedState: null,
    baseState: null,
    queue: null,
    baseUpdate: null,
    next: null,
  };
  if (workInProgressHook === null) {
    // 列表中的第一个hook
    firstWorkInProgressHook = workInProgressHook = hook;
  } else {
    // 添加到列表的末尾
    workInProgressHook = workInProgressHook.next = hook;
  }
  return workInProgressHook;
}

dispatch分发函数

在上面我们提到，useState底层是useReducer，所以返回的第二个参数是dispatch函数，其中的设计十分巧妙。

假设我们有以下代码:

相关参考视频讲解：进入学习

const [data, setData] = React.useState(0)
setData('first')
setData('second')
setData('third')

在第一次setData后， hooks的结构如上图

在第二次setData后， hooks的结构如上图

在第三次setData后， hooks的结构如上图

在正常情况下，是不会在dispatcher中触发reducer而是将action存入update中在updateState中再执行，但是如果在react没有重渲染需求的前提下是会提前计算state即eagerState。作为性能优化的一环。

function dispatchAction<S, A>(
  fiber: Fiber,
  queue: UpdateQueue<S, A>,
  action: A,
) {
  const alternate = fiber.alternate;
   {
    flushPassiveEffects();
    //获取当前时间并计算可用时间
    const currentTime = requestCurrentTime();
    const expirationTime = computeExpirationForFiber(currentTime, fiber);

    const update: Update<S, A> = {
      expirationTime,
      action,
      eagerReducer: null,
      eagerState: null,
      next: null,
    };
    //下面的代码就是为了构建queue.last是最新的更新，然后last.next开始是每一次的action
    // 取出last
    const last = queue.last;
    if (last === null) {
      // 自圆
      update.next = update;
    } else {
      const first = last.next;
      if (first !== null) {

        update.next = first;
      }
      last.next = update;
    }
    queue.last = update;

    if (
      fiber.expirationTime === NoWork &&
      (alternate === null || alternate.expirationTime === NoWork)
    ) {
      // 当前队列为空，我们可以在进入render阶段前提前计算出下一个状态。如果新的状态和当前状态相同，则可以退出重渲染
      const lastRenderedReducer = queue.lastRenderedReducer; // 上次更新完后的reducer
      if (lastRenderedReducer !== null) {
        let prevDispatcher;
        if (__DEV__) {
          prevDispatcher = ReactCurrentDispatcher.current;  // 暂存dispatcher
          ReactCurrentDispatcher.current = InvalidNestedHooksDispatcherOnUpdateInDEV;
        }
        try {
          const currentState: S = (queue.lastRenderedState: any);
          // 计算下次state
          const eagerState = lastRenderedReducer(currentState, action);
          // 在update对象中存储预计算的完整状态和reducer，如果在进入render阶段前reducer没有变化那么可以服用eagerState而不用重新再次调用reducer
          update.eagerReducer = lastRenderedReducer;
          update.eagerState = eagerState;
          if (is(eagerState, currentState)) {
            // 在后续的时间中，如果这个组件因别的原因被重渲染且在那时reducer更变后，仍有可能重建这次更新
            return;
          }
        } catch (error) {
          // Suppress the error. It will throw again in the render phase.
        } finally {
          if (__DEV__) {
            ReactCurrentDispatcher.current = prevDispatcher;
          }
        }
      }
    }
    scheduleWork(fiber, expirationTime);
  }
}

useState更新时流程

updateReducer

因为useState底层是useReducer，所以在更新时的流程(即重渲染组件后)是调用updateReducer的。

function updateState<S>(
  initialState: (() => S) | S,
): [S, Dispatch<BasicStateAction<S>>] {
  return updateReducer(basicStateReducer, (initialState: any));
}

所以其reducer十分简单

function basicStateReducer<S>(state: S, action: BasicStateAction<S>): S {
  return typeof action === 'function' ? action(state) : action;
}

我们先把复杂情况抛开，跑通updateReducer流程

function updateReducer(
  reducer: (S, A) => S,
  initialArg: I,
  init?: I => S,
){
  // 获取当前hook,queue
  const hook = updateWorkInProgressHook();
  const queue = hook.queue;

  queue.lastRenderedReducer = reducer;

  // action队列的最后一个更新
  const last = queue.last;
  // 最后一个更新是基本状态
  const baseUpdate = hook.baseUpdate;
  const baseState = hook.baseState;

  // 找到第一个没处理的更新
  let first;
  if (baseUpdate !== null) {
    if (last !== null) {
      // 第一次更新时，队列是一个自圆queue.last.next = queue.first。当第一次update提交后，baseUpdate不再为空即可跳出队列
      last.next = null;
    }
    first = baseUpdate.next;
  } else {
    first = last !== null ? last.next : null;
  }
  if (first !== null) {
    let newState = baseState;
    let newBaseState = null;
    let newBaseUpdate = null;
    let prevUpdate = baseUpdate;
    let update = first;
    let didSkip = false;
    do {
      const updateExpirationTime = update.expirationTime;
      if (updateExpirationTime < renderExpirationTime) {
        // 优先级不足，跳过这次更新，如果这是第一次跳过更新，上一个update/state是newBaseupdate/state
        if (!didSkip) {
          didSkip = true;
          newBaseUpdate = prevUpdate;
          newBaseState = newState;
        }
        // 更新优先级
        if (updateExpirationTime > remainingExpirationTime) {
          remainingExpirationTime = updateExpirationTime;
        }
      } else {
        // 处理更新
        if (update.eagerReducer === reducer) {
          // 如果更新被提前处理了且reducer跟当前reducer匹配，可以复用eagerState
          newState = ((update.eagerState: any): S);
        } else {
          // 循环调用reducer
          const action = update.action;
          newState = reducer(newState, action);
        }
      }
      prevUpdate = update;
      update = update.next;
    } while (update !== null && update !== first);

•    if (!didSkip) {
•      newBaseUpdate = prevUpdate;
•      newBaseState = newState;
•    }

•    // 只有在前后state变了才会标记
•    if (!is(newState, hook.memoizedState)) {
•      markWorkInProgressReceivedUpdate();
•    }
•    hook.memoizedState = newState;
•    hook.baseUpdate = newBaseUpdate;
•    hook.baseState = newBaseState;
     queue.lastRenderedState = newState;
  }

  const dispatch: Dispatch<A> = (queue.dispatch: any);
  return [hook.memoizedState, dispatch];
}

export function markWorkInProgressReceivedUpdate() {
  didReceiveUpdate = true;
}

后记

作为系列的第一篇文章，我选择了最常用的hooks开始，抛开提前计算及与react-reconciler的互动，整个流程是十分清晰易懂的。mount的时候构建钩子，触发dispatch时按序插入update。updateState的时候再按序触发reducer。可以说就是一个简单的redux。

作者：flyzz177
来源：juejin.cn/post/7184636589564231735

背景

脱离业务场景讲技术方案都是耍流氓

最近接手了IM的业务，一上来就来了几个大需求，搞得有点手忙脚乱。在做需求的过程中发现，我们的会话列表（RecyclerView）居然每次更新都是notifyDataSetChanged()，因为IM的刷新频率是非常高的

大家可以想象一下微信消息列表，每来1条消息，就全局调用notifyDataSetChanged。

这里瞎猜一下，可能由于历史原因，之前设计的同学也是不得已而为之。既然发现了这个问题，那么我们如何来进行优化呢？

IM列表跟普通列表的区别

• 有序性：列表中的Item按时间排序，或者其他规则（置顶也是修改时间实现）

• 唯一性：每个会话都是唯一的，不存在重复

• 单item更新频率高：可以参考微信的会话列表

DiffUtil

首先想到的是DiffUtil，它用来比较两个数据集，寻找出旧数据集->新数据集的最小变化量
实现思路：

• 获取原始会话数据，进行排序，去重操作

• 采用DiffUtil自动计算新老数据集差异，自动完成定向刷新

这里只摘取DiffUtil关键使用部分，至于高级用法和更高级的用法不再赘述

class DiffMsgCallBack: DiffUtil.Callback() {
    private val oldData: MutableList<MsgItem> = mutableListOf()
    private val newData: MutableList<MsgItem> = mutableListOf()
    //老数据集size
    override fun getOldListSize(): Int {
        return oldData.size
    }
    //新数据集size
    override fun getNewListSize(): Int {
        return newData.size
    }

    /**
     * 比较的是position，被DiffUtil调用，用来判断两个对象是否是相同的Item
     * 例如，如果你的Item有唯一的id字段，这个方法就 判断id是否相等
     */
    override fun areItemsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean {
        return oldData[oldItemPosition].id == newData[newItemPosition].id
    }
  
    /**
     * 用来检查 两个item是否含有相同的数据，当前item的内容是否发生了变化，这个方法仅仅在areItemsTheSame()返回true时，才调用
     */
    override fun areContentsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean {
        if (oldData[oldItemPosition].id != newData[newItemPosition].id){
            return false
        }
        if (oldData[oldItemPosition].content != newData[newItemPosition].content){
            return false
        }
        if (oldData[oldItemPosition].time != newData[newItemPosition].time){
            return false
        }
        return true
    }

    /**
     * 高级用法：实现部分（partial）绑定的方法，需要配合onBindViewHolder的3个参数的方法
     * 更高级用法：AsyncListDiffer+ListAdapter
     * 
     */
    override fun getChangePayload(oldItemPosition: Int, newItemPosition: Int): Any? {
        return super.getChangePayload(oldItemPosition, newItemPosition)
    }

SortedList

当我以为DiffUtil已经可以满足需求的时候，无意间又发现了一个SortedList。

SortedList是一个有序列表（数据集）的实现，可以保持ItemData都是有序的，并(自动)通知列表(RecyclerView)（数据集）中的更改。

搭配RecyclerView使用，去重，有序，自动定向刷新

这里也只摘取关键使用部分，具体用法不再详解

class SortListCallBack(adapter: RecyclerView.Adapter<*>?) : SortedListAdapterCallback<MsgItem>(adapter) {
    /**
     * 排序条件，实现排序的逻辑
     */
    override fun compare(o1: MsgItem?, o2: MsgItem?): Int {
        o1 ?: return -1
        o2 ?: return -1
        return o1.time - o2.time
    }
 
    /**
     * 和DiffUtil方法一致，用来判断 两个对象是否是相同的Item。
     */
    override fun areItemsTheSame(item1: MsgItem?, item2: MsgItem?): Boolean {
        return item1?.id == item2?.id

    }
    /**
     * 和DiffUtil方法一致，返回false，代表Item内容改变。会回调mCallback.onChanged()方法;
     * 相同：areContentsTheSame+areItemsTheSame
     */
    override fun areContentsTheSame(oldItem: MsgItem?, newItem: MsgItem?): Boolean {
        if (oldItem?.id != newItem?.id){
            return false
        }
        if (oldItem?.content != newItem?.content){
            return false
        }
        if (oldItem?.time != newItem?.time){
            return false
        }
        return true
    }
    
    /**
     * 高级用法：实现部分绑定的方法，需要配合onBindViewHolder的3个参数的方法
     */
    override fun getChangePayload(item1: MsgItem?, item2: MsgItem?): Any? {
        return super.getChangePayload(item1, item2)
    }

}

对比

DiffUtil和SortedList是非常相似的，修改过数据后，内部持有的回调接口都是同一个:androidx.recyclerview.widget.ListUpdateCallback

/**
 * An interface that can receive Update operations that are applied to a list.
 * <p>
 * This class can be used together with DiffUtil to detect changes between two lists.
 */
public interface ListUpdateCallback {
    
    void onInserted(int position, int count);

    void onRemoved(int position, int count);

    void onMoved(int fromPosition, int toPosition);

    void onChanged(int position, int count, @Nullable Object payload);

DiffUtil计算出Diff或者SortedList察觉出数据集有改变后，会回调ListUpdateCallback接口的这四个方法，DiffUtil和SortedList提供的默认Callback实现中，都会通知Adapter完成定向刷新。 这就是自动定向刷新的原理

总结

• DiffUtil比较两个数据源(一般是List)的差异（Diff），Callback中比对时传递的参数是 position

• SortedList能完成数据集的排序和去重，Callback中比对时，传递的参数是ItemData

• 都能完成自动定向刷新 + 部分绑定，一种自动定向刷新的手段

• DiffUtil: 检测不出重复的，会被认为是新增的

• DiffUtil高级用法支持子线程中处理数据，而SortList不支持

理想与现实

2种方案都有了，是不是可以进行IM会话列表的优化了呢，答案是不能

• 业务需求迭代，牵一发而动全身

• 祖传代码，无人敢动，更别说优化了

有时候我们写代码会想着后面再优化一下，然而很多时候都不会给你优化的机会，除非重大需求变动，所以一开始设计框架的时候就要结合业务场景尽量设计的更加合理

参考文章：blog.csdn.net/zxt0601/art…

作者：掀乱书页的风
来源：juejin.cn/post/7183517773790707769

前言

页面白屏，绝对是让前端开发者最为胆寒的事情，特别是随着 SPA 项目的盛行，前端白屏的情况变得更为复杂且棘手起来（ 这里的白屏是指页面一直处于白屏状态 ）

要是能检测到页面白屏就太棒了，开发者谁都不想成为最后一个知道自己页面白的人😥

web-see 前端监控方案，提供了 采样对比+白屏修正机制 的检测方案，兼容有骨架屏、无骨架屏这两种情况，来解决开发者的白屏之忧

知道页面白了，然后呢？

web-see 前端监控，会给每次页面访问生成一个唯一的uuid，当上报页面白屏后，开发者可以根据白屏的uuid，去监控后台查询该id下对应的代码报错、资源报错等信息，定位到具体的源码，帮助开发者快速解决白屏问题

白屏检测方案的实现流程

采样对比+白屏修正机制的主要流程：

1、页面中间取17个采样点（如下图），利用 elementsFromPoint api 获取该坐标点下的 HTML 元素

2、定义属于容器元素的集合，如 ['html', 'body', '#app', '#root']

3、判断17这个采样点是否在该容器集合中。说白了，就是判断采样点有没有内容；如果没有内容，该点的 dom 元素还是容器元素，若17个采样点都没有内容则算作白屏

4、若初次判断是白屏，开启轮询检测，来确保白屏检测结果的正确性，直到页面的正常渲染

采样点分布图（蓝色为采样点）：

如何使用

import webSee from 'web-see';

Vue.use(webSee, {
  dsn: 'http://localhost:8083/reportData', // 上报的地址
  apikey: 'project1', // 项目唯一的id
  userId: '89757', // 用户id
  silentWhiteScreen: true, // 开启白屏检测
  skeletonProject: true, // 项目是否有骨架屏
  whiteBoxElements: ['html', 'body', '#app', '#root'] // 白屏检测的容器列表
});

下面聊一聊具体的分析与实现

白屏检测的难点

1） 白屏原因的不确定

从问题推导现象虽然能成功，但从现象去推导问题却走不通。白屏发生时，无法和具体某个报错联系起来，也可能根本没有报错，比如关键资源还没有加载完成

导致白屏的原因，大致分两种：资源加载错误、代码执行错误

2） 前端渲染方式的多样性

前端页面渲染方式有多种，比如 客户端渲染 CSR 、服务端渲染 SSR 、静态页面生成 SSG 等，每种模式各不相同，白屏发生的情况也不尽相同

很难用一种统一的标准去判断页面是否白了

技术方案调研

如何设计出一种，在准确性、通用型、易用性等方面均表现良好的检测方案呢？

本文主要讨论 SPA 项目的白屏检测方案，包括有无骨架屏的两种情况

方案一：检测根节点是否渲染

原理很简单，在当前主流 SPA 框架下，DOM 一般挂载在一个根节点之下（比如 <div id="app"></div> ），发生白屏后通常是根节点下所有 DOM 被卸载，该方法通过检测根节点下是否挂载 DOM，若无则证明白屏

这是简单明了且有效的方案，但缺点也很明显：其一切建立在 白屏 === 根节点下 DOM 被卸载 成立的前提下，缺点是通用性较差，对于有骨架屏的情况束手无策

方案二：Mutation Observer 监听 DOM 变化

通过此 API 监听页面 DOM 变化，并告诉我们每次变化的 DOM 是被增加还是删除

但这个方案有几个缺陷

1）白屏不一定是 DOM 被卸载，也有可能是压根没渲染，且正常情况也有可能大量 DOM 被卸载

2）遇到有骨架屏的项目，若页面从始至终就没变化，一直显示骨架屏，这种情况 Mutation Observer 也束手无策

方案三：页面截图检测

这种方式是基于原生图片对比算法处理白屏检测的 web 实现

整体流程：对页面进行截图，将截图与一张纯白的图片做对比，判断两者是否足够相似

但这个方案有几个缺陷：

1、方案较为复杂，性能不高；一方面需要借助 canvas 实现前端截屏，同时需要借助复杂的算法对图片进行对比

2、通用性较差，对于有骨架屏的项目，对比的样张要由纯白的图片替换成骨架屏的截图

方案四：采样对比

该方法是对页面取关键点，进行采样对比，在准确性、易用性等方面均表现良好，也是最终采用的方案

对于有骨架屏的项目，通过对比前后获取的 dom 元素是否一致，来判断页面是否变化（这块后面专门讲解）

采样对比代码：

// 监听页面白屏
function whiteScreen() {
  // 页面加载完毕
  function onload(callback) {
    if (document.readyState === 'complete') {
      callback();
    } else {
      window.addEventListener('load', callback);
    }
  }
  // 定义外层容器元素的集合
  let containerElements = ['html', 'body', '#app', '#root'];
  // 容器元素个数
  let emptyPoints = 0;
  // 选中dom的名称
  function getSelector(element) {
    if (element.id) {
      return "#" + element.id;
    } else if (element.className) {// div home => div.home
      return "." + element.className.split(' ').filter(item => !!item).join('.');
    } else {
      return element.nodeName.toLowerCase();
    }
  }
  // 是否为容器节点
  function isContainer(element) {
    let selector = getSelector(element);
    if (containerElements.indexOf(selector) != -1) {
      emptyPoints++;
    }
  }
  onload(() => {
    // 页面加载完毕初始化
    for (let i = 1; i <= 9; i++) {
      let xElements = document.elementsFromPoint(window.innerWidth * i / 10, window.innerHeight / 2);
      let yElements = document.elementsFromPoint(window.innerWidth / 2, window.innerHeight * i / 10);
      isContainer(xElements[0]);
      // 中心点只计算一次
      if (i != 5) {
        isContainer(yElements[0]);
      }
    }
    // 17个点都是容器节点算作白屏
    if (emptyPoints == 17) {
      // 获取白屏信息
      console.log({
        status: 'error'
      });
    }
  }
}

白屏修正机制

若首次检测页面为白屏后，任务还没有完成，特别是手机端的项目，有可能是用户网络环境不好，关键的JS资源或接口请求还没有返回，导致的页面白屏

需要使用轮询检测，来确保白屏检测结果的正确性，直到页面的正常渲染，这就是白屏修正机制

白屏修正机制图例：

轮询代码：

// 采样对比
function sampling() {
  let emptyPoints = 0;
  ……
  // 页面正常渲染，停止轮询
  if (emptyPoints != 17) {
    if (window.whiteLoopTimer) {
      clearTimeout(window.whiteLoopTimer)
      window.whiteLoopTimer = null
    }
  } else {
    // 开启轮询
    if (!window.whiteLoopTimer) {
      whiteLoop()
    }
  }
  // 通过轮询不断修改之前的检测结果，直到页面正常渲染
  console.log({
    status: emptyPoints == 17 ? 'error' : 'ok'
  });
}
// 白屏轮询
function whiteLoop() {
  window.whiteLoopTimer = setInterval(() => {
    sampling()
  }, 1000)
}

骨架屏

对于有骨架屏的页面，用户打开页面后，先看到骨架屏，然后再显示正常的页面，来提升用户体验；但如果页面从始至终都显示骨架屏，也算是白屏的一种

骨架屏示例：

骨架屏的原理

无论 vue 还是 react，页面内容都是挂载到根节点上。常见的骨架屏插件，就是基于这种原理，在项目打包时将骨架屏的内容直接放到 html 文件的根节点中

有骨架屏的html文件：

骨架屏的白屏检测

上面的白屏检测方案对有骨架屏的项目失灵了，虽然页面一直显示骨架屏，但判断结果页面不是白屏，不符合我们的预期

需要通过外部传参明确的告诉 SDK，该页面是不是有骨架屏，如果有骨架屏，通过对比前后获取的 dom 元素是否一致，来实现骨架屏的白屏检测

完整代码：

/**
 * 检测页面是否白屏
 * @param {function} callback - 回到函数获取检测结果
 * @param {boolean} skeletonProject - 页面是否有骨架屏
 * @param {array} whiteBoxElements - 容器列表，默认值为['html', 'body', '#app', '#root']
 */
export function openWhiteScreen(callback, { skeletonProject, whiteBoxElements }) {
  let _whiteLoopNum = 0;
  let _skeletonInitList = []; // 存储初次采样点
  let _skeletonNowList = []; // 存储当前采样点

  // 项目有骨架屏
  if (skeletonProject) {
    if (document.readyState != 'complete') {
      sampling();
    }
  } else {
    // 页面加载完毕
    if (document.readyState === 'complete') {
      sampling();
    } else {
      window.addEventListener('load', sampling);
    }
  }
  // 选中dom点的名称
  function getSelector(element) {
    if (element.id) {
      return '#' + element.id;
    } else if (element.className) {
      // div home => div.home
      return ('.' + element.className.split(' ').filter(item => !!item).join('.'));
    } else {
      return element.nodeName.toLowerCase();
    }
  }
  // 判断采样点是否为容器节点
  function isContainer(element) {
    let selector = getSelector(element);
    if (skeletonProject) {
      _whiteLoopNum ? _skeletonNowList.push(selector) : _skeletonInitList.push(selector);
    }
    return whiteBoxElements.indexOf(selector) != -1;
  }
  // 采样对比
  function sampling() {
    let emptyPoints = 0;
    for (let i = 1; i <= 9; i++) {
      let xElements = document.elementsFromPoint(
        (window.innerWidth * i) / 10,
        window.innerHeight / 2
      );
      let yElements = document.elementsFromPoint(
        window.innerWidth / 2,
        (window.innerHeight * i) / 10
      );
      if (isContainer(xElements[0])) emptyPoints++;
      // 中心点只计算一次
      if (i != 5) {
        if (isContainer(yElements[0])) emptyPoints++;
      }
    }
    // 页面正常渲染，停止轮训
    if (emptyPoints != 17) {
      if (skeletonProject) {
        // 第一次不比较
        if (!_whiteLoopNum) return openWhiteLoop();
        // 比较前后dom是否一致
        if (_skeletonNowList.join() == _skeletonInitList.join())
          return callback({
            status: 'error'
          });
      }
      if (window._loopTimer) {
        clearTimeout(window._loopTimer);
        window._loopTimer = null;
      }
    } else {
      // 开启轮训
      if (!window._loopTimer) {
        openWhiteLoop();
      }
    }
    // 17个点都是容器节点算作白屏
    callback({
      status: emptyPoints == 17 ? 'error' : 'ok',
    });
  }
  // 开启白屏轮训
  function openWhiteLoop() {
    if (window._loopTimer) return;
    window._loopTimer = setInterval(() => {
      if (skeletonProject) {
        _whiteLoopNum++;
        _skeletonNowList = [];
      }
      sampling();
    }, 1000);
  }
}

如果不通过外部传参，SDK 能否自己判断是否有骨架屏呢？ 比如在页面初始的时候，根据根节点上有没有子节点来判断

因为这套检测方案需要兼容 SSR 服务端渲染的项目，对于 SSR 项目来说，浏览器获取 html 文件的根节点上已经有了 dom 元素，所以最终采用外部传参的方式来区分

总结

这套白屏检测方案是从现象推导本质，可以覆盖绝大多数 SPA 项目的应用场景

小伙们若有其他检测方案，欢迎多多讨论与交流 💕

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

前端登录有很多种方式，我们来挑一些常见的方案先梳理一下，后续再补充更多的。

账号密码登录

在系统数据库中已经有了账号密码，或者通过注册渠道生成了账号和密码，此时可以直接通过账号密码登录，只要账号密码正确就认为身份合法，可以换到系统访问的 token，用于后续业务鉴权。

验证码登录

比如手机验证码，邮箱验证码等等。用户首先提供手机号/邮箱，后端根据会话信息生成一个特定的码下发到用户的手机或者邮箱（通过运营商提供的能力）。

用户得到这个码后填入登录表单，随手机号/邮箱一并发给后端，后端拿到手机号/邮箱、码后，与会话信息做校验，确认身份信息是否合法。

如果一致就检查数据库中是否有这个手机号/邮箱，有的话就不用创建用户了，直接通过登录；没有的话就说明是新用户，可以先创建用户，绑定好手机号/邮箱，然后通过登录。

第三方授权

比如微信授权，github授权之类的，可以通过OAuth授权得到访问对方开放API的能力。

OAuth 协议读起来很复杂，其实本质上就是：

• 我是开发者，有个自己的业务系统。

• 用户想图方便，希望通过一些常用的平台（比如微信，支付宝等）登录到我的业务系统。

• 但是这也不是你想用就能用的，我首先要去三方平台登记一下我的应用，比如注册一个微信公众号，公众号再绑定我的业务域名（验证所有权），可能还要交个费做微信认证之类的。

• 交了保护费后（经过上面的操作），我的业务系统就是某三方平台的合法应用了，就可以使用某三方平台的开放接口了。

• 此时用户来到我的业务系统客户端，点击微信一键登录。

• 然后我的业务系统就会按照微信的规矩生成一些鉴权需要的信息，拉起微信的中间页（如果是手机客户端，那可能就是通过 SDK 拉起手机微信）让用户授权。

• 用户同意授权，微信的中间页鉴权成功后，就会给我的客户端返回一个 code 之类的回调信息，客户端需要把这个 code 传给后端。

• 后端拿到这个 code 可以去微信服务器换取 access_token，基于这个 access_token，可以获取微信用户基本开放信息和帮助用户实现基础开放功能等。

• 后端也可以基于此封装自定义的登录态返给客户端，如有必要，也可以生成用户表中的记录。

• 此时我就认为这个用户是通过微信合法登录到我的系统中了。

有些字段或者信息之类的可能会描述得不够精确，但是整个鉴权的思路大概就是这样。

微信小程序登录

wx.login + code2Session 无感登录

如果你的业务系统需要鉴权大部分接口，但是又不想让用户一打开小程序就去输入啥或者点啥按钮登录，那么无感登录是比较适合的。

关键是找到能唯一标识用户身份的东西，openid 或者 unionid 就不错。那么怎么无感得到这些？wx.login + code2Session 值得拥有。

小程序前端 wx.login 得到用户登录凭证 code（目前说的有效期是五分钟），然后把 code 传给服务端，服务端调用微信服务的 auth.code2Session，使用 code 换取 openid、unionid、session_key 等信息，session_key 相当于是当前用户在微信的会话标识，我们可以基于此自定义登录态再返回给前端，前端拿着登录态再访问后端的业务接口。

getPhonenumber授权手机号登录

当指定 button 组件的 open-type 为 getPhoneNumber 时，可以拉起手机号授权，手机号某种程度上可以标识用户身份，自然也可以用来做登录。

旧版方案中，getPhonenumber得到的 e 对象中有 encryptedData, iv 字段，传给后端，根据解密算法能得到手机号和区号等信息。手机号也相当于是一种可以唯一标识用户的信息（虽然一个人可以有多个手机号，不过宽松点来说也可以用来标识用户），自然可以用来生成用户表记录，后续再与其他信息做关联即可。

但是旧版方案已经不建议使用了，目前 getPhonenumber得到的 e 对象中有 code 字段，这个 code 和 wx.login 得到的 code 不是同一回事。我们把这个 code 传给后端，后端再调用 phonenumber.getPhoneNumber得到手机号信息。

接着再封装登录态返回给前端即可。

微信公众号登录

首先分析一下渠道，在微信环境中，用户可能会直接通过链接访问 H5，也可能通过公众号菜单进入 H5。

微信公众号网页提供了授权方案，具体可以参考这个网页授权文档。

授权有两种形式，snsapi_base 和 snsapi_userinfo。

这个授权是支持无感的，具体见这个解释。

关于特殊场景下的静默授权

上面已经提到，对于以snsapi_base为 scope 的网页授权，就静默授权的，用户无感知；

对于已关注公众号的用户，如果用户从公众号的会话或者自定义菜单进入本公众号的网页授权页，即使是 scope 为snsapi_userinfo，也是静默授权，用户无感知。

这基本上就是说，如果是 snsapi_base 方式，目的主要是取 token 和 openid，用来做后续业务鉴权，那就是无感的。

如果是 snsapi_userinfo 方式，除了拿鉴权信息，还要要拿头像昵称等信息，可能需要用户授权，不过只要关注了该公众号，也可以不出现授权中间页，也是无感的。

下面说下具体的交互形式。

snsapi_base 场景下，需要绑定一个回调地址，交互形式是：

1. 根据标准格式提供链接：

https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=snsapi_base&state=STATE#wechat_redirect

1. 你可以在公众号菜单跳转这个标准链接，或者通过其他网页跳转这个链接。这个链接是个微信鉴权的中间页，如果鉴权没问题就会回调到 REDIRECT_URI 对应的业务系统页面，也就是用户真正前往的网页，用户能感知到的就是网页的进度条加载了两次，然后就到目标页面了，基本上是无感的。

2. 页面在回调时会在 querystring 上携带 code 参数。前端在这个页面拿到 code 后，可以传给后端，后端就可以调下面这个接口得到 token 信息，然后封装出登录态返给前端。

https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

具体实现时，不一定要在页面层级上完成 code 换 token 的操作，也可以在应用层级上实现。

1. 后续可以根据需要进行 refreshToken。

snsapi_userinfo 场景下，也是跳一个标准链接。与 snsapi_base 场景相比，除了 scope 参数不一样，其他都一样。跳转这个标准链接时会根据有没有关注公众号决定是否要拉起授权中间页面。

https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=snsapi_userinfo&state=STATE#wechat_redirect

接着也可以根据 code 换 token，进行必要的 refreshToken。

最重要的是，在 scope=snsapi_userinfo 场景下，还可以发起获取用户信息的请求，这才是它与 snsapi_base 的本质区别。如果 scope 不符合要求，则无法通过调用下面的接口得到用户信息。

https://api.weixin.qq.com/sns/userinfo?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN

还有一些公告调整内容要注意一下：

• 微信网页授权能力调整公告

结语

好了，前端常见的一些登录方式先整理到这里，实际上还有很多种方案还没提到，比如生物认证登录，运营商验证登录等等，后面再补充，只要是双方互相认可的方案，并且能标识用户身份，不管是严格的还是宽松的，都可以拿来做认证使用，具体还要根据你的业务特性决定。

作者：Tusi
来源：juejin.cn/post/7172026468535369735

什么年代了还在用传统账号密码登录？没钱买手机号验证码组合？直接把鉴权和用户系统全盘托出依赖第三方（又不是不能用），省去鉴权系列 SQL 攻击、密码加密、CSRF 攻击、XSS 攻击，老板再也不用担心黑产盗号了（我们的系统根本没有号）

要实现上面的功能就得接入第三方登录，接下来就随着文章一起试试吧！

github

本章节将使用 github 作为第三方登录服务提供商

github 不愧是阿美力卡之光，极其简便的操作即可开启你的第三方登录之旅，经济又实惠，你可以通过快捷链接进入创建 OAuth 应用界面，也可以按照下面的顺序

然后填写相应的信息

生成你的密钥（Client secrets），就可以去试试第三方登录了

组合 URL

您可以在线查看本章节源代码

这里我使用的是 express-generator 去生成项目，并且前后端分离，在选项上不需要 HTML 渲染器

npx express --no-view your-project-path && cd your-project-path

前端部分简单设置一下跳转验证

<html>
  <body>
    <div>
      第三方登录
      <br />
      <button onclick="handleGithubLoginClick()">github</button>
    </div>
  </body>
  <script>
    const handleGithubLoginClick = () => {
      const state = Math.floor(Math.random() * Math.pow(10, 8));
      localStorage.setItem("state", state);
      window.open(
        `https://github.com/login/oauth/authorize?client_id=b351931efd1203b2230e&redirect_uri=http://localhost:8080&state=${state}`,
        "_blank"
      );
    };
  </script>
</html>

其中有三个比较重要的 params

1. client_id - string - “必需”。 注册时从 GitHub 收到的客户端 ID。

2. redirect_uri - string - 用户获得授权后被发送到的应用程序中的 URL。 请参阅以下有关重定向 URL 的详细信息。

3. state - string - 不可猜测的随机字符串。 它用于防止跨站请求伪造攻击。

redirect_uri 默认是注册 OAuth 应用（Register a new OAuth application）是填写的授权回调 URL（Authorization callback URL）

而对于 state 就在前端用随机字符串模拟，通常此类加密的敏感数据会再后端生成，而这里为了方便演示就采用了前端生成

详细参数请参考文档

鉴权验证

登录之后就可以进行相对应的验证，比如输入账号密码、授权、Github 客户端验证

成功鉴权后会再新弹出的页面重定向至 redirect_uri

注意要在属于用户操作的范畴下，比如点击按钮的操作，去使用 window.open(strUrl, strWindowName, [strWindowFeatures]) 这种方式去跳转鉴权，否则像 window.open("https://github.com...", "_blank") 这种常见的写法，会报错

浏览器会以为是弹窗式广告，所以我推荐使用直接在当前窗口跳转的方法，而不是选择新开窗口或者浮动窗口

window.location.href = "https://github.com/login/oauth/authorize?client_id=b351931efd1203b2230e&redirect_uri=http://localhost:8080";

处理回调

通过用户授权时，Github 的响应如下

GET redirect_uri

参数

state 参数负责安全非常重要，想要快速通关的选手可以跳过这部分

对于这里的 state 处理可以分为前端处理和后端处理

前端处理

当 redirect_uri 是前端路由时，可以将之前提交的 state 从 localStorage 或者 sessionStorage 中取出，验证是否一致，再去向后端请求并带上 state 和 code

优点

1. 无需缓存 state

缺点

1. 需要防止 XSS 的 DOM 型攻击

后端处理

当 redirect_uri 是后端时，后端需要持有 state 的缓存，具体做法可以在前端处理第三方登录时同步随机生成的 state，并在后端缓存

优点

1. 不需要防止 XSS 的 DOM 型攻击

缺点

1. 需要缓存 state

科普：早期 token 其实就是这里的 state

获取 token

第三方登录从本质上来讲就是获取到 token，在安全的拿到 code 和 state 之后，需要向 github 发送获取 token 请求，其文档如下

POST https://github.com/login/oauth/access_token

参数

响应

注意因为 client_secret 属于私钥，所以该请求必须放在后端，不能在前端请求！否则会失去登录的意义

const { default: axios } = require("axios");
const express = require("express");
const router = express.Router();

router.post("/redirect", function (req, res, next) {
  const { code } = req.body;
  axios({
    method: "POST",
    url: "https://github.com/login/oauth/access_token",
    headers: {
      "Accept": "application/json",
    },
    timeout: 60 * 1000,
    data: {
      client_id: "your_client_id",
      client_secret: "your_client_secret",
      code,
    },
  })
    .then((response) => {
      res.send(response.data);
    })
    .catch((e) => {
      res.status(404);
    });
});

module.exports = router;

注意，由于 github 的服务器在国外，所以这个请求非常容易超时或者失效，建议做好对应的处理（或者设置一个比较长的时间）

最后拿到对应的 token

总结

如果还没有了解过第三方登录的同学可以试试，毕竟不需要审核，有对应的 github 账号就行，截至写完文章的现在，我仍然没有通过微博第三方登录的审核/(ㄒoㄒ)/~~

参考资料

1. 授权 OAuth 应用 - Github Docs

2. 给你的网站添加第三方登录以及短信验证功能

作者：2分钟速写快排
来源：juejin.cn/post/7181114761394782269

当前技术社区中出现了各种下一代技术或框架，却很少有当代可以用的，于是electron-egg就出现了。

它愿景很大：希望所有开发者都能学会桌面软件开发

当前桌面软件技术有哪些？

为什么使用electron？

某某说：我们的应用要兼容多个平台，原生开发效率低，各平台研发人员不足，我们没有资源。

也许你觉得只是中小公司没有资源，no！大公司更没有资源。因为软件体量越大，所需研发人员越多。再加上需要多平台支持的话，研发人员更是指数级增长的。

我们来看看QQ团队负责人最近的回应吧：

“感谢大家对新版桌面QQ NT的使用和关注，今年QQ团队启动了QQ的架构升级计划，第一站就是解决目前桌面端迭代慢的问题，我们使用新架构从前到后对QQ代码进行了重构，而其中选择使用Electron作为新版QQ桌面端UI跨平台解决方案，是基于提升研发效率、框架成熟度、团队技术及人才积累等几个方面综合考虑的结果。”

也许electron的缺点很明显，但它的投入产出比却是最高的。

所以，对企业而言，效率永远是第一位的。不要用程序员的思维去思考产品。

哪些企业或软件在使用electron？

国内：抖音客户端、百度翻译、阿里云盘、B站客户端、迅雷、网易有道云、QQ(doing) 等

国外：vscode、Slack、Atom、Discord、Skype、WhatsApp、等

你的软件用户体量应该没有上面这些公司多吧？所以你还有什么可担心的呢？

开发者 / 决策者不要去关心性能、包体大小这些东西，当你的产品用户少时，它没意义；当你的产品用户多时，找nb的人把它优化。

聊聊electron-egg框架

EE是一个业务框架；就好比 Spring之于java，thinkphp之于php，nuxt.js之于vue；electron只提供了基础的函数和api，但你写项目的时候，业务和代码工程化是需要自己实现的，ee就提供了这个工程化能力。

特性

• 🍄 跨平台：一套代码，可以打包成windows版、Mac版、Linux版、国产UOS、Deepin、麒麟等

• 🌹 简单高效：只需学习 js 语言

• 🌱 前端独立：理论上支持任何前端技术，如：vue、react、html等等

• 🌴 工程化：可以用前端、服务端的开发思维，来编写桌面软件

• 🍁 高性能：事件驱动、非阻塞式IO

• 🌷 功能丰富：配置、通信、插件、数据库、升级、打包、工具... 应有尽有

• 🌰 安全：支持字节码加密、压缩混淆加密

• 💐 功能demo：桌面软件常见功能，框架集成或提供demo

谁可以使用electron-egg？

前端、服务端、运维、游戏等技术人员皆可使用。我相信在你的工作生涯中，或多或少都接触过js，恭喜你，可以入门了。

为什么各种技术栈的开发者都能使用electron-egg？

这与它的架构有关。

第一：前端独立

你可以用vue、react、angular等开发框架；也可用antdesign、layui、bootstrap等组件库；或者你用cococreater开发游戏也行； 框架只需要最终构建的资源（html/css/js）。

第二：工程化-MVC编程模式

如果你是java、php、python等后端开发者，不懂js那一套编程模式怎么办？

没关系，框架已经为你提供了MVC（controller/service/model/view），是不是很熟悉？官方提供了大量业务场景demo，直接开始撸代码吧。

开箱即用

编程方法、插件、通信、日志、数据库、调试、脚本工具、打包工具等开发需要的东西，框架都已经提供好了，你只需要专注于业务的实现。

十分钟体验

安装

# 下载
git clone https://gitee.com/dromara/electron-egg.git

# 安装依赖
npm install

# 启动
npm run start

效果

界面中的功能是demo，方便初学者入门。

项目案例

EE框架已经应用于医疗、学校、政务、股票交易、ERP、娱乐、视频、企业等领域客户端

以下是部分开发者使用electron-egg开发的客户端软件，请看效果

后语

仓库地址，欢迎给项目点赞！

gitee ： gitee.com/dromara/ele… 2300+

github ： github.com/dromara/ele… 500+

关于 Dromara

Dromara 是由国内顶尖的开源项目作者共同组成的开源社区。提供包括分布式事务，流行工具，企业级认证，微服务RPC，运维监控，Agent监控，分布式日志，调度编排等一系列开源产品、解决方案与咨询、技术支持与培训认证服务。技术栈全面开源共建、 保持社区中立，致力于为全球用户提供微服务云原生解决方案。让参与的每一位开源爱好者，体会到开源的快乐。

Dromara开源社区目前拥有10+GVP项目，总star数量超过十万，构建了上万人的开源社区，有成千上万的个人及团队在使用Dromara社区的开源项目。

electron-egg已加入dromara组织。

作者：哆啦好梦
来源：juejin.cn/post/7181279242628366397

废话开篇：一些 404 页面为了体现趣味性会添加一些简单的交互效果。 这里用纯 JS 简单实现类似 404 可跳跃障碍物页面，内容全部用 canvas 画布实现。

一、效果展示

二、画面拆解

1、绘制地平线

地平线这里就是简单的一条贯穿屏幕的线。

2、绘制红色精灵

绘制红色精灵分为两部分：

（1）上面圆

（2）下面定点与上面圆的切线。

绘制结果：

进行颜色填充，再绘制中小的小圆，绘制结果：

（3）绘制障碍物

这里绘制的是一个黑色的长方形。最后的实现效果：

三、逻辑拆解

1、全局定时器控制画布重绘

创建全局的定时器。

它有两个具体任务：

（1）全局定时刷新重置，将画布定时擦除之前的绘制结果。

（2）全局定时器刷新动画重绘新内容。

2、精灵跳跃动作

在接收到键盘 “空格” 点击的情况下，让精灵起跳一定高度，到达顶峰的时候进行回落，当然这里设计的是匀速。

3、障碍物移动动作

通过定时器，重绘障碍物从最右侧移动到最左侧。

4、检测碰撞

在障碍物移动到精灵位置时，进行碰撞检测，判断障碍物最上端的左、右顶点是否在精灵的内部。

5、绘制提示语

提示语也是用 canvas 绘制的，当障碍物已移动到左侧的时候进行，结果判断。如果跳跃过程中无碰撞，就显示 “完美跳跃～”，如果调跃过程中有碰撞，就显示 “再接再厉”。

四、代码讲解

1、HTML

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <title></title>
        <script src="./wsl404.js"></script>
    </head>
    <body>
        <div id="content">
            <canvas id="myCanvas">
            </canvas>
        </div>
    </body>
    <script>
        elves.init();
    </script>
</html>

2、JS

(function WSLNotFoundPage(window) {
    var elves = {};//精灵对象
    elves.ctx = null;//画布
    elves.width = 0;//屏幕的宽度
    elves.height = 0;//屏幕的高度
    elves.point = null;//精灵圆中心
    elves.elvesR = 20;//精灵圆半径
    elves.runloopTargets = [];//任务序列（暂时只保存跳跃）
    elves.upDistance = 50;//当前中心位置距离地面高度
    elves.upDistanceInitNum = 50;//中心位置距离地面高度初始值
    elves.isJumping = false;//是否跳起
    elves.jumpTarget = null;//跳跃任务
    elves.jumpTop = false;//是否跳到最高点
    elves.maxCheckCollisionWith = 0;//碰撞检测的最大宽度尺寸
    elves.obstaclesMovedDistance = 0;//障碍物移动的距离
    elves.isCollisioned = false;//是否碰撞过
    elves.congratulationFont = 13;//庆祝文字大小
    elves.congratulationPosition = 40;//庆祝文字位移
    elves.isShowCongratulation = false;//是否展示庆祝文字
    elves.congratulationContent = "完美一跃～";
    elves.congratulationColor = "red";
    
    //初始化
    elves.init = function(){
        this.drawFullScreen("content");
        this.drawElves(this.upDistance);
        this.keyBoard();   
        this.runloop();
    }
    
    //键盘点击事件
    elves.keyBoard = function(){
        var that = this;
        document.onkeydown = function whichButton(event)
        {
          if(event.keyCode == 32){
            //空格
            that.elvesJump();
           }
         }
    }
    
    //开始跑圈
    elves.runloop = function(){
        var that = this;
        setInterval(function(){
            //清除画布
            that.cleareAll();
            //绘制障碍物
            that.creatObstacles();
            if(that.isJumping == false){
                //未跳起时重绘精灵
                that.drawElves(that.upDistanceInitNum);
            }
            //绘制地面
            that.drawGround();
            
            //跳起任务
            for(index in that.runloopTargets){
                let target = that.runloopTargets[index];
                if(target.isRun != null && target.isRun == true){
                    
                    if(target.runCallBack){
                        target.runCallBack();
                    }
                }
            }
            //碰撞检测
            that.checkCollision();
            //展示庆祝文字
            if(that.isShowCongratulation == true){
                that.congratulation();
            }
            
        },10);
    }
    
    //画布
    elves.drawFullScreen = function (id){
        var element = document.getElementById(id);
        this.height = window.screen.height - 200;
        this.width = window.screen.width;
        element.style.width = this.width + "px";
        element.style.height = this.height + "px";
        element.style.background = "white";
        this.getCanvas("myCanvas",this.width,this.height);
    }
    
    elves.getCanvas = function(id,width,height){
        var c = document.getElementById(id);
        this.ctx = c.getContext("2d");
        //锯齿修复
        if (window.devicePixelRatio) {
           c.style.width = this.width + "px";
           c.style.height = this.height + "px";
           c.height = height * window.devicePixelRatio;
           c.width = width * window.devicePixelRatio;
           this.ctx.scale(window.devicePixelRatio, window.devicePixelRatio);
        }
    };
    
    //绘制地面
    elves.drawGround = function() {
        // 设置线条的颜色
        this.ctx.strokeStyle = 'gray';
        // 设置线条的宽度
        this.ctx.lineWidth = 1;
        // 绘制直线
        this.ctx.beginPath();
        // 起点
        this.ctx.moveTo(0, this.height / 2.0 + 1);
        // 终点
        this.ctx.lineTo(this.width,this.height / 2.0);
        this.ctx.closePath();
        this.ctx.stroke();
    }
    
    //绘制精灵
    elves.drawElves = function(upDistance){
        
        //绘制圆
        var angle = Math.acos(this.elvesR / upDistance);
        this.point = {x:this.width / 3,y : this.height / 2.0 - upDistance};
        this.ctx.fillStyle = "#FF0000";
        this.ctx.lineWidth = 1;
        this.ctx.beginPath();
        this.ctx.arc(this.point.x,this.point.y,this.elvesR,Math.PI / 2 + angle,Math.PI / 2 - angle,false);
        
        //绘制切线
        var bottomPoint = {x:this.width / 3,y : this.point.y + this.upDistanceInitNum};
        
        let leftPointY = this.height / 2.0 - (upDistance - Math.cos(angle) * this.elvesR);
        let leftPointX = this.point.x - (Math.sin(angle) * this.elvesR);
        var leftPoint = {x:leftPointX,y:leftPointY};
        
        let rightPointY = this.height / 2.0 - (upDistance - Math.cos(angle) * this.elvesR);
        let rightPointX = this.point.x + (Math.sin(angle) * this.elvesR);
        var rightPoint = {x:rightPointX,y:rightPointY};
        
        this.maxCheckCollisionWith = (rightPointX - leftPointX) * 20 / (upDistance - Math.cos(angle) * this.elvesR);
        this.ctx.moveTo(bottomPoint.x, bottomPoint.y);
        this.ctx.lineTo(leftPoint.x,leftPoint.y);
        this.ctx.lineTo(rightPoint.x,rightPoint.y);
        
        this.ctx.closePath();
        this.ctx.fill();
        
        //绘制小圆
        this.ctx.fillStyle = "#FFF";
        this.ctx.lineWidth = 1;
        this.ctx.beginPath();
        this.ctx.arc(this.point.x,this.point.y,this.elvesR / 3,0,Math.PI * 2,false);
        this.ctx.closePath();
        this.ctx.fill();
    }
    
    //清除画布
    elves.cleareAll = function(){
        this.ctx.clearRect(0,0,this.width,this.height);
    }
    
    //精灵跳动
    elves.elvesJump = function(){
        if(this.isJumping == true){
            return;
        }
        this.isJumping = true;
        if(this.jumpTarget == null){
            var that = this;
            this.jumpTarget = {type:'jump',isRun:true,runCallBack:function(){
                let maxDistance = that.upDistanceInitNum + 55;
                if(that.jumpTop == false){
                    if(that.upDistance > maxDistance){
                        that.jumpTop = true;
                    }
                    that.upDistance += 1;
                } else if(that.jumpTop == true) {
                    that.upDistance -= 1;
                    if(that.upDistance < 50) {
                        that.upDistance = 50;
                        that.jumpTop = false;
                        that.jumpTarget.isRun = false;
                        that.isJumping = false;
                    }
                }
                that.drawElves(that.upDistance);
            }};
            this.runloopTargets.push(this.jumpTarget);
        } else {
            this.jumpTarget.isRun = true;
        }
    }
    
    //绘制障碍物
    elves.creatObstacles = function(){
        let obstacles = {width:20,height:20};
        if(this.obstaclesMovedDistance != 0){
            this.ctx.clearRect(this.width - obstacles.width - this.obstaclesMovedDistance + 0.5, this.height / 2.0 - obstacles.height,obstacles.width,obstacles.height);
        }
        this.obstaclesMovedDistance += 0.5;
        if(this.obstaclesMovedDistance >= this.width + obstacles.width) {
            this.obstaclesMovedDistance = 0; 
            //重置是否碰撞
            this.isCollisioned = false;
        }
        this.ctx.beginPath();
        this.ctx.fillStyle = "#000";
        this.ctx.moveTo(this.width - obstacles.width - this.obstaclesMovedDistance, this.height / 2.0 - obstacles.height);
        this.ctx.lineTo(this.width - this.obstaclesMovedDistance,this.height / 2.0 - obstacles.height);
        this.ctx.lineTo(this.width - this.obstaclesMovedDistance,this.height / 2.0);
        this.ctx.lineTo(this.width - obstacles.width - this.obstaclesMovedDistance, this.height / 2.0);
        this.ctx.closePath();
        this.ctx.fill();
    }
    
    //检测是否碰撞
    elves.checkCollision = function(){
        var obstaclesMarginLeft = this.width - this.obstaclesMovedDistance - 20;
        var elvesUpDistance = this.upDistanceInitNum - this.upDistance + 20;
        if(obstaclesMarginLeft > this.point.x - this.elvesR && obstaclesMarginLeft < this.point.x + this.elvesR && elvesUpDistance <= 20) {
            //需要检测的最大范围
            let currentCheckCollisionWith = this.maxCheckCollisionWith * elvesUpDistance / 20;
            if((obstaclesMarginLeft < this.point.x + currentCheckCollisionWith / 2.0 && obstaclesMarginLeft > this.point.x - currentCheckCollisionWith / 2.0) || (obstaclesMarginLeft + 20 < this.point.x + currentCheckCollisionWith / 2.0 && obstaclesMarginLeft + 20 > this.point.x - currentCheckCollisionWith / 2.0)){
                this.isCollisioned = true;
            }
        }
        
        //记录障碍物移动到精灵左侧
        if(obstaclesMarginLeft + 20 < this.point.x - this.elvesR && obstaclesMarginLeft + 20 > this.point.x - this.elvesR - 1){
            if(this.isCollisioned == false){
                //跳跃成功，防止检测距离内重复得分置为true，在下一次循环前再置为false
                this.isCollisioned = true;
                //庆祝
                if(this.isShowCongratulation == false) {
                    this.congratulationContent = "完美一跃～";
                    this.congratulationColor = "red";
                    this.isShowCongratulation = true;
                }
            } else {
                //鼓励
                if(this.isShowCongratulation == false) {
                    this.isShowCongratulation = true;
                    this.congratulationColor = "gray";
                    this.congratulationContent = "再接再厉～";
                }
            }
        }
    }
    
    //庆祝绘制文字
    elves.congratulation = function(){
        
        this.congratulationFont += 0.1;
        this.congratulationPosition += 0.1;
        if(this.congratulationFont >= 30){
                        //重置
            this.congratulationFont = 13;
            this.congratulationPosition = 30;
            this.isShowCongratulation = false;
            return;
        }
        this.ctx.fillStyle = this.congratulationColor;        
        this.ctx.font = this.congratulationFont + 'px "微软雅黑"';        
        this.ctx.textBaseline = "bottom";         
        this.ctx.textAlign = "center"; 
        this.ctx.fillText( this.congratulationContent, this.point.x, this.height / 2.0 - this.upDistanceInitNum - this.congratulationPosition);   
    }
    
    window.elves = elves;
})(window)

五、总结与思考

逻辑注释基本都写在代码里，里面的一些计算可能会绕一些。

作者：头疼脑胀的代码搬运工
来源：juejin.cn/post/7056610619490828325

很多公司都会有自己的组件库，但是在使用起来都不尽如人意，这里分享下我自己的一些观点和看法

问题思考

在规划这种整个团队都要用的工具之前要多思考，走一步想一步的方式是不可取的

首先，在开发一个组件库之前先要明确以下几点：

• 目前现状

  • 不自建的话会有哪些问题，为什么不用 antd/element

  • 哪些人提出了哪些的问题

  • 分析为什么会出现这些问题

  • 哪些问题是必须解决的，哪些是阶段推进的

• 期望目标

  • 组件库的定位是什么

  • 自建组件库是为了满足什么场景

  • 阶段目标是什么

  • 最终期望达到什么效果

• 具体实现

  • 哪些问题用哪些方法来解决

  • 关于后续迭代是怎么考虑的

目前现状

仅仅是因为前端开发为了部分代码或者样式不用重复写就封装一个组件甚至组件库是一件很搞笑的事情，最终往往会出现以下问题：

• 代码分散但是却高耦合，存在很多职责不明确

• 封装过于死板，且暴露的属性职责不明确

• 可维护性低，无法应对不断变化的需求

• 可靠性低，对上游数据不做错误处理，对下游使用者不做兼容处理

最后没法迭代，因为代码质量及版本问题，连原始开发者都改不动的，相关使用者怨声载道，然后又重构一遍，还是同样的设计思路，只不过基于已知业务场景改了写法，然后过一段时间又成为一个新的历史包袱。。。

当你为了方便改别人的代码而选择 fork 别人的组件库下来简单改改再输出时，难道你觉得别人不会对“你写的”这个组件库持同样的看法么？

你会发现，如果仅仅以一个业务员的角度去寻求解决办法的话，最后往往不能够得到其他业务员的认可的～

组件库的存在目的是为了提高团队的工作效率，不是单纯为了个别人能少写代码，前者才是目的，后者只是其中一种实现方式（这句话自己悟吧）

期望目标

一个合格的组件库应该要让使用者感受到两点：

• 约束（为什么只能这样传嘛？）

• 方便（只要这样传就可以耶～）

不合格的组件库往往只关注后者，但是其实前者更加重要

在能实现甲方的需求前提下，约束的树立会让团队对某一问题形成一个固有的解决方案，这个使用过程会促成惯性的产生

同时，这个惯性一旦建立，就能促成两个结果：

• 弥合了人与人之间的差异

• 提高了交流效率（不单单是开发，还包括设计、产品、测试等一条工作链路上的相关人）

要知道的是，团队合作过程中，效率最低的环节永远是沟通，一个好的团队不是全员大神，而是做什么事情以一个整体，每个人步调趋于一致，这样效率才高～

具体实现

编写一个公共库需要考虑很多东西，下面主要分三点来阐述

逻辑的分割

• 避免一次性、不通用、没必要的封装

• 不允许出现相互跨级或交叉引用的情况，应形成明确的上下级关系

• 被抽离的逻辑代码应该尽可能的“独立“，避免变成”谁也离不开谁”

逻辑的封装

对于一个管理平台框架来说，宗旨是让开发少写代码、产品少写文档，不需要每次有新业务都要重复产出

对于开发来说，具体有两点：

• 大部分情况下，能拷贝下 demo 即可实现各类交互效果

• 小部分情况下，组件能提供其他更多的可能以满足特殊需求

封装过程中，仅暴露关键属性，提供多种可能，并且以比较常用的值作为“默认值”并明确定义，即可满足“大部分需求只需无脑引用，同时小部分的特殊需求也能被满足”

维护与开发

作为一个上游的 UI 库，要充分考虑下游使用者的情况

• 做到升级后保证下游大部分情况下不需要改动

• 组件的新增、删除、修改要有充分的理由（需求或 bug），并且要遵循最小影响原则

• 组件的设计要充分考虑日后可能发生的变化

未来展望

仅靠一个 UI 框架难以解决问题，对于未来的想法有分成三个阶段：

1. UI 库，沉淀稳定高效的组件

2. 代码片段生成器，收集业务案例代码

3. 页面生成器，输出有效模版

这里更多面向的是中后台项目的解决方案

总结

组件库输出约束和统一解决办法，前者通过抚平团队中个体的差异来提高团队的沟通效率，后者通过形成工作惯性来提高团队的工作效率

作者：tellyourmad
来源：juejin.cn/post/7063017892714905608

免战申明

本文不讨论两种缩进方式的优劣，只提供一种能够同时兼容大家关于缩进代码风格的解决方案

字符缩进，2还是4?

很久之前，组内开发时发现大家的tab.size不一样，有的伙伴表示都能接受，有的伙伴习惯使用2字符缩进，有的伙伴习惯4字符缩进，导致开发起来很痛苦，一直在寻找兼容大家代码风格的办法，今天终于研究出一种解决方案（不一定适用所有人）。

工具准备

1. vscode

2. prettierrc插件

解决方案

首先设置"editor.tabSize"为自己习惯的tabSize

设置tab按下时不插入空格"editor.insertSpaces": false

项目根目录下创建.prettierrc（可添加到.gitignore）,设置"useTabs": true

{
    "printWidth": 180,
    "semi": true,
    "singleQuote": true,
    //使用tab进行格式化
    "useTabs": true
}

设置展示效果"editor.renderWhitespace": "selection"

最终效果

可以看到，编辑器内设置不同的代码缩进，展示效果不同，但最终提交的代码风格一致。 （小缺陷：对于强制要求使用空格代替tab的情况不适用）

作者：断律绎殇
来源：juejin.cn/post/7095001798120833061

提到大文件上传，在脑海里最先想到的应该就是将图片保存在自己的服务器（如七牛云服务器），保存在数据库，不仅可以当做地址使用，还可以当做资源使用；或者将图片转换成base64，转换成buffer流，但是在javascript这门语言中不存在，但是这些只适用于一些小图片，对于大文件还是束手无策。

一、问题分析

如果将大文件一次性上传，会发生什么？想必都遇到过在一个大文件上传、转发等操作时，由于要上传大量的数据，导致整个上传过程耗时漫长，更有甚者，上传失败，让你重新上传！这个时候，我已经咬牙切齿了。先不说上传时间长久，毕竟上传大文件也没那么容易，要传输更多的报文，丢包也是常有的事，而且在这个时间段万不可以做什么其他会中断上传的操作；其次，前后端交互肯定是有时间限制的，肯定不允许无限制时间上传，大文件又更容易超时而失败....

一、解决方案

既然大文件上传不适合一次性上传，那么将文件分片散上传是不是就能减少性能消耗了。

没错，就是分片上传。分片上传就是将大文件分成一个个小文件（切片），将切片进行上传，等到后端接收到所有切片，再将切片合并成大文件。通过将大文件拆分成多个小文件进行上传，确实就是解决了大文件上传的问题。因为请求时可以并发执行的，这样的话每个请求时间就会缩短，如果某个请求发送失败，也不需要全部重新发送。

二、具体实现

1、前端

（1）读取文件

准备HTML结构，包括：读取本地文件（input类型为file）、上传文件按钮、上传进度。

<input type="file" id="input">
<button id="upload">上传</button>
<!-- 上传进度 -->
<div style="width: 300px" id="progress"></div>

JS实现文件读取：

监听input的change事件，当选取了本地文件后，打印事件源可得到文件的一些信息：

let input = document.getElementById('input')
let upload = document.getElementById('upload')
let files = {}//创建一个文件对象
let chunkList = []//存放切片的数组

// 读取文件
input.addEventListener('change', (e) => {
    files = e.target.files[0]
    console.log(files);
    
    //创建切片
    //上传切片
})

观察控制台，打印读取的文件信息如下：