FastApp
FastApp 是一个轻量级急速开发框架，基于 Fragment+RxJava+Retrofit 2.0+Glide+Realm 构建，采用 Material Design 设计风格，帮助开发者快速构建轻量级应用。当然，由于本项目是为了说明博客中提到的一些问题，因此早期并未让其复杂化。另外，为了让它富有生机，给它起名为“师父说”.
本项目基于 Material Design+RxJava+Retrofit 2.0+Glide+Realm 构建了一个良好 MVC 架构的客户端模型，对新手友好度更高。
本项目仍在不断的完善阶段，欢迎及时向我反馈ISSUES，email。如果对你有帮助欢迎点个 star、fork.另外也欢迎欢迎关注代码之道，编程之法
Preview
Download
(Android 5.0 or above) 点击下载最新版
Point
为什么采用多 Fragment 构建应用？
相比 Activity，Fragment 稍显复杂。谈起 Fragment 的时候，很多开发者直接摆手，然后告诉你这玩意坑太多,比如说调试比较困难，无法有效的实现业务逻辑和 View 的解耦，偶尔的 NullPointerException 问题等等。但这些问题都不是阻止我们使用 Fragment 的原因。其实深究下来，你会发现这并不是 Fragment 自身的问题，而更多的是由于 Fragment 稍显复杂，导致很多开发者没有耐心去深究它，再加上一些开发者喜欢直接 copy 网上的代码，不加以思考的就应用在实际项目中，后果可想而知。有很多人也提出过通过自定义 View 的方式取代 Fragment，当然这也是可行的，但是对于大部分开发者来说，这好像没有必要（你不是在加班，就是在吃饭...你懂的）
那么这里我为什么要采用多 Fragment 构建基础框架呢？主要有有两方面的原因：
1.相比创建 Actvity，Fragment 要显得更加轻量级。尤其是在同一个 Activity 中实现多种布局的时候，无需新建 Activity，另外，由于 Fragment 可以被缓存，因此在某些场景下会有更流畅的体验。
- Fragment 能让你更容易的适配手机和平板。如果你的应用需要支持这两种类型的设备，那么使用 Fragment 会帮你减少很多适配问题。
- 最大程度上的实现布局复用，更好的实现模块化。很多情况下，你会发现：你在用玩“积木”的方法拼装应用。
而你所付出的代价仅仅需要花费点事件研究它。在 FastApp 当中，我们已经为你了一部分工作，在大多数情况下，它工作良好。你需要做的就是关注界面的实现和业务逻辑。
为什么采用 RxJava+Retrofit？
在 11 年左右的时候，没有太多网络库供你选择，所以在一些比较老的项目当中还会看到我们使用 HttpUrlConnection 或者 HttpClient 来自行封装成的请求库。5 年的时间，让 Android 整个生态环境更加完善，越来越多人参与到 Android 的开发工作，也诞生了很多非常优秀的网络库，如 async-http-client,volley，OkHttpClient,Retrofit 等等，这些库各有利弊，但是就目前看来相对比较通用又受大家欢迎的莫过于 volley，OkHttpclent 和 Retrofit 这三者了。而 Retrofit 是通过包装 OKHttpClient 而来，所以说两者在底层并无多大区别，而 volley 则是 google 前几年推出的。在我看来，在你的应用无特殊要求的情况下，三者之一都能满足需求，而且在出现问题的时候能快速的从周围开发者得到反馈。
这里我选择了 Retrofit 来做出基础网络请求，另外也应时的结合 RxJava 来帮助大家更好的学习。
补：目前国内很多大神也在这些项目之上二次封装了很多使用的库，比如 NoHttp，xUtils，OkHttpUtils，OkGo 等，也有很多一些从头开发的，如 HttpLite 等。但无论你选择哪一个，本质并无变化。不过，如果你想深入底层学习，开始时请尽可能的不要使用，封装程度太高，学到的越少。后期有经验之后，自己尝试造轮子呗。
为什么采用 Glide？
目前图片加载框架也是繁多，目前常用的有以下几种：ImageLoader（2011 年），Picasso（2013 年），Glide（2012 年），Fresco（2015 年）四种。其中 ImageLoader 出现的最早也应用的最为广泛。早期出现的 ImageLoader 首要关注的是如何尽快的加载图片，然后需要自己动手处理图片防止内存溢出。后面，大家觉得很烦啊，于是一些即注重加载速度，又减少内存溢出的网络加载框架就出现了，就像后三种。（我在一些群里曾听到一些开发者说“ImageLoader 不行啊，经常造成内存溢出啊，Fresco 就不会，所以 ImageLoader 已经过时了”之类的话，虽然我个人能力也比较一般，但是当遇到问题的时候我首先想的是“我是不是忘记处理什么？是不是我的能力有问题，而不是质疑框架，毕竟框架是死的，人是活的”）
这些加载库各有优缺点，需要自行调研之后根据业务选择，这里我选择了加载速度较快，体积更小的 Glide 作为网络加载库。
这里我们对 ImageLoader，Glide、Picasso、Fresco 做个简单的对比： ImageLoader虽然已经停止维护了，但是仍然比较好用，图片加载不多的场景下推荐使用。
Glide在Picasso基础上二次开发而来，沿袭了 Picasso 以往的简洁风格，并做了大量优化。
| Glide Vs Picasso | Glide | Picasso |
|---|---|---|
| 图片格式 | 默认 RGB_565，支持动态图 | 默认 RGB_ARGB_8888，不支持动态图 |
| 内存占用 | 默认情况下比 Picasso 小一半 | |
| 磁盘缓存 | 根据 ImageView 的大小来缓存相应的图片 | 只缓存原始尺寸的图片 |
| 包体积 | 比 Picasso 大 | |
| 加载速度 | 大部分情况下比 Picasso 快 |
Fresco重点关注图片加载导致的内存溢出问题。和传统做法不一致，Fresco 将图片资源放在虚拟机管理内存之外的 Native 堆当中，因此该部分内存不占用 App 内存。但是由于虚拟机无法管理该区域，因此 Fresco 自行实现了图片资源的回收机制。由于是放在 Native 堆当中的，因此这部分是用 C++来写的，因此阅读难度相对较大，另外 Fresco 这个库也相对较大，会增加 2M 左右的体积。在这个流量不值钱的年代，增加的这点体积好像也算不了什么？
总结，如果你喜欢偷懒，又不擅长处理内存溢出问题，而且你的应用大量使用图片的场景下，推荐使用 Fresco。其他场景下，优先选择 Glide 吧。
为什么使用 Realm？
对 Android 开发者而言，Sqlite 再熟悉不过了，但是你会发现 Sqlite 是面向结构式的语言而并非面向对象式的。而 Realm 则是一种面向对象的数据库，因此你无须再编写 sql 语句就可以将对象存储到数据库当中。如果你的项目是一个新项目，而你又是面向对象的坚定主义者，那么使用 Realm 是你不二的选择。如果你是在改造老项目，而且项目又比较大，请不要使用 Realm,否则会成为你的噩梦.
关于 Realm 更多信息，直接参考官网即可。
Version
V 0.0.1
1.提交第一版
