Android开发

Android源码汇总(启动,loadlib)

本文主要是介绍Android源码汇总(启动,loadlib),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

材料引用blog:http://gityuan.com/ 

App主要是具体的UI业务需求.
AMS则是管理系统四大组件以及进程管理,尤其是Activity的各种栈以及状态切换等管理;
WMS则是管理Activiy所相应的窗口系统(系统窗口以及嵌套的子窗口);
SurfaceFlinger则是将应用UI绘制到frameBuffer(帧缓冲区),最终由硬件完成渲染到屏幕上

交互

  • App跟AMS通信,会建立Session连接到WMS,后续便通过IWindowSesson跟WMS通信;
  • WMS跟SF通信,WMS建立SurfaceComposerClient,然后会在SF中创建Client与之对应, 后续便通过ISurfaceComposerClient跟SF通信;

系统启动架构图

 图解: Android系统启动过程由上图从下往上的一个过程是由Boot Loader引导开机,然后依次进入 -> Kernel -> Native -> Framework -> App
2.1 Linux内核层,2.2 硬件抽象层 (HAL) ,2.3 Android Runtime & 系统库,2.4 Framework层,2.5 App层,2.6 Syscall && JNI
app和framework之间用jni. framework和kernal之间是syscall

 

start_activity_processprocess-create

Boot Loader引导开机,然后依次进入 -> Kernel -> Native -> Framework -> App

启动流程:

  1. 点击桌面App图标,Launcher进程采用Binder IPC向system_server进程发起startActivity请求;
  2. system_server进程接收到请求后,向zygote进程发送创建进程的请求;
  3. Zygote进程fork出新的子进程,即App进程;
  4. App进程,通过Binder IPC向sytem_server进程发起attachApplication请求;
  5. system_server进程在收到请求后,进行一系列准备工作后,再通过binder IPC向App进程发送scheduleLaunchActivity请求;
  6. App进程的binder线程(ApplicationThread)在收到请求后,通过handler向主线程发送LAUNCH_ACTIVITY消息;
  7. 主线程在收到Message后,通过发射机制创建目标Activity,并回调Activity.onCreate()等方法。

到此,App便正式启动,开始进入Activity生命周期,执行完onCreate/onStart/onResume方法,UI渲染结束后便可以看到App的主界面。 启动Activity较为复杂,后续计划再进一步讲解生命周期过程与系统是如何交互,以及UI渲染过程,敬请期待。

每个module作用:

system_server进程是系统进程,Java framework框架的核心载体,里面运行了大量的系统服务,比如这里提供ApplicationThreadProxy(简称ATP),ActivityManagerService(简称AMS),这个两个服务都运行在system_server进程的不同线程中,由于ATP和AMS都是基于IBinder接口,都是binder线程,binder线程的创建与销毁都是由binder驱动来决定的。

App进程是应用程序所在进程,主线程主要负责Activity/Service等组件的生命周期以及UI相关操作都运行在这个线程; 另外,每个App进程中至少会有两个binder线程 ApplicationThread(简称AT)和ActivityManagerProxy(简称AMP),除了下图中所示的线程,其实还有很多线程,比如signal catcher线程等。

Framework层(java frame & c++ frame)

  • Zygote进程,是由init进程通过解析init.rc文件后fork生成的,Zygote进程主要包含:
    • 加载ZygoteInit类,注册Zygote Socket服务端套接字
    • 加载虚拟机
    • 提前加载类preloadClasses
    • 提前加载资源preloadResouces
  • System Server进程,是由Zygote进程fork而来,System Server是Zygote孵化的第一个进程,System Server负责启动和管理整个Java framework,包含ActivityManager,WindowManager,PackageManager,PowerManager等服务。
  • Media Server进程,是由init进程fork而来,负责启动和管理整个C++ framework,包含AudioFlinger,Camera Service等服务。

App层

  • Zygote进程孵化出的第一个App进程是Launcher,这是用户看到的桌面App;
  • Zygote进程还会创建Browser,Phone,Email等App进程,每个App至少运行在一个进程上。
  • 所有的App进程都是由Zygote进程fork生成的。

每一个Activity对应一个应用窗口;每一个窗口对应一个ViewRootImpl对象;
每一个App进程对应唯一的WindowManagerGlobal对象;
WindowManagerGlobal.sWindowManagerService用于跟WMS交互.
WindowManagerGlobal.sWindowSession用于跟Session交互;
每一个App进程对应唯一的相同Session代理对象;
App可以没有Activity/PhoneWindow/DecorView,例如带悬浮窗口的Service;
Activity运行在ActivityThread所在的主线程;
DecorView是Activity所要显示的视图内容;
ViewRootImpl:管理DecorView跟WMS的交互;每次调用addView()添加窗口时,则都会创建一个ViewRootImpl对象;

源码分析参考:Android系统启动-zygote篇 http://gityuan.com/2016/02/13/android-zygote/ ---这个blog写的比较详细具体
startService源码从AMS进程到service的新进程启动过程分析:https://www.jianshu.com/p/e9f579c3b6d0
Android系统启动-综述 http://gityuan.com/2016/02/01/android-booting/

