内存泄漏检测：发现隐藏泄漏的工具

Ehtan_Zheng2026-03-13 9:37

导致 200,000+ 用户崩溃的漏洞

在一家大型银行应用在高峰时段遭遇了超过 20 万用户的集体崩溃。罪魁祸首？一个累积了数周之久的微小内存泄漏。调查显示，一个简单的监听器（listener）未被注销，导致每次会话消耗 500KB 内存。在用户打开 50 多个 Activity 后，应用就会因内存耗尽而崩溃。

产生的影响：

  • 6 小时 的停机时间
  • 200,000+ 受影响用户
  • 数千条 1 星评价
  • 开发者连续 3 周 加班
  • 用户信任度 彻底丧失

修复方案： 仅需 一行代码 来注销监听器。

本文将揭示那些能在进入生产环境前，就揪出这些"静默杀手"的精准工具。

通过阅读本文，你将学会：

  • 即时捕捉泄漏 ：如何使用 LeakCanary 在开发阶段瞬间发现内存泄漏。
  • 深度内存分析 ：熟练掌握 Android Profiler 进行实时内存监控与数据挖掘。
  • 堆转储取证 ：利用 MAT (Memory Analyzer Tool) 这一强大工具对堆转储文件进行深度"取证"分析。
  • 定位 WebView 泄漏 ：巧妙利用 Chrome DevTools 解决混合开发中棘手的 WebView 内存问题。
  • 自动化检测 ：如何在 CI/CD 流水线 中集成内存泄漏自动化检测。
  • 实战案例：剖析真实场景下的案例，并提供经过验证的修复方案。

装备库：你的内存泄漏检测工具箱

1. LeakCanary：守护天使

开发者：Square

LeakCanary 是你的第一道防线。它能自动检测应用中的内存泄漏，并精确指出泄漏发生的地点。

集成步骤（仅需 30 秒）

在你的 build.gradle 文件中添加以下依赖即可完成安装。LeakCanary 会自动挂载到应用的生命周期中，无需在代码中编写额外的初始化逻辑。

arduino 复制代码 
dependencies {
  // debugImplementation 确保 LeakCanary 只在调试版本中运行
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.x'
}

装备库：你的内存泄漏检测工具箱

1. LeakCanary：守护天使

开发者：Square

LeakCanary 是你的第一道防线。它能自动检测应用中的内存泄漏，并精确指出泄漏发生的地点。

集成步骤（仅需 30 秒）

在你的 build.gradle 文件中添加以下依赖即可完成安装。LeakCanary 会自动挂载到应用的生命周期中，无需在代码中编写额外的初始化逻辑。

Gradle

arduino 复制代码 
dependencies {
  // debugImplementation 确保 LeakCanary 只在调试版本中运行
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.x'
}

核心工作原理

  1. 自动监测 ：它利用 ActivityLifecycleCallbacks 自动监控 Activity 和 Fragment 的销毁情况。
  2. 存活检查 ：当 onDestroy() 被调用 5 秒后，它会检查该对象是否已被回收。
  3. 堆转储分析 ：如果对象仍然存活，它会触发 Heap Dump （堆转储），并利用内置的 Shark 引擎分析引用链。
  4. 直观反馈：一旦确认泄漏，它会推送通知并展示一条清晰的"泄漏路径"，告诉你究竟是哪个静态变量或长生命周期对象"拽着"本该销毁的页面不撒手。

实战案例：Activity 内存泄漏

kotlin 复制代码 
class ProfileActivity : AppCompatActivity() {  
    private lateinit var userRepository: UserRepository  

    override fun onCreate(savedInstanceState: Bundle?) {  
        super.onCreate(savedInstanceState)  
        setContentView(R.layout.activity_profile)  

        userRepository = UserRepository.getInstance()  

        // LEAK: Activity holds reference after destroy  
        userRepository.addListener(object : UserUpdateListener {  
            override fun onUserUpdated(user: User) {  
                updateUI(user)  
            }  
        })  
    }  
  
// Missing cleanup in onDestroy()!  
}

LeakCanary 分析结果:

