本文是我对 AutoX (AutoJs 的开源分支) 项目的深度技术分析，从架构师的角度全面剖析这个 Android 自动化框架的设计与实现。

一、项目基础信息

1.1 基本信息

1.2 SDK 配置

1.3 构建工具版本

1.4 构建变体配置

项目采用 channel 维度的产品风味(Product Flavors)：

flavorDimensions.add("channel")
productFlavors {
    create("common") {
        applicationId = "org.autojs.autoxjs"
        versionCode = 668
        versionName = "6.6.8"
    }
    create("v6") {
        applicationIdSuffix = ".v6"  // org.autojs.autoxjs.v6
        versionCode = 668
        versionName = "6.6.8"
    }
}

同时启用了 ABI 分包：

• arm64-v8a (ARMv8 64位)
• armeabi-v7a (ARM 32位)

二、架构分析

2.1 整体架构模式

经过对源码的深入分析，我发现 AutoX 采用的是混合架构模式，主要以 MVVM 为主，同时保留了大量 MVC 风格的遗留代码：

2.2 模块化结构

项目采用多模块 Gradle 结构，模块划分清晰：

2.3 依赖注入方案

项目没有使用任何 DI 框架（无 Dagger/Hilt/Koin），而是采用手动依赖注入配合服务定位器模式：

服务定位模式示例：

// 单例服务 - Kotlin object
object VersionService2 {
    private val retrofit = Retrofit.Builder()
        .baseUrl("https://api.github.com/")
        .build()
    val gitUpdateCheckApi = retrofit.create<GithubUpdateCheckApi>()
}

// 单例获取 - Java static
public static AutoJs getInstance() {
    return instance;
}

2.4 核心引擎架构

AutoJs 的核心是基于 Mozilla Rhino 的 JavaScript 执行引擎：

2.5 UI 架构演进

项目正处于从传统 View 体系向 Jetpack Compose 迁移的过渡期：

三、代码质量评估

3.1 代码规范遵循情况

3.2 设计模式使用情况

具体使用：

3.3 代码异味(Code Smell)分析

我在源码中发现了以下主要问题：

3.3.1 大型类(God Class)

3.3.2 问题代码示例

// HVScrollView.java 中发现的不专业注释
// TODO: FUCK  <- 这类注释应该被清理

// 2017-2018年的过时TODO仍未处理
// TODO: 2018/10/24
// TODO: 2018/2/24 优化效率。不绘制透明字体。

3.4 单元测试覆盖情况

已有测试：

• XmlConverterTest.java - XML布局转换测试 (5个用例)
• MultiLinePreprocessorTest.java - JS预处理测试 (10个用例)
• 其余多为 Example 模板文件

四、依赖管理

4.1 核心依赖库清单

4.2 依赖版本评估

4.3 废弃/风险库

4.4 依赖冲突风险

// build.gradle.kts 中的强制版本控制
configurations.all {
    exclude(group = "org.jetbrains", module = "annotations-java5")
    exclude(group = "com.github.atlassian.commonmark-java", module = "commonmark")
    resolutionStrategy {
        force("com.google.code.findbugs:jsr305:3.0.1")
    }
}

五、性能与安全

5.1 内存泄漏风险

具体问题代码：

// Events.java - 监听器添加但从未移除
public void observeKey() {
    service.getOnKeyObserver().addListener(this);  // ❌ 无对应的 removeListener
}

public void observeTouch() {
    mTouchObserver.setOnTouchEventListener(this);  // ❌ 无清理
    mTouchObserver.observe();
}

5.2 主线程阻塞风险

// HttpUtil.java - 主线程网络请求
public static String doPost(String posturl) {
    HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
    urlConnection.setReadTimeout(5000);   // 可能阻塞5秒
    urlConnection.setConnectTimeout(5000);
    urlConnection.connect();  // ❌ 同步阻塞
    // ...
}

5.3 ProGuard/R8 混淆配置

严重问题：Release 版本未启用混淆！

// app/build.gradle.kts
named("release") {
    isShrinkResources = false
    isMinifyEnabled = false  // ❌ 生产环境未混淆！
}

过度宽泛的 keep 规则：

# proguard-rules.pro - 整个包都被保留
-keep class org.mozilla.javascript.** { *; }
-keep class com.stardust.automator.** { *; }
-keep class com.stardust.autojs.** { *; }

5.4 网络安全问题

具体问题：

// FeatureActivity.java - 硬编码HTTP
private String url = "http://mk.autoxjs.com/pages/ykapp/choiseFeature";  // ❌ HTTP

// WebView 安全配置不足
settings.setJavaScriptEnabled(true);
settings.setJavaScriptCanOpenWindowsAutomatically(true);  // ❌ 风险

5.5 安全问题汇总

六、改进建议

6.1 架构优化建议

6.2 技术债务清单

6.3 迁移建议

Java → Kotlin 迁移路径

View → Compose 迁移策略

1. 新功能优先使用 Compose
2. 逐步迁移简单页面 (Settings, About)
3. 复杂页面保持 View (Editor, Explorer)
4. 建立 Compose 组件库

6.4 优先级排序的重构计划

七、总结

AutoX 是一个功能强大的 Android 自动化框架，其核心 Rhino JavaScript 引擎和丰富的 API 设计体现了较高的工程水平。然而，作为一个社区维护的开源项目，它也面临着一些典型的技术债务问题：

优势：

• 模块化设计清晰，职责分离合理
• 多 OCR 引擎支持（Tesseract、MLKit、PaddleOCR）
• 正在积极向现代架构迁移（Compose、Coroutines）

待改进：

• 测试覆盖率极低（0.65%）
• 安全配置缺失（HTTP、未混淆）
• 存在内存泄漏风险
• Java/Kotlin、RxJava/Coroutines 混用增加维护成本

对于想要基于此项目进行二次开发的开发者，我建议优先解决 P0 级别的安全和稳定性问题，然后逐步进行架构现代化改造。

本文基于 AutoX v6.6.8 版本源码分析