1

When watching my app through the Device Manager I came across behaviour with the inflater that I was hoping someone in the stack overflow community could help me understand. I have a fragment that when It uses the layout inflater to inflate an EditText it spawns two Async Tasks. Why are these getting spawned and what can I do to prevent this or close them afterwards?

When I comment out the EditText, right after the fragment loads I see this: With the edit text

After I put it back: Without the edit text

My fragment looks like:

public class SearchFragment implements View.OnClickListener{

    // the fragment initialization parameters, e.g. ARG_ITEM_NUMBER
    private static final String TAG = "HistorySearchFragment";

    private static final String ARG_SECTION_NUMBER = "sectionNumber";

    public static SearchFragment newInstance(int sectionNumber) {
        SearchFragment fragment = new SearchFragment();
        Bundle args = new Bundle();
        args.putInt(ARG_SECTION_NUMBER, sectionNumber);
        fragment.setArguments(args);
        return fragment;
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
                         Bundle savedInstanceState) {

        super.onCreateView(inflater, container, savedInstanceState);
        View view = inflater.inflate(R.layout.fragment_search, container, false)

        return view;
    }
}

fragment_search.xml looks like

<RelativeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    tools:context="com.main.SearchFragment"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:padding="10dp">

<ScrollView
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:layout_above="@+id/search_button_bw"
    android:layout_below="@+id/space"
    android:isScrollContainer="false">
    <RelativeLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content">

/*************************************************
THIS TEXT BOX HERE
/************************************************/
    <EditText
        android:layout_width="wrap_content"
        android:layout_height="wrap_content" />

/*************************************************
To here
/************************************************/

    </RelativeLayout>
</ScrollView >



<Button
    android:id="@+id/search_button_bw"
    android:layout_width="match_parent"
    android:layout_height="70dp"
    android:text="Search"
    android:layout_alignParentBottom="true"
    android:layout_alignParentLeft="true"
    android:layout_alignParentStart="true" />

I have verified that this only happens when this fragment loads and the Tasks get spawned every time without fail. Does anyone have any idea why this is happening and how I can prevent it?

Community
  • 1
  • 1
nbroeking
  • 8,360
  • 5
  • 20
  • 40

1 Answers1

2

Does anyone have any idea why this is happening

TextView has references to AsyncTask in its locale handling (at least in its Android 5.1 version; you would need to check for the specific version of Android that you are running).

AsyncTask will initialize a thread pool when the AsyncTask class is loaded as part of setting up the rest of the static data members. That pool has a minimum pool size of the number of CPU cores plus one. So, on an emulator or single-core hardware, two Thread objects will be created once something references the AsyncTask class. They will exist for the duration of your process. Note that on multi-core CPUs, I would expect more threads to be in this pool in the steady state, and there can be even more threads (up to double the number of cores, plus one) if a lot of tasks are active.

how I can prevent it?

Don't use TextView or anything that inherits from it. Also, do not use any other framework classes that reference AsyncTask.

Since those threads are not running (as you can see from your screenshot), I fail to see what your issue is. If anything, we need more stuff in the framework using background threads, as there are some places where Android's framework code runs afoul of StrictMode threading checks.

what can I do to... close them afterwards?

They are closed, insofar as they are not running. As you see in your screenshot, they are blocked ("Wait"). They will remain in that state until something needs to run a task. This is how thread pools work.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • This doesn't make sense to me. How come every other Edit text in other fragments do not create the Async Tasks but just this one. As far as issues. We are on a very resource restricted device and don’t want to create extra resources when we don't need to. We have other background threads that are designed to take the load off the main thread. – nbroeking Jul 29 '15 at 23:59
  • @nbroeking: "How come every other Edit text in other fragments do not create the Async Tasks but just this one" -- I have no idea. Perhaps the locale logic is only being executed on this one, and so this is the first time `AsyncTask` is referenced and has its class loaded. Perhaps you are running something other than Android 5.1 (as my links point to the master branch, presently 5.1) and you're tripping over some other `AsyncTask` behavior on an older Android version. Perhaps there is an issue in the way that you conducted your tests. – CommonsWare Jul 30 '15 at 00:05
  • @nbroeking: But, as I noted, `AsyncTask` is used in many places in the framework code. You may not be able to avoid this class being loaded. You *happen* to be having `AsyncTask` load based on this `EditText`, but in the future it might be loaded from something else that you use. If you are building your own custom ROM for this "resource restricted device", you could change `CORE_POOL_SIZE` on `AsyncTask` to be zero or something, and see how that works. – CommonsWare Jul 30 '15 at 00:08
  • We are actually using Android 4.2.2. But I will give you an up vote for pointing me in the direction and Ill accept your answer when I can verify that this is what is creating the AsyncTasks. Thanks for the help – nbroeking Jul 30 '15 at 00:08