一些技术总结

android

关键字

final

理解 Java 关键字 Final

修饰类

当一个类不想被继承时，就可以用final来修饰

修饰方法

当一个方法不想被子类覆写(Override)时，可以用final来修饰。另外一方面，把方法用final来修饰也有一定的性能提升上的帮助，因为虚拟机知道它不会被覆写，所以可以以更简单的方式来处理。

private的方法，默认都会被编译器加上final.

修饰变量

被final修饰的变量只能赋值一次，之后不能再被修改，对于基本类型来说，就是变量值不能再被修改；对于引用来说，就是不能再让其指向其他对象或者null。

修饰成员变量

域变量也是变量，所以用final来修饰的第一个作用就是赋值后，不能再修改变量的值。

但对于成员变量，声明为final的域变量必须在声明时初始化，或者在构造方法中初始化，否则会有编译错误。

遇到过的一个bug

这个有一个线上的bug

class A {
    public void test() {}
}
class B {
    private A a;
    public B() {
        // xxxx
        a = new A();
    }
}
B b = new B();
b.a.test();
报空指针异常

怎么解决的呢？

private final A a;

jvm禁止编译器把final域的写重排序到构造函数之外。

对象实例化有是那个步骤：
1. 分配内存空间。
2. 初始化对象。
3. 将内存空间的地址赋值给对应的引用。

多线程环境下，如果2和3被重排序了，就有可能是1-3-2，那么B不为null，但是A可能还没有初始化。

volatile

一旦共享变量被volatile修饰之后，那么就具备了两层语义：

• 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。
• 禁止进行指令重排序。volatile前面代码的不会重排到volatile后面

synchronized

一个线程执行临界区代码过程如下：

1. 获得同步锁
2. 清空工作内存
3. 从主存拷贝变量副本到工作内存
4. 对这些变量计算
5. 将变量从工作内存写回到主存
6. 释放锁

方法锁和对象锁的区别

深入理解多线程（一）——Synchronized的实现原理

• 同步方法，JVM采用ACC_SYNCHRONIZED标记符来实现同步.

  同步方法的常量池中会有一个ACC_SYNCHRONIZED标志。当某个线程要访问某个方法的时候，会检查是否有ACC_SYNCHRONIZED，如果有设置，则需要先获得监视器锁，然后开始执行方法，方法执行之后再释放监视器锁。这时如果其他线程来请求执行方法，会因为无法获得监视器锁而被阻断住。

• 同步代码块。JVM采用monitorenter、monitorexit两个指令来实现同步。

  执行monitorenter指令理解为加锁，执行monitorexit理解为释放锁。 每个对象维护着一个记录着被锁次数的计数器。未被锁定的对象的该计数器为0，当一个线程获得锁（执行monitorenter）后，该计数器自增变为 1 ，当同一个线程再次获得该对象的锁的时候，计数器再次自增。当同一个线程释放锁（执行monitorexit指令）的时候，计数器再自减。当计数器为0的时候。锁将被释放，其他线程便可以获得锁。

finally

你真的知道finally吗

finally代码块一定会执行吗？

答案当然是否定的。原因显而易见，在如下的情况下，finally代码块不会执行。

• 在try代码块之前，程序出现异常，不会执行到finally代码块。
• 在try代码块之前，程序返回，不会执行finally代码块。
• 在try代码块中，如果主动执行System.exit(0)语句，不会执行finally代码块。
• 在没执行到finally代码块之前，突然JVM异常退出，例如断电，finally不会执行。

返回值问题

示例一

public int finallyCase() {
    int i = 1;
    try {
        i = 3;
        System.out.println("try block,i="+i);
        return i;
    } finally {
        i = 4;
        System.out.println("finally block,i=" + i);
    }
}

结果

try block,i=3
finally block,i=4
方法返回值：3

JVM会把try或者catch代码块中的返回值保留，再来执行finally代码块中的语句，等到finally代码块执行完毕之后，再把之前保留的返回值给返回出去。

示例二

public int finallyCase() {
    int i = 1;
    try {
        i = 3;
        System.out.println("try block,i="+i);
        return i;
    } finally {
        i = 4;
        System.out.println("finally block,i=" + i);
        return i;
    }
}

try block,i=3
finally block,i=4
方法返回值：4

finally代码块是在try中return之前执行。i变成了4，然后直接return了，所以try中的return语句实际是没有被执行的。因此返回值为4。

finalize

对象不可达之后，如果对象没有覆盖finalize方法，或者finalize已经被执行过一次，则直接回收，反之，对象被加入一个队列，等待finalize线程来执行finalize方法，这个方法里面，如果重新与GCroot建立联系，则被移除队列，反之，就被回收

handle

聊一聊Android的消息机制

handler&Looper&MessageQueue

