有赞微商城POS机的模块化过程演进

2017-03-21 本文已影响231人 sylviaMo

背景

有赞微商城接入了三个厂家的 POS 机，分别是旺 POS、商米、拉卡拉，很久之前都是单独维护这三个 POS 机的代码分支，每次发版就需要把主线分支合并代码到相应的 POS 机的分支，这使得POS机的发版流程异常繁琐，而且很容易让 POS 机的版本内容跟微商城手机 App 的版本不一致。
除此之外，每个 POS 机的接入方式和使用方法都有很大的区别，使得对应的业务代码就很混乱。此时恰逢微商城项目要搞模块化，正好借机统一所有 POS 机的代码，让所有 POS 机的使用在业务中是有统一接口去调用，而且把所有代码都合并到主分支，统一 POS 机和手机 App 的发版。

合并代码

首先第一件事情是合并所有 POS 机分支的代码进入主分支，这个过程很艰苦，只能一点点抽取相关代码，然后放到主分支里。刚才在背景中已经提过正在搞模块化，那自然是要把相应的厂家 POS 机的 lib 包和定制的需求的代码放到一个 module 里的。在这里我创建了三个 module，分别 pos_iboxpay，pos_sunmi，pos_wei。参考下图，因为涉及具体业务，此处不公开代码。

pos.png

统一调用接口

POS机定制需求放到相应module里以后，那就是如何解决在业务中有统一的接口去调用POS机的功能的问题了。在业务中，需要使用POS机的打印和扫码功能，那么就对应创建了 POSPrinterBuilder，POSBase 和 ScannerBuilder，ScannerBase。其中POSPrinterBuilder 是在业务中使用的，POSBase 是让pos_iboxpay，pos_sunmi，pos_wei 这三个 module 里都创建的 POSPrinter 这个类去继承的。
备注：因为要统一接口调用，那么在每个 module 里创建的 POSPrinter.java 的路径是需要保持一致的。
下面请看代码：

public class POSPrinterBuilder {

    private static final String POS_PRINTER_CLASS_NAME = "com.qima.kdt.business.pos.POSPrinter";

    private Context mContext;
    private TradesItem mTradeItem;
    private POSPrintListener mPrintListener;
    private POSPrinterInitListener mPrintInitListener;
    private POSPrinterDestroyListener mPrintDestroyListener;

    public POSPrinterBuilder(Context context, POSPrinterInitListener listener) {
        mContext = context;
        mPrintInitListener = listener;
    }

    public POSPrinterBuilder setInitListener(POSPrinterInitListener listener){
        mPrintInitListener = listener;
        return this;
    };

    public POSPrinterBuilder destroy(POSPrinterDestroyListener listener){
        mPrintDestroyListener = listener;
        return this;
    };

    public POSPrinterBuilder setTradeItem(TradesItem tradeItem) {
        mTradeItem = tradeItem;
        return this;
    }

    public POSPrinterBuilder setPrintListener(POSPrintListener printListener) {
        mPrintListener = printListener;
        return this;
    }
    public POSBase build() {
        try {
            Constructor c = Class.forName(POS_PRINTER_CLASS_NAME).getConstructor(Context.class, POSPrinterInitListener.class);
            POSBase printer = (POSBase) c.newInstance(mContext, mPrintInitListener);
            if (mPrintInitListener != null) {
                printer.setInitListener(mPrintInitListener);
            }
            if (mPrintDestroyListener != null) {
                printer.destroy(mPrintDestroyListener);
            }
            if (mTradeItem == null){
                return printer;
            }
            printer.setPOSPrintListener(mPrintListener);
            printer.setTradesListItemEntity(mTradeItem);
            return printer;
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        }

        return new POSBase(mContext, mPrintInitListener) {
            @Override
            public void print() {

            }
        };
    }
}

public abstract class POSBase {

    protected POSPrinterInitListener mPrintInitListener;
    protected POSPrinterDestroyListener mPrintDestroyListener;
    protected TradesItem mTradeItem;
    protected POSPrintListener mPrintListener;
    protected Context mContext;

    public POSBase(final Context context, POSPrinterInitListener listener) {
        mContext = context;
        mPrintInitListener = listener;
    }

    public void setInitListener(POSPrinterInitListener listener){
        mPrintInitListener = listener;
    };

    public void destroy(POSPrinterDestroyListener listener){
        mPrintDestroyListener = listener;
    };

