The cell in ASTableNode, ASCollectionNode never dealloc, when number of cells increase, the memory increases all the time.

[garrettmoon]

From @evanxie-cn on March 30, 2017 8:26

Firstly, thank you very much for creating such amazing framework, it's really so smooth, so fluent.

When I use ASTableNode/ASCollectionNode, I encountered a memory issue, with the new cell creating, the memory cost will be higher and higher, finally crash the app.

I uses the Facebook official CatDealsCollectionView sample to test the ASTableNode ASCollectionNode memory issue. Finally I found the cells are never dealloc, eg. we have 10,000 cells, ASTableNode will create 10,000 cells, and these cells are both in memory.

When you scroll down the cells, the memory will increase a little by a little. If you scroll down and down, the memory cost will reach up several hundred, even over 1 GB, then crash.

When you scroll down to several thousands cells, then let the iPhone rotate to landscape, the whole table node will block for several seconds, then layout finished, it recovered, then scroll down again, it is still smooth.

But when memory cost 1.3GB, the app crashed.

CatDealsCollectionView.zip

https://github.com/evanxie-cn/AsyncDisplayKit/blob/master/MemoryCrash.MOV

Copied from original issue: facebookarchive/AsyncDisplayKit#3231

[garrettmoon]

From @Ruanjijian on March 30, 2017 8:40

+1
Same issue occurred to me with version 2.1
All Heap & Anonymous VM Have been increasing

[garrettmoon]

From @evanxie-cn on March 30, 2017 8:44

I tested on the SDK 2.1, and 2.2, both have this issue.

[garrettmoon]

From @Adlai-Holler on April 3, 2017 17:44

@appleguy I know you are crazy busy but I think you're the man to investigate this very serious issue, as the rest of the team is heads-down on other tasks.

@maicki investigated and he found that CoreGraphics is caching CGImages without us asking for it to. We need to prevent this behavior!

EDIT: As context for everyone, it's not the cell nodes that are the core memory issue. It's intended for all 10,000 nodes to stay alive – a node only takes up a tiny amount of memory. The real cost is the CGImages that the nodes set as layer.contents which are cleared – and expected to be destroyed – when the node exits the display range (-clearContents) method. This behavior suggests that those images are not being deallocated as expected.

[garrettmoon]

From @evanxie-cn on April 25, 2017 8:0

@Adlai-Holler Thanks for your explanation and team hard work. So, maybe we just wait for this issue resolved, right?

[tdlong506]

Thank for rising this question, I am also facing this issue. I work around by reloading table while user move to other screen.

[harryworld]

We are seeing similar problems, and it seems to grow by 50MB pretty quickly with 100 cells created in ASCollectionNode.

[garrettmoon]

I'll try and see if I can figure out what's going on here.

[appleguy]

Sorry I missed this ping! I will try to keep a closer eye on notifications, but sometimes get behind on email; feel free to ping me in the core channel any time. I am happy to help evaluate any findings or proposed fix direction. Thanks for taking a look, Garrett! Although I won't be able to investigate in the next two weeks, if this is still unresolved later this month, I will make a strong effort to dig in.

…

On Wed, Jun 7, 2017 at 8:39 PM Garrett Moon ***@***.***> wrote: I'll try and see if I can figure out what's going on here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#211 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAigA6EA99szCwUxLX_QxAKvreXhPOUCks5sB2zZgaJpZM4NNkhJ> .

[Adlai-Holler]

@ghost @Ruanjijian Are you folks still seeing this issue? It could have been due to our event logging which was enabled-by-default in debug, up until recently.

On the current master (58641a), in a release build, I observed:

• 2 minutes of just scrolling down on CatDealsCollectionView (3000 text nodes!) only resulted in 25MB of persistent memory.
• Pushing and popping new copies of the cat deals view controller never leaked memory and always returned to baseline.

In a debug build the memory usage was slightly steeper, about 1MB per page of cat deals loaded, but pushing and popping copies of the VC did not accumulate memory.

I believe this issue has been resolved. If I'm wrong, absolutely feel free to reopen this issue and thanks for looking out!

[Adlai-Holler]

Pushing and popping VCs:

Just scrolling down for 2 minutes:

[vikas-singla]

I'm still seeing this issue. Refer to ASDKGram sample and cells are not deallocated.

[Danielhhs]

I'm having the same issue here... I was trying to create a image picker by loading all the assets with Photos, but the cells are never deallocated.. Memory get exploded soon.. Does anyone have a solution on this? Thanks!!!

[appleguy]

Could you try adopting the ASCollectionGalleryLayout? It is available on master, and should be significantly faster for this case of a large number of equal sized items. The other solution is to add virtualization to your data source, and only expose ~1000 items to it at a time. If you could attach a memory trace (compress and put on Google Drive), I can take a quick look. The one critical question is if you are using a custom image downloader, which could cause a much bigger memory problem.

…

On Tue, Jul 25, 2017 at 2:39 AM Danielhhs ***@***.***> wrote: I'm having the same issue here... I was trying to create a image picker by loading all the assets with Photos, but the cells are never deallocated.. Memory get exploded soon.. Does anyone have a solution on this? Thanks!!! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#211 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAigAzAFV75QxmSaqOfWsuLEiyvRak5Tks5sRbftgaJpZM4NNkhJ> .

[Danielhhs]

@appleguy Thanks so much for your reply. We just found out the same result as your reply. We are using SDWebImage for image downloading, and set the image to cell node in the completion block. The memory usage will explode by doing this. And we solved the problem by downloading the image on our own.

But I was wondering why the memory usage will increase so much if we use SDWebImage to download the image? Is it causing any retain cycle?

Thanks

[wjling]

I have meet similar issue when I use Kingfisher to download the image in ASTableNode cells. The memory is growing incredible fast, and then crashed. I am using Texture 2.5.1. I use a ASControlNode and have a back view of UIImageView. I use setImage Method of Kingfisher in the UIImageView. Maybe just scroll about 50 cells and using UIImageView and Kingfisher the memory can increase to 800M or more, but using ASNetworkImageNode the memory can go to about 200M. By the way, I enter the viewController and do nothing, just let the table refresh once automatically, the memory is about 65M

[tangbl93]

+1, SDWebImage cause memory raise incredible fast, and then crashed(only in device)

[nguyenhuy]

@Danielhhs @wjling @tangbl93 Looks like your memory problems are caused by the memory cache not being trimmed. Nodes are meant to stay for a long time and never reused/deallocated during the lifecycle of the containing collection/table node. However, their contents are cleared out when they fall out of preload range. ASPINRemoteImageDownloader, the default downloader that ASNetworkImageNode and ASMultiplexImageNode use, takes care of that. Internally, it uses PINRemoteImage and PINCache. If for some reasons you want to use another image downloader backed by SDWebImage or Kingfisher, you should supply a compatible implementation of ASImageDownloaderProtocol. Check out ASBasicImageDownloader and ASPINRemoteImageDownloader for examples. You may also want to take a look at WebASDKImageManager. I haven't checked it source code so I can't vow for its quality but it should be a good starting point.

cc #417.

[qq912276337]

the same problem in 2.8 version. i have 1000 cellNode ,it more than 1G memory and then crash.how to solve it?
i find everytime [tablenode reloadData] ,memory will increase a lot.