,,,,,,,,,,,,,,,,,,,,,,,

Android系统启动过程:
|启动Kernel创建init进程-->init进程fork第一个进程即Zygote进程(横穿Java和C/C++)-->Zygote创建虚拟机(调用AndroidRuntime.cpp中的startVm创建虚拟机)-->startReg完成虚拟机中的JNI方法注册 

zygote_process

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

//先启动AMS,Process.sart 启动new serviceB,然后serviceB和AMS通信,然后到UI 线程

1 ActivityManagerService(AMS)的startService 
2 底层调用  Process.start 
Process.start()会启动service的新进程。然后导入android.app.ActivityThread类实行它的main函数。
在Android应用程序中,每一个进程对应一个ActivityThread实例,在实行main函数中,会创建一个thread实例。
所以ServiceManagerNative.asInterface(new BinderProxy())==new ServiceManagerProxy(new BinderProxy())
3 ActivityThread类的main函数:
1) main函数中创建该进程的UI线程的Looper以及loop().
2) 创建完ActivityThread,调用ActivityThread.attach函数。
在attach函数中,会调用ActivityManagerNative.getDefault().attachApplication(mAppThread)函数
得到ActivityManagerService(AMS)的远程接口,即ActivityManagerProxy。
3) mAppThread是ApplicationThread对象,它是service新进程,通过Binder驱动程序传递给ActivityManagerService(AMS)进程里.
(mAppThread(new service)----<binder>----AMS)
AMS进程通过IApplicationThread对象跟service新进程通信.
AMS进程把mAppThread设置到代理ApplicationThreadProxy的mRemote。
ActivityManagerProxy:attachApplication(app)
4 在AMS onTransact()-->父类ActivityManagerNative的onTransact(),
其中ApplicationThreadNative.asInterface(data.readStrongBinder()),返回是ApplicationThreadProxy的对象,
把之前的IApplicationThread的实例mAppThread对象(通过Binder驱动放到data里面,即data.readStrongBinder())放到ApplicationThreadProxy的mRemote.
在AMS进程里通过ApplicationThreadProxy中mRemote和service新进程通信。
((mAppThread放到ApplicationThreadProxy的mRemote<------>service新进程通信))
在AMS中的attachApplication中:mServices是ActiveServices实例对象
5 ApplicationThreadProxy的scheduleCreateService:
其中mRemote就是service新进程的ApplicationThread对象,
通过Binder驱动程序回到service新进程的ApplicationThread对象中去执行onTransact(),
6 在H类handleMessage 中:
handlerCreateService是在ActivityThread://H.CREATE_SERVICE.回到新进程的UI线程
service.onCreate(),service就起来了。
最终通过ClassLoader加载Activity类,创建对象,回调对应的生命周期,整个过程结束。

// ServiceManagerNative.java
static public IServiceManager asInterface(IBinder obj) {
    //由于obj为BpBinder,该方法默认返回null
    IServiceManager in = (IServiceManager)obj.queryLocalInterface(descriptor);
    return new ServiceManagerProxy(obj); //见下文
}
class ServiceManagerProxy implements IServiceManager {
    public ServiceManagerProxy(IBinder remote) {
        mRemote = remote; //将BinderProxy保存到mRemote
    }
}
所以ServiceManagerNative.asInterface(new BinderProxy())==new ServiceManagerProxy(new BinderProxy()). 
mRemote为BinderProxy对象,该BinderProxy对象的成员变量mObject记录着BpBinder(0),其作为binder代理端,指向大管家serviceManager进程的服务。
ServiceManager.getIServiceManager==new ServiceManagerProxy(new BinderProxy()),此处ServiceManagerProxy简称为SMP。
framework层的ServiceManager的调用实际的工作确实交给SMP的成员变量BinderProxy;
而BinderProxy通过jni方式,最终会调用BpBinder对象;可见上层binder架构的核心功能依赖native架构的服务来完成的。

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

 loadLibrary动态库加载过程分析

动态库加载程,调用栈如下:

System.loadLibrary()
  Runtime.loadLibrary()
    Runtime.doLoad()
      Runtime_nativeLoad()
          LoadNativeLibrary()
              dlopen()
              dlsym()
              JNI_OnLoad()

System.loadLibrary()和System.load()都用于加载动态库,loadLibrary()可以方便自动加载依赖库,load()可以方便地指定具体路径的动态库。对于loadLibrary()会将将xxx动态库的名字转换为libxxx.so,再从/data/app/[packagename]-1/lib/arm64,/vendor/lib64,/system/lib64等路径中查询对应的动态库。无论哪种方式,最终都会调用到LoadNativeLibrary()方法,该方法主要操作:

  • 通过dlopen打开动态共享库;
  • 通过dlsym获取JNI_OnLoad符号所对应的方法;
  • 调用该加载库中的JNI_OnLoad()方法。
这篇关于Android源码汇总(启动,loadlib)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!