深入分析 AbstractBaseUser 和 AbstractUser 的区别

Posted 2023-04-03 部长y

AbstractBaseUser

AbstractBaseUser中只含有3个字段: password, last_login和is_active，方法也仅包含以下一些身份验证功能和密码存储功能。

def save(self, *args, **kwargs):
    super().save(*args, **kwargs)
    if self._password is not None:
        password_validation.password_changed(self._password, self)
        self._password = None

def get_username(self):
    """Return the username for this User."""
    return getattr(self, self.USERNAME_FIELD)

def clean(self):
    setattr(self, self.USERNAME_FIELD, self.normalize_username(self.get_username()))

def natural_key(self):
    return (self.get_username(),)

# 是否是匿名用户
@property
def is_anonymous(self):
    """
    Always return False. This is a way of comparing User objects to
    anonymous users.
    """
    return False

# 身份认证
@property
def is_authenticated(self):
    """
    Always return True. This is a way to tell if the user has been
    authenticated in templates.
    """
    return True

# 通过createsuperuser创建出来的用户密码是用set_password进行哈希加密的
# 一般在用户注册时会使用，会将密码进行加密处理时会用到它。
def set_password(self, raw_password):
    self.password = make_password(raw_password)
    self._password = raw_password

# 检查密码
# 一般在用户登录时会使用，会将密码进行解密处理时会用到它。
def check_password(self, raw_password):
    """
    Return a boolean of whether the raw_password was correct. Handles
    hashing formats behind the scenes.
    """
    def setter(raw_password):
        self.set_password(raw_password)
        # Password hash upgrades shouldn't be considered password changes.
        self._password = None
        self.save(update_fields=["password"])
    return check_password(raw_password, self.password, setter)

def set_unusable_password(self):
    # Set a value that will never be a valid hash
    self.password = make_password(None)

def has_usable_password(self):
    """
    Return False if set_unusable_password() has been called for this user.
    """
    return is_password_usable(self.password)

def get_session_auth_hash(self):
    """
    Return an HMAC of the password field.
    """
    key_salt = "django.contrib.auth.models.AbstractBaseUser.get_session_auth_hash"
    return salted_hmac(key_salt, self.password).hexdigest()

@classmethod
def get_email_field_name(cls):
    try:
        return cls.EMAIL_FIELD
    except AttributeError:
        return 'email'

@classmethod
def normalize_username(cls, username):
    return unicodedata.normalize('NFKC', username) if isinstance(username, str) else username

注意一：用户唯一身份的字段

但是需要注意的是你的拓展模型必须有一个可用于识别目的的唯一字段。这可以是一个用户名，一个电子邮件地址，或任何其他独特的属性。如果你使用可以支持的自定义认证后端，则允许使用非唯一的用户名字段。下列 identifier 将被用作识别字段。
识别字段：能代表用户唯一身份的字段，比如是 username、email 等

class MyUser(AbstractBaseUser):
    identifier = models.CharField(max_length=40, unique=True)
    ...
    # identifier 字段将被用作识别字段
    USERNAME_FIELD = 'identifier'

注意二：自定义管理器实现

由于 AbstractBaseUser 不像 AbstractUser 已经实现了 create_user 和 create_superuser 以及获取唯一 key 的方法(get_by_natural_key, 用于获取 USERNAME_FIELD 的用户)，所以需要自定义管理器实现这些方法：

class UserManage(models.Manager):
    def create_user(self, username, password, **extra_fields):
        user = self.model(username=username, **extra_fields)
        if password:
            user.set_password(password)

        user.save()
	
	# 默认的认证后端(ModelBackend)需要使用这个属性,所以这里需要定义
	# 不然会报错：AttributeError: 'UserManage' object has no attribute 'get_by_natural_key'
	"""
	默认的认证后端比较简单，通过 get_by_natural_key(使用 USERNAME_FIELD 指定的字段的内容检索用户实例。) 获取到登录用户，
	再检查密码和活跃状态。
	
	"""
    def get_by_natural_key(self, username):
        return self.get(username=username)

注意三：自定义认证后端

不管是 AbstractBaseUser 或是 AbstractUser 它们都有一个默认的认证后端，名叫 ModelBackend，里面进行一些简单的用户密码以及用户活跃的功能校验，但是我们可能需要其他的校验，比如验证码校验、微信校验、或者复杂的用户名密码校验等。

默认的用户校验后端：

