[EstevaX 作業日記]
KyoroTextのコードはすべて捨てることにしました。 新たに作り直します。
次のアプリのメタファはEstevaです。 AESTIVALISを誤記した結果、Estevaになりました。
# Just In Time に、情報を表示すること
# AESTIVALIS のように直感的に扱えること
を目標とします。
[課題]
KyoroTextの反省として、パフォーマンスの問題があります。 ちょっとした修正が、大きくパフォーマンスに影響することがありました。
そして、このような問題をそくざに検知することができませんでした。
今回は開発を開始したタイミングで、この問題に対応したいと考えています。
[試み]
EstevaXでは、 パフオーマンス測定用の自動テストを作ることにTRYしてみることしました。
具体的には、以下のような感じです。
-A. Instrumentation#setAutomaticPerformanceSnapshots()
-B. Aでしている事を、別の方法で実現する。
-C. cpuの使用率を計測する。
○Aは「Android Application Testing Guide」 で紹介された方法です。(http://dtmilano.blogspot.jp/)
cpuの処理時間を元に計測できるので、より良い的なことがかかれいました。
○Bは、直接必要なAPIをたたけば良いのではないか?と考えるにいたり、「PerformanceCollector(Androidのソース)」から
APIの使い方を流用することを思いつきまた。
○Cは、「TOPコマンドをたたくだけで良いかな」と考えています。
[A. Instrumentation#setAutomaticPerformanceSnapshots()]
Instrumentation#setAutomaticPerformanceSnapshots() を コールすると、Instrumentationが終了時に、
以下のような素敵ログをはいてくれます。
このうち、cpu_time execution_time に着目して、実際にプロセスが使用した時間を取得できます。
INSTRUMENTATION_RESULT: other_pss=3969
INSTRUMENTATION_RESULT: java_allocated=6146
INSTRUMENTATION_RESULT: global_freed_size=20128
INSTRUMENTATION_RESULT: native_private_dirty=16
INSTRUMENTATION_RESULT: native_free=132
INSTRUMENTATION_RESULT: global_alloc_count=1475
INSTRUMENTATION_RESULT: other_private_dirty=2880
INSTRUMENTATION_RESULT: global_freed_count=344
INSTRUMENTATION_RESULT: sent_transactions=-1
INSTRUMENTATION_RESULT: java_free=193
INSTRUMENTATION_RESULT: received_transactions=-1
INSTRUMENTATION_RESULT: pre_sent_transactions=-1
INSTRUMENTATION_RESULT: other_shared_dirty=2604
INSTRUMENTATION_RESULT: pre_received_transactions=-1
INSTRUMENTATION_RESULT: execution_time=5230398
INSTRUMENTATION_RESULT: native_size=2912
INSTRUMENTATION_RESULT: native_shared_dirty=24
INSTRUMENTATION_RESULT: cpu_time=317
INSTRUMENTATION_RESULT: java_private_dirty=1396
INSTRUMENTATION_RESULT: native_allocated=2779
INSTRUMENTATION_RESULT: gc_invocation_count=0
INSTRUMENTATION_RESULT: java_shared_dirty=8796
INSTRUMENTATION_RESULT: global_alloc_size=91221
INSTRUMENTATION_RESULT: java_pss=1685
INSTRUMENTATION_RESULT: java_size=6339
INSTRUMENTATION_RESULT: native_pss=16
INSTRUMENTATION_CODE: -1
ためしに 私が書いたコードは、以下のところに起きました。
https://github.com/kyorohiro/KyoroSamples/tree/master/InstrumentationSample
adb shell am instrument -w .kyorohiro.samples.android.instrumentation/info.kyorohiro.samples.android.instrumentation.MyInstrumentation
で動作します。
[-B. Aでしている事を、別の方法で実現する。]
Aは使い勝手が悪いです。 instrumentationの動作が完了するまで結果が出力されまん。
なので、別の方法をとることにしました。
Androidの該当するコード(PerformanceCollector)を呼んでみると、対応するAPIは公開されていることがわかります。
具体的には、SystemClock.uptimeMillis() と、 Process.getElapsedCpuTime() です。
直接このメソッドをコールすれば、プロセスがCPUの使用している時間だけをとることができます。
かなり便利です。そして簡単です。
※ためしに 私が書いたコードは、以下のところに起きました。
https://github.com/kyorohiro/KyoroSamples/tree/master/PerformanceCheckSample
※ ↑はCPUの使用時間以外も、Aの場合と同等の結果を任意のタイミングで返すことができます。
当面は、 Process.getElapsedCpuTime()を使用してパフォーマンスを測定することにしました。
何か問題が見つかるまでは、これでいこうと考えています。
2013年3月9日土曜日
EstevaX メモ パフォーマンス測定
登録:
コメントの投稿 (Atom)
mbedtls dart の 開発を始めた web wasm ffi io flutter
C言語 で開発した機能を、Dart をターゲットとして、Web でも サーバーでも、そして Flutter でも使えるようにしたい。 そこで、mbedtls の 暗号化の部分を Dart 向けのPackageを作りながら、 実現方法を試行錯誤する事にした。 dart...
-
[課題] Low Memory Killer を意図的に発生させたい Androidには、ヒープが涸渇すると使われていないアプリをKillする機能があります。 この記事では、意図的にヒープを枯渇させて、この状態をつくる方法について説明します。 単純にヒープを大...
-
Dart の Native Extensions を利用して、 SDL を用いたマルチプラットフォームのゲーム開発環境を作れるか検証してみた。 結論からいくと、 「Mac 上で動作する SDL x Dart の アプリは動作させることが難しいよ」 と言うことです。 Wind...
-
Emscripten と OpenGLを使ってゲームを作ろうと思いたって、 まずは、SDL2の基本的な使い方を試していた。 しかし、今の所は、SDL 1系 の方が、良いと思いました。 SDL2があるのに、SDL1 を選ぶのはなぜか? # 201...
0 件のコメント:
コメントを投稿