【发布时间】：2026-01-26 12:55:01
【问题描述】：
我一直在开发一款针对 Android 4.0 及更高版本的应用，但没有计划支持早期版本。我有什么好的理由继续使用支持库吗？
【问题讨论】：
标签： android android-support-library
【发布时间】：2026-01-26 12:55:01
【问题描述】：
支持库有许多独特的features，适用于所有 API 级别：
- LocalBroadcastManager - 允许应用在单个应用中轻松注册和接收意图，而无需在全球范围内广播它们。
- ViewPager - 添加一个 ViewGroup 来管理子视图的布局，用户可以在它们之间滑动。
- DrawerLayout - 添加了对创建可从窗口边缘拉入的 Navigation Drawer 的支持。
- SlidingPaneLayout - 添加用于创建链接摘要和详细视图的小部件，以适当地适应各种屏幕尺寸。
- FileProvider - 添加对在应用程序之间共享私人文件的支持。
还有其他诸如
- WakefulBroadcastReceiver - 实现 BroadcastReceiver 的通用模式的助手，该模式接收设备唤醒事件，然后将工作传递给服务，同时确保设备在转换期间不会重新进入睡眠状态。
- AtomicFile - 对文件进行原子操作
- SwipeRefreshLayout - 添加拉动以刷新视图
另请注意，Fragments 的支持库版本中提供了一些较新的功能，例如 nested Fragments（仅在 Android 4.2 中添加）。 Renderscript intrinics 也仅在 Android 4.2 中引入，如果您正在执行诸如实时图像处理之类的事情，这很重要。 Big style notifications and notification actions（在 Android 4.1 中引入）在使用 NotificationCompat 时更容易使用（并且 Android Wear Notification API 是基于它构建的）。
【讨论】：
-
哇，没有意识到支持库带来了所有这些功能。谢谢！我在最后一小时还发现它还包含NotificationCompat 库，这是在 API 级别 16 以下构建通知所必需的。
-
Android 再次证明自己是反直觉的。我真的希望所有这些乱七八糟的事情都能在后台处理，而不是让其 api 用户遭受其复杂库的后果。
-
@AndrewS - 我很想听听您对更好系统的建议！不幸的是，除了提供与 API 级别无关的库之外，向旧平台级别提供新功能的方法只有这么多。
-
是的，但是兼容性库中存在很多不兼容的地方。例如 android.support.v4.xxxx 库不能与更原生的 android.app 计数器部分混合。例如，来自非支持库的列表视图片段不能转换为支持库中的一个。有时，Android Studio 会加剧这种情况，因为向导会选择支持库，而 RightClick>New>Fragment> 普通片段则使用原生片段。一些较新的组件仅在支持库中。我现在明白为什么 Google 需要 Gradle 来自动化它的构建，这是一团糟。
使用支持v4的优势（据我所知）：
- 可以使用 ViewPager（仅支持 v4）
- 您可以使用 ArrayMap（在 API 19 中添加）
【讨论】：
如果您的 minSdkVersion >=13，您可以使用 android-support-v13。 jar 位于 $ANDROID_HOME/extras/android/support/v13
【讨论】：
-
这并没有提供问题的答案。要批评或要求作者澄清，请在其帖子下方发表评论。
-
是的，它确实提供了答案。如果您的 minSdkVersion>=13，则没有理由使用 support.v4，在这种情况下您应该使用 support.v13。