概述

Android的单元测试可以分为两部分：

1. Local unit tests：运行于本地JVM
2. Instrumented test：运行于真机或者模拟器

如果使用Local测试，需要保证测试过程中不会调用Android系统API，否则会抛出RuntimeException异常，因为Local测试是直接跑在本机JVM的，而之所以我们能使用Android系统API，是因为编译的时候，我们依赖了一个名为“android.jar”的jar包，但是jar包里所有方法都是直接抛出了一个RuntimeException，是没有任何任何实现的，这只是Android为了我们能通过编译提供的一个Stub！当APP运行在真实的Android系统的时候，由于类加载机制，会加载位于framework的具有真正实现的类。由于我们的Local是直接在PC上运行的，所以调用这些系统API便会出错。
那么问题来了，我们既要使用Local测试，但测试过程又难免遇到调用系统API那怎么办？其中一个方法就是mock objects，比如借助Mockito，另外一种方式就是使用Robolectric， Robolectric就是为解决这个问题而生的。它实现一套JVM能运行的Android代码，然后在unit test运行的时候去截取android相关的代码调用，然后转到他们的他们实现的Shadow代码去执行这个调用的过程

概述

我们知道，OOP三个基本特征是:封装、继承、多态。通过继承，我们可以基于差异编程，也就是说，对于一个满足我们大部分需求的类，可以创建它的一个子类并只改变我们不期望的那部分。但是在实际使用中，继承很容易被过度使用，并且过度使用的代价是比较高的，所以我们减少了继承的使用，使用组合或委托代替

优先使用对象组合而不是类继承

在本文中，我们会分别介绍模板方法模式和策略模式，这两个模式分别使用了继承和委托两种方式。这两种模式解决的问题是类似的，经常可以互换使用，它们都可以分离通用的算法和具体的上下文。比如我们有一个通用的算法，算法有不同的实现方式，为了遵循依赖倒置原则，我们希望算法不依赖于具体实现。

概述

根据依赖倒置原则，我们知道，我们应优先依赖抽象类而不是具体类。在应用开发过程中，有很多实体类都是非常易变的，依赖它们会带来问题，所以我们更应该依赖于抽象接口，已使我们免受大多数变化的影响。
工厂模式（Factory）允许我们只依赖于抽象接口就能创建出具体对象的实例，所以在开发中，如果具体类是高度易变的，那么该模式就非常有用。

接下来我们就通过代码举例说明什么是工厂模式

概述

Fragment表示 Activity 中的行为或用户界面部分。您可以将多个 Fragment 组合在一个 Activity 中来构建多窗格 UI，以及在多个 Activity 中重复使用某个 Fragment。您可以将 Fragment 视为 Activity 的模块化组成部分，它具有自己的生命周期，能接收自己的输入事件，并且您可以在 Activity 运行时添加或移除 Fragment。
Fragment 必须始终嵌入在 Activity 中，其生命周期直接受宿主 Activity 生命周期的影响。 例如，当 Activity 暂停时，其中的所有 Fragment 也会暂停；当 Activity 被销毁时，所有 Fragment 也会被销毁。 不过，当 Activity 正在运行（处于已恢复生命周期状态）时，您可以独立操纵每个 Fragment，如添加或移除它们。 当您执行此类 Fragment 事务时，您也可以将其添加到由 Activity 管理的返回栈 — Activity 中的每个返回栈条目都是一条已发生 Fragment 事务的记录。 返回栈让用户可以通过按返回按钮撤消 Fragment 事务（后退）。

当您将 Fragment 作为 Activity 布局的一部分添加时，它存在于 Activity 视图层次结构的某个 ViewGroup 内部，并且 Fragment 会定义其自己的视图布局。您可以通过在 Activity 的布局文件中声明Fragment，将其作为 <fragment> 元素插入您的 Activity 布局中，或者通过将其添加到某个现有 ViewGroup，利用应用代码进行插入。不过，Fragment 并非必须成为 Activity 布局的一部分；您还可以将没有自己 UI 的 Fragment 用作 Activity 的不可见工作线程。

本文将通过分析源码，对 Fragment 的创建、销毁以及生命周期做一个更深入的认识。

建议读者在看这篇文章的时候，先看下Fragment事务管理源码分析，对Fragment管理类先有一个比较清楚的认识。

概述

