前言

Gradle在android开发中应用地十分广泛，但相信有很多同学并不很了解gradle

本文主要介绍了使用gradle的一些实用技巧，帮助读者增进对这个熟悉的陌生人的了解

主要包括以下内容

• 1.Gradle依赖树查询


• 2.使用循环优化Gradle依赖管理


• 3.支持代码提示的Gradle依赖管理


• 4.Gradle模块化


• 5.Library模块Gradle代码复用


• 6.资源文件分包


• 7.AAR依赖与源码依赖快速切换

1.Gradle依赖树查询

有时我们在分析依赖冲突时，需要查看依赖树，我们常用的查看依赖树的命令为

gradlew app:dependencies

复制代码

不过这种命令行方式查看依赖树出来的信息太多，看的有些费劲

所以官方又推出了Scan工具来帮助我们更加方便地查看依赖树

在项目根目录位置下运行gradle build --scan即可，然后会生成 HTML 格式的分析文件的分析文件

分析文件会直接上传到Scan官网，命令行最后会给出远程地址

第一次跑会让你在 Scan 官网注册一下，邮件确认后就能看了

scan 工具是按照依赖变体挨个分类的，debugCompileClassPath 就是 dedug 打包中的依赖包了


如上，使用这种方式分析依赖树更加方便简洁

2.使用循环优化Gradle依赖管理

如下所示，我们常常使用ext来管理依赖

    dependencies {

        implementation fileTree(include: ['*.jar'], dir: 'libs')

        implementation rootProject.ext.dependencies["appcompat-v7"]

        implementation rootProject.ext.dependencies["cardview-v7"]

        implementation rootProject.ext.dependencies["design"]

        implementation rootProject.ext.dependencies["constraint-layout"]

        annotationProcessor rootProject.ext.dependencies["glide_compiler"]

        ...

    }

复制代码

这样虽然实现了依赖的统一管理，但是随着项目越来越大，依赖也会越来越多，常常会有几十甚至上百行，导致build.gradle越来越长

有没有一种好的方式不在 build.gradle 中写这么多的依赖配置？

有，就是使用循环遍历依赖。

示例如下，首先添加config.gradle

ext{

	dependencies = [

            // base

            "appcompat-v7"                      : "com.android.support:appcompat-v7:${version["supportLibraryVersion"]}"，

            ...

    ]

    

    annotationProcessor = [

            "glide_compiler"                    : "com.github.bumptech.glide:compiler:${version["glideVersion"]}",

            ...

    ]

    

    apiFileDependencies = [

            "launchstarter"                                   :"libs/launchstarter-release-1.0.0.aar"

    ]

    

    debugImplementationDependencies = [

            "MethodTraceMan"                                  : "com.github.zhengcx:MethodTraceMan:1.0.7"

    ]

    

    ...

    

    implementationExcludes = [

            "com.android.support.test.espresso:espresso-idling-resource:3.0.2" : [

                    'com.android.support' : 'support-annotations'

            ]

    ]

    

    ...

}

复制代码

然后在build.gradle中配置如下：

apply from config.gradle

...



def implementationDependencies = project.ext.dependencies

def processors = project.ext.annotationProcesso

def implementationExcludes = project.ext.implementationExcludes

dependencies{

    // 处理所有的 xxximplementation 依赖

    implementationDependencies.each { k, v -> implementation v }   

    // 处理 annotationProcessor 依赖

    processors.each { k, v -> annotationProcessor v }

    // 处理所有包含 exclude 的依赖

    implementationExcludes.each { entry ->

        implementation(entry.key) {

            entry.value.each { childEntry ->

                exclude(group: childEntry)

            }

        }

    }

    ...



}

复制代码

这样做的优点在于

1.后续添加依赖不需要改动build.gradle,直接在config.gradle中添加即可

2.精简了build.gradle的长度

3.支持代码提示的Gradle依赖管理

上面介绍了通过config.gradle管理依赖的方法

在我们添加Gradle依赖时，还有一些痛点

1.不支持代码提示

2.不支持单击跳转

3.多模块开发时，不同模块相同的依赖需要复制粘贴

使用buildSrc+kotlin可以解决这个问题

效果如下：



由于buildSrc是对全局的所有module的配置,所以可以在所有module中直接使用

这里就不多介绍了，详细开发及引入buildSrc的过程可见:

[译]Kotlin + buildSrc：更好的管理Gadle依赖

buildSrc vs includeBuild

上面介绍的方法使用的是buildSrc,使用起来比较方便

不过它的缺点在于构建速度上会慢一些，使用includeBuild可以实现同样的效果

两者实现的最终效果是差不多的

详细实现可见:【奇技淫巧】除了 buildSrc 还能这样统一配置依赖版本？巧用 includeBuild

4.Gradle模块化

我们在开发中，引入一些插件时，有时需要在build.gradle中引入一些配置，比如greendao,推送,tinker等

这些其实是可以封装在相应gradle文件中，然后通过apply from引入

举个例子，例如在我们使用greendao数据库时，需要在build.gradle中指定版本

这种时候应该新建一个greendao-config.gradle

apply plugin: 'org.greenrobot.greendao'



//greenDao指定版本和路劲等

greendao {

    //数据库的schema版本，也可以理解为数据库版本号

    schemaVersion 1

    //设置DaoMaster、DaoSession、Dao包名，也就是要放置这些类的包的全路径。

    daoPackage 'com.example.ausu.big_progect.dao'

    //设置DaoMaster、DaoSession、Dao目录

    targetGenDir 'src/main/java'

}

复制代码

然后再在build.gradle中引入

apply from 'greendao-config.gradle'

复制代码

这样做主要有2个优点

1.单一职责原则，将greendao的相关配置封装在一个文件里，不与其他文件混淆

2.精简了build.gradle的代码，同时后续修改数据库相关时不需要修改build.gradle的代码

5.Library模块Gradle代码复用

随着我们项目的越来越大，Library Module也越建越多，每个Module都有自己的build.gradle

但其实每个build.gradle的内容都差不多，我们能不能将重复的部分封装起来复用？

我们可以做一个 basic 抽取，同样将共有参数/信息提取到 basic.gradle 中，每个 module apply，这样就是减少了不少代码量

apply plugin: 'com.android.library'

apply plugin: 'kotlin-android'

apply plugin: 'kotlin-android-extensions'

apply plugin: 'kotlin-kapt'



android {

    // 指定用于编译项目的 API 级别

    compileSdkVersion Versions.compileSDK

    // 指定在生成项目时要使用的 SDK 工具的版本，Android Studio 3.0 后不需要手动配置。

    buildToolsVersion Versions.buildTools



    // 指定 Android 插件适用于所有构建版本的版本属性的默认值

    defaultConfig {

        minSdkVersion Versions.minSDK

        targetSdkVersion Versions.targetSDK

        versionCode 1

        versionName "1.0"

    }



    // 配置 Java 编译(编码格式、编译级别、生成字节码版本)

    compileOptions {

        encoding = 'utf-8'

        sourceCompatibility JavaVersion.VERSION_1_8

        targetCompatibility JavaVersion.VERSION_1_8

    }



    kotlinOptions {

        jvmTarget = JavaVersion.VERSION_1_8.toString()

    }



    lintOptions {

        // lint 异常后继续执行

        abortOnError false

    }

}



dependencies {

    implementation fileTree(dir: 'libs', include: ['*.jar'])

    ...

}

复制代码

然后在相应的模块的build.gradle中引入即可

apply from:"../basic.gradle"



dependencies {

    api Deps.constraintLayout

    api Deps.retrofit

}

复制代码

这样是不是简洁很多？读者可根据项目实际情况判断是否适合抽取basic.gradle使用

6.资源文件分包

随着项目越来越大，项目中的资源文件也越来越大，比如layout与drawable文件夹下的文件数量常常可达几百甚至上千个

我们能不能像代码一样，对资源文件进行分包呢？

答案是可以的，主要是利用gradle的sourceSets属性

我们可以将资源文件像代码一样按业务分包,具体操作如下

1.新建res_xxx目录


在 main 目录下新建 res_core, res_feed（根据业务模块命名）等目录，在res_core中新建res目录中相同的文件夹如：layout、drawable-xxhdpi、values等。

2.在gradle中配置res_xx目录

android {

    //...

    sourceSets {

        main {

            res.srcDirs(

                    'src/main/res',

                    'src/main/res_core',

                    'src/main/res_feed',

            )

        }

    }

}

复制代码

以上就完成了资源文件分包,这样做主要有几点好处

1.按业务分包查找方便，结构清晰

2.strings.xml等key-value型文件多人修改可以减少冲突

3.当删除模块或做组件化改造时资源文件删除或迁移方便，不必像以前一样一个个去找

7.AAR依赖与源码依赖快速切换

当我们的项目中Module越来越多，为了加快编译速度，常常把Module发布成AAR，然后在项目中直接依赖AAR

但是我们有时候又需要修改AAR，就需要依赖于源码

所以我们需要一个可以快速地切换依赖AAR与依赖源码的方式

我们下面举个例子，以retrofit为例

假如我们要修改retrofit的源码，修改步骤如下：

1.首先下载retrofit，可以放到和项目同级的目录,并修改目录名为retrofit-source,以便区分

2.在settings.gradle文件中添加需要修改的aar库的源码project

include ':retrofit-source'

project(':retrofit-source').projectDir = new File("../retrofit-source")

复制代码

3.替换aar为源码

build.gradle(android) 脚本中添加替换策略

allprojects {

    repositories {

...

    }

 

    configurations.all {

        resolutionStrategy {

            dependencySubstitution {

                substitute module( "com.squareup.retrofit2:retrofit") with project(':retofit-source')

            }

        }

    }

}

复制代码

如上几步，就可以比较方便地实现aar依赖与源码依赖间的互换了

这样做的主要优点在于

1.不需要修改原有的依赖配置，而是通过全局的配置，利用本地的源码替换掉aar，侵入性低

2.如果有多个Module依赖于同一个aar，不需要重复修改，只需在根目录build.gradle中修改一处

总结

本文主要介绍了几个实用的Gradle技巧，如果觉得有所帮助，可以帮忙点赞

如果发现本文还有什么不足，欢迎在评论区指出~

很多开发者都了解这么一个知识点：在 Activity 的 onCreate 方法里我们无法直接获取到 View 的宽高信息，但通过 View.post(Runnable)这种方式就可以，那背后的具体原因你是否有了解过呢？

读者可以尝试以下操作。可以发现，除了通过 View.post(Runnable)这种方式可以获得 View 的真实宽高外，其它方式取得的值都是 0

/**

 * 作者：leavesC

 * 时间：2020/03/14 11:05

 * 描述：

 * GitHub：https://github.com/leavesC

 */

class MainActivity : AppCompatActivity() {



    private val view by lazy {

        findViewById<View>(R.id.view)

    }



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

        getWidthHeight("onCreate")

        view.post {

            getWidthHeight("view.Post")

        }

        Handler().post {

            getWidthHeight("handler")

        }

    }



    override fun onResume() {

        super.onResume()

        getWidthHeight("onResume")

    }



    private fun getWidthHeight(tag: String) {

        Log.e(tag, "width: " + view.width)

        Log.e(tag, "height: " + view.height)

    }



}

复制代码

github.leavesc.view E/onCreate: width: 0

github.leavesc.view E/onCreate: height: 0

