让我们进入init.cpp来看看，首先看main:/Volumes/aosp/WORKING_DIRECTORY/system/core/init/init.cpp

接着上篇的雪崩检测，回顾下LongLinkTaskManager::__RunOnStartTask：/mars-master/mars/stn/src/longlink_task_manager.cc

接力上篇的上层分析，我们这次深入到底层的mars内部来看看。他在另外一个工程mars中。我们打开它，直接先看初始化，在上层的MarsServiceNative的OnCreate中调用了Mars.init(getApplicationContext(), new Handler(Looper.getMainLooper()));

承接上文在looper中会在一开始就创建一个MessageQueue，并且在loop中每次都会从其中取出一个message处理。那么我们就来看看这个MessageQueue：

本来是不想写这篇文章的，但是很早以前看过的东西容易遗忘，希望还是给自己一个记录吧，另外此篇希望能够写的深入一些。looper是什么就不介绍了吧，一个线程的消息泵，handler是消息的操作者，messagequeue是消息队列。我们从源头开始看起，activity里的主ui线程就是ActivityThread mMainThread。这个ActivityThread的ma...

read_thread这个最关键的读取线程中，逐步跟踪，可以明确stream_component_open---> decoder_start---> video_thread--->ffplay_video_thread。这个调用过程，在解码开始后的异步解码线程中，调用的是ffplay_video_thread。具体可见续1。这个函数是解码处理视频的核心：

初始化的过程上一篇其实并未完全分析完，这回接着来。java层的initPlayer函数中，最后还有native_setup的调用，走的是c层的IjkMediaPlayer_native_setup。来看看他干了什么吧：

本来这个过程我是不大想写初始化的过程，觉得网上已经有不少文章来分析了。但是在前面的整个分析过程中，暴露了自己对一些问题理解还不够透彻，因此有必要做一次。首先是java层：

在prepare的stream_open过程中，不仅会启动read_thread，而且会启动video_refresh_thread。今天就来看看这个video_refresh_thread干了什么。

这章要简单分析下ijkplayer是如何从文件或网络读取数据源的。还是read_thread函数中的关键点avformat_open_input函数：

上文中说到在read_thread线程中有个关键函数：avformat_open_input（utils.c），应当是读取视频文件的，这个函数属于ffmpeg层。这回进入到其中去看下：

ijkplayer现在比较流行，因为工作关系，接触了他，现在做个简单的分析记录吧。我这里直接跳过java层代码，进入c层，因为大多数的工作都是通过jni调用到c层来完成的，java层的内容并不是主体功能。

承接上文，从getService开始，要开始走binder的通讯机制了。首先是上文的java层 /frameworks/base/core/java/android/os/ServiceManagerNative.java:

承接上篇，serviceManager是怎么被调用的呢？如何为app提供服务支持？怎么衔接的？。这次我打算从最上层开始逐步把脉络屡清楚。首先，我们在写app的时候需要使用AudioManager这类东西的时候，都要调用context.getSystemService(Context.AUDIO_SERVICE);获取服务。逐层看下代码：

继续上篇的文，这篇打算进入到android的内核世界，真正接触到binder。binder是android内部的一个机制，通过设备驱动的协助能够起到进程间通讯的(ipc)的作用。那么binder的设备驱动的源码在/drivers/staging/android/binder.c这个路径下。先看下定义：

前一阵子在忙项目，没什么更新，这次开始写点android源码内部的东西分析下。以6.0.1_r10版本android源码为例。servicemanager是android服务管理，非常基础的组件之一，分析他的目的是能够深入看到binder的一些处理方式。在开始前先说下阅读源码或者非常复杂代码的方式，我的方式是层级进入，一层掌握脉络之后如果感兴趣...