概述

影像編碼的主要流程為「預測(prediction)」->「轉換(transformation)與量化(quantization)」->「熵編碼(entropy coding)」。

編碼器先用已知的資訊預測當前的影格，將當前影格分成預測的資訊跟剩餘(residual)的資訊。剩餘的圖像資訊經由轉換後，可以進行壓縮，將影響較小的資訊去除，達到大幅縮小資訊量的目的。最後，這些資訊會依據發生頻率進行編碼，在不影響內容的情況下，進一步壓低所需空間。

編碼器在轉換壓縮後，會像解碼器一樣，將壓縮的資料重新解壓縮成影格，用來當作新的已知資訊，預測下一個影格。這樣，就可以保持接收端解碼器的誤差不會越來越大，接收者可以看到一致的結果。

另外，H.264 編碼器是將影格切為巨集區塊(macroblock, MB)處理。巨集區塊大小最主要有 16 x 16 或 4 x 4，大的區塊應對大色塊，而小的區塊處理細節畫面。一搬進行方向是由左到右、由上而下，先處理好的區塊就可以視為新的已知資訊，可用來預測後處理的區塊。

預測

巨集區塊的資訊，通常會跟同一影格鄰近巨集區塊或前後影格的像素相關。此時巨集區塊的值就可以分解成以其它區塊預測的部分，加上預測誤差。預測的部分可以簡易描述要查找的區塊。而誤差的部分則可以在之後近一步壓縮。H.264 編碼器，有 2 種預測資訊的來源：

1. 跨影格預測(Inter prediction)

就是用較早解碼影格的像素資訊做預測。雖說是預測，但進行方式是相反的。用當前的巨集區塊的方框去之前解碼的影格移動比對，尋找預測誤差最小的方框，如圖所示。而到最佳預測方框所需移動的向量，就是位移補償。預測後，只要紀錄位移補償與誤差，可以減少紀錄重複的像素資訊。

注意較早解碼影格不一定代表影格本身時間的先後順序。巨集區塊的預測可用之前或是之後的影格，但一定是先解碼的已知資訊。因此，巨集區塊可區分為只用之前影格資訊的 P 巨集區塊 (P MB)，和兩個方向都可以的B巨集區塊 (B MB)。其中 B 巨集區塊壓縮效率較好，但也更複雜，由於影格需要重新排序，延遲也會延長。B 巨集區塊僅在主設定檔 (main profile) 提供。

2. 影格內預測(Intra prediction)

I 巨集區塊 (I MB)。限定用同一影格先前已編碼的巨集區塊進行預測，可能是左方巨集區塊預測，上方巨集區塊預測，或是這些巨集區塊的平均。如圖。

預測後，以哪些巨集區塊與何種平均方式預測，加上誤差，可以減少紀錄重複的像素資訊。

我們常見的I影格(I frame)、P影格(P frame)以及B影格(B frame)，與上述各種巨集區塊有以下關係：
I 影格，只會包含 I 巨集區塊。
P 影格，可包含 I 巨集區塊或 P 巨集區塊。
B 影格，上述巨集區塊皆可包含。

轉換與量化

巨集區塊經過預測後，留下剩餘的資訊 (residual MB)，也就是預測誤差需要處理。首先會經過離散餘弦轉換，得出的係數再藉由量化進行壓縮。編碼器也是在此階段控制量化量以達到目標位元率 (bitrate)。

離散餘弦轉換 (discrete cosine transform，DCT)

預測誤差相較於原始像素強度資訊，由於像素間的相關性大幅降低，較容易處理。此時對這些資訊進行離散餘弦轉換，係數矩陣會有由左上到右下遞減的特徵。離散餘弦轉換類似傅立葉轉換 (Fourier transform)，轉換後各頻率的係數會由左上（低頻），往右下（高頻）排列。通常左上的數值最大，接著會如同扇形等高線般向右下逐步減少。這種特徵適合鋸齒形 (zigzag) 的掃描方式，形成的實數一維陣列在接下來的量化後通常會帶有一長串可省略的 0。

量化

轉換後接著就是以量化減少資訊。量化是將這些實數數值改以有限的整數取代。會丟失小數或是餘數的資訊，因此才會減少資訊量。量化時使用的數值越少，損失越多。編碼器在操作的時候，則是使用量化參數 (quantization parameter, QP)，量化參數越大代表量化時每一階跨度越大，可視為使用的數值越少，損失越多。

如同前面所說，由其在高頻的部分，許多原本趨近於零的數量化後會呈現連續的 0。連續的 0 可以用運行長度編碼 (run-length encoding) 來進一步減少所需的空間。如果選擇量化量高，則丟失的資訊越多，壓縮率越高。編碼器在尋求滿足目標位元率時，會動態決定使用的量化參數來達成目標。

轉換與量化完成後，編碼器會將壓縮的資訊，先乘上量化量，再進行逆離散餘弦轉換 (inverse discrete cosine transform)，解壓縮還原成預測誤差。解壓縮的預測誤差，加上上一個步驟的預測資訊，就還原成解碼的影格。可以用來預測下一個要處理的巨集區塊。由於經過量化壓縮，解壓縮的預測誤差已經與壓縮前的預測誤差不同，也就是失真了。

熵編碼

