Android P Basic lifecycle transaction containers改动--设计模式体现之策略模式

整理Activity启动流程时发现，Android P代码在android/app作了很大的改动。如果您对Activity启动还未了解，建议您看这篇文章。针对这次改动，Google官方给出的解释如下：

This adds basic containers for holding some messages to a client,
that are related to activity lifecycle. Each transaction can hold
a list of callbacks and a final lifecycle state.
    
Some requests from ActivityManager to client that target activities
are now switched to use transactions. Scheduling, preparing and
executing a request is moved outside of ActivityThread class to
corresponding transaction items.

Android P之前，当我们需要启动一个Activity时，最终从AMS中是调用：

app.thread.scheduleLaunchActivity(new Intent(r.intent), r.appToken,
           System.identityHashCode(r), r.info,
           mergedConfiguration.getGlobalConfiguration(),
           mergedConfiguration.getOverrideConfiguration(), r.compat,
           r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
           r.persistentState, results, newIntents, !andResume,
           mService.isNextTransitionForward(), profilerInfo);

现在，我们执行如下代码：

// Create activity launch transaction.
final ClientTransaction clientTransaction = ClientTransaction.obtain(app.thread,
        r.appToken);
clientTransaction.addCallback(LaunchActivityItem.obtain(new Intent(r.intent),
        System.identityHashCode(r), r.info,
        // TODO: Have this take the merged configuration instead of separate global
        // and override configs.
        mergedConfiguration.getGlobalConfiguration(),
        mergedConfiguration.getOverrideConfiguration(), r.compat,
        r.launchedFromPackage, task.voiceInteractor, app.repProcState, r.icicle,
        r.persistentState, results, newIntents, mService.isNextTransitionForward(),
        profilerInfo));

// Set desired final state.
final ActivityLifecycleItem lifecycleItem;
if (andResume) {
    lifecycleItem = ResumeActivityItem.obtain(mService.isNextTransitionForward());
} else {
    lifecycleItem = PauseActivityItem.obtain();
}
clientTransaction.setLifecycleStateRequest(lifecycleItem);

// Schedule transaction.
mService.getLifecycleManager().scheduleTransaction(clientTransaction);

虽然代码多了，但是流程上更加清晰，执行的操作也相当清楚。整体上优化了ActivityThread的代码，使得ActivityThread更加简洁。
这是关于Activity启动时，Activity生命周期操作相关类的结构图：（如果您还不明白类与类之间的关系，建议您查看这篇文章）

从类图中可以看出，Android P新增的优化代码，使用了设计模式中的策略模式。策略模式一般由三部分组成：抽象策略角色，策略类（通常由一个接口或者抽象类实现），策略角色具体实现（策略的算法行为），策略执行者。ClientTransactionItem和ActivityLifecycleItem都是抽象策略，ResumeActivityItem等都是策略具体实现，ClientTransaction就是策略执行者。使用策略模式还是有优缺点的，优点：1、 策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码转移到父类里面，从而避免重复的代码。2、 策略模式提供了可以替换继承关系的办法。继承可以处理多种算法或行为。如果不是用策略模式，那么使用算法或行为的环境类就可能会有一些子类，每一个子类提供一个不同的算法或行为。但是，这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起，从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。3、 使用策略模式可以避免使用多重条件转移语句。多重转移语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重转移语句里面，比使用继承的办法还要原始和落后。缺点：1、客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。2、 策略模式造成很多的策略类，每个具体策略类都会产生一个新类。有时候可以通过把依赖于环境的状态保存到客户端里面，而将策略类设计成可共享的，这样策略类实例可以被不同客户端使用。换言之，可以使用享元模式来减少对象的数量（当然新增代码也通过对象Pool尽量避免这一缺点）。优缺点部分参考百度百科。