History Management According to the standard definition, the page manages a joint Session history, which contains the historical items of each sub-frame. Logically corresponds to the following relationship:
From the above look at three levels: Page,frame, and JS binding interface. The core of page loading is done by frame through Frameloader, Historycontroller and Backforwardcontroller can be regarded as the interface of page load history operation. Through Historycontroller in the frame hierarchy, the page hierarchy is backforwardcontroller for historical operations.
Backforwardclient and Historyitem store the specific contents of the historical items. The change message for the history item is sent by Frameloaderclient (adapted to the WebKit layer).
The main class relationships in the page hierarchy are as follows:
A historyitem can be understood as the state defined in the standard. The relationship between Historyitem storage and joint session history is represented on its stored member variables:
M_target, M_parent stores the frame name, which can be obtained from frametree to the frame, representing the historyitem corresponding frame, and its parent frame.
The M_scrollpoint is the location currently displayed. If you jump through anchor, this value will be differentiated.
M_stateobject is the content that is manipulated by the pushstate and replacestate of the HTML5 history API.
The jsbinding layer is provided by the history through frame to JS service. At the frame level, frame operates primarily through Frameloader. The page jump operation is done by the navigatorscheduler of the frame. In HTML5 spec, the operation of the session history is concentrated in the Historycontroller, part of the logic scattered in navigationscheduler, such as Navigationscheduler:: The Mustlockbackforwardlist () function, and the processing logic for jumps within 1 seconds.
When the page forward and backward, the specific loading operation is frameloader as the core, Historycontroller and Backforwardcontroller at best is mainly storage operations. Changes in history also need to be distributed to the WebKit and UI layers by frameloaderclient and its implementation on each platform (Webhistorydelegate is the delegate of WebView receiving historical information about Mac OS).
When the page executes pushstate via JS, a historyitem with this state is generated in the Historycontroller and then added to Backforwardlist ( backforwardclient). Here is its timing diagram:
Here is the timing diagram for sending popstate messages to JS when the page jumps:
Specific behavioral logic, read through the standard definition is appropriate. The attached link is as follows:
Https://html.spec.whatwg.org/multipage/browsers.html
From the WebKit external adaptation, the specific implementation of the difference is relatively large, but will be a historical change in the message notification to correspond to the UI of the forward and backward operation and status display, so as to maintain consistency.
For example, under Mac OS, when a history changes, Webframeloaderclient::updateglobalhistory () is notified to WebView using the following method:
if ([view Historydelegate]) {webhistorydelegateimplementationcache* implementations = Webviewgethistorydelegateimp Lementations (view); if (implementations->navigatedfunc) {Webnavigationdata *data = [[Webnavigationdata alloc] Initwithurlstring : Loader->url () title:nilornsstring (Loader->title (). String ()) Originalrequest:loader->originalrequestcopy (). Nsurlrequest (Updatehttpbody) Response:loader->response (). Nsurlresponse () Hassubstitutedata: Loader->substitutedata (). IsValid () Clientredirectsource:loader->clientredirec Tsourceforhistory ()]; Callhistorydelegate (Implementations->navigatedfunc, view, @selector (webview:didnavigatewithnavigationdata: Inframe:), data, M_webframe.get ()); [Data release]; } return; }
The history item creation and notification process is as follows:
Reprint Please specify source: Http://blog.csdn.net/horkychen
The realization of WebKit history management
