在开发程序的时候，会用到各种对象，很多对象在使用之前都需要进行初始化。例如你要操作一个SharedPreference，你需要调用getSharedPreferences(String name,int mode)来获取一个对象，然后才能使用它。而如果这个对象会在多个Activity中被使用，你就需要在每个使用的场景中都写下同样的代码。这不仅麻烦，而且增加了出错的可能。依赖注入让你不需要初始化对象。换句话说，任何对象声明完了就能直接用。
当涉及到Android上的依赖注入（DI.dependency injection）类库的时候，存在不少的选择，但怎么知道哪一个最适合你呢？下面将针对目前比较流行的三种依赖注入框架（Dagger、RoboGuice和ButterKnife）做进一步的对比和分析。
为了解决逻辑处理和UI视图的松散耦合，MVC和MVP的架构模式在很多App中使用比较广泛。
那什么是MVP呢？它又和我们常常听到的MVC有什么关系了以及区别呢？
自从Android 3.0中引入fragments 的概念，根据词海的翻译可以译为:碎片、片段。其目的是为了解决不同屏幕分辩率的动态和灵活UI设计。大屏幕如平板小屏幕如手机，平板电脑的设计使得其有更多的空间来放更多的UI组件，而多出来的空间存放UI使其会产生更多的交互，从而诞生了fragments 。
fragments 的设计不需要你来亲自管理view hierarchy 的复杂变化，通过将Activity 的布局分散到frament 中，可以在运行时修改activity 的外观，并且由activity 管理的back stack 中保存些变化。当一个片段指定了自身的布局时，它能和其他片段配置成不同的组合，在活动中为不同的屏幕尺寸修改布局配置（小屏幕可能每次显示一个片段，而大屏幕则可以显示两个或更多）。
Fragment必须被写成可重用的模块。因为fragment有自己的layout，自己进行事件响应，拥有自己的生命周期和行为，所以你可以在多个activity中包含同一个Fragment的不同实例。这对于让你的界面在不同的屏幕尺寸下都能给用户完美的体验尤其重要。
从一开始做Android的时候就发现，一个app有很多个窗体（或者页面）堆积而成。由于Android自身对MVC的结构抽离得十分清晰，对布局，数据控制，逻辑处理都进行了一定的分离，大大方便了整个开发流程以及降低了开发成本。
但是由此而导致一定的问题，很多初学者开发一个app经常会落入只是重复的写activity的固定思维中。这样的结果就是一个app随着业务量的上升，重复劳动越来越厚重。同时也会伴随越来越多的逻辑错乱无序，或者有些逻辑根本无法实现。面对复杂业务的时候只能是用一个坑来填补另外一个坑。这对app来说本身就是一种灾难。
因此，我打算从这几年的工作经验中来对一个成熟app应该具有的整体架构以及基本知识点进行一个梳理，同时也希望从这些基本的分析中会给广大app开发者一些思考。