Android 高级面试题（二）

• 丰富、可扩展的视图系统，可用以构建应用的 UI，包括列表、网格、文本框、按钮甚至可嵌入的网络浏览器
• 资源管理器，用于访问非代码资源，例如本地化的字符串、图形和布局文件
• 通知管理器，可让所有应用在状态栏中显示自定义提醒
• Activity 管理器，用于管理应用的生命周期，提供常见的导航返回栈
• 内容提供程序，可让应用访问其他应用（例如“联系人”应用）中的数据或者共享其自己的数据

• 原生 C/C++ 库：许多核心 Android 系统组件和服务（例如 ART 和 HAL）构建自原生代码，需要以 C 和 C++ 编写的原生库。Android 平台提供 Java 框架 API 以向应用显示其中部分原生库的功能。例如，您可以通过 Android 框架的 Java OpenGL API 访问 OpenGL ES，以支持在应用中绘制和操作 2D 和 3D 图形。如果开发的是需要 C 或 C++ 代码的应用，可以使用 Android NDK 直接从原生代码访问某些原生平台库。
• Android Runtime：对于运行 Android 5.0（API 级别 21）或更高版本的设备，每个应用都在其自己的进程中运行，并且有其自己的 Android Runtime (ART) 实例。ART 编写为通过执行 DEX 文件在低内存设备上运行多个虚拟机，DEX 文件是一种专为 Android 设计的字节码格式，经过优化，使用的内存很少。编译工具链（例如 Jack）将 Java 源代码编译为 DEX 字节码，使其可在 Android 平台上运行。

• 预先 (AOT) 和即时 (JIT) 编译
• 优化的垃圾回收 (GC)
• 更好的调试支持，包括专用采样分析器、详细的诊断异常和崩溃报告，并且能够设置监视点以监控特定字段

• ACTION_DOWN
• ACTION_MOVE(移动的距离超过一定的阈值会被判定为ACTION_MOVE操作)
• ACTION_UP

• dispatchTouchEvent：方法返回值为true表示事件被当前视图消费掉；返回为super.dispatchTouchEvent表示继续分发该事件，返回为false表示交给父类的onTouchEvent处理。
• onInterceptTouchEvent：方法返回值为true表示拦截这个事件并交由自身的onTouchEvent方法进行消费；返回false表示不拦截，需要继续传递给子视图。如果return super.onInterceptTouchEvent(ev)， 事件拦截分两种情况:
  • 如果该View存在子View且点击到了该子View, 则不拦截, 继续分发 给子View 处理, 此时相当于return false。
  • 如果该View没有子View或者有子View但是没有点击中子View(此时ViewGroup 相当于普通View), 则交由该View的onTouchEvent响应，此时相当于return true。

• onTouchEvent：方法返回值为true表示当前视图可以处理对应的事件；返回值为false表示当前视图不处理这个事件，它会被传递给父视图的onTouchEvent方法进行处理。如果return super.onTouchEvent(ev)，事件处理分为两种情况：
  • 如果该View是clickable或者longclickable的,则会返回true, 表示消费 了该事件, 与返回true一样;
  • 如果该View不是clickable或者longclickable的,则会返回false, 表示不 消费该事件,将会向上传递,与返回false一样。

• Activity：拥有分发和消费两个方法。
• ViewGroup：拥有分发、拦截和消费三个方法。
• View：拥有分发、消费两个方法。

public boolean dispatchTouchEvent(MotionEvent ev) {
    boolean consume = false;
    if (onInterceptTouchEvent(ev)) {
        consume = onTouchEvent(ev);
    } else {
        coonsume = child.dispatchTouchEvent(ev);
    }
  
    return consume;
}

