史上最全的Android面試題集錦（三）

原文連接：http://www.javashuo.com/article/p-phtjrmli-de.html

四、 第三方庫解析

4.一、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.二、圖片加載庫對比
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.三、各類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/