Autor Wątek: Heap size android  (Przeczytany 1923 razy)

Offline Tinekk

  • Użytkownik

# Grudzień 07, 2012, 22:34:56
Witam pożyczyłem sobie telefon (HTC WILDFIRE) od kuzynki na jeden dzień, i zamiast pisać dalej, męczę się z ustawieniem.
A więc tak, appka nie rusza, wywala błędy

12-07 21:32:17.506: E/AndroidRuntime(3808): FATAL EXCEPTION: main
12-07 21:32:17.506: E/AndroidRuntime(3808): java.lang.OutOfMemoryError: (Heap Size=13447KB, Allocated=10722KB, Bitmap Size=7231KB)
12-07 21:32:17.506: E/AndroidRuntime(3808): at org.apache.harmony.luni.platform.OSMemory.malloc(Native Method)
12-07 21:32:17.506: E/AndroidRuntime(3808): at org.apache.harmony.luni.platform.PlatformAddressFactory.alloc(PlatformAddressFactory.java:129)
12-07 21:32:17.506: E/AndroidRuntime(3808): at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:65)
12-07 21:32:17.506: E/AndroidRuntime(3808): at java.nio.ReadWriteDirectByteBuffer.<init>(ReadWriteDirectByteBuffer.java:48)
12-07 21:32:17.506: E/AndroidRuntime(3808): at java.nio.BufferFactory.newDirectByteBuffer(BufferFactory.java:93)
12-07 21:32:17.506: E/AndroidRuntime(3808): at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:65)
12-07 21:32:17.506: E/AndroidRuntime(3808): at Klasy.Object.LoadTof(Object.java:140)
12-07 21:32:17.506: E/AndroidRuntime(3808): at Klasy.Object.<init>(Object.java:37)
12-07 21:32:17.506: E/AndroidRuntime(3808): at Gra.Game.<init>(Game.java:60)
12-07 21:32:17.506: E/AndroidRuntime(3808): at packagename.xx.OpenGLRenderer.<init>(OpenGLRenderer.java:40)
12-07 21:32:17.506: E/AndroidRuntime(3808): at packagename.xx.MyGLSurfaceView.<init>(GLActivity.java:49)
12-07 21:32:17.506: E/AndroidRuntime(3808): at packagename.xx.GLActivity.onCreate(GLActivity.java:24)
12-07 21:32:17.506: E/AndroidRuntime(3808): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1072)
12-07 21:32:17.506: E/AndroidRuntime(3808): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1794)
12-07 21:32:17.506: E/AndroidRuntime(3808): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1851)
12-07 21:32:17.506: E/AndroidRuntime(3808): at android.app.ActivityThread.access$1500(ActivityThread.java:132)
12-07 21:32:17.506: E/AndroidRuntime(3808): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1038)
12-07 21:32:17.506: E/AndroidRuntime(3808): at android.os.Handler.dispatchMessage(Handler.java:99)
12-07 21:32:17.506: E/AndroidRuntime(3808): at android.os.Looper.loop(Looper.java:143)
12-07 21:32:17.506: E/AndroidRuntime(3808): at android.app.ActivityThread.main(ActivityThread.java:4277)
12-07 21:32:17.506: E/AndroidRuntime(3808): at java.lang.reflect.Method.invokeNative(Native Method)
12-07 21:32:17.506: E/AndroidRuntime(3808): at java.lang.reflect.Method.invoke(Method.java:507)
12-07 21:32:17.506: E/AndroidRuntime(3808): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
12-07 21:32:17.506: E/AndroidRuntime(3808): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
12-07 21:32:17.506: E/AndroidRuntime(3808): at dalvik.system.NativeStart.main(Native Method)

Z tego co rozumiem, brakuje ramu?

Chciał bym dodać że appka rusza na innym telefonie (wt 19i) rusza bez problemów - tak samo na maszynie wirtualnej.

Properties
target=android-10
dalvik.vm.heapsize=64m
vm.heapsize=64m


@edit zakomentowanie funkcji ladujacych tekstury nie pomaga.
@edit2 zastanawiam sie, moze mala pamiec telefonu(9mb) nie pozwala? (karta 1gb wolne)
« Ostatnia zmiana: Grudzień 07, 2012, 22:45:58 wysłana przez Tinekk »

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline deadeye

  • Użytkownik

