移動端webapp開發必備知識，webapp開發必備知識

移動端webapp開發必備知識，webapp開發必備知識

行動裝置的使用者越來越多，每天android手機的啟用量都已經超過130萬台，所以我們面向移動終端的WebAPP也開始跟進了。本文主要介紹webapp的開發與調試的相關知識和經驗，以及給出幾種可選的解決方案。

 一、基本概念 （1） CSS pixels與device pixels

CSS pixels： 瀏覽器使用的抽象單位， 主要用來在網頁上繪製內容。

device pixels： 顯示螢幕的的最小物理單位，每個dp包含自己的顏色、亮度。

等值的 CSS pixels在手機螢幕上佔多大的位置，這不是固定的，這取決於很多屬性。經過分析和總結，我們可以得出這麼一條公式： 1 CSS pixels = （devicePixelRatio）^2 device pixels （^2是平方的意思，至於 devicePixelRatio是什麼東西，後面會講解） 。

 （2） PPI/DPI

PPI，有時也叫DPI，所表示的是每英寸所擁有的像素（pixel）數目，數值越高，即代表顯示屏能夠以越高的密度顯示映像。（註：這裡的像素， 指的是device pixels。）搞清楚了PPI是什麼意思，我們就能很容易理解PPI的計算方式了，我們需要首先算出手機螢幕的對角線等效像素，然後處以對角線（我們平 常所說的手機螢幕尺寸就是說的手機螢幕對角線的長度），就可以得到PPI了。準確的計算公示大家可以參照。比較有意思的是，根據公式計算出來的 iPhone 4的PPI為330，要比蘋果官方公布的326要高一點點。

同理，以HTC G7為例，480*800的解析度，3.7英寸，算出來就是252的PPI。

 （3） 密度決定比例

我們計算PPI就是為了知道一部手機裝置是屬於哪個密度區間的，因為不同的密度區間，對應著不同的預設縮放比例，這是一個很重要的概念。

由可知，PPI在120-160之間的手機被歸為低密度手機，160-240被歸為中密度，240-320被歸為高密度，320以上被歸為超高密度（Apple給了它一個上流的名字——retina）。

 

這些密度對應著一個特定的縮放比例值，拿我們最熟悉的iphone4或4s來說，它們的PPI是326，屬於超高密度的手機。當我們書寫一個寬度為 320px的頁面放到iphone中顯示，你會發現，它竟然是滿寬的。這是因為，頁面被預設放大了兩倍，也就是640px，而iphone4或4s的寬， 正是640px。

 

圖中把高密度的一類圈起來，是因為這是android手機的統計資料，在國內安卓手機市場中，高密度的裝置佔了絕大多數的市場份額，這是很重要的一點，也是我們做安卓端webapp要注意的關鍵點。

 （4） viewport的使用

viewport總共有5個屬性，分別如下：

Html代碼  

<meta name="viewport"  

content="  

height = [ pixel_value |device-height] ,  

width = [ pixel_value |device-width ] ,  

initial-scale = float_value , minimum-scale = float_value , maximum-scale = float_value ,  

user-scalable =[yes | no] ,  

target- densitydpi = [ dpi_value | device-dpi| high-dpi | medium-dpi | low-dpi] " />  

<meta name="viewport"content="height = [ pixel_value |device-height] ,width = [ pixel_value |device-width ] ,initial-scale = float_value , minimum-scale = float_value , maximum-scale = float_value ,user-scalable =[yes | no] ,target- densitydpi = [ dpi_value | device-dpi| high-dpi | medium-dpi | low-dpi] " />

 

 

在這些屬性裡面，我們重點關注target-densitydpi，這個屬性可以改變裝置的預設縮放。 medium-dpi是target-densitydpi的預設值，如果我們顯式定義target-densitydpi=device-dpi，那麼 裝置就會按照真實的dpi來渲染頁面。打個比方說，一張320*480的圖片，放在iphone4裡面，預設是佔滿螢幕的，但如果定義了target- densitydpi=device-dpi，那麼圖片只佔螢幕的四分之一（二分之一的平方），因為iphone4的解析度是640*960。

 二、解決方案 （1） 簡單粗暴

如果我們按照320px寬的設計稿去製作頁面，並且不做任何的設定，頁面會預設自動縮放到跟手機螢幕相等的寬度（這是由於 medium-dpi是target-densitydpi的預設值，和不同密度對應不同縮放比例所決定的，這一切都是行動裝置自動完成的 ）。所以這種解決方案，簡單，粗暴，有效。但有一個致命的缺點，對於高密度和超高密度的手機裝置，頁面（特別是圖片）會失真，而且密度越多，失真越厲害。

 （2） 極致完美

