解决方案设计

基于前述能力验证，本章提出三种技术方案，覆盖从轻量级到完整功能的不同需求场景。

方案对比矩阵

flowchart TD
    subgraph 方案A[方案 A: 纯静态分析工具链]
        A1[ktlint CLI] --> A2[Detekt CLI]
        A2 --> A3[Twitter Compose Rules]
    end
    
    subgraph 方案B[方案 B: 精简 Gradle 构建]
        B1[Gradle Daemon] --> B2[AGP Lint]
        B2 --> B3[Detekt Gradle Plugin]
    end
    
    subgraph 方案C[方案 C: Language Server 方案]
        C1[Kotlin LSP] --> C2[Compose 分析器]
        C2 --> C3[Harness 适配层]
    end
    
    A1 -.->|轻量级沙盒| D[沙盒环境]
    B1 -.->|资源充足| D
    C1 -.->|实时反馈| D
    
    style 方案A fill:#c8e6c9
    style 方案B fill:#fff3e0
    style 方案C fill:#e3f2fd

方案 A：纯静态分析工具链（推荐）

架构设计

核心组合：ktlint 1.8.0 + Detekt 1.23.8 + Twitter Compose Rules 0.0.26

flowchart LR
    A[代码输入] --> B{文件类型?}
    B -->|.kt 文件| C[ktlint]
    B -->|.kt 文件| D[Detekt]
    
    C -->|风格问题| E[结果聚合]
    D -->|代码质量问题| E
    D -->|Compose 规则| E
    
    E -->|SARIF/JSON| F[Harness 集成]
    
    style C fill:#c8e6c9
    style D fill:#c8e6c9
    style E fill:#e1f5fe

工作流程

# 1. 代码风格检查（ktlint）
ktlint --stdin --stdin-path="$FILE_PATH" --reporter=json

# 2. 代码质量检查（Detekt）
detekt-cli \
  --input "$FILE_PATH" \
  --config /opt/detekt-sandbox.yml \
  --analysis-mode light \
  --report sarif:stdout

# 3. 结果合并（jq 处理）
jq -s '.[0] + .[1]' ktlint-result.json detekt-result.sarif > final-report.json

配置示例

ktlint 沙盒配置（.editorconfig）

root = true

[*.{kt,kts}]
# 基础风格
indent_size = 4
indent_style = space
max_line_length = 120
insert_final_newline = true

# Compose 特定规则
ktlint_function_naming_ignore_when_annotated_with = Composable
ktlint_standard_no-wildcard-imports = disabled

# 沙盒优化：禁用需要项目上下文的规则
ktlint_standard_filename = disabled
ktlint_standard_package-name = disabled

Detekt 沙盒配置（detekt-sandbox.yml）

build:
  # 轻量分析模式，无类型解析
  analysisMode: light
  maxIssues: 0

config:
  validation: true
  warningsAsErrors: false

# 启用 Twitter Compose 规则
compose:
  active: true
  # 强制 Modifier 参数
  ModifierMissing:
    active: true
  # 检测 remember 遗漏
  RememberMissing:
    active: true
  # 检测 State 误用
  MutableStateAutoboxing:
    active: true

# 核心规则集
style:
  active: true
  MagicNumber:
    active: true
    ignoreNumbers: ['-1', '0', '1', '2']
  MaxLineLength:
    active: true
    maxLineLength: 120

complexity:
  active: true
  LongParameterList:
    active: true
    # Compose 函数参数通常较多
    functionThreshold: 8
    constructorThreshold: 8

# 禁用需要类型解析的规则
potential-bugs:
  active: true
  UnsafeCallOnNullableType:
    active: false  # 需要类型解析
  UnsafeCast:
    active: false  # 需要类型解析

优势与局限

适用场景

• ✅ 代码风格门禁（代码提交前检查）
• ✅ 快速 CI 检查（PR 验证）
• ✅ 轻量级 Harness 环境（资源受限）
• ⚠️ 复杂业务逻辑检查（需人工补充）
• ❌ 完整 Android 合规性检查

方案 B：精简 Gradle 守护进程

架构设计

核心思路：在沙盒中运行最小化的 Gradle Daemon，保留必要的 AGP 功能。

flowchart TD
    A[Gradle Daemon] --> B[AGP 8.2]
    B --> C[Android Lint]
    B --> D[Kotlin Compiler]
    
    C --> E[Compose 规则]
    C --> F[Android 规则]
    D --> G[类型解析]
    
    E --> H[Lint 报告]
    F --> H
    G --> I[Detekt 类型解析]
    I --> H
    
    style A fill:#fff3e0
    style B fill:#fff3e0

最小化 Gradle 配置

gradle.properties（沙盒优化）

# 最小内存配置
org.gradle.jvmargs=-Xmx1536m -XX:MaxMetaspaceSize=512m
org.gradle.daemon=true
org.gradle.parallel=false
org.gradle.configureondemand=true

# AGP 优化
android.useAndroidX=true
android.enableJetifier=false
android.nonTransitiveRClass=true
android.nonFinalResIds=true

build.gradle（仅 lint 任务）

plugins {
    id("com.android.library") version "8.2.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.22" apply false
    id("io.gitlab.arturbosch.detekt") version "1.23.8" apply false
}

// 子模块仅启用 lint，禁用其他任务
subprojects {
    tasks.whenTaskAdded {
        if (name !in listOf("lint", "lintDebug", "detekt")) {
            enabled = false
        }
    }
}

