Tôi có nên tuyệt đối tránh sử dụng enum trên Android không?

Tôi đã sử dụng để xác định một tập hợp các hằng số liên quan như Bundlecác khóa với nhau trong một giao diện như bên dưới:

public interface From{
    String LOGIN_SCREEN = "LoginSCreen";
    String NOTIFICATION = "Notification";
    String WIDGET = "widget";
}

Điều này cung cấp cho tôi một cách tốt hơn để nhóm các hằng số có liên quan với nhau và sử dụng chúng bằng cách thực hiện nhập tĩnh (không phải thực hiện). Tôi biết Androidkhuôn khổ cũng sử dụng các hằng số trong cùng một cách như Toast.LENTH_LONG, View.GONE.

Tuy nhiên, tôi thường cảm thấy rằng cách Java Enumscung cấp tốt hơn và mạnh mẽ hơn nhiều để biểu diễn hằng số.

Nhưng có vấn đề về độ bền khi sử dụng enumstrên Androidkhông?

Với một chút nghiên cứu, cuối cùng tôi đã bối rối. Từ câu hỏi "Tránh Enums nơi bạn chỉ cần kiến" này đã bị xóa khỏi các mẹo về hiệu suất của Android? Rõ ràng là Googleđã xóa "Tránh enums" khỏi các mẹo về hiệu suất của nó, nhưng từ tài liệu đào tạo chính thức của nó, hãy lưu ý phần chi phí bộ nhớ có ghi rõ ràng: "Enums thường yêu cầu bộ nhớ nhiều hơn gấp đôi so với hằng số tĩnh. Bạn nên tránh tuyệt đối việc sử dụng enum trên Android. " Điều này vẫn tốt chứ? (Nói trong Javacác phiên bản sau 1.6)

Một vấn đề nữa mà tôi quan sát thấy là để gửi enumsqua intentssử dụng, Bundletôi nên gửi chúng bằng cách tuần tự hóa (tức là putSerializable()tôi nghĩ rằng một hoạt động đắt tiền so với putString()phương pháp nguyên thủy , eventhough enumscung cấp nó miễn phí).

Ai đó có thể vui lòng làm rõ cái nào là cách tốt nhất để đại diện giống nhau Androidkhông? Tôi có nên tuyệt đối tránh sử dụng enumstrên Androidkhông?

Sử dụng enumkhi bạn cần các tính năng của nó. Đừng tránh nó một cách nghiêm ngặt .

Java enum mạnh hơn, nhưng nếu bạn không cần các tính năng của nó, hãy sử dụng hằng số, chúng chiếm ít dung lượng hơn và chúng có thể là nguyên thủy.

Khi nào sử dụng enum:

• gõ kiểm tra - bạn có thể chấp nhận chỉ giá trị niêm yết, và họ không liên tục (xem dưới đây những gì tôi gọi là liên tục tại đây)

• nạp chồng phương thức - mọi hằng số enum đều có cách triển khai phương thức riêng của nó
  

  public enum UnitConverter{
      METERS{
          @Override
          public double toMiles(final double meters){
              return meters * 0.00062137D;
          }
  
          @Override
          public double toMeters(final double meters){
              return meters;
          }
      },
      MILES{
          @Override
          public double toMiles(final double miles){
              return miles;
          }
  
          @Override
          public double toMeters(final double miles){
              return miles / 0.00062137D;
          }
      };
  
      public abstract double toMiles(double unit);
      public abstract double toMeters(double unit);
  }

• nhiều dữ liệu hơn - một hằng số của bạn chứa nhiều thông tin không thể được đưa vào một biến

• dữ liệu phức tạp - nhu cầu liên tục của bạn các phương pháp để vận hành trên dữ liệu

Khi nào không sử dụng enum:

• bạn có thể chấp nhận tất cả các giá trị của một kiểu và hằng số của bạn chỉ chứa những giá trị được sử dụng nhiều nhất này

• bạn có thể chấp nhận dữ liệu liên tục
  

  public class Month{
      public static final int JANUARY = 1;
      public static final int FEBRUARY = 2;
      public static final int MARCH = 3;
      ...
  
      public static String getName(final int month){
          if(month <= 0 || month > 12){
              throw new IllegalArgumentException("Invalid month number: " + month);
          }
  
          ...
      }
  }

• cho tên (như trong ví dụ của bạn)
• cho mọi thứ khác mà thực sự không cần enum

Enums chiếm nhiều không gian hơn

• một tham chiếu duy nhất đến một hằng số enum chiếm 4 byte
• mọi hằng số enum chiếm không gian là tổng kích thước của các trường của nó được căn chỉnh thành 8 byte + chi phí của đối tượng
• bản thân lớp enum chiếm một số không gian

Hằng số chiếm ít không gian hơn

• một hằng số không có tham chiếu vì vậy nó là một dữ liệu thuần túy (ngay cả khi nó là một tham chiếu, thì trường hợp enum sẽ là một tham chiếu đến một tham chiếu khác)
• hằng số có thể được thêm vào một lớp hiện có - không cần thiết phải thêm một lớp khác
• hằng số có thể được nội dòng; nó mang đến các tính năng thời gian biên dịch kéo dài (chẳng hạn như kiểm tra null, tìm mã chết, v.v.)

Nếu enums chỉ có giá trị, bạn nên thử sử dụng IntDef / StringDef, như được hiển thị ở đây:

