让我们进入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()));

本来是想直接深入到mars的核心层去看的，但是发现其实上面的samples部分还有好些没有分析到，因此回来继续分析。ConversationActivity这个类中实际上还做了很多的工作，在onCreate中：

微信已经开源了mars，但是市面上相关的文章较少，即使有也是多在于使用xlog等这些，那么这次我希望能够从stn这个直接用于im底层通讯的部分进行个分析。为了能分析的全面些，我们从samples开始。首先明确下，微信用了google的开源协议protobuf库，来代替json和xml。至于为何使用这个，原因还在于效率和传输量上，效率上他...

承接上文在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的一些处理方式。在开始前先说下阅读源码或者非常复杂代码的方式，我的方式是层级进入，一层掌握脉络之后如果感兴趣...

可以看到几点信息：1.static方法，使用起来很方便，屏蔽了大量的参数，让他们在后面逐步加入；2.整个Picasso采用单例模式，Picasso的设计就是承担很多工作的引擎，因此占用资源较多，没有必要在一个app中出现多个，也为了节省资源和提高效率，采用了单例模式；3.创建单例的实例的时候，new出了Builder，并传入context，...

volley作为google出品的工具还是非常不错的，今天整理一下对他的源码分析，从中能够学到一些。借用网络上的图来表示下请求流程图及类关系图：类关系图：