影格經過處理後，產生的資訊也可以經過內容編碼再進一步縮減所需空間。其原則是發生頻率越高的內容用越短的碼字 (code word) 表示。H.264 支援 2 種編碼方式：

適應性可變長度編碼 (Context-based Adaptive Variable-Length Coding, CAVLC)

是一種可變長度編碼(variable length coding)。其對應碼字的推論是基於霍夫曼編碼(Huffman coding)。不過實際上 H.264 有提供現成的編碼表，大部分清況下編碼器只需參照編碼即可，並不以自己計算產生專屬的編碼表。此編碼方式較基礎，碼字的長度皆為整數，如果遇到某個值發生頻率高於50%的情況下，受限於碼字不能小於1的情況，壓縮效率較差，也沒有處理傳輸錯誤的情況。適應性可變長度編碼是基線設定檔 (baseline profile) 使用的熵編碼方式。

適應性二元算術編碼 (Context-based Adaptive Binary Arithmetic Coding, CBABC)

是以算術編碼(arithmetic coding)為基礎。此編碼計算方式較複雜，僅主設定檔提供支援，但能較適應性可變長度編碼更接近理論壓縮極限，壓縮效率較佳。

Apple VideoToolbox 的相關設定

檢視 Apple 的 VideoToolbox 裡面跟 H.264 相關的介面，VTCompressionProperties.h。我們可以尋找跟本文主題相關設定。

可選擇設定檔(profile)，從基線設定檔、主設定檔與高設定檔(high profile)。

VT_EXPORT const CFStringRef kVTCompressionPropertyKey_ProfileLevel;

VT_EXPORT const CFStringRef kVTProfileLevel_H264_Baseline_1_3;
VT_EXPORT const CFStringRef kVTProfileLevel_H264_Baseline_3_0;
...
VT_EXPORT const CFStringRef kVTProfileLevel_H264_ConstrainedHigh_AutoLevel;

像下面這是與設定是否使用 B 影格相關。

VT_EXPORT const CFStringRef kVTCompressionPropertyKey_AllowFrameReordering;

如同我們講到，編碼器量化參數不提供直接設定，而是設定平均位元率，交由編碼器決定。

VT_EXPORT const CFStringRef kVTCompressionPropertyKey_AverageBitRate;

支援本文所提的兩種熵編碼的方式。

VT_EXPORT const CFStringRef kVTCompressionPropertyKey_H264EntropyMode;

VT_EXPORT const CFStringRef kVTH264EntropyMode_CAVLC;
VT_EXPORT const CFStringRef kVTH264EntropyMode_CABAC;

文件在解釋適應性二元算術編碼時，提醒我們應選擇支援的設定檔，避免產生錯誤結果。然而，在具備了對編碼器的知識後，這種設定錯誤就不容易產生。

/**
...
Care should be taken when using this property -- changes may result in a configuration
  which is not compatible with a requested Profile and Level.  Results in this case are undefined,
  and could include encode errors or a non-compliant output stream.
*/

結語

經過「預測」->「轉換」->「熵編碼」的處理，影格資料基本上就完成編碼輸出了。解碼器將拿到的資訊進行逆向處理，就可以解碼還原成影格顯示了。解碼器只要依據指示進行逆運算，相較之下是較簡單，可在運算力較差的裝置執行。

對比之下，編碼器在各階段要依據使用者要求做出適合的組合，像是預測階段要選擇預測方式、搜尋範圍內適合預測的巨集區塊，轉換階段要選擇適合的量化參數，熵編碼也要選擇適合的編碼表，這樣的決策組合可多達上百種，也就需要更有力的機器。

我們在進行存擋影片或直播影片編碼參數調教時，可以藉由對編碼器較深入的認識，選擇適當的組合。例如直播時，可以關閉 B 預測模式縮短延遲。在接收端運算能力充足的情況下，可以選擇主設定檔以使用壓縮效率更好的適應性二元算術編碼等。另外我們也會知道當我們調低目標位元率時，編碼時會傾向用更高的量化參數，也就代表犧牲更多畫質，來達成目的。

參考資料
Richardson, Iain. E. G. The H.264 advance video compression standard: Wiley, 2010.

名詞翻譯參考
國家教育研究院—樂詞網

影片編碼流程探討—以H.264編碼為例 was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

不久之前，RD的夥伴們完成了一場精彩絕倫的分享！ 這次有四位同仁分享覺得有趣的主題，分別為：

• Lego CI/CD with github action
• The wet codebase
• Enlarge eyes by Apple face detection and Metal shader
• Smooth skin principle and implementation

快來看看這次的Presentations吧！

Enlarge eyes by Apple face detection and Metal shader

• Introduce Metal and compare to OpenGL ES
• Introduce Vision
• Enlarge eyes algorithm

Smooth skin principle and implementation

本篇介紹 GPUImage 中一個常用的美肌濾鏡，並深入解釋其中使用高斯模糊濾鏡的原因及原理。

• Overview of filter pipeline
• Box blur vs. Gaussian blur and how to implement with shader
• Why Gaussian blur is suitable for smooth skin (fourier transform, low-pass filter)
• Filter pipeline principle summary
• Direction to improve performance and combine with face detection

Lego CI/CD with Github Actions

Using features on Github (Github Action, Github App, Github Deployment) implement a GitOps flow which make application developer and DevOps engineer cowork with each other easier, and how this flow improve the development experience.

