❶ Spark源码分析之SparkSubmit的流程
本文主要对SparkSubmit的任务提交流程源码进行分析。 Spark源码版本为2.3.1。
首先阅读一下启动脚本，看看首先加载的是哪个类，我们看一下 spark-submit 启动脚本中的具体内容。
可以看到这里加载的类是org.apache.spark.deploy.SparkSubmit，并且把启动相关的参数也带过去了。下面我们跟一下源码看看整个流程是如何运作的...
SparkSubmit的main方法如下
这里我们由于我们是提交作业，所有会走上面的submit(appArgs, uninitLog)方法
可以看到submit方法首先会准备任务提交的环境，调用了prepareSubmitEnvironment，该方法会返回四元组，该方法中会调用doPrepareSubmitEnvironment，这里我们重点注意 childMainClass类具体是什么 ，因为这里涉及到后面启动我们主类的过程。
以下是doPrepareSubmitEnvironment方法的源码...
可以看到该方法首先是解析相关的参数，如jar包，mainClass的全限定名，系统配置，校验一些参数，等等，之后的关键点就是根据我们 deploy-mode 参数来判断是如何运行我们的mainClass，这里主要是通过childMainClass这个参数来决定下一步首先启动哪个类。
childMainClass根据部署模型有不同的值:
之后该方法会把准备好的四元组返回，我们接着看之前的submit方法
可以看到这里最终会调用doRunMain()方法去进行下一步。
doRunMain的实现如下...
doRunMain方法中会判断是否需要一个代理用户，然后无论需不需要都会执行runMain方法，我们接下来看看runMain方法是如何实现的。
这里我们只假设以集群模式启动，首先会加载类，将我们的childMainClass加载为字节码对象mainClass ，然后将mainClass 映射成SparkApplication对象，因为我们以集群模式启动，那么上一步返回四元组中的childMainClass的参数为ClientApp的全限定名，而这里会调用app实例的start方法因此，这里最终调用的是ClientApp的start方法。
ClientApp的start方法如下...
可以看到这里和之前我们的master启动流程有些相似。
可以参考我上一篇文章 Spark源码分析之Master的启动流程 对这一流程加深理解。
首先是准备rpcEnv环境，之后通过master的地址获取masterEndpoints端点相关信息，因为这里运行start方法时会将之前配置的相关参数都传进来，之后就会通过rpcEnv注册相关clientEndPoint端点信息，同时需要注意，这里会把masterEndpoints端点信息也作为构造ClientEndpoint端点的参数，也就是说这个ClientEndpoint会和masterEndpoints通信。
而在我上一篇文章中说过，只要是setupEndpoint方法被调用，一定会调用相关端点的的onStart方法，而这会调用clientEndPoint的onStart方法。
ClientEndPoint类中的onStart方法会匹配launch事件。源码如下
onStart中匹配我们的launch的过程，这个过程是启动driverWrapper的过程，可以看到上面源码中封装了mainClass ，该参数对应DriverWrapper类的全限定名，之后将mainClass封装到command中，然后封装到driverDescription中，向Master申请启动Driver。
这个过程会向Mster发送消息，是通过rpcEnv来实现发射消息的，而这里就涉及到outbox信箱，会调用postToOutbox方法，向outbox信箱中添加消息，然后通过TransportClient的send或sendRpc方法发送消息。发件箱以及发送过程是在同一个线程中进行。
而细心的同学会注意到这里调用的方法名为SendToMasterAndForwardReply，见名之意，发送消息到master并且期待回应。
下面是rpcEnv来实现向远端发送消息的一个调用流程，最终会通过netty中的TransportClient来写出。
之后，Master端会触发receiveAndReply函数,匹配RequestSubmitDriver样例类，完成模式匹配执行后续流程。
可以看到这里首先将Driver信息封装成DriverInfo，然后添加待调度列表waitingDrivers中，然后调用通用的schele函数。
由于waitingDrivers不为空，则会走LaunchDriver的流程，当前的application申请资源，这时会向worker发送消息，触发Worker的receive方法。
Worker的receive方法中，当Worker遇到LaunchDriver指令时，创建并启动一个DriverRunner，DriverRunner启动一个线程，异步的处理Driver启动工作。这里说启动的Driver就是刚才说的org.apache.spark.deploy.worker.DriverWrapper
可以看到上面在DriverRunner中是开辟线程异步的处理Driver启动工作，不会阻塞主进程的执行，而prepareAndRunDriver方法中最终调用 runDriver..
runDriver中主要先做了一些初始化工作，接着就开始启动driver了。
上述Driver启动工作主要分为以下几步：
下面我们直接看DriverWrapper的实现
DriverWrapper，会创建了一个RpcEndpoint与RpcEnv，RpcEndpoint为WorkerWatcher，主要目的为监控Worker节点是否正常，如果出现异常就直接退出，然后当前的ClassLoader加载userJar，同时执行userMainClass，在执行用户的main方法后关闭workerWatcher。
以上就是SparkSubmit的流程，下一篇我会对SparkContext的源码进行解析。
欢迎关注...
❷ android 中的“子线程”解析
Android 中线程可分为 主线程 和 子线程 两类，其中主线程也就是 UI线程 ，它的主要这作用就是运行四大组件、处理界面交互。子线程则主要是处理耗时任务，也是我们要重点分析的。
首先 Java 中的各种线程在 Android 里是通用的，Android 特有的线程形态也是基于 Java 的实现的，所以有必要先简单的了解下 Java 中的线程，本文主要包括以下内容：
在 Java 中要创建子线程可以直接继承 Thread 类，重写 run() 方法：
或者实现 Runnable 接口，然后用Thread执行Runnable，这种方式比较常用：
简单的总结下：
Callable 和 Runnable 类似，都可以用来处理具体的耗时任务逻辑的，但是但具体的差别在哪里呢？看一个小例子：
定义 MyCallable 实现了 Callable 接口，和之前 Runnable 的 run() 方法对比下， call() 方法是有返回值的哦，泛型就是返回值的类型：
一般会通过线程池来执行 Callable （线程池相关内容后边会讲到），执行结果就是一个 Future 对象：
可以看到，通过线程池执行 MyCallable 对象返回了一个 Future 对象，取出执行结果。
Future 是一个接口，从其内部的方法可以看出它提供了取消任务（有坑！！！）、判断任务是否完成、获取任务结果的功能：
Future 接口有一个 FutureTask 实现类，同时 FutureTask 也实现了 Runnable 接口，并提供了两个构造函数：
用 FutureTask 一个参数的构造函数来改造下上边的例子：
FutureTask 内部有一个 done() 方法，代表 Callable 中的任务已经结束，可以用来获取执行结果：
所以 Future + Callable 的组合可以更方便的获取子线程任务的执行结果，更好的控制任务的执行，主要的用法先说这么多了，其实 AsyncTask 内部也是类似的实现！
注意， Future 并不能取消掉运行中的任务，这点在后边的 AsyncTask 解析中有提到。
Java 中线程池的具体的实现类是 ThreadPoolExecutor ，继承了 Executor 接口，这些线程池在 Android 中也是通用的。使用线程池的好处：
常用的构造函数如下：
一个常规线程池可以按照如下方式来实现：
执行任务：
基于 ThreadPoolExecutor ，系统扩展了几类具有新特性的线程池：
线程池可以通过 execute() 、 submit() 方法开始执行任务，主要差别从方法的声明就可以看出，由于 submit() 有返回值，可以方便得到任务的执行结果：
要关闭线程池可以使用如下方法：
IntentService 是 Android 中一种特殊的 Service，可用于执行后台耗时任务，任务结束时会自动停止，由于属于系统的四大组件之一，相比一般线程具有较高的优先级，不容易被杀死。用法和普通 Service 基本一致，只需要在 onHandleIntent() 中处理耗时任务即可：
至于 HandlerThread，它是 IntentService 内部实现的重要部分，细节内容会在 IntentService 源码中说到。
IntentService 首次创建被启动的时候其生命周期方法 onCreate() 会先被调用，所以我们从这个方法开始分析：
这里出现了 HandlerThread 和 ServiceHandler 两个类，先搞明白它们的作用，以便后续的分析。
首先看 HandlerThread 的核心实现：
首先它继承了 Thread 类，可以当做子线程来使用，并在 run() 方法中创建了一个消息循环系统、开启消息循环。
ServiceHandler 是 IntentService 的内部类，继承了 Handler，具体内容后续分析：
现在回过头来看 onCreate() 方法主要是一些初始化的操作， 首先创建了一个 thread 对象，并启动线程，然后用其内部的 Looper 对象 创建一个 mServiceHandler 对象，将子线程的 Looper 和 ServiceHandler 建立了绑定关系，这样就可以使用 mServiceHandler 将消息发送到子线程去处理了。
生命周期方法 onStartCommand() 方法会在 IntentService 每次被启动时调用，一般会这里处理启动 IntentService 传递 Intent 解析携带的数据：
又调用了 start() 方法：
就是用 mServiceHandler 发送了一条包含 startId 和 intent 的消息，消息的发送还是在主线程进行的，接下来消息的接收、处理就是在子线程进行的：
当接收到消息时，通过 onHandleIntent() 方法在子线程处理 intent 对象， onHandleIntent() 方法执行结束后，通过 stopSelf(msg.arg1) 等待所有消息处理完毕后终止服务。
为什么消息的处理是在子线程呢？这里涉及到 Handler 的内部消息机制，简单的说，因为 ServiceHandler 使用的 Looper 对象就是在 HandlerThread 这个子线程类里创建的，并通过 Looper.loop() 开启消息循环，不断从消息队列（单链表）中取出消息，并执行，截取 loop() 的部分源码：
dispatchMessage() 方法间接会调用 handleMessage() 方法，所以最终 onHandleIntent() 就在子线程中划线执行了，即 HandlerThread 的 run() 方法。
这就是 IntentService 实现的核心，通过 HandlerThread + Hanlder 把启动 IntentService 的 Intent 从主线程切换到子线程，实现让 Service 可以处理耗时任务的功能！
AsyncTask 是 Android 中轻量级的异步任务抽象类，它的内部主要由线程池以及 Handler 实现，在线程池中执行耗时任务并把结果通过 Handler 机制中转到主线程以实现UI操作。典型的用法如下：
从 Android3.0 开始，AsyncTask 默认是串行执行的：
如果需要并行执行可以这么做：
AsyncTask 的源码不多，还是比较容易理解的。根据上边的用法，可以从 execute() 方法开始我们的分析：
看到 @MainThread 注解了吗？所以 execute() 方法需要在主线程执行哦！
进而又调用了 executeOnExecutor() ：
可以看到，当任务正在执行或者已经完成，如果又被执行会抛出异常！回调方法 onPreExecute() 最先被执行了。
传入的 sDefaultExecutor 参数，是一个自定义的串行线程池对象，所有任务在该线程池中排队执行：
可以看到 SerialExecutor 线程池仅用于任务的排队， THREAD_POOL_EXECUTOR 线程池才是用于执行真正的任务，就是我们线程池部分讲到的 ThreadPoolExecutor ：
再回到 executeOnExecutor() 方法中，那么 exec.execute(mFuture) 就是触发线程池开始执行任务的操作了。
那 executeOnExecutor() 方法中的 mWorker 是什么？ mFuture 是什么？答案在 AsyncTask 的构造函数中：
原来 mWorker 是一个 Callable 对象， mFuture 是一个 FutureTask 对象，继承了 Runnable 接口。所以 mWorker 的 call() 方法会在 mFuture 的 run() 方法中执行，所以 mWorker 的 call() 方法在线程池得到执行！
同时 doInBackground() 方法就在 call() 中方法，所以我们自定义的耗时任务逻辑得到执行，不就是我们第二部分讲的那一套吗！
doInBackground() 的返回值会传递给 postResult() 方法：
就是通过 Handler 将最终的耗时任务结果从子线程发送到主线程，具体的过程是这样的， getHandler() 得到的就是 AsyncTask 构造函数中初始化的 mHandler ， mHander 又是通过 getMainHandler() 赋值的：
可以在看到 sHandler 是一个 InternalHandler 类对象：
所以 getHandler() 就是在得到在主线程创建的 InternalHandler 对象，所以
就可以完成耗时任务结果从子线程到主线程的切换，进而可以进行相关UI操作了。
当消息是 MESSAGE_POST_RESULT 时，代表任务执行完成， finish() 方法被调用：
如果任务没有被取消的话执行 onPostExecute() ，否则执行 onCancelled() 。
如果消息是 MESSAGE_POST_PROGRESS ， onProgressUpdate() 方法被执行，根据之前的用法可以 onProgressUpdate() 的执行需要我们手动调用 publishProgress() 方法，就是通过 Handler 来发送进度数据：
进行中的任务如何取消呢？AsyncTask 提供了一个 cancel(boolean mayInterruptIfRunning) ，参数代表是否中断正在执行的线程任务，但是呢并不靠谱， cancel() 的方法注释中有这么一段：
大致意思就是调用 cancel() 方法后， onCancelled(Object) 回调方法会在 doInBackground() 之后被执行而 onPostExecute() 将不会被执行，同时你应该 doInBackground() 回调方法中通过 isCancelled() 来检查任务是否已取消，进而去终止任务的执行！
所以只能自己动手了：
AsyncTask 整体的实现流程就这些了，源码是最好的老师，自己跟着源码走一遍有些问题可能就豁然开朗了！
❸ Android源码追踪—android:onClick
之前对源码的阅读，总是用时一通乱七八糟的跳转，以学会使用为目的；过了一段时间，就忘记了，因此打算将一些源码的阅读经历记录下来，也通过敲一遍的过程，加深理解。
最开始，用一个比较简单的例子来小试牛刀吧
对于View（Button、TextView等）的点击事件，常用的写法是通过 findViewById 获取View的实例，然后通过 setOnClickListener 设置监听事件，比如我们有如下Button控件。
设置点击事件（假设在Activity中）
但是还有一种写法是在xml布局中通过android:onClick属性直接指定点击执行的函数。
【思考】
首先我们知道诸如 android:xxx 之类的属性是会在某个attrs文件中定义的，此处的 android:onClick 是View的属性，定义在如下文件中。
在View的构造函数中，会解析出此属性的值。
看这里， 如果变量handlerName不为空，就会为此View设置点击事件了 ，这个handlerName就是onClick属性的值doSubmit，但这个点击事件，并不是我们所熟悉的OnClickListener。
进一步看看这个 DeclaredOnClickListener 类
DeclaredOnClickListener 实现了 OnClickListener ，其中重点是参数 mResolvedMethod 和 mResolvedContext 。
在onClick事件中最终通过反射 mResolvedMethod.invoke(mResolvedContext, v); 执行了doSubmit方法。
doSubmit的访问权限是否可以设置为private呢？
答案：不可以，因为源码中没有调用 mMethod.setAccessible(true); 注入所有修饰符。
其实在onClick属性的注释中就已经说明了。