Open Yogesh-Dubey-Ayesavi opened 1 year ago
I figured out the problem, SingleChildScrollView
is the responsible widget.
Since the _chatStreamBuilder
method is embedded inside SingleChildScrollView
so it builds each items at once, which in context with performance is not so good solution.
I tried removing SingleChildScrollView
like this.
GestureDetector(
onHorizontalDragUpdate: (details) => isEnableSwipeToSeeTime
? showPopUp
? null
: _onHorizontalDrag(details)
: null,
onHorizontalDragEnd: (details) => isEnableSwipeToSeeTime
? showPopUp
? null
: _animationController?.reverse()
: null,
onTap: widget.onChatListTap,
child: Column(
children: [
Flexible(
child: _animationController != null
? AnimatedBuilder(
animation: _animationController!,
builder: (context, child) {
return _chatStreamBuilder;
},
)
: _chatStreamBuilder,
),
TypingIndicator(
typeIndicatorConfig: widget.typeIndicatorConfig,
chatBubbleConfig: chatBubbleConfig?.inComingChatBubbleConfig,
showIndicator: showTypingIndicator,
profilePic: profileCircleConfig?.profileImageUrl,
),
SizedBox(
height: MediaQuery.of(context).size.width *
(widget.replyMessage.message.isNotEmpty ? 0.3 : 0.14),
),
],
),
);
- physics: const NeverScrollableScrollPhysics(),
+ controller: widget.scrollController,
+scrollController.position.maxScrollExtent,
After making these changes guess what, it worked nicely.
Using this method performance can be improved until an extent but, scrollingToReplyMessages will take a lot of time because GroupedListView
is built on top of ListView.builders
. I suggest using scrollable_positioned_list or scrollable_positioned_list_extended(with helper methods like scrollToMax extent and notification listeners) inside custom fork of GroupedList
we can reach to threaded messages instantly.
@Yogesh-Dubey-Ayesavi Thanks for pointing out these issues. We had planned for this performance improvement, but you suggested some changes, I will try those and give feedback on this
This issue is stale because it has been open for 30 days with no activity.
This issue was closed because it has been inactive for 14 days since being marked as stale.
I just added to
debugPrint('${widget.message.id} rebuilt');
to MessageView build method .The logs i obtained then.
https://user-images.githubusercontent.com/88256165/228053504-507ae548-96e4-4fd1-bcb6-7bc4664ddf44.mp4
Each message even which are outside the viewPort are getting rebuilt, that causes huge memory consumption.