Android应用内Mock第三方交互类（非单元测试场景）

First off, let's break down your questions clearly and give you practical, actionable answers:

1. Can Mockito be used in Android runtime (not just unit tests)? #

Yes, but with key caveats. Mockito was built for test environments, but it’s technically feasible to use it in a running Android app—though this should only be done for debug builds or internal tools, never production.

Here’s the breakdown:

• Mockito uses dynamic proxy generation (for interfaces) and bytecode manipulation (for classes) to create mocks. On Android, this works with Dalvik/ART, but compatibility varies by API level.
• For mocking static methods, final classes, or final methods, you’ll need mockito-inline (which uses ByteBuddy under the hood). This works reliably on Android 8.0+ (API 26+); older versions may require extra setup like DexMaker.
• You must add Mockito as a runtime dependency (use implementation or debugImplementation instead of testImplementation), but this will increase your APK size.
• Critical note: ProGuard/R8 will strip Mockito classes and obfuscate target classes in release builds, so runtime Mockito will almost certainly fail in production. Stick to debug builds only.

2. Android Runtime Mockito Boilerplate Code #

First, add the dependencies to your module-level build.gradle:

// Basic mocking (interfaces, non-final classes)
debugImplementation 'org.mockito:mockito-core:5.6.0'
// For mocking static methods, final classes, or spies on final methods
debugImplementation 'org.mockito:mockito-inline:5.6.0'

Example 1: Mock a Third-Party Class #

Suppose you have an unmodifiable third-party class ThirdPartyApi:

// Third-party class you can't edit
public class ThirdPartyApi {
    public String fetchData(String endpoint) {
        // Makes real network calls
        return "Real server response";
    }
}

In your debug-only code (e.g., a debug initializer or settings screen):

import org.mockito.Mockito;

// Create the mock
ThirdPartyApi mockApi = Mockito.mock(ThirdPartyApi.class);

// Define custom return values
Mockito.when(mockApi.fetchData("users")).thenReturn("Mocked user list");
Mockito.when(mockApi.fetchData("posts")).thenThrow(new RuntimeException("Mocked error"));

// Replace the real instance with the mock (use reflection if it's a singleton)
try {
    Field instanceField = ThirdPartyApi.class.getDeclaredField("INSTANCE");
    instanceField.setAccessible(true);
    instanceField.set(null, mockApi);
} catch (Exception e) {
    e.printStackTrace();
}

Example 2: Spy on a Real Object (Override Specific Methods) #

If you want to keep most of the real class’s behavior but override a few methods:

ThirdPartyApi realApi = new ThirdPartyApi();
ThirdPartyApi spyApi = Mockito.spy(realApi);

// Override only the fetchData method for a specific endpoint
Mockito.doReturn("Mocked product data").when(spyApi).fetchData("products");

// Use spyApi instead of the real instance in your app

Example 3: Mock Static Methods (Requires mockito-inline) #

For third-party static utilities:

import org.mockito.MockedStatic;
import org.mockito.Mockito;

// Wrap static calls in a try-with-resources block
try (MockedStatic<ThirdPartyStaticUtils> mockedStatic = Mockito.mockStatic(ThirdPartyStaticUtils.class)) {
    // Customize static method behavior
    mockedStatic.when(() -> ThirdPartyStaticUtils.calculateValue(5)).thenReturn(100);
    
    // Any calls to ThirdPartyStaticUtils.calculateValue(5) will return 100 during this block
}

3. Alternative Frameworks/Solutions (No Proxy Pattern) #

If Mockito feels overkill or problematic for runtime use, here are better options:

• DexMaker: Android’s official library for generating Dalvik/ART bytecode at runtime. It’s what Mockito uses for older Android versions, and you can use it directly to build custom mocks without Mockito’s test-focused overhead.
• ByteBuddy: A powerful bytecode manipulation library that lets you dynamically create or modify classes at runtime. It’s more low-level than Mockito but gives full control—perfect for mocking final classes/methods without relying on Mockito.
• Reflection-Based Stubbing: For simple cases, use reflection or MethodHandles (API 26+) to override method implementations directly. It’s lightweight but requires more boilerplate.
• Debug-Only Dependency Injection: If your app uses DI (like Dagger/Hilt), provide mock implementations of third-party classes in debug builds. This avoids runtime bytecode manipulation entirely—just swap the real dependency with a mock in your debug module. (While this uses dependency inversion, it’s a clean, maintainable alternative to proxy patterns.)

Key Runtime Mocking Caveats #

• Performance: Dynamic bytecode generation can slow down app startup and method calls.
• Compatibility: Behavior may vary across Android versions, especially pre-API 26.
• Stability: Mocking can introduce unexpected side effects, especially if the third-party library has complex internal state.

内容的提问来源于stack exchange，提问作者Igal Avraham