mRemovedViewsCache is an array that holds views according to position

[VincentKetelaars]

I have changed the mRemovedViewsCache such that it doesn't list views according to its type, but according to the position these views have in the adapter. In this manner the adapter will be provided with the same view, when it is requested from the cache. In the previous arrangement the lifo order of returning views has issues when views of the same type have not yet been created.
The array is resized on every onChanged.

[bdonahue]

This will result in a substantial amount of cache misses. All new items will always be a cache miss. The point of the cache is to provide ready to use views from the cache as the user scrolls down. This change no longer does that, what this does is only cache views that have already been seen.

This has two major issues.

1. The cache grows linearly as the user scrolls which will lead to eventual Out of Memory error and performance degradation

2. The cache doesn't work. The point of the cache it to avoid view inflation as that is very slow and caused lots of jank when done on the UI thread. The existing cache once full provided a very low miss rate and thus prevented inflation and view.findbyid which is also very slow. This configuration has a 100% miss rate on future items in the list thus scrolling down will cause significant jank.

[VincentKetelaars]

When writing this I was not keeping in mind the inflation part, which I admit is an important consideration. Since the list will usually be rather small, I doubt that the memory strain is significant, but it does not scale like the current implementation, true enough.