1.Handler 的源码基本使用、常见问题的分析源码解析以及运行机制源码讲解
2.Android Activity Deeplink启动来源获取源码分析
3.[Android 消息机制]—— Handler 机制详解
4.❤️ Android 源码解读-从setContentView深入了解 Window|Activity|View❤️
5.Android中View的创建过程
6.ContentProvider 源码深入解析

Handler 的基本使用、常见问题的源码源码解析以及运行机制源码讲解

       Handler 是Android中处理异步操作的关键组件。它主要有两种使用方式：sendMessage() 和post()。分析sendMessage() 有三种实现途径，源码包括创建Handler对象、分析mycat源码是什么创建Message对象并发送，源码以及接收和处理消息。分析post() 则是源码通过将Runnable对象放入消息队列，由主线程的分析Looper处理。

       深入理解Handler，源码我们需要关注常见问题。分析比如在主线程和子线程创建Handler的源码区别：主线程创建时，由于ActivityThread初始化过程自动设置了Looper，分析而子线程创建则需要手动设置，源码否则会因无法获取主线程Looper而抛异常。更新UI是否必须在主线程，实际上，子线程可以更新，但必须在requestLayout和invalidate操作之间完成，否则可能导致异常。

       创建Handler的两种方式有差异，方式一使用匿名内部类或接口回调，方式二虽简洁但有警告，不推荐，因为其消息处理是视频站APP源码通过Handler的dispatchMessage方法调用接口的handleMessage，而方式一则是直接调用重写的方法。post()方法与sendMessage()的区别在于前者会将Runnable对象封装成Message对象并发送到目标Handler，后者则直接调用目标Handler的dispatchMessage方法。

       创建Message有两种方法，obtain()和obtainMessage()。obtain()会从缓存池获取或创建消息，而obtainMessage()则是传递了Handler对象，可以直接通过message.sendToTarget()发送。不当使用Handler可能导致内存泄漏，通常是由于Handler持有外部类引用，当外部类被销毁时，消息队列中的消息未处理，造成引用循环，从而无法被垃圾回收。

       最后，Handler的运行机制包含四个步骤：初始化主线程Looper和MessageQueue，创建Handler时绑定Looper和队列，发送消息至消息队列，然后由Looper从队列中取出并分发消息，根据不同发送方式调用不同的处理方法。深入研究Handler，有助于更高效地管理Android应用的异步任务和UI更新。

Android Activity Deeplink启动来源获取源码分析

       Deeplink在业务模块中作为外部应用的入口提供，不同跳转类型可能会导致应用提供不一致的服务，通常通过反射调用Activity中的安装源码500错误mReferrer字段获取跳转来源的包名。然而，mReferrer存在被伪造的风险，可能导致业务逻辑出错或经济损失。因此，我们需要深入分析mReferrer的来源，并寻找更为安全的获取方法。

       为了深入了解mReferrer的来源，我们首先使用搜索功能在Activity类中查找mReferrer，发现其在Attach方法中进行赋值。进一步通过断点调试跟踪调用栈，发现Attach方法是由ActivityThread.performLaunchActivity调用的。而performLaunchActivity在调用Attach时，传入的referrer参数实际上是一个ActivityClientRecord对象的referrer属性。深入分析后，发现referrer是在ActivityClientRecord的构造函数中被赋值的。通过进一步的调试发现，ActivityClientRecord的实例化来自于LaunchActivityItem的mReferrer属性。接着，我们分析了mReferrer的来源，发现它最终是由ActivityStarter的setCallingPackage方法注入的。而这个setCallingPackage方法的调用者是ActivityTaskManagerService的startActivity方法，进一步追踪调用链路，我们发现其源头是在App进程中的ActivityTaskManager.getService()方法调用。

       在分析了远程服务Binder调用的过程后，我们发现获取IActivityTaskManager.Stub的excel表格的源码方法是ActivityTaskManager.getService()。这使得我们能够追踪到startActivity方法的调用，进而找到发起Deeplink的应用调用的具体位置。通过这个过程，我们确定了mReferrer实际上是通过Activity的getBasePackageName()方法获取的。

       为了防止包名被伪造，我们注意到ActivityRecord中还包含PID和Uid。通过使用Uid结合包管理器的方法来获取对应的包名，可以避免包名被伪造。通过验证Uid的来源，我们发现Uid实际上是通过Binder.getCallingUid方法获取的，且Binder进程是无法被应用层干涉的，因此Uid是相对安全的。接下来，我们可以通过Uid来置换包名，进一步提高安全性。

       总结，mReferrer容易被伪造，应谨慎使用。通过使用Uid来获取包名，可以提供一种更为安全的获取方式。此过程涉及对源代码的深入分析和调试，作者Chen Long为vivo互联网客户端团队成员。

