| Re: android版で最小化した場合の動作 ( No.1 ) |
- 名前：管理人 日時：2017/06/30 00:18
確かに復帰に必要なメモリが足りなかったりすると復帰できずアプリが落ちてしまうかもしれません
よろしければお試しの Android端末の名称や型番、Android のバージョンなどを教えていただけないでしょうか？
あと、ＤＸライブラリ Android版は比較的頻繁に更新していますので、よろしければこちらの暫定の最新版を
お試しになってみてください、もしかしたら症状が改善されるかもしれません m(_ _;m
https://dxlib.xsrv.jp/temp/DxLibAndroidTest_ARM.exe // Android版 ARM用
|
| Re: android版で最小化した場合の動作 ( No.2 ) |
- 名前：初心者 日時：2017/07/12 11:49
おそばせながら、確認してまいりました
arp as01Mという、まあ典型的なロースペック機で、OSのバージョンは5.1です
しかしこの機種の場合、CPUまわりのスペックはスペック相応に低いものの、
なぜかメモリだけは妙に多く積んでいる機種ですので
もしかしたらメモリ不足ではない別の要因があるのか、
あるいはメモリは足りていてもそこから戻すためのCPUが足りないのかなどと思ったりしました
使用する画像を縮小したりすることでほんの少し改善されはしたのですが、
結局開発が進んで画像が増えたりするとまた同様の症状が起きているので、
メモリ関係の可能性が大きそうではありますが・・・
|
| Re: android版で最小化した場合の動作 ( No.3 ) |
- 名前：管理人 日時：2017/07/13 01:31
ご返答ありがとうございます
確かにメモリは沢山( 3GB )積んでいますね…
ただ、私が現在使用している F-02H という端末も 3GB 積んでいるのですが、
少し起動しておくアプリを増やしてアクティブなアプリの切り替えを行うと
切り替えた先のアプリが終了していてアプリの起動画面からやり直しということが
発生することもあるので、現在では 3GB はそこまで大きな容量とは言えないのかもしれません
> 使用する画像を縮小したりすることでほんの少し改善されはしたのですが、
> 結局開発が進んで画像が増えたりするとまた同様の症状が起きているので、
> メモリ関係の可能性が大きそうではありますが・・・
実機で試してみないとわかりませんが、画像を小さくすると改善され、画像が増えると悪化するとなりますと、
やはりメモリ関係の可能性は高いように思います
メモリ容量が大きい代わりに標準でインストールされている常駐アプリが沢山メモリを占有しているということはないでしょうか？
|
| Re: android版で最小化した場合の動作 ( No.4 ) |
- 名前：初心者 日時：2017/07/13 10:40
先ほど試していたas01Mから、
少なくともそれよりはマシであろうFire HD8で動かしてみたところ、
やはり最小化さえしなければ問題なく最後まで動作する、
だけど最小化してしまうと(というか起動しているタスク表示画面に移行したりするだけでも)
そのままホーム画面まで戻ってしまうようでした
ですがホーム画面に戻ってもタスクそのものは残っており(その表示画面では最小化した時の画面が表示されています)
それを実行するとまた1から始まるようになってしまいます
似たような構成で作って、かつその強制終了が発生しないアプリと
同じように動作させてログを確認したところ、
ちゃんと動作するほうのアプリでは
「シェーダーコード関係の初期化、成功」
「グラフィックを復帰します」
「グラフィックの復帰が完了しました」と流れるところが
動作停止するほうのアプリでは
「シェーダーコード関係の初期化、成功」で途切れてしまい
グラフィックを復帰できずにそのまま落ちてしまうようでした
|
| Re: android版で最小化した場合の動作 ( No.5 ) |
- 名前：管理人 日時：2017/07/14 01:37
少し調べたところ Fire HD8 に搭載されているメモリは 1.5GB とのことですので、
as01M に比べてメモリ容量は半分のようです
グラフィックを復帰する段階で終了していることから、やはりメモリに関連する
原因ではないかと思います
ところで復帰せずに終了してしまうアプリでは画像をどのくらい読み込んでいるのでしょうか？
よろしければ１枚あたりの解像度や数などを教えてください m(_ _)m
> ですがホーム画面に戻ってもタスクそのものは残っており(その表示画面では最小化した時の画面が表示されています)
> それを実行するとまた1から始まるようになってしまいます
こちらは Android の仕様でタスクマネージャから明示的に削除しない限りアプリの終了処理が完了していても
タスクマネージャにはアプリの表示が残り続けるようです
( 最小化した際の画面はスクリーンショットなので、仮にアプリが終了していても( 明示的に削除しない限り )表示は残り続けます )
|
| Re: android版で最小化した場合の動作 ( No.6 ) |
- 名前：初心者 日時：2017/07/14 10:30
超大雑把に確認したところ、まずファイルそのもののサイズは31MBほどでした。
これと同時に同じくらいの総容量になるwavの音声ファイルが30個ほど存在します
画像の総ファイル数は130ほどで、
解像度はかなりまちまちですが大きいもので1枠が320x240の画像が
10から20枚並んだ画像が15枚ほどあり、
それを配列上にすべてLoadDivGraphで読み込んでいるので
いちばん負荷がかかるとしたらこいつだろうとは思います
ちなみにその問題なく動く方のアプリでは最大解像度こそほぼ640x480に収まるサイズと小さいですが、
460枚近い50MBほどの画像を読み込んでいますが、問題なく復帰できます
|
| Re: android版で最小化した場合の動作 ( No.7 ) |
- 名前：管理人 日時：2017/07/15 14:50
> 解像度はかなりまちまちですが大きいもので1枠が320x240の画像が
> 10から20枚並んだ画像が15枚ほどあり、
> それを配列上にすべてLoadDivGraphで読み込んでいるので
> いちばん負荷がかかるとしたらこいつだろうとは思います
ＤＸライブラリはGPUが対応しているテクスチャの最大解像度以上のサイズの画像が読み込まれた場合は
内部で複数のテクスチャに分割して読み込むので、その処理が正常に動作していないのかと思い
手元で17280x800などのGPUが対応していない解像度の画像の読み込みをして、アプリの切り替えやホーム画面の
表示などをしてみましたが、正常に復帰することができたので、この処理が原因ではありませんでした…
> 超大雑把に確認したところ、まずファイルそのもののサイズは31MBほどでした。
> ちなみにその問題なく動く方のアプリでは最大解像度こそほぼ640x480に収まるサイズと小さいですが、
> 460枚近い50MBほどの画像を読み込んでいますが、問題なく復帰できます
容量が大きいほうが復帰できるというのは不思議ですね…
wavやその他の処理で使用しているデータ容量などを含めても後者の方が使用メモリが多いのでしょうか？
因みに画像ファイルは読み込まれると無圧縮32bitビットマップに変換されて使用されるので、もし読み込まれている
画像ファイルが圧縮形式である jpg ファイルや png ファイルでしたら、読み込まれた際に必要となるメモリは数倍になります
なので、実際に使用されるメモリ容量は画像ファイルをすべてフルカラーBMP画像( 24bit BMP画像 )にした上で、
サイズの合計に 1.33333333 を掛けたものとなります( 使用される際は 24bit ではなく 32bit なので )
ともあれ、手元で再現できれば原因の究明はすぐにできると思いますので、
もし不都合がなければグラフィックの復帰が失敗してしまうアプリのプロジェクトを頂けないでしょうか？
ただ、間違いなく容量の問題でメールでは送っていただくことは不可能だと思いますので、
もしご承諾いただける際はどこかのファイルアップロードサービスでアップした後、
ダウンロードのURLやパスワードなどをメールで
BQE00322(あっとまーく)nifty.ne.jp
( (あっとまーく) を @ に置き換えてください )
に送ってください m(_ _;m
 |
| Re: android版で最小化した場合の動作 ( No.8 ) |
- 名前：初心者 日時：2017/07/21 15:16
メール送信しています。
このうえなく凄惨な代物ですが、よろしければ確認いただければ幸いです
|
| Re: android版で最小化した場合の動作 ( No.9 ) |
- 名前：管理人 日時：2017/07/23 01:59
メールありがとうございます
アップして頂いたファイルで手元の環境でも現象が再現しました
原因はＤＸライブラリのバグで、LoadDivGraph で読み込まれた画像の復帰の際に
分割する数だけ画像全体用のメモリを確保してしまっていて
( 例えば 768x2880 の画像を１分割 768x320 で 9分割で読み込んでいた場合、
768x2880 の OpenGL ESテクスチャを9個作成してしまっていた( 本来は1個 ) )、
不要にメモリを消費していたのが原因でした
このバグを修正したところ正常に復帰することができるようになりましたので、
よろしければこちらの修正版をお試しください m(_ _;m
https://dxlib.xsrv.jp/temp/DxLibAndroidTest_ARM.exe // Android版 ARM用
https://dxlib.xsrv.jp/temp/DxLibAndroidTest_x86.exe // Android版 x86用
あと、現在初期化時にすべての画像を読み込んでいるようですので、
正常に復帰できる場合も復帰に時間が掛かりますが
こちらを画像が必要になった際に読み込み、不要になったら DeleteGraph で
削除するようにすれば起動時間や復帰に掛かる時間を短縮できますので、
よろしければお試しください m(_ _)m
|
| Re: android版で最小化した場合の動作 ( No.10 ) |
- 名前：初心者 日時：2017/07/23 02:16
確認いたしました。
あんな凄惨で悲惨なプログラムをわざわざ読み解いて頂きありがとうございました。
そう考えるとなんで逆に今までのブログラムが普通に動いていたのかは疑問ではありますが、
単純に解像度が小さい故にそこまで大きな画像を使っていなかったからなのでしょう。
いずれにしろ、本当にありがとうございました。
ところで、メールの方に合わせて記載していた
こちらの質問に関しては、再現はされなかったでしょうか？
もしそうでしたら本来の数値に合わせるように変数を足すようにすれば良いのでしょうか。
//引用
ブログラム内で「GetDateTime」関数を使用していますが
年数が117など極端に小さい値になってしまい、
また月数が本来想定していた数値よりも1小さい値が取得されていました
これを自分たちの感覚でいう正しい日付を取得する場合、
その取得した変数に直接加減算して合わせるしかないのでしょうか？
|
| Re: android版で最小化した場合の動作 ( No.11 ) |
- 名前：管理人 日時：2017/07/23 09:31
あ、すみません！ メモリ問題の方にばかり気が行ってしまって失念していました
ＤＸライブラリのバグだと思いますので修正します
なので取得後の値を加減算して頂く必要はありません
ただ、本日は用事がありあまり作業ができないので、もしかしたら修正版の作成は
明日以降になってしまうかもしれません、すみません m(_ _;m
|
| Re: android版で最小化した場合の動作 ( No.12 ) |
- 名前：管理人 日時：2017/07/23 23:53
|
| Re: android版で最小化した場合の動作 ( No.13 ) |
- 名前：初心者 日時：2017/08/15 02:30
ものすごく遅れてしまって申し訳ございません。
無事にこちらの方も意図したとおりの動作をすることが確認出来ました。
長々とお手数をおかけして本当に申し訳ございませんでした。
【追伸】
DxLibで作成したAPKファイルは、Google Play Storeにアップロードすることができるものなのでしょうか？
今それとなく検索してみたところ、APKファイルを作成する際にキーを設定したり何したりをしていたため
独特な作成をしないといけないのかどうかが気になります。
また、100MBを越えた際はAPK拡張ファイルを作る必要があるとありますが、
単純にプログラム以外のファイルを別に圧縮するだけでもいいのでしょうか？
それともプログラム上でそれを使う旨を記載して元の位置に戻すようなコードを
書く必要があるのでしょうか？
|
| Re: android版で最小化した場合の動作 ( No.14 ) |
- 名前：管理人 日時：2017/08/16 00:38
> DxLibで作成したAPKファイルは、Google Play Storeにアップロードすることができるものなのでしょうか？
> 今それとなく検索してみたところ、APKファイルを作成する際にキーを設定したり何したりをしていたため
> 独特な作成をしないといけないのかどうかが気になります。
Visual Studio で作成される APKファイルは署名がついていないものなので、Google Play Store にアップロードするには
Viaual Studio で作成された APKファイルに手動で署名を付ける必要があります
Google などで『apk 署名 keytool jarsigner』のキーワードで検索すると手動で署名を付ける方法が解説されている
ページが検出されますので、よろしければ調べてみてください m(_ _)m
> また、100MBを越えた際はAPK拡張ファイルを作る必要があるとありますが、
> 単純にプログラム以外のファイルを別に圧縮するだけでもいいのでしょうか？
> それともプログラム上でそれを使う旨を記載して元の位置に戻すようなコードを
> 書く必要があるのでしょうか？
はい、プログラム以外のファイルを別途圧縮した場合は、そのファイルはそのままでは
使用できませんので、実行時に圧縮ファイルを元のファイルに戻す処理を自前で作成する必要があります
ただ、APKファイル自体が zip圧縮されますので、別途圧縮しても APKファイルは
あまり小さくならないかもしれません
あと、現在のＤＸライブラリAndroid版はAPK拡張ファイルには対応していませんので、
一般的な手順で作成される APKファイルが100MBを超えないようにしていただくのが一番無難だと思います…
ファイルサイズの抑制方法としては
・wavファイルを使用していたら、oggファイルに変更する( ファイルサイズが約10分の1に )
・透過箇所の無い bmp画像は jpgファイルに変更する
・透過箇所のある bmp画像は pngファイルに変更する
といったものがあります
|