為了更好的閱讀體驗，建議閱讀原文

想和我一起全面了解新聞類App的開發，點我學習

據相關數據顯示，截至2017年底，中國手機新聞客戶端用戶規模達到6.36億人，移動App已經成為新聞和內容傳播的最重要途徑之一。而伴隨著行業的競爭和發展，App中的內容頁在提升App品質、提升使用時長及提升用戶黏性等方面，扮演著更為重要的角色，同時也面臨著更大的挑戰。

1. 內容頁在呈現上越來越豐富。新聞資訊作為內容頁的主體，逐漸增加了更多的文字樣式、內容形式、富媒體、以及廣告、投票等更為豐富的元素。
2. 內容頁需要更多擴展區域來提高使用時長及用戶黏性。在資訊主體之外，各個App逐漸打造了例如關注模塊、推薦閱讀模塊、評論模塊、運營模塊等越來越多的擴展閱讀區域。
3. 短視頻、直播的爭奪越來越激烈。越來越多的新聞App都將視頻作為獨立的模塊和獨立的內容頁進行展示。
4. 同質化產品競爭激烈。要求更快的迭代速度、更優質的用戶體驗、更小的實現成本。

所以，新聞類App內容頁架構的設計和技術的優化，也要配合產品形態的發展，在越來越復雜的需求挑戰下，擁有快速響應的能力和穩定優質的體驗。

本文結合分析目前主流（DAU）新聞類App如今日頭條、騰訊新聞、天天快報、一點資訊等內容頁技術方案的選擇，一起探索新聞類App內容頁的技術實現和優化。

—— 幾十行代碼完成新聞類App多種形式內容頁

HybridPageKit ：一個針對新聞類App高性能、易擴展、組件化的通用內容頁實現框架。

基于ReusableNestingScrollview、WKWebViewExtension、以及本文中關于內容頁架構和性能的探索。

想和我一起全面了解新聞類App的開發，點我學習

1. 概念定義

結合目前主流的內容頁實現方式，我們把內容頁分為上下兩個部分，為了方便后續的閱讀先簡單定義下關鍵的名詞。

1. 上部分通常用WebView實現。常規包括標題 + 作者（關注）+ 資訊內容，我們稱為WebView內容區。
2. 下半部分主要是平行于WebView的各種擴展內容，常規包括點贊打賞、廣告推廣、相關推薦，熱門評論等等，我們稱為Native擴展區。
3. WebView中每個復雜UI呈現、擴展區中每個獨立模塊，我們都稱為一個模塊或組件。

完整來看，整個內容頁右側（右滑）普遍為評論頁。無論是之前流行的ScrollView右滑還是近期流行的Push新頁面，這兩種方式實現起來都比較簡單且較為獨立，故本文暫時忽略右側（右滑）評論的部分。

2. 目錄

- 技術方案選擇 -

1.WebView類型選擇

不同于微博，新聞類App的內容以段落性的文字為主，配合段落間的圖片、富媒體等。同時為了滿足跨平臺的一致呈現、PC網頁的文章轉載、不同平臺文章的抓取，以及注重閱讀而非交互等原因，使用WebView加載渲染本地的HTML字符串數據已經成為了新聞類App通用的方案。

1. UIWebView VS WKWebView

• 穩定性:

  UIWebView較多的WebCore、JavaScriptCore Crash，以及系統性的內存泄露導致OOM，對整個App的穩定性都是極大的隱患。反觀WKWebView，基于獨立進程，不會占用App的內存計算，同時也不會導致主App Crash。所以在系統級的穩定性上，WKWebView有著極大的優勢。

• 加載速度:

  WKWebView通過JIT大幅優化了JS的執行速度，但是對于新聞類App內容頁的使用場景來說，簡單的進入、退出頁面，且單純的加載渲染HTML字符串，WKWebView比UIWebView慢了很多（Benchmark）。

