閱讀類產品如何做好深色模式？來看起點讀書的實戰經驗！

前言

Android Q 和 iOS 13 為我們帶來了 Dark Mode，這已經不是什么新鮮事了，很多團隊都已經擁有了各自適用的解決方案，起點讀書的 Dark Mode 設計解決方案也終于從幕后開始進入到項目落地環節，從時間跨度上來講已經大半年過去了。這段時間經歷了各產品解決方案的轟炸與洗禮，我們又結合起點本身的產品定位與結構特點，在此背景下一套融合 Dark Mode 和主題皮膚設計的解決方案應運而生。

本文會重點聚焦設計落地執行的解決方案，視覺解決方案每個產品都有自身不同特點，且 Android 和 iOS 官方都各自擁有符合各自平臺的設計解決方案，因此不在此一一贅述。

閱讀類產品如何做 Dark Mode

在落實方案之前我們首先要搞清楚，Android、iOS 各自所理解的 Dark Mode 到底是什么？如果將 Dark Mode 與夜間模式劃等號，這從意識形態上已經出現了疑問。因為起點本身屬于在線閱讀平臺，對于頁面的可讀性的要求非常嚴謹。YUX內部進行過多次深入討論，將這兩種模式嚴格的區分開。

1. 概念區分與融合

Dark Mode （深色模式）是在日夜間都可以使用的一種裝扮主題，需要滿足在日夜間都可以無障礙使用；而夜間模式會比較聚焦于昏暗環境下的閱讀體驗，是大部分 App 為了用戶在昏暗環境下有良好的使用體驗專門定制的模式這叫做夜間模式，因此為了不給用戶過多的理解負擔，我們將這兩個概念進行了部分融合。（如下圖）

當用戶開啟 Dark Mode 開關后，非閱讀場景不需要用戶過于沉浸， 信息的可讀性和內容的高對比度可以讓信息更加高效的傳達，因此為了滿足用戶不同場景下的使用體驗，非閱讀場景會使用偏向 iOS 的 Dark Mode 解決方案；而在閱讀場景下，為了滿足用戶的長時間閱讀的舒適要求，因此會使用低對比度的夜間模式的解決方案。

在谷歌和iOS的官方解決方案中，對主要文字信息表達部分的對比要求大致范圍至少16:1~7:1之間，而對最低文本的對比度要求是4.5:1，因此我們基于此參考，最終將兩種不同場景的對比度劃分為相應可適應區域。

2. 技術條件決定開發成本

起點本是 Android、iOS、Web 混合的模式，因此設計方案需要能兼顧三端。了解清楚當前產品的結構形態是做 Dark Mode 的前提條件，如組件覆蓋率、產品復雜度、技術執行能力等；這幾個條件對 Dark Mode 的工作量影響是比較大的，所以在前期最好能評估好這些條件的實際情況。

基本要素

理論上做 Dark Mode 就是做顏色/素材映射關系。這個與做主題設計的理論概念是完全一致的，因此我們將兩個項目做了合并處理，從設計方案中將 Dark Mode 當成主題來作為解決方案的基礎。既然概念不分家，那么在規則制定上會更多的去考慮在主題模式下的設計表現。

1. 頁面層級

整體結構上我們將App的頁面劃分為4個層級，背景層、UI層、懸浮層、彈出層，每個層級還會有自己的子集，我們按照從下至上的順序來介紹。

背景層對于主題來說背景承載了兩種表現形式：純色、背景圖，因此在處理背景顏色映射的時候就需要考慮到該如何支持兩種主題的設計關系。

UI 層主要是用于放置所有界面元素、組件的層級。UI 層是顏色分類的基本依據，所以我們如果將 UI 層再進一步劃分的話，大致會包含如下內容，背景、文本、元素（圖標）、圖片、圖片上層等。

懸浮層主要包括例如導航欄、工具欄、輸入欄、懸浮按鈕等都屬于懸浮層元素，通常我們定制主題皮膚的時候，都是對懸浮層的元素進行素材改造和氛圍渲染。

彈出層顧名思義，就是原本不屬于本頁面，觸發一定條件后在本頁面展示的彈出層級，例如我們熟悉的彈窗、半彈層、Action Sheet、Toast 等。彈出層的背景色如何制定在主題皮膚下如何表現，會使用到我們與研發團隊共同合作制定的智能取色系統。

通過對層級的劃分，我們大致了解了不同層級在適配主題的時候所承載的主要功能，這幫助我們在設計皮膚主題的時候可以快速帶入頁面、明確色彩關系。

2. 顏色

顏色我們分三個部分來解析，分別是顏色分類、主題分類、映射方案。

顏色分類

