幾何

常常我們都是以iOS為準一稿適配兩端,那么如何讓兩端開發中的字高統一呢?一般我們會以設置行高規范的方式來解決,但其實我們知道安卓字體就是個大雜燴,一些特殊的字體可能會和我們設計稿中的字體相差幾個像素高度;由于開發方式的不同幾個像素的差異在走查過程中很可能就會翻車。

 

發現了問題?

我們在校驗的過程中會發現,安卓有時會和我們的設計稿對不上甚至間距越差越遠,iOS可能有時也會,這個時候我們可能就會要求開發調整修改幾個像素之類的,但是修改之后開發的間距和我們設計稿還一致嗎?和我們的規范還一致嗎?出現這個問題的原因就是我們沒把規范嚴格化,也許我們沒嚴格執行,也許開發沒嚴格執行,也許開發和我們實現方式不一致。

說這些是啰嗦嗎,肯定是一方出了問題呀,但當我們兩方都沒出問題,實現的界面還是沒對上?頭疼不頭疼?

還是有問題!問題出在哪里?

我們發現定了行高規范后仍沒達到我們想要的效果,如何才能像素級還原,以最優的方案解決問題,和開發在工作之余聯調討論了一個周解決方案后,我們試出個設計還原度最高的方案,并且團隊開發側和設計側已投入使用,可供參考。

 

兩方不一致?

開發對設計不了解實現方式和設計不一致;

開發調用舊代碼無法和新設計稿統一;

 

行高處理方式

由于開發習慣的問題;單行文字實現方式一般是,系統默認行高/去行高的方式/固定或相對行高:

多行文字對應實現方式,設置行間距/相對行高;

以上幾種方式是設計中常用方式也是對應移動開發中常用解決方案;了解開發方式會更有助于我們校驗設計的還原度。

 

反求相對行高

實際案例示例分析:

 

以上為設計稿和iOS側的處理方式,Web,Android和iOS對字體的處理原理有所不同,但不影響我們找一最優解決方案,相對于Web端由于適配問題則更建議使用相對行高。

以上可總結為:

單行 默認字體行高/去行高,對應多行 固定行高/相對行高/行間距;

 

字體中的問題

iOS

我們知道目前iOS?systemFont字體中 中文使用的是蘋方字體,英文和數字使用SF Pro Text ;

之前有個計算默認行高的公式和插件:

我們來測試一下看是否準確

找一組常用字號來測試

拿字號56來測試

計算字高為68px;測試結果單行效果完全一致;

對其他字號全部跑一遍結果也是一致的,就不一一列舉了。

測試多行

在多行測試中和設計稿不太一致。

我們用56px字,默認行高為68px;行間距設置為22px;在sketch中文本控件高度為68*3+22*2=248px;

但我們預覽控件的時候發現卻不是這個高度:

這個高度是123也就是246px;和248px差了2px;我們嘗試測試更多行,發現行數越多和設計高度相差越多,這是為什么呢?

看這張圖其實就明白了

其實系統的行高是一個六位小數,這也就驗證了前邊那個求行高公式為什么向上取整了,

我們看33.414062向上取整為34則行高為68px,兩行在設計稿中為136px;

33.414062兩行66.828124向上取整為67則行高為134px;和設計稿差2px;行數越多則最終結果和設計稿相差越大,不同字號也有所差異;

因此以上算行高公式對單行文本是正確的,多行則不能那么算。

 

Android

在Android平臺也是類似此類的算法,但是安卓中會給字體特殊加padding,就導致了安卓默認高度比iOS默認高度高一些,具體高多少也是沒有規律的,所以我們出一稿適配兩端的時候校驗起來特別費勁。

安卓處理行高的方式有三種,設置固定行高/刪去上下padding/只保留字高。

效果是這樣的:

這里的只保留字高并非是我們設計稿中字號設置多少行高設置多少,而是根據文字繪制的最高點和最低點。

加這行代碼去除上下padding

android:includeFontPadding=”false

由以上,安卓系統默認行高無法和iOS一致,但是去除padding后行高和iOS默認行高非常接近,于是我們測試了一下:

