携帯電話端末web開発小記
9096 ワード
摘到:please call me HR
このfeatureは携帯電話端末だけでなく、PCも含まれているはずです.アップルは携帯電話端末だけでなく(iphone 4から)、MACにもretinaを使用しているからです.まずretinaは、dpr(device-pixel-ratio)が通常のスクリーンの2倍であることを意味する.CSSと比較する、本来cssに設定されているのは1 pxであり、実際の画面表示時でも1 pxである.しかし、retinaではcssの1 pxが実画面の2 pxである.
その結果、
何がこんなことになるのかと思う同級生がいます.名前が同じ大きさに見えるのに、どうして画像がぼやけているのですか?これは実際にはビットマップの特性である.例えばjpgファイルのサイズは200です×300.では、彼の実際のスクリーン画素は200 pxです.× 300px. dpr=1の画面に配置し、サイズを次のように設定します.
これにより、当然正常に表示することができる.しかしretinaではcss pxごとに2倍のpxに等しい.これにより、正常に表示する画像が2倍に拡大する.元の画像上の各点は、dpr=1の画面にちょうど置くことができるが、dpr=2の場合、各点が分割されるため、鋸歯がぼやけてしまう現象がある.
解決策もたくさんある.
この方法は背景図の追加に適用する.css 3が提供するdevice-pixel-ratio queryを用いて実行する.簡単なdemoは、
しかし、このようなコストはとても大きくて、その上毎回2部を用意して、いくつかの価値の特に低い仕事をしなければなりません.
冗長なcssコードを上に書くほか、jsを用いて判断することもできる.そして、data-srcの内容を置き換えるリロードを行う.
また、この属性の支持度は非常に高く、基本的にはすべての携帯電話端末とPCが支持しており、IE 8を除く.
Webではベクトルマップを用いる方法が多い.例えばSVG、Fonts.この2つは、最適なはずですが、図を描く場合、ほとんどがビットマップの形式なので、SVGとfontsに変換する必要があるのは、ちょっと難易度が高いです.いくつかの小さなロゴとiconにとって、まだ大きな問題はありません.また、上記の2つの態様で占有する空間の大きさも小さい.
現在、携帯電話の問題はjsスクリプトではなく、ページでレンダリングされています.なぜなら、携帯電話の画面表示はすべてCPUによる処理であるからである.PC端末のように画像を描くための独立したグラフィックスカードはない.
一般に、入力する要素ラベル、例えばinputはフォーカスを取得するとキーボードのポップアップをトリガーする.しかし、iosとアンドロイドでは、両者のキーボードのポップアップの処理方式が異なる.
キーボードのレンダリングには、次の2つの方法があります. inputがキーボードの上にある場合、コントロールを少し上に押してキーボードの上を導くだけです. inputがキーボードの下にある場合、キーボードはそのコントロールを上書きし、コントロールがキーボードの上に押されるまでページ全体を押し上げる.
また、ios 7の場合、fixed属性である要素がある.では、このときキーボードを開くとfixedがabsoluteとしてレンダリングされる可能性がある.だから、これは本当に問題です.
同様に、二つの場合もある.第1種大丈夫 の2つ目は、inputがキーボードの下にあると、コントロールの高さがキーボードの高さを超えるまでdocument全体の高さが増加する.
Androidがdocument全体を押し上げる場合、絶対位置決めとfixed属性位置決めについて.一定の問題がある.追加documentはviewportの位置を高くしていないため、fixedを使用するとエレメントがキーボードの下に走る可能性がある.しかし、キーボードはブラウザ全体の上にあるため、キーボードを上書きすることはできません.一般的な解決策は、入力focusイベントを傍受してfixedの位置を動的に設定することである.(でも複雑ですね).
異なる入力に対して、キーボードに表示するタイプは実際には異なり、一般的に互換性が良いのはデジタル/携帯電話番号である.次のように設定できます.
ユーザがinputのfocusイベントをトリガしない場合.開発者が人工的に触発したもので、ここには2つの異なる状況がある.
IOS
ios 6以前、コントロールがfocusイベントをトリガーするが、focusはユーザがトリガーするものではない、キーボードは弾けない.ios 6以降、
Android
ユーザがトリガしない限り、弾き出すことはできない.
キーボードの格納キーボードの格納はjsのblurイベントを直接トリガすればよい.
ページスクロールに2つのイベントが設計されています.1つはscrollで、1つはtouchmoveです.携帯端末は、性能の問題を解決するために、ページをスクロールする場合、jsによるダイナミックレンダリングは無効である、すなわち、jsを用いてページ上の要素の位置を変更することは無効である.ページのスクロールが終わることを知っています.この効果は主にscrollイベントのトリガのメカニズムに現れる.ios 8以下では、ページがスクロールするとjsのレンダリングが一時停止する.一方、Andriod 4.0以上ではscrollトリガは連続スクロールである.ローカルスクロールを設定する場合は、
歴史的な理由から、web上でflexの効果を実現したい.flexには3つのバージョンがあり、3つのバージョンのサポート性が異なるため、互換性に注意する必要があります.それぞれ: display: box display: flexbox display: flex
AndroidはWebkitオープンソースカーネルを使用しているため、flexにwebkit接頭辞を付けて低バージョンのAndroidと互換性を持たなければなりません.
現在の互換性は次のとおりです. oldはdisplay:boxを使用しています. tweenerはdisplay:flexboxを使用しています. newはdisplay:flexを使用しています.
Mobileでfixedを使うのは複雑な問題です.なぜなら、iosとandroidの異なる効果に鑑みて、入力時にキーボードのポップアップを設計することが多いからである.fixedはキーボードのイジェクト時にずれが発生する可能性がある.例:
具体的な参考:fixed.ios 5以前はfixedをサポートしていなかったが、androidは4.x以降、fixedは基本的に使用可能である.
clickの遅延は、web携帯電話が開発した穴だろう.メーカーが携帯電話端末を設計する際、主に、スケールのことを考慮しているからだ.すなわち、最初にクリックするとclick時間がトリガーされず、ブラウザは300 msの遅延を待ち、300 ms内で再度クリックしたかどうかを判断し、あればzoom inの効果をトリガーします.その後、300 msの遅延がキャンセルされるとともに、長押しして選択するテキストもキャンセルされる.後でだめだと思って、また加えた.Chrome 32+では、IE/FFはOkです.最近ではIOS 9.3でも修復する.しかし、前期はheadラベルに追加する必要があります.
あるいは特定のtagに特定のcss属性を加える
でもFFは支持しない.
このfeatureは比較的古典的だと思います.カバー層がaラベルに覆われると.
touchmoveをレンダリングトリガとして使用しないでください.touchmoveのメカニズムはブラウザ自身が決定するからです.彼がトリガーする回数は限られている.したがって、touchmoveを利用してデータを取得するのが一般的であり、レンダリングにはrequestAnimationFrameを使用する必要がある.
メディアクエリーメカニズムはcss 2ですでに提案されている.たとえば、プリンタの場合:
しかし、css 3では、メディアクエリのメカニズムが補完する.また、IE 8以外のブラウザや携帯端末はサポートする.彼の主な用途はやはり携帯電話端末、PC端末、画面の大きさなどを区別することだ.
まずdemoを見てみましょう.
設定画面のサイズが[641800]の間であれば、
metaは主にウェブページのソース情報を設定するために用いる、例えば、スケール、幅などである.一番よく使われるのは携帯電話です
ここでは毛皮を整理しただけで、興味のある学生は、他の2つの文章を参考にすることができます.
モバイルウェブ問題のまとめ無線Web開発経験談
後で穴の問題に遭遇したら、すぐに更新します.
retinaピクチャ互換
このfeatureは携帯電話端末だけでなく、PCも含まれているはずです.アップルは携帯電話端末だけでなく(iphone 4から)、MACにもretinaを使用しているからです.まずretinaは、dpr(device-pixel-ratio)が通常のスクリーンの2倍であることを意味する.CSSと比較する、本来cssに設定されているのは1 pxであり、実際の画面表示時でも1 pxである.しかし、retinaではcssの1 pxが実画面の2 pxである.
その結果、
何がこんなことになるのかと思う同級生がいます.名前が同じ大きさに見えるのに、どうして画像がぼやけているのですか?これは実際にはビットマップの特性である.例えばjpgファイルのサイズは200です×300.では、彼の実際のスクリーン画素は200 pxです.× 300px. dpr=1の画面に配置し、サイズを次のように設定します.
width: 200px;
height:300px;これにより、当然正常に表示することができる.しかしretinaではcss pxごとに2倍のpxに等しい.これにより、正常に表示する画像が2倍に拡大する.元の画像上の各点は、dpr=1の画面にちょうど置くことができるが、dpr=2の場合、各点が分割されるため、鋸歯がぼやけてしまう現象がある.
解決策もたくさんある.
Media queryの使用
この方法は背景図の追加に適用する.css 3が提供するdevice-pixel-ratio queryを用いて実行する.簡単なdemoは、
#myimage {
width: 400px;
height: 300px;
background: url(lo-res.jpg) 0 0 no-repeat;
}
// Android
@media
screen and (-webkit-min-device-pixel-ratio: 1.5),
screen and (min--moz-device-pixel-ratio: 1.5),
screen and (-o-min-device-pixel-ratio: 3/2),
screen and (min-device-pixel-ratio: 1.5) {
#myimage {
background-image: url(hi-res.jpg);
}
}
// , :
@media only screen and (-webkit-device-pixel-ratio: 2),
only screen and (-moz-device-pixel-ratio: 2),
only screen and (-o-device-pixel-ratio: 2/1),
only screen and (device-pixel-ratio: 2) {
#myimage {
background-image: url(hi-res.jpg);
}
}しかし、このようなコストはとても大きくて、その上毎回2部を用意して、いくつかの価値の特に低い仕事をしなければなりません.
jsを用いて判断する
冗長なcssコードを上に書くほか、jsを用いて判断することもできる.そして、data-srcの内容を置き換えるリロードを行う.
if (window.devicePixelRatio > 1) {
var images = $("img");
images.each(function(i) {
var x1 = $(this).attr('data-src');
$(this).attr('src',x1);
});
}また、この属性の支持度は非常に高く、基本的にはすべての携帯電話端末とPCが支持しており、IE 8を除く.
ベクトルマップの使用
Webではベクトルマップを用いる方法が多い.例えばSVG、Fonts.この2つは、最適なはずですが、図を描く場合、ほとんどがビットマップの形式なので、SVGとfontsに変換する必要があるのは、ちょっと難易度が高いです.いくつかの小さなロゴとiconにとって、まだ大きな問題はありません.また、上記の2つの態様で占有する空間の大きさも小さい.
携帯電話の基本
現在、携帯電話の問題はjsスクリプトではなく、ページでレンダリングされています.なぜなら、携帯電話の画面表示はすべてCPUによる処理であるからである.PC端末のように画像を描くための独立したグラフィックスカードはない.
携帯のキーボード
一般に、入力する要素ラベル、例えばinputはフォーカスを取得するとキーボードのポップアップをトリガーする.しかし、iosとアンドロイドでは、両者のキーボードのポップアップの処理方式が異なる.
iosのキーボード
キーボードのレンダリングには、次の2つの方法があります.
また、ios 7の場合、fixed属性である要素がある.では、このときキーボードを開くとfixedがabsoluteとしてレンダリングされる可能性がある.だから、これは本当に問題です.
Androidのキーボード
同様に、二つの場合もある.
Androidがdocument全体を押し上げる場合、絶対位置決めとfixed属性位置決めについて.一定の問題がある.追加documentはviewportの位置を高くしていないため、fixedを使用するとエレメントがキーボードの下に走る可能性がある.しかし、キーボードはブラウザ全体の上にあるため、キーボードを上書きすることはできません.一般的な解決策は、入力focusイベントを傍受してfixedの位置を動的に設定することである.(でも複雑ですね).
FDタイプ
異なる入力に対して、キーボードに表示するタイプは実際には異なり、一般的に互換性が良いのはデジタル/携帯電話番号である.次のように設定できます.
input[type=tel]
input[type=number]フロッピーディスク
ユーザがinputのfocusイベントをトリガしない場合.開発者が人工的に触発したもので、ここには2つの異なる状況がある.
IOS
ios 6以前、コントロールがfocusイベントをトリガーするが、focusはユーザがトリガーするものではない、キーボードは弾けない.ios 6以降、
autofocusの属性を手動で追加すればよい.Android
ユーザがトリガしない限り、弾き出すことはできない.
キーボードの格納キーボードの格納はjsのblurイベントを直接トリガすればよい.
ページスクロール
ページスクロールに2つのイベントが設計されています.1つはscrollで、1つはtouchmoveです.携帯端末は、性能の問題を解決するために、ページをスクロールする場合、jsによるダイナミックレンダリングは無効である、すなわち、jsを用いてページ上の要素の位置を変更することは無効である.ページのスクロールが終わることを知っています.この効果は主にscrollイベントのトリガのメカニズムに現れる.ios 8以下では、ページがスクロールするとjsのレンダリングが一時停止する.一方、Andriod 4.0以上ではscrollトリガは連続スクロールである.ローカルスクロールを設定する場合は、
-webkit-overflow-scrolling: touch cssプロパティを追加できます.flex問題
歴史的な理由から、web上でflexの効果を実現したい.flexには3つのバージョンがあり、3つのバージョンのサポート性が異なるため、互換性に注意する必要があります.それぞれ:
AndroidはWebkitオープンソースカーネルを使用しているため、flexにwebkit接頭辞を付けて低バージョンのAndroidと互換性を持たなければなりません.
display: -webkit-box;
display: -moz-box;
display: -ms-flexbox;
display: -webkit-flex;
display: flex;現在の互換性は次のとおりです.
fixed問題
Mobileでfixedを使うのは複雑な問題です.なぜなら、iosとandroidの異なる効果に鑑みて、入力時にキーボードのポップアップを設計することが多いからである.fixedはキーボードのイジェクト時にずれが発生する可能性がある.例:
具体的な参考:fixed.ios 5以前はfixedをサポートしていなかったが、androidは4.x以降、fixedは基本的に使用可能である.
touchイベント解析
300 ms click遅延
clickの遅延は、web携帯電話が開発した穴だろう.メーカーが携帯電話端末を設計する際、主に、スケールのことを考慮しているからだ.すなわち、最初にクリックするとclick時間がトリガーされず、ブラウザは300 msの遅延を待ち、300 ms内で再度クリックしたかどうかを判断し、あればzoom inの効果をトリガーします.その後、300 msの遅延がキャンセルされるとともに、長押しして選択するテキストもキャンセルされる.後でだめだと思って、また加えた.Chrome 32+では、IE/FFはOkです.最近ではIOS 9.3でも修復する.しかし、前期はheadラベルに追加する必要があります.
//
あるいは特定のtagに特定のcss属性を加える
html {
touch-action: manipulation;
}でもFFは支持しない.
click点透過
このfeatureは比較的古典的だと思います.カバー層がaラベルに覆われると.
此时, model 是覆盖在 a 标签上的. 当点击罩层, 罩层消失. (罩层绑定的是 tap 事件) 由于, click 事件有 300ms 时延, 所以, 此时 a 标签的跳转效果会触发.
解决办法是:
设置罩层延时消失效果. 延时时间设置为 300ms+ 即可.
在 touchend 里面执行 preventDefault()
使用插件禁止掉 click 事件, 转而使用模拟的.
タッチイベントの詳細
在手机上是没有关于鼠标的相关操作的, 比如 hover, mouseover, mousenter等等. 只有, 相关的 touch 事件.
touchstart 当第一根手指触摸到屏幕时, 触发.
touchmove 当某一个手指在屏幕上移动时, 触发.
touchend 当手指从屏幕上移开时, 触发.
touchcancel 当手指触控被打断时触发. 具体有一下几种.
-
其他事件的发生打断了 touch 事件. 比如, js 操作强制跳转
-
当浏览器的 UI 覆盖到当前的 web 上
-
触摸的手指数超过了浏览器的支持数量. 如果发生, 那么第一根触摸的手指会被取消
// 暂不支持下列两个事件
touchenter 当手指进入指定元素
touchleave 当手指移出指定元素
因为在触发 touch 事件时, 不仅仅只是相关的 touch 事件会触发, 还会触发相关的 mouse 和 click 事件. 所以, 如果 mouse 和 click 事件有影响时, 则需要显示的使用 event.preventDefault() 取消掉后面的触发机制.
在每个 touch 事件里面, 还会返回挂载到 event 上的属性, 常用的有:
touches: 当前屏幕上的属性
targetTouches: 在指定 DOM 元素上的属性
changedTouches: 返回触发时间的相关手指数. 比如, touchmove 事件中, 返回正在移动的手指. 在 touchend 事件中, 返回移除的手指.
并且每一个 touch 上面都会附带相关的属性.
identifier: 每一个手指独一无二的 ID
target: 返回一开始触发 touch 事件的 DOM 元素
screenX/Y: 返回相对于整个手机屏幕而言的位置.
pageX/Y: 返回相对于整个页面的位置, 包括 scroll 的距离.
clientX/Y: 返回相对于浏览器 viewport 的位置. 不包含 scroll 的距离.
radiusX/Y: 返回手势椭圆的长轴和短轴的大小. 目前来说, 还不支持. 和 screenX/Y 有点类似.
touchmoveの穴
移动而不滚动
当触发 touchmove 时. 如果,不加限制的话, 往往会触发 scroll 的效果. 为了消除这样的问题, 只需要将默认行为禁掉就 ok.
document.body.addEventListener('touchmove', function(event) {
event.preventDefault();
}, false); touchmoveをレンダリングトリガとして使用しないでください.touchmoveのメカニズムはブラウザ自身が決定するからです.彼がトリガーする回数は限られている.したがって、touchmoveを利用してデータを取得するのが一般的であり、レンダリングにはrequestAnimationFrameを使用する必要がある.
var touches = []
canvas.addEventListener('touchmove', function(event) {
touches = event.touches;
}, false);
// Setup a 60fps timer
timer = setInterval(function() {
renderTouches(touches);
}, 15);メディアクエリ
メディアクエリーメカニズムはcss 2ですでに提案されている.たとえば、プリンタの場合:
しかし、css 3では、メディアクエリのメカニズムが補完する.また、IE 8以外のブラウザや携帯端末はサポートする.彼の主な用途はやはり携帯電話端末、PC端末、画面の大きさなどを区別することだ.
画面サイズ
まずdemoを見てみましょう.
設定画面のサイズが[641800]の間であれば、
ipad.cssがロードされる.一致しない場合、ブラウザはこのtagをデフォルトで無視します.そのうちonlyというflagは非常に重要である.彼の主な役割はブラウザが一致しなければ無視するルールを教えることだ.画面の大きさでmobile,pad,PCを判断することが有用である.metaラベル
metaは主にウェブページのソース情報を設定するために用いる、例えば、スケール、幅などである.一番よく使われるのは携帯電話です
//
// ;ここでは毛皮を整理しただけで、興味のある学生は、他の2つの文章を参考にすることができます.
モバイルウェブ問題のまとめ無線Web開発経験談
後で穴の問題に遭遇したら、すぐに更新します.