Là AsyncTask thực sự thiếu sót về mặt khái niệm hay tôi chỉ thiếu một cái gì đó?

Tôi đã điều tra vấn đề này trong nhiều tháng nay, đưa ra các giải pháp khác nhau cho nó, điều mà tôi không hài lòng vì tất cả chúng đều là những vụ hack lớn. Tôi vẫn không thể tin rằng một lớp học thiếu sót trong thiết kế đã đưa nó vào khuôn khổ và không ai nói về nó, vì vậy tôi đoán rằng tôi chỉ cần thiếu một cái gì đó.

Vấn đề là với AsyncTask. Theo tài liệu đó

"cho phép thực hiện các thao tác nền và xuất bản kết quả trên luồng UI mà không phải thao tác với các luồng và / hoặc trình xử lý."

Ví dụ sau đó tiếp tục cho thấy một số showDialog()phương thức mẫu mực được gọi trong onPostExecute(). Tuy nhiên, điều này dường như hoàn toàn phù hợp với tôi, bởi vì hiển thị hộp thoại luôn cần tham chiếu đến hợp lệ Contextvà AsyncTask không bao giờ phải giữ tham chiếu mạnh đến đối tượng ngữ cảnh .

Lý do rất rõ ràng: nếu hoạt động bị phá hủy sẽ kích hoạt nhiệm vụ thì sao? Điều này có thể xảy ra mọi lúc, ví dụ như vì bạn lật màn hình. Nếu tác vụ giữ tham chiếu đến bối cảnh đã tạo ra nó, bạn không chỉ giữ một đối tượng bối cảnh vô dụng (cửa sổ sẽ bị hủy và mọi tương tác UI sẽ không thành công ngoại lệ!), Bạn thậm chí có nguy cơ tạo ra một ngoại lệ bộ nhớ bị rò rỉ.

Trừ khi logic của tôi bị thiếu sót ở đây, điều này có nghĩa onPostExecute()là : hoàn toàn vô dụng, bởi vì phương pháp này có ích gì khi chạy trên luồng UI nếu bạn không có quyền truy cập vào bất kỳ ngữ cảnh nào? Bạn không thể làm bất cứ điều gì có ý nghĩa ở đây.

Một cách giải quyết khác là không chuyển các thể hiện ngữ cảnh cho AsyncTask, mà là một Handlerthể hiện. Điều đó hoạt động: vì một Handler liên kết lỏng lẻo bối cảnh và nhiệm vụ, bạn có thể trao đổi tin nhắn giữa chúng mà không gặp rủi ro rò rỉ (phải không?). Nhưng điều đó có nghĩa là tiền đề của AsyncTask, cụ thể là bạn không cần bận tâm đến trình xử lý, là sai. Nó cũng có vẻ giống như lạm dụng Handler, vì bạn đang gửi và nhận tin nhắn trên cùng một luồng (bạn tạo nó trên luồng UI và gửi qua nó trong onPostExecute () cũng được thực thi trên luồng UI).

Trên hết, ngay cả với cách giải quyết đó, bạn vẫn có một vấn đề là khi bối cảnh bị phá hủy, bạn không có hồ sơ về các nhiệm vụ mà nó đã bắn. Điều đó có nghĩa là bạn phải bắt đầu lại bất kỳ tác vụ nào khi tạo lại bối cảnh, ví dụ sau khi thay đổi hướng màn hình. Điều này là chậm và lãng phí.

Giải pháp của tôi cho vấn đề này (như được thực hiện trong thư viện Droid-Fu ) là duy trì ánh xạ của WeakReferences từ tên thành phần đến các thể hiện tại của chúng trên đối tượng ứng dụng duy nhất. Bất cứ khi nào AsyncTask được khởi động, nó sẽ ghi lại ngữ cảnh gọi trong bản đồ đó và trên mỗi cuộc gọi lại, nó sẽ tìm nạp phiên bản ngữ cảnh hiện tại từ ánh xạ đó. Điều này đảm bảo rằng bạn sẽ không bao giờ tham chiếu một trường hợp bối cảnh cũ và bạn luôn có quyền truy cập vào một bối cảnh hợp lệ trong các cuộc gọi lại để bạn có thể thực hiện giao diện người dùng có ý nghĩa ở đó. Nó cũng không bị rò rỉ, bởi vì các tham chiếu yếu và bị xóa khi không còn trường hợp nào của một thành phần nhất định tồn tại nữa.

