从2010年的HUI0.6 版本到现在HUI5.0 

	hui0.6 windraw	基于windows绘图
	hui1.0 beta		使用linux重写hui,hui xml控件思想初步成型
	hui2.0 jiuyong	重写9次绘图逻辑4次内存数据库，大大提高了hui的效率
	hui3.0 base		目前为止使用最多的版本之一，开始导入git管理代码，实现去外部依赖
	hui4.0 vidroid	融入了动态 缩放，旋转实现了框架式管理控件
	hui5.0 hulua	葫芦娃 hui 融入lua脚本语言来控制外部逻辑，实现xml lua shell三位一体
					
						改动特点：	去掉CUS页面缓存机制，使用控件框架隐藏显现来控制单幅多页
									将humap改为传入式的，并且不再element中保存humap，节省系统开销
									任何控件的doflashconfig自始至终值运行一次，其余使用lua控制逻辑，大大提高效率
	
		---HUI5.1	资源管理
						很早之前就有这个想法，element中的res大部分都是只读数据，这个时候加压到内存中是很浪费内存的，
						而且一直在读取过程中加载，甚至重新解码变得无意义	
						假设1:一个动画，大约两百帧的内容，如果都加载到内存中，那么很浪费内存，而且大部分没有意义，
							因为很久才能跑到一帧。
							如果一直释放，那么肯定会不断的重新加载，不断的解码
						假设2:一个文件浏览器，在没有资源管理的情况下，
							目录下有一百个文件，图标都是一样的，原本没有任何相关性，所以同样的图标文件被重复的解码了无数次，
							大幅的浪费了内存，进行了没有意义的工作。
						假设3:页面反复跳转，用的却是同一个背景，这个时候一张全尺寸的图，正在不断的被解码，释放

						新增加menuconfig内核选项readonly resource manager
							runtime decode		如过去的方式,实时解码图片		
							runtime index		将第一次使用的图片从直接映射到虚拟内存，寻你内存可以保存，
												之后启动的时候即不用重新解码(未完全实现) --+10%效率 +60%内存节省
							runtime fetch		用到的图片直接从虚拟内存中拿出一个备份 --+20%效率 

						index与fetch的区别
							index完全不占用任何物理内存的空间，直接从虚拟内存绘制，但是绘制效率可能低下
									目前问题：不支持硬件绘制 ,还没有实现自改变
							fetch也是使用同一个只读虚拟内存池，但是会实时将资源取到物理地址，跟decode一样占用内存，但是省去了所有decode过程
						关于资源还有很多欠缺与不合理的地方，如果加强管理可以大大的提高加载速度，
						资源是给控件利用的一个媒介，如果大家有更好的想法，可以参考我的接口，添加自己的资源管理办法
						尽可能提高速度与利用率

							packres使用方法，编译出packres x86 arm都可以，源码在mres/tools里面，拷贝到资源目录下执行，打包成res文件
		--HUI5.2	自定义绘图逻辑
					menuconfig 自定义绘图逻辑
					后续自定义逻辑绘图请遵规范
						1必须无条件编译通过所有控件，如若依赖特定绘图逻辑的控件必须Kconfig depend相关绘图逻辑
						2将Xsample中的drawlogic_test作为绘图绘图参考，来检测绘图逻辑的完整性
						3如果有发现绘图逻辑不完善的地方，每个人都有义务给出更多的Xsample作为完善绘图逻辑的参考

经过了长久的大家长久的努力与付出，HUI整体取得很大的进步，现在作为HUI的创始人们要考虑HUI未来的发展，相信未来有一天我们的HUI能够成为一个成功，成熟，稳定,通用的UI库
以后的分支与合并可能会不断的发展，我们必须保证手头的代码一致性，才能做到劳动成果共享，通用。
我们应该将这份README文档长久延续下去。核心成员可以通过讨论的方式新增修改内容。
HUI为了HUI有长远的发展，我在此必须要约定今后的行为规范，避免在今后发展过程中臃肿化，与提高一致性，移植性。

HUI编程规范:
	一，所有代码高度抽象，整个HUI内核中，最具体的底线是控件，整个HUI内核中不允许出现业务逻辑相关任何代码
		一个优雅的框架，代码尽量做到高度抽象化，模板化，禁止低效率，低可读，低容错的代码，所有代码中不提倡嵌套超过两个以上的if else
	
	二，规范化命名规则,	HUI<版本号> <子版本号>比如延伸版 HUI5.2.1 ugdraw
	
	三，接口定义规范
		XML向javascript方向发展,C++函数要保证兼容性,不要盲目的跟风android的接口。从设计最初就是针对低端linux平台设计的UI式浏览器,与android有着截然不同的设计理念
		所有接口规范化底层框架至少在大版本不做大的改动，以实现文档的通用性，让更多的人加入HUI，如果接口改动影响整体框架，需取得每一个核心成员同意做出决定
	
	四，绘图规则，绘图逻辑一定要高度层抽象，设计绘图逻辑的时候一定要想象底层一片蓝天，中间鸟儿飞翔，在云中时隐时现的场面
	
	五，任何修改框架都需要无条件的编译所有控件通过，不能menuconfig勾掉了事
		每个人固然有不同的思想，实现绘图逻辑另外的绘图逻辑要通过menuconfig 的方式，通过路由文件修改，要求在切换绘图逻辑时所有控件都可以编译使用，
			或者特殊控件kconfig 必须depend专用绘图逻辑
	六，添加任何新的控件kconfig必须给出help实例
	七，每一个版本都需要在此README中历史给出自己的设计思想，也就是说在写代码之前要先写出自己的需求与设计理念，再实现代码具体部分
	八，还有很多不完善的地方，希望大家能够积极提出，站在考虑HUI长远发展的角度

		抽象不应该向懒惰妥协，一个优秀的程序员不能向图方便妥协。
		让我们大家一起努力为HUI写出更加优雅，优越，高效的代码
		优秀代码的重要性：我今天突然找出了10年写的HUI0.6，通过vc6编译器运行，一份优秀的代码不管多少年拿出来看的时候都能感觉那么舒服，有些接口可能忘掉了，
			但是程序依然能正常运转，开发过程中依然能够正常的拿来调用。但是一份糟糕的代码到处飘着ifelse，多年之后你再想起它的时候只会让你感觉糟糕，头疼
													----胡鑫培 15/06/29



核心成员：
	胡鑫培，张畋，罗杰，胡顶，江振刚，于涛，江进龙，刘伟伟，许巍，方显波，杨峰，杨自和，郭增