unity3d

前言 对于Unity编辑器的扩展方法众多，本文从最常用的一些方法入手，例如Inspector脚本栏的扩展、顶菜单栏的扩展等，图文并茂阐述其完整用法。 本文大部分内容整理自 独立游戏开发 - indienova 所著的 Unity使用技巧集合 ，但仅选取了最常用的一些方法，并在自身项目上加以实现。 项目地址： UnityEditor - SouthBegonia https: //github.com/SouthBegonia/UnityWorld/tree/master/UnityEditor 本文仅供学习交流，如有任何侵权行为立即删除。 脚本栏的扩展 该部分的扩展方法集中在Inspector中脚本面板，主要体现在代码实现脚本栏中可视变量的规范化、便捷化 [Header] 属性标题 为后续区域代码拟订一个标题，用于区分和概述该区域代码含义 [Header( "武器" )] public int weapon; public int ammunition; public int aurability; [Tooltip] 属性提示 实现在Inspector中，鼠标位于该变量名字上时，提示该变量的描述信息 [Tooltip( "玩家的名字，肯定不再是JOJO对吧" )] public string playerName; [Space] 空行属性

数据可视化大屏成为了这两年很火爆的一个需求。 一方面，不少甲方都想做这么酷炫的大屏，用于公司展厅、日常经营监控，还有些特殊行业如交通、运输、工厂制造，会做更高级的3D建模等。 另一方面，市面上可提供做大屏的技术、工具和厂商层出不穷，似乎能和数据搭上边的都能做大屏。 大屏真的像一些文章说的神乎其技吗，真的那么低门槛零成本？ 如果是这样，我作为一个做技术，尤其是做了十几个大屏项目实施，也不会秃头了...... 先来说说几个误区。 误区一：网上看到的绝大部分大屏都是效果图 效果图和实际图最大的区别就是效果图都是静态的，实际实施时需要适配屏幕分辨率，比如字体能否自适应大小。一些动态展示如3D旋转以及图表空间和数据刷新的速率也无法看见，基本上实际图做出来会和效果图差那么一两成。 再者啊，这个效果图很多在线网站，图表插件都可以直接设计出，像我们在做项目前也需要美工帮出几版效果图，所以你无法通过效果图来判别厂商的专业度尤其是实施能力。 误区二：认为大屏仅是前端技术？NO！ 数据从哪里来，是读业务数据库还是建立中间库，数据更新的频率要求是什么，数据质量有无问题还要先做底层数据处理？ 硬件方面，需要明确大屏的尺寸、种类、驱动大屏的主机？ 业务方面，大屏展示什么指标和维度，业务分析逻辑谁来支撑？ 这些都是要考虑的。 误区三：大屏成本低，零代码实现？NO！ 据我所知，一个大屏项目十几万是常有的事

原文出自： IOC : Unity 配置和使用 之前Terry Lee 已经介绍过Unity的简单使用了，不过那篇文章是针对旧版本的，现在的版本1.2版略有不同。 我下载了Unity并做了一个简单的测试，项目的分布是这个样子： LoggerTest.Interface.ILogger 主要是接口， 一个简单的不能再简单的方法结构： public interface ILogger { void Write(string message); } LoggerTest 是实现这个接口的project， 恩，跟Terry Lee 的例子一样，实现两个就OK了，分别是FlatFileLogger和DatabaseLogger。 namespace LoggerTest { public class FlatFileLogger : ILogger { public void Write(string message) { Console.WriteLine(String.Format("Message:{0}", message)); Console.WriteLine("Target:FlatFile"); } } public class DatabaseLogger : ILogger { public void Write(string message) { Console

《asp.net-mvc框架揭秘》一书中，有个示例，是使用unity容器来注入自定义的控制器工厂。代码示例可以自己去下载源码，在这里我就不说了。IOC容器的本质是解耦的实例化接口类，而如何做到解耦就是通过第三方容器来实例化，在这里是unity容器，而不是在项目中实例化接口类。实例化的方法无非就是反射，Emit，表达式树，委托等四个方法。Unity容器的IOC使用主要是三个个方法:Register,Resolver,Dispose。前者注册接口和接口类，后者将接口类的实例化转移到第三方容器中实现。而这里的Dispose却是有点文章了。如果单单是控制台的应用项目，就不必多说，如果是在mvc框架中的话，我们的接口类的资源释放应该放在什么地方合适呢？微软unity开发小组给我们做了很好的解释，原文: https://msdn.microsoft.com/en-us/library/dn178463(v=pandp.30).aspx 我们将Unity容器里面资源的释放与控制器的资源释放绑定在一起。如何用代码来表示？我们在基于Unity的控制器工厂中的GetControllerInstance中解析controllerType对象，而不是解析某个接口: (IController)this.UnityContainer.Resolve(controllerType);