關於移動端的一些tip

移動端的一些tip

開發相關

關於viewport

<meta name="viewport" content="name=value,name=value">
//
指令
每對鍵值對都是一個指令,(ppk 大神的叫法)如下總計共有6對:
width
    設置layout viewport的寬度(css px)
initial-scale 
    設置頁面的初始縮放比例同時能夠設置layout viewport的寬度
minimum-scale
    設置最小縮放比例(指用戶可以縮小到多小)
maximum-scale
    設置最大縮放比例(指用戶可以放大到多大)
height
    設置layout viewport的高度,但暫時不怎麼被支持
user-scalable
    設置是否容許用戶放大縮小。

當咱們的網頁不使用viewport的時候網頁在移動端顯示的時候基本上看不清楚字體,爲何呢?由於咱們將960px(當咱們不作設置的時候viewport會自動的把咱們的html給規定成980px)的內容壓縮到320dpx(非css單位,在移動端中1px帶至一個最小顯示單位,一屏就是320px)。css

解決方案

經過上述的例子咱們知道基本上 viewport 的默認寬度是980px,且瀏覽器會將者 viewport 大小的 html 文檔塞進有限的設備寬度內(瀏覽器會動態計算文檔的佈局及內容),因此咱們看到的東西都很小。
那麼咱們想要清除的看清文檔內的內容怎麼辦 ,沒錯,縮小 viewport 的大小,什麼原理?
當咱們縮小 viewport 的寬度的時候文檔的寬度也對應的被縮小,即同樣的設備寬度,我顯示的東西少了(這時候瀏覽器從新計算文檔佈局及內容)能夠看到的結果是字體被放大了,內容都被放大了!html

詳細解釋
  • [x] width
    能夠用width來設置viewport的寬度,以替代那些不合適的默認寬度。咱們能夠給其設定一個固定大小,但設定成device-width更加明智一些,這樣咱們能夠兼容不一樣大小的屏幕。採用了以後就是咱們上面所說的效果,雖然是顯示的東西變少了可是個人字體變大了!
  • [x] initial-scale
    在移動設備上,用戶有時會縮放,當頁面縮放時,viweport的像素尺寸也會響應的改變,單css尺寸不會變。前端

    好比,在一個400px寬的Viewport中有一個元素,設定width: 100px;,這時該元素就橫跨了1/4的屏幕。若是用戶把頁面放大到兩倍大小,這時Viewport寬度變成了200px,但元素仍然寬100個CSS像素。這時這個元素就佔了半個屏幕了。android

滾動方式

頁面的滾動位置分爲兩種,一種是滾動body,另外一種固定body的高度爲100%,在main中滾動。ios

  • 滾動body:頁面的地址會隨着body的滾動隱藏起來,而且在android設備中,滾動body會更加的流暢。(把body設置爲overflow就好了)這種狀況比較適合長列表頁面,整個頁面除了herder和footer以外都須要滾動,但不少時候咱們只但願頁面的某個元素滾動,這個時候就採起第二種佈局方式。
  • body高度設置爲100%:這種方法有許多種實現方式
    • [x] fixed定位 -- 頭部尾部都設置爲fixed定位
    • [x] absolute定位
    • [x] flex定位
    這裏面也存在一些須要注意的地方,在移動端,若是fixed定位結點後面緊接着跟着興地結點是可滾動的(也就是設置了overflow爲true),那麼fixed結點會被其後的兄弟結點遮住

fixed 與 input

在移動端開發中,在有input元素的標籤頁中使用fixed定位時會出現一些問題。 在ios上,當點擊input標籤獲取焦點喚起軟鍵盤的時候fixed定位會暫時失效,或者理解爲變爲了absolute定位,在含有滾動的頁面會和其餘結點一塊兒滾動。因此在含有input元素的頁面中使用absolute更好。css3

compositionstart和compositionend事件

在開發中咱們常常要對錶單元素進行輸入限制,好比特殊的字符(也有xss的防範功能),咱們會監聽input事件。可是,在ios中input事件會截斷非直接輸入,好比:輸入[焦貴彬]中間過程當中會輸入拼音,每次輸入一個字母都會觸發input事件,然而在沒有點擊選定按鈕以前都會截斷,也就是會觸發不少次。這時候就須要咱們說的兩個事件。web

