It is buried in the View class... I used the grep tool on the git site to find it...
http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/view/View.java#l7883 On Jul 18, 4:38 am, "Fred Grott(shareme)" <[email protected]> wrote: > Romain, was it renamed cannot find it by your link.. > > On Jul 15, 3:55 pm, Romain Guy <[email protected]> wrote: > > > > > We have an efficient implementation for you: use thePools.java file > > fromhttp://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;... > > (and the associated classes.) These are not public APIs so just copy > > the code in your application. > > > Here's an example of a Poolable object with this API: > > static class InvalidateInfo implements Poolable<InvalidateInfo> { > > private static final int POOL_LIMIT = 10; > > private static final Pool<InvalidateInfo> sPool > > =Pools.synchronizedPool( > > Pools.finitePool(new PoolableManager<InvalidateInfo>() { > > public InvalidateInfo newInstance() { > > return new InvalidateInfo(); > > } > > > public void onAcquired(InvalidateInfo element) { > > } > > > public void onReleased(InvalidateInfo element) { > > } > > }, POOL_LIMIT) > > ); > > > private InvalidateInfo mNext; > > > public void setNextPoolable(InvalidateInfo element) { > > mNext = element; > > } > > > public InvalidateInfo getNextPoolable() { > > return mNext; > > } > > > static InvalidateInfo acquire() { > > return sPool.acquire(); > > } > > > void release() { > > sPool.release(this); > > } > > } > > > On Wed, Jul 15, 2009 at 1:48 PM, Brad Larson<[email protected]> wrote: > > > > At Google I/O and in the forums, it has been clear that if you need > > > optimal performance, you must avoid memory allocation inside tight > > > loops. I'm curious about the best way to handle this in my use-case, > > > which I think must be fairly common. I need to access at most n > > > objects of type MyObject, I need to iterate over them during every > > > screen refresh, and I need to remove them and put them back in the > > > object pool randomly. > > > > The object pool seems pretty straight-forward, just use a > > > Vector<MyObject>(n), add n copies of MyObject at bootup, and add/ > > > remove from the end to avoid any memcpy or allocation. > > > > The iterating is a little more difficult. I can use for(MyObject m : > > > myObjects), but this will allocate memory to create the iterator. I > > > could create a static final Iterator at bootup, but there is no good > > > way to get back to the start of the List. For now, I'm using another > > > Vector for active MyObjects, and a for loop with an int to get() the > > > objects and avoid allocating an iterator. get() runs in constant time > > > for a Vector, so this works well. > > > > However, when an object is done, I need to remove it and send it back > > > to the pool. If I use Vector.remove(i), it has to memcpy everything > > > after i. I could use an Iterator on a LinkedList, which can remove() > > > in constant time, but I don't think there is a good way to get the > > > Iterator back to the start of the list without allocating memory. I > > > could use an int to loop through a LinkedList, but LinkedList.get(n) > > > runs in O(n) time. > > > > Any tips on the optimal way to solve this? Worst-case, I assume the > > > memcpy called during Vector.remove() is a better bet over allocating > > > an Iterator inside my app loop, correct? > > > > Thanks! > > > Brad > > > -- > > Romain Guy > > Android framework engineer > > [email protected] > > > Note: please don't send private questions to me, as I don't have time > > to provide private support. All such questions should be posted on > > public forums, where I and others can see and answer them --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
