[CustomEditor(typeof(Type))]
这是所有写过编辑器的人非常熟悉的一行代码，因为它是编辑器的入口。
但是：
[CustomPropertyDrawer(typeof(Type))]
恐怕就没几个人知道了。
它和CustomEditor功能类似，都是自定义特定类型的编辑器界面，但它的对象不是MonoBehaviour，ScriptableObject， 而是一个字段上的数据。
[CustomPropertyDrawer(typeof(UserStruct))]
public class UserStrutDraw : PropertyDrawer
{
public override float GetPropertyHeight(SerializedProperty property, GUIContent label)
{
return 0f;
}
public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
{
EditorGUI.BeginProperty(position, label, property);
EditorGUILayout.BeginHorizontal();
EditorGUILayout.PropertyField(property.FindPropertyRelative("name"),new GUIContent("姓名："));
EditorGUILayout.PropertyField(property.FindPropertyRelative("sex"),new GUIContent("性别："));
EditorGUILayout.EndHorizontal();
EditorGUI.EndProperty();
}
}创建这样一个类后，用到UserStruct这个数据的编辑器界面都会发生变化（或者是公开属性直接在属性面板显示，又或者是用EditorGUILayout.PropertyField呈现）
但这样并不方便，因为同一段编辑器代码会用在多个类型上，所以通常的做法是：[CustomPropertyDrawer(typeof(Type))]中的Type不指定具体类型，而是指定一个PropertyAttribute元标签对象。
public class UserDisplayAttribute : PropertyAttribute
{
}然后在需要应用应用这个编辑器的地方打上UserDisplayAttribute这个元标签。
[System.Serializable]
public class Profile
{
[UserDisplayAttribute]
public UserStruct user;
}便能够有和之前相同的效果。
此外，编辑器类的基类PropertyDrawer是用来定义某个属性的，它具有独占性。但你也可以继承自DecoratorDrawer，它是“装饰”的意思，是可以叠加的，可以用它来做一些界面绘制工作。
[System.Serializable]
public class Profile
{
[DrawLine]
[UserDisplayAttribute]
public UserStruct user;
}另外，Attribute对象也是可以有内部属性的
public class UserDisplayAttribute : PropertyAttribute
{
public Color color;
}直接写在括号内就可以为这些属性赋值，然后就可以在相应的PropertyDrawer类里读取到这个值，并处理。
[System.Serializable]
public class Profile
{
[DrawLine]
[UserDisplayAttribute(color = Color.red)]
public UserStruct user;
}这就为我们开通了另一条，不通过CustomEditor做界面的方法。而这种方法代码量更少，也更容易重用。我们可以在写数据类的时候顺便加上这些元标签，然后用EditorGUILayout.PropertyField呈现整个数据类的根结点，然后用Unity自己的对象层级功能一层层展开，不需要为每条属性书写编辑器代码。对Unity自带呈现不满的地方，用PropertyDrawer类重新定义就可以。
数组也是可以重定义的。
而且用这种方法，以前一些比较麻烦的组件功能也变得容易实现了，诸如Tab
[CustomPropertyDrawer(typeof(TabAttribute))]
public class TabDraw : PropertyDrawer
{
public override float GetPropertyHeight(SerializedProperty property, GUIContent label)
{
return 0f;
}
public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
{
GUIStyle buttonActive = new GUIStyle(GUI.skin.button) { normal = GUI.skin.button.active };
string[] tabNames = (attribute as TabAttribute).tabNames;
EditorGUILayout.BeginHorizontal();
int count = tabNames.Length;
for (int i = 0; i < count; i++)
{
if (GUILayout.Button(tabNames[i], i == property.intValue ? buttonActive : GUI.skin.button))
{
property.intValue = i;
}
}
EditorGUILayout.EndHorizontal();
}
}
public class TabAttribute: PropertyAttribute
{
public string[] tabNames;
}
//使用示例
[Tab(tabNames = new string[] { "tab1","tab2"})]
public int tabIndex;
还有比较重要的属性中文化
[CustomPropertyDrawer(typeof(LabelAttribute),false)]
public class LabelDrawer : PropertyDrawer
{
public override void OnGUI(Rect position, SerializedProperty property, GUIContent label)
{
label.text = (attribute as LabelAttribute).label;
EditorGUI.PropertyField(position, property, label);
}
}
public class LabelAttribute : PropertyAttribute
{
public string label;
public LabelAttribute(string label)
{
this.label = label;
}
}
[Label("中文属性名")]
public int testInt;
所以我们只需要写好数据类，然后适当加几个样式元标签，根据游戏内容自己实现一些特殊的元标签以便和游戏预览部分通信，以及针对布局需求用DecoratorDrawer绘制界面。然后外面再包一个EditorWindows，将游戏的数据用ScriptableObject整体序列化以及储存。
这样我们在游戏开发过程中，编辑器就可以自动完成了，数据部分也是高效的二进制序列化格式，读取即使用，也不需要重写一遍Parse。
要说缺点的话，也就是限死了必须用Unity的序列化格式。当然，如果你愿意的话，也可以写个反射脚本把它转换成JSON,XML等其他格式，但在“技能编辑器”这类应用环境内，由于只有客户端在使用，并不需要“通用性”（虽说这个格式C#也能内建读取就是了）
至于你说，策划和程序用的是不同的Unity工程，所以不能用一样的数据格式……
首先策划和美术起码得用一样的工程，否则同步资源太浪费时间了，不同步资源？是让策划瞎着眼睛配置数据吗？程序部分如果不想暴露代码，可以编译成DLL放到他们的工程目录内，这样用上去和使用同一工程是一样的。
你非要两边代码不共用，就意味着编辑器那边不仅要实现数据编辑，还要把部分游戏逻辑修改复制一份到另一边，很容易不一致，并导致委曲求全，编辑器使用非常困难。
关键是耗费巨大，又没有实际的好处。
只要编辑器和运行时使用同一套CS代码，就可以通过这套东西节约大量开发时间，以及需求变动时修改导致的等待时间。
然而，虽然有这套东西，但是Unity自己的原始属性面板确实比较难用，虽说都可以实现，但像Tab，数组之类的功能，一个个实现也很费时间。
这里正好有一个实现好的三方库
Odin Inspector and Serializersirenix.net
进入网站往下拉可以看到全部功能介绍的动图。
除了大量定义好的元标签之外，还提供了一个任意类型序列化的功能，便于容纳字典等其他复杂类型。
从源码看，它还重写了Unity的那套Attribute的底层，不再限制元标签必须在字段上，可以放到方法上实现诸如Button之类的功能。
[Button("label")]
public void TestMethod()
{
Debug.Log("test");
}在它的基础上开始扩展，应该是更好的做法。
29号更新：
Odin的某个示例程序
貌似是只能猜了吧？
编辑于 2018-01-29