yaml 复制代码 
┬───  
│ GC Root: Thread local variable  
│  
├─ com.example.app.UserRepository instance  
│ Leaking: NO  
│ ↓ UserRepository.listeners  
├─ java.util.ArrayList instance  
│ Leaking: NO  
│ ↓ ArrayList[0]  
├─ com.example.app.ProfileActivity$onCreate$1 instance  
│ Leaking: YES (Activity destroyed but still held)  
│ ↓ ProfileActivity$onCreate$1.this$0  
╰→ com.example.app.ProfileActivity instance  
Leaking: YES  
Activity retained after destroy!

修复代码：

修复方法非常简单，只需确保在生命周期结束时手动"解绑"引用：

kotlin 复制代码 
class ProfileActivity : AppCompatActivity() {  
    private lateinit var userRepository: UserRepository  
    private lateinit var listener: UserUpdateListener  

    override fun onCreate(savedInstanceState: Bundle?) {  
        super.onCreate(savedInstanceState)  
        setContentView(R.layout.activity_profile)  

        userRepository = UserRepository.getInstance()  

        listener = object : UserUpdateListener {  
        override fun onUserUpdated(user: User) {  
            updateUI(user)  
            }  
        }  
        userRepository.addListener(listener)  
        }  

        override fun onDestroy() {  
            super.onDestroy()  
            // Clean up!  
            userRepository.removeListener(listener)  
        }  
}

提示：

  • 仅限调试版本运行 ：默认情况下，LeakCanary 仅在 debug 构建变体中运行。它通过 debugImplementation 引入，这意味着它不会增加正式包（release build）的体积，也不会影响线上用户的性能。

  • 通过 AppWatcher.Config 自定义检测逻辑：你可以根据需求调整 LeakCanary 的行为。例如，修改对象在被判定为泄漏之前的等待时长（默认为 5 秒），或者关闭对特定类型对象（如 Fragment）的监控。

    Kotlin

    arduino 复制代码 
    // 在 Application 类中自定义配置
AppWatcher.config = AppWatcher.config.copy(watchDurationMillis = 10000)

  • 多渠道查看分析结果 ：除了点击手机上的弹窗通知外，你还可以在 Logcat 中搜索 LeakCanary 标签，查看结构化的文本路径。这对于将泄漏日志直接复制到 Bug 追踪系统（如 Jira 或 GitHub Issues）中非常方便。

2. Android Profiler：深度分析利器

Android Profiler 能够提供实时内存使用情况，并允许你捕获**堆转储（Heap Dumps）**进行深度分析。

操作步骤

  1. 打开工具 ：在 Android Studio 中选择 View → Tool Windows → Profiler。
  2. 选择进程：在 Profiler 窗口中选择你正在运行的应用进程。
  3. 进入详情 ：点击 Memory 区域，进入详细的内存监控界面。

解读内存图表

yaml 复制代码 
Memory Timeline:  
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━  
100MB ┤ ╭╮ ╭──╮ ╭─── ⚠️ Leak suspected!  
┤ ╱ ╰╮ ╱ ╰╮ ╱  
50MB ┤ ╱ ╰─╯ ╰───╯  
┤ ╱  
0MB ┼─────────────────────────────────  
0s 10s 20s 30s 40s 50s

案例研究：ViewPager 中的 Fragment 泄漏

场景描述 ：一个带有 5 个标签页（Tabs）的新闻应用，使用 ViewPager 实现，每个标签页都是一个 Fragment。用户在切换 20 多次标签页后，应用因 OOM (内存溢出) 而崩溃。

调查步骤：

  1. 捕获堆转储 (Capture Heap Dump) ： 在 Profiler 界面中点击"相机"图标。这将暂停应用并抓取当前内存中所有对象的快照。

  2. 按分配排序 (Arrange by Allocation) ： 在结果列表中，找到 "Retained Size" (保留大小) 列并进行降序排列。

    • Shallow Size：对象本身占用的内存。
    • Retained Size：对象及其所持有的所有引用对象占用的总内存。这是寻找"罪魁祸首"的关键指标。

  3. 查找重复实例 ： 搜索你的 Fragment 类名。如果你发现同一个 Fragment（例如 NewsFragment）有 10 到 20 个实例同时存在，而当前屏幕上只应该有 1 到 2 个，那么你就锁定了泄漏。

css 复制代码 
Class Name | Instances | Shallow Size | Retained Size  
------------------------------|-----------|--------------|---------------  
NewsFragment | 23 | 1.2 KB | 45 MB ⚠️  
ArticleAdapter | 23 | 800 B | 42 MB ⚠️  
ImageView | 230 | 156 B | 38 MB ⚠️

