共计 4820 个字符,预计需要花费 13 分钟才能阅读完成。
原文链接:https://blog.csdn.net/xiangzhihong8/article/details/96280254
4、第三方库解析
4.1、Retrofit 网络申请框架
概念:Retrofit 是一个基于 RESTful 的 HTTP 网络申请框架的封装,其中网络申请的实质是由 OKHttp 实现的,而 Retrofit 仅仅负责网络申请接口的封装。
原理:App 应用程序通过 Retrofit 申请网络,实际上是应用 Retrofit 接口层封装申请参数,Header、URL 等信息,之后由 OKHttp 实现后续的申请,在服务器返回数据之后,OKHttp 将原始的后果交给 Retrofit,最初依据用户的需要对后果进行解析。
retrofit 应用
1. 在 retrofit 中通过一个接口作为 http 申请的 api 接口
`public interface NetApi {
@GET("repos/{owner}/{repo}/contributors")
Call<ResponseBody> contributorsBySimpleGetCall(@Path("owner") String owner, @Path("repo") String repo);
}
`
2. 创立一个 Retrofit 实例
`Retrofit retrofit = new Retrofit.Builder()
.baseUrl("https://api.github.com/")
.build();
`
3. 调用 api 接口
`NetApi repo = retrofit.create(NetApi.class);
// 第三步:调用网络申请的接口获取网络申请
retrofit2.Call<ResponseBody> call = repo.contributorsBySimpleGetCall(“username”, “path”);
call.enqueue(new Callback<ResponseBody>() {// 进行异步申请
@Override
public void onResponse(Call<ResponseBody> call, Response<ResponseBody> response) {// 进行异步操作}
@Override
public void onFailure(Call<ResponseBody> call, Throwable t) {// 执行谬误回调办法}
});
`
retrofit 动静代理
retrofit 执行的原理如下:
1. 首先,通过 method 把它转换成 ServiceMethod。
2. 而后,通过 serviceMethod,args 获取到 okHttpCall 对象。
3. 最初,再把 okHttpCall 进一步封装并返回 Call 对象。
首先,创立 retrofit 对象的办法如下:
`Retrofit retrofit = new Retrofit.Builder()
.baseUrl("https://api.github.com/")
.build();
`
在创立 retrofit 对象的时候用到了 build()办法,该办法的实现如下:
`public Retrofit build() {
if (baseUrl == null) {
throw new IllegalStateException("Base URL required.");
}
okhttp3.Call.Factory callFactory = this.callFactory;
if (callFactory == null) {
callFactory = new OkHttpClient(); // 设置 kHttpClient
}
Executor callbackExecutor = this.callbackExecutor;
if (callbackExecutor == null) {
callbackExecutor = platform.defaultCallbackExecutor(); // 设置默认回调执行器
}
// Make a defensive copy of the adapters and add the default Call adapter.
List<CallAdapter.Factory> adapterFactories = new ArrayList<>(this.adapterFactories);
adapterFactories.add(platform.defaultCallAdapterFactory(callbackExecutor));
// Make a defensive copy of the converters.
List<Converter.Factory> converterFactories = new ArrayList<>(this.converterFactories);
return new Retrofit(callFactory, baseUrl, converterFactories, adapterFactories,
callbackExecutor, validateEagerly); // 返回新建的 Retrofit 对象
}
`
该办法返回了一个 Retrofit 对象,通过 retrofit 对象创立网络申请的接口的形式如下:
`NetApi repo = retrofit.create(NetApi.class);
`
retrofit 对象的 create()办法的实现如下:
`public <T> T create(final Class<T> service) {
Utils.validateServiceInterface(service);
if (validateEagerly) {
eagerlyValidateMethods(service);
}
return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class<?>[] { service},
new InvocationHandler() {private final Platform platform = Platform.get();
@Override public Object invoke(Object proxy, Method method, Object... args)
throws Throwable {
// If the method is a method from Object then defer to normal invocation.
if (method.getDeclaringClass() == Object.class) {return method.invoke(this, args); // 间接调用该办法
}
if (platform.isDefaultMethod(method)) {return platform.invokeDefaultMethod(method, service, proxy, args); // 通过平台对象调用该办法
}
ServiceMethod serviceMethod = loadServiceMethod(method); // 获取 ServiceMethod 对象
OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args); // 传入参数生成 okHttpCall 对象
return serviceMethod.callAdapter.adapt(okHttpCall); // 执行 okHttpCall
}
});
}
`
4.2、图片加载库比照
Picasso:120K
Glide:475K
Fresco:3.4M
Android-Universal-Image-Loader:162K
图片函数库的抉择须要依据 APP 的具体情况而定,对于重大依赖图片缓存的 APP,例如壁纸类,图片社交类 APP 来说,能够抉择最业余的 Fresco。对于个别的 APP,抉择 Fresco 会显得比拟重,毕竟 Fresco3.4M 的体量摆在这。依据 APP 对图片的显示和缓存的需要从低到高,咱们能够对以上函数库做一个排序。
Picasso < Android-Universal-Image-Loader < Glide < Fresco
2. 介绍:
Picasso:和 Square 的网络库一起能施展最大作用,因为 Picasso 能够抉择将网络申请的缓存局部交给了 okhttp 实现。
Glide:模拟了 Picasso 的 API,而且在他的根底上加了很多的扩大(比方 gif 等反对),Glide 默认的 Bitmap 格局是 RGB_565,比 Picasso 默认的 ARGB_8888 格局的内存开销要小一半;Picasso 缓存的是全尺寸的(只缓存一种),而 Glide 缓存的是跟 ImageView 尺寸雷同的(即 5656 和 128128 是两个缓存)。
FB 的图片加载框架 Fresco:最大的劣势在于 5.0 以下 (最低 2.3) 的 bitmap 加载。在 5.0 以下零碎,Fresco 将图片放到一个特地的内存区域(Ashmem 区)。当然,在图片不显示的时候,占用的内存会主动被开释。这会使得 APP 更加晦涩,缩小因图片内存占用而引发的 OOM。为什么说是 5.0 以下,因为在 5.0 当前零碎默认就是存储在 Ashmem 区了。
3. 总结:
Picasso 所能实现的性能,Glide 都能做,无非是所需的设置不同。然而 Picasso 体积比起 Glide 小太多如果我的项目中网络申请自身用的就是 okhttp 或者 retrofit(实质还是 okhttp),那么倡议用 Picasso,体积会小很多(Square 全家桶的干活)。Glide 的益处是大型的图片流,比方 gif、Video,如果你们是做美拍、爱拍这种视频类利用,倡议应用。
Fresco 在 5.0 以下的内存优化十分好,代价就是体积也十分的大,按体积算 Fresco>Glide>Picasso
不过在应用起来也有些不便(小倡议:他只能用内置的一个 ImageView 来实现这些性能,用起来比拟麻烦,咱们通常是依据 Fresco 本人改改,间接应用他的 Bitmap 层)
4.3、各种 json 解析库应用
参考链接:https://www.cnblogs.com/kunpe…
(1)Google 的 Gson
Gson 是目前性能最全的 Json 解析神器,Gson 当初是为因应 Google 公司外部需要而由 Google 自行研发而来,但自从在 2008 年五月公开公布第一版后已被许多公司或用户利用。Gson 的利用次要为 toJson 与 fromJson 两个转换函数,无依赖,不须要例外额定的 jar,可能间接跑在 JDK 上。而在应用这种对象转换之前需先创立好对象的类型以及其成员能力胜利的将 JSON 字符串胜利转换成绝对应的对象。类外面只有有 get 和 set 办法,Gson 齐全能够将简单类型的 json 到 bean 或 bean 到 json 的转换,是 JSON 解析的神器。Gson 在性能下面无可挑剔,然而性能下面比 FastJson 有所差距。
(2)阿里巴巴的 FastJson
Fastjson 是一个 Java 语言编写的高性能的 JSON 处理器, 由阿里巴巴公司开发。
无依赖,不须要例外额定的 jar,可能间接跑在 JDK 上。FastJson 在简单类型的 Bean 转换 Json 上会呈现一些问题,可能会呈现援用的类型,导致 Json 转换出错,须要制订援用。FastJson 采纳独创的算法,将 parse 的速度晋升到极致,超过所有 json 库。
综上 Json 技术的比拟,在我的项目选型的时候能够应用 Google 的 Gson 和阿里巴巴的 FastJson 两种并行应用,如果只是性能要求,没有性能要求,能够应用 google 的 Gson,如果有性能下面的要求能够应用 Gson 将 bean 转换 json 确保数据的正确,应用 FastJson 将 Json 转换 Bean
点击下方链接收费获取 Android 进阶材料:
https://shimo.im/docs/tXXKHgdjPYj6WT8d/