APP应用市场功能的框架图，约半年前的一个项目，个人独立设计并完成上线的功能，今天认真整理了
    下重新把框架画出来，画的不是很正规.
    


       因为交互需求是支持不断点击切换下载状态的效果，所以下载服务同步处理得比较严谨，并采用断点下载，
这里就不上源码了，不喜勿喷，如有错误，请多多指教！！！

本年度最后一个长假算是过去了，再度回到北京，颇有一番感受。
 
在前面的文章中，我们介绍了开发过程容易出现的一些问题，今天我们就在此基础上打造自己急速开发框架(FastApp)。该框架旨在向你展示一个轻量级的应用的总体结构以及如何构建多Fragment应用，为了使他对所有的开发者都比较友好，我们返本溯源，暂时避开的MVP及MVVM，而是继续沿用MVC设计理念。当然，你可能会问这时候还用MVC，是不是太落后了？关于这点，后面我会单独的写一篇文章来介绍所谓的MVC、MVP、MVVM在移动应用开发中遇到的问题。此后，我们将以该框架为例，来向大家展示一些性能优化技巧以及向你展示一个项目如何由小变大（如何插件化，如何组件化，如何构建CI等），又是如何做技术选型的。此外，为了更好的帮助大家学习RxJava和Retrofit，我特地将其纳入到基础结构中。
 
 
FastApp是什么？
 
FastApp是一个轻量级急速开发框架，基于Fragment+RxJava+Retrofit 2.0+Glide+Realm构建，采用Material Design设计风格，帮助开发者快速构建轻量级应用。
 
技术选型
 
为什么采用多Fragment构建应用？
 
相比Activity，Fragment稍显复杂。谈起Fragment的时候，很多开发者直接摆手，然后告诉你这玩意坑太多,比如说调试比较困难，无法有效的实现业务逻辑和View的解耦，偶尔的NullPointerException问题等等。但这些问题都不是阻止我们使用Fragment的原因。其实深究下来，你会发现这并不是Fragment自身的问题，而更多的是由于Fragment稍显复杂，导致很多开发者没有耐心去深究它，再加上一些开发者喜欢直接copy网上的代码，不加以思考的就应用在实际项目中，后果可想而知。有很多人也提出过通过自定义View的方式取代Fragment，当然这也是可行的，但是对于大部分开发者来说，这好像没有必要（你不是在加班，就是在吃饭…你懂的）
 
那么这里我为什么要采用多Fragment构建基础框架呢？主要有有两方面的原因：
 
 
 
1.相比创建Actvity，Fragment要显得更加轻量级。尤其是在同一个Activity中实现多种布局的时候，无需新建Activity，另外，由于Fragment可以被缓存，因此在某些场景下会有更流畅的体验。 
 2. Fragment能让你更容易的适配手机和平板。如果你的应用需要支持这两种类型的设备，那么使用Fragment会帮你减少很多适配问题。 
 3. 最大程度上的实现布局复用，更好的实现模块化。很多情况下，你会发现：你在用玩“积木”的方法拼装应用。
 
 
而你所付出的代价仅仅需要花费点事件研究它。在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更多信息，直接参考官网即可。
 
 
项目基础结构
 
包目录划分
 
 
我们重点来看与网络层相关的api包和与界面相关的base包。
 
api
 
网络请求客户端配置及放置相关的请求接口。convert子包中用于防止请求和响应转换器，exception子包中则定义了实现约定的请求错误码等，而remote子包中则放置具体的请求接口。
 
base
 
框架的核心包。BaseApplication继承于Application，其内部主要提供数据存储，个性化toast等功能。 
 BaseSubscriber和BaseObserver则分别继承RxJava中的Subscriber和Observer。ui子包当中则是相关的有关界面的基本组件：BaseActivity，BaseDetailFragment，BaseFragment，BaseListFragment，BaseTabFragment。因此我们的Activity需要继承BaseActivity，普通的Fragment需要继承BaseFragment，如果是带下载刷新，上拉加载更多的则需要继承BaseListFragment.BaseDetailFragment和BaseFragment类似，但是再带了下载刷新，通常用于支持手动下拉刷新的详情页面。
 
