HarmonyOS鸿蒙Next中内部使用axios网络请求和混淆问题

在HarmonyOS Next开发中，当模块开启属性混淆后，其引用的HAR包（即使该HAR未混淆）内的axios网络请求出现TypeError: undefined is not callable错误，这通常是由于混淆过程破坏了模块与HAR之间、或HAR内部JavaScript（或ArkTS）代码的运行时绑定关系导致的。

问题核心原因分析

1. 跨模块属性访问失效：属性混淆会重命名模块内（包括其依赖）的类名、方法名、属性名等标识符。虽然你的HAR在打包时未开启混淆，但其对外暴露的API接口（例如导出的类、函数、对象属性）在被主模块引用时，主模块的混淆器可能无法正确识别这些来自未混淆HAR的引用。导致在主模块的混淆后代码中，调用HAR内axios相关方法的语句，其引用的方法名或对象路径可能被错误地重命名或无法解析，从而在运行时变为undefined。

2. 反射或动态调用中断：Axios或其底层适配器可能依赖一些动态属性查找或反射机制（例如通过字符串键名调用方法）。属性混淆重命名了这些属性键名，但运行时动态调用的代码字符串并未同步更新，导致找不到对应实现。

3. HAR的发布形态影响：HAR以release模式打包但未混淆，其内部的代码结构是清晰的。然而，当它被集成到一个开启属性混淆的主模块中时，主模块的混淆处理阶段可能需要明确的规则来保留对HAR公共接口的引用。如果缺乏这些规则，混淆工具可能会“误伤”这些跨模块的引用点。

解决方案

关键在于指导混淆工具（ProGuard/R8或其鸿蒙等效工具）保留HAR对外暴露的、以及HAR内部axios网络请求所必需的接口和属性不被混淆。

你需要在主模块（即引入HAR并开启混淆的模块）的混淆配置文件中添加相应的“保持”（-keep）规则。具体位置通常在模块的build-profile.json5或独立的ProGuard规则文件（如proguard-rules.pro）中。

建议添加的混淆保留规则示例：

1. 保留HAR包中所有公开的类和方法（如果HAR是你自己开发的，且知道其包名）：

   # 假设你的HAR包名为 com.example.mylibrary
   -keep class com.example.mylibrary.** { *; }
   

2. 如果无法明确HAR包结构，或问题出在axios内部，可尝试更宽泛地保留所有可能涉及网络请求的属性和方法（注意：这可能会略微减小混淆效果）：

   # 保留名称中包含“axios”、“http”、“request”、“adapter”等关键词的类、方法和字段
   -keepclasseswithmembers class * {
       *** axios***;
       *** http***;
       *** request***;
       *** adapter***;
   }
   # 保留所有可能被反射调用的方法（如果axios使用了反射）
   -keepattributes RuntimeVisibleAnnotations, RuntimeVisibleParameterAnnotations
   -keepclassmembers class ** {
       @android.webkit.JavascriptInterface public *;
       public *;
   }
   

3. 最直接但粒度较粗的方法：如果上述规则仍不奏效，且问题确由混淆引起，可以暂时针对性地排除对axios库本身的混淆（如果你知道axios在HAR中的具体封装类或路径）：

   # 保持axios核心类不被混淆（示例路径，需根据实际调整）
   -keep class axios.**
   -keep class * implements axios.AxiosInstance
   -keepclassmembers class * {
       public <methods>;
   }
   

操作步骤

1. 定位主模块的混淆配置文件。
2. 将上述适合的-keep规则添加到配置文件中。
3. 清理项目（执行Clean Project）后重新使用release模式构建。

总结

根本原因是主模块的混淆过程未能自动识别并保留对未混淆HAR内部关键接口（特别是axios相关）的引用。通过添加混淆保留规则，明确告知工具哪些类、方法或属性必须保持原样，即可解决此问题。这属于混淆配置的精细调优，是保障跨模块调用在混淆后仍能正常工作的常见步骤。