Technology selection for mobile cross-platform

2021/9/8（水）19:00〜　ラクスR&D Meetup - Flutterでの発表資料です。

Transcript

1. ©2020 RAKUS Co., Ltd. モバイル開発を省力化する クロスプラットフォームツールの評 価 2021/9/8 ラクスR&DMeetup Takuya Okamoto
2. Takuya Okamoto • Job ◦ 株式会社ラクス技術推進課に所属 ◦ 先行技術検証（技術推進PJ）の運営 ◦ 非エンジニア向けの技術勉強会の運営 • Career ◦ 2017年〜Webエンジニア ◦ Spring FW、Nuxt.js、AWS ◦ Java研修講師、資格対策本の執筆 • Hobby ◦ 野球 ◦ 筋トレ ◦ アウトドア ▪ 釣り ▪ キャンプ 2
3. アジェンダ 1. ラクスR&D Meetupの紹介 2. 研究テーマ（モバイルクロスプラットフォーム）の紹介 3. 研究結果 4. 技術選定の実例 3
4. ラクスR&D Meetup 4
5. ラクスR&D Meetup ラクスでは継続的にサービスを成長させるために、新しい技術要素を実際に導入する前 に先行検証する「技術推進プロジェクト」というプロジェクトを進めています。 このプロジェクト内で検証した結果については弊社テックブログでも紹介していますが、 勉強会という形式でも共有していこうと思います。 今回は「モバイルクロスプラットフォーム」の導入検証について当社事例を共有いたしま す。 5
6. 研究テーマの紹介 6
7. • ラクスの課題 ◦ ラクスの開発チームは Webエンジニアがメイン ◦ モバイルアプリの要件が上がると Webエンジニアが開発する可能性 ◦ クロスプラットフォームツールを検証する必要がある ▪ Webエンジニアでもモバイルアプリ開発できる ▪ 開発にかかる工数を削減できる • 想定するゴール ◦ ネイティブ言語での開発と比べて、開発を省力化できるか ◦ 開発を省力化できるなら何を利用すべきか選定する モバイルクロスプラットフォーム 7
8. 研究の結論 1. モバイルクロスプラットフォームを利用すれば、 Web開発者でもモバイルアプリを少ない工数で開発できる 2. まずはFlutterの導入を検討すべき ◦ 弱点が最も少なく汎用性が高い ◦ 開発言語（Dart）がWebエンジニアにとって親和性が高い 8
9. モバイルクロスプラットフォームの検証 9
10. ラクスで求められるモバイルアプリ 1. メインのWebサービスのサブシステムとしてのアプリ ◦ モバイル機能（カメラ・NFCなど）をサブシステムとして利用 ◦ 例）楽楽精算アプリ・楽楽精算カードリーダーアプリ 2. Webアプリのモバイル版 ◦ 一部のモバイル機能を利用しつつ WebViewでWebアプリを表示する モバイル機能に特化するアプリはあまり要求されない 10
11. 省力化の定義 • ネイティブと同じ開発環境が整っていること • ネイティブより学習コストが低い • ネイティブと同じ機能を実装できる • ネイティブより実装時間、コード量を削減できる ※ネイティブ：iOSとAndroid、ネイティブ言語：SwiftとKotlin 11
12. 選定したツール 主にWeb技術を活かせるかという観点で各ジャンルから選定 • ハイブリット型 Cordova、Ionic Framework、Monacaなど　→　Ionic Framework • ネイティブ型 Xamarin、React Nativeなど　→　React Native • 独自レンダラ型 Flutter、Unityなど　→　Flutter 12 VS VS
13. 検証方法・比較観点 • 検証方法 ◦ 同じ機能のサンプルアプリを実装 ◦ ネイティブとクロスプラットフォームで実装結果を比較 • 比較観点 ◦ 開発環境 ◦ 学習コスト ◦ ネイティブ機能実装 13
14. 結論① Web開発者でもモバイルアプリを少ない工数で開発できる 14
15. クロスプラットフォームは開発を省力化できる ラクスで求められるモバイルアプリでは省力化できる • 開発環境が整っていること ◦ 同等、または劣っているのの致命的ではない • 学習コストが低い ◦ 1つのネイティブ言語よりも低い、または同等 • 同じ機能を実装できる ◦ 一部実現できないが、事前に把握しツールを選択する • 実装時間、コード量を削減できる ◦ 検証の範囲では1コードで2つのOSに対応できる 15
16. 開発環境 学習コスト 機能実装 16
17. 開発環境の検証結果 17 • Ionic Frameworkはデバッグツール、デザインツールに不安 • React Nativeはデザインツールが劣っているものの、ほぼ同等の開発環境 • Flutterはネイティブと同等の開発環境 Ionic Framework React Native Flutter エディター 〇 Visual Studio Code 〇 Visual Studio Code 〇 Visual Studio Code Android Studio デバッグツール △ Browser DevTools 〇 React Native DevTools 〇 Flutter DevTools デザインツール △ Browser DevTools & Hot reload △ React Native DevTools & Hot reload 〇 Flutter DevTools & Hot reload
18. 開発環境 学習コスト 機能実装 18
19. 学習コストの比較 • ネイティブの2言語（Swift・Kotlin）との比較 • プログラミング言語・ライフサイクルの学習コスト • エンジニアごとに比較 ◦ フロントエンド経験者（FE経験者）：Angular、React、Vue.jsの開発経験 ◦ バックエンド経験者（BE経験者）：JavaなどのOOP経験 ◦ ラクスはバックエンドエンジニアが多い ※評価者は私（バックエンド経験5年・フロントエンド経験1年） 19
20. 学習コストの検証結果まとめ • フロントエンド経験者 ◦ Web技術で開発できるため、 Ionic FrameworkとReactNativeの学習コストが低い • バックエンド経験者 ◦ DartがOOPでJavaScriptの文法も活かせるので学習コストが低い 20 Ionic Framework React Native Flutter 言語 フレームワーク JavaScript・TypeScript Angular・React・Vue.js JavaScript・TypeScript React Dart Flutter プログラミング言語 学習コスト フロントエンド経験者 〇 〇 △ バックエンド経験者 △ △ ◯ ライフサイクル 学習コスト フロントエンド経験者 〇 〇 △ バックエンド経験者 △ △ △
21. 開発環境 学習コスト 機能実装 21
22. 機能実装の比較 • ネイティブ機能を実装できるか ◦ 実装したサンプルアプリの機能 ローカルデータベース・セキュアストレージ・NFC・カメラ・ Push通知・WebView 22
23. ネイティブ機能実装結果 • Ionic FrameworkとReact Nativeで実現できなかった機能がある ◦ 特にIonic FrameworkはWebViewを実装できない • Flutterは機能実装では欠点が見つからなかった 23 Ionic Framework React Native Flutter ローカルデータベース 〇 〇 〇 セキュアストレージ 〇 〇 〇 NFC △ △ 〇 カメラ 〇 〇 〇 Push通知 〇 〇 〇 WebView ✕ 〇 〇
24. 実現できなかった機能（NFC） • 事象 ◦ Ionic FrameworkとReact Nativeで、iOSでType-FのICカードを読み込めない • 原因 ◦ ライブラリがNDEFフォーマット以外のフォーマットに対応していない ◦ SuicaやIcocaなどのFelica Standerdのフォーマットに対応したライブラリを 見つけることができなかった • 対策 ◦ ライブラリを自作 or ネイティブ言語で実装 ◦ ライブラリの対応を待つ 24
25. 実現できなかった機能（WebView） • Ionic FrameworkではWebViewを実装できない • WebView上で動作しているため、別のWebViewを起動することができない • Ionic Framewrok上で内蔵ブラウザを表示するできるが、機能が限られる 25 Android OS iOS WebView Ionic Framework 開発者 実装できる範囲 WebView WebView
26. 結論② まずはFlutterの導入を検討すべき 26
27. Flutterの導入を検討すべき • 特に目立った欠点がなく、汎用性が高く、省力化が期待できる • 質の高いライブラリが提供されている 27 Ionic Framework React Native Flutter 開発環境 ✕ △ 〇 学習コスト フロントエンド経験者 〇 〇 △ バックエンド経験者 △ △ 〇 機能実現 ✕ △ 〇 ライブラリ数 5656 812 12613 サンプルアプリで使用したライブラリ数 25 29 11 ライブラリ評価機構 ✕ △ 〇
28. ライブラリ評価機構 • ネイティブ機能の実装はライブラリに大きく依存する ◦ ライブラリの質や選定・運用コスト • ライブラリを評価する仕組みを比較 ◦ Ionic Framework：×　提供されていない ◦ React Native：△　品質よりも人気度で評価 ◦ Flutter：◯　品質を評価している 28
29. ライブラリ評価機構：Ionic Framework • ライブラリを評価する仕組みがない • 公式・コミュニティのライブラリはドキュメントに一覧管理 • 評価できるとすれば ◦ GitHubダウンロード数 ◦ 更新頻度 ◦ ドキュメント ◦ 公式 or コミュニティ製 29
30. ライブラリ評価機構：React Native • React Native Directoryで一覧管理 • Directory Scoreで評価されている • 評価項目 ◦ GitHubリポジトリの評価 ▪ fork ▪ star ▪ download ▪ issue ◦ 最終更新日 • 品質よりも人気度 30
31. ライブラリ評価機構：Flutter • pub.devで一覧管理 • pub pointsで評価されている • 評価指標 ◦ ライブラリ情報の公開 ▪ 依存関係の明記、CHANGELOGファイル、LICENSEファイル、READMEファイル ◦ ドキュメントを提供しているか ▪ publicなAPIのリファレンスの網羅率、Sampleコード ◦ Dartコードの静的解析結果 ◦ DartとFlutterの最新StableのSDKで動作するか • ライブラリの品質を評価している項目が多い 31
32. Ionic Frameworkの所感 • 長所 ◦ 開発速度が速い ▪ Web標準技術やReact, Vueを使用できる ◦ UIの自由度が高い ▪ ブラウザエンジンで描画されるので、 HTML, CSS, JavaScriptで画面を構築できる ◦ PWAにも対応している ▪ 同じコードをPWAとしてデプロイできる • 短所 ◦ ライブラリの評価機構がない ▪ ドキュメントが不足していて、実装を確認する必要があった ◦ ネイティブ機能の利用が増えるとパフォーマンスが悪くなる ▪ ネイティブ機能はJavaScriptEngineがBridge、負荷がかかりパフォーマンスが遅くなる ◦ WebViewを実装できない ▪ アプリ起動時にWebViewを起動しそ別のWebViewを実装できない 32
33. React Nativeの所感 • 長所 ◦ 各OSに準拠したネイティブ UIを利用できる ▪ JSXのタグをBridgeして、各OSのネイティブUIを表示できる ◦ Reactの知識を活かせる ▪ Reactで実装したWebのコードを移植・Reactのエコシステムを利用できる • 短所 ◦ 常にBridgeを行っているのでパフォーマンスは遅い ▪ 頻繁にネイティブ機能にアクセス、大量データの表示などで悪化する可能性 ◦ アーキテクチャ変更が予定されており破壊的な変更があるかもしれない ▪ Bridgeへの不安を解消するため ▪ メジャーバージョンが 0であり、仕様も安定しきっていない ▪ Bridgeを廃止した段階でバージョンが 1.0に上がるのでは 33
34. Flutterの所感 • 長所 ◦ 開発環境が整っている ▪ Android Studioを使用できる、Flutter DevToolsが優秀 ◦ ライブラリの質が高い ▪ pub pointsの高いライブラリはリファレンスが充実しており、実装・選定しやすい ◦ 全体的にパフォーマンスが良好 ▪ Dart VMがUI描画や、ネイティブ機能を実行するので Bridgeする機会が少ない • 短所 ◦ アーキテクチャの議論が活発 ▪ 様々な手法が存在し選定やキャッチアップが必要 ◦ Dartの学習コスト ▪ 他のフレームワークに比べ、既存の技術を流用できない ◦ 両OSで同じUIデザインで表示される ▪ 各OSに準拠したUIデザインで表示したい場合は実装コストが上がる 34
35. クロスプラットフォームへの懸念点 • 長期的な運用への不安 ◦ 事例が少なく、できるともできないとも言えない状態 ◦ 開発体制やエコシステム・ライブラリの充実度 • 各OSの新機能対応の遅れ ◦ 最新機能は四半期〜半年遅れて対応される可能性が高い • ネイティブ言語で実装する必要も ◦ 対応できていない機能やバグ修正 ◦ モバイル開発の知識も必要 35
36. 技術選定の事例 36
37. 研究成果の応用事例 • 事例 ◦ あるサービスで新規でiOSアプリの開発要件 ▪ Push通知・WebViewでWebサービスを表示したい ◦ アプリエンジニア不在のため外注を視野に検討 • 研究結果の活用 ◦ クラスプラットフォームツール（Flutter）での内製化を提案 ▪ Push通知・WebView・WebサービスはOOP言語で実装 ◦ 開発環境・学習コスト・導入事例などからFlutterでの開発に決定 37
38. まとめ • クロスプラットフォームツールは開発を省力化できる ◦ 開発環境・学習コスト・ネイティブ機能実装の検証結果から ◦ ツールによっては実装できない機能があるので把握すること • ツールの選定は、まずはFlutterを検討 ◦ 欠点が少なく、ライブラリの品質も高い • 各ツールの特徴から開発のユースケースに合わせた選定を行う 38