• 兼容性:

  NSURLProtocol的無法使用、長按MenuItems Bug（before iOS11）、iOS8不能刪除Cache、設置Cookies及UA、POST參數、異步執行JS...這一系列的問題，成為了穩定項目替換WKWebView最大的挑戰。

• 擴展性:

  WKWebView具有更加豐富的接口、更多HTML和CSS的支持、以及更加友好的JS交互。同時Api的持續更新和社區的活躍，從長遠使用的角度看有著極大的優勢。

2. 修復、擴展WKWebView

通過以上的分析，WkWebView從系統級的穩定性、性能以及后續擴展性都有很大的優勢。通過WKWebViewExtension擴展修復原生WKWebView，結合HybridPageKit中WKWebView的回收復用邏輯，極大程度上解決了原生WKWebView的問題，起到了很好的效果。

• 修復擴展的問題:

  通過逐階段分析耗時，在內容頁的使用場景下，WKWebView從alloc到準備開始渲染這段時間，有著極大的優化空間。在瀏覽內容頁這種場景下，HybridPageKit中通過WKWebView的復用回收以及資源緩存，極大降低了WKWebView加載渲染HTML的時間，使之低于原生UIWebView。

  通過私有方法的擴展和代碼優化，在WKWebViewExtension中支持了URLProtocol、修復了MenuItems的bug、支持iOS8清理緩存、擴展安全的JS執行方法、以及擴展NavigationDelegate以兼容JSBridge邏輯等。

• 無需解決的問題:

  對于新聞類App內容頁的使用場景，一些WKWebView的問題并沒有必要形成通用的解決方案以兼容代碼。比如POST請求不能帶參數、Javascript異步執行等問題，都可以通過代碼的重構來進行解決。尤其不推薦卡主Runloop從而同步JS的方式。

• 遺留問題:

  目前，在使用WKWebView的過程中，唯一未解決的問題就是可靠、全面的白屏檢測方案，從而支持WKWebView在任何情況下的Crash進行重載。諸如系統Crash回調、WebView Title監聽、ContentSize監聽、甚至屏幕隨機取色值等方法都不能滿足全部的白屏場景。

2. WebView內容區與Native擴展區的銜接

對于目前的主流App來說，單純的WebView已經無法滿足復雜的呈現和邏輯。如何在頁面中合理的處理WebView與擴展區中的多種View協同滾動，靈活擴展，并且支持下拉刷新、上拉加載等操作，不同的新聞類App也有不同的技術方案。

1. 結合TableView

• 實現原理:

  由于擴展區中列表類型的模塊較多（例如相關文章、評論等），最簡單的實現即Native擴展區的模塊拆分到Cell的粒度，整體使用TableView實現。對于擴展區和WebView的銜接，如上圖一般有兩種實現方案：TableView根據WebView的Inset（或Div占位）插入到WebView中 & WebView作為TableView的Header。

• 優點:

  這種方法相對簡單，容易實現內容頁各個模塊的布局，同時基于TableView的刷新邏輯，也能動態的處理各個模塊的更新、插入刪除，并且支持家在更多等。和WebView的結合滾動也較為流暢。

• 不足:

  這種方式將Native擴展區的模塊粒度都區分到Cell的層級，列表類型模塊只能通過Cell或者以Section的模式進行管理，同時也無法跨頁面的整體復用UI及業務邏輯。UI的布局依賴TableView模式，靈活性較差。隨著組件類型的增多，非同質性的View也沒有充分利用TableView的復用。

  同時無論使用哪種方式和WebView銜接，都影響了WebView、TableView的獨立渲染展示，增加了維護的困難。并且Header與Inset對于頭部區域的擴展，如下拉刷新等，實現都較為困難。

2. ScrollView嵌套

• 實現原理:

  這種實現用一個ScrollView作為Container，將WebView及擴展區的組件分別作為SubView。全部SubView禁止滾動，內容頁的全部滾動都發生在Container上。對于SubView中的滾動視圖，如果ContentSize小于屏幕高度，則作為普通View，否則設置為屏幕高度，通過offset和Frame的計算，動態的調整視圖相對Container的Frame以及自身的ContentOffset，實現滾動效果。