class ModelBackend(BaseBackend):
    """
    Authenticates against settings.AUTH_USER_MODEL.
    """

    def authenticate(self, request, username=None, password=None, **kwargs):
        if username is None:
            username = kwargs.get(UserModel.USERNAME_FIELD)
        if username is None or password is None:
            return
        try:
            user = UserModel._default_manager.get_by_natural_key(username)
        except UserModel.DoesNotExist:
            # Run the default password hasher once to reduce the timing
            # difference between an existing and a nonexistent user (#20760).
            UserModel().set_password(password)
        else:
            if user.check_password(password) and self.user_can_authenticate(user):
                return user

如何查看怎么使用的 ModelBackend，django 默认在 global_settings.py 中指定了 ：

AUTHENTICATION_BACKENDS = ['django.contrib.auth.backends.ModelBackend']

获取校验的 ModelBackend：
如果 settings 中自己自定义了校验后端，直接获取，如果没有定义则会加载使用父级的( global_settings.py ) AUTHENTICATION_BACKENDS 中指定的默认的校验后端(ModelBackend)，
因为 settings.py 会导入 global_settings.py 的所有内容。

def _get_backends(return_tuples=False):
    backends = []
    for backend_path in settings.AUTHENTICATION_BACKENDS:
        backend = load_backend(backend_path)
        backends.append((backend, backend_path) if return_tuples else backend)
    if not backends:
        raise ImproperlyConfigured(
            'No authentication backends have been defined. Does '
            'AUTHENTICATION_BACKENDS contain anything?'
        )
    return backends

自定义自己的认证后端：

from django.contrib.auth import get_user_model

User = get_user_model()


class BackendBase:
    def get_user(self, pk):
        try:
            return User.objects.get(pk=pk)
        except User.DoesNotExist:
            return None


class PasswordBackend(BackendBase):
    """
    密码登录
    """
    def authenticate(self, request, username, password, **kwargs):
        try:
            user = User.objects.get(username=username)

            if not user.check_password(password):
                raise Exception('密码错误！！')

            return user
        except User.DoesNotExist:
            raise Exception('账号不存在')

# settings.py 中配置如下内容：
AUTHENTICATION_BACKENDS = [
   'djcelerytest.backends.PasswordBackend',
]

继承 AbstractBaseUser 流程：

from django.contrib.auth.base_user import AbstractBaseUser


class UserManage(models.Manager):
    def create_user(self, username, password, **extra_fields):
        user = self.model(username=username, **extra_fields)
        if password:
            user.set_password(password)

        user.save()
	
	# USERNAME_FIELD 指定的字段
    def get_by_natural_key(self, username):
        return self.get(username=username)


class User(AbstractBaseUser):
    objects = UserManage()
    username = models.CharField('用户名', max_length=40, unique=True)
    phone = models.CharField(max_length=40, unique=True, null=True, default=None, verbose_name='手机号')
    # 该字段由 Django 的 AbstractBaseUser 中的方法使用，我们自己不建议使用，总是忽略，
    # 因为我们自己定义了认证后端，不在使用默认的 Modelbackend 认证后端了，如果么有自定义，那么改字段有效
    USERNAME_FIELD = 'username'
    created_at = models.DateTimeField(auto_now_add=True)
    class Meta:
        verbose_name = "用户"

    def __str__(self):
        return self.username


# settings.py 中配置：
AUTH_USER_MODEL = "app名称.User"

"""
默认是 global_settings.py 中的 AUTH_USER_MODEL
它的指向是 django auth 里面的 user:  AUTH_USER_MODEL = 'auth.User'

解释：
	有时我们可能不使用 auth 里面的内容，比如我们自己做一些本地测试的内容，
	但实际开发中我们可能借助于 auth 里面的一些内容，比如创建用户、密码加密、登录、认证等信息，
	使用 auth 里面的 AbstractBaseUser 和 AbstractUser 有利于我们开发。
	
	为什么拓展之后要更改指向：
		所以这里拓展之后必须将指向改为我们现有项目的用户模型，这样是为了应用我们用户模型的字段和	
		AbstractBaseUser 或 AbstractUser中的字段，告诉 django 使用我新定义的 User 表来做
		用户认证并且我们用户模型也永远了里面的方法。

	为什么 migrate：
		将 AbstractBaseUser 或 AbstractUser中的字段和我们项目中的用户字段更新到一张表里面去。
"""

注意四：什么时候使用 AbstractBaseUser

