Thanks for the reply - sorry for the delay (apparently I wasn't subscribed
to this thread).
I'm not familiar with the practices necessary to analyze memory usage at
this point, but I'll look into it.
For reference, the widget is a scaling tiled layer, similar to iOS
CATiledLayer, which allows the user to use arbitrarily sized tiles,
scales, etc - also a previous tile set needs to stay displayed until the
new one is rendered. So generally there are only maybe 4-16 tiles (Views)
being displayed, but for a moment, at a small scale, with a previous set in
place (before that set is destroyed), there could be as many as 60-70
views. The views themselves are just ImageViews, so nothing special about
instantiation. I'm not familiar enough with the platform to know if the
memory used by having references to those views (pooled, for recycling)
outweigh the benefit gained in not having to repeatedly re-instantiate.
On Tuesday, March 5, 2013 1:50:10 AM UTC-6, Piren wrote:
>
> Your best bet is to just analyze your app memory and processing wise...
> see how long it takes you to initialize a view and how much memory they all
> use.. then find a proper balance between the two that makes sure your app
> is both responsive and without a risk of memory issues.
>
> My guess - unless initializing your views is something very complicated
> that takes a while (which might mean you'll need to redesign them since
> they might not be done the best), re-using will be the proper way to go.
>
> On Tuesday, March 5, 2013 6:57:24 AM UTC+2, momo wrote:
>>
>> I have a widget that potentially uses many Views. In looking at the
>> source for other view-intensive widgets (like ListView), I understand that
>> it's a fairly computationally expensive process to instantiate Views. I
>> see they're recycling children - creating them on demand, then caching
>> them, and re-using them with updated properties when one is required.
>>
>> My concern is that in my case (with so many potential Views) that the
>> cost of keeping references to them in memory might be worse than the cost
>> of instantiating them. I'm tracking the total number of Views in the cache
>> and see it reach as much as 60-70 at times.
>>
>> The requirement is such that I can't reduce the number of Views used.
>>
>> When the number is as high as I've mentioned, is caching and recycling
>> Views still a "better" prospect than new instantiation on-demand? I
>> believe that if I did not cache, the unused Views would be
>> garbage-collected properly (there shouldn't be any references that I'm not
>> catching).
>>
>> TYIA.
>>
>
--
--
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.