[Android 消息机制]—— Handler 机制详解

       Android 消息机制的核心在于 Handler 机制，它解决的是主线程访问 UI 和子线程执行耗时操作的矛盾。Handler 提供了一个上层接口，tomcat源码安装教程底层由 MessageQueue 和 Looper 实现。消息机制的核心问题在于为什么只有主线程才能更新 UI。答案在于避免 UI 控件的并发访问导致的不确定性。ThreadLocal 的使用实现了线程间的隔离，让消息在不同线程间传递，实现了线程切换。MessageQueue 通过队列结构管理消息，支持插入和读取，使用单链表结构优化了插入与删除操作。Looper 负责消息循环，不断从 MessageQueue 中获取消息，处理并分发给 Handler。Looper 的构造方法确保了线程与 Looper 的唯一绑定，保证了消息机制的高效运行。Handler 则负责消息的发送与接收，通过 post 和 send 方法实现跨线程的消息传递。消息最终在 Looper 中通过循环处理，由 Handler 的 dispatchMessage 方法进行处理。ThreadLocal 和 Looper 的配合，实现了消息机制中线程切换的关键功能。消息的发送与接收，通过 enqueueMessage 方法在 MessageQueue 中进行，并由 nativeWake 唤醒等待的线程。Handler 机制提供了一种灵活的消息传递方式，但在非主线程中使用时需要妥善管理 Looper 的生命周期，以避免资源泄露和线程阻塞。通过 ActivityThread 的源码可见，每个 App 启动时都会创建一个 Looper，子线程则需要开发者自行创建。Handler 机制在 Android 中提供了线程间高效、安全的消息传递能力，是应用开发中的重要工具。

❤️ Android 源码解读-从setContentView深入了解 Window|Activity|View❤️

       Android系统中，Window、Activity、View之间的关系是紧密相连且相互作用的。了解这三者之间的关系，有助于深入理解Android应用的渲染和交互机制。

       在Android中，通常在创建Activity时会调用`setContentView()`方法，以指定显示的布局资源。这个方法主要作用是将指定的布局添加到一个名为`DecorView`的容器中，并最终将其显示在屏幕上。这一过程涉及到多个组件的交互，下面分步骤解析。

       在`Activity`类中，`setContentView()`方法调用`getWindow()`方法获取`Window`对象，而`Window`对象在`Activity`的`attach()`方法中被初始化。`Window`对象是一个抽象类，其默认实现为`PhoneWindow`，这是Android特定的窗口实现。

       `PhoneWindow`在创建时会通过`setWindowManager()`方法与`WindowManager`进行关联。`WindowManager`是系统级组件，用于管理所有的窗口，包括窗口的创建、更新、删除等操作。`WindowManager`的管理最终由`WindowManagerService`（WMS）执行，这是一个运行在系统进程中的服务。

       在`PhoneWindow`中，`installDecor()`方法会初始化`DecorView`和`mContentParent`。`mContentParent`是一个`ViewGroup`，用于存放`setContentView()`传入的布局。通过`mLayoutInflater`的`inflate()`方法，将指定的布局资源添加到`mContentParent`中。

       `DecorView`是一个特殊的`FrameLayout`，包含了`mContentParent`。在完成布局的添加后，`DecorView`本身并没有直接与`Activity`建立联系，也没有被绘制到屏幕上显示。`DecorView`的绘制和显示发生在`Activity`的`onResume()`方法执行后，这时`Activity`中的内容才真正可见。

       当`Activity`执行到`onCreate()`阶段时，其内容实际上并没有显示在屏幕上，直到执行到`onResume()`阶段，`Activity`的内容才被真正显示。这一过程涉及到`ActivityThread`中的`handleResumeActivity()`方法，该方法会调用`WindowManager`的`addView()`方法，将`DecorView`添加到`WindowManagerService`中，完成`DecorView`的绘制和显示。

       `WindowManagerService`通过`addView()`方法将`DecorView`添加到显示队列中，并且在添加过程中，会创建关键的`ViewRootImpl`对象，进一步管理`DecorView`的布局、测量和绘制。`ViewRootImpl`会调用`mWindowSession`的`addToDisplay()`方法，将`DecorView`添加到真正的显示队列中。

       `mWindowSession`是`WindowManagerGlobal`中的单例对象，其内部实际上是一个`IWindowSession`类型，通过`AIDL`接口与系统进程中的`Session`对象进行通信，最终实现`DecorView`的添加和显示。

       通过`setView()`方法的实现，可以看到除了调用`IWindowSession`进行跨进程添加`View`之外，还会设置输入事件处理。当触屏事件发生时，这些事件首先通过驱动层的优化计算，通过`Socket`跨进程通知`Android Framework`层，最终触屏事件会通过输入管道传送到`DecorView`处理。

       在`DecorView`内部，触屏事件会通过`onProcess`方法传递给`mView`，即`PhoneWindow`中的`DecorView`。最终，事件传递到`PhoneWindow`中的`View.java`实现的`dispatchPointerEvent()`方法，并调用`Window.Callback`的`dispatchTouchEvent(ev)`方法。对于`Activity`来说，`dispatchTouchEvent()`方法最终还是会调用`PhoneWindow`的`superDispatchTouchEvent()`，然后传递给`DecorView`的`superDispatchTouchEvent()`方法，完成事件的分发和处理。

       综上所述，通过`setContentView()`的过程，我们可以清晰地看到`Activity`、`Window`、`View`之间的交互关系。整个过程主要由`PhoneWindow`组件主导，而`Activity`主要负责提供要显示的布局资源，其与屏幕的直接交互则通过`WindowManager`和`WindowManagerService`实现。

