[Xiaomi Poco F5 / Redmi Note 12 Turbo (China)] TheAceBlock:
I would like to share my insights on the battery issue:

If you use ADB or Termux with root when the battery draining occurs, which is almost always around one or two days of uptime, you can use top or htop to see the list of running processes.

Chances are, there are two (or even three - or there might just be one) system_server processes at the top, each using 100% of the CPU (which means that it uses the 100% of the core it's running on).

It's very puzzling to me as to why this happens: there does not seem to be any log message in logcat indicating that something is wrong, and being a system process, it probably shouldn't be caused by any user apps. But I tried to debug the issue anyway, and even though I was not able to completely pinpoint this problem, I am relatively sure that I was close to the root of the problem. Here's some of the most important discoveries that I've made:

If I use top -H -p [PID of the offending system_server process] in ADB, where -H will show all the threads, and -p will limit that to just that one process, it interestingly shows that one thread used up most of the CPU for this process: CpuTracker. Looking at the Android system's source code for this thread, it seemed to be an ordanry housekeeping thread, collecting CPU usage here and there, and it doesn't seem like this particular code has been modified in Evolution (from AOSP), so I was a bit lost.

But I still wanted to know why would this code fail, and fail in this particular way (from the look of things this thread must have been stuck in an infinite loop for it to consume so much CPU), and rebooting the phone would almost always bring it back down to normal level (barely any CPU usage). So I tried to dug deeper: I looked around for a solution (or someone else who had this problem), and realiszed that I could take a backtrace for a running process with debuggerd -b. I took the stack trace, and the results are as follow:

"CpuTracker" sysTid=2667
#00 pc 00000000000fca68 /apex/com.android.runtime/lib64/bionic/libc.so (__ioctl+8) (BuildId: 55fda59133003aeb22942c92f5b09396)
#01 pc 00000000000a83ec /apex/com.android.runtime/lib64/bionic/libc.so (ioctl+156) (BuildId: 55fda59133003aeb22942c92f5b09396)
#02 pc 000000000000cb28 /system/lib64/libcutils.so (ashmem_get_size_region+184) (BuildId: d2cf65882032cdc83ce7e1b1317a8a05)
#03 pc 000000000017541c /system/lib64/libandroid_runtime.so (android::android_util_MemoryIntArray_size(_JNIEnv*, _jobject*, int)+60) (BuildId: 7b41a98bf9c32ca89b7a1171a921e56a)
#04 pc 00000000001ac094 /system/framework/arm64/boot-framework.oat (art_jni_trampoline+116) (BuildId: a3df2abb4e6f1ec75ddb9e54ff12eccfca3d7fd9)
#05 pc 000000000069aabc /system/framework/arm64/boot-framework.oat (android.util.MemoryIntArray.enforceValidIndex+76) (BuildId: a3df2abb4e6f1ec75ddb9e54ff12eccfca3d7fd9)
#06 pc 000000000069ada4 /system/framework/arm64/boot-framework.oat (android.util.MemoryIntArray.get+68) (BuildId: a3df2abb4e6f1ec75ddb9e54ff12eccfca3d7fd9)
#07 pc 000000000058f244 /system/framework/arm64/boot-framework.oat (android.provider.Settings$GenerationTracker.readCurrentGeneration+84) (BuildId: a3df2abb4e6f1ec75ddb9e54ff12eccfca3d7fd9)
#08 pc 000000000058fc18 /system/framework/arm64/boot-framework.oat (android.provider.Settings$NameValueCache.getStringForUser+1272) (BuildId: a3df2abb4e6f1ec75ddb9e54ff12eccfca3d7fd9)
#09 pc 000000000073ee6c /system/framework/arm64/boot-framework.oat (android.provider.Settings$Global.getStringForUser+188) (BuildId: a3df2abb4e6f1ec75ddb9e54ff12eccfca3d7fd9)
#10 pc 00000000021affd8 /memfd:jit-cache (deleted) (offset 0x2000000) (android.util.FeatureFlagUtils.isEnabled+136)
#11 pc 0000000000c32568 /system/framework/oat/arm64/services.odex (com.android.server.am.AppProfiler.updateCpuStatsNow+136) (BuildId: 7f240a58c981d877f1fc5200a9e96d1da3a60ccf)
#12 pc 0000000000c2ef98 /system/framework/oat/arm64/services.odex (com.android.server.am.AppProfiler$ProcessCpuThread.run+552) (BuildId: 7f240a58c981d877f1fc5200a9e96d1da3a60ccf)
#13 pc 000000000021096c /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+556) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#14 pc 0000000000279de8 /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+184) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#15 pc 000000000062014c /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+460) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#16 pc 0000000000668870 /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+1296) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#17 pc 0000000000114a2c /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+204) (BuildId: 55fda59133003aeb22942c92f5b09396)
#18 pc 000000000009dd10 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 55fda59133003aeb22942c92f5b09396)

There was a lot in this trace, but skimming through the system calls I saw that AppProfiler.updateCpuStatsNow was probably relevant, together with the last thread call. So I looked at codes around this area and found this. An infinite loop inside Thread.run? That sure looks interesting. I took more backtraces and saw that no matter when I run the backtrace, it's always in this run function.

Now that does not necessarily mean that this is the problem, but that's probably as close as I can get. I tried to leverage GDB to debug this process with root, but everytime it either lost the thread (it's stressful to debug multi-threaded programs OK), or worse, the whole system UI would crash. Just to be sure, I did a restart, and everything was fine: no excessive CPU usage, not crasy threads, and the backtrace shows that the process was running wait:

"CpuTracker" sysTid=2717
#00 pc 000000000009869c /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28) (BuildId: 55fda59133003aeb22942c92f5b09396)
#01 pc 00000000002820f4 /apex/com.android.art/lib64/libart.so (art::ConditionVariable::TimedWait(art::Thread*, long, int)+164) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#02 pc 0000000000569c94 /apex/com.android.art/lib64/libart.so (art::Monitor::Wait(art::Thread*, long, int, bool, art::ThreadState)+564) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#03 pc 000000000056b3b8 /apex/com.android.art/lib64/libart.so (art::Monitor::Wait(art::Thread*, art::ObjPtr<art::mirror::Object>, long, int, bool, art::ThreadState)+296) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#04 pc 00000000000922dc /system/framework/arm64/boot.oat (art_jni_trampoline+92) (BuildId: 468e3e02972896a5dd0aa4bae5f92658c486321c)
#05 pc 0000000000099e60 /system/framework/arm64/boot.oat (java.lang.Object.wait+48) (BuildId: 468e3e02972896a5dd0aa4bae5f92658c486321c)
#06 pc 0000000000c2ef44 /system/framework/oat/arm64/services.odex (com.android.server.am.AppProfiler$ProcessCpuThread.run+468) (BuildId: 7f240a58c981d877f1fc5200a9e96d1da3a60ccf)
#07 pc 000000000021096c /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+556) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#08 pc 0000000000279de8 /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+184) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#09 pc 000000000062014c /apex/com.android.art/lib64/libart.so (art::JValue art::InvokeVirtualOrInterfaceWithJValues<art::ArtMethod*>(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, art::ArtMethod*, jvalue const*)+460) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#10 pc 0000000000668870 /apex/com.android.art/lib64/libart.so (art::Thread::CreateCallback(void*)+1296) (BuildId: 15d3e3d0e533c477751fcb49226de890)
#11 pc 0000000000114a2c /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+204) (BuildId: 55fda59133003aeb22942c92f5b09396)
#12 pc 000000000009dd10 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 55fda59133003aeb22942c92f5b09396)

... which is probably what it should be doing most of the time.

AND this is not a fluke either: I can consistently reproduce this on my phone and my friend's phone, both the same make and model. Interestingly, one of my friends with a Mi 10 Pro was also using Evolution X (for their device of course), and it recently very likely had the same issue as well. So it might not be the problem with this particular device, but I'm not sure, and I'm definely no Android system dev either, so definely take my findings with a grain of salt. But I would definitely hope that @joeyhuab would resolve this issue better than I was able to. It's been a great ROM, and I definite appreciate your effort in making this as good as it is now.