云控机型分档文档

1. 云控文件定义

云控文件采用 JSON 格式定义，整体结构如下图所示。

云控文件宏观上包含三个模块，分别是版本号定义、配置域列表定义、详细配置域定义。 在同一个云控文件中可以包 含多个配置 域的定义，在调用接口 CheckDeviceClass(string domain)进行判定时，选择对应的配置域，可达到多个配置隔离的效果。在单个配置域中，分为 机型分档数定义、详细分档定义、控制开关定义、白名单定义、维度分档阈值定义。


1.机型分档数定义中需要定义一个整型值，其表示分档的个数，如M；


2.详细分档定义需要定义一个JSON格式的整型数组，其表示详细的分档值，数组中共有 M 个元素，如[C1,C2…,Cm]


3.控制开关定义用于控制各个模块是否启用，只有启用的模块才会参与计算，否则会被忽 略，其能够适应不同使用者的需求。控制开关中包含两种控制开关的定义：白名单开关 以及分档维度开关。白名单开关主要用于控制模拟器、机型白名单、GPU白名单、SoC 白名单、厂商白名单是否有效。分档维度开关主要用于控制分辨率维度、内存维度、 CPU 频率维度， CPU 核数维度、 GPU 维度是否有效。控制开关基于位运算的方式定义，定义 模拟器的开关位值为 20、机型白名单的开关值为 21、 GPU 白名单的开关值为 22、SoC 白名单的开关值为 23、厂商白名单的开关值为 24、分辨率维度开关值为 25、内存维度 开关值为26、CPU频率维度开关值为27、CPU核数开关值为28、GPU维度开关值为29, 当需要判定具体的开关是否起作用时，可以采用"与"运算，如定义开关位的值为 S， 则可以通过 S 和模块开关值的"与"运算的结果是否等于 1 来决定模块是否启用。如果 白名单功能被启用，则需要定义档位对应的白名单值，采用"键值对"的方式，键为档 位Cn,值为档位Cn所对应的白名单JSON数组，如"Cn"：[“Wl”，“W2”…“Wn”],当判定时， 会遍历白名单数组，如果满足则返回对应的档位。


4.维度分档阈值用于描述一种通用的判定算法，在白名单无法满足的情况下，进行维度控 制的判定以及动态调整，提高了判定的科学性和效率，维度运算中需要定义维度阈值， 维度阈值的定义采用分段阈值的方式。定义机型分档数为 M， 详细的机型分档为 [C1,C2…,Cm]在各个维度控制中需要定义的分档阈值为M-1个，即[T1,T2…Tm-i]并满足T1<=T2<=…Tm-i。定义当前维度值V


如果 V<T1， 则返回当前维度机型分档值为 C1；


如果 V>=TM-1, 则返回当前维度机型分档值为 CM；


如果满足V> = Tn且V<Tn+1，则返回机型的分档值为Cn；


定义分辨率维度分档返回值为 C1， 内存维度分档返回值为 C2， CPU 核数分档返回值为 C3, CPU核数分档返回值为C4,GPU维度分档返回值为C5,则最终返回当前设备的分档 值为 C=min(C1,C2,C3,C4, C5)。


GPU 维度阈值定义。根据统计分析，市面上 Android 平台， GPU 型号的份额主要被 Adreno、Mali、PowerVR、Tegra 四个品牌瓜分，而对于不同的 GPU 型号其命名规则 有严格的规范并且是统一的，因此可以通过命名规则来分区不同档位的 GPU 型号。对 于Adreno品牌，其主要的GPU型号统一的命名规则为Adreno ™ N,其中N为 其具体的整型型号，主要分为 100系列、200系列、300系列、400系列、500 系列； 对于Mali品牌，其命名规则为Mali-SN，S为具体的系列，N为型号，主要有g系列 和t系列；对于PowerVR品牌，其命名规则为PowerVR-SN, S为具体的系列，N为型 号，主要有sgx系列、gt系列、ge系列、gx系列、g系列；对于Tegra品牌，命名 规则为Tegra-S，S为具体的系列，主要有K1、X1系列、2系列、3系列、4系列。考 虑到子系列的扩展性，因此在定义时需要指明参与运算的子系列型号，如果有新的子系 列则可以方便地扩展添加。

整体云控配置定义如下所示。

{
   "version": versionnumber,
   "configureList": ["configname1",…"confignameN"],
   "configname1": {
   "classLevelNum": M,
   "classLevelValues": [C1,C2…,CM],
   "defLevel": C1 ,
   "switchops": S1,
   "andopts": S2,
   "emulator": , C1
   "filter-model": {"C1": ["model1","model2"],… "CM": ["model1"," model2"]},
   "filter-gpu": {"C1": ["gpu1","gpu2"],… "CM": ["gpu1"," gpu2"]},
   "filter-soc": {"C1": ["soc1","soc2"],… "CM": ["soc1","soc2"]},
   "filter-manu": {"C1": ["manu1","manu2"],… "CM": ["manu1","manu2"]},
   "resolution":[T1,T2…TM-1],
   "ram": [T1,T2…TM-1],
   "cpufreq": [T1,T2…TM-1],
   "cpucores": [T1,T2…TM-1],
   "gpu_vendor": {
   	"adreno": {
   		"series": ["100", "200", "300", "400", "500"],
   		"100": [T1,T2…TM-1], "200": [T1,T2…TM-1],
   		"300": [T1,T2…TM-1], "400": [T1,T2…TM-1],
   		"500": [T1,T2…TM-1]
   	},"mali": {
   		"series": ["g", "t"],
   		"g": [T1,T2…TM-1], "t":[T1,T2…TM-1]
   	},
   	"powervr": {
   		"series": ["sgx", "gt", "ge", "gx", "g"],
   		"sgx": [T1,T2…TM-1], "gt":[T1,T2…TM-1],
   		"ge": [T1,T2…TM-1], "gx": [T1,T2…TM-1],
   		"g":[T1,T2…TM-1]
   	},
   	"tegra": {
   		"series": ["k1", "x1", "2", "3", "4"],
   		"k1": [T1,T2…TM-1], "x1":[T1,T2…TM-1],
   		"2": [T1,T2…TM-1], "3": [T1,T2…TM-1]],
   		"4": [T1,T2…TM-1]
   	}
   }
   },…
   "confignameN": {}
}

2. 机型档位判定流程

基于定义的云控文件，机型档位的判定流程图如下所示。

判定逻辑采用缓存的策略，在第一次请求 CheckDeviceClass 接口的时候，其会解析本地云控文件，并根据当前设备的硬件参数，逐一判定每个配置域对应的分档值，并写到本地缓存中， 最后返回结果。在后续的请求中，则会直接在缓存中查找对应配置的分档，提高了执行效率。


对于单个配置域，其会根据白名单开关和硬件维度开关计算具体的分档值。在白名单判定 中，采用"短路规则"，即一旦命中则立即返回，而白名单的判定有严格的先后顺序，即先判定机型白名单，再判定GPU白名单，再判定SoC白名单，最后厂商白名单。根据统计分析，机型的覆盖维度最小，而厂商覆盖的维度最大，而对于同一款GPU其可能用于一款SoC上，也可以用于多款SoC上，因此GPU的覆盖维度小于SoC，而同理，SoC维度小于厂商的覆盖维度。


如果白名单没有匹配，则根据维度控制机型相应的计算取得最终的机型分档信息。