Android: Điều gì tốt hơn - nhiều hoạt động hay chuyển đổi chế độ xem theo cách thủ công?

Tôi đã phát triển một số ứng dụng cho Android và câu hỏi này luôn luôn:

Tôi nên cấu trúc giao diện người dùng của mình như thế nào? Tôi có nên khởi chạy hoạt động sau khi hoạt động và để điện thoại tạo nút "quay lại" hay tôi nên chọn tối ưu hóa hơn, nhưng phức tạp hơn để triển khai, bằng cách chuyển Chế độ xem theo cách thủ công và sau đó thực hiện chức năng nút "Quay lại" theo cách thủ công?

Bạn nghĩ (hoặc biết) cách thực hành tốt hơn là gì?

Tôi muốn nói rằng nhiều Hoạt động hầu như luôn có ý nghĩa hơn. Tôi không nghĩ rằng Android được thiết kế để liên tục chuyển đổi quan điểm của riêng nó - bạn đã bỏ lỡ rất nhiều điều. Bạn phải tự mình thực hiện Quay lại, bạn không nhận được bất kỳ chuyển đổi giữa các Hoạt động nào, bạn phải thực hiện nhiều logic nội bộ để tiếp tục ứng dụng ở trạng thái chính xác. Nếu bạn không phân vùng ứng dụng của mình thành Hoạt động, thì việc thay đổi luồng ứng dụng sau này sẽ khó khăn hơn rất nhiều. Nó cũng dẫn đến một mega-Activity có thể khó xử lý hơn rất nhiều đoạn mã nhỏ hơn.

Tôi khó tưởng tượng rằng tốc độ thực sự là một vấn đề; nếu đúng như vậy thì có điều gì đó không ổn với cách bạn đang khởi tạo mỗi Hoạt động. Ví dụ: tôi đã cố gắng chuyển các đối tượng có thể nối tiếp giữa các Hoạt động và điều đó được chứng minh là cực kỳ chậm; khi tôi chuyển sang phương pháp chuyền vật thể nhanh hơn, tốc độ khởi chạy Hoạt động tăng lên đáng kể.

Ngoài ra, tôi nghĩ rằng các nguyên tắc của Android về Thiết kế Hoạt động và Tác vụ hoàn toàn không đề cập đến việc chuyển đổi Chế độ xem; nó tập trung vào thiết kế Activity-as-View.

Tôi muốn chỉ ra một số trường hợp khi một hoạt động đơn lẻ có thể là thiết kế tốt hơn cho một ứng dụng Android có nhiều hơn một Chế độ xem toàn màn hình:

• Nếu các màn hình ứng dụng được ghép nối chặt chẽ và chia sẻ một Đối tượng chung mà tất cả chúng đều đang hoạt động. Trong trường hợp này, việc truyền xung quanh Đối tượng có thể yêu cầu một Gói và có thể dễ xảy ra lỗi vì sẽ có các bản sao của nó. Một ví dụ điển hình có thể là một thuật sĩ . Có, bạn có thể sử dụng static để truy cập Object chung nhưng static có thể nguy hiểm trong Android (hãy nghĩ đến việc thay đổi cấu hình!)

• Nếu bạn muốn một số hoạt ảnh thực sự thú vị giữa các màn hình. Có thể bạn muốn một con chim cất cánh ở một màn hình và hạ cánh ở màn hình khác. Hãy thử làm điều đó khi mỗi màn hình là một hoạt động!

Mặt khác, nếu một trong các màn hình của bạn được thiết kế để hiển thị bởi bất kỳ ứng dụng nào khác thì màn hình đó phải là Hoạt động của chính nó.

CẬP NHẬT tháng 3 năm 2014:

Tại thời điểm này, câu hỏi bây giờ nên bao gồm sự lựa chọn của Fragment. Tôi nghĩ rằng Chế độ xem có lẽ là lựa chọn ít có khả năng nhất trong 3: Hoạt động, Phân mảnh, Chế độ xem. Nếu bạn muốn triển khai các màn hình sử dụng nút quay lại thì đó phải là Hoạt động hoặc Phân đoạn vì cả hai đều xử lý nút quay lại nguyên bản. Các mảnh sẽ cần được thêm vào ngăn xếp lại FragmentManager để nút quay lại hoạt động. Mặc dù vậy, việc quản lý các phân đoạn, hộp thoại và ngăn xếp phía sau có thể hơi khó chịu!

CẬP NHẬT Tháng 9 năm 2018:

Một số nhà phát triển tại Google đang đề xuất các ứng dụng hoạt động đơn lẻ bằng cách sử dụng thành phần kiến ​​trúc điều hướng mới .

Cũng nên nhớ rằng việc triển khai ứng dụng của bạn với nhiều ứng dụng Activitiessẽ mang lại cho người dùng trải nghiệm chặt chẽ hơn với toàn bộ nền tảng. Một phần của trải nghiệm sẽ được định hình bằng cách sử dụng các ứng dụng Google cài sẵn, vì vậy người dùng có thể sẽ dễ dàng sử dụng ứng dụng của bạn hơn nếu ứng dụng hoạt động tương tự như các ứng dụng đã được cài đặt trên điện thoại.

