ASTableView----memory cost too much and reload data...

[nannanIT]

I have met two big problems while using the ASTableView of ASDK. 1.when i reloaddata of the ASTableView, it scrolls to the top of the screen, which is different from the UITableView; 2.compared to using common UITableView and UITableViewCell, using the ASTableView and ASTableViewCell causes much more memory cost, especially the CG Rater Data in the vm, i am sure that the contents of layers can be clear, so why the memory cost so much? can anybody help me?

[appleguy]

@nannanIT thanks for filing an issue — I'd love to help.

1) This sounds like an annoying issue, and should be fixable. Could you try enabling the new 1.2.3 (or master) property of ASTableView that preserves the content offset? "automaticallyAdjustsContentOffset" I haven't tried this with a total reload, as it's meant for insert / remove / move calls.

2) Please share more information about what you're seeing. Is the memory growing continuously and never being lowered? Or is it just a higher baseline? Note that with the default values for rangeTuningParameters, it is expected that ASTableView will consume more memory; it is "rendering ahead" offscreen cells so that when they come onscreen, they do not show placeholders and also don't cause stuttering like UITableView. Please feel free to adjust rangeTuningParameters (particularly for the ASLayoutRangeTypeRender) to a smaller value to save memory.

If you're seeing memory rise without coming down / stabilizing, this could be a bug. Like in any app there is some overhead where the memory will continue to rise as you load more and more content, but it should level off after the working range is full. In particular, CG raster data should tend to stabilize, even though other objects (like the ASDisplayNodes themselves and their corresponding UIViews, CALayers, etc) will continue to grow. Those objects are not very large without the backing store though.

If you're able to provide a test case that demonstrates any of these issues, it will help me and the other active maintainers diagnose and resolve it as quickly as possible. Thanks for trying out the framework!

[nannanIT]

@appleguy thank you for your detail reply, it helps me a lot to better understand ASDK. when using reloadData of ASTableView, it does scroll to the top of the screen, but i have fixed it by using insertRowsAtIndexPaths when i need to load more nodes, it comes very smoothly, meantime the memory cost comes down, so it improves the user performance a lot. i will try what you mentioned and give my report. One more question, when i reloadData of the ASTableView, will all the nodes be created again without reuse? I think so. for this reason, it scrolls to the top of the screen and cost more memory. so i have tried to reuse some nodes when i reloadData with a dictionary, which i think can be improve the performance. But something wrong happened, when using the nodes form cache(the dictionary), Assertion failure in ASDisplayNodeAssertThreadAffinity(self), in the method of - (CGSize)__measure:(CGSize)constrainedSize. I have no idea about that. can you give me some advice to reuse the nodes? Of course,maybe it does not make any sense. thank you.

I have studied ASDK for a long time, and i learned a lot from your great work. I will continue follow your work, i hope i can make a little contribution to it, haha. thank you again.

[nguyenhuy]

Welcome to the community, @nannanIT! I'm quite familiar with the codebase and hopefully can help @appleguy to answer your great question.

In short, yes, reloadData discards everything and load new nodes, without reusing. But hold on, let me explain and show you some alternatives.

Besides reload, we have introduced "relayout". A relayout means there are changes in the layout of one or more nodes, let's keep those nodes and update their layouts. Relayout is done on main thread, but it's ok due to its infrequent usage.

Whenever you want to do a "reload", you actually want to do 1 of the following things:

• Update layout of a specific node: Caused by a change in the node itself while its constrained size is unchanged. For example, its data changed or user taps it. You can easily trigger a relayout on the node by simply calling -setNeedsLayout. If the relayout results in a different size, an empty batch editing transaction must be triggered to animate to new sizes. Examples can be found here and here.
• Update layout of all nodes: Caused by different constrained size for each and every node, for example after orientation change or a table view entering editing mode. ASDK can handle these cases automatically. The API (-relayoutAllRows) is private for now, but after #599, I think it's a good idea to make it public.
• Reload one or some nodes: Caused by total invalidation of the nodes, for example you want to show a completely new UI. This can be done via -reloadSections, -reloadRowsAtIndexPath or -reloadItemsAtIndexPath.
• Reload data (a.k.a reload everything!): Caused by any other reasons and you absolutely need to destroy existing nodes and create new ones.

