[Feature] Improve type safety by reducing 'any' type usage in CDP message handlers

先阅读 src/cdp-proxy/CDPMessageHandlers/ 下的 handlers 和 ICDPMessageHandler 接口，然后检查是否已有可用的 CDP 协议类型。逐步为列出的消息形状定义类型，在需要时添加 guards，并更新 handlers，以替换已识别的 any 用法，同时保留其已处理的消息和行为。

Summary

The CDP (Chrome DevTools Protocol) message handler files use any type extensively, reducing type safety and making the code harder to maintain and debug.

Current Situation

High usage of any type in CDP handlers:

src/cdp-proxy/CDPMessageHandlers/hermesCDPMessageHandler.ts:
- processDebuggerCDPMessage(event: any)
- processApplicationCDPMessage(event: any)
- handleCallFunctionOnEvent(event: any): any
- handleFunctionTypeResult(event: any): any
- handlePausedEvent(event: any): any
- handleBreakpointSetting(event: any): any

src/cdp-proxy/CDPMessageHandlers/iOSDirectCDPMessageHandler.ts:
- processDebuggerCDPMessage(event: any)
- processApplicationCDPMessage(event: any)
- processDeprecatedConsoleMessage(event: any)
- params: any = {}

src/cdp-proxy/CDPMessageHandlers/rnCDPMessageHandler.ts:
- processDebuggerCDPMessage(event: any)
- processApplicationCDPMessage(event: any)
- handleAppBundleFirstPauseEvent(event: IProtocolCommand): any
- params: any = event.params

Interface definition:

interface ICDPMessageHandler {
    processDebuggerCDPMessage: (event: any) => ProcessedCDPMessage;
    processApplicationCDPMessage: (event: any) => ProcessedCDPMessage;
}

Problems with Current Approach

1. No compile-time type checking: Can't catch CDP message structure errors at build time
2. Poor IntelliSense: No autocomplete for CDP message properties
3. Runtime errors: Easy to access non-existent properties without warning
4. Maintainability: Harder to understand expected message structure
5. Refactoring risk: Changes can break code without TypeScript catching it

Proposed Changes

Phase 1: Define CDP Message Types

Create type definitions for CDP protocol messages:

// cdp-proxy/types/CDPMessages.ts

interface CDPEvent {
    method: string;
    params?: Record<string, unknown>;
}

interface CDPCallFunctionOnEvent extends CDPEvent {
    method: 'Runtime.callFunctionOn';
    params: {
        functionDeclaration: string;
        objectId?: string;
        arguments?: any[];
        returnByValue?: boolean;
    };
}

interface CDPPausedEvent extends CDPEvent {
    method: 'Debugger.paused';
    params: {
        callFrames: CallFrame[];
        reason: string;
        data?: Record<string, unknown>;
    };
}

interface CallFrame {
    callFrameId: string;
    functionName: string;
    location: Location;
    scopeChain: Scope[];
}

// ... more type definitions

Phase 2: Update Handler Interfaces

Replace any with proper types:

interface ICDPMessageHandler {
    processDebuggerCDPMessage: (event: CDPEvent) => ProcessedCDPMessage;
    processApplicationCDPMessage: (event: CDPEvent) => ProcessedCDPMessage;
}

Phase 3: Add Type Guards

Implement type guards for runtime type checking:

function isCDPCallFunctionOnEvent(event: CDPEvent): event is CDPCallFunctionOnEvent {
    return event.method === 'Runtime.callFunctionOn';
}

function isCDPPausedEvent(event: CDPEvent): event is CDPPausedEvent {
    return event.method === 'Debugger.paused';
}

Phase 4: Update Handler Implementations

Use type guards in handlers:

public processDebuggerCDPMessage(event: CDPEvent): ProcessedCDPMessage {
    if (isCDPCallFunctionOnEvent(event)) {
        return this.handleCallFunctionOnEvent(event);
    }
    if (isCDPPausedEvent(event)) {
        return this.handlePausedEvent(event);
    }
    // ...
}

private handleCallFunctionOnEvent(event: CDPCallFunctionOnEvent): ProcessedCDPMessage {
    // event.params is now properly typed
    const { functionDeclaration, objectId } = event.params;
    // ...
}

Benefits

• Type safety: Catch CDP message structure errors at compile time
• Better IntelliSense: Autocomplete for CDP message properties
• Self-documenting: Types serve as documentation for CDP protocol usage
• Refactoring safety: TypeScript catches breaking changes
• Debugging: Easier to identify message structure issues
• Maintenance: Clearer code intent and expected structures

Implementation Strategy

1. Start with commonly used CDP message types
2. Add type definitions incrementally (one handler at a time)
3. Use union types for messages with variants
4. Leverage TypeScript's discriminated unions for type narrowing
5. Consider using existing CDP protocol type definitions if available

Potential Challenges

• CDP protocol has many message types
• Some messages have dynamic/flexible structures
• Need to balance type safety with flexibility
• Requires understanding CDP protocol specification

Alternative Approaches

1. Use @types/chrome-devtools-protocol: Leverage existing type definitions
2. Generate types from protocol JSON: Use CDP protocol specification
3. Gradual typing: Start with loose types, refine incrementally
4. Unknown over any: Use unknown instead of any for better safety

References

• CDP Message Handlers: src/cdp-proxy/CDPMessageHandlers/
• Chrome DevTools Protocol: https://chromedevtools.github.io/devtools-protocol/
• Potential types package: @types/chrome-devtools-protocol
• TypeScript discriminated unions: https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#discriminating-unions