Is this related to the memory leak? If not, maybe this should be a separate change.

Well now this PR is not about memory leaks anymore since #147133 got merged in between. Maybe I should rename this PR. Would "Fix jank in cupertino page transition" sounds nice to you ?

That sounds like a great idea. Can you update the PR description to what issue this is fixing now as well? Thank you!

I updated the title and the description of the PR. Tell me if something is unclear

This change from -83 to -197 looks alerting to me.
The test passes at flutter master with -83. And it stops passing with -83 after your change. That means your change is not just improvement in memory management, it modified functionality, that should not happen.

I agree, I was trying to "fix" those changes in the tests. However, with my changes the behavior changes and I will have to update those values.

Before, a new CurvedAnimation was recreated at every build (in the constructor of the stateless widget CupertinoPageTransition). Now, it is reusing the same one. This leads to a change in the functionality (which I believe is correct).

As a reminder, here are some useful values:

Curves.easeInToLinear.transform(0.72); // 0.3149519026279449
- (800 / 3) * Curves.easeInToLinear.transform(0.72);  // -83.98717403411865
Curves.linearToEaseOut.transform(0.72); // 0.979008914809674
- (800 / 3) * Curves.linearToEaseOut.transform(0.72); // -261.0690439492464

And the secondary animation is

_secondPositionCurvedAnimation = CurvedAnimation(
  parent: widget.secondaryRouteAnimation,
  curve: Curves.linearToEaseOut,
  reverseCurve: Curves.easeInToLinear,
);

Before, the test was animating the push of the page from 0ms to 400ms (the entire duration of the push animation is 500ms) and then popping. So the push animation was not completed when being reversed. During the forward animation, the curve used is Curves.linearToEaseOut (which is correct).
During the pop/reverse animation, because the CurvedAnimation is recreated, it was using the reversedAnimation: Curves.easeInToLinear which led to this -83 value.

But this shouldn't happen, if the animation is not complete, it should use its forward curve during the reverse animation. I guess this is to prevent jumps and janks.

This is what those lines are doing:

Now that the CurvedAnimation is stored in the state and reused, it keeps using the forward curve and doesn't "jump" to the reversedCurve, which I believe fixes a jank/jump that currently exists on the master channel.

For the test, I decided the modify it so the push animation finishes and the pop uses the reversedCurved by changing the durations from 40ms to 50ms. But I can revert those duration changes and make the pop use the forward curve instead.

Rather than changing an existing test, can you add a new one? This feel like a potential regression.

+1 on leaving this test alone as much as possible. It does look like logically the animation wouldn't finish by the time the original test tries to go back, so the jump makes sense. I'd rather the test was left as it was to check for regression, even with the jump, and probably renamed. A new test that correctly waits for the animation to finish, then goes back would be preferable.

Does the original test still fail, and how?

Those were the minimum changes I found to "let this test alone as much as possible".

What was happening in this test:

1. Push using the forward animation (500ms)
2. The push is interrupted with a pop at 400ms
3. The pop uses the reversed animation (but should not because it leads to a discontinuity).

After my changes without any modification on the test:

1. Push using the forward animation (500ms)
2. The push is interrupted with a pop at 400ms
3. The pop uses the forward animation for the reverse animation (there is no discontinuity)
4. The test fails at the line

    await tester.pump(const Duration(milliseconds: 40));
    expect(tester.getTopLeft(find.byType(Placeholder)).dx, moreOrLessEquals(-83.0, epsilon: 1.0));

Expected: -83
Actual value: -261

(Comment for reference: https://github.com/flutter/flutter/pull/146999/files#r1575569345)

To make this test pass, I have 2 options:

a. I let the push being interrupted and I need to change the expected values to match the use of the forward curve instead of the reverse curved.
b. I let the push animation complete with more pumps so the reverse animation for the pop uses the reversed curve and I don't need to change the values in the expects.

I have implemented both options. The one linked to the comment is a.. And a bit below, there is the group('Interrupted push', () { ... }); that implements b.

Is that what you are expecting?

@MitchellGoodwin , does this help?

Thank you for the explanation. That all makes sense and the two tests LGTM. Thank you for adjusting the old on and adding a new one.