1. 事件传递优先级：onTouchListener.onTouch > onTouchEvent > onClickListener.onClick。
2. 正常情况下，一个时间序列只能被一个View拦截且消耗。因为一旦一个元素拦截了此事件，那么同一个事件序列内的所有事件都会直接交给它处理（即不会再调用这个View的拦截方法去询问它是否要拦截了，而是把剩余的ACTION_MOVE、ACTION_DOWN等事件直接交给它来处理）。特例：通过将重写View的onTouchEvent返回false可强行将事件转交给其他View处理。
3. 如果View不消耗除ACTION_DOWN以外的其他事件，那么这个点击事件会消失，此时父元素的onTouchEvent并不会被调用，并且当前View可以持续收到后续的事件，最终这些消失的点击事件会传递给Activity处理。
4. ViewGroup默认不拦截任何事件（返回false）。
5. View的onTouchEvent默认都会消耗事件（返回true），除非它是不可点击的（clickable和longClickable同时为false）。View的longClickable属性默认都为false，clickable属性要分情况，比如Button的clickable属性默认为true，而TextView的clickable默认为false。
6. View的enable属性不影响onTouchEvent的默认返回值。
7. 通过requestDisallowInterceptTouchEvent方法可以在子元素中干预父元素的事件分发过程，但是ACTION_DOWN事件除外。

• 一般ACTION_CANCEL和ACTION_UP都作为View一段事件处理的结束。如果在父View中拦截ACTION_UP或ACTION_MOVE，在第一次父视图拦截消息的瞬间，父视图指定子视图不接受后续消息了，同时子视图会收到ACTION_CANCEL事件。
• 如果触摸某个控件，但是又不是在这个控件的区域上抬起（移动到别的地方了），就会出现action_cancel。

• 对于由于外部滑动和内部滑动方向不一致导致的滑动冲突，可以根据滑动的方向判断谁来拦截事件。
• 对于由于外部滑动方向和内部滑动方向一致导致的滑动冲突，可以根据业务需求，规定何时让外部View拦截事件，何时由内部View拦截事件。
• 对于上面两种情况的嵌套，相对复杂，可同样根据需求在业务上找到突破点。

• 外部拦截法：指点击事件都先经过父容器的拦截处理，如果父容器需要此事件就拦截，否则就不拦截。具体方法：需要重写父容器的onInterceptTouchEvent方法，在内部做出相应的拦截。
• 内部拦截法：指父容器不拦截任何事件，而将所有的事件都传递给子容器，如果子容器需要此事件就直接消耗，否则就交由父容器进行处理。具体方法：需要配合requestDisallowInterceptTouchEvent方法。

• 从Activity的startActivity开始，最终调用到ActivityThread的handleLaunchActivity方法来创建Activity，首先，会调用performLaunchActivity方法，内部会执行Activity的onCreate方法，从而完成DecorView和Activity的创建。然后，会调用handleResumeActivity，里面首先会调用performResumeActivity去执行Activity的onResume()方法，执行完后会得到一个ActivityClientRecord对象，然后通过r.window.getDecorView()的方式得到DecorView，然后会通过a.getWindowManager()得到WindowManager，最终调用其addView()方法将DecorView加进去。
• WindowManager的实现类是WindowManagerImpl，它内部会将addView的逻辑委托给WindowManagerGlobal，可见这里使用了接口隔离和委托模式将实现和抽象充分解耦。在WindowManagerGlobal的addView()方法中不仅会将DecorView添加到Window中，同时会创建ViewRootImpl对象，并将ViewRootImpl对象和DecorView通过root.setView()把DecorView加载到Window中。这里的ViewRootImpl是ViewRoot的实现类，是连接WindowManager和DecorView的纽带。View的三大流程均是通过ViewRoot来完成的。

• EXACTLY：精确测量模式，视图宽高指定为match_parent或具体数值时生效，表示父视图已经决定了子视图的精确大小，这种模式下View的测量值就是SpecSize的值。
• AT_MOST：最大值测量模式，当视图的宽高指定为wrap_content时生效，此时子视图的尺寸可以是不超过父视图允许的最大尺寸的任何尺寸。
• UNSPECIFIED：不指定测量模式, 父视图没有限制子视图的大小，子视图可以是想要的任何尺寸，通常用于系统内部，应用开发中很少用到。

• 首先，在ViewGroup中的measureChildren()方法中会遍历测量ViewGroup中所有的View，当View的可见性处于GONE状态时，不对其进行测量。
• 然后，测量某个指定的View时，根据父容器的MeasureSpec和子View的LayoutParams等信息计算子View的MeasureSpec。
• 最后，将计算出的MeasureSpec传入View的measure方法，这里ViewGroup没有定义测量的具体过程，因为ViewGroup是一个抽象类，其测量过程的onMeasure方法需要各个子类去实现。不同的ViewGroup子类有不同的布局特性，这导致它们的测量细节各不相同，如果需要自定义测量过程，则子类可以重写这个方法。（setMeasureDimension方法用于设置View的测量宽高，如果View没有重写onMeasure方法，则会默认调用getDefaultSize来获得View的宽高）