在這種方案中，我們採用 target-densitydpi=device-dpi，這樣一來，手機裝置就會按照真實的像素數目來渲染，用專業的話來說，就是1 CSS pixels = 1 device pixels。比如對於 640*960的 iphone，我們就可以做出 640*960的頁面，在iphone上顯示也不會有捲軸。當然，對於其他裝置，也需製作不同尺寸的頁面，所以這種方案往往是使用媒體查詢來做成響應式 的頁面。這種方案可以在特定的解析度下完美呈現，但是隨著要相容的不同解析度越多，成本就越高，因為需要為每一種解析度書寫單獨的代碼。下面舉個簡單的例 子：

Html代碼  

<meta name="viewport"content="target-densitydpi=device-dpi, width=device-width " />  

<meta name="viewport"content="target-densitydpi=device-dpi, width=device-width " />

 

Html代碼  

#header {  

background:url (medium-density-image.png);  

}  

@media screen and (- webkit -device-pixel-ratio:1.5) {  

/* CSS for high-density screens */  

#header { background:url (high-density-image.png);}  

}  

@media screen and (- webkit -device-pixel-ratio:0.75) {  

/* CSS for low-density screens */  

#header { background:url (low-density-image.png);}  

}  

#header {background:url (medium-density-image.png);}@media screen and (- webkit -device-pixel-ratio:1.5) {/* CSS for high-density screens */#header { background:url (high-density-image.png);}}@media screen and (- webkit -device-pixel-ratio:0.75) {/* CSS for low-density screens */#header { background:url (low-density-image.png);}}

 

  

 （3） 合理折中

針對安卓裝置絕大多數是高密度，部分是中密度的特點，我們可以採用一個折中的方案：我們對480px寬的設計稿進行還原，但是頁面制卻做成 320px寬（使用background-size來對圖片進行縮小），然後，讓頁面自動按照比例縮放。這樣一來，低密度的手機有捲軸（這種手機基本上 已經沒有人在用了），中密度的手機會浪費一點點流量，高密度的手機完美呈現，超高密度的手機輕微失真（超高密度的安卓手機很少）。這種方案的優點非常明 顯：只需要一套設計稿，一套代碼（這裡只是討論安卓手機的情況）。

 三、開發調試 （1） weinre遠程Just-in-Time 偵錯

Web開發人員經常使用Firefox的firebug或者Chrome的開發人員工具進行Web調試，包括針對JavaScript，DOM元素和CSS樣式的調試。但是，當我們期望為移動Web網站或應用進行調試時，這些工具就很難派上用場。

weinre就是一個協助我們在案頭來遠端偵錯運行在行動裝置瀏覽器內的Web頁面或應用的調試工具。weinre是WEb INspector REmote的簡寫，現在是Apache的一個開源項目，託管在github。

 

下面將介紹如此在日常工作使用它。

首先，我們要下載weinre的jar包——項目官方已經找不到該jar檔案，網上能夠找到，這裡建議搭建個獨立的web伺服器，jar運行後是一個本地的伺服器，和web伺服器差不多~~

然後通過運行dos命令來啟動它（請注意在你的電腦上已經安裝有JDK）。運行命令如下，需要把路徑改成你的實際檔案位置：

C代碼  

java -jar d:toolsweinre-jarweinre.jar –httpPort 8081 –boundHost -all- //（httpPort是指定服務連接埠，boundHost參數說明可以使用IP訪問，all參數代表支援所有的host）。  

java -jar d:toolsweinre-jarweinre.jar –httpPort 8081 –boundHost -all- //（httpPort是指定服務連接埠，boundHost參數說明可以使用IP訪問，all參數代表支援所有的host）。

 

 

訪問localhost:8081，如果看到如下的頁面，說明weinre已經啟動成功：

輸入debug client user interface地址（調試用戶端UI地址）。本例中即：http://localhost:8081/client/#anonymous，其 中#anonymous是預設的調試id（debug id）。如果這個weinre調試伺服器只是由你一個人使用，那麼你可以使用預設的debug id：anonymous。 啟動的weinre調試用戶端ui如：

在需要調試的頁面加入中以下指令碼：<script type=”text/javascript” src=”http://localhost:8081/target/target-script-min.js#anonymous”>& lt;/script>，注意把localhost換成手機能夠訪問的真實IP地址。當手機訪問這個頁面時，weinre用戶端就會檢測到目標設 備，然後就可以對它進行調試了。

因為手機上不方便，我這裡就用兩個瀏覽器視窗來展示效果，其實手機上的效果跟右邊是一樣的。

 （2） AVD模擬器調試

