I noticed today that the PagerAdapter gets called a large amount times. I counted 393 when scrolling pages slowly. I saw this question but it didn't really provide me with a good answer.
Is this normal behaviour
If so, why is it that the getCount method is called so often?
Just to be clear, I am looking for a more extensive answer then the one in the provided question.
I do also realize that I need to keep it as fast and that I have no control over how it is called, but that is not the question here.
As you concluded it is used a lot in onTouchEvent. OnTouchEvent is called whenever you interact with the screen, meaning touch move and release events. Moving just one pixel would result in a potential call to this method.
There is not much more to explain, it is just the way it is implemented. Usually adapter.getCount is implemented with something like List.getSize or Cursor.getCount. And has almost zero overhead. If this is a problem, optimize you ListAdapter.getCount method, cache the count or something like that. Only do complex stuff in there when needed and cache the result until it becomes invalid.
Related
I'm trying to prevent my ViewPager's PagerAdapter from destroying Views it already loaded once.
If I understood it correctly, the method ViewPager.setOffscreenPageLimit(1) will create and cache a page on each side of the selected view.
This is okay for me, except for the part that if I for example jump to page 5, pages 4 and 5 will be created and cached, but pages 0 and 1 will be destroyed.
I've tried commenting out everything in my pager's destroyItem() method, and caching in a HashMap the views created in instantiateItem(), and returning them as-is if they are found on the HashMap.
This seems to be working OK, but I'm not sure if there are any downsides to doing that this way, apart from the higher memory usage, which is hopefully not a problem here.
My app is actually an application framework and I'm going to leave that decision to the final developer, leaving ViewPager's default behavior in case he/she doesn't want to apply this caching behaviour. Some clients are pretty unreasonable and they have a huge number of views in everypage. I've tried to convince them to work their way around in different pages since Android's View creation is costly, but as I said, they're unreasonable.
Do you guys know of any good way to do this?
I am trying to implement my own Android view recycling. My question is, is there a simple way to "reset" an Android View object (more specifically, a FrameLayout) to the state in which it would come out of a constructor. In other words, it knows about its context, but it's forgotten about things like calls to SetWillNotDraw, touch handlers, visibility, or anything else I may have set on it.
The alternative would be to write my own "reset" method. I'm concerned that if I go that route, I will end up with bugs relating to failing to reset some portion of the state.
No, there isn't. If you weren't trying to do recycling I'd suggest just creating a new one is the easiest way to ensure it. Its also not a very efficient thing to do in general- there's a lot of pieces of state that can be changed, if you try to set all of them you'll end up wasting a lot of cycles. Generally you have the code that sets these things have a reset method of some sort called when you unbind a view from its model, and it will clear the subset of things it changed.
With a complex adapter, GridViews and ListViews can sometimes take a long time to populate after calling the setAdapter() method. Is there a method we can override that is triggered when the view has been successfully populated with data and is ready to be shown?
My feeling is that it isn't the setAdapter() that takes a long time, but rather that the complex adapter is doing something complex. The ListView and GridViews are specified to work rather quickly, but there's a few reasons they might be slower. Here's a few thoughts as to how to work this one out.
Figure out what's taking so long. Network calls, large database queries, and loading large files (Bitmaps in particular) are often the guilty party. If you don't have any of those, try profiling your code, and see what you can gleam from that.
Once you've figured out the culprit, see what you can do to decrease the amount of time. Perhaps shrinking the size of a bitmap, or using a better database query would work.
If you can't shrink the time down any more, then do the complex task in an AsyncTask. This will do the complex part of your code in the background, and only show the result when it is complete. This works well for things like network calls, loading bitmaps, etc.
I have a ListView with custom Adapter. To be honest, I have many of them at the same time on screen, and my Tegra 3 device started to lag, what made me really confused... I found than in each ListView's Adapter the getView() method is called for all visible rows every time any animations runs on screen. That gives me like few hundreds of calls per second! Digging more, most of these calls are due to measure() and onMeasure() calls of ListViews' parents, and - this is tke key - they are useless, because all the layouts of my ListViews
have const size.
So my question is: how to eliminate these calls? Of course I want to leave proper calls alone (caused by adding items to Adapter and notifyDataSetChanged() ).
I've tried almost anything, but either the whole list doesn't draw itself (when I overriden it's onMeasure() and forced to returned const size without calling super.onMeasure()) or stops updating at some time.
How you implemented the getView() method? If you implement it in the correct way there should be nearly no lagging.
Check out this really really good video:
http://www.youtube.com/watch?v=wDBM6wVEO70
Slides: http://dl.google.com/googleio/2010/android-world-of-listview-android.pdf
As Romain said, work with it not against it. Best is to leave measure() alone and focus on your adapter.
Thats how ListView is implemented.. I don't think that will cause a performance Overhead.. Provided you do things properly there..
For example..
Don't instanciate LayoutInflator inside GetView Method, Do it at class level..
And Inflate View Only if the convertView==null or else just return convertView.. Inflating view is a costly process....
Well like you said these calls are due to measure() and onMeasure() calls of ListViews parents and I'm sure you are using height=wrap_content also with wrap_content on height your ListView will check without stop if your height has changed.
So the solution is to put the height=fill_parent.
I hope this helped you.
The underlying reason for this is that ListView.onMeasure() calls AbsListView.obtainView(), which will request a view from your list adapter. So if your view is being remeasured through animations, your performance will be very poor.
I have seen this question asked by "vbjain", but answer that are given are not satisfactory for me.
I am also facing same problem, I have a huge list where i need to do extensive calculation in getView() which are unavoidable, my list contains live data which gets generated at the time of displaying list, so i can't avoid these calculation other than doing them in getView function.
I don't know why getView method is getting called when i am switching focus from/to list view, cause of getView is getting called at the time of changing the focus and i am doing calculations in getView my application gets stuck for 2-3 seconds and then it switches focus from/to list view.
Is there any way by which we can avoid this behavior of list view.
Thanks.
The list view behaves the way it does largely for performance reasons, I can't recommend this video enough for people working with list views, Romain Guy explains everything clearly and concisely. If you want your list view to perform, follow his advice.