在之前的两篇中，我们使用 public 静态方法对之前的内容进行了一个抽取，有了 public 静态方法这个工具，我们的学习行为也发生了一点变化。
在没使用 public 关键字之前呢，每一个示例仅仅是一个知识的记录作用。而我们用了 public 关键字之后，我们可以把知识作为一个可以复用的方法。但是呢，这样就有了一个顺序的问题。
我们是先写方法在写 MenuItem？还是先写 MenuItem 还是在写方法？
笔者给出的答案是，在学习新的 API 或者新的知识点的时候建议先写 MenuItem 示例，等掌握这个知识之后，再去设计方法。其他的情况我们遇到了再说。
接下来要学什么？我们的知识库有一个问题，就是存在重复代码，第八个示例和之前的示例都重复了。有点经验的童鞋早就有把它们一口气整理的冲动了吧？不过，还不是整理的时候，还不是时候。因为我们的规则和约定经常改的话会非常不稳定，会徒增工作量，所以呢，我们要等待一个比较合适的时机。时机成熟了就进行整理。但是在整理之前呢先按照这种接着收集我们的示例。
不过到这里，笔者就迷茫了。在之前我们的知识点都是有目的的，这些知识点组合起来可以为我们解决一些问题，比如导出功能最初是为了让自己在家和在公司之间或者在项目之间进行无缝切换的。这个问题已经解决了，那么还有什么我们身边问题通过编程解决呢？
笔者要好好思考一下，在教程的开头，笔者说要选择的知识点是搭建框架需要的知识点，或者笔者认为比较重要的知识点。而导出功能所需要的知识点是框架中比较常用的 Unity API。而我们每个示例的规则和约定则是架构相关的内容。然后在导出功能之后应用了 C# 语法中的 public 关键字，也就是访问权限，访问权限对一个框架来说也是非常重要的东西。我们到目前为止的目标呢，只是打造一个知识库，这个目标还是在第一篇的时候定的，目前看来只是完成了一个知识库使用的流程，并没有积累很多的知识点。好吧，又回到了刚才提出的要学什么知识点的问题了。
虽然又回到了原点，不过这样梳理一遍思路还是很有帮助的。最起码可以得到一个具体的分类，将以上的几个关键点列出来如下:
框架常用的 Unity API 与功能(比如导出功能)。
架构的内容:约定、规则。
C# 程序设计:访问权限与方法设计。
有了以上这样的一个列表，结构就清晰了很多。在 Unity 开发者中，大多数的童鞋都是做项目，少部分童鞋专职做插件、框架或者渲染等工作。所以呢，笔者要思考知识点的方向选什么最合适？
对于专栏来讲，用最少的时间完成一个最简版的框架或许可以马上迎合教程的主题，但是市面上写最简框架的教程和文章多得数不胜数，如果只是为了搞个简易框架而写这篇专栏，不如去看 2017 版本的专栏。
对于读者来讲，专栏要保证阅读体验，并且掌握文章的知识点和方法论的同时能够从文章中获得启发，这样是最好的。而如果一个专栏或者书籍太过系统很影响阅读体验。
所以经过综合思考，接下来学习一些更贴近项目的小知识点。
第九个示例（一）在上一篇文章中，经过大量的思考我们得出了一个学习方向，那就是在项目中比较实用的小知识点。
我们大部分 Unity 做的项目呢都是移动端的项目，这里包括 iPhone、iPad 以及各种 Android 端的设备。而经过笔者统计大部分的设备屏幕宽高比都是 16:9(iPhone 5s 至 iPhone 8) 和 4:3 (iPad)。而少部分的则是接近 2:1(iPhone X) 和 3:2(iPhone 4s)，还有一些比较奇葩的分辨率，比如魅族和华为的 Pad。
而我们在进行屏幕适配的时候多多少少会通过代码来写一些特定分辨率的逻辑（因为总有那么几个比较奇葩的设备）。OK，到此我们要做的事情比较明确了。
我们来做一个用来区分当前设备分辨率的工具。
我们先来写一个最简单的，判断是否是 Pad 分辨率(4:3)。
第九个示例在开始写判断逻辑之前呢，我们先要获取当前设备的宽和高。
Unity 提供了 Screen.height 和 Screen.width 这两个 API 来为我们提供当前设备的高和宽。
判断横竖屏设备有可能是横屏也可能是竖屏，所以我们要判断当前是横屏还是竖屏。
判断代码如下:
#if UNITY_EDITOR [MenuItem("QFramework/9.屏幕宽高比判断")] #endif private static void MenuClicked() { var isLandscape = Screen.width > Screen.height; Debug.Log(isLandscape ? "横屏" : "竖屏"); }如下图所示，当将 Game 视图的分辨率改成 4:3 时。
输出结果为:横屏