用户对于视觉体验和操作效率的要求早Yi今非昔比。你是否也曾好奇，为什么当你把那台昂贵的折叠屏手机展开时系统设置界面Neng瞬间从“手机模式”无缝切换到“平板模式”，甚至还Neng左右分屏，一边kan着网络列表，一边配对蓝牙设备？这背后其实隐藏着一项名为 Activity 嵌入 的黑科技。今天我们就来扒一扒这项技术的底裤，kankan它到底是如何在系统设置中施展魔法的。

想象一下你手里拿着一款当下备受追捧的可折叠设备。当它合上的时候，它就是一个普通的智Neng手机，所有的设置页面dou像叠罗汉一样，一层压着一层，这是我们熟悉的堆叠模式。但是一旦你将它展开，奇迹发生了：原本挤在一起的设置页面突然学会了“分身术”，主列表在左边，详细选项在右边，井水不犯河水，却又相得益彰。

这就是 Activity 嵌入带来的直观体验。它并不是简单的页面拉伸，而是将应用的一个任务窗口巧妙地拆分，让两个不同的 Activity，甚至是同一个 Activity 的两个实例，Neng够在同一个屏幕上并排表演。这就像是把一个大任务拆解成了几个小任务，各自在不同的“小舞台”上同时进行，极大地提升了大屏设备上的信息展示效率和操作便捷性。比如在设置网络和蓝牙时用户完全Ke以在同一视野内完成连接和配对，这种“左右逢源”的感觉，一旦用过就回不去了。

想要在自家应用里实现这种酷炫的效果， 得把地基打好。在 Android 的开发世界里这通常意味着要在构建脚本中引入正确的依赖库。对于系统设置这种级别的应用，我们通常会在 settings 目录下的 Android.bp 文件中进行操作。

这就好比盖房子前得先准备好砖块和水泥，而 androidx.window_window 这个库，就是我们实现 Activity 嵌入不可或缺的核心材料。我们需要在 Android.bp 文件中，将这个库添加到 static_libs 配置项中。虽然这只是一行简单的配置，但它却为后续所有的分屏逻辑奠定了坚实的基础，就像房子的地基，虽然埋在地下kan不见，却决定了整栋楼的高度。

android_library {
    name: "Settings-core",
    //lib的名字
    //..
    static_libs: 
}
android_app {
    name: "Settings",
    //..
    static_libs: , //引用上述lib
}

材料准备好了接下来就是搭建“指挥中心”。在自定义的 Application 类中，我们需要启动分屏规则的初始化流程。这通常是在 SettingsApplication 类的 onCreate 方法中完成的。

我们Ke以把 SettingsApplication kan作是一个运筹帷幄的指挥官。当应用启动时它第一时间Zuo的不是别的事，而是创建一个 ActivityEmbeddingRulesController 实例，并命令它去执行 initRules 方法，开启分屏规则的“旅程”。这段代码逻辑非常清晰，就像军队出征前的点将一样，必须确保核心指挥系统率先运转起来。

public class SettingsApplication extends Application {
    @Override
    public void onCreate {
        super.onCreate;
        final ActivityEmbeddingRulesController controller = new ActivityEmbeddingRulesController;
        controller.initRules;
    }
}

而 ActivityEmbeddingRulesController 这个类，则是具体的执行者。在它的构造函数中，它会获取上下文环境以及Zui关键的 RuleController 实例。这就像是找到了自己的“Zui佳拍档”，两者联手，共同负责后续所有分屏规则的制定与下发。

public ActivityEmbeddingRulesController {
    mContext = context;
    mRuleController = RuleController.getInstance;
}

在正式开始布置分屏之前，我们还有一件极其重要的事情要Zuo，那就是“侦察敌情”——判断当前设备环境是否真的支持分屏。这就像出门前一定要kankan天气预报，Ru果下大雨，你肯定不会穿凉鞋出门。

代码中通常会有一个类似 isEmbeddingActivityEnabled 的方法。这个方法会Zuo两件事：它会去检查配置文件中的功Neng开关是否打开，这就像是确认家里的总闸是否合上；它会调用 SplitController 来询问系统内核：“嘿，你支持分屏吗？”只有当这两个条件dou为真时我们才会放心大胆地进行后续的分屏操作。否则，强行在不支持分屏的旧版本系统上搞这些花里胡哨的东西，只会导致应用崩溃，那可就得不偿失了。

public static boolean isEmbeddingActivityEnabled {
    //这个是配置里的设定
    final boolean isFlagEnabled = FeatureFlagUtils.isEnabled;
    //这个是判断系统是否支持分屏
    final boolean isSplitSupported = SplitController.getInstance.isSplitSupported;
    return isFlagEnabled && isSplitSupported;
}

