超級App暗黑模式的最佳實踐---標準化設計體系

什麼是最佳實踐

Best Practice ：最佳實踐。Wikipedia 上對其解釋爲：

A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things. 

  (最佳實踐是一種：因其產生的結果優於其它選擇下的結果，或其已經成爲一種作事的標準，從而被廣泛承認優於任何替代方案的方法或技術。) 這個概念源於管理學，簡而言之，就是所謂「正確的作法」。   最佳實踐自己是美好的存在，猶如夜空中的一輪明月，照亮黑暗中的方向，指引着摸索前行的凡人。   可是對於最佳實踐，人們容易犯教條主義的錯誤，覺得就是放之四海而皆準，反而受其所累。因此咱們要先明確一下咱們實踐的目的和環境，並尋求這種場景下的最佳實踐。   咱們的目的是對於android和ios的最新系統版本新增特性--暗黑模式進行適配。   那麼什麼是暗黑模式呢？暗黑模式影響的範圍？咱們適配的App是一個什麼樣的App？咱們的技術環境是怎樣的？咱們準備投入多少成原本完成？   明確完這些問題，咱們就能夠肯定最適合的設計的方案。

項目需求

什麼是暗黑模式？

Android Q 與 iOS13 前後發佈深色模式，以前隨公衆理解的深色氛圍一躍而上成爲系統平臺級能力。 IOS：developer.apple.com/design/huma… Android：developer.android.com/guide/topic… 深色界面在專一環境下與內容有更高的契合度，更凸顯內容、緩解視覺疲勞。 深色界面更易營造品質感與沉浸感。 深色界面更易創建填充感 -- From 設計

暗黑模式影響的範圍

而做爲一種系統平臺能力，它打造的是一個整個用戶使用週期的全鏈路視覺體驗，也就是要覆蓋到用戶能到達的每個角落。 這包括了分發場景，搜索場景，消費場景等複雜的頁面結構的場景，也包括落地頁，活動頁等獨立頁面，還包括了彈窗，Toast，播放器等經常使用組件。要Cover如此複雜細碎的場景就須要總體性的視覺呈現效果和低成本的用戶和平臺開關。

優酷現有的相似場景及其技術方案

分析完須要影響範圍，咱們再來看一下，咱們實踐的對象--優酷APP。優酷App發展到今天，已經從一個單體App，進化成了一個承載集團衆多業務出口的超級App。因此優酷app的頁面是由十幾個建制完整的內部和外部團隊共同貢獻的，這種全站範圍的適配將涉及到上百位相關的設計開發和測試同窗，管理成本，落地成本都很是高。 在肯定技術方案前，咱們先調研了每一個業務團隊現有的技術方案。 主要有三種，第一種是經過服務端下發視覺模式標記，客戶端經過解析該標記的配置，轉化成對每個視圖的代碼設置。一個視圖在某個視覺模式對應的代碼設置在開發時就肯定了。第二種，是服務端下發一套視覺樣式的KV，客戶端預先寫好視覺樣式的Key和某一個/類視圖元素的對應關係，在客戶端渲染時，經過這個Key在服務端數據中找到對應的Value並設置給視圖元素。第三種，是依賴於原生的資源加載器，不一樣的視覺模式對應不一樣的資源文件。

預期成本

因爲優酷的業務需求較多，以往大量佔用業務需求的開發人力的方式，成本較高。因此咱們但願能夠以較低的開發成本完成需求。而咱們又但願第一時間將系統的新特性儘早的呈現給客戶，因此咱們的開發週期定在了雙十一以後的兩週。

如何落實最佳實踐

最簡即最優

在肯定技術方案以前，咱們還須要肯定設計原則。咱們的原則是： 簡單 準確 全面 具有必定的動態性 設計體系