在Fragment使用中，有时候需要对Fragment进行add、remove、show、hide、replace等操作来进行Fragment的显示隐藏等管理，这些管理是通过FragmentTransaction进行事务管理的。事务管理是对于一系列操作进行管理，一个事务包含一个或多个操作命令，是逻辑管理的工作单元。一个事务开始于第一次执行操作语句，结束于Commit。通俗地将，就是把多个操作缓存起来，等调用commit的时候，统一批处理。下面会对Fragmeng的事务管理做一个代码分析

概述

动态代理是java的一大特性，动态代理的优势就是实现无侵入式的代码扩展。它可以增强我们原有的方法，比如常用的日志监控,添加缓存等，也可以实现方法拦截，通过代理方法修改原方法的参数和返回值等。
要了解动态代理，我们需要先看看什么是静态代理

概述

Android开发者应该都遇到了64K最大方法数限制的问题，针对这个问题，google也推出了multidex分包机制，在生成apk的时候，把整个应用拆成n个dex包（classes.dex、classes2.dex、classes3.dex），每个dex不超过64k个方法。使用multidex，在5.0以前的系统，应用安装时只安装main dex（包含了应用启动需要的必要class），在应用启动之后，需在Application的attachBaseContext中调用MultiDex.install(base)方法，在这时候才加载第二、第三…个dex文件，从而规避了64k问题。
当然，在attachBaseContext方法中直接install启动second dex会有一些问题，比如install方法是一个同步方法，当在主线程中加载的dex太大的时候，耗时会比较长，可能会触发ANR。不过这是另外一个问题了，解决方法可以参考：Android最大方法数和解决方案 http://blog.csdn.net/shensky711/article/details/52329035。

本文主要分析的是MultiDex.install()到底做了什么，如何把secondary dexes中的类动态加载进来。

概述

对于JNI，有些童鞋在没有接触过的时候，可能会觉得比较复杂，但是其实当你真正去了解、去使用的时候，就会发现JNI的使用还是比较简单的，JNI本身提供了一系列的API让我们可以在native方法中操作java。JNI的使用无非也就是使用这些接口和java交互。这几天在学习JNI接口的时候，发现网上搜索的JNI的中文虽然不少，但是很多都是零零碎碎的小例子，有一些官方文档的翻译，但要么是不全面，要么是资料比较旧了，干脆自己根据java native interface specification整理了一份技术资料。当然，很多时候看中文资料是词不达意的，如果文中有疑问的地方欢迎指出，或者翻阅原文

首先，JNI是一个本地编程接口。它允许运行在Java虚拟机的Java代码与用其他语言（如C,C++和汇编）编写的库交互
JNI最大的好处是JNI不受Java虚拟机实现方式的限制，因此，Java虚拟机厂商添加JNI的支持并不会影响虚拟机其它功能模块。native代码只需要编写一遍，就可以在所有支持JNI的虚拟机上工作。

通过JNI，你可以在native代码中：

• 创建、检查或者更新java对象
• 调用java方法
• 捕捉和抛出异常
• 加载class和获取class信息
• 运行时类型检查

Android应用程序使用NDK的意义在这里就不说了，本文主要讲解如何在Android Studio 2.2下如何一步步搭建NDK开发环境。

下载NDK和工具

Android Studio2.2开始推荐开发者使用CMake去构建本地代码，在构建之前，我们需先安装下面三个依赖：

• NDK: a set of tools that allows you to use C and C++ code with Android.
• CMake: an external build tool that works alongside Gradle to build your native library. You do not need this component if you only plan to use ndk-build.
• LLDB: the debugger Android Studio uses to debug native code.

我们可以使用SDK Manager进行下载，菜单位置：Tools > Android > SDK Manager，勾选后安装即可

ProGuard简介和工作流程

ProGuard能够通过压缩、优化、混淆、预检等操作，检测并删除未使用的类,字段,方法和属性，分析和优化字节码，使用简短无意义的名称来重命名类，字段和方法。从而使代码更小、更高效、更难进行逆向工程。

上图就是ProGuard的工作流程，分别会经过四个阶段：

1. 压缩（Shrink）:在压缩处理这一步中，用于检测和删除没有使用的类，字段，方法和属性
2. 优化（Optimize）:在优化处理这一步中，对字节码进行优化，并且移除无用指令
3. 混淆（Obfuscate）:在混淆处理这一步中，使用a,b,c等无意义的名称，对类，字段和方法进行重命名
4. 预检（Preveirfy）:在预检这一步中，主要是在Java平台上对处理后的代码进行预检

以上四个步骤都是可选的，我们可以通过配置脚本来决定其中的哪几个步骤。比如我们可以配置只压缩和混淆，不进行优化，不进行预检。
ProGuard的官网有使用指导：http://proguard.sourceforge.net/