AndroidのOkHttp、コードリフティング安定性の要求行OkHttp

OkHttpは間違いなくAndroidの開発は、ネットワークライブラリに依存しなければならない各プロジェクトは、我々は大幅に符号化効率を高めるために非常に便利で効率的な処理のネットワーク要求とすることができます。しかし、時には、私たちはOkHttp使用することは、このような問題が発生します

A.クラッシュスタックトレース
E AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
E AndroidRuntime: Process: com.example.okhttpexceptionsample, PID: 13564
E AndroidRuntime: java.lang.NullPointerException: blablabla
E AndroidRuntime:    at com.example.okhttpexceptionsample.MainActivity$createNPEInterceptor$1.intercept(MainActivity.kt:61)
E AndroidRuntime:    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
E AndroidRuntime:    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
E AndroidRuntime:    at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
E AndroidRuntime:    at okhttp3.RealCall$AsyncCall.run(RealCall.kt:136)
E AndroidRuntime:    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
E AndroidRuntime:    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
E AndroidRuntime:    at java.lang.Thread.run(Thread.java:784)
II。なぜクラッシュ

上記のスタックトレースから、我々はNullPointerExceptionが発生した分析することができます。クラッシュが発生しました。

待って、私はそれを持っている異常な状況にOkHttp契約を覚えています。

ああ、確かに、このような異常のコールの発生などの例外を処理する場合があるOkHttp onFailure。たとえば、以下の説明のコールバックの内容。

interface Callback {
  /**
   * Called when the request could not be executed due to cancellation, a connectivity problem or
   * timeout. Because networks can fail during an exchange, it is possible that the remote server
   * accepted the request before the failure.
   */
  fun onFailure(call: Call, e: IOException)

  /**
   * Called when the HTTP response was successfully returned by the remote server. The callback may
   * proceed to read the response body with [Response.body]. The response is still live until its
   * response body is [closed][ResponseBody]. The recipient of the callback may consume the response
   * body on another thread.
   *
   * Note that transport-layer success (receiving a HTTP response code, headers and body) does not
   * necessarily indicate application-layer success: `response` may still indicate an unhappy HTTP
   * response code like 404 or 500.
   */
  @Throws(IOException::class)
  fun onResponse(call: Call, response: Response)
}

はい。

唯一のIOExceptionの場合に対応OkHttp、
NullPointerExceptionがIOExceptionをのサブクラスではありません

クラッシュが発生した、処理されていません。

そして、何の解決策は、その崩壊が起こらないように、ユーザーはそれに干渉しない、ありませんか？実際には、それが可能です。

III。使用インターセプタ

package com.example.okhttpexceptionsample

import okhttp3.Interceptor
import okhttp3.Response
import java.io.IOException

/**
 * 对于Interceptor的intercept中可能出现的Throwable包裹成IOExceptionWrapper，转成网络请求失败，而不是应用崩溃
 */
class SafeGuardInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        try {
            return chain.proceed(chain.request())
        } catch (t: Throwable) {
            throw IOExceptionWrapper("SafeGuarded when requesting ${chain.request().url}", t)
        }
    }
}

/**
 * 将chain.proceed处理中发生的Throwable包装成IOExceptionWrapper
 */
class IOExceptionWrapper(message: String?, cause: Throwable?) : IOException(message, cause)

上記のコードは、私たちはどんなだろうThrowableにターンがIOExceptionWrapper（にIOExceptionが変装）、その後、OkHttpClientに追加しました

fun createOKHttpClient(): OkHttpClient {
        return OkHttpClient.Builder()
            .addInterceptor(SafeGuardInterceptor())
            .build()
    }

我々は再び変更されている、NPEコードを実行するにログオンする必要がある場合（もはやクラッシュログが、例外ログ）

W System.err: com.example.okhttpexceptionsample.IOExceptionWrapper: SafeGuarded=blablabla
  W System.err:   at com.example.okhttpexceptionsample.SafeGuardInterceptor.intercept(SafeGuardInterceptor.kt:12)
  W System.err:   at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
  W System.err:   at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
  W System.err:   at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
  W System.err:   at okhttp3.RealCall$AsyncCall.run(RealCall.kt:136)
  W System.err:   at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
  W System.err:   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
  W System.err:   at java.lang.Thread.run(Thread.java:784)
  W System.err: Caused by: java.lang.NullPointerException: blablabla
  W System.err:   at com.example.okhttpexceptionsample.MainActivity$createNPEInterceptor$1.intercept(MainActivity.kt:61)
  W System.err:   at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
  W System.err:   at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
  W System.err:   at com.example.okhttpexceptionsample.SafeGuardInterceptor.intercept(SafeGuardInterceptor.kt:10)
  W System.err:   ... 7 more

上記の注意すべき二つのこと

追加することインターセプタではなく、NetworkInterceptor
順序が重要であり、それは最初の位置に配置する必要があります
IV。何の問題

それは、当然のことながら、大幅にアプリケーションを要求する安定性と崩壊性を高めることができません。しかし、それはまた、いくつかの問題を持っていないですか？そのようなものとして
問題飲み込ま状況がない問題を識別するために助長されていません
確かに上記のような問題が存在する可能性があるが、我々は軽減するために、次の方法を使用するか、問題を解決することができます
SafeGuardInterceptorケースはどこデバッグを発見しやすく容易に解放のために適用されます
小さな問題の発見を容易にするために、可能な限り、別のビルドバリアント用に設定
よりインテリジェントなダイナミックなオープンな戦略を実装します。

ソフトウェア工学では、意思決定の多くは、トレードオフは、私たちが自分の選択のバランスをとることができ、特定の実施形態を反映しています。

私について

上記githubの上のほかのアンドロイドインタビューシニアコレクション
小さなパートナーの必要性は、クリックすることができ、私に私が取得リンク
非常にみんなと共通の進捗状況を共有したいです

現在、プログラマは、Androidの開発者が知識を共有するために、だけでなく、技術的な人々は個人的な要約、職場での経験、面接の経験を含め、育っ共有するだけでなく、あなたはあまり作る少し回り道を行ってみたいです。