A lot of perf tricks we use on Android are really workarounds for issues in Dalvik. ART (the runtime in Android 5+) has very different perf characteristics. I think the trick that's most likely to be affected is object pooling. Here's why:
Dalvik's allocator is surprisingly outdated. It is not designed for multicore systems. There's a single global lock for allocations and deallocations. This means that allocations are ridiculously expensive compared to ART, which has thread-local allocation. So avoiding allocations by object pooling can be a big win.
On ART, though, POJO allocations are super cheap. ART actually uses fixed-size object pools under the hood, and because they use C++ tricks that aren't available in Java (like inferring the pool from the address of the object), the cost is comparable to the cost of managing an object pool in Java. Based on code analysis, I expect allocations to be slightly slower and deallocations to be slightly faster than a good Java object pool implementation.
That's not the whole story, though. ART also has a significantly more sophisticated generational collection model. Objects with short lifetimes are incredibly cheap to collect. But because of the way ART does concurrent collection, arrays of references can be kind of expensive. The cost is roughly proportional to the amount of churn in the array, so an object pool that sees heavy use is actually more expensive than a set of short-lived allocations.
All of which means that on ART, pooling is not an automatic win. Instead, the rules for pooling become pretty much the same as any other runtime: pool objects that are either (a) expensive to create, or (b) expensive to destroy.
As I mention in APP season 2 episod 10, Paint and Paint-related objects satisfy both of those conditions. But most POJOs don't.