预期结果：5 个 NewsFragment 实例（每个标签页一个） 实际结果：23 个实例！

根本原因：

kotlin 复制代码 
class NewsViewPagerAdapter(fm: FragmentManager) : FragmentPagerAdapter(fm) {  
    // WRONG: Default behavior retains all fragments  
    override fun getItem(position: Int): Fragment {  
        return NewsFragment.newInstance(position)  
    }  
}

修复方案

kotlin 复制代码 
class NewsViewPagerAdapter(fm: FragmentManager) :  
    FragmentPagerAdapter(fm, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) {  
    // Correct: Only keeps current fragment  

        override fun getItem(position: Int): Fragment {  
            return NewsFragment.newInstance(position)  
        }  
 }  

// Better: Use ViewPager2 with FragmentStateAdapter  
class NewsViewPager2Adapter(fragment: Fragment) :  
    FragmentStateAdapter(fragment) {  

    override fun getItemCount(): Int = 5  

    override fun createFragment(position: Int): Fragment {  
        return NewsFragment.newInstance(position)  
    }  
}

3. MAT (Memory Analyzer Tool)：取证专家

Eclipse Memory Analyzer

MAT 适用于你需要进行严肃的内存取证时。它就像是你堆转储（heap dumps）的 CSI（犯罪现场调查）。

入门指南

  1. 从 Android Studio Profiler 捕获堆转储 ：获取 .hprof 文件。

  2. 转换为标准格式：使用 Android SDK 自带的工具，将 Profiler 生成的堆转储转换为 MAT 可读取的标准格式：

    hprof-conv heap-dump.hprof heap-dump-mat.hprof

  3. 在 MAT 中打开

使用 MAT 查找泄漏

功能 #1：支配树 (Dominator Tree)

erlang 复制代码 
Dominator Tree:  
├─ com.example.app.MainActivity (45% heap)  
│ ├─ android.view.ViewGroup (30% heap)  
│ │ ├─ ImageView (25% heap) ⚠️  
│ │ │ └─ Bitmap (24 MB)  
│ │ └─ TextView (2% heap)  
│ └─ UserRepository (10% heap)

支配树会显示按"保留堆大小"（Retained Heap Size）排序的对象列表。

  • 它的原理 ：在对象图中，如果通往对象 B 的每一条路径都必须经过对象 A，那么就称 A 支配 B。这意味着如果对象 A 被垃圾回收，那么对象 B 也将被回收。
  • 为何强大 ：它能让你一眼看出是谁"拽住"了大量的内存。即使一个对象本身（Shallow Heap）很小，但如果它支配着成千上万个其他对象，它在支配树中的 Retained Heap 就会变得异常巨大。

功能：泄漏嫌疑报告 (Leak Suspects Report)

MAT 会自动识别可能的泄漏点。

vbnet 复制代码 
Problem Suspect 1:  
────────────────────────────────────────────────  
One instance of "com.example.app.ChatActivity"  
loaded by "dalvik.system.PathClassLoader"  
occupies 42.8 MB (85% of total heap).  
Details:  
• Activity has been destroyed  
• Still referenced by static field in UserManager  
• Holds 150 Bitmap objects

真实案例：静态引用泄漏

kotlin 复制代码 
// ❌ DISASTER: Static context reference  
object AnalyticsManager {  
    private var context: Context? = null // Memory bomb!  

    fun initialize(context: Context) {  
        this.context = context  
    }  

    fun trackEvent(event: String) {  
        context?.let { ctx ->  
            // Use context...  
        }  
    }  
}  

    // Called from Activity  
class MainActivity : AppCompatActivity() {  
    override fun onCreate(savedInstanceState: Bundle?) {  
        super.onCreate(savedInstanceState)  
        AnalyticsManager.initialize(this) // Leaks entire Activity!  
    }  
}

MAT分析

php 复制代码 
Shortest Path to GC Root:  
────────────────────────────────────────  
AnalyticsManager (static)  
↓ context field  
MainActivity (Leaked)  
↓ mDecor field  
PhoneWindow$DecorView  
↓ children array  
LinearLayout  
↓ children array  
ImageView[150 instances]  
↓ mBitmap field  
Bitmap (45 MB total)

修复方案

