技术文章配图指南

技术文章配图指南

原文连接： https://draveness.me/sketch-and-sketch

这多是一篇不少博客的读者都期待的文章，我最终仍是决定说一说『如何为技术文章配图』这一话题，过去的几年一直都有很是多的读者在博客、微博和公众号下面提出这样的问题 —— 『你的图是用什么工具画的？』，对于这种问题我我一直都不多回复，一方面是由于我在博客下面其实已经写明了画图工具：

本做品采用知识共享署名 4.0 国际许可协议进行许可。 转载时请注明原文连接，图片在使用时请保留图片中的所有内容，可适当缩放并在引用处附上图片所在的文章连接，图片使用 Sketch 进行绘制。

另外一方面，我不认为工具在帮助咱们配图时起到了决定性的做用，不管是使用 Photoshop 仍是 OmniGraffle 甚至是其余的工具都能达到彻底相同的效果，更加剧要的实际上是咱们对于制图规则的思考并造成一套自恰的体系，这篇文章就会分享一下做者在过去的几年中是如何完成这一套制图规则的。

概述

在理解做者对制图规则的思考以前，我想先简单分享一下最开始写博客而且分享一些经验和知识背后的缘由，这对于做者制图规则的造成起着比较重要的做用；国内的大多数技术博客（包括 CSDN 在内的一众平台）并无提供逻辑清晰、排版合理而且足够优雅的内容，不少博客对于内容的排版和设计很是糟糕，做者在查询到国内的资料时总有一种读不下去和不忍直视的感受，因此想输出一些在内容和排版上都相对优质的内容，而图片做为一种可以承载大量信息的媒介和博客的重要一个组成部分天然也要作到足够美观和清晰。

从开始写博客、画图到今天也有 五、6 年的时间了，在这个过程当中我也不断地完善了对制图规则的设计，其中有几个准则是很是重要的：

1. 图片必须足够美观而且清晰地传达想要表现的内容；

   1. 是技术博客中出现图片的意义；

2. 图片必须可以在短期内实现量产，不影响写做的效率；

   1. 博客中的所有图片都是在写做的过程当中一一绘制的，而不是最后统一完成的，因此会但愿画图的时间能够尽可能短，一旦画图的时间超过过长，那么整个思路就会被打断；
   2. 博客的内容和逻辑相比于图片更加剧要，做者不但愿在上面花费过长的时间；

3. 图片须要保证风格上的一致性，不会显得很是突兀；

   1. 图片的风格和配色对于做者来讲就是签名，造成统一的风格以后会给读者留下比较深的印象；

这些准则也是做者这么多年总结下来的，也是在整理我的制图规则时遵循的一些指南，在文章的剩余部分，你会看到做者在对于制图方法和风格的变化和演进。

演进

博客中图片的风格其实也不是一开始就像今天这样的，如今博客中的大多数图片都会使用使用 Sketch 进行绘制，图片的风格很是统1、配色也高度一致：

不过在刚开始为博客制做流程图的时候还会使用 OmniGraffle、Paper 等工具，到目前为止，除了 Sketch 和 LucidChart 以外的工具做者也都再也不使用了，博客上绝大多数的图片都是 Sketch 绘制的。

OmniGraffle

刚开始使用制做插图时，做者还会使用 OmniGraffle 这样的工具，它提供的功能其实比较强大，绘制流程图、时序图也很是方便，若是你对这个工具很是熟悉，也比较推荐使用它画图。

做者对于这个工具并非特别熟悉，使用了一段时间仍是以为没有 Sketch 来的顺手，因为其自己的目的就是绘制流程图、UML 图，因此在设计上会对一些样式作一些限制，若是以为遵循这套限制是能够接受的话，使用 OmniGraffle 其实会有很是大的优点，可是做者更但愿减小工具的限制，因此最终仍是选择放弃了它。

Paper

除了 OmniGraffle 以外，在一两年前做者还会使用 Paper 这种手绘的工具画图，使用 Paper 为博客画插图实际上是一件比较耗费时间和精力的事情，可是这种风格的图片确实很是有辨识度，做者在 Redis 和 I/O 多路复用 中就使用这种方式绘制插图：

