論PAGELINK的必要性，論PAGELINK必要性

論PAGELINK的必要性，論PAGELINK必要性

原文同時發表在老碼農的個人部落格，歡迎大家訪問：http://www.koulianbing.com/?p=9

通常來說，App內的PageLink機制有幾個顯著的優點值得我們去做：如，增加運營靈活性，頁面開放性，利於效果追蹤，反推模組間解耦，降低子工程間的依賴等。

用戶端總有那麼幾個核心業務承接頁面，是給使用者展示資訊的主場，也是運營活動、訊息推送時的使用者承接頁。如微博的個人首頁，手淘的商品/店鋪詳情，的公用帳號首頁等。通常我們會把它們開放給運營，甚至三方應用。這個時候，就輪到PageLink上場了。把頁面定位進行URI正常化，由URI的分發中心接受URI並開啟目標頁頁。運營同學在搞新活動的時候，可以通過URI來配置活動承接頁，靈活控制跳轉路徑。

另外，我們也可以為每一次跳轉賦予一個唯一ID，橫向追蹤每個運營活動的效果，如點擊，轉化率等。把整個活動資料化。

把頁面進行URI正常化的同時，也反推了技術在開發時對頁面之間的跳轉進行解耦。因為只有入參簡化，規範了，才能做到以URI中的Query做為輸入，提供所需要的關鍵參數。

PageLink在使用過程中，我們還可以進行擴充，在跳轉頁面的基礎上進一步加強為執行Action。如，播放頁面聲音，觸發網路請求，打電話等。一切Action都由schema://host/action?queryKey=queryValue的形式來表示。將軟體中的模組、服務進行解耦，划出界限，最終通過Action組織起來形成一個個的互動。

當我們的工程變得越來越大時，參與人員越來越多時，不可避免的要拆分成為不同的子工程，這個時候不同業務團隊之間做直接的代碼引用會很痛苦的，內耗和溝通成本都會直線上升。你能想象一個團隊的人偶然修改了一個方法導致所有人都編譯不了，然後每個都在開發群裡罵街的情形嗎？

這裡提兩個實現細節方面的事。

一個是Action的數量隨著App的版本在不斷增加，這個需要做好版本管理，以及前向/與舊版相容，避免出現穩定性問題。

另外，在queryKey和queryValue的定義上，最好使用有字面意義的字元來表示，要做到見文知義，不要把程式中的索引值拿出來用。假設我們在AppStore中定義了一個URI來表示，希望程式跳轉到詳情頁時定位到第二個叫做“評論”Tab，那麼query最好定義為subTab=comment，這樣很容易明白的寫法。如果你是使用方，一定不希望開發人員定義成這樣：subTab=2（表示第二個Tab），這樣做一方面會讓使用者不名所以，另一方面，當頁面的資訊結構重構時，如“評論”在某個新版本中變為第3個Tab了，你肯定能想象寫代碼會是多麼痛苦。