【重要|官方调研】关于引擎私有变量的访问

Creator 3.x
#62

#私有变量最终在 babel 是用 WeakMap 实现的，需要考虑下性能问题，还有包体问题

https://babeljs.io/repl#?browsers=defaults%2C%20not%20ie%2011%2C%20not%20ie_mob%2011&build=&builtIns=false&corejs=3.21&spec=false&loose=false&code_lz=MYGwhgzhAECC0G8BQ1XQMRmgXmgRgG4kBfJJUSGWPRFNAfS10JKA&debug=false&forceAllTransforms=false&modules=false&shippedProposals=false&evaluate=false&fileSize=false&timeTravel=false&sourceType=module&lineWrap=true&presets=env%2Creact%2Cstage-2&prettier=false&targets=&version=7.26.2&externalPlugins=&assumptions={}

#63

所以这个方式估计行不通。
只有支持 ES 新标准的 JS 虚拟机才原生支持 #

#64

我觉得不应该加开关了，应该加一个白名单，如果出现问题，开发者自己把用到的私有变量加上白名单，这样，就能满足所有人的需求，而且不需要定期去加什么getter setter，直接把白名单里面的变量不进行压缩就好了

2赞
#66

+10086

#67

先点赞。

但是：

既然我们以 TypeScript 为主，不用考虑 JavaScript 的兼容性，尊重 private、protected、public 修饰符，能否抽时间看看有没有现成的方案或者自己写个以 private 属性而不是以 $ 结尾的属性为准进行压缩，实在是好丑好 Hack。

还希望再做个功能：给个选项，可以剔除未使用的类成员（可选引擎的还是项目的），这肯定比名称的提升还要大得多。

把前端现代化的工具链全部利用上。

#68

很多事情是无解的,我一直吐槽scrollview体验差,尤其在掉帧的情况下滑动体验太糟糕,从2反馈到3,但是官方觉得这个够用,或者需求级别太低,根本排不上需求去改,这种情况会存在大量的这类需求,为什么是魔改不是提pr,因为不是很好的解法,只是在原有的基础上调整一下满足特定场景下的需求,不是个通用解法,为什么不重构了,主要是看不懂,设计的有点太复杂,不是设计者看不懂这块的逻辑,无从下手,没有那么多时间去重构整个ui系统,所以只能退而求其次去选择hack的方式,不是说我一定要用hack的方式,是没有办法满足产品需求的情况下做出来的选择

2赞
#69

不知道有什么属性装饰器之类的能解决这个问题，不然确实有点丑，其它贡献代码的人也得谨记这种奇怪的规则了

#70

与其在这费劲地收集来收集去的，

如果纯粹是为了解决私有变量调用的问题（而不是收集哪些用例官方没有很好地支持），那为何不增加一个选项可以配置多个正则来排除某些名称不被压缩？

这个说实话感觉工作量也不大也不难啊，只是加个 filter 函数而已，而且所有人都能满意，还是一个把问题抛给用户的好方法。

因为既然他都访问私有变量这么 Geek 了，那会用这种高级用户的高级功能应该也是应该的。

我觉得引擎总是把一些东西封装地死死地，不如直接开放出来，真正在做优化的都不是菜鸟，不要这么不相信用户。

1赞
#71

当然如果通过这次事情,让引擎组注意到接口设计的时候面向开发者够用,而不仅仅是面向引擎组或者编辑器组够用,那也够了

#72

不需要属性装饰器，现在 3.8.5 这个功能是基于 terser 封装的，terser 用 AST 语法树进行分析处理的，全部在工具层解决，不需要业务层配合，JS 没有这些修饰符的数据，但 TS 是有这些 AST 的，所以对引擎组来说可能是需要造新轮子，但可以把活干得漂亮点。

#73

这个是有考虑过的。但并不是所有用 private 修饰的属性，都能够被压缩。比如用 @property, @type, @serialize 修饰的要序列化的私有属性，就不能进行属性压缩，否则存储就出问题了。用 $ 相对代价是最低的，而且是在变量结尾，也不影响代码提示功能。

还希望再做个功能：给个选项，可以剔除未使用的类成员（可选引擎的还是项目的），这肯定比名称的提升还要大得多。

