摘要：對于開發(fā)同學(xué)來說不管用戶比例多高設(shè)計(jì)稿都按給絕對是最值得吐槽的事情之一在我剛開始接觸開發(fā)的那個(gè)階段每當(dāng)有人問起這件事我都說的做法就是看著差不多就行了后來有些要求特別高的設(shè)計(jì)開發(fā)同學(xué)就只能很苦逼的一個(gè)一個(gè)的改到滿意為止我看現(xiàn)在不少輔助開發(fā)工具

對于 Android 開發(fā)同學(xué)來說, "不管用戶比例多高, 設(shè)計(jì)稿都按 iOS 給"絕對是最值得吐槽的事情之一.

在我剛開始接觸 Android 開發(fā)的那個(gè)階段, 每當(dāng)有人問起這件事, 我都說 "Android 的做法就是看著差不多就行了..." 后來有些要求特別高的設(shè)計(jì), Android 開發(fā)同學(xué)就只能很苦逼的一個(gè) dp 一個(gè) dp 的改到 UI 滿意為止. 我看現(xiàn)在不少輔助開發(fā)工具的思路也是這樣.

17 年底 ~ 18 年初搞 UI 大改版的時(shí)候, iOS 開發(fā)同學(xué) 傳人 Joe 跟設(shè)計(jì)敲定了 iOS 的還原方式. 我覺得如果 Android 不搞的話之后開發(fā)就太煩了, 就決定 試一試. 最后的方案雖然不是特別通用, 但也能解決大部分問題.

然后就被設(shè)計(jì)小姐姐催著寫原理, 然后一年就過去了...

從這里開始

上圖中, 粉底的 "22 一行"和 "22 多行"是設(shè)計(jì)小姐姐給的參照圖, 是用 Sketch 輸出的, 使用 22 號字+默認(rèn)行高情況下的設(shè)計(jì)稿上的樣子. 綠底和黃底的 "22 一行"是 Nexus 5 上, 使用 22dp 的樣子; 藍(lán)底(疊加顯示成紫色)的 "22 四行"也是 22dp, 文字用 " " 換行. 底色之間的差異就是"行高"的差異.

可見綠底一行的行高有一點(diǎn)細(xì)微的偏差, 黃底一行因?yàn)榀B加了 4 次這個(gè)誤差, 比較明顯. 多行情況下的誤差更大, 因?yàn)?Android 和 iOS 在多行文本排版的概念上差異很大. 參照圖上單行和多行是能對上的, 現(xiàn)在我們要想辦法讓 Android 的單行和多行都能跟參照圖對上.

單行對齊

觀察發(fā)現(xiàn)單行差的是底部的一段空白, 我稱之為 additionalPaddingBottom. 對比各種字號的情況, 發(fā)現(xiàn)并沒有規(guī)律, 因此搞出來一組經(jīng)驗(yàn)值.

這個(gè)經(jīng)驗(yàn)值在 3 倍屏上還是比較準(zhǔn)確的(最重要的是設(shè)計(jì)走查就用 3 倍屏...), 單行文字位置和行高都能對上. 在其他倍數(shù)的屏幕上基本 ok, 但也有一些異常. 比如在 1.5 倍屏上, 部分字號只能達(dá)成行高對的上但文字位置對不上的效果, 而且還受到 setSingleLine 的影響, 15dp + setSingleLine(true) 時(shí)偏差尤其大.

/**
 * density 為 3 時(shí)的經(jīng)驗(yàn)值, 作為計(jì)算 additionalLineSpace 的基數(shù)
 */
static {
    paddingBottomMap.put(10, 1f / 3);
    paddingBottomMap.put(11, 4f / 3);
    paddingBottomMap.put(12, 2f / 3);
    paddingBottomMap.put(13, 1f / 3);
    paddingBottomMap.put(14, 3f / 3);
    paddingBottomMap.put(15, 2f / 3);
    paddingBottomMap.put(16, 1f / 3);
    paddingBottomMap.put(17, 4f / 3);
    paddingBottomMap.put(19, 1f / 3);
    paddingBottomMap.put(22, 2f / 3);
    paddingBottomMap.put(30, 5f / 3);
}

多行對齊

根據(jù) Android 文本排版概念, 我寫了個(gè)簡單的 MetricsTextView 來確定單行和多行的行高關(guān)系:

觀察發(fā)現(xiàn): 兩行文字的高度 = 單行文字的高度 + 單行文字設(shè)置 setIncludeFontPadding(false) 的高度

同時(shí), 兩行文字和兩組單行的差別在于文字之間的空白, 因此需要增加 lineSpaceExtra = topSpace + bottomSpace + additionalPaddingBottom. 這樣 Android 也實(shí)現(xiàn)了 n 行文字行高 = n x 單行文字行高, 多行也就對上了.

行高

上面都是參考圖使用默認(rèn)行高的情況, 如果行高變了呢);

/**
 * sketch 中字號對應(yīng)的默認(rèn)行高 (dp)
 */
static {
    defaultLineHeightMap.put(10, 14);
    defaultLineHeightMap.put(11, 16);
    defaultLineHeightMap.put(12, 17);
    defaultLineHeightMap.put(13, 18);
    defaultLineHeightMap.put(14, 20);
    defaultLineHeightMap.put(15, 21);
    defaultLineHeightMap.put(16, 22);
    defaultLineHeightMap.put(17, 24);
    defaultLineHeightMap.put(19, 26);
    defaultLineHeightMap.put(30, 42);
}

首先我們有默認(rèn)行高的值, 然后把 deltaPaddingTop = deltaPaddingBottom = (lineHeight - defaultLineHeight) / 2 用 paddingTop 和 paddingBottom 加到 每一行 上 - 實(shí)驗(yàn)結(jié)果表明上下加的一樣多, 可以除 2, 真是幸運(yùn).

帶行高的對齊:

局限性

只關(guān)注行高, 不關(guān)注文本寬度, 所以換行還是跟 iOS 不一樣.

并不是對所有的字號/字體都有效, 只處理了我們常用的字號(其它字號要加也不難), 默認(rèn)字體.

沒有抽成庫, 原因就是上面那條.

18 年 Android 最新的 support 庫好像為 AppCompatTextView 增加了行高支持, 但我還沒有來得及試.

其它已知問題

5.0 以下系統(tǒng)需要特殊處理 paddingBottom, 因?yàn)闀黾宇~外的 lineSpaceExtra

但是有些 5.0 及以上的手機(jī) (vivo X9, 錘子) 居然也有這個(gè)問題, 管不了了...

因?yàn)橹苯有薷牧?TextView 的 paddingTop 和 paddingBottom, 如果設(shè)計(jì)稿上有上下邊距, 只能用 margin 或者再嵌套一層的方式解決.

也許可以寫得更完善些.

在生產(chǎn)環(huán)境中使用時(shí), 有同學(xué)發(fā)現(xiàn)該 TextView 中 ClickableSpan 的點(diǎn)擊事件無法被觸發(fā).

還木有解決...

@Uraka.Lee