携帯で画像振り分けで行なってきたこと
昨日、社内勉強会を開き、うちの会社でこれまで行なってきた、携帯への画像関連のことを話しました。
社内blogにも書いていたので、かける範囲でこちらにも転載してみます。
携帯向けのサイトでの画像
携帯向けのサイトで画像を使いたい場合、いくつかの超えるべき障害があります。
- 画像の種別(jpeg/png/gif)
- 端末ごとの対応画像
- 画像のサイズ(大きさ)
- 画面サイズ
- 画像の容量(ファイルサイズ)
- キャッシュサイズ
画像の種別
画像の種別は、キャリアによって対応状況が違います。
- DoCoMo
- 古い端末 → gifのみ
- 最新機種 → jpeg/gif (pngは未対応)
- au
- 古い端末 → pngのみ
- 最新機種 → jpeg/png/gif
- SoftBank
- 古い端末 → pngのみ
- 最新機種 → jpeg/png/gif
DoCoMoは、古い端末では、gifしか対応していません。
新しい端末でも、jpeg、gifのみの対応で pngファイルは未対応です。
auは、古い端末で、pngのみの対応という端末があります。bmp(ビットマップ)も対応している端末がありますが、こちらは論外で。
対応機種に入る範囲では、jpeg/png/gifのすべてに対応していると考えて大丈夫でしょう。
SoftBankは、古い端末では、png/jpgeで逆にgifに対応していません。
最近の端末は、jpeg/png/gifのすべてに対応しています。
画像の種別として、会社ロゴやアイコンなど、色数が少ないアイコンは、gif/pngの方がきれいに見え、逆に写真やグラデーションのあるものはjpegという選択肢になると思います。
携帯向けの話で、さらにある程度古い機種を考えた場合、アイコン系ではキャリアによって画像の種別を変える必要が出てきます。
- アイコン系 > DoCoMo・au=gif、SoftBank=png
- 最近はgifで統一でも大丈夫になってきた
- 写真系 > jpeg
- 昔はjpeg非対応端末のことを考えなければならなかった・・
画像のサイズ
画像の大きさは、まぁ、見た目のとおりディスプレイサイズが違うので、端末ごとに分けなければならないのはわかりやすいと思いますが、その中でもいくつか種別があります。
- 最新機種 >基本はQVGA
- 240x320
- SoftBankで、VGAの端末もある
- 480x640
- QVGAでも auの場合にスクロールバー分少し小さい
- 230x348
- 縦の長さは QVGA内でも差がある
- 240×256、240×320、240×400、240×432
端末の画面サイズより大きな画像を表示させようとすると、端末側で自動縮小がかかりますが、横幅を調整したい場合には、やはり画像自体での対応が必要になります。
例えば、画面サイズに対して 50%のロゴを表示したい場合に、画面サイズが小さいと、いっぱいにひろがった状態で表示されてしまったりします。
画像容量
携帯端末では、キャッシュサイズという制限があります。
これは、1ページを表示する時に、サーバから文章や画像等を全て合わせて処理できる容量です。
キャッシュサイズが小さいと、当然、1ページ内で扱える画像に容量に制限がでてきてしまい、場合によっては表示できなかったりすることになります。
このキャッシュサイズは、対応端末をしぼる理由の1つだったりします。うちで一般的な案件で対応している端末で、最小のキャッシュサイズは、DoCoMoの P505系、P504系です。
同じ 505系でも Pだけ少ない…
開発する側からすると、早く切り捨てたいですね。movaとか。
これまでの取り組み
うちの会社でこれまで行なってきた方法です。
- 〜2004年中ごろ
- テンプレートに直で拡張子のみ切り替え
- 2004年中ごろ〜2005年2月ごろ
- 動的に拡張子切り替え
- 2005年2月ごろ〜
- 動的に拡張子のみ+画像サイズ切り替え
- 2006年2月ごろ〜
- 画像変換ASP導入
- 2008年2月ごろ〜
- 自社で画像変換ライブラリ作成
〜2004年中ごろ
当時は、jpeg対応端末が、まだ、ほとんど無かったので、拡張子のみの切り替えをしていました。
テンプレートも、phpファイルとして記述して、includeする形式でした。
phpプログラム側で以下のようにキャリア判別をし、
<?php //色づけ switch($__AGENT__){ case "DoCoMo": $ext = 'gif'; break; case "UP.Browser": // au $ext = 'gif'; break; case "J-PHONE": $ext = 'png'; break; }
テンプレートとなるphpファイルで次のように記述していました。
<?php //色づけ <img src="images/logo.<?= $ext ?>">
過去のソースあさってたら、J-Phoneとか出てきた。懐かしいですねー
この頃は、もうVodafoneだったのかな?
問題点
- デザイナーさんがローカル環境で作成時に確認できない
- 画像種別切り替えしかできない
- あらかじめ画像を作っておかないといけない
デザイナーさんが作成時に確認できないというのと、あらかじめ画像を作らなければならないのは、作業工数が増える要因でした。
2004年中ごろ〜2005年2月ごろ
画像の切り替え自体は、以前と同じ拡張子のみでしたが、ob_startのフィルタや、Smartyのポストフィルタを使用し、動的に拡張子を書き換えるようになりました。
html上は通常のタグ表記になります。
<img src="images/logo.jpg">
php側で、ob_startで imgタグのsrc属性の中身を書き換える処理を登録しておきます。
このフィルタ内では、preg系の関数でごりごり正規表現で置換しています。
問題点
2005年2月ごろ〜
変換する画像パスにサイズ指定も盛り込むことで、画像の種別だけでなく、サイズも切り替えて出せるようにしていました。
この頃から、jpeg対応の端末が増え、QVGA端末も出てきました。
jpegは少し大きめ、という対応だけでは足りなくなってきたので、L,M,Sの3種類を作成し、それを切り替えるようになりました。
例えば、以下のように3種類のサイズの違う画像を用意します。
- logo_l.jpg
- logo_m.jpg
- logo_s.jpg
html上は、logo_l.jpgの Lの画像を指定するようにし、この命名規則の画像は、アクセス元の端末により、切り替えて出力するという仕組みです。
<img src="images/logo_l.jpg">
この画像識別の設定値は、iniファイルで設定できるようになっていて、端末の画面サイズ、キャッシュサイズ、対応画像などをパラメータとして、変換方法を簡単に設定できる仕組みを作っていました。
いまでも、軽い案件では、このフィルタを使う場合があります。
問題点
- 画像種別切り替えしかできない → 解決!!
- あらかじめ画像を作っておかないといけない
- 作らなければならない画像が増えたので、画像加工のコストは増大…
2006年2月ごろ〜
この頃、ある案件から画像変換ASPを導入しました。画像変換ASPに元画像を渡すだけで、アクセスしてきた端末に最適化した画像を自動的に変換してくれます。
これにより、残っていた最後の問題も解決しました。
問題点
- あらかじめ画像を作っておかないといけない → 解決!!
- 画像変換ASPのコストがかかる
また、一般的に画像変換ASPの仕組みとして、htmlの imgタグにASPのURLを記述する方式になってしまいます。
例)
<img src="http://example.com/XXXXXX/images/logo.jpg" />
※example.comが画像変換ASPのサーバ
ちょっとわかりにくいかもしれませんが、携帯から直接画像変換ASPに画像を取得しにいくことになります。
これでは、ローカル環境で確認できないという問題が再発してしまいます。
また、ステージング環境、本番環境といった、環境差異の吸収も出来なくなってしまいます。
これの解決策として、うちでは、画像自体をphpとして起動させ、その中で処理をわけさせるようにしています。
画像自体をプログラムとして使うことになるので、html上は通常の相対パスの画像指定にすることが出来ます。
<img src="images/logo.jpg" />
画像を置いているディレクトリ内の .htaccessで次のような指定をします。
AddType application/x-httpd-php .gif .png .jpeg .jpg .GIF .PNG .JPEG .JPG <FilesMatch "\.(gif|jpe?g|png|GIF|JPE?G|PNG)"> php_value auto_prepend_file "/path/to/_image.php" </FilesMatch>
これで、指定した拡張子にアクセスした場合に、phpとして起動し、/path/to/_image.php が実行されます。
このphp内で、環境差異の吸収をし、バック通信で画像変換ASPに接続し、変換した画像を取得する処理をします。
2008年2月ごろ〜
今年の、2月から、画像の変換する処理を作成し、画像変換ASPを使用せずに、各端末用に変換した画像を返せるようになりました。
問題点
- 画像変換ASPのコストがかかる → 解決!!
画像変換を自前で行なうためには、各端末の画面サイズなどの詳細な情報が必要になりますが、こちらは別途購入している情報を使用しています。
この機種別プロファイルの各サーバへの配布方法などもいろいろ工夫しているのですが、それはまた別のお話で。
画像変換自体には、それなりに変換コスト(時間的な意味で)がかかるのですが、一度作成してしまえば、それ以降はキャッシュが聞くので、秒間さばける数も現実的な数値になっています。