kotlin 复制代码 
// Use Application Context  
object AnalyticsManager {  
    private var context: Context? = null  

    fun initialize(context: Context) {  
        // Store only Application context (lives forever anyway)  
        this.context = context.applicationContext  
    }  

    fun trackEvent(event: String) {  
        context?.let { ctx ->  
        // Safe to use Application context  
        }  
    }  
}

4. Chrome DevTools：WebView 专家

Chrome DevTools Protocol

如果你的应用使用了 WebViews，那么 Chrome DevTools 对于检测 JavaScript 内存泄漏至关重要。

设置 WebView 调试 (Setup)

要通过 Chrome 调试 WebView，你需要在 Android 代码中显式开启该功能。

kotlin 复制代码 
class ArticleActivity : AppCompatActivity() {  
    override fun onCreate(savedInstanceState: Bundle?) {  
        super.onCreate(savedInstanceState)  

        val webView = findViewById<WebView>(R.id.webView)  

        // Enable debugging  
        if (BuildConfig.DEBUG) {  
            WebView.setWebContentsDebuggingEnabled(true)  
        }  

        webView.loadUrl("https://example.com/article")  
    }  
}

调试步骤

  1. 打开 Chrome：在地址栏输入 chrome://inspect。
  2. 选择你的 WebView：在设备列表中找到对应的页面并点击 "inspect"。
  3. 进入 Memory 标签页：在开发者工具顶部菜单中选择 Memory。
  4. 拍摄堆快照 (Take Heap Snapshot) ：点击底部的圆点按钮进行拍摄。

案例研究：事件监听器泄漏 (Event Listener Leak)

WebView 中的 JavaScript 代码：

javascript 复制代码 
// Leak: Event listeners accumulate  
function initializeArticle() {  
    const shareButton = document.getElementById('share');  

    // This adds a NEW listener every time!  
    shareButton.addEventListener('click', function() {  
        Android.shareArticle(document.title);  
    });  
}  
  
// Called every time article changes (100+ times per session)  
function loadArticle(articleId) {  
    fetchArticle(articleId).then(article => {  
        renderArticle(article);  
        initializeArticle(); // Adds duplicate listeners!  
    });  
}

Chrome DevTools 分析

less 复制代码 
Detached DOM tree:  
├─ Detached div#article-container (25 instances) ⚠️  
│ ├─ button#share (25 instances)  
│ │ └─ 25 click event listeners (125 KB)

修复方案

javascript 复制代码 
// Remove old listeners first
let shareButtonHandler = null;

function initializeArticle() {
    const shareButton = document.getElementById('share');
    
    // Remove old listener
    if (shareButtonHandler) {
        shareButton.removeEventListener('click', shareButtonHandler);
    }
    
    // Add new listener
    shareButtonHandler = function() {
        Android.shareArticle(document.title);
    };
    shareButton.addEventListener('click', shareButtonHandler);
}
// Even better: Use event delegation
document.addEventListener('click', function(e) {
    if (e.target.id === 'share') {
        Android.shareArticle(document.title);
    }
});

5. CI/CD 中的自动化泄漏检测

测试环境中的 LeakCanary

不要等到上线后再处理！在 CI 流水线中就将泄漏扼杀在摇篮里。

带 LeakCanary 的插桩测试 (Instrumentation Test)

你可以将 LeakCanary 集成到你的 UI 自动化测试（如 Espresso 脚本）中。这样，每当运行功能测试时，系统都会自动检测内存泄漏。

实现步骤：

  1. 引入依赖 ：确保 leakcanary-android-instrumentation 已添加到你的 androidTestImplementation 中。
  2. 配置 TestRule ：在你的测试类中添加 LeakCanary 提供的规则，它会在每个测试用例结束时自动运行泄漏分析。
kotlin 复制代码 
@RunWith(AndroidJUnit4::class)  
class ProfileActivityLeakTest {  
  
    @get:Rule  
    val activityRule = ActivityScenarioRule(ProfileActivity::class.java)  

    @Test  
    fun profileActivity_noMemoryLeak() {  
        // Simulate user navigation  
        activityRule.scenario.onActivity { activity ->  
        // Perform actions  
        activity.findViewById<Button>(R.id.loadProfile).performClick()  
        Thread.sleep(1000)  
        }  

        // Finish activity  
        activityRule.scenario.close()  

        // Force GC  
        Runtime.getRuntime().gc()  
        Thread.sleep(2000)  

        // Check for leaks  
        val leaks = AppWatcher.objectWatcher.hasWatchedObjects  
        assertFalse("Activity leaked!", leaks)  
    }  
}

