Android Framework 笔记

1,461 阅读11分钟

1.zygote进程。

由init进程fork出来。

zygote主要有两个作用,启动systemserver进程fork子进程。 WMS,AMS,PMS等都运行在systemserver进程中。而我们平常的app进程则是由zygote进程fork出来。

为什么zygote在fork子线程的时候需要单线程?

fork的原理就是copy-on-write机制。zygote进程中已经启动了jvm虚拟机,类预加载资源等。在fork的时候可以继承父进程的资源。但是fork只支持单线程,不支持多线程。zygote在创建子进程的时候,只能有一个线程,负责可能会出现死锁或者资源不同步等问题。而父进程里有很多线程。zygote在fork子进程的时候,先将父进程主线程外的其余的线程停掉,等fork进程完毕之后再启动。 但是有一点需要强调的是,zygote进程可不是单线程,因为它还有守护线程再运行。

为什么不直接用systemserver来孵化呢

1.从架构设计原则来看,尽量做到类或者模块单一原则。

2.从功能实现上看.在fork进程的时候,子继承会继承父进程的一些资源。 我们在启动一个新继承的时候需要最很多的准备。如创建虚拟机,加载各种资源等。这些如果提前加载的话,则可以大大优化进程的创建流程。 systemserver进程主要是用来孵化各种个样的服务,是不能继承到子进程中去的。我们在启动进程的时候,除了一些必备的资源,其它最好是干净的。 所以系统创建了一个zygote进程。既满足了fork子进程时候高效的目的,同时也做到了模块功能的单一和解耦。

zygote的IPC采用的是socket,而不是binder

1.多线程问题 fork子线程时候为了避免死锁,需要单线程环境。而binder是多线程,在fork子线程时候容易出死锁的问题。

2.binder调用比较麻烦。 如果zygote用binder进行通信,需要打开binder驱动,获取文件描述符,mmap内存映射,同时创建binder对象到serviceManager。同时再调用的时候还要从serviceManager中查询binder对象。几个来回比较麻烦。而zygote和systemServer进程本来就是父子关系,对于这种简单的消息,socket比较方便。

3.MMAP数据复写 如果zygote采用binder来fork出systemserver进程的话,那systemserver会继承zygote的描述符和内存映射。这两个进程在binder驱动层会共用一套数据结果。子进程的copy-on-write会造成地址空间重新映射。而子进程还在访问之前的父进程mmap地址,从而引发SIGSEGV、SEGV_MAPERR等错误

2. Android系统的启动

Android系统启动整体比较复杂。主要节点可简单介绍为。 1.init进程fork出zygote进程。zygote通过runOnce方法fork出systemserver进程和其它子进程。

2.systemserver通过startSystemServer()方法来启动。通过nativeZygoteInit()方法来启动binder。然后调用systemserver的main函数。main函数中主要有以下几个功能。

private void run(){
   Looper.prepareMainLooper();
   System.loadLibrary("system_service");
   createSystemContext();

   startBootStrapService();
   startCoreService();
   startOtherService();

   Looper.loop();
}
系统服务怎么发布的:

publishBinderService(String name ,IBinder service),将服务注册到serviceManager里面

系统服务跑在什么线程:

displayThead,fgThread,IoThread,UIThread(这里这个UIThread是子线程),binder线程

服务间的相互依赖是怎么解决的:

分批启动:如ams,pms 分阶段启动:不同的阶段启动不同的service

启动桌面

最后调用systemReady()方法,通过startHomeActivityLocked来启动launcher

3.系统服务和bind服务区别

具体类型系统服务bind服务
启动方式在ststemService进程的startBootStrapService();startCoreService();startOtherService();中启动startService(Intent intent) ,classLoader加载类,然后创建context
注册方式public static void addService(String name,IBInder service){getServiceManager().addService(name,service,false)}(夸进程通信)binder service到AMS
注册位置注册到serviceManager注册到AMS
注册时机(1)systemService中启动各种服务时候(java方式) (2)surfaceflinger这种独立进程,通过jni添加手动注册
使用方式context.getSystemService(Context.POWER_SERVICE)binderService(serviceIntent,ServiceConnection)

4. 进程 & binder启动

在启动进程过程中,binder通信是绕不开的一个点。 应用在启动完毕通知AMS时候是通过binder通信进行通知。而binder的启动时在zygote启动启动进程的时候。zygote在收到AMS的启动请求的时候,会调用runOnce函数

boolean runOnce(){
  String args=readArgumentList();
  int pid=Zygote.forkAndSpecialize(...);
  if(pid==0){
   handleChildProc();
   return true;
  }else {
   // deal parentProc 
  }
}

在handleChildProc()中的nativeZygoteInit()中会启动binder。binder启动主要分为四个步骤

  1. 打开binder驱动
  2. 映射内存,分配缓冲区
  3. 注册binder线程
  4. 进入binder loop

