robovm support a function which is called tree-shak, it can get rid of classes and methods which are never invoked in the app, this function can make app size as smaller as possible, can moe support such function?
Thanks very much.
Specifies the tree shaking algorithm to be used by the compiler. With tree shaking enabled the compiler will strip out unused methods and constructors, reducing executable file size and reducing compile and link times. The supported modes are:
none - Disables tree shaking.
conservative - Only allows unused methods and constructors explicitly marked with the @WeaklyLinked annotation, either on the method/constructor or class level, to be stripped. This is the default.
aggressive - Strips out all methods which aren’t reachable from the main class. In this mode all methods are implicitly @WeaklyLinked and stripped if not referenced unless explicitly annotated with @StronglyLinked on the method or class level. Constructors are implicitly @StronglyLinked and preserved unless explicitly annotated with @WeaklyLinked on the method or class level.
Common for any mode is that static initializers are always preserved. Also, methods and constructors in the main class and in force linked classes will never be stripped.
Edit: Kristóf was faster, but since I already typed this in, here you go…
Hi,
In MOE we use ProGuard for the same purpose. We chose ProGuard because it is not a custom “vendor lock-in” type solution: it is used on the desktop and in Android as well.
Starting with MOE 2.x we will use Jack from Android for compiling, and it also has integrated ProGuard support.
We already have a patch in our version of ProGuard / Jack that makes it more efficient when stripping unneeded Nat/J *Ptr classes.
We looked briefly at the tree-shaking algorithm of RoboVM, but it does not seem to be very different from the one used by ProGuard. If there is a specific place, where RoboVM’s solution is more efficient in stripping classes, please let us know, because we would be interested in implementing it in ProGuard / Jack.
Currently the MOE runtime is larger than RoboVMs’, mostly due to the fact that ART is larger than RoboVM.
ART includes a lot of stuff, e.g. the debugger, that is not included in RoboVM. We plan to reduce MOE’s size by removing parts of ART that are not required in production builds.
