1. 为什么你的App一到地铁里就卡聊聊弱网测试那点事不知道你有没有遇到过这种情况早上通勤在地铁里刷着新闻App图片半天加载不出来刷个短视频一直转圈圈甚至点个外卖提交订单时直接卡死闪退。你可能会怪手机信号不好但作为开发者我们心里清楚这很可能是因为我们的App没有在“弱网”环境下做好充分的兼容性测试。所谓弱网简单说就是网络信号差、速度慢、不稳定的环境。它离我们并不远甚至每天都在发生。想想看除了地铁还有电梯里、地下停车场、大型商场的角落、郊区的公路上甚至是演唱会现场人挤人的时候。这些场景下手机的网络信号无论是蜂窝数据还是Wi-Fi都会大幅衰减。如果你的App只在高速度、低延迟的实验室Wi-Fi下测试通过那上线后用户在实际复杂网络环境中的体验很可能就是一场灾难。App在弱网下会暴露什么问题呢我见过太多案例了页面白屏、数据加载失败却不给用户任何提示、重复点击导致订单重复提交、图片错乱、甚至直接闪退。这些问题轻则影响用户体验重则导致数据错误和用户流失。所以弱网测试绝不是“锦上添花”而是保障App基本可用性和稳定性的“必修课”。传统的弱网测试方法有很多比如用两部手机开热点限制速度或者购买昂贵的硬件网络损伤仪。但这些方法要么不够精确要么成本太高要么无法灵活模拟各种复杂场景。今天我要跟你分享一个我用了很多年、既免费又强大的方法使用Charles代理工具来模拟复杂网络环境。Charles本身是个抓包工具但它的“网络节流”功能能让我们在办公室的电脑前就轻松模拟出用户在地铁、电梯等场景下的真实网络状况提前发现并修复问题。接下来我就手把手带你玩转它。2. 工欲善其事Charles基础配置与环境搭建在开始模拟弱网之前我们得先把Charles这个工具给配置好。别担心过程很简单我会把每一步都讲清楚包括你可能遇到的“坑”。2.1 安装与基础代理设置首先去Charles官网下载对应你操作系统Windows/macOS的版本。安装过程就是一路“下一步”这里不多说。安装完成后第一次打开Charles可能会请求为系统安装根证书这是必须同意的否则它无法解密HTTPS流量。接下来是关键的一步设置代理。Charles启动后默认代理端口是8888。你需要让你的手机和电脑处于同一个局域网比如连接同一个Wi-Fi。然后在手机的Wi-Fi设置里找到当前连接的Wi-Fi点进去修改网络选择“手动”代理服务器地址填写你电脑的IP地址在Charles的Help - Local IP Address菜单里可以看到端口填8888。这时候你手机上的任何网络请求都会先经过Charles这台“中间人”然后再发往互联网。你会在Charles的界面里看到刷刷刷出现的请求列表。第一次用手机访问网络时Charles会弹出一个请求连接的对话框一定要点“Allow”允许这样它才能持续捕获流量。2.2 搞定HTTPS抓包解决“未知”协议问题如果你发现抓到的HTTPS请求内容都是乱码或者显示“unknown”那是因为Charles没有安装手机端的证书。解决步骤如下在电脑上的Charles里点击Help - SSL Proxying - Install Charles Root Certificate on a Mobile Device or Remote Browser。屏幕上会显示一个提示告诉你用手机浏览器访问chls.pro/ssl这个地址。用你的手机已经设置好代理的那台打开Safari或Chrome浏览器访问chls.pro/ssl。这会下载一个名为charles-proxy-ssl-proxying-certificate.pem的文件。对于iOS设备你需要进入“设置”-“通用”-“VPN与设备管理”或“描述文件”找到下载的描述文件并安装。安装后还需要进入“设置”-“通用”-“关于本机”-“证书信任设置”找到Charles Proxy的根证书并完全信任它。这一步非常重要很多同学卡在这里就是因为忘了信任证书。回到电脑上的Charles还需要针对你想要抓包的域名开启SSL代理。在Charles的菜单栏选择Proxy - SSL Proxying Settings...在弹窗里点击“Add”在Host栏位可以填*表示监听所有域名Port填443。这样Charles就能解密并看到HTTPS请求的具体内容了。完成以上两步你的Charles抓包环境就基本搭建好了。你可以随意打开手机上的App看看网络请求是如何发送和接收的这本身就是一个学习App网络架构的好方法。3. 核心实战用Charles模拟真实世界里的“龟速”网络环境搭好了现在进入最核心的部分如何用Charles模拟出那些让人头疼的弱网场景。Charles的“Throttle”功能就像一个精准的网络调节阀。3.1 理解并配置Throttle Settings在Charles顶部菜单找到Proxy - Throttle Settings...点击打开弱网模拟设置面板。这个面板里信息很多我逐一解释Enable Throttling总开关勾上才生效。Throttle preset预设模板。Charles很贴心地提供了一些经典网络环境的预设比如“3G”、“4G”、“Edge2.75G”。你可以直接选用作为起点。Bandwidth带宽这是最核心的参数决定了网络的速度上限。Downstream下行下载速度比如你从服务器加载图片、视频的速度。Upstream上行上传速度比如你提交表单、发送图片消息的速度。 单位是Kbps千比特每秒。记住一个换算1Mbps兆比特每秒 1024 Kbps。我们常说的“百兆宽带”理论下行速度是100Mbps约等于102400 Kbps。而弱网环境下这个值可能只有几十到几百Kbps。Utilisation利用率带宽的实际使用率。100%表示完全使用你设置的带宽值。降低这个百分比可以模拟网络带宽未被充分利用的情况比如网络拥堵时的效率低下。Round-trip latency往返延迟数据包从你手机到服务器再回来的时间也就是常说的“ping值”。单位是毫秒(ms)。在良好的Wi-Fi下延迟可能小于30ms而在信号差的蜂窝网络下延迟可能高达500ms甚至更多。高延迟会让每个请求的“起步”都很慢即使带宽足够体验也会很卡顿。MTU最大传输单元网络传输中单个数据包的最大尺寸。在差网络上MTU值可能需要调小因为大包更容易出错或丢失。通常保持默认即可。Reliability可靠性模拟网络的稳定性。包含“Unstable quality”不稳定质量和“Data error”数据错误率。Unstable quality勾选后可以模拟网络质量的波动比如突然变好或变差。Data error设置数据包的丢包率。这是弱网中非常关键但常被忽略的因素。想象一下电梯里信号时断时续数据包在传输中丢失了。设置1%的丢包率就意味着每100个数据包可能会随机丢失1个这会触发TCP的重传机制进一步降低有效速度。3.2 创建你自己的“地铁模式”和“电梯模式”理解了参数我们就可以动手创建贴合真实场景的配置了。不要只依赖预设根据你的用户场景自定义测试效果会更好。场景一早晚高峰地铁模式我实测过在拥挤的地铁隧道里网络信号衰减非常严重但并非完全中断特点是高延迟、中低带宽、偶发丢包。带宽下行设为256 Kbps上行设为128 Kbps。这个速度大概能勉强加载标清图片但看视频会很卡。延迟往返延迟设为500 ms。模拟信号在复杂环境中穿梭的耗时。可靠性勾选“Unstable quality”让网络质量有一定波动将“Data error”丢包率设为0.5%。模拟信号不稳定导致的随机丢包。作用域名在面板下方的“Only for selected hosts”区域添加你App主要使用的API域名。这样不会影响你手机其他App的正常使用测试更聚焦。场景二地下停车场/电梯模式这种场景更极端信号可能非常微弱时有时无。我们可以模拟极低带宽、超高延迟、高丢包率。带宽下行64 Kbps上行32 Kbps。这个速度回到2G时代加载纯文本都吃力。延迟设为1000 ms1秒。每个请求都要等1秒才刚“出发”。可靠性丢包率大胆设为2%甚至5%。模拟信号极不稳定的状态。 配置好后给它起个名字比如“Extreme_Elevator”点击“Add”保存为自定义预设以后就可以一键切换了。4. 不只是慢模拟超时、中断与异常场景弱网测试不仅仅是把网速调慢。网络环境是复杂多变的经常会出现连接超时、请求被重置等异常情况。Charles虽然不能直接模拟“无网络”但我们可以通过一些组合拳和技巧来逼近这些场景。4.1 利用断点和Map Local模拟请求失败有时候我们想测试服务器长时间不响应或者返回一个特定的错误码如500、502时App的表现如何。Charles的“Breakpoints”断点和“Map Local”本地映射功能可以大显身手。方法A使用断点模拟超时在Charles的请求列表里找到你想测试的那个关键API请求比如“用户登录”。右键点击它选择“Breakpoints”。这样下次手机再发出这个请求时Charles会将其拦截并暂停。当请求被暂停时你可以在Charles的“Edit Request”窗口里什么都不做就让它挂着。等待一段时间比如30秒模拟服务器处理超时。然后你可以点击“Execute”放行或者点击“Abort”直接终止请求。观察你的App是显示了友好的超时提示还是直接卡死、闪退方法B使用Map Local返回自定义错误准备一个本地的文本文件比如error_500.json里面写好你想返回的错误信息例如{code: 500, message: Internal Server Error}。在Charles中右键点击目标请求选择“Map Local...”。在设置里选择你刚准备好的那个本地JSON文件。保存后清空手机App缓存再次触发那个请求。此时请求并不会真的发往服务器而是由Charles直接返回你本地文件的内容。你可以用这个方法来测试App对各种错误码404、500、503等的解析和UI提示是否正常。4.2 组合Throttle与工具模拟网络切换与抖动真实的弱网环境是动态的。比如用户从户外走进电梯网络从4G降级到2G或者在地铁里信号在隧道无信号和站台满格4G之间频繁切换。我们可以通过手动快速切换Charles的不同Throttle预设来模拟这种变化。例如先启用“4G”预设让App正常操作。突然切换到“电梯模式”预设观察App的响应正在进行的请求是否会超时页面是否有加载失败提示等待几秒再切换回“4G”模式看App是否能自动重连、恢复数据加载还是会停留在错误状态这种“网络抖动”的测试能很好地检验App的重试机制和状态恢复能力是否健壮。我建议把你App的核心流程如登录、支付、内容浏览都放在这种动态切换的网络环境下跑一遍往往能发现一些在单纯慢速网络下发现不了的问题。5. 测试之后做什么分析结果与优化建议模拟测试做完了Charles里也记录了一大堆数据我们该怎么分析又该如何推动问题解决呢这才是弱网测试的最终价值所在。5.1 看懂Charles的性能数据Charles的“Sequence”序列视图和“Summary”摘要视图是分析性能的利器。在弱网测试时重点关注以下几点请求时序Waterfall在Sequence视图里每个请求都是一条横杠长度代表请求的耗时。在弱网下你会明显看到这些横杠变长了。重点关注Stalled阻塞时间请求在发送前等待的时间。如果这个时间很长可能意味着达到了浏览器或系统的并发请求限制在弱网下这个问题会被放大。Request/Response请求/响应传输时间数据包在“路上”的时间。高延迟和低带宽会显著增加这个时间。Content Download内容下载时间下载响应体所花的时间。这直接受下行带宽影响。请求大小在Summary视图里检查每个请求的请求体和响应体的大小。一个简单的优化原则是在弱网下传输的数据越少越好。看看有没有不必要的字段、过大的图片没有根据网络状况切换清晰度、未压缩的文本数据等。5.2 提出切实可行的优化建议根据分析结果你可以给开发团队提出非常具体的优化建议而不是笼统地说“弱网下体验不好”。例如图片优化“在商品列表页当前每张封面图大小约为200KB。建议引入WebP格式并在弱网环境下可通过Charles模拟自动切换到更低清晰度的缩略图将单张图大小控制在50KB以下。”请求合并与减少“检查发现首页加载时并发请求达25个其中多个小JSON请求可以合并为一个。建议使用GraphQL或对后端接口进行聚合减少请求数量以降低高延迟环境下的整体耗时。”超时与重试策略优化“当前全局请求超时时间为30秒在模拟高丢包环境下用户体验极差。建议区分请求类型关键支付请求超时可保持15-30秒并伴有自动重试非核心内容请求超时缩短至8-10秒并给予用户‘重试’按钮。”数据缓存与离线支持“App在断网后再次进入部分已浏览过的内容仍显示为空白。建议对文章、商品详情等核心内容增加本地缓存机制并在UI上明确标识‘离线缓存内容’提升弱网下的用户体验。”UI反馈优化“在网络从差变好时页面内容自动恢复加载但用户无感知。建议增加‘网络已恢复正在重新加载’的轻量级提示Toast让用户感知状态变化。”把这些具体的、有数据支撑的建议和Charles的测试截图一起提交推动优化的成功率会高很多。弱网测试不是一个一次性的任务而应该成为App迭代周期中的常规环节。每次发布新功能前都花上半小时用Charles模拟一下地铁和电梯场景跑一跑能帮你拦住不少线上问题。