ラベル 開発 の投稿を表示しています。 すべての投稿を表示
ラベル 開発 の投稿を表示しています。 すべての投稿を表示

2014年9月7日日曜日

Androidのメモリ アロケート量

知らないことが多いんだな-、と反省。

Dalvik VMはメモリサイズ量の管理が特殊なのかな。大容量をAllocateできない。JNI内でAllocateすると大量のメモリを確保できる。プロセスが終われば解放されるのであれば、それで良いのではないかと思う。

DalvikVM(JVM)は一定量以下のJAVAで利用するメモリを操作するのに向いていて、GCも効率よく出来ているようだが、メガバイト単位の領域を確保するようにはなっていないようだ。メガバイトを確保すると、他のアプリに迷惑がかかるだろうが、業務で利用することを考えたら、そんなことは関係無い。速く動く方が良いに決まっているし、機種も限定される。

JNIはVMの外側でアロケートできるようで、VMが管理している全メモリ量くらいまでアロケート可能なようだ。VMはBitmapをこの外部メモリにアロケートするようだが、Bitmap以外でもアロケートして欲しいものだ。

しかし、Javaの処理速度から考えれば、現在のメモリ管理量は妥当なのかもしれない。

16MBのデータファイルを5個開こうとしている事に無理があるのかな。それでも80MBなんだが。メインメモリは2GBもあるのに。

C言語(JNI側)

for (int i = 0; i < 5; i++)
  K[i].pDataBuffer = (char *)malloc(1024 * 1024 * 16);

同じバッファをJava側で確保しようとしたら、3個目でOutOfMemoryした。

変な考えを起こさないで最初からC言語で確保すれば良かった。この領域、プログラム終了まで解放しないので、問題ないみたい。最初、JNIで確保するとリークするのかと思っていた。そんなことは無い。JNIは単にNativeなだけで直接Linuxを呼び出しているだけのようだ。

2014年9月5日金曜日

Android 開発 Uriで受け取ったファイルの元のファイル名とサイズの取り出し方

ContentResolver cr = getContentResolver();
String[] projection = {MediaStore.MediaColumns.DISPLAY_NAME, MediaStore.MediaColumns.SIZE};
Cursor metaCursor = cr.query(uri, projection, null, null, null);
if (metaCursor != null) {
    try {
        if (metaCursor.moveToFirst()) {
            orgFileName = metaCursor.getString(0);
            orgSize = metaCursor.getString(1);
        }
    } finally {
        metaCursor.close();
    }
}

ずっと悩んでいたが解決した。そうだよね、取り出し方が無いなんてことはないでしょ。