Presentations Day #1 was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

Harnessing filter_complex

FFmpeg’s filter_complex works in a similar fashion as Unix pipes. Take a input, modify, output, then rinse and repeat. A filtergraph contains one or more filterchains, each which contains a certain order of filters to be applied to the input source. Like Unix pipes, you can get pretty creative and generate some great results.

Splitting Outputs

First, we will split a single input into 2 outputs with scaled resolutions.

• 0:v: Select the first input source’s videostream only
• split=2: Split the stream into 2 and store them as 360pand 720p
• [360p]scale=-2:360[360p] and [720p]scale=-2:720[720p] scales the input to 360px and 720pxheight respectively while preserving aspect ratio and sends the output back to the same input name. The -2 is to tell the scaler to scale to a even number as some formats do not support a odd number of pixels
• -map "[360p]" 360p.mp4 and -map "[720p]" 720p.mp4 take each respective output and encodes it to a file.

The result will be 2 files with different resolutions. Keep in mind, all outputs created in the filtergraph must be connected to an output.

Blurring

The next component is to generate a blurred video. There are many blurring algorithms available, but for this task, we will be using boxblur. This blur has 3 tunable settings each with radius (box radius to apply to the frame) and power (how many times to apply to the frame):

• luma (luma_radius and luma_power): Brightness
• chroma (chroma_radius and chroma_power): Color
• alpha (alpha_radius and alpha_power): Transparency

Fading In

The last part we need is a fade. This is filter is fairly simple as it takes a start and a end with either a fade in or fade out. It supports both frames and time/duration. For our case, we will use the time/duration and skip calculating frames.

Peanut Butter Jelly Time

Now that we have all the tools we need, let’s put this all together. The plan is to put each of the filters above to create a Blur Out effect. A Blur Out is essentially 2 videos (the original and a blurred version) overlayed on top of each other with the one of the videos fading.

For this example, we will choose the original video as the baseand the blurred video as the fade in.

1. We will will need to split the input into 2, base and blurred, so we use the split filter
2. Next we need to generate a blurred version using boxblur
3. Taking the blurred input, we add a fade in start time 1s and duration 3s. The extra alpha=1 mentioned here is to allow the video to be transparent when faded out else the background color will be black
4. The final step is to use overlay to put input sources on top of each other (like an onion). The alpha=1 from above would then allow the base to show through the blurred layer as it is being faded in.

References

• FFmpeg Filtering Guide

Blur Out Videos with FFmpeg was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

此外，CNCF 基金會 目前已經將 Telepresence 加入計畫，可以對這個工具多一點的信心。

解決問題

• 如果 cluster 的 micro service 很多，不可能在本地端用 minikube 測試。
• 不需要等待 CI/CD 將程式碼推到 Cluster 才能看到結果
• 不需要額外設定 VPN(OpenVPN, Wireguard)，存取 Cluster 其他 Service
• 可以在程式內直接使用 Kubernetes Cluster 的 Service. ex. requests.get(‘client.elasticsearch:9200’)

Step by Step

Code: https://github.com/RammusXu/toolkit/tree/master/demo/k8s/telepresence

Install

brew cask install osxfuse

brew install datawire/blackbird/telepresence

先準備一個 telepresence 的 proxy pod(deployment+service)

以及一個簡單的 Flask

Run

kubectl apply -f telepresence.yaml

sudo telepresence --deployment telepresence-rammus --expose 5000:80 --namespace dev --run sh -c "FLASK_DEBUG=1 flask run"

`--deployment [deployment-name]` 將會置換掉 deployment

`--expose 5000:80` 將 localhost:5000 expose 到 kubernetes-pod:80

`--namespace [your-namespace]` 可以選擇要替換哪個 namespace 的 deployment。預設是 `default`

`--run` 啟用 server 的方式。ex. `npm start`, `flask run`, `rails server`。這邊帶入 FLASK_DEBUG=1 自動監控 app.py 程式碼變更時重啟 server，如果是別的語言，請自行替換，或是加入環境變數。

Advanced

如果需要限制 developer 的 RBAC，這裡有 minimal RABC role：https://www.telepresence.io/reference/connecting#running-telepresence-manually

如果想要用 docker 可以參考：https://www.telepresence.io/tutorials/docker

telepresence — swap-deployment hello-world — docker-run — rm -it -v $(pwd):/usr/src/app hello-dev

如果不希望 developer 的 pod 可以存取所有其他的 service/pod，可以參考：

• https://kubernetes.io/docs/concepts/services-networking/network-policies/
• https://github.com/ahmetb/kubernetes-network-policy-recipes

其他選擇

• skaffold
• Ksync

Reference

• https://www.reddit.com/r/kubernetes/comments/aapysv/whats_the_dev_workflow_with_k8s_on_the_local/
• https://www.bizety.com/2019/02/13/kubernetes-dev-tools-codeready-skaffold-draft-squash-telepresence-and-ksync/

本篇文章同步發表於 rammusxu.github.io

Telepresence: Rapid Deployment and Communicate with Remote Kubernetes Cluster in Local was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

Google I/O 2019 最讓 WEB 開發者注意的事情就是宣佈了 Flutter for web 第一個技術預覽版本，同時釋出 Flutter 1.5 版本。

Quick Review — 什麼是 Flutter ?

先來看看 Flutter 的官方網站對自己的形容：