这个是针对项目脚本吗？这种剔除类成员会影响类的定义（Shape/InlineClass），代码中应该尽量避免有不使用的属性才是。

把前端现代化的工具链全部利用上。

这个我并不特别赞同，用得东西越多，维护代价越大。我比较推崇 KISS 原则。

#74

记一个这么简单的规则，比去让你一个文件中配表舒服多了吧？

比如，新增表项、修改表项、删除表项，妥妥的更增加思想负担。

#75

是的，目前 terser 是作用在 rollup 插件最后一步，已经是 JS 了，丢失了 ts 的 modifer 信息了。

要在 ts 处理时候处理，需要编写 babel 插件进行处理。但是因为某些私有属性又有例外，还需要做额外的装饰器判断。

并不是说实现不了，只是代价、维护成本的问题。如果插件出问题，会有额外的排查问题的路径，把这个压缩属性的功能做的相对复杂。

#76

既然咱真有这功夫，那可以多写几行代码排除有装饰器的

CleanShot 2024-11-21 at 14.22.12@2x
CleanShot 2024-11-21 at 14.22.12@2x1962×884 60.7 KB

https://ts-ast-viewer.com/#code/MYGwhgzhAECC0G8BQ1XQA4CcCWA3MALgKbRgDcKalqAAgCYD2AdgdRjvsdAEYUC+QA

针对引擎和项目，确实会影响类定义，但没有副作用吧，类变得更少属性了，性能更好了。

我觉得太理想化了，这个问题不可能避免的，比如：

坐标转换，矩阵转换有一堆 A to B B to C 的工具函数之类的。

资源管理器，loadAny loadBundle loadRemote loadAudio loadText 我总有一个不用的。

可能有点误解我的意思了，我的意思是尽量利用，不自己造，好的、需要的东西，吸收进来。

#77

加一个白名单设置可以吗 让用户自行剔除hack过的属性保护不被压缩

#78

那得看有多少用户会为了缩小包体，把引擎的所有代码都过一遍，然后写一个能做到最优的 filter 函数 or 正则？
现在相当于是一刀切，好处是：引擎开启这个配置，就帮你把引擎代码体积最优处理了，对引擎代码不熟悉的大部分用户也能享受到这个优化。

#79

如果说 $，那么我觉得这是污染代码，我宁愿配表，让脏东西在一个文件里。

如果说是基于 private 的规则，我觉得都得有，规则既要简单，也要给个口子让我们配表做定制。

#80

不是，反了，我的意思是，默认情况下：帮你把引擎代码体积最优处理。

但我们会访问私有变量，我们这种用户就可以通过增加正则排除我们用的变量不被压缩啊。

#81

自然是这样，我也不喜欢没事自己造轮子显得B格有多高。但无奈的事情多了去了。历史因素，有的垒得很高的塔，垒的时候，垒的人是很爽的，山堆得很高了，山上满是轮子的时候，卸几个轮子看看？代价？
做加法容易，做减法难。

1赞
#82

可能是我有问题吧，但我觉得真不是一次两次了，最近大部分论坛的 “调研” 活动在我看来都非常的没有必要。

包括如何处理 position 的 set/get 行为，Dashboard 要不要自动升级，引擎的 Electron 版本升级了是否有兼容性问题，私有变量的访问的收集，原谅我大胆点说真是浪费时间、浪费精力。

我们是不屑于抄竞品还是咋的，用 Cocos 不会不用 VSCode 写代码吧？90% 的人在用 VSCode 应该不过分吧，跟着 VSCode 的 Electron 版本走不就行了。

Dashboard 该不该自动升级，U 就是自动升级的，这种相对引擎主要特性来讲无所谓的小事，直接按行业顶级产品的来不会有错吧。

代码的压缩和剔除这个事情，U 不也做得非常完善了？

https://docs.unity3d.com/cn/current/Manual/ManagedCodeStripping.html

  • 普通用户，你可以通过 Managed Stripping Level 从五个级别中选择优化级别就能做到很好的优化效果。

  • 高级用户，把等级拉满，通过 Preserve 属性或者 link.xml 配表保留属性来做更细致的优化。

1赞