Android中View的创建过程

        我们知道在onCreate里面View还是没有测绘完成的。那么什么时候测绘完成了？答案是onResume。

        通过查看源码 我们可以看到在onCreate方法里面调用了getWindow()方法然后在将我们的页面塞到这个window里面。这个window也就是PhonwWindow.

        那PhoneWindow是什么时候被创建的？

        这就引出了Activity的创建流程。

那Activity是怎么被创建的呢？

        由于Activity是一个组件他是由系统使用ActivityThread方法去创建的。

        现在我来分析下：

        先来到ActivityThread类的handleLaunchActivity方法。

        可以看到他去调用了Activity的performCreate方法。

        现在我们终于看到onCreate方法被调用了。

        这里还有个重点，在performLaunchActivity里面去调用Activity的onCreate方法之前还去做了一件很重要的事情，这个事情在第行：调用了Activity的attach方法。

        现在跟到Activity的attach方法：找到了我们一直找的PhoneWindow的创建。

ContentProvider 源码深入解析

       ContentProvider作为Android系统中核心组件之一，用于实现应用间数据共享。其工作流程始于ActivityManagerService启动新进程，此过程由startProcessLocked方法调用Process的start方法实现。ActivityThread的main方法作为整个流程的起点，创建ActivityThread实例后，通过attach方法进行一系列数据操作，开启主线程Looper循环。

       attach方法内部首先调用ActivityManagerService的attachApplication方法，经过attachApplicationLocked和ApplicationThread的bindApplication方法，实现进程间的调用。接着，通过handler发送消息给ActivityThread的handleBindApplication方法，从而创建ContextImpl与Instrumentation对象。

       整个启动过程中，installContentProviders方法起到关键作用，它遍历ProviderInfo列表，通过installProvider进行ContentProvider启动操作，并将启动的ContentProvider发布到AMS中。借助ClassLoader加载ContentProvider，完成对象创建。最终调用localProvider.attachInfo(c, info);方法，实现ContentProvider的onCreate操作，至此，ContentProvider完成启动过程，为其他应用提供访问途径。

       随着ContentProvider的启动，ActivityManager能够访问并利用其提供的接口，实现应用间的数据共享。这一机制简化了跨应用数据访问的复杂性，为Android系统的整体架构提供了高效的数据流通渠道。