编写高效Android代码避免使用枚举

 避免使用枚举
枚举变量非常方便，但不幸的是它会牺牲执行的速度和并大幅增加文件体积。例如：

    public class Foo {
  public enum Shrubbery { GROUND, CRAWLING, HANGING }
}
会产生一个900字节的.class文件(Foo$Shubbery.class)。在它被首次调用时，这个类会调用初始化方法来准备每个枚举变量。每个枚举项都会被声明成一个静态变量，并被赋值。然后将这些静态变量放在一个名为"$VALUES"的静态数组变量中。而这么一大堆代码，仅仅是为了使用三个整数。

这样:

    Shrubbery shrub = Shrubbery.GROUND;会引起一个对静态变量的引用，如果这个静态变量是final int，那么编译器会直接内联这个常数。

一方面说，使用枚举变量可以让你的API更出色，并能提供编译时的检查。所以在通常的时候你毫无疑问应该为公共API选择枚举变量。但是当性能方面有所限制的时候，你就应该避免这种做法了。

    有些情况下，使用ordinal()方法获取枚举变量的整数值会更好一些，举例来说，将：

     for (int n = 0; n < list.size(); n++) {
   if (list.items[n].e == MyEnum.VAL_X)
      // do stuff 1
   else if (list.items[n].e == MyEnum.VAL_Y)
      // do stuff 2
}
替换为:

  int valX = MyEnum.VAL_X.ordinal();
  int valY = MyEnum.VAL_Y.ordinal();
  int count = list.size();
  MyItem items = list.items();

  for (int  n = 0; n < count; n++)
  {
       int  valItem = items[n].e.ordinal();

       if (valItem == valX)
         // do stuff 1
       else if (valItem == valY)
         // do stuff 2
  }
会使性能得到一些改善，但这并不是最终的解决之道。

    将与内部类一同使用的变量声明在包范围内
请看下面的类定义：

public class Foo {
   private int mValue;

   public void run() {
       Inner in = new Inner();
       mValue = 27;
       in.stuff();
   }

   private void doStuff(int value) {
       System.out.println("Value is " + value);
   }

   private class Inner {
       void stuff() {
           Foo.this.doStuff(Foo.this.mValue);
       }
   }
}
这其中的关键是，我们定义了一个内部类(Foo$Inner)，它需要访问外部类的私有域变量和函数。这是合法的，并且会打印出我们希望的结果"Value is 27"。

    问题是在技术上来讲（在幕后）Foo$Inner是一个完全独立的类，它要直接访问Foo的私有成员是非法的。要跨越这个鸿沟，编译器需要生成一组方法：

/*package*/ static int Foo.access$100(Foo foo) {
   return foo.mValue;
}
/*package*/ static void Foo.access$200(Foo foo, int value) {
   foo.doStuff(value);
}

    内部类在每次访问"mValue"和"doStuff"方法时，都会调用这些静态方法。就是说，上面的代码说明了一个问题，你是在通过接口方法访问这些成员变量和函数而不是直接调用它们。在前面我们已经说过，使用接口方法（getter、setter）比直接访问速度要慢。所以这个例子就是在特定语法下面产生的一个“隐性的”性能障碍。

    通过将内部类访问的变量和函数声明由私有范围改为包范围，我们可以避免这个问题。这样做可以让代码运行更快，并且避免产生额外的静态方法。（遗憾的是，这些域和方法可以被同一个包内的其他类直接访问，这与经典的OO原则相违背。因此当你设计公共API的时候应该谨慎使用这条优化原则）