• Activity/View#onWindowFocusChanged：此时View已经初始化完毕，当Activity的窗口得到焦点和失去焦点时均会被调用一次，如果频繁地进行onResume和onPause，那么onWindowFocusChanged也会被频繁地调用。
• view.post(runnable)： 通过post可以将一个runnable投递到消息队列的尾部，始化好了然后等待Looper调用次runnable的时候，View也已经初始化好了。
• ViewTreeObserver#addOnGlobalLayoutListener：当View树的状态发生改变或者View树内部的View的可见性发生改变时，onGlobalLayout方法将被回调。
• View.measure(int widthMeasureSpec, int heightMeasureSpec)：match_parent时不知道parentSize的大小，测不出；具体数值时，直接makeMeasureSpec固定值，然后调用view..measure就可以了；wrap_content时，在最大化模式下，用View理论上能支持的最大值去构造MeasureSpec是合理的。

• 重写View的layout方法,使最终宽度总是比测量宽/高大100px。
• View需要多次measure才能确定自己的测量宽/高，在前几次测量的过程中，其得出的测量宽/高有可能和最终宽/高不一致，但最终来说，测量宽/高还是和最终宽/高相同。

• 首先绘制View的背景；
• 如果需要的话，保持canvas的图层，为fading做准备；
• 然后，绘制View的内容；
• 接着，绘制View的子View；
• 如果需要的话，绘制View的fading边缘并恢复图层；
• 最后，绘制View的装饰(例如滚动条等等)。

• 默认情况下，View没有启用这个优化标记位，但是ViewGroup会默认启用这个优化标记位。
• 当我们的自定义控件继承于ViewGroup并且本身不具备绘制功能时，就可以开启这个标记位从而便于系统进行后续的优化。
• 当明确知道一个ViewGroup需要通过onDraw来绘制内容时，我们需要显示地关闭WILL_NOT_DRAW这个标记位。

• requestLayout()方法 ：会导致调用 measure()过程 和 layout()过程，将会根据标志位判断是否需要ondraw。
• onLayout()方法：如果该View是ViewGroup对象，需要实现该方法，对每个子视图进行布局。
• onDraw()方法：绘制视图本身 (每个View都需要重载该方法，ViewGroup不需要实现该方法)。
• drawChild()：去重新回调每个子视图的draw()方法。

• 线程是CPU调度的最小单元，同时线程是一种有限的系统资源；而进程一般指一个执行单元，在PC和移动设备上指一个程序或者一个应用。
• 一般来说，一个App程序至少有一个进程，一个进程至少有一个线程（包含与被包含的关系），通俗来讲就是，在App这个工厂里面有一个进程，线程就是里面的生产线，但主线程（即主生产线）只有一条，而子线程（即副生产线）可以有多个。
• 进程有自己独立的地址空间，而进程中的线程共享此地址空间，都可以并发执行。

• 静态成员和单例模式完全失效：独立的虚拟机造成。
• 线程同步机制完全失效：独立的虚拟机造成。
• SharedPreferences的可靠性下降：这是因为Sp不支持两个进程并发进行读写，有一定几率导致数据丢失。
• Application会多次创建：Android系统在创建新的进程时会分配独立的虚拟机，所以这个过程其实就是启动一个应用的过程，自然也会创建新的Application。

• AIDL接口：继承IInterface。
• Stub类：Binder的实现类，服务端通过这个类来提供服务。
• Proxy类：服务端的本地代理，客户端通过这个类调用服务端的方法。
• asInterface()：客户端调用，将服务端返回的Binder对象，转换成客户端所需要的AIDL接口类型的对象。如果客户端和服务端位于同一进程，则直接返回Stub对象本身，否则返回系统封装后的Stub.proxy对象。
• asBinder()：根据当前调用情况返回代理Proxy的Binder对象。
• onTransact()：运行在服务端的Binder线程池中，当客户端发起跨进程请求时，远程请求会通过系统底层封装后交由此方法来处理。
• transact()：运行在客户端，当客户端发起远程请求的同时将当前线程挂起。之后调用服务端的onTransact()直到远程请求返回，当前线程才继续执行。

