And when you’re done, you just sum and delete

If you have a better idea, please feel free to comment

By the way, when will the Nuggets have an article classification function, used to put some miscellaneous thoughts and other things that do not need to be published;

2021.1.26 Found that the idle fish seems to have been done

Juejin. Cn/post / 691748…

Is not know open source, first reference to look at;

Problems faced

  • Flutter doesn’t release the reset gesture object until the touch animation ends, and it’s a long story when the animation ends.
  • The RecyclerView cache mechanism for Android is a bit overdone.
  • Android RecyclerView Diff algorithm? How do you implement a local refresh?
  • ItemDecoration, ItemTouchHelper, SnapHelper?
  • Flutter is implemented by constructing a sliver method. Do you need an exposed method to implement onBind? Is this required? Can the onBind be replaced by the mechanism of Flutter itself
  • More?

Solution conjecture

  • First question: custom gesture competitor, implement a pseudo-event interception distribution mechanism, such as custom Scrollable? Can not be modified on the basis of the previous transformation of the PageView? That gets through the child Page to call the parent Page, and then get through the parent Page to call the child Page, and maybe at the same time can realize the SnapHelper aspect of things, sliding state this is not out of reach; (Alternatively, take a look at extend_tab and force up the animation. The UI is definitely not going to work in practice, but at least it’s not going to work. In short, I can run.
  • Flutter itself has a caching mechanism that seems to allow caching in non-reconstructed states. The mechanism is similar; First from the introduction of Diff in, then the full process introduction again;
  • Local refresh, if not, use Key to find widgets.
  • Now imagine that the sliver of Flutter ==RecyclerView layoutManager, so the problem of pure modification of the layout of ItemDecoration should belong to the sliver part, which should be set through the chain structure. ItemTouchHelper is an ItemTouchHelper that listens for gestures on the outer layer of the child widget constructed by sliver and then interacts with the current child widget to determine drag, SWIP, etc. SnapHelper should be in PageScrollPhysics;
  • To see if onBind is needed in flutter, wait until diff and partial flush are done first

The current progress

First question (gestures, event handling)

Finally decided or in the original PageView transformation, and recyclerView itself is to support nested sliding, and then support nested sliding by other components to achieve;

The current scenario is to copy the design of nestedScrollView, where all event processing is handed over to a coordination class; NestedScrollerView is slightly different from nestedScrollerView, referring to the nested sliding mechanism in Android, first access the corresponding child Page can slide, and then slide the rest of the parent Page processing; I tried it and it seemed to work;

In this way, there is no need to deal with a series of painful issues such as who acquired the event and whether the event is over. It doesn’t matter where you come from, what state you are in, to coordinate the class, it’s up to him;

Is the amount of work seems a little bit too much ………… At present, it is still changed on the basis of the original PageView. After solving the problem of quick sliding before, I found that there is basically nothing left to change, from PageView itself and State to internal controller, position, and even activity and ScrollPhysics. All that’s left is a scrollable that provides basic slides and events…

This implementation to recyclerView seems a bit of trouble ………… In fact, Android recyclerView itself does not support nested sliding ………… Or it is supported by nested sliding

Do you want to open a nestedScrollerView? Support any number, any level, no limit, while modifying pageView, tabbarView, these also have corresponding support nesting and other features?

But that begs the question, what is the least intrusive way to allow nested sliding for arbitrary controls? It seems that Flutter itself doesn’t want too many controls to support nested sliding… However, lists, whether vertical or horizontal, are often used ………… Under the coordination of class pull away, and then reference AutomaticKeepAliveClientMixin treatment under this thing? Ideally, nesting slides can be done by simply following it with…

2021.1.27

On second thought, I will not do this content for the moment. The nested sliding mechanism of flutter is a little serious and a little off topic. RecyclerView, recyclerView, recyclerView, Instead of NestedScrollingParent and NestedScrollingChild, which is another skill tree, recyclerView simply implements the NestedScrollingChild interface, which itself has nothing to do with nesting

Second question (caching mechanism)

It seems that the 4 tier cache mechanism of RecyclerView is not used for flutter…………

The main purpose of the four-tier caching mechanism in Android is to prevent the reconstruction of itemView as much as possible, because the performance cost of Android View generation and findViewById is not small. One is XML parsing and the other is DFS. So the good thing to do is after you’ve created an itemView and initialized it, and then you update the data, you update the data that the view is showing instead of regenerating it;

Because there is no XML in a flutter, reconstruction performance is much better, and state updates in a flutter rely on widget reconstruction, so I thought I’d just use the caching mechanism that the listView has in a flutter. After all, They designed it this way and optimized it according to this design scheme

Read the article of idle fish

If internal sliver rebuilding is going to have a big performance impact, then you really need to use caching…

How about changing Android RecyclerView’s 4-tier (or 3-tier, without a basically useless cache layer) cache?

It’s not as if Idle fish is using Android in this way, or just introducing reuse, rather than onBind fetching views from the cache and updating them

It seems so. Just rebuild the widgets you need

2021.1.27 update

I took a closer look at the mechanics of the Element and changed the architecture in my mind. It used to be like doing everything at the widget level, but now I think it’s better to manage elements. After all, widgets are just cannon cannon

In addition, wait for the big high-performance long list to come out of the white whao not good?

Third question (Local refresh and Diff algorithm)

NewFile -> diff_util.dart

2021.1.26

Study the solution mentioned in the idle fish article

I don’t think there’s a Diff algorithm or anything, and the rest of it is insertion or something, okay

Local refresh found something:

ValueListenableBuilder

Blind guess just wrap it up with this thing and try it out later.

I’ll try out any scrollerView tomorrow, and I’ll stop here for the day. Tiwat’s still waiting for me

2021.1.28

ValueListenableBuilder, but the frame rate is not significantly improved. Debug mode enables performance analysis, which increases from 42 to 49. That’s what Profile reckons

Is it because my test demo item is too simple to see the effect?

DiffUtil translation is finished, although I did not look at it, but after copying -> paste -> change the error found, it seems to run ah, first research this thing has not changed the bug, incidentally see how to do next, this thing is really so simple to get over?

If nothing goes too far, the feasibility test and preparation are pretty much done,

Let’s get the Adapter and layoutManager out

ItemDecoration, ItemTouchHelper, SnapHelper

ItemDecoration can be added directly to Sliver. To be clear, just like Android does, flutter does a layer on the outside of the sliver or something else, extending the widget passed into the itemBuilder

ItemTouchHelper is a bit complicated, so let’s see if there’s a component that can do this…

SnapHelper is not much to talk about, it is actually a Physics change, may also need activity support; But it shouldn’t be a problem. After all, the PageView section already has something like PageSnapHelper

The 1.27 update

Basic feasibility test completed, these three seem to be functional implementation of the problem;

stories

Some thoughts on the element reuse piece of idle fish

Here’s what the idle fish says about element reuse

First we element to analyze the process of recycled SliverMultiBoxAdaptorElement cache by _childElements elements, when scrolling is beyond the scope of the viewport display and preload or data source change, Unwanted elements are collected by calling the collectGarbage method;

We can override collectGarbage to capture the deactive child element in the buffer pool without using keepAlive. When you need to create an element, get it from the buffer pool first.

So, the adapter and layoutManger should be designed deep into the Element layer, so to say, itemView == Element, Canvas == renderObject, holder == widget, Is it ok to understand this way?

So are adapters and layoutManagers designed to control elements directly? What about the Diff part? If there are multiple ItemViewTypes, would it be a problem to change the widget tree so that it only works at the Element level, or Diff at the widget level and nothing at the Element level and just cache?

In the current scheme, ItemDecoration is taken from the canvas of the Render layer, and then it is forced to redraw (rather than rebuild) by dirtying the canvas. Then, the context redrawing mechanism is used to trigger the processing and drawing of the canvas of ItemDecoration. Is there a performance problem with this approach? What is the dirty trigger mechanism? Active smudging only happens when the data is changed, and the rest of the time, the ListView mechanism itself?

In this case, how should we design the itemDecoration of layoutManager? Or do you just layer the widget? Is it better to add this ItemDecoration to the cache? (The canvas itself is drawn, not cached, the cache body is still element)

The ItemTouchHelper section

How about ReorderableListView?

I found a nice thing called Overlay ReorderableListView that I used

I take a look when I’m in painDevelopment diary

2021.2.3 After fishing for two days, I found that fishing is really happy, that kind of happiness must have been experienced by everyone;

But as an older blogger, my pride wouldn’t allow me to sink so low;

So I took a closer look at the three trees of Flutter and concluded:

How to feel the custom engine reliable point?

Widget creates Element, renderObject; But renderObject doesn’t get widgets; But Element does. Element holds widgets as well as RenderObjects;

ItemDecoration should not be a widget. It should be a class that manipulates RenderObject ？？？？？ (It looks like you can)

In addition, listView cache mode is really quite simple ………… There seems to be no reuse mechanism ………… It looks like the RenderObject should be rebuilt or rebuilt;

Or more precisely, what needs to be added is a reuse mechanism…

2021.2.4

This RenderObject stores a lot of stuff…

For example, firstChild and lastChild…

We can get the child RenderObject in the cache and display area, and then we can get the index information directly from the parentData, and the offset of the current Render in the whole list…

So here’s the question:

Why is it that other auto-exposure frameworks are so complicated and maintain their own Element queue… Iterating directly from firstChild to lastChild, find the firstChild whose mainAxisDelta is greater than negative · the current childrender size range && is less than the current child’s render range. And then get the index in parentData and that’s it;

Similarly, the last visible term can be obtained…

If that were true, I’d write an Auto-exposure frame that Even Goblins could do in five minutes.

There is a method in scrollable that can jump directly to the corresponding index.

But I haven’t found it for a long time. It seems not feasible… Doesn’t the flutter load calculate the unshown parts? There is no way to calculate how far the flutter will slide unless all items are fixed in height… Who knows the width and height of the parts not shown…

How did Android do it?

Well, Android seems to be sending a message that slides 10000 distance until it finds the View corresponding to the index.

Big guy analysis article: juejin.cn/post/684490…

2021.2.5

Found that the design of Flutter into three trees had another great advantage:

Widget Element renderObjec is basically isolated, so wiget tree is one order, renderObject can be another order, for example: listView renderObject is drawn from the first View; But you can rewrite the renderObject so that it starts drawing from the last View without changing the interaction, data book, etc.; In Android, to change the order of the drawing hierarchy, we need to change the order of the View, which affects the order of the data…

2021.2.7

Seems to basically understand how to reuse;

But there are a bunch of assert checks in the garbage collection process. See if there’s a way to bypass those assert checks. One on element and one on renderObject… This TM also want to transfer data across classes, a little annoying alas

2021.2.8

After searching for a long time, I couldn’t find a way around it… The related data of parentData configuration should also be changed …………

ParentData (” keepAlive “); keepAlive (” keepaliveBucket “); keepAlive (” keepaliveBucket “);

If I change the keepAlive property, can I reuse _keepAliveBucket directly?

Or see if you can override the _keepAliveBucket section and replace it with a queue with a maximum capacity? Change keepAlive to true when added, discard the first added keepAlive that exceeds the upper limit, and then change keepAlive to false.

Parentdata. keepAlive only affects collectGarbage and _destroyOrCacheChild. It also affects applyParentData. It feels like something to play with;

Of course, this is all at the renderObject level; But it feels like the mechanics are there, and Element is probably about the same; RenderObejct = renderObejct; renderObejct = renderObejct; CollectGarbage at the RenderObject level is processed at the Element level using the same principle.

Is the custom engine version of Idle Fish too low? Why do I feel so many things that flutter officials have brought …………