LuckSiege / LuckSiege/PictureSelector

内存泄漏

Open
#2,776 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
13.6k
Forks
3.1k
PR merge metrics
No merged PRs in 30d

Description

## Current use version?
#### 当前使用的版本是多少?

```
v3.11.1
```

## Will this problem occur in demo?
#### Demo能否复现这问题?

```
必现 fragment 承载 选择完图片 页面等待10s左右 LeakCanary 提示内存泄漏
```

## Describe the problem or provide an error log?
#### 描述问题或提供错误log?

```
┬───
│ GC Root: System class

├─ android.app.ActivityThread class
│ Leaking: NO (a class is never leaking)
│ ↓ static ActivityThread.sCurrentActivityThread
│ ~~~~~~~~~~~~~~~~~~~~~~
├─ android.app.ActivityThread instance
│ Leaking: UNKNOWN
│ Retaining 714.4 kB in 11274 objects
│ mInitialApplication instance of com.xxx.xxx.app.AppApplication
│ mSystemContext instance of android.app.ContextImpl
│ mSystemUiContext instance of android.app.ContextImpl
│ ↓ ActivityThread.mNewActivities
│ ~~~~~~~~~~~~~~
├─ android.app.ActivityThread$ActivityClientRecord instance
│ Leaking: UNKNOWN
│ Retaining 666.4 kB in 10276 objects
│ activity instance of com.xxx.xxx.main.publish.PublishActivity with mDestroyed = false
│ ↓ ActivityThread$ActivityClientRecord.nextIdle
│ ~~~~~~~~
├─ android.app.ActivityThread$ActivityClientRecord instance
│ Leaking: UNKNOWN
│ Retaining 665.4 kB in 10250 objects
│ activity instance of com.luck.picture.lib.basic.PictureSelectorSupporterActivity with mDestroyed = true
│ ↓ ActivityThread$ActivityClientRecord.activity
│ ~~~~~~~~
╰→ com.luck.picture.lib.basic.PictureSelectorSupporterActivity instance
​ Leaking: YES (ObjectWatcher was watching this because com.luck.picture.lib.basic.PictureSelectorSupporterActivity
​ received Activity#onDestroy() callback and Activity#mDestroyed is true)
​ Retaining 618.7 kB in 9509 objects
​ key = 81287b33-d4cd-475e-ae86-bb4da2561634
​ watchDurationMillis = 34584
​ retainedDurationMillis = 29579
​ mApplication instance of com.xxx.xxx.app.AppApplication
​ mBase instance of androidx.appcompat.view.ContextThemeWrapper

METADATA

Build.VERSION.SDK_INT: 29
Build.MANUFACTURER: Xiaomi
LeakCanary version: 2.7
App process name: com.xxx.xxx
Count of retained yet cleared: 3 KeyedWeakReference instances
Stats: LruCache[maxSize=3000,hits=17365,misses=219189,hitRate=7%]
RandomAccess[bytes=14042589,reads=219189,travel=145642201696,range=45045065,size=51358863]
Heap dump reason: 16 retained objects, app is visible
Analysis duration: 12603 ms

```

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the fragment flow that launches PictureSelectorSupporterActivity, selects an image, and waits about 10 seconds while observing LeakCanary. Trace the Activity#onDestroy() path and retained activity shown in the report. Done means the destroyed activity is no longer reported as retained after the same flow.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, java
Domain
mobile, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.