Android开发为何不选尽可能低的minSdkVersion？有哪些缺点？

很多开发者刚接触Android开发时都会觉得，把minSdk拉到系统允许的最低阈值、把targetSdk升到最新版本，理论上能覆盖最多的设备范围。但实际踩过坑的开发者都知道，这种配置的实际性价比极低，缺点主要集中在这几个方面：

• 冗余兼容代码大幅抬升开发成本
  现代Android开发普遍依赖Jetpack组件、Kotlin语言特性，这些工具链本身就对minSdk有明确的最低要求：比如CameraX要求minSdk不低于API 21，协程在低版本上需要额外引入兼容库，甚至很多基础的系统能力（比如动态权限申请、分区存储）在低于对应版本的系统上根本没有原生实现。如果强行把minSdk压到过低的水平，你就得针对每一个版本分支写大量的判断逻辑，甚至要自己手写系统已经淘汰的老旧功能实现，代码维护的复杂度会指数级上升。
• 第三方生态的适配断层会带来连带问题
  目前绝大多数主流商用SDK（支付、推送、统计、社交分享）、热门开源库，近三年发布的版本都已经逐步放弃了对低版本系统的支持。为了兼容老设备，你只能选用这些库已经停止维护的老旧版本，这些老旧版本不仅功能缺失、缺少安全修复，本身还可能在新系统上出现适配崩溃，反而会影响高版本主流用户的体验。
• 测试与崩溃率的投入产出比完全失衡
  从活跃用户占比来看，目前全渠道Android 7.0以下系统的活跃用户占比已经跌到个位数，这些低版本设备的硬件碎片化程度、厂商系统魔改程度远高于新版本设备。为了覆盖这部分极低占比的用户，你需要采购多台不同品牌、不同配置的老设备做全量测试，或是承担云测试平台上老机型的高额服务成本；而这些额外投入带来的用户增长收益，远抵不上开发、测试环节的人力消耗，甚至因为兼容分支过多引入新bug，会导致全版本的应用崩溃率上升。
• 上架合规与安全层面的潜在风险
  目前国内主流应用分发平台的上架审核，已经对minSdk设置了明确的最低门槛，通常要求不低于Android 5.0（API 21），如果设置值远低于这个门槛，很可能直接无法通过上架审核。同时低版本系统本身存在大量已知的安全漏洞，且早已停止官方安全更新，应用在这些设备上运行时，缺少系统级的安全机制保护，不仅容易出现数据被窃取的风险，也会被合规评定为安全适配不到位。
• 性能表现的反向拖累
  低版本系统的运行时没有现代ART的编译优化能力，对应的硬件算力、内存容量也普遍偏低。为了兼容这些设备，你无法开启部分能提升运行效率的新特性，甚至需要引入兼容层的额外代码，最终会拉高应用的整体内存占用、拖慢启动速度，反而让高版本主流设备上的用户体验打折扣。

补充：实际开发中完全可以结合应用的历史用户版本分布数据，选择覆盖95%以上活跃用户的最低minSdk值，这种平衡才是最优解，而非一味追求理论上的最大覆盖范围。

内容的提问来源于stack exchange，提问作者cluster1。