二进制数据保存参数的方案的确存在速度的优势， 但同时也存在着以下几个不是避免的问题。1 对现有数据进行扩展极为不便。例如 在设计时， 我们理所当然的想到，16个字符完全足够能够显示一个用户名，假设，客户提一个特别变态的需求，需要输入17个字符.怎么办?动之以情，晓之以理，劝劝客户别提这么变态的需求。可人客户不听，怎么办?只能重新定义结构体。这下更好了， 新的参数结构体与早先的软件不兼容。怎么办?定义客户编绎开关，只有此客户才用到此编绎开关。 行,问题是解决了,随意的添加工编绎开关,又为后期的维护埋下的定时炸弹.2 无法直接查看编缉参数。保存的参数对我们来说是不透明的， 不可交互的。 在软件开发， 我们常常遇到由于参数区数据被破坏而引发的bug, 我们为会拷贝参数区到一个文件 ，与正常的参数区二进制进行对比， 以确定参数区是否被破坏。 存入参数区的数据为二进制数据, 二进制式数据对我们来说, 几乎不具有可读性,进而影响到软件的可维护性。3 软件移植起来困难。如果我们想把软件从嵌入式平台移植linux(或者windows)下进行开发, 由于参数保存关联到设备文件/dev/mtdblock4,会给移植造成一定的阻碍.
三 以文本的形式保存参数。数据以文本的形式保存到一个参数数据文件。有过windows下软件开发经验的同学，一定清楚windows下配置文件---ini文件。很多windows下的应用程序采用ini的格式文件进行配置参数的保存，ini文件同样也适用于linux下。 ini的格式如下。[login]username=dcdclookpassword=123456上面提出的二进制保存数的几个不足之处，恰恰就是文本形式保存参数的优点。我们可以很容易的进行数据扩展，用户名想要定义为17个字符?行，[login]username=dcdclook89abcdefghikjpassword=123456随便一个文本编缉工具就可以查看系统参数。保存的参数的数据内容对我们来说是完全可见的由于不关联硬件设备文件，移植以来容易。当然文本的形式保存参数也不可避免的存在着一个问题，解析花的时间会较二进制数据保存参数方案长那么一点点。其它常见的文本保存参数格式有xml,较之ini文件，xml可以实现多层数据参数的写入。四 用数据库来保存参数。常见的嵌入式关系型数据库SQLite，单纯的用SQLite来进行配置参数数据的保存与读取，个人觉得并不是一个合理方案，有点杀鸡用牛刀的意味。在一些特定的嵌入式开发应用场景中，sqlite 还是有有武之地。例如， 手机中的通信录(Android系统中就集成数据库Sqlite)。没有最好的技术，只有最合适的技术。具体采用何种参数，可以依实际的需求进行选择。