I am developing a live wallpaper using andengine. Initially i used about 20 texture atlas for each sprite but then in one of the posts in andengine forum I saw that to many texture atlas is not a good thing to have in your app so I changed it to texture packer and now i have 3 texture packers. Everything is ok except when the wallpaper gain focus (either on unlock or closing another app), the wallpaper freezes for about 1-2 sec. Freezing was there even when i had individual texture atlas for each sprite. I added comments in onResume method and the first animation method to see what goes in between the execution of these two lines (first and last line in the following logcat output) and following is the logcat output. Can someone please direct me in right direction. I have already searched a lot on andengine freezing issues but none of them explain's my issue.
12-10 21:23:05.816: E/LiveWallpaperSettings(21831): Resume // <<< onResume Called
12-10 21:23:05.896: D/AndEngine(21831): VERSION: OpenGL ES 2.0
12-10 21:23:05.896: D/AndEngine(21831): RENDERER: Mali-400 MP
12-10 21:23:05.896: D/AndEngine(21831): EGLCONFIG: EGLConfig(Red=5, Green=6, Blue=5, Alpha=0, Depth=0, Stencil=0)
12-10 21:23:05.896: D/AndEngine(21831): EXTENSIONS: GL_OES_texture_npot GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil
12-10 21:23:05.906: D/AndEngine(21831): MAX_VERTEX_ATTRIBS: 16
12-10 21:23:05.906: D/AndEngine(21831): MAX_VERTEX_UNIFORM_VECTORS: 128
12-10 21:23:05.906: D/AndEngine(21831): MAX_FRAGMENT_UNIFORM_VECTORS: 1024
12-10 21:23:05.906: D/AndEngine(21831): MAX_TEXTURE_IMAGE_UNITS: 8
12-10 21:23:05.906: D/AndEngine(21831): MAX_TEXTURE_SIZE: 4096
12-10 21:23:05.906: D/AndEngine(21831): LiveWallpaperTemplate.onSurfaceCreated #(Thread: 'GLThread 11')
12-10 21:23:05.906: D/AndEngine(21831): LiveWallpaperTemplate.onReloadResources #(Thread: 'GLThread 11')
12-10 21:23:05.906: D/AndEngine(21831): LiveWallpaperTemplate.onSurfaceChanged(Width=480, Height=800) #(Thread: 'GLThread 11')
12-10 21:23:06.156: D/dalvikvm(21831): GC_FOR_MALLOC freed 39K, 81% free 2725K/13639K, external 3900K/3900K, paused 12ms
12-10 21:23:06.161: I/dalvikvm-heap(21831): Grow heap (frag case) to 12.774MB for 3932176-byte allocation
12-10 21:23:06.191: D/dalvikvm(21831): GC_FOR_MALLOC freed 0K, 52% free 6565K/13639K, external 3900K/3900K, paused 10ms
12-10 21:23:06.256: D/dalvikvm(21831): GC_CONCURRENT freed 0K, 52% free 6565K/13639K, external 3900K/3900K, paused 1ms+2ms
12-10 21:23:06.301: D/dalvikvm(21831): GC_EXTERNAL_ALLOC freed 3843K, 81% free 2725K/13639K, external 60K/3900K, paused 16ms
12-10 21:23:06.661: D/dalvikvm(21831): GC_FOR_MALLOC freed 4096K, 81% free 2724K/13639K, external 4156K/4156K, paused 9ms
12-10 21:23:06.666: I/dalvikvm-heap(21831): Grow heap (frag case) to 13.274MB for 4194320-byte allocation
12-10 21:23:06.696: D/dalvikvm(21831): GC_FOR_MALLOC freed <1K, 50% free 6820K/13639K, external 4156K/4156K, paused 10ms
12-10 21:23:06.741: D/dalvikvm(21831): GC_CONCURRENT freed <1K, 50% free 6820K/13639K, external 4156K/4156K, paused 1ms+1ms
12-10 21:23:06.911: D/dalvikvm(21831): GC_FOR_MALLOC freed 4096K, 81% free 2724K/13639K, external 4156K/4156K, paused 10ms
12-10 21:23:06.916: I/dalvikvm-heap(21831): Grow heap (frag case) to 13.274MB for 4194320-byte allocation
12-10 21:23:06.946: D/dalvikvm(21831): GC_FOR_MALLOC freed 0K, 50% free 6820K/13639K, external 4156K/4156K, paused 10ms
12-10 21:23:06.996: D/dalvikvm(21831): GC_CONCURRENT freed <1K, 50% free 6820K/13639K, external 4156K/4156K, paused 1ms+2ms
12-10 21:23:07.076: D/dalvikvm(21831): GC_EXPLICIT freed 4100K, 81% free 2724K/13639K, external 60K/572K, paused 16ms
12-10 21:23:07.106: E/LiveWallpaperSettings(21831): Backward loop // animation method called
Related
I have a bar-code scanning Cordova (webview) app, and after a certain point, if I restart the barcode-scanning camera, I get a crazy crash that bricks my phone until I give the entire phone a full restart:
Stats:
Nexus 5
Android 4.4.4
Kernel 3.4.0-gd59db4e
I'm using the zbar scanning lib, which uses OpenCV.
Here's the catlog right around the time that things go haywire; once I start getting "Failed to get_buf", the repeating image effect kicks in and I have to restart my phone.
D/mm-camera(199): module_faceproc_port_event_func:667] FD_STREAMON for stream 10004
I/mm-camera(199): cpp_module_handle_streamon_event:1983, identity=0x10004, stream-on done
I/mm-camera(199): isp_streamon: E, session_id = 1, stream_id = 4, stream_type = 5
I/mm-camera(199): wb_set_params: param_id is not supported in this module
I/mm-camera(199): wb_set_params: param_id is not supported in this module
I/mm-camera(199): wb_set_params: param_id is not supported in this module
D/mm-camera(199): module_faceproc_port_event_func:825] MCT_EVENT_MODULE_ISP_OUTPUT_DIM stream info 1920x1080 identity 10004 10003
I/mm-camera(199): isp_ch_util_streamon: session_id = 1, channel_id = 3, already active.
I/mm-camera(199): ispif_streamon: session_id = 1, active_streams = 3
I/mm-camera(199): mct_pipeline_process_set: Stream on/off returned
D/mm-camera-intf(186): mm_stream_qbuf: Starting poll on stream 0xb7f4c4cc type :5
D/mm-camera-intf(186): mm_stream_qbuf: Started poll on stream 0xb7f4c4cc type :5
D/mm-camera-intf(186): mm_stream_qbuf: Starting poll on stream 0xb7f4bda4 type :1
D/mm-camera-intf(186): mm_stream_qbuf: Started poll on stream 0xb7f4bda4 type :1
D/mm-camera(199): module_faceproc_client_schedule_mode:1808] apply 3 report 2 new_mode 0
E/mm-camera-sensor(199): port_sensor_handle_upstream_module_event:1244 Reset previously set LED state!
I/AEC_PORT(199): aec_port_proc_downstream_event: Received LED state timeout. Reset LED state!
D/mm-camera(199): module_faceproc_client_schedule_mode:1808] apply 0 report 3 new_mode 0
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 1689470 CurPosition: 36
D/mm-camera(199): module_faceproc_client_schedule_mode:1808] apply 1 report 0 new_mode 0
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 634118 CurPosition: 33
D/dalvikvm(3354): GC_FOR_ALLOC freed 3373K, 35% free 17228K/26472K, paused 13ms, total 13ms
I/dalvikvm-heap(3354): Grow heap (frag case) to 19.818MB for 3110416-byte allocation
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 602020 CurPosition: 30
D/dalvikvm(3354): GC_FOR_ALLOC freed 0K, 24% free 20265K/26472K, paused 14ms, total 14ms
D/dalvikvm(3354): GC_FOR_ALLOC freed 3037K, 35% free 17227K/26472K, paused 14ms, total 14ms
I/dalvikvm-heap(3354): Grow heap (frag case) to 19.818MB for 3110416-byte allocation
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 552162 CurPosition: 27
D/dalvikvm(3354): GC_FOR_ALLOC freed 0K, 24% free 20265K/26472K, paused 15ms, total 15ms
E/mm-camera(199): cpp_module_process_frame_control:1458 failed: wrong queue for mct_type = 2 frame 8 exp 16
E/mm-camera(199): cpp_module_process_frame_control:1458 failed: wrong queue for mct_type = 2 frame 8 exp 16
E/mm-camera(199): cpp_module_process_frame_control:1458 failed: wrong queue for mct_type = 2 frame 8 exp 16
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 524040 CurPosition: 31
D/dalvikvm(3354): GC_FOR_ALLOC freed 3037K, 35% free 17227K/26472K, paused 13ms, total 14ms
I/dalvikvm-heap(3354): Grow heap (frag case) to 19.818MB for 3110416-byte allocation
D/dalvikvm(3354): GC_FOR_ALLOC freed 0K, 24% free 20265K/26472K, paused 17ms, total 17ms
E/mm-camera(199): cpp_module_process_frame_control:1458 failed: wrong queue for mct_type = 2 frame 9 exp 17
E/mm-camera(199): cpp_module_process_frame_control:1458 failed: wrong queue for mct_type = 2 frame 9 exp 17
E/mm-camera(199): cpp_module_process_frame_control:1458 failed: wrong queue for mct_type = 2 frame 9 exp 17
D/dalvikvm(3354): GC_FOR_ALLOC freed 3037K, 35% free 17227K/26472K, paused 12ms, total 12ms
I/dalvikvm-heap(3354): Grow heap (frag case) to 19.818MB for 3110416-byte allocation
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 328800 CurPosition: 33
D/dalvikvm(3354): GC_FOR_ALLOC freed 0K, 24% free 20265K/26472K, paused 21ms, total 21ms
D/dalvikvm(3354): GC_FOR_ALLOC freed 3037K, 35% free 17227K/26472K, paused 13ms, total 13ms
I/dalvikvm-heap(3354): Grow heap (frag case) to 19.818MB for 3110416-byte allocation
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 370341 CurPosition: 35
D/dalvikvm(3354): GC_FOR_ALLOC freed 0K, 24% free 20265K/26472K, paused 16ms, total 16ms
D/dalvikvm(3354): GC_FOR_ALLOC freed 3037K, 35% free 17227K/26472K, paused 14ms, total 14ms
I/dalvikvm-heap(3354): Grow heap (frag case) to 19.818MB for 3110416-byte allocation
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 398033 CurPosition: 37
D/dalvikvm(3354): GC_FOR_ALLOC freed 0K, 24% free 20265K/26472K, paused 16ms, total 16ms
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 397856 CurPosition: 39
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 424101 CurPosition: 41
D/mm-camera-intf(186): mm_stream_read_msm_frame: Stoping poll on stream 0xb7f4bda4 type :1
D/mm-camera-intf(186): mm_stream_read_msm_frame: Stopped poll on stream 0xb7f4bda4 type :1
D/mm-camera-intf(186): mm_stream_read_msm_frame: Stoping poll on stream 0xb7f4c4cc type :5
D/mm-camera-intf(186): mm_stream_read_msm_frame: Stopped poll on stream 0xb7f4c4cc type :5
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 440796 CurPosition: 43
I/mm-camera(199): af_util_cur_pos_after_lens_move: After move: FV: 438574 CurPosition: 41
I/mm-camera(199): af_util_update_focus_status: AF Status already updated to output!Return!
I/mm-camera(199): af_util_update_focus_status: AF Status already updated to output!Return!
E/mm-camera(199): mct_stream_metadata_bus_msg:Failed to get_buf
E/mm-camera(199): mct_stream_metadata_bus_msg:1259: NULL ptr
D/mm-camera-intf(186): mm_stream_read_msm_frame: Stoping poll on stream 0xb7f4af54 type :8
D/mm-camera-intf(186): mm_stream_read_msm_frame: Stopped poll on stream 0xb7f4af54 type :8
E/mm-camera(199): mct_stream_metadata_bus_msg:Failed to get_buf
E/mm-camera(199): mct_stream_metadata_bus_msg:1259: NULL ptr
E/mm-camera(199): mct_stream_metadata_bus_msg:Failed to get_buf
E/mm-camera(199): mct_stream_metadata_bus_msg:1259: NULL ptr
E/mm-camera(199): mct_stream_metadata_bus_msg:Failed to get_buf
E/mm-camera(199): mct_stream_metadata_bus_msg:1259: NULL ptr
Any ideas?
The answer posted by my colleague at the following link solved our problem:
https://stackoverflow.com/a/27284543/914123
OK we had the same problem - Nexus 5 only, but with ZBar lib instead of ZXing.
The issue was resolved by switching from a SurfaceView to a TextureView - however this resulted in slower frame rates.
Through testing we found that our issue was caused by leaving the screen, bringing up the keyboard and going back - our solution was setting android:windowSoftInputMode to AdjustPan in the manifest.
I have exit my app, but there is still a backgroud service is running. Whe the GC logs come a log. I will so you the logs beblow. You can see, about 3 logs per second. Is This phenomenon is normal ? My device's memory is enough, and the backgroud service is holding a WebSocket connection.
08-11 10:33:54.456 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 12ms+6ms, total 44ms
08-11 10:33:54.776 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1985K, 18% free 10676K/12871K, paused 12ms+8ms, total 54ms
08-11 10:33:55.109 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1950K, 18% free 10671K/12871K, paused 12ms+17ms, total 68ms
08-11 10:33:55.459 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2004K, 18% free 10680K/12871K, paused 13ms+8ms, total 62ms
08-11 10:33:55.769 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2010K, 18% free 10680K/12871K, paused 12ms+7ms, total 48ms
08-11 10:33:56.093 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1996K, 18% free 10677K/12871K, paused 12ms+9ms, total 50ms
08-11 10:33:56.416 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2028K, 18% free 10681K/12871K, paused 2ms+8ms, total 37ms
08-11 10:33:56.746 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2031K, 18% free 10682K/12871K, paused 8ms+8ms, total 46ms
08-11 10:33:57.079 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1996K, 18% free 10677K/12871K, paused 12ms+7ms, total 46ms
08-11 10:33:57.429 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2002K, 18% free 10678K/12871K, paused 12ms+19ms, total 59ms
08-11 10:33:57.766 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2003K, 18% free 10679K/12871K, paused 12ms+7ms, total 46ms
08-11 10:33:58.143 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1945K, 18% free 10669K/12871K, paused 12ms+17ms, total 72ms
08-11 10:33:58.473 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 2ms+6ms, total 41ms
08-11 10:33:58.786 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2013K, 17% free 10690K/12871K, paused 12ms+8ms, total 48ms
08-11 10:33:59.106 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2031K, 18% free 10683K/12871K, paused 12ms+8ms, total 53ms
08-11 10:33:59.443 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2021K, 18% free 10681K/12871K, paused 12ms+8ms, total 48ms
08-11 10:33:59.786 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 2028K, 18% free 10681K/12871K, paused 11ms+7ms, total 44ms
08-11 10:34:00.153 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕ GC_CONCURRENT freed 1997K, 18% free 10677K/12871K, paused 12ms+18ms, total 58ms
Is This phenomenon is normal ?
It depends what you mean by "normal".
If you mean normal for an application with those particular heap dimensions, that amount of heapspace used for long-lived objects, and that rate of allocation ... then the answer is "Yes, it is normal".
Basically, you are running your application with a heap that is (objectively) too small for the work that you are asking it to do. You have roughly 2Mb of free space, and you are allocating objects at roughly 6Gb per second. If you want to reduce the number of GC cycles, you need to do one or more of the following:
Increase the heap size. (I don't know if this is feasible for an Android app ...)
Reduce the "working set" of long-lived objects. Maybe you have a memory leak, lots of large images loaded, or an overly large in-memory cache of ... something.
Reduce the rate at which new objects are being allocated by your application.
The last two require you to track down the source of the memory usage / allocation, and change you code to mitigate the effects. There are tools (memory profilers) that can help with this, but the details will be specific to your application.
Here's how I'd interpret the GC log lines ... by example:
08-11 10:33:54.456 6821-6823/com.tong.iknow:ik_service_v1 E/dalvikvm﹕
GC_CONCURRENT freed 2020K, 18% free 10682K/12871K, paused 12ms+6ms, total 44ms
The "GC_CONCURRENT" collector is being used.
This GC collection cycle reclaimed 2020K bytes.
When the GC cycle completed, 18% of the heap is free, and 10682K out of a total usable heap size of 12871K is in use.
Normal thread activity was paused for two intervals of 12ms and 6ms respectively.
The elapsed time for the GC cycle was 44ms.
Note that the amount of heap freed isn't always exactly the same as the different between total and available ... because for much of the time that the GC is running there are normal threads allocating new objects.
I am making an app that involves a lot of animation.
For example:
I got a group of png files(50+) and iterate them with the frame rate of 15fps, to make it looks like an animation.
I have many groups of image files like that. image size: 480x800, with alpha.
my app works basically okay, while I found a lot of GC_FOR_ALLOC in the logcat while playing animation.
my question is that with so many GC_FOR_ALLOC, can I just ignore them, or figured someway to eliminate them? my app also has an minor problem, not sure if related with GC, on some older android devices, the frame rate can not get to even 10fps.
I tried to recycle the bitmap, but it seems only mark that item is available for GC.
I load image this way:
BitmapFactory.Options localOptions = new BitmapFactory.Options();
localOptions.inPreferredConfig = Bitmap.Config.ARGB_8888;
try {
return BitmapFactory.decodeStream(context.getAssets().open(fileName), null, localOptions);
} catch (IOException e) {
e.printStackTrace();
}
return null;
after load the image, I draw them on SurfaceView, like this:
canvas.drawBitmap(BgImage,rectBG2, rectScreen2, null);
for every frame, I need to draw about 3 images(3 layers). not sure if that has anything to do with GC.
below is an example of those GCs:
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17653K/32583K, paused 29ms, total 29ms
E/ttt ( 4993): 66
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17653K/32583K, paused 25ms, total 25ms
E/ttt ( 4993): 64
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 25ms, total 25ms
E/ttt ( 4993): 64
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 26ms, total 26ms
E/ttt ( 4993): 66
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 37ms, total 37ms
E/ttt ( 4993): 83
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 37ms, total 38ms
E/ttt ( 4993): 68
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 25ms, total 26ms
E/ttt ( 4993): 53
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 25ms, total 26ms
E/ttt ( 4993): 62
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 27ms, total 27ms
E/ttt ( 4993): 67
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 27ms, total 27ms
E/ttt ( 4993): 67
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 26ms, total 26ms
E/ttt ( 4993): 66
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1501K, 46% free 17654K/32583K, paused 27ms, total 27ms
E/ttt ( 4993): 66
D/dalvikvm( 4993): GC_FOR_ALLOC freed 1500K, 46% free 17654K/32583K, paused 26ms, total 26ms
E/ttt ( 4993): 65
currently I am trying a way to load bitmap from JNI, like game engine did, not sure if this is the right way to do it.
While your app should run fine with those, I would say your best bet is to look into getting rid of them. Remember that this means your app is having to constantly free resources, which is time-consuming for your app (when it's running that much), and also bad from a memory management perspective. You can see a bit more about this here: https://stackoverflow.com/a/11312145/3342157 While you may not have any issues now, it could potentially cause major slowdowns later (if it isn't already).
As for how to get rid of them, remember that you should only have to reload the image if you are changing it. If you aren't, I would say to not reload it each frame. If you have several images it will swap between and can afford to use the memory (not sure on the image sizes), load them all at the beginning, and then hold on to them for rendering later. I see that you are specifically talking about animation, and my recommendation would be to create a sprite sheet to prevent having to load each individual PNG image.
in my simple app i am using 6 buttons and setting background with png.
Button btnGadgetmusic = (Button) findViewById(R.id.gadgetmusic);
btnGadgetmusic.setBackgroundResource(R.drawable.btnselectedsong);
minimum size of png is 13.5K and maximum size is 40K. When ever i try to run this app on emulator with version 2.3, i get "external allocation too large for this process" and interestningly if i run on honeycomb or on ICS then there is no problem.
So i am confused what should i do, should i ignore it, if not, do we have some better solution for that.
looking for your reply
EDIT Log File added
I/dalvikvm-heap(4190): Clamp target GC heap from 25.494MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed <1K, 51% free 2647K/5379K, external 18806K/20812K, paused 28ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed <1K, 51% free 2647K/5379K, external 18806K/20812K, paused 49ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.833MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 51% free 2647K/5379K, external 19153K/20812K, paused 25ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed <1K, 51% free 2657K/5379K, external 19153K/20812K, paused 56ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.852MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed <1K, 51% free 2657K/5379K, external 19162K/20812K, paused 24ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed 4K, 51% free 2671K/5379K, external 19162K/20812K, paused 69ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.887MB to 24.000MB
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 51% free 2671K/5379K, external 19184K/20812K, paused 28ms
W/KeyCharacterMap(4190): No keyboard for id 0
W/KeyCharacterMap(4190): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
W/KeyCharacterMap(4190): No keyboard for id 0
W/KeyCharacterMap(4190): Using default keymap: /system/usr/keychars/qwerty.kcm.bin
I/dalvikvm-heap(4190): Clamp target GC heap from 25.913MB to 24.000MB
D/dalvikvm(4190): GC_CONCURRENT freed 16K, 50% free 2697K/5379K, external 19184K/20812K, paused
3ms+35ms
I/dalvikvm-heap(4190): Clamp target GC heap from 25.942MB to 24.000MB
D/dalvikvm(4190): GC_CONCURRENT freed 13K, 50% free 2727K/5379K, external 19184K/20812K, paused 3ms+3ms
D/dalvikvm(4190): GC_EXTERNAL_ALLOC freed 2K, 50% free 2724K/5379K, external 19184K/20812K, paused 65ms
E/dalvikvm-heap(4190): 20736-byte external allocation too large for this process.
I/dalvikvm-heap(4190): Clamp target GC heap from 25.939MB to 24.000MB
E/GraphicsJNI(4190): VM won't let us allocate 20736 bytes
D/dalvikvm(4190): GC_FOR_MALLOC freed 0K, 50% free 2724K/5379K, external 19184K/20812K, paused 38ms
D/skia(4190): --- decoder->decode returned false
D/AndroidRuntime(4190): Shutting down VM
W/dalvikvm(4190): threadid=1: thread exiting with uncaught exception (group=0x40015560)
E/AndroidRuntime(4190): FATAL EXCEPTION: main
E/AndroidRuntime(4190): java.lang.OutOfMemoryError: bitmap size exceeds VM budget
Why does Android system always call garbage collection every time I make a request to web server to get images? Although I did every actions are asynchronous. Calling GC too many times make my app delays when scrolling or fling.
Update: I guess Android system always call GC when you do something request to web server. Here is the log when using the Android default browser. Each time you click on a link GC will be called automatically.
03-08 16:36:19.530: D/dalvikvm(341): GC_FOR_ALLOC freed 2124K, 31% free 10780K/15623K, paused 49ms
03-08 16:36:19.590: D/dalvikvm(341): GC_FOR_ALLOC freed 0K, 20% free 12635K/15623K, paused 49ms
03-08 16:36:19.700: D/dalvikvm(341): GC_CONCURRENT freed 1K, 20% free 12635K/15623K, paused 3ms+4ms
03-08 16:36:22.610: D/dalvikvm(20845): GC_CONCURRENT freed 735K, 10% free 9018K/9991K, paused 2ms+6ms
03-08 16:36:25.620: D/dalvikvm(20845): GC_CONCURRENT freed 1046K, 12% free 8954K/10119K, paused 4ms+3ms
03-08 16:36:27.880: D/dalvikvm(2781): GC_EXPLICIT freed 263K, 7% free 6373K/6791K, paused 2ms+2ms
03-08 16:36:28.950: D/dalvikvm(20845): GC_CONCURRENT freed 884K, 12% free 8946K/10119K, paused 3ms+3ms
03-08 16:36:29.760: D/dalvikvm(20845): GC_CONCURRENT freed 861K, 12% free 8949K/10119K, paused 3ms+3ms
03-08 16:36:31.390: D/dalvikvm(285): GC_EXPLICIT freed 1275K, 38% free 20843K/33223K, paused 17ms+8ms
03-08 16:36:31.510: D/dalvikvm(20845): GC_CONCURRENT freed 810K, 12% free 8946K/10119K, paused 3ms+5ms
03-08 16:36:38.100: D/dalvikvm(20845): GC_CONCURRENT freed 730K, 11% free 9027K/10119K, paused 3ms+6ms
03-08 16:36:40.920: D/dalvikvm(20845): GC_CONCURRENT freed 864K, 12% free 8989K/10119K, paused 2ms+5ms
03-08 16:36:45.780: D/dalvikvm(20845): GC_FOR_ALLOC freed 620K, 12% free 8909K/10119K, paused 41ms
03-08 16:36:48.250: D/dalvikvm(20845): GC_FOR_ALLOC freed 499K, 12% free 9002K/10119K, paused 45ms
03-08 16:36:48.570: D/dalvikvm(20845): GC_FOR_ALLOC freed 225K, 13% free 8899K/10119K, paused 28ms
03-08 16:36:50.670: D/dalvikvm(20845): GC_FOR_ALLOC freed 388K, 12% free 8915K/10119K, paused 34ms
03-08 16:36:52.550: D/dalvikvm(20845): GC_FOR_ALLOC freed 511K, 11% free 9008K/10119K, paused 44ms
03-08 16:36:53.780: D/dalvikvm(20845): GC_FOR_ALLOC freed 273K, 12% free 8909K/10119K, paused 42ms
03-08 16:37:05.070: D/dalvikvm(569): GC_EXPLICIT freed 376K, 12% free 6207K/6983K, paused 2ms+2ms
03-08 16:37:25.550: D/dalvikvm(2549): GC_CONCURRENT freed 337K, 9% free 7198K/7879K, paused 2ms+3ms
03-08 16:37:31.330: D/dalvikvm(2549): GC_EXPLICIT freed 54K, 10% free 7143K/7879K, paused 7ms+2ms
03-08 16:38:45.630: D/dalvikvm(2549): GC_EXPLICIT freed 268K, 10% free 7161K/7879K, paused 7ms+2ms
Android GC is automatic, opaque, non-deterministic. Which means you have nothing can do on it.
Traditionally, this type of GC works like this.
Wait until enough garbages are generated.
If GC engine thinks it's time, it stops your app.
Clear the garbages
Resume your app.
Of course, this sucks for end-use UI and graphics.
So Google added incremental collection. Essentially, this is just doing above procedure more frequently with less garbages. So pause time itself would be short but collection itself happens a lot more frequently.
As a conclusion, garbage collection happens randomly, but very frequently. So it would look happening always for any of operations.
Practically, there's no guaranteed way to avoid GC lag on typical GC systems.