github.leavesc.view E/onResume: width: 0

github.leavesc.view E/onResume: height: 0

github.leavesc.view E/handler: width: 0

github.leavesc.view E/handler: height: 0

github.leavesc.view E/view.Post: width: 263

github.leavesc.view E/view.Post: height: 263

复制代码

从这就可以引申出几个疑问：

• View.post(Runnable) 为什么可以得到 View 的真实宽高


• Handler.post(Runnable)和View.post(Runnable)有什么区别


• 在 onCreate、onResume 函数中为什么无法直接得到 View 的真实宽高


• View.post(Runnable) 中的 Runnable 是由谁来执行的，可以保证一定会被执行吗

后边就来一一解答这几个疑问，本文基于 Android API 30 进行分析

一、View.post(Runnable)

看下 View.post(Runnable) 的方法签名，可以看出 Runnable 的处理逻辑分为两种：

• 如果 mAttachInfo 不为 null，则将 Runnable 交由mAttachInfo内部的 Handler 进行处理


• 如果 mAttachInfo 为 null，则将 Runnable 交由 HandlerActionQueue 进行处理

    public boolean post(Runnable action) {

        final AttachInfo attachInfo = mAttachInfo;

        if (attachInfo != null) {

            return attachInfo.mHandler.post(action);

        }

        // Postpone the runnable until we know on which thread it needs to run.

        // Assume that the runnable will be successfully placed after attach.

        getRunQueue().post(action);

        return true;

    }



    private HandlerActionQueue getRunQueue() {

        if (mRunQueue == null) {

            mRunQueue = new HandlerActionQueue();

        }

        return mRunQueue;

    }

复制代码

1、AttachInfo

先来看View.post(Runnable)的第一种处理逻辑

AttachInfo 是 View 内部的一个静态类，其内部持有一个 Handler 对象，从注释可知它是由 ViewRootImpl 提供的

final static class AttachInfo {

    

        /**

         * A Handler supplied by a view's {@link android.view.ViewRootImpl}. This

         * handler can be used to pump events in the UI events queue.

         */

        @UnsupportedAppUsage

        final Handler mHandler;



    	AttachInfo(IWindowSession session, IWindow window, Display display,

                ViewRootImpl viewRootImpl, Handler handler, Callbacks effectPlayer,

                Context context) {

            ···

            mHandler = handler;

            ···

    	}

    

    	···

}

复制代码

查找 mAttachInfo 的赋值时机可以追踪到 View 的 dispatchAttachedToWindow 方法，该方法被调用就意味着 View 已经 Attach 到 Window 上了

	@UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.P)

    void dispatchAttachedToWindow(AttachInfo info, int visibility) {

        mAttachInfo = info;

        ···

    }

复制代码

再查找dispatchAttachedToWindow 方法的调用时机，可以跟踪到 ViewRootImpl 类。ViewRootImpl 内就包含一个 Handler 对象 mHandler，并在构造函数中以 mHandler 作为构造参数之一来初始化 mAttachInfo。ViewRootImpl 的performTraversals()方法就会调用 DecorView 的 dispatchAttachedToWindow 方法并传入 mAttachInfo，从而层层调用整个视图树中所有 View 的 dispatchAttachedToWindow 方法，使得所有 childView 都能获取到 mAttachInfo 对象

	final ViewRootHandler mHandler = new ViewRootHandler();



    public ViewRootImpl(Context context, Display display, IWindowSession session,

                        boolean useSfChoreographer) {

        ···

        mAttachInfo = new View.AttachInfo(mWindowSession, mWindow, display, this, mHandler, this,

                context);

        ···

    }



    private void performTraversals() {

        ···

        if (mFirst) {

            ···

            host.dispatchAttachedToWindow(mAttachInfo, 0);

    	    ···

        }

        ···

        performMeasure(childWidthMeasureSpec, childHeightMeasureSpec);

        performLayout(lp, mWidth, mHeight);

        performDraw();

        ···

    }

复制代码

此外，performTraversals()方法也负责启动整个视图树的 Measure、Layout、Draw 流程，只有当 performLayout 被调用后 View 才能确定自己的宽高信息。而 performTraversals()本身也是交由 ViewRootHandler 来调用的，即整个视图树的绘制任务也是先插入到 MessageQueue 中，后续再由主线程取出任务进行执行。由于插入到 MessageQueue 中的消息是交由主线程来顺序执行的，所以 attachInfo.mHandler.post(action)就保证了 action 一定是在 performTraversals 执行完毕后才会被调用，因此我们就可以在 Runnable 中获取到 View 的真实宽高了

2、HandlerActionQueue

再来看View.post(Runnable)的第二种处理逻辑

HandlerActionQueue 可以看做是一个专门用于存储 Runnable 的任务队列，mActions 就存储了所有要执行的 Runnable 和相应的延时时间。两个post方法就用于将要执行的 Runnable 对象保存到 mActions中，executeActions就负责将mActions中的所有任务提交给 Handler 执行

public class HandlerActionQueue {

    

    private HandlerAction[] mActions;

    private int mCount;



    public void post(Runnable action) {

        postDelayed(action, 0);

    }



    public void postDelayed(Runnable action, long delayMillis) {

        final HandlerAction handlerAction = new HandlerAction(action, delayMillis);

        synchronized (this) {

            if (mActions == null) {

                mActions = new HandlerAction[4];

            }

            mActions = GrowingArrayUtils.append(mActions, mCount, handlerAction);

            mCount++;

        }

    }



    public void executeActions(Handler handler) {

        synchronized (this) {

            final HandlerAction[] actions = mActions;

            for (int i = 0, count = mCount; i < count; i++) {

                final HandlerAction handlerAction = actions[i];

                handler.postDelayed(handlerAction.action, handlerAction.delay);

            }



            mActions = null;

            mCount = 0;

        }

    }



    private static class HandlerAction {

        final Runnable action;

        final long delay;



        public HandlerAction(Runnable action, long delay) {

            this.action = action;

            this.delay = delay;

        }



        public boolean matches(Runnable otherAction) {

            return otherAction == null && action == null

                    || action != null && action.equals(otherAction);

        }

    }

    

    ···

    

}

复制代码

所以说，getRunQueue().post(action)只是将我们提交的 Runnable 对象保存到了 mActions 中，还需要外部主动调用 executeActions方法来执行任务

而这个主动执行任务的操作也是由 View 的 dispatchAttachedToWindow来完成的，从而使得 mActions 中的所有任务都会被插入到 mHandler 的 MessageQueue 中，等到主线程执行完 performTraversals() 方法后就会来执行 mActions，所以此时我们依然可以获取到 View 的真实宽高

	@UnsupportedAppUsage(maxTargetSdk = Build.VERSION_CODES.P)

    void dispatchAttachedToWindow(AttachInfo info, int visibility) {

        mAttachInfo = info;

        ···

        // Transfer all pending runnables.

        if (mRunQueue != null) {

            mRunQueue.executeActions(info.mHandler);

            mRunQueue = null;

        }

        ···

    }

复制代码

二、Handler.post(Runnable)

Handler.post(Runnable)和View.post(Runnable)有什么区别呢？

从上面的源码分析就可以知道，View.post(Runnable)之所以可以获取到 View 的真实宽高，主要就是因为确保了获取 View 宽高的操作一定是在 View 绘制完毕之后才被执行，而 Handler.post(Runnable)之所以不行，就是其无法保证这一点

虽然这两种post(Runnable)的操作都是往同个 MessageQueue 插入任务，且最终都是交由主线程来执行。但绘制视图树的任务是在onResume被回调后才被提交的，所以我们在onCreate中用 Handler 提交的任务就会早于绘制视图树的任务被执行，因此也就无法获取到 View 的真实宽高了

三、onCreate & onResume

在 onCreate、onResume 函数中为什么无法也直接得到 View 的真实宽高呢？

从结果反推原因，这说明当 onCreate、onResume被回调时 ViewRootImpl 的 performTraversals()方法还未执行，那么performTraversals()方法的具体执行时机是什么时候呢？

这可以从 ActivityThread -> WindowManagerImpl -> WindowManagerGlobal -> ViewRootImpl 这条调用链上找到答案

首先，ActivityThread 的 handleResumeActivity 方法就负责来回调 Activity 的 onResume 方法，且如果当前 Activity 是第一次启动，则会向 ViewManager（wm）添加 DecorView

	@Override

    public void handleResumeActivity(IBinder token, boolean finalStateRequest, boolean isForward,

            String reason) {

        ···

        //Activity 的 onResume 方法

        final ActivityClientRecord r = performResumeActivity(token, finalStateRequest, reason);

        ···

        if (r.window == null && !a.mFinished && willBeVisible) {

            ···

            ViewManager wm = a.getWindowManager();

            if (a.mVisibleFromClient) {

                if (!a.mWindowAdded) {

                    a.mWindowAdded = true;

                    //重点

                    wm.addView(decor, l);

                } else {

                    a.onWindowAttributesChanged(l);

                }

            }

        } else if (!willBeVisible) {

            if (localLOGV) Slog.v(TAG, "Launch " + r + " mStartedActivity set");

            r.hideForNow = true;

        }

		···

    }

复制代码

此处的 ViewManager 的具体实现类即 WindowManagerImpl，WindowManagerImpl 会将操作转交给 WindowManagerGlobal

    @UnsupportedAppUsage

    private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();



	@Override

    public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {

        applyDefaultToken(params);

        mGlobal.addView(view, params, mContext.getDisplayNoVerify(), mParentWindow,

                mContext.getUserId());

    }

复制代码

WindowManagerGlobal 就会完成 ViewRootImpl 的初始化并且调用其 setView 方法，该方法内部就会再去调用 performTraversals 方法启动视图树的绘制流程

public void addView(View view, ViewGroup.LayoutParams params,

            Display display, Window parentWindow, int userId) {

        ···

        ViewRootImpl root;

        View panelParentView = null;

        synchronized (mLock) {

            ···

            root = new ViewRootImpl(view.getContext(), display);

            view.setLayoutParams(wparams);

            mViews.add(view);

            mRoots.add(root);

            mParams.add(wparams);

            // do this last because it fires off messages to start doing things

            try {

                root.setView(view, wparams, panelParentView, userId);

            } catch (RuntimeException e) {

                // BadTokenException or InvalidDisplayException, clean up.

                if (index >= 0) {

                    removeViewLocked(index, true);

                }

                throw e;

            }

        }

    }

复制代码

所以说， performTraversals 方法的调用时机是在 onResume 方法之后，所以我们在 onCreate和onResume 函数中都无法获取到 View 的实际宽高。当然，当 Activity 在单次生命周期过程中第二次调用onResume 方法时自然就可以获取到 View 的宽高属性

四、View.post(Runnable) 的兼容性

从以上分析可以得出一个结论：由于 View.post(Runnable)最终都是往和主线程关联的 MessageQueue 中插入任务且最终由主线程来顺序执行，所以即使我们是在子线程中调用View.post(Runnable)，最终也可以得到 View 正确的宽高值