Gradle Daemon 预热策略

# Dockerfile：预启动 Gradle Daemon
FROM gradle:8.5-jdk17-alpine

COPY . /project
WORKDIR /project

# 预下载依赖并启动 Daemon
RUN gradle dependencies --no-daemon 2>/dev/null || true
RUN gradle lint --dry-run

# 保持 Daemon 运行
CMD ["gradle", "--status"]

性能基准

优势与局限

适用场景

• ✅ 完整合规性检查（发布前检查）
• ✅ 复杂类型问题检测（空安全、泛型）
• ⚠️ 中等资源沙盒环境（> 2GB 内存）
• ❌ 实时/快速反馈场景
• ❌ 资源受限环境

方案 C：Language Server 协议（LSP）方案

架构设计

核心思路：实现自定义 Kotlin LSP 服务器，专注于 Compose 语义分析。

flowchart TD
    A[IDE/编辑器] -->|LSP| B[Kotlin LSP Server]
    B --> C[PSI 解析器]
    B --> D[Compose 分析引擎]
    
    C --> E[语法树]
    D --> F[Compose 规则]
    
    E --> G[诊断结果]
    F --> G
    G -->|LSP| A
    
    style B fill:#e3f2fd
    style D fill:#e3f2fd

技术栈

核心实现示例

// ComposeLspServer.kt
class ComposeLspServer : LanguageServer {
    private val textDocuments = TextDocumentServiceImpl()
    
    override fun initialize(params: InitializeParams): CompletableFuture<InitializeResult> {
        return CompletableFuture.completedFuture(
            InitializeResult(
                ServerCapabilities().apply {
                    textDocumentSync = TextDocumentSyncKind.Incremental
                    diagnosticProvider = DiagnosticRegistrationOptions(
                        "kotlin",
                        true
                    )
                }
            )
        )
    }
}

// Compose 特定分析
class ComposeAnalyzer {
    fun analyze(file: KtFile): List<Diagnostic> {
        val diagnostics = mutableListOf<Diagnostic>()
        
        file.accept(object : KtVisitorVoid() {
            override fun visitNamedFunction(function: KtNamedFunction) {
                // 检测 Composable 函数命名
                if (function.hasComposableAnnotation()) {
                    if (!function.name!!.startsWithUppercase()) {
                        diagnostics.add(
                            Diagnostic(
                                range = function.nameIdentifier!!.textRange,
                                message = "@Composable 函数名应使用 PascalCase",
                                severity = DiagnosticSeverity.Warning
                            )
                        )
                    }
                }
            }
            
            override fun visitCallExpression(expression: KtCallExpression) {
                // 检测 remember 遗漏
                if (expression.isInComposableContext() &&
                    expression.isExpensiveCall() &&
                    !expression.isWrappedInRemember()) {
                    diagnostics.add(
                        Diagnostic(
                            range = expression.textRange,
                            message = "昂贵计算应使用 remember 缓存",
                            severity = DiagnosticSeverity.Warning
                        )
                    )
                }
            }
        })
        
        return diagnostics
    }
}

增量分析缓存

class IncrementalAnalyzer {
    private val cache = Caffeine.newBuilder()
        .maximumSize(1000)
        .expireAfterWrite(5, TimeUnit.MINUTES)
        .build<String, AnalysisResult>()
    
    fun analyzeIncremental(
        filePath: String,
        content: String,
        changes: List<TextDocumentContentChangeEvent>
    ): List<Diagnostic> {
        val cached = cache.getIfPresent(filePath)
        
        return if (cached != null && changes.isIncremental()) {
            // 仅分析变更区域
            analyzeChangesOnly(cached, changes)
        } else {
            // 全量分析
            val result = analyzeFull(content)
            cache.put(filePath, result)
            result.diagnostics
        }
    }
}

性能基准

优势与局限

适用场景

• ✅ 实时 IDE 反馈（代码编写时）
• ✅ 深度自定义规则需求
• ✅ 长期大规模团队
• ❌ 快速落地场景
• ❌ 资源极度受限

方案选型决策矩阵

flowchart TD
    A[沙盒环境资源] --> B{内存 > 2GB?}
    B -->|是| C[方案 B: 精简 Gradle]
    B -->|否| D{需要实时反馈?}
    D -->|是| E[方案 C: LSP]
    D -->|否| F[方案 A: 纯静态分析]
    
    G[团队规模] --> H{> 50 人?}
    H -->|是| I[推荐方案 C]
    H -->|否| F
    
    J[时间预算] --> K{> 2 周?}
    K -->|是| E
    K -->|否| F
    
    style C fill:#fff3e0
    style E fill:#e3f2fd
    style F fill:#c8e6c9

决策建议

混合策略详解

推荐实施路径：

1. 阶段 1（立即）：部署方案 A

   • 所有开发者在 IDE 中安装 ktlint + Detekt 插件
   • CI 中使用方案 A 进行快速检查（< 30 秒）

2. 阶段 2（1-2 周）：引入方案 B

   • 在 CI 中增加 Gradle Lint 任务（ nightly 运行）
   • 生成完整合规报告

3. 阶段 3（1-2 月，可选）：探索方案 C

   • 开发自定义 LSP 服务器
   • 集成团队特定的 Compose 模式检查

本章提出的三种方案可根据实际需求灵活组合，推荐从方案 A 开始快速验证，逐步演进至更复杂的架构。