Wap App;Native App;Hybrid App(融合體，H5頁面巢狀在Native中)，之所以說這三個，是因為它們相互之間的聯絡在某種程度上制約了Wap App 的柵格設計。下面詳細說下柵格試驗。
Phone柵格和PC柵格，本質上沒有區別，一樣的計算方式，無外乎螢幕大小的差別，但這螢幕大小，就有很多細節需要結合手機使用者習慣來判斷和取捨。我們試驗的Phone柵格都是流體柵格，簡單說，就是不定義具體尺寸，而是螢幕佔比。
說到螢幕佔比，我們需要設定基準螢幕(這個可根據某些具體資料確定，比如我的目標使用者群使用的手機螢幕尺寸佔比最多的是1136*640，即可定位基準螢幕)，這裡假定基準螢幕是960*640 。
通常柵格的計算公式 (m+a)*n-a=640-2b (m 柵格寬;a 槽寬;b 留白寬;n柵格個數)
試驗 1
m=40 n=12 a=10 b=25(我們通常定義柵格數目n是2，3，4，6的整數倍，12柵格算是最簡單的柵格結構)。
試驗1的柵格是沿襲PC的思想，但在後來應用到越來越多的頁面時，這種柵格做2，3，4，6等分都很OK，但不做等分時，靈活性就很差，也算是一個致命的缺點，對於視覺設計師來說有很大的侷限性。所以不建議在手機上使用12柵格。
試驗 2
m=44 n=12 a=8 b=12。
試驗2和試驗1其實差別不大，柵格數目都是12，也算是相對早期提出的(還沒有覺得12柵格的靈活性差)，相當於是試驗1的優化：一是覺得兩邊留白寬度25略大，二是可以在一個單位柵格內取到最小的'可觸控尺寸44*44。但其實真正應用到介面上時體現的價值並不大。當然後來發現12柵格的弊病後，便一併放棄了。
試驗 3
m=18 n=24 a=8 b=12。
24柵格是基於設計的靈活性而提出的。在應用中，無論是等分，還是靈活性，還是前端對於柵格的基數考量上，都相對合理，但依然沒有最後選擇這種柵格，這就牽扯到開始提到的Hybrid App。
需要應用柵格體系的H5頁面，大部分是要巢狀到Native App中，所以要儘量讓巢狀頁面看起來和原生介面保持統一性，而App 有一個不成文的柵格規定，任何的介面尺寸都要是4DP的倍數，也就是最小柵格單位要是8Px(當然這可能也是沒有足夠經驗的原因，到最後和APP團隊溝通後才瞭解到，所以到試驗柵格後期才採用了柵格試驗4的方案)。
還是建議大家，如果你設計的WAP不需要配合Native，選擇24柵格是相對完美的一種方案。
試驗 4
m=8 n=80 a=8*2 b=8*3。
整個介面按8Px的尺寸等分80分，靈活性很好，可以很好匹配Native。但也有不夠完美的地方，一是不論對視覺設計師還是前端工程師，應用起來都不方便，計算起來相對麻煩;二是不能3等分和5等分介面，需要在設計和開發時做特殊處理，當然使用者是看不出來的。但因為要保持終端的一致性，所以我們對於wap柵格設計採用了柵格4。