postxxx和sendxxx什么区别

callback runnable message调用顺序

postDelay如何实现

Message对象池

ThreadLocal

Looper为什么不会ANR

MessageQueue的IdleHandler

你知道android的MessageQueue.IdleHandler吗？
Android常见优化方式-避开高峰期

在消息队列MessageQueue类中，定义了一个IdleHandler接口，它是用来表示当线程处理完所有的消息，准备进入等待状态时的回调接口，可以根据这个来判断应用的核心业务运行状态是否进入了空闲状态。
避免高峰期

应用场景

Android里面有一个场景：

当从一个Activity启动另一个Activity时，Ams要先调用当前Activity的onPause()，然后再启动目标Activity，目标Activity启动后，要把原Activity完全覆盖掉，按照Activity的生命周期管理，原Activity要调用onStop()，但它是在什么时候调用的呢，就是在IdleHandler中调用的。为什么这样做呢，因为新Activity的显示非常重要，要保证它的优先处理，旧Activity要销毁了，已经不显示UI界面了，那就等到UI线程处于空闲期再处理。

自己App的场景

Android应用运行启动之后，一般要进行全局初始化、资源加载、UI显示等一系列的操作，显然此时会出现CPU使用一个高峰期，如果这些任务不加区分，一股脑的全部运行起来，势必影响到UI的显示。因此，可以对此进行流程优化，全力把保障UI线程的运行，把初始化、资源加载分为两部分，一部分是UI界面显示必需的，另一部分和初始化界面不相关的，在应用启动阶段只运行和UI相关的部分，其余部分等到高峰期过去之后再运行。

Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() { 
    @Override public boolean queueIdle() { 
        initInBackground(); //后台运行的初始化任务在UI处于空闲时运行
        return false; 
    } 
});

同步屏障

setAsynchronous

启动过程

Activity启动过程

一篇文章看明白 Android 从点击应用图标到界面显示的过程

Service启动过程

Broadcast启动过程

窗口机制

Activity&Window&DecorView的关系

Activity&Window的关系

Activity启动流程 可以参考上面的，我们直接说ApplicationThread.scheduleLaunchActivity()，发送小小给H，然后H调用handleLaunchActivity

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
   ...
    // Initialize before creating the activity
    WindowManagerGlobal.initialize();
    Activity a = performLaunchActivity(r, customIntent);
    if (a != null) {
        r.createdConfig = new Configuration(mConfiguration);
        Bundle oldState = r.state;
        handleResumeActivity(r.token, false, r.isForward,
        ...
}

再来看下performLaunchActivity

ActivityThread.performLaunchActivity

ActivityThread.performLaunchActivity {
    //类似Application的创建过程，通过classLoader加载到activity.
    activity = mInstrumentation.newActivity(classLoader, 
               component.getClassName(), r.intent);
    //因为Activity有界面，所以其Context是ContextThemeWrapper类型，但实现类仍是ContextImpl.
    Context appContext = createBaseContextForActivity(r, activity);
    activity.attach(context,mInstrumentation,application,...);
    //调用activity.oncreate
    mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
...
    //调用Activity的onstart方法
    activity.performStart();
   //调用activitu的OnRestoreInstanceState方法进行Window数据恢复 
    mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state,r.persistentState);
}

由上面这些源码我们可以知道

• handleLaunchActivity
  

  • performLaunchActivity
    

    • mInstrumentation.newActivity
    • activity.attach
    • mInstrumentation.callActivityOnCreate
      public void callActivityOnCreate(Activity activity, Bundle icicle) {
          prePerformCreate(activity);
          activity.performCreate(icicle);
          postPerformCreate(activity);
      }
    • activity.performStart()
    • mInstrumentation.callActivityOnRestoreInstanceState

• handleResumeActivity
  

  • performResumeActivity
    

    • activity.performResume()

所以，handleLaunchActivity里面会调用onCreate，onStart，onRestoreInstanceState，onResume；onCreate里面又回调用setContextView。还有就是，一个 Activity 界面的绘制，其实是在 onResume() 之后才开始的

在ActivityThread.performLaunchActivity中,创建Activity的实例,接着会调用Activity.attach()来初始化一些内容,而Window对象就是在attach里进行创建初始化赋值的。

Activity.attach

final void attach（...） { 
    ...    
    mWindow = new PhoneWindow(this);    
    mWindow.setWindowManager((WindowManager)context.getSystemService(Context.WINDOW_SERVICE), mToken, mComponent.flattenToString(),(info.flags & ActivityInfo.FLAG_HARDWARE_ACCELERATED) != 0);   
    if (mParent != null) {            
        mWindow.setContainer(mParent.getWindow());        
    }
    mWindowManager = mWindow.getWindowManager();    
    ...
}

