Today when passing --enable-heap-profiler we turn on three heap trackers (one for malloc, one for part alloc, one for oilpan). See [1] for more. these heap tracker only care about the outstanding allocations (the one not freed).
They could very easily also count the churn and expose it via a counter track (see TRACE_COUNTER).
The final effect would be having a visual indication of heap traffic over time.

Siggi's is doing some related work in https://codereview.chromium.org/2386123003/.
His work is more generic as it allows to capture heap traffic on an arbitrary scope.
Right now his only use case is exposing this data on the chrome://profiler (which is not there on ANdroid).

I need to think a bit more, but I think there should be a way to use siggi's scoped tracker in our heap trackers and dump the stats every now and then.
The major things that require a decision are:

1) siggi's scoped heap stats are per-thread (for a good reason). When it comes to tracing, though, do we want to expose 3 tracks (the 3 heaps) per each thread? That might cause quite some visual clutter (maybe we can overlap the 3 charts into one track and have one track per thread).

2) when should we dump samples of the heap traffic in tracing?
  Option A: at the same points when we do memory dumps (O(seconds)). this is easy but might be too coarse to get actionable data.
  Option B: do something similar to what he's doing in his cl when attaching data to the chrome://profiler and piggy back on the TaskAnnotator, so we'd get a sample per task: this might slow down things and spam the trace too much.
 Option C: some kinds of b + throttling.


[1] https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/heap_profiler_internals.md