那些年Shop的一些总结

那些年Shop的一些总结

前一阵子，做了一个商业级的商城项目，耗时总共也就一个月多点，后面支付拖了很久，记录一些坑。

1.对于RX系列的一些的看法：不使用

体现在于联网的，okhttp，因为RX系列，整个项目就要使用multidex进行分包，RXjava2 快1w+方法，直接舍弃，就是用okhttp+okhttpUtils，不用retrofit，同时自己封装okhttp，根据后台一起协议的json结构，进行二次封装

2.选择开源库：

优先多次使用过的，然后fork下来，改源码，记得提交，这样方便后面维护，同时引入开源库的时候，记得加混淆规则。加固不是万能的，前一段时间360加固被发现加固同时加入广告，360果然流氓。

3.欢迎界面，引导图优化

开发中引入了多个大厂的SDK，比如腾讯的bugly，百度的地图，微信支付，分享，支付宝支付，每个开源库，都按需加载，不要全部放在application中，这样会导致启动白屏时间过长，同时欢迎界面或者引导图，结束后，清空图片加载的内存，系统只有在内存紧张的时候才会GC，在三星机器，有时候内存紧张清理不会及时会导致白屏

代码参考：

    mImg.setBackgroundResource(0);
    System.gc();
    System.runFinalization();

4.定位的选择，对于apk的体积的影响

优先选择，高德地图，同时SO只引入arm64-v8a，armeabi。可以考虑地图展示由H5来做，这样能减少5M+的体积，同时对于定位，一大段代码，全部封装到一个单例工具类，定位完以后得到结果，直接关闭定位。

5.crash的控制

首先在获取网络数据，那里，try catch住，如果出现crash直接展示服务器错误，这样在可控的情况能保证程序不挂，能保证用户能继续使用的情况下后台修改，前端不用重新上包。 同时推荐能够有能力自己写一个bug收集系统，这样能够很好的定位到bug的原因。

6.打包的key要指定文件

主要指定好，即可避免第三方SDK因为sha1，或者其他什么失败。

//keytool -list -keystore debug.keystore
signingConfigs {
    release {
        keyAlias 'xxxxx'
        keyPassword 'xxxxx'
        storeFile file('../key/weishangcheng.jks')
        storePassword 'kaisa008'
    }
    debug {
        keyAlias 'androiddebugkey'
        keyPassword 'android'
        storeFile file('../key/debug.keystore')
        storePassword 'android'
    }
    buildTypes {
        debug {
            signingConfig signingConfigs.debug
        }
        release {
            signingConfig signingConfigs.release
        }
    }
}

7.代码的架构

MVP好用么，项目中以前实践过几个项目，代码确实好维护，但是用的很心累，如果快速开发中，我还是喜欢MVC+Eventbus。

前一阵子，看到有个阿里大神，貌似想法跟我一样的 哈哈

首先，我以前重构代码得时候，发现每次都是因为联网逻辑而把activity代码写的越来越多，那是不是把联网的代码抽出去即可了呢，事实上是的。

也就是在原来基础上加一个model层，进行联网，处理数据，然后回调回来处理UI，即可。轻量，快速，好用。

当然我说的是快速开发，毕竟开发时间不多，时间要给业务，当然你能解决MVP的心累也是可以用的，比如使用AS的模板化，直接帮你建立MVP三个文件也可以的。

8.对于金钱的计算

谨慎，谨慎，在谨慎！我建议关于金钱的字段，后台就String，然后前台使用BigDecimal进行计算，具体的可以看

android不在坑三：Float丢失精度

9.后台与前台约定好的呢

约定好的json结构就不要变了，你一遍我联网框架就要变了，还再次封装一次，比如约定好的content内容呢，你不能直接返回一个成功给我呢，虽然我知道只有成功就可以了。

还有一点，移动端的开发人员，不是只敲代码。你得跟后台去过一次业务流程，从中告诉后台你需要什么内容，数据怎么给你方便，那些工作必须放在后台做，那些工作放前台合理点，你是程序员，不是码农呐

10.如果时间不够的话，一些展示性的内容交给H5

快速开发，如果移动端有人会H5，是一个很幸福的事情，因为你做一个页面，IOS，android，都可以使用，而且出问题了，不用重新上包。同时可以考虑把一些业务放到H5去，这也是解耦。

11.一些共用的业务处理，别影响其他业务

这里我就说一下，一些常规的联网业务处理，加载失败，加载成功，加载中，空数据，就是用一个dialog展示结果，千万不要影响一些列表里的业务，我以前很多就因为要在列表中展示这些东西，业务写的差点维护不了了。

结语：

有问题可以发邮件到[email protected]，互相学习，互相交流