从上面两个代码可以看出来，Activity在onCreate之前，先创建了一个Windown，即PhoneWindow，并设置了WindowManager，因此一个Activity对应着一个Window也就是应用窗口。
由上面的代码可知Window类的成员变量mWindowManager和Activity的成员变量mWindowManager都是指向同一个WindowManager对象，而WindowManager对象是调用如下代码获取：

(WindowManager)context.getSystemService(Context.WINDOW_SERVICE)

而我们知道Activity是继承Context类的，ContextImpl类中实现了WindowManager服务的注册，代码如下：

class ContextImpl extends Context {
static {
    registerService(WINDOW_SERVICE, new ServiceFetcher() {
                Display mDefaultDisplay;
                public Object getService(ContextImpl ctx) {
                    Display display = ctx.mDisplay;
                    if (display == null) {
                        if (mDefaultDisplay == null) {
                            DisplayManager dm = (DisplayManager)ctx.getOuterContext().
                                    getSystemService(Context.DISPLAY_SERVICE);
                            mDefaultDisplay = dm.getDisplay(Display.DEFAULT_DISPLAY);
                        }
                        display = mDefaultDisplay;
                    }
                    return new WindowManagerImpl(display);
                }});
    .......
    }
}

有上面代码可知，在ContextImpl类中注册服务是一个静态代码块，也就是说值执行main方法之前就已经完成了WindowManager服务的注册。在整个应用第一次创建Context对象的时候就已经创建WindowManagerImpl对象了，所以，不管一个应用程序中有多少个Activity，但只有一个WindowManagerImpl对象。

Activity添加View

每个Activity都会在onCreate里面调用setContextView方法来加载布局视图，而这其实就是视图View添加到Activity窗口上的一个过程。加载布局视图代码如下Activity#setContentView：

public void setContentView(int layoutResID) {
    getWindow().setContentView(layoutResID);
    initWindowDecorActionBar();
}

PhoneWindow#setContentView

public void setContentView(int layoutResID) {
    if (mContentParent == null) {
        //给窗口安装装饰视图DecorView
        installDecor();
    } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
        mContentParent.removeAllViews();
    }
    if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {
        final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,
                getContext());
        transitionTo(newScene);
    } else {
        //加载xml布局视图内容到视图容器mContentParent中
        mLayoutInflater.inflate(layoutResID, mContentParent);
    }
}

调用installDecor方法给窗口安装视图装饰，所谓视图装饰指的就是界面上看到的标题栏，导航栏Actionbar，也就是窗口的标题栏。

installDecor

private void installDecor() {
    if (mDecor == null) {
        //
        mDecor = generateDecor();
        mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);
        mDecor.setIsRootNamespace(true);
        if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {
            mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);
        }
    }
    if (mContentParent == null) {
        mContentParent = generateLayout(mDecor);
     }
    ........
}

该方法中主要做了两件事:
- 调用generateDecor方法获得DecorView对象，该对象是ViewGroup类型，用于描述窗口Window的顶层视图。
- 调用generateLayout方法给窗口添加标题栏，同时获得装载窗口内容的容器mContentParent，该成员变量也是ViewGroup类型。

generateDecor()

protected DecorView generateDecor() {
    return new DecorView(getContext(), -1);
}

generateLayout()

protected ViewGroup generateLayout(DecorView decor) {
   int layoutResource;  //窗口修饰布局文件
   if() {
    layoutResource = com.android.internal.R.layout.dialog_title_icons;
   } else if() {
    layoutResource = com.android.internal.R.layout.screen_title_icons;
   } else if() {
    layoutResource = com.android.internal.R.layout.screen_progress;
   } else if() {
   }
   ....
    View in = mLayoutInflater.inflate(layoutResource, null);
    decor.addView(in, new ViewGroup.LayoutParams(MATCH_PARENT, MATCH_PARENT));
    ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);
    return contentParent;
}

1. 根据窗口的风格修饰类型为该窗口选择不同的窗口布局文件(根视图)，例如FullScreen(全屏)、NoTitleBar(不含标题栏)等
2. android:id="@android:id/content"，根据这个id得到mContentParent，这个就是咱们setContentView的根布局，一般为FrameLayout

窗口布局文件，R.layout.screen_title

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
        android:orientation="vertical"
        android:fitsSystemWindows="true">
        <FrameLayout
            android:layout_width="match_parent" 
            android:layout_height="?android:attr/windowTitleSize"
            style="?android:attr/windowTitleBackgroundStyle">
            <TextView android:id="@android:id/title" 
                style="?android:attr/windowTitleStyle"
                android:background="@null"
                android:fadingEdge="horizontal"
                android:gravity="center_vertical"
                android:layout_width="match_parent"
                android:layout_height="match_parent" />
        </FrameLayout>
        <FrameLayout android:id="@android:id/content"
            android:layout_width="match_parent" 
            android:layout_height="0dip"
            android:layout_weight="1"
            android:foregroundGravity="fill_horizontal|top"
            android:foreground="?android:attr/windowContentOverlay" />
    </LinearLayout>

