灰色後門

Android 在 4.0 以後規定有網路連線的程式必須寫在另外的Thread，主Thread 負責處理與UI相關的部分 Android裡的 AsyncTask 是符合這個需求比較好的解法，他本身實作了 Java 的 concurrent 套件 所以透過它可以省掉一些實作上的細節 只是App中最常碰到的 Exception 大多是網路連線引發的 一旦沒有處理到 Exception 就很容易導致 App crash App 本身的 Exception 處理不像 Java Web 那樣有 filter、error page 等機制 參考討論後大概是以下方式比較好處理 Multi-Thread 引發的 Exception

純粹看到這方面的討論，所以寫一下個人心得 有經驗的開發者大概都已經有一定的體會 在我剛入門的時候滿願意嘗試各種 Library 有別人造好的輪子，那幹嘛再自己打造一個呢？ 而且別人已經實現的功能看起來很強大、很好用，玩起來也很有趣 只是開源 Library當然不完全是這麼方便，使用前可以考慮以下理由 1.使用的語言及版本 你要引入的函式庫可能會使用其他語言或是不同的版本 需要承擔與當前的dependency衝突或造成日後版本升級的dependency衝突問題 2.需求不完全一致 你所需要的可能只是開源函式庫的一部分功能 但是他設計的API可能為因應廣泛的功能開發而需要更多的輸入 所以你可能會需要提供原本根本不用產生的資料 3.肥大 很多強大的框架、函式庫伴隨而來的是他的體積或是對資源的佔用 如果你開發的是與網路狀況關係更密切的應用，那麼更該盡量縮減應用的大小 4.維護與資安問題 日後你可能會因為效能、bug、配合其他功能所需的dependency等理由升級 這些也是採用上隱含的成本 這概念跟使用商用軟體或開源軟體的議題雷同 雖然開源軟體是很好的概念，也沒什麼帳面費用，但它隱含的成本可能不少於商用軟體 很多時候如果碰上bug，你可能得幫忙回報、修改才得以克服 當然這也開源軟體能持續進步的精神 商用軟體就是把上述的問題丟給開發公司負責，由他們提出解決方案 所以沒有哪邊一定比較好，重點還是開發時的各種考量 另外資安問題也是得重視的問題 left-pad事件 也是頻傳的狀況 業餘時間開發的維護者不爽無法從採用的大公司分到收益時有所聞 當你發現重要的產品壞掉竟然是採用的open source層層倚賴的如此簡單的功能出問題 想必也是無言吧 Log4Shell漏洞也是源自於圖方便的極少數需求而來的 簡單講考量須回歸SOLID原則 你採用的方案是否會造成高耦合，難以抽換或引入困難的變更成本

話說我在之前想過 "考完這次JLPT後，我就要回來寫Blog了" 嗯...有些 Flag 還是不要亂立的好 Orz 這一天是我這個行程中在日本的最後一天 出發前還在猶豫要跑京都內部的景點、或者是跑到海津大崎賞櫻 這個時間點除了洛北的部分地點外，櫻花的花況也差不多要進入尾聲了 前一天晚上在爬花況文的時候看到有人推薦海津大崎，查了一下還滿心動的 這個行程通常會安排騎自行車遊琵琶湖畔賞櫻，以及參觀日本名城之一的彥根城 不過因為從京都出發的話要比較早啟程才有充足的時間 考量到這一天晚上還要搭HARUKA回關西機場 時間的安排上沒那麼有把握之下，還是選擇以京都市內的景點優先 退房後先前往京都車站放行李 京都車站有不少角落提供置物櫃寄放行李，時間最長可以放一天 所以可以玩一天後再回車站取行李後離開，對觀光客來說非常友善 這一天第一個來到的地點是清水寺