測試 機型 小米(720*1280/1080*1920/1440*2560),華為(1080*1920),vivo(2080*1920/1440*2560)。在測試中發現去掉padding后的行高非常接近iOS默認字體高度,根據字體大小會稍有差異,但是可以這么理解,相同字號中安卓的字體如果比iOS大一些行高就會稍高一點,這么計算也理所應當即使從設計側如果字號稍大一點我們也應該讓空間留的稍大一點,當然這只是一兩個像素的差異。
 

總結字體問題

iOS:可設置固定行高(相對行高)/系統默認行高/去行高(行高等于字號)Android:可設置固定行高(相對行高)/系統默認行高/去上下padding/保留字高如何讓它倆統一到一塊呢,如果都設置固定行高或相對行高,相同字號中隨安卓字體的不同字體稍大會稍擠字體稍小會稍散的感覺,但也不是不可取看能接受的程度。系統默認行高,兩端沒法統一,我們沒法確定以及統一安卓各個廠商的字體。設計中常常會把行高設為和字號一致,iOS去行高,但在安卓中沒法算出和蘋方去行高一致的算法,行高和字號設為一致容易翻車,在某些情況下開發設置了控件高度和行高一致的話有些字體是無法顯示完的,或者后期調整字體就會有無法顯示完的風險。當然安卓中的保留字高更不可取我們沒法這樣出設計稿,僅在一個平臺以怎樣的方式都可以對接。

當使用一稿對接兩端的情況,在測試過程中,系統的才是最好的。

首先,如果我們是以iOS規范出設計稿。字體使用的是iOS的系統字體,那么我們就理所應當遵循iOS系統規范去做設計,我們經常感覺開發效果和設計稿差異太大,其實如果兩者遵循相同的規范設置參數一致實現效果就應該一致。對于安卓,經測試安卓去除padding后和iOS默認行高最接近,并且使用系統字體,對于安卓校驗,我們校驗的時候應該是看其參數是否一致。

最終我們采用的方案是:設計稿以iOS系統字體規范出,也就是以上邊那個公式算出來的行高,安卓去除includeFontPadding和蘋方字體最接近,行間距不用固定行高或相對行高,使用linespace行間距。

在嘗試過程中也找到了iOS和設計稿單行多行都完全一致的方案,但需要引用用戶字體,也就是非系統字體,我們將蘋方字體打包至應用內,對三方字體進行測試發現,打包的蘋方行高沒有規律:

可以給不同字號設置固定行高,例如我們把引用的蘋方設置成和系統行高一樣的:

這時我們發現文字顯示的位置不對,需要使用baselineOffset屬性修正文字在行中的顯示位置:

CGFloat baselineOffset = (lineHeight – label.font.lineHeight) / 2;

多行里采用的方式其實就1*n的方式繪制多個單行文本最終高度和設計稿是完全一致的,但是該方案并沒有采用,我們知道使用三方蘋方字體在英文和數字中就沒法獲取系統的SF字體,會造成字體不統一,兩者需要取舍。

 

以上內容僅供參考,最終目的是為了提升設計和開發效率以及兩端統一和設計更好驗收。?

 

原文地址:夜貓設計話(公眾號)
作者:owlling?

 

轉載請注明:學UI網 » 如何統一兩端開發中的文本行高

登錄收藏
 
你可能喜歡的:
UI組件-滑塊 用戶超愛的選擇小助手UI組件-滑塊 用戶超愛的選擇小助手
啥?你說我不懂如何設計消息中心?啥?你說我不懂如何設計消息中心?
界面布局| 移動端常見8種界面布局的分析與運用界面布局| 移動端常見8種界面布局的分析與運用
砂之船奧萊數字化零售項目砂之船奧萊數字化零售項目
Material Design Shape and motion 形狀與動效Material Design Shape and motion 形狀與動效
Material Design Shape as expression 形狀表達Material Design Shape as expression 形狀表達
細說控件| Button按鈕的不同樣式與狀態細說控件| Button按鈕的不同樣式與狀態
Material Design Shape and hierarchy 形狀與層級Material Design Shape and hierarchy 形狀與層級
聊聊加載等待的那些事之“進度指示器”(原則篇)聊聊加載等待的那些事之“進度指示器”(原則篇)
Material Design About shape 形狀指南Material Design About shape 形狀指南
?
街机捕鱼城金库券