compositionstart 事件在用戶開始進行非直接輸入的時候觸發,而在非直接輸入結束,也即用戶點選候選詞或者點擊「選定」按鈕以後,會觸發 compositionend 事件。chrome

關於性能

使用css3動畫,開啓硬件加速(存在須要注意的地方)

css3動畫會新建一個圖層,另外部分css3動畫會調用GPU,獲得性能上的提高.瀏覽器

觸發
  • 3d 透視或視圖變換(perspective transform)css屬性
  • 使用加速視頻解碼的元素
  • 擁有3d(webGL)上下文或2d上下文的元素(carvers)
  • 混合插件(如flash)
  • 對本身的opacity作css動畫或使用一個動畫webkit變換元素
  • 擁有加速 CSS 過濾器的元素
  • 元素有一個包含複合層的後代節點(換句話說,就是一個元素擁有一個子元素,該子元素在本身的層裏)
  • 元素有一個 ** z-index ** 較低且包含一個複合層的兄弟元素(換句話說就是該元素在複合層上面渲染)

上面有提到須要注意一些地方,就是他會將後面的一些不須要新建圖層的元素新建圖層,使性能不只沒有提高反而出現了一些隱患!css3動畫

如何來看到css3動畫新建的圖層

在chrome 中選擇open drawer(版本不一樣會不同,有些版本下直接在控制檯的設置中 more tools --> rednering)選擇rendering,而後選擇打開layer boerders ,如今在咱們的瀏覽器上就能夠看到一些黃色的框框,這個就是咱們所謂的複合層,表示被放到了一個新的圖層中渲染。

隱患

注意觸發新建圖層的最後一條,它的意思是若是有一個元素,它的兄弟元素複合層中渲染,而這個兄弟元素的z-index較小,那麼這個元素(不論是否應用了硬件式加速)也會被放到複合層中,那麼瀏覽器頗有可能給複合層以後的全部相對或絕對定位的元素都建立一個複合層來渲染,因而就有了這樣的情形-- 頁面上不少元素都啓用了GPU加速,反而致使了頁面很是的卡頓

解決方案

  • 在啓用css3動畫的元素上增長position:relative和z-index:1,這種作法的原理是認爲提高動畫元素的z-index,讓瀏覽器知道這個元素的層序,就不會很傻逼的把其餘z-index比他高的元素耶弄到複合層中了
  • 上面說了一些須要注意的地方,可是整體來講咱們仍是會採用一些css3的動畫去調用GPU,好比translate-Z:0;但是此時咱們並非要旋轉,這是一種欺騙瀏覽器的行爲。此時咱們能夠關注一下will-change
    ```
    /* 關鍵字值 /
    will-change: auto;
    will-change: scroll-position; // 告知瀏覽器會有滾動
    will-change: contents; // 告知瀏覽器內容或動畫變化了
    will-change: transform; /
    示例 /
    will-change: opacity; /
    示例 /
    will-change: left, top; /
    兩個 示例 */

    /* 全局值 */
    will-change: inherit;
    will-change: initial;
    will-change: unset;
    ```

適當的使用touch事件代替click事件

  • touch事件觸發的流程:touchstart -> touchmove -> touchend -> click
  • 觸發時機:click在dom上手指觸摸開始,且手指不曾在屏幕上移動(某些瀏覽器容許移動一個很是小的值)且在這個在這個dom上手指離開屏幕,且觸摸和離開屏幕之間的間隔時間較短才能觸發。

減小媒體查詢

若是使用的是rem的單位(至關於根元素的字體大小來縮放)由於這樣有兩個明顯的缺點 1.適配屏幕的尺寸不是連續的 2. 在本身的css文件中添加打斷的這樣查詢代碼。增長了css文件的體積。

  • 參考淘寶的移動端的頁面適配規則,使用js獲取客戶端的寬度,根據設計稿原型動態計算計算font-size的值

other

  • 避免使用css漸變陰影效果
  • 不濫用Web字體
    Web字體須要下載,解析,重繪當前頁面,儘可能減小使用。

參考

相關文章
相關標籤/搜索