[Android] GooleI/O 2018 Android App Open Source 囉~

來源：Android Dev Blog

   好啦，來說一下這個的重點，

   簡單說，這個App的源碼，可以當作一個Google本身對現代Android App的建議的具體呈現，所以如果想做類似功能或架構可參考這支App的源碼，當成小說看看也不錯 (喂~誰看的下去)


架構部分

• Presentation Layer，邏輯確實從View(Activity/Frgamnet)移開到ViewModel，然後使用LiveData跟Data Binding關聯資料跟UI。
• Data Layer，有Repository 處理全部的資料邏輯，處理來自不同來源的資料，包括從Firestore來的使用者資料，跟從SharedPreferences來的偏好設定資料。
• 兩層中間還有一個Domain Layer，負責分派不同的工作邏輯處理
• 用了Dagger2處理dependancy injection，用了Esspreso處理instrumentation test，用了 JUnit 和 Mockito 處理unit test。

Firebase部分，這支App用到以下：

•  Firestore：處理user data，會做同步跟快取。
• Functions： 用來跑backend code。預訂功能靠Functions去檢查使用者狀態跟空位，及在Firestore上做預訂。
• FCM：通知App Conference資料變更用，用了ping-and-fetch model。
• Remote Config：用來更新跟Conference資料無直接關係的資料，像是Wifi跟接駁車。(這個居然有這種用法...)

用了Kotlin+KTX寫。

用了很多Material Design元件，只是來不及用完整的Material Theming。

之後可能還會加上JetPack，當作安卓模範生展示 XD

專案GitHub在此。


Hey，看看這些你有多少還沒用呢？

[Android P] 正式版囉~

來源：Android Dev Blog、HK01、LTN、YahooNews、ExtremeTech、TheSun

8/6出正式，果然比前兩代早出呀...不到8/20就出了。

雖然8/6就出了，但其實目前也只有Pixel家族跟Essential PH-1能用，很多國家都買不到，就看成是一個較大規模的公測吧，其他廠商的話...

根據HK01，有Beta計畫的手機會在Q3完結前(9月底前)更新，其他肯升的大概是年底前：

"早前參加了 Android P Beta 計劃的手機，包括 Nokia 7 Plus、Oppo R15 Pro、Sony Xperia XZ2、Vivo X21UD、Vivo X21 及 小米 Mix 2s 等，再加上一眾合資格的 Android One 裝置，將會第三季完結之前陸續收到更新。其他廠商的合資格型號手機則會在今年底之前，可望得到 Android 9 Pie 的升級。"

根據LTN，Sony已有喊話，機款跟時程都有喊，只是根據經驗Z系列升完還會升中高階的。

"SONY Mobile 除了今年旗艦機款 Xperia XZ2 可升級 Android P 9.0，此外，首波公布可支援升級的 Xperia 機型名單，包括有：XZ2 Compact（台灣未引進上市）、XZ2 Premium、 XZ1、 XZ1 Compact、XZ Premium，主要以去年、今年的旗艦機款為優先。
預計將會在 9 月至 11 月期間，陸續推送升級更新服務"

根據YahooNerws，HTC目前只有喊機款，還沒壓時間。

"宏達電在官方推特（Twitter）證實，近期將升級Android 9的4款HTC手機包括今年旗艦機HTC U12+以及去年推出的HTC U11+、HTC U11、HTC U11 life（Android One版本），實際升級時間將另行公布。"

根據TheSun，Moto也有喊機種，時間壓秋天(9~11月)，

"In mid-August, Motorola confirmed that it would be serving up some delicious Android Pie on the following phones this autumn:
Moto Z3
Moto Z3 Play
Moto Z2 Force Edition
Moto Z2 Play
Moto X4
Moto G6 Plus
Moto G6
Moto G6 Play"

好啦，Samsung、LG、Huawei都沒喊聲，只是依慣例，最新旗艦肯定會升。

