iT邦幫忙

2021 iThome 鐵人賽

DAY 15
0
Mobile Development

我的怨念齊天高 之「為什麼我的專案死掉了!」系列 第 15

You can't always get what you want

其實今天是想延續昨天繼續討論「每個專案的程式碼都該這樣開始」,為什麼會變成這個標題?

因為我寫的每篇其實都是怨念文,而我喜歡這首歌,又發現它也很切題。

思考「專案為什麼死掉」是一件「可以用各種不同方式描述、但最終會發現其實都是在描述同一件事」的事情。(好饒舌啊!)

為什麼會有專案?就是集合眾人之力、用管理的方式集合眾人的專長,一起合力(但不用合心)完成一件本來眾人個別單獨時絕對做不到的事情。
最後這個「眾人個別單獨時絕對做不到的事情」不一定要是「專案最初成立時所訂立的計畫」,可能是計劃中途修正了,可能是計劃中途的額外計畫,,也可能是必須要從計劃失敗的殘骸中挖掘出來的東西。
如果注意力完全只注意在原本的計畫任務上,因此錯失了其他的可能性,就算專案任務成功也可能只是「結案、收錢」,如果專案任務失敗真的就只是失敗,除此以外毫無意義。

就連「每個專案的程式碼都該這樣開始」都是從失敗的專案中累積的經驗,「如果一開始就知道這樣做,或許專案在施作進度掌握上就不會失敗了。」

所以...
順利的、華麗的完成專案任務、然後從這個成功中發覺整個專案的最大價值,誰不想呢?
但...「You can't always get what you want」...

就這樣結束這篇文?好像怪怪的...對了,繼續把「每個專案的程式碼都該這樣開始」講完。

3.專案無大小,沒有簡單的專案,但也預設所有的專案都應該很簡單。
像昨天提到的「實作一套更新畫面的機制」,那其實是個陷阱題。
這樣的機制是不可能直接用昨天描述的方式運作的,因為它會造成Leaking,——被UiJob指定為工作內容的View有可能並不會因為它所屬的Activity/Fragment被回收了就跟著被回收。

例如開啟了一個連線工作,並且在連線啟動時指定了「連線收到回傳時要用什麼樣的UiJob去完成工作」。但連線可能中途被轉為在背景執行,當下啟動連線的Activity/Fragment也必須關閉、所有的UiJob都失去了執行的必要與價值了!
但UiJob可能會持續待在「等待執行的佇列」中,即使將佇列清除、即使將UiJob回收了,裡面的View卻有可能依舊待在記憶體中.......UiJob原本要處理的就有可能會變成一個回收機制無法處理的垃圾資料。

要怎麼修正、或怎麼補完?
簡單說,這個UiJob機制需要搭配Activity/Fragment也有隨著自己的生命週期去清除UiJob佇列的功用。

怎麼做?
直接去擴充Activity產生一個具有這個功能的父類別?
註冊一個Activity的生命週期監聽機制?
不管是哪個,複雜度都會瞬間超越原本的規劃,但又可以讓整個專案變簡單。


上一篇
每個專案的程式碼都該這樣開始
下一篇
關於除錯這件事
系列文
我的怨念齊天高 之「為什麼我的專案死掉了!」20

尚未有邦友留言

立即登入留言