AbstractBaseUser 里面是没有创建用户和创建超级用户项的，比如你想创建一些复杂的用户，可能随机生成一些特有格式的用户名，那么 AbstractUser 中的 create_user 是做不到的，这个时候可以使用 AbstractBaseUser 并自己在管理器中实现 create_user 方法。或者想定义一些自己的认证方法，比如电子邮件登录、手机验证登录等。
如果使用 AbstractBaseUser 那么 auth 中的很多方法是用不了的，或者说是不适合的，比如：创建用户、认证、权限、管理器等
AbstractBaseUser 中没有创建用户方法。
AbstractBaseUser 只有一个默认的认证方式 ModelBackend。
AbstractBaseUser 没有权限相关的方法。
AbstractBaseUser 没有用户管理器提供的方法。
基于以上考虑：如果你对默认的auth_user中有不满意的地方或者不想要的字段, 或者只想保留默认的密码储存方式, 则可以选择这一方式。
反之就是如果你对django自带的User model刚到满意, 又希望额外的field的话, 你可以扩展AbstractUser类。

AbstractUser

实现了一个功能齐全的用户模型，并且可以使用 auth 中提供的所有方法，是比较成熟的一套用户体系。
他继承AbstractBaseUser和PermissionsMixin，所以也会有一些密码校验和权限管理的方法。
因此有需要的话可以从中继承并添加自己的配置字段和方法。

官网解释：
如果你对Django的User模型非常满意，但你想添加一些额外的配置文件信息，你可以将Django.contrib.auth.models.AbstractUser子类化，并添加你的自定义配置文件字段，尽管我们建议使用一个单独的模型，如指定自定义用户模型. AbstractUser提供了默认User作为抽象模型的完整实现。

class AbstractUser(AbstractBaseUser, PermissionsMixin):
    """
    An abstract base class implementing a fully featured User model with
    admin-compliant permissions.

    Username and password are required. Other fields are optional.
    """
    objects = UserManager()

提供了创建用户方法：

class UserManager(BaseUserManager):
    
    def create_user(self, username, email=None, password=None, **extra_fields):
        extra_fields.setdefault('is_staff', False)
        extra_fields.setdefault('is_superuser', False)
        return self._create_user(username, email, password, **extra_fields)

    def create_superuser(self, username, email=None, password=None, **extra_fields):
        extra_fields.setdefault('is_staff', True)
        extra_fields.setdefault('is_superuser', True)

        if extra_fields.get('is_staff') is not True:
            raise ValueError('Superuser must have is_staff=True.')
        if extra_fields.get('is_superuser') is not True:
            raise ValueError('Superuser must have is_superuser=True.')

AbstractBaseUser 里面有的他也都有，AbstractUser 没有的他也有，方法都同上，不再多赘述。

深入分析AsyncTask

1. 什么是AsyncTask

---

AsyncTask 即 asynchronous task，异步任务。

AsyncTask实际上是围绕Thread和Handler设计的一个辅助类，在内部是对Thread和Handler的一种封装。AsyncTask的异步体现在由后台线程进行运算（访问网络等比较耗时的操作），然后将结果发布到用户界面上来更新UI，使用AsyncTask使得我不用操作Thread和Handler。

2. AsyncTask的简单使用

---

new AsyncTask<String,String,String>()
     运行在主线程中，做预备工作/
    onPreExecute()
    
    
    // 运行在子线程中，做耗时操作
    String doingBackGround(String s)
    
    
    // 运行在主线程中，耗时操作完成，更新UI
    onPostExecute(String s)
    			
    

.execute(String);

AsyncTask用法比较简单，Google设计这个类就是为了方便我们进行类似Handler这样的异步操作。

如上代码，一般使用AsyncTask只要重写里面的三个方法，onPreExecute和onPostExecute不是抽象方法，不是必须实现，实现这两种方法一般能让代码的逻辑更加清晰。onPreExecute运行在主线程中，做一些准备工作。onPostExecute同样运行在主线程中，用于在耗时操作完成后，更新UI。另外，还有一个onProgressUpdate方法，用于在后台任务执行过程中来实时地更新UI。

doingBackGround则是抽象方法，必须实现，我们使用AsyncTask时希望将一些耗时操作放在子线程中，doingBackGround中逻辑就相当于我们在Thread-Handler中Thread中的run方法中实现的逻辑。

execute方法用于启动执行任务

3. 从源码角度看AsyncTask的设计

---

