Optimize Fragment operations so that minimal work is done.

Bug 29631389

When multiple operations are executed at once, they sometimes
cancel each other. For example, if the following transactions
are queued:

Transaction 1: add A
Transaction 2: replace with B

This can be trimmed down to add B.

This CL optimizes fragments in both add and pop directions.

Developers can choose not to allow optimization by
using FragmentTransaction#setAllowOptimization

Test: If6637e9f1c2a414bebaff6404efc45dd828378ad

Change-Id: Iab75be3e0aa388fc79b794e647ac6893165bebd7

1 files changed, 26 insertions, 0 deletions

diff --git a/core/java/android/app/FragmentTransaction.java b/core/java/android/app/FragmentTransaction.java
index 633e85b78118..25a7839fa1ed 100644
--- a/core/java/android/app/FragmentTransaction.java
+++ b/core/java/android/app/FragmentTransaction.java
@@ -260,6 +260,32 @@ public abstract class FragmentTransaction {
     public abstract FragmentTransaction setBreadCrumbShortTitle(CharSequence text);
 
     /**
+     * Sets whether or not to allow optimizing operations within and across
+     * transactions. Optimizing fragment transaction's operations can eliminate
+     * operations that cancel. For example, if two transactions are executed
+     * together, one that adds a fragment A and the next replaces it with fragment B,
+     * the operations will cancel and only fragment B will be added. That means that
+     * fragment A may not go through the creation/destruction lifecycle.
+     * <p>
+     * The side effect of optimization is that fragments may have state changes
+     * out of the expected order. For example, one transaction adds fragment A,
+     * a second adds fragment B, then a third removes fragment A. Without optimization,
+     * fragment B could expect that while it is being created, fragment A will also
+     * exist because fragment A will be removed after fragment B was added.
+     * With optimization, fragment B cannot expect fragment A to exist when
+     * it has been created because fragment A's add/remove will be optimized out.
+     * <p>
+     * The default is {@code false} for applications targeting version
+     * versions prior to O and {@code true} for applications targeting O and
+     * later.
+     *
+     * @param allowOptimization {@code true} to enable optimizing operations
+     *                          or {@code false} to disable optimizing
+     *                          operations on this transaction.
+     */
+    public abstract FragmentTransaction setAllowOptimization(boolean allowOptimization);
+
+    /**
      * Schedules a commit of this transaction.  The commit does
      * not happen immediately; it will be scheduled as work on the main thread
      * to be done the next time that thread is ready.