【Android笔记】 Framework

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

---

带着问题去思考

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信号的起点保持一致。从而减少卡顿。

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对象

最后

针对于上面的问题，我总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案，并整理做成了文档，以及系统的进阶学习视频资料。
（包括Java在Android开发中应用、APP框架知识体系、高级UI、全方位性能调优，NDK开发，音视频技术，人工智能技术，跨平台技术等技术资料），希望能帮助到你面试前的复习，且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。

r这个binder对象（简称GBP）。 所以 surface的本质是GraphicBufferProducer，而不是buffer surface夸进程传递，本质是GraphicBufferProducer这个binder对象的传递。

1. 怎么理解surface，它是一块buffer吗？

不是，它只是一个壳子，里面包含了能生产buffer对象的GraphicBufferProducer这个binder对象

最后

针对于上面的问题，我总结出了互联网公司Android程序员面试涉及到的绝大部分面试题及答案，并整理做成了文档，以及系统的进阶学习视频资料。
（包括Java在Android开发中应用、APP框架知识体系、高级UI、全方位性能调优，NDK开发，音视频技术，人工智能技术，跨平台技术等技术资料），希望能帮助到你面试前的复习，且找到一个好的工作，也节省大家在网上搜索资料的时间来学习。

[外链图片转存中…(img-3q1pkssu-1720108366573)]