全屏的窗口布局文件 R.layout.screen_simple:

<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
        android:id="@android:id/content"
        android:fitsSystemWindows="true"
        android:foregroundInsidePadding="false"
        android:foregroundGravity="fill_horizontal|top"
        android:foreground="?android:attr/windowContentOverlay" />

然后，回过头来，在installDecor里面调用inflate方法将布局视图内容加载到刚刚获得的内容容器mContentParent上。

现在总结一下他们之间的关系：一个Activity中有一个Window对象用于描述当前应用的窗口，而Window是抽象类，实际上指向PhoneWindow类。PhoneWindow类中有一个内部类DecorView用于描述窗口的顶层视图，该类实际上是ViewGroup类型。它里面有一个@android:id/content指向的mContentParent，也是一个ViewGraoup，我们setContextView里面设置进去的xml，会成为它的子 view。

DecorView添加到Window上

我们知道Activity中的PhoneWindow对象帮我们创建了一个PhoneWindow内部类DecorView（父类为FrameLayout）窗口顶层视图，然后通过LayoutInflater将xml内容布局解析成View树形结构添加到DecorView顶层视图中id为content的FrameLayout父容器上面。到此，我们已经知道Activity的content内容布局最终会添加到DecorView窗口顶层视图上面

那么，窗口顶层视图DecorView是怎么绘制到我们的手机屏幕上的呢？
上面我们说到

handleLaunchActivity里面会调用onCreate，onStart，onRestoreInstanceState，onResume；onCreate里面又回调用setContextView

所以接下来，我们看下onResume的调用。
我们上面说过，在handleLaunchActivity里面，performLaunchActivity之后，会调用handleResumeActivity：