看今年何時可以在台灣買到有Android 9的手機囉~|


另外，App devs如果還有沒測完9的就加油好好測吧...沒有Pixel家族就用Emulator囉~

話說，今年Pixel家族應該會在台灣開賣吧...只是日期還沒出來呀..

[Android P] Final Preview，最終測試版囉~

來源：Dev Android

摘要：
這版是Beta 4，應該也就是Developer Preview 5 (DP5)，
最終行為變更版囉，API也沒變喔，跟Beta2(DP3)時一樣；
要測要改的要快喔！

要改的改完了，行有餘力可以試試P的新程式功能。


心得：

• DP5了，還是不知P是啥甜點?
• DP5了，App dev們有認真在測嗎?
• DP5了，照raod map上距離正式出版那麼近的距離，不知正是會不會早出，
  還是跟前兩代一樣8/21、或8/22出?
• 我的手機不知能不能升到P呀? 雖然有升到O，用Treble的測試App也說有支援Treble，應該有機會吧..

相關文章
[Android] Migrating Apps to Android P

[Android] 2018/7月份 版本分布

參考：Android dashboards

1. 最重要的，API22+破82%了，如果有新App要做，可以考慮min用22(5.1)了。
2. API21+破86%了，MIN真不能用22+的就用21+吧 XD
3. OREO(8.X)升為12.1%，出現在榜單10個月。
4. 牛軋糖(7.X)+為42.9%，出現在榜單已21個月了...
5. API24(7.0)以下全部下降。
6. API25(7.1)以上持續上升。
7. 還有4.1%的使用中裝置不能玩PMGO跟熊大農場。

上個月股哥沒公布，不是我偷懶沒PO喔..

另一個Dev會遇到的就是尺寸問題：
ldp還有0.3%(↓)、mdpi還有4.7(↓)%、最大比例在xhdpi 41.5%(↑)(所以如果想偷懶只放一份資源...嗯)

[Android] Google Cardboard VR

Google Cardbord雖然很早就出了(Android 4.4以上可用)，但我之前都沒試過，倒是HTC Vive有試過；最近買了個最便宜的紙盒來玩。

嗯...效果果然比HTC Vive差不意外。

實際體驗發現有以下缺點，就知為何要有更高階的VR。

• 可視範圍小，可清楚看的範圍更小。
  
• 手機很重，不用手扶光靠頭帶會歪。
  
• 戴眼鏡看會無法貼合，但盒子設計本來就不太貼臉。
  
• 然後可能會沾到臉上的油，所以要用久一點要洗臉完才能用。(不過這各家都一樣，只是紙板吸油看的到 XD)
  
• 不知如何操控；用Google Cardboard的官方App說"Press the Button"，但我盒子上沒按鈕可按呀..查了一下Cardbord 2代才有按鈕，1代Carboard是靠撥磁鐵，可參考知乎這篇。
  
• 看完眼睛有點不舒服，對焦出問題的感覺。
  
• 另外，距離看時手機點還是很大，看來再換更高密度的手機之前，我應該不用再買手機型VR頭盔了。給個比較，我的手機(Sharp S2)密度是420ppi，VIVE是448ppi、Oculus Rift是456ppi、VIVE pro是615ppi。我之前用VIVE時也是覺得點有點大，所以手機的點更大，如果有450ppi以上的手機的人，應該可以試試。
  
• 鏡片跟左右眼隔板容易脫位。
  
• 鏡片容易沾塵變髒，帶頭盔看灰塵會很明顯(只是這應該也是各家都一樣)。
  
• 坐著很難轉圈看360度，還是要站著用較方便(只是這應該也是各家都一樣)。
  

目前只有試用Google官方寫的App，包括：

• Cardboard
• YouTube360
• Cardboard 相機

---

下次看要買2代設計的頭套(非紙盒)，還是要買獨立(Stand alone)VR裝置呢？
就先試用看看現有App吧~

