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