Google Developer Day 2009に行ってきました！
写真とセッションのレポートをいくつか。
各ブレイクアウトセッションの内容メモ
【WS-1】HTML5によって拓かれる次世代Web - Google Developer Day 2009 - hdk_embeddedの日記
【SC-2】OpenSocial in Japan - Google Developer Day 2009 - hdk_embeddedの日記
【MB-1】Androidのデータ共有 - Google Developer Day 2009 - hdk_embeddedの日記
【MB-2】 Androidでリアルタイムゲームの開発方法 - Google Developer Day 2009 - hdk_embeddedの日記
【MB-3】Android 高度 方法指南 - Google Developer Day 2009 - hdk_embeddedの日記
写真
GDDフォンいただけました。
以下、そのほかの写真、ブレイクアウトセッションのメモです。
【SC-2】OpenSocial in Japan - Google Developer Day 2009
今回、GDDに参加してOpenSocialに初めて注目しました。
いままでは単語だけ聞いたことあるな、という曖昧な印象しかなかったけど
アイディア次第で楽しみが何倍にも広がりそうです。
ひとつ思いついたのでGoogleフォンで作ってみたい。
OpenSocial in Japan 株式会社ミクシィ 田中洋一郎 氏 OpenSocialとは？ ソーシャルグラフを利用したアプリケーション SNSの原動力は？ ユーザ間の関係(ソーシャルグラフ) バイラル効果(新しいコンテンツの発見) いままでのSNSにはユーザと運営者の2つの関係しかなかった そこに一般開発者を加えるとどうなるか。 SNSのもつソーシャルグラフを解放することでユーザにメリットがでる？ ただし、SNSそれぞれがAPIを策定してしまうと互換性が著しく低下 → OpenSocialを提案 ソーシャルアプリケーションのための共通仕様 Write ones, Deploy anywhere ソーシャルアプリケーション 他の人とコラボレーションしながら使えるアプリ 海外での成功例 Mobsters:月間アクティブユーザ数1300万人(比較としてmixiのユーザは1600万人) シェア・コミュニケーションに重点 OpenSocial API Specification(仕様) API内部の仕組み 二つの形態がある。 JavaScript API 画面の中で動く RESTful Protocol 専用のアプリとして動く OpenSocial JavaScriptAPI XML + HTML + JavaScript (+Flashなど) つまりAJAXと同じ感覚 OwnerとViewerの関係 オーナーがアプリをインストールすると、そのアプリケーションは自分の持ち物になる。 たとえばインストールの結果、 プロフィールページにアプリが埋め込まれる。 そのアプリを実際に使う人がViewer。 OwnerとViewerの関係を分離して考える事が重要 Viewer Friend アプリケーションを使っている人の友達 Owner Friend 持ち主の友達 Views アプリケーションの置く場所を指定する Canvas View：アプリケーションを画面フルに使う Profile、Home Viewなど。 Viewによって利用目的が異なる。 Gadget XML ＆ Views 基本はXMLで記述。 簡単に言うとルート要素にmoduleがあり、modulePrefsとContentに分かれている。 OpenSocial JavaScript APIの紹介 Person API 使用者の情報を取得する(世界各SNSの最大公約数的なデータ) SNSごとにとれる情報の項目が異なってくる。名前や性別、年齢など。 → 利用できる情報はSNSごとに異なる Friends API 他ユーザーの集合。3つの視点で使い分ける USER_ID：起点となるユーザ GROUP_ID：友達の種類、ビジネスなど NETWORK_DISTANCE：友達の距離。友達の友達など。 例)友達の一覧を取得するなどが可能 Activities API 誰かのFeedを取得する。 日記の更新情報などを取得できる Persistence API あとでログインしたときに改めて情報を使いたいなど永続化のためのAPI。 自分の情報ではなくて、自分が貯めた情報を他の人も共有できる gadgets.io.makeRequest 他のコンテンツとのマッシュアップをするための関数 はてブのRSSフィードを読み込んで表示するなど。 ただし、直接サーバーに取りに行ける訳ではなくて オープンソーシャルコンテナという専用サーバーを経由して取得(XSS予防) OpenSocial RESTFul Protocol デスクトップアプリケーションなどソーシャルグラフをから使いたいとき。 データの取得が可能ですが専用言語なのでパースが大変。 Java,PHP,Python,Rubyなどオブジェクトへの変換するライブラリがあります 基本的な開発手法 コーディングはテキストエディタ、Ajax対応のIDE デバッグは各SNSのSandBoxなどが中心 OpenSocial Dev App その場でコードを書いて実行できます OSDE(OpenSocialDevelopment Environment) ローカルマシンでソーシャルグラフを仮想的に提供(Eclipce) OpenSocial-jQuery XMLでかくのは長くてしんどいので短くするために書き方を工夫できる キャッシュ 人気が出たアプリケーションは膨大なアクセスが発生 リクエスト処理は持たなくなってしまう･･･ OpenSocialサーバーにキャッシュ機構でカバーする 外部サーバーへ負荷を軽減 アプリケーション作っているときは邪魔者(修正が反映されない) URLのあとにnocache=1をいれるとキャッシュ機構は無効に。 OpenSocialのオープン性 コミュニティでAPI策定が行われている 個人レベルでの参加が可能 策定された仕様に基づいてSNSが1から実装するのは大変 Apache Shindigで実装を提供する 開発者のためのコミュニティ OpenSocial-Japan 日本におけるOpenSocial gooホーム 2009/5/21 一般公開 サービスをマッシュアップしたGadgetを体験できます mixiアプリ 2009/4/8 オープンβ mixiのソーシャルグラフを利用可能、モバイル版は明日からリリース(企業向け) 課金API、広告プログラムなどビジネス的な展開もあります Javascript libraries for jQuery jOpenSocial opensocial jQuery いずれも日本人が作成 OpenSocial 日本語ドキュメントが用意されています 日本がOpenSocialをリードしている OpenSocial Hackathon 毎月開催しています。主催はGoogleやOpenSocial Japanなど OpenSocial v0.9 v0.6が初版 v0.9ではテンプレート的なものが採用(OSML) Lightweght JavaScript APIに対応。開発をできるだけ簡単にする。 AlbumAPIで画像が使えたりします
【MB-1】Androidのデータ共有 - Google Developer Day 2009
ネットワークをデータ共有に活用する、という意識が全くなかったので新鮮でした。
ちょうど勉強しているところを解説してもらえたので、
とても満足度が高いセッションでした。
Androidのデータ共有 株式会社ケイブ 安生 誠 氏 1.Intent 大きく分けて二通り 明示的 起動したいActivityのクラス名を直接記述する 暗黙的 Intent.ACTION DIAL：Intentの種類を指定 Action Intentはいくつか種類がある 電話番号にダイヤルするなどアクションが指定できる Broadcast Intent Androidから発行される。たとえばTIME_TICKであれば1秒ごとに。 Intentに渡されるデータは？ 実質Stringのみ。Intent.putExtra()を使えばタイプの異なる一つ以上のデータを渡したいときに便利 ExtraDataで扱えるデータはArrayとその他の型色々。IntentにIntentを渡すことも可能 ExtraData ビットマップなどbyte[]で渡すことができる Intentでビットマップ渡しが可能だが、あまりに大きいファイルは渡すことができない。 Seializableなど渡すことができる Intentの勘所 共有というより、一方的に渡す程度。 2.SharedPreferences マルチプロセスには非対応(いずれ対応) Private SharedPreferences PrefsPrivate; 読み込み側は書き込んだ方のアプリケーションとコンテキストが違う場合、 書き込み側コンテキストを呼び出す必要がある? パーミッションが設定出来る(MODE) 同一アプリケーション内なら気にしないでよい 実際はファイルへ書きだしている SheredPrefsディレクトリの下にXMLファイルとして書き出し。 ファイルのパーミッションの変更がMODEの変更(PRIVATEやWORLD) 3.ContentProvider android.content.ContetnProvider 実装が必要なメソッドがいくつかあります。 Query, Insert, Upate, Delete, getTypeなど 実際はデータベースです。 使い方は2通り getContentResolver.queryメソッド Activity.ManagedQueayメソッド 事前準備としてAndroidManifest.xmlにContentProvider利用を宣言する必要がある メソッドの実装は、行いたい動作を記入してください(これは必要) DBへのアクセスだけならSQLiteを使うことで、ContentProviderを使わなくても可能 共有しない場合はこちらを推奨 Android.database.Sqlほにゃらら 4.Network Web Server（Cloud)を経由したファイル共有 データはサーバへおきたい Java.net.HtttpURLConnection 注意点 UI Thread(Main Thread）でHTTP送受信はNG 同期待ちするのでサーバーからレスポンスが帰ってくるまで止まってしまう ANRダイアログが発生 (条件) ・ユーザーからの入力に対して5秒間反応しない ・BroadcastReceiverに対する処理に10秒以上かかっている ANRを避けるために 通信が発生している間にユーザに何もせずに待っていてほしい場合、 プログレスバーーやダイアログを表示させる Backgroundで通信していてほしい場合、 Threadクラスを継承したり、Runnable Interfaceを実装する形で 通信処理を行うクラスを別スレッド化しておく ・Pros And Cons メリットとデメリット さきほど説明した順に処理が遅くなっている。 ただし、ハードウェア、利用状況で大きく異なるので参考程度に。 Intent 簡単 SharedPrefs パーミッションの設定が可能 ContentProvider SQLが使えるため、データの取り出し方が自在 データ型も豊富。 ネットワーク 記憶容量をきにしなくていい データの永続性が端末に依存しない 共有範囲が自分の端末に限定されない デメリット Intent ストレージに存在するデータとは限らない もともと共有するためのものではなくて、一方的に投げるもの データ量はオンメモリなので少ない 必要に応じて自分で保存しないといけない SharedPrefs データ型が少ない。細かいパーミッション設定は難しい(むり) ContentProvider 準備に手間がかかる。SQLを覚える必要がある ネットワーク データの取り出し、書き込みに時間がかかる(ネットワーク依存) 処理時間も推定しづらい。 → UXに注意を払う必要がある → バッテリーに優しくない まとめ その都度、最適と思われる方法を。（会場笑い） ほかにもSDカードや内蔵容量にファイルとして保存する方法がある Androidが搭載されているハードウェア、実行環境によって メリット、デメリットは変わるため、考慮に入れて設計しましょう お知らせ Android−SDK-Japan 日本アンドロイドの会 各種WGによる勉強会もあります！
【MB-2】 Androidでリアルタイムゲームの開発方法 - Google Developer Day 2009
非常に実践的。とても参考になりました。
クリスさんがすごく楽しそうに話すのでゲーム作りたくなっちゃいますね。
気になったのが
パフォーマンス：タッチスクリーンを使うとUIスレッドは大量のMotionEventsを受け取る
OnTouchEventの中でSleepするとシステムを止められるよ(やっていいのかｗ)
の下り。
メインスレッドが16msぐらい寝ている、とのことなのでそれぐらいなら許容範囲なのかな？
ANRの条件には当てはまらないのは間違いないですが、
Androidのシステムとして想定している動きなんだろうか…。
まぁ、MotionEventsをホイホイなげつけてしまうのが
そもそも、どうなんかなーって思います。こういう話題はどこに投げればいいんだ？
Androidでリアルタイムゲームの開発方法 Google Developer Advocate(開発支援) クリス プルエット 氏 Mr. Chris Pruett もともとゲーム開発をしていました。 今回、Googleの20%ルールを活用して作っているゲームについてお話しします。 なぜAndroidでゲームを作るのか？ 3つのゴール - 楽しいゲームを作る - オープンソースのゲームエンジンを作る - 本当にAnroidでゲームはあり得るのかを確認したい うち、二番目のゴール「オープンソースの開発」について 今のゲーム開発を終了した後に取り掛かります 横スクロールゲーム 開発期間：5ヶ月間。週に1日のペース。 ゲームにAndroidのAPIが役立つのか確認したい OpenGL ESなどなど。 ここでDEMO 作成中のゲーム「ワンダのレプリカ島」 ゲームアーキテクチャの基本 ゲームグラフを利用 入力は経過時間、ボタン入力 出力はレンダリングスレッドへのコマンド 背景、キャラクタのサブグラフがあり、カメラの場所によって どのオブジェクトを更新するか決定される。 基本的な仕組みで作った(実際の開発では特性に合わせてアーキテクチャを選択したら良い) 大事な点として 経過時間も入力として利用することでフレームスキップ（コマ落ち）しても 自然に動くようにする。アニメーション時間など本当の経過時間を利用する必要がある。 ハードが変わってしまうとゲーム性も変わる恐れがある。 描画処理は分離しておくこと。 レンダリングのコマンドのみ生成して、レンダリングは別スレッドで処理する スレッドは３つ メインスレッド 入力イベントの受付 ゲームスレッド 描画以外のすべてを担当 レンダリングスレッド 描画、ハードウェア制御を行うため、スレッドを分割して非同期化 SurfaceHolderに管理、フレーム単位でキューにたまった レンダリングコマンドをOpenGLに投げつける。 高速なJavaコードを生成するには？ 開発歴：C++が圧倒的。Javaは触りだして6カ月なので嘘をいうかも。 高速なゲームはパフォーマンスと拡張性／保守性のバランスをとることが重要★ 開発フェーズで、やってみる→だめ→ほかのことしてみるの試行錯誤ができないとだめ。 そのためには拡張性を持たせておかないとゲームに制限ができて、破綻する。 メモリ管理 ゲーム中にメモリ確保や解放をしないように。 GCが確保のタイミングで動く可能性がある。 なんとGCのタイミングでプロセスが止まってしまう。（100msや300ms単位） 対策：ゲームが始まるタイミングでメモリプールしておく メモリの使用状況はDDMSをつかってメモリの仕様状況を確認できる Javaはいつも内部でメモリを確保している。Enum。ValuesやArrays.Sortなどなど。 (メモリ管理しなくて良いはずなのに、結構使ってるじゃないか、とコメントしてました) 関数を呼ばない (会場笑い) Javaの関数呼び出しはC++に比べてコストが高い。インライン展開もしてくれない。 インターフェイス経由の関数呼び出しはクラス経由の仮想関数呼び出しより30％遅い JNI関数は処理が早いが呼び出しが遅い できるだけ避けたいところ。 Tips なるべくローカル変数を使う 変数をFinalにする。G1では小数点演算はソフトで行うのでFloatやDoubleは演算が遅い。 (気にするほどではないかもしれない) 描画を早くする方法 SpriteMethodTest(code.google.comで公開中) 1000スプライト、OpenGLで描画するとだいたい10FPS。 Androidの描画はどんな手法がある？ canvas: 2Dレンダリング。 描画オブジェクトが少なければ早い。その上、使いやすい。10スプライトで16ms OpenGL ES:3Dレンダリングだが２Dでも役立つ Canvasより遅くならないが、ビデオ管理などcanvasより使いにくい側面も。 AndroidではOpenGL ES1.0までサポート メーカーによっては独自Extensionとして1.0以上を取り込むことがある。 使えるものもあるかも。ただし、1.0以上のAPIを利用する場合でも端末依存が強いので 注意したほうがいい。 → 10スプライトまでならCanvasでよいんじゃない？ G1ではDrawtexture Extensionが最速 かならずglGetStringng(GL10.GL_EXTENSIONS)で確認 Canvasはパズルゲームなど頻繁な描画更新がないゲームで役に立つ。 ベンチマークはcode.google.com/Androidで公開中 背景の描画 背景は3レイヤーとした(いくらでも凝れるがここでは3層。) 案)背景マップのタイルを32x32ドットとする。 最悪のケースで150個を再描画する必要がある。 → 最初は全部を１つのビットマップにまとめて描画 GlTexParameteribが遅すぎて使いものにならなかった タイルを別々のテクスチャに分けてみました 処理時間計ってみたら最悪のケースを考えると処理に19〜23ミリ、さらにレンダリングに9〜13ミリ。 使いものにならない…。ステージ構成に限りがでてきてしまう。 案)複数のタイルをまとめて書き込む VBOをつかったら早くなった。ひとつひとつレンダリングするとOpenGLのState(状態)変更に 時間かかるが、まとめるとState変更が少ないようだ。 ワーストケースでもベストケースでも3-5ミリ秒程度ですむ。 Tips & Tricks落とし穴 パフォーマンス：タッチスクリーンを使うとUIスレッドは大量のMotionEventsを受け取る OnTouchEventの中でSleepするとシステムを止められるよ(やっていいのかｗ) ポーズやレジュームの処理はメモリの待避とかでややこしい。標準のGLSurfaceViewを使おう。 ※Android1.0〜1.5ではIndirect BufferでVBOを使おうとするとちゃんと動かないことがある。 Donutから治る。それまでは、うまくレンダリングしなかったり、落ちることもあるので DirectBufferを使うように。 アプリケーションを小さくする。2-3MBにする。 ユーザのフィードバックと端末に入っている時間が長いこと。大きすぎると消される。 (会場笑い) ハードウェアキーやトラックボールのないデバイスがあるので、依存しないように。 タッチスクリーンは必ずある。 面白いゲームほどFeaturedされる可能性があります！ 頑張って作ってね！
【MB-3】Android 高度 方法指南 - Google Developer Day 2009
Androidプラットフォームでの以下の3つの開発方法
・Dalvikバーチャルマシン上のJavaアプリ
・Ajax
・ネイティブコード
で、どのように機能提供するのか、特徴、メリットデメリットなど
手法の評価のお話です。
コンピュータとアルゴリズムの専門用語が多かったからか同時翻訳が少しまずかったです。
つくづく英語を直接聞いて理解できればと思いました。
Android 高度 方法指南 Google ジェイソン チェン 氏 Androidとは？ いつものLayerCakeの説明 最下層にLinux、次にLibなど…(つまらないので省略しましょう (会場笑い) 開発者にとってAndroidとはなんでしょうか？ 電話をするためのコードの塊であり、 ネットワークスタックであり、インターネットクライアント コードを走らせるためのプラットフォーム アンドロイドはアプリケーションのプラットフォームであるということ ただし、Androidをつかって携帯を独占したいわけではない よりよいモバイルを提供することが重要 Androidでの開発手法紹介 3つのタイプのアプリケーションプラットフォームである。 それぞれの開発手法の利用統計や、将来の開発方針を紹介します。 現在、存在する3つの開発手法 ・Managed Code Dalvikバーチャルマシンで動くJavaアプリ （ちなみにDalvikはアイスランドの地名で、スタッフの故郷がそこだったから） ・Ajax Javascript,CSS,HTMLでWebブラウザで動作するアプリ ・NativeCode ARMプロセッサのネイティブコードC/C++で書かれているアプリ 事例として、3つの方法で違いがみられるものを紹介します 例としてK-MEANSクラスタリングの実装。 K-means法は点をグルーピングするアルゴリズム Dalvikの場合 Dalvikバーチャルマシンはライフサイクルの管理を行っています。 開発では組込マシン用に1から作り、レジスタベース（スタックベースではない）です。 JITCでJavaを変換して実行する。 OpenGLなどの部分はネイティブコード(C/C++)によって書かれている。 このあたりの動作はDalvikでやると遅くなるため、APIはJNIを経由して実行されている。 Javaの開発環境として一般的なEclipsceプラグインを使えるようになっています Dalvikは何を提供できるのか - リッチなUI - BackGroundでのアプリ動作(サービス) - 共有コンポーネントやシステムイベント、UIを提供している。 スピードが問題であればネイティブコードの方が最もいいかもしれない。 基本的には用途によって、最適かどうかを判断すべき。 JavaでのKMEANSクラスタリングの実行DEMO (そこそこのスピードで動く。ただしカクカクとはしてました) Dalvik上のアプリ開発事例 Coreとなるシステム用アプリ、 スカイマップ（星座をみることができる）など多岐にわたります Dalvikの今後 ガベージコレクションの改良 JastInTime変換処理の向上 CoreLibrarieｓの更新 今後も新しい機能を提供します。 Bluetooth、P2Pメッセージなど。 Ajaxの場合 Ajaxとは AnroidのブラウザはWebKit+SquirrelFishを利用。 Ver 528.5、Gears 0.5.17.0、Canvasタグのサポート できること ウェブページの表示、DOM、CANVAS、Gears できないこと HTML5やバックグラウンド動作ができません AjaxでのK-MEANS法 Javaと同じアルゴリズムをJavascriptで。 Dalvikより非常に遅い アプリ例 Google Reader For Mobile Gmail(Web 版） その他のWebkit上で動くアプリなどはたくさん 将来 HTML5への対応（Androidでも） 拡張Ajaｘへの対応 JavaオブジェクトとJavaScriptを橋渡しして、 Ajaxを拡張する。 NativeCode ARM ELFなど Native Development Kitを開発中（まだ提供段階ではない 時間的に重要な処理をできるし、バーチャルマシンをカスタマイズすることもできる サポートしないもの ユーザ独自のライブラリへの参照は正式サポートしていません。 現在提供しているAPIはlibm,libcに限られている。 ネイティブコードはAndroidシステムを把握できない。 JNIからProxyを経由してネイティブライブラリを呼び出す → 同じアルゴリズムでも高速に動作する ネイティブコードでできること 過去資産の流用：非常に古いゲームの利用 SCUMMVM 負荷の問題 ：音楽ストリーミング Spotify ※いずれもJNI経由で使う必要がある 現在、ライブラリの追加を計画中 リクエストがあれば教えてください★ 今後やらないこと ネイティブコードで独立したアプリケーション作成できないのは変わりません。 今後もサポート予定無し Javascriptの今後 拡張Ajaxと呼ばれるモノを使えばAndroidシステムのAPIに JavaScriptからアクセス可能(JSからでもネイティブコードを利用可能) オープンソースとしてデモを公開中です。 http://code.google.com/p/dhict/ それぞれの方法の比較 レンダリングタイム Javascriptが最も遅い。Dalvikでは処理時間がNativeの5倍かかる。 スピードだけが観点ではないので みなさまのアプリケーションに最適なものを選んでください フローチャートを表示 ・既存のWebサイトがあるならAjaxでREST Serviceにしちゃえば？ ・APLの速度が必要か？ … (沢山の選択肢) … → 頭痛のタネですね。（会場笑い） Androidでは複数の方法を用意しています。 ユーザは選択肢から最適なモノを選んでください。 質疑応答 AndroidシステムはNativeCodeを検証(Verify)しますか？ → しません。 Android MarketでのNativeCodeを使うかを確認していますか？ → いいえ。 NativeCodeをアプリケーションにいれるのはユーザに委ねられている。 Android Marketは端末側で対応しているアーキテクチャごとに アプリケーションを取捨選択してリストを作るのみ。 LinuxへのModule追加はApplicationに含めることはできますか？ セキュリティの問題があるのでカーネル変更するのは無理。 AndroidのSandBoxに影響が出てしまいます。 今後の予定 次はOpenGLのネイティブコードアクセスが実現される