CI 参考配置 (GitHub Actions)

yaml 复制代码 
name: Memory Leak Detection
on: [pull_request]
jobs:
  leak-detection:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          
      - name: Run Leak Tests
        run: ./gradlew connectedDebugAndroidTest
        
      - name: Check Leak Reports
        run: |
          if grep -r "LEAK DETECTED" app/build/reports/; then
            echo "Memory leaks found!"
            exit 1
          fi

成功案例：真实的泄漏，真实的修复

案例 1：电商应用 ------ 崩溃率降低 70%

问题描述：用户在结账（Checkout）过程中，应用频繁发生 OOM（内存溢出）错误并崩溃。

调查过程 (Investigation)：

  1. LeakCanary 预警 ：在测试环境中，LeakCanary 明确指出 ProductDetailsActivity 发生了泄漏。
  2. Profiler 深度分析 ：通过 Android Profiler 查看堆快照，发现内存中竟然堆积了 45 个 Activity 实例。
  3. 锁定根源：

根本原因 (Root Cause)： 代码中使用了 AsyncTask（异步任务）来加载商品详情。用户在加载未完成时反复点击并退出页面。由于 AsyncTask 作为一个非静态内部类 ，它隐式持有了 ProductDetailsActivity 的引用。只要后台网络请求没结束，该 Activity 就永远无法被回收

kotlin 复制代码 
// Before: 
class LoadProductTask(private val activity: ProductDetailsActivity) : AsyncTask<...>() {
    override fun doInBackground(...) { ... }
    
    override fun onPostExecute(result: Product) {
        activity.displayProduct(result)  // Leaks if Activity destroyed!
    }
}

// After: 
class LoadProductTask(activity: ProductDetailsActivity) : AsyncTask<...>() {
    private val activityRef = WeakReference(activity)
    
    override fun doInBackground(...) { ... }
    
    override fun onPostExecute(result: Product) {
        activityRef.get()?.displayProduct(result)  // Safe!
    }
}
// Even Better: Use Coroutines + ViewModel
class ProductViewModel : ViewModel() {
    private val _product = MutableLiveData<Product>()
    val product: LiveData<Product> = _product
    
    fun loadProduct(id: String) {
        viewModelScope.launch {
            _product.value = repository.getProduct(id)
        }
    }
}

案例 2：社交媒体应用 ------ 电池寿命提升 3 倍

问题描述：应用在后台运行期间消耗电量极快。

调查过程 (Investigation)：

  1. Profiler 实时监控 ：Android Profiler 显示内存分配曲线持续上升，即便应用处于闲置状态，内存占用也从未下降。
  2. MAT 深度取证 ：通过 MAT 分析堆转储文件，直观地发现内存中存在 1000 多个 BroadcastReceiver 实例。

根本原因 (Root Cause)： 在社交应用的动态刷新逻辑中，开发者在 onResume() 中注册了用于监听网络状态或新消息通知的 BroadcastReceiver，但却忘记在 onPause() 或 onStop() 中注销。

由于广播接收器被系统服务（System Server）通过强引用持有，导致每次 Activity 重启或配置变更（如旋转屏幕）时，旧的接收器都会残留在内存中。这些"僵尸"接收器不仅占用内存，还会持续响应系统广播并触发逻辑，导致 CPU 频繁唤醒，从而排干了电池。

kotlin 复制代码 
class FeedActivity : AppCompatActivity() {
    private val networkReceiver = NetworkChangeReceiver()
    
    override fun onResume() {
        super.onResume()
        // Register
        registerReceiver(networkReceiver, IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION))
    }
    
    override fun onPause() {
        super.onPause()
        // Unregister
        unregisterReceiver(networkReceiver)
    }
}

案例 3：新闻应用 ------ WebView 内存爆炸

问题描述 ：用户在阅读 10 篇文章后，应用内存占用从 50MB 飙升至 500MB，导致低端机型频繁卡顿。

