特定の要件を満たしたり、使いやすさを向上させたりするために、システムの起動時間を短縮する方法を知っておくことは多くの場合、有益です。
注: これはRaspberry Piの最短動時間を示すものではなく、最適化調整の入門記事です。
この記事では、ユーザー空間での最適化のみを対象としています。他の(カーネル空間など)の最適化の方が良い結果をもたらす可能性もありますが、アプリケーション開発者の視点から最も利用しやすい方法であると思われます。
Raspberry Pi 4は、初期起動段階の最適化に関しては制限がありますのでご注意ください。
環境
- Raspberry Pi 4B
- Boot to Qt (あるいは同様のユーザー空間のイメージ)
- HDMIディスプレイ
- ターゲットイメージ用にビルドされたアプリケーション
この最適化により、全体の起動時間を約13%短縮することができました。
イメージとツールチェーンの入手
このシナリオでは、Boot to Qt イメージが使用されますが、この手順は特定のイメージに限定されるものではありません。Boot to Qt イメージとツールチェーンは、Qtメンテナンスツールで入手できます。
まずRaspberry Piにイメージをフラッシュし、電源を入れます。RaspberryがデフォルトのBoot to Qtアプリケーションで起動したら、次の手順に進みます。
任意：Boot to Qt をビルドします
Boot to Qtのビルドに関する一般的な手順は、ここで取り上げられています。
Boot to Qt ディストリビューションをビルドする際、WebEngine を使用しない場合は、b2qt.conf ファイルから webengine の DISTRO_FEATURES を削除してください。これにより、時間とリソースを節約できます。
注:さらなる最適化(例えば静的ビルド)を目指す場合は、最終的にはご自身でBoot to Qtをビルドする必要があります。
ユーザー空間最適化
初期状態
ユーザー空間で最初に起動されるプロセスは /sbin/init です。デフォルトのイメージを使用している場合、これは systemdの起動スクリプトのシンボリックリンクです。systemd-analyze ツールを起動後に適用すると、デフォルトで多くの不要なサービスが起動していることがわかります。
以下は
systemd-analyze plot > /tmp/systemd-boot.svg
を実行した調査結果の一部です。
不要なサービスを一つずつ削除する代わりに、初期化に systemd を使用しないようにします。この最適化後は、systemd のランレベル、サービス、その他の機能は利用できなくなりますのでご注意ください。代わりに、systemd とは独立した init スクリプトを使用します。
この時点では、アプリケーションの依存関係を把握しておくことをお勧めします。理想的にすぐ利用できるアプリケーションが存在しますが、そうでない場合は、initスクリプトを修正することで、後から依存関係を追加することができます。
ステップ 1
新しいスクリプトを作成し、シンボリックリンクのターゲットをそのスクリプトに変更します。スクリプトが実行可能であることを確認してください。
ステップ 2
QT_QPA_EGLFS_KMS_CONFIG 経由でアプリケーションが後で使用する新しい /opt/kms.config ファイルを作成します。次のような内容になります。
{ "device": "/dev/dri/card1", "hwcursor": false, "pbuffers": true, "outputs": [ { "name": "VGA1", "mode": "off" }, { "name": "HDMI1", "mode": "1024x600" } ]}ステップ 3
アプリケーションを最小限のブートで起動するための /sbin/new_init.sh スクリプトは、以下のような内容です。
#!/bin/shmount -t sysfs none /sysmount -t proc none /procmount -t tmpfs none /tmpmount -o remount,rw /#graphics setupmodprobe -a vc_sm_cma gpu_sched videodev v3d i2c_brcmstbexport QT_QPA_EGLFS_KMS_CONFIG=/opt/kms.config./opt/app
このスクリプトの処理内容
- カーネルデータに必要な sysfs をマウント
- ハードウェアおよびプロセス管理に使用されるprocのマウント
- 一時的なセッションデータに必要な tmpfs をマウント
- ルートディレクトリへの書き込みアクセス権を取得するためにルートを再マウント
- Raspberry Pi 4のグラフィックに必要なカーネルモジュールをロード
- kms.configファイル用の環境変数を設定
- アプリケーションを起動
注:アプリケーションによっては、さらにカーネルモジュールをロードする必要があります。
Thank you guys for your efforts!
I think I'll wait for the Beta to test...
I'll keep my fingers crossed for beta!
I've begun working on a "windeployqt" tool too.
You can see the beginnings here:
http://git.hohndel.org/?p=s...
http://git.hohndel.org/?p=s...
Do you think it would be useful to move to qttools?
@Thiago, please check the qttools in stable where we are working on windeployqt, with slightly different approach, but working for Win, WinRT and WinPhone. You can also check with fkleint about details.
At least the first patch seems to be clearly a mingw only solution.
Sounds like a suitably clean separation... it wasn't clear which files needed to be under version control in android projects for 5.1 and so I added them all. I'll wait for the binary betas before giving it a go though.
Is it possible to add some java code to generated files for some specific behavior ?
The preferred way to add Java code is to add your own Java files and subclass the generated files to override its behavior.
If you want, it's also possible to put a modified QtActivity.java for instance in your Android package source, and this will then overwrite the generated QtActivity.java. This will however mean that you need to make sure it's properly updated if you upgrade to a new Qt version.
I tried one of the 5.2.0-beta1 snapshots, working great so far, I like the simplicity of the whole process, great, great work! The only thing I am missing is a QtWidgets-free version of QtQuickControls (which is probably the most common use case for Android deplyment) in order to reduce the package size. I can of course compile it myself but that would be useful for many users to have it in the binary package.
I agree. We'll look into removing the widgets-dependency by default in Qt 5.2.
What about apk file sizes with all its Qt stuff bundled? Are they compeititive or still needs some wo rk?
A default "Hello World" APK in Qt Quick 2 which includes the necessary Qt libraries, plugins and imports will be around 9 MB.
Not too bad I guess :)
This is really great news. Good job, Qt team!
Is there a possibility like in the old android support to only get the libaries needed into the package? Currently it seems to copy all in with a lot of stuff not needed
Currently, the auto-detection will be greedy, including all relevant plugins and imports and their dependencies, since we don't have any way to know currently which ones will be used at run-time. The overhead of this is pretty minimal compared to the overhead of the required libraries.
For QML imports, we'll improve this to be smarter, thus only including the ones that are actually used. Work for this is in progress.
It's also possible to completely override the auto-detection manually to specify precisely which libraries, plugins and files should be included. I'd expect this to be an appropriate extra step right before going into production with an app. See the documentation for details on this.
Hi
This "separation" mean it will be some possibility in the future to develop for android (compiling, packaging and deploy) using Visual Studio 2013 through plugin instead to use Qt Creator?
Thank you
This is a great improvement particularly in for working with several kits and several CPUs like ARM and Intel (coming at some new Samsung tablets).
Just to remind you that child window bugs related
to sizes and positioning of dialogs, etc. child windows are actually show-stoppers for porting QWidgets - based applications. There are about 10 such issues filed in JIRA whereas it could be that there are only 2-3 real issues behind these 10 reports.
Thank you in advance!
This is great news, I've been wanting a cleaner separation for some time. Good job!
First of all I really like where Qt is heading now, Qt Quick 2 with opengl and scenegraph is pretty awesome, but... a lot of Qt features really look like a technology preview rather than final product. It is nice to have new features but it would be better to have existing features refined. Now it looks like KDE4 when it became usable with version 4.5+ but in the meantime I've switched to gnome...