簡單是由於暗黑模式在超級App落地涉及的團隊很是多，而你們真的技術棧很是不一樣，極具差別性，因此我但願個人技術方案必定要在緊貼系統，才能讓你們容易接受，纔不會和別的技術方案產生衝突。技術方案能夠疊加但不能衝突，否則落地就遙遙無期了。 準確是由於暗黑模式涉及的頁面很是多，設計開發也天然很是多，如何把控整體的效果，而不在落地的過程當中發生變異，就須要一個惟一的標尺，並且這樣在開發中出現設計或者需求修改的狀況也可以快速響應。 全面是由於暗黑模式的頁面中，不只有Android/IOS這樣的native頁面，還有Weex，H5等動態頁面，將來還有可能有Flutter，小程序這種新興勢力。因此必定要設計一個全面的技術方案。另外，咱們但願咱們的方案能夠輸出，到文娛，到集團，甚至到外部。因此也須要一個全面的設計。 具有必定的動態性是考慮到可能須要服務端下發，或者針對不一樣頁面作定製。 設計體系 以前的設計開發以前是割裂的，經過標註進行溝通，開發不對設計效果負責，設計每每都要在集成前才能看到設計效果，而後設計再找開發修改，再review，造成循環。這是縱向的割裂。還有橫向的割裂，一樣的設計在不一樣的應用場景要重複循環，而不一樣的設計和開發可能在最終的效果上有不一樣的表達，形成風格的不統一，下降用戶體驗。因此咱們但願的咱們的實踐可以減小這些gap，造成完整的設計體系。

標準化設計體系

下面爲你們介紹咱們最終的實踐方案---標準化設計體系 咱們和設計同窗一塊兒經過對大量線上的產品進行了摸底，概括抽象出了其中的共性的設計，站在全站的高度，共同搭建了視覺產品化能力，把影響視覺風格調性的最基礎屬性（顏色、字號、間距、圓角、尺寸）進行了統一的命名（DesignToken），設計與開發團隊共同維護一套可擴展的視覺屬性。視覺屬性與框架佈局分離並與開發邏輯相互對應，經過SDK的方式統一管理，一處替換全端生效，遍於控制並快速定義產品風格。 在暗黑模式的具體工做上，設計同窗負責肯定暗黑模式的色彩框架，造成設計規範，創建模式色板。而研發同窗則再也不像以往根據具體的數值進行開發，改成根據語義名進行開發，並且經過多級的視覺開發代碼複用，最大程度的減小具體業務組件的適配工做，將適配開發改成了頁面走查，走查沒有歸入或使用DesignToken的場景。 另外，咱們考慮到語義化名字在設計和開發之間的天然流轉，還修改了設計開發工具。將以前輸出數值在標註上的方式，改成了輸出DesignToken和示例代碼在標註上。在不給設計增長標記成本的同時，大大減小了設計和開發的溝通成本。

此外，咱們還對於暗黑模式進行了色彩分層，靜態色層是全站使用的基礎色值，它直接對應着一個具體的值。它不會隨着視覺模式的變化而變化。在它之上的是動態色層，動態色在不一樣的視覺模式下，對應不一樣的靜態色。這是經過android原生的資源加載機制完成，即暗黑模式對應關係在暗黑資源文件中，普通模式在普通資源文件夾中。而在動態色層之上，是代碼編寫的色彩管理器，它在合適的時間會去獲取當前的全部靜/動態色值，設計這一層有兩個緣由，一個是提升性能，提早緩存一份給更上層調用，另外一個是造成中間層，衆所周知，xml資源文件的動態性是不足的。XML資源啓動即加載，加載後就是隻讀的。有了這一層，咱們能夠支持服務端動態下發色值token的定義，以達成必定程度的動態性。在色彩管理器之上，是公共的控件和組件，因爲這樣的層次關係，使最終的業務設計能夠經過搭建完成，徹底不須要從零寫起，也不須要關注設計標註的細節，開發不再用一個元素一個元素的調整，設計也不須要一個像素一個像素的校對了。只要在第一次歸入的時候進行一次就夠了，大大提升了工做效率。

Weex && H5

對於Weex和H5，咱們考慮了幾種方案，好比只提供模式查詢能力，由JS開發控制效果，再如創建JS版本的資源庫和設計標準化體系，前者過於簡單，難以控制最終結果，後者又比較重，須要較長的時間成本。咱們的最終的方案，JS側開發按照DesignToken進行開發，這樣設計對於不一樣渲染方式是無感的，而Native在調用Weex或H5的渲染時，將當前的色值表傳給JS側，這樣JS側對於當前所處的視覺模式也是無感的，可是最終效果就是和Native完美契合的。

留給將來

咱們以爲設計標準化體系大大的提升瞭如暗黑模式這種全站視覺開發的效率，DesignToken的設計將開發從繁瑣的視覺效果開發中解脫了出來，將來咱們會繼續深化和豐富標準化設計體系的能力。也但願這種開發方式能夠在不一樣的App間變成通用方式，這樣對如公共組件池，Weex/Flutter/小程序等的跨應用通投都有重要的意義。 跨端技術方案提供了跨端的技術基礎，而標準化設計體系則給出了跨端的實際方案。