简介面向Android开发者的兼容性支持库合集聚焦v4与v7 support两个经典jar包适合需要维护旧版本适配、理解向后兼容策略的初中级开发者。压缩包共447个文件约2.05MB以223个xml资源与213个png图片为主承载布局、样式与图标素材另有2个jar核心库、3个java源码及readme、properties等配置说明便于直接引入工程或对照研究。已有239人学习下载。资源完整保留了support-v4对Fragment、Loader等组件的低版本支持以及support-v7-appcompat中ActionBar、AppCompatActivity与Material主题兼容实现可帮助读者在API 23及以上环境中继续复用旧库或为迁移至AndroidX提供对照参考理解系统版本碎片化下的兼容设计思路。1. 从两个文件名说起v4 和 v7 到底是什么刚接触安卓开发的人第一次在项目里看到android-support-v4.jar和android-support-v7-appcompat.jar这两个名字大概率会愣一下v4、v7 是版本号吗为什么一个项目里要同时放两个它们和手机系统版本又是什么关系先把最容易误会的一点说清楚这里的 v4 和 v7 不是安卓系统版本也不是库的版本号而是指「这个库最低能兼容到哪个 API 级别」。v4 表示最低支持 API 4安卓 1.6v7 表示最低支持 API 7安卓 2.1。换句话说它们是给老版本系统「补课」用的兼容包让新写法能在旧手机上跑起来。你写的代码用了新特性但用户手里还攥着几年前的旧手机这两个 jar 就是中间的翻译官。搞懂它们你才能明白为什么很多老项目里到处是android.support.v4.app.Fragment这种带前缀的类名也才能在看懂之后决定新项目还要不要碰它们。2. 为什么老项目离不开它们兼容包解决的真实问题2.1 一个类比新电器配老插座想象你买了一个新式三孔插头的电器但家里墙上只有老式两孔插座。你有两个选择换墙上的插座让所有用户升级系统或者买一个转换头。兼容包就是那个转换头。安卓早期版本迭代很快每个新版本都会加一批新类、新控件、新方法。比如 Fragment 是在 API 11 才进入系统框架的但你的应用想覆盖 API 7 以上的设备怎么办系统里没有这个类直接写就崩溃。兼容包的做法是把新类的实现自己带一份打包进你的应用里运行时优先用系统自带的系统没有就用包里自带的。这样同一份代码在新手机上走系统实现在老手机上走兼容实现用户无感。v4 包管的是最基础的那批兼容类Fragment、ViewPager、NotificationCompat、Loader、各种 Compat 结尾的工具类。v7 包则是在 v4 的基础上往上叠最典型的就是appcompat它提供了AppCompatActivity、Toolbar这些让界面在新老系统上表现一致的组件。所以你会看到 v7 依赖 v4两个经常一起出现。2.2 为什么现在还要了解它你可能会问现在都什么年代了新项目直接用 AndroidX 不就行了还学这两个老 jar 干嘛这话对一半。新项目确实应该用 AndroidX但现实里大量存量项目、老教程、第三方 SDK 的示例代码仍然是 support 库的写法。你接手一个老项目打开一看满屏android.support.v7.widget.RecyclerView如果不知道它是什么、和 AndroidX 什么关系连报错都看不懂。更实际的是很多新手照着网上几年前的教程敲代码导包时 IDE 提示找不到android.support.v4.app.Fragment然后就卡住了。这个卡点的根源就是没搞清 support 库和 AndroidX 是两套并行的兼容方案不能混用。了解 v4 和 v7本质上是了解安卓兼容性这段历史让你在看老代码时不发怵在迁移时知道自己在改什么。提示如果你正在新建项目直接用 AndroidX不要主动引入 support 库。这一章讲它是为了让你读懂存量代码不是让你在新项目里用它。2.3 两个包的分工一张表看清包名最低兼容主要提供典型类support-v4API 4基础兼容组件Fragment、ViewPager、NotificationCompatsupport-v7-appcompatAPI 7界面兼容与主题AppCompatActivity、Toolbar、AppCompatTextView这张表不用背记住一句话就行v4 打地基v7 盖界面。实际项目里 v7 会依赖 v4所以两个 jar 常常成对出现。你看到项目 libs 目录下同时躺着这两个文件说明这是一个用 support 库体系搭建的老项目。3. 第一个例子怎么跑从零搭一个能用的最小工程3.1 先确认你的工具链入门阶段最容易翻车的地方不是代码写错而是环境没对齐。support 库是配合旧版构建工具和旧版 IDE 使用的如果你用的是最新版开发工具新建项目默认就是 AndroidX硬塞 support 库会各种冲突。所以第一步不是写代码而是确认你手上是什么环境。入门的话建议先分清两条路一条是「读老项目」你只需要能打开、能编译、能看懂不必自己从零配另一条是「自己搭一个 support 库的最小例子」这条适合想彻底搞明白依赖关系的人。下面走第二条用最朴素的方式手动配一次配完你就懂那些自动生成的配置在干什么了。先检查你的构建配置文件里有没有这两行关键设置// build.gradle模块级 android { compileSdkVersion 28 // 编译用哪个版本的 SDK defaultConfig { minSdkVersion 15 // 最低支持到 API 15 targetSdkVersion 28 // 目标版本 } }minSdkVersion决定了你的应用能装到多老的手机上它必须大于等于兼容包要求的最低 API。compileSdkVersion是你编译时参照的 SDK 版本写高了低版本工具可能不认。这两个值在老项目里通常是 28 及以下因为 support 库在 AndroidX 推出后就停止更新了。3.2 把两个 jar 放进项目最原始的做法是手动放 jar。在模块目录下建一个libs文件夹把android-support-v4.jar和android-support-v7-appcompat.jar复制进去然后在构建配置里声明依赖dependencies { // 本地 jar 依赖fileTree 表示把 libs 下所有 jar 都引入 implementation fileTree(dir: libs, include: [*.jar]) }fileTree的意思是「把这个目录下匹配规则的文件都当成依赖」dir指定目录include指定后缀。这样写的好处是不用一个个列文件名坏处是目录里混进无关 jar 也会被引入。放完同步一下工程如果 IDE 不再标红android.support.v4.app.Fragment说明依赖生效了。注意v7 的 appcompat 在较新版本里是以 aar 形式分发的纯 jar 可能缺少资源文件导致主题相关代码报错。如果你手动放 jar 后遇到资源找不到的问题优先怀疑这一点而不是你的代码写错了。3.3 写一个用到兼容类的界面依赖通了写个最小验证一个继承自AppCompatActivity的 Activity里面放一个Fragment。这段代码的目的不是做功能而是验证两个包都能被正确加载。// 继承 v7 的 AppCompatActivity而不是系统的 Activity public class MainActivity extends AppCompatActivity { Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // 使用 v4 的 FragmentManager 管理 Fragment getSupportFragmentManager() .beginTransaction() .replace(android.R.id.content, new DemoFragment()) .commit(); } } // 继承 v4 的 Fragment保证老系统也能用 class DemoFragment extends Fragment { Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { // 返回一个最简单的文本视图 TextView tv new TextView(getActivity()); tv.setText(兼容包跑通了); return tv; } }几个关键点解释一下。AppCompatActivity来自 v7它内部帮你处理了主题和标题栏的兼容getSupportFragmentManager()来自 v4注意方法名里带Support这是兼容包的标志系统原生的叫getFragmentManager()。Fragment也导的是 v4 的包不是android.app.Fragment。导包时 IDE 可能给你两个选项选错一个就可能在老设备上崩这是新手最常见的翻车点之一。跑起来看到屏幕上出现「兼容包跑通了」说明 v4 和 v7 都正常工作了。这时候再回头看项目结构你就能对上号哪个 jar 提供了哪个类为什么方法名带 Support 前缀。4. 避坑指南新手最容易踩的五个坑4.1 坑一support 库和 AndroidX 混着用现象编译报错提示类重复或者找不到符号错误信息里同时出现android.support和androidx两个包名。原因AndroidX 是 support 库的继任者两套库的类功能重叠但包名不同构建工具不允许它们共存。你从老教程复制了一段 support 写法又在新工程里默认引入了 AndroidX冲突就来了。解决二选一。新项目统一用 AndroidX把老代码里的android.support.v4.app.Fragment改成androidx.fragment.app.FragmentAppCompatActivity改成androidx.appcompat.app.AppCompatActivity。老项目如果暂时不迁移就在构建配置里关掉 AndroidX 开关别两边都开。4.2 坑二导包导成了系统原生类现象代码能编译但在低版本手机上运行时崩溃日志里是ClassNotFoundException或NoSuchMethodError。原因Fragment、Activity这些名字系统里也有IDE 自动导入时可能选了android.app.Fragment而不是android.support.v4.app.Fragment。在新手机上系统类存在跑得好好的到老手机上系统没有这个类直接崩。解决养成看 import 区的习惯凡是兼容包提供的类包名里一定带support。写完一个文件扫一眼 import比事后查崩溃日志省事得多。4.3 坑三只放了 v7 没放 v4现象编译时报错提示找不到android.support.v4下的某些类。原因v7 的 appcompat 内部依赖 v4 的基础类两个包是上下层关系。只引入 v7相当于盖了二楼没打地基。解决两个一起引入。用 jar 手动管理时容易漏用依赖管理工具时通常会自动带上传递依赖这也是推荐用依赖声明而不是手动拷 jar 的原因之一。4.4 坑四minSdkVersion 设得比兼容包要求还低现象构建工具直接报错提示最低 SDK 版本不满足依赖要求。原因兼容包本身有最低 API 要求v7 要求 API 7 以上。你把minSdkVersion设成 5等于要求库支持它自己都不支持的版本。解决把minSdkVersion调到兼容包要求之上。实际项目里这个值通常远高于 7所以这个问题多出现在照抄老配置的时候。4.5 坑五以为换了 AndroidX 就万事大吉现象迁移到 AndroidX 后某些第三方 SDK 的示例代码编译不过报的还是 support 相关的错。原因AndroidX 只替换你自己项目里的类第三方库如果内部还引用 support 库需要它自己发布 AndroidX 版本或者你找替代方案。解决先看报错来自哪个库查这个库有没有新版本。没有的话评估能不能换库或者把这个库的调用隔离到独立模块里单独处理。迁移不是一键操作血泪经验是先迁自己的代码再逐个处理第三方依赖。5. 下一步学什么从读懂兼容包到理解依赖管理走到这里你已经能认出 v4 和 v7、能配出一个最小工程、能跑通一个用到兼容类的界面。接下来该往哪走我的建议是不要把精力花在背 support 库的类清单上而是顺着它去理解「依赖管理」这件事这才是能迁移到其他技术栈的能力。具体路径可以分三步。第一步把你手上这个最小工程里的手动 jar 依赖改成用依赖坐标声明观察构建工具是怎么自动解析传递依赖的。第二步找一个用 support 库的老项目尝试把其中一个模块迁移到 AndroidX记录每一步报错和改法这个过程比看十篇教程都管用。第三步回头看看你引入的每个库问自己它最低支持什么版本、依赖了谁、被谁依赖。能回答这三个问题你对项目结构的掌控力就上了一个台阶。下面这张表可以作为你自查的清单阶段目标判断标准认得出看到 support 类知道来自哪个包能说出 v4 和 v7 的分工配得上能手动配出一个可编译的工程依赖同步后不标红跑得通兼容类在低版本设备上不崩界面正常显示迁得动能把一个模块从 support 迁到 AndroidX编译通过且功能不变我第一次接触这两个 jar 的时候图省事直接照抄了别人的 libs 目录结果 v7 缺资源文件主题一直报错查了大半天才发现是 aar 和 jar 的区别。从那以后我每次引入依赖都强制自己先看清楚它是 jar 还是 aar、有没有传递依赖再决定怎么放。这个习惯后来帮我省掉了无数次类似的排查。希望帮到你。本文还有配套的精品资源点击获取