windows10利用linux子系统编译mono

  1. 安装debian
    1. 系统设置中,启用开发者选项
    2. windows组件中,安装linux子系统组件
    3. app store中安装debian
  2. 安装编译工具
    1. 打开debian命令行
    2. sudo apt install build-essential zip unzip git bison
    3. sudo apt-get install git autoconf libtool automake build-essential gettext cmake python
  3. 下载相应的mono
    1. unzip到/home/xxxx-user
    2. 查看external/build/build-runtime-android.sh,查找ndk版本,这里是r10e
  4. 下载ndk
    1. 下载ndk的linux-x86_64版本
    2. unzip解压到/home/xxxx-user
  5. 设置ndk-root
    1. 修改external/build/build-runtime-android.sh
    2. 在前面添加 export ANDROID_NDK_ROOT=/home/xxx-user/ndk-r10e
    3. 修改CFLAGS -fpic -O2
    4. 修改KRAIT_PATCH_PATH=”${CWD}/android_krait_signal_handler/build”
  6. 执行一次 编译
    1. 在mono根目录下执行 external/build/build-runtime-android.sh
    2. 这次不会成功
    3. 错误提示有可能在最开始,而不再最后(我一直再后面找错误,卡了很久)
  7. 修改android_krait_signal_handler/build/build.pl
    1. 把第一行中的 -w 去掉
    2. #use PrepareAndroidSDK; 这是注释掉,因为sdk校验在脚本中完成了,这里加上是冗余,而且会报错
    3. #PrepareAndroidSDK::GetAndroidSDK(undef, undef, “r10e”); 这里也注释掉
  8. 再次尝试编译,这次应该成功了,提示缺少什么,安装就行了。
    1. 在mono根目录下执行 external/build/build-runtime-android.sh

.net core GC 暂停

很多C#程序员都没遇到过明显的GC暂停,就以为没有。
这里贴一篇老外的文章,可以更真切的认识.net core的GC。
本文中,当内存有6G常驻对象的话,GC暂停时间就会达到1秒以上,48G时可以达到8秒以上。

这是原作者2018年9月末写的文章,比较新了。

原文地址

jdk11发布了ZGC

jdk11带来了一个实验性的GC

ZGC的官方目标:

  • Pause times do not exceed 10ms
  • Pause times do not increase with the heap or live-set size
  • Handle heaps ranging from a few hundred megabytes to multi terabytes in size

GC暂停最大(不是平均)时间在10ms以内
暂停不会随着内存和运行时间的增加而增大
支持的内存可以从几百M到几T。

真是神器,让java程序使用超大内存成为可能,基本消除了jvm优化工作。为java开启了更多应用场景,比如开发游戏服务器、开发缓存服务器。只要程序可以容忍最大10ms的延迟,就可以使用java来开发。

试用ZGC

  • 只能在linux上用
  • 开启zgc
    -XX:+UnlockExperimentalVMOptions -XX:+UseZGC
    • 查看gc日志:
      -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc
    • 看详细gc日志:
      -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc*

貌似还有另外一个GC: Shenandoah

也只能再linux上使用。看官方测试延迟大概再50ms以下。
https://wiki.openjdk.java.net/display/shenandoah/Main

如何把一个图片中黑色部分变透明,灰色部分半透明

这个最终效果是:在黑色底版上,放上了一个白色半透明图片。最终形成和原图相同的图片。
打开PS

  • 黑色变透明:魔棒容差0,选择黑色,删除。
  • 灰色变半透明:选择复制图片,新建图层,填充白色,添加Mask(下方小图标),在通道页选中Mask,粘贴图片。ctrl+i反转Mask即可。

unity crunch 压缩

