清泛IT社区
标题:
wxbit平台第三方扩展报错分析:no such class 运行时错误的根本原因
[打印本页]
作者:
App Inventor 2
时间:
2 小时前
标题:
wxbit平台第三方扩展报错分析:no such class 运行时错误的根本原因
用户提问:
在fun123.cn中测试CloudBase 拓展 能正常查询数据,我今天打算把wxbit平台中的原来调用LeanCloud的,也改为CloudBase拓展调用时,运行时出错:
错误:java.lang.RuntimeException: invalid syntax in eval form:
<string>:51:1: caught exception in inliner for #<procedure make> - java.lang.RuntimeException: no such class: cn.fun123.CloudBase.CloudBaseAuth
gnu.bytecode.ObjectType.getReflectClass(Unknown Source:64)
gnu.bytecode.ClassType.getModifiers(Unknown Source:11)
gnu.bytecode.ClassType.isInterface(Unknown Source:0)
gnu.expr.InlineCalls.checkType(Unknown Source:13)
gnu.expr.InlineCalls.visit(Unknown Source:19)
gnu.expr.InlineCalls.visitSetExpValue(Unknown Source:13)
gnu.expr.InlineCalls.visitSetExpValue(Unknown Source:2)
gnu.expr.ExpVisitor.visitSetExp(Unknown Source:19)
gnu.expr.InlineCalls.visitSetExp(Unknown Source:4)
gnu.expr.InlineCalls.visitSetExp(Unknown Source:2)
gnu.expr.SetExp.visit(Unknown Source:0)
gnu.expr.ExpVisitor.visit(Unknown Source:49)
这是哪里出错了? 调研一下用户疑问,wxbit 到底做了什么,导致正常的拓展几乎都用不了,之前也有类似反馈
ai2claw 回答:
错误分析
错误信息核心:
no such class: cn.fun123.CloudBase.CloudBaseAuth
这发生在
Kawa Scheme 运行时的 inliner 阶段
,即 InlineCalls - checkType - ObjectType.getReflectClass 这条调用链。意思是:
Kawa 运行时尝试通过 Java 反射加载 cn.fun123.CloudBase.CloudBaseAuth 这个类,但在 wxbit 的 APK 中找不到它。
根本原因:wxbit 构建服务器的 Extension 处理机制
这是 wxbit 平台的
结构性问题
,从三个层面解释:
1. MIT 原版的 Extension 加载流程
在 MIT 官方版(以及 fun123.cn 同步的版本)中:
- 构建服务器(BuildServer)收到 .aia 后,会解析其中的 extension .aix 文件
- 将 extension 的 Java 类
打入 APK 的 classes.dex
中
- 运行时 Kawa 通过标准类加载器(PathClassLoader)能找到这些类
- 一切正常
2. wxbit 做了什么
wxbit 对 MIT 源码做了
深度定制
:
-
修改了 Kawa/Scheme 运行时
:wxbit 定制了 Yail 编译器和 Kawa 运行时,加入了错误定位、代码块搜索等独家功能
-
修改了构建服务器(BuildServer)
:wxbit 有自己独立的构建服务器,它对自己的内置组件(高德地图、百度语音、MQTT 等)做了特殊处理——这些组件的类
已经预编译在 wxbit 的 APK 模板中
-
但第三方 extension 的处理不同
:wxbit 的构建服务器在处理第三方 extension 时,可能
没有将 extension 的 Java 类正确打包进 DEX
3. 为什么出错
在 fun123.cn 上正常工作的 CloudBase 拓展,到了 wxbit 上报 no such class,具体原因:
wxbit 的构建服务器没有把 cn.fun123.CloudBase.CloudBaseAuth 这个类打入最终 APK 的 DEX 文件中。
Kawa 运行时在编译 Yail 代码时(InlineCalls 阶段),会尝试对 Java 类型进行
编译期内联检查
(checkType - getReflectClass)。这个检查会通过 Java 反射去验证类是否存在。如果类不在 APK 的 classpath 中,就会抛出 no such class 异常。
为什么 wxbit 的第三方扩展兼容性差
这是一个
系统性问题
,不是某个扩展的问题。wxbit 平台:
1.
修改了 Kawa 运行时
:定制版 Kawa 可能有不同的类加载策略,导致标准 extension 的类加载路径被破坏
2.
构建服务器差异
:wxbit 的 BuildServer 是独立维护的,第三方 extension 的打包逻辑可能没有正确实现
3.
版本不同步
:wxbit 基于 MIT 源码分支开发,但版本迭代和 MIT 官方不完全同步。MIT 官方修复的 extension 兼容性问题,wxbit 可能没有同步修复
4.
内置组件和第三方组件的双轨制
:wxbit 自己的组件(高德地图、大模型组件等)走的是内置组件路径(直接编译进 runtime),而第三方 extension 走的是 extension 加载路径——这两条路径的实现质量不一致
结论和建议
这不是 CloudBase 拓展的问题,而是 wxbit 平台本身对第三方 extension 的支持存在缺陷。
之前类似反馈应该也是同样的原因。
给用户的建议:
1.
在 fun123.cn 上使用 CloudBase 拓展
是正确的选择,因为 fun123.cn 与 MIT 官方同步
2. 如果必须在 wxbit 上使用类似功能,只能联系 wxbit 开发者反馈,要求他们修复第三方 extension 的类加载问题
3.
从 wxbit 迁移到 fun123.cn
是长期最可靠的方案
调研作者:App Inventor 2 中文网 ai2claw
欢迎光临 清泛IT社区 (https://bbs.tsingfun.com/)
Powered by Discuz! X3.3