【Android笔记】 Framework-优快云博客

本文链接：https://blog.youkuaiyun.com/2401_84912041/article/details/138933004

}else {

// deal parentProc

}

复制代码

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

打开binder驱动
映射内存，分配缓冲区
注册binder线程
进入binder loop

5.Application

一般用来：

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

初始化：从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线程

冷启动流程大致如图：

[图片上传失败…(image-92a9c-1638946169885)]

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

发送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.屏幕刷新

带着问题去思考

丢帧一般是什么原因引起的？
Android 刷新频率是60帧/秒，每隔16ms调onDraw绘制一次？
onDraw完之后屏幕会马上刷新吗？
如果界面没有重绘，还会每隔16ms刷新屏幕吗?
如果在屏幕快要刷新的时候才去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信号的起点保持一致。从而减少卡顿。

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

主线程耗时操作

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

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

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

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

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

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

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

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

9.surface