虽然手绘的插图很是有辨识度而且 Paper 默认的风格其实也比较美观，可是这种类型的插图做者没有办法进行『量产』，并且每一张图片都须要消耗比较多的时间，图片的修改过程也比较麻烦，因此做者最终放弃了这种方法，不过手绘的方式确实是一种不同的体验。

除了这种图片须要较多时间、没法量产以外，前期的设备投入其实也比较大，若是想要使用 Paper 进行画图，iPad 和 Apple Pencil 基本上是必需品，若是不是特别热衷于手绘的读者并不建议使用这种方式。

LucidChart

LucidChart 其实就是用于绘制 UML 图、流程图的商业软件，它其实就是 SaaS 版本的 OmniGraffle，可是与 OmniGraffle 相比，它提供的默认配色和样式其实看起来很是美观，哪怕是以前没有经验的人也能够比较容易的画出优雅的流程图，详解 Kubernetes DaemonSet 的实现原理 中的图片就都是经过 LucidChart 进行绘制的：

然而 LucidChart 实际上是收费软件，免费版限制了能够保存图片的最大数量，做者购买了最低价格的套餐，一年的成本大概是 60$ 左右，价格相对来讲仍是比较贵的，不过很是适合经验较少的博主。

国内其实也有一些比较相似的服务，例如 ProcessOn，可是它们提供的一些样式和设计在做者看来相对 LucidChart 仍是有必定距离，没有达到做者心中对于图片样式要求的那根线，因此也不是特别推荐使用。

Sketch

最后要介绍的就是目前做者最常使用的工具 Sketch 了，相对于 Photoshop 来讲比较简单，它的场景也并非对图片进行处理，更偏向于一个 UI 设计工具，最开始使用 Sketch 也是做者的一个设计师朋友推荐的，不过目前来看 Sketch 其实已经成为了比较经常使用的设计工具。

Sketch 对于 UI 设计是很是友好的，它也提供了很是多的插件，相比于更专业的 Photoshop 也没有那么复杂，使用它的一些最基本功能就完成高度定制的插图，做为一个相对来讲比较专业而且自由的工具，做者目前在平常工做中常常会使用 Sketch 来处理和创做一些图片和插图。

画图

在这一节中，做者将介绍为技术博客绘制图片时总结的一些经验，但愿帮助各位读者找到本身的制图风格，为技术文章绘制图片和使用 PS 修改图片、为 App 绘制 UI 设计图是彻底不一样的，技术文章的配图主要做用仍是为了辅助说明内容，图画的再好看若是不能很好地解释问题都没有太多的做用，相比于图片的样式，咱们应该更加关注图片的内容是否清晰和简单。

内容

正如咱们上面所介绍的，图片的内容是配图时相当重要的，做者在一个问题太过复杂或者连续的文字过多时，就会选择为文章插入适合的图片，内容做为博客中插图的核心，咱们须要清楚地知道须要表达什么，做者将博客中的图片简单的分红了如下三类分别用于描述和展现不一样的内容：

1. 用于展现多个平等的概念时；
2. 用于描述模块以及概念之间的关系时；
3. 用于描述特定场景下概念的特性时；

在须要展现某个问题的多个方面、多个缘由或者阶段等处于相同层次的概念时就会使用以下所示的图片：

这张图片介绍了选择版本控制系统时应该关注的三个特性：分布式、性能和可靠性，使用列表的方式也是没有问题的，这只是做者的配图习惯，而你在这篇文章稍微靠前的部分中也会看到用于展现绘图工具的插图，这些图片的内容类型都是类似的。

除了展现概念的配图以外，做者还会使用以下所示的图片来展现不一样概念或者模块之间的关系，流程图、架构图等类型的图片都会被做者归到这一类中：

上述图片展现了在分布式的版本控制系统中，各个仓库之间的树形结构，图中使用不一样的颜色将不一样仓库在树中的高度作出了区分，这种图片可以很好地帮助读者理解各个模块之间的关系，咱们在 LucidChart 一节中分享的图片其实也属于这种类型的图片，只是使用的工具不一样：

除了这两种比较常见的插图类型以外，做者在遇到一些特殊问题时也会选择经过图片帮助读者理解问题，例如 为何 DNS 使用 UDP 协议 中就使用了以下所示的图片：

这张巨型图片的主要做用就是帮助读者理解 DNS 协议使用 TCP 或者 UDP 获取域名解析时所须要传输数据的大小，经过这张图片咱们可以比较直观的了解不一样协议在处理 DNS 协议时在数据方面的差异。

