[討論] 專家也跟不上Android生態系的變化？
網路上看到一篇文章
講的很辛酸的感覺
請問這是文章作者本身不夠強
還是Android開發者真的就是這樣的慘狀
thanks
(全文頗長，節錄內文如下)
https://www.jianshu.com/p/ee0ed95b9a01
請允許我用 Android 開發者的背景，描述一下我這兩年所經歷的事情：
在過去的兩年裏，我啓動了三個項目，我一直爭取，至少參與其中一個項目的開發工作。我回過頭來看這些已經存在的項目，並分析這些項目前期所做的技術決定對整個項目的影響。我寫了這篇文章，也製作了很多 Android 開發的高級課程，也花了很多時間在互聯網上討論 Android 相關的主題。
即使這樣，我今天依然感覺跟不上 Android 整個生態系統的變化。可想而知，對於那些經驗不足，需要指導的 Android 開發者而言，是多麼地絕望。我現在已經無法想像，現在從頭開始學習 Android 的感覺。當你好不容易學會了某個框架或者工具，覺得它很好用的時候，它或許就要過時了。現在也許是加入 Android 開發大家庭最壞的時候。
Google 正爲他們的“包容性”沾沾自喜，但這一切，對初學者來說，都是極其痛苦的。
Google 在 Android 框架中所做的事情，會導致大量的時間浪費。我們需要花費數小時的時間才能讀完所有更改的內容，更別說在項目中應用它們了。我寧願花時間來創造價值，而不是捨本逐末。
--
邊開火邊移動
框架 引擎 平台 => 軍備競賽
開發者 := 平台競爭之下被打出去的子彈跟砲灰.
要怪就怪甲骨文衝康導致谷哥轉向Kotlin，以後有新科技
出來，要決定開發語言時，一定不會選Java
2019 kotlin編譯時間最好的情況增加50%?2020有改善嗎？
ndroid-development-december-2020/ 看看2020的比對xd
是 現在光跑背景就有這麼多選項 http://i.imgur.com/M
HEEDHJ.jpg
然後workmanager裡面還包了他們以前宣稱的幾種“完美
的解決方法”
真的r
幹我隔壁的同事也常常在幹醮每年八九月都要重新弄一次
Android 的東西，不然一堆套件都不能用惹
所以才不找寫Android的工作
Android 真的沒事不要隨便進來
kotlin爽爽
一個框架或工具的過時 必有他的原因 像Eventbus, Asyncta
sk都是因為有著問題 才有人提出更好的方式
kotlin的出現也並不是單純的複製Java而已 也帶來很多好處
如果都不追求更好更完美的框架或工具 那就乾脆WebApp弄一
弄 跟眾多銀行的App一樣 能跑就好
也沒到每年要重用這麼誇張吧 並不需要全都追新的
例如dagger2都已經好幾年了 最近公司才想導入..
難怪被os壟斷 從pc時代開始
dragger也是很麻煩到一個極致，所以才改良出2和hilt，
結果就是要你繼續學吧
推 baobomb
Flutter2也來囉，歡迎學Dart
持續學習，了解新框架和工具能帶來的好處才是基本的吧
碎片化很真的很痛苦，安卓真的比蘋果難寫很多
非走Native App不可嗎？轉Web app是否可行？
WebApp能做到的事 Native都能做到 但Native能做的事 WebA
pp很多做不到 光是Local Database WebApp就一堆問題了
再來Dagger2 其實真的是好東西 在大型專案中 可以很有效
的做到Module split 可以加快Multiple modules的編譯速
度還有解耦 （不過kapt是另一個造成編譯變慢的問題）
只是學習曲線很高 而且很容易錯用（很多工程師把Dagger c
omponents當成Static object來用 大錯特錯）但一旦學會了
幾乎就等同于沒學九陽神功跟有學九陽神功的差別
碎片化的好處在於方便你做Composition 如同碎片化的好的
話 你應該不會覺得痛苦反而會覺得碎片復用容易而且要Depr
ecating的時候很方便 會覺得很痛苦 那很大機率是碎片化
的不好 可以仔細看看是不是用太多inheritance....
我常常看到很多工程師很愛 inheritance 繼承的到處都是
結果就是要scale或是拔功能的時候世界毀滅
Android更新是很快，但沒有表示什麼都要用最新的
原文寫的很多都能認同,是很資深的工程師,但不代表入門
就會很困難.哪個平台哪個框架不是一直改
而且我真的很討厭RxJava, 這我最能認同原作XD
寫Android 7年了，我覺得最近幾年進步速度滿大的
首先是宣布Kotlin成為一級語言後，Kotlin使用率極速上
升，然後推出了Jetpack Architecture，推出了開發上常
用的解決方案，MVVM用的ViewModel、有生命週期概念的
LiveData、資料庫Room、RecyclerView用的Paging(雖然我
沒用XD)...等，還有Kotlin正式推出的Coroutine，我在某
個社群說過這東西以後可以取代掉RxJava還一堆人驚訝
當然缺點也是有，我有點不喜歡那個WorkManager，然後一
些基於安全性或隱私權考量的一些api調整，但整體我覺得
利仍大於弊，反而我覺得現在新手比過往更好上手，雖然
要學的Library很多，但是有比較完整的解決方案和教學總
比新手自己胡搞瞎搞來得好，最後想說的是，databinding
是拉機XD
data binding真的拉機,從沒學過.誰要在xml上寫code
拿win平台來說，win32->MFC->WinForm->WPF->UWP好像也是
學不完，但是大部分的東西反正最後都會沒人用的，還是
win32 api最穩當XD 甚麼?不用UWP寫不能上MS Store? 反正
UWP推不動MS自己就會轉彎了~ (笑)
xml寫code、databinding，這些web已經寫了十年了XD
不知道大家對RxJava的看法是什麼？？
我很常看到工程師認為RxJava是用來處理multi thread, 所
以會被coroutine取代
但其實RxJava是用來處理Stream layer separating的. 試想
在一個App啟動時 如果有一大堆的critical path服務需要在
background thread init. 然後其他的usecase需要等待這
些服務完成後馬上接續其他的動作
沒有RxJava 以往就是create一大堆的callback listener.
而且很難處理buffer. 但React programming很好的處理了
這問題. Coroutine有Flow 可以做到一樣的效果, 但還不Sta
ble 我自己用起來覺得還是RxJava更直接.
而且CoroutineScope在多線程的情況下需要一直重複切換Con
text 用起來會導致function變很冗長. 但我自己也是樂觀
看待 畢竟很多人誤用RxJava(不懂得復用Subscription,Stre
am,而是每次有需求就subscribe一次 最後也沒有好好Dispos
e導致memory leak) Coroutine看起來可以解決這問題 但希
望可以寫起來更優美
我自己用Flow是沒遇到什麼問題，當然RxJava release那
麽久了，你說Flow相較起來不stable是沒錯，但是我不知
道你說用RxJava更直接是什麼意思，有什麼功能Rx做得到
Flow做不到的嗎？然後CoroutineScope在多線程的情況下
需要一直重複切換Context，難道Rx不需要嗎？會需要頻繁
切換大多都是background thread處理資料後需要更新UI
Rx也一定需要吧？滿好奇你的case
細節也可以去AndroidDev版討論，我可不想被哈哈人噓
其實我也很喜歡Flow啦哈哈 只是很多工程師只是為了方便
切換線程而用coroutine function內withContext寫的到處
都是 看的真的很頭痛....
RxJava寫起來更有chain的感覺 可以在streams之間直接stre
am.subscribeOn/observeOn. 對我來說更能有效的強制工程
師去細分function從而達到unit test更好寫
但Coroutine 的withContext這東西... 很容易讓很多工程師
濫用... 不是說不好 而是太方便了-.-
Flow有個flowOn()，應該可以達到你要的效果，至於到處
寫withContext()是能保證那個function的內容是用特定的
Dispatcher去執行，這就看你們團隊的討論了
我覺得Coroutine比RxJava直覺多了耶！可能是我是先學前
面再學後面
Android Studio 每次按下更新鈕，都要禱告
禱告？沒有啊每次更新都沒什麼事
android studio 4之後的版本bug超多的好嗎
我自己是習慣等個一陣子在更新android studio 讓同事幫忙
除雷XD
全吃一定是吃不完
主要還是要做取捨 像上面講到coroutine and RxJava
先選一種學 另一種有需要再看 不過Google現在選的是corouti
ne了吧? 範例都改coroutine+flow了
我倒覺得databinding超好用的耶，不用一堆 init，至
於在xml編輯，大概因為習慣直接在xml coding 元件內容
所以還蠻習慣的
真的不用什麼都用最新 lib XD，只有在開發新產品才會
使用當下最新最穩定的 lib 版本。這部分 ios 比較慘吧
，常常新版本都有不兼容的 function，直接給你停用出
現 bug(同情地望向 ios 同事），android 至少不會讓你
舊的 function 不能用（或是功能有非常大落差），版
本更新主要看新的調整有沒有影響到自己的 app 再做調
整就好
是可以感受到對開發者的限制增多，但我覺得是讓使用
者的安全性和隱私提高，這是好事，而且統一的規範總
比各廠牌手機魔改系統要好（對，我說的就是大部分陸廠
手機以及少部分他國品牌，雖然個人認為這也是部分開發
者種下的惡果），當你按照官方 sdk 開發卻發現在某幾
個手機上表現不如預期才真令人抓狂...為了這幾個例外
又要再想辦法額外 coding 讓這些例外可以正常運行（暈
）
![Re: [討論] 專家也跟不上Android生態系的變化？](https://www.techyourchance.com/wp-content/uploads/2019/11/state_of_android_november_2019.jpeg "Re: [討論] 專家也跟不上Android生態系的變化？")
23
[討論] Magisk 作者加入 Android 安全團隊轉錄 Magisk 作者 FB 今年五月開始 Magisk 作者 吳泓霖 加入了 Android 安全團隊 看到他加入 Android 安全團隊真的不太意外，畢竟他的專長就在這![[討論] Magisk 作者加入 Android 安全團隊](https://i.imgur.com/yb4ZF2Qb.png "[討論] Magisk 作者加入 Android 安全團隊")
6
[情報] Android 12 內部代號為 Snow Cone ，但Android 12 內部代號為 Snow Cone ，但正式版本只會叫做 Android 12 by Chevelle.fu 2021.02.17 12:34PM Google 自 Android 11 後取消了除了版本號以外的甜點代號，意圖簡化名稱讓消費者容 易記得，不過根據傳聞報導， Google 仍為下一代的 Android 12 進行內部代號的命名， 據稱 Android 12 開發代號為 Snow Cone ，但最終正式版本不會冠上甜點代號，僅會以![[情報] Android 12 內部代號為 Snow Cone ，但](https://sw.cool3c.com/user/29442/2021/f51a2463-e1ab-45e1-a2d1-84d29ea21f5d.jpg?fit=max&w=1400&q=80 "[情報] Android 12 內部代號為 Snow Cone ，但")