只是PLAY Award的Best VR App都是Daydream的，一般Carboard手機不能用 Q_Q..

[Android] 2018/5月份 版本分布

參考：Android dashboards

1. 最重要的，API21+破84%了，如果有新App要做，可以考慮min用21(5.0)了，因為5.0才開始原生支援Material Design呀....還有JobScheduler呀...
2. API19+破95%了，MIN真不能用21+的就用19+吧 XD
3. OREO(8.X)升為5.7%，出現在榜單8個月。
4. 牛軋糖(7.X)+為36.8%，出現在榜單已19個月了...
5. API24(7.0)以下全部下降。
6. API25(7.1)以上持續上升。
7. 還有5%的使用中裝置不能玩PMGO跟熊大農場。

另一個Dev會遇到的就是尺寸問題：
ldp還有0.4%、mdpi還有5.1%、最大比例在xhdpi 40.5%(所以如果想偷懶只放一份資源...嗯)

[Android] 2018/4月份 版本分布

參考：Android dashboards

1. 最重要的，API21+破84%了，如果有新App要做，可以考慮min用21(5.0)了，因為5.0才開始原生支援Material Design呀....還有JobScheduler呀...
2. 另外，API18+破95%了，只是API19+也有94.8%，MIN真不能用21+的就用19+吧 XD
3. OREO(8.X)升為4.6%，出現在榜單7個月。
4. 牛軋糖(7.X)+破35%，出現在榜單已18個月了...
5. 棉花糖(6.X)以下全部下降。
6. 牛軋糖(7.X)以上持續上升。
7. 還有5.2%的使用中裝置不能玩PMGO跟熊大農場。

上個月股哥沒公布，不是我偷懶沒PO喔..

另一個Dev會遇到的就是尺寸問題：
ldp還有0.4%、mdpi還有5.2%、最大比例在xhdpi 40.6%(所以如果只想放偷懶放一份資源...嗯)

---

其實我比較想各裝置寬高多少dp的統計，刻多dimen會用到，但...官方沒提供，看來只能自己統計囉..
法1：找銷售前10名的型號，跑測試程式看寬、高(W、H)各多少dp。
法2：自己的App埋統計回傳(Analytics) 高寬(W、H) dp數，如果App夠熱門，應該樣本不少。
法3：不管dp數，我就是要用px，那熱門機px就很好查了.

[Android] ARCore下批可能支援的手機

來源：Android Police

摘要：
新的ARCore App被拆包看，發現多了很多裝置代碼，可能是之後會支援的；
包括：Huawei的一些手機、Samsung的一些手機、Moto跟Xiaomi的一些手機。就是越來越多隻的意思。只是目前還不支援。

心得：
Google的ARCore只支援某些高階機，這次新的名單裡有比較中階的Samsung A5/A7，對捨不得花大錢的人是好消息吧...只是A5(2017)都下市了，也太舊...真希望有台灣可買到的中階手機支援呀...好多AR App不能玩 QQ
另外，Android P裡面應該直接塞ARCore呀...

[Android] Migrating Apps to Android P

來源：Dev Android

摘要：
Google教你怎麼測你的App在Android P是正常的~

-第一階段：現有App不改先在P測，可參考Google的品質和測試Guideline，及Table 1的主要變更項目。

-第二階段：targetSdkVersion 指到P，參考這篇 還有Table 2看要測啥改啥。

一二階段都測完就能(稍微)安心了，耶~


心得：
每一版Android都改不少呢，之前有想過看兩版差異報告，多到會吐血，看不下去，現在Google比較好了，會出行為變更整理，這次還出搬遷指導。

DP1三月已出，DP2五月出....DP5七月出，正式版Q3出，如果是8.0前的Android，其實從正式出在測應該還來的及，因為廠商至少要一個月客製化 (除了Google親兒子)。

