2011-06-28

処理時間測定方法(android.util.TimingLogger)

Android

例えば、アプリ内のボトルネック調査するとき、
重そうな処理にアタリつけて処理時間測定しますよね。
ベタにやるとこんな感じ。

// 測定開始
long start = System.currentTimeMillis();

// 測定したい処理

// 測定終了
long end = System.currentTimeMillis();
Log.d(getClass().getName(), "measure: " + (end - start));

何かないかなーと思って公式javadoc見てたら
便利そうなクラスを発見。

android.util.TimingLogger

使い方はざっくりこんな感じ。

コンストラクタ(測定開始)
- // 処理1
- addSplit(処理1 の処理時間測定)
- // 処理2
- addSplit(処理2 の処理時間測定)
- ・・・
dumpToLog(測定終了＋ログ出力)

テストコード書いてみた。

private void testTimingLogger() {
    // 測定開始
    TimingLogger logger = new TimingLogger("TAG_TEST", "testTimingLogger");

    // 処理1

    logger.addSplit("abeshi");

    // 処理2

    logger.addSplit("hidebu");

    // 測定終了＋ログ出力
    logger.dumpToLog();
}

さっそく実行してみる。
が、ログが出ない。

javadoc見ると、TimingLogger のコンストラクタにこう書いてある。

Create and initialize a TimingLogger object that will log using the specific tag.
If the Log.isLoggable is not enabled to at least the Log.VERBOSE level 
for that tag at creation time then the addSplit and dumpToLog call will do nothing.

参考までにこんな記事も。
stackoverflow - Time code execution in Android

ログ出力レベルを「VERBOSE」にしないと何も出力しないだそうです。

というわけで、ログレベルを「VERBOSE」に変更してみる。
上記ソースの場合、ログレベル変更はこんな感じになりますね。

$ adb shell
# setprop log.tag.TAG_TEST VERBOSE

アプリ実行。

DEBUG/TAG_TEST(940): testTimingLogger: begin
DEBUG/TAG_TEST(940): testTimingLogger:      6 ms, abeshi
DEBUG/TAG_TEST(940): testTimingLogger:      17 ms, hidebu
DEBUG/TAG_TEST(940): testTimingLogger: end, 23 ms

ログ出た。これは便利。

2011-06-27

Android技術者認定試験制度

Android

自分の Android に関する知識がすごく狭い範囲に偏っているなぁーと
意識することが最近よくあって。

全体を知るために何したらいいのかなーと考えたときに
この Android技術者認定試験を思いだしたので
試験内容を改めてチェックしてみました。

試験は以下の2種類。

アプリケーションスキル for Android
プラットフォームスキル for Android(開発中)

対応している分野は、
前者＝アプリを作る人、後者＝フレームワークいじる人、というかんじですね。

さっそく前者の試験範囲をチェックしてみる。
(現在受験可能なのは前者のみ)

アプリケーションスキル定義

なるほど。
とにかく広範囲な試験、という感じ。
(1つ1つをあまり深く掘り下げていない)

Androidでアプリネタをなにか思いついたときに、
「実現方法のアタリをつけるための最低限の知識」を
身につけるためにはいいのかもしれない。

模擬試験があったので試しに解いてみた。

模擬試験
10点中7点。微妙ｗ

資格のことを考えるときに思い出すのが、
「資格は足の裏の米粒のようなもの」
という先輩からのお言葉。

「資格」とかけまして！
「足の裏の米粒」と説く！
その心は！
「取っても食えない」
ねずっｔ(ｒｙ

「資格持ってまっせ！！」アピールすることを目的とするのではなく、
資格を取るために「試験範囲を自分で勉強する」ことがいちばん大事。

といっても、就活時代に履歴書に毎回、

普通自動車第一種運転免許
英検5級

と書いてた自分よりはマシかもしれないｗ

就活ではじめてのシステム系会社の面接時に、

面接官「経験した言語は？」
自分「英語とドイツ語です」

と素で答えた黒歴史を思い出した件。
もちろん落ちましたｗ

2011-06-24

NativeDriver

Android

Google謹製のテストフレームワークが！
Introducing Native Driver

サンプルではGoogleMapのテストが記載されとりますね。これはおもしろい。

Android Zaurusさんの日本語訳はこちら。
【超訳】AndroidのUIをUnitTestできるNative Driver

テストコード書くのは慣れないと書くのが大変、という点はあるけども、
テストを自動化できる、というメリットはやはりでかい。
さっそく試してみるとします。

2011-05-31

ソース内の改定履歴

バージョン管理にコメントを残したとしても、ソースコードに改訂履歴のコメントを残す必要があるという主張 - プログラマとSEのあいだ

考えさせられた。

今の職場は svn 使用してます。
このあたりの意見は個人によってさまざま。
むしろコミットログ詳細を残す習慣がなく、
ソースコードに「担当者＋日付＋チケット番号＋開始〜終了」みたいな人も多い。

いまの自分の考えはこうかなー。

できるだけ1回のコミットで、1つの課題(チケット)のみ対象とするようにする
1回のコミットで複数の課題(チケット)が対象になる場合は、コミットログに修正詳細書いとく
ソース内に改定履歴は書かない

で、1課題で複数コミットが発生するような対応は

基本的に branch で作業
対応完了するまでは trunk にはコミットしない
対応完了したら branch->trunk へマージ(1コミット)
マージ時に「branch -> trunkへマージ(r1:10)」みたいなコミットログ書いとく

という感じで作業していたりする。
trunk へのコミットはなるべく「1チケット1コミット」、
「branchでは好き放題コミット」みたいな。

gitとか分散型リポジトリだとまた話が変わってくるのかなー。
個人で使ったことはあるけども、複数人でgit使って作業したことがないからよくわからん。

うーん。どうするのが理想なんだろうか。

2011-05-30

ADTのレイアウトエディタがすごい件

Android

いつのまにか ADTのレイアウトエディタが恐ろしく進化している！！

11(preview版)では xml を直接いじらなくても
エディタ上だけでこんなことができたりする。
(正確には 10.x でも動作する機能が一部あり)

共通レイアウトの抽出
アニメーションのプレビュー
カスタムビューもD&Dで配置可能

eclipseのプラグイン自動更新では 10.x のバージョンまでしか落ちてこないが、
サイトには 11(preview版) がzipで配布されとります。(2011/5/30現在)

Android Tool Project Site

@yanzm さんがustで ADT11(preview版) について
説明してくれていたのだが、見てて衝撃を受けた。
(当日のログはハッシュタグ #debhw で検索したら見れるかも)

いままでADTのレイアウトエディタ(レイアウト用xml開いたら表示されるエディタ)は、
使い勝手が悪くてxmlを直接修正しないと使い物にならない、という意識だった。
どうせxmlいじらないとダメなんだからこんなエディタ使ってらんねー、
と思って使うことすら避けてたのだけども。

いつのまにか超進化しとる。
ADTレイアウトエディタ派になってみる。

プログラマってこんなかんじ？？

アプリ作ったり歌ったりしてます

処理時間測定方法(android.util.TimingLogger)

Android技術者認定試験制度

NativeDriver

ソース内の改定履歴

ADTのレイアウトエディタがすごい件