为了方便理解，这里我们用uml来描述一下： 
 
 
参见Github
 

前言
 
由于自己平时做项目(自己做或者帮朋友做的移动APP,webAPP,机器学习算法类)比较多,做的东西大多没有整理成文档,现在就把之前做的项目整理成文档分享给大家,好大家以后做相关项目有个参考!
 
 
 
在做HTML5开发时一直在使用Hbuilder进行代码的编辑,发现Hbuilder写代码的速度非常的快,同时它也有自己的一套开发web APP 的框架MUI,今天有时间给大家介绍一下,怎么完整的去开发一套商城类APP整个流程.这里着重给大家介绍功能点的集成和开发,如果这个掌握了,其他框架开发的APP功能的集成都是一模一样的了!
 
 
之后也会给大家介绍利用ionic框架,React Native框架,vue框架开发一款APP.
 
目录
 
1.[webAPP项目]基于MUI框架webAPP开发功能流程之引导图制作详解01
 
2.[webAPP项目]基于MUI框架webAPP开发功能流程之头部导航与底部导航制作详解02
 
3.[webAPP项目]基于MUI框架webAPP开发功能流程之轮播图制作详解03
 
4.[webAPP项目]基于MUI框架webAPP开发功能流程之接口解析及数组展示详解04

APP 基本框架设计
 
前言
 
        一个良好的APP 基本遵循“简单”，“易用”，“高效”，“便维护”，“可扩展”基本也是从这几个原则出发，比较符合用户体验；同时也是比较符合我们开发人员设计程序的初衷，尽量低的耦合性和尽量高的可复用性，而一个设计良好的应用程序；必然需要有个比较规范和通用的设计框架，因此APP框架设计就变得尤为重要了.
 
APP框架设计包括哪些内容
 
APP框架搭建的设计；主要的核心思想还是分层思想，通常设计下，会包括以下内容:(如下图)
 

 
 
APP框架搭建需要考虑的因数
 
目前现在比较流行混合开发模式，而上图框架的设计内容是基于原生基础上设计，原生开发固然体验比较好，但是开发周期相对于网页通常比较长，对于混合开发模式；我们要考虑以下几个方面：
 
1一般情况下；从用户体验的角度出发；为了提高用户体验；一般本地的一级页面，以及改动量比较小的页面，需要做成原生的。
 
2 基于公司实际情况出发，经常变动版本；改动比较大的或者详情页面我们可以做成网页形式，便于我们版本迭代更新
 
3复杂的软件必须有清晰合理的架构，否则无法后期扩展和维护；通常情况下；我们会结合业界比较成熟的一些设计模式；
 
1 MVC 是最常见的软件架构之一，业界有着广泛应用，也是早期我们APP 设计时最常见的一种架构模式.
 

 
 
 
 
§  视图（View）：用户界面。
 
§  控制器（Controller）：业务逻辑
 
§  模型（Model）：数据保存
 
 
 
MVC模式的意思是，软件可以分成三个部分。它们的通信方式
 
1.View传送指令到 Controller
 
2.Controller完成业务逻辑后，要求 Model改变状态
 
3.Model将新的数据发送到 View，用户得到反馈.
 
所有的通信都是单向的。
 
2 MVP 模式作为一种新型模式，是从经典的模式MVC演变而来，它们的基本思想有相通的地方，将 Controller 改名为Presenter，同时改变了通信方向。
 

 
 
 
 
1. 各个部分之间的通信，都是双向的。
 
2. View 与 Model 不发生联系，都通过 Presenter传递。
 
3. View 非常薄，不部署任何业务逻辑，称为"被动视图",即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
 
4模型与视图完全分离，我们可以修改视图而不影响模型；
 
5可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部；
 
6我们可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁；
 
7如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）
 
