[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する機能があります。 この記事では、意図的にヒープを枯渇させて、この状態をつくる方法について説明します。 単純にヒープを大...
-
UPnPを用いて、NAT越えできました。しかし、ルータがUPnPをサポートしていなかったり。UPnPだけでは越えられないNATがあります。 本文では、その代案として前回解説できなかった。「適当なサーバーに接続してみて、相手から見えているアドレスを返してもらう方法」について解...
-
Dart の Native Extensions を利用して、 SDL を用いたマルチプラットフォームのゲーム開発環境を作れるか検証してみた。 結論からいくと、 「Mac 上で動作する SDL x Dart の アプリは動作させることが難しいよ」 と言うことです。 Wind...