Use Charles Proxy to improve iOS development efficiency, charlesios

Use Charles Proxy to improve iOS development efficiency, charlesios

In the past, the most used tool for front-end development was Fiddler, which is very convenient for locating problems and simulating specific scenarios, greatly improving the development efficiency.
After iOS development, the biggest headache is that Fiddler does not have a Mac version. Fortunately, it found Charles Proxy, a good alternative tool. However, there are still many differences between it and Fiddler.
In addition, according to my incomplete observation, many iOS development engineers are not used to using HTTP packet capture tools ...... So I think it is necessary to write an article about Charles.

Trial & genuine & cracked

Charles is a paid software and can be used for free for 30 days. The trial version cannot be used for more than 30 minutes each time. during use, it will be interrupted for 5 seconds from time to time, and there will be a delay of 10 seconds at startup. Therefore, this trial solution is quite user-friendly for the majority of users, but when you need to perform packet debugging for a long time, it will be affected by Charles's forced shutdown.

We recommend that you purchase a genuine copy on the official website.

In addition, there is also a cracked version on the Internet, in the http://charles.iiilab.com/This site can download to Charels each version of the cracked version.

Use and Configuration

In view of Charles's many tutorials, this article does not intend to write an introductory tutorial, but introduces how to use Charles to improve development efficiency in common development scenarios.
For basic usage, refer to the iOS development tool-network packet analysis tool Charles.
Charles is essentially an HTTP proxy server, so you need to configure the proxy on the iOS device, but this also means that Charles can only capture the HTTP packet when the mobile phone is connected to WIFI, but not 3G/4G
In addition, it is strongly recommended that you briefly understand the HTTP protocol before using it. Charles is only a tool after all.

Use Cases Quickly locate the cause of a BUG

The most common problem in App development is that an interface needs to obtain and display data through the backend HTTP interface, and the test sister gave you a BUG to tell you that the interface has no data or data error.
The common mistake that Junior engineers make is to break the breakpoint Debug at the beginning or stick to it as a backend problem, which often results in a waste of time.
The correct method is to narrow down the scope of the cause of the BUG and locate the cause accurately. Generally, I will diagnose the cause in this order:
1. Have Charles caught the corresponding HTTP packet? Debug App code not found
2. Is the HTTP Response of the captured packet correct?
* If no response is returned, or the HTTP status is 4xx/5xx/, the responsibility is pushed to the backend.
* Does the response comply with the interface document definition? If the JSON field is completely invalid or the JSON field is missing, the responsibility is pushed to the backend.
* The response must comply with the definition, but an error message is returned. The HTTP request may be incorrect. If no error is returned, this document may contain errors and omissions ...... The responsibility is still pushed to the backend
3. The above are all correct, so the problem should be on the App side. Please start the debug code.

Remember to take Charles's packet capture results to the backend, which is easier to convince them than the information posted on the Xcode console.

Disable response caching

Note that Etag is enabled for many backend services (For details, refer to Wikipedia)
If AFNetworking is used, the response content may not be visible to Charles (304 the response has no body)
The solution is to Click Tools> No caching in the menu to enable the Global cache or disable the cache mode for a specific domain name.

Failed to quickly construct the request

Generally, the App will have a transitional effect when initiating a request (for example, sending a request to a chrysanthemum (for example, sending a chrysanthemum) handle), and an error will be prompted when the request fails.
However, in the development process, the request process for the same LAN is usually very short and generally does not fail. How can we debug these two interfaces?
One way is to use the OHHTTPStubs library to construct a response through Mock. The disadvantage is to write code, and the other is to use Charles.
Start the App to initiate a request, find the corresponding request in Charles, and right-click and select "Breakpoints 』

In this way, the next time the App initiates a request with the same URL, Charles will give you a breakpoint interface, you can choose Excute or Abort

If you want to debug the interface for failed requests, click Abort. The App will go to the HTTP request failure processing process.
If you want to debug the interface in the request, stop at the breakpoint interface. After debugging, click Abort or Excute.

In actual operation, we will find that Excute needs to be clicked twice to complete an HTTP request. Why? See the following section.

Construct expected response data

Some interfaces in the App often display different styles based on different backend data. In the development process, it is expected that the backend interface can return some specific data. If you look at the back-end students to "create data" for you, it is not realistic. The feasible method is still the two mentioned above. You can use OHHTTPStubs mock or use Charles
There are two ways to construct data in Charles:

Real-time modification response

As mentioned above, you need to click Excute twice to complete an HTTP Request. The reason is that Charles's breakpoint function provides the opportunity to modify HTTP Request and Response respectively.
Before clicking the second Excute, we can modify the Response content in real time, click "Edit Response", and select a suitable display panel to modify the content. For example, if the Response is in JSON format, JSON panel is recommended

Map local files

Another method is similar to OHTTPStubs. You can specify a local file as a response to a specific URL.
First, Charles needs to capture the corresponding HTTP request, right-click the request, and select the "Map Local" at the bottom 』

Then, select a local file in the pop-up window.

The biggest use of this method is that when the backend interface development is not complete, the App can complete the complete interface process "self-sufficiency.
In addition, Charles also provides the Import and Export function for existing Map rules, so that you can share the entire set of rules with other colleagues by clicking Tools> Map Local in the menu, on the displayed page, click Export.

Finally, I am trying to connect Map Local with the backend development process through tools to achieve App development more efficiently ...... Haha