https://developer.android.com/studio/write/annotations.html#enum-annotations

Ví dụ: thay vì:

enum NavigationMode {NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS} 

bạn sử dụng:

@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST, NAVIGATION_MODE_TABS})
@Retention(RetentionPolicy.SOURCE)
public @interface NavigationMode {}

public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;

và trong hàm có nó làm tham số / giá trị trả về, hãy sử dụng:

@NavigationMode
public abstract int getNavigationMode();

public abstract void setNavigationMode(@NavigationMode int mode);

Trong trường hợp enum phức tạp, hãy sử dụng một enum. Nó không tệ.

Để so sánh enums với giá trị không đổi, bạn nên đọc ở đây:

http://hsc.com/Blog/Best-Practices-For-Memory-Optimization-on-Android-1

Ví dụ của họ là một enum có 2 giá trị. Nó chiếm 1112 byte trong tệp dex so với 128 byte khi sử dụng số nguyên hằng số. Có lý, vì enums là các lớp thực, trái ngược với cách nó hoạt động trên C / C ++.

Ngoài các câu trả lời trước, tôi sẽ nói thêm rằng nếu bạn đang sử dụng Proguard (và bạn chắc chắn nên làm điều đó để giảm kích thước và làm xáo trộn mã của mình), thì của bạn Enumssẽ được tự động chuyển đổi thành @IntDefbất cứ nơi nào có thể:

https://www.guardsquare.com/en/proguard/manual/optimizations

class / unboxing / enum

Đơn giản hóa các kiểu enum thành hằng số nguyên, bất cứ khi nào có thể.

Do đó, nếu bạn có một số giá trị rời rạc và một số phương thức chỉ cho phép lấy các giá trị này chứ không phải các giá trị khác cùng loại, thì tôi sẽ sử dụng Enum, vì Proguard sẽ thực hiện công việc tối ưu hóa mã thủ công này cho tôi.

Và đây là một bài viết hay về cách sử dụng enums từ Jake Wharton, hãy xem nó.

Với tư cách là nhà phát triển thư viện, tôi nhận ra những tối ưu hóa nhỏ này nên được thực hiện khi chúng tôi muốn tác động ít nhất đến kích thước, bộ nhớ và hiệu suất của ứng dụng tiêu thụ càng tốt. Nhưng điều quan trọng là phải nhận ra rằng [...] việc đặt một enum trong API công khai của bạn so với các giá trị số nguyên nếu thích hợp là hoàn toàn tốt. Biết sự khác biệt để đưa ra quyết định sáng suốt là điều quan trọng

Tôi có nên tuyệt đối tránh sử dụng enum trên Android không?

Không. " Nghiêm túc " có nghĩa là chúng quá tệ, chúng hoàn toàn không nên được sử dụng. Có thể một vấn đề về hiệu suất có thể phát sinh trong một tình huống cực đoan như nhiều (hàng nghìn hoặc hàng triệu) hoạt động với enum (liên tiếp trên chuỗi ui). Phổ biến hơn rất nhiều là các hoạt động I / O mạng sẽ diễn ra nghiêm ngặt trong một chuỗi nền. Việc sử dụng phổ biến nhất của sự đếm có lẽ là một số loại kiểu kiểm tra - cho dù một đối tượng là này hay rằng đó là quá nhanh, bạn sẽ không thể nhận thấy một sự khác biệt giữa một so sánh duy nhất của sự đếm và so sánh các số nguyên.

Ai đó có thể vui lòng làm rõ cái nào là cách tốt nhất để đại diện giống nhau trong Android không?

Không có quy tắc chung cho điều này. Sử dụng bất kỳ thứ gì phù hợp với bạn và giúp bạn sẵn sàng ứng dụng. Tối ưu hóa sau - sau khi bạn nhận thấy có một nút thắt cổ chai làm chậm một số khía cạnh của ứng dụng của bạn.

Với Android P, google không có hạn chế / phản đối trong việc sử dụng enums

Tài liệu đã thay đổi nơi trước đây được khuyến cáo nên thận trọng nhưng hiện tại nó không đề cập đến. https://developer.android.com/reference/java/lang/Enum

Hai sự thật.

1, Enum là một trong những tính năng mạnh nhất trong JAVA.

2, Điện thoại Android thường có rất nhiều bộ nhớ.

Vì vậy, câu trả lời của tôi là KHÔNG. Tôi sẽ sử dụng Enum trong Android.

Tôi muốn nói thêm rằng bạn không thể sử dụng @Annotations khi bạn khai báo Danh sách <> hoặc Bản đồ <> trong đó khóa hoặc giá trị là của một trong các giao diện chú thích của bạn. Bạn gặp lỗi "Chú thích không được phép ở đây".

enum Values { One, Two, Three }
Map<String, Values> myMap;    // This works

// ... but ...
public static final int ONE = 1;
public static final int TWO = 2;
public static final int THREE = 3;

@Retention(RetentionPolicy.SOURCE)
@IntDef({ONE, TWO, THREE})
public @interface Values {}

Map<String, @Values Integer> myMap;    // *** ERROR ***

Vì vậy, khi bạn cần đóng gói nó thành một danh sách / bản đồ, hãy sử dụng enum, vì chúng có thể được thêm vào, nhưng các nhóm int / string @annotated thì không.