android - generic thread framework vs asynctask -


i have few questions the usages of generic thread framework(for specific amount of jobs of course) vs usage of many asyntasks.
know if better have many asyntasks small jobs, handler thread when job takes bit longer or better have generic thread having generic jobs notification system built on top of the running thread(or subclass, same story).

my idea creating thread handles different jobs without knowing beforehand jobs. goes in direction of creating sort of small framework handling different generic jobs.
example approach goes in direction of code below:

    public (abstract if want extend , add on top) class workerthread extends thread {      private static final string tag = workerthread();     private list<worktask> syncqueue = new arraylist< worktask >();     private boolean clearqueue = false;     public workerthread() {      }       public void stop(boolean clear) {         clearqueue = clear;         this.stopworker = true;     }      public void addtask(workertask task) {         synchronized (syncqueue) {             if (task != null && !getsynqueue().contains(task)) {                 getsynqueue().add(task);             }         }     }      @override     public void run() {         while (!stopworker) {             workertask task = null;             synchronized (syncqueue) {                 if (!getsynqueue().isempty()) {                     task = getsynqueue().get(0);                 }             }             if (task != null) {                 try {                     task.run();                     synchronized (syncqueue) {                         if (!getsynqueue().isempty()) {                             getsynqueue().remove(task);                             //notify something/someone                         }                     }                 } catch (exception e) {                     log.e(tag, "error in running task." + e.getmessage());                     synchronized (syncqueue) {                        //again u can notify                     }                 } {                     //here can notify of success                 }             }         }         if(clearqueue){            getsynqueue().clear();         }     }     private list<workertask> getsynqueue() {         return this.syncqueue;     } } 

here task abstract base class jobs extend.
on top of thread or subclass of class can observer notifies when went wrong jobs/tasks. far, know, pros , cons approach that:
thread:

pros:
1. long time operations.
2. centralized.
3. scalable.
4. once have tested work smoothly.

cons
1. complex architecture.
2. hard maintain.
3. over-engineering small jobs.

asyntask:

pros
1. easy used.
2. short-time operation jobs.
3. easy maintain/understand.

cons
1. cannot scale much, need stick doinbackground , onpostexecute.
2. not long-time operation jobs.

if missed please correct me.
final question be, when architecture gets bit big lot of requests, short-time, long-time, isn't better try , make generic framework can handle both rather asynctasks there, maybe handlerthread in other parts, etc?

asynctask should used short operations. official documentation:

asynctask

asynctask designed helper class around thread , handler , not constitute generic threading framework. asynctasks should ideally used short operations (a few seconds @ most.) if need keep threads running long periods of time, highly recommended use various apis provided java.util.concurrent package such executor, threadpoolexecutor , futuretask.

therefore, if operation designed take longer few seconds, recommended use concurrent package. e.g of operations are, storing file, picture, login, etc.
however, asynctask has few limitations can seen in link below:
asynctask limitations

there limit of how many tasks can run simultaneously. since asynctask uses thread pool executor max number of worker threads (128) , delayed tasks queue has fixed size 10. if try execute more 138 asynctasks app crash java.util.concurrent.rejectedexecutionexception.


also, between api 1.6 , 3.0 there no way customize asynctask. can run tasks in parallel no customization possible. between api 3.0 , api 4.3.1 there default fixed delayed queue size of 10, minimum number of tasks, 5, , maximum number of tasks 128. however, after api 3.0, 1 can define own executor. therefore, if have number of minimum 16 tasks run, first 5 start, next 10 go queue, 16th new worker thread allocated. after version 4.4(kitkat), number of parallel asynctasks depends on amount of processors device has:

private static final int cpu_count =    runtime.getruntime().availableprocessors(); private static final int core_pool_size = cpu_count + 1; private static final int maximum_pool_size = cpu_count * 2 + 1; private static final blockingqueue<runnable> spoolworkqueue = new linkedblockingqueue<runnable>(128); 

the aforementioned details, make asynctask usable in specific cases, loading image or file or storage.

on hand generic threading framework(or library) can extendable , customizable. example of libraries rxjava customizable. using rxjava 1 can specify task run on either ui thread , background. also, loading/saving pictures asynchronously to/on sdcard, 1 can use different libraries picasso or glide.


Comments

Popular posts from this blog

php - Invalid Cofiguration - yii\base\InvalidConfigException - Yii2 -

How to show in django cms breadcrumbs full path? -

ruby on rails - npm error: tunneling socket could not be established, cause=connect ETIMEDOUT -