feat: auto-retry with single-threaded writer on OOM

[Ushie]

Type

Functionality

Issue

When running on limited memory, it may not be enough to patch a specific app and ends up throwing an OOM as seen in #193

Feature

ReVanced Patcher handles the OOM and restarts with single thread at the appropriate step

Motivation

ReVanced Patcher supports both single and multi-threads, multi-threads are preferred at all times as the patching process will overall be faster

This moves the hassle from the end-user to ReVanced Patcher, hopefully for a seamless transition with a few additional logs to state what happened

Additional context

The reason I'm opening this in the ReVanced Patcher repository instead of ReVanced Library or expecting it to be done by the clients is that hopefully, ReVanced Patcher can restart ONLY the necessary section instead of having to start over from the beginning

Acknowledgements

• I have searched the existing issues and this is a new and no duplicate or related to another open issue.
• I have written a short but informative title.
• I filled out all of the requested information in this issue properly.

[LisoUseInAIKyrios]

Perhaps patcher could also check how much memory is available, and if it's below some preset threshold then always use single threaded from the start.

[oSumAtrIX]

@LisoUseInAIKyrios It depends on the app. Some apps can be patched with 500MB, such as YouTube with multiple threads, but TikTok requires 500MB with a single line due to having way more classes.

[LisoUseInAIKyrios]

Then could alternatively check how many classes/methods are total, or the total file size of the original class/dex files, and use a threshold based on that. Then compare what YouTube and TikTok size up to, and pick a threshold that falls somewhere between the two that indicates to always use single threaded.

[oSumAtrIX]

By default 1 << 16 classes are compiled for each dex file, reducing this number causes more dex files to be compiled but it does not consume this much memory anymore, but more dex files mean the app will load slower.

[oSumAtrIX]

I am considering closing this issue as it doesn't really make sense from the standpoint of ReVanced Patcher to handle memory issues. It provides the option to select either single or multithreading, but what you make out of it, is not the concern of ReVanced Patcher anymore.

[Ushie]

A client can't implement a solution that is better than a solution from the ReVanced Patcher itself, if ReVanced Patcher can figure out whether to use single or multithreading then the issue is solved universally on all clients, this prevents clients from having to restart the process when they encounter an OOM to run it in single threaded mode

[oSumAtrIX]

It is not ReVanced Patcher's responsibility to care about the environment it runs on, even if it seems simpler to move the matter to ReVanced Patcher. ReVanced Patcher is what the name suggests. It is the single responsibility, and matters like the environment have to be handled by the environment. For that, it allows configuring it according to the environment's needs.

[Ushie]

What about moving this to ReVanced Library? it fits the Library's motive and responsibility of unifying common code across clients