Question about Original wasm size behavior with Strip Automatically After Build

Unity Engine
, , ,
1

I’d like to ask if this is expected behavior.
If not, could you provide some directions for troubleshooting?

  • Unity: 6000.2.5f1
  • Web Stripping Tool: 1.1.1 (same issue also occurs on 1.2.0)

Both scenarios use the same Build Profile.
The only difference is whether Strip Automatically After Build is enabled.

  • Strip Automatically After Build (Off)
    Original wasm size: 5.2 MB

01
01344×363 20.5 KB

  • Strip Automatically After Build (On)
    Original wasm size: 7.0 MB

02
02611×500 38.3 KB

I’m not sure why the Original wasm size shows such a difference between the two cases.

2

Hi. Sorry about the confusion here: the difference comes from that if Strip Automatically After Build is on, we enable debug symbols as they are required for submodule stripping, but in the UI we show your build settings, not what necessarily what were the effective build settings.

3

Thanks, I understand now!
I really like this package — it gives Unity much more leverage to compete with Cocos in terms of web build size.

4

Great to hear! Please feel free to post any other feedback or questions you might have regarding the package on this forum.

5

@Ali-Unity3D As you are inviting feedback, would you be able to share some insights on your roadmap for the tool?

How much is there still room for lowering the build size vs how much is it in the hands of other teams removing dependencies in their packages (e.g, stripping completely UnityUI when only UITK is used in URP) ?

Love the tool! Just wondering if we can expect even more drastic improvements in the future.

Thanks!

6

After the submodules we made for 1.2.0, I don’t think we have any major ones in sight currently, we will be keeping an eye on the new features Unity gains and creating submodules for those, if deemed useful. I think the next major milestone for us would be to add support for user-defined C# submodules, users could profile their own code and create their own submodules that would be optimal for their project. But this is something we have simply discussed, it’s not on our immediate roadmap yet.