Tại sao các loại xây dựng khác biệt với hương vị sản phẩm?


173

Lời nói đầu: đây không phải là câu hỏi về cách sử dụng loại xây dựng và hương vị sản phẩm trong ứng dụng Android. Tôi hiểu các khái niệm cơ bản liên quan. Câu hỏi này liên quan nhiều hơn đến việc cố gắng hiểu cấu hình nào sẽ được chỉ định trong loại bản dựng, cấu hình nào sẽ được chỉ định trong hương vị sản phẩm và liệu có bất kỳ sự phân biệt nào thực sự cần thiết hay không.

Tuần này, tôi đã tìm hiểu thêm về cấu hình lớp cho các ứng dụng Android. Ban đầu tôi nghĩ rằng tôi đã xử lý tốt các loại xây dựng so với hương vị sản phẩm, nhưng càng đi sâu vào tài liệu tôi càng nhận ra sự khác biệt giữa hai loại này đối với tôi không rõ ràng.

Vì có một hệ thống phân cấp được xác định rõ (theo nghĩa các thuộc tính được chỉ định trong các loại xây dựng được ưu tiên hơn các loại được chỉ định trong các hương vị sản phẩm), tôi không hiểu tại sao cần phải phân biệt giữa các loại xây dựng và hương vị sản phẩm. Sẽ không tốt hơn nếu hợp nhất tất cả các thuộc tính và phương thức vào đối tượng DSL hương vị sản phẩm, và sau đó chỉ coi loại xây dựng là thứ nguyên hương vị (mặc định)?

Một số ví dụ cụ thể dẫn đến sự nhầm lẫn của tôi:

  • Các signingConfigbất động sản có thể được thiết lập trong cả xây dựng các loại và hương vị sản phẩm ... nhưng minifyEnabled(và, tôi giả sử, shrinkResources?) Chỉ có thể được cấu hình trong xây dựng các loại.

  • applicationIdchỉ có thể được chỉ định trong hương vị sản phẩm ... và applicationIdSuffixchỉ có thể được chỉ định trong các loại bản dựng!?

Câu hỏi thực tế :

Cho các ví dụ trên: có sự phân biệt rõ ràng giữa vai trò của các loại xây dựng và hương vị sản phẩm không?

Nếu vậy, cách tốt nhất để hiểu nó là gì?

Nếu không, kế hoạch cuối cùng là hợp nhất các loại xây dựng và hương vị sản phẩm thành một đối tượng DSL có thể cấu hình được không?


55
"cấu hình nào sẽ được chỉ định trong loại xây dựng, cấu hình nào sẽ được chỉ định trong hương vị sản phẩm" - loại xây dựng mô hình vòng đời phát triển của bạn (gỡ lỗi, "dogfood", phát hành, v.v.). Hương vị sản phẩm mô hình chiến lược phân phối của bạn (Google IAP so với Amazon IAP so với BlackBerry IAP, v.v.). Đây là những khái niệm độc lập. Đối với phần còn lại, tôi sẽ tưởng tượng rằng có những lý do kỹ thuật gắn liền với việc triển khai chỉ ra một chút cách họ thiết lập DSL, và do đó tôi sẽ ngạc nhiên nếu có kế hoạch sáp nhập.
CommonsWare

1
@CommonsWare có ý nghĩa ở mức cao. Và vâng, có lẽ việc xử lý tuần tự các loại / hương vị hạn chế cách thức và thời điểm người ta có thể thay đổi toàn bộ applicationId, chẳng hạn.
stbest

Câu trả lời:


167

