Android第三方支付SDK设计与实践

Android第三方支付SDK设计与实践：从0到1构建安全可靠的支付解决方案

前言

在移动支付日益普及的今天，如何设计一个安全、稳定、易用的第三方支付SDK成为了许多开发者关注的话题。本文将分享我们团队从零开始设计和实现Android第三方支付SDK的完整过程，包括架构设计、技术选型、安全防护、性能优化等方面的实践经验。

一、项目背景与需求分析

业务场景

我们面临的业务场景是：

需要集成多个第三方支付平台（支付宝、微信、银联等）
支付页面为H5页面，需要在App内展示
要求支持多种展示模式（全屏、弹窗）
需要完善的安全防护机制
要求简单易用的API设计

技术挑战

1、安全性: 如何防范各种安全风险？

2、兼容性: 如何适配不同的Android版本和设备？

3、稳定性: 如何保证回调机制的可靠性？

4、易用性: 如何设计简洁的API？

5、可扩展性: 如何支持未来的功能扩展？

二、架构设计

整体架构

我们采用了分层架构设计：

┌─────────────────────────────────────┐
│           业务层 (App)              │
├─────────────────────────────────────┤
│           SDK API层                 │
├─────────────────────────────────────┤
│      UI层    │    Bridge层         │
│  Activity    │   JavaScript        │
│  Dialog      │   Interface         │
├─────────────────────────────────────┤
│         WebView核心层               │
├─────────────────────────────────────┤
│      安全层   │    配置层          │
│   SecurityConfig │ PaymentConfig   │
└─────────────────────────────────────┘

设计流程图

核心组件

1. PaymentSDK - 核心管理器

PaymentSDK作为整个支付系统的核心管理器，采用了单例模式来确保全局唯一性。这个设计决策基于以下几个考虑：首先，支付SDK需要维护全局状态（如安全配置、回调管理等），单例模式能够确保这些状态的一致性；其次，避免重复初始化带来的资源浪费；最后，为开发者提供简洁统一的API入口。

在实现上，我们使用了线程安全的双重检查锁定（Double-Checked Locking）模式，这种方式既保证了线程安全，又避免了不必要的同步开销。延迟初始化的设计让SDK只在真正需要时才创建实例，节省了应用启动时的内存和时间。

class PaymentSDK private constructor() {

    companion object {
        @Volatile
        private var INSTANCE: PaymentSDK? = null

        fun getInstance(): PaymentSDK {
            return INSTANCE ?: synchronized(this) {
                INSTANCE ?: PaymentSDK().also { INSTANCE = it }
            }
        }
    }

    fun init(context: Context, debug: Boolean, securityConfig: SecurityConfig)
    fun pay(activity: Activity, paymentUrl: String, callback: PaymentCallback)
    // ... 其他方法
}

设计亮点:

单例模式确保全局唯一性
延迟初始化节省内存
线程安全的双重检查锁定

2. PaymentWebView - 自定义WebView

PaymentWebView是整个SDK的核心UI组件，它不仅仅是一个简单的WebView封装，而是一个高度定制化的支付容器。我们之所以选择自定义WebView而不是直接使用系统WebView，主要是为了解决以下几个关键问题：

安全性增强：系统WebView的默认配置往往过于宽松，存在安全隐患。我们的自定义WebView集成了多层安全防护，包括域名白名单验证、JavaScript接口安全控制、文件访问限制等。

兼容性保证：不同Android版本和厂商的WebView行为差异很大，自定义WebView让我们能够统一处理这些差异，为开发者提供一致的体验。

功能扩展：我们在标准WebView基础上增加了支付专用功能，如AuthToken自动注入、第三方应用拉起、支付结果回调等。

资源管理：自动的资源清理机制确保WebView不会造成内存泄漏，这在长时间运行的应用中尤为重要。

class PaymentWebView @JvmOverloads constructor(  
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0
) : WebView(context, attrs, defStyleAttr) {

    fun setupWebView(config: WebViewConfig?, listener: PaymentWebViewListener?)
    fun loadPaymentUrl(url: String)
    fun cleanup()
}

设计亮点:

封装了所有WebView相关的复杂逻辑
统一的安全配置和错误处理
自动的资源清理机制

