> > How much is too much? Obviously i don't have an answer for that... but if the device freezes and you could pinpoint the issue to these requests, it's safe to say that you've gone over the limit for that device :)
> What drive isn't flash? I'm assuming that app internal storage (I don't > use), external storage, and removable external storage are all flash. Meant the internal drive of course. Unless you pushed the DB to the SDCard, it uses the internal storage btw, any either way DB access is I/O. By System blocking i meant that all drive access eventually is on a queue ... (not that it blocks the entire system thread wise). So hammering the DB with requests is a nice way to make the entire device unresponsive. I've never actually checked if keeping the DB open will load it to memory, but if you know you have lots of DB access, it's a good idea to cache it in memory anyway. I'd start by lowering the I/O done by onScroll (just for testing) and see if it has an effect on the device. On Tuesday, May 14, 2013 9:52:03 PM UTC+3, Nathan wrote: > > > On Tuesday, May 14, 2013 1:09:37 AM UTC-7, Piren wrote: >> >> onScroll is called very frequently, much much more frequent than binding >> calls... >> > does the loading mechanism knows how to deal with that? >> > > Yes. The offscreen bitmap is moved while scroll is in progress. Only after > finger is lifted is the redraw of the offscreen bitmap started, if the > screen has moved enough. > > >> how frequent are the IO calls? >> > > There might be a retrieval of 25 or so small files after the scroll, or > the same number of database binary reads. Enough to cover the screen. > > That may not be as precise as you want. > > Making too much I/O is never a good thing >> > How much is too much? > > (including accessing the flash drive... >> > What drive isn't flash? I'm assuming that app internal storage (I don't > use), external storage, and removable external storage are all flash. > > these are system blocking) >> > > This could be a clue. What do you mean by system blocking? Does this mean > that all threads in all JVM's come to a halt while reading a block from > storage? Or just that if multiple threads are trying to read from the > storage, only one gets through at once? > > Certainly there could be some correlation between "system blocking" and > complete freeze of the system, particularly if the Droid Razr HD does > something special with File I/O. > > Based on some logs I have gotten, normal java.io.File operations appear to > be routed through the media provider on the Droid Razr HD, which I do not > call explicitly. > > Nathan > -- -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
