在Android开发中，进行兼容性测试时，通常需要从哪些方面来设计测试范围和用例？

回答思路

1. 【回答框架 1】兼容性测试核心是应对Android平台碎片化，需覆盖硬件、系统版本、屏幕尺寸、厂商定制四个维度。硬件上重点验证CPU架构（armeabi-v7a、arm64-v8a、x86）对so库的加载，以及不同内存、摄像头、传感器等配置下的表现。
2. 【回答框架 2】系统版本方面，需覆盖主流API级别（如API 21以上），验证权限模型变更、后台限制、存储分区等行为变化对应用功能的影响。可结合云真机或热机型top榜单来制定优先级。
3. 【回答框架 3】屏幕与分辨率适配需检查不同尺寸、像素密度和刘海屏/挖孔屏的布局显示、资源加载和手势交互。厂商定制ROM（如MIUI、EMUI）可能改变系统行为，需重点测试后台存活、通知权限、自启动限制等场景。
4. 【回答框架 4】测试手段包括真机测试、模拟器测试、云测试平台（如Firebase Test Lab）、自动化框架（Appium、UIAutomator）结合，数据采集需统计崩溃率、ANR率，并利用Crash监控工具（如Bugly、Firebase Crashlytics）反馈现场。
5. 【关键点 1】兼容性测试需覆盖硬件、系统版本、屏幕尺寸和厂商定制四个维度。
6. 【关键点 2】优先级应根据用户设备分布数据（top机型/版本）来确定，而非全量覆盖。
7. 【关键点 3】真机、云测试平台和自动化工具结合可提升覆盖效率并降低维护成本。
8. 【关键点 4】厂商定制ROM的权限与后台行为差异是兼容性风险的高发区，必须专项验证。
9. 【易错点 1】误以为兼容性测试等同于在少量模拟器上运行，忽略厂商定制ROM和真实硬件差异导致的功能异常。
10. 【易错点 2】盲目追求全量覆盖而缺乏优先级，导致成本过高且核心问题未暴露。
11. 【易错点 3】忽略系统版本升级后的行为变更（如运行时权限、后台限制）对旧功能的影响。