JavaScript进度管理

更新日期: 2020-01-21阅读: 1.7k标签: 管理

前言

我们写程序的时候会经常遇到显示进度的需求,如加载进度、上传进度等。
最常见的实现方式是通过记录 已完成数量(loadedCount) 和 总数量(totalCount),然后算一下就能得到进度了。
这种方式简单粗暴,容易实现,但不好扩展,必须有个地方维护所有 loadedCount 和 totalCount。
本文将会基于上述实现方式,实现一种更容易扩展的进度管理方式。


问题

笔者在写 WebGL 应用,在应用预加载阶段需要计算加载进度。
加载的内容包括:模型资源、贴图资源、脚本资源等。
其中模型资源中又会包含材质资源,材质资源里面又会包含贴图资源。
画图来表示的话就是如下的结构:

+-------------------------------------------------------------+
|                                                             |
|  resources                                                  |
|                                                             |
|  +----------+   +-----------------+   +-----------------+   |
|  | script1  |   | model1          |   | model2          |   |
|  +----------+   |                 |   |                 |   |
|                 | -------------+  |   | -------------+  |   |
|  +----------+   | |model1.json |  |   | |model2.json |  |   |
|  | script2  |   | +------------+  |   | +------------+  |   |
|  +----------+   |                 |   |                 |   |
|                 | +------------+  |   | +------------+  |   |
|  +----------+   | | material1  |  |   | | material1  |  |   |
|  | texture1 |   | | +--------+ |  |   | | +--------+ |  |   |
|  +----------+   | | |texture1| |  |   | | |texture1| |  |   |
|                 | | +--------+ |  |   | | +--------+ |  |   |
|  +----------+   | | +--------+ |  |   | | +--------+ |  |   |
|  | texture2 |   | | |texture2| |  |   | | |texture2| |  |   |
|  +----------+   | | +--------+ |  |   | | +--------+ |  |   |
|                 | +------------+  |   | +------------+  |   |
|                 |                 |   |                 |   |
|                 | +------------+  |   | +------------+  |   |
|                 | | material2  |  |   | | material2  |  |   |
|                 | +------------+  |   | +------------+  |   |
|                 +-----------------+   +-----------------+   |
|                                                             |
+-------------------------------------------------------------+

这里有个前提:当加载某个资源的时候,必须保证这个资源及它引用的资源全部加载完成后,才能算加载完成。
基于这个前提,我们已经实现了一个 onProgress 接口,这个接口返回的进度是已经包含了子资源的加载进度的了。
翻译成代码就是:

class Asset {
    load(onProgress) {
        return new Promise((resolve) => {
            if (typeof onProgress !== 'function') {
                onProgress = (_p) => {  };
            }

            let loadedCount = 0;
            let totalCount = 10; // NOTE: just for demo
            let onLoaded = () => {
                loadedCount++;
                onProgress(loadedCount / totalCont);
                if (loadedCount === totalCount) resolve();
            };

            Promise.all(
                this.refAssets.map(asset => asset.load().then(onLoaded))
            );
        });
    }
}

既然有了这个接口,如果沿用全局维护 loadedCount 和 totalCount 的形式的话,处理起来其实挺麻烦的。
本文接下来要介绍的,就是一种变通的做法。


原理

基本思想就是分而治之。把一个大任务拆分成多个小任务,然后分别计算所有小任务的进度,最后再把所有小任务的进度归并起来得到总进度。
如下图表示:


+--------------------------------------------------------------------+
|                                                                    |
|                                                                    |
|   total progress                                                   |
|                                                                    |
|   +---------+---------+----------+----------+--------+--------+    |
|   | script1 | script2 | texture1 | texture2 | model1 | model2 |    |
|   |  (0~1)  |  (0~1)  |   (0~1)  |   (0~1)  |  (0~1) |  (0~1) |    |
|   +---------+---------+----------+----------+--------+--------+    |
|                                                                    |
|   model1                                                           |
|   +-------------+-----------------------+-----------+              |
|   | model1.json |      material1        | material2 |              |
|   |   (0~1)     |        (0~1)          |   (0~1)   |              |
|   +------------------------+------------------------+              |
|                 | texture1 |  texture2  |                          |
|                 |   (0~1)  |    (0~1)   |                          |
|                 +----------+------------+                          |
|                                                                    |
|   model2                                                           |
|   +-------------+-----------------------+-----------+              |
|   | model2.json |      material1        | material2 |              |
|   |    (0~1)    |        (0~1)          |   (0~1)   |              |
|   +------------------------+------------------------+              |
|                 | texture1 |  texture2  |                          |
|                 |   (0~1)  |    (0~1)   |                          |
|                 +----------+------------+                          |
|                                                                    |
+--------------------------------------------------------------------+

基于这个原理去实现进度,实现方式就是通过一个列表去保存所有资源当前的加载进度,然后每次触发 onProgress 的时候,执行一次归并操作,计算总进度。

var progresses = [
  0, // script1,
  0, // script2,
  0, // texture1,
  0, // texture2,
  0, // model1,
  0, // model2
];

function onProgress(p) {
    // TODO: progresses[??] = p;
    return progresses.reduce((a, b) => a + b, 0) / progresses.length;
}

但这里面有个难点,当触发 onProgress 回调的时候,如何知道应该更新列表中的哪一项呢?
利用 JavaScript 的闭包特性,我们可以很容易实现这一功能。

