How To Improve UI Quality And Performance

Transcript

1. How To Improve UI Quality And Performance CA.flutter 11/14 naruogram
2. 自己紹介 名前: なるお(naruogram) 技術: Flutter, Swift X: @naruogram 所属: Amebaマンガ 経歴: CA24卒内定者
3. 目次 - 第一章: Visual Regression Test 導入へ - 第二章: VRT運用について考える - 第三章: integration testでパフォーマンス計測
4. UIの品質とは
5. UIの品質とは そのサービスがユーザーにとってどれだけ使いやすく、 理解しやすく、効率的であるか (ChatGPT調べ)
6. UIの品質チェックリスト(自分調べ) - 異なるデバイスでもUIが崩れないか - 異なる状況においてUIが崩れないか - 異なる状況において操作を阻害しないか - 端末の文字サイズによってUIが崩れないか - エラーハンドリングができているか - アクセシビリティ準拠されているか - その他諸々
7. 手動で確認するのは時間がかかりすぎて辛い😡
8. テストを使って自動化しよう🥺
9. 第一章: Visual Regression Test 導入へ
10. 第一章: Visual Regression Test 導入へ VRT(Visual Regression Test)とは UIの変更を自動的に検出するテスト手法の一つです。 これにより、新 しいコードの導入や変更がグラフィカルユーザーインターフェースに与 える影響を迅速にキャッチすることができます。 つまりUIの見た目やUIの差分変更を可視化することができる🔥
11. 第一章: Visual Regression Test 導入へ 使用技術 flutter Package: playbook-ui Test Tool: reg-suit CI: GitHub Actions(linux) Storage: Google Cloud Storage(AWS等でも可)
12. 第一章: Visual Regression Test 導入へ 導入手順 1. playbookを使ってstoryを書く(各ページ等) 2. widgetTestを書く 3. GitHubへPushしてCIを回す 4. reg-suitにて差分比較ができる
13. 第一章: Visual Regression Test 導入へ 1. playbookを使ってstoryを書く(各ページ等)
14. 第一章: Visual Regression Test 導入へ 2. WidgetTestを書く ※ここで端末などを指定できる
15. 第一章: Visual Regression Test 導入へ 3. GitHubActionsでCIを回す ビルドできる状態でreg-suitを走らせる
16. 第一章: Visual Regression Test 導入へ 4. 差分検証 PRにVRTの結果が送られる
17. 第一章: Visual Regression Test 導入へ 4. 差分検証 意図しない変更やUI崩れを確認できる 崩れていた場合は修正できるので 品質を保つ運用ができる
18. 第一章: まとめ - 導入自体はコストが低い - 新規アプリの場合は、最初から導入していると運用が楽 - 既存プロダクトの場合は、重要な部分のみ導入でも効果あり
19. 第二章: VRT運用について考える
20. UIの品質チェックリスト - 異なるデバイスでもUIが崩れないか - 異なる状況においてUIが崩れないか - 異なる状況において操作を阻害しないか - 端末の文字サイズによってUIが崩れないか - エラーハンドリングができているか - アクセシビリティ準拠されているか
21. UIの品質チェックリスト - 異なるデバイスでもUIが崩れないか - 異なる状況においてUIが崩れないか - 異なる状況において操作を阻害しないか - 端末の文字サイズによってUIが崩れないか - エラーハンドリングができているか - アクセシビリティ準拠されているか VRTで網羅できる部分を考える
22. UIの品質チェックリスト - 異なるデバイスでもUIが崩れないか - 異なる状況においてUIが崩れないか(一部) - 異なる状況において操作を阻害しないか - 端末の文字サイズによってUIが崩れないか - エラーハンドリングができているか(一部) - アクセシビリティ準拠されているか(一部)
23. 2-1: 異なるデバイスでもUIが崩れないか
24. 1. 異なるデバイスでもUIが崩れないか Case1: 例えばiOS14以上に対応するアプリを作ったとする iOS14はiPhoneSE(第2世代)がサポートしている。 その場合、サイズの小さい iPhoneSEのサイズにも対応する必要があ る。
25. 1. 異なるデバイスでもUIが崩れないか Case1: 例えばiOS14まで対応するアプリを作ったとする。 iPhone11 iPhoneSE(第二世代)
26. 1. 異なるデバイスでもUIが崩れないか 問題: デバイスによるUI崩れが発生する 解決策: VRTテストにおいてテストする端末を増やす iOS iPhoneSE iPhone11 iPadProMini6 iPadPro6 Android pixel4 lavieT8 xperiaZTablet チームでは下記の端末に対応
27. 1. 異なるデバイスでもUIが崩れないか 選定理由 各OSでの、通常サイズ、タブレットサイズにて 一番大きい端末、小さい端末を採用する 画面サイズの差で起きるUI差分を極限まで減らす
28. 1. 異なるデバイスでもUIが崩れないか 活用事例 - iPhoneSEなどの小さい端末でのUI崩れの発見 - タブレットサイズに対してのUI崩れの発見
29. 2-2: 異なる状況でもUIが崩れないか
30. 2. 異なる状況でもUIが崩れないか Case1: 文字が長いケース Case2: 正しく画像等を取得できなかった場合(通信状況が悪い) UIの状況は、一画面に対しても様々である。
31. 2. 異なる状況でもUIが崩れないか 問題 - 長い文字列や画像のPathがない場合にUIが崩れる 解決策 - 長い文字列のStoryを用意する - 画像がないケースのStoryを用意する
32. 2. 異なる状況でもUIが崩れないか 運用方法 - UIへのチェック項目をルール化する - 複数のシナリオを用意する 効果 - UI崩れの早期発見になる - UI修正タスクが減少する
33. 2. 異なる状況でもUIが崩れないか 運用方法 - UIへのチェック項目をルール化する - 複数のシナリオを用意する 効果 - UI崩れの早期発見になる - UI修正タスクが減少する 引数を渡さないと検証できないの?
34. 2. 異なる状況でもUIが崩れないか Fakeを使ってデータを差し替える 1. FakeXXXを用意 2. VRT時にProviderをoverride ※ VRT時は通信処理は使えない
35. 2. 異なる状況でもUIが崩れないか Case3: リファクタリング等で現状のUIを崩していないか否か 機能追加やリファクタリングがUI崩れに繋がる時もあります。 Component等は特に気をつけるべき🚨
36. 2. 異なる状況でもUIが崩れないか 問題 ・リファクタリングなどの変更による デグレの発生 解決策 ・reg-suitを使い、不要な差分を早期発見👀
37. 2. 異なる状況でもUIが崩れないか 活用例 1. リファクタリングをした場合に差分がないか 2. デザイン修正した場合に、不要な差分がないかを確認できる 3. タップ領域のみを拡大した場合に差分がないか (a11y対応)
38. 2-3: 端末の文字サイズによってUIが崩れないか
39. 3. 端末の文字サイズによってUIが崩れないか Case1: 端末の文字サイズを1.5倍や2倍にしている場合 ユーザーは各OSにおいて文字サイズを設定することができる。 その文字サイズはアプリを制御していない場合を除き、適用する。
40. 3. 端末の文字サイズによってUIが崩れないか iOSでの文字サイズの標準と最大の違い
41. 3. 端末の文字サイズによってUIが崩れないか iOSでの文字サイズの標準と最大の違い 文字サイズの変更に対応しなければUIが崩れる
42. 3. 端末の文字サイズによってUIが崩れないか iOSでの文字サイズの標準と最大の違い 文字サイズの変更に対応しなければUIが崩れる 文字サイズに対応することはAccessibility的にも大切
43. 3. 端末の文字サイズによってUIが崩れないか Flutter Accessibility Large Fonts Render text widgets with user-specified font sizes (引用: flutter.dev) FlutterのAccessibility的にも推奨されている👀
44. 3. 端末の文字サイズによってUIが崩れないか Flutter Accessibility Large Fonts Render text widgets with user-specified font sizes (引用: flutter.dev) FlutterのAccessibility的にも推奨されている👀 どう対応するのか?
45. 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)
46. 3. 端末の文字サイズによってUIが崩れないか 問題 文字サイズによるUI崩れが発生 解決策 TextScaleFactorの値を設定し、 複数パターンの文字サイズをテストする。
47. 3. 端末の文字サイズによってUIが崩れないか 実際のVRTを実行した結果 1倍 1.5倍
48. 3. 端末の文字サイズによってUIが崩れないか 活用事例 チームでは文字サイズを1倍と1.5倍を使い、テストをしている。 早期発見できた問題 1. サイズを固定にしているWidgetでのUI崩れ(AppBarなど) 2. VRTは成功しているが、文字サイズが大きく、見切れているケース
49. 3. 端末の文字サイズによってUIが崩れないか 引用: https://developers.cyberagent.co.jp/blog/archives/36310/ 詳しくは CyberAgent Developer Blogへ
50. 第二章: まとめ - 効果を大きくするためには、テストする項目を決めるのが大事 - アプリのケースによって、何をテストするかを決めよう - VRTを駆使すれば、作業時間の減少することができる
51. 第三章: flutter integration testで計測する
52. 第三章: integration testで計測 flutter integration testとは Flutterアプリケーションの特定の部分または全体をテストするための方法 です。Integration Testは、アプリケーションの異なる部分が連携して正しく 機能することを確認します。(統合テスト) ※統合テストとは 個々のモジュールやコンポーネントが正しく連携して動作するかを確 認するテスト
53. 第三章: integration testで計測 flutter_integration_testは計測できる👀 特定のタスクの実行中にパフォーマンスタイムラインを記録 し、結果の概要をローカルファイルに保存するテストを作成す る方法。 引用: flutter.dev
54. 第三章: integration testで計測 flutter_integration_testは計測できる👀 特定のタスクの実行中にパフォーマンスタイムラインを記録 し、結果の概要をローカルファイルに保存するテストを作成す る方法。 引用: flutter.dev integration testを導入してみよう
55. 第三章: integration testで計測 - 従来のintegration testを記述する。 今回のテストではListViewをスクロールし て、一番最後の要素を見つけたら成功とい う処理を書いている。
56. integration testを使ってパフォーマンス計測してみよう
57. 第三章: integration testで計測 計測するためには 1. traceActionを使用する 2. reportKeyを設定する 引用: flutter.dev
58. 第三章: integration testで計測 計測するためには 3. test_driverフォルダの中に 　 　 perf_driver.dartを作成する。 4. テストを実行し、計測結果のjsonが 　 生成される 引用: flutter.dev
59. 第三章: integration testで計測 生成されたJson - 平均フレームビルド時間 - 最長フレームビルド時間 - 平均フレーム描画時間 - 最長フレーム描画時間 - 平均CPU使用率 - 平均メモリ使用率 これ以外のメトリクスを取得可能
60. 第三章: integration testで計測 - 平均フレームビルド時間: 16ms未満だと60fpsで描画される - 平均CPU使用率: アプリ全体に対して、特定のアクションが異常値の場合、改善の余地あり - 平均メモリ使用率: アプリ全体に対して、特定のアクションが異常値の場合、改善の余地あり (特に対応している最低のスペック端末での検証だと効果が見えやすい)
61. Tips: 複数のテストを同時に計測する
62. 第三章: integration testで計測 問題 現状だと値が渡せないので、特定のテスト しか、実行できず、都度書き換える必要が ある。
63. 第三章: integration testで計測 解決策(手順1) integrationTestで複数のケースを一度のアクションで実行するには、 all_test.dart(ファイル名は問わない)というファイルを用意し、それぞれのテストを 呼び出す必要がある。
64. 第三章: integration testで計測 解決策(手順2) 1. integration testのシナリオを置い ているフォルダに対して、テスト名 を取得する。 2. 取得したテスト名一覧を使用し、パ フォーマンスの計測結果を複数作成す る。
65. 現実的に活用できる体制を考える
66. 第三章: integration testで計測 効果が期待できる使用方法 1. 現在のアプリのパフォーマンスを確認する。 2. パフォーマンスが落ちている原因を探す。 3. パフォーマンス改善タスクの際に、ローカルで都度テストをして、計測する。 4. 定期的にintegration testのCIを回し、パフォーマンスの著しい低下を防ぐ。
67. 第三章: integration testで計測 効果が期待できない使用方法 1. PR時にPushごとにintegration_testのCIを回す。 - CIのコストが高いため、コストに対しての効果が期待できない。 2. パフォーマンスが求められないアプリでの実行 - 基本的に複雑なアプリではない限り、気にしなくても快適に使用できる。
68. 第三章: まとめ - integration testの導入はコストが高いので必要なケースから対応する - チームの状況によって活用方法は考えるべき
69. 最後に
70. まとめ - テストは各チームによって必要なものが変わるので、導入は慎重に - VRTは導入コストが低い - integration testは導入コストが高いため検討が必要
71. ご清聴ありがとうございました🙇