threepigs的专栏

SparseArray是Google为了提高性能替换HashMap而推荐使用的容器类，本文从源码的角度来了解一下两种容器的实现原理，从而分析一下其性能对比。HashMap是hash函数+拉链法实现，SparseArray则使用的是有序数组+二分查找实现。HashMap的性能影响主要体现：占用内存过大，插入过程内存动态增长的扩容操作代价，hash冲突时的链表遍历。SparseArray的性能影响

上篇文章我们讲了Fragment的生命周期管理，对Fragment整个运行机制都会比较清楚了，这节我们分析Fragment的View管理。一，Fragment的两种定义方式1，在layout xml里通过fragment标签定义，这种方式定义的fragment是由LayoutInflater在解析xml文件的时候创建。在Activity的onCreate方法里，会通过setContentView方法设置layout id，继而调用LayoutInflater的inflate方法解析xml。LayoutI

之前两篇文章 Fragment本质之生命周期管理 和 Fragment本质之View管理，我们主要介绍了Fragment的整个生命周期管理，对Fragment的基本机制也了解得比较透彻了。这节我们介绍一下Back Stack和事务操作。所有用过Fragment的人对FragmentTransaction应该都不会陌生，这是fragment基本操作的接口。FragmentTransaction名字里带了transaction这个单词，也就意味着他是支持事务操作的，而事务是可以回退的。FragmentTran

Fragment最早引入是在给平板的Android 3.0系统，用来解决Pad上UI的模块化。随后逐渐推广到Phone UI上，3.0之前的版本则通过Support包引入。Fragment本质上是带生命周期管理的View的Wrapper，解耦了Activity和View，一方面Activity可以不用再处理View的逻辑；另一方面View也可以只专注渲染，不用关心Controller逻辑。

Dalvik的指令执行是解释器+JIT的方式，解释器就是虚拟机来对Javac编译出来的字节码，做译码、执行，而不是转化成CPU的指令集，由CPU来做译码，执行。可想而知，解释器的效率是相对较低的，所以出现了JIT(Just In Time)，JIT是将执行次数较多的函数，做即时编译，在运行时刻，编译成本地目标代码，JIT可以看成是解释器的一个补充优化。再之后又出现了Art虚拟机的AOT(Ahead

看art虚拟机也有一段时间了，是时候写点什么出来了。早先看art的时候，发现不是太能理解，所以就恶补了一下dalvik虚拟机，所以有了之前的dalvik系列，等再次回头看art的时候，确实轻松了不少。art从Android L开始正式替换dalvik，成为Android的默认虚拟机，L的art源码和之前KK的差别比较大，网上很多分析ART的文章都是基于KK的art源码。L开始art才走向成熟，

上一篇分析了art虚拟机的启动过程，不过跳过了一个技术点，就是ImageSpace。由之前的分析可知，ClassLinker是用来加载类对象的，有三类类对象，一是ClassRoot，包括java.lang包下的类，这类的类对象是语言自己的，不需要import，ART虚拟机是定义在mirror目录下的。二是boot_class_path，包括jdk和android.jar，这类的类对象是通过指定

前面两篇文章介绍了ART的启动过程，而在启动之后，我们感兴趣的就是ART是怎么运行的。回顾一下虚拟机系列的前面几篇文章，我们可以理一下思路：一，apk以进程的形式运行，进程的创建是由zygote。参考文章《深入理解Dalvik虚拟机- Android应用进程启动过程分析》二，进程运行起来之后，初始化JavaVM参考文章《深入理解ART虚拟机—虚拟机的启动》三，JavaVM创建之

Anroid的杀进程策略是基于kernel里的LowMemeoryKiller模块，LMK的实现在这里不展开分析，大致的原理就是LMK注册了内核的shrinker(lowmem_shrinker)，内核线程kswapd，在linux回收内存分页的时候，通过shrinker回调回来给LMK。LMK根据每个进程的oom_adj值，将大于某个阈值的进程都发送SIGKILL信号杀掉。oom_adj的阈值因

Service对于Android开发来说再熟悉不过了，不过大部分人对Service的了解也仅限于api，这篇文章，我们通过分析AMS的源码，从一个更高的高度来了解一下Service的整个生命周期。Service的生命周期接口：1. startService2. bindService3. stopService4. unbindService这几个接口在apk进程里调用，通过ActivityManagerNative这个Binder最后调用到ActivityManagerService里，而AM

最近突发奇想，写个Java源码分析系列。开发过程中，总会使用各种类库，如ArrayList，LinkedList等，用得虽多，但对于其实现细节却了解甚少，所以专卖开辟个系列，从源码的角度分析一下各种Java类库的实现细节。就先从最简单的List入手。List是给接口，其继承自Collection，标准接口咱就不说了，List的实现有两个，ArrayList和LinkedList，前者是数组实现

Android的应用进程启动是apk在manifest里申明的Activity，Service，BroadcastReceiver等组件被调起时而触发的。我们以Activity为例，当点击桌面上的应用图标时，桌面会调用startActivity，启动manifest里申明的相应Launcher的Activity，而Activity的startActivity会通过Binder调用来到Activit