精华速览

编程教育平台Efiwe针对网络不稳、设备低端的学习者，放弃原生应用，采用PWA架构，将Python（Pyodide）和SQL（sql.js）编译为WebAssembly在浏览器本地执行，首次加载后可离线使用。平台已覆盖160个国家、超2.2万名学习者，并在尼日利亚和印度开展学校试点。文章披露了存储配额、冷启动、多人共用设备等工程难题，其中一次因存储写入失败导致课程白屏的事故，促使团队确立“持久化写入不得阻塞渲染”的原则。

要点透视

  • Efiwe平台目前已被160个国家的22000多名学习者使用，并在尼日利亚拉各斯州、奥贡州及印度北阿坎德邦的学校开展有组织试点。
  • 平台选择PWA而非原生Android应用，主要考虑安装流量开销、Service Worker更新机制以及用一套Web运行时支持Python、SQL、JavaScript和HTML代码执行。
  • Python通过Pyodide、SQL通过sql.js以WebAssembly形式在设备端运行，运行时按需在Worker中初始化，主线程不等待初始化完成，超时设为45秒。
  • 存储层从localStorage迁移至IndexedDB，原因是localStorage约5MB的容量上限和同步读写会阻塞主线程，在低端Android设备上造成明显卡顿。
  • 尼日利亚试点中，10位老师有8位认为学生没有自己的设备是最大障碍，平台因此支持单台设备保存最多20个用户档案并一键切换。
  • AI反馈采用两级机制：云端模型超时设为4秒，本地确定性分析始终先执行，离线时直接返回端侧结果，并记录反馈来源层级。
  • 尼日利亚为期八周的试点中，离线可靠性平均评分为4.0分（满分5分），低分均指向首次缓存未完成即断网的情况。
  • 语言切换功能支持246种语言，但试点中10位老师有4位从未使用本地语言界面，原因是切换按钮位于页面底部，功能难以被发现。

文章拆解

Efiwe的工程实践揭示了一个常被忽视的事实：面向低端设备和弱网用户的编程教育产品，真正的难点不在模型质量，而在存储、配额、冷启动和失败路径的设计。多数在线教育平台默认学习者拥有笔记本电脑、宽带、英语阅读能力和付费能力，而Efiwe的试点数据显示，这些假设在尼日利亚和印度部分地区的学校中并不成立。选择PWA而非原生应用，本质上是用浏览器存储机制的不确定性换取更低的安装门槛和更快的更新触达，这一取舍直接引出了后续一系列存储问题。

代码在本地执行是另一个关键决策。学生解一道题往往需要尝试十到十二次，若每次判定都经过服务器往返，在弱网教室中几乎不可行。WebAssembly让Python和SQL能在设备端运行，但代价是运行时体积大、初始化慢，团队因此规定运行时不得在主线程初始化，也不得在需要之前初始化。这一规则与存储层的异步化改造共同指向同一个设计原则：任何可能失败或阻塞的操作，都不应成为页面渲染的前置条件。

那次课程白屏事故最能说明问题。表面上看是低端设备兼容性问题，实际原因是启动流程中用await等待缓存写入，设备存储满时写入失败，Promise链中断，渲染函数从未被调用。修复方式是将持久化写入改为发起后不等待并捕获异常，使离线缓存降级为优化项而非必要条件。这一原则对任何面向存储紧张设备的应用都具有参考价值，因为用户把手机存满是一个无法通过代码消除的现实。

多人共用设备的需求同样来自实地反馈。默认一设备一用户的身份模型在共用手机场景下会导致频繁登出和进度丢失，按用户档案隔离本地存储命名空间因此成为架构层面的必要设计。文章也坦承，这类机制在上线后再补，成本远高于从第一天做起。

值得关注的变量包括：WebAssembly运行时在性能最弱设备上的冷启动仍不理想；端侧模型质量构成离线反馈的上限，确定性分析目前承担了超出预期的工作量；浏览器存储配额数据经过填充处理，persist()支持不一致，缓存清理机制不透明。这些问题尚待确认能否在Web平台层面得到根本改善，现有防御性设计更多是在弥补平台不足。此外，语言切换功能“存在但隐形”的教训提示，功能可发现性与可用性是两个独立问题，产品设计应以用户自然操作路径为检验标准，而非以“告知后能否找到”为准。

查看原文