5.Application

一般用来:

  1. 保存全局的应用变量
  2. 初始化操作
  3. 提供上下文

初始化: 从main函数跟进

public static void main(String[] args){
    Looper.prepareMainLooper();
    ActivityThread thread=new ActivityThread();//只是一个普通java类,不是thread
    thread.attach(false);
    
    Looper.loop();
}

在attach函数当中调用

private void attach(){
  final IActivityManager mgr=ActivityManagerNative.getDefault();//AMS在应用进程的binder代理对象
  mgr.attachApplication(mAppthread);//mAppthread是应用进程的binder对象,传入AMS中
}

然后在ASM中调用函数

boolean attachApplicationLocked(IApplicationThread thread){
 thread.bindApplication();//IPC通信到应用进程中
}

应用进程的bindApplication函数为

public  final void bindApplication(){
 AppBindData data=new AppBindData();
 
 sendMessage(H.BIND_APPLICATION,data);//抛到应用主线程去处理
}

在主线程创建Application对象并调用mInstrumentatio.callApplicationOnCreate(app); 所以Application的总体的执行顺序为

new Application() -> Application.attachBaseContext() -> Application.onCreate
不能在Application的构造函数中调用上下文

因为这个时候上下文还没有被初始化。

不要在Application的生命周期中执行耗时参数。

不同于AMS的ONEWAY(发起调用马上返回)的调用方式,Application执行耗时函数会阻塞UI线程。阻碍Application自身后续组件的初始化。

Application中使用静态变量的坑。

在Application中声明一个static Strting name;在A activity中赋值,在B activity中使用。假如此时长时间压后台,然后重新切回来的时候,Application和B activity会重新创建,但是这个时候拿到的静态变量name不会被A activity赋值,从而引发异常。 为解决这个问题,建议B activity接收name参数是用getIntent()的方式从A activity接收参数。同时在onSaveInstanceState中保存这个值。在恢复重建的时候从onCreate(Bundle savedState) 的savedState里读取

6.Context

应用中context的数量=activity数量+service数量+application数量 方便访问系统资源,调用系统服务。

application context

application继承自ContextWrapper.

public class ContextWrapper extends Context{
      Context mBase;//在activity中getBaseContext时候返回。所以是context中还包含了一个context。
      protected void attachBaseContext(Context base){
          mBase=base;
      }
      public Resources getResources(){
        return mBase.getResources();//静态代理。context的所有调用
        //都委托给了mBase
      }
}

getApplication和getApplicationContext都是返回Application全局对象。 getApplicationContext是属于Context的抽象函数。 getApplication是activity和service中特有的函数。

activity context

整体跟application的创建比较类似。但是activity是继承自ContextThemeWrapper. 代码执行也是先执行attachBaseContext,再执行onCreate; 具体创建包括

private Activity perfirmLaunchActivity(){
    Activity activity=null;
    activity=mInstrumenttation.newActivity();//内部通过classloader加载类
    Application app=r.packageInfo.makeApplication();//获取Application对象
    Context appContext =createBaseContextForActivity(r,activity);
    activity.attach(appContext,app,...);//会调用attachBaseContext(context)
    activity.onCreate();
    return activity;
}
servixe context

继承自ContextWrapper。创建流程和perfirmLaunchActivity差不多。

BroadcaseReceiver和Context Provider的上下文由外边传入。但是Context Provider的onCreate调用是在application的onCreate之前调用,但是在application的attachBaseContext之后。

7.Activity 启动流程 & 显示原理 & UI线程

冷启动流程大致如图:

48204bd91fdf451d8ab761871245f131_tplv-k3u1fbpfcp-watermark.png

而普通的应用启动流程如下:

发送startActivity请求到AMS,AMS通过socket发送消息到zygote,zygote发送socket消息到应用进程。后边的流程如上图对应的位置

UI线程

UI线程:UI刷新所在的线程,且UI是单线程刷新的 对activity来说,UI线程就是主线程。runOnUiThread(); 对View来说,UI线程是ViewRootImpl创建所在的线程.View.post(only the origin thread that created a view hoerarchy can touch int view) 随之而来的另外一个问题就是:子线程刷新UI? 参考主线程创建:

final void handleResumeActivity(IBinder token,...){
    final Activity a=r.activity:
    ViewManager wm =a.getWindowManager();
    wm.addView(decor,l);//该方法中会创建ViewRootImpl
}

root=new ViewRootImpl()
root.setView(view,wparams,panelParentView)

所以类似的我们也可以在子线程中刷新view

new Thread(){
    public void run(){
        Looper.prepare();
        getWindowManager().addView(view,parmas);//可以正常显示和操作UI
        Looper.loop();
    }
}.start();

8.屏幕刷新

