来谈另一个灵异现象，已经有点头绪 但板上我没找到资料 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 前不久敝公司要我 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 的讨论.. --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 42.72.182.75 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/java/M.1466613495.A.1DA.html ※ 编辑: HuangJC (42.72.182.75), 06/23/2016 00:43:29