u3d减少编译时间原理
2015-09-17 12:28
417 查看
How it's working
Mad Compile Time Optimizer is taking an advantage ofUnity special folders and
how Unity compiles things.
If you’re already familiar with this matter then you most probably know that moving your scripts back and forth can take a lot of time. What’s a bigger problem is that you almost always have to do it each time when you want to upgrade assets from the Asset
Store.
What does a programmer do when he needs to do something repeatedly? He writes a script to do it of course! That’s why Mad Compile Time Optimizer has been born!
Why the optimization works?
Let’s say you have two scripts: the Foo.cs script and the Bar.cs script. Both of them are placed directly inAssets folder. If you modify the Foo.cs script, Unity will compile both of them. The same goes for the
Bar.cs script.
Let’s say that you want to optimize your compile times right here. There are two conditions these scripts need to met before optimization can be successful:
The dependency should be only in one direction (either Bar.cs →
Foo.cs or Foo.cs → Bar.cs)
The script that is the dependency should not be modified too often
Let’s assume that Foo.cs requires Bar.cs and Foo.cs is the one that is frequently modified. Knowing that we can safely move
Bar.cs into the Standard Assets or Plugins directory, do you want to know what will happen then?
From now on if you modify the Foo.cs script, the Bar.cs script won’t be recompiled!
Taking it to a real world scenario
How is this working in a real world? If you’re an Asset Store user (and I bet you are!) then your project may include assets such asNGUI, PlayMaker etc. The great things about these assets is that they come with a source code. The bad thing is that when you modify any source files in your project, all of these 3rd party source codes need to be
recompiled too (like in our Foo Bar example!).
Then if you have these assets, the dependency is, in most cases, unidirectional. This means that your code is using imported assets, but imported assets are not using your code (again as in the example above).
Having it that way you’re safe to move these 3rd party assets into Standard Assets and
Plugins directories? Right?! Wrong!!!
To make it work, the directory structure should be strictly kept as in the documentation. If you simply move your assets folders, most probably you will loose the access to the editor scripts inside them which will make them useless. You have to carefully
reorganize the folder structure to make it work.
The human factor
When something is needed to be done carefully, the human factor is the one most likely to fail. Of course if you’re focused enough and you have enough time you can do it again and again, but who wants that?Mad Compile Time Optimizer is reducing the human factor issue. It reorganizes the directory structure in a way that it will still work, but it cannot remove the human factor completely. You have to tell which assets can be moved (rarely modified
assets) and identify the dependencies.
The reverting issue
So what if you’ve already moved your script files and you need to upgrade the asset?Mad Compile Time Optimizer gives you the ability to revert the operation so all files will be back where they originally were. By doing this, you will be able to upgrade your 3rd-party assets and optimize them again without breaking
anything.
相关文章推荐
- 愚公移山——大道至简第一章读后感
- 分页sql优化
- NoMasp 博客导读:Android/Java/Windows/Lisp
- Scala包和引用
- 如何调用Linux内核没有导出的函数
- Spring boot jar 后台运行
- java学习之TressSet
- jfinal图片上传
- Spring boot jar 后台运行
- Spring boot jar 后台运行
- Spring boot jar 后台运行
- C#模拟百度登录并到指定网站评论回帖(四)
- GPS的一些浅显知识兼介绍一下GPS测试仪
- Tomcat学习笔记 - 错误日志 - Tomcat安装版安装后第二次启动后闪退(转)-- javac不是内部或外部命令 -- 配置java环境教程
- java的动态代理机制详解
- TextView排版问题
- 不再需要ImageOle或DynamicGifCtl,.NET实现IM编辑控件
- 函数返回值1的数量
- nyoj 题号12 水厂(两)——南阳oj
- A标签/按钮防止重复提交&页面Loading制作