之前寫過一個(gè)關(guān)于柵格系統(tǒng)的簡述文章；現(xiàn)在來看只能作為簡單的視覺布局參考，更多的是從排版布局的角度出發(fā)。最近被問到選擇幾作為柵格基數(shù)比較好這個(gè)問題，對此做一下整理。
其實(shí)柵格在各個(gè)平臺(tái)開發(fā)布局中都有所定義。
淺析三大平臺(tái)的開發(fā)布局方式
通俗介紹 簡單了解一下開發(fā)布局中柵格的變革
Web端
Web端最常見的布局Bootstrap?；
它是Twitter的設(shè)計(jì)師Mark Otto和Jacob Thornton合作開發(fā)的一款強(qiáng)大的前端框架，至今仍被廣泛使用，已經(jīng)更新到V4版本了。
Bootstrap中的柵格系統(tǒng)是一套響應(yīng)式、移動(dòng)設(shè)備優(yōu)先的瀑布流式柵格系統(tǒng)。
它將系統(tǒng)分為12列，當(dāng)然也可以通過變量來改變列數(shù)和列寬，水槽寬度，屏幕浮動(dòng)寬度；
其實(shí)設(shè)置屏幕浮動(dòng)寬度就是我們看到的屏幕自適應(yīng)，就是根據(jù)屏幕寬度來選擇顯示參數(shù)。
Bootstrap中的柵格流只能作為大的布局定義，那么針對最小單位是該用8、10、15還是多少也是需要根據(jù)需求去做分析。
iOS端
iOS布局方式很多，常用的可以歸納為Frame、Autoresizing、Constraint、StackView和Masonry?五種；
其中，
Frame用來描述UIView的位置和大??；
Autoresizing早期用來適配屏幕；
Constraint比Autoresizing更加靈活，適配效果更好；
了解一下，
StackView?它是iOS9時(shí)新增的一個(gè)視圖類，可以把它理解成一個(gè)容器，添加到容器內(nèi)的控件可以按照行或列進(jìn)行布局。
Masonry?是一個(gè)輕量級的布局框架，是基于NSLayoutConstraint的一種第三方框架；通俗來講用它實(shí)現(xiàn)適配布局更簡潔更輕量。
Android端
先簡單了解一下Android開發(fā)中的六大基本布局
LinearLayout?線性布局：最常用的以垂直和水平方向的布局方式
RelativeLayout?相對布局：可以基于父或兄弟控件來布局
FrameLayout?層布局：就是控件蓋控件的那種布局方式
AbsoluteLayout?絕對布局：基于絕對坐標(biāo)xy布局，無法自適應(yīng)
了解一下，
TableLayout?表格布局：多行多列的布局方式
GridLayout?網(wǎng)格布局：以網(wǎng)格的方式進(jìn)行布局
在引入的表格布局和網(wǎng)格布局中其實(shí)就是為了更加方便系統(tǒng)柵格化
根據(jù)以上內(nèi)容對于三大平臺(tái)的常用布局做一個(gè)簡單的分析
總結(jié)：
Web端引入的Bootstrap、Android端的表格和網(wǎng)格布局以及iOS9之后引入的Stachview和Masonry都是為了能更好的適配以及進(jìn)行系統(tǒng)的柵格布局；
也體現(xiàn)了設(shè)計(jì)中需要柵格定義的重要性。
以上布局框架僅是從開發(fā)層面的一個(gè)布局演變
轉(zhuǎn)換到設(shè)計(jì)中來，如何去定義？如何站在多個(gè)角度去思考柵格布局？
看到過很多關(guān)于柵格布局的文章，現(xiàn)在理解覺得有些片面，可能僅是作為從設(shè)計(jì)的角度去理解， 很多的柵格方式都是從平面排版設(shè)計(jì)中的柵格演變過來的，基數(shù)可能比較隨性，并且沒有嚴(yán)格貼合系統(tǒng)去做。
柵格系統(tǒng)以多少為基數(shù)比較好，好在哪里？
站在巨人的肩膀上，還是從這三大平臺(tái)來看，看一下官方給出的建議。
簡單看一下Bootstrap的柵格參數(shù)， 通過下表可以詳細(xì)查看 Bootstrap 的柵格系統(tǒng)是如何在多種屏幕設(shè)備上工作的。
由表知Bootstrap的默認(rèn)水槽寬度是30px(每列左右是15px)，當(dāng)然這些是可自定義的，Bootstrap的主要目的是為了適配屏幕進(jìn)行自適應(yīng)布局；
我們設(shè)計(jì)時(shí)設(shè)置柵格的時(shí)候大多數(shù)情況下是以非自適應(yīng)網(wǎng)頁來做的柵格，柵格最小單位一般是10，15等不定參數(shù)；
雖然Web端的可視范圍比較大瀏覽方式和移動(dòng)端不一樣，
但是我們發(fā)現(xiàn)針對一些內(nèi)容較多的網(wǎng)頁或者說對卡片內(nèi)的信息去做布局，基數(shù)是10或15就會(huì)很難呈現(xiàn)出想要的效果。
8點(diǎn)柵格，以8為基數(shù)做柵格
以8為基數(shù)的柵格系統(tǒng)漸漸被使用，以8為基數(shù)?好在哪里？
之前國外的一個(gè)博客中(spec.fm?*一個(gè)開發(fā)者和設(shè)計(jì)師共同搭建的博客，設(shè)計(jì)細(xì)節(jié)中會(huì)從多個(gè)緯度去考量)， 有一篇文章?提到過使用8點(diǎn)柵格的好處。
總結(jié)一下他們在Web端分析出的好處點(diǎn)有哪些；
Bootstrap或其他的框架只作為一個(gè)大的布局系統(tǒng)，對于設(shè)計(jì) 沒有一個(gè)設(shè)計(jì)單位去衡量 排版很難一致性，使用8點(diǎn)的好處在哪：
對于設(shè)計(jì)：效率，減少?zèng)Q策，同時(shí)能保持元素之間的節(jié)奏。
對于團(tuán)隊(duì)：開發(fā)人員更容易理解，在開發(fā)眼里8更有說服性。
對于用戶：一致審美，減少設(shè)備上出現(xiàn)模糊的半像素偏移問題。
iOS端
我們來看iOS的?Human Interface Guidelines?如何去給出布局建議。
iOS是個(gè)封閉的系統(tǒng)，在?Human Interface Guidelines?可以看到iOS使用Auto Layout自動(dòng)布局，iOS的系統(tǒng)完全自主更新，終端設(shè)備也完全由自己決定，因此系統(tǒng)可以做到強(qiáng)制規(guī)范化。但在這里提到的基數(shù)也是?8?。
在布局中說到的約束，就是我們來定義的柵格基數(shù)，他給的建議也是?8?。
下邊我們找一下iOS官方組件，看一下自適應(yīng)布局的限制區(qū)域是不是基數(shù)?8?。
在Sketch中置入一個(gè)iOS官方頁面組件將其拆解：
其實(shí)我們發(fā)現(xiàn)在iOS系統(tǒng)設(shè)計(jì)中的基數(shù)也是以8為基準(zhǔn)。
上邊說到的 Spec.fm 中的那篇文章中有提到Points，關(guān)于iOS的@1x，@2x，@3x圖，用 8 為基數(shù)可減少出現(xiàn)是奇數(shù)造成一像素偏移模糊的情況。
Android端
Android端的?Material Design?布局給出的建議。
在 Material Design 給出的建議中是以8dp為基準(zhǔn)，小的控件以4dp為基準(zhǔn)。
Material Design 定義的柵格布局更像Bootstrap，它可以適應(yīng)多平臺(tái)，結(jié)合它豐富的視覺語言能搭建出更加嚴(yán)謹(jǐn)?shù)囊苿?dòng)應(yīng)用或網(wǎng)頁。
站在巨人的肩膀上
從以上三大平臺(tái)來看，移動(dòng)端官方給出的建議都是以8為基準(zhǔn)。
從以上分析 我個(gè)人覺得，
從系統(tǒng)的角度，首先要保證是偶數(shù)；只研究移動(dòng)端平臺(tái)：2、4、6、8、10；
其實(shí) 我覺得用2的次方計(jì)算會(huì)更加貼合： 2^1、2^2、2^3、2^4 :?2、4、8、16；
在這些數(shù)字中2作為基數(shù)太小了我們視覺能看到的2個(gè)點(diǎn)太小，并且使用起來很麻煩每次都要進(jìn)行計(jì)算；
那么10或16作為基數(shù)又太大了，在移動(dòng)端很難避免信息過多小屏幕需要考慮排版的問題；
取在這兩組數(shù)中的交集還剩下 4 和 8 ；
以上Material Design給出的建議中也是以8為基準(zhǔn)，小的控件以4為基準(zhǔn)。
從很多角度來看 8 點(diǎn)柵格是最為理想的柵格基礎(chǔ)單位
下面再總結(jié)一下8點(diǎn)柵格的好處：
1、Web端布局更加靈活。
2、視覺一致性，保證元素之間的節(jié)奏。
3、減少出現(xiàn)奇像素偏移造成模糊。
4、開發(fā)更容易理解的數(shù)字8。
5、能被最多的屏幕尺寸整除適配，這也是Material Design和iOS建議的主要原因之一。
END / THX
