While StrictMode is not exclusively used for performance purposes, it's
primarily used for perf purposes so let's move it to the perf package
and code owner it.
They're currently lazy { lazy { value } }. Accessing `lazy.value`
directly allows us to make it lazy { value }. This should be more
performant and prevents us from double-counting these components.
By having LazyMonitored implement Lazy, we can continue to pass these
values directly into the ac APIs that require Lazy references. For some
reason, implementing `Lazy.value` can replace `operator fun getValue`
required for delegates.
By component groups, I mean I applied this to any class with the
class kdoc, "Component group for...".
There are a few instances of lazy we had to keep using the old API to
avoid having to update constructor arguments.
In a followup PR, we need to add state to strictModeManager (the
number of suppressions). This is much simpler to do when this is defined
as a class rather than an object. However, when this is defined as a
class, `resetAfter` needs access to the strictModeManager. Instead of
passing it in as an argument, it made sense to move this function onto
the strictModeManager instead.
Since folks are used to calling:
```
StrictMode.ThreadPolicy.allowThreadDiskReads().resetAfter
```
We're going to have to add a lint check to prevent them from doing that.
This is not the super fancy version yet - since we still need to restore into SessionManager and
haven't fully switched to BrowserStore yet. However AC having knowledge about "undo" and whether
it was performed or not, will help us with features like "recently closed tabs". And once we
can improve "undo", Fenix will get all the nice things automatically.
Requires:
https://github.com/mozilla-mobile/android-components/pull/8449
We set the ContentBlockingSettings directly on the GeckoRuntime now to
improve the startup of the engine.
This change has requirements from Android Components and GeckoView, so
we would only see the full perf benefits in Nightly as the changes ride
the train, although we might start to see some of them as we're updating
the GeckoProvider for the `geckoBeta` variant as well.
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
* For #11171 - Removes feature flag for the new tab tray
* For #11171 - Removes all tab references from homeFragment
* For #11171 - Fixes unit tests
* For #11171 - Gets UI tests to compile and HomeScreenTest to pass
* For #11171 - Fixes `deleteMultipleSelectionTest`
* For #11171 - Fixes `openHistoryItemInNewPrivateTabTest`
* For #11171 - Fixes `openHistoryInPrivateTabTest`
* For #11171 - Fixes `openHistoryInNewTabTest`
* For #11171 - Fixes `openNewPrivateTabTest`
* For #11171 - Fixes tabbedBrowsingTests
* For #11171 - Fixes SettingsPrivacyTest
* For #11171 - Fixes TopSitesTest
* For #11171 - Fixes lint errors
* Ignore
They were both in their packages by themselves, which feels unnecessary.
Unfortunately, a utils pkg is discouraged by kotlin but we don't have a
better place for them right now. Maybe an annotations/ pkg for the
latter?
Make sure that we actually lazily initialize our storage layers.
With this patch applied, storage layers (history, logins, bookmarks) will be initialized when first
accessed. We will no longer block GeckoEngine init, for example, on waiting for the logins storage
to initialize (which needs to access the costly securePrefStorage).
Similarly, BackgroundServices init will no longer require initialized instances of the storage
components - references to their "lazy wrappers" will suffice.
In practice, this change changes when our storage layers are initialized in the following ways.
Currently, we will initialize everything on startup. This includes loading our megazord, as well.
With this change, init path depends on if the user is signed-into FxA or not.
If user is not an FxA user:
- on startup, none of the storage layers are initialized
- history storage will be initialized once, whenever:
- first non-customTab page is loaded (access to the HistoryDelegate)
- first interaction with the awesomebar
- history UI is accessed
- bookmarks storage will be initialized once, whenever:
- something is bookmarked, or we need to figure out if something's bookmarked
- bookmarks UI is accessed
- logins storage will be initialized once, whenever:
- first page is loaded with a login/password fields that can be autofilled
- (or some other interaction by GV with the autofill/loginStorage delegates)
- logins UI is accessed
- all of these storages will be initialized if the user logs into FxA and starts syncing data
- except, if a storage is not chosen to be synced, it will not be initialized
If user is an FxA user:
- on startup, none of the storage layers are initialized
- sometime shortly after startup is complete, when a sync worker runs in the background, all storage
layers that are enabled to sync will be initialized.
This change also means that we delay loading the megazord until first access (as described above).
The a-c side of this work is in https://github.com/mozilla-mobile/android-components/pull/6128
This switches Fenix to use `SyncableLoginsStorage`, which caches a connection internally
on first access, and doesn't expose any lock/unlock APIs at the public boundary.