ios

好像只有在亞洲地區才流行這樣的組合，也就是從 native app 畫面開 web view 切到行銷活動網頁，再透過 javascript 方式跟 app 互動之後回到 app 裡進行後面的導頁與串行銷資料。 同步切換 app 畫面標題 為了要讓 webView 載入的網頁標題也能貼回到 App 裡的 navigation bar 上，所以在 viewDidLoad() 的時候，加上 addObserver： webView.addObserver(self, forKeyPath: #keyPath(WKWebView.title), options: .new, context: nil) 為了避免 leak，若有開啟 addObserver 更新 title 的話，在 ViewController dismiss 時要移除掉： webView.removeObserver(self, forKeyPath: "title") 顯示與取消 Loading 對應到 WKNavigationDelegate 可以透過下方兩個 methods 顯示或取消自訂的 loading view： func webView(_ webView: WKWebView, didStartProvisionalNavigation navigation: WKNavigation!) { guard isBeingDismissed || isMovingFromParent else { // present loading view return } } func webView(_ webView: WKWebView, didFinish navigation: WKNavigation!...

我們的專案已經有 816 snapshot tests 並且有 600 張 snapshots，對專案的 coverage 約 47%，對產品的品質信心算是滿足夠的。 常被抱怨的點是在 CI 上跑 unit test 的時間太久，以專案 800 多個 snapshot tests 來說需要花上 15 mins 才能跑完，有時候開的 PR 一多幾乎都是在等待 unit test 跑結束，反而有點浪費在等待，目前只能採取折衷的作法，在特定的 branch 才啟動 unit test。 另外遇到的問題是不同機器配上對應的模擬器有時候會發生圖片”看起來”是一樣內容，但檔案大小卻差了幾個 bytes，所以程式比對圖片就直接認定 assert failed。原因是畫面在截取的當下可能仍會因為動畫等視覺效果，而造成產生的 snapshot 有些微色彩的差異。 這類問題的解法目前是走 duplicate image detection 的做法，也就是算出 snapshot 對應的 hash 值，然後將兩張圖片的 hash 根據 Hamming distance 來評估是不是一樣的圖片。 本來是在這邊 GitHub – benhoyt/dhash 看到這個，查了一下大概就是這幾種 hash 方法的比較，來源是 GitHub – ameingast/cocoaimagehashing 這裡： Name Performance Quality aHash good bad dHash excellent good pHash bad excellent 其實滿推崇 pHash 的方法，看 別人分享 iOS 上測試的過程 具有很多優勢；但因為 dHash 實作上相對容易，也滿多實作的作品可以參考。自己參考的實作是這兩篇：...