# Grudzień 07, 2012, 23:26:06
W starym Androidzie rozmiar sterty dla jednej aplikacji może być bardzo mały (u ciebie - 13mb), a rozmiar bitmapki masz duży (7mb), więc nie ma szans. Poczytaj na Android Developers jak sobie z tym radzić.

Offline Tinekk

  • Użytkownik

# Grudzień 07, 2012, 23:34:23
Ok doszedlem więc że ladowanie modelu tworzy problem:
alien = new Object("alien.tof", context, true); model wazy dokladnie 3.15mb
uruchomila mi się appk ale wyglada jak shit

wszystko dobrze jak zakomentuje
setEGLConfigChooser(8, 8, 8, 8, 16, 0);więc co teraz gdy potrzebuje formatu 888 do pickingu? nie przesadzajmy ze taka prosta rzecz dyskwalifikuje uruchomienie aplikacji na htc wildifre s...

Offline Avaj

  • Użytkownik

# Grudzień 07, 2012, 23:56:28
rób picking na 5 6 5?

Offline Tinekk

  • Użytkownik

# Grudzień 08, 2012, 00:08:22
Wracając do heap size

"FWIW, this is configured with the dalvik.vm.heapsize system property
(default "16m").  Apps can't change it, but if you're using a rooted
device or the emulator it's now much easier to experiment with
different memory limits. "

czyli po ptokach?

Offline RedHot

  • Użytkownik

# Grudzień 08, 2012, 00:35:48
Przypomnę tylko, że starsze Androidy bardzo kochają 5 6 5 :) Warto się zainteresować

Offline Tinekk

  • Użytkownik

# Grudzień 08, 2012, 00:39:18
Przypomnę tylko, że starsze Androidy bardzo kochają 5 6 5 :) Warto się zainteresować
Pół biedy z tym - to jeszcze da się rozwiązać :)

Offline skoti

  • Użytkownik

# Grudzień 09, 2012, 03:01:49
Jeśli będziesz zarządzał sam pamięcią z poziomu C++ w NDK to problem z pamięcią też nie będzie obowiązywał (problem masz tylko korzystając z GC dalvika)

Offline RedHot

  • Użytkownik

# Grudzień 12, 2012, 02:17:23
Kontynuując poprzednią wypowiedź skotiego. Pisząc mój soft AR na Androida ~2.1/2.2  musiałem korzystać z C++ NDK bo GC w Javie koszmarnie mi zabijał wydajność. Już jest lepiej, ale nadal się uczę tweakowania :) A niestety większośc rynku nadal siedzi < Androida 3.0, a od 4.0 programiści dostali kupę fajnych narzędzi .

Offline skoti

  • Użytkownik

  • +1
# Grudzień 12, 2012, 10:49:04
@up: 50% rynku to dalej Android 2.3... jednak należy pamiętać, że część z tych urządzeń to przykładowo G1 z nieoficjalnym softem. Co z tego, że ma Android 2.3 (który już daje sporo możliwości) skoro i tak wiele z tych urządzeń wydajnościowo nie podołają grze/aplikacji. Android 4.x nie wnosi wiele w NDK (OpenMAX nie jest aż tak interesujący - tzn jest bo sprzętowo można dekodować video, ale nie wiele aplikacji tego potrzebuje), a w SDK masz Support Library dzięki czemu możesz skorzystać z nowości jednocześnie mając wsteczną kompatybilność z wcześniejszymi wersjami.
Ogólnie rynek Androida to 87% 2.3 lub wyżej, a to daje już przyzwoite możliwości w NDK (2.3 zrobił tu duży postęp i można pisać dla wszystkich arch (arm, x86, mips), można korzystać z całkowicie natywnego kodu, jest OpenSL ES... - jedynie OpenMAX brakuje z Androidów 4.x), a dodając to, że starsze Androidy czyli 13% przeważnie i tak nie są wstanie uruchomić programu (chociażby dlatego, że 9.2% androidów to urządzenia bez OpenGL ES 2.0, a jakie CPU idą z tym w parze to każdy wie), można uznać, że pisanie dla 2.3 to rozsądne minimum.