DroidKaigi2019 2日目、一部オフィスアワーにもいってみたのでメモを。
2日目は朝食も用意されていていました。
オフィスアワーでした質問の内容には、Q/Aとつけてあります。
Dialogflowによる自然言語処理(NLP)を用いたボイスコマンド音声認識の精度向上
DialogFlowによる自然言語処理(NLP)を用いたボイスコマンド音声認識の精度向上
スライド
単純なボイスコマンドの場合
複雑なコマンドでなけれ、SpeechRecognizerだけで十分
ただし、認識は完璧ではないので表記揺れを考慮しとかないといけない。
Q/A どうやって表記ゆれを、集めているのか？
＝＞アプリを使ってもらって集めているが、
何でもかんでも表記ゆれとして入れると、他のワードで逆に認識率が下がったりするので、
取捨選択が重要
複雑なボイスコマンドの場合
DialogFlowのように自然言語処理が必要
DialogFlowを使うことで、自然言語処理について詳しくなくてもコンソールから設定すれば、認識機が作れる。
ただし、固有名詞などを処理しようとすると、コツが必要になってくる。
認識率の改善について
ユーザが認識できないことを言わないようにするのも認識率改善の方法の一つ
あらかじめできることを先にユーザに知らせておくのが重要
誤認識の結果から、ユーザの意図を推測することが重要
どれを学習させるのか、どれを認識の揺れとするのかなど、ここが一番泥臭いポイント
そんな感じで３５％＝＞１７％台にまで誤認識を減らせた。
Q/A 改善しても、それでも誤認識するものってどんなものがあったのか？
上記の話は英語での話だったのだが、認識できなかったのは、
そもそも意味不明な内容だった。
どうやっても認識しようのないものというのも出てくる。
↓の内容は、セッションの内容とは関係なかったのだが、会社で作っているアプリについても聞いてみた。
Q/A
ActivityRecognitionとかセンサーの値を使った機能のデバッグはどうやっている？
カーシェアで車を借りて実際に試している。
Wi-Fi RTTによる屋内測位アプリを作ろう
スライド
前のセッションのオフィスアワーがあったので、最初のほうが聞けていない。
Google Wifiだけがしれっと対応しているとのこと。
用途的に、イベントとかでないとつらそうな感じだった。
測位する場所の地図が必要だったり、専用のAPが必要だったりとハードルが高い。
測位できる環境が作れても、センサーの値はかなりブレがある。
デモ動画があったが、何かしらフィルターをかけないと厳しいぐらいブレがあった。
カスタムブラウザの作り方 ー 実例から学ぶ Chrome と Firefox のカスタムビルド開発 ー
なんかレッサーパンダのぬいぐるみがおいてある。かわいい。
ブラウザのビルド簡単なようで難しいという感じ。
ちょっとカスタムするなら内容にもよるが、簡単
基本的にビルドはめちゃくちゃ大変 数時間単位
AndroidのFirefoxやChrominiumをビルドしたい人は必見だが、めっちゃニッチでマニアック。
SpekでUnitTestを書こう
スライド
Android EnterPriseで実現できる端末管理の世界
MDM？
Mobile Device Management
会社が従業員の端末を管理したい
問題点
OSバージョアップで、制限できることが減ってしまっている
そこで Android Enterprice （元Android for Work）
Android Enterprizeについて
Google Playの管理ができる
ただし、Googleの許可が必要
文鎮化デモ動画
注意点
Android9 からdepricated
Android 10では Enterprize に完全移行
Q/A キオスク端末とかで、通信ポート制限とかはできる？
＝＞ポート制限する案件は結構あるけど、Enterprizeにその機能はないので、アプリ側で頑張るしかない。
Navigation Architecture Component によるアプリ内遷移の管理
スライド
DeepLinkもnavigationのXMLとAndroidManifestに書くだけで実装できるので、めっちゃお手軽
しかも、DeepLinkでもバックスタックをちゃんと作ってくれて便利
マルチモジュールでNavigation使おうとするとツライ
アクティビティ名をハードコーティングしたり、リフレクションを使うことになる
現状は共通モジュールにNavigationをもたせてリフレクションさせるのが良さそう
今回のDroidKaigi2019のような構成
ああ、素晴らしきTDD ~アプリとエンジニアの心に安寧を~
スライド
https://www.slideshare.net/SaikiIijima/tdd-130994383
画面分割して、テストとソースを並べて、かなり頻繁に行き来しながら書いていく
テストを通す以上に実装してはならないルールを守るのかなり難しそう
自分のテストコードの書き方の考えとめちゃくちゃ乖離していた。
自分の想像以上にテストコードとソースの行き来が多い
工数の見積もりは、実装にテストも含める
（＜＝ 実装と切り離せないくらい行き来するから）
テストの粒度
テストは１つの振る舞いごとに書く
BLEアプリ設計パターン
スライド
Qrio Lockアプリのノウハウの紹介
BLE
低用量（バイト単位）で低頻度の通信が得意
Bluetoothだと1ヶ月しか持たないバッテリーが1年持つようになる。
BLEには、20バイトの壁がある
BLEの通信経路は暗号化されないので自前で用意しないといけない。
あるにはあるが、使える状況がかぎられる。
低レイヤーの部分を結構自作する必要があって、いろいろ辛い。
まとめ
本当はコードラボにも行ってみようと思っていたが、部屋が満員で入れなかった。
オフィスアワーは現地へ行っているからこその部分なので、もっと行っておけば良かったと思った。
けど、あんまりオフィスアワーに来ている人が少ない感じだった。
セッションはあとからでもYoutubeで見れるはずなので、現地へ行ってるならオフィスアワーに積極的に行くべき。
1日中内容の濃いセッションを聞き続けて、かなりハードであった。
最後の方のセッションは本当にヘトヘト状態になっていた。
この2日間、かなりの知見が得られたり、いろいろと体験できた。
ぜひ一度、現地へ行って、あの熱気にあふれる空間を体験してみると良いかもしれない。
ただし、来年は会社のお金で行こう。
コメント