640 * 1136的圖片能不能在iphone5上徹底展現?
iphone5分辨率640*1136javascript
邏輯像素與物理像素的關係
px邏輯像素:瀏覽器使用的抽象單位
dp,pt物理像素:設備無關像素
dpr:設備像素縮放比
計算公式:1px = (dpr)^2 * dp
iphone5的 dpr = 2;css
DPI:打印機每英寸能夠噴的墨汁點(印刷行業)
PPI:屏幕每英寸的像素數量,即單位英寸內的像素密度
目前,在計算機顯示設備參數描述上,兩者意思一致
計算公式:以iphone5爲例:ppi = √(1136^2 + 640^2)/4 = 326ppi(視網膜retina屏)
注意:單位爲硬件像素(物理像素),非px
PPI越高,像素數越高,圖像越清晰。但可視度月低(小),系統默認縮放比越大。
retina屏(高清屏):dpr都是>=2。html
手機瀏覽器默認爲咱們作了兩件事情:
① 頁面渲染在一個980px(ios)的viewport
② 縮放前端
爲何要有viewport?
一個300多像素的屏幕,放一個1000多像素的頁面,會混亂,因此要先虛擬一個980像素的頁面,而後進行縮放。java
度量|視口 visual viewport ==== 窗口縮放scale
佈局 layout viewportandroid
設計移動web,爲何不使用默認的980px的佈局viewport?
① 寬度不可控制,不一樣系統的設備默認值均可能不一樣
② 頁面縮小版顯示,交互不友好
③ 連接不可點
④ 有縮放,縮放後又有滾動
font-size爲40px等於pc上12px同等物理大小,不規範ios
移動web最佳viewport設置: 佈局viewport = 設備寬度 = 度量viewport
<meta name=」 viewport」 content = 「width=device-width, initial-scale = 1, user-scalable = no」>css3
手機寬320px,咱們就拿320px設計。web
縮放0.5。根據設備的物理像素dp等於抽象像素px來設計。1px像素邊框和高清圖片都不須要額外處理。chrome
在移動開發過程當中要學會作減法,一些不過重要的東西能夠隱藏起來。
不少網站都是使用固定佈局,之前凡客、淘寶也有段時間使用過流式佈局,如今都改爲固定佈局。
可是固定佈局不適合移動開發。
① 響應式佈局:responsive 高清圖片 retina px em rem
② flex彈性盒子佈局:高效居中方案 等比例填充列行 background-size font-size 多行文本溢出
根據元素個數不一樣,自動填充
display:-webkit-flex; 表示使用彈性佈局
子元素設置 flex:num; 佔容器的比例
position:absolute;
top:50%;
left:50%;
transform:translate(-50%,-50%);
.parent{
justify-content : center; //子元素水平居中
align-items : center; //子元素垂直居中
display : -webkit-flex;
}
①新flex佈局:
display : -webkit-flex;
-webkit-fiex: 1; //子元素的flex
justify-content : center;
align-items : center;
②舊flexbox佈局:
display : -webkit-flex-box;
-webkit-fiex-box: 1; //子元素的flex
box-pack : center;
box-center: center;
(1)hack方式
li{
line-height: 568px;
vertical-align:middle;
}
li img{
vertical-align:middle;
}
(2)更優雅的方式,對於高級瀏覽器來講
// 父元素
position:absolute;
// 子元素
li{
display: table-cell;/*盒模型變成表格的元素*/
vertical-align: middle;
}
(3)另外一種垂直居中方式
li{
display: -webkit-box;
-webkit-box-pack:center;
-webkit-box-align:center;
}
開發一個頁面,在全部的設備上都可以完美展現。
print(打印機)
handheld(手持設備)
all(通用)
width —— 視口寬高
height —— 視口寬高
device-width —— 設備的寬高
device- height —— 設備的寬高
orientation:檢查設備處於橫向(landscape)仍是豎屏(portrait)
僅僅使用媒體查詢來適應不一樣固定寬度設計,只會從一組css到另外一組css的切換。兩種設計之間沒有任何平滑漸變。只使用媒體查詢,佈局有時會變得不可控制。
固然,這只是建議,也有一些頁面採用固定佈局的狀況下可以很好的在一些沒有考慮過媒體查詢狀況下的設備上很好的展現。
思路:不管什麼時候,全都包在圖片的元素寬度範圍內,以最大的寬度同比完整的顯示圖片。
img{ max-height: 100% }
當頁面達到手機屏幕寬度的時候,不少時候就要放棄一些傳統的頁面設計思想。力求頁面簡單,作以下處理:
① 同比例縮減元素尺寸
② 調整頁面結構佈局
③ 隱藏冗餘的元素
常常須要切換位置元素使用【絕對定位】,減小重繪提升渲染性能。
根據響應式設計的理念,一個頁面包含全部設備不一樣屏幕的樣式和圖片,當一個移動設備訪問一個響應式的頁面,就會下載pc,筆記本,ipad等不一樣設備對應的樣式。而這些樣式倒是冗餘的,徹底沒有用。
權衡利弊:性能不是最優,可是能減小重複開發。
在移動web頁面上渲染圖片,爲了不圖片產生模糊,圖片的寬度應該用物理像素單位渲染,便是100 * 100的圖片,應該使用100dp * 10dp。
width:(w_value/dpr)px;
height:(w_height/dpr)px;
一樣是retina屏幕下的問題,根本緣由:1px使用2dp渲染。
border:0.5px;(錯誤),僅僅ios8可使用
通用方案:scaleY(0.5)
爲了適應各大屏幕的手機,px略顯固定,不能根據尺寸的大小而改變,使用相對單位更能體驗頁面兼容性。
em:是根據父節點的font-size爲相對單位
rem:是根據html的font-size爲相對單位
em在多層嵌套下,變得很是難以維護,rem更加能做爲全局統一設置的度量
那麼,rem的基值設置爲多少比較好?
迴歸目的:爲了適應各大手機屏幕
rem = screen.width / 20
通常來說font-size是不該該使用rem的相對單位的。由於字體的大小是趨向於閱讀的實用性,並不適合於排版佈局。
同理,趨向於一些固定的元素的特性。咱們不使用rem而改成使用px去確保在不一樣屏幕上表現一致(跟rem的目的相反)。
單行文本溢出,對title類的使用很是多,而多行文本類,在詳情介紹則用的比較多。
//單行文本溢出…
.inaline {
overflow: hidden;
white-space: nowrap;
text-overflow: ellipsis;
}
//多行文本溢出…
.intwoline {
display: -webkit-box: !important;
overflow: hidden;
text-overflow: ellipsis;
word-break: break-all;
-webkit-box-orient: vertical;
-webkit-line-clamp: 4;
}
移動web頁面上的click事件響應都要慢上300ms
用300ms判斷是單擊仍是雙擊
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)
觸摸纔是移動設備的交互的核心事件,支持多點觸摸。
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。
①彈性滾動:當客戶端的頁面滾動到頂部或底部的時候,滾動條會收縮並讓咱們多滑動必定距離。經過緩衝反彈的效果,帶給用戶良好的體驗。
移動web頁面也是擁有這樣的能力的,但滾動有幾種狀況須要考慮:
body層滾動:(系統特殊化處理)
自帶彈性滾動,overflow:hidden失效,GIF和定時器暫停。
局部滾動:沒有彈性滾動,沒有滾動慣性,不流暢。
局部滾動開啓彈性滾動:
body {
overflow:scroll;
-webkit-overflow-scrolling:touch;
}
②下拉刷新:頂端下拉一小點距離,頁面彈性滾動向下。
④ 上拉加載:使用scroll事件,而不是touch事件(android有bug)
優化技巧: canvas代替img標籤
drawImage(image,x,y);canvas上繪製圖片
drawImage(image,x,y,width,height);canvas上繪製縮放圖片
緣由: img使用瀏覽器渲染,當圖片特別大且手機性能不是很好的狀況下,會特別卡,一般表如今滑動圖片。由於沒有觸發物理設備自己的GPU(圖形處理器)渲染
① 預加載圖片:當設置img.src=」」的時候,就表示請求加載圖片
② 圖片的按比例縮放
當一個css3動畫結束時,咱們能夠監聽相關事件AnimationEnd,好比對於webkit來講,是webkitAnimationEnd。
① 單域 - Media Query
② 單域 – 多模板
③ 多域 – 跳轉(很原始)
④ 多平臺 App
① 移動端的用戶和流量愈來愈多
② 各類屏幕讓咱們更聚焦業務的本領
③ 移動設備有更先進的人機交互體驗
接口模型:前端消費者;後端生產者;測試監督者
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;/* 防止閃白 */
6)更多圖片的優化,保留3個要使用的節點,當前的,上一個,下一個圖片的節點,剩餘的不須要的刪除
7)jQuery Mobile(JQM jQMobile)
是jQuery在手機上和平板設備上的版本,是建立移動web app的框架。
8)2048製做過程當中遇到的bug:(見9(2)touch基礎事件BUG)
// 手機上手指識別無用,chrome19827號錯誤:touchevent不被觸發。防止沒有正確使用preventDefault()
document.addEventListener('touchmove', function(event) {
event.preventDefault();
});
10)使用Dropbox發佈本身的web app
免費
限制: ① 靜態網站 ② 速度較慢(在國外) ③ 域名不宜記憶
11)web app、native app和hybrid app(混合模式)
本文連接:http://www.cnblogs.com/xsilence/p/5774737.html