3 MVVM (数据绑定) 最早是微软提出的；模式将 Presenter 改名为ViewModel，基本上与 MVP 模式完全一致。
 

 
 
 
 
简单的说，ViewModel就是View与Model的连接器，View与Model通过ViewModel实现双向绑定。
 
唯一的区别是，它采用双向绑定：View的变动，自动反映在 ViewModel，反之亦然.
 
谷歌推出了Data binding这个框架，Data Binding是一个 support包，因此与 Android M没什么关系，可以轻松的实现MVVM，Data binding解决了 Android UI 编程中的一个痛点，
 
官方原生支持 MVVM 模型可以让我们在不改变既有代码框架的前提下，非常容易地使用这些新特性。
 
其实在此之前，已经有些第三方的框架（RoboAndroid) 
 
可以支持 MVVM 模型，无耐由于框架的侵入性太强，导致一直没有流行起来。
 
 
 
Data Binding 的基本用法
 
一 环境   
 
要求你的Android Studio版本是1.3+ 
 
在开始之前，请更新你的Support repository到最新的版本
 
要使用DataBinding,android的构建插件gradle要求1.5.0-alpha1或者更高的版本。
 
二 添加依赖
 

 
 
 
 
三Data Binding 入门级Demo 例子
 
1 我们首先定义一个java bean  user 类
 
 
2 我们再来写一个布局文件；如下图
 
 
3最后来看看Activity怎么写。
 

 
 
 
 
没有了之前的find控件，没有了setText，Activity代码更加简洁明了
 
运行结果
 

 
 
 
 
 
结合项目用的比较多的设计架构一般分为2种：
 
  
 
A 单Activity＋多Fragment的架构.
 
 
B 多模块Activity＋多Fragment的架构.
 
 
是使用单Activity＋多Fragment的架构，还是多模块Activity＋多Fragment的架构？
 
单Activity＋多Fragment：
 一个app仅有一个Activity，界面皆是Frament，Activity作为app容器使用。 
 
优点：性能高，速度最快。参考：新版知乎 、google系app
 
缺点：逻辑比较复杂，尤其当Fragment之间联动较多或者嵌套较深时，比较复杂。
 
多模块Activity＋多Fragment：
 一个模块用一个Activity，比如
 1、登录注册流程：
 LoginActivity + 登录Fragment+ 注册Fragment + 填写信息Fragment ＋ 忘记密码Fragment
 2、或者常见的数据展示流程：
 DataActivity + 数据列表Fragment+ 数据详情Fragment ＋ ...
 
优点：速度快，相比较单Activity+多Fragment，更易维护。
 
总结
 
 
 
权衡利弊，我认为多模块Activity＋多Fragment是最合适的架构，开发起来不是很复杂，app的性能又很高效。
 
 
当然。Fragment只是官方提供的灵活组件，请优先遵从你的项目设计！真的特别复杂的界面，或者单个Activity就可以完成一个流程的界面，使用Activity可能是更好的方案。
 
 
 
 
Android 的 Data Binding 框架还在 beta 阶段，Android Studio 对其内部支持也不是很完整，
 
进步的空间还很大。不过它被设计和开发的很好，将会改变 Android 应用开发方式(如果顺利的话)。
 
1 我个人比较倾向于采用了MVP+ Data Binding的混合模式.也就是比较流行热火的MVPVM模式。
 
2如果有程序框架，因为项目的几乎是一致的，所以上一个项目的项目计划可以直接拿过来使用，而且经过几个项目之后，这个项目计划的模板会越来越细，越来越实用。
 
因为结构一致，代码混乱性会降低到可以接受的程度，而且可以重用上一个项目的大部分代码。而且逻辑清晰，使得代码相对较小，不容易在代码中迷失。因为代码逻辑简单有序，所以测试起来会很容易。
 
3 最后我们不能永远理想化地去选择所谓最好的设计，具体问题还得具体分析；在现实的必要情况下，我们要敢于舍弃，最合适的设计才是最好的设计.