final void handleResumeActivity(IBinder token,
        boolean clearHide, boolean isForward, boolean reallyResume){
    //调用activity.onResume，把activity数据记录更新到ActivityClientRecord
    ActivityClientRecord r = performResumeActivity(token, clearHide);
    if (r != null) {
        final Activity a = r.activity;
        //activity.mStartedActivity是用来标记启动Activity，有没有带返回值，一般我们startActivity(intent)是否默认是startActivityForResult(intent,-1)，默认值是-1，所以这里mStartedActivity = false
        boolean willBeVisible = !a.mStartedActivity;
        ...
        //mFinished标记Activity有没有结束，而r.window一开始activity并未赋值给ActivityClientRecord，所以这里为null
        if (r.window == null && !a.mFinished && willBeVisible) {
            r.window = r.activity.getWindow(); //赋值
            View decor = r.window.getDecorView();
            decor.setVisibility(View.INVISIBLE);
            ViewManager wm = a.getWindowManager();
            WindowManager.LayoutParams l = r.window.getAttributes();
            a.mDecor = decor;
            l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
            l.softInputMode |= forwardBit;
            if (a.mVisibleFromClient) {
                a.mWindowAdded = true;
                //把当前的DecorView与WindowManager绑定一起
                wm.addView(decor, l);
            }
        ...

performResumeActivity注释已经很清楚了，里面会回调onResume方法，这里就不详细说明了。一个 Activity 界面的绘制，其实是在 onResume() 之后才开始的。
我们主要看这句：

wm.addView(decor, l);

很明显，这句就是把Activity的顶层视图DecorView添加到窗口视图上，我们来看addView方法
下面是WindowManagerImpl的源码

public final class WindowManagerImpl implements WindowManager {
    private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();
    private final Display mDisplay;
    private IBinder mDefaultToken;
    public WindowManagerImpl(Display display) {
        this(display, null);
    }
    private WindowManagerImpl(Display display, Window parentWindow) {
        mDisplay = display;
        mParentWindow = parentWindow;
    }
    public WindowManagerImpl createLocalWindowManager(Window parentWindow) {
        return new WindowManagerImpl(mDisplay, parentWindow);
    }
 @Override
    public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
        applyDefaultToken(params);
        mGlobal.addView(view, params, mDisplay, mParentWindow);
    }
    @Override
    public void updateViewLayout(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {
        applyDefaultToken(params);
        mGlobal.updateViewLayout(view, params);
    }
@Override
    public void removeView(View view) {
        mGlobal.removeView(view, false);
    }
    @Override
    public void removeViewImmediate(View view) {
        mGlobal.removeView(view, true);
    }
    @Override
    public Display getDefaultDisplay() {
        return mDisplay;
    }
}

我们发现，其实都是调用了WindowManagerGlobal类相对应的方法：

public final class WindowManagerGlobal {
    private final ArrayList<View> mViews = new ArrayList<View>();
    private final ArrayList<ViewRootImpl> mRoots = new ArrayList<ViewRootImpl>();
    private final ArrayList<WindowManager.LayoutParams> mParams =
            new ArrayList<WindowManager.LayoutParams>();
    ........
    //单例模式构造方法
    public static WindowManagerGlobal getInstance() {
        synchronized (WindowManagerGlobal.class) {
            if (sDefaultWindowManager == null) {
                sDefaultWindowManager = new WindowManagerGlobal();
            }
            return sDefaultWindowManager;
        }
    }
     ........
     //窗口的添加过程
     public void addView(View view, ViewGroup.LayoutParams params,
            Display display, Window parentWindow) {
        final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams)params;
        if (parentWindow != null) {
            parentWindow.adjustLayoutParamsForSubWindow(wparams);
        } else {
            final Context context = view.getContext();
            if (context != null
                    && context.getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.LOLLIPOP) {
                wparams.flags |= WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED;
            }
        }
        ViewRootImpl root;
        View panelParentView = null;
        synchronized (mLock) {    
            if (mSystemPropertyUpdater == null) {
                mSystemPropertyUpdater = new Runnable() {
                    @Override public void run() {
                        synchronized (mLock) {
                            for (int i = mRoots.size() - 1; i >= 0; --i) {
                                mRoots.get(i).loadSystemProperties();
                            }
                        }
                    }
                };
            }
            //不能重复添加窗口
            int index = findViewLocked(view, false);
            if (index >= 0) {
                if (mDyingViews.contains(view)) {
                    mRoots.get(index).doDie();
                } else {
                    throw new IllegalStateException("View " + view
                            + " has already been added to the window manager.");
                }       
            }
            //判断当前窗口是否为子窗口，如果是则获得其父窗口并保存在panelParentView变量中
            if (wparams.type >= WindowManager.LayoutParams.FIRST_SUB_WINDOW &&
                    wparams.type <= WindowManager.LayoutParams.LAST_SUB_WINDOW) {
                final int count = mViews.size();
                for (int i = 0; i < count; i++) {
                    if (mRoots.get(i).mWindow.asBinder() == wparams.token) {
                        panelParentView = mViews.get(i);
                    }
                }
            }
            //每一个窗口对应着一个ViewRootImpl对象
            root = new ViewRootImpl(view.getContext(), display);
            //给当前窗口视图设置参数
            view.setLayoutParams(wparams);
            //保存三个数组
            mViews.add(view);
            mRoots.add(root);
            mParams.add(wparams);
        }
        try {
            //真正执行窗口的视图View绘制工作的方法
            root.setView(view, wparams, panelParentView);
        } 
    }
 //主要更新当前窗口的参数LayoutParams
 public void updateViewLayout(View view, ViewGroup.LayoutParams params) {
        final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams)params;
        view.setLayoutParams(wparams);
        synchronized (mLock) {
            int index = findViewLocked(view, true);
            ViewRootImpl root = mRoots.get(index);
            mParams.remove(index);
            mParams.add(index, wparams);
            root.setLayoutParams(wparams, false);
        }
    }
    //从三个数组里面分别移除DecorView对象，ViewRootIpl对象，WindowManager.LayoutParams对象
    public void removeView(View view, boolean immediate) { 
        synchronized (mLock) {
            int index = findViewLocked(view, true);
            View curView = mRoots.get(index).getView();
            removeViewLocked(index, immediate);
            if (curView == view) {
                return;
            }
        }
    }

在WindowManagerGlobal类中维系着三个数组分别是：

• mViews：保存着当前应用所有窗口的顶层视图DecorView对象
• mRoots：保存着当前应用所有窗口的视图绘制类ViewRootImpl
• mParams：保存着当前应用所有窗口的参数 WindowManager.LayoutParams

另外，上面我们说过:

一个应用中不管有多少个Activity，都共用一个WindowManagerImpl对象，

因此：

而在WindowManagerImpl类中是单例模式获得WindowManagerGlobal对象，因此：一个应用中也就只有一个WindowManagerGlobal对象了。而在该对象中通过维护以上三个数组来维护一个应用中所有窗口的管理。

我们来看下addView方法：

public void addView(View view, ViewGroup.LayoutParams params,Display display, Window parentWindow) {
    ...
    ViewRootImpl root = new ViewRootImpl(view.getContext(), display);        
    view.setLayoutParams(wparams);    
    mViews.add(view);    
    mRoots.add(root);    
    mParams.add(wparams);        
    root.setView(view, wparams, panelParentView);
    ...
}

这个过程创建一个ViewRootImpl,并将之前创建的DecoView作为参数传入,以后DecoView的事件都由ViewRootImpl来管理了,比如DecoView上添加View,删除View。
ViewRootImpl实现了ViewParent这个接口,这个接口最常见的一个方法是requestLayout()。
ViewRootImpl是个ViewParent，在DecoView添加的View时,就会将View中的ViewParent设为DecoView所在的ViewRootImpl,View的ViewParent相同时,理解为这些View在一个View链上。
所以每当调用View的requestLayout()时,其实是调用到ViewRootImpl，ViewRootImpl会控制整个事件的流程。可以看出一个ViewRootImpl对添加到DecoView的所有View进行事件管理。

• View链的判断标准是ViewParent是否为同一个。
• View调用requestLayout()方法时，实际上时调用了他的ViewParent的requestLayout()，也即时ViewRootImpl的requestLayout()。
• windowManager.addView调用一次，就会新建一个ViewRootImpl对象

我们接着看ViewRootImpl的setView方法：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
    ...
    // Schedule the first layout -before- adding to the window  
    // manager, to make sure we do the relayout before receiving  
    // any other events from the system.
    requestLayout();
    ...
    try {
    ...
        res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,getHostVisibility(), mDisplay.getDisplayId(),mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,mAttachInfo.mOutsets, mInputChannel);
    } 
}。

