技術文章配圖指南

技術文章配圖指南

原文連接： 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 的源文件，其中包含了這篇文章中的一些插圖；若是有意願的話，相信從這個源文件開始你就能夠構建本身的規則了，也但願各位讀者可以從這篇文章中有所收穫並遇到和我同樣的問題，而我也能從相同的問題中解脫（不太可能）。