Google Developer Day 2010
東京国際フォーラム
■基調講演
○Chrome/HTML5
・インターネットの利用時間の大幅な増加
・人々がWebの上で生活するようになっている
・Webがアプリケーション化するにおいて重要な技術がHTML5
・これら重要な技術がひとつのベンダーによるものでなくオープンな環境でのイノベーションが重要
・慶応大学SFCの教授: W3Cの日本の代表
2009年6月の段階ではXHTMLで行くかHTML5か議論されていた。その結果HTML5に決まった
HTML5はアプリケーションプラットフォーム。ビジネスの劇的な変化がおきる
・Canaly Build -> xxx -> Stable と進んでいく
・WebGLはGoogleがWeb上の3Fグラフィックのために策定を進めている仕様
→ 注) すごいこれ
・CSS3のトランスフォームを使ってGoogle検索画面を横倒しするデモ
・HTML5デモサイト
http://studio.html5rocks.com/
・HTML5は確実に次の段階に進んでいる
・機能の一部紹介
・デバイスオリエンテーション: デバイスのオリエンテーションをDOMで取得可能
・@speech属性
・ファイルアクセス: File API / FileSystem API
・課題3つ
#1 見つけやすさ
→ 魅力的なアプリケーションがあっても探せない
#2 再アクセスの容易さ
→ 一度見つけたものを再度見つけることができるか
#3 マネタイゼーション
→ どうやってマネタイズしていくか。広告だけでいいのか
・それらの課題の解決策としてGoogleが提案するのが Chrome Web Store
→ インストール、という概念
→ 無償アプリケーションも有償アプリケーションも
→ 開発者向けプレビューをすでに提供中
・デモ: Fiabee for Chrome
→ ネットストレージサービス。すでにiPhone/Android版は提供中
→ サイト内検索はWebSQLを使って実装されている。非常に高速
→ デスクトップNotificationを使ってアップロード完了を通知
○Android
・全人口の半分以上がモバイルデバイス使っている
・実は今年初めて世界の携帯電話からのインターネット接続がPCを上回った
・今は1日20万のAndroidデバイスが新しく接続している
・Androidアプリケーションは8万まで成長
・Androidでもゲームが伸びている
→ クリス登場。Galaxy Tab でデモ
・Froyo に追加された新機能の追加
→ 音声認識に日本語対応追加。オムロンのエンジン搭載 (iWnn IME Voice Input)
・2つの日本語フォントをオープンソースで提供
・日本のアンドロイドアプリダウンロード数は世界2位
○Google App Engine
・App Engine の導入事例が急速に増えている
・エコポイントのシステムは App Engine で動いている
・mixiFES (ワールドカップアプリ) も GAE で動いていた
・Google App Engine for Business を2010年5月に発表
・IT予算の6割は保守に使われる、といわれている
→ 新しい開発のために使われているのではない
・Googleは100%の予算をイノベーションに使ってほしいと考えている
・GAE トラフィックも日本は世界2位
・デモ: Spring Roo
○音声認識
・ベータとDevChannel
・Google 日本語入力
→ Mozc (もずく) オープンソース版もあり
→ Chrome OS (Linux/MacOS) へのポーティング済み
→ Mac 版はできたてほやほや！
・Google日本語入力 Cloud API 本日公開！
→ とりあえずバックエンドのみ。フロントエンドも後日公開
→ デモ (JavaScriptで実装したもの)
・Transliteration API
・10/23 日本語入力テクニカルイベント開催
・Google Developer Day は今年で4回目
○
・DevQuizについて
応募数: 4904 / 合格者数: 1481 / 最高得点: 41.94 / 合格点: 23.22
トップ20の方にはジャケットプレゼント
・Google の中ではコードを書くことも重要だが、レビューをしてもらうことも重要
→ レビューされないとリリースできない
→ コードだけでなくコメントもいかにわかりやすく書くかの厳しい基準がある
・GTUG (Google Technocal User Group)
→ 京都はもっとも活発なコミュニティのひとつ
・女性限定ハッカソン開催
・アンケートに答えるともれなくTシャツプレゼント、抽選でアンドロイド人形、ジャケット
■ Panel Discussion ～ 未来のソーシャルウェブを占う
講演者: mixi 田中洋一郎氏、DeNA 山口徹氏、マイクロソフト 西脇資哲氏、グリー 伊藤直也氏
・mixi: 複数のサイトのアカウントをもっていて使い分ける人も多くなってきていると思う
・DeNA: オープン化といっても、適用先がなければ意味がない
・MS: 1社独占はよくない。ネットワークに関してのオープンは重要
・ビジネス上はクローズにしたほうが儲かるのは間違いない。アメブロがいい例
→ メリットデメリットを考えるとクローズのほうがいい
・技術的にはオープンがいい。ビジネス的にはクローズがいい
・MovableTypeの仕様はオープンだが性善説過ぎたからスパムが多くなった
■ Hi-perfoemance Android Apps
・ハイパフォーマンスとは
スピードをどう速めるか
時間のかかる作業をいかにユーザーをハッピーにさせるか
・”Jank”
→ “A janky App”
→ スムーズでないアプリのことを刺す
・べからず
1. イベントのクイックにリーチさせる
2. イベントループスレッド
3. (メモ間に合わず)
・ANR: “App Not Responding”
UIスレッドが5秒以上待ち状態になった場合
・ユーザーが遅いと感じるのは 100～200ms の遅延
→ ジャンクな状態になる
・Webと通信すると1秒はかかることになる
・フラッシュメモリへのwriteは様々な要因で遅くなる
→ 絶対にUIのスレッドで行ってはいけない
・SQLlte をどう使うかはよく考えないといけない
・ログをSQLiteに書いてはいけない
・まとめ
ストレージへのwriteは遅い
ネットワークは遅い
UIのスレッドから遅いものははずすこと
・asyncTaskはひとつのツール
→ 思いタスクをバックグラウンドで実装できて、進捗フィードバックもできる
→ 注) 使えそう！
・注意点
・バックボタンを押すなどしてアクティビティがバックグラウンドにいってしまうと、killされる可能性がある
→ メモリが不足したときなど
・そういう時には IntentService を使うとよい
・デモ: LifeSaver
→ 時間がかかることをユーザーに見せるのが大事
・アドバイス
1. できるだけシンプルに
2. それでも遅ければ推定はしないで測定をしろ
3. 速くなったら飲みに行く
・ツール: TraceView
→ 写真参考
→ 注) コードを数行入れるだけでどこが遅いか指摘してくれる。adb で traceview ツールがある。便利！
・教訓
1. UIスレッドを大切にする (大きな処理はやらない)
2. 推定をしないで測定をすること (TraceViewがオススメ)
・質問
・アンドロイドのロードマップについて。特にセキュリティが弱いと言われているが
→ 具体的なコメントはできないが、セキュリティチームがAndroidにいるが、非常に多くの労力が費やされているのは間違いない
・C2DMのスケーラビリティについて。100万台くらいのAndroid端末に対してメッセージングできるか
→ 全く同時というのは難しい。ネットワーク遅延もあるため
・様々なデバイスが出てきたときにプログラマーはどう対応していけばいいか
→ Googleでは互換性の問題と認識している。Android Developer Blog (英語のみ) でコメントしている
→ 1. 様々なデバイスで動くようにする
→ Galaxy Tab でもたくさんのアプリが動作している
→ 注意深く見守ってほしい
・バックグラウンドで動くアプリの場合、混んでいるときと空いているときの区別はできるか
→ 処理に優先順位をつけることができる
■マーケットランシングを使ってAndroidアプリケーションを守るには
・Android 1.5以上で利用可能
・無料
・3つのコンポーネント
App + LVL (License Verification Library)
Market App
Google License Server
・実装について
サンプルコードをそのまま使ってはいけない
コードの難読化はしたほうがいい
NOT_LICENSED に対する実装が抜けている
・実装のコツ
1. コードの難読化
→ フローは変えることはできないので完璧ではない
→ ProGuard はオススメ (オープンソース)
2. LVLコードを変更する
→ switch を if に置き換える
→ onCreate() に入れるのはやめる
など
3. 改ざん防止機構をいれる
4. オフロードさせる (Offload license from a trusted server)
→ クラックが非常に難しい
・ポリシーについて
1. ServerManagedPolicy (推奨)
2. StrictPolicy
・まずは Market Licensing developer guide を読むべし
■クールなAndroidアプリを作るには
株式会社ケイブ 安生真氏 (Tokyo GTUG マネージャー) @Tennetiss
○IMoNi 江川崇氏
約25万DL アクティブ率: 86%
・「クールな」アプリを作るには「緩やかな繋がり」を生かすといい
→ Intent と Content Provider
・共有ダイアログについて
→ 賛否両論分かれるところだが、いいところもたくさんある
・Uriがオススメ
→ パースしやすいし、目でみてわかりやすい
・有名アプリの威を借りる
→ 有名アプリと連携できるようにしたほうが、検索でも引っかかるしインストールしてもらえやすい
・標準装備されている仕組みに乗る
→ 標準のContent Provider に突っ込むといい (SMSとか。IMoNiは新着通知をSMSに入れている)
→ 自分が持っている情報も、標準の仕組みで公開できるようにしておくといい
・アドレス帳は2.0以降のデバイスでは大きく変わる
→ データ構造が変わる
・開発者とユーザー
→ 実際に利用してくれている方からの意見は重要
→ いろんな端末の人がいる
→ ひどいコメントは無視に限る
○ → 絶対に無理をしない
→ 息切れするより、ゆっくりと継続したほうがユーザーにとっても幸せ
・優先順位
1. 致命的なバグ
2. 他の開発者からの要望
3. 自分が実装したいもの、ユーザーが望むもの
・Android という共通のプラットフォームでのゆるいつながりは重要
→ 集まるのが好きな人が多い
○FxCamera 山下盛史氏
約370万DL アクティブ率: 57%
・クールとは
使いやすいこと、落ちないこと、サポートがしっかりしていること、
・BACKキーのハンドリングをしたほうがいい
・MENUキーについて
→ 結構気づかない人が多い
1. 積極的に活用する
2. 一切使わない
3. うまくハイブリッド
・ConfigChange は見落としがち
→ Manufestに書いて無視するか処理するかしたほうがいい
・ヘルプページ
→ FAQ 的なものは絶対に必要
→ Webページとして作るのがオススメ