• 管道：在创建时分配一个page大小的内存，缓存区大小比较有限；
• 消息队列：信息复制两次，额外的CPU消耗；不合适频繁或信息量大的通信；
• 共享内存：无须复制，共享缓冲区直接附加到进程虚拟地址空间，速度快；但进程间的同步问题操作系统无法实现，必须各进程利用同步工具解决；
• 套接字：作为更通用的接口，传输效率低，主要用于不同机器或跨网络的通信；
• 信号量：常作为一种锁机制，防止某进程正在访问共享资源时，其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。 不适用于信息交换，更适用于进程中断控制，比如非法内存访问，杀死某个进程等；

• 效率：传输效率主要影响因素是内存拷贝的次数，拷贝次数越少，传输速率越高。从Android进程架构角度分析：对于消息队列、Socket和管道来说，数据先从发送方的缓存区拷贝到内核开辟的缓存区中，再从内核缓存区拷贝到接收方的缓存区，一共两次拷贝。而对于Binder来说，数据从发送方的缓存区拷贝到内核的缓存区，而接收方的缓存区与内核的缓存区是映射到同一块物理地址的，节省了一次数据拷贝的过程。共享内存不需要拷贝，Binder的性能仅次于共享内存。
• 稳定性：上面说到共享内存的性能优于Binder，那为什么不采用共享内存呢，因为共享内存需要处理并发同步问题，容易出现死锁和资源竞争，稳定性较差。Socket虽然是基于C/S架构的，但是它主要是用于网络间的通信且传输效率较低。Binder基于C/S架构 ，Server端与Client端相对独立，稳定性较好。
• 安全性：传统Linux IPC的接收方无法获得对方进程可靠的UID/PID，从而无法鉴别对方身份；而Binder机制为每个进程分配了UID/PID，且在Binder通信时会根据UID/PID进行有效性检测。

• 首先 Binder 驱动在内核空间创建一个数据接收缓存区。
• 接着在内核空间开辟一块内核缓存区，建立内核缓存区和内核中数据接收缓存区之间的映射关系，以及内核中数据接收缓存区和接收进程用户空间地址的映射关系。
• 发送方进程通过系统调用 copyfromuser() 将数据 copy 到内核中的内核缓存区，由于内核缓存区和接收进程的用户空间存在内存映射，因此也就相当于把数据发送到了接收进程的用户空间，这样便完成了一次进程间的通信。

• Server&Client：服务器&客户端。在Binder驱动和Service Manager提供的基础设施上，进行Client-Server之间的通信。
• ServiceManager（如同DNS域名服务器）服务的管理者，将Binder名字转换为Client中对该Binder的引用，使得Client可以通过Binder名字获得Server中Binder实体的引用。
• Binder驱动（如同路由器）：负责进程之间binder通信的建立，计数管理以及数据的传递交互等底层支持。

• 从进程间通信的角度看，Binder 是一种进程间通信的机制；
• 从 Server 进程的角度看，Binder 指的是 Server 中的 Binder 实体对象；
• 从 Client 进程的角度看，Binder 指的是 Binder 代理对象，是 Binder 实体对象的一个远程代理;
• 从传输过程的角度看，Binder 是一个可以跨进程传输的对象；Binder 驱动会对这个跨越进程边界的对象对一点点特殊处理，自动完成代理对象和本地对象之间的转换。

• IBinder：跨进程通信的Base接口，它声明了跨进程通信需要实现的一系列抽象方法，实现了这个接口就说明可以进行跨进程通信，Client和Server都要实现此接口。
• IInterface：这也是一个Base接口，用来表示Server提供了哪些能力，是Client和Server通信的协议。
• Binder：提供Binder服务的本地对象的基类，它实现了IBinder接口，所有本地对象都要继承这个类。
• BinderProxy：在Binder.java这个文件中还定义了一个BinderProxy类，这个类表示Binder代理对象它同样实现了IBinder接口，不过它的很多实现都交由native层处理。Client中拿到的实际上是这个代理对象。
• Stub：这个类在编译aidl文件后自动生成，它继承自Binder，表示它是一个Binder本地对象；它是一个抽象类，实现了IInterface接口，表明它的子类需要实现Server将要提供的具体能力（即aidl文件中声明的方法）。
• Proxy：它实现了IInterface接口，说明它是Binder通信过程的一部分；它实现了aidl中声明的方法，但最终还是交由其中的mRemote成员来处理，说明它是一个代理对象，mRemote成员实际上就是BinderProxy。

