開發乙個頁面，在所有的裝置上都能夠完美展示。
print（印表機）
handheld（手持裝置）
all（通用）
width—— 視口寬高
height—— 視口寬高
device-width—— 裝置的寬高
device- height—— 裝置的寬高
orientation：檢查裝置處於橫向（landscape）還是豎屏（portrait）
設計點一：百分比布局
僅僅使用**查詢來適應不同固定寬度設計，只會從一組css到另一組css的切換。兩種設計之間沒有任何平滑漸變。只使用**查詢，布局有時會變得不可控制。
當然，這只是建議，也有一些頁面採用固定布局的情況下能夠很好的在一些沒有考慮過**查詢情況下的裝置上很好的展示。
img
設計點三：重新布局，顯示與隱藏
當頁面達到手機螢幕寬度的時候，很多時候就要放棄一些傳統的頁面設計思想。力求頁面簡單，做如下處理：
① 同比例縮減元素尺寸
② 調整頁面結構布局
③ 隱藏冗餘的元素
經常需要切換位置元素使用【絕對定位】，減少重繪提高渲染效能。
關於響應式設計的思考：在移動web頁面上渲染，為了避免產生模糊，的寬度應該用物理畫素單位渲染，即是100 * 100的，應該使用100dp * 10dp。
width：（w_value/dpr）px；
height：（w_height/dpr）px；
（2） 一畫素邊框
同樣是retina螢幕下的問題，根本原因：1px使用2dp渲染。
border：0.5px；（錯誤），僅僅ios8可以使用
通用方案：scaley（0.5）
（3） 相對單位rem
為了適應各大螢幕的手機，px略顯固定，不能根據尺寸的大小而改變，使用相對單位更能體驗頁面相容性。
em：是根據父節點的font-size為相對單位
rem：是根據html的font-size為相對單位
em在多層巢狀下，變得非常難以維護，rem更加能作為全域性統一設定的度量
那麼，rem的基值設定為多少比較好？
回歸目的：為了適應各大手機螢幕
rem = screen.width / 20
不使用rem的情況：font-size
一般來講font-size是不應該使用rem的相對單位的。因為字型的大小是趨向於閱讀的實用性，並不適合於排版布局。
同理，趨向於一些固定的元素的特性。我們不使用rem而改為使用px去確保在不同螢幕上表現一致（跟rem的目的相反）。
（4） 多行文字溢位•••
單行文字溢位，對title類的使用非常多，而多行文字類，在詳情介紹則用的比較多。
1//單行文字溢位…
2.inaline
7//多行文字溢位…
8.intwoline
對click事件say no
彈性滾動
上拉重新整理
tap事件基礎
touch觸控事件
下拉載入
300ms:
移動web頁面上的click事件響應都要慢上300ms
用300ms判斷是單擊還是雙擊
(1) tap基礎事件
300ms延遲怎麼破？tap事件代替click事件。自定義tao事件原理：
在touchstart、touchend的記錄時間、手指位置，在touchend時進行比較，如果手指位置為同一位置(或允許移動乙個非常小的位移值)且時間間隔較短（一般認為是200ms），且過程中未曾觸發過touchmove，即可認為觸發了手持裝置上的「click」，一般稱它為「tap」。
tap「點透」的bug：有兩層，點選第一層的時候，如果點選的區域在第二層的範圍內，那麼第二層也會被觸發。（原因與300ms有關）
tap透傳的解決方案：
①使用快取動畫，過渡300ms的延遲
②中間層dom元素的加入，讓中間層接收這個「穿透」事件，稍後隱藏
③「上下」都使用tap事件，原理上解決tap穿透事件，（但是不可避免原生標籤的click事件，如a，input）。
③ 改用fastclick的庫（聽過最新的zepto已經fixed掉這個bug）
(2) touch基礎事件
觸控才是移動裝置的互動的核心事件，支援多點觸控。
touchstart：手指觸控螢幕觸發（已經有手指放螢幕上不會出發）
touchmove：手指在螢幕上滑動，連續觸發
touchend：手指離開螢幕時觸發
touchcancel：系統取消touch時候觸發（不常用）eg：滑動頁面時來了乙個**或者其他系統事件
除常見的事件屬性外，觸控事件包含專有的觸控屬性：
touches：跟蹤觸控操作的touch物件陣列
targettouches：特定事件目標的touch物件陣列
changetouches：上次觸控改變的touch物件陣列
乙個小bug：android只會觸發一次touchstart，一次touchmove，touchend不觸發。（4.0，4.1有，4.2修復沒有了，4.4開始又出現了）
解決方案：在touchmove中加入：event.preventdefault（），可fixedbug。
但注意：event.preventdefault（）會導致預設行為不發生，如scroll，導致頁面不滾動！如果頁面帶有滾動條，就需要考慮更換解決方案。
(3) 彈性滾動，下拉重新整理
①彈性滾動：當客戶端的頁面滾動到頂部或底部的時候，滾動條會收縮並讓我們多滑動一定距離。通過緩衝**的效果，帶給使用者良好的體驗。
移動web頁面也是擁有這樣的能力的，但滾動有幾種情況需要考慮：
body層滾動：（系統特殊化處理）
自帶彈性滾動，overflow：hidden失效，gif和定時器暫停。
區域性滾動：沒有彈性滾動，沒有滾動慣性，不流暢。
區域性滾動開啟彈性滾動：
body
但注意：android不支援原生的彈性滾動！但可以借助三方庫iscroll來實現
②下拉重新整理：頂端下拉一小點距離，頁面彈性滾動向下。
④ 上拉載入：使用scroll事件，而不是touch事件（android有bug）
(4) canvas & gpu render【gpu 渲染】
優化技巧：canvas代替img標籤
drawimage（image，x，y）；canvas上繪製
drawimage（image，x，y，width，height）；canvas上繪製縮放
image object：
(5) css3 animation
當乙個css3動畫結束時，我們可以監聽相關事件animationend，比如對於webkit來說，是webkitanimationend。
（1） 移動優先：
① 移動端的使用者和流量越來越多
② 各種螢幕讓我們更聚焦業務的本領
③ 移動裝置有更先進的人機互動體驗
（2） 多終端檢測
（3） 介面：結構：通用介面，
介面模型：前端消費者；後端生產者；測試監督者
1）css3動畫，代替dom animation，效率更高，因為css3直接使用瀏覽器的gpu（圖形處理器）渲染
2） 當你給乙個元素設定它的百分比寬度的時候，他需要乙個比照，也就是父元素，但是當它沒有父的時候，需要給他乙個絕對定位absolute值，但是在移動開發中，給整個整塊的頁面使用position: absolute;很占用記憶體，特別是當內容比較多的時候，會非常明顯。會有幾個後果：在ios下，會導致瀏覽器直接崩潰掉；在android下，會導致非常非常的卡。所以建議直接用js計算。
3）將顯示到一排上，不使用浮動，使用-webkit-transform:translate3d(0,0,0); position: absolute;
4）new date() * 1；// * 1 ，進行數值運算，轉換為數字形式的時間戳
5）
self.startx = evt.touches[0].pagex; //記錄開始的位移,touches包含著所有手指觸控在螢幕上的點的集合
-webkit-backface-visibility:hidden;/*
防止閃白
*/
8）2048製作過程中遇到的bug：（見9（2）touch基礎事件bug）
//手機上手指識別無用，chrome19827號錯誤：touchevent不被觸發。防止沒有正確使用preventdefault()
document.addeventlistener('touchmove', function
(event) );
移動web開發中遇到的一些問題收納
window.scrolly window.scrollx桌面瀏覽器中想要獲取滾動條的值是通過document.scrolltop和document.scrollleft得到的，但在ios中你會發現這兩個屬性是未定義的，為什麼呢？因為在ios中沒有滾動條的概念，在android中通過這兩個屬性可以正...
一些Web開發工具
php 之前用過eclipse很久，當時也是唯一的選擇，不過現在看來是非常不好的選擇。netbeans和phpstorm都是很優秀的選擇。乙個細節 單元測試唯一可用的就是phpunit,但是適合的場景是 工具類 即不怎麼依賴其他外部資源 適配過的框架 如yaf，yii，官方有定製版的phpunit ...
web開發快取的一些了解
最近面試中又問道web開發後台快取的一些東西，以前這片幾乎是盲區所有有必要整理一些。快取 基本思路 將短時間內重複頻繁訪問的內容 或通過計算得出的內容 儲存在乙個更容易訪問的位置，方便下次訪問請求到來時直接取出 結果 總之是減少計算次數 或訪問次數。快取 基本原則 需要有大量的 頻繁的對同型別資源的...