一、节点数量
我的节点一共接近300个，下图为节点的局部图（一行为一条流程），在编辑和运行时，没发现与节点数量有关的性能问题。
网上有人说节点超过xxx个的时候，会出现性能问题，我猜可能不是节点数量的问题，而是脚本逻辑的问题。
节点数量与性能的关系，有待后期研究和分析。
?
二、对Unity工程进行build的时候的注意事项
Graph上的每个node，在编辑器下运行一点事都没有，但是在build时可能会遇到莫名其妙的问题：比如不能初始化，有时候弹出错误，甚至会询问你是否在脚本用了【#IF?UNITY_EDITOR...】编译条件.....我刚编译的时候，有报错，但是没有指出是什么脚本错，让我一度有点崩溃。
一些思路?
1、遇到错误先冷静，也不要自个吓唬自个，更不要武断的下定论——比如说：WebGL不能用xNode。
2、启用调试功能 ，把运行时的log扒出来慢慢看，逐条处理。
build的时候，启用 development build，对exe特别有用（因为我始终没在本机上找到output log的文件）。建议先build成PC版本，调试成功后，再build成其它的webGL。
3、所有的节点，确保他们都是有效的。有效是什么意思——node上的脚本存在，而且node上设置的参数也有被初始化。我遇到的问题：在开发节点的时候，节点脚本的名字和类名不一致，导致节点不显示在Graph上，但是build的时候，报错崩溃。
4、自己开发一些小工具：比如检查node的脚本是否missing，检查参数是否被初始化
三、开发节点的时候，注意逻辑的粒度
我以前用过virtools做三维仿真，后来转unity，本身自己是一个码农，所以，对一些流程或者框架的东西比较感兴趣。
新手的话，设计node的时候千万别粒度太细，不然就搞复杂了。
我喜欢用消息来解耦，并且只用node来表达业务流程，如下所示：发送一个消息去执行一坨代码，代码执行完毕后返回一个ok的消息，我的流程就等这个ok消息，等待后，往后面执行。这样，我的总流程只是一些步骤，很少涉及分支，不存在循环（循环都在code里）。
?