如何整合两个大的Android应用工程？（一）

app开发常常计划没有变化快，折腾是常有的事。譬如，有时候业务需要将两个独立发展的工程整合成一个。android开发发展了这么多年，早年主要靠android标准库，现在慢慢发展到各种各样第三方库极大丰富。早年app工程比较简单，java代码、jni代码、res、manifest这四部分也就差不多了；现在各种库被引进到app工程中，有jar、有aar、有so、有源代码工程；再加上android
studio取代了eclipse之后，功能更强大的同时使用的复杂度也有增加。所以，集成代码的时候，当两个工程都很大，可能工作量和难度要比想象中更大。这就是工程，目标和流程在想象和规划的时候都很顺畅，但实施起来却常常遇到各种坑。这里聊聊我觉得比较好的整合方式，以及中间可能遇到的一些坑。（假设将project A整合到project B中。）

先说一下，eclipse/android studio/android编译环境都支持将一个工程编译成jar；android studio更提供了aar，可以将res也打包进去，一定程度上解决以jar包集成无法带res的问题（但aar只是简单地将res打包进入到aar，如果资源id冲突，还是会以定位到主工程的资源，如果想资源上有所拆分隔离，就要考虑插件化编程了）。本文并非针对这种方式，而是代码级的整合，无论是runtime还是buildtime，都彻底二合为一个工程。库的方式最大的问题在于，B调用A没问题，但反过来A调用B的逻辑就不方便了。

整合步骤

第一步：将A中的java代码和jni代码移植到B中，注意package结构上的隔离。大的工程往往庞杂无头绪，感觉无处下手。那么从以编译通过为第一个目标，以build error为线索驱动，是一个很合适的方式，这样一个一个（有时候是几百个几百个）来fix build error，也更有成就感一些。从这一步完成开始，简单粗暴开始编译，看build error“走着瞧”。

第二步：移植库（jar、aar、so、编译依赖工程等）。第一步完成之后，开始编译，第一批出现的build error应该是外部依赖库，这样一条一条error对照着A中的gradle.build，将库移植到B。就此也可以整理、学习。

第三步：移植res（values、layout、drawable等）。第二步完成之后，res资源找不到的build error将出现。这时候需要细致地将A中所有的res集成过来。这时主要的工作量在于解决id冲突，但往往可能没有想象中冲突那么多，虽然像R.id.login_button这类的id命名是所有人的最爱，但每个人的命名习惯千差万别，碰上的几率可能并不大，集中精力rename冲突的一小撮就好。这一步之后，将迎来第一个里程碑——build
success。

第四步：移植manifest.xml。主要是permission和基础设施（Activity、Service、Provider、Receiver等）。

第五步：移植代码混淆（Proguard或者Dexguard）配置。各种-keep、-dontwarn。。。。。。

第六步：run调试。经过上述5步，新的大工程B（A）应该可以运行了，接下来就是冒烟测试，跑跑主流程，见招拆招，解决crash、功能问题。