來談另一個靈異現象，已經有點頭緒
但板上我沒找到資料
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
前不久敝公司要我 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 的討論..