简介这份资源面向Android开发初学者与需要维护旧项目的工程师提供android-support-v4.jar与android-support-v7-appcompat.jar两个经典兼容库及其配套工程文件用于解决低版本系统无法原生使用Fragment、ActionBar与Material Design组件的问题。压缩包共447个文件以223个xml布局与资源定义、213个png图片素材为主另含3个java源码、2个jar核心库及readme、properties等配置说明整体约2.05MB结构接近可直接导入的AppCompat示例工程。已有237人学习下载。通过其中的jar包与资源文件读者可理解v4库对API 4及以上Fragment、Loader等组件的支持方式以及v7库如何借助AppCompatActivity在API 7及以上实现ActionBar与主题样式兼容并了解其在API 23及暗黑模式下的延续价值为迁移至AndroidX打下基础。1. 两个 jar 包为什么现在还有人翻出来用上周帮一个做工业手持终端的哥们看项目他们接手的是一套 2015 年前后定型的 Android 采集程序源码里赫然躺着android-support-v4.jar和android-support-v7-appcompat.jar两个文件没有 Gradle 依赖没有 AndroidX全靠 libs 目录硬塞。他问我这俩东西到底还能不能用要不要换成 AndroidX。这个问题其实很典型——不是所有项目都有条件做迁移尤其是那些跑在定制 ROM、老 SDK、离线环境里的设备端程序。这两个 jar 包解决的核心问题就一个让低版本 Android 也能用上高版本才有的 API 和 UI 组件。v4 管的是 Fragment、ViewPager、Loader、NotificationCompat 这类基础兼容层v7-appcompat 管的是 ActionBar、AppCompat 主题、Material 风格控件。适合谁适合维护存量老项目、做设备端定制开发、或者教学环境里需要理解 Android 兼容机制的人。如果你是新起项目直接上 AndroidX别回头。2. 拆开看v4 和 v7-appcompat 各自管什么2.1 v4 的职责边界与常见误用android-support-v4.jar这个名字里的 “v4” 指的是最低支持 Android 1.6API 4不是只给 Android 4.x 用的。它里面塞了一堆兼容类最常用的几个android.support.v4.app.Fragment/FragmentManager在 API 11 之前Fragment 是系统没有的全靠这个包模拟。android.support.v4.view.ViewPager翻页容器至今很多老项目还在用。android.support.v4.app.NotificationCompat统一通知构建方式避免不同版本 API 差异。android.support.v4.content.LocalBroadcastManager应用内广播绕过系统广播的一些限制。常见误用是把它当成“低版本专用”在高版本项目里也硬塞结果和系统类冲突。比如你在 API 21 的设备上同时 import 了android.app.Fragment和android.support.v4.app.Fragment编译能过运行时 FragmentManager 拿到的实例类型对不上直接崩。血泪经验一个项目里只保留一套 Fragment 体系要么全系统原生要么全 support。2.2 v7-appcompat 的依赖链与主题机制android-support-v7-appcompat.jar不是孤立的它依赖 v4而且带资源文件。你光把 jar 丢进 libs 是不够的还得把它的 res 目录合并进来否则Theme.AppCompat找不到编译期就报No resource found that matches the given name。它主要提供android.support.v7.app.ActionBarActivity后来是AppCompatActivity让低版本也有 ActionBar。android.support.v7.widget.Toolbar可嵌入的标题栏。Theme.AppCompat.*系列主题统一 Material 风格。依赖关系是这样的v7-appcompat 的 jar 里引用了 v4 的类所以两个 jar 必须同时存在且版本要匹配。我见过有人只更新了 v7 的 jarv4 还是旧的结果NoClassDefFoundError在启动页就炸了。2.3 版本对应关系别拿错 jar这两个包在 Android 9.0API 28之后就不再更新了最后一个版本是 28.0.0。如果你从旧项目里翻出来的 jar可以用unzip -l看一下里面的AndroidManifest.xml或者META-INF里的版本信息。常见版本对应support 版本对应 compileSdk备注23.4.0API 23最后一个 23.x很多老项目停在这24.2.1API 24过渡版本部分 API 有变动25.4.0API 25稳定但和 AndroidX 不兼容26.1.0API 26开始要求 Gradle 插件升级27.1.1API 27最后一个 27.x28.0.0API 28终版之后全面转 AndroidX拿错版本的典型症状是编译通过运行时在AppCompatActivity.onCreate里抛IllegalStateException提示主题不对。这时候先查build.gradle里的compileSdkVersion和 support 库版本是否匹配。3. 手动集成不靠 Gradle 把两个 jar 塞进项目3.1 目录结构与文件放置假设你拿到的是一个 Eclipse 时代的项目或者一个纯命令行构建的工程。标准做法是MyLegacyApp/ ├── libs/ │ ├── android-support-v4.jar │ └── android-support-v7-appcompat.jar ├── res/ │ ├── values/ │ │ └── styles.xml │ └── ... ├── AndroidManifest.xml └── src/ └── com/example/legacy/MainActivity.java注意v7-appcompat 的资源不在 jar 里你需要单独把它的 res 目录内容合并到项目的 res 下。常见做法是从 SDK 的extras/android/support/v7/appcompat/里拷贝res目录然后覆盖合并。合并时注意values/styles.xml里的主题名不要冲突。3.2 命令行编译与 dx 打包如果你用javacdxaapt手动构建顺序很重要# 1. 编译 Java 源码classpath 包含两个 jar javac -source 1.7 -target 1.7 \ -bootclasspath $ANDROID_SDK/platforms/android-28/android.jar \ -classpath libs/android-support-v4.jar:libs/android-support-v7-appcompat.jar \ -d bin/classes \ src/com/example/legacy/*.java # 2. 打包资源注意 -I 指定 android.jar-S 指定 res 目录 aapt package -f -m -J gen/ \ -M AndroidManifest.xml \ -S res/ \ -I $ANDROID_SDK/platforms/android-28/android.jar # 3. 把资源编译结果和 classes 一起 dx 成 dex dx --dex --outputbin/classes.dex \ bin/classes/ \ libs/android-support-v4.jar \ libs/android-support-v7-appcompat.jar # 4. 最后用 aapt 打包 apk再签名 aapt package -f -M AndroidManifest.xml -S res/ -I android.jar -F bin/app.unaligned.apk逻辑说明javac阶段只做语法和类型检查jar 里的类不会被打进 classes 目录dx阶段才把 jar 里的字节码一起转成 dex。参数--output指定输出 dex 文件后面跟的是所有需要转换的 class 目录和 jar。坑在于如果两个 jar 里有重复类比如都带了android.support.v4.app.Fragmentdx 会报Ill-formed class或者直接覆盖导致运行时行为不确定。所以务必确认 v7 的 jar 里没有重复打包 v4 的类。3.3 AndroidManifest 与主题配置集成 v7-appcompat 后Activity 必须继承AppCompatActivity并且主题要改成Theme.AppCompat或其子主题。在AndroidManifest.xml里application android:themestyle/AppTheme activity android:name.MainActivity android:themestyle/AppTheme.NoActionBar intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity /applicationres/values/styles.xml里resources style nameAppTheme parentTheme.AppCompat.Light.DarkActionBar item namecolorPrimary#3F51B5/item item namecolorPrimaryDark#303F9F/item item namecolorAccent#FF4081/item /style style nameAppTheme.NoActionBar item namewindowActionBarfalse/item item namewindowNoTitletrue/item /style /resources参数说明colorPrimary控制 ActionBar 背景colorPrimaryDark控制状态栏colorAccent控制控件高亮色。如果这些属性在低版本设备上不生效检查是否用了Theme.AppCompat而不是系统主题。常见翻车点在AndroidManifest里写了android:themeandroid:style/Theme.Material然后 Activity 继承AppCompatActivity启动直接崩因为 AppCompat 要求主题必须是 AppCompat 系列。4. 避坑排查五个让老项目起死回生的关键点4.1 现象启动即崩日志显示NoClassDefFoundError: android.support.v4.app.Fragment原因v7-appcompat 的 jar 里引用了 v4 的类但 v4 的 jar 没有一起打包进 dex或者打包顺序导致 v4 的类被覆盖。解决确认dx命令里同时包含两个 jar并且 v4 的 jar 在 v7 之前。如果是 Gradle 项目检查dependencies里是否同时有com.android.support:support-v4和com.android.support:appcompat-v7版本号必须一致。4.2 现象编译报No resource found that matches the given name Theme.AppCompat.Light原因v7-appcompat 的资源没有合并到项目 res 目录或者合并时values文件夹被覆盖。解决从 SDK 的extras/android/support/v7/appcompat/res里拷贝values、values-v11、values-v14等目录合并到项目 res 下。注意不要直接覆盖整个 res而是逐文件合并。如果用的是 Android Studio检查build.gradle里是否加了compile com.android.support:appcompat-v7:28.0.0加了就不需要手动拷贝资源。4.3 现象运行时IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity原因Activity 继承了AppCompatActivity但AndroidManifest里指定的主题不是Theme.AppCompat系列。解决把android:theme改成style/AppTheme并在styles.xml里让AppTheme继承Theme.AppCompat.Light.DarkActionBar。如果用了Toolbar替代 ActionBar主题里加windowActionBarfalse和windowNoTitletrue。4.4 现象ViewPager滑动卡顿或者Fragment切换时状态丢失原因v4 的ViewPager和FragmentPagerAdapter在低版本上对setOffscreenPageLimit处理不同默认缓存页数太少。解决调用viewPager.setOffscreenPageLimit(3)增加缓存页数。如果 Fragment 状态丢失检查是否用了FragmentPagerAdapter而不是FragmentStatePagerAdapter后者会保存状态但内存占用更高。参数3是经验值根据页面复杂度调整太大反而吃内存。4.5 现象dx打包时报trouble processing javax/xml/...或Ill-formed class原因两个 jar 里有重复类或者 jar 本身被混淆过dx 无法解析。解决用unzip -l列出两个 jar 的类清单对比重复项。如果 v7 的 jar 里包含了 v4 的类用zip -d删掉重复的 class 文件或者换用官方提供的appcompat-v7的 aar 包aar 里不会重复打包 v4。另一个办法是升级 dx 工具版本旧版 dx 对 Java 8 字节码支持不好。5. 从 support 到 AndroidX迁移判断与一个验证技巧如果你维护的项目还在用这两个 jar迟早要面对迁移问题。但迁移不是无脑换包名先做判断项目是否还在活跃开发如果只是维护状态设备固定、系统固定那继续用 support 库没问题别为了“技术先进”去折腾。如果项目要上新功能、要适配新设备那 AndroidX 是唯一选择。迁移的核心动作是在gradle.properties里加android.useAndroidXtrue和android.enableJetifiertrue然后把所有com.android.support依赖换成对应的androidx包。但手动集成 jar 的项目没法用 Jetifier只能改源码里的 import。常见映射support 包AndroidX 包android.support.v4.app.Fragmentandroidx.fragment.app.Fragmentandroid.support.v7.app.AppCompatActivityandroidx.appcompat.app.AppCompatActivityandroid.support.v4.view.ViewPagerandroidx.viewpager.widget.ViewPagerandroid.support.v7.widget.Toolbarandroidx.appcompat.widget.Toolbar改完 import 后资源引用也要改style/Theme.AppCompat变成style/Theme.AppCompatAndroidX 里主题名没变但依赖包变了。验证迁移是否彻底我一般用这个命令扫一遍源码grep -rn android.support src/ res/ AndroidManifest.xml如果输出为空说明没有遗漏。但注意有些第三方 jar 里可能还引用了 support 类这时候要么找 AndroidX 版本要么用 Jetifier 处理仅限 Gradle 项目。手动集成项目只能换 jar。从那以后我每次接手老项目第一件事就是跑一遍这个 grep确认 support 库的残留范围再决定是修还是迁。希望帮到你。本文还有配套的精品资源点击获取