但该结论也只在 API 24 及之后的版本上才成立，View.post(Runnable) 方法也存在着一个版本兼容性问题，在 API 23 及之前的版本上有着不同的实现方式

	//Android API 24 及之后的版本

	public boolean post(Runnable action) {

        final AttachInfo attachInfo = mAttachInfo;

        if (attachInfo != null) {

            return attachInfo.mHandler.post(action);

        }

        // Postpone the runnable until we know on which thread it needs to run.

        // Assume that the runnable will be successfully placed after attach.

        getRunQueue().post(action);

        return true;

    }



	//Android API 23 及之前的版本

	public boolean post(Runnable action) {

        final AttachInfo attachInfo = mAttachInfo;

        if (attachInfo != null) {

            return attachInfo.mHandler.post(action);

        }

        // Assume that post will succeed later

        ViewRootImpl.getRunQueue().post(action);

        return true;

    }

复制代码

在 Android API 23 及之前的版本上，当 attachInfo 为 null 时，会将 Runnable 保存到 ViewRootImpl 内部的一个静态成员变量 sRunQueues 中。而 sRunQueues 内部是通过 ThreadLocal 来保存 RunQueue 的，这意味着不同线程获取到的 RunQueue 是不同对象，这也意味着如果我们在子线程中调用View.post(Runnable) 方法的话，该 Runnable 永远不会被执行，因为主线程根本无法获取到子线程的 RunQueue

    static final ThreadLocal<RunQueue> sRunQueues = new ThreadLocal<RunQueue>();



	static RunQueue getRunQueue() {

        RunQueue rq = sRunQueues.get();

        if (rq != null) {

            return rq;

        }

        rq = new RunQueue();

        sRunQueues.set(rq);

        return rq;

    }

复制代码

此外，由于sRunQueues 是静态成员变量，主线程会一直对应同一个 RunQueue 对象，如果我们是在主线程中调用View.post(Runnable)方法的话，那么该 Runnable 就会被添加到和主线程关联的 RunQueue 中，后续主线程就会取出该 Runnable 来执行

即使该 View 是我们直接 new 出来的对象（就像以下的示例），以上结论依然生效，当系统需要绘制其它视图的时候就会顺便取出该任务，一般很快就会执行到。当然，由于此时 View 并没有 attachedToWindow，所以获取到的宽高值肯定也是 0

        val view = View(Context)

        view.post {

            getWidthHeight("view.Post")

        }

复制代码

对View.post(Runnable)方法的兼容性问题做下总结：

• 当 API < 24 时，如果是在主线程进行调用，那么不管 View 是否有 AttachedToWindow，提交的 Runnable 均会被执行。但只有在 View 被 AttachedToWindow 的情况下才可以获取到 View 的真实宽高


• 当 API < 24 时，如果是在子线程进行调用，那么不管 View 是否有 AttachedToWindow，提交的 Runnable 都将永远不会被执行


• 当 API >= 24 时，不管是在主线程还是子线程进行调用，只要 View 被 AttachedToWindow 后，提交的 Runnable 都会被执行，且都可以获取到 View 的真实宽高值。如果没有被 AttachedToWindow 的话，Runnable 也将永远不会被执行

五、总结

Activity 的 onResume 方法在第一次被调用后，绘制视图树的 Runnable 才会被 Post 到和主线程关联的 MessageQueue 中，虽然该 Runnable 和回调 Activity 的 onResume 方法的操作都是在主线程中执行的，但是该 Runnable 只有等到主线程后续将其从 MessageQueue 取出来后才会被执行，所以这两者其实是构成了异步行为，因此我们在onCreate 和onResume 这两个方法里才无法直接获取到 View 的宽高大小

当 View 还未绘制完成时，通过 View.post(Runnable)提交的 Runnable 会等到 View.dispatchAttachedToWindow方法被调用后才会被保存到 MessageQueue 中，这样也依然保证了该 Runnable 一定是会在 View 绘制完成后才会被执行，所以此时我们才能获取到 View 的宽高大小

除了View.post(Runnable)外，我们还可以通过 OnGlobalLayoutListener 来获取 View 的宽高属性，onGlobalLayout 方法会在视图树发生变化的时候被调用，在该方法中我们就可以来获取 View 的宽高大小

        view.viewTreeObserver.addOnGlobalLayoutListener(object : ViewTreeObserver.OnGlobalLayoutListener {

            override fun onGlobalLayout() {

                view.viewTreeObserver.removeOnGlobalLayoutListener(this)

                val width = view.width

            }

        })

复制代码

按照我自己的想法，系统提供View.post(Runnable)这个方法的目的不仅仅是为了用来获取 View 的宽高等属性这么简单，有可能是为了提供一种优化手段，使得我们可以在整个视图树均绘制完毕后才去执行一些不紧急又必须执行的操作，使得整个视图树可以尽快地呈现出来，以此优化用户体验

Android 系统中，Window 在代码层次上是一个抽象类，在概念上表示的是一个窗口。Android 中所有的视图都是通过 Window 来呈现的，例如 Activity、Dialog 和 Toast 等，它们实际上都是挂载在 Window 上的。大部分情况下应用层开发者很少需要来和 Window 打交道，Activity 已经隐藏了 Window 的具体实现逻辑了，但我觉得来了解 Window 机制的一个比较大的好处是可以加深我们对 View 绘制流程以及事件分发机制的了解，这两个操作就涉及到我们的日常开发了，实现自定义 View 和解决 View 的滑动冲突时都需要我们掌握这方面的知识点，而这两个操作和 Window 机制有很大的关联。视图树只有被挂载到 Window 后才会触发视图树的绘制流程，之后视图树才有机会接收到用户的触摸事件。所以说，视图树被挂载到了 Window 上是 Activity 和 Dialog 等视图能够展示到屏幕上且和用户做交互的前置条件

本文就以 Activity 为例子，展开讲解 Activity 是如何挂载到 Window 上的，基于 Android API 30 进行分析，希望对你有所帮助 😇😇

一、Window

Window 存在的意义是什么呢？

大部分情况下，用户都是在和应用的 Activity 做交互，应用在 Activity 上接收用户的输入并在 Activity 上向用户做出交互反馈。例如，在 Activity 中显示了一个 Button，当用户点击后就会触发 OnClickListener，这个过程中用户就是在和 Activity 中的视图树做交互，此时还没有什么问题。可是，当需要在 Activity 上弹出 Dialog 时，系统需要确保 Dialog 是会覆盖在 Activity 之上的，有触摸事件时也需要确保 Dialog 是先于 Activity 接收到的；当启动一个新的 Activity 时又需要覆盖住上一个 Activity 显示的 Dialog；在弹出 Toast 时，又需要确保 Toast 是覆盖在 Dialog 之上的

这种种要求就涉及到了一个层次管理问题，系统需要对当前屏幕上显示的多个视图树进行统一管理，这样才能来决定不同视图树的显示层次以及在接收触摸事件时的优先级。系统就通过 Window 这个概念来实现上述目的

想要在屏幕上显示一个 Window 并不算多复杂，代码大致如下所示

	private val windowManager by lazy {

        context.getSystemService(Context.WINDOW_SERVICE) as WindowManager

    }



    private val floatBallView by lazy {

        FloatBallView(context)

    }



    private val floatBallWindowParams: WindowManager.LayoutParams by lazy {

        WindowManager.LayoutParams().apply {

            width = FloatBallView.VIEW_WIDTH

            height = FloatBallView.VIEW_HEIGHT

            gravity = Gravity.START or Gravity.CENTER_VERTICAL

            flags =

                WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE or WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL

            type = if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {

                WindowManager.LayoutParams.TYPE_SYSTEM_ALERT

            } else {

                WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY

            }

        }

    }



    fun showFloatBall() {

        windowManager.addView(floatBallView, floatBallWindowParams)

    }

复制代码

显示一个 Window 最基本的操作流程有：

1. 声明希望显示的 View，即本例子中的 floatBallView，其承载了我们希望用户看到的视图界面


2. 声明 View 的位置参数和交互逻辑，即本例子中的 floatBallWindowParams，其规定了 floatBallView 在屏幕上的位置，以及和用户之间的交互逻辑


3. 通过 WindowManager 来添加 floatBallView，从而将 floatBallView 挂载到 Window 上，WindowManager 是外界访问 Window 的入口

当中，WindowManager.LayoutParams 的 flags 属性就用于控制 Window 的显示特性和交互逻辑，常见的有以下几个：

1. 
   

   WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE。表示当前 Window 不需要获取焦点，也不需要接收各种按键输入事件，按键事件会直接传递给下层具有焦点的 Window

   
   


2. 
   

   WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL。表示当前 Window 区域的单击事件希望自己处理，其它区域的事件则传递给其它 Window

   
   


3. 
   

   WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED。表示当前 Window 希望显示在锁屏界面

   
   

此外，WindowManager.LayoutParams 的 type 属性就用于表示 Window 的类型。Window 有三种类型：应用 Window、子 Window、系统 Window。应用类Window 对应 Activity。子 Window 具有依赖关系，不能单独存在，需要附属在特定的父 Window 之中，比如 Dialog 就是一个子 Window。系统 Window 是需要声明权限才能创建的 Window，比如 Toast 和 statusBar 都是系统 Window

从这也可以看出，系统 Window 是处于最顶层的，所以说 type 属性也用于控制 Window 的显示层级，显示层级高的 Window 就会覆盖在显示层级低的 Window 之上。应用 Window 的层级范围是 1～99，子 Window 的层级范围是 1000～1999，系统 Window 的层级范围是 2000～2999。如果想要让我们创建的 Window 位于其它 Window 之上，那么就需要使用比较大的层级值了，但想要显示自定义的系统级 Window 的话就必须向系统动态申请权限

WindowManager.LayoutParams 内就声明了这些层级值，我们可以择需选取。例如，系统状态栏本身也是一个 Window，其 type 值就是 TYPE_STATUS_BAR

    public static class LayoutParams extends ViewGroup.LayoutParams implements Parcelable {



        public int type;



        //应用 Window 的开始值

        public static final int FIRST_APPLICATION_WINDOW = 1;

        //应用 Window 的结束值

        public static final int LAST_APPLICATION_WINDOW = 99;



        //子 Window 的开始值

        public static final int FIRST_SUB_WINDOW = 1000;

        //子 Window 的结束值

        public static final int LAST_SUB_WINDOW = 1999;



        //系统 Window 的开始值

        public static final int FIRST_SYSTEM_WINDOW = 2000;

        //系统状态栏

        public static final int TYPE_STATUS_BAR         = FIRST_SYSTEM_WINDOW;

        //系统 Window 的结束值

        public static final int LAST_SYSTEM_WINDOW = 2999;

        

    }

复制代码

二、WindowManager

每个 Window 都会关联一个 View，想要显示 Window 也离不开 WindowManager，WindowManager 就提供了对 View 进行操作的能力。WindowManager 本身是一个接口，其又继承了另一个接口 ViewManager，WindowManager 最基本的三种操作行为就由 ViewManager 来定义，即添加 View、更新 View、移除 View

public interface ViewManager {

    public void addView(View view, ViewGroup.LayoutParams params);

    public void updateViewLayout(View view, ViewGroup.LayoutParams params);

    public void removeView(View view);

}

复制代码

WindowManager 的实现类是 WindowManagerImpl，其三种基本的操作行为都交由了 WindowManagerGlobal 去实现，这里使用到了桥接模式

public final class WindowManagerImpl implements WindowManager {

    

    private final WindowManagerGlobal mGlobal = WindowManagerGlobal.getInstance();

    

    @Override

