Android从配置文件谈后期开发可拓展性

1.为什么使用配置文件

项目中经常用到配置文件，android中也包含很多配置文件，比如local.properties、gradle.properties等项目自带的配置文件，也有开发自己维护的配置文件，比如properties.properties.

配置文件的格式一般是这样的：（还有以json、xml、ini格式的配置文件，不在本文讨论范围）

baseurl=www.baidu.com
host=127.0.0.1
port=8080

通常以键值对的方式存在，就像ios中的NSDictionary一样，以key-value形式存在的存储方式，通常通过key获取value进行数据读取。

在软件系统配置文件更是随处可见，使用配置文件到底有什么好处呢

2.配置文件的好处

项目开发中，不管是需求也好，架构也罢，变是肯定的，没有哪一个项目从头做到尾，一点不变。

比如说：

• 更换服务器，地址变了，端口变了
• 数据库账号密码变了
• 地图引擎开始用arcgis，后来用osmdroid了（配置文件只是其中的一小步）
• …………

变数太多，我们能做的就是将后期工作量降到最低，而且项目后期的可拓展性、可移植性更高，当然前期开发工作量会增加。用一句话概括，以不变应万变。

举个简单的例子：

web项目上线后，服务器地址变了，对应方式：

①地址写在配置文件中：去项目配置文件修改服务器地址，类似于上面例子的文件。清晰，一目了然

②地址写在类里：先去代码里找到写服务器的地方，然后修改代码，在然后重新编译发布

两种方式的效率和工作量很明显，配置文件的确让维护更加方便。当然这种情况在android中并不现实，对于也只是对应接口的改变。但在实际开发中，配置文件的使用也很大。

通过简单的例子我们可以总结，使用配置文件的特点及好处：

• 提高可维护性
• 减少维护工作量
• 提高效率
• 可拓展性（下面会讲）
• 保存设置（比如window的.ini文件）
• 修改后重启即可
• ……

3.配置文件在android的使用

个人总结有两种方式：

3.1 使用android资源文件

android提高的strings.xml来统一管理andoird中出现的字符串，我们可以借用一下。类似于下面

<!-- 地图引擎全类名 -->
<string name="map_engine">kmap.KMapWrapper</string>

获取当然也很简单

String clazz=context.getResources().getString(R.string.map_engine);
//后续...

当我们需要修改的时候可以直接在strings.xml中修改，当然也可以新建一个.xml资源文件，当成你的配置文件，获取方式相同。

3.2 新建文件的方式

我们自己的资源文件一般都放在assets文件夹中（声音视频一半放在raw），目录下但在android studio中assets文件夹默认是不自动生成的，而标准的android目录结构一般为：

-src/
  -androidTest/
  -main/
    -AndroidManifest.xml
    -res/
    -assets/
    -aidl/
    -rs/
    -jni/
    ... 

在main下直接新建assets文件夹，新建文件properties.properties，输入如下内容：

url=www.baidu.com

注：key——value都是字符形式，以=隔开

读取配置文件的工具类

public class ReadPropertyUtil {

public static String getProperty(Context ctx, String keyName) throws IOException {
    Properties pro = new Properties();

    InputStream in = ctx.getResources().getAssets().open("property.property");
    pro.load(in);
    return pro.getProperty(keyName, "没有获取到资源文件的内容");

}

}

实际调用

String url = null;
try {
    url = ReadPropertyUtil.getProperty(this, "url");
} catch (IOException e) {
    e.printStackTrace();
}

Toast.makeText(this, url, Toast.LENGTH_SHORT).show();

到此，配置文件的基本使用已经介绍的差不多了

4.配置文件+反射谈可拓展性

（会有单独的一篇文章介绍地图引擎拓展，所以下面只是简单介绍）

实际项目中的例子，公司项目本来用的google的地图，但是因为收费，自定义等方面的问题要更换称自由度更高的Osmdriod地图，因为本来项目未做抽取，所以改起来超级麻烦，几乎用到地图的每一个地方都需要重新修改，工作量不是一般的巨大。

总有解决的办法，一次受累，终生舒坦，开始了抽取之路。

定义自己的地图接口IMap，接口中的方法根据实际项目而定，比如画点线面等一些基础的操作，还有一些特殊定制的地图操作。

然后在实际调用中不能出现第三方的api，只能调用自己写的IMap中的方法，意思就是调用依赖接口。所以整体流程不会出现任何有关第三方api的东西。

然后开始写实现，比如说刚开始用的google地图引擎，我们定义一个GoogleWrapper实现IMap接口,实现对应方法，在构造方法中持有一个google的Mapview对象，类似于代理模式的方式，实现接口中方法。

实现类写好了，如何实例化呢，通过反射（为什么通过反射，直接new不行吗？）

//clazz为配置文件中获取的地图引擎的全类名
Class cls = Class.forName(clazz);
Class[] paramTypes = { Context.class };// 参数
Object[] params = { ctx }; // 方法传入的参数
Constructor con = cls.getConstructor(paramTypes); // 根据参数调用构造器
IMap map = (IMap) con.newInstance(params); // 实例化对象

通过上面的方式进行实例化获得一个IMap对象，其实就是配置文件中的地图引擎的全类名。至此，基本上结束了，可能你还看不出这样到底有什么好处？那么问题来了，现在google地图国内被墙了，突然不能用了，你不能告诉用户说你开个代理，一个月才十几块钱吧，只能换地图引擎，那么接下来换地图引擎的步骤是什么？

1. 第一步：定义OsmWrapper继承IMap并实现相应的方法，用Osmdroid的Api
2. 第二部，修改配置文件中的全类名
3. 看电影
4. 听音乐
5. 唱歌
6. 下班

现在好处可以一目了然了吧，可以让你拿出更多的时间来泡妞，打游戏，睡觉……当然如果你想提升一下自己的能力，那就用省下来的时间学习吧。

生命不止，学习不停！