FastApp

FastApp

项目地址： closedevice/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 可以被缓存，因此在某些场景下会有更流畅的体验。

1. Fragment 能让你更容易的适配手机和平板。如果你的应用需要支持这两种类型的设备，那么使用 Fragment 会帮你减少很多适配问题。
2. 最大程度上的实现布局复用，更好的实现模块化。很多情况下，你会发现：你在用玩“积木”的方法拼装应用。

而你所付出的代价仅仅需要花费点事件研究它。在 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 更多信息，直接参考官网即可。