    public void addView(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {

        applyDefaultToken(params);

        mGlobal.addView(view, params, mContext.getDisplayNoVerify(), mParentWindow,

                mContext.getUserId());

    }



    @Override

    public void updateViewLayout(@NonNull View view, @NonNull ViewGroup.LayoutParams params) {

        applyDefaultToken(params);

        mGlobal.updateViewLayout(view, params);

    }

    

    @Override

    public void removeView(View view) {

        mGlobal.removeView(view, false);

    }

    

}

复制代码

这里主要看下 WindowManagerGlobal 是如何实现 addView 方法的即可

首先，WindowManagerGlobal 会对入参参数进行校验，并对 LayoutParams 做下参数调整。例如，如果当前要显示的是子 Window 的话，那么就需要使其 LayoutParams 遵循父 Window 的要求才行

	public void addView(View view, ViewGroup.LayoutParams params,

            Display display, Window parentWindow, int userId) {

        if (view == null) {

            throw new IllegalArgumentException("view must not be null");

        }

        if (display == null) {

            throw new IllegalArgumentException("display must not be null");

        }

        if (!(params instanceof WindowManager.LayoutParams)) {

            throw new IllegalArgumentException("Params must be WindowManager.LayoutParams");

        }



        final WindowManager.LayoutParams wparams = (WindowManager.LayoutParams) params;

        if (parentWindow != null) {

            parentWindow.adjustLayoutParamsForSubWindow(wparams);

        } else {

            // If there's no parent, then hardware acceleration for this view is

            // set from the application's hardware acceleration setting.

            final Context context = view.getContext();

            if (context != null

                    && (context.getApplicationInfo().flags

                            & ApplicationInfo.FLAG_HARDWARE_ACCELERATED) != 0) {

                wparams.flags |= WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED;

            }

        }

        ···

    }

复制代码

之后就会为当前的视图树（即 view）构建一个关联的 ViewRootImpl 对象，通过 ViewRootImpl 来绘制视图树并完成 Window 的添加过程。ViewRootImpl 的 setView方法会触发启动整个视图树的绘制流程，即完成视图树的 Measure、Layout、Draw 流程，具体流程可以看我的另一篇文章：一文读懂 View 的 Measure、Layout、Draw 流程

	public void addView(View view, ViewGroup.LayoutParams params,

        			Display display, Window parentWindow, int userId) {

        ···



        ViewRootImpl root;

        View panelParentView = null;



        ···



        root = new ViewRootImpl (view.getContext(), display);



        view.setLayoutParams(wparams);



        mViews.add(view);

        mRoots.add(root);

        mParams.add(wparams);



        // do this last because it fires off messages to start doing things

        try {

            //启动和 view 关联的整个视图树的绘制流程

            root.setView(view, wparams, panelParentView, userId);

        } catch (RuntimeException e) {

            // BadTokenException or InvalidDisplayException, clean up.

            if (index >= 0) {

                removeViewLocked(index, true);

            }

            throw e;

        }

    }

复制代码

ViewRootImpl 内部最终会通过 WindowSession 来完成 Window 的添加过程，mWindowSession 是一个Binder对象，真正的实现类是 Session，也就是说，Window 的添加过程涉及到了 IPC 调用。后面就比较复杂了，能力有限就不继续看下去了

        mOrigWindowType = mWindowAttributes.type;

        mAttachInfo.mRecomputeGlobalAttributes = true;

        collectViewAttributes();

        adjustLayoutParamsForCompatibility(mWindowAttributes);

        res = mWindowSession.addToDisplayAsUser(

            mWindow, mSeq, mWindowAttributes,

            getHostVisibility(), mDisplay.getDisplayId(), userId, mTmpFrame,

            mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,

            mAttachInfo.mDisplayCutout, inputChannel,

            mTempInsets, mTempControls

        );

        setFrame(mTmpFrame);

复制代码

需要注意的是，这里所讲的视图树代表的是很多种不同的视图形式。我们知道，在启动一个 Activity 或者显示一个 Dialog 的时候，都需要为它们指定一个布局文件，布局文件会通过 LayoutInflater 加载映射为一个具体的 View 对象，即最终 Activity 和 Dialog 都会被映射为一个 View 类型的视图树，它们都会通过 WindowManager 的 addView 方法来显示到屏幕上，WindowManager 对于 Activity 和 Dialog 来说具有统一的操作行为入口

三、Activity & Window

这里就以 Activity 为例子来展开讲解 Window 相关的知识点，所以也需要先对 Activity 的组成结构做个大致的介绍。Activity 和 Window 之间的关系可以用以下图片来表示

1. 
   

   每个 Activity 均包含一个 Window 对象，即 Activity 和 Window 是一对一的关系

   
   


2. 
   

   Window 是一个抽象类，其唯一的实现类是 PhoneWindow

   
   


3. 
   

   PhoneWindow 内部包含一个 DecorView，DecorView 是 FrameLayout 的子类，其内部包含一个 LinearLayout，LinearLayout 中又包含两个自上而下的 childView，即 ActionBar 和 ContentParent。我们平时在 Activity 中调用的 setContentView 方法实际上就是在向 ContentParent 执行 addView 操作

   
   

Window 这个抽象类里定义了多个和 UI 操作相关的方法，我们平时在 Activity 中调用的setContentView和findViewById方法都会被转交由 Window 来实现，Window 是 Activity 和视图树系统交互的入口。例如，其 getDecorView() 方法就用于获取内嵌的 DecorView，findViewById() 方法就会将具体逻辑转交由 DecorView 来实现，因为 DecorView 才是真正包含 contentView 的容器类

public abstract class Window {

    

    public Window(Context context) {

        mContext = context;

        mFeatures = mLocalFeatures = getDefaultFeatures(context);

    }

    

    public abstract void setContentView(@LayoutRes int layoutResID);



    @Nullable

    public <T extends View> T findViewById(@IdRes int id) {

        return getDecorView().findViewById(id);

    }

    

    public abstract void setTitle(CharSequence title);

    

    public abstract @NonNull View getDecorView();

    

    ···

    

}

复制代码

四、Activity # setContentView

每个 Activity 内部都包含一个 Window 对象 mWindow，在 attach 方法中完成初始化，这说明 Activity 和 Window 是一对一的关系。mWindow 对象对应的是 PhoneWindow 类，这也是 Window 的唯一实现类

public class Activity extends ContextThemeWrapper implements LayoutInflater.Factory2,

        Window.Callback, KeyEvent.Callback,

        OnCreateContextMenuListener, ComponentCallbacks2,

        Window.OnWindowDismissedCallback,

        AutofillManager.AutofillClient, ContentCaptureManager.ContentCaptureClient {

            

    @UnsupportedAppUsage

    private Window mWindow;



    @UnsupportedAppUsage

    private WindowManager mWindowManager;

               

    @UnsupportedAppUsage

    final void attach(Context context, ActivityThread aThread,

            Instrumentation instr, IBinder token, int ident,

            Application application, Intent intent, ActivityInfo info,

            CharSequence title, Activity parent, String id,

            NonConfigurationInstances lastNonConfigurationInstances,

            Configuration config, String referrer, IVoiceInteractor voiceInteractor,

            Window window, ActivityConfigCallback activityConfigCallback, IBinder assistToken) {

        attachBaseContext(context);



        mFragments.attachHost(null /*parent*/);



        //初始化 mWindow

        mWindow = new PhoneWindow(this, window, activityConfigCallback);

        mWindow.setWindowControllerCallback(mWindowControllerCallback);

        mWindow.setCallback(this);

        mWindow.setOnWindowDismissedCallback(this);

        mWindow.getLayoutInflater().setPrivateFactory(this);

        ···

    }

    

    public void setContentView(@LayoutRes int layoutResID) {

        getWindow().setContentView(layoutResID);

        initWindowDecorActionBar();

    }

              

}

复制代码

Activity 的attach 方法又是在 ActivityThread 的 performLaunchActivity 方法中被调用的，在通过反射生成 Activity 实例后就会调用attach 方法，且可以看到该方法的调用时机是早于 Activity 的 onCreate 方法的。所以说，在生成 Activity 实例后不久其 Window 对象就已经被初始化了，而且早于各个生命周期回调函数

	private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {

        ···

        Activity activity = null;

        try {

            java.lang.ClassLoader cl = appContext.getClassLoader();

            activity = mInstrumentation.newActivity(

                    cl, component.getClassName(), r.intent);

            StrictMode.incrementExpectedActivityCount(activity.getClass());

            r.intent.setExtrasClassLoader(cl);

            r.intent.prepareToEnterProcess();

            if (r.state != null) {

                r.state.setClassLoader(cl);

            }

        } catch (Exception e) {

            if (!mInstrumentation.onException(activity, e)) {

                throw new RuntimeException(

                        "Unable to instantiate activity " + component

                                + ": " + e.toString(), e);

            }

        }



        ···

            

        activity.attach(appContext, this, getInstrumentation(), r.token,

                r.ident, app, r.intent, r.activityInfo, title, r.parent,

                r.embeddedID, r.lastNonConfigurationInstances, config,

                r.referrer, r.voiceInteractor, window, r.configCallback,

                r.assistToken);



        ···

            

        if (r.isPersistable()) {

            mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);

        } else {

            mInstrumentation.callActivityOnCreate(activity, r.state);

        }

        return activity;

    }

复制代码

此外，从 Activity 的setContentView 的方法签名来看，具体逻辑都交由了 Window 的同名方法来实现，传入的 layoutResID 就是我们希望在屏幕上呈现的布局，那么 PhoneWindow 自然就需要去加载该布局文件生成对应的 View。而为了能够有一个对 View 进行统一管理的入口，View 应该要包含在一个指定的 ViewGroup 中才行，该 ViewGroup 指的就是 DecorView

下面就再来看下 PhoneWindow 是如何处理这一个流程的

五、PhoneWindow # setContentView

PhoneWindow 的 setContentView 方法的逻辑可以总结为：

1. PhoneWindow 内部包含一个 DecorView 对象 mDecor。DecorView 是 FrameLayout 的子类，其内部包含两个我们经常会接触到的 childView：actionBar 和 contentParent，actionBar 即 Activity 的标题栏，contentParent 即 Activity 的视图内容容器


2. 如果 mContentParent 为 null 的话则调用 installDecor() 方法来初始化 DecorView，从而同时初始化 mContentParent；不为 null 的话则移除 mContentParent 的所有 childView，为 layoutResID 腾出位置（不考虑转场动画，实际上最终的操作都一样）


3. 通过LayoutInflater.inflate生成 layoutResID 对应的 View，并将其添加到 mContentParent 中，从而将我们的目标视图挂载到一个统一的容器中（不考虑转场动画，实际上最终的操作都一样）


4. 当 ContentView 添加完毕后会回调 Callback.onContentChanged 方法，我们可以通过重写 Activity 的该方法从而得到布局内容改变的通知

所以说，Activity 的 setContentView 方法实际上就是在向 DecorView 的 mContentParent 执行 addView 操作，所以该方法才叫setContentView而非setView

public class PhoneWindow extends Window implements MenuBuilder.Callback {

    

	private DecorView mDecor;



    ViewGroup mContentParent;

    

    @Override

