前言

httpdns是基于Http协议的域名解析服务,用于替代基于UDP协议向运营商Local DNS发起解析请求的传统方式,目标是解决域名劫持和跨网访问等问题。

httpdns的接入

传统的使用Local DNS的方式,我们只需要在url中指定hostname;网络库帮我们做了域名解析、ttl缓存管理,我们不需要关心底层的流程。

但当使用httpdns,就需要我们自己向httpdns发起http请求,获取到域名对应的ip。一般商业的httpdns sdk都会提供域名解析成ip的方法,一般的开发者接入httpdns还是需要做以下工作:

  1. 从URL中提取hostname,通过httpdns sdk获取到对应的IP
  2. 将URL中的hostname替换成IP
  3. 设置请求Header的Host字段
  4. 如果请求的是HTTPS,修改证书的域名验证策略

android端有三个网络基础库,具体的接入方式会有差异:

  • apache httpclient
  • http urlconnection
  • okhttp

对于最后一个okhttp,由于它本身提供的设置外部dns的api,接入最简单,只需要简单的实现okhttp提供的lookup方法即可;但针对apache和urlconnection,就只能采取显式将url中的hostname替换成ip的方式了,然后添加Host头和HTTPS证书验证策略。但由于apache httpclient和urlconnection在设计之初,就没有考虑外部设置dns的策略,进行相关的接入时,总有各种异常case需要处理,比如apache http client在实现上,使用的是url中的ip信息作为cookie存储管理的key …


查看全文
Posted by 郑文

旧文一篇,看到移动开发前线推送了MultiDex工作原理分析和优化方案,也将我们的MultiDex启动优化思路分享给社区

MultiDex存在的问题

我们经常说的MultiDex,可以分成运行时和编译时两个部分:

  • 编译时的分包机制,将app中的class以某种策略将class分散在多个dex中,目的是减少为了第一个dex也就是main dex中包含的class。

  • 运行时: app启动时,虚拟机只加载main dex中的class。app启动以后,使用Multidex.install API,通过反射修改ClassLoader中的dexElements加载其他dex。

MultiDex机制的出现本身是为了避免出现app 65535问题的出现,但随着业务逻辑的增长,以及不合理的模块划分,可能会导致main dex的方法数也超出了65535,这就导致了main dex capacity exceeded异常。

此外,Multidex的接入额外还会对app的启动性能造成影响。Multidex在install时需要加载dex,首次启动时还需要做odex的转换,而这些都是在ui主线程中完成。 根据 Carlos Sessa的测试,启用multidex后,4.4或以下的设备,app的启动时间平均会增加15%,更严重的情况,甚至在启动时候会出现了黑屏。

目前部分app采取的策略是,放弃掉Multidex的 …


查看全文
Posted by 郑文