1. 首先定义IActivityManager接口：

   public interface IActivityManager extends IInterface {
       //binder描述符
       String DESCRIPTOR = "android.app.IActivityManager";
       //方法编号
       int TRANSACTION_startActivity = IBinder.FIRST_CALL_TRANSACTION + 0;
       //声明一个启动activity的方法，为了简化，这里只传入intent参数
       int startActivity(Intent intent) throws RemoteException;
   }
   

2. 然后，实现ActivityManagerService侧的本地Binder对象基类：

   // 名称随意，不一定叫Stub
   public abstract class ActivityManagerNative extends Binder implements IActivityManager {
       public static IActivityManager asInterface(IBinder obj) {
           if (obj == null) {
               return null;
           }
           IActivityManager in = (IActivityManager) obj.queryLocalInterface(IActivityManager.DESCRIPTOR);
           if (in != null) {
               return in;
           }
           //代理对象，见下面的代码
           return new ActivityManagerProxy(obj);
       }
       @Override
       public IBinder asBinder() {
           return this;
       }
       @Override
       protected boolean onTransact(int code, Parcel data, Parcel reply, int flags) throws RemoteException {
           switch (code) {
               // 获取binder描述符
               case INTERFACE_TRANSACTION:
                   reply.writeString(IActivityManager.DESCRIPTOR);
                   return true;
               // 启动activity，从data中反序列化出intent参数后，直接调用子类startActivity方法启动activity。
               case IActivityManager.TRANSACTION_startActivity:
                   data.enforceInterface(IActivityManager.DESCRIPTOR);
                   Intent intent = Intent.CREATOR.createFromParcel(data);
                   int result = this.startActivity(intent);
                   reply.writeNoException();
                   reply.writeInt(result);
                   return true;
           }
           return super.onTransact(code, data, reply, flags);
       }
   }
   

3. 接着，实现Client侧的代理对象：

   public class ActivityManagerProxy implements IActivityManager {
       private IBinder mRemote;
       public ActivityManagerProxy(IBinder remote) {
           mRemote = remote;
       }
       @Override
       public IBinder asBinder() {
           return mRemote;
       }
       @Override
       public int startActivity(Intent intent) throws RemoteException {
           Parcel data = Parcel.obtain();
           Parcel reply = Parcel.obtain();
           int result;
           try {
               // 将intent参数序列化，写入data中
               intent.writeToParcel(data, 0);
               // 调用BinderProxy对象的transact方法，交由Binder驱动处理。
               mRemote.transact(IActivityManager.TRANSACTION_startActivity, data, reply, 0);
               reply.readException();
               // 等待server执行结束后，读取执行结果
               result = reply.readInt();
           } finally {
               data.recycle();
               reply.recycle();
           }
           return result;
       }
   }
   

4. 最后，实现Binder本地对象（IActivityManager接口）：

   public class ActivityManagerService extends ActivityManagerNative {
       @Override
       public int startActivity(Intent intent) throws RemoteException {
           // 启动activity
           return 0;
       }
   }
   

• 写给 Android 应用工程师的 Binder 原理剖析
• Binder学习指南
• Binder设计与实现
• 老罗Binder机制分析系列或Android系统源代码情景分析Binder章节

• 1、启动电源以及系统启动 ：当电源按下时引导芯片从预定义的地方（固化在ROM）开始执行，加载引导程序BootLoader到RAM，然后执行。
• 2、引导程序BootLoader ：BootLoader是在Android系统开始运行前的一个小程序，主要用于把系统OS拉起来并运行。
• 3、Linux内核启动 ：当内核启动时，设置缓存、被保护存储器、计划列表、加载驱动。当其完成系统设置时，会先在系统文件中寻找init.rc文件，并启动init进程。
• 4、init进程启动 ：初始化和启动属性服务，并且启动Zygote进程。
• 5、Zygote进程启动 ：创建JVM并为其注册JNI方法，创建服务器端Socket，启动SystemServer进程。
• 6、SystemServer进程启动 ：启动Binder线程池和SystemServiceManager，并且启动各种系统服务。
• 7、Launcher启动 ：被SystemServer进程启动的AMS会启动Launcher，Launcher启动后会将已安装应用的快捷图标显示到系统桌面上。