    public void setContentView(int layoutResID) {

        // Note: FEATURE_CONTENT_TRANSITIONS may be set in the process of installing the window

        // decor, when theme attributes and the like are crystalized. Do not check the feature

        // before this happens.

        if (mContentParent == null) {

            installDecor();

        } else if (!hasFeature(FEATURE_CONTENT_TRANSITIONS)) {

            mContentParent.removeAllViews();

        }



        if (hasFeature(FEATURE_CONTENT_TRANSITIONS)) {

            final Scene newScene = Scene.getSceneForLayout(mContentParent, layoutResID,

                    getContext());

            transitionTo(newScene);

        } else {

            //将 layoutResID 对应的 View 添加到 mContentParent 中

            mLayoutInflater.inflate(layoutResID, mContentParent);

        }

        

        mContentParent.requestApplyInsets();

        final Callback cb = getCallback();

        if (cb != null && !isDestroyed()) {

            //回调通知 contentView 发生变化了

            cb.onContentChanged();

        }

        mContentParentExplicitlySet = true;

    }

    

	private void installDecor() {

        mForceDecorInstall = false;

        if (mDecor == null) {

            mDecor = generateDecor(-1);

            mDecor.setDescendantFocusability(ViewGroup.FOCUS_AFTER_DESCENDANTS);

            mDecor.setIsRootNamespace(true);

            if (!mInvalidatePanelMenuPosted && mInvalidatePanelMenuFeatures != 0) {

                mDecor.postOnAnimation(mInvalidatePanelMenuRunnable);

            }

        } else {

            mDecor.setWindow(this);

        }

        if (mContentParent == null) {

            mContentParent = generateLayout(mDecor);



            // Set up decor part of UI to ignore fitsSystemWindows if appropriate.

            mDecor.makeFrameworkOptionalFitsSystemWindows();



            final DecorContentParent decorContentParent = (DecorContentParent) mDecor.findViewById(

                    R.id.decor_content_parent);



            if (decorContentParent != null) {

                mDecorContentParent = decorContentParent;

                ···

            } else {

                ···

            }

            ···

        }

    }

    

}

复制代码

mContentParent 通过 generateLayout 方法来完成初始化，该方法主要完成的操作有两个：

1. 读取我们为 Activity 设置的 theme 属性，以此配置基础的 UI 风格。例如，如果我们设置了 <item name="windowNoTitle">true</item>的话，那么就会执行 requestFeature(FEATURE_NO_TITLE) 来隐藏标题栏


2. 根据 features 来选择合适的布局文件，得到 layoutResource。之所以会有多种布局文件，是因为不同的 Activity 会有不同的显示要求，有的要求显示 title，有的要求显示 leftIcon，而有的可能全都不需要，为了避免控件冗余就需要来选择合适的布局文件。而虽然每种布局文件结构上略有不同，但均会包含一个 ID 名为content的 FrameLayout，mContentParent 就对应该 FrameLayout。DecorView 会拿到 layoutResource 并生成对应的 View 对象（对应 DecorView 中的 mContentRoot），并将其添加为mContentParent的 childView

	protected ViewGroup generateLayout(DecorView decor) {

        // Apply data from current theme.



        TypedArray a = getWindowStyle();



        ···

		

        //第一步

        if (a.getBoolean(R.styleable.Window_windowNoTitle, false)) {

            requestFeature(FEATURE_NO_TITLE);

        } else if (a.getBoolean(R.styleable.Window_windowActionBar, false)) {

            // Don't allow an action bar if there is no title.

            requestFeature(FEATURE_ACTION_BAR);

        }



        ···



        // Inflate the window decor.



        //第二步

        int layoutResource;

        int features = getLocalFeatures();

        // System.out.println("Features: 0x" + Integer.toHexString(features));

        ···

        //交由 DecorView 去生成 layoutResource 对应的 View

        mDecor.onResourcesLoaded(mLayoutInflater, layoutResource);



        //正常来说每种 layoutResource 都会包含一个 ID 为 ID_ANDROID_CONTENT 的 ViewGroup

        //如果找不到的话就直接抛出异常

        ViewGroup contentParent = (ViewGroup)findViewById(ID_ANDROID_CONTENT);

        if (contentParent == null) {

            throw new RuntimeException("Window couldn't find content container view");

        }



        ···

        return contentParent;

    }

复制代码

当我们new了一个对象，会发生什么呢？来段代码：

public class Tested {

    public static int T = 10;

    public int c = 1;

}

复制代码

类初始化

在编译期，编译器会将 Tested.java类转换成 Tested.class 字节码文件。当虚拟机接收到new 字节码指令时，如果此时类还未被初始化，则虚拟机会先进行类的初始化过程。

在类加载完成后。虚拟机会为new Tested() 的Tested对象，在java堆中分配内存。而对象所需要的内存大小在类加载完成后就被确定了。

指针碰撞

如果 java 中的内存是规整的，即使用过的放在一边，空闲的在另一边，中间放着指针作为分界点的指示器。那所分配的内存就仅仅是将指针像空闲空间挪动一段与对象大小相等的距离。这种方式内称为指针碰撞。

空闲列表

如果 java 中的内存是不工整的，使用过的和空闲的内存相互交错，那么虚拟机就必须维护一个列表记录哪些内存是可用的。在分配的时候从列表中找到一块足够大的空间给对象示例，并更新表的记录。这种分配方式称为空闲列表。

对象初始化

当我们的对象内存被分配完毕后，虚拟机就会对对象进行初始化操作。

此时Tested 对象在我们眼里就算出生了，在虚拟机眼里就是真正可用的了。可对象的生命并不是无穷的，它也会经历自己的死亡。

可达性分析

在主流实现中，我们通过可达性分析来判断一个对象是否存活。实现思路是：通过一系列被称为 “GC Roots” 的对象作为起始点，从这些节点开始像下搜索，搜索所走的路径被称为引用链，当一个对象到GC Roots没有任何引用链相连，则证明此对象是不可用的。见图：

即使 Obj5 与 Obj4 由于与 GC Roots 没有引用链相连，所以我们称 GC Roots 到对象 Obj4 和 Obj5 不可达。所以 Obj4 和 Obj5 就是可回收的。

既然Obj4 和 Obj5 是可回收的，那么是否一定会被回收呢？不一定。此时虚拟机会进行第一次的标记过程。因为 java 内能够重写 finalize() 方法（在这里只是分析特例，不推荐在任何情况下使用此方法），当对象重写了此方法，并且 finalize() 方法还未被虚拟机调用，那么虚拟机就会将此对象放入一个专门的F-Queue队列，由一个单独的 Finalizer 线程去执行它，如果队列中对象的 finalize() 方法在虚拟机第二次标记之前执行，并在此次执行过程中又将自己与GC Roots 引用链相连，那么虚拟机在进行第二次标记时，就会将该对象从 F-Queue队列移除，否则就宣告该对象死亡。注意：finalize() 方法只会被执行一次，所以一个对象一生只有一次机会进入F-Queue队列，有机会逃脱本此死亡。

如果对象已经宣告死亡了，那么虚拟机怎么来回收它吗？

标记-清除算法

这是最基础的收集算法，主要分为标记和清除两个阶段。首先标记出所以需要回收的对象，在标记完成后统一回收所有被标记的对象。可以参考上面的空闲列表。其有两点不足：

a. 效率问题，标记和清除两个过程效率都不高。

b. 空间问题，因为堆中的内存不是规整的，已使用的和空闲的内存相互交错，这也就导致了每次GC回收后，产生大量的内存碎片，而当再次分配一个大对象时，如果无法找到足够的连续内存，又会再此触发GC回收。

复制算法

复制算法是将堆内存分成大小相等的两块，每次只使用其中一块，这样内存就是规整的了，参考指针碰撞。每当一块内存使用完了，就将该块内存中存活的对象复制到另一边，随后将该块内存一次清理掉。

现在的虚拟机都采用这种方式来回收新生代，只是并不是按照1:1的比例来划分内存，而是将内存分为一块较大的 Eden 空间，和两块较小的 Survivor 空间（HotSpot虚拟机默认Eden：Survivor = 8 :1）。每次只使用 Eden 和 其中一块 Survivor 空间，当回收时，将 Eden 空间和当前正使用的 Survivor 空间内存活的对象复制到另一块空闲的 Survivor空间，随后清空 Eden 和 刚才用过的 Survivor 内存。

注意：由于我们无法保证每次 存活的对象所占内存一直都不大于 Survivor 内存值，所以就会有溢出风险。所以在 分代收集算法 中，虚拟机会将内存先划分为一块新生代内存和一块为老年代内存。而在新生代内存中，会采用这种8:1:1的内存分配方式，如果溢出了，就将该情况下的存活对象全部放在老年代内存里，说白了就是一种兜底策略。这里要注意的是，不是溢出的那部分，而是全部的存活对象。

标记-整理算法

标记-整理算法中的标记过程，与标记-清除算法中的标记过程一样，不同的是，当标记完成并清理回收完对象后，会将当前不连续的碎片内存就行整理，即存活的对象都移到一端，来保证接下来要分配的内存的规整性。我们的 分代收集算法 中的老年代内存块，就是采用的该算法（当然也可以是标记-清除算法，不同虚拟机的策略不同）。所以就不再对分代收集算法就行赘述了。

好了，本文到这里，关于“对象”的生命周期的讲解就结束了。如果本文对你有用，来点个赞吧，大家的肯定也是阿呆i坚持写作的动力。

参考
1、周志明，深入理解JAVA虚拟机：机械工业出版社

在说动态代理之前，先来简单看下代理模式。代理是最基本的设计模式之一。它能够插入一个用来替代“实际”对象的“代理”对象，来提供额外的或不同的操作。这些操作通常涉及与“实际”对象的通信，因此“代理”对象通常充当着中间人的角色。

代理模式

代理对象为“实际”对象提供一个替身或占位符以控制对这个“实际”对象的访问。被代理的对象可以是远程的对象，创建开销大的对象或需要安全控制的对象。来看下类图：

再来看下类图对应代码，这是IObject接口，真实对象RealObj和代理对象ObjProxy都实现此接口：

/**

 * 为实际对象Tested和代理对象TestedProxy提供对外接口

 */

public interface IObject {

    void request();

}

复制代码

RealObj是实际处理request() 逻辑的对象，但是出于设计的考量，需要对RealObj内部的方法调用进行控制访问

public class RealObject implements IObject {



    @Override

    public void request() {

        // 模拟一些操作

    }

}

复制代码

ObjProxy是RealObj的代理类，其同样实现了IObject接口，所以具有相同的对外方法。客户端与RealObj的所有交互，都必须通过ObjProxy。

public class ObjProxy implements IObject {

    IObject realT;



    public ObjProxy(IObject t) {

        realT = t;

    }



    @Override

    public void request() {

        if (isAllow()) realT.request();

    }



    private boolean isAllow() {

        return true;

    }

}

复制代码

番外

代理模式和装饰者模式不管是在类图，还是在代码实现上，几乎是一样的，但我们为何还要进行划分呢？其实学设计模式，不能拘泥于格式，不能死记形式，重要的是要理解模式背后的意图，意图只有一个，但实现的形式却可能多种多样。这也就是为何那么多变体依然属于xx设计模式的原因。

代理模式的意图是替代真正的对象以实现访问控制，而装饰者模式的意图是为对象加入额外的行为。

动态代理

Java的动态代理可以动态的创建代理并动态的处理所代理方法的调用，在动态代理上所做的所以调用都会被重定向到单一的调用处理器上，它的工作是揭示调用的类型并确定相应的策略。类图见下：