• 優點:

  這種方式完全獨立每個模塊的實現，使UI和業務邏輯一一對應。對WebView的渲染沒有干擾，模塊的加載和布局靈活管理、復用，模塊業務邏輯獨立內聚。添加刪除模塊、實現上拉下拉等操作簡單。極大的提高了靈活性和復用的可能。

• 不足:

  由于這種方式需要對SubView中的滾動視圖進行計算、模塊動態更新時整體布局也需手動刷新等，極大的提高的實現的復雜度。

  基于ReusableNestingScrollview，在HybridPageKit中，封裝了以上ScrollView嵌套邏輯。這樣就隱藏了復雜的實現邏輯和邊界條件，充分的保留了靈活性的特點。同時對于內容頁的使用場景，精簡了嵌套滾動的使用，擴展上拉加載更多及下拉刷新邏輯，使整個方案實現簡單、靈活擴展。

3. WebView內復雜UI、復雜交互模塊的展示

隨著核心的WebView內容區逐漸支持復雜的呈現方式，單純的H5基礎渲染已經滿足不了現有的需求，比如視頻的交互、音樂的續播、以及各種地圖、投票等組件。同時Web中復雜的UI和邏輯也極大降低了WebView的渲染速度，增加了開發和維護的成本。

1. 復雜UI及邏輯實現困難

• 為了滿足更好的交互體驗，資訊內容中富媒體內容逐漸增多，如視頻的續播、小窗播放、音樂懸浮播放、內容中插入地圖、投票等。同時隨著產品功能的迭代，例如圖片類型的簡單模塊，也增加了點擊全屏、長按保存、二維碼識別、雙擊擴大等交互。這些復雜的UI和邏輯導致CSS和JS增多，Native和Web的通信增加，以及大量運用LocalStorage等瀏覽器存儲，增加了客戶端開發和維護的成本。

2. 簡單圖片的展示耗時

• 對于內容WebView中的圖片，最簡單的作法，就是后臺直接下發Img標簽，依靠WebView自身的下載與渲染。但是這種方式靈活度較低、客戶端無法合理的控制下載時機、無法做自定義的緩存以及裁剪等。
• 對于簡單Img標簽的升級，即后臺數據單獨下發圖片數據，客戶端根據需求自定義選擇下載時機及緩存策略。Html模板中先用占位圖占位，Native下載成功后替換標簽的Src進行展示。這種方式雖然解決了靈活性的問題，但是也帶來了整個流程的復雜性，以及多次IPC間的通信延遲。
• 為了兼顧靈活性，以及縮短圖片的Loading時間，我們在單獨處理圖片的同時，替換內容WebView中全部圖片為Native，減少不必要的流程及通信，極大提高了加載的速度。

3. Native化全部非文字類組件

為了減少實現復雜UI、復雜交互模塊的開發、維護成本、減少模塊在Web和Native間的邏輯流程，提高Web中模塊的加載展示速度，在HybridPageKit中將Web中全部非文字類模塊全部Native化。

• 頁面模板使用空div占位:

  結合后臺的模板與數據，全部模板中全部非文字類的組件，映射成統一Class的Div，通多唯一的id與數據綁定。組件默認實現占位圖邏輯，對于同步數據同時設置組件的Size，異步數據則先設置為0。替換后WebView對模板進行渲染。

• 渲染完成通過JS獲取位置:

  WebView渲染成功回調，通過JS獲取全部統一class對應WebView的Frame，以及對應的唯一Id。

• 在相應位置粘貼NativeView:

  在進行以上兩個步驟的同時，進行下載圖片數據、NativeView創建、初始化、異步數據拉取等工作。在JS回調全部位置時，根據位置及ID，粘貼Native組件。

• 調整字體大小，組件異步數據拉取：對于異步的變化，在復用邏輯之后，下文將結合一并說明。

