从零开始搭建一个前端资源自动化构建发布系统(中)

前言

接上篇从零开始搭建一个前端资源自动化构建发布系统(上),本来想写一个长篇,这个世界好玩儿的东西太多,前段时间在干别的,上一篇在我的草稿箱躺了很久,所以分成了多篇。

上篇说到提交代码要进行构建和发布,前提是分支或者tag格式满足条件,但是不能不分青红皂白直接构建和发布,需要做一些检查。

构建前的检测

  1. 检测当前group是否开通了发布权限,这个是为了清楚的知道哪些用户在使用,方便以后有变更能清晰的知道应该通知哪些人。

    阅读全文 »

从零开始搭建一个前端资源自动化构建发布系统(上)

前言

前端在工程化这条路上已经走了很远了。我用了约两周的时间写出了一个构建发布系统,包括研究方案和解决问题,技术的世界就是这么神奇,想想很简单,动起手来才知道有坑。技术选型当然是JavaScript,放在Node.js这个runtime上执行。

之前写了使用gitlab ci实现前端资源自动发布,本文是算是第二季,所以根本就不是从零开始,标题党了一下。

好用的发布系统应该是什么样子的。

  1. 提交代码能自动构建并且部署到测试环境。
  2. 打tag可以自动构建并将静态资源发布到CDN,技术同学把对应的入口页面或者版本号拿去发布就可以了。

好处

  1. 可以省去技术或者测试同学去干一些重复的活。提交代码不算,这个现在来看必要的。
  2. 每个版本都保留了tag。我们应该为每个版本保留一个tag,这个是不应该省的。
  3. 将权限校验转嫁给了gitlab,因为你没权限提交不了代码嘛。

    阅读全文 »

使用gitlab ci实现前端资源自动发布

描述

web端的特点是灵活,随时可上线。带来的问题就是上线重复次数特别多,这个需要简化。

现在很多公司在内网搭起了自己的gitlab。

如何能省事儿呢?代码提交后依靠gitlab的ci来自动build代码并部署是希望达到的效果。毕竟我现在提交代码大部分时候就两条命令。

$ gcam <msg>

$ gp

这是用了Oh My Zsh 的git插件的效果。

可以做这样一个约定,提交代码到gitlab,如果提交的分支是一个特殊格式的分支名那么静态资源发布系统自动拉取代码build,并且将build的结果发布到日常环境供测试同学来使用。如果是打一个特殊格式的tag那么自动build发布到CDN。

阅读全文 »

前端性能优化(五)为啥echarts渲染静态数据也会占用很高的CPU

前言

本文没有太多技术细节,写一些算是常识的东西。

背景介绍

接前一篇 前端性能优化(四)报价密度性能优化及工作机会推荐(纯javascript高频数据处理性能优化),还是这次优化。

正文

有发现页面在没有任何数据推送的时候依然占用了百分之七八的CPU。

echarts占用资源多是出了名的,没想到可以这样多。细细研究是zrender(echarts使用的渲染引擎)中requestAnimationFrame在不停的刷。

做了一个简单的例子,如下。

function step () {
requestAnimationFrame(step)
}
requestAnimationFrame(step)

阅读全文 »

前端性能优化(四)交易报价密度性能优化(纯javascript高频数据处理性能优化)

背景介绍

报价密度是用来展示各档位报价数量的,需要在浏览器端做合并。比如报价2.9511的数量1.0200,报价2.9520的数量是1.0333,按照两位小数合并,如果是卖盘则合并结果为报价2.9600的数量为2.0533,如果是买盘则合并结果为报价2.9500的数量为2.0533。按照什么精度来合并用户可以自己选择。由于交易特别活跃,推送的非常频繁,需要在浏览器端做大量计算,直接的结果就是CPU非常高。

优化

我之前写了一篇前端加载优化的文章《前端性能优化(一)用一张图说明加载优化》 ,
@i5ting
狼叔看了之后说业务梳理更重要,确实是这样的,本次确实做了很多业务梳理方面的优化,原则当然是能不计算就不计算,能少计算就少计算。比如循环外就可以确定的值不要在循环内做计算。比如报价显示20档,当计算获得的数据足够显示时就不要再计算了。

因为场景特殊,这次在纯技术角度的优化所带来的收益也是非常多的,甚至可能超过了业务梳理。

一般来说浏览器端程序出现性能问题都是和DOM操作扯上关系,纯javascript出现严重性能问题是少见的。我至今也就遇到过两次,第一次是在大智慧做行情显示,推送频繁;第二次就是这次的报价密度,推送频繁。本文会主要说一些纯技术方面的优化点,有一些是本次做了的,有的是还没做的,优化无止境,一步一步来。

阅读全文 »

前端性能优化(三)聊聊HTTP/2带来的加载优化

那些年,我们使用HTTP1.1,我们忍受着巨大的网络延时,而同时我们的网页变得越来越复杂,我们需要加载的资源越来越大越来越多。

HTTP1.1如何加载资源

  1. 建立HTTP链接,由于HTTP是基于TCP的,所以必然要经过TCP的三次握手。
  2. 发送请求,TCP有慢启动的问题。
  3. 接收响应。
  4. 如果连接被双方认可是keep-alive的,那么后续请求可复用该连接发送请求。

对,这里面有一个问题,就是一个HTTP连接同一时刻只能处理一个资源的请求,处理完才可能处理下一个。

阅读全文 »

前端性能优化(二)通过一个实例聊聊DOM操作优化

DOM操作优化现在已经不是很受重视了,原因是有了virtual DOM,外加上浏览器自身的优化也越来越到位。

多年前我曾经做过一个表格,这个表格对性能要求非常高,踩过一些坑,不断优化,最后得到了比较好的结果。

一般来说表格用于展示数据,一次性渲染,数据是不会变的,而且还做了分页,如果这样那么无论怎么做都不会出大问题的。如果加一个条件呢,?每一个单元格每秒更新6次,屏幕可视区域有30条,怎么办?对,这是展示股票行情的实际需要。

该怎么做?当时年少不懂事,直接拿table写了一下,结果就是性能烂的不行,cpu跑满了,及其卡,卡到没法响应用户操作,甚至浏览器直接死掉了。究其原因就是使用js更新数据的时候会触发reflow,而且table会触发更多的reflow,我们一直在说js操作DOM慢,慢的原因也在于操作DOM会引发reflow。

那么都哪些情况会触发reflow呢?如下

阅读全文 »

程序员们,那些年吹过的牛逼都实现了吗?

有一部分程序员中的老司机,他们善于找各种借口,少干活,少背锅,多拿钱。但是,更多的程序员坦诚、直白、意气用事。

那些年吹过的牛逼都实现了吗?还是随风而去?

这个功能简单,一天就能搞完

程序员拿到一个新功能,心里暗暗发笑,这剧情我见过啊。于是脱口而出,这功能简单,一天就能做完,明天上线肯定没问题。

结果,眼看着到自己设定的截止日期了,还有一部分代码没有写完,怎么办?

阅读全文 »