还以上面的代码为例，这是对外的接口IObject：

public interface IObject {

    void request();

}

复制代码

这是 InvocationHandler 的实现类，类图中 Proxy 的方法调用都会被系统传入此类，即 invoke 方法，而 ObjProxyHandler 又持有着 RealObject 实例，所以 ObjProxyHandler 是“真正”对 RealObject 对象进行访问控制的代理类。

public class ObjProxyHandler implements InvocationHandler {

    IObject realT;



    public ObjProxyHandler(IObject t) {

        realT = t;

    }



    @Override

    public Object invoke(Object proxy, Method method, Object[] args)

            throws Throwable {

        // request方法时，进行校验

        if (method.getName().equals("request") && !isAllow())

            return null;

        return method.invoke(realT, args);

    }



    private boolean isAllow() {

        return false;

    }

}

复制代码

RealObj是实际处理request() 逻辑的对象。

public class RealObject implements IObject {

    @Override

    public void request() {

        // 模拟一些操作

    }

}

复制代码

动态代理的使用方法如下：我们通过 Proxy.newProxyInstance 静态方法来创建代理，其参数如下，一个类加载器、一个代理实现的接口列表、一个 InvocationHandler 的接口实现。

    public void startTest() {

        IObject proxy = (IObject) Proxy.newProxyInstance(

                IObject.class.getClassLoader(),

                new Class[]{IObject.class},

                new ObjProxyHandler(new RealObject()));

        proxy.request(); // ObjProxyHandler的invoke方法会被调用

    }

复制代码

Proxy源码

来看下Proxy 源码，当我们 newProxyInstance(...) 时，首先系统会进行判空处理，之后获取我们实际的 Proxy 代理类 Class 对象，再通过一个参数的构造方法生成我们的代理对象 p（p : 返回值），这里能看出来 p 是持有我们的对象 h 的。注意 cons.setAccessible(true) 表示，即使是 cl 是私有构造，也可以获得对象。源码见下：

public static Object newProxyInstance(ClassLoader loader,

                                          Class<?>[] interfaces,

                                          InvocationHandler h)

        throws IllegalArgumentException

    {

        Objects.requireNonNull(h);



        final Class<?>[] intfs = interfaces.clone();

     

        /*

         * Look up or generate the designated proxy class.

         */

        Class<?> cl = getProxyClass0(loader, intfs);

        ...

        final Constructor<?> cons = cl.getConstructor(constructorParams);

            final InvocationHandler ih = h;

            if (!Modifier.isPublic(cl.getModifiers())) {

                cons.setAccessible(true);

                // END Android-removed: Excluded AccessController.doPrivileged call.

            }

            return cons.newInstance(new Object[]{h});

        ...

    }

复制代码

其中 getProxyClass0(...) 是用来检查并获取实际代理对象的。首先会有一个65535的接口限制检测，随后从代理缓存proxyClassCache 中获取代理类，如果给定的接口不存在，则通过 ProxyClassFactory 新建。见下：

    private static Class<?> getProxyClass0(ClassLoader loader,

                                           Class<?>... interfaces) {

        if (interfaces.length > 65535) {

            throw new IllegalArgumentException("interface limit exceeded");

        }



        // If the proxy class defined by the given loader implementing

        // the given interfaces exists, this will simply return the cached copy;

        // otherwise, it will create the proxy class via the ProxyClassFactory

        return proxyClassCache.get(loader, interfaces);

    }

复制代码

存放代理 Proxy.class 的缓存 proxyClassCache，是一个静态常量，所以在我们类加载时，其就已经被初始化完毕了。见下：

private static final WeakCache<ClassLoader, Class<?>[], Class<?>>

        proxyClassCache = new WeakCache<>(new KeyFactory(), new ProxyClassFactory());

复制代码

Proxy 提供的 getInvocationHandler(Object proxy)方法和 invoke(...) 方法很重要。分别为获取当前代理关联的调用处理器对象 InvocationHandler，并将当前Proxy方法调用 调度给 InvocationHandler。是不是与上面的代理思维很像，至于这两个方法何时被调用的，推测是写在了本地方法内，当我们调用proxy.request 方法时（系统创建Proxy时，会自动 implements 用户传递的接口，可以为多个），系统就会调用Proxy invoke 方法，随后proxy 将方法调用传递给 InvocationHandler。

public static InvocationHandler getInvocationHandler(Object proxy)

        throws IllegalArgumentException

    {

        /*

         * Verify that the object is actually a proxy instance.

         */

        if (!isProxyClass(proxy.getClass())) {

            throw new IllegalArgumentException("not a proxy instance");

        }

        final Proxy p = (Proxy) proxy;

        final InvocationHandler ih = p.h;

   

        return ih;

    }



    // Android-added: Helper method invoke(Proxy, Method, Object[]) for ART native code.

    private static Object invoke(Proxy proxy, Method method, Object[] args) throws Throwable {

        InvocationHandler h = proxy.h;

        return h.invoke(proxy, method, args);

    }

复制代码

ProxyClassFactory

重点是ProxyClassFactory 类，这里的逻辑不少，所以我将ProxyClassFactory 单独抽出来了。能看到，首先其会检测当前interface 是否已被当前类加载器所加载。

        Class<?> interfaceClass = null;

        try {

            interfaceClass = Class.forName(intf.getName(), false, loader);

        } catch (ClassNotFoundException e) {

        }

        if (interfaceClass != intf) {

            throw new IllegalArgumentException(

                intf + " is not visible from class loader");

        }

复制代码

之后会进行判断是否为接口。这也是我们说的第二个参数为何不能传基类或抽象类的原因。

        if (!interfaceClass.isInterface()) {

            throw new IllegalArgumentException(

                interfaceClass.getName() + " is not an interface");

        }

复制代码

之后判断当前 interface 是否已经存在于缓存cache内了。

        if (interfaceSet.put(interfaceClass, Boolean.TRUE) != null) {

            throw new IllegalArgumentException(

                "repeated interface: " + interfaceClass.getName());

        }

复制代码

检测非 public 修饰符的 interface 是否在是同一个包名，如果不是则抛出异常

    for (Class<?> intf : interfaces) {

        int flags = intf.getModifiers();

        if (!Modifier.isPublic(flags)) {

            accessFlags = Modifier.FINAL;

            String name = intf.getName();

            int n = name.lastIndexOf('.');

            String pkg = ((n == -1) ? "" : name.substring(0, n + 1));

            if (proxyPkg == null) {

                proxyPkg = pkg;

            } else if (!pkg.equals(proxyPkg)) {

                throw new IllegalArgumentException(

                    "non-public interfaces from different packages");

            }

            ...



复制代码

检验通过后，会 getMethods(...) 获取接口内的全部方法。

随后会对methords进行一个排序。具体的代码我就不贴了，排序规则是：如果方法相等（返回值和方法签名一样）或同是一个接口内方法，则当前顺序不变，如果两个方法所在的接口存在继承关系，则父类在前，子类在后。

之后 validateReturnTypes(...) 判断 methords 是否存在方法签名相同并且返回值类型也相同的methord，如果有则抛出异常。

之后通过 deduplicateAndGetExceptions(...) 方法，将 methords 方法内的相同方法的父类方法剔除掉，并将 methord 保存在数组中。

转成一维数组和二维数组，Method[] methodsArray，Class< ? >[][] exceptionsArray，随后给当前代理类命名：包名 + “$Proxy” + num

最后调用系统提供的 native 方法 generateProxy(...) 。这是真正的代理类创建方法。感兴趣的可以查看下java_lang_reflect_Proxy.cc源码
和 class_linker.cc源码

        List<Method> methods = getMethods(interfaces);

        Collections.sort(methods, ORDER_BY_SIGNATURE_AND_SUBTYPE);

        validateReturnTypes(methods);

        List<Class<?>[]> exceptions = deduplicateAndGetExceptions(methods);



        Method[] methodsArray = methods.toArray(new Method[methods.size()]);

        Class<?>[][] exceptionsArray = exceptions.toArray(new Class<?>[exceptions.size()][]);



        /*

         * Choose a name for the proxy class to generate.

         */

        long num = nextUniqueNumber.getAndIncrement();

        String proxyName = proxyPkg + proxyClassNamePrefix + num;



        return generateProxy(proxyName, interfaces, loader, methodsArray,

                             exceptionsArray);

复制代码

好了，本文到这里就结束了，关于动态代理的讲解也应该够用了。如果本文对你有用，来点个赞吧，大家的肯定也是阿呆i坚持写作的动力。

参考
1、Head First 设计模式：中国电力出版社

数据结构是指相互之间存在着一种或多种关系的数据元素的集合和该集合中数据元素之间的关系组成

简单来说：数据结构是以某种特定的布局方式存储数据的容器。这种“布局方式”决定了数据结构对于某些操作是高效的，而对于其他操作则是低效的。首先我们需要理解各种数据结构，才能在处理实际问题时选取最合适的数据结构。

1、数组

数组是可以再内存中连续存储多个元素的结构，在内存中的分配也是连续的，数组中的元素通过数组下标进行访问，数组下标从0开始

NSArray *array = [NSArray arrayWithObjects:@"1",@"2",@"3",@"4", nil];
//    NSArray *array = @[@"1",@"2",@"3",@"4"];
NSLog(@"%@",array[0]);

优点：

线性表是最基本、最简单、也是最常用的一种数据结构。线性表（linear list）是数据结构的一种，一个线性表是n个具有相同特性的数据元素的有限序列。

线性表中数据元素之间的关系是一对一的关系，即除了第一个和最后一个数据元素之外，其它数据元素都是首尾相接的（注意，这句话只适用大部分线性表，而不是全部。比如，循环链表逻辑层次上也是一种线性表（存储层次上属于链式存储），但是把最后一个数据元素的尾指针指向了首位结点）

在日常的应用中，我们讨论和用的更多的是树的其中一种结构，就是二叉树。

二叉树是树的特殊一种，具有如下特点：

• 1、每个结点最多有两颗子树，结点的度最大为2。
• 2、左子树和右子树是有顺序的，次序不能颠倒。
• 3、即使某结点只有一个子树，也要区分左右子树。

二叉树是一种比较有用的折中方案，它添加，删除元素都很快，并且在查找方面也有很多的算法优化，所以，二叉树既有链表的好处，也有数组的好处，是两者的优化方案，在处理大批量的动态数据方面非常有用。

1. 问题/坑点

1.1 item宽高不生效问题

需要注意的是，AdapterViewFlipper 在布局时，宽高一定要用 match_parent 或者 具体dp值。

如果宽、高中使用了 wrap_content 时，会导致 AdapterViewFlipper 容器的宽高，最终变成第一个item的宽高。即使后续item的宽高超过第一个item，也不会生效，内容显示只会被限定在第一个的宽高范围内。

原理也很好理解，后续item没有绘制出来时， wrap_content 计算出来的结果，就是第一个item的宽高。当后续 item 显示的时候，没有地方去重新更新父容器 AdapterViewFlipper 的宽高。

2. 常用方法

1. 
   

   AdapterViewAnimator支持的XML属性如下：

   
   
   
   
   • android:animateFirstView：设置显示组件的第一个View时是否使用动画。
   
   
   • android:inAnimation：设置组件显示时使用的动画。
   
   
   • android:loopViews：设置循环到最后一个组件时是否自动跳转到第一个组件。
   
   
   • android:outAnimation：设置组件隐藏时使用的动画。
   
   
   
   


2. 
   

   轮播控制：

   
   
   
   
   • startFlipping、stopFlipping : 开始、停止播放
   
   
   • showPrevious、showNext：上一个、下一个
   
   
   
   


3. 
   

   轮播状态与参数

   
   
   
   
   • isFlipping：是否轮播中
   
   
   • flipInterval: 动画间隔
   
   
   
   


4. 
   

   设置入场、出场动画：setInAnimation、setOutAnimation

   
   

3. 文字/图片 轮播 Demo

/**

 * 图片/文字轮播

 * 坑点：text_flipper height 如果设置wrap_content 导致item宽度只会以第一个item的为准

 */

class FlipperAnimActivity : AppCompatActivity(), View.OnClickListener {



    private var textFlipper: AdapterViewFlipper? = null

    private var imgFlipper: AdapterViewFlipper? = null

    private var preBtn: Button? = null

    private var nextBtn: Button? = null

    private var autoBtn: Button? = null



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_flipper_anim)

        initTextFlipper()

        initImgFlipper()

    }



    // 文字轮播

    private fun initTextFlipper() {

        textFlipper = findViewById(R.id.text_flipper)

        val list = listOf("文字轮播测试0", "文字轮播测试02...")

        textFlipper?.adapter = TextFlipperAdapter(this, list)

        textFlipper?.setInAnimation(this, R.animator.text_flipper_in_from_bottom)

        textFlipper?.setOutAnimation(this, R.animator.text_flipper_out_to_top)

//        textFlipper?.flipInterval

//        textFlipper?.startFlipping()

    }



    // 图片轮播

    private fun initImgFlipper() {

        imgFlipper = findViewById(R.id.img_flipper)

        val list = listOf("http://www.nicesoso.com/test/file/img/test.jpg", "http://www.nicesoso.com/test/file/img/test_h_1.jpg",

                "http://www.nicesoso.com/test/file/img/test_h_2.jpg")

        imgFlipper?.adapter = ImgFlipperAdapter(this, list)

        imgFlipper?.setInAnimation(this, R.animator.img_flipper_in)

        preBtn = findViewById(R.id.prev_btn)

        nextBtn = findViewById(R.id.next_btn) as Button

        autoBtn = findViewById(R.id.auto_btn) as Button



        preBtn?.setOnClickListener(this)

        nextBtn?.setOnClickListener(this)

        autoBtn?.setOnClickListener(this)

    }



    override fun onClick(v: View?) {

        when (v?.id) {

            R.id.prev_btn -> {

                imgFlipper?.showPrevious()

                imgFlipper?.stopFlipping()

            }

            R.id.next_btn -> {

                imgFlipper?.showNext()

                imgFlipper?.stopFlipping()

            }

            R.id.auto_btn -> {

                imgFlipper?.startFlipping()

            }

        }

    }



    override fun onDestroy() {

        super.onDestroy()

        textFlipper?.takeIf { it.isFlipping }?.stopFlipping()

        imgFlipper?.takeIf { it.isFlipping }?.stopFlipping()

    }

}

