おまぬけ活動日誌(2013-05-15)

2013年05月15日(Wed) Google I/O 2013 Day 1 [長年日記]

● 名物シングルスレッド待機列

食べる

正確には2並列のところもありましたが。

● [io13] キーノート

今年のキーノートは一日目の午前中全部を使うという長丁場でした。内容は、Googleによる録画や各記事 (adakoda.com*1)に譲るとして、多数の大画面で見る映像は楽しいものです。

前方のスクリーン後方のスクリーン

疲れたらGDGラウンジで中継を見るのも一興です。僕なんか昼ももらってきちゃったよ。

GDGラウンジでのキーノートの中継

上記も含めてキーノートの雰囲気のわかる写真を置いておきますね。

*1 すばらしい一覧をありがとうございます

● [io13] What's New in Android Developer Tools

Googleによる録画あれ？メモが残ってないよ。 Android Studio (version 0.1だ!)の紹介。

Some part are rock solid. Some part are not

● [io13] The Next Frontier: Indoor Maps

Googleによる録画。この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

現状での測地精度。GPSは15m (屋内不可)、Wifiは25m。屋内で自分の位置を知るには精度が足りない。気圧計で高度が測れるが気圧の変化は±20ほどでどの階に居るかわからない。

しかし今後Indoor mapの需要は増えるだろう。インターネットのドメイン名が1999年ごろに爆発的に増え (1999年に150万を突破し、現在450万)て今はwwwページの無い企業が時代遅れに見えるように、 Indoor mapの無い場所*1が時代遅れになるかもしれない。この講演ではIndoor mapの現状を説明します。サンフランシスコ空港ではエスカレータも含めた徒歩ナビゲーションができるし、 Smithonian Air & Space Museumでは飛行機のかたちがわかる。

Indoor mapに必要なもの。地図のカバレッジ、High quality indoor location。これらをセルフサービスで用意できるようになっている。

High quality inddor locationの用意。 AndroidにFused locatin providerが用意されていて、 GPSだけでは測地できない場所でもなんとかできる。 Google Maps Floor Plan Markerを起動して、端末を持ち歩きながら、現在地をIndoor mapに記録していく。この結果をGoogleに送信しておくと、端末が感じているGPS信号WiFi信号加速度計ジャイロなどのセンサの記録と照合して、ユーザーの現在位置を推定できるようになる。

WiFiは測地用には作られていなくて、特にアクセスポイントと端末の間に人間が入ると結果が狂うのだけれど、とにかくたくさんあるので活用できる。 (測地用に使うことのできるWiFiの規格も提案されている。 )

Fused location serviceには、電池の消耗を抑えつつユーザーが歩いているか自転車に乗っているか自動車に乗っているかを判断できる機能もあり、今後、コンテクストを考慮した屋内での測位の結果の利用が進むだろう。たとえば、モールで友だちを見つけるとか、近くの店によって検索結果を最適化するとか。

*1 商業施設のことかな

● [io13] Design Decisions in AngularJS

AngularJSに込めた指針: D.R.Y.、Structure、Testability

Google Feedbackは17k行だったのが、 AngualrJSでつくりなおしたら3週間かかって1.5k行になった。

1ページウェブアプリのデータの流れ。 DOMとそれに対応するメモリがブラウザの中にあり、メモリの内容がデータベースとやりとりする。それをAngularJSで単純化(simpify)したい。

DOMをテンプレートとして活用する

ロジックの導入、MVCへの分離。index.htmlから例えば下記のようなコントールを呼ぶ (動画8:20付近)。 UI/View/DOMが、Logic/Controllerを通して、あるいは、直接に、 Data/Modelとやりとりをする。

Dependency Injection。動画12:50付近

の替わりに、動画13:10付近