• Android系统启动流程之init进程启动
• Android系统启动流程之Zygote进程启动
• Android系统启动流程之SystemServer进程启动
• Android系统启动流程之Launcher进程启动

Intent intent = mActivity.getPackageManager().getLaunchIntentForPackage(packageName);
mActivity.startActivity(intent);   

1. ActivityManagerServices，简称AMS，服务端对象，负责系统中所有Activity的生命周期。
2. ActivityThread，App的真正入口。当开启App之后，调用main()开始运行，开启消息循环队列，这就是传说的UI线程或者叫主线程。与ActivityManagerService一起完成Activity的管理工作。
3. ApplicationThread，用来实现ActivityManagerServie与ActivityThread之间的交互。在ActivityManagerSevice需要管理相关Application中的Activity的生命周期时，通过ApplicationThread的代理对象与ActivityThread通信。
4. ApplicationThreadProxy，是ApplicationThread在服务器端的代理，负责和客户端的ApplicationThread通信。AMS就是通过该代理与ActivityThread进行通信的。
5. Instrumentation，每一个应用程序只有一个Instrumetation对象，每个Activity内都有一个对该对象的引用，Instrumentation可以理解为应用进程的管家，ActivityThread要创建或暂停某个Activity时，都需要通过Instrumentation来进行具体的操作。
6. ActivityStack，Activity在AMS的栈管理，用来记录经启动的Activity的先后关系，状态信息等。通过ActivtyStack决定是否需要启动新的进程。
7. ActivityRecord，ActivityStack的管理对象，每个Acivity在AMS对应一个ActivityRecord，来记录Activity状态以及其他的管理信息。其实就是服务器端的Activit对象的映像。
8. TaskRecord，AMS抽象出来的一个“任务”的概念，是记录ActivityRecord的栈，一个“Task”包含若干个ActivityRecord。AMS用TaskRecord确保Activity启动和退出的顺序。如果你清楚Activity的4种launchMode，那么对这概念应该不陌生。

• Instrumentation: 监控应用与系统相关的交互行为。
• AMS：组件管理调度中心，什么都不干，但是什么都管。
• ActivityStarter：Activity启动的控制器，处理Intent与Flag对Activity启动的影响，具体说来有：1 寻找符合启动条件的Activity，如果有多个，让用户选择；2 校验启动参数的合法性；3 返回int参数，代表Activity是否启动成功。
• ActivityStackSupervisior：这个类的作用你从它的名字就可以看出来，它用来管理任务栈。
• ActivityStack：用来管理任务栈里的Activity。
• ActivityThread：最终干活的人，Activity、Service、BroadcastReceiver的启动、切换、调度等各种操作都在这个类里完成。

• 调用者进程，如果是在桌面启动应用就是Launcher应用进程。
• ActivityManagerService等待所在的System Server进程，该进程主要运行着系统服务组件。
• Zygote进程，该进程主要用来fork新进程。
• 新启动的应用进程，该进程就是用来承载应用运行的进程了，它也是应用的主线程（新创建的进程就是主线程），处理组件生命周期、界面绘制等相关事情。

• 1、点击桌面应用图标，Launcher进程将启动Activity（MainActivity）的请求以Binder的方式发送给了AMS。
• 2、AMS接收到启动请求后，交付ActivityStarter处理Intent和Flag等信息，然后再交给ActivityStackSupervisior/ActivityStack 处理Activity进栈相关流程。同时以Socket方式请求Zygote进程fork新进程。
• 3、Zygote接收到新进程创建请求后fork出新进程。
• 4、在新进程里创建ActivityThread对象，新创建的进程就是应用的主线程，在主线程里开启Looper消息循环，开始处理创建Activity。
• 5、ActivityThread利用ClassLoader去加载Activity、创建Activity实例，并回调Activity的onCreate()方法，这样便完成了Activity的启动。

• 继承BroadcastReceiver，重写onReceive()方法。
• 通过Binder机制向ActivityManagerService注册广播。
• 通过Binder机制向ActivityMangerService发送广播。
• ActivityManagerService查找符合相应条件的广播（IntentFilter/Permission）的BroadcastReceiver，将广播发送到BroadcastReceiver所在的消息队列中。
• BroadcastReceiver所在消息队列拿到此广播后，回调它的onReceive()方法。

