Android Shape工具 Duck

因为本身在开发中遇到的问题，全部弄了一个 Android Shape 的工具 Duck ，能帮助开发者直接在 xml 的任意控件上实现 Shape 效果，无需建立额外的xml文件，而且没有任何侵入性。

废话很少说，直接看效果：

项目地址：Duck

初衷

这个库的由来，是由于公司一个维护了 4 年的项目。

经历 4 年的项目，产品设计不知道改了多少版，期间产生并堆砌大量shape.xml 文件，这些文件由于索引的问题每每还没法清理。

同时，同一个 shape.xml 文件，由于设计存在不规范的问题，在不一样页面改动了一点颜色、倒角或线宽等，就没法复用，必须据此建立新的文件。

最后，大量的文件堆积，开发人员开发时，花时间找 shape.xml ，还不如本身建立新的方便，这样恶性循环， 只能 GG。

我想说，Android 设计 Shape 的初衷是好的: 一个 APP，统一的设计规范，就应该复用 Shape 。

但这种状况对于国内的生态来讲并不适用。

首先，相同屏幕尺寸，中文承载信息的能力远大于英文，这就致使国外大部分 APP 界面设计简洁清爽，国内就显得很是复杂，同时国内互联网更新速度很快，界面是生命周期短，人员流动，很难作到界面统一。

全部，Android 的 Shape 并不适合国内生态。

开发时，超级羡慕对面 IOS 开发们能够直接在控件上进行花式倒角、加线框等骚操做，想不通为啥 Android 不能在这一点上借鉴IOS。哎，Android 与 IOS 的宿命之争，说多了都是泪。

基于上面种种缘由，因此出现了想开发这个库。

这个库只实现最经常使用的 Shape 功能，selector 及 layout-list 并未实现，由于有两点考虑：

1. shape 使用场景更多，而且更频繁，其余两种只在少数特定场景中使用。
2. selector 及 layout-list 须要更多精细的代码控制，如所有挤在 xml 中一个控件上，会很是臃肿，难以维护。

原理

在考虑用什么技术实现时，考虑这几点：

1. 任何控件都能有效，即便是自定义控件。
2. 不能有侵入性，即便更换或废弃本库，也能保证稳定性。

最开始，第一个想到的是 LayoutInflater.Factory ，xml 控件解析成 View时，必须通过它，也是换肤的解决方案，但这样得一个个替换成本身的，很是麻烦。

有没有更好的解决方案呢？

得益于 AspectJ 的 AOP（面向切面编程）能力，咱们能够在编译时期，直接在 View 及其子类的构造方法中插入相关代码，解析xml 中自定义的属性，最后设置到控件上。

@Pointcut("execution(android.view.View+.new(..))")
    public void callViewConstructor() {
    }

    @After("callViewConstructor()")
    public void inject(JoinPoint joinPoint) throws Throwable {

        Signature signature = joinPoint.getSignature();
        Object target = joinPoint.getTarget();
        Object[] args = joinPoint.getArgs();

        int length = args.length;
        if (!(target instanceof View) || length < 2 || target.hashCode() == lastHash || !(args[0] instanceof Context) || !(args[1] instanceof AttributeSet)) {
            return;
        }
        lastHash = target.hashCode();

        Context context = (Context) args[0];
        AttributeSet attrs = (AttributeSet) args[1];

        int count = attrs.getAttributeCount();

        for (int i = 0; i < count; i++) {
            Log.i(TAG, attrs.getAttributeName(i) + " = " + attrs.getAttributeValue(i));
        }

        Log.i(TAG, "inject =====> " + signature.toString());
        DuckFactor.getFactor().inject((View) target, context, attrs);
    }
复制代码

AOP 相关内容，能够查看AOP 系列 包含：

1.OOP 与 AOP

2.Java 注解处理器

3.Aspect

4.Android中使用 Javassist

因为 AspectJ 能遍历项目中全部依赖包，所以，不管是 support 库，仍是第三方库都能获得很好支持。

可是 AOP 也存在必定问题，咱们的 apk 中是不会存在系统原生 Android SDK 的，例如 TextView 这个系统控件，在编译时是不会打包到 apk 中，所以，AOP 技术对这种原生控件无能为力。

幸亏，咱们绝大部分项目为了兼容性，通常都会直接依赖官方的兼容库，即 support 相关的库。

在 support· 库中，会将一些原生控件，直接替换成 support 相关控件。相关代码以下：

android/support/v7/app/AppCompatViewInflater switch (name) {
            case "TextView":
                view = createTextView(context, attrs);
                verifyNotNull(view, name);
                break;
            case "ImageView":
                view = createImageView(context, attrs);
                verifyNotNull(view, name);
                break;
            case "Button":
                view = createButton(context, attrs);
                verifyNotNull(view, name);
                break;
            case "EditText":
                view = createEditText(context, attrs);
                verifyNotNull(view, name);
                break;
   			......
        }
复制代码

而对于这些控件，咱们的 AOP 都可以生效了。

在 support 库中，没有替换掉 ViewGroup 的几个经常使用子类，如LinearLayout 、RelativeLayout、FrameLayout等，

因此，咱们咱们仿照 support 的替换方式，直接在 LayoutInflater.Factory.onCreateView 方法中注入相应的替换代码。

@Pointcut("execution(* *..LayoutInflater.Factory+.onCreateView(..))")
    public void callLayoutInflater() {
    }

	@Around("callLayoutInflater()")
    public Object replaceView(ProceedingJoinPoint joinPoint) throws Throwable {

		....
            
        switch (name) {
            case "RelativeLayout":
                return new DuckRelativeLayout(context, attrs);
            case "LinearLayout":
                return new DuckLinearLayout(context, attrs);
            case "FrameLayout":
                return new DuckFrameLayout(context, attrs);
            case "TableLayout":
                return new DuckTableLayout(context, attrs);
            case "ScrollView":
                return new DuckScrollView(context, attrs);
            default:
                break;
        }

        return result;
    }

复制代码

这个库的代码其实不多，我这里也只是实现了 Shape 这一个功能。

private static Injector mInjector;

    public static void setFactor(Injector injector) {
        mInjector = injector;
    }

    public static Injector getFactor() {
        if (mInjector == null) {
            mInjector = new ShapeInjector();
        }
        return mInjector;
    }
复制代码

这里保留的 Duck 的扩展性，若是以为不够，能够自行实现功能更强大的 Injector。

AOP 的能力远不止如此，还有不少事情能够作，建议你们能够发挥想象，进行更多的扩展。

优化

核心原理已经搞定，还有两点须要优化：

1. 在 xml 中使用时，没有提示不方便，这一点能够经过Live Template 来解决。

   

2. 没法预览，AOP 在编译时工做，全部没法实时预览，看到别人的库是替换成自定义 View 来查看效果，感受这种实现方式不够完美，全部就放弃了，后续想着可否经过 AS 插件实现预览。

项目地址：Duck

小插曲

这个库的出现挺坎坷的。

在 18 年 8 月份左右，就开始写了这个库，当时核心功能的实现，xml 的代码提示问题都已经想好了解决方案。

但写到一半出现了功能相同的库，

BackgroundLibrary

仔细看了项目代码，对比发现实现原理不同，xml 提示解决方案相同，预览问题经过替换解决。

额~

好吧！就瞬间没写下去的动力了，再加上公司赶工期，代码就扔在那没动了。

直到最近空闲了，忽然想着无论这样，仍是弄完吧，搞个烂尾实在是很差。