    public void setTradesListItemEntity(TradesItem tradeItem) {
        mTradeItem = tradeItem;
    }

    public void setPOSPrintListener(POSPrintListener printListener) {
        mPrintListener = printListener;
    }

    public Context getContext() {
        return mContext;
    }

    public abstract void print();
}

以 pos_sunmi 中的 POSPrinter 为例：

创建 POSPrinter.java，继承 POSBase.java

把具体实现内容写在 print() 函数

业务代码中只要创建 POSPrinterBuilder，调用 print() 函数即可

备注：加“@Keep”，是因为要通过反射方式获取POSPrinter，要避免打包时被混淆

@Keep
public class POSPrinter extends POSBase {

    public static final String FLAVOR = "sunmi";

    private V1Printer mV1Printer;
    private ICallback mICallback;

    public POSPrinter(Context context, POSPrinterInitListener listener) {
        super(context, listener);
        init();
    }

    private void init() {

    //此处是POS机初始化具体代码

    }

    @Override
    @WorkerThread
    public void print() {
        if (null != mPrintListener) {
            mPrintListener.onPrintStart();
        }
        new Thread(new Runnable() {
            @Override
            public void run() {
                printOrder();
            }
        }).start();
    }


    /**
     * 订单打印
     */
    private void printOrder() {

    //此处是具体业务实现代码

    }

}

new POSPrinterBuilder(TestActivity.this, null)
.setTradeItem(mItemEntity)
.setPrintListener(newPOSPrintListenerImp(TestActivity.this))
.build()
.print();

多个FLAVOR问题的解决

由于已经把 POS 机的业务代码和手机App的代码合并成一套，首先想到的是用 BuildConfig.FLAVOR 字段去区分业务逻辑，之前写过模块化项目中如何做，参考链接 http://www.jianshu.com/p/e86a3b71a88a/ ，但是这个使用方法如果很多业务模块都要使用，会让 app 中的 build.gradle 和每个 module 下的 build.gradle 文件配置比较麻烦。为此，这里使用反射去解决这个问题。
方案如下：

在 app 中的 build.gradle 文件中配置 flavor

productFlavors {

  iboxpay {
      buildConfigField "boolean", "POS", "true"
      buildConfigField "String", "DEVICE_TYPE", "\"android-iboxpay\""
  }

  sunmi {
      buildConfigField "boolean", "POS", "true"
      buildConfigField "String", "DEVICE_TYPE", "\"android-sunmi\""
      applicationId "${sunmiId}"
  }

  weipos {
      buildConfigField "boolean", "POS", "true"
      buildConfigField "String", "DEVICE_TYPE", "\"android-weipos\""
  }
}

dependencies {
  sunmiCompile project(':pos_sunmi')
  iboxpayCompile project(':pos_iboxpay')
  weiposCompile project(':pos_wei')
}

2.在每个对应的 POS 机的 module 的 POSPrinter 类里定义一个名字为 FLAVOR 的 public 的 static 的string，例如 pos_sunmi 这个 module 里是
public static final String FLAVOR = "sunmi";

3.在 application create 的时候，通过反射方式去读取对应编译的 POS 机 module 的 POSPrinter 的 static 类型的字符串 "FLAVOR"

public static String FLAVOR = "full";
public static boolean POS = false;
public static void searchPosPrinter(){
    try {
        Class clazz =  Class.forName(POS_PRINTER_CLASS_NAME);
        Field flavorField  = clazz.getField("FLAVOR");
        FLAVOR = (String)flavorField.get(null);
        POS = true;
    } catch (NoSuchFieldException e) {
        e.printStackTrace();
    } catch (ClassNotFoundException e) {
        POS = false;
        e.printStackTrace();
    } catch (IllegalAccessException e) {
        POS = false;
        e.printStackTrace();
    }
}

4.在业务代码中直接使用 FLAVOR 和 POS 的值，不使用 BuildConfig 的值
5.可以开始编译一个 POS 机的 apk 了,例如 ./gradlew clean assembleSunmiRelease,则只会加载 pos_sunmi 这个 module。

总结

同一个项目，代码尽量不要散落在不同分支，一定要保证主分支的代码的完整性
当具体业务具有很多相似操作的时候，尽量封装一下实现面向接口编程，这会减轻以后业务拓展的工作量
合理使用反射，不要谈“反射”色变

有赞微商城POS机的模块化过程演进

背景

合并代码

统一调用接口

多个FLAVOR问题的解决

总结

猜你喜欢

热点阅读