Tuy nhiên, đây là một cách giải quyết phức tạp và đòi hỏi phải phân lớp một số lớp thư viện Droid-Fu, làm cho cách tiếp cận này khá khó khăn.

Bây giờ tôi chỉ đơn giản muốn biết: Tôi chỉ thiếu ồ ạt một cái gì đó hay AsyncTask thực sự hoàn toàn thiếu sót? Kinh nghiệm của bạn làm việc với nó như thế nào? Làm thế nào bạn giải quyết những vấn đề này?

Cảm ơn vì đầu vào của bạn.

Còn những thứ như thế này thì sao:

class MyActivity extends Activity {
    Worker mWorker;

    static class Worker extends AsyncTask<URL, Integer, Long> {
        MyActivity mActivity;

        Worker(MyActivity activity) {
            mActivity = activity;
        }

        @Override
        protected Long doInBackground(URL... urls) {
            int count = urls.length;
            long totalSize = 0;
            for (int i = 0; i < count; i++) {
                totalSize += Downloader.downloadFile(urls[i]);
                publishProgress((int) ((i / (float) count) * 100));
            }
            return totalSize;
        }

        @Override
        protected void onProgressUpdate(Integer... progress) {
            if (mActivity != null) {
                mActivity.setProgressPercent(progress[0]);
            }
        }

        @Override
        protected void onPostExecute(Long result) {
            if (mActivity != null) {
                mActivity.showDialog("Downloaded " + result + " bytes");
            }
        }
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mWorker = (Worker)getLastNonConfigurationInstance();
        if (mWorker != null) {
            mWorker.mActivity = this;
        }

        ...
    }

    @Override
    public Object onRetainNonConfigurationInstance() {
        return mWorker;
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (mWorker != null) {
            mWorker.mActivity = null;
        }
    }

    void startWork() {
        mWorker = new Worker(this);
        mWorker.execute(...);
    }
}

Lý do rất rõ ràng: nếu hoạt động bị phá hủy sẽ kích hoạt nhiệm vụ thì sao?

Tự phân tách các hoạt động từ AsyncTasktrong onDestroy(). Bằng tay liên kết lại các hoạt động mới vào AsyncTasktrong onCreate(). Điều này đòi hỏi một lớp bên trong tĩnh hoặc một lớp Java tiêu chuẩn, cộng với có lẽ 10 dòng mã.

Có vẻ như AsyncTasklà một chút nhiều hơn chỉ là thiếu sót về mặt khái niệm . Nó cũng không thể sử dụng bởi các vấn đề tương thích. Các tài liệu Android đọc:

Khi được giới thiệu lần đầu tiên, AsyncT task đã được thực thi ser seri trên một luồng nền đơn. Bắt đầu với DONUT, điều này đã được thay đổi thành một nhóm các luồng cho phép nhiều tác vụ hoạt động song song. Bắt đầu HONEYCOMB, các tác vụ quay trở lại được thực thi trên một luồng duy nhất để tránh các lỗi ứng dụng phổ biến do thực thi song song. Nếu bạn thực sự muốn thực thi song song, bạn có thể sử dụng executeOnExecutor(Executor, Params...) phiên bản của phương thức này với THREAD_POOL_EXECUTOR ; tuy nhiên, xem bình luận ở đó để cảnh báo về việc sử dụng nó.

Cả hai executeOnExecutor()và THREAD_POOL_EXECUTORđược thêm vào API cấp 11 (Android 3.0.x, HONEYCOMB).

