[WIP] Use ndk AChoreographer to get vsync callback

[FelixZhang00]

Uses the NDK AChoreographer if it is available and falls back to the Java Choreographer if it is not

implement this issue #flutter/flutter#62166

After using the NDK api AChoreographer_postFrameCallback, it can run on UI thread rather than the platform thread.
It will save time when the platform thread's MessageQueue is busy.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or Hixie said the PR is test-exempt. See testing the engine for instructions on
  writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[flutter-dashboard]

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat.

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

[chinmaygarde]

I don't think we should land this till after determining that avoiding the JNI layer makes a measurable difference to per frame performance. The observation that this can allow the us to listen for Vsync callbacks from the UI thread directly is interesting. But, we can solve this by making the the UI thread created using the Java APIs. That was the limiting factor when the implementation was originally written. Maintaining this complicated of a mechanism to the NDK APIs and maintaining a fallback is not something I want us to attempt without being confident of its benefits.

[dnfield]

Yes - we need some traces to show whether this will make a positive difference or not. You could consider running for example the flutter_gallery__transitions_perf benchmark from the devicelab with a locally built engine with this patch.

[dnfield]

This patch has some other issues - I'd be happy to provide a full review if we can show this improves performance for API levels it supports.

[chinmaygarde]

Agreed. And, if the improvements are due to the choreographer scheduling directly on the UI thread instead of going via the platform thread, the we should attempt creating the thread in Java code. That way, even older versions of Android would get the improvements.

[ColdPaleLight]

Hi, @chinmaygarde @dnfield

The author is my colleague, we think you are right, we will do the following two things next:

1. Make a report based on flutter_gallery__transitions_perf benchmark. But I guess that report may not have much positive difference.Because the busier the platform thread, the more obvious the advantages of this PR. In the flutter_gallery__transitions_perf scenario, the platform thread may not be busy.
2. Investigate whether it is possible to get the Vsync signal on the UI thread without using the NDK. Maybe we don’t need to create the UI thread from Java. Instead, after creating the std::thread, We can call Looper.prepare and Looper.run through JNI, and then don’t call MessageLoop::Run()

   engine/fml/thread.cc

   Line 35 in 08dabe9

   loop.Run();

   
   We will try it soon.

Thanks

[FelixZhang00]

I create a new pr #29889 to fix this, whitout using NDK API.
/cc @dnfield @chinmaygarde