调查过程 (Investigation)：

  1. Chrome DevTools 诊断 ：通过 chrome://inspect 连接 WebView，拍摄堆快照（Heap Snapshot）。
  2. 发现异常 ：快照中显示存在 50 多个脱离文档的 DOM 树（Detached DOM trees） 。这意味着 HTML 元素已经从页面中移除，但它们在内存中依然存活。

根本原因 (Root Cause)： 新闻页面的 JavaScript 逻辑在文章切换时，没有手动移除全局事件监听器（Event Listeners）。

  • 闭包陷阱 ：每一个监听器（如 window.addEventListener('resize', ...)）都通过闭包持有了对文章容器或大图的引用。
  • 链式反应：即便 WebView 加载了新文章，旧文章的 DOM 节点依然被这些全局监听器牢牢"拽住"，导致内存无法被回收。
javascript 复制代码 
class ArticleActivity : AppCompatActivity() {
    private lateinit var webView: WebView
    
    override fun onDestroy() {
        super.onDestroy()
        
        // ✅ Proper WebView cleanup
        webView.clearHistory()
        webView.clearCache(true)
        webView.loadUrl("about:blank")
        webView.onPause()
        webView.removeAllViews()
        webView.destroyDrawingCache()
        webView.destroy()
    }
}

自定义泄漏检测 (Custom Leak Detection)

虽然 LeakCanary 等工具非常强大，但有时你需要针对业务中的关键对象（如大型缓存、单例监听器或自定义引擎实例）建立专属的监控机制。

kotlin 复制代码 
object LeakWatcher {
    private val watchedObjects = mutableMapOf<String, WeakReference<Any>>()
    
    fun watch(obj: Any, tag: String) {
        watchedObjects[tag] = WeakReference(obj)
    }
    
    fun checkLeaks() {
        Runtime.getRuntime().gc()
        Thread.sleep(1000)
        
        watchedObjects.forEach { (tag, ref) ->
            if (ref.get() != null) {
                Log.e("LeakWatcher", "Potential leak: $tag")
            }
        }
    }
}

// Usage
class MyActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        LeakWatcher.watch(this, "MyActivity-${System.currentTimeMillis()}")
    }
}

必备资源库 (Essential Resources)

核心工具 (Tools)

  • 📦 LeakCanary --- 自动化内存泄漏检测

    • 用途：开发阶段的"标配"，通过自动捕获堆转储并生成引用链，帮你拦截大部分 Activity 和 Fragment 泄漏。

  • 🔧 Android Studio Profiler --- 实时监控

    • 用途：集成在 IDE 中的全能监测器，用于观察内存实时波动、排查内存抖动以及捕获原始堆快照。

  • 🔬 Eclipse MAT (Memory Analyzer Tool) --- 堆转储深度分析

    • 用途：内存取证专家。当你需要通过支配树（Dominator Tree）和复杂查询语言（OQL）分析大型、复杂的堆快照时，它是不可替代的。

  • 🌐 Chrome DevTools --- WebView 调试

    • 用途：针对混合开发（Hybrid）应用，专门用于检测 WebView 内部的 JavaScript 对象和 DOM 节点的内存泄漏。
相关推荐
赏金术士12 小时前
Kotlin ViewModel
android·kotlin
vistaup13 小时前
kotlin 二维码实现高斯模糊
android·kotlin
愈努力俞幸运14 小时前
function calling与mcp
android·数据库·redis
阿巴斯甜14 小时前
LeakCanary
android
阿巴斯甜15 小时前
compose
android
阿巴斯甜15 小时前
Glide
android
-SOLO-15 小时前
使用Perfetto debug trace查看超时slice
android
阿巴斯甜15 小时前
Retrofit
android
阿巴斯甜15 小时前
OkHttp
android
阿巴斯甜16 小时前
Flow
android
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03CC-Switch & Claude 基于 Linux 服务器安装使用指南04零基础教你claude code 接入 deepseek V405【AI】2026 年具身智能模型和世界模型总结06Windows端Codex接入第三方模型（DeekSeek，BaiLian)07Cursor 接入 DeepSeek‑V4‑Pro 完整指南（2026 实测）08codex app每次打开重连5次Reconnecting问题解决09要裂开了！ChatGPT要手机号验证了？注册Codex要求验证电话号码怎么办？2026年登陆Codex要手机号验证的解决办法10裂开！ChatGPT 居然开始要手机号验证，附详细解决方法