iOS可配置系统

## 介绍

可配置系统是一套动态更新App的系统，允许我们在不发版的情况下，更新App的内容和外观。

为什么会有这样一个系统？2015年初，某产品发现x宝的底部栏时不时的更换皮肤，贴合不同的节日和主题，非常漂亮，遂萌生了我们也要搞一套的想法。只是简单的支持更换UI，一年用个两三次，有我们开发自己来配。于是第一版系统诞生了，没有后台，由我们自己写JSON字符串，仅支持动态更新底部栏的图片。

当然，需求的野心肯定是不会止步的，渐渐的，个人中心要配置，登录注册也要配置，首页、账户管理....一个个的需求接踵而来，形成了我们如今看到的可配置系统。

## 实现

1.  可配置系统在技术上涉及到后台、API、APP

*   后台：管理可配置JSON文件

*   API：根据请求接口的客户端、App版本和站点信息，返回相应的可配置文件Url给App

*   APP：接收可配置文件并缓存，实现相关业务逻辑

1.  在业务逻辑上涉及到客户端、App版本、站点三个维度

*   客户端：iOS、Android、Wap

*   App版本：支持对任意一个或多个版本做配置

*   站点：支持对大站做配置

1.  为了优化流量使用，每个可配置化文件都有一个版本号。在请求最新可配置化文件时，会把这个版本号传给API，API判断如果该版本文件已经为最新，则App端无需重复下载

## 怎样新增一个可配置条目

在iOS端，为了避免写两套代码，所有可配置的业务模块，都会统一读取配置来实现业务逻辑。那么这样就会有个问题，在用户初次使用，并没有联网的情况下，本地没有可配置文件的缓存，也无法从服务器拿到配置文件，这时候如何实现？针对这样的使用场景，iOS端项目内部有一份默认可配置文件，当初次使用没有本地缓存也没有服务器文件时，会读取这份默认文件来实现业务逻辑。所以每次新增/更新一个可配置模块，需要做以下几件事情：

1.  在本地BLDefaultConfigData增加/更新可配置模块

2.  找测试在后台更新相应的可配置文件

3.  开发相应功能并测试

## 未来

*   加强安全性。整个可配置文件会透露App的很多信息，所以在传输和存储过程中要确保安全。在传输时，通过https来加密；在本地存储时，应该加密后再存储，并把现在一些显而易见的文件名和字段替换掉

*   目前配置模块不成体系，往往是加一个功能加一个字段，难以维护和管理。将来需要根据规范来命名，并且制定纵向深度，以此给所有业务模块分区分块

*   目前可配置功能，App内部各个业务单位都各自取用，代码耦合严重，将来考虑将这一部分层级化，把原来混在一个业务逻辑里面的配置A和配置B，拆分成该业务下的子业务A和子业务B

*   目前写配置文件比较痛苦，很难做版本管理，将来要做成一个UI系统，做成类似配广告位的形式，把自动生成App默认可配置文件做成工具