复制代码

3.1 文字轮播：TextFlipperAdapter

class TextFlipperAdapter(private val context: Context, private val datas: List<String>) : BaseAdapter() {

    override fun getView(position: Int, convertView: View?, parent: ViewGroup?): View {

        val view = convertView ?: LayoutInflater.from(context).inflate(R.layout.item_flipper_text, parent, false)

        val textView = view?.findViewById<TextView?>(R.id.text)

        textView?.text = datas.get(position)

        return view

    }



    override fun getItem(position: Int): Any {

        return datas.get(position)

    }



    override fun getItemId(position: Int): Long {

        return position.toLong()

    }



    override fun getCount(): Int {

        return datas.size

    }

}

复制代码

3.2 图片轮播：ImgFlipperAdapter

class ImgFlipperAdapter(private val context: Context, private val datas: List<String>) : BaseAdapter() {

    override fun getView(position: Int, convertView: View?, parent: ViewGroup?): View {

        val view = convertView ?: ImageView(context)

        (view as? ImageView)?.scaleType = ImageView.ScaleType.FIT_XY

        view.layoutParams = ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT, ViewGroup.LayoutParams.MATCH_PARENT)

        (view as? ImageView)?.let { Glide.with(context).load(datas.get(position)).into(it) }  



        return view

    }



    override fun getItem(position: Int): Any {

        return datas.get(position)

    }



    override fun getItemId(position: Int): Long {

        return position.toLong()

    }



    override fun getCount(): Int {

        return datas.size

    }

}





复制代码

3.3 布局：activity_flipper_anim.xml

<?xml version="1.0" encoding="utf-8"?>

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"

    xmlns:tools="http://schemas.android.com/tools"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    android:orientation="vertical">



    <RelativeLayout

        android:layout_width="match_parent"

        android:layout_height="100dp"

        android:background="@android:color/holo_red_light"

        android:orientation="vertical">



        <!--宽高要必须设置填充满，否则wrap_content时，大小变成第一个item的大小-->

        <AdapterViewFlipper

            android:id="@+id/text_flipper"

            android:layout_width="match_parent"

            android:layout_height="match_parent"

            android:autoStart="true"

            android:flipInterval="2000" />

    </RelativeLayout>



    <RelativeLayout

        android:layout_width="match_parent"

        android:layout_height="0dp"

        android:layout_weight="1">



        <AdapterViewFlipper

            android:id="@+id/img_flipper"

            android:layout_width="match_parent"

            android:layout_height="match_parent"

            android:layout_alignParentTop="true"

            android:flipInterval="5000" />



        <TextView

            android:layout_width="match_parent"

            android:layout_height="wrap_content"

            android:layout_alignParentTop="true"

            android:gravity="center"

            android:text="图片轮播测试（5s）"

            android:textSize="24sp" />



        <Button

            android:id="@+id/prev_btn"

            android:layout_width="wrap_content"

            android:layout_height="wrap_content"

            android:layout_alignParentLeft="true"

            android:layout_alignParentBottom="true"

            android:text="上一个" />



        <Button

            android:id="@+id/next_btn"

            android:layout_width="wrap_content"

            android:layout_height="wrap_content"

            android:layout_alignParentBottom="true"

            android:layout_centerHorizontal="true"

            android:text="下一个" />



        <Button

            android:id="@+id/auto_btn"

            android:layout_width="wrap_content"

            android:layout_height="wrap_content"

            android:layout_alignParentRight="true"

            android:layout_alignParentBottom="true"

            android:text="自动播放" />



    </RelativeLayout>

</LinearLayout>

复制代码

3.4 动画

文字轮播，入场动画：res/animator/text_flipper_in_from_bottom.xml

<?xml version="1.0" encoding="utf-8"?>

<objectAnimator xmlns:android="http://schemas.android.com/apk/res/android"

    android:duration="300"

    android:interpolator="@android:anim/accelerate_decelerate_interpolator"

    android:propertyName="y"

    android:valueFrom="100"

    android:valueTo="0"

    android:valueType="floatType" />

复制代码

文字轮播，出场动画：res/animator/text_flipper_out_to_top.xml

<?xml version="1.0" encoding="utf-8"?>

<objectAnimator xmlns:android="http://schemas.android.com/apk/res/android"

    android:duration="300"

    android:interpolator="@android:anim/accelerate_decelerate_interpolator"

    android:propertyName="y"

    android:valueFrom="0"

    android:valueTo="-100"

    android:valueType="floatType" />

复制代码

图片轮播，入场动画：res/animator/img_flipper_in.xml

<?xml version="1.0" encoding="utf-8"?>

<objectAnimator xmlns:android="http://schemas.android.com/apk/res/android"

    android:duration="300"

    android:interpolator="@android:anim/accelerate_decelerate_interpolator"

    android:propertyName="x"

    android:valueFrom="500"

    android:valueTo="0"

    android:valueType="floatType" />

复制代码

参考

1. AdapterViewFlipper轻松完成图片轮播

在今年的 2 月 3 日，Jcenter 运营官方发布一则通告称：包括 GoCenter、Bintray、JCenter 在内的多项软件包管理和分发服务都将停止运营。

UPDATE: To better support the community in this migration, JFrog has extended the JCenter new package versions submission deadline through March 31st 2021.

To clarify, the JCenter repository will keep serving packages for 12 months until February 1st 2022. Only the JCenter REST API and UI will be sunsetted on May 1st 2021.

原文链接如下：jfrog.com/blog/into-t…

对于 JFrog 停止运营 Jcenter 的原因我们不予置评。但是 Jcenter 仓库作为 Android 开发者使用最多的仓库，突然停止运营对于很多开发者和开源企业都带来很大的影响。同样我们神策 Android 系的 SDK 都是开源发布在 Jcenter 仓库上，所以我们内部也开始启动迁移方案的调研，在这个过程中，我们主要调研了三种备选方案：JitPack 仓库、公有 Maven 仓库和私有 Maven 仓库，最终我们采用发布到公有 Maven 仓库作为主选，发布到 JitPack 仓库作为备份应急，过渡阶段也会继续发布到 Jcenter。本篇文章主要介绍公有 Maven 和 JitPack 仓库的发布流程。

1. JitPack 仓库

JitPack 是一个基于 GitHub 开源仓库的发布仓库，它完美地与 GitHub 仓库兼容，使用 Jcenter 发布仓库时，我们需要在脚本中标注对应的 GroupId、Artifac 等信息，但是使用 JitPack 可以省去 Jcenter 发布过程中诸多繁琐的配置。下面介绍基于 JitPack 仓库发布的步骤。

1.1. 发布 GitHub Release

当我们的代码从本地分支推送到 GitHub 远程分支后，我们就可以发布一个版本的 Release。 在仓库的 Release 主页面，点击“Draft a new release”按钮发布一个新版本。这里我们以我们开源的一款 SDK 为例。

分别填写 Tag version、Release title、Describe this release 字段，我们以本次提交的版本是 1.2.3 为例：

• Tag version：v1.2.3


• Release title： Release 1.2.3

最后点击下方的“Publish release”绿色按钮。

1.2. Jitpack 发布

进入Jitpack 官方，使用 GitHub 账号进行登录。

• 点击右上角「Sign In」使用 GitHub 账号登录


• 在「Git repo url」中输入需要发布的仓库地址

这里依照神策分析埋点 SDK 为例：

配置项说明：

• Releases：已发布的 Release 版本；


• Builds：构建记录；


• Branches：当前仓库的分支；


• Commits：提交记录；

在 Releases 选项卡页面，点击「Get it」按钮即可进行对应版本的发布。发布成功后 Log 选项卡会呈现绿色，提示「Status：ok」，反之则是红色，提示错误异常信息。

1.3. 版本引用

第一步：在项目根目录的 build.gradle 文件中添加：

allprojects {

repositories {

...

maven { url '[https://jitpack.io](https://jitpack.io/)' }

}

}

第二步：在项目 Module 下的 build.gradle 文件中添加：

dependencies {

implementation 'com.github.sensorsdata:sa-sdk-android:5.1.3'

}

至此我们就完成了版本远程仓库的发布和引用。

1.4. 版本删除

在 JitPack 仓库包中，如果一个版本出现 Bug 需要删除，则需要现在 GitHub 的 Release 中删除该版本即可。