• 调用到requestLayout（），表示添加Window之前先完成第一次layout布局过程，以确保在收到任何系统事件后面重新布局。requestLayout最终会调用performTraversals方法来完成View的绘制。
• 接着会通过WindowSession最终来完成Window的添加过程。在下面的代码中mWindowSession类型是IWindowSession，它是一个Binder对象，真正的实现类是Session，也就是说这其实是一次IPC过程，远程调用了Session中的addToDisPlay方法。
• 而Session的addToDisPlay最后也是调用了WindowManagerService的addWindow方法，也就是说Window的添加请求，最终是通过WindowManagerService来添加的

这时候，我们在看下这种图，就会很清晰了

我们在看下requestLayout（）这个方法

@Override
public void requestLayout() {
    if (!mHandlingLayoutInLayoutRequest) {
        checkThread();
        mLayoutRequested = true;
        scheduleTraversals();
    }
}

checkThread判断线程一致行的，注意其实并不是判断是否时UI线程

void checkThread() {
    if (mThread != Thread.currentThread()) {
        throw new CalledFromWrongThreadException(
                "Only the original thread that created a view hierarchy can touch its views.");
    }
}

这里就涉及到一个问题，子线程是否可以更新UI，具体情况看这里 子线程是否可以更新UI

我们主要来看scheduleTraversals()

