unity3d程序美术问题汇总.docx

建议他拿一个dome现场操作一下。

目前手机上大家使用的通讯用多还是socket多?如何选择？我根本上几个工程中用到的都是socket。

通讯这块并不精通，选择socket，还是，个人感觉其实还是更需要依据工程的具体类型来选择。偏休闲、卡牌等网络实时性需求并不太高的一般选取，而Arpg等根本上选取的还是socket。

怎么用代码治理工程中的各种对象？不使用拖拽的方法去绑定，还有没有其他好的方法？其实对于Unity来说，拖拽绑定是他所特有或者说官方推举的对象绑定方法。

其它的，诸如可以使用GameObject.Find查找对象〔效率不高〕，GetComponent方法猎取脚本对象〔效率也不高〕。

其实不使用拖拽方法绑定对象，在我们遇到的实际状况就是，代码访问权限或者资源和代码解耦合的状况。解决这种问题我们一般是使用将拖拽的对象引用到中间脚本，然后靠映射机制，将中间脚本的对象引用赋值到目标脚本，解除真实的处理脚本和资源之间的耦合关系。

使用图集|加载图集，和外部加载场景图片怎么去规划适宜？

由于我之前所做的都是3D玩耍，所以图集对于我们来说更多的还是应用于UI。

根本上是首先由筹划供给资源一般是存在于什么时候，根本上是按职业，按功能，按等级等区分图集，理论上是要做到尽可能的降低使用的图集数量，以及现存图集中尽可能少的存在冗余。

打包时候怎么才能让我们的应用文件最小？

影响包大小的，最大的影响就是资源。所以按目标平台等选取适宜的图片压缩格式，既能削减包大小，也能削减运行内存。

还有一种就是，尽量少用.net中的一些比较大的库。例如linq等。尽量的以引入精简版的第三方库为主〔或者有条件的可以自己开发〕

写代码的时候影响u3d的效率的都有那些？

影响U3D效率的，其实U3D的独有的并不太多。

削减GameObject.Find的使用频率

Update中少做实时运算，条件允许的状况可使用缓存变量，防止Update中运算过多。

如非必要，削减GetComponent和AddComponent的使用，尽量的在开发期间完成，削减运行时的运算量。

类似于ganeobject.transform的引用，写起来很简洁，其实挺费的，假设需要操作N次transform的话，建议将transform缓存。一次gameobject.transform的开销，相当于调用一次GetComponent。

尽可能的少用”aaa”+“bbb”+“ccc”等字符串拼接方式，推举使用StringBuilder，哪怕string.format都优于+++的拼接方式〔会造成大量的额外GC开销〕。

多Ui文件怎么分层名目，高效读取，治理？没理解什么意思。

其实我们的UI还是更多的以功能来区分，一个功能面板，对应一个UI文件。

UI处理是使用NGUI插件吗？是全部功能模块都用一个图集？还是一个功能模块对应一个图集？图集加载？

是使用的NGUI。

全部模块共用一个图集会导致，图集超大，冗余量太多。

一个模块一个图集可能会导致，UI的资源量过大，不同图集中存在冗余。

建议使用，将UI分成公用资源和界面独有资源。比方整个UI都公用的资源，比方背景图片，比方按钮背景等等尽量的做到一个或几个图集中，类似于uiCommon1.png、uiCommon2.png等形式，其它的按功能区分每个界面独有的单独存放在一张图集中。

比方背包界面，可能需要使用的图集

关于图集的加载，其有用到实时加载的图集更多的还是应用与图标。推举，静态UI界面所需要的资源和icon图标等资源严格分别。

多脚本，多组件绑定对应时，导致的会一些问题。

多脚本绑定时，特别是多人协同开发遇到的问题，可能会引起脚本丧失，最主要的缘由就是大家一般都使用SVN、Git等治理工具，可能由于.meta文件的缘由常常简洁造成脚本的丧失。

还有一个隐患就是，当一个GameObject绑定多个脚本时，假设多个脚本之间又互有引用，可能会由于脚本的实例化挨次导致引用丧失，或者空指针崩溃等。建议时当存在这种状况时，在Unity中显示的设置脚本的实例化挨次。

说说untiy加载机制(app更机制)

问题太笼统，没搞明白，请具体描述一下再说吧。

团队协作模式和方法

团队开发方法，第一还是看工程规模，假设工程小，人员少，谈不上所谓的方法，三两个人开发与其争论方法不照实时的口头沟通。

对于大型工程来说。

首先，资源的治理软件，不推举Unity本身的资源治理工具。第三方的一般大家使用SVN或者Git。推举使用Git，相对于SVN来说属于分布式治理，