样式

图片的内容是它的核心价值所在，而图片的样式是决定图片是否『优雅』的关键，内容和样式之间的关系，就是 Web 前端中 HTML 和 CSS 的关系同样，咱们在这一节中就详细介绍做者对于博客中图片样式的一些约定。

配色

图片的配色其实很是重要，它决定了整个图片从第一眼看过去给人的感受，若是一个博客的配色你使用了很是长的时间，这也会成为你的标志。

每次看到其余博客中有相同配色的图片时，都会点进去看一下，大多数博客的博主都会把图片上的水印去掉而且不加引用，对于这种行为做者也很少评论，我只是但愿各位读者在使用图片时可以在图片上或者文章末尾增长引用。

做者在最开始画图时都会使用不一样的配色方案，可是大多数的配色若是长时间使用而且天天接触确实会有必定的审美疲劳，这时就会选择进行更换，你能够在经过下面的连接在历史的博客中查看做者使用过的配色方案：

• MySQL 索引设计概要
• 浅谈 MVC、MVP 和 MVVM 架构模式
• 使用 ASDK 性能调优 - 提高 iOS 界面的渲染性能

你能够看到做者在三年前使用的配色和画图方式与今天彻底不一样，这也是做者在实践的过程当中不断进行的修正，关于配色选择能够经过一些在线的网站获取，你可使用 Coolors 这一服务生成你的配色，做者以前就是用过这一服务，选择配色时必定要使用相对较为和谐的配色，至因而否和谐就依赖各位读者本身的审美了。

图片长宽

不少平台其实会限制博客的头图或者封面的长宽比例，好比微信公众号，这种时候咱们就只能接受平台的设定，不过对于其余图片的长宽，咱们只须要注意两个比较关键的问题：

1. 保证图片的宽度必定，长度不要太长；
2. 保证图片的大小被合理利用；

由于大多数人在阅读博客时都会使用显示器，这个时候过长的图片会影响显示效果，极可能一页没有办法展现所有的内容，这会很是影响阅读的体验，因此咱们能够固定图片的宽度，目前做者博客的图片宽度都是 1200px，这个值的选择与使用的平台和博客引擎都有关系，各位读者能够按需选择。

对于一张图片天然是越清晰越好，可是大图片会消耗较多的下载资源，若是使用 CDN 服务来加速图片的分发，这其实会影响博客的运维成本，你的支出会与博客的访问量成正比，因此选择的时候也应该量力而行。

字号

接下来咱们简单介绍一下字号的选择，对于字号大小的选择，我只能说要根据状况进行，不过做者通常会遵照如下的两个规则（在宽度为 1200px 的图片中），若是图片的大小改变，字号也会相应增减：

• 图片标题的字号 31px；
• 图片非标题的字号 18~20px；

固然咱们不能排除一些极端的状况，好比文字过长或者过多，遇到这种问题时会首先考虑减小文字的数量和长度，若是没法解决再缩小字号，保证图片中文字的正常显示。

圆角

圆角实际上是一个很是有意思的设计，做者在图片中基本不会使用直角的矩形，出如今图片中的形状都是圆形或者圆角矩形，因此对于圆角矩形也须要选择合适的圆角。根据历史的一些经验，做者通常会选择 15px 如下的圆角，尽量地保证圆角不会太大也不过小，看起来相对比较柔和。

总结

但愿在这篇文章以后不会有人再问『你的图片是用什么画的』，由于使用什么工具并不重要，以前微博上有一个评论我以为说得特别对也特别好：

画图的工具并不重要，重要的实际上是你应该如何造成本身的规则体系，想要为博客配图并非一件困难的事情，比较困难的是长期坚持而且常常思考，对本身造成的规则不断改善，最终就必定可以作好。

假如你读到这里而且想要得到这篇文章中的 Sketch 文件，能够关注『真没什么逻辑』公众号并回复 Sketch，你会获得一份 Sketch 的源文件，其中包含了这篇文章中的一些插图；若是有意愿的话，相信从这个源文件开始你就能够构建本身的规则了，也但愿各位读者可以从这篇文章中有所收获并遇到和我同样的问题，而我也能从相同的问题中解脱（不太可能）。