Điều này có nghĩa là nếu bạn tạo hai AsyncTaskgiây để tải xuống hai tệp, lần tải xuống thứ 2 sẽ không bắt đầu cho đến khi lần đầu tiên kết thúc. Nếu bạn trò chuyện qua hai máy chủ và máy chủ đầu tiên không hoạt động, bạn sẽ không kết nối với máy chủ thứ hai trước khi kết nối với máy chủ đầu tiên. (Tất nhiên trừ khi bạn sử dụng các tính năng API11 mới, nhưng điều này sẽ làm cho mã của bạn không tương thích với 2.x).

Và nếu bạn muốn nhắm mục tiêu cả 2.x và 3.0+, công cụ sẽ trở nên thực sự khó khăn.

Ngoài ra, các tài liệu nói:

Thận trọng: Một vấn đề khác bạn có thể gặp phải khi sử dụng luồng công nhân là khởi động lại bất ngờ trong hoạt động của bạn do thay đổi cấu hình thời gian chạy (chẳng hạn như khi người dùng thay đổi hướng màn hình), có thể phá hủy luồng công nhân của bạn . Để xem làm thế nào bạn có thể duy trì nhiệm vụ của mình trong một trong những lần khởi động lại này và cách hủy tác vụ đúng cách khi hoạt động bị hủy, hãy xem mã nguồn cho ứng dụng mẫu Kệ.

Có lẽ tất cả chúng ta, bao gồm cả Google, đang sử dụng sai AsyncTasktừ quan điểm MVC .

Một hoạt động là một Trình điều khiển và bộ điều khiển không nên bắt đầu các hoạt động có thể tồn tại lâu hơn Chế độ xem . Nghĩa là, AsyncT Nhiệm vụ nên được sử dụng từ Mô hình , từ một lớp không bị ràng buộc với vòng đời Hoạt động - hãy nhớ rằng Hoạt động bị hủy khi xoay vòng. (Đối với Chế độ xem , bạn thường không lập trình các lớp có nguồn gốc từ ví dụ android.widget.Button, nhưng bạn có thể. Thông thường, điều duy nhất bạn làm về Chế độ xem là xml.)

Nói cách khác, việc đặt các dẫn xuất AsyncTask trong các phương thức Hoạt động là sai. OTOH, nếu chúng ta không được sử dụng AsyncT task trong Hoạt động, AsyncTask sẽ mất đi tính hấp dẫn: nó từng được quảng cáo là một cách khắc phục nhanh chóng và dễ dàng.

Tôi không chắc chắn rằng bạn có nguy cơ bị rò rỉ bộ nhớ với tham chiếu đến ngữ cảnh từ AsyncTask.

Cách thông thường để triển khai chúng là tạo một cá thể AsyncTask mới trong phạm vi của một trong các phương thức của Activity. Vì vậy, nếu hoạt động bị hủy, thì một khi AsyncTask hoàn thành, nó sẽ không thể truy cập được và sau đó đủ điều kiện để thu gom rác? Vì vậy, tham chiếu đến hoạt động sẽ không thành vấn đề vì bản thân AsyncTask sẽ không xuất hiện.

Sẽ mạnh mẽ hơn khi giữ WeekReference cho hoạt động của bạn:

public class WeakReferenceAsyncTaskTestActivity extends Activity {
    private static final int MAX_COUNT = 100;

    private ProgressBar progressBar;

    private AsyncTaskCounter mWorker;

