Hi all,
Sometime ago, I wrote a post about a weird platform’s behavior that we faced during the porting of one of our applications. This tricky behavior costed us many efforts hours, since it was hard to figure out, because it was related to a specific implementation of that platform. I am here today to tell you, one more chapter of this incredible odyssey of porting mobile applications. This new story, one more time, reinforce that WORA does not work very well for Java mobile development.
We have an app, which has been ported to many devices and platforms (e.g. Android, S60, Windows Mobile, etc.) along the past months. During all those porting, some minor adjustments were often done to get this app up and running properly. So far, no big deal! However, during the porting to Windows Mobile 6.5, which is powered by Smertec Jbed CDC JVM, we experienced a case of an unexplainable out of memory error.
This same app runs very well on other devices with less memory and power processing than this one powered by Windows Mobile+Jbed. However, the resolution is huge higher (480x800). That was our first investigation point. As you must know, image is a memory hog. However, we had 16MB free. During five minutes test, the memory was already gone.
From this point, we started investigating other app’s components in order to find the memory leak: no success! We also implemented a test app that loaded some images to see how the device manages the memory usage. For an unexplainable reason, the JVM had 11MB available in Java heap. So why is an out of memory raised with all this free memory? The first reasonable answer was that this device has another memory area, which is shared with the device, and the JVM uses it to store the image objects, instead of Java heap. Even thought it seemed to be guilty by the problem, in the end, it did not explain why so much memory was consumed. Be prepared to know the real guilty!
As this app is fully-canvas, of course, we use Canvas to implement the user interfaces. In fact, GameCanvas. There are no mandatory requirements for us to use GameCanvas. We have used it, since there are more features available, which could be necessary in the future. However, this Jbed seems to have some personal issues with GameCanvas. One teammate wondered why GameCanvas? At that moment, he had no specific objective with that question. Just brainstorming. However, based on that, other teammate had an idea to replace GameCanvas to Canvas. Just to give it a shot. As we had no tight dependence with GameCanvas, it was quite easy and fast to get it replaced. Bingo! You have no idea: problem solved! The app ran very well and memory consumption was very low. Incredible result.
Now, tell me why? Why is GameCanvas so heavier than Canvas to crash the app so fast? I do not see any reasonable explanation for that. Just what I see is an implementation bug on Jbed regarding GameCanvas. I confess I have not worked much with Java ME for Windows Mobile, so I do have much knowledge on Jbed. So if you have some comments on Jbed and would like to share with us, please let us know.
Just what I know is that a challenge like this makes our job fun, though we expend much time to solve it. Write once, port forever. :)
See you in the next post...
No comments:
Post a Comment