3. PaymentJsBridge - JavaScript桥接

PaymentJsBridge是连接H5页面和原生Android代码的关键桥梁，它的设计直接关系到支付流程的安全性和稳定性。这个组件的复杂性主要体现在需要处理多种不同的交互场景：

多格式数据处理：H5页面可能传递JSON格式的复杂支付结果，也可能只是简单的状态字符串。我们的桥接器需要智能识别并正确解析这些不同格式的数据。

安全防护机制：作为外部数据的入口点，JavaScript桥接器面临着各种安全威胁。我们实现了多层防护：频率限制防止DOS攻击、输入长度限制防止内存溢出、JSON深度检查防止递归攻击、敏感信息过滤防止数据泄露。

异步处理优化：JavaScript调用是异步的，但Android的UI操作必须在主线程进行。我们设计了线程安全的处理机制，确保所有操作都在正确的线程中执行。

动态功能注入：AuthToken注入功能展示了桥接器的灵活性，它能够根据业务需要动态向H5页面注入功能和数据。

方法重构实践：随着功能增加，我们将原本庞大的处理方法拆分为多个职责单一的小方法，这不仅提高了代码可读性，也便于单元测试和维护。

class PaymentJsBridge(  
    listener: PaymentJsBridgeListener,
    securityConfig: SecurityConfig? = null
) {

    @JavascriptInterface
    fun onWebPayResult(resultJson: String)

    @JavascriptInterface
    fun onPageLoaded()

    @JavascriptInterface
    fun getAuthToken(): String

    // 安全验证
    private fun isValidCall(): Boolean
    private fun validateJsonDepth(jsonObject: JSONObject): Boolean
}

设计亮点:

多层安全验证机制
频率限制防止恶意调用
JSON深度检查防止攻击
AuthToken动态注入支持
方法重构提高可维护性

三、安全防护实践

1. 输入验证与过滤

输入验证是安全防护的第一道防线，也是最重要的一道防线。在支付SDK中，我们面临的输入主要来自H5页面的JavaScript调用，这些输入可能包含恶意数据或超出预期的内容。我们的验证策略采用了"白名单+黑名单"的双重机制：

长度限制：防止超大数据导致的内存溢出攻击。我们根据业务需求设定了合理的上限，既能满足正常使用，又能阻止恶意攻击。

结构验证：JSON数据的深度检查防止了递归解析导致的栈溢出。通过限制嵌套层数，我们有效防范了这类攻击。

敏感信息过滤：在生产环境中，我们会自动过滤日志中的敏感信息，如密码、token等，防止信息泄露。这个功能在调试时可以关闭，方便开发调试。

格式校验：确保输入数据符合预期格式，防止格式化字符串攻击和注入攻击。

// JSON长度限制
if (resultJson.length > config.maxJsonLength) {  
    handleSecurityError("支付结果数据过长")
    return
}

// JSON深度验证
if (!validateJsonDepth(jsonObject)) {  
    handleSecurityError("数据结构过于复杂")
    return
}

// 敏感信息过滤
private fun sanitizeMessage(message: String): String {  
    return if (isDebug) {
        message
    } else {
        sensitivePatterns.fold(message) { acc, pattern ->
            acc.replace(pattern, "***")
        }
    }
}

2. 域名白名单机制

域名白名单是防止恶意网页攻击的重要手段。在移动支付场景中，WebView可能被引导到恶意网站，这些网站可能会尝试窃取用户信息或进行其他恶意操作。我们的域名白名单机制提供了灵活而强大的保护：

多种匹配模式：支持精确匹配、通配符匹配和子域名匹配，能够适应不同的业务场景。精确匹配用于已知的固定域名，通配符匹配用于同一服务商的多个子域名，子域名匹配用于大型网站的域名体系。

动态配置能力：白名单可以在运行时动态更新，无需发布新版本就能应对新的安全威胁或业务需求变化。

性能优化：域名匹配算法经过优化，即使在大量域名的情况下也能保持高效的匹配性能。

灵活的策略：当白名单为空时，系统不进行限制，这样可以在开发和测试阶段提供便利，同时在生产环境中提供严格的安全保护。

