随着整个项目越来越大，整个项目无法打包已经迫在眉睫，当时为了临时快速解决此问题，我将一些jar包删去，但是这也不是长久之计，因为有些jar包互相之间引用如果删除某一个整个工程不会报错，但是运行的时候就会崩掉，为了避免自己给自己挖坑就得想一个最终解决方案，然后花了一两天时间去研究方法超出的问题了，解决方案有两大种，     
        第一种：将大工程分成若干个小工程由一个主工程采用反射机制去动态加载，说白点就是在一个Activity上去操作上面的View对象，对象的加载采用反射的机制去加载，由于ZT项目每个模块之间耦合太强了采用这样的方案开发起来还是后面还是会有很多问题，如果像支付宝和携程一样,每个模块功能独立性很强的话采用这个方案自然要比下面好，因为每个功能为单位，分成多个小组，维护起来和团队管理更加方便，每次运行测试会更快，某个功能块出了问题可以动态升级不需要重新安装等等。具体的实现方案我就不赘述了，因为这篇博客已经写得够详细了，我自己已经按照博客里面实现过了，可以使用。        第二种：采用谷歌提供的插件对dex进行拆分，只需要在gradle里进行配置即可，当方法超出65k时自动拆分，其实还有一种方案和第二种方案差不多，基于Ant进行拆分，跟上面的方案比起来这个的优点在于可以指定第三方jar进行拆分，可以灵活配置。这种方案也有人写的足够好了我就不累赘的说一遍了，本人已经按照此篇博客试过一遍。
      
      由于项目周期比较赶几乎不给你歇息的时间，我考虑到几点因数，因数1，周期短要分离项目几乎让所有的兄弟们加班加点的做。因数2，虽然安卓人不多但是也有小9人，要想所有人都按照此框架去做，迁移速度也会变得很慢。因数3.由于业务之间的耦合性太强了，如果采用此框架，后面如果某一个分支跳转逻辑有变动，其他项目组的人都得跟着修改因此成本也是很高的。因数4，虽然有小9人但是人员但是还不足以采用此框架，因为我们现在是9个人并发去做三个版本，一个支付大改造，一个是财友功能大改造，一个是保证现有产品bug修复和产品迭代，每个版本在SVN上一个分支，每个分支相互独立需要3个人去处理，然后bug修复之后需要合到支付和财友上面，如果现在再拆分再细分后面人员根本就不够，加班加死了也搞不完，因为此综合上面四个因数我决定不用此框架，采用第二种谷歌自带的插件去解决此问题，只需要再build,gradle配置一下即可，采用这个方案唯一不便的就是项目组所有人都采用android studio进行开发，IDE全部由原来的eclipse转到android studio，由于整个项目组水平参差不齐，我担心有的人一天都浪费在安装环境和熟悉环境上面我给了一天到两天的缓冲期，也就是当天仍然采用eclipse开发项目，然后随便把android studio安装好，我把svn上所有以前eclipse项目配置成android studio可以直接导入的方式，这样子既不会很影响开发进度又有一个缓冲期。