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

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

閱讀類產品如何做深色模式

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 時，我們已經明白這對設計團隊和研發團隊都是一場考驗，而這其中最難的並非是設計方案的制定，方案的推進與執行才是最大的考驗。