Re: [问题] 有没有人碰过所谓的灵异现象(multi-dex)

楼主: HuangJC (吹笛牧童)   2016-06-23 00:38:08
来谈另一个灵异现象,已经有点头绪
但板上我没找到资料
-------------------------------
前不久敝公司要我 implement twitter 模组
由于在别的专案已经做过了
因此我算架轻就熟,搬 code 就好
可是 code 一搬过来就不会动了
逻辑上出了什么问题?不会吧..
至少,我新功能不会动,不要影响旧功能啊!
这个有错误讯息,还好
Unable to execute dex: method ID not in [0, 0xffff]: 65536
google 查下去有资料,而且还是中文的(感动~)
https://ingramchen.io/blog/2014/09/prevention-of-android-dex-64k-method-size-limit.html
http://tinyurl.com/hq9yc5t
简单说,程式写太大
不是逻辑问题,是触到 java 极限的问题
这个简称 64K Methods 的问题有文件,英文的 T^T
https://developer.android.com/studio/build/multidex.html?hl=zh-tw
勉强翻译后我给些结论
1. android 给了官方解法
5.0 版以前,要改程式,还要改 build machine
(这有点辛苦,但不是办不到)
2.但测试结果是:并没想像中的完整,还会有一堆 bug
这就是问题了
意思是我们改了架构,然后 QA 得面对更大的 loading 了
(RD自己初测 ok,也不代表所有程序都 ok)
3.还有一个 bug 是,程式太大后,加载程序会出问题
(说是只发生在安装程式后的第一次执行)
当加载超过五秒,就引起加载失败
解决方法是"不要用官方解法",自己控制加载
这有点像当年 exe 档过大后,开始发展 DLL
DLL 可以不要在一开始加载,但在使用到这个指令前,一定要加载完毕
如果 DLL 很多,何时加载才好?
可以由 OS 控制,也可以由程式手动控制(透过 LoadLibrary, FreeLib)
所以一开始只加载最小模组,马上启动程式,就不会有问题
但因为程式的启动进入点很多,可能由 user 启动,也可能用 service, notice
等等来启动,所以最小模组必需把每一个区块都顾到
这结论出来后,程式是稳了,但架构要大改了
手动加载根本是 AP 在扮演 OS 的角色!?
--------------------------
以上,虽然和程式逻辑无关
但一种语言或执行平台有其极限
只要电脑学久一点都见识过
我也见识过 dos 时代 640K 极限
后来开始 EMS/XMS, DPMS, 还养活了一个 QEMM 这样的软件
直到后来真正能使用 32条位址线的作业系统出现
都不知过几年了...
因为那一定要保护模式,所以 dos 下的软件相容性大有问题
大家开始由 dos 被强迫搬至 win os
也死了一大票无法跟上潮流的老工程师
以前的血泪历历在目啊...
所以我很紧张,马上打报告通知所有 RD
增加新功能已经不是第一要务
可以的话,由业务层面解决掉;我们要更多时间来缓冲这个问题...
这些不算程式逻辑,但毕竟还是有错误讯息
接下来,同事帮忙把程式转移至 Android Studio
可以 build, 可以执行
但有时突然会闪退;这就完全没有错误讯息了 Orz
--------------------------------
不卖关子,这个我们解掉了
原来是 Android Studio 改用 Gardle 来 build 程式
里面有些参数要填,会填到我们引用哪一版 support lib
我们用 23.0.1 版,而这在 Android 4.3 会有问题
改成 23.1.0 就好了
https://code.google.com/p/android/issues/detail?id=185457
这里有讨论
能解掉这个问题是不小心喵到,也算有错误讯息
(但我们自己写的 log 系统没记录它)
讯息是
06-14 16:30:16.551 3378-3378/module_name A/libc: Fatal signal 11 (SIGSEGV)
at 0x00000000 (code=1), thread 3378 (module_name)
以上,也算很灵异吧,但很仔细都可以找到讯息而找出答案
本来想在板上找答案的,没找到
后来还好网络上有
希望板上也多点 multi-dex 的讨论..
作者: qrtt1 (有些事,有时候。。。)   2016-06-23 01:21:00
标题要加强啊。不要再灵异来灵异去了....这真的是限制啊
作者: ssccg (23)   2016-06-23 07:33:00
这哪边灵异了,就限制和bug啊Support library偶尔就会有奇怪bug,不然怎么会需要改版..然后multidex的问题,可以看一下这篇http://www.cnblogs.com/yydcdut/p/4887157.html
作者: NullLife (废材大叔有点累)   2016-06-23 10:33:00
没写android 不过学到新知识了 大推~~~
作者: bitlife (BIT一生)   2016-06-23 11:08:00
要分清楚abnormal(异常)和paranormal(灵异),原则上在萤幕没有贞子爬出来以前都算前者
作者: qrtt1 (有些事,有时候。。。)   2016-06-23 11:11:00
@NullLife 如果有写或接触到 code generator 应该也会遇到在非 andoird 但有写 java web 的人。应该是以超巨大的 jsp会撞到这个问题。
作者: realmeat (真肉)   2016-06-23 11:38:00
这不是java的极限, 看来是android某个版本前的限制
作者: tbpfs (http://0rz.tw/Uk989)   2016-06-25 16:31:00
这东西不是proguard就好了?
楼主: HuangJC (吹笛牧童)   2016-06-26 23:31:00
proguard 是可以减少 method counts 没错,我们出货版有做。但开发时可能需要步进执行,我就不知道 Eclipse 能不能加入这步骤了(就算能,很耗时间也会想打人吧..)另一个方法是把测好的模组移除,用这方法开发...好吧,主管不肯(主管就是权力最大,年纪最大,最赶不上潮流的人,嗯),我只不过说我把 code 摆上去,他如果跑不动,只要手动删掉就可以执行,他就会骂说:你才应该在你的电脑里保留,现在摆上去的版本先删掉那这样暂时出一版给QA测的 beta 就永远不会有新模组啊...好啦,老主管拖慢进度的事时有所闻,将来我也会老...我不想把问题全归疚在学不会新把戏的主管身上..(现在全部门都改用 Android Studio 了,主管还在用Eclipse,他说有远比升级 Compiler 更重要的事)他掌握的是算法,亲自 implement,我们只是会用新工具..说真的,他才是核心,我们还比较像免洗;随时一个刚毕业的大学生能取代的是我们,不是他..

Links booklink

Contact Us: admin [ a t ] ucptt.com