1. 这份“二星级”练习卷到底考什么——适合谁、怎么刷才不白费先说个扎心的事实很多干了两年多的Android开发简历上写着“熟悉Android体系”实际遇到module间依赖循环、AGP版本升级把构建搞挂、蓝牙设备连不上只能干瞪眼马上原形毕露。这份“二星级综合练习卷”不是给零基础小白做的概念题也不是给架构师准备的深水区题目它的定位很明确覆盖日常开发最高频、最容易踩坑、面试最常被追问的基础到进阶地带考察的是“你嘴上说会、手上是不是真会”。为什么说“二星级”这个难度标定得挺准因为它既不考你手写Binder底层实现也不考你怎么设计插件化框架但如果你连FileProvider的uri授权路径都配不对、连R8混淆规则导致Release包崩溃都排查不出来那这卷子就会让你很难看。它更像是一面镜子照出你以为会了、实际一碰就碎的知识盲区。适用对象我建议框定在三类人第一类是工作1到3年、准备跳槽面试的Android工程师用来做自测和补漏第二类是带项目的技术负责人可以抽题当作新人试用期的实操考核第三类是自学Android有一段时间、刷了不少教程但没经过系统检验的人这套题的价值在于把零散的知识点串成“见树木也见森林”的体系。这套卷子覆盖的板块我梳理下来大概是六块开发环境与构建链Android Studio、AGP、Gradle、代码保护与包体优化R8、混淆、UI体系动态图标、协调布局、透明度与配色、Framework与系统机制AMS、OTA、APEX、Root边界、硬件与外设蓝牙、I2C、OpenOCD调试、架构设计与工程化MVVM、组件化、跨端适配。每一块我都配了题、配了坑、配了排查思路。刷这套卷子之前我给个建议别开卷别查资料先按自己的本能写答案。写完之后再对照后面的解析重点看“我当时的思路错在哪一步”。这比直接看答案有效十倍。2. 开发环境与构建链的那些“版本恐惧症”从Hedgehog与AGP 8.0说起2.1 一道高频选择题Android Studio Hedgehog 2023.1.1 Patch 2 支持 AGP 8.0 吗这道题在热搜里出现频率极高很多人一看到“Patch 2”就懵了觉得补丁版本会不会影响AGP的兼容范围。答案是支持而且不仅是支持Hedgehog这个版本本身就是为了承接AGP 8.x而发布的稳定版本线之一。先看Android Studio版本和AGP版本的关系很多人以为Android Studio大版本必须对应某个AGP版本实际不是。AS本身是IDE壳子AGP是Gradle插件两者的关系是“AGP要求最低的Gradle版本同时要求最低的AS版本”。Hedgehog 2023.1.1的默认模板创建新项目时会推荐AGP 8.1.x或8.2.x但Patch级别比如Patch 2、Patch 3不影响AGP支持范围它修的是IDE自身的一些bug和性能问题。我实操时的建议如果你用的AS是Hedgehog 2023.1.1 Patch 2新建项目时Gradle插件版本直接选8.1.0以上配合Gradle 8.0以上构建链就很稳。如果你是从老项目升级上来的原来用的是AGP 7.4升到AGP 8.0后有几个点必须处理否则构建直接崩命名空间必须显式声明AGP 8.0开始不推荐也不允许在build.gradle里用package声明包名必须用namespace单独指定。JDK版本要求提升AGP 8.0要求JDK 17如果你本机还是JDK 11要先把Android Studio内置的JBRJetBrains Runtime切好否则会报Unsupported class file major version。BuildConfig默认关闭AGP 8.0默认不再生成BuildConfig类如果你代码里用到BuildConfig.DEBUG或者自定义字段必须在build.gradle里显式开启buildFeatures { buildConfig true }。2.2 构建链的实操命令与排查思路很多搜索结果里出现的“Could not load compiled classes for settings file”这是一道真实的构建故障题。报错的场景一般是这样某个Android工程里执行sync或者buildGradle提示settings文件编译失败。这个问题的常见原因有三个我一个个排查过第一个原因Gradle版本和AGP版本不匹配。Gradle本身有版本要求比如AGP 8.1要求Gradle最低8.0你用Gradle 7.6去跑构建时就会出现settings编译异常。处理方式很直接把gradle-wrapper.properties里的distributionUrl改成匹配版本通常在8.0以上。第二个原因settings.gradle里的插件仓库配置写错。比如pluginManagement块里仓库地址配了无效的镜像或者依赖了内部私有仓库但没配认证。排查时打开gradle的debug日志看具体卡在哪个仓库解析上。第三个原因项目路径包含中文或特殊字符。我确实在一台Windows上遇到过路径里带中文导致Kotlin DSL脚本编译失败把项目挪到纯英文路径后一切正常。这个坑很少被人提但实际踩中的概率不小。提示遇到settings文件编译报错先别急着改代码按“gradle版本 → 仓库配置 → 项目路径 → JDK版本”的顺序逐项排查80%的问题出在这四步里。AGP版本兼容矩阵这个事我建议团队里维护一份对照表避免每个人各自为政。下面是我自己常用的兼容表不一定是最新但足够覆盖大多数公司的存量项目Android Studio 版本推荐 AGP 版本最低 Gradle 版本Hedgehog 2023.1.1 Patch 28.1 ~ 8.28.0Iguana 2023.2.18.38.4Jellyfish 2023.3.18.4 ~ 8.58.6Koala 2024.1.18.58.73. 代码保护与包体优化的实战题R8、混淆规则和“马甲包”的边界3.1 R8到底帮你做了什么——不止是混淆搜索热词里“android r8”出现频率很高R8在AGP 3.4之后接替了ProGuard成为默认的压缩、混淆、优化工具。很多人对R8的认知停留在“把类名变量名改成a、b、c”这就太浅了。R8实际做了四件事**压缩shrinking**把未使用的类、方法、字段从包里干掉**混淆obfuscation**把类名、方法名改成无意义短名称**优化optimization**做内联、常量折叠、去掉无用的分支**预检preverification**给代码加一些运行时校验信息。这四件事里压缩带来的包体收益往往比混淆还大。一个没有配置keep规则的中型项目R8开起来后包体体积能减少10%到20%特别是那些依赖了一大堆第三方库、但只用了一两个API的场景。3.2 混淆规则的常见错误和Keep策略混淆规则的坑我见过太多次了典型的错误有下面几类第一类把整个第三方库全部keep住。有些人图省事直接-keep class com.xxx.lib.** { *; }这样确实不会崩但R8的压缩优化也废了包体蹭蹭往上涨。正确做法是针对性地keep需要反射调用的类、以及被XML引用的自定义View。第二类遗漏了Gson/Jackson等序列化库的泛型信息。如果你的数据类用了TypeToken或者泛型解析R8默认会把泛型签名删掉运行时报ClassCastException或者JsonSyntaxException。解决办法是keep所有数据类的泛型签名-keepattributes Signature -keepattributes *Annotation*第三类JNI方法名被混淆。如果你的项目里有NDK代码Java层的native方法名必须和C/C函数名对应R8混淆后native方法找不到入口直接崩。处理方式-keepclasseswithmembernames class * { native methods; }3.3 “马甲包”混淆和包体标识这个敏感话题热搜里有一条“谷歌android马甲包代码混淆”这个表述我得多说两句。实际操作中多包投放确实会通过改包名、换签名、调整资源混淆策略来做版本区分但这种做法涉及谷歌Play政策层面的合规问题。我个人的观点是代码混淆和技术层面的包体定制是合理需求但如果涉及绕过平台审核、伪装应用身份那就踩到红线了不建议在任何正规工程里这么做。从纯技术角度讲“代码混淆多渠道打包”有一套相对成熟的做法用Gradle的productFlavors配置不同渠道的applicationId、app名称、渠道标识再配合资源混淆比如AndResGuard和R8规则实现不同渠道包的差异化。整个过程是合规的关键在于别做“伪装”那一层。3.4 从一道Release崩溃题看混淆排查思路我给别人review项目时遇到过一个经典崩溃debug包一切正常release包一启动就闪退logcat里只有一行ClassNotFoundException。最开始怀疑是某个类被R8干掉了但实际上问题出在项目里用了HashMap存储带泛型的复杂对象反序列化时反射失败。排查思路可以照着走一遍第一步抓logcat里的完整异常堆栈找到是哪个类找不到。第二步用mapping.txt映射文件把混淆后的类名反推回原始类名。这个文件在app/build/outputs/mapping/release/目录下。第三步在proguard-rules.pro里加上对应的keep规则。第四步重新打包验证同时对比一下包体变化确认没加过头。mapping文件这个工具很多人忽略排查混淆崩溃时它就是救命稻草。建议CI流程里把mapping文件按版本号归档保存线上出问题才能快速回溯。4. UI层的“送分题”和“陷阱题”动态图标、协调布局、透明度和配色4.1 Android动态图标是个“看起来简单、细节很碎”的知识点热搜里“android动态图标主题”和“android图标”一起出现不少人对动态图标的认知还停留在“换个图片资源”。实际上Android 13开始引入的是Themed Icons主题图标它通过Monochrome图层的alpha通道对外部主题化取色图标本身只用单色资源由Launcher根据用户选择的壁纸颜色动态着色。这就意味着你在开发时不能再只画彩色图标必须额外适配一套纯alpha的Monochrome图层。动态图标的适配细节有三个adaptive icon XML结构要完整adaptive-icon里除了background和foregroundAndroid 13以上还可以加monochrome标签。Monochrome图层的安全区所有图层的核心内容都要控制在66%的safe zone里否则桌面会裁掉重要视觉元素。动态主题的兼容处理Android 12以下系统识别不到monochrome图层会退回到普通adaptive icon所以你做设计时要保证三个图层的视觉重心一致。4.2 协调布局Banner为什么你的页面一滑就卡搜“android中协调布局banner”的大概率是遇到了CoordinatorLayout嵌套Banner滚动不流畅的问题。CoordinatorLayout的核心价值是协调子View之间的联动行为常见的组合是AppBarLayout CollapsingToolbarLayout RecyclerView实现头图折叠、标题渐变、列表滚动上推。但很多人用的时候忽略了一个关键点理论上Banner比如ViewPager2应该放在AppBarLayout折叠区内但ViewPager2本身有自己的页面滑动逻辑两个滑动体系叠加协调不好就会出现“手势被吃掉”“滑到一半卡住”的现象。解决办法通常是这样如果Banner只是页面顶部的内容不参与AppBar折叠那就直接放在NestedScrollView或RecyclerView的header里不要放进CollapsingToolbarLayout。如果Banner确实要参与折叠需要给ViewPager2关闭嵌套滚动冲突的干扰通常用requestDisallowInterceptTouchEvent做手势分发处理或者在CoordinatorLayout的Behavior里重写onInterceptTouchEvent。性能问题Banner如果加载的是大图需要做内存缓存和三倍图适配否则滑动卡顿基本是图片加载引起的不全是布局嵌套的锅。4.3 setColor、透明度对照表和设计师的“数字暗号”“android setcolor”“android透明度对照表”这两个热搜词背后是同一个痛点设计师给的色值是#80FFFFFF这种带透明度的工程师要么直接搬过来用要么不懂alpha怎么算。setColor的本质就是把颜色值int传进去这个int包含ARGB四个通道Alpha、Red、Green、Blue。常见的透明度百分比对照我整理了一份可以直接贴进代码注释的表透明度视觉Hex Alpha十进制 Alpha描述100%不透明FF255完全不透90%E6230轻微透明80%CC204能透出背景70%B3179常见蒙层60%99153半透明中档50%80128一半一半30%4D77弱化显示0%透明000完全透明很多人搞不清楚#80FFFFFF和#FFFFFF80的区别前者是透明度80%实际alpha十六进制的80约50%透明度的白色后者是黄色白色但蓝色通道偏低。这个顺序是ARGB不是RGBA写代码的时候一定注意。另外一个实用函数是动态修改控件的透明度view.background.setAlpha(128) // 0-255128即约50%透明度 view.alpha 0.5f // View整体透明度两个API效果不一样setAlpha只作用于背景view.alpha作用于整个View及其内容包括子View。实际开发中很多人混用导致背景和文字透明度不一致设计师一眼就能看出来。4.4 Settings布局那些“看起来简单、复现很难”的偏好设置页搜“android settings布局”的工具人多半是在做App的设置页然后用常规的XML布局硬写写起来烦、样式还不统一。其实Android官方早就提供了一个标准做法PreferenceFragmentCompat。设置页用Preference体系有几个好处自带圆角分组卡片、开关样式统一、数据存储自动走SharedPreferences、不需要手写item的点击事件。我建议每个项目组都尽量用这个体系省下的时间可以用来处理真正的业务逻辑。需要注意的点Settings页面里如果嵌入了自定义View比如头像选择、版本号点击检测更新需要用Preference的子类重写onBindViewHolder或者在XML里用android:layout指定自定义布局。这块很多人不熟容易写出几百行的复杂XML导致性能下降。5. Framework层的系统机制题AMS、APEX、OTA与Android 14的Root边界5.1 AMS这道题到底该掌握到什么程度搜“android ams”的人一部分是面试考前突击一部分是系统应用开发遇到实际性能问题。AMS全称ActivityManagerService它是SystemServer里管理系统所有Activity、Service、BroadcastReceiver等组件生命周期的核心服务。平时我们写的startActivity最终会通过Binder IPC调用AMS的startActivity方法AMS再去做进程调度、任务栈管理、生命周期回调。这道题的常规考点有这么几个AMS与ActivityThread的关系ActivityThread是应用进程的UI线程入口它通过ApplicationThread这个Binder接口接收AMS的调度指令。任务栈与启动模式standard、singleTop、singleTask、singleInstance四种模式在AMS里对应的其实是TaskRecord的入栈出栈逻辑。ANR的触发机制AMS监控输入分发、广播、Service执行的时间超时就会弹ANR。实操层面的建议是不一定需要你手写AMS源码但必须能画出一条“点击桌面图标到Activity显示”的完整链路。这条链路里包含了Launcher进程、SystemServer进程、应用进程三者的跨进程通信能讲清楚这条链路面试官就能判断你是有真实项目经验还是只会背概念。5.2 APEX模块化系统组件的新形态“android apex”这个搜索词相对冷门但如果你接触过系统定制、OTA升级就绕不开它。APEX是Android 10引入的一种包格式可以理解为系统组件的“模块化升级包”。传统系统组件打包在system分区里升级必须整包OTAAPEX则允许单独升级某个系统模块比如时区数据、网络栈、媒体编解码器。它的本质是Android对Bionic库和系统服务的一种保护机制。开发者在做预装系统应用时如果涉及APEX模块需要明确两点第一普通App不能依赖APEX里的私有API第二调试时发现某功能失效优先检查对应APEX模块的版本和状态。查看设备上APEX包的常用命令adb shell pm list packages --apex-only5.3 OTA升级与系统稳定性——测试人员和开发的协作点“android ota”也是热搜词这说明很多人在做系统升级或整机定制。OTA升级的流程大致是系统下载升级包 - 校验签名 - 进入recovery模式 - 应用升级 - 重启。宕机、断电、升级包损坏都可能导致设备变砖所以OTA的稳定性测试非常关键。做App开发的工程师可能觉得OTA离自己很远但有一类实际问题很常见应用在OTA升级后数据缓存失效、权限被重置、甚至直接崩溃。原因通常是系统升级后应用沙箱标识符或签名校验发生变化。这类问题排查起来费时费力更合理的做法是在升级前做数据迁移方案而不是升级后打补丁。5.4 Android 14的Root现状一句“可以但不建议”背后的技术细节“android 14 root”这个热搜词背后大概率是一些爱折腾的用户在刷机。技术层面Android 14的Root方案相比以前更复杂因为Google加强了verified boot的完整性校验大多数新设备的bootloader锁定状态下无法直接root。解锁bootloader、刷入修补过的boot.img、使用Magisk修补init_boot是当前的主流路线。Root这件事从工程角度谈我的态度是做安全评估、做自动化测试工具时root过的设备可以作为测试环境之一做线上业务、处理用户敏感数据时root环境必须被检测并限制。应用层通过su文件检测、SafetyNet或Play Integrity来判断设备状态这件事值得每个Android开发知道原理但涉及具体绕过手段就不展开了那是另一个不适宜公开讨论的领域。6. 硬件与外设题的调试思路蓝牙、I2C和OpenOCD在Android上的连接姿势6.1 Android蓝牙开发的经典大坑搜索不到、连不上、配对失败“android蓝牙”几乎是每个做IoT或外设连接功能的开发都会搜的词。蓝牙开发分传统蓝牙Bluetooth Classic和低功耗蓝牙BLE两条线现在主流是BLE但坑依旧不少。坑一权限声明不完整。从Android 12API 31开始蓝牙相关权限从运行时权限升级为需要同时申请精确位置权限部分情况下和蓝牙专属权限BLUETOOTH_SCAN、BLUETOOTH_ADVERTISE、BLUETOOTH_CONNECT。很多人只声明了旧权限在高版本设备上直接闪退或搜索不到设备。坑二回调里的主线程问题。蓝牙的扫描结果回调、GATT连接回调默认不一定在主线程如果你在回调里直接更新UI会偶发崩溃。处理方式是统一用Handler或者协程切换到主线程。坑三设备缓存问题。BLE设备连接过一次后设备的GATT缓存可能会保留一些旧的service信息导致信号变化后App还认为是旧的。连接前主动清一下缓存Method refreshMethod device.getClass().getMethod(refresh) refreshMethod.invoke(device)6.2 I2C-Tools在Android上怎么用——当你的板子上有传感器“i2c-toos 在 android 上使用”这个搜索词比较小众但做嵌入式、做硬件调试的人肯定会遇到。I2C是一种低速总线协议传感器、触摸屏、EEPROM等外设都靠它通信。在Android系统里I2C调试工具通常是i2cdetect、i2cget、i2cset这些命令但它们默认不在Android系统的shell里需要自己编译或从源码里带过去。在Android设备上使用I2C工具的第一步是确认设备节点是否存在ls /dev/i2c-*。如果有节点但没有读写权限通常需要root。对于普通App开发者I2C一般通过内核驱动封装成Input子系统或者HAL接口不需要直接操作。但如果你在做驱动调试手上有i2cdetect -y 1这类命令就能快速确认总线上挂了哪些设备地址比自己盲猜靠谱得多。6.3 OpenOCD在Android调试里的真实用途“android openocd”这个搜索词有两个方向一个是用OpenOCD调试Android设备的芯片比如Rockchip、Allwinner方案另一个是在Android设备上运行OpenOCD做嵌入式 MCU 调试。前者比较常见做嵌入式方案定制的人会用JLink或者CMSIS-DAP连接芯片OpenOCD负责提供GDB Server接口。我实际用过的一个场景是一块Android平板外接了一块MCU板子MCU的固件调试用的是OpenOCDAndroid端通过串口和MCU通信。两者各司其职Android负责业务逻辑MCU负责数据采集。这里的教训是别试图用Android去直接跑OpenOCD做高性能固件调试Android的USB Host和调试器兼容性都有限干净利落的方式是用PC端连接调试器Android只管业务。7. 架构设计与工程化的综合题MVVM、模块化与“能用但不好改”的代码7.1 MVVM到底解决了什么问题——一道送命题搜“android studio mvvm代码示例”的人大概率是刚学架构模式想找个模板。MVVM的核心不是把Activity里的代码搬家到ViewModel而是通过数据驱动UI的方式让Activity只做View层的事情业务逻辑交给ViewModel数据仓库负责数据源管理。我见过很多“MVVM”项目其实只是把代码从Activity挪到了ViewModel页面里还是到处findViewById和setText本质上还是MVC。真正的MVVM应该有一个稳定的数据流UI事件 - ViewModel处理 - 数据源更新 - LiveData/StateFlow通知 - UI自动刷新。一个极简的MVVM示例骨架class MainViewModel : ViewModel() { private val _userName MutableLiveDataString() val userName: LiveDataString _userName fun loadUser() { viewModelScope.launch { val result repository.getUser() _userName.value result.name } } } class MainActivity : AppCompatActivity() { private val viewModel: MainViewModel by viewModels() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) viewModel.userName.observe(this) { name - binding.userName.text name } binding.loadButton.setOnClickListener { viewModel.loadUser() } } }这段代码的关键点Activity只做“把数据绑到UI”这一件事点击事件也只是告诉ViewModel“该加载了”具体的网络请求、数据缓存、状态管理都在ViewModel里。这样单元测试时可以只测ViewModel不用启动Activity。7.2 模块化拆分的边界别为了“架构感”而过度设计架构设计方面后来我发现一个常见问题很多人对“AGP 8”和“Maven中央仓库”这些构建概念没搞清楚就着手做多module拆分结果构建时间翻倍、依赖地狱频发。模块化拆分的边界应该是按业务和复用的维度切而不是按代码分层切。比如你做了一个通用的网络库把它拆成一个module多个业务模块共用这是合理的。但如果只是为了“逻辑分层好看”把utils、network、database、widget全拆成独立module最后所有module都依赖utils那这个utils是不是module已经无所谓了反而增加同步和构建成本。我实际项目里常用的最小拆分方案app壳工程负责组装和依赖注入common通用工具、基础组件、主题资源按业务细分module_login、module_home、module_mine7.3 组件通信的“优雅”和“克制”多个module之间怎么通信是MVVM之外另一个高频考点。最简单的方案是直接用接口回调但module多了之后接口回调会变成“回调套回调”维护起来很痛苦。这时候可以考虑引入路由框架如ARouter或者用事件总线。路由框架的核心价值不是让代码更“高级”而是解耦login模块不用直接持有home模块的类引用只需要通过路径跳转。这会给团队的代码导航带来灵活性但也要求团队有严格的路径命名规范否则路由表会变成一锅粥。7.4 协程和FlowStateFlow和LiveData怎么选MVVM里数据源用LiveData还是StateFlow是个经常被问到的选择题。LiveData是Android生态的原生产物天然感知生命周期不需要处理取消订阅StateFlow是Kotlin协程流需要配合repeatOnLifecycle来收集写起来稍微复杂但能力更强支持操作符链、背压处理、冷热流转换。我最近两年的项目里新代码都优先用FlowStateFlowLiveData只留在老代码里。原因很简单Flow可以统一网络请求、数据库操作、UI状态这一整条链路的写法代码可读性和可测试性都好于LiveData。当然如果你团队里大部分人不熟悉协程强行全上Flow开发效率不一定比LiveData高这需要权衡团队的实际情况。8. 跨端与系统适配的开放题HarmonyOS NEXT、iOS最低版本与Android碎片化8.1 HarmonyOS NEXT和“a支持iOS 11.0及以上”这类描述怎么理解热搜里“harmonyos next 5.0及以上”和“a支持ios 11.0及以上及android 4.0及以上”同时出现说明现在很多产品都在做跨端适配版本兼容声明成了标配。但“支持某个系统版本”这句话的含金量差别很大关键在于你测过哪些系统行为。HarmonyOS NEXT是一个彻底去掉了Android兼容层的系统从内核到应用框架都是鸿蒙自己的所以一个App想在HarmonyOS NEXT上跑基本意味着需要单独做一套鸿蒙原生版本或者用跨端框架比如Flutter、RN做一套“代码多端复用”的迁移。这个版本的适配工作量和Android/iOS适配完全不是一个量级提前评估很重要。8.2 Android版本碎片化不是一句空话——4.0和14的差距有多大支持Android 4.0意味着你的App要兼容从API 14到API 34这20个大版本中间经历了ColorPrimary暗色主题、运行时权限、分区存储、前台服务限制、蓝牙权限拆分等无数次行为变更。做这样一个兼容声明不是在build.gradle里写一行minSdkVersion 14就完事它背后是成体系的兼容策略代码里必须有大量的Build.VERSION.SDK_INT判断分支。资源目录要用values-v21、values-v23来区分不同版本的样式和主题。第三方库也要确保它们的minSdkVersion不高于你的。核心逻辑必须在Android 4.4和Android 14两台不同版本的设备上做完整的功能巡检。8.3 适配层的“版本判断”设计如何写得优雅版本判断最容易写成一坨if-else比如if (Build.VERSION.SDK_INT 33) { // 新版本逻辑 } else if (Build.VERSION.SDK_INT 29) { // 中间版本逻辑 } else { // 旧版本逻辑 }一旦系统行为变更多了代码就开始失控。更优雅的做法是用策略模式或者接口隔离把不同版本的行为差异封装成独立的实现类通过工厂方法按版本分发。这里我不推荐一上来就引入重量级架构但建议至少做到版本差异逻辑集中管理别散落在各个业务方法里。9. 刷完这套题之后我建议你这样沉淀这套“二星级综合练习卷”真正想检验的不是你会背多少API而是你在真实工程里的判断力。比如AGP升级遇到构建失败你是直接百度报错信息还是能根据兼容矩阵快速锁定范围R8混淆导致Release崩溃你是一遍遍试keep规则还是能通过mapping文件精准定位从我自己的经验看刷题最有价值的产出物不是分数而是一份“个人盲区清单”。我建议你准备一个Markdown文件或者笔记本把每道错题的原因、排查思路、最终解法记下来然后对照着去读源码、看官方文档、分析实际项目。还有一个小技巧很多问题不是靠记忆解决的而是靠“快速定位的能力”。比如你知道AGP版本和Gradle版本存在兼容关系不需要背下每个版本号只需要知道去哪里查官方对照表就能节省大量时间。这套卷子里的大多数题目本质上考的都是“你有没有建立一套高效的排查框架”而不只是“记没记住某个知识点”。最后说一句实在的Android开发这个领域变化太快Android Studio一年两个大版本AGP每年都在迭代R8的规则也在不断调整。保持“练习卷”心态每隔半年给自己组一套题做一遍是抵御技术焦虑最务实的办法。你手头的这份二星级卷子已经覆盖了不少高频场景能踏实吃透它你就已经超过了相当一部分同行。