但8.0 Oreo後，因為Project Treble，有可能升版速度會變快，就是這次9.0(P)就可知道Project Treble到底有沒有用囉~雖然他方向是對的，可是不是每個OEM廠商都有把每台8.X裝置加進去；但如果要保險起見，還是從DP4開始測吧~

[Firebase] Crashlytics已成為Firebase正式的Crash Reporter

來源：Google Dev Blog

摘要：

Crashlytics是Creash Reporter SDK第一名，有很多好功能，加入Firebase後功能多更多，3/19時已BETA完變正式囉~ 有以下重點：

-整合GA，做出麵包屑(Breadcrumbs)功能，讓你方便追user行為。

-有Crash insights，建議你這問題可能的原因跟解法。

-可以固定住最重視的版本，方便查看。

-有dSYM(XCode編iOS的一個對應檔)上傳工具。

-成為Firebase的預設崩潰報告，Firebase Crash Reporting只會活到9/28，有用快轉喔。

-有Fabric跟FrieBase的連結工具，兩個都有用可以連一下；只有用Fabric就還要等一下轉換工具。

心得：

Fabric Crashlytic的華麗報告畫面不知會不會變成Google的Material Design畫面？

Fabric的其他服務(eg. Answers)不知還會不會活著？

Google整合服務真的很快耶....不像之前某Y公司都買來放著。

[Cross-platform] 用Flutter也可做出跨平台百萬下載，評分4.3+的App

來源：Google Dev Blog

摘要：
設計公司POSSE用Flutter做了Hamilton的App(iOS、Android)，然後下載量超過一百萬，還有50萬以上活躍用戶，只要寫一次就可以賣兩邊，真是好棒棒，快來用Flutter吧~


心得：
之前聽過的跨平台方案都有缺點，整個開發體驗不如原生方案美好；而且針對官方OS、SDK、Design Guideline更新都可能會卡關，要找通用的輪子(別人寫好的元件)也較難。

只是我只試用過AIR、PhoneGap跟React Native，Xamarin沒試過。

AIR是很早期的Adobe行動解決方案，用Flex開發，現在應該沒人用了，因為要有runtime才能跑。

PhoneGap系列不用說，網頁就是慢。所以後來的跨平台才會都說要編成Native；

但React Native的開發環境跟Android原生開發體驗差很多，很像在開發網頁(用JSX)，應該蠻適合React或Node工程師轉行或兼職用。

Xamarin用的是C#，如果是C#工程師轉行應該不錯，只是聲勢目前低於React Native就是。

Flutter用的語言是Dart，一個用的人不算多的語言，但是相對Obj-C或JSX，對寫Java或C++的人來說應該好懂很多，至於為什麼用Dart，可看這篇。然後他號稱比ReactNative不容易遇到效能瓶頸，而且又有提供兩平台的UI元件(當然要兩邊符合設計要分開做啦)

至於Xamarin vs. React Native vs. Flutter，可以看這篇。

只是如果叫我三選一，我應該會說...可不可以讓我只寫Android，好啦，應該會先試試看Flutter吧..畢竟IDE跟AS比較像，語法對Java工程師又比較容易懂。

[Android] Android Studio 3.1 Stable

來源：Android Dev Blog

摘要：
Android Studio3.1出囉，支援更新的工具跟語法、跑得更快、提供更多好用工具，簡直好棒棒，快來更新吧~

心得：
看完文章跟影片，真的會覺得好棒棒，但還是有人反應App會跑不起來的問題，就目前沒時間蒐集災情跟測試，等有空再來試試囉~

[Android] Play商店會根據你的裝置推薦你完整版或Lite版App

來源：Android Police

摘要：
Play商店會根據你的裝置推薦你完整版或Lite版App (eg.FB & FB Lite)。

心得：
雖然不知怎麼做到的，可能是上架時要做些設定，但在台灣跟美國應該沒有那麼差的手機，不能跑完整版FB的。