Khác với những người khác, tôi sử dụng kết hợp cả hai, ví dụ:
1. Có một menu chính khi ứng dụng khởi động
2. Bạn nhấp vào tìm kiếm, đưa bạn đến hoạt động tìm kiếm
3. Sau đó, có một nút bộ lọc, chỉ chuyển chế độ xem và hiển thị bạn lọc các tùy chọn
4. Có hai nút ở cuối chế độ xem bộ lọc, Bạn nhấn "Tìm kiếm" hoặc "Hủy" và bạn quay lại Chế độ xem tìm kiếm một lần nữa (không chuyển đổi hoạt động)
5. Bây giờ nếu người dùng nhấn điện thoại trở lại anh ấy được đưa trở lại menu chính thay vì các tùy chọn bộ lọc tìm kiếm. Mà tôi đoán là hành vi chính xác.

Sử dụng nó theo cách người dùng sẽ cảm thấy tự nhiên. Và giữ mọi thứ trong một hoạt động sẽ làm cho nó trở nên phức tạp.

Tất cả phụ thuộc vào ứng dụng, bạn đang cố gắng gì để đạt được hiệu suất tốt hơn, giao diện người dùng mượt mà hơn. IMHO Tôi thích cách tiếp cận thứ hai là kiểm soát các Hoạt động theo cách thủ công ngay cả khi nó phức tạp hơn như bạn đã nêu. Đây là một cách tiếp cận mà tôi đã sử dụng trong dự án tab android của mình, bạn cũng có thể muốn xem một lớp có tên ActivityGroup (không chắc là gói) nó cho phép bạn có nhiều hoạt động mà bạn có thể chuyển đổi giữa các hoạt động, điều tốt về lớp này là các hoạt động của bạn không bị dỡ bỏ khi bạn chuyển đổi nhưng điều tồi tệ là phải mất nhiều thời gian hơn để tải ứng dụng chính của bạn.

Chỉ là ý kiến ​​của tôi.

Vấn đề với việc chuyển đổi chế độ xem, mà tôi đã vấp phải, cũng do người thu gom rác gây ra. Có vẻ như GC được kích hoạt khi bạn rời khỏi hoạt động chứ không phải chế độ xem. Vì vậy, việc thay đổi các tab có chế độ xem con khá phức tạp, chẳng hạn, gần như chắc chắn sẽ dẫn đến ngoại lệ tràn ngăn xếp ..

Tôi đã gặp rất nhiều vấn đề với bố cục nhiều hoạt động và tôi thực sự không khuyến khích nó, trừ khi có lý do chính đáng để chọn nó.

Bất lợi của nhiều hoạt động

Sử dụng nhiều hoạt động, rất khó để cấu trúc lại mã để trả lại dữ liệu từ hoạt động.

Nếu bạn gọi một hoạt động 'phụ' thì hoạt động chính có thể bị hủy. Nhưng bạn không bao giờ gặp phải điều đó trong khi gỡ lỗi trên một thiết bị tốt, do đó bạn cần phải xử lý trạng thái luôn lưu và trạng thái khôi phục chính xác. Đó là một nỗi đau. Hãy tưởng tượng việc gọi một phương thức trên một thư viện (tức là một hoạt động khác) và bạn sẽ phải đảm bảo rằng khi phương thức đó trả về, ứng dụng của bạn phải có thể tạo lại trạng thái của nó hoàn toàn với tất cả các trường trên tất cả các đối tượng trong VM (tức là hoạt động. restoreIntance). Điên rồ của nó.

Ngoài ra, ngược lại, khi bạn mở hoạt động phụ, máy ảo có thể đã bị giết vì hoạt động phụ lần đầu tiên được sinh ra, chẳng hạn như khi ứng dụng được thu nhỏ trong khi hoạt động phụ được hiển thị.

Thật là gọn gàng hơn khi chỉ có một nơi để lưu trữ trạng thái ứng dụng có liên quan và trong trường hợp của tôi, thường xuyên nhất nếu VM bị giết, tôi muốn đưa người dùng trở lại màn hình chính và để họ làm lại công việc của mình, bởi vì tôi không không dành 30-50 giờ để viết mã lưu / tiếp tục chức năng mà 0,1% người dùng sẽ từng trải nghiệm.

Thay thế

Phân đoạn hoặc chỉ quản lý các lượt xem hoạt động của chính bạn. Quản lý chế độ xem theo cách thủ công, yêu cầu mã hóa một số thay thế chuyển đổi chế độ xem cho các hoạt động / phân đoạn có chuyển đổi nếu muốn.

Và không, nó không có nghĩa là một hoạt động lớn, như được đề xuất trong câu trả lời được chấp nhận, theo bất kỳ cách nào khác với một siêu ứng dụng của nó. Nó chỉ yêu cầu thêm một chút thiết kế cơ sở mã thành các mảnh phù hợp, bởi vì có nhiều công việc hơn trong việc quản lý các khung nhìn, mặc dù ít công việc hơn trong việc quản lý trạng thái hoạt động và những điều kỳ lạ khác.

Có thể có liên quan: Reddit: Chính thức: Google chính thức đề xuất kiến ​​trúc ứng dụng hoạt động đơn lẻ