4. 內容頁全部組件的滾動復用

在Native化全部非文字類組件之后，面對文章中圖片、富媒體數量的增多，以及Native擴展區元素的增加，沒有復用回收的內容頁從滾動性能及內存兩個兩個方面都面臨著挑戰。同時，為了更好的提升用戶體驗，需要對各個組件滾動時的位置進行計算，從而區分不同的區域進行諸如預處理、延遲釋放等邏輯。

1. 主流滾動復用框架

• 繼承特殊ScrollView:

  目前流行的框架如alibab的LazyScrollView，對于實現復用回收機制，都需要繼承相應的ScrollView，這種方式對于WKWebView來說，是無法實現的。

• 繼承特殊Model:

  由于滾動復用需要保存View對應的數據信息，大部分開源框架需要繼承特殊數據Model，生成對應必要的參數或方法，對于支持多種類型組件的通用框架來說，繼承的實現方式不易于擴展和維護。

• View滾動狀態簡單:

  滾動時位置的計算，最簡單的方式就是根據屏幕的高度計算是否進入屏幕，對于預加載的需求，絕大部分開源框架也是只是在屏幕區域的上下增加了Buffer，仍然不能區分具體的狀態，如進入buffer、進入屏幕等，無法滿足復雜的業務邏輯。

2. WebView中組件的滾動復用

• 無需繼承:

  在ReusableNestingScrollview中，為了兼容WebView、ScrollView等一切滾動視圖中子View的復用回收，我們通過scrollView delegate的擴展分發，擴展handler單獨處理子View的復用回收，這樣就在無需繼承的前提下，支持所有滾動視圖中子View的復用回收。

• 數據驅動:

  由于View需要不斷的復用回收，所以數據、狀態、位置、對應的View類型都存儲在對應的Model中，不但實現了數據驅動易于動態擴展，同時優化了復用的邏輯，也緩存住了Frame等關鍵信息優化了渲染布局邏輯。

• 面向協議:

  由于滾動復用的模塊對應的View及數據Model種類眾多，在不動態擴展NSObject、UIView的情況下，無法做到通用的邏輯公用。所以為了更好的支持擴展、更靈活的實現方式，ReusableNestingScrollview中面向通過擴展數據Protocol，使得任何Model輕松實現復用回收對應邏輯。

• 更加豐富的狀態:

  在ReusableNestingScrollview中，為了滿足更復雜的需求，如視頻預加載及自動播放、Gif預加載及自動播放等，我們擴展了組件在滾動過程中的狀態，增加自定義workRange，使組件在滾動過程中的狀態變為3種，即None、prepare區域及Visible區域，更加全面準確的記錄狀態切換，更加靈活的支持業務場景。同時通過3種狀態擴展為二級緩存，對View在不同級別的緩存設置不同的策略。

綜上，通過ReusableNestingScrollview只需將模塊對應Model擴展增加協議，滾動視圖擴展Delegate，就可實現任何滾動視圖中子View的回收復用功能。

3. 內容頁中全部組件的滾動復用

在解決了內容WebView中非文字類組件的Native化、滾動復用之后，我們將實現思想運用到包含Native擴展區的，內容頁整體架構中。如果從內容頁的維度去看，內容WebView也可以算作一個組件，它和擴展區的各種組件一起作為Container的子View，也可以運用上面提到的ReusableNestingScrollview進行實現和管理。

所以整個內容頁就是從兩個維度、運用ReusableNestingScrollview中的實現方法兩次實現滾動復用回收、數據驅動、組件自管理以及組件狀態切換邏輯。

5. 組件異步拉取與動態調整

面對復雜的需求、以及按需加載、異步拉取等優化體驗的策略，在HybridPageKit中也針對相應的場景做了高效的處理。

1. WebView字體大小調整