如果真的要照顧低階手機的users，可以去買Android Go版手機來當測試機囉~
畢竟Google說Go是為了另一批十億users做的，啊...只是要去拍賣找找看了，因為應該不會在已開發國家賣..

[Android] 無Google認證裝置不能用Google服務囉~

來源：Engadget 中文版、Android Police

摘要： 3/16後出來的ROM，沒經過Google認證就不能用Google服務跟Google Apps囉~ 除非註冊該台的AndroidID 心得： 之後刷第三方ROM的手機跟大陸機 要裝PLAY服務難度又變高囉... 話說我只刷過官方ROM過...因為都不是買熱門旗艦機，沒啥客製ROM能選 XD

[Android] ScrollView包SwipeRefreshLayout包RecyclerView完全沒有畫面(RecyclerView does not show in SwipeRefreshLayout)

問題：
因為RecyclerView做的List上面還要放一些固定的東西，但為了小螢幕手機只好用ScrollView包起來，但為了下拉刷新只好加上SwipeRefreshLayout；
就是ScrollView包SwipeRefreshLayout包RecyclerView，然後...RecyclerView就不秀了，怎麼辦呀？

參考：StackOverflow、CSDN、ivankocijan.xyz、CSDN、珞璃之神

說明：
根據StackOverflow可知，SwipeRefreshLayout外面不能有ScrollView，那就反過來包；SwipeRefreshLayout包ScrollView，這樣就會秀囉。

只是這樣有幾個問題：

1. 轉圈(progress view)不在List上方，而是在ScrollView上方。
   =>在意的話，只能改成最外面不是SwipeRefreshLayout，而是CoordinatorLayout，參考CSDN、珞璃之神。
   
2. SwipeRefreshLayout會吃ScrollView手勢。
   =>可以判斷List到頭才啟用SwipeRefreshLayout，可參考CSDN。

好啦，如果2這做法SwipeRefreshLayout包ScrollView包RecyclerView大致沒問題，只是如果把ScrollView改為NestedScrollView，下面的RecyclerView做的List會全展開，如果想限制項目數，只能自己在程式裡設定高度了。

手機螢幕高度不夠用問題真的很難解，所以Material Design才會用CoordinatorLayout、AppBarLayout、CollapsingToolbarLayout等元件，讓畫面上方有些東西可以在捲動時縮起來，設計畫面時可參考看看囉。

另外，在查資料時發現NestedScrollView在舊版v4包有很多問題，這篇在用v4:27.1.0時已經沒那些問題了。

[Android] 禁止EditText跳出選單 (EditText disable popup menu )

問題：
我有一個EditText希望點文字不要跳出 [剪下(cut)/複製(copy)/貼上(paste)/分享(share)]選單，官方沒有提供設定介面耶，該怎麼辦？

參考：StackOverflow、簡書、CSDN

說明：
這個問題網路上查到有以下解，但是不同Android版本效果不同，所以我有針對Android 5.0、6.0、7.1、8.1做測試，就來看看吧~

1. android:longClickable="false" → 5.0+就沒用了，照樣可選 (據說3.1+就沒用了)。
   
2. android:textIsSelectable="false" → 5.0+就沒用了，照樣可選。
   
3. setCustomSelectionActionModeCallback設定自己改寫的 → 5.0+就沒用了，照樣可選。
   
4. setOnTouchListener針對ACTION_DOWN不做事 → 6.0+才有用。
   
5. 繼承EditText改寫isSuggestionsEnabled跟canPaste(參考StackOverflow) → 5.0~8.1都不會跳出全選的選單，但是點擊游標下方的小水滴(text select handle)還是會有貼上(paste)選單。
   
6. 自訂textSelectHandle(有單、左、右三個)為長寬0dp的矩形(參考StackOverflow) → 5.0~8.1都沒小水滴了，但全選時還是會跳選單。
   
7. 把EditText的mEditor抓出，把Insert handle跟Select handle關掉(參考簡書) → 5.0~8.1都有用。