接下来进入这篇文章的重点，我们从源码角度来分析AsyncTask是如何实现的。

AsyncTask的execute方法

public final AsyncTask<Params, Progress, Result> execute(Params... params) 
        return executeOnExecutor(sDefaultExecutor, params);
    

上面是execute方法，发现execute其实内部调用的executeOnExecutor方法，调用executeOnExecutor方法传递了两个参数，这里第一个传递了一个默认的执行器，关于这个sDefaultExecutor我们再来讲，我们现在来看AsyncTask的流程设计。

我们来看这个executeOnExecutor方法,这里将不重要的代码略去了，其实这里面的逻辑比较清晰。

 public final AsyncTask<Params, Progress, Result> executeOnExecutor(Executor exec,
            Params... params) 
        .....
        .....

        mStatus = Status.RUNNING;
        
        // 第一步：在主线程中执行准备操作
        onPreExecute();
        // 第二步：把params参数赋值给mWorker
        mWorker.mParams = params;
        // 第三步：用线程池执行mFuture
        exec.execute(mFuture);
        ///
        return this;
    

第一步，onPreExecute与上面的介绍一样，进行准备工作，这个就没有必要分析，如果我们没有重写，就不会做相关的准备。我们主要第二步和第三步，第二步，把params参数赋值给mWorker，params是execute中传递过来的参数，同时也是泛型中第一个参数，将params赋值给mWorker，那么mWorker是什么呢？

AsyncTask的构造方法

我们继续看源码:主意到mWorker是在AsyncTask的构造方法中创建的。

public AsyncTask() 
        mWorker = new WorkerRunnable<Params, Result>() 
            public Result call() throws Exception 
               .....
            
        ;

        mFuture = new FutureTask<Result>(mWorker) 
            @Override
            protected void done() 
               .....
            
        ;
    

首先，mWorker在构造方法中创建，它是一个匿名内部类，那WorkerRunnable是个什么东西呢？

 private static abstract class WorkerRunnable<Params, Result> implements Callable<Result> 
        Params[] mParams;
    

我们发现WorkerRunnable其实就是一个Callable，同时在execute方法中mFuture也在这里创建了出来，这里会将mWorker传递到FutureTask中去，那么将mFuture传进去做了什么什么操作呢？

 public FutureTask(Callable<V> callable) 
        if (callable == null)
            throw new NullPointerException();
        //这里将mWorker传递进来，其实就是callable///
        /
        this.callable = callable;
        this.state = NEW;       // ensure visibility of callable
    

FutureTask是java.util.concurrent，FutureTask继承了Future，通过 Future 接口，可以尝试取消尚未完成的任务，查询任务已经完成还是取消了，以及提取（或等待）任务的结果值。

在AsyncTask的构造方法中，将mWorker传进来，即将callable传进来，因为mWorker就是callable。

这样在上面的executeOnExecutor中的第三步中，exec.execute(mFuture) 用线程池来执行mFuture，其实就是执行mFuture中的run方法，我们来看FutureTask中的run方法：

FutureTask中的run方法

 public void run() 
        if (state != NEW ||
            !UNSAFE.compareAndSwapObject(this, runnerOffset,
                                         null, Thread.currentThread()))
            return;
        try 
            Callable<V> c = callable;
            if (c != null && state == NEW) 
                V result;
                boolean ran;
                try 
                   //① 调用callable中的call方法，其实就是mWorker中的call方法
                   //并且将结果赋值给result
                    result = c.call();
                    ran = true;
                 catch (Throwable ex) 
                    result = null;
                    ran = false;
                    setException(ex);
                
                if (ran)
                    //② 调用自己内部的set方法设置结果
                    set(result);
            
         finally 
            // runner must be non-null until state is settled to
            // prevent concurrent calls to run()
            runner = null;
            // state must be re-read after nulling runner to prevent
            // leaked interrupts
            int s = state;
            if (s >= INTERRUPTING)
                handlePossibleCancellationInterrupt(s);
        
    

在FutureTask中的run方法，我们需要关注两个地方，第一个，就是上面代码片段的①处，这里调用了mWorker中的call方法，这样我们再回头来看mWorker中的call方法。

mWorker = new WorkerRunnable<Params, Result>() 
            public Result call() throws Exception 
                mTaskInvoked.set(true);

                Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
                //noinspection unchecked
                return postResult(doInBackground(mParams));
            
        ;

 private Result postResult(Result result) 
        @SuppressWarnings("unchecked")
        Message message = sHandler.obtainMessage(MESSAGE_POST_RESULT,
                new AsyncTaskResult<Result>(this, result));
        message.sendToTarget();
        return result;
    

