1. 为什么你需要 FragmentContainerView 与 Navigation 的深度整合如果你正在开发一个现代化的 Android 应用特别是那种采用“单 Activity 多 Fragment”架构的应用那你肯定绕不开两个东西FragmentContainerView和Jetpack Navigation。你可能已经分别用过它们但有没有想过把它们俩“拧”在一起深度整合能爆发出多大的能量我刚开始用的时候也是分开用的。FragmentContainerView 嘛就是个高级点的 FrameLayout专门放 FragmentNavigation 嘛就是个管理页面跳转的库。但用着用着就发现不对劲了。比如用普通的 FrameLayout 配合 Navigation在 Fragment 切换动画时偶尔会出现页面闪烁或者动画重叠的鬼畜现象。又比如在横竖屏切换或者应用被系统回收后恢复时Fragment 的状态有时会乱掉导航栈也可能出问题。这些问题排查起来特别头疼因为它们不是每次都出现像幽灵一样。后来我深入研究了官方文档和源码才发现 Google 推出 FragmentContainerView 不是没有道理的。它根本不是 FrameLayout 的简单替代品而是为了与 Navigation 组件进行深度绑定和优化而生的“灵魂伴侣”。它从底层解决了传统容器在托管 Fragment尤其是配合 Navigation 进行导航时的一系列顽疾视图层级管理混乱、转场动画冲突、生命周期同步不精准以及状态恢复不可靠。所以这篇文章不是简单告诉你这两个组件怎么用市面上那样的教程太多了。我想跟你分享的是如何把它们像齿轮一样严丝合缝地组装起来构建一个既流畅又稳定还能轻松应对复杂导航需求的现代 Android 应用架构。我会结合我实际项目中踩过的坑和总结的最佳实践让你看完就能上手避开我当年走过的弯路。2. 从零开始搭建你的深度整合环境理论说再多不如动手搭一遍。我们先从最基础的配置开始确保你的项目已经为深度整合做好了准备。2.1 依赖配置选对版本是关键第一步打开你的app/build.gradle.kts或者build.gradle文件。依赖的版本号非常重要不兼容的版本会导致各种奇怪的运行时错误。我推荐使用当前稳定且互相兼容的版本。dependencies { // Fragment 相关依赖FragmentContainerView 就在这个库里 implementation(androidx.fragment:fragment-ktx:1.8.0) // Navigation 组件依赖 implementation(androidx.navigation:navigation-fragment-ktx:2.8.7) implementation(androidx.navigation:navigation-ui-ktx:2.8.7) // 如果你使用 Safe Args 进行类型安全的参数传递强烈推荐 implementation(androidx.navigation:navigation-safe-args-gradle-plugin:2.8.7) }注意上面fragment-ktx的版本它包含了FragmentContainerView。确保你的项目已经迁移到了 AndroidX。另外navigation-fragment-ktx这个库是连接 Navigation 和 Fragment 的关键它提供了对FragmentContainerView的原生支持。在项目根目录的build.gradle.kts中别忘记添加 Safe Args 的插件依赖如果你决定使用它的话plugins { id(androidx.navigation.safeargs.kotlin) version 2.8.7 apply false }然后在app/build.gradle.kts中应用它plugins { id(com.android.application) id(org.jetbrains.kotlin.android) id(androidx.navigation.safeargs.kotlin) // 应用 Safe Args 插件 }2.2 布局文件声明你的导航核心接下来我们来定义承载整个应用导航的“舞台”。传统的做法可能是在 Activity 的布局里放一个FrameLayout但现在我们要用FragmentContainerView。打开你的主 Activity 的布局文件通常是activity_main.xml进行如下配置?xml version1.0 encodingutf-8? androidx.constraintlayout.widget.ConstraintLayout xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto android:layout_widthmatch_parent android:layout_heightmatch_parent !-- 可选的顶部应用栏与 Navigation UI 组件搭配使用 -- com.google.android.material.appbar.MaterialToolbar android:idid/toolbar android:layout_width0dp android:layout_height?attr/actionBarSize app:layout_constraintEnd_toEndOfparent app:layout_constraintStart_toStartOfparent app:layout_constraintTop_toTopOfparent / !-- 核心FragmentContainerView 作为 NavHost -- androidx.fragment.app.FragmentContainerView android:idid/nav_host_fragment android:nameandroidx.navigation.fragment.NavHostFragment android:layout_width0dp android:layout_height0dp app:layout_constraintBottom_toBottomOfparent app:layout_constraintEnd_toEndOfparent app:layout_constraintStart_toStartOfparent app:layout_constraintTop_toBottomOfid/toolbar app:defaultNavHosttrue app:navGraphnavigation/nav_graph / /androidx.constraintlayout.widget.ConstraintLayout这段代码有几个关键点我当初就是没理解透这几个属性导致导航行为异常android:nameandroidx.navigation.fragment.NavHostFragment这是最重要的一步它告诉系统这个FragmentContainerView内部初始化的不是一个普通的 Fragment而是一个特殊的NavHostFragment。NavHostFragment是 Navigation 库的核心它持有一个NavController负责管理导航图NavGraph中所有目的地的切换。没有这个属性你的FragmentContainerView就只是一个普通的容器无法执行导航操作。app:navGraphnavigation/nav_graph这里关联了你的导航图资源。导航图NavGraph是一个 XML 文件它定义了应用中所有可导航的“目的地”通常是 Fragment以及它们之间的连接关系动作。我们稍后会创建它。app:defaultNavHosttrue这个属性至关重要。它确保了这个NavHostFragment能够拦截和处理系统的“返回”按钮事件。当用户按下返回键时事件会先交给它处理让它执行导航回退弹出上一个 Fragment而不是直接关闭 Activity。我强烈建议你永远把它设为true除非你有多个 NavHost 的特殊场景。2.3 创建导航图定义你的应用地图导航图就像是你的应用导航路线图。在res目录下新建一个navigation文件夹然后创建一个nav_graph.xml文件。让我们先创建一个简单的包含三个页面的导航图一个主页HomeFragment一个详情页DetailFragment和一个设置页SettingsFragment。?xml version1.0 encodingutf-8? navigation xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto xmlns:toolshttp://schemas.android.com/tools android:idid/nav_graph app:startDestinationid/homeFragment !-- 指定应用启动时的第一个目的地 -- !-- 目的地主页 -- fragment android:idid/homeFragment android:namecom.yourpackage.ui.home.HomeFragment !-- 你的 Fragment 类全路径 -- android:labelHome tools:layoutlayout/fragment_home !-- 动作从主页跳转到详情页 -- action android:idid/action_home_to_detail app:destinationid/detailFragment / !-- 动作从主页跳转到设置页 -- action android:idid/action_home_to_settings app:destinationid/settingsFragment / /fragment !-- 目的地详情页 -- fragment android:idid/detailFragment android:namecom.yourpackage.ui.detail.DetailFragment android:labelDetail tools:layoutlayout/fragment_detail !-- 可以定义从详情页返回的动作但通常使用全局返回逻辑 -- /fragment !-- 目的地设置页 -- fragment android:idid/settingsFragment android:namecom.yourpackage.ui.settings.SettingsFragment android:labelSettings tools:layoutlayout/fragment_settings / /navigation在这个导航图里我们定义了三个“目的地”以及从主页到其他两个页面的“动作”。startDestination指定了入口。tools:layout属性只是为了在 Android Studio 的设计预览中能看到界面不影响运行时。3. 核心整合让导航真正“活”起来环境搭好了地图也画好了现在该让导航跑起来了。深度整合的精髓就在于如何优雅地在 Fragment 中发起导航并处理好界面联动。3.1 在 Activity 中完成初始绑定你的主 Activity 代码会变得异常简洁因为大部分导航逻辑已经转移到了 Fragment 和导航图中。class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) // 找到布局中的 Toolbar val toolbar findViewByIdMaterialToolbar(R.id.toolbar) setSupportActionBar(toolbar) // 关键步骤获取与 NavHostFragment 关联的 NavController val navHostFragment supportFragmentManager.findFragmentById(R.id.nav_host_fragment) as NavHostFragment val navController navHostFragment.navController // 将 Toolbar 与 NavController 绑定 // 这会让 Toolbar 自动更新标题并显示返回按钮当不在起始目的地时 val appBarConfiguration AppBarConfiguration(navController.graph) setupActionBarWithNavController(navController, appBarConfiguration) } // 重写此方法让导航控制器处理返回按钮事件 override fun onSupportNavigateUp(): Boolean { val navController findNavController(R.id.nav_host_fragment) return navController.navigateUp() || super.onSupportNavigateUp() } }这段代码做了三件事1) 设置了 Toolbar2) 获取了导航控制器3) 将 Toolbar 和导航控制器绑定。绑定后当你从主页导航到详情页Toolbar 的标题会自动变成详情页的android:label并且会显示一个返回箭头。点击返回箭头就会触发navigateUp()方法回到上一个目的地。这一切都是自动的你不需要手动去设置标题或监听返回按钮。3.2 在 Fragment 中发起导航两种标准方式这是你日常开发中最常做的事情。假设你在HomeFragment里有两个按钮分别跳转到详情和设置。方式一使用 View 的扩展函数最推荐、最简洁这是 Kotlin 的福利。Navigation 库为View提供了一个扩展函数findNavController()它能自动找到离这个 View 最近的NavController。class HomeFragment : Fragment(R.layout.fragment_home) { override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) view.findViewByIdButton(R.id.btn_go_to_detail).setOnClickListener { // 直接使用 view.findNavController() view.findNavController().navigate(R.id.action_home_to_detail) } view.findViewByIdButton(R.id.btn_go_to_settings).setOnClickListener { view.findNavController().navigate(R.id.action_home_to_settings) } } }这种方式代码非常干净也是官方推荐的做法。它背后的原理是NavHostFragment会在其视图上设置一个NavController的标签findNavController()方法会沿着视图树向上查找直到找到它。方式二使用 Fragment 的扩展函数你也可以直接在 Fragment 内部调用findNavController()。class HomeFragment : Fragment(R.layout.fragment_home) { override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) view.findViewByIdButton(R.id.btn_go_to_detail).setOnClickListener { // 使用 Fragment 的 findNavController() 扩展函数 findNavController().navigate(R.id.action_home_to_detail) } } }两种方式在大多数情况下效果一样。但有一点细微差别Fragment.findNavController()会先尝试从Fragment的parentFragment或activity中查找而View.findNavController()是纯视图树查找。在简单的单 NavHost 场景下用哪个都可以。我个人更习惯用View.findNavController()感觉意图更明确。3.3 使用 Safe Args 进行类型安全的参数传递在页面跳转时传递参数是非常常见的需求。传统的方式是用Bundle但它是类型不安全的容易写错 key 或者传错类型。Navigation 的Safe Args插件就是为了解决这个问题而生的。首先确保你已经按照 2.1 节配置好了插件。然后在导航图nav_graph.xml中为动作定义参数。假设我们从HomeFragment跳转到DetailFragment时需要传递一个商品ID。在导航图中定义参数fragment android:idid/detailFragment android:namecom.yourpackage.ui.detail.DetailFragment android:labelDetail !-- 定义这个目的地接收的参数 -- argument android:nameproductId app:argTypestring / !-- 参数类型支持 int, long, string, reference 等 -- /fragment !-- 在从 home 到 detail 的动作中也可以定义要传递的参数但更常见的做法是在代码中指定 -- action android:idid/action_home_to_detail app:destinationid/detailFragment /在代码中使用生成的类进行导航编译项目后Safe Args 插件会生成一些辅助类。对于action_home_to_detail它会生成一个HomeFragmentDirections类。// 在 HomeFragment 中 view.findViewByIdButton(R.id.btn_go_to_detail).setOnClickListener { // 使用生成的 Directions 类创建导航动作并设置参数 val action HomeFragmentDirections.actionHomeToDetail(productId p123456) view.findNavController().navigate(action) }在目标 Fragment 中获取参数同样会生成一个DetailFragmentArgs类用于安全地获取参数。class DetailFragment : Fragment(R.layout.fragment_detail) { override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // 使用生成的 Args 类从 arguments 中提取参数 val args by navArgsDetailFragmentArgs() val productId args.productId // 现在可以安全地使用 productId 了 Log.d(DetailFragment, Product ID: $productId) } }使用by navArgs()这个委托属性需要fragment-ktx库代码简洁又安全。如果参数没传或者类型不对在编译时或运行时就会得到清晰的错误提示彻底告别getStringExtra(“key”)可能返回null的烦恼。4. 高级技巧与性能优化基础整合搞定后我们来看看如何玩得更溜让应用体验更上一层楼。这里涉及到导航图的模块化、深层链接、动画优化以及一些性能考量。4.1 导航图的模块化与嵌套当应用变得庞大所有目的地都挤在一个nav_graph.xml里会难以维护。Navigation 支持嵌套导航图可以将功能模块独立出来。例如我们把所有和用户设置相关的页面SettingsFragment, ProfileFragment, NotificationFragment放到一个子导航图里。创建子导航图(res/navigation/nav_settings_graph.xml)navigation xmlns:androidhttp://schemas.android.com/apk/res/android xmlns:apphttp://schemas.android.com/apk/res-auto android:idid/nav_settings_graph app:startDestinationid/settingsFragment fragment android:idid/settingsFragment android:namecom.yourpackage.ui.settings.SettingsFragment android:labelSettings / fragment android:idid/profileFragment android:namecom.yourpackage.ui.settings.ProfileFragment android:labelProfile / !-- ... 其他设置相关目的地 -- /navigation在主导航图中引用它navigation ... fragment android:idid/homeFragment ... / !-- 嵌套导航图作为一个“目的地” -- include app:graphnavigation/nav_settings_graph / /navigation从主页导航到设置模块导航到嵌套图时会进入其startDestination即 SettingsFragment。// 在 HomeFragment 中 view.findNavController().navigate(R.id.nav_settings_graph)在设置模块内部比如 SettingsFragment 跳转到 ProfileFragment导航逻辑完全在nav_settings_graph内部管理与主图隔离实现了很好的关注点分离。同时全局的返回栈依然正常工作从 ProfileFragment 按返回键会回到 SettingsFragment再按一次会回到 HomeFragment。4.2 处理深层链接深层链接让你的应用能响应特定的 URL直接从外部如浏览器、通知跳转到应用内的某个深层页面。与FragmentContainerView和 Navigation 整合后实现起来非常优雅。在导航图中定义深层链接在DetailFragment的声明中添加deepLink。fragment android:idid/detailFragment android:namecom.yourpackage.ui.detail.DetailFragment android:labelDetail argument android:nameproductId app:argTypestring / !-- 定义深层链接 -- deepLink app:uriyourAppScheme://example.com/detail/{productId} / /fragment在 AndroidManifest.xml 中关联 NavHost在包含FragmentContainerView即 NavHost的 Activity 声明中添加一个nav-graph标签。activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.VIEW / category android:nameandroid.intent.category.DEFAULT / category android:nameandroid.intent.category.BROWSABLE / !-- 匹配定义的 scheme 和 host -- data android:schemeyourAppScheme android:hostexample.com / /intent-filter !-- 关键指向你的导航图 -- nav-graph android:valuenavigation/nav_graph / /activity当用户点击一个yourAppScheme://example.com/detail/p123的链接时系统会启动你的MainActivityNavigation 库会自动解析这个 URI并将productId”p123″作为参数直接导航到DetailFragment。你不需要在 Activity 里写任何额外的Intent解析代码一切由 Navigation 和FragmentContainerView自动完成。4.3 优化转场动画与共享元素过渡FragmentContainerView对 Fragment 的转场动画有内置优化但我们可以让它更炫。Navigation 支持自定义转场动画和共享元素过渡。自定义转场动画 在nav_graph.xml的动作action中直接定义。action android:idid/action_home_to_detail app:destinationid/detailFragment app:enterAnimanim/slide_in_right app:exitAnimanim/slide_out_left app:popEnterAnimanim/slide_in_left app:popExitAnimanim/slide_out_right /共享元素过渡 这能实现两个 Fragment 之间平滑的视图转换比如点击列表项图片放大到详情页。这需要配合FragmentContainerView的过渡 API。在跳转时为共享的视图分配一个唯一的过渡名称。// 在 HomeFragment 中 val imageView view.findViewByIdImageView(R.id.item_image) val transitionName product_image_${product.id} ViewCompat.setTransitionName(imageView, transitionName) val action HomeFragmentDirections.actionHomeToDetail(productId product.id) val extras FragmentNavigatorExtras(imageView to transitionName) findNavController().navigate(action, extras)在目标DetailFragment的布局中为对应的视图设置相同的transitionName。ImageView android:idid/detail_image android:layout_widthmatch_parent android:layout_height300dp android:transitionNamestring/transition_product_image !-- 或用动态名称 -- tools:srcdrawable/product_placeholder /在目标 Fragment 中推迟过渡直到视图准备好避免画面闪烁。class DetailFragment : Fragment(R.layout.fragment_detail) { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) // 推迟共享元素过渡 postponeEnterTransition() } override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // 等待图片加载完成后再开始过渡 loadProductImage { // 你的图片加载回调 startPostponedEnterTransition() } } }要实现完美的共享元素过渡需要仔细协调两个 Fragment 的视图生命周期FragmentContainerView和 Navigation 提供了底层支持但具体的动画细节和加载逻辑需要开发者精心设计。4.4 性能考量与内存管理深度整合虽然方便但也需要注意性能。FragmentContainerView配合 Navigation 默认使用FragmentTransaction.replace()来切换目的地。这意味着旧的 Fragment 视图会被销毁新的会被创建。对于复杂的 Fragment频繁切换可能会有性能开销。优化策略使用ViewModel跨 Fragment 共享数据不要通过参数传递大量数据而是将数据放在作用域更大的ViewModel如 Activity 级别的ViewModel或使用 Navigation 的navGraphViewModels中。这样Fragment 重建时数据得以保留无需重新加载。考虑使用ViewPager2与FragmentStateAdapter对于标签页Tab这种横向滑动场景使用ViewPager2内嵌在某个 Fragment 中比用多个导航目的地来回切换性能更好体验也更流畅。这时FragmentContainerView作为这个“容器 Fragment”的视图即可。懒加载与视图复用在 Fragment 的onViewCreated中初始化耗时操作并考虑使用ViewStub或按需加载部分视图。对于列表等组件确保使用RecyclerView并进行正确的视图复用。监控返回栈深度Navigation 会管理返回栈但栈太深可能占用较多内存。对于某些不必要加入返回栈的跳转比如跳转到一个全局性的、独立的页面可以使用navOptions来配置不将其加入返回栈。val navOptions NavOptions.Builder() .setLaunchSingleTop(true) .setPopUpTo(R.id.homeFragment, false) // 可选弹出到某个目的地 .build() findNavController().navigate(R.id.some_destination, null, navOptions)5. 避坑指南实战中常见问题与解决方案整合之路并非一帆风顺我踩过不少坑。这里总结几个最常见的问题和解决办法希望能帮你节省大量调试时间。5.1 返回键失灵或行为异常问题按下返回键应用直接退出而不是回到上一个 Fragment。原因这是新手最常见的问题。根本原因是FragmentContainerView的app:defaultNavHosttrue属性没有设置或者你的 Activity 没有正确处理onSupportNavigateUp()。解决检查布局文件中的FragmentContainerView确保app:defaultNavHosttrue。在你的主 Activity 中务必重写onSupportNavigateUp()方法并委托给NavController。override fun onSupportNavigateUp(): Boolean { return findNavController(R.id.nav_host_fragment).navigateUp() || super.onSupportNavigateUp() }如果你使用了自定义的返回按钮逻辑确保最终调用了navController.navigateUp()。5.2 Fragment 重叠或显示空白问题屏幕旋转或从后台恢复后Fragment 重叠在一起或者FragmentContainerView内一片空白。原因这通常是因为 Activity 被销毁重建时你手动执行了FragmentTransaction比如在onCreate里判断savedInstanceState null然后添加 Fragment而 Navigation 和FragmentContainerView已经通过android:name属性自动恢复了自己的状态两者冲突了。解决绝对不要在使用了android:nameandroidx.navigation.fragment.NavHostFragment的FragmentContainerView对应的 Activity 中再手动添加 Fragment。导航图的恢复完全由 Navigation 库和FragmentContainerView自己处理。你的 Activity 的onCreate应该像 3.1 节那样简洁只做绑定 UI 的工作。5.3 导航动作找不到或参数传递失败问题调用navigate(R.id.some_action)时崩溃提示 action 找不到或者 Safe Args 参数为 null。原因Action ID 错误检查R.id.action_xxx是否确实存在于你当前 Fragment 所在的导航图中。如果你使用了嵌套导航图要确保你从正确的作用域查找 action。Safe Args 插件未生效确保项目正确同步Sync。有时需要Build - Clean Project再Build - Rebuild Project来触发代码生成。检查build/generated/source/navigation-args/目录下是否有生成的Directions和Args类。参数类型不匹配在导航图中定义的argType必须与代码中传递的类型完全一致。比如app:argTypestring对应 Kotlin 的Stringapp:argTypeinteger对应Int。5.4 与 BottomNavigationView 或 DrawerLayout 整合的坑问题使用BottomNavigationView切换底部标签页时每次切换都会创建新的 Fragment 实例状态无法保存。解决方案这是 Navigation 的高级用法。你需要使用NavigationUI库来智能地管理这种“多栈”导航。为每个底部标签页准备一个独立的子导航图nav_graph_home,nav_graph_dashboard,nav_graph_notifications。在主 Activity 布局中为每个子导航图准备一个FragmentContainerView或者使用NavHostFragment的FragmentStateAdapter配合ViewPager2但更推荐前者。使用NavigationUI.setupWithNavController将BottomNavigationView与一个NavController关联并通过监听选择事件动态切换 Activity 中显示的NavHostFragment。同时需要自己管理多个NavController的返回栈。更简单的做法是使用官方navigation-ui库提供的setupWithNavController方法但它默认是为单 NavHost 设计的。对于真正的多栈需求你可能需要参考 Google 的 “Navigation Advanced Sample” 中关于底部导航和多返回栈的实现这涉及到NavHostFragment的动态替换和NavController的保存与恢复是一个相对复杂的主题。核心思想是让每个底部标签页拥有自己独立的导航返回栈切换标签页时切换整个NavHostFragment从而切换整个导航上下文和返回栈。5.5 视图泄露与内存问题问题在 Fragment 中注册了监听器如LiveData观察、RxJava订阅但在 Fragment 销毁时没有取消导致内存泄露。解决这是 Android 开发的通用准则在与 Navigation 配合时尤其重要因为 Navigation 默认的replace操作会销毁 Fragment 的视图。使用viewLifecycleOwner来观察与视图相关的LiveData而不是thisFragment 本身。这样可以确保在onDestroyView()时观察自动停止。// 正确做法 viewModel.someData.observe(viewLifecycleOwner) { data - // 更新 UI } // 风险做法如果观察者内部持有视图引用可能导致泄露 // viewModel.someData.observe(this) { ... }在onDestroyView()或onDestroy()中手动清理你创建的任何可能持有上下文或视图引用的对象如Handler、广播接收器、自定义监听器等。考虑使用Fragment的getViewLifecycleOwnerLiveData()或 Kotlin 协程的lifecycleScope针对视图生命周期来启动协程它们会在适当的时机自动取消。深度整合FragmentContainerView和 Jetpack Navigation本质上是在拥抱 Android 官方推荐的现代化架构。它强迫你遵循更清晰的生命周期管理和状态恢复模式。一开始可能会觉得约束多但一旦习惯你会发现它带来的可维护性、稳定性和开发效率的提升是巨大的。尤其是在团队协作中一套标准的导航框架能极大减少沟通成本和潜在的 Bug。我自己的项目在全面转向这套方案后之前那些诡异的 Fragment 相关崩溃几乎绝迹页面跳转的逻辑也变得一目了然。如果你还在手动管理一堆FragmentTransaction强烈建议你花点时间尝试一下这个组合它值得你投入。