优先使用注解，慎用枚举

纯常量场景

分组且存在对应关系

小结
1 万能的枚举

2 枚举对于性能的损耗

3 寻找替代方案

分组常量
1 注解一般使用步骤

2 补充

总结

转载请注明出处：http://blog.csdn.net/my_truelove/article/details/70519234

访问 ruicb.com，一键抵达我的博客！

之前写过一篇 使用枚举代替常量，简化工作！，介绍了使用枚举如何使得程序更加优雅、健壮，该文章一度成为我博客访问量最高的一篇。如果还没看，建议先扫一眼，再继续看本文。

虽然我今天要打脸，介绍如何使用注解，慎用枚举，但其实在之前的文章最后，我很明显的提议大家分场景的使用：

最后，声明一点，我所说的使用枚举替换常量，是针对类似于 “常量之间存在关联” 的情况，并不是说以后所有常量都写成枚举，毕竟官方是不推荐使用枚举的。所以在实际开发中，还需要根据实际使用场景去斟酌，杜绝滥用。

为了让读者更好的区分常量、注解和枚举的使用场景，我将分别就不同的场景，为大家介绍相应的使用方案：

纯常量场景：常量只是作为全局配置数据使用；

分组常量场景：归属于同一分组的常量；

分组且存在对应关系的常量场景：常量归属于同一分组，且另一方面常量之间存在对应关系。

1. 纯常量场景

这里的常量，主要是用来作为全局的配置项使用，如下

GlobalContants

：

public class GlobalContants {
public static final int MAX_THREAD_NUM = 3;
public static final String DOWNLOAD_DIR = "download";
public static final float PI = 3.14f;
}

大概就这个意思，记得大学期间这种方式使用最多了，很基础的东西，不再展开讲了。

2. 分组且存在对应关系

我们先来看看 分组且存在对应关系 的常量我们应该如何处理，假设你已经看过我那篇推荐枚举的文章了，我就直接说了。

public enum TaskStatus {

UN_KNOW(-1, "未知", "#84807f"),
UN_START(0, "未开始", "#e2d512"),
PROGRESSING(1, "进行中", "#12ea2f"),
COMPLETED(2, "已完成", "#c30910");

int mCode;
String mDesc;
String mColor;

TaskStatus(int code , String desc , String color){
mCode = code;
mDesc = desc;
mColor = color;
}

public static TaskStatus getTaskStatus(int status) {
for (TaskStatus taskStatus : values()) {
if (status == taskStatus.mCode) {
return taskStatus;
}
}
return UN_START;
}
}

上述代码，我们用枚举实现了一个常量分组，且常量之间存在对应关系的功能。

这里的常量分组，指的就是一组任务状态，简化上述代码来看：

public enum TaskStatus {
UN_KNOW,
UN_START,
PROGRESSING,
COMPLETED
}

我们一眼就能看出

TaskStatus

包含这样一组状态。

而常量间对应关系，指的是：

UN_KNOW(-1, "未知", "#84807f"),
UN_START(0, "未开始", "#e2d512"),
PROGRESSING(1, "进行中", "#12ea2f"),
COMPLETED(2, "已完成", "#c30910");

以

UN_KNOW

状态为例，分别由对应的状态码、描述和色值组成，以此实现常量间的对应关系。

很难想象，在这种场景下，如果你不使用枚举，而是：

在

GlobalContants

中定义状态码

在

string.xml

中定义描述

在

colors.xml

中定义色值

我想，终有一天你会隐约听到代码松动的声音，那真的不是幻觉。

3. 小结

哦，这不是总结，还没完呢。

至此，你已经明白常量和枚举的使用了，确实在对应场景下，像上述那样使用没有任何问题。现在我们梳理下，抛出问题，来引出注解的使用。

3.1 万能的枚举

现在，有这样一个场景，我们仅仅需要根据一组状态中的某一状态执行相应的操作，不需要多个常量之间相互对应。

你自然会想到枚举的简化版：

public enum TaskStatus {
UN_KNOW,
UN_START,
PROGRESSING,
COMPLETED
}

然后定义了一个任务辅助类：

import com.ruicb.enumdemo.TaskStatus;

public class TaskHelper {

public static void doSth(TaskStatus status){
switch (status){
case UN_KNOW:
//do something
break;
case UN_START:
break;
case PROGRESSING:
break;
case COMPLETED:
break;
}
}
}

然后如此调用：

TaskHelper.doSth(TaskStatus.COMPLETED);

这样使用枚举，十分优雅：

保证了类型安全：调用者无法随意传一个 int 值；

代码可读性非常高；

但是…

3.2 枚举对于性能的损耗

事实上你也知道，官方是不建议使用枚举的，这个在文章开头简单说了。

想详细了解的，可以参考该博文：http://blog.csdn.net/hp910315/article/details/48975655

同时，官方发布了有关枚举的视频

The price of ENUMs

，你可以直接看视频：

YouTube

优酷

