If `FlutterDartProject` found an `FLTLibraryPath` entry in an iOS
application's `Info.plist`, it assumed that values that were valid
filesystem paths were paths to bundles. If the attempt to retrieve
the `NSBundle` fails, `FlutterDartProject` ignored the failure and
then would assign `nil` to a C++ `std::string`, resulting in a null
pointer dereference.
Add some failure checks to prevent this.
The service isolate creation callback may occur on a background thread before
the call the Dart_Initialize within the DartVM construtor can finish. We store
pointers to various snapshots within the DartVM object. These snapshots are
necessary for to successfully create the service isolate. The isolate creation
callback access the global object within the ForProcessIfInitialized method.
This method can return null if the VM object has not been initialized. This
leads to the service protocol failing to start in a non-deterministic manner.
This patch moves the creation and access of the DartVM object within a critical
section.
We'd like the ability to add Flutter to existing iOS applications
without requiring that they set `FLTLibraryPath` and `FLTAssetsPath`
in the main bundle's `Info.plist`.
1. Modify `-[FlutterDartProject initWithPrecompiledDartBundle:]` to
support setting the library and assets path from the specified
`NSBundle` instead.
2. If no `NSBundle` is explicitly specified, look for one with a
default bundle identifier ("io.flutter.flutter.app") before
falling back to the main NSBundle.
Also remove `+[FlutterDartProject pathForFlutterAssetsFromBundle:]`
because we don't use it internally, and it isn't exposed in the
header file.
When these delegate methods were initially added, it was expected that a single
shell would be able to own mutliple platform views, engines and animators. This
plan was abandoned in favor of creating multiple shells with their own platform
views, engines, etc.. The arguments were meant to ease the disambiguate the
instances of the variaous objects managed by the shell. This is no longer
necessary.
This change adds a delay before Animator::BeginFrame calls its
delegate's OnAnimatorNotifyIdle. This is because under certain
workloads, such as our parent view resizing us, which is communicated
via viewport change events, we won't have a frame scheduled yet in the
animator, despite the fact that we will go on to schedule a frame once
the viewport event arrives.
In Fuchsia's resizing performance test, on our reference high end x86-64
hardware, the previous logic was resulting in a ~45ms garbage collection
right after the first frame of an animation.