2. 公有 Maven 仓库

或许当初是由于发布到 Maven 仓库流程过于繁琐，Android 才会选择 Jcenter 作为默认的仓库地址。但是随着 Jcenter 的停止运营，仍然需要迁移到 Maven 仓库。

对于发布到 Maven 仓库，Sonatype 官方也提供了基于 Gradle 的脚本配置的指导文档，同时 Android 官方也提供了基于 Maven Publish 插件发布的指导帮助文档。但是由于 Maven 仓库要求对于发布的资源必须进行签名，但是 Android 官方提供的配置文档缺失签名部分，所以会导致发布到 Maven 之后，并不能真正的发布成功。Sonatype 提供的基于的指导文档是基于 maven 插件的 uploadArchives 任务，而 maven 插件在 Gradle 7.0 中已经被废弃并且被删除。所以我们最终采用基于 maven-publish 插件的 publishing 任务来发布到 Maven 仓库。

下面详细介绍一下发布到共有 Maven 仓库的操作步骤。

2.1. 注册 Sonatype 账号和申请项目

2.1.1. 注册 Sonatype 账号

注册地址：issues.sonatype.org/secure/Sign…

2.1.2. 申请创建新项目

在注册完成账号之后，创建 Issue 申请项目。

申请地址：issues.sonatype.org/secure/Crea…

完成申请之后，会与官方的支持人员与你确认沟通，以便确认你是该域名的持有者。需要注意的是，现在针对 GitHub 用户的域名是以：io.github. 开头，不允许自定义。如果有独立的域名可以使用域名作为Group Id。

2.2. GPG 签名

对于发布到 Maven 的资源，需要有签名校验，比较普遍的签名有 GPG 和 PGP，这里使用 GPG 签名作为示例。

2.2.1. GPG 安装

GPG 可以使用安装命令行，也可以通过客户端工具安装。这里我使用 brew 命令进行安装。

➜ ~ brew install gpg

安装完成后，通过 gpg --version 查看是否安装成功。

➜ ~ gpg --version

gpg (GnuPG``/MacGPG2``) 2.2.10

libgcrypt 1.8.3

Copyright (C) 2018 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <https:``//gnu``.org``/licenses/gpl``.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Home: /Users/dengshiwei/``.gnupg

支持的算法：

公钥：RSA, ELG, DSA, ECDH, ECDSA, EDDSA

对称加密：IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256,

TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256

散列：SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224

压缩：不压缩, ZIP, ZLIB, BZIP2

2.2.2. 生成密钥

指令：gpg --gen-key

输入：gpg --gen-key 后，会提示我们输入真实姓名、电子邮箱地址用于标识我们这个用户，最后确认信息时会让我们填入标识该用户的密码信息（很重要，一定要记住）。

2.2.3. 查看密钥

指令：gpg --list-keys

➜ ~ gpg --list-keys

/Users/dengshiwei/``.gnupg``/pubring``.kbx

------------------------------------

pub dsa2048 2010-08-19 [SC] [已过期：2020-06-15]

85E38F69046B44C1EC9FB07B76D78F0500D026C4

uid [已过期] GPGTools Team <team@gpgtools.org>

pub rsa2048 2021-03-01 [SC] [有效至：2023-03-01]

C19CC95F56C5D3EF8ADA2222133C922134E5CD035

uid [ 绝对 ] dengshiwei <dengshiwei@sensorsdata.cn>

sub rsa2048 2021-03-01 [E] [有效至：2023-03-01]

这里可以看到我的公钥 ID = C19CC95F56C5D3EF8ADA2222133C922134E5CD035，仅仅有公钥是不够的，我们需要发布公钥到密钥服务器才能进行识别。

2.2.4. 发布公钥到服务器

指令：gpg --keyserver hkp://pool.sks-keyservers.net --send-keys 公钥 ID

➜ ~ gpg --keyserver hkp:``//pool``.sks-keyservers.net --send-keys C19CC95F56C5D3EF8ADA299933C922134E5CD035

gpg: 将密钥‘33C922134E5CD035’上传到 hkp:``//pool``.sks-keyservers.net

2.2.5. 查看密钥是否发布成功

指令：gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 公钥 ID

➜ ~ gpg --keyserver hkp:``//pool``.sks-keyservers.net --recv-keys C19CC95F56C5D3EF8ADA299933C922134E5CD035

gpg: 密钥 33C922134E5CD035：“dengshiwei <dengshiwei@sensorsdata.cn>”未改变

gpg: 合计被处理的数量：1

gpg: 未改变：1

这样就标志着发布成功了。

2.2.6. 密钥导出

gpg 中提供了导出公钥和私钥的签名方法。

• gpg -a -o public-file.key --export KeyId : 导出公钥到 public-file.key 文件中；


• gpg -a -o private-file.key --export-secret-keys KeyId : 导出私钥到 private-file.key 文件中。

其中：

• -a 为 --armor 的简写，表示密钥以 ASCII 的形式输出，默认以二进制的形式输出；


• -o 为 --output 的简写，指定写入的文件。

2.3. 发布脚本

2.3.1. 引入发布和签名插件

在需要发布的工程项目的 build.gradle 文件中引入 maven-public 和 signing 插件。

build.gradle

apply plugin: 'signing'

apply plugin: 'maven-publish'

2.3.2. 配置发布脚本

maven-public 插件通过 publishing 任务来发布资源。这里的配置主要包含：javadoc 文件、pop 文件、javadocJar 文件等。

task sourceJar(``type``: Jar) {

from android.sourceSets.main.java.srcDirs

classifier = 'sources'

}

task javadoc(``type``: Javadoc) {

dependsOn 'assembleRelease'

source = android.sourceSets.main.java.srcDirs +

'build/generated/not_namespaced_r_class_sources/release/generateReleaseRFile/out/com/sensorsdata/analytics/android/sdk/R.java'

classpath += project.files(android.getBootClasspath().``join``(File.pathSeparator))

}

javadoc {

options {

encoding "UTF-8"

charSet 'UTF-8'

}

}

task javadocJar(``type``: Jar, dependsOn: javadoc) {

classifier = 'javadoc'

from javadoc.destinationDir

}

publishing {

publications {

mavenAndroid(MavenPublication) {

groupId = 'com.sensorsdata.analytics.android'

artifactId = 'SensorsAnalyticsSDK'

version = version

artifact sourceJar

artifact javadocJar

artifact(``'build/outputs/aar/SensorsAnalyticsSDK.aar'``)

// 配置 pop 文件格式

pom {

packaging 'aar'

name = 'The official Android SDK for Sensors Analytics.'

description = 'The official Android SDK for Sensors Analytics.'

url = 'The official Android SDK for Sensors Analytics.'

licenses {

license {

name=``'The Apache Software License, Version 2.0'

url=``'[http://www.apache.org/licenses/LICENSE-2.0.txt'](http://www.apache.org/licenses/LICENSE-2.0.txt')

}

}

developers {

developer {

id = 'dengshiwei'

name = 'dengshiwei'

email = 'dengshiwei@sensorsdata.com'

}

}

scm {

connection = '[https://github.com/sensorsdata/sa-sdk-android'](https://github.com/sensorsdata/sa-sdk-android')

developerConnection = '[https://github.com/sensorsdata/sa-sdk-android.git'](https://github.com/sensorsdata/sa-sdk-android.git')

url = '[https://github.com/sensorsdata/sa-sdk-android'](https://github.com/sensorsdata/sa-sdk-android')

}

}

}

}

// 配置远程仓库

repositories {

// maven 对应的用户名和密码自定义存在 local``.properties 文件中

Properties properties = new Properties()

properties.load(project.rootProject.``file``(``'local.properties'``).newDataInputStream())

def mavenUser = properties.getProperty(``"maven.user"``)

def mavenPassword = properties.getProperty(``"maven.password"``)

maven {

// 发布地址，新申请的项目发布地址为：https:``//s01``.oss.sonatype.org``/service/local/staging/deploy/maven2/

url = '[https://oss.sonatype.org/service/local/staging/deploy/maven2/'](https://oss.sonatype.org/service/local/staging/deploy/maven2/')

credentials {

username mavenUser

password mavenPassword

}

}

}

}

// 对 mavenAndroid 发布内容进行签名

signing {

sign publishing.publications.mavenAndroid

}

发布脚本配置中有以下需要注意：

• groupId：需要配置自己申请的 groupId；


• artifactId：需要修改为自己项目的 artifactId；


• pom 中的文件描述需要修改为自己项目的描述；


• repositories 部分配置了远程仓库对应的用户名和密码，发布地址需要根据是否是新项目进行修改，旧项目域名是 oss.sonatype.org，新项目域名是：s01.oss.sonatype.org


• signing 签名部分需要配置对应的 gpg 密钥和账户信息

签名密钥配置

signing 签名要求在 gradle.properties 配置文件中配置密钥信息。

signing.keyId=YourKeyId

signing.password=YourPublicKeyPassword

signing.secretKeyRingFile=PathToYourKeyRingFile

• 
  

  signing.keyId：指刚才我们发布的公钥 ID，这里有一个坑就是这个 ID 的长度只能是 8 位，所以我们可以直接截取公钥 ID 的后 8 位即可；

  
  


• 
  

  signing.password：发布公钥对应的密码；

  
  


• 
  

  signing.secretKeyRingFile：指 gpg key 导出的私钥对应的问题，是绝对路径。可以通过指令 gpg --keyring secring.gpg --export-secret-keys > ~/.gnupg/secring.gpg 进行导出。

  
  

至此，我们完成发布相关的所有配置。

2.4. 版本发布

当我们配置好 publishing 后，我们可以通过指令：./gradlew publish 来执行发布任务。还可以通过 Android Studio 中的 Gradle 任务看板来执行 publish 任务。

2.5. 版本引用

第一步：在项目根目录的 build.gradle 文件中添加：

allprojects {

repositories {

...

mavenCentral()

}

}

第二步：在项目 Module 下的 build.gradle 文件中添加：

dependencies {

implementation 'com.github.sensorsdata:sa-sdk-android:5.1.3'

}

至此我们就完成了版本远程仓库的发布和引用。

3. Jcenter 同步到 Maven

对于新发布的版本，我们可以选择直接发布到 Maven，但是对于已经发布到 Jcenter 的仓库，我们需要借助 Jcenter 提供的 Maven Central 功能进行同步。

3.1. Jcenter 配置 GPG 密钥

在 Jcenter 首页点击个人头像后点击「Edit Profile」进入个人信息配置页面，然后选中「GPG Signing」选项，配置导出的公钥和私钥。

配置完成后点击「Update」按钮即可。

3.2. Jcenter 配置 Sonatype 账号

在个人信息配置页面点击「Accounts」选项，配置注册的 Sonatype 账号。

3.3. 同步仓库到 Maven

进入仓库主页，点击「Maven Central」选项卡切换到对应的页面，点击「Sync」同步至 Maven。

至此完成整个 Jecenter 到 Maven 仓库的同步。

4. 总结

本次 Jcenter 的停止维护对于 Android 开发者来说会造成很大的影响，同时在迁移配置脚本的过程中也遇到很多问题，这里就不一一列举了，遇到问题首先要做的就是要反复检查核对自己的配置。希望 Android 官方能尽快出一个快速高效的迁移方案。