总之，与静态常量相比，枚举会增大应用程序编译后的 dex 文件，同时应用在运行时的内存占用也会升高。在资源有限的移动设备上，大量的使用枚举无疑是致命的。

3.3 寻找替代方案

既然如此，我们不使用枚举不就行了吗？反正只是简单的单一状态，我单独定义一个常量类，实现分组：

/**
* 任务状态常量
*/
public class TsakContants {
public static final int UN_KNOW = -1;
public static final int UN_START = 0;
public static final int PROGRESSING = 1;
public static final int COMPLETED = 2;
}

然后修改

doSth()

方法：

public class TaskHelper {

public static void doSth(int status){
switch (status){
case TsakContants.UN_KNOW:
//do something
break;
case TsakContants.UN_START:
break;
case TsakContants.PROGRESSING:
break;
case TsakContants.COMPLETED:
break;
}
}
}

调用起来也没有区别：

TaskHelper.doSth(TsakContants.COMPLETED);

上述代码达到了和枚举一样的效果，完全可以不使用枚举。可是，让我再回到使用枚举的好处：

保证了类型安全：调用者无法随意传一个 int 值；

代码可读性非常高；

反过来对比看，向上面那样使用常量会有什么问题:

首先，我们无法保障类型安全，用户可以在调用时传入任何一个 int 值：

TaskHelper.doSth(100);

其次代码可读性很差，IDE 只是提示传入

int

类型的参数。此时如果不看方法体，调用者根本不知道该传什么值。

那么问题来了？在一组常量的情况下，我们使用枚举太重，使用常量不安全、可读性差，我们该怎么办？

当然是使用注解了！哈哈，兜了一圈终于轮到注解，是时候为其正名啦。

4. 分组常量

假设你知道注解的用法，不知道也没关系，很简单。比如定义一个注解：

public @interface TaskStatus {

}

是的，类似于接口的定义，加个

@

符号。

4.1 注解一般使用步骤

那么对于上面的枚举和常量都不 work 的场景，如何使用枚举解决呢？

定义注解类，添加常量

@Retention(RetentionPolicy.SOURCE)
public @interface TaskStatus {
int UN_KNOW = -1;
int UN_START = 0;
int PROGRESSING = 1;
int COMPLETED = 2;
}

和接口成员一样，注解类的成员默认就是

public static final

修饰的。

@Retention(RetentionPolicy.SOURCE)

表示告诉编译器，该注解是源代码级别的，生成 class 文件的时候这个注解就被编译器自动去掉了。

修改

doSth()

方法：

public class TaskHelper {

public static void doSth(@TaskStatus int status){
switch (status){
case TaskStatus.UN_KNOW:
//do something
break;
case TaskStatus.UN_START:
break;
case TaskStatus.PROGRESSING:
break;
case TaskStatus.COMPLETED:
break;
}
}
}

可以看出，

doSth()

方法的参数是 int 类型的，但是使用

@TaskStatus

进行了注解，这样外界就无法传递

TaskStatus

之外的成员作为参数了。

调用

TaskHelper.doSth(TaskStatus.UN_START);

在调用时，IDE 会提示

@TaskStatus int status

，提醒我们传入

TaskStatus

类型的值。

同时，调用者如果再随便传入一个

int

值，虽然可以运行，但代码会爆红，lint 检查将会给与警告：

Must be one of: TaskStatus.UN_KNOW, TaskStatus.UN_START, TaskStatus.PROGRESSING, TaskStatus.COMPLETED

如此，保证了类型安全。但也只是警告，仍然可以运行，但总比没有警告强多了。

4.2 补充

其实这种用法在 Android 源码中屡见不鲜，比如

Resources

下的

getDrawable()

方法：

public Drawable getDrawable(@DrawableRes int id) throws NotFoundException {
final Drawable d = getDrawable(id, null);
//...
return d;
}

使用时，我们一般会这么用：

getResources().getDrawable(R.drawable.ic_launcher);

虽然是

int

值，但是当我们这么用时：

getResources().getDrawable(111);

就会爆红并提示：

Expected resource of type drawable

再补充一点，为了防止在我们定义的常量值重复，我们还可以使用Android 注解支持库（support-annotations）中的

@IntDef

来限定常量不允许重复：

@IntDef({
TaskStatus.UN_KNOW,
TaskStatus.UN_START,
TaskStatus.PROGRESSING,
TaskStatus.COMPLETED
})
@Retention(RetentionPolicy.SOURCE)
public @interface TaskStatus {
int UN_KNOW = -1;
int UN_START = 0;
int PROGRESSING = 1;
int COMPLETED = 2;
}

以上，就这些。

5. 总结

好了，为注解正名了。现在看完本文之后再思考，你应该清楚什么场景下该使用那种方案了吧。

文章开头所说的三种场景，注意区分开就好了。之所以使用注解，是因为在一组常量的情况下，枚举太重，不要轻易使用；其次，使用常量会导致类型安全、可读性差等问题。

就酱，周末愉快。

扫描下方二维码，关注我的公众号，及时获取最新文章推送！