最近公司的活一直很多时间也很紧，加上忙搬家所以好久没有更新了。。。今晚刚刚好项目做得差不多，忙里偷闲更新一下
之前一直说要做一次ExoPlayer（这里会用ExoPlayer2作为例子）的源码分析,想了一下，还是先介绍一下ExoPlayer的代码结构比较合适，原因有以下几点，也算是最近的一些感悟和大家分享：
- 1.其实很多文章，关于框架的源码分析都太过深入，其实本质就变成了一次代码跟踪，这样不是不好，毕竟看代码也是能力的一种。但是更多的情况下我们看代码，尤其是一些优秀的第三方框架，我们不是希望把代码100%背下来，而是学习第三方框架源码的优秀之处，看过一次源码，要至少明白他的优点在哪，精髓在哪。比如看完Retrofit，我们体会到了这个框架的怎么进行解耦，怎么运用注解，看完Volley，我们明白了一个短小精悍的网络库怎么做多线程，怎么运用Cache，怎么进行request的分发等等等等。所以我自己的感觉是需要更多的从整体去理解框架会更有帮助一些。
- 2.很多朋友在学习的时候都太着急，一个框架还没用熟就老是急着想做“源码分析”。我个人的观点先摆出来，学习一个框架的源代码，一定要带着问题去看，不能盲目的进行代码跟踪，那样一点意义都没有。要带着问题，从深度再慢慢扩展到广度，这样循序渐进的过程才比较科学。有心的朋友可以试着去谷歌上搜索RxJava source code anaylysis和RxJava源码分析，你可以发现，英文的RxJava源码分析几乎没人做，而中文的文章却一大堆。仔细想想，这个原因到底是什么？其实就是国内的应用用户太多，我们国内的开发者需要对第三方库(俗称轮子)做各种各样的定制（customisation),那么就免不了对框架进行源码的解析。而国外的应用用户量级与国内压根没法比，没有各式各样“苛刻”的用户要求，自然没有人去做什么源码分析。还是那个观点，需要带着问题去看框架，如果没问题，给自己找一个问题。
所以在开始一次源码的结构分析之前，大家先问问自己，我使用过这个ExoPlayer没有？使用的深度如何？是否只是按照doc做了一个sample，doc上面初始化ExoPlayer的参数和各种构件都代表什么意思？对ExoPlayer的使用上有没有什么疑惑？
说了这么多废话，希望也不要打击大家看源码的热情，只不过学的勤，不如学的巧，掌握更科学的方法可以事半功倍，那何乐而不为。学习这件事本身也是需要耐得住性子。。。so。。。
不要紧张，咱们来段freestyle压压惊，开始分析了！
首先ExoPlayer的入口自然是ExoPlayerImplInternal了，在创建ExoPlayer对象之后，ExoPlayer会通过handler，根据当前自身的状态去不停发放消息，然后自己同时接受这些消息。
比如当我们调用ExoPlayer的prepare()方法时，其实我们就用ExoPlayer的handler去发送了一条消息MSG_PREPARE。
发送之后，ExoPlayerImplInternal对象自己又接受它，再去处理这条消息。
最后再叫ExoPlayer所有的MediaSource进行准备prepare。
又或者再看看MSG_DO_SOME_WORK这个消息发放出去之后，ExoPlayer做了什么
大家知道在创建ExoPlayer的时候我们需要传入一个renderer数组，包括Video，Audio或者字幕的TextRenderer，他们每个都负责渲染Render自己负责的那一部分，在ExoPlayer里面就是这么一个简单的for循环，搞定。
在一个dosomeWork()结束之后，通过handler再发一次MSG_DO_SOME_WORK
大家可以自己观察一下其他MSG是用来干嘛的，其实稍微看看就可以发现，都是和Playback相关的一些操作，比如seek，pause，release等等。
那么其实到现在为止，ExoPlayer从整体上是怎么工作，它的大概结构就很清楚了，用一个图来表达一下。
user在创建ExoPlayer之后，调用任何的方法都是发送一条message给他的handler，根据消息的不通，ExoPlayer把消息分发给不同的component，比如prepare就会把消息分发给MediaResource，do_some_work会把消息分发给Render，根据当前的进度去渲染视频，音频和字幕。在处理完一个消息之后，会根据当前状态发送下一个消息给ExoPlayerImplInternnal。在一个不停止的情况下，消息队列一般都是:
1.MSG_PREPARE
2.MSG_PERIOD_PREPARED
3.MSG_DO_SOME_WORK........不停的do some work...
整个ExoPlayer就是靠Handler来进行状态维护的，不光只是ExoPlayerImplInternal这个类，其他的很多类比如LoadControl啊等等都是靠Handler来做状态维护，和消息发放，尤其是ExoPlayer的事件分放部分，都需要用户自己传入一个handler。可能这对初次使用的同学会造成一定的困扰。
不过在理解了ExoPlayer的大概结构之后，相信为何需要这个Handler的原因大家应该都能理解了。
ExoPlayer本身就是利用handler进行事件分发，和自身的状态控制，任何用户的操作，在ExoPlayer内部的实现都是会变成一个handler能处理的Message，再根据message的内容，ExoPlayer会让不同的构件进行相应的操作，再根据操作的结果发下一个消息。
这次的分析就先到此为止，下次我会开始分析MediaResource部分，也就是我们每次调用prepare()方法之后，我们到底在prepare(准备)什么？
晚安！
