One, foreword

In the era of mobile Internet, web pages are still an important medium for content display, which cannot be separated from the support and development of WebKit browsing kernel technology. On iOS, developers need to use the WKWebView framework to interact with WebKit. Although Apple officially provides apis and instructions for WKWebView, it is not enough to meet the needs of developers, and we are still struggling with various complex scenarios, and solutions are not easy to find. At this point, excellent developers turned to Apple’s open source WebKit kernel code to find a solution to the puzzle, but found that there are still many difficulties and frustrations, the main problems are as follows:

1. The kernel source code is complex and difficult to understand: several gigabytes of source code, and the lack of key code notes and instructions, tracking and analysis of the workload; The system is compatible with more branches, a piece of code may distinguish iOS, Mac, embedded and other branches; Historical code or experimental features more, resulting in the source code is not easy to trace the logic.

2. Failure to combine business code analysis: Abnormal problems tend to occur in complex scenarios. Without the combination of business codes, problems cannot be repeated, so we cannot locate the problem and are prone to guess the cause and try to repair it by changing solutions.

Whether you want to explore the WebKit source code out of interest or for the above reasons, this article will help you get started quickly. Next, we will be in accordance with the source code download, source code compilation, create debugging engineering, source code actual combat analysis steps to help you browse the kernel to explore the road.

Download the source code

Before compiling and debugging, we first need to obtain a copy of Apple’s official WebKit source code.

• Github download (recommended) : github.com/WebKit/WebK…

• Download from WebKit.org/

After downloading the WebKit project, open it through Xcode (Xcode is an iOS application development tool officially recommended by Apple).

WebKit project directory

The gtest/MiniBrowser/MobblieMiniBrowser/TestWebKitAPI/WebKitTestRunner repository is the test repository. For compilation efficiency reasons, it is usually not necessary to compile the test repository. Since the rest of this article describes how to effectively leverage these test repositories, we chose to do all-source compilation here.

Third, source code compilation

With the source code in hand, let’s look at the command line and how Xcode is compiled.

This article recommends compiling using the command line first and then using Xcode. In practice, command line compilation makes it easier to trace specific exceptions if errors occur during compilation.

1. The WebKit directory for Embedded Builds downloads has a Tools/Scripts directory with various Scripts including Scripts for building WebKit using the command line, One of the most important scripts is configure-xcode-for-Embedded development, which runs the following command on the Mac terminal console:

sudo Tools/Scripts/configure-Xcode-for-embedded-development
Copy the code

This script is needed because iOS is an embedded platform, and Xcode uses this script to build the command-line tools needed to build WebKit for the embedded platform. Otherwise, the following error will be reported when compiling projects such as JavaScriptCore: ‘com.apple.product-type.tool’, but there’s no such product type for the embedded platform, can’t find the corresponding architecture.

2) Compile through Xcode and set the location of the build product

After opening the project, select Xcode’s File menu, select Workspace Settings, and then open the Workspace Settings window, as shown below:

Next, select the Advanced button, open the following window, press the red box to configure the project build directory as WebKitBuild, and click Finish:

Now that the preparation is finally complete, we can start compiling.

3) Start compiling

First check the All Source option, configure Scheme to select the emulator to run, and then click Xcode’s Build button to start building.

Please wait patiently here, the first compilation takes a long time, the test in this paper is on the I5 processor 8G memory Mac Pro machine test, test full source compilation took 1h. After the compilation is successful, a warning will pop up indicating that MiniBrowser is unavailable (belonging to Mac application project), which can be ignored. At this point, the kernel compilation is finished, and then we continue to enter the next step, creating debugging projects and exploring source code.

4. Create a debugging project

In this paper, two types of debugging requirements are distinguished. Official Demo project and custom project are used for debugging respectively, as shown below.

1) Understand WebKit operating mechanism and source code: use official Demo project debugging

Once compiled, there will be a MobileMiniBrower APP in our project artifact WebKitBuild directory. At this point, we can select MobileMiniBrowser APP from the project Scheme configuration for project construction. The APP is apple’s official browser Demo (as shown below), which can perform address input, forward/backward, multi-tab and other functions through the address bar. Breakpoint testing can be done in the source code.

2) Analyze actual business problems: use custom project debugging

In view of such requirements, we need to replace the system’s WebKit.framework with the compiled webKit. framework as follows:

1. First, create a new Project with Xcode, TestWKWebView in this example, and add this Project to WebKit’s Project space, WebKit.xcworkspace. Also output to the WebKitBuild directory.

2. After doing the above Settings, you can write a test program, in the test program to hit the breakpoint, then you will find that the system WebKit library has been replaced, breakpoint can jump source code, you can happily explore the source code.

After this step, you can find that WebKit source code is huge, even if the code run, how to break the analysis problem is still difficult to control. Therefore, we need to supplement and understand some knowledge points, this article will enter the actual combat link, with Demo project analysis, to provide you with the idea of source code analysis.

Five, source code actual combat analysis

1) WebKit’s multi-process mechanism

In the iOS system, one application usually has one process. However, in the development of WebKit, the concept of multi-process is introduced based on stability and security considerations to avoid the impact of a single page exception on the overall app operation. Firstly, this paper briefly introduces several common WebKit processes, as shown below.

