通常来说，可视化的报表会以更高效率的方式将数据背后隐藏的信息传递给我们。通过一个简单的BarChart，我们就很容易对比某商品在第二季度中的销量差异；而通过一条简单的LineChart，则很容易看出员工平均工作时间在某个月份的分布。这些报表都或多或少与时间相关：随着时间的流逝，某项指标会因为各种各样的因素而产生变化。

另一方面，在某些领域，我们需要更高时效性的报表。比如产品的线上指标分析：有多少用户当前在线，主站的负载情况如何，有多少在线交易正在形成等等。此外，很多运维数据也希望有更高的实时性，比如目前服务器的负载如何，过去的5分钟的负载情况又是什么样子的等等。

• 对于细粒度的指标，数据量可能会很大
• 过了某段特定的时间段，数据的价值会骤降

比如上图是Mac上的CPU使用情况的实时报表，它展现了一段时间内的各个核上的计算负载。这些信息不断产生，有不断被丢弃，没有人关注一个小时之前的CPU占用，只要能展示出最近几分钟的就好。

基于这些特性，如何存取数据、如何分析度量结果、如何滚动历史数据等等都会遇到和其他图表不尽相同的问题。另外，由于实时数据的可视化与时间是强相关的 – 它本质上必须是一个动态的图表，这与其他的图表类型又有不同。我们在这篇文章中将会讨论这些问题，以及解决这些问题的常见方案。

对于实时数据，我们关注不同事件发生的次数，以及事件发生时持续的时长等。我们首先需要定义一些对象：

计数器涉及需要被记录次数的事件（通常是每发生一次，计数器加一/减一），这类数据的增长/减少规律比较固定，比如：

1. 下载文档中引用的CSS、JS
2. 将JS代码交给JS引擎执行
3. 根据Render Tree进行布局layout（为每个元素计算尺寸和位置信息）
4. 绘制（Paint）每个层中的元素（绘制每个瓦片，瓦片这个词与GIS中的瓦片含义相同）

使用Chrome的DevTools - Timing，可以很容易的获取一个页面的渲染情况，比如在Event Log页签上，我们可以看到每个阶段的耗时细节（清晰起见，我没有显示Loading和Scripting的耗时）：

应该注意的是，浏览器可能会将Render Tree分成好几个层来分别绘制，最后再合并起来形成最终的结果，这个过程一般发生在GPU中。

Devtools中有一个选项：Rendering - Layers Borders，打开这个选项之后，你可以看到每个层，每个瓦片的边界。浏览器可能会启动多个线程来绘制不同的层/瓦片。

你可以拖动滑块来看到随着时间的前进，页面上元素被逐步绘制出来了。我录制了一个我的知乎活动页面的视频，不过需要翻墙。

为了尽快的让用户看到页面内容，我们需要快速的完成DOM+CSSOM - Layout - Paint - Composite Layers的整个过程。一切会阻塞DOM生成，阻塞CSSOM生成的动作都应该尽可能消除，或者延迟。

在这个前提下，常见的做法有两种：

对于不同的浏览终端，同一终端的不同模式，我们可能会提供不同的规则集：

如果将这些内容写到统一个文件中，浏览器需要下载并解析这些内容（虽然不会实际应用这些规则）。更好的做法是，将这些内容通过对link元素的media属性来指定：

要给优秀的程序员下一个明确的定义无疑是一件非常困难的事情。擅长抽象思维，动手能力强，追求效率，喜欢自动化，愿意持续学习，对代码质量有很高的追求等等，这些维度都有其合理性，不过又都略显抽象和主观。

我对于一个程序员是否优秀，也有自己的标准，那就是TA对命令行的熟悉／喜爱程度。这个特点可以很好的看出TA是否是一个优秀的（或者潜在优秀的）程序员。我周围就有很多非常牛的程序员，无一例外的都非常擅长在命令行中工作。那什么叫熟悉命令行呢？简单来说，就是90%的日常工作内容可以在命令行完成。

