Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 315 Plugins
- 70 User experience
- 75 Marketplace
- 290 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
In this Discussion
ANRs on Android platform
simwhi
Member
Hi everyone,
I read the following article regarding the most common issues with Android apps:
https://medium.com/googleplaydev/how-to-fix-app-quality-issues-with-android-vitals-and-improve-perfo
In particular, I found the following interesting:
What are the common reasons for ANRs?
Executing disk or network I/O on the main thread. This is by far the most common cause of ANRs. While most developers agree that you shouldn’t read or write data to disk or network on the main thread, sometimes we’re all tempted to do it. Reading a few bytes from disk will probably not cause an ANR under ideal conditions, but it’s never a good idea. What if the user has a device with slow flash memory? What if their device is under extreme pressure from other apps that are simultaneously reading and writing, while your app waits in the queue to perform your “fast” read operation? Never perform I/O on the main thread.
How is file saving / loading done under the hood in Gideros. We design educational apps / game so this is important to us as we have to save a fair amount of data.
I read the following article regarding the most common issues with Android apps:
https://medium.com/googleplaydev/how-to-fix-app-quality-issues-with-android-vitals-and-improve-perfo
In particular, I found the following interesting:
What are the common reasons for ANRs?
Executing disk or network I/O on the main thread. This is by far the most common cause of ANRs. While most developers agree that you shouldn’t read or write data to disk or network on the main thread, sometimes we’re all tempted to do it. Reading a few bytes from disk will probably not cause an ANR under ideal conditions, but it’s never a good idea. What if the user has a device with slow flash memory? What if their device is under extreme pressure from other apps that are simultaneously reading and writing, while your app waits in the queue to perform your “fast” read operation? Never perform I/O on the main thread.
How is file saving / loading done under the hood in Gideros. We design educational apps / game so this is important to us as we have to save a fair amount of data.
Likes: totebo
Tagged:
+1 -1 (+1 / -0 )Share on Facebook
Comments
In all my games I've had issues with data disappearing or becoming corrupt, meaning the player loses all of their progress. This appears to only happen on Android (I see the issue angrily reported in one star reviews) and doesn't affect a large percent of players.
Maybe it could be related to the I/O running on the main thread? If so, should I run all saving and loading as an Async call?
I rethought and split the large structure into a bunch of smaller ones. Each character was saved as a separate file, the shared stash was one file, and the game state also got its own file. My structures were not overly large but I began compressing the files with zlib before saving and then uncompressing them on loading again. As an anti cheating method I encrypted the data before compression as well.
For each file to be saved I encoded the table into a JSON string, encrypted the JSON string using Gideros encryption library, compressed the encrypted string with zlib, and finally wrote the file to device. This worked amazingly fast,
From my learning I am now always trying to keep relevant data together and not to make my data structures too large. also bear in mind that in a lot of cases you won't need to save every structure to the device, just ones that have been modified.
If you are saving a bunch of files then make a little class that displays the name of the file being saved just before saving it. This gives the user an indication of what is going on and because you are saving a bunch of files but each saves quickly.. you can avoid ANR issues.
Hope that goes a little way to help. Just squeak if you didn't get it or have other questions
Likes: Apollo14, SinisterSoft
@antix I think I'm going to implement something similar to your approach. We already split saves across files.
Many thanks for your comments and ideas.
Likes: simwhi
https://deluxepixel.com
Likes: Apollo14, SinisterSoft, totebo, simwhi