在mWorker中call方法中主要就是执行耗时操作，正是doInBackground方法，并且将执行的结果result返回回去，用postResult对doInBackground进行包裹则是为了运用Handler机制来更新UI。
接下来我们看FutureTask中run方法中的②处，调用了FutureTask自己的set方法。

protected void set(V v) 
        if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) 
            outcome = v;
            UNSAFE.putOrderedInt(this, stateOffset, NORMAL); // final state
            finishCompletion();
        
    

 private void finishCompletion() 
        // assert state > COMPLETING;
        for (WaitNode q; (q = waiters) != null;) 
            if (UNSAFE.compareAndSwapObject(this, waitersOffset, q, null)) 
                for (;;) 
                    Thread t = q.thread;
                    if (t != null) 
                        q.thread = null;
                        LockSupport.unpark(t);
                    
                    WaitNode next = q.next;
                    if (next == null)
                        break;
                    q.next = null; // unlink to help gc
                    q = next;
                
                break;
            
        
        //① 调用了FutureTask中的done方法
        done();

        callable = null;        // to reduce footprint
    

由set方法，调用finishCompletion，主要看finishCompletion的逻辑，我们只关注finishCompletion代码的①处，这里调用了done方法，
这样我们来看done方法中的逻辑。

mFuture = new FutureTask<Result>(mWorker) 
            @Override
            protected void done() 
                try 
                    postResultIfNotInvoked(get());
                 catch (InterruptedException e) 
                    android.util.Log.w(LOG_TAG, e);
                 catch (ExecutionException e) 
                    throw new RuntimeException("An error occured while executing doInBackground()",
                            e.getCause());
                 catch (CancellationException e) 
                    postResultIfNotInvoked(null);
                
            
        ;

在Future中调用了postResultIfNotInvoked，其实这里将这段处理逻辑抽取到方法中去了，在android2.3即以前的源码都是没有抽取的，这也是使得现在的逻辑更加清晰。
java.util.concurrent.atomic.AtomicBoolean （ 在这个Boolean值的变化的时候不允许在之间插入，保持操作的原子性）
由于在mWorker中的call和在mFuture的done方法都会调用postResult来更新UI，由于是线程操作，不能保证先后顺序，所以需要使用AtomicBoolean来保持操作的原子性。其实在2.3上的代码不是这样处理的，2.3上将更新UI的操作都放在mFuture中的done方法中。

private void postResultIfNotInvoked(Result result) 
        final boolean wasTaskInvoked = mTaskInvoked.get();
        if (!wasTaskInvoked) 
            postResult(result);
        
    

最后，我们来看postResult方法。

  private Result postResult(Result result) 
        @SuppressWarnings("unchecked")
        Message message = sHandler.obtainMessage(MESSAGE_POST_RESULT,
                new AsyncTaskResult<Result>(this, result));
        message.sendToTarget();
        return result;
    

这里就是我们非常熟悉的代码了，使用Message发送消息给Handler来更新UI。
在AsyncTask中定义了一个InternalHandler，如果耗时操作执行完毕，就会执行finish(result.mData[0])，如果结果正在执行，则会onProgressUpdate来更新进度，这个onProgressUpdate正是我们前面说到的需要实现的更新进度的方法。

private static class InternalHandler extends Handler 
        @SuppressWarnings("unchecked", "RawUseOfParameterizedType")
        @Override
        public void handleMessage(Message msg) 
            AsyncTaskResult result = (AsyncTaskResult) msg.obj;
            switch (msg.what) 
                case MESSAGE_POST_RESULT:
                    // There is only one result
                    result.mTask.finish(result.mData[0]);
                    break;
                case MESSAGE_POST_PROGRESS:
                    result.mTask.onProgressUpdate(result.mData);
                    break;
            
        
    

AsyncTaskResult类的只是一个封装

  @SuppressWarnings("RawUseOfParameterizedType")
    private static class AsyncTaskResult<Data> 
        final AsyncTask mTask;
        final Data[] mData;

        AsyncTaskResult(AsyncTask task, Data... data) 
            mTask = task;
            mData = data;
        
    

private void finish(Result result) 
        if (isCancelled()) 
            onCancelled(result);
         else 
            //耗时操作执行完毕，更新UI///
            //onPostExecute运行在主线程
            onPostExecute(result);
            //
        
        mStatus = Status.FINISHED;
    

