產品若已經穩定，就可有空閒時間來優化它！Google旗下的Firebase Performance，就成了我們嘗試的目標。
其實早在我進公司第一週，我在把玩公司App時，就發現載入卡片這個產品好慢，實際去追程式碼，發現下載資源檔進行了兩次一模一樣的API呼叫，當時就有跟老闆反應。現在終於可讓上萬人一起來累計數據，再拿給老闆看更有說服力，到時候著手優化此過程，我要來邀功囉～🤡
原本專案就已經有整合Firebase Crashlytics，於是就如此簡單就加入Firebase Performance，執行某行程回傳數據，約莫一天的等待後，數據真的就出現在Firebase後台，真是令人振奮！
2020年5月開始，Apple已強制只要有第三方登入的App，一定要加上Apple Sign In (蘋果登錄)功能。🤪
也就是說，Apple也想要角逐第三方登入。先前我已寫文章觀察其他App，參考：Apple 強迫整合 Sign In With Apple。
上週有嘗試過PHAsset的modificationDate和MD5的Image Hash，來判斷兩影像是否一樣，不過這兩個值不太可靠，因為會有其他因素讓兩個值改變⋯⋯
於是乎，就必須找其他方法替代！這次找到檔案大小，透過PHAssetResource的fileSize，是可以當作影像是否有被修改的指標。為什麼呢？因為影像一旦被處理過，就會再次存檔，此時檔案大小會不一樣～儘管此數值可能會一模一樣，不過機率實在太低，99.999%不會同數值。😎
（繼續閱讀…）前一個版本實作判斷相片是否被修改，是拿相片最後修改時間來比較，不過卻發生異常狀況，使得就算用戶沒有修改過相片，還是會跑到有修改過相片的流程，這讓我們家負責客服的同事哀嚎了一下⋯⋯大概讓我們損失好幾萬美元的營收。😳
透過PHAsset拿到相片資料中的modificationDate，也就是相片的最後修改時間，照理說應是沒有問題才是⋯⋯
RGB各通道的灰階影像。
記得在偉大的港商上班時，我們有三個iOS開發者，共同開發維護一個產品。此產品歷經1.5年開發，最後沒有上線，產品還直接被停掉。
當時我們每隔一週就要發布一個測試版本，後來主管指示此過程要全面自動化，於是我們帶頭的同事捲起袖子，把Jenkins 與 Gitlab串接起來，成為幾乎自動化的發佈過程！🤠
此圖是我統整所有過程，寫出來的四大部分和五大行為。未來可給大家參考用囉！
香港的同事負責送審，他會指定發佈到「獅子山」這個國家，我還以為他在開玩笑，查詢之後真有這個國家呢！😛
為什麼還沒開發完就要送審？因為我們要確保臨時要上架是沒有問題的！所以送審的頻率一個禮拜一次，而且都只上架到獅子山。
在港商上班最大的收穫之一，是跟香港同事合作，並見識到同年紀的香港CEO和CTO如何處理部屬～😏
技術上的精進比較沒太多可以著墨，因為是產品開發元老的架構為基礎往上開發，離開公司後那些複雜的流程不怎麼好用啦⋯⋯
總之，我還是認為，一個人就能開發App，是最過癮且最有成就感的事啦！💪
多虧Firebase Crashlytics的幫助，讓我曉得用戶發生哪些崩潰，在後台記錄得非常詳細，可以清楚讓我知道哪一個Class中的哪一行Code是崩潰關鍵！
可看到最近一週，有10次崩潰，影響10個用戶。
IDFA 全稱為Identity for Advertisers，即廣告標識符。用來標記用戶，目前最廣泛的用途是用於投放廣告、個性化推薦等。
關於IDFA在iOS的重要性，可以見我先前文章：IDFA、IDFV、UUID。
（繼續閱讀…）看標題還不知道要做什麼，那麼就直接來寫程式！
其實一張圖多顏色 (One Image Multi Color)，就是想要只提供一張圖片，就能呈現多樣顏色，這有什麼好處？就不用設計師出許多不同顏色的圖囉！
又到了一年一度更新推播憑證的時候！因為先前僅有初次產出推播憑證經驗，但沒有更新推播憑證的經驗，以為會有多難，沒想到就跟初次一樣的步驟。🧐
發現舊有的憑證無法更新期限，那麼就如同第一次建立新的推播憑證吧！此次推播憑證更新：2020/10/05，期限：2021/11/04，有效期間為13個月。
又到了必須適配App至最新的iOS 14，iOS SDK每年都有一定程度的大躍進，Apple有意無意讓開發者要不斷往前進，若不與時俱進者，則很快就會被淘汰囉～今年最大的適配項目是隱私權。
對於我們家快樂印App來說，這次更新最主要的項目在於相片權限 (Photos Authorization)。乍聽之下沒什麼，不過流程就必須要適當調整，讓用戶能知道相片為何無法被我們App存取。
HappyMan・迴響