object DomainUtils {  
    fun isUrlInWhitelist(url: String?, whitelist: List<String>?): Boolean {
        if (whitelist.isNullOrEmpty()) return true // 不设置则不限制

        val domain = extractDomain(url) ?: return false
        return whitelist.any { whitelistDomain ->
            isDomainMatched(domain, whitelistDomain.lowercase())
        }
    }

    private fun isDomainMatched(domain: String, pattern: String): Boolean {
        return when {
            domain == pattern -> true // 完全匹配
            pattern.contains("*") -> Pattern.matches(
                pattern.replace(".", "\\.").replace("*", ".*"), 
                domain
            ) // 通配符匹配
            pattern.startsWith(".") -> domain.endsWith(pattern) // 子域名匹配
            else -> false
        }
    }
}

3. 频率限制防护

频率限制是防范DOS攻击和恶意调用的有效手段。在JavaScript Bridge中，恶意网页可能会尝试高频调用我们的接口，导致应用卡顿甚至崩溃。我们设计了多层次的频率限制机制：

短期快速调用限制：检测短时间内的连续调用，防止恶意脚本的快速攻击。这种攻击通常试图在短时间内发送大量请求，消耗系统资源。

长期调用频率控制：监控较长时间窗口内的调用频率，防止持续的低频攻击。这种攻击可能不会触发短期限制，但会持续消耗系统资源。

动态阈值调整：根据设备性能和网络状况动态调整限制阈值，在保证安全的同时不影响正常使用。

优雅降级处理：当检测到异常调用时，不是简单地拒绝服务，而是记录日志、通知监控系统，并给出友好的错误提示。

重置机制：提供了重置计数器的机制，避免正常用户因为偶发的快速操作被误判。

private fun isValidCall(): Boolean {  
    val currentTime = System.currentTimeMillis()

    // 检查调用间隔
    if (currentTime - lastCallTime < config.minCallInterval) {
        rapidCallCount++
        if (rapidCallCount > config.maxRapidCalls) {
            return false
        }
    } else {
        rapidCallCount = 0
    }

    // 检查每分钟调用次数
    if (currentTime - windowStartTime > RATE_LIMIT_WINDOW) {
        windowStartTime = currentTime
        callCount = 0
    }

    callCount++
    return callCount <= config.maxCallsPerMinute
}

四、内存管理与生命周期

回调管理器设计

我们遇到的一个关键问题是：在Activity模式下，如何确保回调的可靠性？

问题: Activity可能因为内存压力被系统回收，导致回调失效。

解决方案: Activity设计了一个专门的回调管理器：

这个回调管理器的设计体现了我们对Android生命周期管理的深度理解。在移动端开发中，Activity的生命周期是不可预测的，系统可能在任何时候因为内存压力回收Activity。传统的回调机制往往依赖于Activity实例，一旦Activity被回收，回调就会失效。

我们的解决方案是将回调管理提升到Application级别，使用单例模式确保回调管理器不会被系统回收。同时，我们实现了强引用机制来保证回调不会被垃圾回收，并通过重复调用防护来避免同一个支付结果被多次处理。

这种设计的另一个优势是简化了超时机制。我们移除了复杂的超时逻辑，改为简单的状态标记，这不仅提高了系统的稳定性，也降低了维护成本。

object PaymentCallbackManager {  
    private var currentCallback: PaymentCallback? = null
    private var isCallbackProcessed = false

    fun setCallback(callback: PaymentCallback) {
        clearCallback()
        currentCallback = callback
        isCallbackProcessed = false
    }

    fun handlePaymentResult(result: PaymentResult) {
        // 重复调用防护
        if (isCallbackProcessed) {
            LogUtils.w(TAG, "回调已被处理，忽略重复调用")
            return
        }

        val callback = currentCallback
        if (callback == null) {
            LogUtils.w(TAG, "回调未设置，无法处理结果")
            return
        }

        // 标记回调已被处理
        isCallbackProcessed = true

        try {
            when {
                PaymentStatus.isSuccess(result.status) -> callback.onPaymentSuccess(result)
                PaymentStatus.isFailed(result.status) -> callback.onPaymentFailed(result)
                PaymentStatus.isCancelled(result.status) -> callback.onPaymentCancelled(result)
            }
        } catch (e: Exception) {
            LogUtils.e(TAG, "处理支付结果时发生异常", e)
            callback.onPaymentError(e)
        }
    }
}