“Flutter is Google’s portable UI toolkit for building beautiful, native applications for mobile, web, and desktop from a single codebase.”

Flutter 是一個由 Google 開發、開源及免費的跨平台行動應用程式框架，可以快速的開發 Android 及 iOS 原生使用者介面應用程式，而且可以相容於現有的專案，使用 Dart 為開發的程式語言。開發人員可以透過單一套程式碼，編譯後同時運行在 Android 及 iOS 等各平台，並且使用由 Flutter 自己的渲染引擎繪製圖層、widget，保持各平台 UI 的一致性，Flutter 也提供了許多元件、應用介面、快速成長的生態系及網路社群，可以快速的開發原生套件，提供使用者良好的體驗。Flutter 在 2019 年的重點是將 Flutter 擴展到行動應用平臺之外，如網頁、桌面及嵌入式的平台上。

Quick Review — 什麼是 Dart？

Dart 是 Google 開發的程式語言，於2011年10月份釋出，可以被用於 WEB、伺服器、行動端或 IoT 等領域的開發。更詳細 Flutter 為何選擇 Dart 為程式語言的說明可參考 Why did Flutter choose to use Dart 有更詳細的說明。

Quick Review — 什麼是 Flutter for web？

Flutter for web 是 Flutter 為實現代碼兼容 (code-compatible) 的一個實作，項目之前的名稱為 Hummingbird，透過基於現有的技術標準 HTML/CSS 及 JavaScript ，自己製作渲染引擎，Flutter for web 開發者可以將使用 Dart 編寫的 Flutter 程式編譯至客戶端體驗 (client experience) 並且嵌入瀏覽器，部署至 Web。且可以使用 Flutter 現有的功能，且不需要其他瀏覽器的套件。

由 Flutter for web 的架構可知，為了增加在瀏覽器的支援與實作，Flutter 的核心是基於的 WEB API 的標準上透過綜合 DOM、Canvas 及 CSS 的技術繪製圖層，是以 Dart 程式語言完成，使用 Dart 優化過的 JavaScript 編譯器將 Flutter 框架核心與使用者的 .dart程式編譯成新的單一、簡化的應用程式，且可以部署到任何伺服器。，提供了可攜式、高品質且高性能的使用者體驗。完整說明可參考：https://flutter.dev/web

Web support for Flutter

來一個 Flutter for web 的 Hello World 吧！

如果是全新的開發者請參考 Preset 步驟先安裝環境

Preset I — 安裝 Flutter 與 Dart

參考官網的安裝流程，根據開發者的作業系統有不同安裝跟設定的方式。參考網址：https://flutter.dev/docs/get-started/install

Preset II — 編輯器設定

官方也提供了Android studio/IntelliJ 及 VS Code 編輯器 Dart 及 Flutter 的擴充套件，如果已經安裝過 Flutter 的開發環境，則需要更新至 Flutter 1.5 版本。參考網址：https://flutter.dev/docs/get-started/editor?tab=vscode

$ flutter upgrade

接著透過 flutter doctor 指令檢查開發環境。會得到類似下列的結果：

$ flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, v1.5.4-hotfix.2, on Mac OS X 10.14.4 18E226, locale zh-Hant-TW)
[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
[✓] iOS toolchain - develop for iOS devices (Xcode 10.2.1)
[✓] Android Studio (version 3.4)
[✓] VS Code (version 1.33.1)
[!] Connected device
    ! No devices available

! Doctor found issues in 1 category.

接著需要安裝 webdev，Dart 的 command-line tool 編譯 .dart 程式。記得要先安裝 pub (Dart Package Manager) 及一定要設定環境變數 $Home/.pub-cache/bin 不然安裝webdev會出現錯誤。

如果是沒有 Dart 的環境，需要另行參考： Dart 安裝方式

設定完後執行安裝指令：

$ flutter packages pub global activate webdev
# or
$ pub global activate webdev

建立專案

如果是使用 Visual Studio Code，可以將 VS code 上的 Dart 與 Flutter 擴充套件，更新至 3.0 版，增加了 Flutter：New Web Project 的 指令，讓我們可以自動建立 Flutter 的 web 專案。

Flutter 的專案名稱建議是以底線分開的命名規則，建立好的專案結構：

• lib 資料夾存放我們撰寫的 Dart 程式。main.dart 是整個專案程式的進入點。
• web 存放網頁的檔案，如果是在 App 的專案，則會有iOS及Android 的資料夾。
• pubspec.yaml 是紀錄專案的設定檔，類似於 Node.js NPM 的package.json 或 PHP Composer 的 composer.json 。
• 相關 asset 的設定（如：圖片、字型檔）檔案是放在 web資料夾內，也需要在 pubspec.yaml 寫相關的連結。
• build資料夾則是放置程式編譯完成時產生的檔案。

執行專案

設定好專案、安裝好相關依賴後，接下來執行 webdev serve 。

$ webdev serve

# or serve with hot reload
$ webdev serve --auto restart

打開瀏覽器 http://localhost:8080 就可以看到充滿 material design ？的 Flutter demo 網頁了！Hello World!

更多關於 webdev 的指令：https://github.com/dart-lang/webdev

最後使用打包的指令，最終檔案會編譯在 build 資料夾內。

$ webdev build

如果不是透過 CLI 工具建立的專案，則需要建立下列檔案（範例程式參考 CLI 所建立之檔案內容）：

• pubspec.yaml

• lib/main.dart

• web/index.html & web/main.dart

執行 pub get 安裝相關的 dependencies，並且會產生.dart_tool 資料夾存放及 lock 檔案 pubspec.lock（類似 Node.js 的 node_modules & package-lock.json）。

目前的一些技術限制

Flutter for web is currently available as a technical preview.

由於這個技術還在開發階段，所以還有以下問題。

• 目前還是沒有一個好的 debug tool。
• 瀏覽器支援度還不夠，建議先使用 chromium based 的瀏覽器。
• 正在整合的過程中，以後還是有可能需要大改程式碼。
• 由於目前還沒有辦法直接跟 App project 直接共用程式碼，Flutter API 與 Flutter for web 的 API 不相容，不過已經正在 merge。
• Flutter for web 的 dependencies 中使用的 UI SDK 與 App project 的不同。如： flutter_web ＆ flutter_web_ui

https://github.com/flutter/flutter_web/blob/master/docs/faq.md

官方 Github 中也列了一份 Q&A 說明在現在實驗性質的專案可能遇到的問題，讓開發者在踩雷的時候 (?)，可以…認命點吧。

參考資料

1. https://developers.googleblog.com/2019/05/Flutter-io19.html
2. https://flutter.dev/web
3. https://github.com/flutter/flutter_web
4. https://medium.com/flutter-io/bringing-flutter-to-the-web-904de05f0df0
5. https://medium.com/flutter-community/flutter-web-announced-in-google-io19-c6f1da207f3c

哈囉 Flutter for web！ was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

使用者在社群中分享網頁連結，當其他人看到並且有安裝 Mobile App 時，會希望使用者能夠自動開啟 Mobile App；或是尚未安裝時，能夠自動導到 App Store 或是 Play Store。

Firebase Dynamic Link 可以讓這件事情變得簡單點，先來看一下介紹影片。

看完之後是不是很心動呢？接下來介紹一下 Firebase Dynamic Link 吧！

創建 Dynamic Link

創建 Firebase Dynamic Link 可以透過幾種方式來創建：

• Firebase Console
• REST API
• SDK
• 手動創建

大家可以挑選適合的方式來創建，今天將會著重在手動創建這個方式的小細節。

在預設情況下，Firebase 提供 page.link 這個域名供使用者使用，能夠自行設定不同的子網域來區分不同的用途，像是：

// SWAG 專用的 Dynamic Link
swag.page.link

// SWAG 活動專用的 Dynamin Link
swagevent.page.link

若使用者想使用自己的網域名稱，也可以在 Firebase Console 中來設定，使用自訂的網域名稱，大概會長得像這樣：

link.swag.live

這個部分就看實際使用的情境來決定。

手動創建

Firebase Dynamic Link 可以透過自行組合參數來創建，像是：

https://link.swag.live?link=your_deep_link&apn=android_package_name

若使用者有安裝對應的 Android App 則會直接開啟 Android App；若無，則會自動導到 Play Store。

Firebase Dynamic Link 的參數會分成幾個部分：

• Deep Link Parameters
• Android Parameters
• iOS Parameters
• Other Platform Parameters
• Navigation Parameters
• Social Meta Tag Parameters
• Analytics Parameters
• Debug Parameters

Deep Link Parameters

Deep Link 的參數主要是提供 App 和退到網頁版來使用，若使用者已安裝 Mobile App 則直接透過 App 來開啟；若尚未安裝，則看是要導到商店或是退到網頁版。

link
Mobile App 將會開啟的 URL，指定 App 可以處理的 URL，一般來說是 App 的內容或是啟動特定 App 邏輯的 Payload；link 會是格式良好且 URL 編碼過的 URL，可以是 HTTP 或 HTTPS，且不能為另一個 Firebase Dynamic Link。

在桌面裝置的瀏覽器上開啟時，將會開啟這個連結，除非有另外指定 ofl。

Android Parameters

這部分的參數主要是提供給 Android 來使用。

apn
Android 用來開啟連結的 Package name，且該 App 在 Firebase Console 的 Overview 頁面中，應該要與專案被連結在一起；對於 Dynamic Link 要開啟 Android App 來說是必要的。

afl
當 Android App 尚未安裝時所開啟的連結，這個連結用來指定一些像是開啟手機版的網頁，或是一些 App 的促銷頁面，並非用在使用者尚未安裝 App 時，從 Play Store 安裝 App 的用途。

amv
App 能夠開啟此連結的最低版本，如果安裝的較舊的版本時，將會導至 Play Store 來升級 App。

iOS Parameters

這部分的參數主要提供給 iOS 和 iPads 來使用。

ibi
用來開啟連結的 iOS App Bundle ID，該 App 應該要在 Firebase Console 的 Overview 中與專案連結在一起；對於 Dynamic Link 要開啟 iOS App 來說是必要的。

ifl
當 iOS App 尚未安裝時所開啟的連結，用來指定一些像是開啟手機版的網頁，或是開啟 App 的促銷頁面，並非用在使用者尚未安裝 App 時，開啟 App Store 讓使用者安裝 App 的用途。

ius
自訂的 URL Schema。

ipfl
當 App 尚未安裝時，在 iPads 上所開啟的連結，與 ifl 的用途類似，只是專門用在 iPads 上。

ipbi
在 iPads 上用來開啟連結的 App Bundle ID，該 App 必須要在 Firebase Console 的 Overview 頁面中與專案連結在一起。

isi
App 的 Apple Store ID，當使用者尚未安裝 App 時用來帶使用者到 App Store。

imv
能夠開啟連結的最低 App 版本，當 App 開啟時，這個 flag 會被傳到 App 中，App 中必須決定該如何處理。

Other Parameters

主要為除了 Android 和 iOS 平台外所使用的參數。

ofl
除了 Android 和 iOS 平台，其他平台所開啟的連結，這在電腦版中用來指定不同的行為非常好用，像是開啟 App 內容的滿版網頁，或是其他用來安裝 App 的 Dynamic Link Payload。

Navigation Parameters

Navigation 所使用的參數。

efr
將 efr 設為 1 開啟 Dynamic Link 時會略過 App 的預覽頁面，直接跳轉到商店或是 App；App 的預覽畫面在使用者開啟 Dynamic Link時，可以更可靠的將使用者帶到更適合的目的地

然而，如果你期望 Dynamic Link 只在 App 中被開啟，在沒有 App 的預覽畫面時會更可靠，因此也可以選擇將 efr 設為 0 來停止它。

App 的預覽畫面現在只會在 iOS 上出現， Android 上之後可能也會出現，這個參數將會影響到 Dynamic Link 在兩個平台上的行為。

Social Meta Tag Parameters

用在社群分享的參數。

st
用來當作分享在社群貼文中的標題。

sd
用來當作分享在社群貼文中的描述。

si
跟這個連結有相關的圖片，圖片至少要 300*200px 且小於 300KB。

Analytics Parameters

用於數據分析的參數。

Google Play Analytics Parameters

• utm_source
• utm_medium
• utm_campaign
• utm_term
• utm_content
• gclid

iTunes Connect Analytics Parameters

• at
• ct
• mt
• pt

Debug Parameters

用於偵錯的參數。

d
透過將 d 設為 1 進入偵錯模式，將會產生 Dynamic Link 的行為流程圖，而不是載入 Dynamic Link，可以用來預覽 Dynamic Link 在不同平台和配置的行為。

https://link.swag.live?link=your_deep_link&d=1

總結

使用 Firebase Dynamic Link 時，可以結合 Android 和 iOS 兩平台的參數，來產生在 Android 和 iOS 上都能夠使用的 Dynamic Link。

另外，當使用者尚未安裝 Mobile App 時，不是每次都需要導到商店，這種情況下 iOS Parameters 可以不帶 isi，這樣就能夠不跳到 App Store。

ifl、ipfl、afl 和 ofl 在大多數的情況下可以不用帶，但如果有需要針對尚未安裝 Mobile App 的使用者有不同行為（像是：安裝 Mobile App 就能夠獲得一些特別促銷……等），在這種情況下就蠻適合透過這幾個參數，來設定這種不同的行為。

Firebase Dynamic Link — 簡單介紹 was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

什麼是 Tig

Tig 是 Git browser 的一種
除了可以比原生 git 秀出更詳細的 log 之外他針對.git操作的方式也可以更多元
簡單說 Tig 就像 CLI版的Sourcetree，可以以視覺化方式在 Terminal 操作 Git 的工具。 雖然Git 本身已經就擁有 interactive mod 這些具便利性的指令，但是 Tig 這隻工具有提供更多方式讓你可以用更進階的方式去修改你的Git commit。

安裝方式

macOS 透過 Homebrew 安裝

brew update
brew install tig

Ubuntu 透過 apt-get 安裝

sudo apt-get update
sudo apt-get install tig

基本操作

在已經 git init 過的專案底下輸入 tig
就可以直接進入Tig 的main view
來查看當前git的commit
可以上下切換commit 後 enter 查看當前commit 的diff

Diff View

進入Diff View後 按 j/k 可上下捲動diff 檢視變更
按q則可離開diff view
回到main view 後 按t 則會進入tree view

利用Tree view 來快速切換要檢視的Branch

通常在git 底下是必需先checkout 的
但是在tig可以直接查看指定branch 底下的commit
不管在哪一個view底下都可以用大寫的S來 切換到status view 底下 並用u 加入指定的檔案到這次的commit 中

最後
如果專案沒有任何commit 紀錄 tig 是會報錯的

tig: No revisions match the given arguments.

這時候還是可以透過tig 來增加commit
只要直接執行tig status 然後再按 `u `來新增檔案即可

Tig- CLI 版的 Sourcetree was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

一個iOS APP從2016至今已經快三年了，這段時間除了iOS系統本身的變動外，也多了新的語言Swift 加入，而且在這段期間內歷經各種大大小小因應營運的需求及急速功能變動，因此逐漸累積了不少技術債，為了面對未來更多的挑戰，償還歷史技術債是在所難免的，但是專案本身要進行大範圍重構是很困難的，畢竟產品已經在營運中是不等人的，因此我們的目標是縮限在有限的時間內達到有效的優化目的的重構，因此我們team根據目前的架構以及所遭遇的問題，綜合時間及範圍的掌握程度，選擇了幾個方向進行，其中一個就是APP中常用的user model。

問題評估

原本的程式大約如下:

@interface SWUserModel: MTLModel  <MTLJSONSerializing>
@property (copy ,nonatomic) NSString  *identifier;
@property (copy ,nonatomic) NSString  *username;
- (void)checkMembership:(void (^)(BOOL isMember))result;
@end

針對user model進行評估後，決定以下三個項目為目標
⁃ Objective-C to Swift
⁃ No Mantle
⁃ No API call

首先是APP本身早期是用Objective-C開發的，但是目前ject已經逐漸轉以Swift 為主要開發語言，雖然可以用Swift extension方式擴展，但為了可以充分發揮新的語言帶來的好處及便利，因此想要藉此機會轉換過去。
而Mantle則是用來將JSON轉成object用的套件，但是改用Swift後就有decodable可以直接取代了。
再來就是在資料model中有進行呼叫API的行為，這雖然是一個很方便（偷懶）的方式，但是不符合SRP原則，因此也一直是我們想要下手處理的目標。

解決方案

考量不影響既有架構下抽換掉舊的data model的方式，而且也有可能新舊架構要並存一段時間的情形，決定採用protocol方式把data model實體藏起來，用統一的介面來溝通，這樣外界存取時就完全不需要管拿到的model實體是誰，之後就算拔掉整個舊model或者以後再更換model時會受到影響就會相當低。

因此先用Objective-C方式整理出介面，之後重構完成後就算用Swift方式重新寫一次也花不了多少功夫。

@protocol UserProtocol <NSObject>
@property (copy ,nonatomic) NSString *identifier;
@property (copy ,nonatomic) NSString *username;
@end

因此新的Swift版本的User Model就會如下

@objcMembers class UserModel:NSObject ,Codable ,UserProtocol {
 var identifier: String
 var username: String?

private enum CodingKeys:String ,CodingKey {
  case userID ="id"
  case username
 }
 func encode(with aCoder: NSCoder) {
     aCoder.encode(userID, forKey: "identifier")
     aCoder.encode(username, forKey: "username")
 }
 required init?(from decoder:Decoder )throws {
  let container = try decoder.container(keyedBy:CodingKeys.self)
  self.userID =try container.decodeIfPresent (String.self, forKey: .userID)
  self.username = try container.decodeIfPresent(String.self , forKey: .username) ?? ""
 }
}

然後找了個module將原本使用SWUserModel部分全部以UserProtocol取代後，進行小部分的測試並確認無誤後，但是這時突然發覺還有個重要問題還沒有解決，就是APP本身為了暫存目前使用者資料，所以將整個model object存下來在本地端，如果不處理這部分的話，會造成既有的使用者在升級到新版時，因為與新格式不符而變成需要重新進行登入，更甚者可能發生crash的狀況，因此還是必須有一個舊轉新的升級動作，以避免影響使用者體驗。

因此另外寫了個CurrentUserArchiver class，用來處理存取本地端資料時的介面，當新舊user model進行載入本地端使用者物件時，如果是用舊的model時會進行轉換成新的，並將轉換的行為包裝起來。

@objcMembers class CurrentUserArchiver: NSObject, NSKeyedUnarchiverDelegate {
    static let shared = CurrentUserArchiver()
    private let userDefaults = CurrentUserDefaults()

func transfer(_ object: Any) -> Data {
        return NSKeyedArchiver.archivedData(withRootObject: object)
    }
    
    func revert(from data: Data) -> Any? {
        do {
            let obj = try NSKeyedUnarchiver.unarchiveTopLevelObjectWithData(data)
            if let obj = obj as? SWCurrentUserModel {
                let user = CurrentUserModel.from(swCurrentUser: obj)
                return user
            }

return obj
        }
        catch let (err) {
            debugPrint(err)
        }
        return nil
    }
    
    func unarchived() -> Any? {
        guard let archivedData = userDefaults.currentUser else { return nil }
        return revert(from: archivedData)
    }
    
    func archived(user: Any) {
        var object = user
        if let user = user as? SWCurrentUserModel {
            object = CurrentUserModel.from(swCurrentUser: user) as Any
        }
        
        userDefaults.currentUser = transfer(object)
    }
}

這樣之後就可以無痛從舊的轉換成新的了。

至於呼叫API的處理，以根據使用的需求來分析，所以選擇的處理方式是用Singleton的class，由需要的View Controller來跟Singleton請求，這樣也可以避免掉重複的API request。

結論

雖然沒有一一帶到所有細節，到此基本上已經達到原本預期目標，其實在整個過程中還會需要一併納入考量的像是流程優化，去除多餘的、不必要處理等等。而花了那麼多功夫，其實也只是還了小部分技術債，但是可以讓產品本身開始往正確的方向發展。

重構時順便還的技術債 was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

When the question comes to What is the difference between concatMap() and flatMap() in RxJava? People would tell you:

flatMap() doesn’t care about orders, while concatMap does.

And I bet a lot of people read it from

RxJava Observable tranformation: concatMap() vs flatMap() | Fernando Cejas

So do I. That explains why their signatures are the same, and why people always get confused about when to use which.

At first I was like “ I don’t really care, sometimes I use flatMap, sometimes I use concatMap.”. I never had a chance to have the problem that needs to take care of orders.

And like the author himself said: he didn’t took a look at the Rx document before he uses it. Neither did I. I don’t even understand what his code is to do. Until one day, a strange bug came to me. I finally realized that it is something to do with the concatMap/flatMap things.

Here is what I found.

TL;DR

Make sure every observable completes if you use concatMap(), and it really matters

Say I have 3 Observables that looks like below

val source = Observable.create<Int>{
    it.onNext(1)
    it.onNext(2)
    it.onComplete()
    it.onNext(3)
}

fun operationCompletes(number: Int): Observable<Int> {
    return Observable.create<Int> {
        it.onNext(number)
        it.onComplete()
    }
}

fun operationNoCompletes(number: Int): Observable<Int> {
    return Observable.create {
        it.onNext(number)
    }
}

The source emits onNext(1), onNext(2), onComplete() and then try to fire onNext(3). To make things easier, the functions do nothing but pass the variable to downstream. One is with onComplete() while the other one is not.

The expected result looks like:

I/System.out: [Original]OnNext: 1
I/System.out: [Original]OnNext: 2
I/System.out: [Original]Completed

And then let’s try to connect observables with flatMap()

And the result is

I/System.out: [FlatMapC]OnNext: 1
I/System.out: [FlatMapC]OnNext: 2
I/System.out: [FlatMapC]OnComplete
I/System.out: ######
I/System.out: [FlatMapNC]OnNext: 1
I/System.out: [FlatMapNC]OnNext: 2
I/System.out: ######

Hmm… the onComplete() is gone after the non-complete observable. But so what? onNext() is enough for most of the time, and the non-complete observable itself choose not to fire onComplete(). That’s the desired behavior.

Okay, Let’s change nothing but flatMap() to concatMap()

The result is:

I/System.out: [ConcatC]OnNext: 1
I/System.out: [ConcatC]OnNext: 2
I/System.out: [ConcatC]OnComplete
I/System.out: ######
I/System.out: [ConcatNC]OnNext 1
I/System.out: ######

wait… what? Only onNext(1) was emitted in the last case.

This actually makes sense. concatMap() takes orders in consideration, so it must wait for a signal to tell him that he can do next.

I would like to go deeper with the source code and Rx documents, but it is more complicated than I thought. So the part I is just to share this common error that happens to Rx beginners. Part II will be wait until I found how to tell the story.

Any feedback is welcome. I would be happy to hear how programmers are to avoid this things from happening in a team work project.

References

flatMap()

RxJava Observable tranformation: concatMap() vs flatMap()

discussions on stackoverflows

Side effect of messing up with Rx operators: concatMap() vs flatMap() in RxJava. Part I was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.

App 品質的重要性

App 的品質代表著，是會被留在裝置上，還是會被立馬移除
App 的品質代表著，是會被好康道相報，還是會被壞事傳千里
App 的品質代表著每次推出新版本時，是會心驚膽跳，還是會悠閒的喝著咖啡看著業績數字的成長

App 的品質來自於團隊中的每一位成員

品質，不是靠最後的查 bug、修 bug，來確保是否達品質要求。
品質，是早從確認需求、規畫設計就得開始管理的。
如同蓋社區大廈一般，若建築師未能將設計圖畫好、未能確認好各區所需用到建材及數量時，即讓工人進行施工，而在施工過程中，又未能將設計圖補足，這麼一來，難保最後不會蓋出漏水滲水甚至是大地震來時會倒塌的房子。

而當需求被明確化被 spec 化了，這時就是輪到將 spec 實現化的執行單位要管理執行過程中的品質並符合其需求。
如同建築師已將設計圖畫好，但工人在施工過程中，卻沒去注意到一戶要隔成兩房一廳或三房兩廳，難保不會蓋出不符合需求的房子。

或許有些人會認為，品質的檢測是只需放在最後最後的檢查，但我想帶個想法給大家，〔品質的檢測，應該是在專案的每一個階段〕。
如同工人挖好地基了，工人&建築師&檢驗人員都應確認其地基挖的夠深夠寬後，房子才開始往地面向上蓋，若在此時及時發現地基挖的不夠就能及時補強。

倘若其專案不只有需求單位，另還有使用者時，就不光只是檢測是否符合需求，連同提供給使用者觀看內容的審核也是品質的一環。

如同社區大樓新建案完成了，若能有間宅裝過的樣品屋，更能提高這一片空屋的品質，進而較獲得看屋者的青睞。

而品質檢測的同時，最需要的是時間。專案在時間緊迫情況下，儘管看起來似乎完成了檢測，但日後也許很可能那些未檢測到的項目，陸續出現問題。
很多時候，特別是在追趕進度時候，最常被壓縮的就是測試時間，這也同時代表著 App 的品質被犠牲了。

品質意識不是單一層面不是一個單位的責任，品質是多面化是團隊每一位成員出自內心對品質的認知。

QA 在團隊中所扮演的角色

QA，有些人會把它當成檢查單位、有些人會把它當成審核單位，但我把它定義為協助單位，協助團隊在專案開發前，即能思考到複雜及反向的情況，而不再讓團隊處於僅思考到單向好的方面；協助團隊在專案開發過程中，陸續提供測試結果給 PM 甚至是需求單位，以確保驗收標準及專案成果等同於需求單位所要的；協助團隊在專案開發後，確保其專案的穩定性並提高專案的品質。

品質你我他 was originally published in SWAG on Medium, where people are continuing the conversation by highlighting and responding to this story.