导出 UnityPackage 功能到这里要告一段落了，相信认真看的童鞋都有收获。笔者在写教程之前纠结了很久。到底是先给出一坨工具代码，然后再逐个讲解比较好，还是一篇一个知识点比较好。后来想通了。工具和知识点都要同时写。也就诞生了这个系列的教程，这对笔者来说是一个挑战。
在 框架搭建 2017 年版本，采用的就是一篇文章一个小工具。而到了 2018 年版本，自己的内容变多了，所以一篇文章会讲好多东西。大家读起来内容会比较深一点，一篇文章大概要读个半个小时。再后来觉得一篇文章读半个小时这件事对笔者和读者都有点难度。笔者写一篇文章要准备很久，而读者读一篇文章也要花很多时间，读者的学习效果也不一定好。从这时候笔者开始思考一个问题，如何让自己高产并且让读者的压力小一点。
答案就是这个系列教程所呈现的方式，笔者也比较喜欢这种比较轻松的方式。
我们的约定事实上，文章读到这里，我们之间有了一个简单的约定（笔者和读者之间）。在第一篇的环境搭建的时候，笔者把示例放在了 QFramework 这个目录下，在这篇之后的示例也是如此，所以这就是一个约定。笔者和读者之间约定好了将所有的本教程的示例都放在 QFramework 下。
除此之外还有一点，就是大家在自己练习时候的要做的步骤，导出和导入。导出的部分是希望读者在多个项目之间或者在公司和家里之间切换的时候不会导致冲突。为了解决这个冲突所以，导出的部分包含了导出文件的命名。是按照日期和小时来命名的，这样读者在学习时很少会造成冲突。这个算是文件命名规则，也就是一个小小的规则。这也算是我们的约定范畴的。这部分规则集成到导出工具里了，不用大家再花费时间去思考如何给文件命名这件事了。
每个示例的命名目前都是按照数字加上功能进行命名的，这里没有限定一定要英文，因为 Unity 支持中文，而中文对我们以中文为母语的国人来说更友好一些。命名格式为: 数字.功能。
除了命名，导出部分还包含一个特定的步骤，每次写完示例就进行一次导出，以便及时备份，导出的文件呢，可以在家和公司或者多个项目之间进行切换，并不需要为每个示例进行一个项目的创建。
除了以上比较明显的约定之外，其实还有一些隐藏的要注意的事情，如果是在公司的项目进行学习的时候不要影响项目的编译打包，所以代码都要加上一个命名空间，教程推荐是用 QFramework，因为这个教程是以 QFramework 的迭代演进为原型的。这个专栏最终产出的代码会越来越趋近于最新版本的 QFramework。而为了兼顾可读性和项目风险，所以我们的编辑器脚本并没有放在每个示例的 Editor 目录下，而是选择了在脚本上加上 UnityEditor 宏。这部分在之前的文章里也是简单提了一下。
列出以上这点的原因是希望大家知道笔者做得每件事情的用意，并且呢这些内容都是和框架搭建相关的。只要理解了这些事情的用意，大家就不会觉得遵循这些无聊的约定和规则没有意义了。
大家遵循了这些约定和规则，理论上我们可以写无数个小示例了，除非达到磁盘空间的极限，或者文件数量多到无法运行 Unity ，在写个几十个这样的小示例没问题。
假如每个小示例算是一个游戏的功能或者业务，那么我们在写几十个类似的功能或者业务也没问题。
所以架构早就开始了。
自己收集知识点有了以上的规则和约定，大家在收集本教程的知识点的同时，也可以收集自己所学的知识，只要按照我们的规则和约定来就好。笔者给出的知识点不可能包含所有在工作中要到的知识点，也不可能是比较初级基础的知识点，而是在对于搭建框架用到的知识点，或者是笔者自己觉得比较重要的知识点，但是大家最好是把教程的知识点都收集起来并掌握。
今天内容就这些，说了一堆理论的东西，我们接下来接着一个个做小示例。