頁面層級的劃分幫助我們更好的管理顏色，通過此方法我們為每一組顏色打好標簽，通過對頁面拆解、層級的剝離得到以下比較符合起點業務場景的標簽分類，請注意這里的分類不區分色彩傾向，只以功能、頁面、層級特點為分類基礎。

舉個例子，Primary 對應的就是起點的主色紅色系，這個標簽屬于相同色系；而 OnImage 對應的是出現在圖片上的顏色，這個標簽就屬于多個色系顏色；他們各司其職，通過當前的類別劃分已經基本上滿足起點讀書的設計需求，可應對多種場景變化。

但是光看這組標簽還不足以幫我們理清思緒，通過判斷該顏色是否是影響 App 主題的關鍵因素，將這些標簽分為有映射、無映射、自定義色這三個類別來劃分。（如下圖）

同為淺色主題（關于主題區分下文會做介紹）的前提下，有映射關系的顏色是指這些顏色在 App 主題中都會有自己固定的色彩映射值，無需我們主動調整，比如 Outline 這個顏色在所有淺色主題中會有自己固定的映射值，不會隨著主題的變化而產生改變。

無映射關系是指該顏色不會受主題的影響而產生改變，比如 OnImage 這個顏色就不受主題的影響，它在任意場景下均為相同顏色。

自定義色就是影響主題調性的顏色了，通常我們講設計主題其實首先就要對這個幾個顏色進行調試，前文提到的輕主題就可以通過調整這個分類的顏色就可以快速生成一款主題。

主題分類

剛剛我們提到顏色分類的時候說過在淺色主題前提下，色彩映射可分為三類，那么我們是如何判斷深淺主題的呢？深淺主題又該如何做分類？簡單一句話概括就是淺色主題就是白底黑字/面，深色主題就是黑底白字/面；如果我們以「底（即背景）」為參照物，那么淺色主題對應的就是用淺色背景的主題，而深色主題對應的就是用深色背景的主題。

我們結合顏色分類和主題分類，就可以總結一個結論，同一個主題分類下的顏色映射除去自定義色以外都是相同的。

那么我們如何區分深淺呢，我們提出了兩種解決方案，第一種也是最簡單的方法，那就是人為的區分，設計師自己人為的劃定主題類別；第二種更偏向于智能化一點，當我們上傳了一張 Background 圖片或者自定義一個顏色作為背景時，我們可通過對背景取色，取其主色并通過對主色 RGB 值分析來區分所取顏色的深淺，通過深淺自動匹配不同的主題映射方案（如下圖）。未來我們將會對兩種方案進行整合，純色背景的主題智能化處理，圖片作為背景的主題，依然需要設計師輔助區分。

而剛剛我們所取的主色就可以當做我們的 SheetBackground 來使用，而 Primary 顏色我們可以通過算法匹配出一個相應的主色（算法大意：取背景色的HSB，色相值H，然后自定義S、B的數值就可以匹配出我們需要的顏色）或者自定義一個主色亦可。

映射方案

在具體落實方案上還有很多細節點，比如我們在 Background 顏色/背景上通常會覆蓋一層黑色半透明，主要是因為特定情況下該顏色會與 SheetBackground 產生交集。

在日常的UI設計中往往還會遇到 Design Token 顏色不夠用，還常常用到其他顏色的情況，雖然是小概率事件，但我們依然需要將其納入到設計流程中，為避免雙方（設計與研發）使用直接的 RGB 色值，我們又制定了一套色碼表，色碼表收錄了包含 Design Token 的所有顏色，并且有規律可循，這樣我們就可以保證與研發的雙向約束。以下為起點的 Design Token 命名映射表單以及色碼表一覽。

關于同色不同標簽，也同樣擁有很多注意點，比如白色 #FFFFFF 這個顏色，在 Background、SheetBackground、NavBarBackground、Surface、OnImage 中都有出現，但是各自的顏色映射關系都有點不太一樣，在 Background 中需要映射背景或者自定義顏色，在 SheetBackground 中需要依托取色或者自定義，在 NavBarBackground 中又是全透明的映射關系，而在 Surface 是一套固定的映射關系，出現在 OnImage 卻又不需要映射。

3. 素材的適配方案

將端內的素材按照類型分大致可分為五類：單色圖標、多色圖標、缺省圖、氛圍圖片/動畫文件、書封/UGC圖片。對于不同的素材需要有不同的處理方案。

單色圖標因為使用的是 Svg，所以只需要進行著色處理即可。

多色圖標以金剛區為例，通常產品金剛區的圖標來源于本地素材和服務端下發這兩種場景，如果是本地素材，可以內置兩套素材；而服務端下發的圖片素材，在無法基于 Dark Mode 自動替換的前提下，只能使用一套基礎圖片。然而客戶端對服務端下發的圖片的可編輯性是非常有限的，目前僅能對單色圖片做著色處理；眾所周知金剛區的圖標風格都比較強烈且偏個性表達，因此如何解決不同皮膚下的金剛區圖標風格問題，我們嘗試了一下有效解決方案：

