Repository navigation
ListView on debug and release get High CPU Memory VS iOS native #20857
Description
my Question:
Sample ListView Page in Diffrent Environment CPU and Memory very Hight, i Want To Know Why ,And How to solution!
====================================================
- Doctor:
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel unknown, v0.5.1, on Mac OS X 10.13.4 17E199, locale zh-Hans-CN)
[!] Android toolchain - develop for Android devices (Android SDK 28.0.1)
! Some Android licenses not accepted. To resolve this, run: flutter doctor --android-licenses
[!] iOS toolchain - develop for iOS devices (Xcode 9.3)
✗ libimobiledevice and ideviceinstaller are not installed. To install, run:
brew install --HEAD libimobiledevice
brew install ideviceinstaller
! CocoaPods out of date (1.5.0 is recommended).
CocoaPods is used to retrieve the iOS platform side's plugin code that responds to your plugin usage on the Dart side.
Without resolving iOS dependencies with CocoaPods, plugins will not work on iOS.
For more info, see https://flutter.io/platform-plugins
To upgrade:
brew upgrade cocoapods
pod setup
[✓] Android Studio (version 3.1)
[✓] Connected devices (1 available)
-
比对：
-
UI页面
-
major Code:
child: PageView.builder(
itemCount: widget.entity.length,
controller: controller,
// controller: scrollController,
onPageChanged: onPageChanged,
itemBuilder: (BuildContext context, int index){
return RefreshIndicator(
child: ListView.builder(
itemCount: dataList.length + 1,
itemBuilder: (context,index){
if (index == dataList.length){
return _buildProgressIndicator();
}else{
return _buildRow(dataList[index],selectIndex,size,context);
}
}
),
onRefresh: fetchList,
);
},
),
Activity
lichentao commentedon Aug 21, 2018
@kangwang1988 Sample ListView Page in Diffrent Environment CPU and Memory very Hight, i Want To Know Why ,And How to solution!
kangwang1988 commentedon Aug 21, 2018
@lichentao
There are several tips for us to help you figure it out.
2.Post the flutter environment you're using by
3.If possible, create a project in github, so that we can reproduce your problem.
[-]ListView on debug and release get Hight CPU Memery VS iOS native[/-][+]ListView on debug and release get High CPU Memery VS iOS native[/+][-]ListView on debug and release get High CPU Memery VS iOS native[/-][+]ListView on debug and release get High CPU Memory VS iOS native[/+]Wanghuayin commentedon Sep 22, 2018
@lichentao ref #20245
if you use the Listbuilder, it'll create and destory the instances when you scrolling that why it get so unstable CPU and Memory
lifenautjoe commentedon Jan 23, 2019
Uh... At the state of things I'm wondering wether it's fair to say to end-users that Flutter is production ready and have seriously started regretting not going for a PWA.
A lot of the building blocks of basic apps are either missing, incomplete or unstable. (Performant scrolling, date pickers, selectable text fields, non-crashing video players).
On release mode, sluggish scrolling even with caching of widgets,
wantsKeepAlive, const physics and all tricks I could find to make the thing usable. Still, hugely disappointing.James-A-White commentedon Mar 18, 2019
(NOTE: I'm posting this here because what people may interpret as a problem with the ListView could actually be due to other issues)
My Flutter app (debug) consumed nearly 20% of the battery power of my phone in under 10 minutes of use. This will not be acceptable to end users. So, I profiled it and noticed some interesting things with the ListView. The most problematic is a situation where the screen with the ListView continues to refresh continuously even when there is no user interaction. And, to make matters worse, the GPU load is pretty high.
Eventually, I isolated the problem to the CachedNetworkImage library. Apparently, if you include a standard circular progress indicator as a placeholder to display as the images are loading, this is not getting properly disposed after the image loads. Even though it is not displayed on the screen, it is forcing screen refreshes to occur.
So, if you are having problems with your ListView performance and you are also embedding widgets such as the CircularProgressIndicator in your ListView rows, you might want to try removing these and seeing if that fixes the problem.
I'll open an issue in the CachedNetworkImage repo.
Just for grins, my Flutter doctor output is below.
potatoker commentedon Mar 22, 2019
so, the truth is Flutter listView has no recycler mechanism, memory will definitely be increasing when scrolling the list and the programmer will only depends on dart vm itself to gc? And gc not only fresh the dart vm heap but also the native renderingObject memory, right?
NathanAP commentedon Apr 9, 2019
I believe thats it, we will depend on dart vm to make things work... The main problem IMO is that we can't do anything to make the ListView smooth or using less memory.
In my case I have a screen with a ListView.builder with images that if I open twice in any iOS device the app will just crash. Our team got another situation that ListViews were literally making objects being duplicated in the screen.
For the second situation we created Lists with Rows and Columns and I believe I'll do it for the first situation, but this is really disappointing.
Kavantix commentedon May 8, 2019
I might have run into a similar issue, for me items int the listview kept rebuilding even though they did not need to.
When I removed the refresh indicator it worked as expected
@NathanAP could you try removing the refresh indicator and see if the performance increases.
pedromassangocode commentedon Sep 16, 2020
Hi @lichentao
Are you still facing this issue? If yes, please provide your
flutter doctor -v, yourflutter run --verboseand a minimal complete reproducible code sample?Thank you
TahaTesser commentedon Oct 14, 2020
Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
github-actions commentedon Aug 11, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.