1. Window用于显示View和接收各种事件，Window有三种型：应用Window(每个Activity对应一个Window)、子Widow(不能单独存在，附属于特定Window)、系统window(toast和状态栏)
2. Window分层级，应用Window在1-99、子Window在1000-1999、系统Window在2000-2999.WindowManager提供了增改View的三个功能。
3. Window是个抽象概念：每一个Window对应着一个ViewRootImpl，Window通过ViewRootImpl来和View建立联系，View是Window存在的实体，只能通过WindowManager来访问Window。
4. WindowManager的实现是WindowManagerImpl，其再委托WindowManagerGlobal来对Window进行操作，其中有四种List分别储存对应的View、ViewRootImpl、WindowManger.LayoutParams和正在被删除的View。
5. Window的实体是存在于远端的WindowMangerService，所以增删改Window在本端是修改上面的几个List然后通过ViewRootImpl重绘View，通过WindowSession(每Window个对应一个)在远端修改Window。
6. Activity创建Window：Activity会在attach()中创建Window并设置其回调(onAttachedToWindow()、dispatchTouchEvent())，Activity的Window是由Policy类创建PhoneWindow实现的。然后通过Activity#setContentView()调用PhoneWindow的setContentView。

• 复制APK到/data/app目录下，解压并扫描安装包。
• 资源管理器解析APK里的资源文件。
• 解析AndroidManifest文件，并在/data/data/目录下创建对应的应用数据目录。
• 然后对dex文件进行优化，并保存在dalvik-cache目录下。
• 将AndroidManifest文件解析出的四大组件信息注册到PackageManagerService中。
• 安装完成后，发送广播。

• 通过AAPT工具进行资源文件（包括AndroidManifest.xml、布局文件、各种XML资源等）的打包，生成R.java文件。
• 通过AIDL工具处理AIDL文件，生成相应的Java文件。
• 通过Java Compiler编译R.java、Java接口文件、Java源文件，生成.class文件。
• 通过dex命令，将.class文件和第三方库中的.class文件处理生成classes.dex，该过程主要完成Java字节码转换成Dalvik字节码，压缩常量池以及清除冗余信息等工作。
• 通过ApkBuilder工具将资源文件、DEX文件打包生成APK文件。
• 通过Jarsigner工具，利用KeyStore对生成的APK文件进行签名。
• 如果是正式版的APK，还会利用ZipAlign工具进行对齐处理，对齐的过程就是将APK文件中所有的资源文件距离文件的起始距位置都偏移4字节的整数倍，这样通过内存映射访问APK文件的速度会更快，并且会减少其在设备上运行时的内存占用。

• dex：最终生成的Dalvik字节码。
• res：存放资源文件的目录。
• asserts：额外建立的资源文件夹。
• lib：如果存在的话，存放的是ndk编出来的so库。
• META-INF：存放签名信息

• androidManifest：程序的全局清单配置文件。
• resources.arsc：编译后的二进制资源文件。

• 确保Apk来源的真实性。
• 确保Apk没有被第三方篡改。

• 补充：
  • 散列算法的基础原理：将数据（如一段文字）运算变为另一固定长度值。
  • SHA-1：在密码学中，SHA-1（安全散列算法1）是一种加密散列函数，它接受输入并产生一个160 位（20 字节）散列值，称为消息摘要 。
  • MD5：MD5消息摘要算法（英语：MD5 Message-Digest Algorithm），一种被广泛使用的密码散列函数，可以产生出一个128位（16字节）的散列值（hash value），用于确保信息传输完整一致。
  • SHA-2：名称来自于安全散列算法2（英语：Secure Hash Algorithm 2）的缩写，一种密码散列函数算法标准，其下又可再分为六个不同的算法标准，包括了：SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。
• 特征：
  • 唯一性
  • 固定长度：比较常用的Hash算法有MD5和SHA1，MD5的长度是128拉，SHA1的长度是160位。
  • 不可逆性

1. 计算摘要：通过Hash算法提取出原始数据的摘要。
2. 计算签名：再通过基于密钥（私钥）的非对称加密算法对提取出的摘要进行加密，加密后的数据就是签名信息。
3. 写入签名：将签名信息写入原始数据的签名区块内。

