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 １と２が混在するプロダクトの開発で泣いたこととそのワークアラウンド

Recommended

Recommended

More Related Content

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

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

More from Takao Sumitomo

More from Takao Sumitomo (20)

Recently uploaded

Recently uploaded (9)