iOS 分机型资源分级架构设计 先把问题拆清楚。“分机型资源分级看似是给不同手机不同画质”但真正的难点是三个互相打架的约束机型爆炸且持续增加——你不可能维护一张iPhone X 用中画质的硬编码表明年出的新机型你没法预判。同机型表现也不稳定——同一台 iPhone 13冷机和发烫时、满电和低电量时性能差一截。静态分级不够。分级会撑爆包体——一张贴图存 4 档就是 4 倍体积iOS 还有下载大小限制和审核。所以架构不是一张机型表那么简单而是三层解耦设备能力识别 → 质量档位决策 → 资源/参数按档位分发与加载。整篇围绕这三层外加 iOS 特有的分发机制。一、核心设计原则能力抽象而非机型枚举第一个要立的规矩永远不要用机型名做逻辑判断。// ❌ 灾难写法新机型一出就得改代码、发版if(deviceModeliPhone13,2)qualityHigh;// ✅ 正确思路机型 → 能力评分 → 档位intscoreEvaluateDeviceCapability();QualityTiertierMapScoreToTier(score);机型只是能力的一个输入信号不是判断依据。这样即使遇到没见过的新机型也能靠能力评分给出合理档位新机型通常更强天然落到高档。二、第一层设备能力识别目标是把一台设备量化成一个能力画像。iOS 上可靠的信号有这些信号获取方式可靠性说明GPU FamilyMetalsupportsFamily★★★★★最可靠的性能分级依据内存总量NSProcessInfo.physicalMemory★★★★★决定贴图/资源驻留上限机型标识uname→iPhone15,3★★★★☆用于查表补充非主判据CPU 核心/频率sysctl★★★☆☆参考实测跑分首次启动微基准★★★★☆兜底最准但有成本GPU Family 是重点。Metal 提供了按功能族查询的能力比机型名稳定得多// Metal GPU Family 是苹果官方的能力分档天然适合做性能分级idMTLDevicedeviceMTLCreateSystemDefaultDevice();// 从高到低探测命中最高的就是它的档位if([device supportsFamily:MTLGPUFamilyApple8])tier8;// A15/A16/M2elseif([device supportsFamily:MTLGPUFamilyApple7])tier7;// A14/M1elseif([device supportsFamily:MTLGPUFamilyApple6])tier6;// A13// ... Apple5(A12) / Apple4(A11) / Apple3(A10)...能力评分的组合逻辑DeviceProfileBuildProfile(){intgpuScoreGetMetalGPUFamilyLevel();// 主权重longmemGBGetPhysicalMemoryGB();stringmodelGetDeviceModel();// GPU 定基调内存做钳制GPU 强但内存小依然要降贴图档intscoregpuScore*100(int)memGB*10;// 极少数需要特判的机型如已知的发热/驱动问题走覆盖表if(overrideTable.TryGetValue(model,outvarforced))returnforced;returnnewDeviceProfile{Scorescore,MemGBmemGB,GpuLevelgpuScore};}关键点机型覆盖表override table应该是云端可下发的配置不是硬编码。上线后发现某款机型实际表现异常改配置即可纠正不用发版。这是整个架构里最重要的后悔药。三、第二层质量档位决策把连续的能力评分映射到有限的几个离散档位。为什么要离散因为资源只能按有限档位预制你不可能给每个评分单独做一套资源。能力评分连续 质量档位离散通常 3~5 档 0 ────────────────► Low (兜底跑得动优先) 300 ───────────────► Medium 600 ───────────────► High 900 ───────────────► Ultra (旗舰拉满)档位不是一个整数而是一组参数集Quality Profile。这是架构的核心数据结构[Serializable]publicclassQualityProfile{publicstringtier;// High// ── 资源分级维度 ──publicinttextureMaxSize;// 贴图最大边长: 512/1024/2048publicintmodelLODBias;// 模型 LOD 偏移publicintshadowResolution;// 阴影贴图分辨率publicboolenablePostProcessing;publicintparticleMaxCount;// 特效粒子上限// ── 运行时参数维度 ──publicfloatrenderScale;// 分辨率缩放 0.7~1.0publicinttargetFrameRate;// 30/60/120publicboolenableHDR;publicintmsaaLevel;}至关重要的一点这套 Profile 定义应该在云端配置本地只带一份兜底默认值。这样调优不用发版——你在线上观察到High 档在某批设备上掉帧直接改云端 Profile 的renderScale就能救。启动流程 拉云端 Quality 配置失败则用内置兜底 │ ▼ 本地识别设备能力 → 算出评分 │ ▼ 评分匹配到某个 QualityProfile │ ▼ 应用参数 决定要加载哪一档资源四、第三层资源分发——iOS 特有的重头戏档位定了接下来是最实际的问题不同档位的资源尤其是贴图/模型怎么存、怎么下、怎么加载才能既分级又不撑爆包体iOS 有三种机制要组合用1. App Thinning / App Slicing系统自动分发苹果的 App Slicing 会根据设备自动只下载匹配的资源变体。你在 Asset Catalog 里为不同设备等级标注 variantApp Store 会为每台设备切出专属包。优点系统自动、用户只下自己需要的那份包体最小局限主要作用于 Asset Catalog 里的图片资源、1x/2x/3x、Metal 版本等对游戏引擎自管的大量资源AssetBundle帮助有限2. On-Demand ResourcesODR按需下载把非首屏、高画质档位的资源标成 ODR tag首包不带用到时才下。首包只含 Low/Medium 档必需资源 ← 通过审核、下载快 │ 运行时高端机识别为 Ultra 档 │ └─► 请求 ODR tag ultra_textures → 系统按需下载 → 加载这是控制初始下载体积的关键武器。低端机永远不会去下 Ultra 资源天然省流量。3. 引擎自管 AssetBundle 变体最灵活主流大项目用这个自建 CDN 资源变体系统绕开 App Store 的限制完全自己掌控。这是重度游戏的标配。CDN 上按档位组织资源 cdn/textures/low/hero.bundle (512, 2MB) cdn/textures/medium/hero.bundle (1024, 8MB) cdn/textures/high/hero.bundle (2048, 30MB) │ 客户端按自己的 tier 只下对应目录三者如何取舍包体内首包必带 → Low/Medium 兜底资源保证离线可玩 ODR / 自建CDN 按需 → High/Ultra 高清资源按 tier 拉取 Asset Catalog Slicing → 图标、系统级图片、UI 素材分级不等于存 N 套完整资源——省体积的技巧不要天真地每档存一份完整贴图。实践中贴图只存最高清一份运行时/打包时 mipmap 降采样生成低档或用texture streaming按需只加载需要的 mip 层级。ASTC 不同块大小也是分级手段。模型一套模型带多级 LOD低档只是LODBias偏移不额外存模型。特效同一套特效低档通过参数砍粒子数/关闭子发射器不做两套。能用参数降级解决的就不要用多套资源解决——这是控制包体的第一原则。真正需要多套物理资源的主要是贴图分辨率和音频码率。五、第四层容易被忽略运行时动态降级静态分级只解决了起点。但设备会发烫、会低电量、某些场景特别重。需要运行时监控实际帧率动态微调。classDynamicQualityController{floatframeTimeAvg;voidUpdate(){frameTimeAvgSmoothFrameTime();// 持续掉帧 → 降级先降代价大回报高的分辨率、后处理if(frameTimeAvgtargetFrameTime*1.2fstableFrames60){StepDown();// renderScale ↓ → 关后处理 → 降阴影 → ...}// 长期非常流畅 → 谨慎升级留余量别反复横跳elseif(frameTimeAvgtargetFrameTime*0.7fstableFrames300){StepUp();}}}动态降级的排序原则优先调参数分辨率缩放、后处理开关、阴影质量这些改了立刻生效、无需重载资源尽量不动需要重新加载的资源档贴图 mip因为运行时换贴图会卡顿。同时监听系统信号// 热状态过热时主动降级避免系统强制降频导致更糟的体验[NSProcessInfo processInfo].thermalState// Nominal/Fair/Serious/Critical// 低电量模式用户开了省电应主动降帧率/画质[NSProcessInfo processInfo].isLowPowerModeEnabled静态分级定能跑多好动态降级保不掉链子。两者缺一不可只有静态分级发烫时照样卡只有动态冷启动第一帧就可能过载。六、整体架构图┌──────────────────────────────────────────────────────────┐ │ 云端配置中心 │ │ QualityProfiles各档参数 机型 override 表 │ │ 可热更不用发版就能调优/纠错 │ └───────────────────────┬──────────────────────────────────┘ │ 启动拉取失败用内置兜底 ▼ ┌──────────────────────────────────────────────────────────┐ │ ① 设备能力识别 │ │ Metal GPU Family 内存 机型 (可选)微跑分 → 能力评分 │ └───────────────────────┬──────────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ ② 档位决策 │ │ 评分 → 匹配 QualityProfileLow/Med/High/Ultra │ └───────────────────────┬──────────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ ③ 资源分发与加载 │ │ 首包兜底资源 ODR/CDN 按 tier 拉高清 Slicing │ │ 贴图 mip streaming / 模型 LOD / 特效参数降级 │ └───────────────────────┬──────────────────────────────────┘ ▼ ┌──────────────────────────────────────────────────────────┐ │ ④ 运行时动态调节 │ │ 帧率监控 thermalState 低电量 → 参数级实时升降 │ └───────────────────────┬──────────────────────────────────┘ │ 上报实际帧率/机型/档位 ▼ 数据回流 → 反哺云端 override 表调优注意最下面那条数据回流线上收集某机型在某档实际帧率分布反过来修正云端配置。这让分级系统能自我进化而不是上线即定死。七、落地时的关键取舍清单决策点建议分几档3~4 档足够档太多资源维护成本爆炸判据GPU Family 为主内存钳制机型仅做 override分级配置必须云端可热更这是能救命的后悔药资源多套 vs 参数降级优先参数降级只有贴图/音频才做多套物理资源首包大小只带 Low/Med 兜底高清走 ODR/CDN 按需动态降级优先调参数分辨率/后处理慎重换资源兜底识别失败、配置拉取失败一律落到最低档保证能跑一句话总结用GPU Family 内存把设备量化成能力评分映射到云端可热更的有限档位Quality Profile资源上能用参数降级就不做多套首包只带兜底、高清走 ODR/CDN 按 tier 下载运行时再用帧率 热状态做参数级动态升降最后靠线上数据回流持续修正档位配置。核心是三个解耦——能力识别、档位决策、资源分发彼此独立加上一条贯穿始终的原则别枚举机型别硬编码把决策权交给可热更的配置。