    @SuppressWarnings("deprecation")
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_async_task_test);

        mWorker = (AsyncTaskCounter) getLastNonConfigurationInstance();
        if (mWorker != null) {
            mWorker.mActivity = new WeakReference<WeakReferenceAsyncTaskTestActivity>(this);
        }

        progressBar = (ProgressBar) findViewById(R.id.progressBar1);
        progressBar.setMax(MAX_COUNT);
    }

    @Override
    public boolean onCreateOptionsMenu(Menu menu) {
        getMenuInflater().inflate(R.menu.activity_async_task_test, menu);
        return true;
    }

    public void onStartButtonClick(View v) {
        startWork();
    }

    @Override
    public Object onRetainNonConfigurationInstance() {
        return mWorker;
    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (mWorker != null) {
            mWorker.mActivity = null;
        }
    }

    void startWork() {
        mWorker = new AsyncTaskCounter(this);
        mWorker.execute();
    }

    static class AsyncTaskCounter extends AsyncTask<Void, Integer, Void> {
        WeakReference<WeakReferenceAsyncTaskTestActivity> mActivity;

        AsyncTaskCounter(WeakReferenceAsyncTaskTestActivity activity) {
            mActivity = new WeakReference<WeakReferenceAsyncTaskTestActivity>(activity);
        }

        private static final int SLEEP_TIME = 200;

        @Override
        protected Void doInBackground(Void... params) {
            for (int i = 0; i < MAX_COUNT; i++) {
                try {
                    Thread.sleep(SLEEP_TIME);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                Log.d(getClass().getSimpleName(), "Progress value is " + i);
                Log.d(getClass().getSimpleName(), "getActivity is " + mActivity);
                Log.d(getClass().getSimpleName(), "this is " + this);

                publishProgress(i);
            }
            return null;
        }

        @Override
        protected void onProgressUpdate(Integer... values) {
            super.onProgressUpdate(values);
            if (mActivity != null) {
                mActivity.get().progressBar.setProgress(values[0]);
            }
        }
    }

}

Tại sao không ghi đè onPause()phương thức trong Hoạt động sở hữu và hủy bỏ AsyncTasktừ đó?

Bạn hoàn toàn đúng - đó là lý do tại sao một phong trào tránh sử dụng các tác vụ / bộ tải không đồng bộ trong các hoạt động để tìm nạp dữ liệu đang đạt được đà. Một trong những cách mới là sử dụng khung Volley về cơ bản cung cấp một cuộc gọi lại sau khi dữ liệu đã sẵn sàng - phù hợp hơn nhiều với mô hình MVC. Volley đã được phổ biến trong Google I / O 2013. Không hiểu tại sao nhiều người không biết về điều này.

Cá nhân, tôi chỉ mở rộng Thread và sử dụng giao diện gọi lại để cập nhật giao diện người dùng. Tôi không bao giờ có thể khiến AsyncTask hoạt động bình thường mà không gặp sự cố FC. Tôi cũng sử dụng hàng đợi không chặn để quản lý nhóm thực thi.

Tôi nghĩ hủy bỏ hoạt động nhưng nó không.

Ở đây họ RTFMing về nó:

"" Nếu tác vụ đã bắt đầu, thì tham số mayInterrupt IfRasty xác định xem luồng thực thi tác vụ này có bị gián đoạn trong nỗ lực dừng tác vụ hay không. "

Điều đó không ngụ ý, tuy nhiên, các chủ đề là gián đoạn. Đó là một thứ Java, không phải là một thứ AsyncTask. "

http://groups.google.com/group/android-developers/browse_thread/thread/dcadb1bc7705f1bb/add136eb4949359d?show_docid=add136eb4949359d

Bạn sẽ tốt hơn khi nghĩ về AsyncTask như một thứ gì đó được kết hợp chặt chẽ hơn với Activity, Context, ContextWrapper, v.v ... Thật tiện lợi khi phạm vi của nó được hiểu đầy đủ.

Đảm bảo rằng bạn có chính sách hủy trong vòng đời của mình để cuối cùng nó sẽ được thu gom rác và không còn giữ tham chiếu đến hoạt động của bạn nữa và nó cũng có thể là rác được thu thập.

Nếu không hủy AsyncTask trong khi di chuyển khỏi Ngữ cảnh, bạn sẽ gặp phải rò rỉ bộ nhớ và NullPulumExceptions, nếu bạn chỉ cần cung cấp phản hồi như Toast một hộp thoại đơn giản thì một Bối cảnh ứng dụng của bạn sẽ giúp tránh được vấn đề NPE.

AsyncTask không tệ lắm nhưng chắc chắn có rất nhiều phép thuật đang diễn ra có thể dẫn đến một số cạm bẫy không lường trước được.

Như để "kinh nghiệm làm việc với nó": đó là khả năng để giết chết quá trình cùng với tất cả AsyncTasks, Android sẽ tái tạo hoạt động ngăn xếp để người dùng sẽ không đề cập đến bất cứ điều gì.