靜態頁面並不能滿足我們的需求，很多實際效果比如touch事件，滾動事件，鍵盤輸入事件等，都需要在真實的環境下測試，這時就需要用到模擬器。就 像我們測試ie6一樣，AVD模擬器可以類比於PC上的虛擬機器，當我們需要測試某一特定的機型時，我們可以建立一個AVD，進行一系列的測試。不過使用 AVD的前提是已經部署好android的開發環境，這個需要JDK + android SDK + Eclipse + ADT，還是稍微有點繁瑣。

 （3）手機抓包與配host

在PC上，我們可以很方便地配host，但是手機上如何配host，這是一個問題。

這裡主要使用fiddler和遠程代理，實現手機配host的操作，具體操作如下：

 總結

以上就是我們在實際開發中積累的一些經驗和技巧，希望能夠給大家一些協助，如果你有好的方法或者工具，也請在留言中分享~~

到底什情況該選擇開發移動Web App？

移動Web也是唯一一個可供開發人員發布行動裝置 App的平台，它將各種移動互動與案頭任務有效地串連了起來。移動Web平台具有以下一些優點：容易學習，開發成本低、標準化、使用方便、易於發布。我將這些優點歸結為無處不在原則：通常開發簡單而且市場廣泛的東西往往能夠取得成功。“高品質”也是成功的關鍵因素之一，而這一點移動Web這些年還沒能做得很好。移動Web在許多方面還存在一些困難，如解決裝置的多樣性就是提升移動Web品質的一個重大挑戰。但是，移動Web遇到的困難遠沒有Native Apps遭遇的挑戰來得複雜。另外，這些挑戰將在這幾年的時間裡得到有效解決。眾所周知，我是移動Web的擁護者；然而，我也是第一個承認Native App重要性的人。開發Native App可以充分利用裝置的特性，而這一點往往是Web瀏覽器做不到的，所以對一個產品本身而言，Native App是最佳的選擇。下面幾節將討論一下Native App的一些主要功能。什麼時候應該開發一個Native App1.為應用收費沒有任何地方規定開發人員不能對一個移動Web App收取使用費，但是由於某些原因，人們常常認為不能或是不應該對一個Web App收取費用。由於曆史原因，導致行動裝置上付費服務遭遇兩大阻力：2.付款條件在行動裝置上輸入信用卡號相當麻煩，而且在許多老式裝置上也沒有安全保障。一種典型的方式是，如果你需要對你的應用收費，你可以與電訊廠商達成協議，讓電訊廠商代為為你的服務收費。這也意味著，你需要和多個電訊廠商達成合作。這通常是首選的方法，因為許多手機使用者可能根本就沒有信用卡，比如青少年。另一種方法是將使用者的信用卡資訊儲存在一個安全的網站上。使用者可以通過登入到該網站購買應用服務。這個過程不算特別理想，因為這意味著使用者不能直接通過他們的行動裝置購買服務了。3.強制分成行動電信業者是會提成的。App無論是通過電訊廠商還是通過行動裝置發布，他們都為應用提供了一套收費機制。這些電訊廠商和行動裝置將會提取部分收益，然後將剩餘的部分交給應用開發商，這也意味著，開發人員必須遵守他們的市場規則。適應電訊廠商的市場規則通常是非常困難的，需要投入大量的人力資源。相比而言，行動裝置的市場規則則簡單許多，但是也存在不少的困難。妨礙電訊廠商和行動裝置開發商利益的應用以及服務都將受到阻擾。過去，那些不靠電訊廠商和行動裝置開發商運作的網站如果收入過於顯眼的話，都逃脫不了被關閉的命運，但是最近，這樣的事情鮮少發生了。如果你想為你的Native App收費，那麼你就必須接受這個現實——你必須遵守別人的市場規則，還得放棄部分收益。開發遊戲如果你是想開發一個移動遊戲（移動遊戲是移動市場上最大的一塊），那麼你需要開發一個Native App。遊戲對資源的佔用很大，並且需要使用許多裝置API或平台API。雖然，現在有幾款完全使用Web技術開發的遊戲佔有了一定的市場份額，但是和Native App市場的佔有情況相比，還是微不足道的。遊戲使用者對應用的視覺和操作效果要求很高。移動Web雖然提供了一些模擬體驗，但還遠遠不能滿足使用者的需求。在開發移動遊戲時，你需要謹慎考慮你的應用需要支援哪些平台。幸運的是，現在有許多工具能夠協助你將你的遊戲推向多個平台，但是完成這些工作，還是需要花費大量的人力和物力。4.使用定位功能下一個功能就是定位功能，可以通過GPS或者是訊號檢測確定使用者當前的位置資訊。以前只能通過Native App的APIs查看使用者的位置資訊，但現在大多數主流行動瀏覽器上都嵌入了W3C Geolocation API。像iPhone或Android這樣安......餘下全文>>
 
移動webapp開發我要該怎學

在網上找資源或者報個軟體課程。