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

2013年05月17日(Fri) Google I/O 2013 Day 3 [長年日記]

● がんばって起きてMoscone Center Westまで歩いてドーナツとコーヒーとオレンジジュースをいただく。twitterのログを見るとgit pullをして何かバグを直してたみたい。何を直してたんだろうw コード書きたいよね。

● [io13] The New Android SDK Build System

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

Gradleベースのビルドシステムに乗り換えます。 build.gradleの例 (動画3:00付近)

ファイルの位置は基本的にconventionで決まっている。古い(eclipseで始めた)プロジェクトでは、build.gradleでフォルダを指定しておく (動画4:50付近)。

GradleTasks。 gradleコマンドのコマンドラインにタスクを複数指定できる。 assemble、check、build (assembleとcheck)、clean、…。

で一覧が見られる。

Customization。これもbuild.gradleで(動画7:40付近)。

ビルドしたらバージョンコードを上げたいとすると(動画8:10付近)*1、

BuildTypes (動画9:10付近)。

デバグのみに必要なソースがある場合にはソースコードのフォルダを追加したりもできる(動画10:10付近)。

署名のしかたもbuild.gradleに書く(動画11:15付近)。

ビルドタイプによってパッケージ名を分けることもできる。ファイルの依存もbuild.gradleに書く。ローカルなフォルダ、リモートレポジトリ。

MultiProject。settings.gradleに。ライブラリプロジェクトの記述。

バイナリパッケージをアップードできる。

プロダクトのflavorの設定 - paid/free/...

build type/flavorと次元が増えている。優先度つきで設定を選んできてくれる。

テスト。ライブラリはapkに入る。check、connectedCheck (PCに端末をつないで)、deviceCheck (ビルドサーバ経由で端末あるいはエミュレータで)。設定はbuild.gradleに書いておく。レポートを作ってくれる。

ビルド環境。gradleのバージョンはラッパーを使って、プラグインのバージョンはbuild.graldeで指定して、tools versionもbuild.gradleで指定する。プロジェクトによってSDKのバージョンを設定できる。 IDE(Android Studio)はビルドに関係しない。

参考サイト。 Android Tools Project Site、 http://b.android.comより AndroidのIssueのリスト。

*1 どこで永続化するのかな

● [io13] Device Agnostic Development

Developer Sandboxでレンダリングの問題についてうれしそうに解説するPaul Lewisさん Googleによる録画。この記事はzundaのメモからの講演内容の再現です、発表内容を網羅しているわけではありませんし、誤りが含まれるかもしれません。

ウェブサイトを閲覧する環境。デスクトップ、モバイルだけではなく、テレビ、ゲームコンソール、…。 Network、Compute、Renderが様々な環境がある。どのように対応すればよいか？ Chrome DevToolsにいろいろあるから活用するといいよ。

Network。Page Load Time (PLT)を気にする。ロードに3秒かかると57%のユーザーはどこかに行ってしまい、 46%は戻ってこない。22%は友だちにあのサイトには行くな、とアドバイスする。ネットワークには、レインシ、バンド幅、課金というコストが存在する。リクエストをできるだけ減らす、Concentrate & minify、画像による負荷を減らす、といった努力が必要。画像はトラフィックの60%を占めるので、 WebPを使う、必要なサイズにサーバ側で小さくしてから送る、SVGを使うといった工夫が大切。 mod_pagespeedによる高速化も。

Compute。Jankを減らす。 60 FPSのリフレッシュレートのなか(16.7msec)で描画を終わらせるべき。ユーザーはフレームの抜けに気づく。スタイルの変更はDOMの中に留める。子要素の変更で済むときはBodyは変更しない。レイアウトの再生成(layout trashing)を避ける。例えば、offsetwidthを参照すると、その時点でレンダリングしなければならない。 style.widthを設定すると、レンダリングのリフレッシュが必要になる。 position.fixedを使って再レンダリングを減らす。 Javascriptを減らす。アニメーションやトランジションはブラウザの実装を使うようにする。イベントリスナは最小限にする。

Render。画像のデコードや拡大縮小には時間がかかる。ピクセルを塗り潰すのは大変。影をつけるなどの複雑なペイントは負荷が高い。 ChromeのDevToolsでペイントしなおしている場所を見ることができる。

UXの改善。ユーザーの環境に依らない内容と機能。開発者が受けている制限をユーザーに押し付けてはいけない。内容の配置をユーザーの環境に合わせて最適化すること。

その他。制限を決めて、限界を決めて、最初から測定を続けて、目標に到達するまでは出荷しない。Let's Make the Web Jank-free!。

● 2階南側「UX Design for Developers」は部屋に入れる直前に満室になってしまいました。聴きたかっんだけれど録画も無いとのこと。残念。「Code Lab: Android Location Based Services」に行ってみましたが無線ではSDKのダウンロードもままならず断念。早めのお昼にしました。二階の南側でぽかぽか日光に当たりながらGoogle Glassも試させていただきました。そういえば何かコードも書いてた気がする。