Mở rộng về những gì @CommonsWare đã nói trong các nhận xét, ý tưởng cơ bản là các loại bản dựng dành cho các bản dựng khác nhau của ứng dụng của bạn không khác nhau về chức năng - nếu bạn có phiên bản gỡ lỗi và phát hành ứng dụng, chúng là cùng một ứng dụng , nhưng một mã chứa mã gỡ lỗi, có thể ghi nhật ký nhiều hơn, v.v. và mã kia được sắp xếp hợp lý và tối ưu hóa và có thể bị xáo trộn thông qua ProGuard. Với hương vị, mục đích là ứng dụng này khác biệt đáng kể theo một cách nào đó. Ví dụ rõ ràng nhất sẽ là phiên bản miễn phí so với phiên bản ứng dụng của bạn, nhưng các nhà phát triển cũng có thể phân biệt dựa trên nơi phân phối (có thể ảnh hưởng đến việc sử dụng API thanh toán trong ứng dụng).

Có những nhà phát triển tạo ra nhiều, nhiều phiên bản khác nhau của một ứng dụng tương tự cho các khách hàng khác nhau - một ví dụ có thể là một ứng dụng đơn giản mở ra một trang web trong chế độ xem web, với các URL và nhãn hiệu khác nhau cho mỗi phiên bản - đây là một sử dụng tốt các hương vị.

Để nhắc lại, nếu đó là "cùng một ứng dụng", hãy sửa đổi một số khác biệt không quan trọng đối với người dùng cuối và đặc biệt là nếu tất cả các biến thể ngoại trừ một biến thể đều được sử dụng cho thử nghiệm và phát triển của riêng bạn và chỉ một biến thể sẽ được triển khai người dùng cuối, thì đó là một ứng cử viên tốt cho các kiểu xây dựng. Nếu đó là một ứng dụng "khác biệt" và nhiều biến thể sẽ được triển khai cho người dùng, thì có lẽ đó là một ứng cử viên cho hương vị sản phẩm.

Bạn đã thấy rằng có một số khác biệt về chức năng giữa các loại bản dựng và hương vị, trong đó một số tùy chọn được hỗ trợ cho một loại nhưng không phải loại khác. Nhưng các khái niệm là khác nhau mặc dù chúng giống nhau và không có kế hoạch hợp nhất chúng lại với nhau.


17
Cảm ơn, Scott. Tôi chắc chắn nghĩ rằng sự khác biệt này có ý nghĩa (và các tên 'loại xây dựng' và 'hương vị sản phẩm' phù hợp cho việc sử dụng này). Có lẽ người ta có thể hiểu applicationIdvấn đề như sau: vì các hương vị đại diện cho các phiên bản "hoàn toàn khác nhau" của ứng dụng của bạn, nên có thể chỉ định các id ứng dụng "hoàn toàn" khác nhau; trong khi đó, đối với một hương vị cố định, tất cả các loại bản dựng đều đại diện cho ứng dụng "giống nhau" và do đó chỉ được phép thay đổi hậu tố id ứng dụng (do đó giữ lại 'nhóm' các id ứng dụng).
stbest

28

buildType cấu hình cách chúng tôi gói ứng dụng của chúng tôi

  • nguồn thu nhỏ
  • progaurdFile
  • Vân vân.

Hương vị cấu hình các lớp và tài nguyên khác nhau.

  • trong Flavor1 MainActivity của bạn có thể làm một cái gì đó và trong Flavor2 thực hiện khác nhau

  • tên ứng dụng khác nhau

  • Vân vân.

Mỗi hương vị sản phẩm có thể có các giá trị riêng của các thuộc tính sau, trong số các thuộc tính khác, dựa trên cùng các thuộc tính từ defaultConfig:

  • applicationId
  • minSdkVersion
  • targetSdkVersion
  • versionCode
  • versionName

9

Đây là cách tôi chắt lọc sự khác biệt xuống bản chất của nó:

  • buildTypecách xây dựng.
  • flavornhững gì của bản dựng.

0

Chúng build typesđược sử dụng để chỉ debug/releasechế độ với các chứng chỉ khác nhau và bật Proguardhoặc debuggablegắn cờ.

Chúng flavorsđược sử dụng để có các tính năng tùy chỉnh (ví dụ: phiên bản miễn phí hoặc trả phí), minimum and target APIcác yêu cầu về cấp độ, thiết bị và API như layout, drawabledo đó bạn có thể có các mã và tài nguyên khác nhau theo các cách khác nhau flavors.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.