项目由来

Web框架泛滥的时代

初学Web开发的人都知道，面对琳琅满目的Web前端、后端开发框架，都会患上选择困难症，像SSH、ROR、ASP、Angular、Backbone等等等等超多的解决方案，可以让开发人员做选择。

然而来到了游戏开发领域，相对的开发框架缺少得多，尤其是客户端领域，大家更多的是讨论游戏引擎。因此在实际的游戏开发中，总会发现，有一些工作是一遍又一遍的死重复着——读取配置表的机制、资源的加载管理、更新机制、多语言等等等等，几乎每一个新的项目，经常都重头开发一次。 更要命的是，当机制没有稳定规范时，重复的开发，同时之前所有的趟坑经验都是作废的；对于团队项目，这同时还连累了策划和美术伙伴。

能否在游戏开发领域，有一套可以复用的开发框架？

2014年，KEngine由此想法而萌生，最初它是由已有的项目中抽离、解耦出来的一套Asset Bundle辅助工具，尝试对资源、UI、配置表三个方面制定稳定的开发机制，并针对Unity 3/Unity 4中坑大了的Asset Bundle系统做了一套Asset Bundle打包系统（非常类似今天Unity 5中的新Asset Bundle系统）。

进入Unity 5，新Asset Bundle系统让Unity的资源管理提升了一大个层次，同时运营热更新的需求在今天也越来越受重视；同时，对于大Unity项目，后期的维护是一个噩梦，大量的C#代码导致轻微的修改却引发大量的转菊花时间、频繁的易崩溃等因素，都会对开发效率大受影响，这时候开发期的热重载也能大大的提升效率。

KEngine + SLua+ Framework = KSFramework

KSFramework整合了KEngine和SLua，将资源加载与打包、配置表的智能编译、UI规范和Lua脚本整合起来，并更多的开始思考开发、运营阶段的热重载。

在KSFramework的开发中，简单，是其功能开发的第一原则；对机制的思考过程，远比实际的开发耗时要多得多。因此，KSFramework出现的更重要的意义是对一些普遍的功能模块提供一些机制和规范， 您完全可以根据这些机制轻松的自己实现一套类似的。

多年的开发经验告诉我们，做一款开发工具最困难的部分，就是让其变得简单。KSFramework在这方面还有很长的路要走。

运维导向的开发

当今时代，一款软件产品的运营是快节奏的。 各种各样软件产品的运营，离不开“热”字，运营想想希望在用户无知觉的状态的，呈现给用户最新的功能。

然而在游戏开发中，尽管Lua的流行，更多的客户端热更新，主要还是使用重启后更新的机制。

KSFramework中关注热重载，更希望能做到真正的“热”——可以在游戏运行过程中，用户无知觉的状态下进行“热”更新。

这不单给予项目的运营巨大的好处，而且给项目的开发阶段也节省巨大的时间成本——以往一些在修改代码后，需要重启，点击界面，进入测试环境的情况，在热重载的机制下能节省很多的时间。

然而，要做到真正的热重载，更多的并非技术问题，而是惯性思维、技术习惯的问题。这也是KSFramework努力的一个方向。