var progresses = [];
function add() {
    progresses.push(0);
    var index = progresses.length - 1;

    return function onProgress(p) {
        progresses[index] = p;
        reduce();
    };
}

function reduce() {
    return progresses.reduce((a, b) => a + b, 0) / progresses.length;
}

利用闭包保留资源的索引,当触发 onProgress 的时候,就能根据索引去更新列表中对应项的进度了。最后归并的时候就能计算出正确的进度了。
剩下的事情就是整合我们所有的代码,然后对其进行测试了。


测试

我们可以用下面的代码来模拟一下整个加载过程:

class Asset {
    constructor(totalCount) {
        this.loadedCount = 0;
        this.totalCount = totalCount;
        this.timerId = -1;
    }

    load(onProgress) {
        if (typeof onProgress !== 'function') {
            onProgress = (_p) => {  };
        }

        return new Promise((resolve) => {
            this.timerId = setInterval(() => {
                this.loadedCount++;
                onProgress(this.loadedCount / this.totalCount);
                if (this.loadedCount === this.totalCount) {
                    clearInterval(this.timerId);
                    resolve();
                }
            }, 1000);
        });
    }
}

class Progress {
    constructor(onProgress) {
        this.onProgress = onProgress;
        this._list = [];
    }

    add() {
        this._list.push(0);

        const index = this._list.length - 1;

        return (p) => {
            this._list[index] = p;
            this.reduce();
        };
    }

    reduce() {
        const p = Math.min(1, this._list.reduce((a, b) => a + b, 0) / this._list.length);
        this.onProgress(p);
    }
}

const p = new Progress(console.log);
const asset1 = new Asset(1);
const asset2 = new Asset(2);
const asset3 = new Asset(3);
const asset4 = new Asset(4);
const asset5 = new Asset(5);

Promise.all([
    asset1.load(p.add()),
    asset2.load(p.add()),
    asset3.load(p.add()),
    asset4.load(p.add()),
    asset5.load(p.add()),
]).then(() => console.log('all resources loaded'));

/**
  输出
  Promise { <state>: "pending" }
  
  0.2 
  0.3 
  0.36666666666666664 
  0.41666666666666663 
  0.45666666666666667 
  0.5566666666666668 
  0.6233333333333333 
  0.6733333333333333 
  0.7133333333333333 
  0.78 
  0.8300000000000001 
  0.8699999999999999 
  0.9199999999999999 
  0.96 
  1 
  all resources loaded 
 */

这种方式的优点是能避开全局管理 loadedCount 和 totalCount,把这部分工作交回资源内部管理,它要做的只是对大任务进行归并计算。

缺点也很明显,需要对 onProgress 接口进行一次统一。在已有项目中推进难度很大,所以比较适合新项目或者小项目去实践。

出处http://scarletsky.github.io/

链接: https://www.fly63.com/article/detial/7314

程序员的思考:一年管理成富翁,三年市场路路通,十年技术一场空

程序员的思考:在中国,做技术的出路非常有限。首先做技术需要跟对老板,其次做技术的要和老板有共同的价值观,再有最最重要的是需要有一个好的身体。

IIS和ASP的标题广告管理系统的详细介绍与使用

标题广告是Web上最常见的广告形式。本文介绍了一个基于IIS和ASP的标题广告管理系统,该系统支持广告客户和广告的管理,能够随机选择广告并生成显示广告的HTML代码

缺这项能力,做不了技术管理工作

大部分开发者工作三五年后,都能掌握所在岗位必须的知识、经验和技能,然而很多人接下来就陷入困境,左冲右突,无法加薪升职,一直停在第1层,三年五年过去了,八年十年过去了,可能都还停在1层的位置。

到底什么才是后台?

我们整天说着前端,客户端,后台。到底什么才是后台?前台(前端)后台,在英语中即:Front-End,Back-End。广义上的前端包括客户端(PC、Android、IOS等),后台即通常意义上的Server。

团队管理上的一点思考

团队的成长离不开成员的成长,一个稳定的学习环境对于成员的成长有很大的帮助,也有不少的成员是以这样的心态在工作的,特别是还没有太多工作经验的毕业生。满足成员成长的需求,会让团队富有激情

brew 安装详解

MacOS上的包管理工具。类似RHEL/CentOS上的yum或者Ubuntu上的apt-get一样。 前置条件:brew是ruby开发的,需要确认ruby是否已安装,缺省状况下是已经安装的。默认不安装cask 有需要的可以替换

组织和管理CSS

在项目开发的过程中,基于有限的时间内保质保量的完成开发任务无疑是一场挑战。在这场挑战中我们不但要快速处理自己的问题,还需要与别人协同合作,以避免两者之间的冲突。

如何统一前端项目的 Node 版本和包管理器?

成员机器 Node.js 版本不统一: 守旧派用 12.x、保守用 14.x、激进用 17.x。项目能否正常跑起来全凭天意,在没有 CICD 流水线加持本地 npm run build 的场景下线上风险可想而知。

React状态管理器Rematch的使用

Rematch是没有样板文件的Redux的最佳实践,没有action types、 action creators, 状态转换或thunks。Redux 是一个了不起的状态管理工具,由良好的中间件生态系统和优秀的开发工具支持。

基于vue3的后台管理UI框架

​对于前端来说,想快速构建一个后台管理系统界面,首先需要选择js框架,然后就要选择相应的UI框架。基于Vue3的优秀表现和良好的生态这里我们选择Vue.js作为js框架。

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!