Re: [問題] 有沒有人碰過所謂的靈異現象(multi-dex)

看板java作者 (吹笛牧童)時間7年前 (2016/06/23 00:38), 7年前編輯推噓2(2027)
留言29則, 7人參與, 最新討論串1/1
來談另一個靈異現象,已經有點頭緒 但板上我沒找到資料 ------------------------------- 前不久敝公司要我 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://www.ptt.cc/bbs/java/M.1466613495.A.1DA.html ※ 編輯: HuangJC (42.72.182.75), 06/23/2016 00:43:29

06/23 01:21, , 1F
標題要加強啊。不要再靈異來靈異去了....這真的是限制啊
06/23 01:21, 1F

06/23 07:33, , 2F
這哪邊靈異了,就限制和bug啊
06/23 07:33, 2F

06/23 07:36, , 3F
Support library偶爾就會有奇怪bug,不然怎麼會需要改版..
06/23 07:36, 3F

06/23 07:37, , 4F
然後multidex的問題,可以看一下這篇
06/23 07:37, 4F


06/23 10:33, , 6F
沒寫android 不過學到新知識了 大推~~~
06/23 10:33, 6F

06/23 11:08, , 7F
要分清楚abnormal(異常)和paranormal(靈異),原則上在螢幕
06/23 11:08, 7F

06/23 11:08, , 8F
沒有貞子爬出來以前都算前者
06/23 11:08, 8F

06/23 11:11, , 9F
@NullLife 如果有寫或接觸到 code generator 應該也會遇到
06/23 11:11, 9F

06/23 11:11, , 10F
在非 andoird 但有寫 java web 的人。應該是以超巨大的 jsp
06/23 11:11, 10F

06/23 11:11, , 11F
會撞到這個問題。
06/23 11:11, 11F

06/23 11:38, , 12F
這不是java的極限, 看來是android某個版本前的限制
06/23 11:38, 12F

06/25 16:31, , 13F
這東西不是proguard就好了?
06/25 16:31, 13F

06/26 23:31, , 14F
proguard 是可以減少 method counts 沒錯,我們出貨版有
06/26 23:31, 14F

06/26 23:32, , 15F
做。但開發時可能需要步進執行,我就不知道 Eclipse 能不
06/26 23:32, 15F

06/26 23:33, , 16F
能加入這步驟了(就算能,很耗時間也會想打人吧..)
06/26 23:33, 16F

06/26 23:33, , 17F
另一個方法是把測好的模組移除,用這方法開發...
06/26 23:33, 17F

06/26 23:33, , 18F
好吧,主管不肯(主管就是權力最大,年紀最大,最趕不上
06/26 23:33, 18F

06/26 23:34, , 19F
潮流的人,嗯),我只不過說我把 code 擺上去,他如果跑不
06/26 23:34, 19F

06/26 23:34, , 20F
動,只要手動刪掉就可以執行,他就會罵說:你才應該在你
06/26 23:34, 20F

06/26 23:35, , 21F
的電腦裡保留,現在擺上去的版本先刪掉
06/26 23:35, 21F

06/26 23:35, , 22F
那這樣暫時出一版給QA測的 beta 就永遠不會有新模組啊...
06/26 23:35, 22F

06/26 23:36, , 23F
好啦,老主管拖慢進度的事時有所聞,將來我也會老...
06/26 23:36, 23F

06/26 23:36, , 24F
我不想把問題全歸疚在學不會新把戲的主管身上..
06/26 23:36, 24F

06/26 23:36, , 25F
(現在全部門都改用 Android Studio 了,主管還在用
06/26 23:36, 25F

06/26 23:37, , 26F
Eclipse,他說有遠比升級 Compiler 更重要的事)
06/26 23:37, 26F

06/26 23:37, , 27F
他掌握的是演算法,親自 implement,我們只是會用新工具..
06/26 23:37, 27F

06/26 23:37, , 28F
說真的,他才是核心,我們還比較像免洗;隨時一個剛畢業
06/26 23:37, 28F

06/26 23:38, , 29F
的大學生能取代的是我們,不是他..
06/26 23:38, 29F
文章代碼(AID): #1NQhxt7Q (java)