読者です 読者をやめる 読者になる 読者になる

やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

第1回 #DroidKaigi に行ってきました

AndroidエンジニアのAndroidエンジニアによるAndroidエンジニアのためのカンファレンス、第1回*1 DroiKaigiに参加してきました。

f:id:nowsprinting:20150427003737j:plain

発表資料は公開されていますので、簡単なメモと感想だけ残します。

droidkaigi.github.io

基調講演(@yanzmさん)

  • マッチョなActivity
    • Android 2.2までは個人開発者の時代
    • Android 4.3まで、アプリベンチャーの時代
    • Android 5.0はインフラ化の時代。Material Designはアニメーションに本気で取り組むと大変
    • Activityにすべて書いていたら破綻する
    • 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』は、ベータ版を脱するための加筆候補がたくさんあるそうです。

tatsu-zine.com

CardboardのUXをカメラで向上する(@ken1_takaさん / Room B)

  • Oculus Riftはケーブルとか面倒
  • Cardboardはお手軽。でもタッチパネルが使えないので操作に難あり
  • Cardboardにはカメラ穴があいてるので利用したい
  • Cardboard SDK: 複眼ビュー、樽ゆがみ、マグネットボタン
  • OpenCVでカメラ画像を認識させて、ジェスチャー操作させる

デモアプリが(高速化に失敗して)動かなくなったとのことで残念。OpenCVで指の形状・ジェスチャーを認識できるデモは見ることができました。

なお、OpenCVで頑張るほか、Leap MotionAndroid SDK(今はアルファ版)を待つという選択肢もありますね。

www.leapmotion.com

あるゲームアプリケーションの構成とアップデートサイクル(@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版でなくフル版を配る、というのは良さそう。ぜひ真似したい。

紹介されていた書籍。ビルド職人の端くれ(兼業)として、ポチりました。

ゲーム・映像制作パイプライン構築マニュアル

ゲーム・映像制作パイプライン構築マニュアル

ソフトウェア一般としてはこちらもオススメ。

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

アプリの企画、プロトタイプからリリースに至るまで(@__chocomelonさん / Room A)

  • pixivマンガ。少人数のチーム、ファーストリリースまで3ヶ月
  • 以下の順で開発
    1. ストアの紹介文をメンバー全員で持ち寄って大喜利。アプリの売りを明確化
    2. 雑なプロトタイプ。機能ごとに、雑に。メンバーが物理的に近いことが大事。
    3. イメージ共有後、デザイナーがSketchでライブデザイン
    4. アプリのプロトタイプを作る
      • これもコードは捨てる前提。言語、ライブラリなどを試す。
      • DeployGateで社内で使ってもらう
      • バグの印象がユーザに残ってしまうので、雑過ぎなのもよくない
      • 毎日やっていると、バグフィックスなどに追われて本来のプロトタイプとして機能しなかったので、3日サイクルくらいに。
      • ふりかえり
    5. コーディング。プロトは捨てる
      • サービスで使う言葉を統一する("編集部オススメ"→"EditorsPick"とか)
      • CircleCIでdevelopブランチの変更ごとにビルドして、DeployGateにcurlで上げる
      • 新規開発なのでPull Requestが巨大になりがち。こまめにコミット、こまめにPR
      • ちゃんとKPTでふりかえるようにした。週一。
      • リリース前2weekをバグフィクスにあてる。機能の多さよりクオリティを担保。
  • 以降のリリースサイクルは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
    • ELF形式、共有ライブラリ(.so)と同じ
    • リンカ、ローダはOAT独自
    • .rodataセクション:Linux標準のものに加え、DEXそのもの、GCガイド情報など
    • .oat_patchesセクション:OAT独自。イメージの再配置情報
  • QuickコンパイラJITコンパイラベース(だけどARTでは高速化されている)
  • ほかのコンパイラは最新のmasterでは削除されている
  • Quickは、LIR層までCPU依存でない(DalvikはLIRはCPU依存だった)

他のセッションと比較して、はじめからハードル高めな低レイヤの話でした。まずDalvikを知るべし。

tatsu-zine.com

買ってあるけど読めてません…

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 StudioGUIでもかなり色々設定できる(build.gradleに反映される)
  • 記述方法は、『Android実践プログラミング』第5章および、GitHubで公開しているandroid_gradle_templateリポジトリを参照

techbooster.booth.pm

github.com

アプリを公開する前に、最低限知っておきたいセキュリティ事項(@tao_gakuさん / Room A)

Android Security 安全なアプリケーションを作成するために

Android Security 安全なアプリケーションを作成するために

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を隠す
  • @yanzmさんに加わってもらったことを契機に、メンバー増加に備えた
    • コーディング規約などを整備、CONTRIBUTIONS.mdに集約した
    • JavaDocはちゃんと書くようにした。API Clientは特に丁寧に書く。
    • ActivityやFragmentの継承(BaseActivity/Fragment)をどうすべきか問題。Frilでは使わないこととした
  • リニューアル後、滞在時間2倍くらい、継続率も伸びてる、売買の成約率も上昇。
  • 登録の動線も見直し、離脱率も削減。
  • Googleの2014 Best Appに選ばれた
  • Android 4.0以上にした。2.3向けに旧バージョンを提供はしている。

今ならSupport Libraryがあるとは言え、「導入しました」では済まないところなので大変参考になりました。

なかでも、ガイドラインユーザビリティのくだりは身につまされました。ActionButtonをタブのように使うのは気持ち悪いだろうな、と。でも、既存ユーザの慣れの問題なのか、動線の問題なのかまで踏み込んでいるので、気持ち悪いながらも決断したというところでしょうか。

所感

connpassによる募集は瞬殺、大量のキャンセル待ちを抱えたイベントでした。通常、首都圏のこの手の参加費無料イベントは当日キャンセルも多く、6〜7割くらいの入りになってしまうものですが、今回は10:00の開始時点でかなり席が埋まっているという状態。しかも年齢層が若い。

Android関係の開発者コミュニティの活動が鈍っている、という話はかなり前から聞き、また実感していたところですが、これを見ると需要はあって、個々のコミュニティでうまく世代交代ができずに失速しただけなのかも。

またスタッフの人数も多く、とても至れり尽くせりなイベントでした。スケジュールアプリの提供と、アプリからアンケートフォームを開き、回答してくれた人にステッカーを提供、という流れはとても良いですね*2。 アンケートの回答率がどれくらいだったか、大本営発表が楽しみです。

主催の@mhidakaさん、スタッフ、登壇者の皆さん、また会場提供のサイバーエージェントさんに感謝。 次はDroidcon Tokyoを開催してJeke神を呼ぶ、という話がかなり現実的に聞こえて(見えて)いるので、引き続き期待しています。

*1:と言っていい気がしたけど、次はDroidcon Tokyoになる可能性も?

*2:この手のイベントを主催するとだいたいいつも問題になるので、できれば真似したい