結構拆分法，以下圖為例，將原圖標拆分為上下兩層結構，不同主題下客戶端僅需對圖標底部背景色進行 Token 綁定即可。這種解決方案的下的產品主題皮膚更加沉浸、風格更加統一。

一套圖解決思路，將原本設計調整為可適應多場景的風格；這樣的解決方案好處在于給了設計師更多的發揮空間，可以在金剛區嘗試不同的設計風格，同時還可以拓展動態圖標的運用，這些自定義操作都不會受限于客戶端的展示形式。

缺省圖提供雙風格的樣式即可，或者調整風格為多場景通用的樣式。

氛圍圖片/動畫文件通常是裝飾作用的素材，因此大部分不需要進行映射處理。

書封/UGC圖片遵照應對多場景使用均可使用的原則，因此不對圖片做過透明度/遮罩/對比度等處理。

接入方式

1. 如何保證設計準確性

我們在構建組件庫時需嚴格按照顏色的使用標準和標簽來用色，做到所有顏色均從 Design Token 中調用；日常版本迭代中設計師也需要遵守用色標準，無需映射的顏色或者特殊用色也可以從色碼表中獲取。當然只要是人為進行的操作就肯定會有出錯的情況，為此我們又借助 Figma 中的 Themer 插件可以做到顏色一鍵切換的效果，可以幫助我們快速檢索用色錯誤的元素。

2. 研發接入方式

Android、iOS、Web 接入的前提條件是已經擁有比較高的組件覆蓋率；通過與研發同學的通力合作，我們搭建各端的 Design Token，這其中包含顏色、字體、陰影等視覺屬性。通過SDK的方式管理 Design Token，確定好哪些映射關系可以統一替換，哪些是需要自定義下發的。

以安卓為例，初始化的時候有3套基本 Token 的映射，分別是 Dark Mode、深色皮膚、淺色皮膚。當切換主題后會判斷主題類型并為之匹配不同的映射方案，隨后會跟隨皮膚主題色來改變部分影響皮膚調性的 Token 映射。因為深色皮膚和淺色皮膚模式下部分顏色來自取色或自定義下發的 Token 文件，所以在 Dark Mode 模式下需用借用技術手段Hook 住此類顏色，從 Apk 的資源管理器中取得我們預制好的 Token 即可。

這樣的接入方式，無需對整個 App 進行頁面一對一的適配調整，對設計師來說要求更加的嚴格了，需要更加工程化的思維來設計頁面，但是降低了我們的溝通成本。Design Token 同時還讓 App 兼具了換膚的功能，對于做設計賦值都是比較好的方式；對于研發同學來說這將大大的降低了接入 Dark Mode 所帶來的繁重工作量（對復雜產品來說，工作量確實比較繁重），同時在保證設計還原上面也能得到比較顯著的提升。

客戶端與系統的解耦方式

Dark Mode 目前在iOS13+系統以及少部分安卓手機才擁有相應的系統開關，基于安卓復雜的生態系統，我們對安卓暫時采取了比較一刀切的設計方案，暫時不跟隨系統；iOS則以13作為比較明確的界限，iOS13 以下用戶和安卓用戶在客戶端內操作即可實現兩種模式的切換（如下圖）。

而在iOS13+系統中，因為同時存在系統開關、端內開關兩種模式；而端內開關不僅僅只有深色模式，還需保留相應的皮膚拓展能力，因此不能一刀切的直接與系統開關做綁定關系；此時則需要另外增設一個是否跟隨系統的開關。那么當三個開關擺在我們面前，復雜三角關系就形成了?；诖?if 的情況比較復雜，具體處理方式可查看下圖。

當用戶開啟不同開關時，系統會根據三個開關的不同狀態匹配相應的結果。（如下圖）

經過多個產品線小伙伴的討論研究，最終推論出此方案可以在客戶端與系統之間實現理想的解耦關系，同時也為主題皮膚功能預留了接入入口。

小結

當起點需要做 Dark Mode 時，我們已經明白這對設計團隊和研發團隊都是一場考驗，而這其中最難的并非是設計方案的制定，方案的推進與執行才是最大的考驗。項目初期我們通過對雙端規則的研究，結合起點產品的現狀，制定了這一套 Design Token 解決方案，這套方案對于成熟的團隊可能作用甚微，但對于還糾結于此事的團隊來說，應該可以提供一些幫助，對于文中提到的觀點歡迎留言參與討論。

感謝每一位為此項目付出的設計、研發、測試、服務端等小伙伴。

更多深色模式的設計復盤：

歡迎關注作者的微信公眾號：「閱文體驗設計YUX」