Vite2+Capacitor2でWEB&モバイル開発環境構築
1つのソースコードで、WEB・モバイル端末・デスクトップ向けのアプリを開発するプラットフォームは、「ReactNative」「Flutter」「Xamarin」「Uno Platform」「Unity」などが有名で、それぞれ特徴を持っています。
当記事では、Vueの開発におけるホットリロードを高速化する「Vite」をベースにプロジェクトを作り、「Capacitor」を追加した環境を作ります。
その環境を使い、1つのVueコードでWEB・Androidアプリのプロダクトビルドを実行するまでをお伝えします。(iOSアプリの生成も可能なようです)
デバッグや動作確認は、Viteのプロジェクト生成時のサンプルを使っています。
- なぜ「Vite+Capacitor」か
- 開発のライフサイクル概要
- 動作確認した環境
- 「Vite」の開発環境を構築
- WEBのデバッグ
- WEBのプロダクトビルド
- Andorid Studioのインストール
- Capacitorの追加
- Andoridでの動作確認
- Andoridのプロダクトビルド
- まとめ
なぜ「Vite+Capacitor」か
やはりVueによるWEB開発に慣れたチームがモバイルアプリも生成するには最適です。
WEBとモバイルアプリの共通機能のデバッグにおいて、「Vite」の高速なホットリロードの恩恵を十分受けられます。
例えば「Flutter」でもホットリロード機能がありますが、「Vite」の方がブラウザへの反映が体感でも速いと思います。
また、Vueの様々なエコシステムをモバイルアプリに適用できる可能性もあります。
例えば、以下でも記載しますが、JavaScriptによるCSSフレームワークである「Tailwind CSS」や、http通信フレームワークの定番「axios」は、一部の機能しか確かめていませんが、Androidアプリでも全く同じように機能が適用されることを確認しました。
ただ、今は動作しても、今後プロジェクトで採用するVueやJavaScriptのフレームワーク・ライブラリが動くか、またそれらがバージョンアップしたときにも、あるいはAndroidやiOSがバージョンアップしたときにも、きちんと動作することを「Capacitor」が担保できるかが心配ではあります。
長期保守を検討する場合は、「Capacitor」の企業向けサイトの情報が参考になるかもしれません。
ところで、プロジェクト生成時のサンプルソースをほぼそのまま、プロダクト版でビルドしたファイルサイズは、WEBもAndroid(apk)も「Vite2+Capacitor2」のほうが「Flutter2」より小さいようでした。(下表参照)
Vite2+Capacitor2 | Flutter2 | |
---|---|---|
WEB | 64KB | 3.1MB |
Android(apk) | 1.6MB | 15.3MB |
※WEBはMAPファイルは含めていません。
サンプルは完全に同一ではありませんが、双方ともタイトルの表示と+ボタンで1ずつ加算結果を表示するだけのアプリです。それだけの機能でしかないのに、結構差が大きい気がします。
ですが、モバイル機能中心の開発・デバッグは、Flutterなど他のプラットフォームのほうがよいかもしれません。 特にモバイルアプリはCapacitorの仕様によりWebViewで動作しますので、FlutterやReactNativeなど、ネイティブ寄りのプラットフォームのほうが機能によっては高速に動作するかもしれません。(ただ、Capacitorのホワイトペーパーでは、「WebViewがモバイルで遅いと考えるのはもう古いよ」と言ってます)
開発のライフサイクル概要
最初にyarnでviteベースの初期プロジェクトフォルダを生成し、WEBとモバイルで共通の機能をVueの開発手法に従ってコーディングしていきます。
エディタやIDEはVisual Studio Codeなど、何でもかまいません。デバッグはViteで用意されたサーバをコマンドラインから起動し、WEBブラウザやIDEで確認しながら行います。
Visual Studio Codeですと、「Debugger for Firefox」というプラグインを追加し、<プロジェクトルート>/.vscode/launch.json
に設定を加えると、デバッガでブレークポイントの設置・ステップ実行・変数値の確認ができるようになります。
WEBのプロダクトビルドファイルは、Viteのコマンドを実行して生成します。
一方、モバイル特有の機能(カメラやGPSなど)の動作確認や、モバイルのプロダクトビルドは、Andorid StudioやXCodeから行います。(当記事では、iOSアプリ向けのXCodeによるデバッグやビルドは割愛しています)
Capacitorの機能で、WEBのプロダクトビルドファイルをベースに、AndroidやiOS用のプロジェクト上にWebViewコードが生成されるようになっています。
つまり、基本的に毎回WEBのプロダクトビルドを行ってから、シミュレータや実機で動作確認、Andorid StudioやXCodeでビルドという手順を踏みます。他のマルチプラットフォーム開発環境と比べると、この手順が煩わしいと感じます。
さらに、Andorid StudioやXCodeでブレークポイントの設置、ステップ実行でモバイル機能のデバッグができないのも難点と思います。
一方、例えばFlutterであればWEB向けモバイル向け関係なく、同じ方法でブレイクポイント設置、ステップ実行、変数値の確認ができますし、ビルドもflutter build web
flutter build apk
flutter build ipa
などとコマンドを実行するだけでよく、開発環境として洗練されているように思いました。
なお、モバイル特有の機能のコーディングは、Viteプロジェクト内のVueの中で、JavaScriptまたはTypeScriptで記述します。
このとき、import { Plugins, CameraResultType } from '@capacitor/core'
などとして、Capacitorより必要機能をインポートします。
動作確認した環境
ソフト | バージョン | 説明 |
---|---|---|
Linux Mint | 20.1 | Ubuntuベースのディストリビューション |
Node.js | 14.16.0 | JavaScript実行環境 |
NPM | 6.14.11 | JavaScriptパッケージ管理 |
Yarn | 1.22.10 | NPM互換のJavaScriptパッケージ管理システム |
Vite | 2.1.0 | 高速なVueベースのWEBデバッグ・ビルド環境 |
Vue | 3.0.5 | WEB開発フレームワーク |
TypeScript | 4.1.3 | 静的型付け・オブジェクト指向のWEB開発言語 |
Capacitor | 2.4.7 | WEBビルドファイルのモバイル開発環境への橋渡しツール |
Android Studio | 4.1.2 | Androidデバッグ・ビルド環境 |
「Vite」の開発環境を構築
Node.js・NPM インストール
sudo apt install nodejs npm
NPM を最新版に
sudo npm install -g npm
n インストール
sudo npm install -g n
n を使って NodeJS を最新安定版に
sudo n stable
旧バージョンのNodeJS・NPM を削除
sudo apt purge nodejs npm
ログインシェル起動
exec $SHELL -l
バージョン確認
node -v
npm -v
Yarn インストール
sudo npm install -g yarn
Yarn バージョン確認
yarn -v
※最新バージョンのYarn2系では、「Vite」のコマンドは実行可能でしたが、「Capacitor」のコマンドはエラーで実行できませんでした。
Viteプロジェクト生成
ここでは「test_vite」というプロジェクトをホームフォルダの「develop」フォルダに生成する例とします。
cd $HOME/develop
yarn create @vitejs/app test_vite
コマンドを実行すると「? Select a template: … 」とメッセージが表示されます。 TypeScriptを使うとして「vue-ts」を選択してEnterキーを押下します。 すると、「develop」フォルダ配下に「test_vite」フォルダが生成され、その配下に以下のファイル群が生成されます。
├── README.md ├── index.html ├── package.json ├── public │ └── favicon.ico ├── src │ ├── App.vue │ ├── assets │ │ └── logo.png │ ├── components │ │ └── HelloWorld.vue │ ├── main.ts │ └── shims-vue.d.ts ├── tsconfig.json └── vite.config.ts
これでプロジェクトフォルダの生成は完了です。 Visual Studio Codeなどで、当フォルダをプロジェクトルートに設定するとよいと思います。
WEBのデバッグ
NPMによるモジュールのインストール
cd $HOME/develop/test_vite
yarn
プロジェクトフォルダへ移動し、「yarn」コマンドを実行します。
「package.json」を参照し、Node.jsで管理されたJavaScirptのライブラリがインターネットよりダウンロードされてきます。
デバッグサーバの起動
yarn dev
プロジェクトフォルダにて、「yarn dev」コマンドを実行します。
サンプルアプリが読み込まれ、以下のようなメッセージが表示されて、デバッグサーバが起動します。
vite v2.1.2 dev server running at: > Local: http://localhost:3000/ > Network: http://192.168.11.143:3000/
WEBブラウザで「http://localhost:3000」にアクセスすると、下図のようなサンプルアプリの画面が表示されます。
「count is: 0」のボタンをクリックすると、1ずつ増えていきます。
プログラムの修正
デバッグサーバは起動したまま、WEBブラウザを開いたままの状態でソースコードを修正すると、一瞬でWEBブラウザに反映されます。
デザインや動作をまめにチェックしながら、開発を進めることができます。
カメラやGPSなど、モバイル特有の機能の動作は、ここでは確認できません。後述しますが、Capacitorをプロジェクトに追加後、Andoroid Studioなどから起動するエミュレータなどで動作確認します。
モバイルアプリと共通の機能は粗方ここで確認してもよいかと思いますが、厳密なテストはエミュレータや実機で実施したほうがよいでしょう。
デバッグサーバを終了するときは、プロンプトでCtrl+Cキーを押下します。
WEBのプロダクトビルド
cd $HOME/develop/test_vite
yarn build
プロジェクトフォルダへ移動し、「yarn build」コマンドを実行します。
すると、プロジェクトフォルダに「dist」というフォルダが生成されます。そのファイル群を本番環境のWEBサーバにデプロイします。
「dist」フォルダ内は以下の構造になっており、これらファイルサイズの合計が上記表の「Vite2+Capacitor2」に記載した64KBになっていました。
dist ├── assets │ ├── index.e108508f.css │ ├── index.e30e4e65.js │ ├── logo.03d6d6da.png │ └── vendor.6801b2a0.js ├── favicon.ico └── index.html
Andorid Studioのインストール
Androidアプリのデバッグ・ビルド環境であるAndorid Studioをインストールします。
Linux Mintの「ソフトウェアマネージャ」よりAndorid Studioを検索すると、執筆時点での最新版(4.1.2)をインストールできました。
Capacitorの追加
NPMによるモジュールのインストール
ViteプロジェクトにNPMを利用してCapacitorを追加します。
cd $HOME/develop/test_vite
yarn add @capacitor/core @capacitor/cli
なお、yarn add @capacitor/cli@next @capacitor/core@next
とすると、最新ベータ版が追加されます。執筆時点ではバージョン「3.0.0-rc.0」が追加され、以後のコマンドも一応すべて問題なく実行できました。
Capacitorプロジェクトの初期化
次に以下のコマンドを実行し、初期化します。
npx cap init
質問のプロンプトが表示されますので、入力します。
- Name:test_vite(プロジェクト名)
- Package ID:com.test(モバイルアプリのパッケージID)
- Web asset directory:dist(WEBのプロダクトビルドファイルを読み込むパス(
yarn build
出力先))
もし入力を誤った場合は、実行後にプロジェクトルートに生成されたcapacitor.config.ts
を削除し、再度npx cap init
を実行すればやり直せます。
さらに以下のコマンドを実行し、Android・iOS用のモジュールを追加します。
npx cap add android
npx cap add ios
最新ベータ版は、yarn add @capacitor/ios@next @capacitor/android@next
で追加できます。
Android Studio の起動ファイルのパスを追加
以降のAndroidのデバッグ時のcapacitorのコマンドを実行した際、自動でAndroid Studioを起動させるため、環境変数CAPACITOR_ANDROID_STUDIO_PATH
にAndroid Studio の起動ファイルのパスを設定します。
「Andorid Studioのインストール」の手順を実施していた場合、実行ファイルのパスは以下になります。
/var/lib/flatpak/app/com.google.AndroidStudio/current/active/files/extra/android-studio/bin/studio.sh
これを環境変数に追加するため、以下のコマンドを実行するとよいでしょう。
echo "export CAPACITOR_ANDROID_STUDIO_PATH=\"/var/lib/flatpak/app/com.google.AndroidStudio/current/active/files/extra/android-studio/bin/studio.sh\"" >> $HOME/.profile
ZIPの解凍など、他の手順でAndroid Studioをインストールした場合でも、studio.sh
ファイルのパスをCAPACITOR_ANDROID_STUDIO_PATH
に設定しておけばよいと思います。
これで最低限のモバイルアプリのデバッグ・ビルド環境ができました。ここまでは環境構築なので1度行うだけで大丈夫です。
Andoridでの動作確認
WEBのプロダクトビルド
Andoridアプリでの動作を確認する際、まず最初にWEBのプロダクトビルドを実行します。
上記でお伝えしたように、プロジェクトルートフォルダへ移動し、yarn build
コマンドを実行して「build」フォルダにプロダクトビルドファイルを生成します。
なお、デバッグ前に当然コーディングをするわけですが、基本的にはカメラやGPSなど、WEBでは使えないモバイル端末専用の機能のデバッグが主になるでしょう。
具体的なコーディング方法はCapacitorの公式サイトや紹介サイトをご覧ください。ご参考までに、公式サイトからカメラ機能について以下のとおり引用します。
import { Plugins, CameraResultType } from '@capacitor/core'; const { Camera } = Plugins; async takePicture() { const image = await Camera.getPhoto({ quality: 90, allowEditing: true, resultType: CameraResultType.Uri }); var imageUrl = image.webPath; imageElement.src = imageUrl;
上記のとおり、TypeScriptやJavaScriptで@capacitor/core
より必要機能をインポートします。
Androidプロジェクトへコピー
以下のCapacitorのコマンドを実行することで、WEBのプロダクトビルドファイルをベースにAndroidプロジェクトへコピー&変換されます。
npx cap sync
Android Studioを起動
以下のCapacitorのコマンドを実行することで、コピー&変換されたAndroidプロジェクトがAndroid Studioにて開かれます。
npx cap open android
Android Studioで動作確認
あとは、Android Studioの標準機能に従ってデバッグビルドを行い、エミュレータや実機で動作を確認します。
メニュー「Run」→「Run」を選択するとエミュレータが起動し、動作確認ができます。
「count is: 0」のボタンをクリックすると、1ずつ増えていきます。
ここで、Android Studioで「Debug...」を選択してエミュレータを起動しても、ソースがブレークポイントを置けるものではないので、意味がありません。ただ重いエミュレータがさらに重くなるだけです。ステップ実行や変数値チェックができないのはつらいところ....
また、Flutterのようにホットリロード機能がありません。
Vue系のファイル修正の都度、エミュレータを停止 → yarn build
→ npx cap sync
→ Android Studioで「Run」でエミュレータを起動...の流れに、手間・時間がかかりそうです。エミュレータの起動でも30秒、停止で10秒ほどかかりますし....
これが、モバイル専用機能が多い場合にお勧めしづらい点です。WEBと完全に同一の機能をモバイルアプリでも提供するか、極簡単なカメラやGPSなどの機能を付けるだけのアプリなら問題ないかもしれません。
Andoridのプロダクトビルド
Android Stuidoの標準機能でプロダクトビルド、.apkファイルの生成を行います。
Vueで修正 → yarn build
→ npx cap sync
までは前項の動作確認手順と同じです。
通常のAndoridアプリ開発同様、Android SDK(SDK Platforms)のバージョンに注意を払う必要がありますが、CapacitorのバージョンとAndroid SDKのバージョンがリンクしているようです。つまり、Capacitor2.4.7だとAndroid10.0が、最新ベータ版のCapacitor3.0.0-rc.0だとAndroid11.0が動作可能なバージョンのようです。
プロダクトビルドですが、基本的にはAndroid Studioで最初にアプリの署名の設定をした上でビルドします。
メニュー「Build」→「Generate Signed Bundle / APK」を選択します。
次に「APK」を選択し、「Next」ボタンをクリックします。
一度も署名キーファイルを作成したことがなければ、ここで「Create new...」を選択します。
署名に必要な情報を入力し、「OK」ボタンをクリックします。「Key store」の「Password」や「Key」の「Password」は、この次の画面ですぐ利用しますので、記憶しておいてください。
「Key store path:」に入力情報が保存されます。次回ビルド時より同じ入力をしなくて済みますので、保管しておきましょう。
前画面で入力した「Key store」の「Password」や「Key」の「Password」を入力し、「Next」をクリックします。
「Destination Folder:」にはビルドファイルの保存先を指定します。初期値のままでよければ、覚えておいてください。「Build Variants:」は「release」を、「Signature Versions:」にはアプリに応じて選択し、「Finish」をクリックします。
そうしますとGradleが実行され、サンプルアプリであれば20秒ほどでビルドファイルが「Destination Folder:」に生成されます。
この「app-release.apk」ファイルをUSBケーブルやWi-FiなどでAndroid端末へコピーし、起動すれば、インストールできるようになります。Playストアへの公開対象にもなります。
2回目以降であれば、上記は初期値として入力済みの状態となり、手間が少なくビルドできると思います。
WEBやエミュレータ同様、「count is: 0」のボタンをクリックすると、1ずつ増えていきます。
まとめ
長い手順になりましたが、繰り返し操作していると慣れてきて、早く開発できるようになると思います。
記事中Flutterと比較しましたが、どちらも一長一短、向き不向きがあるので注意です。
クロスプラットフォームの開発環境を検討されている方向けに、参考になれば幸いです。
FIRフィルタを固定小数点化してみる
「FIRのフレーム処理」 では、FIRフィルタのフレーム化(実装)を紹介しましたが、今回は組み込み向けの話しをしたいと思います。
信号処理の組み込みと言えば、まずはDSP*1を思いつきますが、 RISC CPUによるSIMD*2やVLIW*3のように、並列処理により信号処理が高速に行われる時代になりました。
そしてDSPにも高速なFPU*4を持ったものや、SIMDやVILWが使われる時代で、ハイスペックなDSPが登場し再度注目を集めていると思います。
- 固定小数点DSP
- 組み込み向けのリファレンスコード(デジタル信号処理向けのリファレンスコード)
- basic_op (固定小数点DSP向けの命令関数)
- FIRフィルタの固定小数点化
- サンプルコード【C言語】
思考のサルベージ(その14)
各工程で心がけたい思想を掘り起こしてみる
処理性能を求められるシステムでは、CPUを最大限有効に稼働させなければなりません。「空いた時間の上手な使い方」について考えてみます。
HWサポート
複数個のデータを元に複雑な演算をする必要があるとします。ソフトウェアによる演算では処理時間がかかりすぎてしまうので、この演算専用のハードウェア.Aを搭載してもいました。仕様はざっくり次のような感じです。
- データ設定レジスタにデータを設定する
- 起動レジスタに1を書き込むことで演算を開始する
- 演算が終了すると終了レジスタに1が書き込まれる。
- 終了レジスタに1を書き込むと同時に、結果レジスタに演算結果が書き込まれる。
この手のHW.Aにアクセスするドライバとしては以下のようなものも考えられます。
- 1.データ設定からHW起動までを行うstart関数
- 2.演算終了レジスタをポーリングし、演算が終了したら演算結果を返すwait関数
- 3.1と2をパッキングした、startend関数
3のstartendようなドライバであれば、HW.Aを使うSWでは、ドライバ一つ呼ぶだけで演算結果を使って次の処理に進むことができます。単純明快な処理となるので、bugを埋め込むリスクも小さくなります。
空き時間
SWによる演算より速いとはいえ、HW.Aの演算にも時間はかかります。そこで、演算結果を取得した後に続く処理に目をつけてみます。当然、演算結果が無ければ実行できない処理があります。しかし、HW.Aから取得できる演算結果の他に、後続処理で必要なデータがあるならば、HW.Aの演算終了を待つ間に他のデータの収集する処理を行っておけます。
[ startend ]→[他のデータ収集]→[後続処理]
[start]→[他のデータ収集]→[wait]→[後続処理]
[他のデータ収集]がHW.Aの演算時間に収まればその分の処理時間を削減することができます。
できることできないこと
上記では単純化なモデルケースで説明しています。実際にシステムで稼働するSWはもっと複雑な実装になっているでしょうが、同様のやり方で、HWの処理時間の裏で他の処理を実行させることは可能でしょう。 ただし、注意も必要です。例えばHW.A起動中の裏で実行したい処理が別のHWを用いるような処理であれば、HW同士の同時起動に制約がないか確認する必要があります。同時起動自体は可能でもHW同士が同一メモリにアクセスするようなケースではbus接続の影響でアクセス競合が起こる可能性もあります。こうなるとHWを用いても性能を引き出せないといったことになってしまいます。こうなっては折角のHWサポートも電力を使うだけで、なんの効果も生んでくれません。
何か掘り起こせた?
空き時間を有効に使うには、HWの仕様・特性をきっちり把握する必要があります。
- 使用するHW、アクセスするメモリ等を考慮する必要があり
- 設計段階でやれることやれないことを整理しておく。
おしまい
HWサポートを一つ搭載するにもそれだけのコストをかけるということ。本当にそのサポートが必要かも含め、どうすれば性能を引き出せるかをきっちりと検討したいですね。
Fedora34でデフォルトIMEがAnthyになるですって!?? 〜OSSかな漢字変換再考〜
え、Anthy・・・!?!?
昨年末、LinuxディストリビューションのFedora界隈でこんなディスカッションなるものがあったそうです。。。
中身はタイトルのとおりなのですが、、、
Fedora次期バージョン(=Fedora34)からデフォルトIMEがIBus-Anthyになる!!
とのこと。
趣味でかな漢字変換を自作している著者としては、「何事!?」と思われるお話だったのですが、よく考えると「あ〜なるほど」とある程度は納得のできるお話でした。(注:全てに納得したわけではありませんが
というわけで今回は、OSSのかな漢字変換について振り返りをしてみようと思います。
本日、話題となるかな漢字変換はこちら。
- Anthy
- Mozc
- libkkc
それでは、行ってみます!
続きを読む