1. 首先用同样的Hash算法从接收到的数据中提取出摘要。
2. 解密签名：使用发送方的公钥对数字签名进行解密，解密出原始摘要。
3. 比较摘要：如果解密后的数据和提取的摘要一致，则校验通过；如果数据被第三方篡改过，解密后的数据和摘要将会不一致，则校验不通过。

• 证书颁发机构
• 证书颁发机构签名
• 证书绑定的服务器域名
• 证书版本、有效期
• 签名使用的加密算法（非对称算法，如RSA）
• 公钥等

• DER（Distinguished Encoding Rules）：二进制格式，所有类型的证书和私钥都可以存储为der格式。
• PEM（Privacy Enhanced Mail）：base64编码，内容以-----BEGIN xxx----- 开头，以-----END xxx----- 结尾。

1. 解析出 CERT.RSA 文件中的证书、公钥，解密 CERT.RSA 中的加密数据。
2. 解密结果和 CERT.SF 的指纹进行对比，保证 CERT.SF 没有被篡改。
3. 而 CERT.SF 中的内容再和 MANIFEST.MF 指纹对比，保证 MANIFEST.MF 文件没有被篡改。
4. MANIFEST.MF 中的内容和 APK 所有文件指纹逐一对比，保证 APK 没有被篡改。

• JVM:.java -> javac -> .class -> jar -> .jar
• 架构: 堆和栈的架构.
• DVM:.java -> javac -> .class -> dx.bat -> .dex
• 架构: 寄存器(cpu上的一块高速缓存)

• ART优点：
  • 系统性能的显著提升。
  • 应用启动更快、运行更快、体验更流畅、触感反馈更及时。
  • 更长的电池续航能力。
  • 支持更低的硬件。
• ART缺点：
  • 更大的存储空间占用，可能会增加10%-20%。
  • 更长的应用安装时间。

• 在Java中声明Native方法（即需要调用的本地方法）
• 编译上述 Java源文件javac（得到 .class文件） 3。 通过 javah 命令导出JNI的头文件（.h文件）
• 使用 Java需要交互的本地代码 实现在 Java中声明的Native方法
• 编译.so库文件
• 通过Java命令执行 Java程序，最终实现Java调用本地代码

• 从classpath路径下搜索ClassMethod这个类，并返回该类的Class对象。
• 获取类的默认构造方法ID。
• 查找实例方法的ID。
• 创建该类的实例。
• 调用对象的实例方法。

  JNIEXPORT void JNICALL Java_com_study_jnilearn_AccessMethod_callJavaInstaceMethod  
  (JNIEnv *env, jclass cls)  
  {  
    jclass clazz = NULL;  
    jobject jobj = NULL;  
    jmethodID mid_construct = NULL;  
    jmethodID mid_instance = NULL;  
    jstring str_arg = NULL;  
    // 1、从classpath路径下搜索ClassMethod这个类，并返回该类的Class对象  
    clazz = (*env)->FindClass(env, "com/study/jnilearn/ClassMethod");  
    if (clazz == NULL) {  
        printf("找不到'com.study.jnilearn.ClassMethod'这个类");  
        return;  
    }  
    // 2、获取类的默认构造方法ID  
    mid_construct = (*env)->GetMethodID(env,clazz, "<init>","()V");  
    if (mid_construct == NULL) {  
        printf("找不到默认的构造方法");  
        return;  
    }  
    // 3、查找实例方法的ID  
    mid_instance = (*env)->GetMethodID(env, clazz, "callInstanceMethod", "(Ljava/lang/String;I)V");  
    if (mid_instance == NULL) {  
        return;  
    }  
    // 4、创建该类的实例  
    jobj = (*env)->NewObject(env,clazz,mid_construct);  
    if (jobj == NULL) {  
        printf("在com.study.jnilearn.ClassMethod类中找不到callInstanceMethod方法");  
        return;  
    }  
    // 5、调用对象的实例方法  
    str_arg = (*env)->NewStringUTF(env,"我是实例方法");  
    (*env)->CallVoidMethod(env,jobj,mid_instance,str_arg,200);  
    // 删除局部引用  
    (*env)->DeleteLocalRef(env,clazz);  
    (*env)->DeleteLocalRef(env,jobj);  
    (*env)->DeleteLocalRef(env,str_arg);  
  }