為什麼你的 APP 在 Sketch 上看起來更好: 探索 Sketch 和 iOS 的渲染差異
找出兩幅圖的差異
你能找到下面兩幅圖之間的不同點嗎？
如果你仔細看，可能會注意到一些微妙的差別：
右面的這幅圖:
- 有更大的陰影。
- 有更深的漸變。
- “in” 這個單詞在段落的第一行。
左邊的這幅圖是 Sketch 的一張截圖，右邊的圖是 iOS 系統實際產出的圖。這些差別會在影象渲染的時候出現。他們有完全相同的字型，行間距，陰影半徑，顏色和漸變屬性 —— 所有的這些常量都是相同的。
你可以看到，原始設計圖的某些方面在從設計圖到真實程式碼的轉變過程中有所丟失。我們會對這些細節進行探索，因此你可以知道去注意哪裡並且如何修復這些問題。
我們為什麼要關心
設計對於成功的移動 APP 來說是至關重要的。尤其在 iOS 平臺，使用者已經習慣了 APP 執行順暢並且介面優美。
如果你是一個移動應用的設計者或者開發者，你知道小的細節對於終端的使用者體驗是多麼的重要。高質量的軟體只能從那些深切在乎他們的作品的人們中產出。
APP 為什麼有可能看起來並不像原始設計稿那樣好，這是有很多原因的。我們會調查更精細的原因中的其中一個 —— Sketch 和 iOS 渲染時的不同。
轉化過程中的丟失
某些特定型別的使用者體驗因素在 Sketch 和 iOS 上有顯著的不同。我們將探索以下幾個因素：
- 排版
- 陰影
- 漸變
1. 排版
排版有許多種實現方式，但在這個測試中我將會用 label 來實現（ Sketch 中的 “Text” 元素，iOS 中的 ‘UILabel’）。 讓我們一起來看一下其中的一些不同:
上面這個例子中最大的不同就是換行的位置。設計圖中的第三組以 “This text is SF Semibold” 開始的文字，在 “25” 後面進行換行，但在 app 中，換行是在 “points” 後進行的。這個相同的問題會發生在那些換行不一致的的文欄位落中。 另一個比較小的不同是 leading（行間距）和 tracking（字元間距）在 Sketch 中稍大一些。
當他們直接被覆蓋時，這些不同會被更容易看到：
那使用其他的字型會怎樣呢? 將 San Francisco 字型替換成 Lato（一個更廣泛使用的免費字型），我們得到了下面的結果：
效果好了很多!
行間距和字元間距仍舊存在一些不同，但是大體上是小了。不過要注意，如果文字需要和其他元素對齊比如背景圖片，這些小的偏移量可能會相當明顯。
如何修復
其中的一些問題是和 iOS 的預設字型：San Francisco 有關的。當 iOS 渲染系統字型時，它會自動包括基於字號的字元間距。這個自動應用的字元間距表可以在蘋果網站上獲得。有一個 Sketch 外掛叫做 “SF Font Fixer”，它在 Sketch 中反映出了這些值。如果你的設計稿用到了 San Francisco 字型，我十分推薦使用這個外掛。
(邊注: 要一直記住在 Sketch 中將 text box（ Sketch 控制元件）緊緊包住文字四周。這個可以通過選擇文字並且開啟 “Fixed” 和 “Auto” 對齊來實現，接著重置 text box 的寬度。如果存在任何額外的空間，這會很容易導致不正確的值輸入到佈局中。)
2. 陰影
陰影並不像排版一樣有全域性佈局的規則，它並沒有清晰的定義。
我們可以在上面的圖片中清晰的看到，陰影在 iOS 上預設的會大一些。在上面的這些例子中，這一點在長方形的邊框上造成了最明顯的不同。
陰影是比較棘手的，因為 Sketch 和 iOS 的變數是不一樣的。最大的不同是 ‘CALayer’ 沒有 “spread” 的概念，即使我們可以通過增大 layer 的面積使他包含整個陰影來解決。
陰影可以在 Sketch 和 iOS 的不同上變化很廣泛。我曾看到過一些陰影在 Sketch 上看起來很好但在真機上幾乎不可見，即使他們有一模一樣的引數。
如何修復
陰影很棘手，它需要手動的調節來匹配原始的設計圖。通常地，陰影的半徑需要變小同時不透明度需要變高。
// old
layer.shadowColor = UIColor.black.cgColor
layer.shadowOpacity = 0.2
layer.shadowOffset = CGSize(width: 0, height: 4)
layer.shadowRadius = 10
// new
layer.shadowColor = UIColor.black.cgColor
layer.shadowOpacity = 0.3
layer.shadowOffset = CGSize(width: 0, height: 6)
layer.shadowRadius = 7
複製程式碼所需的改變是會根據大小，顏色和形狀來變化的 —— 這裡，我們僅僅需要一些很小的調整。
3. 漸變
漸變結果證明也是很麻煩。
三個漸變中，只有“橙色”（上）和“藍色”（右下）有所差異。
橙色的漸變在 Sketch 上看起來更加橫向，但是在 iOS 上更加的豎向。因此，整體的顏色漸變在最終的 app 上要比設計時更黑一些。
藍色漸變的不同更加的突出一些 —— iOS 上的角度更加的偏向垂直。這個漸變是被三種顏色來定義的： 左下角的淺藍色，中間的深藍和右上角的粉色。
如何修復
如果漸變是需要角度的，那開始點和結束點可能需要一些調整。嘗試根據這些不同輕輕地偏移 CAGradientLayer 的 startPoint 和 endPoint 屬性。
// old
layer.startPoint = CGPoint(x: 0, y: 1)
layer.endPoint = CGPoint(x: 1, y: 0)
// new
layer.startPoint = CGPoint(x: 0.2, y: 1)
layer.endPoint = CGPoint(x: 0.8, y: 0)
複製程式碼這裡沒有什麼魔法公式 —— 這些值需要不斷的調整迭代知道兩個結果在視覺上匹配。
Jirka Třečák 釋出了一個精彩的回覆，包含了連結來解釋漸變在渲染時是如何工作的。如果你想深入原始碼瞭解的話可以去看一下！
自己親眼看看
我建立了一個演示 app，可以在真機上簡單看一下這些不同。它包含了上面的這些例子，同時還有原始碼和原始的 Sketch 檔案所以你可以任意的調整這些常量。
這是一個很好的辦法來在團隊內部增強意識 —— 只需要把你的手機給他們然後他們自己就會看到。簡單地觸控螢幕上任意地方就可以切換圖片（類似於上面的 gif 圖片）。
獲得開源的演示 app: [github.com/nathangitte… Sketch -vs- iOS ](github.com/nathangitte… Sketch -vs- iOS )
Sketch vs iOS 演示 APP —— 自己試一下！
總結
不要假設同樣的值意味著同樣的結果。即使數值是匹配的，實際的視覺表現也可能不匹配。
在最後，任何設計在實現後都需要迭代。設計師和工程師良好地協作對於高質量最終產品是起決定性的。
喜歡這個文章？ 在 Medium 這裡留下一些掌聲??? 並且分享給你的 iOS 設計/開發朋友。想要持續獲取移動 app 設計/開發的最新資訊？ 在 Twitter 上關注我們： twitter.com/nathangitte…
感謝Rick Messer和David Okun對這篇文章的校正。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。