當WebView中字體大小調整時，需要同時調整全部Native組件的位置。我們監聽WebView的ContenSize變化，當變化發生時，重新執行獲取組件位置的JS語句獲得全部組件的新位置。基于滾動復用的邏輯，只需要對在屏幕中的組件View的位置進行調整，其余只需要重新對組件對應Model的Frame進行賦值，極大提升了效率。在此基礎上，要動態的檢測ContenSize是否小于屏幕高度，高度小于一屏幕時，要同時調整Native擴展區組件的位置。

2. WebView中組件異步拉取數據渲染

對于異步拉取數據的組件，由于初始化時占位Div的高度為0，當數據獲取成功，并渲染好組件后，需要首先執行JS動態修改對應占位Div的大小，之后按照以上的邏輯，重新賦值Native組件位置。

3. Native擴展區組件異步拉取數據渲染

Native擴展區中的組件不同于WebView中的組件，不依賴WebView自身渲染。所以當動態調整大小時，之需調整全部Native擴展區組件數據Model中保存的Frame信息，同時調整在屏幕中的組件位置即可。

—— 幾十行代碼完成新聞類App多種形式內容頁

HybridPageKit ：一個針對新聞類App高性能、易擴展、組件化的通用內容頁實現框架。

基于ReusableNestingScrollview、WKWebViewExtension、以及本文中關于內容頁架構和性能的探索。

想和我一起全面了解新聞類App的開發，點我學習

- 內容頁組件化架構 -

在實現了以上技術關鍵點的基礎上，如何合理的設計內容頁通用的架構，快速響應內容頁的各種需求調整，使整體架構易擴展、易維護，同時有較高的性能及較小的內存占用，成為了整個內容頁架構實現的重點。在HybridPageKit中，我們圍繞靈活復用、高內聚低耦合、易于實現擴展三個重點的方向，設計實現了基于組件化的內容頁整體架構。

1. 組件化解耦及組件通信

為了滿足內容頁業務的相對獨立，支持快速響應迭代及組件整體復用，內容頁整體的結構應滿足通用性、易于擴展、以及高內聚低耦合的特點。所以在ReusableNestingScrollview的支持下，采用組件化的方式實現全部內容頁業務模塊。

1. 組件化解耦

為了達到組件的高內聚、與內容頁的低耦合，在HybridPageKit中拆分業務邏輯為獨立的組件化的處理單元，每個處理單元通過MVC模式實現。其中Model作為組件的數據，只需要在實現解析邏輯同時，實現對應delegate即可。Controller只需要實現組件間通信的delegate，選擇性的實現例如controller生命周期、webview關鍵回調、以及滾動復用相關的方法即可。通過組件的自管理及復用，組件可以集成統一的上報邏輯、業務邏輯到自己的Controller中，并且在不同類型的頁面靈活復用。

2. 組件通信

為了更好的實現組件化的結構，組件的Controller需要在內容頁初始化時進行注冊。內容頁在每個關鍵的生命周期或業務節點，采用中心化通信，廣播執行相應的方法，組件的Controller按需實現處理即可。對于新增、刪除功能，只需擴展delegate中的方法，內容頁中觸發方法、組件中實現方法即可。

2. 組件及WebView的復用管理

1. WebView & 組件View全局復用

為了提高WKWebView渲染速度，通過建立全局WKWebView復用回收池來復用WKWebView。除了基本的線程安全、復用狀態管理等，在進入回收池前要load特殊Url以維護整個backFowardList。組件的View也是通過全局的復用回收池進行管理，使得相同的組件View可以靈活的出現在內容頁、列表頁等App內各個頁面，極大的減少了開發成本，提高運行效率。

2. 自動回收 & 內存管理

WebView及組件View實現自動回收邏輯，每次在申請新View時檢測活動隊列中View的SuperView是否為nil，是則自動回收防止內存泄露，同時增加View最大數量閾值、內存告警自動釋放邏輯等。

3. 內容頁整體架構

1. 易于擴展業務節點 & 組件類型

