浅谈android嵌入第三方sdk的二次封装原则

        由于android的开源特性，很多功能（例如网络请求，json解析等）可以在网上找到大把的工具，另外还有很多第三方sdk（例如，推送）已经大行其道。这些第三方框架以其调用方便，性能稳定等特性大受android程序猴子欢迎。虽然这些sdk内部封装的很好，调用也极其方便，所以很多人都不想在此基础上进行二次开发，以方便自己使用。这样造成的问题就是，一旦更换sdk，结果将是灾难性的大面积修改甚至重构。

       猴子不才，看到同事对那些第三方sdk的封装讲大大降低这一风险，于是偷偷总结一下，方便以后查看。现在以联网请求为例来分析这一封装方式的优越性。

       哥们采取的方法是，按照功能分层，最底层只负责将sdk中提供的功能进行封装调用：

public static RequestHandle post(String url, Map<String, Object> map,
                                 Callback callback) {

    StringEntity entity = MapParamsConverter.map2Entity(map);

    HttpRequestCallBack requestCallBack = new HttpRequestCallBack(callback);
    RequestHandle handler = mAsyncHttpClient.post(MyApplication.appContext, url, entity, "application/json", requestCallBack);
    return handler;
} 

       其中 mAsyncHttpClient是第三方的网络请求框架的实际工作层。

       上一层则是封装基本的公共参数，例如deviceid，token等，这部分代码涉及公司机密，也没什么技术性可言，就不粘贴了，这一层封装的用处是，将公共数据抽取，提高代码的重用性，毕竟代码是该被重用而飞被复制。

       再上一层则是，必要参数的封装，例如在登录接口，需要传递用户名，密码什么的。也没什么技术性可言。

      这样经过三层封装，好处就是，当底层的网络请求框架需要被换掉时，只需改动

RequestHandle handler = 你的请求框架的.post(MyApplication.appContext, url, entity, "application/json", requestCallBack);

      完全不需要管哪里调用网络请求，也不需要知道他究竟传给了什么参数，变化都被隔离在最底层的基本方法上。