HybridCLR调研

作者

HybridCLR简介

官方链接：https://hybridclr.doc.code-philosophy.com
HybridCLR是 Code Philosophy（代码哲学） 公司的代表作品，我们希望通过我们的聪明才智深刻地改变整个行业，帮助游戏团队制作出更优秀的游戏。
HybridCLR是一个特性完整、零成本、高性能、低内存的近乎完美的Unity全平台原生c#热更方案。
HybridCLR扩充了il2cpp的代码，使它由纯AOT runtime变成AOT+Interpreter 混合runtime，进而原生支持动态加载assembly，使得基于il2cpp backend打包的游戏不仅能在Android平台，也能在IOS、Consoles等限制了JIT的平台上高效地以AOT+interpreter混合模式执行，从底层彻底支持了热更新。
HybridCLR不仅支持传统的全解释执行模式，还开创性地实现了 Differential Hybrid Execution(DHE) 差分混合执行技术。即可以对AOT dll任意增删改，会智能地让变化或者新增的类和函数以interpreter模式运行，但未改动的类和函数以AOT方式运行，让热更新的游戏逻辑的运行性能基本达到原生AOT的水平。

HybridCLR和其热更方案的区别

  • HybridCLR学习和使用成本几乎为零。HybridCLR让IL2CPP变成全功能的Runtime，学习和使用成本几乎为零，几乎零侵入性。而其他方案则有大量的坑和需要规避的规则，学习和使用成本较高，需要对原项目作大量改造。
  • HybridCLR可以使用所有C#的特性，而其他方案往往有大量的限制。（组件、UnityAPI、以及大量的官方和第三方工具都可以直接使用）
  • HybridCLR中可以直接支持使用和继承主工程中的类型，其他方案要写适配器或者生成代码。
  • HybridCLR中热更新部分元数据与AOT元数据无缝统一，像反射代码能够正常工作的，AOT部分也可以通过标准Reflection接口创建出热更新对象。其他方案做不到。
  • HybridCLR对多线程支持良好。像多线程、ThreadStatic、Async等等特性都是HybridCLR直接支持，其他方案除了Async特性外均难以支持。
  • HybridCLR中Unity工作流与原生几乎完全相同。HybridCLR中热更新MonoBehaviour可以直接挂载在热更新资源上，并且正确工作。其他方案不行。
  • HybridCLR兼容性极高。各种第三方库只要在IL2CPP下能工作，在HybridCLR下也能正常工作。其他方案往往要大量魔改源码。
  • HybridCLR内存效率极高。HybridCLR中热更新类型与主工程的AOT类型完全等价，占用一样多的空间。其他方案的同等类型则是假类型，不仅不能被Runtime识别，还多占了数倍空间。
  • HybridCLR执行效率高。HybridCLR中热更新部分与主工程AOT部分交互属于IL2CPP内部交互，效率极高。而其他方案则是独立虚拟机与IL2CPP之间的效率，不仅交互麻烦还效率低下。

正因为HybridCLR是原生runtime级别实现，热更新部分的类型与主工程AOT部分类型是完全等l价并且无缝统一的。可以随意调用、继承、反射、多线程，不需要生成代码或者写适配器。

其他热更新方案则是独立vm，与il2cpp的关系本质上相当于mono中嵌入lua的关系。因此类型系统不统一，为了让热更新类型能够继承AOT部分类型，需要写适配器，并且解释器中的类型不能为主工程的类型系统所识别。特性不完整、开发麻烦、运行效率低下。（很重要！工作量增加，系统复杂度增加，项目体量越大越明显，维护周期越长越明显）

性能测试报告

数据来源：https://hybridclr.doc.code-philosophy.com/#/basic/performance

  • 社区版本的HybridCLR除了数值计算跟lua持平之外，其他方面数据均大幅（数倍到数十倍）优于lua方案。
  • 商业版本的HybridCLR大幅优化了数值计算性能，有近300%的性能提升，其他大多数普通指令也有50%-200%的性能提升，对性能有严苛要求的开发者可以联系我们商业化服务。
  • 以下是社区版本的HybridCLR在iphone 11及小米5C手机下的实机测试报告,测试代码附录最后。

AOT 行是原生il2cpp的数据。HotFix 行是HybridCLR的数据。Lua 行是xlua的数据

file
file

以下是部分测试用例下的商业化版本相比于社区版本的性能提升数据。
file
以下是数值计算方面AOT与HybridCLR在优化后的性能对比，加法大约是7-16倍左右，乘法是4倍，除法是2倍。
file

内存占用报告

数据来源:加载程序集占用的内存

HybridCLR是CLR级别的实现，热更新类型除了执行方式是以解释模式执行，其他方式跟AOT部分完全相同的。因此定义等价的类型，无论在AOT还是热更新中，对象大小是完全相同的。

file

易用性（上手程度）

  • Unity引擎本身就是C#开发，而且在开发中不会有Inject、ILRuntime、Lua等脚本语言的一些限制，所以在开发时编写代码几乎和单机游戏开发一样。
  • 而且本身Unity在设计时也是高度绑定C#语言，所以从开发上不管是质量还是速度都有很大的帮助，很多以往积累下来符合Unity引擎的最佳实践都可以得以使用。
    注：目的就是降低学习成本，让编写更简单高效。

