tree 92e4ef0147cf4181c7c50560ac1cad3aeb3da08d
parent 714ba34556572d36b1f9f8d9b860c4da24da6361
author Dianne Hackborn <hackbod@google.com> 1383262364 -0700
committer Dianne Hackborn <hackbod@google.com> 1383262364 -0700

Fix issue #11168649: LRU logic for Chrome renderers seems...

...not to work on KitKat (was: Janky exit animation)

Reworking the LRU list (splitting it into an activity vs. empty
section) accidentally broken the old behavior of "client activity"
processes being prioritized with activity processes.  In fact, we
were no longer marking "client activity" processes at all.

In this change, we rework how we manage "client activity" processes
by putting them on the main activity LRU section.  This is generally
simple -- ActiveServices now keeps track of whether a process is
a "client activity" process based on its bindings, and updateLruProcess
treats these as regular activity processes.  However, we don't want
to allow processes doing this to spam our LRU list so that we lose
everything else, so there is some additional complexity in managing
that list where we spread client activity processes across is so
that the intermingle with other activity processes.

The rest of the change is fairly simple -- the old client activity
process management is gone, but that doesn't matter because it wasn't
actually running any more.  There is a new argument to updateLruProcess
to indicate a client process it comes from (since we now need to update
this based on bindings) which is just used to limit how high in the
LRU list we can move things.  The ProcessRecord.hasActivities field is
simply removied, because ProcessRecord.activities.size() > 0 means the
same thing, and that is actually what all of the key mechanisms are using
at this point.

Finally, note there is some commented out code of a new way to manage
the LRU movement.  This isn't in use, but something I would like to
move to in the next release so it is staying there for now for further
development.

Change-Id: Id8a21b4e32bb5aa9c8e7d443de4b658487cfbe18