移动开发工程师,现在在研究混合开发技术。
“IP直连方案”主要在于解决DNS污染、省去DNS解析时间,通常情况下我们可以在项目中使用 NSURLProtocol 拦截 NSURLSession 请求,下面将支持 Post 请求中面临的一个挑战,以及应对策略介绍一下。
weex 旨在兼顾web动态性与native的用户体验,如果想将两者的优势最大化,那么缓存就显得格外重要,本文介绍如何利用缓存,实现weex页面迅速打开,甚至“秒开”的效果。
【前言】KVO API设计非常不合理,于是有很多的KVO三方库,比如 KVOController 用更优的API来规避这些crash,但是侵入性比较大,必须编码规范来约束所有人都要使用该方式。有没有什么更优雅,无感知的接入方式?
**Table of Contents** *generated with [DocToc](https://github.com/thlorenz/doctoc)* - [前言](#%E5%89%8D%E8%A8%80) - [实现原理](#%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86) - [优化:降低50%以上误报机率](#%E4%BC%98%
如果 app 连续 crash 两次无法启动,用户往往会选择卸载。本文介绍如何该类 crash 的自修复技术。
在开发中 `unrecognized selector sent to instance XXXXX` 是非常常见的 crash 类型。这篇博文主要介绍如何在客户端自修复该问题,并进行原理解析。
无论是从 Local DNS 解析域名,获取到 IP 列表,还是从第三方的 DNS 解析服务中,获取到域名对应的 IP 列表。我们获得多个 IP 后,总是想选取一个最优的 IP 使用,本文主要探讨如何在客户端探测 IP 的连接性以及连接速度,保证返回可用性最好的IP,以达到“IP优选”的目的。
## WEEX + HTTPDNS iOS解决方案 由于`WebView`并未暴露处设置DNS的接口,因而在`WebView`场景下使用`HttpDns`存在很多无法限制,但如果接入`WEEX`,则可以较好地植入`HTTPDNS`,本文主要介绍在`WEEX`场景下接入`HTTPDNS`的方案细节。 在`WEEX`运行时环境下,所有的逻辑最终都会转换到`Native Runtime`中执
## WEEX + HTTPDNS iOS解决方案 由于`WebView`并未暴露处设置DNS的接口,因而在`WebView`场景下使用`HttpDns`存在很多无法限制,但如果接入`WEEX`,则可以较好地植入`HTTPDNS`,本文主要介绍在`WEEX`场景下接入`HTTPDNS`的方案细节。 在`WEEX`运行时环境下,所有的逻辑最终都会转换到`Native Runtime`中执
## WEEX + HTTPDNS iOS解决方案 由于`WebView`并未暴露处设置DNS的接口,因而在`WebView`场景下使用`HttpDns`存在很多无法限制,但如果接入`WEEX`,则可以较好地植入`HTTPDNS`,本文主要介绍在`WEEX`场景下接入`HTTPDNS`的方案细节。 在`WEEX`运行时环境下,所有的逻辑最终都会转换到`Native Runtime`中执
本文主要介绍 HTTPS(含SNI) 业务场景下在 iOS 端实现 “IP直连” 的通用解决方案。
本文主要介绍,防 DNS 污染方案在 WebView 场景下所遇到的一些问题,及解决方案,也会涉及比如:“HTTPS+SNI” 等场景。
本文将讨论下类似这样的问题: WKWebView 对于 Cookie 的管理一直是它的短板,那么 iOS11 是否有改进,如果有,如何利用这样的改进? 采用 IP 直连方案后,服务端返回的 Cookie 里的 Domain 字段也会使用 IP 。
302等 URL 重定向业务场景需要解决的问题:302 等重定向状态码,如何正确执行跳转逻辑,要求跳转后,依然需要执行 IP 直连逻辑,多次 302,也能覆盖到。
SNI(单IP多HTTPS证书)场景下,iOS上层网络库 `NSURLConnection/NSURLSession` 没有提供接口进行 `SNI 字段` 配置,因此需要 Socket 层级的底层网络库例如 `CFNetwork`,来实现 `IP 直连网络请求`适配方案。