對于增加關鍵的業務節點用于組件業務處理，我們只需擴展delegate中的方法，在相關組件中實現。內容頁Controller中在相應位置，通過統一函數觸發廣播代理方法即可。對于增加組件來說，只需創建組件完全獨立的MVC代碼，實現數據解析Model并實現滾動復用delegate，在組件Controller中實現delegate中需要的方法等待調用，以及初始化時在內容頁注冊即可。刪除組件完全無需操作內容頁，刪除獨立的MVC結構并停止注冊即可。

2. 易于擴展內容頁類型

為了實現內容頁擴展區的靈活復用，在HybridPageKit中也擴展了非WebView類型的內容頁。就像文中之前提到的，如果將WebView看做一個整體作為一個組件，基于ReusableNestingScrollview的位置動態管理，完全可以替換成普通的View（類似Banner視頻內容頁），或者可擴展收起的View（問題回答頁面）甚至tableView等。所以整個App內各種類型的內容頁只需要簡單的配置，便可進行實現和組件復用。

3. 內容頁架構

結合ReusableNestingScrollview、WKWebViewExtension以及組件化的設計思路，HybridPageKit整體的架構如下：

通過繼承特殊的內容頁Controller并進行簡單的配置，即可生成不同類型的內容頁整體架構。框架內集成基本的Mustache解析和渲染。結合后臺數據，只需實現對應頁面中組件MVC邏輯即可。其中Model只需實現對應Protocol，Controller在內容頁中注冊，實現對應Protocol即可。

—— 幾十行代碼完成新聞類App多種形式內容頁

HybridPageKit ：一個針對新聞類App高性能、易擴展、組件化的通用內容頁實現框架。

基于ReusableNestingScrollview、WKWebViewExtension、以及本文中關于內容頁架構和性能的探索。

- 首屏加載速度優化 -

新聞類App內容頁，在Native的頁面框架下，基于WebView進行加載和渲染。所以，從優化的角度就延伸出兩個維度，即從Web的維度優化，以及從Native的維度優化。

1. Web維度的優化

• WKWebView的復用 :

  通過WKWebView的復用，極大的縮短了WebView從創建到渲染結束的時間。

• 利用HTTP緩存 :

  對于內容WebView中必要的CSS以及JS，以及必要的基礎Icon，可以通過設置HTTP緩存，依靠瀏覽器自身緩存提高效率。同時通過資源md5校驗以保證刷新資源。

• 減少資源請求并發 :

  通過Native化全部非文字類的內容，Web頁面只加載最近本的Html內容，減少了業務邏輯的資源請求和并發。

• 減少Dom & Javascript復雜度 :

  通過Native化全部非文字類的內容，極大的減少了Dom的復雜度、CSS的復雜度以及過多的JS業務邏輯。

• 其它Web優化通用方法 :

  精簡Javascript，使用iconFont，CSS & Javascript文件壓縮等

2. Native維度的優化

• 數據模板分離，資源并行加載 :

  基于后臺數據以及Native化組件，內容頁Html中模板與數據分離，使得全部資源如圖片視頻等都可以通過Native在合適的時機異步并行加載。不依賴與Web的渲染。

• 預加載數據,延遲加載組件:

  對于內容頁關鍵內容（Webview）的拉取，大部分App都放到了列表頁中進行。進入內容頁時直接從Cache中取出內容模板，直接交給WebView渲染。基于ReusableNestingScrollview擴展豐富的狀態及二級緩存，在頁面滾動的過程中各個組件也可以精確的實現按需加載、預加載等邏輯。

