前两天有读者问我网上不少 Kotlin 写的 Activity 示例有的写class MainActivity : Activity()有的写class MainActivity : ComponentActivity()这俩到底差在哪我把它们各自继承过来编译都能过App 也都能跑是不是随便选一个就行这个问题问得很典型。很多人从老教程、旧项目模版切到新版 AndroidX 项目时都会被这两个类绕晕。表面上看它们只是继承对象不同跑起来也没什么肉眼可见的区别但实际开发中ComponentActivity才是 AndroidX 生态的“标准地基”而android.app.Activity更像一个“历史遗留容器”。这篇文章我不打算只给结论我会把两者的继承链、能力差异、Kotlin 代码里的实际表现、迁移过程中踩过的坑一次性讲透。1. 直接说结论ComponentActivity 就是“增强版”的 Activity1.1 从继承关系看本质ComponentActivity并不是和android.app.Activity平起平坐的另一个类它本身就是Activity的子类。从 AndroidX 源码里可以看到它的声明大致是public class ComponentActivity : Activity, LifecycleOwner, ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner, OnBackPressedDispatcherOwner, ActivityResultRegistryOwner { // ... }这个声明已经把所有关键差异写在脸上了它继承了系统提供的Activity然后又额外实现了一堆 Jetpack 接口。所以你可以把android.app.Activity理解成“毛坯房”而ComponentActivity是“精装修样板间”。毛坯房能住人但水电、网络、门禁这些基础设施都要你自己重新布样板间则是把这些全部预装好了钥匙拿到手就能拎包入住。两者在继承关系上的直观对比对比项android.app.Activityandroidx.activity.ComponentActivity所属体系Android 系统框架AndroidX (Jetpack)直接父类ContextThemeWrapperandroid.app.Activity是否实现 LifecycleOwner高版本系统部分实现是且全版本一致是否实现 ViewModelStoreOwner否是是否实现 SavedStateRegistryOwner否是是否实现 OnBackPressedDispatcherOwner否是是否实现 ActivityResultRegistryOwner否是1.2 为什么 AndroidX 要再造一个 ComponentActivityAndroid 系统版本碎片化是个长期痛点。系统自带的Activity在不同 Android 版本上的行为可能是不同的尤其在高版本系统上官方会把一些新能力补到平台类里。但你的 AppminSdkVersion如果还是 24 或者 26那低版本设备上就没有这些新行为。ComponentActivity的作用就是把这些“本该属于高版本系统”的能力以库的形式下沉。它不依赖系统版本只要你在 build.gradle 里引入了androidx.activity:activity-ktx那么在 Android 6 到 Android 15 的设备上LifecycleOwner、ViewModelStoreOwner这些行为都是一致的。这一点对做多版本兼容的开发者来说极其关键。我遇到过不少朋友问“我发现 API 30 之后的android.app.Activity也实现了LifecycleOwner那我直接用系统 Activity 不是也行吗”这个说法对了一半。高版本系统确实开始内置这些接口但你的 App 要覆盖老设备平台类在不同版本上的差异绕不开。ComponentActivity的价值不是“能不能用”而是“在所有版本上都能用、行为一致、和 Jetpack 生态完全对齐”。生产项目里不要拿系统的“部分实现”去赌兼容性。1.3 和 FragmentActivity、AppCompatActivity 的关系还有一个常见混淆点FragmentActivity和AppCompatActivity又是哪一层继承链是这样的android.app.Activity └─ ComponentActivity └─ FragmentActivity └─ AppCompatActivity也就是说FragmentActivity是ComponentActivity的子类AppCompatActivity是FragmentActivity的子类。简单理解ComponentActivity提供了最基础的生命周期、ViewModel 和返回键能力FragmentActivity在这个基础上增加了 Fragment 管理能力AppCompatActivity再进一步增加了 AppCompat 主题、ActionBar、Material 组件适配等能力。所以你如果只是要一个不带 ActionBar、不带 Fragment 的现代 Android 页面宿主用ComponentActivity是最轻量的选择。而如果你的页面还要用Fragment或者传统的Toolbar、主题控件就直接继承AppCompatActivity。2. 能力差异清单从 Lifecycle 到 ViewModel 再到返回手势2.1 LifecycleOwner协程、LiveData 都依赖它LifecycleOwner是 Jetpack 里最底层的存在。lifecycleScope、LiveData.observe、repeatOnLifecycle、Flow.flowWithLifecycle这些 API都要求当前对象是一个LifecycleOwner否则无法感知页面生命周期。继承android.app.Activity时如果你直接用lifecycleScope.launch { }编译期可能能过取决于你用的是哪个版本的 lifecycle但运行时不一定会按你预期绑到 Activity 生命周期上更麻烦的是在某些系统版本上lifecycle根本没拿到正确的生命周期状态协程任务在页面不可见时还在继续跑。而ComponentActivity内部创建了LifecycleRegistry从onCreate到onDestroy一路自动派发状态并且暴露lifecycle属性。这在 Kotlin 里的实际好处非常明显你可以毫无顾虑地写class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) lifecycleScope.launch { lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) { // 页面可见时执行页面不可见时自动取消 } } } }如果换成Activity你会发现这套东西要么不生效要么需要你自己 new 一个LifecycleRegistry再手动同步生命周期事件。这不是不能实现但属于典型的“自己造轮子还容易漏”。2.2 ViewModelStoreOwnerby viewModels()的地基在 Kotlin 里写一个带ViewModel的页面最常见的写法是class MainActivity : ComponentActivity() { private val viewModel: MainViewModel by viewModels() }这个viewModels()扩展函数来自androidx.activity:activity-ktx它的实现依赖ViewModelStoreOwner。ComponentActivity已经实现了这个接口内部维护了一个ViewModelStore并且在配置变更比如旋转屏幕后会通过onRetainNonConfigurationInstance把ViewModelStore传下去保证 ViewModel 实例不销毁、数据不丢。而android.app.Activity本身并没有维护这样一个 store。如果你直接:class MainActivity : Activity() { private val viewModel: MainViewModel by viewModels() // 编译报错 }viewModels()这个扩展会找不到ViewModelStoreOwner直接编译失败。被迫只能手动写ViewModelProvider那一套而且还要自己解决 ViewModel 的存储和恢复问题。很多人在这里踩坑后才意识到继承ComponentActivity有多省事。2.3 SavedStateRegistryOwner进程被杀后的数据恢复只看旋转屏幕系统Activity也能通过onSaveInstanceState恢复数据但处理顺序和恢复时机不够稳定。ComponentActivity通过SavedStateRegistry提供了更统一的保存/恢复机制并且把恢复的数据暴露成SavedStateHandle给 ViewModel 用。这个能力的典型使用场景是当 App 被系统杀死后重新启动ViewModel 的SavedStateHandle会自动拿到上次保存的数据。如果你的BaseActivity只是继承系统Activity要么乖乖写一堆onSaveInstanceState里的putString/getString要么在某些状态下发现数据丢了却根本找不到原因。ComponentActivity则是在内部统一注册好节点各个库都能在自己的宿主上保存状态不需要你逐层分发。2.4 OnBackPressedDispatcherOwner返回键的现代化方案从 Android 13API 33开始系统Activity的onBackPressed()已经被标记过时取而代之的是基于OnBackPressedDispatcher的预测性返回手势。这个“预测性返回”不只是拦截返回按键它还能让系统在手指侧滑时展示动画预览。ComponentActivity实现了OnBackPressedDispatcherOwner给开发者提供了一个统一的返回回调注册入口。在 Kotlin 里想要在页面内拦截返回事件标准写法是class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) onBackPressedDispatcher.addCallback(this) { // 自定义返回逻辑 if (!handleBack()) { isEnabled false onBackPressedDispatcher.onBackPressed() } } } }如果是传统的Activity你只能重写onBackPressed()。在 Android 13 上这种老写法会导致预测性返回手势无法正确联动用户侧滑返回时动画不完整甚至出现“按键已经返回了但动画还是半透明状态”的奇怪 bug。想把这些行为统一到所有 Android 版本上直接依赖ComponentActivity的 dispatcher 是更省心的方案。2.5 ActivityResultRegistryOwner告别 startActivityForResult老项目中常见的跳转回调写法是startActivityForResult加onActivityResult这套 API 在新版本中已经被废弃而且存在 requestCode 冲突、进程重建后回调丢失等问题。ComponentActivity实现了ActivityResultRegistryOwner所以 Kotlin 代码里可以直接这样写class MainActivity : ComponentActivity() { private val pickImageLauncher registerForActivityResult(ActivityResultContracts.GetContent()) { uri - // 处理返回结果 } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) pickImageLauncher.launch(image/*) } }这个 API 类型安全、不用处理 requestCode、进程重建后也能正确恢复回调。而这一切在系统Activity上是使用不了的你还是得抱着老 API 写一堆样板代码。3. Kotlin 代码里最直观的几个差异点3.1 获取 ViewModel 的写法差异拿一个最简单的例子来说。继承ComponentActivity时class MainActivity : ComponentActivity() { private val viewModel: TestViewModel by viewModels() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) viewModel.loadData() } }干净利落一行搞定。继承android.app.Activity时如果你还想用 ViewModel就必须自己实现ViewModelStoreOwner写出来的代码会变成class MainActivity : Activity(), ViewModelStoreOwner { private lateinit var viewModelStoreInternal: ViewModelStore override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) viewModelStoreInternal ViewModelStore() val provider ViewModelProvider(this, defaultViewModelProviderFactory) val viewModel provider[TestViewModel::class.java] viewModel.loadData() } override fun onRetainNonConfigurationInstance(): Any? { viewModelStoreInternal.clear() return viewModelStoreInternal } override fun getViewModelStore(): ViewModelStore { return viewModelStoreInternal } }这还是简化版真实项目里还要处理SavedStateRegistryOwner、生命周期绑定等一堆东西。一旦页面多了每个Activity都要重复这套逻辑代码冗余度直线上升。3.2 ActivityResult 注册差异系统Activity的老式写法class MainActivity : Activity() { companion object { const val REQUEST_PICK_IMAGE 1001 } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val intent Intent(Intent.ACTION_PICK).apply { type image/* } startActivityForResult(intent, REQUEST_PICK_IMAGE) } override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) { super.onActivityResult(requestCode, resultCode, data) if (requestCode REQUEST_PICK_IMAGE resultCode Activity.RESULT_OK) { val uri data?.data // 处理结果 } } }ComponentActivity的新式写法class MainActivity : ComponentActivity() { private val pickImageLauncher registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri - // 处理结果 } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) pickImageLauncher.launch(PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly)) } }新写法的好处不只是代码变短更重要的是它把所有回调状态交给ActivityResultRegistry管理进程被系统回收再恢复时回调不会像老 API 那样莫名其妙丢失。3.3 Compose 的 setContent 只能在 ComponentActivity 上用这是很多人遇到的一个隐藏问题。在 Compose 项目中官方推荐的宿主就是ComponentActivity因为setContent这个扩展函数就是专门给ComponentActivity定义的class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { Text(Hello Compose) } } }如果你改成class MainActivity : Activity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { // 编译报错 Text(Hello Compose) } } }编译直接失败。想在系统Activity上用 Compose必须手动创建AndroidComposeView还要自己往 view 树里塞ViewTreeLifecycleOwner、ViewTreeViewModelStoreOwner这些节点繁琐程度远超直接换个基类。我这里想说的是如果你准备做 Compose 项目基类直接锁定ComponentActivity没有什么可纠结的。3.4 返回键监听差异系统Activity上我们通常这样拦截返回class MainActivity : Activity() { override fun onBackPressed() { if (shouldInterceptBack()) { // 自定义逻辑 } else { super.onBackPressed() } } }ComponentActivity的推荐写法是class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) onBackPressedDispatcher.addCallback(this) { if (shouldInterceptBack()) { // 自定义逻辑 } else { isEnabled false onBackPressedDispatcher.onBackPressed() } } } }从表面看只是换了一套 API但深层变化在于OnBackPressedDispatcher支持多个回调按优先级排队而且能配合系统预测性返回手势。你可以在基类注册一个默认回调在子类再注册更优先级的回调系统会按顺序弹栈处理逻辑上比单纯的onBackPressed重写要清晰得多。4. 我在迁移基类时遇到的实际问题与被坑经历4.1 起因老项目 BaseActivity 接 ViewModel 时编译不过去年我接手过一个维护了三年的老项目因为历史原因项目的BaseActivity是直接继承系统的Activity所有页面都从它派生。需求变更要求给某个页面加ViewModel我照着新项目的惯例写class OrderDetailActivity : BaseActivity() { private val viewModel: OrderDetailViewModel by viewModels() }结果编译直接报错Unresolved reference: viewModels。我当时第一反应是依赖没引全于是加了一堆lifecycle和activity-ktx的依赖重新 sync 后错误依然存在。后来才意识到问题根本不依赖而是BaseActivity继承的是android.app.Activity它不是ViewModelStoreOwnerviewModels()这个扩展函数自然派不上用场。如果当时图省事我完全可以不用委托改成手动ViewModelProvider(this)[OrderDetailViewModel::class.java]this同样不是ViewModelStoreOwner还是编译不过。所以最终只有两条路要么让BaseActivity自己实现ViewModelStoreOwner要么直接把基类切到ComponentActivity。4.2 第一次尝试手动实现 ViewModelStoreOwner越写越复杂我一开始不想动基类担心改动会影响全项目于是尝试给BaseActivity手动补齐接口abstract class BaseActivity : Activity(), ViewModelStoreOwner { private lateinit var mViewModelStore: ViewModelStore override fun getViewModelStore(): ViewModelStore { if (!::mViewModelStore.isInitialized) { mViewModelStore ViewModelStore() } return mViewModelStore } override fun onRetainNonConfigurationInstance(): Any? { return mViewModelStore } }逻辑跑通后我又发现页面里Lifecycle相关功能还是不够顺手比如想用lifecycleScope时依然没有LifecycleOwner。于是又加上abstract class BaseActivity : Activity(), LifecycleOwner { private val lifecycleRegistry LifecycleRegistry(this) override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE) } override fun onStart() { super.onStart() lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START) } override fun onResume() { super.onResume() lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME) } // ... }写到这里我已经烦了因为后面还有SavedStateRegistry、OnBackPressedDispatcher每个接口都得手动触发和恢复状态。这不是能不能实现的问题而是完全没必要。我花了一个下午补齐这些模板代码换来的只是“看起来像 ComponentActivity”的一个残次品还不如直接切基类。4.3 切到 ComponentActivity 后的连锁反应最后我还是把BaseActivity改成了abstract class BaseActivity : ComponentActivity() { // 原来的业务代码基本不用动 }改完以后编译一次过viewModels()立刻可用lifecycleScope、repeatOnLifecycle全部正常。但我也遇到了几个连锁问题这里专门列出来供参考第一个问题是onBackPressed行为变了。项目里有两个页面重写了onBackPressed继承ComponentActivity后这个方法的处理优先级和之前不同尤其是页面里还有Dialog、BottomSheet的情况下返回键可能先被内部组件消费外层onBackPressed根本走不到。这个时候必须改成onBackPressedDispatcher.addCallback的写法并检查回调顺序。第二个问题是第三方库的泛型约束。有个登录相关的库方法签名要求传入AppCompatActivity之前基类是Activity时也能用因为能强转或者它内部判断但切到ComponentActivity后如果这个页面还想要 AppCompat 主题就还得把基类改成AppCompatActivity。所以你会发现到底用ComponentActivity还是AppCompatActivity不是拍脑袋定的要看你的页面是否需要 AppCompat 主题以及依赖的库有没有强制要求。第三个问题是setContentView的时机差异。ComponentActivity的setContentView内部会做更多布局树初始化工作。原来基于系统Activity写的某些布局在addContentView和setContentView混用时会出现视图层级不一致的现象。我有个页面的广告位用的是addContentView动态添加切到ComponentActivity后需要把ViewTreeLifecycleOwner挂载位置调整一下才恢复正常。4.4 排查问题的一个心得如果你在项目里遇到莫名其妙的 Jetpack 功能不可用第一反应不是去查依赖版本而是先看页面基类是谁。看到class MainActivity : Activity()这种继承关系时十有八九就是基类选错了。排查链路一般是这样的编译报错报错信息指向LifecycleOwner、ViewModelStoreOwner、SavedStateRegistryOwner等接口时检查继承的 Activity 类型。如果继承的是android.app.Activity直接看项目里有没有activity-ktx依赖再看对应页面是否需要 ViewModel、Lifecycle 或 Compose。需要的话不要犹豫直接把基类切到ComponentActivity或AppCompatActivity。切完以后重点重测返回键、状态恢复、Fragment 嵌套这三块它们最容易出现行为变化。这个思路帮我解决了很多“看起来是依赖冲突”的问题实际上基本都是宿主类不够“现代”导致的。5. 到底该怎么选默认 ComponentActivity但也要知道边界5.1 新项目建议直接用 ComponentActivity如果你开新项目并且页面主要用 Compose 或者轻量布局我的建议是直接继承ComponentActivity。它没有AppCompatActivity那一层主题和 ActionBar 的额外负担启动速度更快、依赖更轻而且所有 Jetpack 现代特性都能直接使用。一个比较通用的模板class MainActivity : ComponentActivity() { private val viewModel: MainViewModel by viewModels() private val launcher registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result - // handle result } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) // 初始化逻辑 } }5.2 需要传统主题和控件时选 AppCompatActivity如果页面必须使用 MaterialButton、Toolbar、AppCompat 主题或者 Fragment那么就要继承AppCompatActivity。它本身是ComponentActivity的子类所以上面提到的viewModels()、lifecycleScope、registerForActivityResult这些能力全都具备只是多了一层主题兼容和 ActionBar 支持而已。比如一个典型的 Fragment 容器页面class HomeActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_home) if (savedInstanceState null) { supportFragmentManager.beginTransaction() .replace(R.id.container, HomeFragment()) .commit() } } }5.3 什么时候可以直接用 android.app.Activity有一种情况我会考虑继续用系统Activity项目完全没有引入 AndroidX并且只在特定设备上运行比如嵌入式设备、定制 ROM、打印终端等且代码量极小、不涉及 ViewModel/Lifecycle/Compose。这种情况下系统Activity反而更干净没有额外依赖。但大多数普通应用不管你是新是老项目我都建议尽快往ComponentActivity或AppCompatActivity上迁。别跟兼容性较劲现在的 Jetpack 生态基本都是围绕 AndroidX 构建的逗留在系统Activity上等于把自己排除在现代工具链之外。5.4 我的最终选择策略我在实际项目里的策略很简单能用ComponentActivity就用ComponentActivity需要 Fragment、AppCompat 主题或 Material 控件时再用AppCompatActivity不到万不得已不直接用android.app.Activity。这样做至少有三个好处ViewModel 和生命周期状态全版本统一registerForActivityResult、OnBackPressedDispatcher这些新 API 不需要兼容判断将来接 Compose 时已经站在了正确的地基上不会面临推倒重来的麻烦。最后再说一个我自己的习惯。新写任何页面我都会把BaseActivity的继承关系先确认一遍如果发现是android.app.Activity就顺手把它改成ComponentActivity或AppCompatActivity。这个动作看起来很小但能避免后面很多莫名其妙的编译问题和运行时状态丢失问题。你也可以在你自己项目里试试先挑一个小页面把基类换掉跑一遍之前所有测试用例对比一下从启动到返回的手感和状态保持情况心里对这两个类的差距就会有更直观的感受。 
长河君 · 2026/9/9 9:24:15 · 阅读 1.2k ComponentActivity与Activity：AndroidX生态下的标准基类
前两天有读者问我网上不少 Kotlin 写的 Activity 示例有的写class MainActivity : Activity()有的写class MainActivity : ComponentActivity()这俩到底差在哪我把它们各自继承过来编译都能过App 也都能跑是不是随便选一个就行这个问题问得很典型。很多人从老教程、旧项目模版切到新版 AndroidX 项目时都会被这两个类绕晕。表面上看它们只是继承对象不同跑起来也没什么肉眼可见的区别但实际开发中ComponentActivity才是 AndroidX 生态的“标准地基”而android.app.Activity更像一个“历史遗留容器”。这篇文章我不打算只给结论我会把两者的继承链、能力差异、Kotlin 代码里的实际表现、迁移过程中踩过的坑一次性讲透。1. 直接说结论ComponentActivity 就是“增强版”的 Activity1.1 从继承关系看本质ComponentActivity并不是和android.app.Activity平起平坐的另一个类它本身就是Activity的子类。从 AndroidX 源码里可以看到它的声明大致是public class ComponentActivity : Activity, LifecycleOwner, ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner, OnBackPressedDispatcherOwner, ActivityResultRegistryOwner { // ... }这个声明已经把所有关键差异写在脸上了它继承了系统提供的Activity然后又额外实现了一堆 Jetpack 接口。所以你可以把android.app.Activity理解成“毛坯房”而ComponentActivity是“精装修样板间”。毛坯房能住人但水电、网络、门禁这些基础设施都要你自己重新布样板间则是把这些全部预装好了钥匙拿到手就能拎包入住。两者在继承关系上的直观对比对比项android.app.Activityandroidx.activity.ComponentActivity所属体系Android 系统框架AndroidX (Jetpack)直接父类ContextThemeWrapperandroid.app.Activity是否实现 LifecycleOwner高版本系统部分实现是且全版本一致是否实现 ViewModelStoreOwner否是是否实现 SavedStateRegistryOwner否是是否实现 OnBackPressedDispatcherOwner否是是否实现 ActivityResultRegistryOwner否是1.2 为什么 AndroidX 要再造一个 ComponentActivityAndroid 系统版本碎片化是个长期痛点。系统自带的Activity在不同 Android 版本上的行为可能是不同的尤其在高版本系统上官方会把一些新能力补到平台类里。但你的 AppminSdkVersion如果还是 24 或者 26那低版本设备上就没有这些新行为。ComponentActivity的作用就是把这些“本该属于高版本系统”的能力以库的形式下沉。它不依赖系统版本只要你在 build.gradle 里引入了androidx.activity:activity-ktx那么在 Android 6 到 Android 15 的设备上LifecycleOwner、ViewModelStoreOwner这些行为都是一致的。这一点对做多版本兼容的开发者来说极其关键。我遇到过不少朋友问“我发现 API 30 之后的android.app.Activity也实现了LifecycleOwner那我直接用系统 Activity 不是也行吗”这个说法对了一半。高版本系统确实开始内置这些接口但你的 App 要覆盖老设备平台类在不同版本上的差异绕不开。ComponentActivity的价值不是“能不能用”而是“在所有版本上都能用、行为一致、和 Jetpack 生态完全对齐”。生产项目里不要拿系统的“部分实现”去赌兼容性。1.3 和 FragmentActivity、AppCompatActivity 的关系还有一个常见混淆点FragmentActivity和AppCompatActivity又是哪一层继承链是这样的android.app.Activity └─ ComponentActivity └─ FragmentActivity └─ AppCompatActivity也就是说FragmentActivity是ComponentActivity的子类AppCompatActivity是FragmentActivity的子类。简单理解ComponentActivity提供了最基础的生命周期、ViewModel 和返回键能力FragmentActivity在这个基础上增加了 Fragment 管理能力AppCompatActivity再进一步增加了 AppCompat 主题、ActionBar、Material 组件适配等能力。所以你如果只是要一个不带 ActionBar、不带 Fragment 的现代 Android 页面宿主用ComponentActivity是最轻量的选择。而如果你的页面还要用Fragment或者传统的Toolbar、主题控件就直接继承AppCompatActivity。2. 能力差异清单从 Lifecycle 到 ViewModel 再到返回手势2.1 LifecycleOwner协程、LiveData 都依赖它LifecycleOwner是 Jetpack 里最底层的存在。lifecycleScope、LiveData.observe、repeatOnLifecycle、Flow.flowWithLifecycle这些 API都要求当前对象是一个LifecycleOwner否则无法感知页面生命周期。继承android.app.Activity时如果你直接用lifecycleScope.launch { }编译期可能能过取决于你用的是哪个版本的 lifecycle但运行时不一定会按你预期绑到 Activity 生命周期上更麻烦的是在某些系统版本上lifecycle根本没拿到正确的生命周期状态协程任务在页面不可见时还在继续跑。而ComponentActivity内部创建了LifecycleRegistry从onCreate到onDestroy一路自动派发状态并且暴露lifecycle属性。这在 Kotlin 里的实际好处非常明显你可以毫无顾虑地写class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) lifecycleScope.launch { lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) { // 页面可见时执行页面不可见时自动取消 } } } }如果换成Activity你会发现这套东西要么不生效要么需要你自己 new 一个LifecycleRegistry再手动同步生命周期事件。这不是不能实现但属于典型的“自己造轮子还容易漏”。2.2 ViewModelStoreOwnerby viewModels()的地基在 Kotlin 里写一个带ViewModel的页面最常见的写法是class MainActivity : ComponentActivity() { private val viewModel: MainViewModel by viewModels() }这个viewModels()扩展函数来自androidx.activity:activity-ktx它的实现依赖ViewModelStoreOwner。ComponentActivity已经实现了这个接口内部维护了一个ViewModelStore并且在配置变更比如旋转屏幕后会通过onRetainNonConfigurationInstance把ViewModelStore传下去保证 ViewModel 实例不销毁、数据不丢。而android.app.Activity本身并没有维护这样一个 store。如果你直接:class MainActivity : Activity() { private val viewModel: MainViewModel by viewModels() // 编译报错 }viewModels()这个扩展会找不到ViewModelStoreOwner直接编译失败。被迫只能手动写ViewModelProvider那一套而且还要自己解决 ViewModel 的存储和恢复问题。很多人在这里踩坑后才意识到继承ComponentActivity有多省事。2.3 SavedStateRegistryOwner进程被杀后的数据恢复只看旋转屏幕系统Activity也能通过onSaveInstanceState恢复数据但处理顺序和恢复时机不够稳定。ComponentActivity通过SavedStateRegistry提供了更统一的保存/恢复机制并且把恢复的数据暴露成SavedStateHandle给 ViewModel 用。这个能力的典型使用场景是当 App 被系统杀死后重新启动ViewModel 的SavedStateHandle会自动拿到上次保存的数据。如果你的BaseActivity只是继承系统Activity要么乖乖写一堆onSaveInstanceState里的putString/getString要么在某些状态下发现数据丢了却根本找不到原因。ComponentActivity则是在内部统一注册好节点各个库都能在自己的宿主上保存状态不需要你逐层分发。2.4 OnBackPressedDispatcherOwner返回键的现代化方案从 Android 13API 33开始系统Activity的onBackPressed()已经被标记过时取而代之的是基于OnBackPressedDispatcher的预测性返回手势。这个“预测性返回”不只是拦截返回按键它还能让系统在手指侧滑时展示动画预览。ComponentActivity实现了OnBackPressedDispatcherOwner给开发者提供了一个统一的返回回调注册入口。在 Kotlin 里想要在页面内拦截返回事件标准写法是class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) onBackPressedDispatcher.addCallback(this) { // 自定义返回逻辑 if (!handleBack()) { isEnabled false onBackPressedDispatcher.onBackPressed() } } } }如果是传统的Activity你只能重写onBackPressed()。在 Android 13 上这种老写法会导致预测性返回手势无法正确联动用户侧滑返回时动画不完整甚至出现“按键已经返回了但动画还是半透明状态”的奇怪 bug。想把这些行为统一到所有 Android 版本上直接依赖ComponentActivity的 dispatcher 是更省心的方案。2.5 ActivityResultRegistryOwner告别 startActivityForResult老项目中常见的跳转回调写法是startActivityForResult加onActivityResult这套 API 在新版本中已经被废弃而且存在 requestCode 冲突、进程重建后回调丢失等问题。ComponentActivity实现了ActivityResultRegistryOwner所以 Kotlin 代码里可以直接这样写class MainActivity : ComponentActivity() { private val pickImageLauncher registerForActivityResult(ActivityResultContracts.GetContent()) { uri - // 处理返回结果 } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) pickImageLauncher.launch(image/*) } }这个 API 类型安全、不用处理 requestCode、进程重建后也能正确恢复回调。而这一切在系统Activity上是使用不了的你还是得抱着老 API 写一堆样板代码。3. Kotlin 代码里最直观的几个差异点3.1 获取 ViewModel 的写法差异拿一个最简单的例子来说。继承ComponentActivity时class MainActivity : ComponentActivity() { private val viewModel: TestViewModel by viewModels() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) viewModel.loadData() } }干净利落一行搞定。继承android.app.Activity时如果你还想用 ViewModel就必须自己实现ViewModelStoreOwner写出来的代码会变成class MainActivity : Activity(), ViewModelStoreOwner { private lateinit var viewModelStoreInternal: ViewModelStore override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) viewModelStoreInternal ViewModelStore() val provider ViewModelProvider(this, defaultViewModelProviderFactory) val viewModel provider[TestViewModel::class.java] viewModel.loadData() } override fun onRetainNonConfigurationInstance(): Any? { viewModelStoreInternal.clear() return viewModelStoreInternal } override fun getViewModelStore(): ViewModelStore { return viewModelStoreInternal } }这还是简化版真实项目里还要处理SavedStateRegistryOwner、生命周期绑定等一堆东西。一旦页面多了每个Activity都要重复这套逻辑代码冗余度直线上升。3.2 ActivityResult 注册差异系统Activity的老式写法class MainActivity : Activity() { companion object { const val REQUEST_PICK_IMAGE 1001 } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val intent Intent(Intent.ACTION_PICK).apply { type image/* } startActivityForResult(intent, REQUEST_PICK_IMAGE) } override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) { super.onActivityResult(requestCode, resultCode, data) if (requestCode REQUEST_PICK_IMAGE resultCode Activity.RESULT_OK) { val uri data?.data // 处理结果 } } }ComponentActivity的新式写法class MainActivity : ComponentActivity() { private val pickImageLauncher registerForActivityResult(ActivityResultContracts.PickVisualMedia()) { uri - // 处理结果 } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) pickImageLauncher.launch(PickVisualMediaRequest(ActivityResultContracts.PickVisualMedia.ImageOnly)) } }新写法的好处不只是代码变短更重要的是它把所有回调状态交给ActivityResultRegistry管理进程被系统回收再恢复时回调不会像老 API 那样莫名其妙丢失。3.3 Compose 的 setContent 只能在 ComponentActivity 上用这是很多人遇到的一个隐藏问题。在 Compose 项目中官方推荐的宿主就是ComponentActivity因为setContent这个扩展函数就是专门给ComponentActivity定义的class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { Text(Hello Compose) } } }如果你改成class MainActivity : Activity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { // 编译报错 Text(Hello Compose) } } }编译直接失败。想在系统Activity上用 Compose必须手动创建AndroidComposeView还要自己往 view 树里塞ViewTreeLifecycleOwner、ViewTreeViewModelStoreOwner这些节点繁琐程度远超直接换个基类。我这里想说的是如果你准备做 Compose 项目基类直接锁定ComponentActivity没有什么可纠结的。3.4 返回键监听差异系统Activity上我们通常这样拦截返回class MainActivity : Activity() { override fun onBackPressed() { if (shouldInterceptBack()) { // 自定义逻辑 } else { super.onBackPressed() } } }ComponentActivity的推荐写法是class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) onBackPressedDispatcher.addCallback(this) { if (shouldInterceptBack()) { // 自定义逻辑 } else { isEnabled false onBackPressedDispatcher.onBackPressed() } } } }从表面看只是换了一套 API但深层变化在于OnBackPressedDispatcher支持多个回调按优先级排队而且能配合系统预测性返回手势。你可以在基类注册一个默认回调在子类再注册更优先级的回调系统会按顺序弹栈处理逻辑上比单纯的onBackPressed重写要清晰得多。4. 我在迁移基类时遇到的实际问题与被坑经历4.1 起因老项目 BaseActivity 接 ViewModel 时编译不过去年我接手过一个维护了三年的老项目因为历史原因项目的BaseActivity是直接继承系统的Activity所有页面都从它派生。需求变更要求给某个页面加ViewModel我照着新项目的惯例写class OrderDetailActivity : BaseActivity() { private val viewModel: OrderDetailViewModel by viewModels() }结果编译直接报错Unresolved reference: viewModels。我当时第一反应是依赖没引全于是加了一堆lifecycle和activity-ktx的依赖重新 sync 后错误依然存在。后来才意识到问题根本不依赖而是BaseActivity继承的是android.app.Activity它不是ViewModelStoreOwnerviewModels()这个扩展函数自然派不上用场。如果当时图省事我完全可以不用委托改成手动ViewModelProvider(this)[OrderDetailViewModel::class.java]this同样不是ViewModelStoreOwner还是编译不过。所以最终只有两条路要么让BaseActivity自己实现ViewModelStoreOwner要么直接把基类切到ComponentActivity。4.2 第一次尝试手动实现 ViewModelStoreOwner越写越复杂我一开始不想动基类担心改动会影响全项目于是尝试给BaseActivity手动补齐接口abstract class BaseActivity : Activity(), ViewModelStoreOwner { private lateinit var mViewModelStore: ViewModelStore override fun getViewModelStore(): ViewModelStore { if (!::mViewModelStore.isInitialized) { mViewModelStore ViewModelStore() } return mViewModelStore } override fun onRetainNonConfigurationInstance(): Any? { return mViewModelStore } }逻辑跑通后我又发现页面里Lifecycle相关功能还是不够顺手比如想用lifecycleScope时依然没有LifecycleOwner。于是又加上abstract class BaseActivity : Activity(), LifecycleOwner { private val lifecycleRegistry LifecycleRegistry(this) override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE) } override fun onStart() { super.onStart() lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_START) } override fun onResume() { super.onResume() lifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_RESUME) } // ... }写到这里我已经烦了因为后面还有SavedStateRegistry、OnBackPressedDispatcher每个接口都得手动触发和恢复状态。这不是能不能实现的问题而是完全没必要。我花了一个下午补齐这些模板代码换来的只是“看起来像 ComponentActivity”的一个残次品还不如直接切基类。4.3 切到 ComponentActivity 后的连锁反应最后我还是把BaseActivity改成了abstract class BaseActivity : ComponentActivity() { // 原来的业务代码基本不用动 }改完以后编译一次过viewModels()立刻可用lifecycleScope、repeatOnLifecycle全部正常。但我也遇到了几个连锁问题这里专门列出来供参考第一个问题是onBackPressed行为变了。项目里有两个页面重写了onBackPressed继承ComponentActivity后这个方法的处理优先级和之前不同尤其是页面里还有Dialog、BottomSheet的情况下返回键可能先被内部组件消费外层onBackPressed根本走不到。这个时候必须改成onBackPressedDispatcher.addCallback的写法并检查回调顺序。第二个问题是第三方库的泛型约束。有个登录相关的库方法签名要求传入AppCompatActivity之前基类是Activity时也能用因为能强转或者它内部判断但切到ComponentActivity后如果这个页面还想要 AppCompat 主题就还得把基类改成AppCompatActivity。所以你会发现到底用ComponentActivity还是AppCompatActivity不是拍脑袋定的要看你的页面是否需要 AppCompat 主题以及依赖的库有没有强制要求。第三个问题是setContentView的时机差异。ComponentActivity的setContentView内部会做更多布局树初始化工作。原来基于系统Activity写的某些布局在addContentView和setContentView混用时会出现视图层级不一致的现象。我有个页面的广告位用的是addContentView动态添加切到ComponentActivity后需要把ViewTreeLifecycleOwner挂载位置调整一下才恢复正常。4.4 排查问题的一个心得如果你在项目里遇到莫名其妙的 Jetpack 功能不可用第一反应不是去查依赖版本而是先看页面基类是谁。看到class MainActivity : Activity()这种继承关系时十有八九就是基类选错了。排查链路一般是这样的编译报错报错信息指向LifecycleOwner、ViewModelStoreOwner、SavedStateRegistryOwner等接口时检查继承的 Activity 类型。如果继承的是android.app.Activity直接看项目里有没有activity-ktx依赖再看对应页面是否需要 ViewModel、Lifecycle 或 Compose。需要的话不要犹豫直接把基类切到ComponentActivity或AppCompatActivity。切完以后重点重测返回键、状态恢复、Fragment 嵌套这三块它们最容易出现行为变化。这个思路帮我解决了很多“看起来是依赖冲突”的问题实际上基本都是宿主类不够“现代”导致的。5. 到底该怎么选默认 ComponentActivity但也要知道边界5.1 新项目建议直接用 ComponentActivity如果你开新项目并且页面主要用 Compose 或者轻量布局我的建议是直接继承ComponentActivity。它没有AppCompatActivity那一层主题和 ActionBar 的额外负担启动速度更快、依赖更轻而且所有 Jetpack 现代特性都能直接使用。一个比较通用的模板class MainActivity : ComponentActivity() { private val viewModel: MainViewModel by viewModels() private val launcher registerForActivityResult(ActivityResultContracts.StartActivityForResult()) { result - // handle result } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) // 初始化逻辑 } }5.2 需要传统主题和控件时选 AppCompatActivity如果页面必须使用 MaterialButton、Toolbar、AppCompat 主题或者 Fragment那么就要继承AppCompatActivity。它本身是ComponentActivity的子类所以上面提到的viewModels()、lifecycleScope、registerForActivityResult这些能力全都具备只是多了一层主题兼容和 ActionBar 支持而已。比如一个典型的 Fragment 容器页面class HomeActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_home) if (savedInstanceState null) { supportFragmentManager.beginTransaction() .replace(R.id.container, HomeFragment()) .commit() } } }5.3 什么时候可以直接用 android.app.Activity有一种情况我会考虑继续用系统Activity项目完全没有引入 AndroidX并且只在特定设备上运行比如嵌入式设备、定制 ROM、打印终端等且代码量极小、不涉及 ViewModel/Lifecycle/Compose。这种情况下系统Activity反而更干净没有额外依赖。但大多数普通应用不管你是新是老项目我都建议尽快往ComponentActivity或AppCompatActivity上迁。别跟兼容性较劲现在的 Jetpack 生态基本都是围绕 AndroidX 构建的逗留在系统Activity上等于把自己排除在现代工具链之外。5.4 我的最终选择策略我在实际项目里的策略很简单能用ComponentActivity就用ComponentActivity需要 Fragment、AppCompat 主题或 Material 控件时再用AppCompatActivity不到万不得已不直接用android.app.Activity。这样做至少有三个好处ViewModel 和生命周期状态全版本统一registerForActivityResult、OnBackPressedDispatcher这些新 API 不需要兼容判断将来接 Compose 时已经站在了正确的地基上不会面临推倒重来的麻烦。最后再说一个我自己的习惯。新写任何页面我都会把BaseActivity的继承关系先确认一遍如果发现是android.app.Activity就顺手把它改成ComponentActivity或AppCompatActivity。这个动作看起来很小但能避免后面很多莫名其妙的编译问题和运行时状态丢失问题。你也可以在你自己项目里试试先挑一个小页面把基类换掉跑一遍之前所有测试用例对比一下从启动到返回的手感和状态保持情况心里对这两个类的差距就会有更直观的感受。