其中，5有點危險，因為有改寫一個non-public method canPaste，如果Google改名就沒用了；
然後7更危險，還會被Android Studio警告，因為有用名稱抓內部資源，如果Google改名就沒用了，沒防呆還會當。

但是如果不用5或7似乎真的沒解。

所以...我是推薦用3+5+6，詳細就參考StackOverflow吧。

[Android] 離開App寫法 (Quit App)

問題：我想在Android App裡寫個離開(exit/ quit)功能，該怎麼寫呢？

參考：掘金1、掘金2、CSDN、StackOver1、龍崗山上的倉鼠、StackOverflow2、StackOverflow3、DevAndroid1、DevAndroid2、DevAndroid3、DevAndroid4

說明：
首先，Google不建議開發者自己殺掉整個App Process，而是交由系統處理，只要畫面全部finish()即可，而且有在各畫面的onDestroy()處理掉該處裡的東西(Thread、Handler、interface...)，這樣gc在整理時應該會順利清除。
甚至建議開發者不要在App裡加離開按鈕。

看來真有人照做，我看LINE、FB、FB Messenger都是在Root Activity(最下層的)時再按返回，就回到桌面，但其實process沒死，點icon再開，不會從啟動畫面(splash screen)進去。但如果從多工鍵(Overview Button)進去滑掉他的Task(這才真的殺掉process)，下次就會重啟。

另外，Play商店、GMail、YouTube不管有沒有滑掉，離開再點icon都是從同樣畫面進去，只是這三隻也都沒離開鈕，都是在Root Activity時再按返回，就回到桌面了。

---

但是，Dev是每個都那麼強嗎？不會少處理造成MemoryLeak而無法回收嗎?
或是說工程師的潔癖就是不要留太多垃圾等打掃阿姨(GC)來收呀 XD

如果，你不聽Google言，一定要做Quit App，就看掘金1、掘金2這兩篇選個方法做吧
裡面方法實在太多種了：

簡單說，殺掉process的方式有以下兩種，效果看來一樣..
System.exit(0); 跟 android.os.Process.killProcess(android.os.Process.myPid());
只是在做這件事之前，你要先把Activities關閉，才不會造成重啟。

所以啦，

• 如果你的Quit()寫在RootActivity，或只有一個Activity，只要把自己finish()然後再exit(0)，就好了。
  
• 如果你的Quit()寫在非RootActivity也可調用，那你就finish()所有Activities，然後再exit(0)吧。這方法很多，以下推幾種:
  如果你min=API 21+，可以用finishAndRemoveTask()；
  如果你min=16+且只有一個Task，可以用finishAffinity()；
  如果你min<16或有多個Tasks，那可用List保存Activities法。

[Android] OkHttp3 TLS 1.2 連線寫法

問題：我有WebService連線要用 TLS1.2，那用OkHttp要怎麼寫呢？

參考：OkHttp Wiki、OkHttp Issues、DevArea、DevAndroid-SSLSocket、DevAndroid-SSLContext

說明：
根據DevAndroid-SSLSocket的表格，API16+可支援TLS1.2但不是預設，到API20+才是，那這是甚麼意思呢？

就是說：

• 你Build.VERSION.SDK_INT<16就完全不能用TLS1.2。
• 你Build.VERSION.SDK_INT是16~19可以用，但要多寫一些code。
• 你Build.VERSION.SDK_INT>=20可以用，而且不用多寫code。

有沒有覺得MIN>20好棒呀 XD

那<16的支援方式我就不管了，畢竟現在2018了，新專案還要MIN 15也太低了..

---

那16~19的寫法簡單說，

1. 要extends SSLSocketFactory寫一個處理TLS的Factory，叫Tls12SocketFactory 好了，可看OkHttp Issues及DevArea的寫法
   
   
2. 針對Build.VERSION.SDK_INT16~19的要多做以下：
   Tls12SocketFactory tlsSocketFactory = new Tls12SocketFactory(sc.getSocketFactory());
   client.sslSocketFactory(tlsSocketFactory , Platform.get().trustManager(tlsSocketFactory));
   在OkHttp Issues中，的client.sslSocketFactory只有第1個參數的寫法已經deprecated了，還是要有第2參數X509TrustManager，可從Factory中取出。
   
   