关键点:

使用强引用保证回调不被GC
移除超时机制，简化逻辑
重复调用防护提高稳定性
异常保护确保回调安全

资源清理机制

资源清理是防止内存泄漏的关键环节，特别是在WebView这样的重量级组件中。WebView不仅占用大量内存，还可能持有各种系统资源，如果不正确清理，很容易导致内存泄漏和性能问题。

我们的清理策略采用了"多层次、全覆盖"的方式：

JavaScript接口清理：移除所有注册的JavaScript接口，防止H5页面继续调用已经无效的方法。

WebView状态重置：清空历史记录、缓存和当前页面，将WebView恢复到初始状态。

引用关系解除：将所有相关的引用设置为null，帮助垃圾回收器及时回收内存。

异常安全保证：整个清理过程都包装在try-catch中，确保即使某个步骤出现异常，也不会影响其他清理操作。

时机控制：清理操作在Activity的onDestroy生命周期中执行，确保在组件销毁时及时释放资源。

class PaymentWebView {  
    fun cleanup() {
        try {
            // 清理JS Bridge
            paymentJsBridge?.cleanup()
            paymentJsBridge = null

            // 清理WebView
            clearHistory()
            clearCache(true)
            loadUrl("about:blank")
            removeJavascriptInterface("WeliPayment")

        } catch (e: Exception) {
            LogUtils.e(TAG, "清理资源时发生异常", e)
        }
    }
}

五、UI设计与用户体验

双模式支持

我们提供了Activity和Dialog两种展示模式：

Activity模式

全屏展示，沉浸式体验
适合复杂的支付流程
系统级别的生命周期管理

Dialog模式

弹窗展示，快速操作
可自定义位置和大小
不影响原页面状态

这种双模式设计的核心思想是"一套代码，多种体验"。无论选择哪种模式，底层的WebView逻辑、安全机制、回调处理都是完全一致的，只是展示方式不同。这样既保证了功能的一致性，又为不同的业务场景提供了灵活性。

在技术实现上，我们使用了策略模式来处理不同的展示逻辑，通过LoadMode枚举来控制具体的展示方式。这种设计让添加新的展示模式变得非常简单，只需要扩展枚举值和对应的处理逻辑即可。

enum class LoadMode {    ACTIVITY,    DIALOG}// 使用示例PaymentSDK.getInstance().pay(    activity = this,    paymentUrl = url,    loadMode = LoadMode.DIALOG,    paymentConfig = PaymentConfig.createBottomDialog())

可配置的UI参数

UI配置的灵活性是提升用户体验的关键因素。不同的应用有不同的设计风格和交互需求，我们的配置系统需要在保持简洁易用的同时，提供足够的定制能力。

我们的配置设计遵循了"约定优于配置"的原则：为每个参数都提供了经过精心调试的默认值，这些默认值适用于大多数场景。同时，我们也提供了丰富的定制选项，让有特殊需求的开发者能够精确控制每个细节。

尺寸控制：通过比例而不是绝对像素来控制尺寸，确保在不同屏幕密度的设备上都能有一致的视觉效果。

位置控制：支持多种重力设置，可以将支付窗口定位在屏幕的任意位置。

视觉效果：圆角、透明度等视觉参数让支付窗口能够完美融入应用的整体设计风格。

交互行为：可取消性、外部点击行为等参数控制用户的交互体验。

