上线当天App就崩了——用App Inventor 2的Web组件正确处理API调用

上周五晚上，朋友老刘急匆匆给我发消息："我的查价App上线两天，差评炸了，用户说一打开就白屏。"

看了他的项目才发现：Web组件拖出来，设个URL，直接调GET请求，没有超时处理，没有错误兜底，连返回状态码都没判断。用户在地铁里信号差，请求挂起30秒不返回，界面就僵死在那里。

需求分析

老刘的查价App核心逻辑很简单：

1. 用户输入商品关键词
2. 调用第三方价格API（返回JSON）
3. 解析数据，在列表中展示结果

问题出在第二步——完全没有考虑网络异常。

技术方案

帮老刘用Web组件重新设计了API调用流程，核心改动四个：

改动一：设置超时时间

Web组件的超时时间(ms)属性默认是0（无限等待）。改成8000毫秒——8秒不返回就触发超时事件，提示用户重试。

改动二：理解异步回调机制

Web组件是异步的，请求发出后不会阻塞等待。正确流程：

• 按钮点击 → 设置URL → 调用执行GET请求()
• 系统后台发HTTP请求
• 完成后触发获得文本(URL, 响应代码, 响应类型, 响应内容)事件
• 在事件回调里解析JSON、更新界面

很多人在按钮点击事件里直接读取响应内容，结果拿到的永远是空值。

改动三：用字典模式解析JSON

API返回嵌套JSON：{"code":200, "data":{"products":[...]}}

原来用的解码JSON文本返回列表套列表，取值要用在键值对中查找，嵌套多了容易绕晕。改用用字典解码JSON文本方法，返回字典对象，直接获取键的值层层取数据，可读性大幅提升。

改动四：正确设置请求头

有些API要求Content-Type: application/json。通过Web组件的请求标头属性设置双元素列表((Content-Type application/json))即可。

关键实现要点

1. 按钮点击：检查输入 → URI编码关键词 → 设置URL和超时 → 调用GET请求
2. 获得文本回调：判断响应代码=200 → 字典方式解析JSON → 遍历列表加入ListView
3. 超时事件：Notifier提示"网络较慢，请稍后重试"
4. 非200响应：Notifier提示服务异常

中文参数务必用URI编码处理，否则搜索中文关键词会出乱码。

两个隐蔽的坑

坑一：JSON解析崩溃。 API偶尔返回HTML错误页面（如502），直接解析会报错。方案：解析前检查响应内容是否以{开头。

坑二：Cookie丢失。 需要登录的API如果没勾选允许使用Cookies属性，每次请求都是未授权状态。勾上后Web组件自动维护Cookie。

最终效果

重构后各网络环境表现稳定：WiFi下1-2秒返回，弱网8秒内返回或超时提示，无网络不会卡死白屏。老刘提交新版后差评率从12%降到2%以下。

复盘

Web组件虽简单，但异步编程的思维不能少：事件回调、超时兜底、错误处理，三件事都是网络编程基本功。App Inventor 2 把这些能力封装好了，关键在于你用不用。

如果也在做调用API的App，建议把 Web 组件文档完整读一遍，特别是事件回调和JSON解析部分。