• Native化非文字UI，及組件化實現負載均衡 :

  WebView中非文字類UI Native化，極大的縮短了展示所需的流程，減少了進程間通信，減少了I/O及圖片編解碼邏輯，提高了類似圖片類的UI展示速度。

  組件的解耦與自管理，以及廣播delegate的實現，為組件的按需加載、按優先級加載提供了基礎。對于內容頁的各個組件來說，在內容頁展示之前大部分是不需要初始化、數據拉取以及渲染的。組件化之后的組件可以根據業務優先級，在不同的關鍵生命周期回調中實現業務邏輯，以減輕內容頁創建、模板拼接以及WebView渲染的壓力。簡單的舉例，由于內容WebView幾乎都大于一屏，擴展區中的全部組件都可以在WebView渲染結束后進行View創建、網絡拉取和渲染等，這樣即不影響用戶的使用，同時極大的釋放了渲染結束前的網絡、IPC及CPU壓力，提高首屏展示速度。

• 組件的滾動復用 & 全局復用 & Model緩存Frame:

  基于ReusableNestingScrollview擴展數據Model，緩存對應View的Frame信息，結合View的滾動復用，極大的減少了UI布局的邏輯和計算。頁面內組件的滾動復用及頁面間的組件復用，也同時減少了組件View的初始化耗時。

• 其它通用方法:

  基于App的技術實現和業務邏輯的優化，如異步執行業務邏輯、 圖片編解碼優化及資源緩存，DNS緩存等。

3. 整體優化方法

綜上，從一個內容頁在列表上的點擊，到WebView渲染結束，最后到用戶的滾動操作，按照時間的順序，全部的優化策略如下圖：

—— 幾十行代碼完成新聞類App多種形式內容頁

HybridPageKit ：一個針對新聞類App高性能、易擴展、組件化的通用內容頁實現框架。

基于ReusableNestingScrollview、WKWebViewExtension、以及本文中關于內容頁架構和性能的探索。

想和我一起全面了解新聞類App的開發，點我學習

- 拾遺及Tips -

對于新聞類App內容頁的完整的解決方案，還有一些基本的技術點，比如模板引擎及模板拼接的模塊、JSApi注入及管理的模塊等等，由于篇幅所限，暫且不做深入的展開。

• 新聞類App的內容頁，除去基本的渲染HTML數據外，同時也需要支持服務于活動、運營的臨時H5頁面。這些頁面為了和Native進行交互，在自定義JSApi注入、JSBridge的選擇、后臺下發domain黑白名單、以及相關的安全性考慮也是整個實現中重要的一環。同時由于WKWebView支持復用回收，加載本地Html類型的WebView應該與加載H5的WebView在不同的回收復用池分開管理。

• 對于內容頁圖片的管理，絕大多數App都將之納入了App統一的圖片管理體系中。無論使用哪個開源圖片庫，在緩存策略上，盡量將內容頁圖片的緩存策略與其他的有所區分，或者使用LRU + FIFO的緩存策略，避免進入內容頁大量圖片占用緩存空間，導致列表圖片釋放。同時從使用的角度來說，重復進入同一篇文章的場景也不會頻繁的出現。

• 由于各個App的數據接口和技術選型不同，在HybridPageKit中只簡單的實現了基于Mustache的模板拼接，主要是由于它的logic-less、多終端集成的方便以及開源社區的活躍。對于這部分邏輯，需要根據后臺數據的格式及業務需求自定義的擴展。

內容頁整體的實現和優化，依賴整個App的技術實現和結構，在實現和優化的過程中，還有許多權衡和妥協，以及許多通用的、細節的優化，這里就不一一贅述。

- 寫在最后 -

文章全部的探索及分析的實現，除對應業務邏輯外，應用封裝成三個框架：HybridPageKit、ReusableNestingScrollview以及WKWebViewExtension。最終可以通過幾十行代碼，完成新聞類App多種形式的、高性能、易擴展、組件化的內容頁實現。

有任何疑問，歡迎提交 issue， 或者直接修改提交 PR!

—— 幾十行代碼完成新聞類App多種形式內容頁

HybridPageKit ：一個針對新聞類App高性能、易擴展、組件化的通用內容頁實現框架。

基于ReusableNestingScrollview、WKWebViewExtension、以及本文中關于內容頁架構和性能的探索。

想和我一起全面了解新聞類App的開發，點我學習