android 技术选型
2020-03-18 本文已影响0人
天真的小罗罗
一、开发语言
kotlin和Java 或者第三方跨平台框架（先留坑，后面再补充）
二、APP整体架构
| - | MVC | MVP | MVVM | MVPVM | Clean |
|---|---|---|---|---|---|
| 介绍 | 1.Model：数据结构相关的类； 2.View：XML文件； 3.Controller：Activity/Fragment/Adapter等直接和UI相关的类； |
1.MVP将View和Model解耦，从而降低了耦合度; 2.Model：数据结构和操作相关的类; 3.Presenter：作为View与Model交互的中间纽带，处理与用户交互的业务逻辑； 4.View：页面的显示，即xml+activity/fragment 5.需要View实现的接口，View通过View interface与Presenter进行交互 ； |
1.对比MVP，MVVM充分利用xml，将逻辑层(Presenter/ViewModel)和View层的单向绑定改为了双向绑定，耦合度和MVP差不多，类比MVP少，可用性更强,Model和View类似MVP； 2.VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体； |
MVPVM=Model+View+Presenter+ViewModel; 1.没有使用类似MVP架构时，逻辑一般写在Activity或者Fragment，导致View臃肿，业务逻辑、UI操作和数据耦合到了一起，结构混乱。现在View层要处理的逻辑全部委托给Presenter处理，View层专注实现UI，Presenter专注实现业务逻辑，它们之间通过View Interface和Presenter Interface交互。在google推出databinding后，View Interface的部分功能可以转移到ViewModel中去，进一步降低View层的臃肿; 2.View层：实现View Interface，对外提供showDialog、showToast之类的方法; 3.ViewModel层：以databinding为基础，对外提供控制xml界面的方法; 4.Presenter层：实现Presenter Interface，处理业务逻辑; 4.Model层：服务器数据对应数据模型类; |
1.Clean 一般是指，代码以洋葱的形状依据一定的依赖规则被划分为多层：内层对于外层一无所知。这就意味着依赖只能由外向内。 2.domain：抽象业务层; 3.data：数据层; 4.presentation：展示层; |
| 优点 | 代码结构简单 开发简单 |
view层和model层分离 可将一个Presenter用于多个视图 方便单元测试 模型视图分离，逻辑清晰 |
用户直接交互的是View View和ViewModel是多对一的关系 View和ViewModel的双向数据绑定 双向绑定，简洁清晰 |
逻辑清晰，耦合度低 | 耦合度极低 |
| 缺点 | xml作为view层,可控性较差; view层和model层存在耦合; Activity代码臃肿; 业务增加后，不易维护; |
由于通过接口进行控制,接口粒度不好控制; UI驱动，要考虑线程及生命周期; V层和P层存在耦合; 复杂业务也会导致P层代码臃肿; 抽象接口较多; |
由于去除了Presenter层，会导致view层依然过重; 可读性较差，出现问题不易定位; |
实现业务复杂度高; | 业务实现复杂读极高; |
| 适用场景 | 极小型项目 | 中大型项目 | 中大型项目 | 大型项目 | 超大型项目 |
三、网络框架
http底层
| -- | HttpClient | HttpURLConnection | OkHttp |
|---|---|---|---|
| 介绍 | Apache的一个三方网络框架 | 一个多用途、轻量级的http客户端 | Square 公司封装的一个高性能 http 请求库 |
| 优点 | 网络请求做了完善的封装，api众多，用起来比较方便，开发快。实现比较稳定，bug比较少 | 由于API比较简单，使得我们可以更加容易的去使用和拓展它 | 链接复用Response 缓存和 Cookie 默认 GZIP请求失败自动重连DNS 扩展Http2/SPDY/WebSocket协议支持 |
| 缺点 | 由于其api众多，是我们很难再不破坏兼容性的情况下对其进行扩展，在android5.0被废弃，6.0逐渐删除 | 它对网络请求的封装没有HttpClient彻底，api比较简单，用起来没有那么方便 | okhttp请求网络切换回来是在线程里面的，不是在主线程，不能直接刷新UI，需要我们手动处理。封装比较麻烦 |
- 总结：HttpClient已经不建议使用了，OkHttp在Android2.3之后已经成为了谷歌的标配，HttpURLConnection在Android4.4以后已将底层改用OkHttp；OkHttp为了使用方便还是需要进行封装
封装框架
| -- | volley | Retrofit |
|---|---|---|
| 介绍 | 一个谷歌开源的简单的异步http库； | Square 公司出品的默认基于 OkHttp 封装的一套 RESTful 网络请求框架； |
| 优点 | 支持图像加载自带缓存，支持自定义请求 * 轻量级网络交互，适合大量的，小数据传输。 | 彻底解耦默认使用 OkHttp ，性能上要比 Volley 占优势支持同步、异步和RxJava |
| 缺点 | 不支持 post 大数据，不适合上传文件图片加载性能一般 | 比较高的门槛 |
- 总结：volley使用简单，适合用于多次的小数据传输；Retrofit适用范围较广，API使用简单，但有一定使用门槛，配合RxJava使用更佳
四、图片加载框架
| - | Glide | Picasso | Fresco |
|---|---|---|---|
| 介绍 | 2014年 Google 员工的开源项目 | 2013年 Square 开源的项目 | 2015年Facebook开源的图片框架 |
| 优点 | 可接受Activity/fragment的context，控制生命周期支持git支持okhttp，Volley内存友好2级缓存 | 自带统计监控功能使用复杂的图片压缩转换来尽可能的减少内存消耗 | 图片的渐进式呈现图片存储在安卓系统的匿名共享内存,无OOM很好的支持 GIF自定义居中焦点 |
| 缺点 | 大小和方法数均大于Picasso(500k和2678) | 不支持git无自动控制生命周期2级缓存 | 包较大（2~3M）使用复杂 |
- 总结：Glide除了包较大几乎拥有Picasso的所有优点，比较适合非专业的应用中的图片处理；Fresco拥有前面两个库的优点，但它的包很大，且使用门槛较高，比较适用于图片需求较大的应用