data class PaymentConfig(    val widthRatio: Float = 1.0f,           // 宽度比例    val heightRatio: Float = 0.67f,         // 高度比例      val gravity: Int = Gravity.BOTTOM,      // 显示位置    val cornerRadius: Float = 16f,          // 圆角半径    val backgroundAlpha: Float = 0.6f,      // 背景透明度    val cancelable: Boolean = true,         // 是否可取消    val webViewConfig: WebViewConfig? = null // WebView配置)

六、性能优化实践

1. WebView优化

WebView的性能优化是一个复杂的系统工程，涉及到渲染性能、内存使用、网络加载等多个方面。我们的优化策略基于对WebView内部机制的深入理解和大量的性能测试数据。

渲染优化：通过设置高渲染优先级，确保支付页面能够快速渲染。这对于用户体验至关重要，特别是在低端设备上。

缓存策略：在支付场景中，我们选择了不缓存的策略，确保每次都能获取到最新的支付信息。虽然这会增加网络请求，但能够避免因为缓存导致的支付信息不一致问题。

安全配置：根据安全配置动态调整WebView的行为，在安全性和功能性之间找到平衡点。严格SSL模式适用于生产环境，而兼容模式则适用于开发测试环境。

内存管理：通过合理的设置减少WebView的内存占用，特别是在资源受限的设备上。

private fun configureWebViewSettings() {  
    with(settings) {
        // 基础设置
        javaScriptEnabled = config.javaScriptEnabled
        domStorageEnabled = config.domStorageEnabled

        // 性能优化
        cacheMode = WebSettings.LOAD_NO_CACHE // 确保数据实时性
        setRenderPriority(WebSettings.RenderPriority.HIGH)

        // 安全设置
        allowFileAccess = securityConfig.allowFileAccess
        allowContentAccess = securityConfig.allowContentAccess
        mixedContentMode = when (securityConfig.enableStrictSSL) {
            true -> WebSettings.MIXED_CONTENT_NEVER_ALLOW
            false -> WebSettings.MIXED_CONTENT_COMPATIBILITY_MODE
        }
    }
}

2. 内存优化

内存优化是移动应用开发中的永恒主题，特别是在使用WebView这样的重量级组件时。我们的内存优化策略涵盖了整个组件的生命周期，从创建到销毁的每个环节都有相应的优化措施。

及时清理策略：在组件销毁时立即清理所有相关资源，不等待垃圾回收器的自动回收。这种主动清理的方式能够显著减少内存占用时间。

弱引用使用：对于生命周期较长的对象，使用WeakReference来避免强引用导致的内存泄漏。但我们也学会了在关键路径上使用强引用来保证功能的正确性。

Context选择：优先使用ApplicationContext而不是ActivityContext，避免因为Activity引用导致的内存泄漏。

异常安全：所有的清理操作都包装在异常处理中，确保即使某个步骤失败，也不会影响整体的清理过程。

// 及时清理无用资源
override fun onDestroy() {  
    super.onDestroy()
    try {
        paymentWebView.cleanup()
        paymentWebView.destroy()
    } catch (e: Exception) {
        LogUtils.e(TAG, "销毁WebView异常", e)
    }
}

// 使用Application Context避免内存泄漏
fun init(context: Context) {  
    applicationContext = WeakReference(context.applicationContext)
}

3. 日志优化

日志系统是SDK调试和线上问题排查的重要工具，但不当的日志实现可能会带来性能问题和安全风险。我们的日志优化策略在保证调试便利性的同时，也充分考虑了性能和安全因素。

敏感信息保护：在生产环境中自动过滤敏感信息，如密码、token、银行卡号等。我们使用正则表达式来识别这些敏感模式，并将其替换为安全的占位符。

性能优化：日志的格式化和输出是有性能开销的，特别是在高频调用的场景中。我们通过条件检查来避免不必要的字符串操作。

分级控制：不同级别的日志有不同的输出策略，调试日志只在开发环境输出，而错误日志则始终输出以便问题排查。

内存友好：避免在日志中创建大量临时对象，减少GC压力。

object LogUtils {  
    private val sensitivePatterns = listOf(
        Regex("password[\"']?\\s*[:=]\\s*[\"']?[^\\s,}]+", RegexOption.IGNORE_CASE),
        Regex("token[\"']?\\s*[:=]\\s*[\"']?[^\\s,}]+", RegexOption.IGNORE_CASE),
        Regex("\\b\\d{13,19}\\b") // 可能的银行卡号
    )

    private fun sanitizeMessage(message: String): String {
        return if (isDebug) {
            message
        } else {
            sensitivePatterns.fold(message) { acc, pattern ->
                acc.replace(pattern, "***")
            }
        }
    }
}

七、测试策略

1. 单元测试

单元测试是保证代码质量的基础，特别是在支付这样的关键业务场景中。我们的单元测试策略注重覆盖核心业务逻辑和边界条件，确保每个组件都能在各种情况下正确工作。

业务逻辑测试：重点测试支付结果解析、域名白名单验证、安全检查等核心功能。这些功能直接关系到支付的正确性和安全性。

边界条件测试：测试各种边界情况，如空值、超长字符串、特殊字符等。这些测试能够发现潜在的崩溃风险和安全漏洞。

Mock对象使用：通过Mock对象来隔离外部依赖，确保测试的独立性和可重复性。

断言完整性：不仅测试正常情况，也测试异常情况，确保系统在各种情况下都能给出正确的响应。

@Testfun testDomainWhitelist() {    val whitelist = listOf("*.example.com", "test.com")    assertTrue(DomainUtils.isUrlInWhitelist("https://pay.example.com", whitelist))    assertTrue(DomainUtils.isUrlInWhitelist("https://test.com", whitelist))    assertFalse(DomainUtils.isUrlInWhitelist("https://malicious.com", whitelist))}@Testfun testPaymentResultParsing() {    val jsonString = """{"status":"PAYED","message":"支付成功"}"""    val bridge = PaymentJsBridge(mockListener)    // 验证解析逻辑    bridge.onPaymentResult(jsonString)    verify(mockListener).onPaymentResult(any())}

2. 集成测试

我们创建了完整的测试页面：

集成测试是验证各个组件协同工作的重要手段。与单元测试不同，集成测试关注的是组件之间的交互和整体的业务流程。我们创建了一系列H5测试页面来模拟真实的支付场景。

这些测试页面不仅用于功能验证，也是性能测试和用户体验测试的重要工具。通过模拟各种支付结果和异常情况，我们能够确保SDK在各种场景下都能正确处理。

测试页面的设计遵循了真实业务场景的特点，包括不同的数据格式、各种支付状态、异常情况处理等。这种贴近实际的测试方式能够更好地发现潜在问题。

<!-- test_activity_callback.html --><!DOCTYPE html><html><head>    <title>Activity回调测试</title></head><body>    <button onclick="testSuccess()">测试支付成功</button>    <button onclick="testFailed()">测试支付失败</button>    <button onclick="testCancel()">测试用户取消</button>    <script>        function testSuccess() {            WeliPayment.onPaymentResult(JSON.stringify({                status: "PAYED",                message: "支付成功",                responseData: "{\"orderId\":\"123456\"}"            }));        }        // ... 其他测试方法    </script></body></html>

3. 压力测试

压力测试是验证系统在极端条件下稳定性的重要手段。在支付SDK中，我们特别关注高频调用、大数据量、并发访问等场景下的系统表现。

高频调用测试：模拟恶意脚本的快速连续调用，验证频率限制机制的有效性。这种测试能够确保我们的安全防护机制在实际攻击中能够正常工作。

内存压力测试：在内存受限的环境中测试SDK的表现，确保即使在低端设备上也能稳定运行。

并发测试：模拟多个支付流程同时进行的情况，验证线程安全和资源竞争处理。

长时间运行测试：让SDK在长时间运行的环境中工作，检测内存泄漏和性能退化问题。

@Testfun testRapidCalls() {    val bridge = PaymentJsBridge(mockListener, securityConfig = SecurityConfig.createStrict())    // 模拟快速连续调用    repeat(10) {        bridge.onPaymentResult("""{"status":"PAYED"}""")    }    // 验证只有前几次调用生效    verify(mockListener, times(3)).onPaymentResult(any())}

八、线上监控与数据分析

关键指标监控

1、成功率指标

支付发起成功率
H5页面加载成功率
回调到达成功率

2、性能指标

页面加载时间
JavaScript执行时间
内存使用情况

3、安全指标

恶意调用拦截次数
域名白名单命中率
异常错误统计

埋点实现

数据埋点是线上监控的基础，通过收集关键节点的数据，我们能够了解SDK的真实运行状况和用户使用情况。我们的埋点策略注重数据的完整性和隐私保护。

关键节点覆盖：在支付流程的每个关键节点都设置了埋点，包括支付发起、页面加载、结果回调等。这些数据能够帮助我们构建完整的用户行为链路。

性能数据收集：收集页面加载时间、内存使用、网络延迟等性能指标，为性能优化提供数据支持。

错误信息记录：详细记录各种错误情况，包括错误类型、发生频率、影响范围等，为问题修复提供依据。

隐私保护：在收集数据时严格遵循隐私保护原则，不收集用户的敏感信息，所有数据都经过脱敏处理。

数据聚合：通过合理的数据聚合减少网络传输和存储成本，同时保证数据的有效性。

object PaymentAnalytics {  
    fun trackPaymentStart(url: String, mode: LoadMode) {
        Analytics.track("payment_start", mapOf(
            "url_domain" to extractDomain(url),
            "load_mode" to mode.name,
            "timestamp" to System.currentTimeMillis()
        ))
    }

    fun trackPaymentResult(result: PaymentResult, duration: Long) {
        Analytics.track("payment_result", mapOf(
            "status" to result.status,
            "duration_ms" to duration,
            "error_code" to result.errorCode
        ))
    }
}

九、持续优化与版本迭代

版本规划

v1.0: 基础功能完成，支持Activity/Dialog模式
v1.1: 安全功能增强，添加域名白名单
v1.2: 性能优化，内存管理改进
v1.3: 用户体验优化，错误处理完善

技术债务管理

1、定期代码审查: 每个功能完成后进行代码审查

2、重构计划: 定期重构复杂度较高的模块

3、文档更新: 及时更新API文档和使用说明

4、测试覆盖: 保持80%以上的测试覆盖率

十、经验总结与最佳实践

成功经验

1、安全优先: 从设计阶段就考虑安全问题，而不是事后补救

2、渐进增强: 先实现核心功能，再逐步添加高级特性

3、用户至上: API设计要简单易用，降低接入成本

4、完善监控: 线上监控帮助我们快速发现和解决问题

踩过的坑

1、WeakReference过度使用: 一开始为了防止内存泄漏大量使用WeakReference，结果导致回调经常失效

2、生命周期管理: Activity被系统回收导致的回调丢失问题

3、WebView兼容性:不同Android版本的WebView行为差异

4、JavaScript Bridge安全: 没有充分考虑恶意网页的攻击可能性

5、线程安全问题: WebView方法必须在主线程调用，否则会抛出异常

6、方法重构困难: 大方法难以维护，重构时需要拆分为小方法

7、超时机制复杂: 过度复杂的超时逻辑反而降低了系统稳定性

未来规划

1、Kotlin协程支持: 使用协程优化异步操作

2、Jetpack Compose: 考虑支持Compose UI

3、多进程支持: 支持在独立进程中运行WebView

4、插件化架构: 支持动态加载不同的支付插件

5、AI辅助: 集成AI能力，自动检测和处理异常情况

6、性能监控: 更完善的性能监控和自动优化

7、国际化支持: 支持多语言和多地区的支付场景

结语

构建一个优秀的支付SDK需要在安全性、稳定性、性能和易用性之间找到平衡。通过不断的实践和优化，我们的SDK已经能够稳定服务于生产环境。

希望这篇文章能够为正在开发类似功能的同学提供一些参考和启发。如果你有任何问题或建议，欢迎交流讨论！

作者介绍：

米思宇高级Android开发工程师

菜单

Android第三方支付SDK设计与实践：从0到1构建安全可靠的支付解决方案

前言

一、项目背景与需求分析

业务场景

技术挑战

二、架构设计

整体架构

设计流程图

核心组件

1. PaymentSDK - 核心管理器

设计亮点:

2. PaymentWebView - 自定义WebView

设计亮点:

3. PaymentJsBridge - JavaScript桥接

设计亮点:

三、安全防护实践

1. 输入验证与过滤

2. 域名白名单机制

3. 频率限制防护

四、内存管理与生命周期

回调管理器设计

关键点:

资源清理机制

五、UI设计与用户体验

双模式支持

Activity模式

Dialog模式

可配置的UI参数

六、性能优化实践

1. WebView优化

2. 内存优化

3. 日志优化

七、测试策略

1. 单元测试

2. 集成测试

3. 压力测试

八、线上监控与数据分析

关键指标监控

1、成功率指标

2、性能指标

3、安全指标

埋点实现

九、持续优化与版本迭代

版本规划

技术债务管理