void scheduleTraversals() {
    if (!mTraversalScheduled) {
        mTraversalScheduled = true;
        mTraversalBarrier = mHandler.getLooper().postSyncBarrier();
        mChoreographer.postCallback(
                Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
        if (!mUnbufferedInputDispatch) {
            scheduleConsumeBatchedInput();
        }
        notifyRendererOfFramePending();
    }
}
..............
final class TraversalRunnable implements Runnable {
        @Override
        public void run() {
            doTraversal();
        }
    }
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
...............
 void doTraversal() {
        if (mTraversalScheduled) {
            mTraversalScheduled = false;
            mHandler.getLooper().removeSyncBarrier(mTraversalBarrier);
            try {
                performTraversals();
            } finally {
                Trace.traceEnd(Trace.TRACE_TAG_VIEW);
            }
        }
    }
............

跟踪代码，最后DecorView的绘制会进入到ViewRootImpl类中的performTraversals()成员方法：

private void performTraversals() {
    // cache mView since it is used so much below...
    //我们在Step3知道，mView就是DecorView根布局
    final View host = mView;
    //在Step3 成员变量mAdded赋值为true，因此条件不成立
    if (host == null || !mAdded)
        return;
    //是否正在遍历
    mIsInTraversal = true;
    //是否马上绘制View
    mWillDrawSoon = true;
    .............
    //顶层视图DecorView所需要窗口的宽度和高度
    int desiredWindowWidth;
    int desiredWindowHeight;
    .....................
    //在构造方法中mFirst已经设置为true，表示是否是第一次绘制DecorView
    if (mFirst) {
        mFullRedrawNeeded = true;
        mLayoutRequested = true;
        //如果窗口的类型是有状态栏的，那么顶层视图DecorView所需要窗口的宽度和高度就是除了状态栏
        if (lp.type == WindowManager.LayoutParams.TYPE_STATUS_BAR_PANEL
                || lp.type == WindowManager.LayoutParams.TYPE_INPUT_METHOD) {
            // NOTE -- system code, won't try to do compat mode.
            Point size = new Point();
            mDisplay.getRealSize(size);
            desiredWindowWidth = size.x;
            desiredWindowHeight = size.y;
        } else {//否则顶层视图DecorView所需要窗口的宽度和高度就是整个屏幕的宽高
            DisplayMetrics packageMetrics =
                mView.getContext().getResources().getDisplayMetrics();
            desiredWindowWidth = packageMetrics.widthPixels;
            desiredWindowHeight = packageMetrics.heightPixels;
        }
}
............
//获得view宽高的测量规格，mWidth和mHeight表示窗口的宽高，lp.widthhe和lp.height表示DecorView根布局宽和高
int childWidthMeasureSpec = getRootMeasureSpec(mWidth, lp.width);
int childHeightMeasureSpec = getRootMeasureSpec(mHeight, lp.height);
// Ask host how big it wants to be
//执行测量操作
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
........................
//执行布局操作
performLayout(lp, desiredWindowWidth, desiredWindowHeight);
.......................
//回调OnGlobalLayoutListener，在meausre、layout之后，draw之前
if (triggerGlobalLayoutListener) {
    mAttachInfo.mRecomputeGlobalAttributes = false;
    mAttachInfo.mTreeObserver.dispatchOnGlobalLayout();
}
.......................
//执行绘制操作
performDraw();
}

performTraversals方法会经过measure、layout和draw三个过程才能将一个View绘制出来，所以View的绘制是ViewRootImpl完成的，另外当手动调用invalidate，postInvalidate，requestInvalidate也会最终调用performTraversals，来重新绘制View。

这里面还有一个问题，我们通过上面的分析可以知道，在onCreate和onResume里面调用getMeasureHeight() = 0是没有问题，平时我们获取的时候，可以使用监听：

view.getViewTreeObserver().addOnGlobalLayoutListener(new OnGlobalLayoutListener() {
    @Override
    public void onGlobalLayout() {
    // TODO Auto-generated method stub
    }
});

上面的代码已经很清楚了：

//执行测量操作
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);
........................
//执行布局操作
performLayout(lp, desiredWindowWidth, desiredWindowHeight);
.......................
//回调OnGlobalLayoutListener，在meausre、layout之后，draw之前
if (triggerGlobalLayoutListener) {
    mAttachInfo.mRecomputeGlobalAttributes = false;
    mAttachInfo.mTreeObserver.dispatchOnGlobalLayout();
}
.......................
//执行绘制操作
performDraw();

OnGlobalLayoutListener，是在meausre、layout之后，draw之前回调的。

• ActivityThread.performLaunchActivity()
• Activity.attach()
• Activity.onCreate()
• Activity.setContentView()
• PhoneWindow.setContentView()
• PhoneWindow.installDecor()
  
  • PhoneWindow.generateDecor()：创建DecorView对象，继承FrameLayout
  • PhoneWindow.generateLayout()：根据不通的窗口风格，选择不通的layout文件，并添加到DecorView，返回id为content的FrameLayout，作为
• ActivityThread.performResumeActivity()

绘制机制

卡顿检测的方法

屏幕刷新机制

Android 屏幕刷新机制

进程间通信

AIDL

Messager

Context

Android Context 上下文 你必须知道的一切

数字1：启动Activity在这些类中是可以的，但是需要创建一个新的task。一般情况不推荐。
数字2：在这些类中去layout inflate是合法的，但是会使用系统默认的主题样式，如果你自定义了某些样式可能不会被使用。

View

View.post

View.post() 不靠谱的地方你知道吗？

集合

SparseArray

为什么不用一个数组？

线程

Lock & synchronized 区别

(1). Lock是一个接口，是JDK层面的实现；而synchronized是Java中的关键字，是Java的内置特性，是JVM层面的实现；
(2). synchronized 在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
(3). Lock 可以让等待锁的线程响应中断，而使用synchronized时，等待的线程会一直等待下去，不能够响应中断；
(4). 通过Lock可以知道有没有成功获取锁，而synchronized却无法办到；
(5). Lock可以提高多个线程进行读操作的效率。
在性能上来说，如果竞争资源不激烈，两者的性能是差不多的。而当竞争资源非常激烈时（即有大量线程同时竞争），此时Lock的性能要远远优于synchronized。所以说，在具体使用时要根据适当情况选择。

停止线程

Java多线程初探——正确停止线程

性能优化

卡顿优化

图片优化

包大小减少

架构

设计模式

反向控制IOC

IOC模式是一种依赖倒置，也即反向调用机制。如果把应用层调用框架层代码的过程，称为正向调用的话，那么反过来，由框架层调用应用层代码的过程，就称为反向调用。也就是说框架层根据自己的流程，会在需要的时候回调应用层的代码，来实现具体业务逻辑，从应用层的角度看，相当于流程控制从自己一方转移到了框架层，相当于控制反转了。

优缺点