带着问题去思考

  1. 丢帧一般是什么原因引起的?
  2. Android 刷新频率是60帧/秒,每隔16ms调onDraw绘制一次?
  3. onDraw完之后屏幕会马上刷新吗?
  4. 如果界面没有重绘,还会每隔16ms刷新屏幕吗?
  5. 如果在屏幕快要刷新的时候才去onDraw绘制会丢帧吗?

Choreographer:编舞者(通过threadLoacl创建)

public static Choregrapher getInstance(){
    return sThreadInstance.get();//不同的线程调用getInstance返回的是不同的Choreographer对象
}
requestLayout(){//在一个vsync周期内,只会执行一次刷新
    scheduleTraversals();//插入同步屏障
}

绘制的时候如果跳帧严重,源码会打印出日志提示,SKIPPED_FRAME_WARNING_LIMIT默认是30

void doFram(long framTimenanos,int frame){
    if (skippedFrames >= SKIPPED_FRAME_WARNING_LIMIT) {

        Log.i(TAG, "Skipped " + skippedFrames + " frames!  "
              + "The application may be doing too much work on its main thread.");
}

当view调用requestLayout()时候,将一个callBack传到Choreographer中,Choreographer没有直接处理callBack,而是先向SurfaceFlinger发送requestNextVsync请求下一个vsync信号,SurfaceFlinger在下一个vsync信号来的时候通过postSynEvent通知给Choreographer,Choreographer收到通知后执行真正的绘制performTraversal()方法。

Choreographer作为编舞者,主要是起协调作用。将代码绘制控制到和vsync协调到一个节奏,避免在一个vsync信号的中间位置开始绘制,而是将真正绘制代码的起点和收到vsync信号的起点保持一致。从而减少卡顿。

Choreographer编舞前: 6CCB266B-054C-4ED5-84E2-2FEEC7E84ADE.png Choreographer编舞后:

C6BA47C7-FEB0-4D0F-9803-64891B08B1E4.png

1. 丢帧一般是什么原因引起的?

主线程耗时操作

2. Android 刷新频率是60帧/秒,每隔16ms调onDraw绘制一次?

刷新频率指得是vsync信号发生的频率,不一定每次vsync信号都去绘制,需要应用端主动发起重绘,然后才会向SurfaceFlinger请求接受vsync信号,然后再下次vsync信号来的时候才会去真正绘制

3. onDra完之后屏幕会马上刷新吗?

不会。要等到下次vsync信号来的时候才刷新

4. 如果界面没有重绘,还会每隔16ms刷新屏幕吗?

不发生重绘,就不会接受vsync信号,但是屏幕还是会每隔16m刷新屏幕,只不过刷新是旧的数据

5. 如果在屏幕快要刷新的时候才去onDraw绘制会丢帧吗?

不一定。我们代码中发起的绘制是要等到下次vsync信号来的时候才会执行,跟发起绘制操作的时机没有太大联系

9.surface

surface夸进程传递

  1. 怎么理解surface,它是一块buffer吗?
  2. 如果是,surface跨进程传递怎么带上这个buffer?
  3. 如果不是,那surface和buffer是什么关系?
  4. surface是怎么进行夸进程传递回应用的?
private void performTraversals(){
    if(mFirst){
      relayoutResult=relayoutWindow(params,...);
    }
}
int relayoutWindow(WindowManager.LayoutParams params,...){
    //mWindowSession是一个binder对象,像wms申请surface,所以view的绘制也涉及跨进程通信
    return mWindowSession.relayout(mWindow,...mSurface);
}

WMS端创建了一个native的surface对象,并跟java层的surface对象绑定在一起。(将native层surface对象的指针保存在java层的surface对象中)。WMS端native service的核心是GraphicBufferProducer这个binder对象(简称GBP)。 所以 surface的本质是GraphicBufferProducer,而不是buffer surface夸进程传递,本质是GraphicBufferProducer这个binder对象的传递。

1. 怎么理解surface,它是一块buffer吗?
      不是,它只是一个壳子,里面包含了能生产buffer对象的GraphicBufferProducer这个binder对象
2. 如果是,surface跨进程传递怎么带上这个buffer?
3. 如果不是,那surface和buffer是什么关系?
    通过GraphicBufferProducer(GBP)这个binder对象来传递
4. surface是怎么进行夸进程传回应用的?
     通过GraphicBufferProducer夸进程通信

surface绘制原理

  1. surface 绘制的buffer是怎么来的

    通过GBP向BufferQueue申请.BufferQueue是在surfaceFlinger进程中创建的双端队列。应用端的一个surface对应surfaceFlinger进程端的一个BufferQueue。通过binder跨进程通信将buffer传给应用端的surface。buffer作为canvas和bitmap的缓冲区。等canvas绘制完之后再返回给BufferQueue。BufferQueue通知consumer回调去消费,表示这一帧数据绘制好了。

  2. buffer绘制完了是怎么提交的

    通过GBP提交给BufferQueue(surfaceFlinger进程中)。