crunch压缩是有损压缩,具有很高的压缩比,要比Low quality还要小50%以上。所以,要高清显示的图片可以采用它。

  • 如果启用crunch压缩,最好把compressor quality置为100。出来的图不会明显变形。这样压缩的会慢点,尺寸稍微增大(不明显,比50的质量大了16%左右,相比没有启用crunch,这点变化可以忽略)。
  • 对于UI元素用图,最好不要启用crunch,而且要选择“高品质”。
  • 有时候某些Sprite里会掺杂别的sprite的边边角角,这时可以尝试图集里的Tight模式。

Unity tilemap产生缝隙

  • 贴片图要打包成图集
  • 图集的padding要足够大。(我最开始选择2,改成8后缝隙消失)
    • 老外的解释:The tearing comes from oversampling a tile by a tiny bit (i.e. 0.0001), and into an adjacent tile’s content. Padding repeats the border pixels of a tile to ensure the effects of oversampling can’t be seen, even though it’s still happening.

unity ui 性能调优

原文

  • Canvas

Canvas职责: 负责把子元素的几何体合理的批处理,并生成渲染指令,发送到Unity的图形系统。这个过程用c++实现,叫做批处理重建(rebatch)或者批处理构建(batch build)。如果Canvas包含需要rebatch的元素,可以把这个Canvas标记为Dirty。
Rebuild包含: Layout重建和Graphics重建两个步骤,也就是说如果元素的集合体变化(大小、位置)变化、以及图形、材质变化,会分别触发两个两个步骤。

  1. PreLayout
    Update data needed for layout calculations
  2. Layout
    Used by auto-layout system
  3. PostLayout
    Update data dependent on layout
  4. PreRender
    Update vertices and materials
  5. LatePreRender
    Update vertices dependent on generated text character data

Sub-Canvas: 作为Canvas子节点的Canvas称为子画板,子画板和父画板是隔离的:子画板rebatch,要求父画板同时rebatch,反之亦然。不过有部分边界情况会违反这个原则,比如修改Canvas属性。

  • batch原则:

** 两个元素(无论是否重叠),拥有有相同material和texture(同一图集),可以batch。

  • 优化方法
    • 所有UI尽量采用同一Material。
    • 减少Texuture变化,使用图集。
      • 注意:UIText文本时包含在Texture中的,可以被batch(可以观察FrameDebug看到)。(可以猜想,具有图集的TextmeshPro也一定可以batch。)
    • 切换Material的开销远远高于切换图集。切换Material时,内部渲染状态需要重建,而切换图集仅仅是增加一个drawcall,所以尽量使用相同Material。
    • 尽量不要动态修改CanvasRender属性。修改CanvasRender属性,会导致rebuild。
    • 避免修改UI对象的层次关系、兄弟节点的次序:需要重新计算深度关系,导致rebuild。
    • 避免使用PixelPerfect:每次移动Rect时都要计算自己以及子节点,把像素填充到顶点边缘,非常慢。
      • 可以静止时开启PixelPerfect,移动时关闭。
      • PixelPerfect只在WorldSpace模式有用。
    • 拆分Canvas
      Problem: 当Canvas中一个或多个元素变化后,整个Canvas标记为Dirty。需要重新分析整个Canvas:如何优化、如何batch,这个过程非常消耗cpu,很有可能降低帧数。
      Solution:拆分Canvas。每个Canvas就是一个独立的Drawcall,用的过多也会降低FPS,需要自己权衡。
      • 把静态UI和动态UI拆分到不同Canvas,
      • 把关联更新的UI放到一起
      • 也可以考虑把相同图集的元素放到一起,比如UIText:可以把所有HudText放到一个Canvas,把所有血条放到一个Canvas,避免他们因为叠加,而不能batch。
  • fq
    1. UIText重复设置相同Text的时候会触发rebuild吗?
      不会,源码为证,我们要相信unity开发人员,同样,transform设置相同pos的时候也不会。
//setter
                if (m_Text != value)
                {
                    m_Text = value;
                    SetVerticesDirty();
                    SetLayoutDirty();
                }