Randall hit an issue where his device would take a few seconds to start
up. His logs indicate that his device is spending time running
LaunchJobs.
The first change here is to make sure we explicitly set the launch job
work at an ultra-high priority. This is okay, since we don't actually
present UI until after we finish these jobs. Running this work at
UserInteractive is appropriate since it quite literally prevents the
user from interacting with the app. There's also no other time-sensitive
UI work we need to be doing (like running animations) that we could be
contending with.
The second change is to add a bit more logging that allows us to monitor
the amount of work these jobs are doing. This will allow us to see if
these jobs are performing an excessive amount of work.
Finally, I moved these LaunchJobs to Swift. Mostly because the ObjC
implementations were block based. The additional code was going to
indent things further and our linter aggressiely indents blocks to begin
with. Moving this to Swift is much more readable.
...rather than stringifying the UUID just to parse it back. For
-[TSAccountManager localAddress] in particular the savings are
surprisingly substantial because the UUID string went into an
autorelease pool.
...instead of parsing them all from the server and *then* processing
them (85200228cf). This should keep from blowing out an arbitrary
amount of RAM in pathological cases.
Generate valid sender certificates in tests, removing the need to
customize validation or build certificate data by hand.
While here, remove "throwswrapped" from some APIs that no longer wrap
ObjC-throwing methods.
iOS keeps track of the last-used skin tone modifiers for every
reaction emoji you use. Before reactions were customizable, this
applied to the default set of reactions as well: if you went into the
full picker to select a light-skinned thumbs-up, the short picker
would also have a light-skinned thumbs-up from then on, and if you
changed to dark skin or back to "default" (yellow in our font), the
short picker would be updated again.
However, this is *not* how the customized reactions sync'd through
storage service work; those have skin tone modifiers "baked in", so to
speak. These reactions weren't being treated as valid because they
weren't "base" emoji that could have a skin tone applied to them.
This PR changes things so that there are now two possible states:
- You have never customized your reactions on any platform. In this
case, skin tones continue to follow your most recent choice for that
emoji from the full picker.
- You *have* customized your reactions, in which case it's assumed
they already have the skin tones you want. This even allows you to
have multiple reactions in your default set with the same base emoji
but different skin tones.
Further commits will remove the special nature of the first state.
SignalClient used to support a non-standard version of HKDF as
"version 2" (numbered for an old version of the Signal protocol), and
the standard one as "version 3". Now only the standard version is
supported, so the parameter is unnecessary.
Optimizing for non-downloaded stickers by reading the entire table set
of IDs into memory first then subsequently reading each row one-by-one
seems less than ideal.
Without the GroupV2Params caches, processing multiple large group
updates is extremely wasteful, decrypting the same profile keys and
UUIDs over and over again. The size of these caches has also been
*increased* to match the group size limit, or else there's no benefit
for large groups.
Other LRUCache instances are still off by default in the NSE by virtue
of the "NSE max" defaulting to 0.
If there are several group changes being returned at once,
deserializing all of them up front can lead to excessive memory use,
especially for very large groups. This commit switches to
deserializing each change as it is used, which doubles the amount of
CPU work (because we loop through the changes twice) in exchange for
only ever having one Change object graph in memory at a time. It does
also mean we can get a protobuf deserialization error a bit later in
the process if the data is ever corrupted, but that shouldn't cause
additional issues at these particular call sites.
Previously fetching outstanding challenges from the database was done
synchronously when the app was done loading, but using them was always
done from the work queue. Nothing synchronized those two, though, so
TSan flagged it as a data race.
* refactored async loading of avatar images in HomeView
* async loading avatars does not use extra DispatchWorkItems anymore
* minor code changes, added comments
