什么是在Android应用程序使用多个进程的利弊 [英] What are pros and cons of using multiple processes within android application
问题描述
我写这个问题没有任何具体的应用程序的一部分，但作为未来应用的潜在用途的一部分。我知道这个问题的答案是非常特殊应用，但我希望你会和我一起裸。我会把我的理解是，希望你能帮助我通过扩展它。令人惊讶的是徒劳的，我已经在网上搜索一个完整的概述，一直没能找到它。相关网页的任何链接，欢迎明显。
在一个单一的进程默认运行Android应用程序。每个活动或服务，你开始会默认在主线程甚至可以运行。由用户所有的操作是用主线程的活套排队，并且各个回调在主线程处理。
为了提供并发，线程可以在许多不同的方式，单独或池启动。没有明确的需要在这方面为多个进程。使用多个进程，让您的设备的多核并行工作是没有必要的，因为线程可以并行运行为好，甚至你的<一个href="http://stackoverflow.com/questions/16562424/does-single-thread-application-utilize-multi-core-in-android">main线程？但是，也许这将是更容易真正实现？
为了让在特定的活动或服务的工作（可能不同）过程中，你只设置了安卓过程清单文件的属性。所以容易实现？
Android框架是专门为移动设备，它们具有有限的内存与到处去建。因此进程可以在各种情况下被杀死，明确指出这里。只要你执行活动和服务，如的onStop 或的onDestroy ，这应该不会给任何的生命周期回调真正的问题。但显然compartmentalizing你的应用的各个部分，通过使用多个进程，有可能让更重要的事情活着。例如，一个背景下载服务可以保持存活（3级中的重要性），而该过程与初始活性，在背景（4级）开始这个服务，现在可以被释放其资源。此外，你是隔离应用程序的核心功能的事实，可能会允许您的设备，以更好地利用资源？
在活页夹框架使得IPC很容易处理的，是你通常会使用，而不管实际使用多个进程。我认为有多个进程的应用程序的主要成本是共享资源的访问，或进程之间发送这些资源，不包括需要从受精卵派生进程的额外资源。我不知道是否使用多个进程实际上会迫使你以不同方式实现应用程序？
我觉得概念上使用多个进程不会增加实施的难易程度？
要摘要多进程的优点：
- 隔离可能使更多的终生保护。
- 条块提供设备更多的机动性重新获得资源。
- 并行的性能提升？
缺点：
- 在一个新的进程必须从受精卵利用资源叉
- 在一个应用程序资源将需要在多个进程共享，其中应变的装置和也许应用性能两者。
在主要用例我能想到的：
- 使用任何用户交互的前台活动并运行连续使用绑定的服务要做到这一点可能活得比用户与你的活动和/或应用程序的会话有用的同步。
如果您对我的理解发表任何言论，请注明左右（注意我的解释几个问号）。如果您有任何优点和/或缺点，添加请回复，以及，我将它们添加到列表中。
使用多个进程，让您的设备的多核并行工作是没有必要的，因为线程可以并行运行为好，甚至你的主线程？
现场（非阻塞）的线程将在多个内核并行运行自动。
但是，也许这将是更容易真正实现？
我会考虑线程比进程更简单，而是更容易是普遍的看法。
有关例如一个后台下载服务可以保持存活（3级中的重要性），而该过程与初始活动开始这服务，现在在后台（4级），可以释放其资源。
除了将你通过具有两个过程在首位，并保持运行长时间一个业务通常反模式浪费更多的资源。
在活页夹框架使得IPC很容易处理的，是你通常会使用，而不管实际使用多个进程
开发通常不直接使用活页夹。只有那些实现绑定服务都需要它，这是Android应用的一个相当小的比例。
我不知道是否使用多个进程实际上会迫使你以不同方式实现应用程序？
是的。
隔离可能使更多的终生保护
恕我直言，这不是浪费内存，CPU和电池上的多个进程的有效借口。
并行的性能提升？
主题涵盖这一点。
主要使用情况下，我能想到的
虽然有可能是方案中的用例实际上是净好处给用户，这是远不能确定。既然你有不同的方式实现你的应用程序来处理多个进程，使用多个进程是一个的最后的办法，不是说你做定期的诸如此类的事情，恕我直言。
I am writing this question not as part of any specific application, but as part of potential use for future applications. I know that the answers to this question can be very application specific, but I hope you will bare with me. I will convey my understanding as is, and hopefully you can help me by extending it. Surprisingly in vain, I have searched the web for a 'complete' overview and have not been able to find it. Any links to relevant pages are welcome obviously.
An android application by default runs in a single process. Each Activity or Service that you start will by default even run in the main thread. All actions by the user are queued by the Looper of the main thread, and the respective callbacks are handled in the main thread.
In order to provide concurrency, threads can be started in lots of different ways, single or in pools. There is not explicit need in this regard for multiple processes. Using multiple processes to allow the multiple cores of your device to work in parallel is not necessary since Threads can be run in parallel as well, maybe even your main thread? But perhaps it will be easier to actually achieve?
In order to let an Activity or Service work in a specific (potentially different) process you only set the android:process attribute in the Manifest file. So easy to implement?
The Android framework is specifically built for mobile devices, which typically have limited memory to go around with. Therefore processes can be killed under a variety of circumstances, clearly stated here. As long as you implement the lifecycle callbacks of Activities and Services, such as onStop or onDestroy, this should not give any real problems. But obviously compartmentalizing pieces of your application, by using multiple processes, could potentially keep more important things alive. For instance a background download Service could be kept alive (level 3 in importance), while the process with the initial Activity that started this Service, now in the background (level 4) could be freed for its resources. Furthermore the fact that you are isolating core features of your application might allow your device to make better use of its resources?
The Binder framework makes IPC fairly easy to handle, and is something you will use generally, regardless of actually using multiple processes. I think the main cost of having multiple processes to the application is the access to shared resources, or the sending of those resources between processes, excluding the additional resources required for forking a process from the Zygote. I wonder whether using multiple processes will actually force you to implement your application differently?
I think that conceptually the use of multiple processes will not increase ease of implementation?
To summarize the pros of multiple processes:
- Isolation potentially gives more lifetime protection.
- Compartmentalization gives the device more manoeuvrability in regaining resources.
- Parallelization performance boost?
Cons:
- A new process must be forked from the Zygote using resources
- Within an application resources will need to be shared over multiple processes, which strain both the device and the perhaps application performance.
The main use case I can think of:
- Use a foreground activity for any user interactions and run a continuously used bound Service to do useful synchronization that might outlive the session that the user has with your activity and/or application.
If you have any remarks on my understanding please state so (Note several question marks in my explanation). If you have any pros and/or cons to add please reply as well, I will add them to the list.
Using multiple processes to allow the multiple cores of your device to work in parallel is not necessary since Threads can be run in parallel as well, maybe even your main thread?
Live (non-blocked) threads will be run in parallel across multiple cores automatically.
But perhaps it will be easier to actually achieve?
I would consider threads easier than processes, but "easier" is generally an opinion.
For instance a background download Service could be kept alive (level 3 in importance), while the process with the initial Activity that started this Service, now in the background (level 4) could be freed for its resources.
Except that you wasted more resources by having the two processes in the first place, and keeping a service running for long periods of time is generally an anti-pattern.
The Binder framework makes IPC fairly easy to handle, and is something you will use generally, regardless of actually using multiple processes
Developers do not normally use Binder directly. Only those implementing bound services need it, and that is a fairly small percentage of Android apps.
I wonder whether using multiple processes will actually force you to implement your application differently?
Yes.
Isolation potentially gives more lifetime protection
IMHO, this is not a valid excuse for wasting RAM, CPU, and battery on multiple processes.
Parallelization performance boost?
Threads cover this.
The main use case I can think of
While there may be scenarios in which your use case actually is a net benefit to the user, it is far from certain. Given that you have to implement your app differently to handle multiple processes, using multiple processes is a last resort approach, not the sort of thing that you do routinely, IMHO.
这篇关于什么是在Android应用程序使用多个进程的利弊的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
