HOME’Sのサイト開発@なかじま

自己紹介

名前

なかじまたくや (勤続7年目くらい)

普段の業務内容

サイトの機能開発を自由にやってます

得意な領域

フロントエンド(主にJS)だけど、一人プロジェクト多いのでだいたいどこの領域もやることが多いです

今日の話

ユーザー視点の開発…

は、僕は特にしてないので語れることはなかった

UX界隈の人すぐ斧なげるから怖い

代わりに地図系のサイト作った時に得た知見とかの話

僕の思う「使い勝手」を追い求めてみた話

地図系のサイト

緯度経度で何か検索して地図上に表示させるよくあるやつ

地図検索系あるある

• 地図検索系ってそんなにバリエーションがないから結構共通の苦悩と戦うことになると思う

あるある1

• 検索クエリ(緯度経度)が毎回違うから検索エンジン側のキャッシュが効かなくてパフォーマンスでない

＼ちょっと移動／

検索クエリ(緯度経度)

が微妙にかわる

あるある２

• 地図移動前と移動後で表示領域のかぶり多いのに全部検索しなおたりして無駄だなーって憂鬱になる

＼ちょっと移動／この部分は前の表示領域一緒なのに・・・

あるある3• 超でかいディスプレイで操作されると検索範囲広がってパフォーマンスでない(スケールとかの恩恵受け辛い)

一回の検索範囲が大きいいくつかに分けたい…

あるある4

• マーカーとかポリライン沢山ひくとなんか動作がほんのりもっさくなる

Google Maps自身はあんなにシームレスでサクサクなのに！

僕らもサクサクでストレスレスなユーザー体験を提供した

い！！

Google Mapsの実装を探る

なんでそんなサクサクうごくの(*？_？*)

基本編

Google Mapsはいかにして継ぎ目のない描画を実現しているの

か

地図そのものの表示

小さな画像をタイル状に敷き詰めて表示させてる

彼らは地図をタイルごとに読み込むことで、地図の移動時に差分となるタイルだけを描画している

タイルについて考える

zoom lv. 0

zoom lv. 1

0,0

0,1

1,0

1,1

0,0

タイルの開始点

緯度経度: (85.05112877980659,-180)

赤道を256pxとして表現する時にいい感じに収まる座標

pixel座標と緯度経度の変換

function fromLatLngToPoint(lat, lng) {

var x, y;

x = (lng + 180) / 360 * 256;

y = ((1 - Math.log(Math.tan(lat *

Math.PI / 180) + 1 / Math.cos(lat *

Math.PI / 180)) / Math.PI) / 2 *

Math.pow(2, 0)) * 256;

return {x: x, y: y};

}

function fromPointToLatLng(x, y) {

var lat, lng, n;

lng = x / 256 * 360 - 180;

n = Math.PI - 2 * Math.PI * y / 256;

lat = (180 / Math.PI * Math.atan(0.5 *

(Math.exp(n) - Math.exp(-n))));

return {lat: lat, lng: lng};

}

ってstack overflowが言ってたよ

中級編

Markerとかってどうやってるの

Markerを調べる

MarkerはCanvasで作られていた

複数のmarkerでも収まれば1つのcanvasで表示→ 省エネ

PolyLine & Polygon

Google Maps APIのだいたいのやつはCanvasで作られていた

ぐう有能

Markerとか一つ一つ要素作ってstyle当ててたらコスト高すぎてこのパフォーマンスは実現できない

canvasでの描画

• 大量のDOMを作るよりタイルシステムの規格通りのcanvas作ってその上で描画する方がコストが低い

• でも、描画情報しかないんならmarkerクリックできないのでは？？？？？？？

• クリックできたりhoverしたらカーソルがかわったりするけど？？？？？？？

canvasとマウスアクション

カーソルがcanvas上のマーカー描画位置にきたら地図コンテナ自身のcursor値を変更してる！！！！

canvasあるいはそれより上位の要素にイベントを割り当てて、mousemove時に座標判定して該当マーカーがある時に処理するというガチなやつで実装してるみたい

canvasとマウスアクション

デフォルトのpoiとかは

時々リクエストに紛れてるこいつらがが座標情報なんじゃないかな

融通効かないとこ

でもその割に、1マーカーに1つずつevent設定していくしかないのはもったいないような…

全部のマーカーに共通のイベント張る時とかコストが勿体ない

まぁなにはともあれ

この辺の仕組みが地図アプリのパフォーマンスの肝になってる

• タイル化することで とかも可能になる

• 何かを検索して地図上にプロットする系のサイトもタイルごとに検索を行えば同タイルの時に発生するリクエストは全部同じ座標になるためある程度Cacheできる

• MarkerのCavans化も自前でやっちゃえばイベントハンドラ周りとか、さらにいい感じに省エネ化できる

サクサクさせるために模倣する

• Google Mapsのタイル規格と同じタイルのレイヤを作り、それぞれマーカーCanvasを自作する

＼きえた／

実際の仕上がりと操作感

継ぎ目ない感じでてる！検索もキャッシュ効くからはやい！

操作感をより上げるための細かいチューニング

• 単純にcanvas化しまくるとどこかでメモリ溢れるから描

画領域から離れたタイルは描画座標だけ記憶してすぐ復元できる状態だけ作って消したり

• retina対応とかは解像度みてやる必要があるか判定したり

• 検索エンジン側(solr)でfilter query利用してcacheできるようにしたり

二度と同じ実装したくないのでライブラリ化

そんな感じで日々HOME’Sの中の人は自分の思う「よりよい使い勝手」を探し求めて今日も実装しています

終わり

1 more slide

ネクストではいい感じのiOSエンジニアとWebエンジニアを

募集しています！

本当におわりです！