AndroidエンジニアのAndroidエンジニアによるAndroidエンジニアのためのカンファレンス、第1回*1 DroiKaigiに参加してきました。
発表資料は公開されていますので、簡単なメモと感想だけ残します。
基調講演（@yanzmさん）
- マッチョなActivity
- 分割先の選択肢として、FragmentとCustomView
- FragmentはActivity寄り
- CustomViewについては『Android Pattern Cookbook』の第6章参照
- Activityがマッチョになる要因と対策
- 画面回転のときの値保持は、CustomViewのonSave/RestoreInstanceState()に実装する（Activityに書かない）
- データとViewのマッピングもCustomView内に実装する
- バリデーションも同様
- Fragmentではまらないために
- FragmentへのコールバックはsetTargetFragment()を使う
- バックスタックは難しい
- FragmentからstartActivity()ははまる。startActivityForResult()はもっと危険。
- Fragment in Fragment、Loaderとの組み合わせは危険。startActivityForResult()も危険。
Fragmentは手を出すのが遅かったので未だに恐る恐る使っていますが、このセッションを聴いて恐怖++と同時に、このままFragmentを使っていくという方向は腹をくくっていいのかな、と。
データとViewのマッピングやバリデーションは、私はViewModel的なクラスに実装することが多いかも。分量次第ですが。
参考書籍。『Master of Fragment』は、ベータ版を脱するための加筆候補がたくさんあるそうです。
Android Pattern Cookbook マーケットで埋もれないための差別化戦略
- 作者: あんざいゆき
- 出版社/メーカー: インプレス
- 発売日: 2014/03/20
- メディア: Kindle版
- この商品を含むブログを見る
CardboardのUXをカメラで向上する（@ken1_takaさん / Room B）
- Oculus Riftはケーブルとか面倒
- Cardboardはお手軽。でもタッチパネルが使えないので操作に難あり
- Cardboardにはカメラ穴があいてるので利用したい
- Cardboard SDK: 複眼ビュー、樽ゆがみ、マグネットボタン
- OpenCVでカメラ画像を認識させて、ジェスチャー操作させる
デモアプリが（高速化に失敗して）動かなくなったとのことで残念。OpenCVで指の形状・ジェスチャーを認識できるデモは見ることができました。
なお、OpenCVで頑張るほか、Leap MotionのAndroid SDK（今はアルファ版）を待つという選択肢もありますね。
あるゲームアプリケーションの構成とアップデートサイクル（@iizukakさん / Room B）
- KLabさんの某音ゲー、Android 2.3以降対応、2〜3ヶ月に一度アップデートしている
- ビルド〜デプロイプロセスを「パイプライン」と呼んでいる。GitHub, Jenkins, API, アセット類はAmazon S3にデプロイ
- 50MBが非Wi-Fiでのapkサイズ限界。ゲームでは足りないので、リソースは追加ダウンロード
- アップデート、Google Play(apk)は2〜3ヶ月ごとに、追加DLで済むものは数週間ごとに実施。
- 開発後半は、apkはデイリーで作成してテストエンジニアに配る
- リリース向けのDL版でなく、アセットを全部バンドルした「フル版」数百M〜数GBのapkを使う
- 開発終盤はDL版でテスト
- 実装者は思い込みや見落としがあるので、テストエンジニア重要
- クラッシュレポート、Developer Consoleはあまり参考にならないので、ほかのサービスを使う
- 遅延なく監視できるのか、NDK部分を分析できるか
- Crashlytics, SmartBeat
ビルド〜デプロイプロセスの自動化は、テスト自動化を伴わないとしても開発効率を上げるものなので、KLabさんのように専業のパイプラインエンジニア（ビルド職人）がいなくても、ちょっと時間を取って整備するといいですね。
内部テスト向けの配布はDL版でなくフル版を配る、というのは良さそう。ぜひ真似したい。
紹介されていた書籍。ビルド職人の端くれ（兼業）として、ポチりました。
- 作者: Renee Dunlop,加藤諒,中本浩
- 出版社/メーカー: ボーンデジタル
- 発売日: 2014/10/02
- メディア: 単行本
- この商品を含むブログを見る
ソフトウェア一般としてはこちらもオススメ。
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
- 作者: David Farley,Jez Humble,和智右桂,高木正弘
- 出版社/メーカー: KADOKAWA/アスキー・メディアワークス
- 発売日: 2012/03/14
- メディア: 大型本
- 購入: 24人 クリック: 567回
- この商品を含むブログ (53件) を見る
アプリの企画、プロトタイプからリリースに至るまで（@__chocomelonさん / Room A）
- pixivマンガ。少人数のチーム、ファーストリリースまで3ヶ月
- 以下の順で開発
- 以降のリリースサイクルは2week、月曜から段階的に20% → 50% → 100%
- リリース前週の水曜にコードフリーズ、金曜にチェックシート
- 朝会後、5〜10分チームメンバー全員でドッグフーディング（立ったまま）
- 毎週、KPTとはべつに、アプリの今後を全員で考える「ヴィジョナリータイム」実施。エモい。
- チャットツール(idobata)にcrash hook。Crashlytics連携でメインのチャットに投げられる
- Play Storeのレビューもhook。gsutilで取得する。ただし2日遅れ
- ご意見フォーム（id入力とかの要らないカジュアルなもの）もhook
ストアの紹介文から入る点、機能ごとの「雑なプロトタイプ」を作る点と、それでイメージを共有した上でデザイナさんがデザインを作っていく、というプロセスは面白そう。
チャットにクラッシュやユーザの反応を流していくのも良いアイデアだと思いますが、それをissue化する作業が誰か（当事者意識を持った人）に依存してしまう恐れがありそう。真似るなら、KPTや「ヴィジョナリータイム」もセットでやらないと危険かも。
大容量データのダウンロード戦略（@misyobunさん / Room A）
- android.app.DownloadManagerを使う選択肢。ただし、
- アプリ内でやりたい。統一されたUIを提供したい。
- Googleのダウンロードアプリに状況を出したくない
- 自力で実装。android.app.DownloadManagerのソースを参考にする
- DLタスクの状態を管理するContentProvider
- Serviceを使う。Activityをまたぐ処理を行なう場合
- Serviceから、startForeground()でNotificationを出せる。プライオリティも上がるので死ににくい
- Activityとプロセスを分けると、ヒープも別になり死ににくい。AndroidManifestに書ける
- IntentServiceはシリアル実行なので、パラレルしたければ自力でServiceから書く。
- 生死ハンドリング、プロセス名を使って生存確認
- onTaskRemoved()は機種によっては呼ばれないので注意
進化するランタイムART（@kmt-tさん / Room A）
- ARTを理解するには、まず『Androidの仮想マシン Dalvik編』を読むべき
- LollipopからはART
- OATファイル、OATコンパイラが吐く
- DEXファイルは、OATファイルに埋め込まれる。Annotationなどのメタデータ
- OAT
- Quickコンパイラ。JITコンパイラベース（だけどARTでは高速化されている）
- ほかのコンパイラは最新のmasterでは削除されている
- Quickは、LIR層までCPU依存でない（DalvikはLIRはCPU依存だった）
他のセッションと比較して、はじめからハードル高めな低レイヤの話でした。まずDalvikを知るべし。
買ってあるけど読めてません…
ARTのメモリ管理（@haru067さん / Room A）
- GC ルートスキャンと再マークの一部を並行実行されるので、停止は3msくらい
- LOS(large object space): 大きいオブジェクト専用スペースを設け、フラグメントを抑える
- 並行(concurrent)GCの実行タイミングが賢くなった
- 並列(parallel)GC、マルチコアな端末に向けて
- 世代別GC
- アロケータ、ResAlloc。並行メモリ割り当てが改善され、ロック不要になった
- 質疑応答
- コンパクションは基本やらない。backgroundのアプリを対象
GC(Garbage Collection)の話。Androidはmark and sweepだという認識を持ったままでしたが、色々進化していることを知りました。
つかえるGradleプロジェクトの作り方（@zaki50さん / Room A）
- 設定するとできること
- buildToolsVersionなどの一元管理
- デバッグ証明書をプロジェクトに含めて管理
- リリースapkへの署名
- バージョンコード設定
- git hashを埋め込む
- Android StudioのGUIでもかなり色々設定できる（build.gradleに反映される）
- 記述方法は、『Android実践プログラミング』第5章および、GitHubで公開しているandroid_gradle_templateリポジトリを参照
アプリを公開する前に、最低限知っておきたいセキュリティ事項（@tao_gakuさん / Room A）
- Androidセキュリティに関する書籍は、日本語では二冊だけ
- AnColeという学習ツールを公開している。Eclipseプラグインとして提供。
- コンポーネントは外部非公開（export=false）にしていくのがオススメ
- Activity/Serviceの乗っ取り。攻撃者がIntentを投げる
- ContentProvider
- SSL通信の実装不備
- テストサーバのオレオレ証明書を通すため例外を無視するコードを、そのままリリースしてしまう
- 世の中の1/3くらい該当している？
- プライバシーポリシー
- 広告モジュールが何を収集しているか。プライバシーポリシーに明記する必要がある
- Andrider公認の広告モジュール
- ユーザの不安。電池、スマホが遅くなる、に次いで、情報が取られそう29.2%、ウィルス32.5%
- ガイドライン
- 総務省から、プライバシーポリシー作成のガイドラインが出ている。 総務省｜「スマートフォン プライバシー イニシアティブ −利用者情報の適正な取扱いとリテラシー向上による新時代イノベーション−」の公表
- タオソフトウェアさんでカスタマイズしたものを公開している（Apache License 2） アンドロイドスマートフォンプライバシーガイドライン
- 書籍『スマートフォンプライバシーの基礎知識』がオススメ
- MCFもガイドラインを公開している スマートフォンのアプリケーション・プライバシーポリシーに関するガイドライン(pdf)
- 同意取得は、インストール時のパミッション表記だけでは不足。利用目的、外部送信、第三者提供有無も必要。
- 「個人情報」という言葉は法律解釈になり意味が無いので、「利用者情報」と総務省ドキュメントでは呼んでいる。法律でなく良心で判断する。
- プライバシーポリシーと利用規約を一緒にしない
- 会社のプライバシーポリシーと一緒にしない。アプリごとに作成すべき。
Android Security 安全なアプリケーションを作成するために
- 作者: タオソフトウェア株式会社
- 出版社/メーカー: インプレス
- 発売日: 2012/11/28
- メディア: Kindle版
- この商品を含むブログを見る
アプリビジネスで転ばないためのスマートフォンプライバシーの基礎知識 Next Publishing (NextPublishing)
- 作者: 寺田眞治
- 出版社/メーカー: インプレスR&D
- 発売日: 2012/12/21
- メディア: Kindle版
- この商品を含むブログを見る
Material Design を取り入れたデザインリニューアル（@ninjinkunさん、@yuki930さん / Room A）
Fril 3.xにおける、マテリアルデザインのキャッチアップから実装まで。
design
- キャッチアップ。Feedlyが参考になる。Googleのガイドラインは頻繁に更新されている。
- ユーザテストを実施。既存ユーザの体験を損なう変更があった。
- 画面下にあったタブをドロアに入れたため、
- お知らせを開くのに2タップ必要になった
- 未読バッジが見えなくなった
- ActionButtonでお知らせに遷移するように変更した。標準的なUIから外れるが、ユーザテストの結果を尊重した
- ユーザの動線。タイムラインを見た後、お知らせがあれば見て終了、という流れだった
- 画面下にあったタブをドロアに入れたため、
- 標準のタイポグラフィに合わせると日本語フォントに合わないので調整した
- Sketch向けUIパーツがGoogleから配布されている
- アイコンはsvgをIcoMoonというサイトでフォント化して使用。アプリサイズも削減できる。
- textAppearanceを活用。styleの切り分けが楽に。
code
- Support Libraryが出る前だったので、UI部品も自力で実装。後のバージョンでSupport Libraryに切り替え
- リニューアルと同時に構造もモダンに。Fragment, Retrofit, RxJavaを導入
- calligraphy。textViewに外部フォントを読み込み可能にしている
- ListViewスクロールに合わせてActionBarを隠す
- 自作ライブラリで実装、公開
- Support Libraryであれば、ActionBar#setHideOnContentScrollEnabledを使う
- 他のOSS: https://github.com/ksoichiro/Android-ObservableScrollView
- @yanzmさんに加わってもらったことを契機に、メンバー増加に備えた
- リニューアル後、滞在時間2倍くらい、継続率も伸びてる、売買の成約率も上昇。
- 登録の動線も見直し、離脱率も削減。
- Googleの2014 Best Appに選ばれた
- Android 4.0以上にした。2.3向けに旧バージョンを提供はしている。
今ならSupport Libraryがあるとは言え、「導入しました」では済まないところなので大変参考になりました。
なかでも、ガイドラインとユーザビリティのくだりは身につまされました。ActionButtonをタブのように使うのは気持ち悪いだろうな、と。でも、既存ユーザの慣れの問題なのか、動線の問題なのかまで踏み込んでいるので、気持ち悪いながらも決断したというところでしょうか。
所感
connpassによる募集は瞬殺、大量のキャンセル待ちを抱えたイベントでした。通常、首都圏のこの手の参加費無料イベントは当日キャンセルも多く、6〜7割くらいの入りになってしまうものですが、今回は10:00の開始時点でかなり席が埋まっているという状態。しかも年齢層が若い。
Android関係の開発者コミュニティの活動が鈍っている、という話はかなり前から聞き、また実感していたところですが、これを見ると需要はあって、個々のコミュニティでうまく世代交代ができずに失速しただけなのかも。
またスタッフの人数も多く、とても至れり尽くせりなイベントでした。スケジュールアプリの提供と、アプリからアンケートフォームを開き、回答してくれた人にステッカーを提供、という流れはとても良いですね*2。 アンケートの回答率がどれくらいだったか、大本営発表が楽しみです。
主催の@mhidakaさん、スタッフ、登壇者の皆さん、また会場提供のサイバーエージェントさんに感謝。 次はDroidcon Tokyoを開催してJeke神を呼ぶ、という話がかなり現実的に聞こえて（見えて）いるので、引き続き期待しています。