などとできる。(この記事の執筆時よくわかってない（´・ω・｀）

Imperative worldとDeclarative world。AngularJSではどちらも使える。

● [io13] A Trip Down Memory Lane with Gmail and DevTools

パフォーマンスとメモリの関係。使うメモリを増やせば速度は速くなるという逸話は本当か？

ChromeでGMailがメモリを食うというハナシがあった。本当か？Googleの同僚も言ってる。パワーユーザーだけ？検証しようにもデータが無かった。 Chromeは各タブにプロセスを割り当てるが、プロセス数が最大を越えると1つのプロセスが複数のタブを管理するよになり、プロセスあたりのメモリ使用量が増えることになる。

基本 - Javascriptのメモリ管理。 Javascriptの型は、Boolean、Number、String、Object、External object。これだけ。プログラムから見えないroot node ("e;document"e;)から参照している先のnode/valueがあり、 Object nodeが参照を続け、Scalar nodeで参照木が終端される。 Root nodeから続くRetaining pathによって参照されているnodeは Garbage correction (GC)されないが、 Root nodeから届かないnodeはGCされる。 GCはRoot nodeから届くLive valueを見つけて、そうではないDead valueを改修する。ここで、「Retaining size」は、そのnodeを消すとGCできるようになるnodeの数。

V8でのメモリ管理。 Javascriptからnewを呼ぶコストは、通常は小さく、メモリの割り当ては速い。しかし、GC(Chromeの場合はgenerational GC)が必要になると 10msec程度のGC Pauseが起きることになってしまう。 V8の世代別GCでは、 Young generationの割り当ては速く、長い間生きてきたValueの回収*1は速く、頻繁に回収されれう。これに対して、 Old generationの割り当ては速いが、回収は遅く、時々しか行なわれない。 GCのコストはLive valueの数に比例するので、 Young generationの回収を頻繁に行うことで、速度を保つ。

Young generationのGC。 To spaceとFrom spaceのふたつのメモリ領域があり、普段はTo spaceに新しいnode/valueのメモリが割り当てられる。 To spaceが足りなくなると、GCとPage pauseが起きる。 To spaceへのポインタとFrom spaceへのポインタが交換され、 From space中のlive valueをマークして、To spaceにコピーする。

Crhomeで使えるツールやテクニック。 Chrome 22からwindow.performance.memoryでメモリの状況

jsHeapSizeLimit
totalJSHeapSize
usedJSHeapSize

が得られるので、これをUIのレイテンシと一緒に記録しておく。これで、メモリ使用量が多いほどUIが遅いことがわかった。

Chrome developer tool。右上の「Hot dog menu」から辿るかCtrl+Shift+IでDeveopler Toolsを開く。たとえばメモリのTimelineを見ると、ゴミ箱アイコンから強制的にGCしても開放されないメモリリークの量を確認できたりする。

Object Tracker/Heap Profiler。現在はCanaryのみ。タイムラインと一緒に、ヒープのプロファイルを記録できる。 Profile - Track Allocations。記録が終わった時に開放されていないnode/valueがいつ割り当てられたかわかる。

気をつけるべきポイント。あなたの書いたページはどれだけのメモリを使っているか、メモリリークはないか、 GCの頻度は？

質疑応答。理想的なヒープの大きさは？無限。

*1 Old generationへの？

● [io13] Using Drive as the Storage Solution on Android

最近赤ちゃんが産まれたのでいろいろログを取りたくなった。名前、誕生日、性別を入力して記録を取り(なかなか使いやすい)、そのうちにデバイスを乗り換えたら、

設定が同期されない
記録していたデータが来ない

App is treating the device as a user

Google Driveをアプリに組み込んで使いましょう。全てのGMailユーザーは5GBの無料領域を持っているし使ってもらいやすい。

アプリのための記録領域としては、

ユーザーからは直接は見えないApp Data
ユーザーからも見える通常ファイル - 例えば、CSVファイルとして記録しておき (Google Spreadsheetsでも参照できる)、アプリ内のSQLiteと、ユーザーの設定に応じて同期する。アプリ内ではユーザーの入力をSQLiteに記録する

の可能性がある。コード例 (動画 17:00、17:40)

こうしておくことによって、デバイス間、Schemaが公開されていればアプリケーション間、そして、ユーザー間でポータブルなデータが作れる。

ユーザーから見たアプリのデータ。ユーザーがGoogle Drive側から何をできるか、選択できる。 View: No、Edit: No、See quota: Yes、Delete Yes…など。各プロジェクトに複数のoAuth2.0クライアントを設定できるので、 iOSクライアント、Androidクライアント、…と様々なクライアントを横断して使ってもらえる。認証スコープは、 https://www.googleapis.com/auth/drive.appdata *1 に記載されている。 SharedPreferencesを、 onSharedPreferenceChanged()やonPerformSync()など経由で記録しておける。

サンプルアプリは https://github.com/googledrive/appdatapreference-android *2 に。

質疑応答。コンフリクトが置きた場合はどう処理される？後からの更新が勝ちます。

*1 執筆時にFirefoxからアクセスしたらNot Foundになりましたが…

*2 こちらもNot Found…