● [io13] When Bad Things Happen to Good Clusters: Robust Systems with Google Compute Engine

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

Google Compute Engine - Infrastructure as a Service (IaaS)。バーチャルマシン+ネットワーク、ストレージに、スケール、スピード、グローバルなフットプリントがくっついたもの。 Googleのエンジニアリングの専門知識と経験も。 Google Cloud Engineの一部。

さて。何がうまくいかなくなるか？なにもかも: 人的ミス。設定、手順の問題や、事故。バグやリソース不足によるソフトウェアの不具合、それに引き続くリカバリの失敗や、アップグレードの失敗。ハードウェアの問題やセキュリティの問題。

ガイドライン。信頼性のゴールを設定して、指標の測定を続けること。すべてをドキュメントすること。すべてを自動化すること。メンテナンスや機能停止に備えておくこと。アップグレード計画を用意しておくこと。

Google Compute Engineからの電動工具(power tool)。

ストレージ。 VMと一緒に消えるscratch disk、高速でスナップショットもとれるpersistent disk、 VM外のcloud storage、cloud SQL、cloud database、また、ユーザの所有するストレージが使える。

自動化。 VMのメタデータにssh鍵等を含めておく、rc.localなどで起動時の処理をさせる、イメージをつくる、ChefやPuppetによるオーケストレーション。

スケーリングや安定性。ロードバランサ、geographic density。高速な起動。

最後に。

Reliavility = Infrastructure + Design + People

アプリ、サーバ、ゾーン、リージョン、その他、の機能停止に備えておこう。 Google Compute EngineにはEalry Access Programもあります。

● 画像の説明講演の合間には分解されたChromebook Pixelを眺めたり。こういうのも興味を持って会場にやってくると得られる情報量が違うんだろうなあ…。

● [io13] Mobile Performance from the Radio Up: Battery, Latency and Bandwidth Optimization

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

有線とは異なる無線の性質、デザインへの制限、パフォーマンスの特性、最適化の基準。無線ネットワークはWiFiとMobileに、Mobileはさらに2G、3G、4Gに分かれている。

WiFi (802.11 1999年から)はデスクトップやラップトップのための規格。消費電力に制限はない。衝突が起きた場合にはランダムな時間だけ待つ。輻輳するとパフォーマンスが落ちるため、それぞれのチャンネルの負荷は10%程度に抑えないといけない。規格では16チャンネル用意されているがそれぞれの通信が複数チャンネルにまたがってしまうので、同時に使えるのは最大3チャンネル(例えば1、6、11)だけ。講演者の近所には15個近いアクセスポイントが見えている。混雑しているところでは、通信の95%で35msec程度のレイテンシが生じてしまう。

Mobile。安定していてスケールできる。消費電力をできるだけ抑える。 Radio Resource Controller (RRC)による交通整理。端末からデータを送りたいというリクエストを送ると、時間、電力、エンコード等を指定される。 RRCは2G、3Gではコアネットワークにあったが、4Gではアンテナタワーに設置されていて、レイテンシの短縮に寄与している。

端末網のレイテンシ。 Control Plane Latenctyは3Gでは2.5秒未満、4Gでは0.1秒未満、 User Plane Latencyは3Gでは0.1秒未満、4Gでは0.05秒未満。 Low power stateからだと、 Idle to activeには0.1秒、 Dormant to activeには0.05秒かかってしまう。通信がない状態がしばらく続くと、Control planeからやり直しになる。ここで、例えばDNS参照には、TCPのハンドシェイク等も含めて、 3Gでは0.5-3.5秒かかり、4Gではもう少し短かい。

遅延が0.1秒未満だと動作はスムーズに感じられるが、 0.1-0.3秒だとひっかかりを感じ、1秒を越えるとコンテキストが破壊される。 (YouTubeでは5-10秒に動画を切って送付しながら回線の速度をモニターしてクオリティを調整している。)

電力消費。通信がない状態が続いて低消費電力状態になるまでの電力の消費でぜんたいの消費電力が決まる。 1回のサイクルで10J程度消費する。定期的に通信をするビーコンや解析ツールはどんどん電池を消費するので注意が必要。

携帯デバイスのためには、キャッシュを有効活用する、通信内容を圧縮することがたいせつ。

● あちら側のケーブルカーの終点 Google I/Oの終わった後には、Fisherman's Wharf方面のTrader Joe'sにお土産を買いに行きました。贅沢してケーブルカーに乗ろうと思ったら満席だったのでバスで。Google Mapsで検索してすぐに経路がわかるのが便利です。さすが地元。38番のバスはトロリーで、インバーターの音を聞きながらチャイナタイウン、イタリアタウン(!)を抜けて行きました。ちょっと足を伸ばしてFisherman's Wharfに行って食べたクラムチャウダーはホワイトソースの缶詰の味しかしなかった。残念。Google Glassをかけたままの人を見かけましたが強奪されたりしないかな。