• UIProcess — the process in which the application resides, WKWebView code and the WebKit framework are loaded into your process space;

• WebContent — also known as WebProcess, the location of JS and DOM memory allocation, i.e. the process of WebContent rendering and JS execution;

• Network Process – Responsible for issuing the underlying Network requests associated with Web requests;

• Storage Process – Storage for database and service workers.

Next, we use two demos for kernel analysis:

Demo1 — Single WebView model:

In the Demo1 project, we simply used a WKWebView to load the network. Taking baidu home page as an example, after running the project, click the “Show the Debug Navigator” option in the debugging mode, which is the resource analysis module under DEBUG.

Now we can look at CPU, memory, disk, network usage for each process, and of course we can do Instruments analysis.

The process distribution is as follows:

Demo2 — Multiple WebView model:

Use multiple WKWebViews for network loading, each page loaded, create a new WKWebView instance.

The process distribution is as follows:

Combined with the above Demo project, we can have an intuitive understanding:

1. The WebContent process corresponds to each newly opened web page, which can be reused depending on the memory condition. The abnormality of a WebContent process does not affect the main APP process, and the common abnormal phenomenon is blank screen.

2. UIProcess is the process where app is located. WKWebView provides a large number of apis in this process for developers to interact with the kernel, which is also the most familiar part of developers.

3. NetWorking processes, no matter how many WKWebView or single WKWebView scenarios, have only one NetWorking process. This design is mainly convenient for network request management and ensure the consistency of network cache and cookie management.

Apple’s official document description: the configuration of the same WKProcessPool multiple WKWebView share the same WebContent process, namely can configure WebContent process only (developer.apple.com/documentati…). .

However, the comments in the source dock file are inconsistent with the official document. The source dock file describes that multiple WkWebViews configured with the same WKProcessPool share the same WebContent process pool. This configuration does not limit the number of WebContent processes, but shares the process pool.

From the actual Demo test, the official document description is not accurate, we will refer to the source note.

With the above understanding, let’s look at the Directory of WebKit files under Xcode. The directory is also reasonably divided according to the process responsibilities.

Therefore, in the debugging process, in addition to global search or single step breakpoint debugging according to the known associated API or code stack, we can also combine the responsibilities of the three processes for problem analysis and search. In addition, since you can view the CPU, memory, disk, network and other states of each process, there are performance requirements for this aspect, you can use to view the specific resource consumption of each process when a web page is loaded.

2) TestWebKitAPI project

Using the source code project, in addition to code analysis, apple system also provides a large number of system API related functional tests, which are implemented based on the gtest framework and integrated into the TestWebKitAPI project. In practice, TestWebKitAPI project can be used for some interface analysis and testing according to the following ideas:

1. Learn about the test cases of various apis (including private apis). Through code demonstrations and descriptions, we can have a deep understanding of the usage specifications of interfaces and better understand the DESIGN ideas of APIS.

2. Gtest is a cross-platform (Liunx, Mac OS X, Windows, Cygwin, Windows CE and Symbian) C++ unit testing framework published by Google. It can write C++ test code on different platforms. The GTest framework provides a wealth of assertions, fatal and non-fatal judgments, parameterization, “death tests,” and more. There are a large number of gtest framework based test code accumulation in the WebKit kernel source code. When we do some trick operations, it is also a good choice to do automatic testing based on TestWebKitAPI project.

Six, Tips,

• WebKit source debugging may not be used in general, but for the analysis and solution of WebKit complex problems, combined with business to explore and analyze WebKit source code, or there is a certain significance.

• In particular cases, developers may make special use of some apis, and breakpoint debuggable source code can help us better avoid risks.

• Apple officially prohibits the replacement of WebKit kernel on the real machine, we can compile the corresponding real library, but cannot install and debug, so the content in this article is carried out in the emulator.

• Webkit source code is constantly updated, so the download and compilation process may encounter some incompatibility problems, generally can be solved by annotating the relevant incompatible code.

Seven, conclusion

This introductory article does not go into the critical technical analysis of the WebKit kernel; you can now debug WebKit source code or use Instruments to analyze WebKit processes while running Web applications. Hopefully this article has provided you with a more in-depth look at the stack details of using WKWebView applications and a better understanding of how the WebKit layer works. We will continue with a detailed look at key kernel technologies based on the business

Stay tuned:

In-depth understanding of WKWebView (Basics) – WKWebView load life cycle and proxy method analysis

Understanding WKWebView (Basics) – talk about cookie management

In-depth understanding of WKWebView (Basics) – Explore WebKit web resource caching

References:

1. WebKit source: github.com/WebKit/WebK…

2. WebKit official website: webkit.org/

Recommended reading:

Based on ETCD to achieve large-scale service governance application combat

Short video personalized Push project road to progress

Baidu Aipanfan data analysis system architecture and practice

— — — — — — — — — — END — — — — — — — — — — said baidu Geek Baidu public official technology, on-line! Technical dry goods · industry information · online salon · Industry conference recruitment information · Internal push information · technical books · Baidu surrounding welcome students to pay attention to