android 进程相关

进程   

Android6.0 进程创建流程

http://gityuan.com/2016/03/26/app-process-create/

(http://gityuan.com/images/android-process/start_app_process.jpg)   

图解：

1. App发起进程：当从桌面启动应用，则发起进程便是Launcher所在进程；当从某App内启动远程进程，则发送进程便是该App所在进程。发起进程先通过binder发送消息给system_server进程；
2. system_server进程：调用Process.start()方法，通过socket向zygote进程发送创建新进程的请求；
3. zygote进程：在执行ZygoteInit.main()后便进入runSelectLoop()循环体内，当有客户端连接时便会执行ZygoteConnection.runOnce()方法，再经过层层调用后fork出新的应用进程；
4. 新进程：执行handleChildProc方法，最后调用ActivityThread.main()方法。

android进程启动全过程（4大组件）  

http://gityuan.com/2016/10/09/app-process-create-2/

Activity, Service, ContentProvider, BroadcastReceiver这四大组件,在启动的过程,当其所承载的进程不存在时需要调用startProcessLocked先创建进程

本文首先介绍AMS的4个同名不同参数的方法startProcessLocked; 紧接着讲述了四大组件与进程的关系,Activity, Service, ContentProvider, BroadcastReceiver这四大组件,在启动的过程,当其所承载的进程不存在时需要先创建进程.再然后进入重点以startProcessLocked以引线一路讲解整个过程所遇到的核心方法. 在整个过程中有新创建的进程与system_server进程之间的交互过程是通过binder进行通信的, 这里有两条binder通道分别为AMP/AMN 和 ATP/ATN.

上图便是一次完整的进程创建过程,app的任何组件需要有一个承载其运行的容器,那就是进程, 那么进程的创建过程都是由系统进程system_server通过socket向zygote进程来请求fork()新进程, 当创建出来的app process与system_server进程之间的通信便是通过binder IPC机制.

Android创建新线程   

http://gityuan.com/2016/09/24/android-thread/

Android线程，一般地就是指Android虚拟机线程，而虚拟机线程由是通过系统调用而创建的Linux线程。纯粹的Linux线程与虚拟机线程的区别在于虚拟机线程具有运行Java代码的runtime. 除了虚拟机线程，还有Native线程，对于Native线程有分为是否具有访问Java代码的两类线程。接下来，本文分析介绍这3类线程的创建过程。

1. Native线程(Java版)：该过程相对比较复杂，见如上流程图：
2. Native线程： 相对简单，只有上图中的紫色部分：thread.run -> androidCreateRawThreadEtc -> _threadLoop
3. Java线程： Thread.start -> Thread_nativeCreate -> CreateNativeThread

Android6.0 杀进程的实现原理   

http://gityuan.com/2016/04/16/kill-signal/

 Process.killProcess(int pid)
 Process.killProcessQuiet(int pid)
 Process.killProcessGroup(int uid, int pid)

(http://gityuan.com/images/android-process/process-kill-quiet.jpg)

• Process.killProcess(int pid): 杀pid进程
• Process.killProcessQuiet(int pid)：杀pid进程，且不输出log信息
• Process.killProcessGroup(int uid, int pid)：杀同一个uid下同一进程组下的所有进程

流程分为用户空间(User Space)和内核空间（Kernel Space)。从用户空间进入内核空间需要向内核发出syscall，用户空间的程序通过各种syscall来调用用内核空间相应的服务。系统调用是为了让用户空间的程序陷入内核，该陷入动作是由软中断来完成的。用户态的进程进行系统调用后，CPU切换到内核态，开始执行内核函数。unistd.h文件中定义了所有的系统中断号，用户态程序通过不同的系统调用号来调用不同的内核服务，通过系统调用号从系统调用表中查看到相应的内核服务。

Android6.0 进程绝杀技  

http://gityuan.com/2016/10/22/force-stop/

1. Process: 调用AMS.killPackageProcessesLocked()清理该package所涉及的进程;
2. Activity: 调用ASS.finishDisabledPackageActivitiesLocked()清理该package所涉及的Activity;
3. Service: 调用AS.bringDownDisabledPackageServicesLocked()清理该package所涉及的Service;
4. Provider: 调用AMS.removeDyingProviderLocked()清理该package所涉及的Provider;
5. BroadcastRecevier: 调用BQ.cleanupDisabledPackageReceiversLocked()清理该package所涉及的广播
6. 发送广播ACTION_PACKAGE_RESTARTED，用于停止已注册的alarm,notification.

persistent进程的特殊待遇:

• 进程: AMS.killPackageProcessesLocked()不杀进程
• Service: ActiveServices.collectPackageServicesLocked()不移除不清理service
• Provider: ProviderMap.collectPackageProvidersLocked()不收集不清理provider. 且不杀该provider所连接的client的persistent进程;
• 
  

功能点归纳：

1. force-stop并不会杀persistent进程；
2. 当app被force-stop后，无法接收到任何普通广播，那么也就常见的监听手机网络状态的变化或者屏幕亮灭的广播来拉起进程肯定是不可行；
3. 当app被force-stop后，那么alarm闹钟一并被清理，无法实现定时响起的功能；
4. app被force-stop后，四大组件以及相关进程都被一一剪除清理，即便多进程架构的app也无法拉起自己；
5. 级联诛杀：当app通过ClassLoader加载另一个app，则会在force-stop的过程中会被级联诛杀；
6. 生死与共：当app与另个app使用了share uid，则会在force-stop的过程，任意一方被杀则另一方也被杀，建立起生死与共的强关系。

既然force-stop多次提到杀进程，那最后简单说两句关于保活：正确的保活姿态，应该是在用户需要时保证千万别被杀，用户不需要时别强保活，一切以用户为出发点。

• 进程是否需要存活，系统上层有AMS来管理缓存进程和空进程，底层有LowMemoryKiller来根据系统可用内存的情况来管理进程是否存活，这样的策略是从系统整体性角度考虑，为了是给用户提供更好更流畅的用户体验。
• 用户需要的时候千万别被杀：谨慎使用插件化和共享uid，除非愿意接受级联诛杀和生死与共的场景；还有就是提高自身app的稳定性，减少crash和anr的发生频率，这才是正道。
• 用户不需要的时候别强保活：为了保活，多进程架构，利用各种小技巧来提升优先级等都是不可取的，一招force-stop足以干掉90%以上的保活策略，当然还有一些其他手段及漏洞来保活，系统层面往往还会采取一些特别的方法来禁止保活。博主曾经干过手机底层的性能与功耗优化工作，深知不少app的流氓行径，严重系统的流畅度与手机续航能力。

为了android有更好的用户体验，为了不影响手机系统性能，为了不降低手机续航能力，建议大家花更多时间精力在如何提高app的稳健性，如何优化app性能，共同打造Android的良好生态圈。

进程被杀的善后工作：binderdied()