Camera API １と２が混在するプロダクトの開発で泣いたこととそのワークアラウンド

©2018 Wantedly, Inc. 2018-03-20 shibuya.apk #23 @cattaka_net
Camera API １と２が混在するプロダクトの開発で
泣いたこととそのワークアラウンド
20.Mar.2018 – Takao Sumitomo

ページタイトルページサブタイトル
©2018 Wantedly, Inc.©2018 Wantedly, Inc. 2018-03-20 shibuya.apk #23 @cattaka_net
自己紹介
●
住友孝郎(Takao Sumitomo)
– Wantedly 所属
– Androidアプリを主担当
●
こんなアプリ作ってます
– Wantedly People
– 名刺管理アプリ
– リアルタイムに名刺を認識して取り込むアプリ

今回はCamera API 1 / 2についてのお話です

おさらい

新旧２つのAPI
● Camera API 1
– プレビューを表示して、シャッターを切る
– 一般的なカメラを意識したインターフェースで制限が多い
● Camera API 2
– カメラの内部イベントをJava層に引っ張り出したようなインターフェース
– 自由度は高いけど扱いが難しい

なんで混在させたか？

理由
●
当時は4.xを切るわけに行かなかった
– 市場で数割はマーケティング費用に換算すると大きい
●
Camera API 2でもLegacyモードのデバイスはパフォーマンスが悪い
●
Camera API 1はプレビューの解像度がFHDが上限
良いとこ取りをしたい！

混在させる実装アプローチ

抽象化したらいいやん？
ICameraEngine
CameraEngine1 CameraEngine2
Camera API 1 Camera API 2
アプリからは
これだけを意識する

茨の道でした

どちらもコールバックで
フレームを受け取るが、、、
● Camera API 1
–コールバックは原則UIThreadで呼ばれる
● Camera API 2
–コールバックのスレッドを選べる
UIThreadで重い処理をしたくない

フレームをRxJavaで
ストリームにしたら行けるでしょ？
http://reactivex.io/documentation/operators/backpressure.html より

簡単には行かない！
●
フレームのサイズが大きすぎる
–FHD：1920x1080x32bit ≒ 8.3MB
–QHD：3840x2160x32bit ≒ 33.2MB

OOMの危険
●
認識ロジックは時間が掛かるので、詰まると即OOMになる
●
RxJavaのBackpressureも考えたが、緻密な制御が必要なので怖い

結局、バッファとセマフォで
制御をフルスクラッチした

つまり筋力でカバー

機種依存をどうやって確認するか？

クラウドテストが使えない
●
リモートでテストできるけど触れない...
–Firebase Test Lab
–Amazon Device Farm
–etc
操作感の確認は実機を触るしか無い

気合で実機でテスト
●
シェア上位の60機種をリストアップ
●
検証センターに篭った

それでも出てくる機種依存
●
CameraCharacteristicsで確認してるのに、組み合わせで駄目なデバイスがある
– 駄目な場合に「何もしない」にフォールバックするデバイス
●
コアバリューに影響する
– AutoFocusやAutoWhiteBalanceが動かない
●
android.os.Build を見て個別に対応を入れた

まとめ

ギリギリの環境はフルスクラッチしかない

機種依存の確認はひたすら実機で検証

筋トレしていこう

ご清聴ありがとうございました

Camera API １と２が混在するプロダクトの開発で 泣いたこととそのワークアラウンド

More Related Content

More from Takao Sumitomo