我在这里重新发布了my question from Android Enthusiasts，因为这更像是一个编程问题，并且建议使用它。 无论如何。这是：
我正在创建一个应用程序，它会更改ROM的键值的build.prop。但是，Android经常给我一个ANR警告，因为我正在做UI线程上的所有工作。在Android文档中，它告诉我应该使用工作线程，而不是在UI线程中做任何工作。但是，我正在构建这个系统应用程序以使用单个核心设备的ROM。
为什么我要使用工作线程，因为效率不高？因为，Android必须暂停UI线程，加载工作线程，并且再次使用UI时，暂停工作线程并再次加载UI线程。这效率不高吗？
那么，我应该使用工作线程（无论如何都会降低UI线程速度）或者只是在UI线程上完成我的所有工作*即使应用程序UI真的很慢）？
答案 0 :(得分：2)
如果您的用户是机器人，那么您的逻辑就非常有意义。没有上下文切换等于（非常轻微）总体计算时间。你可以对它进行基准测试，看看究竟有多少。
然而，在目前（以及不久的将来），您的用户很可能是人类，因此您需要开始考虑心理学：一般来说，移动的进度条或响应性会给您的用户留下任务的印象实际上比没有任何反馈的时间更短。 带有反馈的主观速度要高得多。
关于主观速度的主题存在大量论文，我在网上找到的first one对a video中的进度条进行了很好的比较（基本上，一些条似乎比其他条更快） ，从而减少主观整体等待时间。）
答案 1 :(得分：1)
使用工作线程。
正如您所说，在UI线程上执行所有操作会锁定UI，直到操作完成。这意味着您无法更新进度，无法处理输入事件（例如用户按下取消按钮）等。
您对上下文切换速度的担忧是错误的 - 随着核心系统进程和其他应用程序在后台运行，这种情况无论如何都会发生。一些快速Google搜索显示，同一进程中的上下文switching a thread仍然是typically faster，而不是进程级上下文切换。通过创建线程然后后续的上下文切换引入了稍微更多的开销，但它可能很短 - 特别是如果你只有1个线程正在完成工作。由于我上面单独列出的原因（UI更新和接受用户输入的能力），需要几毫秒的整体性能。