Open tryBetter opened 8 years ago
是不是开了Proguard?
@junyuecao 打包的时候有用到混淆,但是平时编译运行也很慢,debug下的proguard是没开的。
开了multi dex吗
@razerdp 是的,因为65K了。
←←,想想瘦身吧。。。。我们之前也是65K,multi dex没个2,3分钟都不行,然后一咬牙,大量瘦身。。。无用的getter/setter都去了(去了4K methods我去。。。)【虽然不太建议←←,但是去掉了各种json解析出来的只是为了展示用的getter/setter,发现少了好多】
这里有一个参考文章: https://getpocket.com/a/read/1169468146 关于库的,文章提到了这个: https://github.com/openproject/LessCode 感觉还不错,不过这得看你们取舍。
@razerdp 去了4K·····佩服佩服。这个工作量有点多呀。
@tryBetter 我们整个组的,因为以前用gson插件的时候太方便,,,,导致无用的getter/setter过多,然后65K就蒙逼了,开发速度下降了好多。现在gson支持不生成getter/setter,全用public(除了个别),还是那个味哈哈
65k真心坑,加个v4,10k就用掉了~~
http://tools.android.com/recent/androidstudio20preview8available 这里解释了gradle 2.x 编译缓慢的原因, 2.0.0-alpha8 会在gradle所分配的内存不足时进行提示.
http://tools.android.com/recent/androidstudio20preview9available as 2.0 pre9 关闭了 in-memory dexing
另外instant run也能节约大量时间
2016-02-01 23:27 GMT+08:00 ipcjs notifications@github.com:
65k真心坑,加个v4,10k就用掉了~~
— Reply to this email directly or view it on GitHub https://github.com/android-cn/android-discuss/issues/370#issuecomment-178020029 .
@razerdp google 官方好像也说 不需要getter/setter,直接public 取合适
针对65k的问题,推荐一个网站,统计apk方法数的,将apk直接拖进去就能看到数据 http://inloop.github.io/apk-method-count/
@gaoneng102 很不错的分析工具,谢谢分享。
@gaoneng102 @tryBetter 统计apk方法数 还有个as插件,https://github.com/KeepSafe/dexcount-gradle-plugin 一个命令行https://github.com/mihaip/dex-method-counts
开Instant Run吧。
谢谢楼上各位的工具,学习了。
@chendd Avoid Internal Getters/Setters In native languages like C++ it's common practice to use getters (i = getCount()) instead of accessing the field directly (i = mCount). This is an excellent habit for C++ and is often practiced in other object oriented languages like C# and Java, because the compiler can usually inline the access, and if you need to restrict or debug field access you can add the code at any time.
However, this is a bad idea on Android. Virtual method calls are expensive, much more so than instance field lookups. It's reasonable to follow common object-oriented programming practices and have getters and setters in the public interface, but within a class you should always access fields directly.
Without a JIT, direct field access is about 3x faster than invoking a trivial getter. With the JIT (where direct field access is as cheap as accessing a local), direct field access is about 7x faster than invoking a trivial getter.
Note that if you're using ProGuard, you can have the best of both worlds because ProGuard can inline accessors for you.
@lizhenghlh 意思是在Class内部推荐直接访问field?而不使用getter/setter方法?
加速gradle构建可以参考我这篇博客:http://blog.csdn.net/maosidiaoxian/article/details/49583215 统计构建过程各任务时间:https://github.com/eleventigers/gradle-build-timer-plugin 统计各包方法数:https://github.com/KeepSafe/dexcount-gradle-plugin
尽量避免multidex,尽量避免SNAPSHOT版本的库。 65535的优化可以先用上面的插件查看哪些包使用了较多的方法数,比如guava(这玩意儿真不适合在android中)就会占用13000+的方法。尽量使用专为android开发而不是为j2ee开发的库,比如使用square的。
告诉一个我的经验,很多人都没讲到。 尽量保证你的project不要依赖其它module,如果需要依赖module,可以将这个module打包成aar或者jar,这样处理之后你的编译会很快,clean、run基本上都是一分钟内搞定,并且启动AS速度也很快。
对于这种现象,我的理解是:如果你依赖了其它module,则构建的时候每个module都需要编译,所以时间才那么长。
试试这个:
android {
dexOptions {
incremental true
javaMaxHeapSize "4g"
}
}
我是参考的这篇博客:http://www.jianshu.com/p/8014f1443d34 使用的Instant run
Freeline
尽量保证你的project不要依赖其它module,如果需要依赖module,可以将这个module打包成aar或者jar
这个必须要做, 另外可以屏蔽掉一些无用的task,参考这里: 加速 gradle 编译之屏蔽部分 Task
是不是Module越多,打包越慢?
是不是Module越多,打包越慢?
这是必然, module越多,task越多,可以查看gradle console看看, 或者右侧 Gradle-->app-->Tasks...看看你的tasks
话说回来,,,请直接上SSD。。。磁盘IO也是一个瓶颈。
@jp1017 我想知道每个Task的执行时间,找出耗时的task,然后优化
https://github.com/eleventigers/gradle-build-timer-plugin @MyLifeMyTravel 试试这个, GitHub 一搜, 还是很多的 :smile:
freeline https://github.com/alibaba/freeline
每次做点小改动也要编译运行个三五分钟,打包更久······求优化的思路和分析方法。