##############################################################

这样我们关于AsyncTask的流程终于走通了，为什么onPreExecute和onPostExecute运行在主线程，而doingBackGround为什么运行在子线程中，这个逻辑是不是就变得清晰了。上面贴了好多代码，一直都是在分析代码的意思，至于关于设计的思想感觉现在的自己还体悟不够。

4. AsyncTask在上面遗留的问题

---

关于AsyncTask中executeOnExecutor中的sDefaultExecutor

项目中问题场景：

操作步骤>>>>>>>>>>>

• 设置安全中，选择指纹。
• 解锁方式选择图案。
• 在选择您的图案界面，点击确定，需要三到五秒才能跳转到下一界面。

问题分析：在设置解锁方式为为图案时，第二次绘制图案后，Settings源码中使用了AsyncTask来将一些比较耗时的验证操作放在子线程中去处理(参看下面的部分代码)，由于android原生设计是使用
AsyncTask中的一个参数的方法，一个参数的方法采用的是默认的执行器，即串行执行器

frameworks/base/core/java/com/android/internal/widget/LockPatternChecker.java

public static AsyncTask<?, ?, ?> verifyPattern(final LockPatternUtils utils,
            final List<LockPatternView.Cell> pattern,
            final long challenge,
            final int userId,
            final OnVerifyCallback callback) 
        AsyncTask<Void, Void, byte[]> task = new AsyncTask<Void, Void, byte[]>() 
            private int mThrottleTimeout;
            @Override
            protected byte[] doInBackground(Void... args) 
                try 
                    return utils.verifyPattern(pattern, challenge, userId);
                 catch (RequestThrottledException ex) 
                    mThrottleTimeout = ex.getTimeoutMs();
                    return null;
                
            
            @Override
            protected void onPostExecute(byte[] result) 
                callback.onVerified(result, mThrottleTimeout);
            
        ;
        默认使用的串行的执行器//
        task.execute();
        ///
        return task;
    

public static final Executor SERIAL_EXECUTOR = new SerialExecutor();
private static volatile Executor sDefaultExecutor = SERIAL_EXECUTOR;

private static class SerialExecutor implements Executor 
        final ArrayDeque<Runnable> mTasks = new ArrayDeque<Runnable>();
        Runnable mActive;

        public synchronized void execute(final Runnable r) 
            mTasks.offer(new Runnable() 
                public void run() 
                    try 
                        r.run();
                     finally 
                        scheduleNext();
                    
                
            );
            if (mActive == null) 
                scheduleNext();
            
        

        protected synchronized void scheduleNext() 
            if ((mActive = mTasks.poll()) != null) 
                THREAD_POOL_EXECUTOR.execute(mActive);
            
        
    

我们发现SerialExecutor即是串行执行器，它的作用是保证任务执行的顺序，也就是它可以保证提交的任务确实是按照先后顺序执行的。它的内部有一个队列用来保存所提交的任务，保证当前只运行一个，这样就可以保证任务是完全按照顺序执行的。如果发现异步任务还未执行，可能被我们发现SerialExecutor即是串行执行器顺序的使用线程执行。因为应用中可能还有其他地方使用AsyncTask，所以到我们的AsyncTask也许会等待到其他任务都完成时才得以执行而不是调用executor()之后马上执行。

如果executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR,params)则不一样。

 /**
     * An @link Executor that can be used to execute tasks in parallel.
     */
    public static final Executor THREAD_POOL_EXECUTOR
            = new ThreadPoolExecutor(CORE_POOL_SIZE, MAXIMUM_POOL_SIZE, KEEP_ALIVE,
                    TimeUnit.SECONDS, sPoolWorkQueue, sThreadFactory);

API中的解释：能够并行的执行任务。THREAD_POOL_EXECUTOR是一个数量为corePoolSize的线程池，具体线程池的数量是依据CPU的核心来设置的，如果超过这个数量的线程个数就需要等待

SerialExecutor是按顺序执行，THREAD_POOL_EXECUTOR则一定程度上能保证并行执行。

以上就是关于AsyncTask的全部内容，希望能对你有些帮助，贴了好多源码，如果想真正弄清楚，还是得自己去阅读阅读源码，整理这个也不容易，前前后后花了大概一个星期。
最后是AsyncTask的时序图，画的不太好，凑合看吧，O(∩_∩)O哈哈~