维护性

  • 热更代码几乎可以涵盖整个工程C#代码，框架代码-随包代码-热更代码的分类和注意事项不会有太多的限制，从管理复杂度上就下降很多。
  • 这么多年来unity使用起来的最佳实践，各种周边检测工具，性能分析工具，堆内存查找工具，lua也有，但是也经过3-4年的迭代逐步完善的。
  • 官方的插件和store上的付费插件、github上的各种开的插件都是基于C#开发。
  • C#静态语言自身的优势。
  • 易于调试，对应的性能分析工具、IDE等辅助工具完善。
  • 原生语言是C#，所以Unity的一些设计和使用上都是朝招利用C#的特点编写的，组件化，基于C#的各种功能性API，接口，但第三方语言要加很多的wrap或者Import操作，大量的组件和API需要重新写重新设计，这种复杂度的增加是指数级别的增长而非线性。这种维护上的痛苦，经过脚本语言热更洗礼的开发者都深有感触。
  • 新版和老本热更较其他热更方式更优，例如:比如1.0更新到2.0，基于HybridCLR会出两种情况，第一种是从服务器更新代码执行2.0逻辑。第二种是执行随包进入的2.0代码，第二种使用native代码直接运行，性能更好，但是Lua/purets/ILRuntime 2.0版本都是解释执行，也就是无法享受到native代码直接运行这种优势。
    注：游戏的研发周期一般只占整个产品生命周期的20%左右，复杂度直接影响到开发的时长、bug率、人员的分配等情况，所以降低维护的复杂度是开发中非常重要的环节。

适用平台

HybridCLR是一个特性完整、零成本、高性能、低内存的近乎完美的Unity全平台原生c#热更方案。

社区情况

InjectFix 没有群（github已经近2年没有更新了）出现日期：2019.9.5
ILRuntime QQ群1955 人 出现日期：2016.424
Lua 500人微信群 3个
PureTS QQ群1657人 discord 125人 出现日期：2020.8.15
HybridCLR 一共4个QQ群，其中2个3000人 一个642人 336的互助群 更名Hybrid后出现日期：2022.4.9（实际发布时间点比这个要久）

  • 短短一年时间聚集7000人的社区可见一斑，在UWA中也为HybridCLR做过宣传，点击进入
  • 用户群体大，这样意味着权威性（在方案调研时胜出），也意味着稳定（用户基数决定了样本数）

生态环境

  • 因为C#是Unity原生语言，其含有大量的优秀解决方案（行为树、资源检测、性能检测工具等官方和第三的各种插件，以及配套的工作流和最佳实践），这无疑极大缩短开发周期和避免重复造轮子的的事情，在速度和开发质量上的帮助极大。
  • 因为用户基数大，所以在遇到一些问题的时候更容易查找。例如：网上、技术群、社区和其他公司的前同（圈子太小）
  • 基于第二条，如果我们再做新的方向或者预研的时候，有很大几率会得到一个可行的方案，有效降低试错成本。而且很多解决方案都是严重依赖C#或者Unity严格绑定的，如果不够了解C#和Unity的一些独有特性在后续学习参考上都会造成很大的阻力，无疑也会拖慢开发节奏和选择上的范围。
  • Unity在2017版本之后已经不再支持JavaScript脚本语言,这也能侧面证明这种动态语言不在适合Unity后续技术的发展趋势，这种从设计、性能、趋势、维护、扩展性的考量相信一定会比此篇报告要深入的多。详情请见：点击进入

注：如果以做flash游戏的程序员用Unity开发，从个人角度来看，一定是Unity的操作几乎和flash一致才是最好的，但是从项目使用Unity引擎的特性长远来看，一定是按照Unity的工作流来进行开发才是最合理的。
出现这种情况一般是在长期内无法招到对应的从业人员，所以只能从相同的行业不同方向的来进行招聘，不得已而为之，当初16-17年腾讯就是以这种方式从Unity招聘大量的人员转UE，内部也出过一本类似《快速从Unity3D转UE指导蓝皮书》的指导文档，指导Unity开发人员快速转变为UE开发工作流。

为Unity开发者准备的虚幻引擎4指南
Unity3D开发者快速上手Unreal Engine 4指南

所以这种做法是不得已而为之，是没有其他任何解决方式或者选择的妥协结果，并不是最优，而是唯一解，所以也承担了相当多的额外的代价。

人员可选性

  • 招人的选择范围和质量
  • 候选人对我们的意愿（主流解决方案）
    白鹭引擎就是因为用户群体太少慢慢消失了

技术积累

  • 因为Hybrid是一个全平台且C#的热更，而且性能优于市面上所有的热更方案，所以有想要做一些对性能要求高、大体量项目的工作室，同样有一定的参考性。
  • 而且以C#方式进行的工作流，会逐渐让项目成员对Unity引擎的工作方式更加熟悉。
    注：如果是一个只适合轻量并且比较老的非主流技术方案，虽然有一定的技术积累，但它的受众也不是很多或者没有。

商业合作公司

  • 腾讯
  • 网易 明确
  • funplus 明确
  • 字节
  • 百度 明确
  • 完美
  • 巨人
  • 叠纸
  • 游族 明确
  • 智明星通
  • Bilibili
  • IGG
  • 散爆网络
  • 上海紫龙
  • 乙亥互娱
  • 英雄互娱

发展趋势

  • slua – tolua – ILRuntime – xlua – InjectFix/PureTS – HybridCLR
    热更的趋势也是朝着原生C#语言的方式发展，越来越接近

结语

所有的工具以及产物最后都是为人服务，所以不管使用何种语言何种技术，最后的目的就是让我们开发更顺畅，更简单、更好高效。

阅读量： 621

发表评论