当然，喜欢／习惯使用命令行可能只是表象，其背后包含的实质才是优秀的程序员之所以优秀的原因。

是一个完整的CSS属性列表，其中包含了会影响布局或者绘制的CSS属性，以及在不同的浏览器上的不同表现。 了解浏览器的工作方式，对我们做前端页面渲染性能的分析和优化都非常有帮助。为了高效而智能的完成渲染，浏览器也在不断的进行优化，比如资源的预加载，更好的利用GPU（启用更多的线程来渲染）等等。 另一方面，我们在编写前端的HTML、JS、CSS时，也需要考虑浏览器的现状：如何减少DOM、CSSOM的构建时间，如何将耗时任务放在单独的线程中（通过WebWorker）。

上面这段groovy脚本定义了三个Stage，每个Stage中分别有自己的命令，这种以代码来控制的方式显然比GUI编辑的方式更加高效，自动化也编程了可能。

是一个功能强大的监控工具，不过其背后的理念倒是很简单：

• 将数据渲染成图，并定期刷新

用户只需要将数据按照一定格式定期发送给Graphite，剩下的事情就交给Graphite了，比如它可以消费这样的数据：

第一个字段表示数据的名称，比如此处instance.prod.cpu.load表示prod实例的CPU负载，第二个字段表示数据的值，最后一个字段表示时间戳。

这样，Graphite就会将所有同一个名称下的值按照时间顺序画成图。

默认地，Graphite会监听一个网络端口，用户通过网络将信息发送给这个端口，然后Graphite会将信息持久化起来，然后定期刷新。简而言之，只需要一条命令就可以做到发送数据：

date +%s会生成当前时间戳，然后通过echo命令将其拼成一个完整的字符串，比如：

然后通过管道|将这个字符串通过网络发送给graphite.server这台机器的2003端口。这样数据就被记录在graphite.server上了。

如果我们要自动的将数据每隔几秒就发送给graphite.server，只需要改造一下这行命令：

1. 每隔5分钟做重复一下1-4

获取CPU的load在大多数系统中都很容易：

• -A表示统计所有当前进程

这样可以得到每个进程占用CPU负载的数字：

下一步是将这些数字加起来。通过awk命令，可以很容易做到这一点：

比如要计算1 2 3的和：

通过管道可以讲两者连起来：

看来还不错，有个这个脚本，通过crontab来定期调用即可：

当然，如果使用等强调UI的工具，可以很容易的做的更加酷炫：

想想用GUI应用如何做到这些工作。

最早的时候，有一个叫做mpg123的命令行工具，用来播放MP3文件。不过这个工具是商用的，于是就有人写了一个工具，叫mpg321，基本上是mpg123的开源克隆。不过后来mpg123自己也开源了，这是。

将我的所有mp3文件的路径保存成一个文件，相当于我的歌单：

然后我将这个歌单交给mpg321去在后台播放：

这样我就可以一边写代码一边听音乐，如果听烦了，只需要将这个后台任务切换到前台fg，然后就可以关掉了：

综上，优秀的程序员借助命令行的特性，可以成倍（有时候是跨越数量级的）地提高工作效率，从而有更多的时间进行思考、学习新的技能，或者开发新的工具帮助某项工作的自动化。这也是优秀的程序员之所以优秀的原因。而面向手工的、原始的图形界面会拖慢这个过程，很多原本可以自动化起来的工作被淹没在“简单的GUI”之中。

最后补充一点，本文的关键在于强调优秀的程序员与命令行的关系，而不在GUI程序和命令行的优劣对比。GUI程序当然有其使用场景，比如做3D建模，GIS系统，设计师的创作，图文并茂的字处理软件，电影播放器，网页浏览器等等。

应该说，命令行和优秀的程序员之间更多是关联关系，而不是因果关系。在程序员日常的工作中，涉及到的更多的是一些需要命令行工具来做支持的场景。如果走极端，在不适合的场景中强行使用命令行，而置效率于不顾，则未免有点矫枉过正，南辕北辙了。