android前辈的心得-知识点-各种依赖库-集锦

2019-08-20 本文已影响0人 W的北城

Android sdk 放在home目录或者其他app无关的位置，因为在安卓有些包含SDK的IDE的时候,可能火把SDK放在IDE同一目录下，当年你需要升级或者重新安装的时候，会比较麻烦。如果IDE是普通用户下运行，而不是在root下运行，还需要避免吧SDK放到需要studo权限的系统级别目录下。

Gradle配置

不要在build.gradle中定义sigingConfigs，因为会出现在版本控制中，重新建立一个不加人版本控制系统的gradle.properties文件

使用Maven依赖方式替代使用jar包方案如果项目中明确使用jar文件，那么为了避免成为固定版本，下载jar包来更新很繁琐，可以定义成Maven形式。然后会自动升级到指定的最新版本

Activities and Fragments

实现ui界面的时候，Fragments应该作为默认选择。可以重复使用Fragements用户接口来组合成你的应用，强烈推荐使用Fragments而不是activity来呈现ui界面：

（1）使用多窗格布局解决方案：Fragments的引入主要将手机应用内引申到平板电脑，所以在平板上面可能有A,B两个窗格，但是在手机应用上A.B可能分别充满整个屏幕。所以在起初就用fragments的话，会方便以后的屏幕适配。

（2）屏幕间数据通信：从一个Activity发送复杂数据(例如Java对象)到另外一个Activity，Android的API并没有提供合适的方法。不过使用Fragment，你可以使用一个activity实例作为这个activity子fragments的通信通道。即使这样比Activity与Activity间的通信好，你也想考虑使用Event Bus架构，使用如 Otto 或者 greenrobot EventBus作为更简洁的实现。如果你希望避免添加另外一个类库，RxJava同样可以实现一个Event Bus。

（3）Fragments 一般通用的不只有UI：你可以有一个没有界面的fragment作为Activity提供后台工作。进一步你可以使用这个特性来创建一个fragment 包含改变其它fragment的逻辑而不是把这个逻辑放在activity中。

（4）ActionBar可以使用内部fragment来管理：你可以选择使用一个没有UI界面的fragment来专门管理ActionBar,或者你可以选择使用在每个Fragment中添加它自己的action 来作为父Activity的ActionBar.

但是也不能滥用嵌套的fragments,因为可能会引起 matryoshka bugs。在架构一个app框架的时候，应该有一个顶级的activity来包含绝大部分业务相关的fragment。也可以有一些辅助的activity，辅助activity通信可以很简单限制在这两种方法 Intent.setData() 或 Intent.setAction()或类似的方法。

资源文件 Resources

命名：遵循前缀表面类型的习惯，例如type_foor_bar.xml

组织布局文件：

每一个属性一行，缩进四个空格

android:id作为第一个属性

android:layout_ 属性在上边

style 属性在底部

应该使用styles几乎每个项目都需要适当的使用style文件，因为对于一个视图来说有一个重复的外观是很常见的。

可以将一个大的style文件分割成多个文件 可以有多个styles.xml文件，Android SDK支持其他文件，style这个文件名称并没有起作用，起作用的在文件里的<style>标签。

colors.xml是一个调色板 在你的colors.xml文件中应该只是映射颜色的名称的一个RGBA值，没有其它的。避免重复定义RGBA值，这使如果需要改变基本色变的很复杂。同时，这些定义是更环境关联起来的，如button或者comment，应该放到一个按钮风格中，而不是在color.xml。

避免深层次的视图结构 有时候为了摆放一个视图，可能尝试添加另外一个LinearLayout。

各种dpi的范围

Android中的命名规范： 1.包名：使用反域名，全部使用小写字母；2.类：名词，采用大驼峰命名（又称帕斯卡命名法），尽量避免缩写，除非是公认的。如HTML,URL;3.接口：大驼峰命名；4.方法和变量：小驼峰命名法（驼峰命名）5.常量：全部大写，下划线命名；6.资源文件：全部小写，采用下划线命名法。7.资源布局文件（xml文件）全部小写，采用下划线命名法；8.资源id:小驼峰；9.layout中的id，view缩写_模块名称_view逻辑名称

开发模式(mvc和mvp)：

对比MVC和MVP模式来说：mvc模式容易造成Activity或者Fragment里面的代码越来越臃肿。

MVC模式：View：布局的xml文件Controller：Activity、Fragment、Dialog等；Model:相关的业务操作处理数据（如对数据库的操作、对网络等的操作都应该在Model层里）

MVP模式：View：Activity、Fragment、Dialog、Adapter等，该层不包含任何业务逻辑；Presenter：中介，View 与 Model 不发生联系，都通过 Presenter 传递；Model:相关的业务操作处理数据（如对数据库的操作、对网络等的操作都应该在Model层里）

MVP开发模式，便于后期的维护。

在使用第三方依赖库的时候，需要学会封装，抽象的依赖第三方框架。以便于实现低耦合。

知识点：

JAVA反射机制：JAVA反射机制在运行状态中对于任意一个实体类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意方法和属性，这种动态获取信息以及调用对象方法的功能称为java语言的反射机制。

Dagger2

(1)基于JAVA注解来实现的在完全编译阶段完成依赖注入的开源库，主要用于模块姐解耦，提高代码的健壮性和可维护性。

(2)实现有三种方式：1、构造注入；2、接口注入；3、注解注入（推荐使用，因为前面两种都需要写大量代码，这一种只需要 “@Inject”即可）

(3)目的：最主要为了解耦，达到高内聚，低耦合的目的，保证代码的健壮性，灵活性和可维护性。

(4)主要用法：@Inject, @Module, @Provides, @Component, @Qulifier, @Scope, @Singleten

Retrofit+RxJava+OkHttp -封装篇

1.创建一个统一的生成接口实例的管理类

2.创建接口，通过第一步获取实例

3.创建一个业务Loader,如xxxLoader,获取并处理相关业务

4.Activity/Fragment中调用

5.统一处理结果和错误

6.添加公共参数

（Demo：https://github.com/pinguo-zhouwei/RetrofitRxJavaDemo）

android前辈的心得-知识点-各种依赖库-集锦

目录：

1.建议

2.知识点

3.Dagger2使用篇

4.Retrofit+RxJava+OkHttp -封装篇

建议：

android SDK