清理手机缓存每次都要花费很长时间，有啥办法可以快速清理吗？

Posted 2023-05-16

清理手机缓存文件，可以尝试以下方法进行清理：
1、手机安装一个腾讯手机管家，在健康优化里面点一下垃圾清理，再选择垃圾扫描，扫描完成后立即清理按完成就可以了。
2、在设置里面可以对应用程序进行单个清理缓存。设置-更多设置-应用程序-选择要清理的程序-清除缓存和数据。
3、以上还无法清除干净的话可以选择恢复出厂设置，这样可以清除所有数据。不过清理之前要做好备份处理，否则会导致所以数据丢失。 参考技术A 腾讯手机管家清理手机垃圾耗时很少的本回答被提问者采纳

使用 multiprocessing.Manager.list 而不是真正的列表会使计算花费很长时间

【中文标题】使用 multiprocessing.Manager.list 而不是真正的列表会使计算花费很长时间

【英文标题】：Using multiprocessing.Manager.list instead of a real list makes the calculation take ages

【发布时间】：2012-10-18 18:38:57

【问题描述】：

我想从这个例子开始尝试不同的使用multiprocessing的方式：

$ cat multi_bad.py 
import multiprocessing as mp
from time import sleep
from random import randint

def f(l, t):
#   sleep(30)
    return sum(x < t for x in l)

if __name__ == '__main__':
    l = [randint(1, 1000) for _ in range(25000)]
    t = [randint(1, 1000) for _ in range(4)]
#   sleep(15)
    pool = mp.Pool(processes=4)
    result = pool.starmap_async(f, [(l, x) for x in t])
    print(result.get())

这里，l 是一个列表，当产生 4 个进程时会被复制 4 次。为了避免这种情况，文档页面提供了使用队列、共享数组或使用multiprocessing.Manager 创建的代理对象。最后一个，我改了l的定义：

$ diff multi_bad.py multi_good.py 
10c10,11
<     l = [randint(1, 1000) for _ in range(25000)]
---
>     man = mp.Manager()
>     l = man.list([randint(1, 1000) for _ in range(25000)])

结果看起来仍然正确，但是执行时间急剧增加，以至于我认为我做错了什么：

$ time python multi_bad.py 
[17867, 11103, 2021, 17918]

real    0m0.247s
user    0m0.183s
sys 0m0.010s

$ time python multi_good.py 
[3609, 20277, 7799, 24262]

real    0m15.108s
user    0m28.092s
sys 0m6.320s

文档确实说这种方式比共享数组慢，但这感觉不对。我也不确定如何对此进行分析以获取有关正在发生的事情的更多信息。我错过了什么吗？

附：使用共享数组，我得到的时间低于 0.25 秒。

P.P.S.这是在 Linux 和 Python 3.3 上。

【问题讨论】：

在您的实际用例中，您是否正在修改千兆字节的数据？还是流程只需要访问数据？

@unutbu 只读就可以了。

那么您不需要将数据作为参数传递给工作函数。只需在__main__ 模块的全局级别定义数据一次，所有子进程都可以访问它。为此，您根本不需要 mp.Manager 或 mp.Array。

@unutbu 这是一个很好的观点，谢谢！不知何故，我发现在使用共享数组时我可以这样做（因为将它们作为参数传递会产生错误），但令我感到羞耻的是，我未能将这一事实推广到其他情况。但是让我们假设我确实需要写权限，因为我也希望它对我来说很清楚。

@unutbu 实际上，我只是尝试过（将def f(l, t) 更改为def f(t) 并调整异步调用），看起来每个进程都存储数据，它不是共享的。因此，总内存使用量是使用代理对象或共享数组观察到的内存使用量的倍数。有什么想法吗？

【参考方案1】：

当子进程为os.forked 时，Linux 使用copy-on-write。演示：

import multiprocessing as mp
import numpy as np
import logging
import os

logger = mp.log_to_stderr(logging.WARNING)

def free_memory():
    total = 0
    with open('/proc/meminfo', 'r') as f:
        for line in f:
            line = line.strip()
            if any(line.startswith(field) for field in ('MemFree', 'Buffers', 'Cached')):
                field, amount, unit = line.split()
                amount = int(amount)
                if unit != 'kB':
                    raise ValueError(
                        'Unknown unit u!r in /proc/meminfo'.format(u = unit))
                total += amount
    return total

def worker(i):
    x = data[i,:].sum()    # Exercise access to data
    logger.warn('Free memory: m'.format(m = free_memory()))