• 优点是完美地兼顾了框架的通用性和应用的具体性，由框架负责不变的流程，应用负责易变的业务；
• 缺点就是流程不容易理解、难以调试，因为是反向调用，和人的正向调用思维方式不一样，尤其是在调试代码时，不能像正向调用那样一步步的跟踪，来查找问题。

实现方式

模板方法模式
框架层定义基类，在基类中实现框架的基本逻辑流程，并定义了抽象方法以供基类使用，由应用层继承该基类并override抽象方法

观察者模式
框架层定义回调接口类，由应用层实现该接口类，并注册到框架层，框架层负责调用该回调接口。

Android中的应用

• Application、Activity、Fragment类中的onXxx()等生命周期方法、View的onMeasure()、onLayout()、onDraw()、onXxxEvent()等方法，都是模板方法模式中的“钩子方法”
• View类中常用的OnXxxListener接口，由应用层实现具体的接口添加View实例中，OnXxxListener为Observer角色，框架层为Subject角色。

依赖注入DI

DI（依赖注入）模式是通过对象注入的方式让框架得到所需要的对象。这样，应用层不再关注何时以及如何把对象实例传给框架，只要提供相关的类就行了，由框架自己在需要的时候负责创建依赖对象的实例，从而由应用层创建对象实例，变成了由框架层自己创建。总之，概括起来就是：DI模式就是由框架层负责创建应用层所定义的类的对象实例，从应用层视角看，就好像是自己定义的类被自动注入到了框架层。

优缺点

• 好处就是解耦，能够保持软件模块之间的松耦合，为设计开发带来灵活性。我们开发时只需要定义相关类就行了，框架在需要的时候自己会主动创建。如果业务需求变化了，比如，需要替换一个Activity，修改非常简单，只需要重新编写一个新的Activity类，在Manifest中替换掉旧的Activty即可，除了编写一个类外，没有修改其它地方的任何代码，和其它代码没有任何耦合，方便多了。当然，严格地说只是在代码层面上解耦了，把耦合放到了Manifest中去了。定义一个类，修改一下配置文件，就满足了需求变化，无需修改原来的代码，够灵活够方便吧
• 缺点，首先是效率低，因为需要解析配置文件、动态加载类、使用反射来创建对象，不过毕竟DI模式能够为编程带来方便，牺牲点性能应该还能接受的。其次，在创建对象时不够灵活，不如应用层那样可以按照不同的具体场景创建对象。

实现方式

实现DI模式的方法一般就是配置文件+ClassLoader+反射，通常应用层完成了接口类的定义之后，把它按照一定的格式要求，在配置文件中进行设置，比如：类的名称、包名、相关参数、是否单例等。框架在运行的时候，解析该配置文件，得到创建这些类的相关信息，然后在合适的时机使用ClassLoader来加载这些类，接着使用反射机制创建出相应的对象实例。

• 提供反向控制IOC：框架层定义了基类，并抽象依赖于这个基类定义的接口方法进行业务处理，应用层定义了这个基类的派生类，并实现或者override基类的接口方法。框架层使用这个派生类创建了对象实例，并供自己使用它来实现具体的业务逻辑。
• 提供工厂方法来管理、控制对象实例：应用层定义类，自己并不创建它的对象实例，当要使用的时候，就调用框架层提供的类似getInstance(String id)方法来得到一个对象。框架层预先或者在应用层调用getInstance()的时候来创建相应的对象实例，实现了工厂方法的功能，框架层可以延迟创建或者缓冲这些对象实例。

Android中的应用

• Manifest、xml文件

  Manifest中定义的那些Activity、Service等对象，在需要的时候调用它们，从而实现了应用层的具体业务；在View的Layout布局文件中，可以在节点处设置View类，如TextView、ImgeView等类。Android框架会自动扫描这些配置文件中的节点，并解析它们，得到类的名称和创建对象要用到的参数，然后创建出它们的对象实例，并注入到相关业务逻辑代码中，在需要的时候，就调用它们实现的接口方法。这样我们只是实现这些类就行了，无需在代码中创建相应的实例对象。这是第一种应用场景，框架层自己创建对象实例自己使用。

• 资源文件

  Android开发工程中，有一个res资源目录，里面除了layout之外，还有其他的文件夹，比如color、drawable、anim等资源目录，可以把它们所包含的文件看作是配置文件。Android框架在运行的时候，会解析它们，并创建出相应的对象实例，比如Color、Drawable等类型的对象实例，并以它们的id作为索引号，保存在R.id包下。如果应用程序要使用这些对象，根本不需要通过new操作来创建它们，而是在Context中调用对应的方法接口，比如getColor()、getDrawable()等获取它们就行了，因为这些对象已经都被Android框架在程序运行时创建好了，并且缓存了起来。这是第二种应用场景，框架层创建对象实例供应用层使用，框架层就是创建对象的工厂