3. client要再設啥connectionSpecs可再設。
   

而20+的寫法就是少掉第1、2點即可。

其他關於OkHttp的HTTPS設定，可看OkHttp Wiki。

[Android] 2018/2月份 版本分布

參考：Android dashboards

1. 最重要的，API21+破82%了，如果有新App要做，可以考慮min用21(5.0)了，因為5.0才開始原生支援Material Design呀....還有JobScheduler呀...
   
2. 另外，API18+破95%了，只是API19+也有94.3%，MIN真不能用21+的就用19+吧 XD
   
3. OREO(8.X)升為1.1%，出現在榜單5個月。
4. 牛軋糖(7.X)+破29%，出現在榜單已16個月了...
   
5. 棉花糖(6.X)以下全部下降。
6. 牛軋糖(7.X)以上持續上升。
   
7. 還有5.7%的使用中裝置不能玩PMGO跟熊大農場。

話說，旅行青蛙(旅かえる)只要16+(Android 4.1)就能跑，真的有那麼舊的機器測嗎?

[Android] WebService處理

問題：
我想在App裡處理WebService，跟主機發Http Request(Get/Post)，等Response回來，然後parse完結果，秀在UI上，發現有好多工具套件，該怎麼選？

參考：
比較：Quora、stromzhang、StackOverflow1、PacketZoom、Medium、GetIt01、黑客派
分析：SmashingMagzine、簡書
教學：CSDN1、泡在網上的日子、JournalDev、綠豆湯、DevAndroid1、bng86、DevAndroid2
GitHub：okHttp、Volley、Retrofit

說明：這題有幾個部分要處理喔~

1. App跟Http主機溝通的元件
2. UI端跟Http處理元件的溝通
3. 解析Response回來的結果

這篇就只講"1.App跟Http主機溝通的元件"，不然太長了..

先說結論：選OkHttp，如果不喜歡包OkHttp，那就用Volley，完全不喜歡第三方包就HttpURLConnection。

看網路找的結果現在大概會有以下選擇：

• HttpURLConnection：官方內建元件。
• OkHttp：Square社製作，網路上大推的元件。
• Volley：Google社製作，網路上大推的元件。
• Retorfit：Square社製作，網路上大推的元件。

其實這4個只有前2個是真的Http處理元件，後2個是包裝簡化使用的結果，

如果很早就在寫Android的朋友應該有用過apache的HttpClient，只是它在Android 6.0(API 23)被移除了，所以還在用org.apache.http.legacy的朋友應該可以考慮轉OkHttp，因為Square有做OkHttp Apache HttpClient Implementation，可以減少轉換痛苦。

[更新] HttpClient跟URLConnection的實作都被OkHttp廢棄(deprecated)了，用舊版應該是可，只是若有BUG沒人修了，原本用法可參考：HttpClient用OK、URLConnection用OK。
建議使用純okhttp3的寫法囉~

如果喜歡用Volley的，底層連接也可改用okHttp已增進效能，參考簡書這篇，只是看來有點煩。

OkHttp大致上

好處：

• 快
• 簡
• 省

壞處：

• 需額外引入com.squareup.okhttp3:okhttp

---

複雜的都不想說，有疑問可看參考。

再說一次結論：選OkHttp，如果不喜歡包OkHttp，那就用Volley，完全不喜歡第三方包就HttpURLConnection。

Retorfit的話，建議先用過OkHttp再用會比較理解囉

當然，這四種選哪種都很好查到範例跟資源啦...
而且都能完成GET/POST/HTTPS/憑證綁定(certificate pinning) 等工作...吧 XD