Reality tech blogを読む
Androidアプリ開発
iOS
iOSでのタイのアプリ配信
>チームが雰囲気で行っていた様々な命名規則やUI実装方法を改めて統一したり
>開発者が既に転職してしまった部分のコードをローカライズしたり
>現在はそれなりに一般的な MVVM + CleanArchitecture を RxSwift を軸にして開発しており、エッセンスとして kickstarter/ios-oss や CleanArchitectureRxSwift を参考にしています。
>ツールの選定は割と自由にやっているのですが「開発に関わるあらゆるコマンドは全てMakefileから実行できる（ターゲットを作る）ようにする」というルールにしています。
利用しているライブラリのリスト
課題
> - CI / CD 環境(Jenkins)のメンテナンスコスト
開発体制
根深いバグを倒す機会がある
ユーザー向け成果発表
著者：メタルおじさん
iOS/Androidエンジニア
音声がぷつぷつするとは
1. 無音区間がある
回線が不安定で音声データが到着していない
2. 非連続区間がある
Android 11からスクリーンレコード機能で音声を書き出してスペクトラム解析したら2だった
サーバーのアーカイブ音声は非連続区間はなかった
この時点でAndroidの音声処理に何らかの問題があるとアタリをつけた
アプリ固有の問題だった
>声の再生を一時停止したときに音声データ出力スレッドを止めていなかっなったとか再生開始の関数を呼ぶたびに音声データ出力スレッドが増殖していたとか…詳細はREALITYに固有のコードになるのでここでは触れませんが、問題を見つけて修正することができました。
REALITY新卒サーバエンジニア うすぎぬ
OSごとに音量が異なる問題の改善
課題
配信音量が異なる問題がOS起因なのかが不明
どの程度小さいのかが不明
配信音量の評価指標がない
配信者が配信する音声の音量
視聴者が再生する音量
配信枠全体での人間の聴覚特性を考慮した配信音量を絶対値評価したいという目的があった
配信の分析
OSごとにヒストグラムをとったところAndroidはiOSより全体的に小さかった
原因は不明
>iOSは自動で入力音声信号の音量を自動調整しているのか？
視聴の分析
>そんなん、端末ごとにスピーカーも違うし、絶対音量は違うやんという感じがしますが、OS別の出力音声のラウドネス傾向に明らかな違いが見られれば両OSの視聴環境を揃える方向に改修する必要がありますので、調査は必要です。
防音室で音量マックスで録音
ラウドネスの異なる音源を鳴らして確認するとiOSは音量を調節していそうな結果となった
対応
Androidにも音量バランス調整を入れる
>REALITYでは配信時のマイクのノイズ抑制をするためにspeexdspというライブラリを使用しているのですが、その中にAutomaticGainControlという「いい感じに音量を調整してくれる機能」が用意されていたので使用してみました。
ラウドネスは改善したが、ノイズや環境音も大きかったのでOFFに
>配信・視聴時に端末が熱くなる問題を解決すべく、端末の温度を定期的に自動計測する仕組みを考えました。
> 運用化まで至っておりませんが、UIテストフレームワークやプロファイラを駆使した自動化についてまとめた
realityはリッチ
基本：3Dアバター + フェイストラッキング + 配信
付随：ギフト, コラボ配信, ゲーム
3つの処理を並行実行
>1. アプリをインストールし、指定の配信画面まで自動遷移する処理
UIテストを実施
>iOS/Androidともに配信画面はUnity上のUI部品を特定するのが難しいため、座標指定による特定位置の押下処理を行うワークアラウンド
>Androidは配信画面のUIテストが実現できている
>2. 指定の配信画面上で一定時間ギフトを投下する処理
描画処理に負荷をかけてデバイスの温度を上げる
profilerで温度情報が取れる
>Jetifierはライブラリ内に存在するサポートライブラリ（android.support.*）への依存を、対応するAndroidXのパッケージ（androidx.*）に自動的に書き換えてくれるツールです。
>一見すると便利に見えるJetifierですが、一方でビルドパイプラインを複雑にし、変換作業のためにビルド時間が増えてしまう、という隠れた問題があります。
結果：計測したがビルド時間が変わらなかった
>REALITYは流行りのライブラリをフル活用して開発するというよりは、本当に必要な（安定した）ものだけを導入する思想で開発をしています。