如何整合两个大的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、功能问题。

你可能感兴趣的:(如何整合两个大的Android应用工程?(一))