标签：android java 条件编译
在代码的开发过程中，不管是C/C++也好，Java也罢，都要面对在平台移植的问题， 所以不可避免的要考虑条件编译的问题。 在C/C++代码的开发中，条件编译的实现很容易实现，可以分成二种：一种是在单个代码文件中通过 #ifdef ... #endif 或者 #if ... #endif 的方式选择性编译文件中的代码，另一种是在Makefile中通过宏判断来选择性编译某个文件。在Java代码的开发中，实现条件编译则没有直接对应的方法，但是仍然可以采用变通的方法来实现条件编译。
对于单个文件内的的代码的条件编译，可以利用Java代码的优化功能来实现：
private final boolean DEBUG = false;
if (DEBUG) {
Log.i("TEST","hello,world");
}
这里，因为DEBUG是一个final变量，相当于C/C++里的CONST变量，
所以Java编译器在编译的时候会对代码进行优化，当DEBUG为false时，就不会把if里面的代码编译进去。
但是这种方法有个缺陷，就是不能实现对函数的条件编译，这个时候，Java的开发人员可能就要羡慕C#的开发人员了，因为在C#里可以像C/C++一样实现条件编译的功能。
下面重点来讲下Android的Java代码的开发中如何实现选择性编译某些Java代码文件。
在Android.mk中，有一行脚本大家应该非常熟悉：
LOCAL_SRC_FILES := $(call all-java-files-under, src)
这条代码的意思是从src目录中查找所有的java文件，并保存到LOCAL_SRC_FILES
所以我们可以选择性的把平台相关的代码加到LOCAL_SRC_FILES中。
方法如下：
建立如下的目录结构：
│ Android.mk
│
└─platform
│ Android.mk
│
├─bb
│ │ Android.mk
│ │
│ └─src
└─aa
│ Android.mk
│
└─src
platform/Android.mk中的内容如下：
include $(call all-makefiles-under, $(LOCAL_PATH)/platform)
这里的LOCAL_PATH为在根目录的Android.mk中定义的LOCAL_PATH
执行时会包含platform子目录下的所有Android.mk
在platform目录下放的即为平台相关的java代码
platform/aa目录下的Android.mk内容如下：
ifeq ($(TARGET_PRODUCT),aa)
PLATFORM_DIR := aa
Endif
platform/bb目录下的Android.mk内容如下：
ifeq ($(TARGET_PRODUCT),bb)
PLATFORM_DIR := bb
endif
platform下的平台相关子目录Android.mk文件会判断平台是否符合要求，如果符合要求就会把子目录赋值给PLATFORM_DIR变量。
来看根目录下的Android.mk的内容如下：
LOCAL_PATH:= $(call my-dir) include $(CLEAR_VARS)
...
LOCAL_SRC_FILES := $(call all-java-files-under, src)
include $(LOCAL_PATH)/platform/Android.mk
LOCAL_SRC_FILES += $(call all-java-files-under, platform/$(MTA_PLATFORM_DIR)/src)
...
标红的第一行代码把platform/Android.mk包含进来，执行的脚本会根据平台定义PLATFORM_DIR变量。第二行代码即为把平台相关的src目录下的所有java代码包含进来.
这样，就实现了编译不同文件的java代码了。
实现条件编译还有一种方法，就是把平台相关的代码编译成static Java库，
方法是用
include $(BUILD_STATIC_JAVA_LIBRARY)代替include $(BUILD_JAVA_LIBRARY)
include $(BUILD_JAVA_LIBRARY)会直接编译出jar包。而include $(BUILD_STATIC_JAVA_LIBRARY)虽然也会生成jar包，
但是在被其它apk的编译时，如果通过LOCAL_STATIC_JAVA_LIBRARIES把这个库包含进来，这样也会把代码静态编译进apk，而不会依赖于额外的jar包。
但是这种方法明显更复杂，有兴趣可以试下。
Android平台Java代码的条件编译问题
标签：android java 条件编译
原文地址：http://blog.csdn.net/i2cbus/article/details/42425909
