手游弱网与性能测试全攻略：从模拟到标准文档

简介一套聚焦手游弱网与性能测试的实战文档合集覆盖低质量网络2G/3G/4G/5G/Wi-Fi下的丢包模型、验收指标、用例设计与报告模板适合手游测试、移动端性能测试工程师及相关培训人员使用。资源共20个文件、约16MB主格式包含docx、xml、xlsx、pdf等docx/xls/ppt提供性能测试指导书、验收标准、弱网测试执行指引与培训课件xml为纯丢包、3G高铁/地铁/断网等多场景网络模型配置pdf则为GT Android工具使用指南。已有1941人学习浏览。除基础测试方法外还包含弱网环境配置教程、弱网络测试执行指引、前台性能测试指导书、弱网测试用例及《XXX》Vx.x.x版本性能测试报告模板可帮助团队快速搭建可复用的弱网测试环境、规范用例设计与报告输出其中3G周期性断网、高铁、地铁、EDGE等网络模型与WCDMA无线接入网络测试场景及参数一并梳理为专项弱网验证提供了直接可参考的指标依据。1. 手游弱网、性能测试方法及标准文档从“能玩”到“敢上线”的最后一公里手游提测时演示很流畅一上真机地铁场景就卡成幻灯片登录页在弱网下转圈两分钟超时直接踢下线——这些都不是功能Bug能发现的而是弱网与性能测试漏掉的典型盲区。弱网测试关注的是网络状态剧烈变化时客户端的容错与恢复能力性能测试关注的是CPU、内存、帧率、耗电等资源消耗与流畅度体验。这个标题里的“标准文档”不是让测试抓阄而是把测试模型、执行步骤、阈值判定固化下来让不同人跑同一套用例得到同一份结论。适合客户端测试、专项测试和刚接手性能优化的开发同学照着搭出一套能说服产品与研发的测试基线。2. 弱网测试先定网络模型再抓两个核心指标手机上的“弱网”不是一个精确说法。延迟 300ms 是弱网丢包 5% 也是弱网但两者对业务的影响完全不同。弱网测试的第一步不是找一台信号差的手机去楼道里反复试而是先在测试方案里定义清楚你要模拟的到底是哪一种网络劣化参数是多少通过什么条件判定通过。这一章先解决三个问题有哪几种弱网模型、怎么在真机上把模型跑起来、以及业务上必须覆盖哪些场景。2.1 三种必须分清的弱网流量模型常见项目最容易犯的错误是只模拟“慢”也就是只限制带宽。实际上网络差分为延迟、丢包、抖动和带宽四类劣化单独设置其中一项都不能代表真实弱网。我建议把弱网场景拆成三种可复现的模型。第一种是固定劣化模型。延迟固定 200ms、丢包固定 3% 或 5%、带宽固定 200kbps参数全程不变。它适合做功能验证比如登录超时、资源加载失败后的重试机制。优点是结果稳定A 同学测的和你测的完全可对比问题能不能复现、修没修好都有一把尺子。第二种是抖动模型。延迟在 50ms 到 500ms 之间随机波动丢包率在 0% 到 10% 之间切换带宽在 0 到 1Mbps 之间跳变。它模拟的是地铁、电梯、移动中穿梭楼宇的真实体验容易暴露客户端在网络“忽快忽慢”时的状态错乱比如技能释放被重复提交、消息重复弹出。这类模型做不了全量回归但适合在版本发布前跑一轮核心玩法和支付链路。第三种是弱信号与切换模型。带宽被压到几十 kbps同时强制 WiFi 与蜂窝网络切换甚至短暂断开后立刻恢复。它验证的是会话保持、断线重连、断点续传和最终一致性。很多项目只在固定劣化下测了重连没测切换瞬间的请求悬空结果线上用户切个网络客户端就卡在白屏。下表是三种模型的选择参考模型典型参数适用场景主要关注点固定劣化延迟 200ms丢包 5%带宽 200kbps功能验证、Bug 复现超时逻辑、错误提示、重试次数抖动模型延迟 50~500ms丢包 0~10%带宽波动地铁、电梯、移动中状态同步、重复请求、操作响应切换模型弱信号 网络切换 短暂断网出门、跨基站、切网重连机制、断点续传、数据恢复实际执行时我会把三套参数写成脚本或弱网仪预设切换场景只改一个参数名。不要在同一轮测试里混着改参数不然数据之间无法对比后面定位问题时很难判断是哪一项劣化引起的。2.2 用 Linux tc 在真机上跑通一次最小弱网模拟做手游弱网测试常见做法是准备一台路由器或一台装了 Linux 的电脑当网关手机连它的 WiFi然后在网关上用 tc 命令模拟延迟、丢包和带宽限制。相比商业弱网仪tc 的优势是免费、可脚本化、能直接写进 CI 流程。下面给你一套最小可用的脚本我一般把它存成apply_weaknet.sh。#!/bin/bash # 在网关上配置弱网200ms 延迟 5% 丢包 200kbps 限速 DEVeth0 DELAY200 LOSS5 RATE200kbps # 先清空已有规则避免重复设置报错 sudo tc qdisc del dev $DEV root 2/dev/null # 第一层netem 模拟延迟和丢包 sudo tc qdisc add dev $DEV root handle 1: netem delay ${DELAY}ms loss ${LOSS}% # 第二层tbf 模拟带宽限制 sudo tc qdisc add dev $DEV parent 1:1 tbf rate ${RATE} burst 32kbit latency 400ms逻辑分两层。tc qdisc add给网卡增加一条排队规则netem是内核自带的网络模拟模块负责延迟和丢包tbf是令牌桶过滤器把实际带宽限制到指定速率。手机连接这台网关的 WiFi 后所有经过eth0的流量都会先进入 netem 排队再进入 tbf 限速所以网卡上的“慢”就等效成了手机上的“弱网”。参数上delay 200ms表示双向都会增加 200ms 往返延迟适合模拟 3G 网络或拥塞 WiFiloss 5%是丢弃 5% 的数据包真实弱网下 2% 到 10% 丢包是常见区间rate 200kbps模拟的是 2G 或极拥堵网络的下行带宽。DEV必须替换成实际网络出口网卡用ip addr命令查看常见是eth0或enp2s0。burst 32kbit是令牌桶的突发容量设得太小会导致带宽不稳定设得太大限速效果又会打折我用 32kbit 起步观察实际效果再微调。测试结束后恢复网络sudo tc qdisc del dev eth0 root这条命令会删除所有规则网卡恢复原状。注意每次执行apply_weaknet.sh时先del是为了避免规则叠加导致延迟变成 400ms、丢包变成 25% 这种翻倍现象。还要提醒一点如果测试机上还跑着其他业务比如办公软件在同步文件共享的 200kbps 带宽会被抢走。我一般会拉一条独立的 WiFi 热点来测或者用 iptables 把网络模型只指向手机 IP不让旁路流量影响结果。最小可行方案里先对整网卡生效动手前确认没有其他流量干扰。2.3 弱网测试必跑的 7 类场景清单定了网络模型还要定业务场景。不是所有功能都值得在弱网上跑一遍但下面这 7 类是手游弱网测试的标准动作每类都应该对应标准文档里的一条用例。弱网启动在弱网下冷启动游戏记录首屏出现时间、资源加载是否失败、会不会卡在白屏或黑屏。常见问题某个资源请求超时后客户端一直等待没有降级逻辑。登录与账号验证弱网下登录观察超时时长是多少秒、超时后有没有明确提示、重试按钮是否有效。踩过坑的人都知道很多登录按钮没有防重复点击弱网下用户点了三次就发了三个登录请求账号系统直接被顶号。断线重连网络断开后自动重连验证重连次数、退避策略、重连过程中 UI 是否有遮挡进度条是否卡住。这里要特别关注重连成功后客户端会不会主动拉取增量数据。弱网下的核心玩法战斗、实时对战、强交互操作。关注操作响应延迟、技能按钮点击后是否立即反馈、延迟过高时客户端是排队还是丢弃指令。对战类项目还要验证客户端是否有丢帧缓冲否则会在网络波动瞬间大卡一下。网络切换WiFi 切到 4G/5G或 4G/5G 切回 WiFi以及飞行模式开关。观察会话是否保持、请求是否因为断网而永久悬挂、切换后界面数据是否需要重新登录。很多项目的 HTTP 请求没有超时配置断网后请求能挂几分钟。极限弱网丢包率调到 20%带宽压到 50kbps模拟电梯和地下车库。此时重点看客户端有没有降级策略比如自动降低画质、暂停非关键资源下载、隐藏排行榜等强依赖网络的功能。弱网恢复网络恢复正常后客户端是否自动同步数据有没有提示用户刷新旧数据会不会残留。这个场景最容易出现“客户端显示成功了但服务器根本没收到”的假成功状态。每个场景执行时都要记录开始时间、操作路径、出现的异常截图、以及对应网络参数。后面写标准文档时这些记录就是判定通过与否的证据。3. 性能测试帧率、内存、耗电与温度的四维考核弱网测的是“网络环境变化时业务抗不抗造”性能测的是“常规环境下手机跑不跑得动”。性能测试关注四个维度帧率与卡顿、CPU与内存、耗电与温度、以及它们之间的联动。每台手机的性能上限不同所以不能拿一张别人网上的截图当标准必须把采集方案定好、数据口径定好、阈值按自己的项目定好。3.1 性能采集方案怎么选工程化采集优于“人眼盯帧”很多团队初测性能靠肉眼玩起来“感觉还行”。可一旦要优化开发问你“卡在哪个函数”产品问你“凭什么不能发版”你拿不出数据感觉就废了。性能测试的第一步是选对采集方案常见的三类方案各有定位。商业化性能采集工具。界面友好一般连接手机后能自动画出帧率曲线、Jank 次数、CPU 占用、内存占用还支持导出 Excel 和曲线图。它的优势是统计口径统一、出报告快适合做正式验收和给管理层汇报。缺点是部分工具需要安装配套客户端有些要收费而且统计的是整体帧率定位不到具体卡点。引擎自带的 Profiler。比如 Unity 的 Profiler、UE 的 Profiler能看到每一帧内 GameLogic、Render、Update 的耗时甚至能定位到具体函数。如果发现某段场景有针对性卡顿用这个方案定位效率最高。缺点是接入和操作成本高带上 Profiler 后性能本身会受影响不能拿它代表线上真机表现。adb 命令采集。用top、dumpsys gfxinfo、dumpsys meminfo等命令直接抓数据不需要装客户端可脚本化、可放进 CI适合做自动化回归。缺点是要自己解析数据、处理设备差异统计口径需要自己校准。我一般这样分配回归测试和版本验收用 adb 脚本 商业化工具出报告定位卡顿原因用引擎 Profiler日常快速验证用 adb 命令。最终标准文档里必须写清楚用的是哪种方案因为不同方案的帧数据采样口径不一样数字不能混着比。3.2 用 adb 命令采集帧率、内存、CPU 和温度先说采集 CPU 和内存的命令。包名假设为com.example.yourapp在终端执行PACKAGEcom.example.yourapp PID$(adb shell pidof $PACKAGE | tr -d \r) echo PID$PID # 每2秒采样一次CPU占用共10次 adb shell top -n 10 -d 2 -p $PID | tee cpu.log # 打印内存PSS汇总和堆内存 adb shell dumpsys meminfo $PACKAGE | grep -E TOTAL PSS|Java Heap|Native Heaptop -n 10 -d 2 -p表示取 PID 对应进程的 CPU 占用每 2 秒采样一次共 10 次输出结果同时写入cpu.log。tee是为了既看结果又留文件。dumpsys meminfo里的TOTAL PSS是按比例分摊后的物理内存比 RSS 更接近这台设备上应用真实占用的系统内存Java Heap和Native Heap分别对应 Java 层和 Native 层堆内存如果 Native Heap 只涨不降大概率是底层资源没释放。帧率采集稍微复杂先导出帧数据# 获取最近渲染的帧统计 adb shell dumpsys gfxinfo $PACKAGE framestats framestats.csv然后用 Python 解析计算平均帧耗时和百分位import csv frame_times [] with open(framestats.csv, newline) as f: for row in csv.reader(f): # 帧数据行以 127 开头row[4] 和 row[5] 是帧开始和结束时间戳 if len(row) 6 and row[0] 127: try: # 时间戳单位是纳秒转成毫秒 cost (int(row[5]) - int(row[4])) / 1_000_000 frame_times.append(cost) except (ValueError, IndexError): pass if frame_times: frame_times.sort() n len(frame_times) avg sum(frame_times) / n p95 frame_times[int(n * 0.95)] p99 frame_times[int(n * 0.99)] print(f总帧数: {n}) print(f平均帧耗时: {avg:.2f} ms) print(fP95帧耗时: {p95:.2f} ms) print(fP99帧耗时: {p99:.2f} ms)这段代码把每一帧耗时算出来按从小到大排序取 P95 和 P99。比如 60 帧目标下16.6ms 是一帧的标准时间P95 是 26ms意味着 95% 的帧在 26ms 内完成剩下 5% 的帧会明显掉帧。只看平均帧耗时没有意义平均 16ms 可能是 80% 的帧 10ms20% 的帧 40ms玩家仍然会感觉到卡顿。温度采集用电池温度作为主要参考# 电池温度单位是 0.1摄氏度读取后除以10 adb shell dumpsys battery | grep temperature # CPU温度不同芯片路径不同以下为常见路径 adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/cpu_temp 2/dev/null电池温度是手机全局热量的一个缩影超过 40℃ 时手机开始有明显发热感超过 45℃ 时 SoC 降频概率大增。CPU 温度路径因平台而异如果cpu_temp不存在可以查/sys/class/thermal/thermal_zone*/temp。温度必须和帧率一起看否则容易把降频后的性能数据当成版本本身的缺陷。3.3 性能阈值怎么定从参考基线到项目红线性能测出来是一堆数字但数字本身不代表结论。常见的参考值可以列成一张表当起点指标常见参考范围说明平均帧率60帧目标下不低于55FPS30帧目标下不低于27FPS取整段测试时长的平均值P95帧耗时60帧目标下不超过25ms描述长尾卡顿卡顿次数单帧耗时超过100ms的次数每10分钟不超过3次对体感影响大内存PSS中端机不超过600MB高端机不超过800MB必须按机型基线调整CPU占用平均不超过60%峰值不超过90%多核平台看整体占用电池温度不超过45℃超过后数据有效性存疑直接把这张表抄进标准文档是不行的。不同游戏玩法、画质档位、机型平台差异巨大更合理的做法是先定自己的基线选择两个主流测试机一个高端一个中端在最新优化版本上跑一段固定 15 分钟主线任务采集帧率、内存、温度取这段时间的 P50 和 P90 作为基线。然后在基线基础上定义“可接受范围”和“红线”。举个例子某项目在高端机上测出帧率 P90 48FPS那“可接受范围”可以定 P90 45FPS“红线”定 P90 40FPS。如果某次版本把 P90 从 48 拉到 42还没跌破红线但明显比基线差也应该判“不通过”。标准文档里的每个阈值后面都要写一行来源是几月几号的基线数据这样后面优化回去时也有依据。4. 弱网与性能测试避坑指南环境、数据与结果可信度这一章全是血泪经验。弱网测试和性能测试最大的坑不是工具不会用而是测出来的数据自己都不信配置明明开了却不生效帧率显示 60 帧用户却骂卡内存报告稳定但线上内存泄漏。以下 5 条踩坑记录几乎每个专测项目都会遇到。4.1 弱网配置“不生效”流量根本没走模拟网卡现象在网关上设好了延迟 200ms、丢包 5%但手机网页秒开游戏一点也不卡延迟始终在 20ms 左右。原因大概率是手机连的 WiFi 和配置 tc 规则的网卡不是同一个。比如开发机有两个网卡手机连了wlan0你在eth0上配了规则流量当然不受影响。还有一种情况是网关本身开启了硬件加速部分流量绕过内核协议栈直接转发tc 规则直接失效。解决先用ping从手机 ping 网关确认网关 IP 正常然后在网关和手机上用抓包工具确认流量的出入接口。检查命令# 查看当前网卡分配和手机IP所在网段 ip addr # 确认手机连的是哪个WiFi然后把这台手机的IP和网卡对上如果确认规则没放错网卡就把硬件加速关闭或换一台不支持加速的路由器。日常执行时我习惯在脚本开头先打印当前网卡和 IP测试完成后看一眼记录防止拿到的数据是“裸奔”的。4.2 帧率数据“虚高”垂直同步和掉帧统计口径被忽略现象报告写着平均帧率 59.8FPS玩家反馈“卡成狗”测试团队对账发现数据报告和真实体验完全对不上。原因平均帧率被大量快帧平均掉了。比如 10 秒内前 8 秒满帧 60后 2 秒掉到 20平均帧率仍有 52FPS但玩家体感就是后面 2 秒明显卡顿。另一个问题是部分设备开启垂直同步后显示的帧率是固定 60实际有不少帧是重复渲染的工具统计成了有效帧。解决不要只看平均帧率把 P95、P99 和卡顿次数一起统计。制定标准文档时明确写“帧率数据以平均帧率P95卡顿次数三项为准”并且说明卡顿定义单帧耗时超过 100ms 计一次卡顿。还要核对商业化工具和 adb 采集到的数据曲线先跑一轮对比确认统计口径一致后再用。上线后收集玩家反馈时也回看这些维度避免“数据好但不流畅”的冤案。4.3 内存泄漏被“波动”掩盖只看均值不划线现象测试报告内存均值从 612MB 涨到 618MB结论写“内存稳定”但实际数据每 10 分钟涨 5MB增长到一定值后被 GC 回收再继续涨像锯齿一样一路向上。原因只统计了整段测试的均值没有按时间画趋势线。GC 会把内存暂时回收掩盖“对象不断创建但不释放”的事实。尤其在弱网场景下失败的请求、超时回调里如果持有 Activity 引用内存就会一波一波地涨。解决把内存数据按时间画成曲线看整体趋势而不是均值。标准文档里加一条泄漏判定同一场景、同一时长对比前后两个版本的内存曲线如果后续版本起点高、增长速度也大即使 GC 波动明显也判接近泄漏。执行测试时建议每 5 分钟手动触发一次adb shell am dumpheap观察对象堆里哪些类在持续增长报给开发比单报“内存高”有用得多。4.4 温度触发降频连续测试成绩越跑越差现象上午在一台手机测试帧率稳定 55FPS下午同一台手机同一场景只有 40FPS开发说没有改代码测试说环境也没变。原因手机持续高负载运行温度升高后 SoC 为了保护硬件主动降频性能数据自然掉下来。测试机如果放在包里、贴在桌面或处在太阳直射环境结果差异更大。解决每轮测试前后用adb shell dumpsys battery记录电池温度温度超过 45℃ 时先停止测试等降到 35℃ 以下再继续。同一场景如果连续测 3 轮只取第一轮结果作为对外结论后面两轮用来观察降频曲线。报告里必须写上设备起始温度和环境温度让看报告的人知道这个数据是在“凉机”还是“热机”状态下跑的。标准文档里写清楚数据有效性基于起始温度不超过 40℃ 的前提。4.5 采样时间轴没对齐卡顿时刻和指标对不上现象录屏看到第 3 分 21 秒有一波卡顿但帧率曲线和 CPU 数据在那个时间点毫无异常。原因录屏时间、adb 采集时间、游戏内日志时间各走各的有的取设备时间有的取电脑时间时钟差了几秒卡顿就对不上号。特别是从多个工具导出数据时时间戳格式不同很难精确对齐到某几分钟。解决做自动化采集时每个采样点都记录设备系统时间切换场景时用命令打点# 在场景切换瞬间记录设备时间戳 adb shell date录屏时也在游戏画面停留 3 秒作为可见标记。采集脚本把每次采到的数据都附带timestamp字段最后按场景开始时间归零对齐。只有时间线对齐了帧率卡顿才能和内存暴涨、温度升高关联起来不然修都不知道从哪里修起。5. 把测试结果固化成“标准文档”一份可评审、可验收的测试模板测了、采了、避坑了最后一步是把经验写成文档。现在很多团队的性能报告只是贴几张图写一段“本次测试无明显问题”这种文档无法评审、无法追踪、更无法指导后续优化。标准文档应该让别人拿到后不看聊天记录也能独立复测并得出相同结论。5.1 标准文档里必须写清的 12 个字段我在项目里要求每个弱网或性能用例都带一张固定表头12 个字段一个都不能少字段填写示例为什么必填用例IDWNET-001评审、复测、归因都靠它游戏版本号v1.2.103结论必须对应具体版本测试机型某中端机型结论只在同档机型有效网络模型延迟200ms、丢5%、限速200kbps没有参数就无法复现业务场景登录-主城-战斗性能与玩法强相关操作步骤启动游戏→登录→进主城→打一场5分钟关卡让他人可重复执行运行时长20分钟覆盖温度上升和掉帧稳定期预期结果登录超时10s内弹出提示帧率P95≥45FPS客观判定基线实测数据附曲线图和原始CSV链接证据可追溯判定结论通过/可接受/不通过决策明确负责人A同学有问题能找到人日期2025-06-10对比基线时知道新旧有些字段看起来啰嗦但真到线上事故复盘时“没有版本号”“隔了三个月不知道数据来源”是最常见的翻车原因。标准文档宁可多写也不要少写。5.2 测试报告的核心章节环境、过程、数据、结论标准文档不只是记录更是一份可供评审的测试报告。我一般按下面章节组织每一章都有明确目的。第 1 章是“测试概述”用两三句话说清楚这轮测试验证了什么、总体结论什么。第 2 章是“测试环境”依次列出设备型号、系统版本、网络模型参数、游戏资源版本、采集工具及命令版本。环境放前面是为了让看报告的人知道任何换环境后的差异都可能导致结论不成立。第 3 章是“测试场景与结果”用表格逐行列出用例编号、场景描述、执行次数、通过情况、问题链接。第 4 章是“关键指标分析”分别展示帧率分布、内存趋势、温度变化和 CPU 占用曲线图上标注异常时间点。异常点必须对应到业务操作比如“主线战斗开始第 30 秒出现卡顿”不然开发无从下手。第 5 章是“问题清单”每个问题都写复现步骤、影响范围、前提条件、严重程度和建议优先级。最后是“结论与建议”只有在数据充分时才能写“通过”或“不通过”否则写“需要补充数据”。数据部分要标注哪些数据有效、哪些作废。比如温度过高导致降频后的帧率数据必须划掉并说明原因否则会污染整个报告。原始数据文件以 CSV 或日志形式附在报告末尾方便开发自行分析。5.3 用“通过/可接受/不通过”三级判定代替单一 PASS最早我用 PASS/FAIL 判定结果发现很多版本卡在一半的边界上功能没到大问题但帧率偶尔掉到过线边缘。直接 FAIL 太苛刻全 PASS 又掩盖风险于是引入三级判定团队现在都默认用这套口径。判定条件处理建议通过所有指标在目标阈值内无阻塞问题放行进入下一环节可接受1~2 个指标在可接受范围内不影响主流程体验上报版本负责人约定后续优化日期不通过任一指标超过红线或存在阻塞性体验问题打回优化修复后重新执行测试举例60 帧项目中平均帧率 58P95 是 45红线定的是 40那判“可接受”如果 P95 掉到 35 并持续 1 分钟直接“不通过”。每个阈值都要在文档里写明“目标阈值”“可接受阈值”“红线阈值”三层数据落在哪个区间给哪个结论。这样评审会上不用再为“算不算问题”吵架所有人都按统一口径说话。6. 进阶把标准文档变成一条自动回归流水线标准文档不应该是手工测试时代的期末报告更理想的做法是把文档里的网络模型、场景步骤、采集命令和阈值判断都写成脚本挂到每日回归里。这样版本每次更新弱网和性能数据自动生成报告自动填充人只需要处理异常。一个最小流水线的组合类似#!/bin/bash # 每日弱网性能回归 ./apply_weaknet.sh 200 5 200kbps python run_scenario.py --package com.example.yourapp --duration 300 --scene main_city ./collect_perf.sh result.json ./stop_weaknet.sh python check_threshold.py result.json --p95 45 --pss 600apply_weaknet.sh就是第 2 章的 tc 脚本封装run_scenario.py用 adb 输入或 UI 自动化引擎跑固定路线collect_perf.sh汇总 gfxinfo、meminfo 和温度check_threshold.py按标准文档里的阈值输出通过/可接受/不通过。关键点是每个脚本都往结果文件里写timestamp和scene字段标准文档里的“操作步骤”“实测数据”“判定结论”全部由脚本生成不靠人抄。我自己在维护模拟项目 X 时最初也是先写文档再手工跑结果反复被人问“这数据哪来的”。后来改成先跑流水线再生成文档每个阈值都让数据自己说话报告自然硬气。如果你的标准文档现在还没人照着做不用去逼着大家填表把采集脚本先交给 QA 同学试试文档和脚本绑定后遵守成本低大家才愿意长期用。希望帮到你。本文还有配套的精品资源点击获取