添加viewport標籤css
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" />
詳細屬性:html
width ---- viewport的寬度(width=device-width意思是:寬度等於設備寬度) height ------ viewport的高度(height=device-height意思是:高度等於設備寬度) initial-scale ----- 初始的縮放比例 minimum-scale ----- 容許用戶縮放到的最小比例 maximum-scale ----- 容許用戶縮放到的最大比例 user-scalable ----- 用戶是否能夠手動縮放
轉自:移動前端開發和 Web 前端開發的區別是什麼? - 知乎
https://www.zhihu.com/question/20269059前端
我轉了快2個月了,準備 談談感想。晚上回家吃完飯開更。html5
---------react
看到這麼多贊,不填坑對不起你們,可是本人水平有限,內容又太多太雜,今天先更新一部分,這幾天較忙。以後慢慢補,謝謝你們支持和點贊。android
有交流盡管留言,時間容許我會和你討論,並列入本回答。ios
0827,9:49css3
---------git
1,普通pc端開發與移動端開發區別。程序員
先說背景,我大言不慚的說一下,我pc端的前端開發幹了有快4年多,不算大牛,也算一個標準的前端開發工程師吧,可憐的是我2015年以前作過的移動端項目不超過1個。。因此幾乎經驗爲零。我對這個神祕又被炒的火熱的名字迷惑了好久,移動前端開發工程師,h5前端開發工程師,native前端開發工程師,Hybrid前端開發工程師,臥槽感受屌屌的有木有啊。。
因此我在15年決定棄坑了(pc的代碼實在寫膩歪了。。),投身到專屬的移動開發中,業餘時間也作過phonegap,也知道和了解過一些h5+native開發的方式,下面就慢慢給你們【科普】一下。。說錯了別噴。
普通pc端開發,我理解就是你拿電腦打開的網頁都算【這不是廢話麼】。
那麼移動端前端開發工程師,說白了就很好理解了,作手機網頁的前端開發工程師。
這麼一比,是否是感受,移動端開發簡單多了?
沒錯,我轉了以後發現還真是呢。。。【還有點小激動】
pc,咱們須要考慮什麼呢?有點開發經驗的同窗都知道,ie6-11,firefox,chrome,safari都得兼容的吧。哪一個都夠你吃一壺的,不管是css仍是js。
mobile的網頁開發,咱們須要考慮什麼呢?
就目前來講,咱們只須要考慮webkit內核的瀏覽器和chrome,uc,qq,小米手機瀏覽器就行了。。。【後面特地會說這幾隻國產瀏覽器哪裏屌了】
相比較而言,除了經驗是0之外,須要兼容的東西仍是少了,少了,少了呢。
ok,單純說pc和移動端開發的區別,其實也就是這個,能夠簡單的歸納來講,mobile端的網頁開發比pc端的網頁開發,更簡單一些。【頁面小了啊,裝的東西少了,css和html寫的少了吧】交互簡單一些【滑動,觸屏,手勢,平時看看手機你還能有啥特殊操做?】
so,別被這玩意嚇壞了,根據個人經驗來看,pc端的前端開發程序員,轉mobile開發,一點問題沒有,並且上手會很快。
夠直白的解釋了。
2,移動端web app開發與套殼開發區別。
移動端web app,移動端網頁,Hybrid開發【我喜歡叫套殼開發工程師……】,無所謂叫什麼,移動端開發無疑就是這3種了。下面一一解釋下個人理解。
移動端web app是什麼呢?簡單理解就是頁面頭部加入了下面這一句話的東西:<meta name="apple-mobile-web-app-capable" content="yes">
這個meta的做用是讓普通移動網頁被添加到主屏幕後,擁有一些類native的功能,不少同窗應該都很熟悉了。就是相似隱藏ios的上下狀態欄,實現全屏,禁止彈性拖拽,全屏,修改頂部顏色等。
我理解這種模式的網頁爲web app,固然還有一種類型就是你們平時都訪問的那些網站,好比手機taobao,手機美團,手機微博的網頁版,你們打開的時候,不是全屏的,可是用起來,開發者把它們假裝的很像這種web app的交互體驗而已。
以上2種我以爲能夠總結爲web app。而不是普通的移動端網頁,若是想看移動端網頁,能夠參考手機新浪網,手機網頁,手機騰訊新聞,手機鳳凰,是很好的對比。
以後我來講下套殼的吧。這部分若是沒有開發過phonegap或者相似和native連調過webview的同窗,可能以爲很陌生,其實不是,這種套殼開發和開發普通的網頁沒什麼區別,只不過資源大部分是file開頭的,本地資源,網絡資源分爲使用js異步接口獲取和native獲取,再和js的接口交互,相似ios中,能夠直接在oc或者swift能夠直接在webview中執行js,android同理,可是js想調用native功能怎麼辦呢?
咱們這邊的作法是有一個負責通信的iframe,咱們經過修改這個iframe的url,來讓native來監控一系列特殊的url地址請求,再在native中調用對應的功能,好比攝像頭,特殊交互,呼起,或者提供接口數據。數據的提供方式相似jsonp的原理,在執行函數的參數中傳回來。
理解了這塊,其實作套殼的比作普通web app和網頁都簡單,由於在native的webview中是能夠指定是什麼版本的webview,用什麼內核,擁有什麼等級的安全權限等等,ios和android作法不同,可是原理一致,對於前端開發工程師來講是無差的。
並且套殼開發還有個好處就是,由於資源是本地化的,因此可使用比較重的框架,如angular,react,一些三方框架,由於最終都是經過和native代碼捆綁發佈的。
套殼native的靜態前端部分的更新,咱們可使用遠程下載靜態資源包的方法實現,不發佈大版本而修改webview中邏輯的需求,這一點也是大部分公司選擇一半native一半h5來開發的緣由。都知道ios審覈發版很慢。
這些就是我知道的一些很通俗的區別了,技術細節就不說了,太多。你們有個概念就好啦。
3,對js和css的使用選擇。
這部分我提早預警,這是我本身的見解,不必定是正確的,你們互相討論。
個人想法是不使用目前那些主流的移動端框架,選擇手寫。我會說爲何。
好比jq mobile,zepto,backbone,angular,還有相似工具集,underscore,一些動畫框架,還有小型的遊戲框架,通通實際上是不太須要的。
我並非說他們很差,而是這些對於新手來講,只能是陣痛藥,而不是萬能藥。爲何呢,移動端的優化很大的一個瓶頸就是網絡加載速度不一致,有wifi,有3g,有4g,還有2g。代碼量在移動端開發是很大的一個考察點。
咱們反觀這些框架:zepto最早說,你用它作什麼?動畫?選擇器?事件委派?基於zepto的插件?可能大部分人就是用個選擇器吧。可是移動端的原生選擇器方法應有盡用,原生的徹底夠用,包括事件和委派,一共寫起來不超過10幾行的東西,引入一個框架不值得。再說mvc的框架,若是不使用離線存儲,我是反正不敢想沒wifi的狀況下體驗如何,外加移動端真的是否須要分層這種處理不說,主要仍是看業務場景。
套殼的那種上面說了,框架隨便用,由於足夠複雜,可是普通移動端開發,我我的是不推薦使用的,能夠直接上原生的來寫,最多來一個模塊化工具。我下面就說說本身是怎麼作的吧。
手機端對ES5的特性已經所有都支持的很好了,參考:
xiaojue/ES-shim · GitHub
這裏的api特性,只實現了一部分,可是其實平時對數據的處理,對象的處理,已經徹底足夠。我不說優缺點,我只說,移動端這些都是純自然的而已。
而後是咱們對手勢的處理,zepto中有幾個頗有用的事件,swipe,swipeLeft,right,up,down,一類的,還有tap,咱們能夠看下zepto的源碼:
zepto/touch.js at master · madrobby/zepto · GitHub
咱們真的全部場景都須要全部的功能麼,tap,doubletap,有多少人用了。。用到的時候,也是很是好實現的功能。我推薦直接手寫,或者本身寫一個swipe的基類,也不會比zepto的touch.js多太多,而好處是咱們可讓它貫穿咱們的項目,做爲一個base類使用,固然我不是噴zepto多餘,它不少代碼作了兼容處理,可是就目前咱們的業務來講,咱們只須要考慮webkit,只須要考慮幾個特定國產瀏覽器,由於這是統計數聽說了算。
沒了框架,咱們就不能寫代碼了麼?移動端開發,我以爲更考驗的是前端的基本功,只要基本功紮實,其實都是很簡單的需求,正由於都是本身一行一行寫的,遇到詭異問題就更好解決,而再也不須要糾結於,究竟是我作錯了,仍是框架錯了這個問題。
我不止一次的修改過iscroll的源碼來適應和「知足」咱們的測試。。。好比ios下用了iscroll,a標籤沒法點擊跳轉,不少人遇到過吧,不看文檔你還真是一時不知道怎麼解決,iscroll因爲禁止了頁面原生的滾動,不少原本很簡單得東西複雜化了,而咱們須要的是什麼?一個下託刷新?一個慣性滾動特效?開什麼玩笑,原生的也沒幾行啊。。。對於一個寫了多年pc端的前端來講我相信徒手寫個下託刷新禁止頁面慣性反彈的代碼,應該不復雜吧?這裏給個思路,好比咱們檢測touchmove的位置快到達頁面【或者容器】底部的時候,阻止touchmove,作容器或者頁面translate移動,再在下部埋一個loading,touchend以後再作緩動回覆,應該普通前端都能作到。
再說一個經常使用的移動端框架,swipe.js 作幻燈用的,我相信幻燈片作pc端得前端應該每一個人都寫過不下5遍了吧。只是事件換了,固然移動端有移動端本身須要處理的問題,可是我使用swipe框架的經歷也是很痛苦的,好比沒法很好的設置滾動過的距離,自定義緩動效果,還有沒法它本身自己帶的一些問題,好比橫豎屏的時候復位問題,動態插入子節點重排等,讓我第一次用的時候越開發越傷心,後來乾脆也是本身實現。
因此其實,1,咱們的需求,那些移動端框架不必定知足咱們。2,太大,太複雜,太難調試。3,需求其實自己不復雜,只是咱們想偷懶了。
有點跑題,這個標題說是js和css的選擇,js的立場我足夠明確了,若是簡單功能,不須要js框架,原生足夠,已經作得很好,下面說說css。
首先,作pc咱們都須要一個reset或者common,我共享下咱們的,
https://gist.github.com/xiaojue/8bac56fb488532e7857f
固然裏面有一些咱們特殊的顏色字體,我css並非特別好,我簡單的重複一下咱們css同窗的一些注意要點,可能不全:
下面截圖幾個wiki:
css這個方面的東西,我很差多說,畢竟我認可我css通常,可是有幾個原則能夠提煉出來的就是:
1,不少坑的形成是對原生屬性的掌握程度不熟練或者不知道有這個特性。
2,不少屬性極限突破可使用縮放,傾斜這種手段來hack,好比最小字體,好比各類本身畫的僞類圖標。
3,能css畫的不要用圖。
4,大小須要自適應的圖標作成字體的不要畫。
5,能flex佈局的不要用浮動,不要用絕對定位(不利於頁面佈局的擴展)
原本還有幾個比較典型得css案例,這個找機會在其餘答案裏說吧,都是上週css比較屌的同事分享的,我也受益不淺。總說就是移動端的css的寫法和pc相差甚遠,並且技術含量更高了,可喜的是兼容性問題少了,更多的是如何處理的更好擴展和精簡。
4,模塊化移動端的常見組件。
我只說咱們非業務方面的,能夠抽象出來的,可能和公司業務場景掛鉤。
1,touch對應的swipe事件。
2,各類滑動翻頁效果。
3,簡單的小遊戲框架。
4,視頻和音頻的包裝。
5,各類lazyload。
6,各類keyframes效果收集。
7,拉拽刷新。
其實不少pc要有的mobile端也都有,好比浮層,tip,氣泡,分享,添加主屏一類,可能和業務關聯太多,就不一一列舉了。這部分的組件其實市面上也沒有太多開源的比較簡易的,大部分都是又支持pc,又支持mobile,致使了不少冗餘,或者質量和需求,api不過關,致使很難擴展,各家都是本身寫。好比在微信的webview裏分享和在qq的webview分享,和在普通頁面的分享,在微博的webview裏分享,提示和實現的方法都不同,可是其實徹底都是能夠抽象成一個公共的東西的,個人團隊也在作這方面積累。
這個再安利一下,我作的一個作劃屏活動頁的組件:
xiaojue/EasySlide · GitHub
慢慢我也會開源咱們內部抽象好的移動端組件出來的。
5,移動端的性能優化和統計。
性能優化必須創建在統計的基礎上,不然都是耍流氓,因此先說統計。
目前個人作法和pc差很少,監控一些前端關注的時間點,首屏,doc ready,window ready,css ready,實現統計方法和pc也都同樣,應該各個公司都有,我簡單說下前端實現首屏統計如何作:
個人思路是,首屏的圖加載完,即首屏完成,首屏無圖,最接近首屏的dom節點ready的時間點爲首屏時間,咱們能夠在load的時候和document ready的過程之間檢測這幾個臨界,來收集首屏的完成時間,固然很不許啦,可是也是有一些參考價值的。。。
有了數據,我說一下移動端的統計極值問題,舉個例子,咱們手機打開一個網頁,尚未load完成,切到了後臺,這個時候腳本是不會執行的了,過了幾小時,幾天再回來的數據,咱們都能收集到,這部分屬於垃圾數據,是須要算平均值的時候去除的。這點和pc不太同樣。
而後是性能優化創建在均值性能指標上的,咱們儘快的提高首屏和win load的時間便可,原則和作法和pc一致,固然,移動端不是資源越合成一個越好,咱們的實踐是分散成不一樣的幾個資源下載,總時間比較快,好比活動頁面,h5小遊戲頁都是這樣。能夠統一把資源圖拆開加載,而後增長loading便可。
----我還在奮力思考和編寫中-----今天先到這裏了。。。。【這裏還有一個點,我想討論一下是mobile的cache的利用率問題,這個明天我詳細說,決定找些權威的數據或者本身作下測試再開始寫】
6,移動端網頁佈局方法與pc的差別。
主要是css方面,外加如何作到同一url,不一樣客戶端展示不一致的作法,俗稱pc和mobile都兼容。還有會說一下rem的相關用法和一段比較經典的rem.js
今天有空來更新一下這個rem在移動端佈局的一個用法:)(20151013更新)
首先,em和rem的概念我簡要說一下,em是父元素fontsize的倍數表示,rem則是root即爲html的fontsize的倍數表示。好比我html.style.fontSize = 12px;那麼1rem則爲12px,0.5rem爲6px;
好了,概念有了,那麼作佈局的時候咱們怎麼用呢,你們應該用過的都知道,移動端的字體默認爲16px,那麼1rem我想表示爲10px的話,咱們就須要 10 % 16 = 0.625 即爲62.5%,這樣就能夠比較方便的把設計稿裏的px轉換成rem單位來作到自適應了。這樣不管用戶如何設置電腦或者手機的默認字體大小,設置爲rem的單位的長度都會隨比例變化。
這是一種常規作法,其實換個角度咱們還能夠這樣用:
咱們想象一個設計稿寬度爲640,800,1200px等尺寸時,咱們如何來快速完成響應式的佈局呢?
百分比?flex?這些仍是有些複雜的。
後來發現,柵格等比縮放整個設計稿看起來是個更簡單粗暴的方法。並且正好能夠利用rem這個比例變化單位。
看下這段js:
https://gist.github.com/xiaojue/0615797dd6a7160177bd
比較好理解,咱們首先根據psd的設計稿寬度設置一個基值,而後咱們js獲取到當前窗口的寬度值,而後把這個設計稿寬度除以100柵格化一下,得到一份的寬度數,以後再用真實窗口的寬度除以這個一份的寬度,拿到就是咱們須要給html設置的fontsize的px值。
這樣咱們只須要把對應psd裏的px單位除以100,就獲得了任何寬度環境下的rem值。固然實際發現有些瀏覽器這個rem單位是存在bug的,好比比例值不許,那麼咱們就須要得到這個不許的比例再轉換成準的再賦值html的fontsize,可見calcTestDom函數,以後再處理一下旋轉屏幕時候的狀況,resize時候的狀況就行了。
這樣咱們在作一些活動專題頁面時,只須要引入這段js,在頁頭設置一個設計稿寬,而後對着設計稿一頓瘋狂的px除100來定位就行了。。比設置成62.5%的方式要更好(1,修復了瀏覽器bug,2,轉換單位更方便直觀,px/100便可)
7,常見js組件與pc端組件差別。
這部分還在想怎麼說比較通俗易懂,哪些組件是很是典型得,須要我回去慢慢想一想,找幾個實際的對比例子。
8,一些常見的坑。
分享一下內部wiki的經典移動端坑和解決辦法。(不會太多,別抱太大期待了。。)
9,適配【機型,瀏覽器】的方法和選擇。
1,統計說話。
2,調試方法。
10,測試技巧與pc的差異。
幾個比較經典的調試方法和工具介紹。
慢慢壘,先補提綱,5678910都沒寫。。。
轉自:HTML5移動端手機網站開發流程-段亮我的博客
https://www.duanliang920.com/learn/web/html5/304.html
最近一直在研究移動手機網站的開發,發現作手機網站沒有想象中的那麼難。爲何會這麼說呢?咱們試想下:咱們連傳統的PC網站都會作,難道連一個小小的手機網站難道都搞不定嗎?其實手機網站就是一個微縮版的PC網站罷了!至於爲何以爲難、以爲無從下手。
段亮以爲有如下幾點:
1、沒有完整的思路和流程
就像作網站的流程同樣,若是你能知道它的流程,我相信就不會以爲作手機網站難!真正難的是你沒有思路。
2、把html5這門技術想的高深莫測
好像以爲學會用html5+css3作手機網站,就至關於學會了頂尖的絕世武功。其實你錯了!不要把html5這玩意想的過高深,其實作手機網站,真正意義上用不到什麼的html5的強大功能。(可能對於一些不懂什麼技術的小白而言:你的手機網站是用HTML5+CSS3作的啊,簡直牛逼呀!能用上目前互聯網上最新最前沿的技術。其實明眼人一看,就知道是用什麼技術作的。俗話說的好:"外行看熱鬧,內行看門道")
好了扯了這麼多,下面就說說怎麼來開發移動手機網站吧!
基本上開發手機網站,可大體分爲兩大類。一類是用框架開發手機網站。一類是本身手寫手機網站。
1、框架開發手機網站
通常用如今經常使用的開發框架有:目前Web前端最火的框架(BootStrap)、Jquery mobile..固然可能還有一些移動端開發的框架,這些我就沒具體去研究過。
爲何說BootStrap是目前前端最火熱的開發框架呢?
由於bootstrap自帶響應式佈局(柵格系統),並且能作到移動設備優先的原則。
運用bootstrap來開發網站有什麼好處呢?
1.不懂設計也能夠作網站
就算不懂設計,你的網頁在Bootstrap的幫助下,也能擁有超高顏值。它強大的內置樣式庫讓你的做品變成尤物。
主要體如今:字體文件和bootstrap自帶的UI樣式。(爲廣大不會UI設計的程序員,提供了福音)
2.上手快
你能夠專心解決問題,冗繁的細節都丟給Bootstrap操心。能夠作到一次開發,就可適配全部終端,而且能迅速上手並建出網站原型。還提供不少豐富的插件,就算你不會JS,基本能看懂常見的API,網站上的效果,基本能解決。
缺點:
1.不遵循最佳實踐
咱們在使用Bootstrap時遇到的最大問題之一是你的DOM元素上將擁擠大量的類。這打破了良好的web設計基本規則之一,HTML再也不有語義,並且內容和表示再也不分離。前端純粹主義者會以爲這至關使人討厭,覺得它使可擴展性、重用性和維護性遇到了更大的挑戰。
2. Bootstrap 過重
直接點說:就是CSS和JS有點點大。CSS壓縮後115k,JS壓縮後35k
若是你想要使用Bootstrap的全部功能,你應該好好考慮資源的加載時間。固然,對於一些地方這可能不是問題,可是在新西蘭互聯網不得不橫跨太平洋,這時數據達到那兒將是很緩慢的。所以考慮你的目標市場。
相信任何框架都有它的優勢,同時也是有它的缺點的。沒有一個產品是很完美的,因此根據自身實際狀況進行選擇。至於一些其它框架暫時不作過多的解釋了,相信只要你肯願意百度一下,就能夠找到你想要的答案。
2、手寫手機網站
通常咱們本身手動開發手機網站的話,基本能夠劃分兩類來作到。一類是經過在網頁頭部添加meta標籤進行實現(網頁指html5的格式來開發)。另外一類是經過CSS3的Media標籤(媒介查詢)來實現。不瞭解媒介查詢的朋友,能夠看看這篇文章:響應式佈局。
在這裏咱們詳細講解下,利用添加meta標籤來作手機網站。
基本在網頁頭部咱們只需添加四個meta標籤就能夠實現一個手機網站的框架。我一塊兒來看看是哪些meta標籤。
一、添加viewport標籤
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" />
詳細屬性:
width ---- viewport的寬度(width=device-width意思是:寬度等於設備寬度) height ------ viewport的高度(height=device-height意思是:高度等於設備寬度) initial-scale ----- 初始的縮放比例 minimum-scale ----- 容許用戶縮放到的最小比例 maximum-scale ----- 容許用戶縮放到的最大比例 user-scalable ----- 用戶是否能夠手動縮放
關於viewport的詳細原理和知識點,各位就百度吧!在這裏我就不作詳細的講解了。
二、禁止將數字變爲電話號碼
<meta name="format-detection" content="telephone=no" />
通常狀況下,IOS和Android系統都會默認某長度內的數字爲電話號碼,即便不加也是會默認顯示爲電話的,so,取消這個頗有必要!
三、iphone設備中的safari私有meta標籤
<meta name="apple-mobile-web-app-capable" content="yes" />
它表示:容許全屏模式瀏覽,隱藏瀏覽器導航欄
四、iphone的私有標籤
<meta name="apple-mobile-web-app-status-bar-style" content="black">
它指定的iphone中safari頂端的狀態條的樣式
默認值爲default(白色),能夠定爲black(黑色)和black-translucent(灰色半透明)
另外還有一個個性化的link標籤,它支持用戶將網頁建立快捷方式到桌面時,其圖標變爲咱們本身定義的圖標。好比手機騰訊網上的標籤:
<link rel="apple-touch-icon-precomposed" href="http://3gimg.qq.com/wap30/info/info5/img/logo_icon.png">
不過騰訊對這個png圖標的命名並不規範,常規咱們要求文件名應爲 apple-touch-icon.png 或 apple-touch-icon-precomposed.png ,前者的命名iOS會爲這個圖標自動添加圓角、陰影和高亮覆蓋層,後者則不會添加這些效果。
手機網站基本框架代碼:
<!doctype html> <html> <head> <meta charset="utf-8"> <title>手機網站</title> <meta name="keywords" content="" /> <meta name="description" content="" /> <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" /> <meta name="format-detection" content="telephone=no" /> <meta name="apple-mobile-web-app-capable" content="yes" /> <meta name="apple-mobile-web-app-status-bar-style" content="black"> <meta name="author" content="duanliang, duanliang920.com" /> <style> body{font-size:62.5%;font-family:"Microsoft YaHei",Arial; overflow-x:hidden; overflow-y:auto;} .viewport{ max-width:640px; min-width:300px; margin:0 auto;} </style> </head> <body> <div> 你們好!我是段亮,這是個人第一個手機網頁哦! </div> </body> </html>
下面是我作的基於微信二次開發的手機頁面案例:
其實在移動端的開發讓我糾結的是在字體單位上的選擇。
隨着CSS3的興起,有一種叫rem的單位漸漸的出如今咱們的視野中。它是一個相對單位,能實現響應式的那種。它是相對於html根元素來設置當前文字大小,或者寬高的。由於它是一個不固定值,不像PX。據說在PX這個單位在PC和移動的解析不一樣,因此才使用rem的。這點我也不是很清楚,也請教了一些作手機網站的高手,瞭解了一些信息。
原來大部分的人依舊是使用PX來佈局,rem都用的少。目前來講,就移動端的淘寶首頁就是採用rem來做爲單位來佈局的。關於使用rem單位這個問題以及它的好處:還得須要大神來解答這個問題,畢竟我也只是剛接觸。
關於手機網站的調試問題
通常咱們採用的:在瀏覽器調試+真機測試,由於瀏覽器畢竟只是一個模擬工具,實際開發的話,咱們還得用真機去測試。
好比:(Android類手機,iPhone五、5s、六、6Plus...)
而在瀏覽器上測試,能夠chrome(谷歌瀏覽器)的F12調試工具:有個手機樣的小圖標,點擊就能模擬手機測試。
以下圖:
或者用火狐的測試工具:按shift+ctrl+M進行查看。
寫在最後:其實等你真正熟悉作手機網站這套流程後,你會發現作手機網站沒有你想象的那麼難,真正難的是不知道如何去下手。對於移動端的JS效果可能和PC端有些不一樣,由於移動端有移動端的事件,這也是我爲何總是強調學JS,是學原生JS,而不是學Jquery。