UIKit's reloadData is relatively cheap and we tend to overuse it -- reloadData all the time! But ASDK's version is substantially more expensive. So when we are about to call reloadData, we should ask ourselves: Do I really need it? Most of the time, instead of reloadData, what you actually need is insert, delete, move, relayout or maybe a combination of them. reloadData is the last resort :)

[nannanIT]

@nguyenhuy Thank you very much, your explanation is really helpful. I did not realize the expensive to use reloadData before, it's the last resort...=.=

[nannanIT]

@appleguy @nguyenhuy What's more, do you think the "automaticallyAdjustsContentOffset" is necessary to be added in ASTableView, with which may resolve the problem -- "the tableview scrolls to the top of the screen every time it reloadData", I am not sure but UIKits UITableView does. thank you.

[huchunyu]

I have similar memory cost issue. I have a ASTableView which displays feeds, like twitter. Each ASCellNode include an ASCollectionView (wrapped as a ASDisplayNode using initWithViewBlock) and other nodes. The ASCollectionView includes no more than 9 ASNetworkImageNodes. Also I use NSFetchedResultController as datasource of ASTableView. It does help for scrolling experience, but the memory usage is just increasing and never stops. Most memory usage seems related to ASNetworkImageNode from profiling result. BTW, I'm using master branch.

[nannanIT]

@huchunyu You know using initWithViewBlock to init a node, the node is synchronous, your ASCollectionView includes n ASNetworkImageNodes, from the source code, the n ASNetworkImageNodes can be asynchronous. I am not sure using initWithViewBlock can cause more memory cost. what's more, do you have image cache? And if you are using reloadData when you pull to load more data, you can use insertRowsAtIndexPaths instead. BTW, if you have a better solution, please tell me. Thank you, good luck.

[huchunyu]

Thanks nannanIT. I do have image cache and we use WebASDKImageManager, which is based on SDWebImage. I use insertRowsAtINdexPaths instead of reloadData. So far, I still don't figure out why the memory usage is so high.

[appleguy]

@huchunyu @nannanIT - I'm very sorry you encountered this issue. It turns out there is a bug with ASBasicImageDownloader. My hope was that few people would use this class, because there is a lot of value for an app to more closely control its use of the network (that's why the cache and downloader properties exist with a protocol that you can adopt for ASNetworkImageNode and ASMultiplexImageNode). Still, it is a very serious issue to leak memory and so I apologize for this problem.

Depending on the situation, the amount of memory leaked may be small or large. I'm closing this task because this issue has now been discovered and will be fixed soon. The test project that reproduces it is an example where quite little memory is wasted, but the leak is definitely consistent.

Also — please adopt ASCollectionNode instead of the manual wrapping of ASCV — this will use memory much more efficiently in the near future by limiting the expansion of the render-ahead working range when the horizontal elements are offscreen. For your current solution it is essential to set the rangeTuningParameters and reduce at least the render range, probably also some of the network range, or 9 items per cell is going to be a ton of memory.

Follow along here and test out the solution with us: https://github.com/facebook/AsyncDisplayKit/issues/763

[peak77]

Hello, @nguyenhuy , In the process of learning, something bothers me. ASTextNode in ASCellNode, when change ASTextNode maximumNumberOfLines from 5 to 0. and [textNode setNeedsLayout];

First, Why the ASTextNode in ASTableNode have a flash? But,somtimes it seems not have flash. Second,The difference between[textNode setNeedsLayout]and '[cellNode setNeedsLayout]' I would appreciate it if you spent time help me,Thank you very much. the vedio: http://132.232.41.183:8080/TappedTruncation/tMovie.mp4 the project:https://github.com/peakerWu/TappedTruncation Texture version 2.7