万事俱备，只欠东风。现在我们要开始制定具体的分屏规则了。其中Zui关键的一环，就是设置主页的占位 Activity。你Ke以把它想象成是在大屏幕右侧预先留好的一张“VIP门票”，默认情况下这张门票对应的座位是留给网络设置页面的。

我们通过 registerHomepagePlaceholderRule 方法来实现这一点。我们需要准备一个“篮子”——也就是一个 HashSet，用来装那些需要设置占位 Activity 的主屏类，比如 SettingsHomepageActivity 和 Settings。

final Set activityFilters = new HashSet<>;
addActivityFilter;
addActivityFilter;

接着，我们要创建一个 Intent，明确指定这个占位位置到底要显示谁。在系统设置的代码里通常会将它指向 Settings.NetworkDashboardActivity.class，也就是网络仪表盘页面。同时我们还Ke以通过 putExtra 传递一些额外参数，告诉系统这是一个二级页面。

final Intent intent = new Intent;
intent.putExtra;

有了过滤器和意图，接下来就是构建具体的规则了。我们需要使用 SplitPlaceholderRule.Builder 来像搭积木一样组装规则。这里面有hen多细节Ke以调整，比如分屏的Zui小宽度、Zui小高度、纵横比限制等等。特别是 setDefaultSplitAttributes，它允许我们定义分屏的比例，比如是三七开，还是五五分。这就像是在装修房子时决定家具怎么摆放，怎么摆放Zui舒服，全kan开发者的设计。

SplitAttributes attributes = new SplitAttributes.Builder
      .setSplitType))//
      .build;
final SplitPlaceholderRule placeholderRule = new SplitPlaceholderRule.Builder
      .setMinWidthDp)
      .setMinSmallestWidthDp)
      .setMaxAspectRatioInPortrait
      .setSticky
      .setFinishPrimaryWithPlaceholder
      .setDefaultSplitAttributes
      .build;
mRuleController.addRule;

当然并不是所有页面dou适合分屏。有些页面比如搜索页，可Neng需要独占整个屏幕才Neng展示足够多的内容。这时候，我们就需要用到 registerAlwaysExpandRule 方法。

逻辑大同小异，也是先创建一个 ActivityFilter 集合，把需要全屏的页面装进去。然后通过代码判断是否满足全屏的条件。Ru果配置里开启了“搜索页始终全屏”的开关，那我们就把这个规则告诉控制器，让系统在展示这些页面时不要搞分屏，直接给个Zui大的舞台。

if ) {
    //搜索页
}

虽然 Activity 嵌入听起来hen美好，但在实际开发过程中，我们难免会遇到各种“水土不服”的情况。毕竟Android 碎片化的问题由来Yi久，不同的设备和系统版本对这项新特性的支持程度千差万别。

这就好比你想给一间老房子安装Zui新的智Neng安防系统，结果发现老房子的电路根本带不动。某些旧版本的系统可Neng根本不支持分屏特性，Ru果强行调用相关 API，应用大概率会闪退。为了解决这个问题，我们必须在代码中Zuo好版本检查和兼容性处理。对于不支持分屏的旧系统，我们要学会妥协，直接隐藏分屏功Neng，让应用以传统的堆叠方式运行。这虽然牺牲了一部分体验，但至少保证了稳定性，就像给老房子装个普通的门锁，虽然不智Neng，但安全。

此外页面显示异常也是常见的坑。比如分屏后布局错乱、元素重叠，或者是在横竖屏切换时页面闪烁。这些问题往往是因为布局文件属性设置不当，或者生命周期处理逻辑有漏洞。解决这些问题需要极大的耐心，就像是在修复一件精密的瓷器，必须仔细检查每一个 dp 值，确保每一个 View dou在它该在的位置上。

说了这么多技术细节，我们不妨回过头来kankan，费这么大劲引入 Activity 嵌入，到底值不值？答案是肯定的。

从用户的角度来kan，这种改变是颠覆性的。某知名品牌的平板电脑在系统设置中采用了这项技术后用户反馈设置速度比以前快了近 30%，操作流畅度也大幅提升。用户Ke以在左侧点击“显示”，右侧立马就Neng调节亮度，这种所见即所得的效率，是传统单窗口模式无法比拟的。

从开发者的角度来kan，虽然前期需要增加一些配置工作，编写一些规则代码，但整体上并不需要对现有业务逻辑进行大规模重构。这就像是给旧房子进行了一次精装修，虽然刷墙铺地hen累，但房子焕然一新后的价值提升是显而易见的。而且，随着折叠屏设备的普及，Neng够完美适配大屏的应用，无疑将在未来的市场竞争中占据geng有利的位置。

总而言之，Activity 嵌入技术不仅是 Android 系统掌握并运用好这样的“秘密武器”，或许就是我们脱颖而出的关键。