def main():
    procs = [mp.Process(target = worker, args = (i, )) for i in range(4)]
    for proc in procs:
        proc.start()
    for proc in procs:
        proc.join()

logger.warn('Initial free: m'.format(m = free_memory()))
N = 15000
data = np.ones((N,N))
logger.warn('After allocating data: m'.format(m = free_memory()))

if __name__ == '__main__':
    main()

产生了

[WARNING/MainProcess] Initial free: 2522340
[WARNING/MainProcess] After allocating data: 763248
[WARNING/Process-1] Free memory: 760852
[WARNING/Process-2] Free memory: 757652
[WARNING/Process-3] Free memory: 757264
[WARNING/Process-4] Free memory: 756760

这表明最初大约有 2.5GB 的可用内存。 分配 float64s 的 15000x15000 数组后，有 763248 KB 可用空间。这大致是有道理的，因为 15000**2*8 字节 = 1.8GB 并且内存下降，2.5GB - 0.763248GB 也大约是 1.8GB。

现在每个进程生成后，可用内存再次报告为 ~750MB。可用内存没有显着减少，因此我认为系统必须使用写时复制。

结论：如果不需要修改数据，在__main__模块的全局级别定义它是一种方便且（至少在Linux上）内存友好的方式在子进程之间共享它。

【讨论】：

在我的机器上也是这样，我什至尝试将直接使用Process改为Pool.apply_async，结果还是差不多。我不确定与我的初始代码有什么不同。我还尝试在 if 块内移动内存分配。

好的，没有区别 :) 不知何故 top 报告所有进程都在使用大量内存，并且它没有显示为共享。

【参考方案2】：

这是意料之中的，因为访问共享对象意味着必须腌制请求，通过某种信号/系统调用发送它

基本上，您应该尽量避免共享内存。这会导致更多可调试的代码（因为您的并发性要少得多）并且速度更快。

只有在真正需要时才应该使用共享内存（例如，共享千兆字节的数据，以便复制它需要太多 RAM，或者进程应该能够通过该共享内存进行交互）。

附带说明一下，使用管理器可能比共享数组慢得多，因为管理器必须能够处理任何 PyObject * 并因此必须腌制/取消腌制等，而数组可以避免大部分这种开销。

来自多处理的文档：

管理器提供了一种创建数据的方法，这些数据可以在它们之间共享 不同的过程。一个管理器对象控制一个服务器进程，它 管理共享对象。其他进程可以访问共享对象 通过使用代理。

因此，使用管理器意味着生成一个新进程，该进程仅用于处理共享内存，这可能是它需要更多时间的原因。

如果您尝试分析代理的速度，它比非共享列表慢很多：

>>> import timeit
>>> import multiprocessing as mp
>>> man = mp.Manager()
>>> L = man.list(range(25000))
>>> timeit.timeit('L[0]', 'from __main__ import L')
50.490395069122314
>>> L = list(range(25000))
>>> timeit.timeit('L[0]', 'from __main__ import L')
0.03588080406188965
>>> 50.490395069122314 / _
1407.1701119638526

虽然Array 并没有那么慢：

>>> L = mp.Array('i', range(25000))
>>> timeit.timeit('L[0]', 'from __main__ import L')
0.6133401393890381
>>> 0.6133401393890381 / 0.03588080406188965
17.09382371507359

由于非常基本的操作很慢，并且认为加快它们的希望不大，这意味着如果您必须共享大量数据并希望快速访问它，那么您应该使用@987654324 @。

可能会加快速度的方法是一次访问多个元素（例如，获取切片而不是单个元素），但取决于您想要执行的操作，这可能会也可能不会。

【讨论】：

使用代理对象会使事情变慢 100 倍，使该方法无用。我想知道它是否仅适用于所示案例。也许代理对象的正确用例有点不同？是的，我只是在研究这个，因为我需要在进程之间共享千兆字节的数据。

如果shared Array比Manager.list快很多，为什么不能用呢？您真的需要list 的灵活性吗？

我想知道重构现有应用程序需要付出多少努力。更改为使用列表代理很简单。更改为共享数组可能是可能的，但更复杂。在执行此操作之前，我想确保我了解发生了什么。

我添加了更多解释。您需要在重构中付出多少努力取决于使用此列表的代码。如果它使用了list 中不存在的许多Array 功能，那么您将不得不更改很多代码，但如果您已经有一个同质序列，那么您可能不需要更改很多代码。