Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
How To Improve UI Quality And Performance
Search
CyberAgent
PRO
November 21, 2023
0
99
How To Improve UI Quality And Performance
UIの安全性、パフォーマンスをVRTやflutter_integrationTestなどを使い、テストの観点から改善。またアクセシビリティの観点からも深掘りします。
CyberAgent
PRO
November 21, 2023
Tweet
Share
More Decks by CyberAgent
See All by CyberAgent
未来のテレビを形づくる ABEMAのグロース戦略:ユーザー体験と品質向上のアプローチ
cyberagentdevelopers
PRO
1
310
IBC 2024 動画技術関連レポート / IBC 2024 Report
cyberagentdevelopers
PRO
1
150
生成AIは安心・安全に貢献できるのか
cyberagentdevelopers
PRO
0
19
AIの血肉となるアノテーションデータのために大事にしている事
cyberagentdevelopers
PRO
2
24
ABEMA NEWSにおける映像データを活用した記事生成AI 〜記事制作者に寄り添ったソリューションにするまで〜
cyberagentdevelopers
PRO
0
45
ACL 2024 参加報告
cyberagentdevelopers
PRO
0
58
生成AIの強みと弱みを理解して、生成AIがもたらすパワーをプロダクトの価値へ繋げるために実践したこと / advance-ai-generating
cyberagentdevelopers
PRO
1
300
SNSマーケティングに革新! ABEMA サッカー動画切り出しを生成AIで自動化し、業務効率化を狙う! / abema-ai-marketing
cyberagentdevelopers
PRO
2
170
新卒1年目が挑む!生成AI × マルチエージェントで実現する次世代オンボーディング / operation-ai-onboarding
cyberagentdevelopers
PRO
1
260
Featured
See All Featured
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
31
2.7k
Six Lessons from altMBA
skipperchong
27
3.5k
Navigating Team Friction
lara
183
14k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
How to Ace a Technical Interview
jacobian
276
23k
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.3k
Fireside Chat
paigeccino
34
3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Transcript
How To Improve UI Quality And Performance CA.flutter 11/14 naruogram
自己紹介 名前: なるお(naruogram) 技術: Flutter, Swift X: @naruogram 所属: Amebaマンガ
経歴: CA24卒内定者
目次 - 第一章: Visual Regression Test 導入へ - 第二章: VRT運用について考える
- 第三章: integration testでパフォーマンス計測
UIの品質とは
UIの品質とは そのサービスがユーザーにとってどれだけ使いやすく、 理解しやすく、効率的であるか (ChatGPT調べ)
UIの品質チェックリスト(自分調べ) - 異なるデバイスでもUIが崩れないか - 異なる状況においてUIが崩れないか - 異なる状況において操作を阻害しないか - 端末の文字サイズによってUIが崩れないか -
エラーハンドリングができているか - アクセシビリティ準拠されているか - その他諸々
手動で確認するのは時間がかかりすぎて辛い😡
テストを使って自動化しよう🥺
第一章: Visual Regression Test 導入へ
第一章: Visual Regression Test 導入へ VRT(Visual Regression Test)とは UIの変更を自動的に検出するテスト手法の一つです。 これにより、新
しいコードの導入や変更がグラフィカルユーザーインターフェースに与 える影響を迅速にキャッチすることができます。 つまりUIの見た目やUIの差分変更を可視化することができる🔥
第一章: Visual Regression Test 導入へ 使用技術 flutter Package: playbook-ui Test
Tool: reg-suit CI: GitHub Actions(linux) Storage: Google Cloud Storage(AWS等でも可)
第一章: Visual Regression Test 導入へ 導入手順 1. playbookを使ってstoryを書く(各ページ等) 2. widgetTestを書く
3. GitHubへPushしてCIを回す 4. reg-suitにて差分比較ができる
第一章: Visual Regression Test 導入へ 1. playbookを使ってstoryを書く(各ページ等)
第一章: Visual Regression Test 導入へ 2. WidgetTestを書く ※ここで端末などを指定できる
第一章: Visual Regression Test 導入へ 3. GitHubActionsでCIを回す ビルドできる状態でreg-suitを走らせる
第一章: Visual Regression Test 導入へ 4. 差分検証 PRにVRTの結果が送られる
第一章: Visual Regression Test 導入へ 4. 差分検証 意図しない変更やUI崩れを確認できる 崩れていた場合は修正できるので 品質を保つ運用ができる
第一章: まとめ - 導入自体はコストが低い - 新規アプリの場合は、最初から導入していると運用が楽 - 既存プロダクトの場合は、重要な部分のみ導入でも効果あり
第二章: VRT運用について考える
UIの品質チェックリスト - 異なるデバイスでもUIが崩れないか - 異なる状況においてUIが崩れないか - 異なる状況において操作を阻害しないか - 端末の文字サイズによってUIが崩れないか -
エラーハンドリングができているか - アクセシビリティ準拠されているか
UIの品質チェックリスト - 異なるデバイスでもUIが崩れないか - 異なる状況においてUIが崩れないか - 異なる状況において操作を阻害しないか - 端末の文字サイズによってUIが崩れないか -
エラーハンドリングができているか - アクセシビリティ準拠されているか VRTで網羅できる部分を考える
UIの品質チェックリスト - 異なるデバイスでもUIが崩れないか - 異なる状況においてUIが崩れないか(一部) - 異なる状況において操作を阻害しないか - 端末の文字サイズによってUIが崩れないか -
エラーハンドリングができているか(一部) - アクセシビリティ準拠されているか(一部)
2-1: 異なるデバイスでもUIが崩れないか
1. 異なるデバイスでもUIが崩れないか Case1: 例えばiOS14以上に対応するアプリを作ったとする iOS14はiPhoneSE(第2世代)がサポートしている。 その場合、サイズの小さい iPhoneSEのサイズにも対応する必要があ る。
1. 異なるデバイスでもUIが崩れないか Case1: 例えばiOS14まで対応するアプリを作ったとする。 iPhone11 iPhoneSE(第二世代)
1. 異なるデバイスでもUIが崩れないか 問題: デバイスによるUI崩れが発生する 解決策: VRTテストにおいてテストする端末を増やす iOS iPhoneSE iPhone11 iPadProMini6
iPadPro6 Android pixel4 lavieT8 xperiaZTablet チームでは下記の端末に対応
1. 異なるデバイスでもUIが崩れないか 選定理由 各OSでの、通常サイズ、タブレットサイズにて 一番大きい端末、小さい端末を採用する 画面サイズの差で起きるUI差分を極限まで減らす
1. 異なるデバイスでもUIが崩れないか 活用事例 - iPhoneSEなどの小さい端末でのUI崩れの発見 - タブレットサイズに対してのUI崩れの発見
2-2: 異なる状況でもUIが崩れないか
2. 異なる状況でもUIが崩れないか Case1: 文字が長いケース Case2: 正しく画像等を取得できなかった場合(通信状況が悪い) UIの状況は、一画面に対しても様々である。
2. 異なる状況でもUIが崩れないか 問題 - 長い文字列や画像のPathがない場合にUIが崩れる 解決策 - 長い文字列のStoryを用意する - 画像がないケースのStoryを用意する
2. 異なる状況でもUIが崩れないか 運用方法 - UIへのチェック項目をルール化する - 複数のシナリオを用意する 効果 - UI崩れの早期発見になる
- UI修正タスクが減少する
2. 異なる状況でもUIが崩れないか 運用方法 - UIへのチェック項目をルール化する - 複数のシナリオを用意する 効果 - UI崩れの早期発見になる
- UI修正タスクが減少する 引数を渡さないと検証できないの?
2. 異なる状況でもUIが崩れないか Fakeを使ってデータを差し替える 1. FakeXXXを用意 2. VRT時にProviderをoverride ※ VRT時は通信処理は使えない
2. 異なる状況でもUIが崩れないか Case3: リファクタリング等で現状のUIを崩していないか否か 機能追加やリファクタリングがUI崩れに繋がる時もあります。 Component等は特に気をつけるべき🚨
2. 異なる状況でもUIが崩れないか 問題 ・リファクタリングなどの変更による デグレの発生 解決策 ・reg-suitを使い、不要な差分を早期発見👀
2. 異なる状況でもUIが崩れないか 活用例 1. リファクタリングをした場合に差分がないか 2. デザイン修正した場合に、不要な差分がないかを確認できる 3. タップ領域のみを拡大した場合に差分がないか (a11y対応)
2-3: 端末の文字サイズによってUIが崩れないか
3. 端末の文字サイズによってUIが崩れないか Case1: 端末の文字サイズを1.5倍や2倍にしている場合 ユーザーは各OSにおいて文字サイズを設定することができる。 その文字サイズはアプリを制御していない場合を除き、適用する。
3. 端末の文字サイズによってUIが崩れないか iOSでの文字サイズの標準と最大の違い
3. 端末の文字サイズによってUIが崩れないか iOSでの文字サイズの標準と最大の違い 文字サイズの変更に対応しなければUIが崩れる
3. 端末の文字サイズによってUIが崩れないか iOSでの文字サイズの標準と最大の違い 文字サイズの変更に対応しなければUIが崩れる 文字サイズに対応することはAccessibility的にも大切
3. 端末の文字サイズによってUIが崩れないか Flutter Accessibility Large Fonts Render text widgets with
user-specified font sizes (引用: flutter.dev) FlutterのAccessibility的にも推奨されている👀
3. 端末の文字サイズによってUIが崩れないか Flutter Accessibility Large Fonts Render text widgets with
user-specified font sizes (引用: flutter.dev) FlutterのAccessibility的にも推奨されている👀 どう対応するのか?
3. 端末の文字サイズによってUIが崩れないか 端末の文字サイズを検知する The number of font pixels for each
logical pixel. For example, if the text scale factor is 1.5, text will be 50% larger than the specified font size. (引用: flutter.dev)
3. 端末の文字サイズによってUIが崩れないか 問題 文字サイズによるUI崩れが発生 解決策 TextScaleFactorの値を設定し、 複数パターンの文字サイズをテストする。
3. 端末の文字サイズによってUIが崩れないか 実際のVRTを実行した結果 1倍 1.5倍
3. 端末の文字サイズによってUIが崩れないか 活用事例 チームでは文字サイズを1倍と1.5倍を使い、テストをしている。 早期発見できた問題 1. サイズを固定にしているWidgetでのUI崩れ(AppBarなど) 2. VRTは成功しているが、文字サイズが大きく、見切れているケース
3. 端末の文字サイズによってUIが崩れないか 引用: https://developers.cyberagent.co.jp/blog/archives/36310/ 詳しくは CyberAgent Developer Blogへ
第二章: まとめ - 効果を大きくするためには、テストする項目を決めるのが大事 - アプリのケースによって、何をテストするかを決めよう - VRTを駆使すれば、作業時間の減少することができる
第三章: flutter integration testで計測する
第三章: integration testで計測 flutter integration testとは Flutterアプリケーションの特定の部分または全体をテストするための方法 です。Integration Testは、アプリケーションの異なる部分が連携して正しく 機能することを確認します。(統合テスト)
※統合テストとは 個々のモジュールやコンポーネントが正しく連携して動作するかを確 認するテスト
第三章: integration testで計測 flutter_integration_testは計測できる👀 特定のタスクの実行中にパフォーマンスタイムラインを記録 し、結果の概要をローカルファイルに保存するテストを作成す る方法。 引用: flutter.dev
第三章: integration testで計測 flutter_integration_testは計測できる👀 特定のタスクの実行中にパフォーマンスタイムラインを記録 し、結果の概要をローカルファイルに保存するテストを作成す る方法。 引用: flutter.dev integration
testを導入してみよう
第三章: integration testで計測 - 従来のintegration testを記述する。 今回のテストではListViewをスクロールし て、一番最後の要素を見つけたら成功とい う処理を書いている。
integration testを使ってパフォーマンス計測してみよう
第三章: integration testで計測 計測するためには 1. traceActionを使用する 2. reportKeyを設定する 引用: flutter.dev
第三章: integration testで計測 計測するためには 3. test_driverフォルダの中に perf_driver.dartを作成する。 4.
テストを実行し、計測結果のjsonが 生成される 引用: flutter.dev
第三章: integration testで計測 生成されたJson - 平均フレームビルド時間 - 最長フレームビルド時間 - 平均フレーム描画時間
- 最長フレーム描画時間 - 平均CPU使用率 - 平均メモリ使用率 これ以外のメトリクスを取得可能
第三章: integration testで計測 - 平均フレームビルド時間: 16ms未満だと60fpsで描画される - 平均CPU使用率: アプリ全体に対して、特定のアクションが異常値の場合、改善の余地あり -
平均メモリ使用率: アプリ全体に対して、特定のアクションが異常値の場合、改善の余地あり (特に対応している最低のスペック端末での検証だと効果が見えやすい)
Tips: 複数のテストを同時に計測する
第三章: integration testで計測 問題 現状だと値が渡せないので、特定のテスト しか、実行できず、都度書き換える必要が ある。
第三章: integration testで計測 解決策(手順1) integrationTestで複数のケースを一度のアクションで実行するには、 all_test.dart(ファイル名は問わない)というファイルを用意し、それぞれのテストを 呼び出す必要がある。
第三章: integration testで計測 解決策(手順2) 1. integration testのシナリオを置い ているフォルダに対して、テスト名 を取得する。 2.
取得したテスト名一覧を使用し、パ フォーマンスの計測結果を複数作成す る。
現実的に活用できる体制を考える
第三章: integration testで計測 効果が期待できる使用方法 1. 現在のアプリのパフォーマンスを確認する。 2. パフォーマンスが落ちている原因を探す。 3. パフォーマンス改善タスクの際に、ローカルで都度テストをして、計測する。
4. 定期的にintegration testのCIを回し、パフォーマンスの著しい低下を防ぐ。
第三章: integration testで計測 効果が期待できない使用方法 1. PR時にPushごとにintegration_testのCIを回す。 - CIのコストが高いため、コストに対しての効果が期待できない。 2. パフォーマンスが求められないアプリでの実行
- 基本的に複雑なアプリではない限り、気にしなくても快適に使用できる。
第三章: まとめ - integration testの導入はコストが高いので必要なケースから対応する - チームの状況によって活用方法は考えるべき
最後に
まとめ - テストは各チームによって必要なものが変わるので、導入は慎重に - VRTは導入コストが低い - integration testは導入コストが高いため検討が必要
ご清聴ありがとうございました🙇