欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

當我還在上大學(xué)的時(shí)候，Android 和 iOS 還是新興的平臺，每個(gè)人都對這兩項技術(shù)很感興趣。如果你參加一些當時(shí)的編程研討會(huì )，最后總會(huì )寫(xiě)一個(gè)小型的 Android 應用。這就是我向 Android 生態(tài)系統邁出的第一步，也可能是我隨后成為了一名移動(dòng)開(kāi)發(fā)者的原因。

在這篇文章中，我想要分享我關(guān)于 Android SDK 和 Flutter 的糟糕體驗。我提到的某些要點(diǎn)也適用于 iOS SDK。我已經(jīng)在幾年前放棄了移動(dòng)開(kāi)發(fā)的工作，希望后來(lái)許多事情已經(jīng)在朝好的方向改進(jìn)。但在當時(shí)，我發(fā)現移動(dòng)生態(tài)系統是如此的令人感到困惑和挫敗，以至于我選擇了一條不同的職業(yè)路徑。

本文由原作者發(fā)表在 medium.com，經(jīng)原作者授權由 InfoQ 中文站翻譯并分享

對開(kāi)發(fā)者而言，Android 開(kāi)發(fā)的最大痛點(diǎn)，就是設備配置的巨大差異。我一直都未能理解為什么 SDK 中大部分功能（尤其是用戶(hù)交互界面的部分）取決于設備，而不是我的應用。這從根本上導致我必須使用支持庫，針對每個(gè)目標 API 級別調試我的應用。除此之外，我還經(jīng)常遇到在仿真器或者測試設備上好好的代碼，卻在某個(gè)三星或者華為的設備上崩潰的情況。

當我在 HackerNews 或者 Reddit 上讀到關(guān)于谷歌的 Material Design 的評論時(shí)，某些時(shí)刻會(huì )感到我是唯一真正喜歡它的人。我覺(jué)得它在視覺(jué)上很具吸引力，我通常很享受這樣的用戶(hù)體驗。官方的文檔網(wǎng)站發(fā)展得很快，也非常成功，我覺(jué)得這是優(yōu)秀文檔的典范。當它被宣布用于 Android 時(shí)，我感到非常興奮！

話(huà)雖如此，在 Android 平臺上從 Holo 過(guò)渡到 Material Design 并非一帆風(fēng)順。因為它好像是被急匆匆發(fā)布出來(lái)似的。在接下來(lái)的幾年之中，官方的 Material Design 支持庫一直缺少一些非?；镜慕M件。雖然你有時(shí)可以在谷歌自有的應用上看到這些組件，但是它們并沒(méi)有真正被納入到支持庫中。開(kāi)發(fā)者不得不構建自己的組件，或者使用 GitHub 上質(zhì)量無(wú)法保證的實(shí)現作為替代品。這次使用 Material Design 支持庫的經(jīng)歷，再加上大量的不一致的視覺(jué)設計和實(shí)現錯誤，讓我第一次停下來(lái)真正地思考和質(zhì)疑這個(gè)生態(tài)系統。

構建一個(gè)可靠的 Android 應用，是一項充滿(mǎn)挑戰的任務(wù)。這主要是因為 SDK 對開(kāi)發(fā)者并不友好。理論上，一個(gè) Android 應用程序可以永遠掛在后臺不使用任何系統資源，然后在用戶(hù)需要時(shí)立即回到先前的狀態(tài)，這實(shí)在是令人驚訝。不過(guò)前提是開(kāi)發(fā)者正確地實(shí)現了這個(gè)應用的狀態(tài)和生命周期管理機制。

開(kāi)發(fā)者：你好，互聯(lián)網(wǎng)！我的應用在改變屏幕方向時(shí)崩潰了，該如何解決？互聯(lián)網(wǎng)：這很簡(jiǎn)單！禁止改變屏幕方向即可。

——啊哦，不幸的是，這種回復很普遍。

你是否曾經(jīng)使用過(guò) Java 中的線(xiàn)程（Threads）？在可變變量隨處可見(jiàn)的的命令式代碼庫中，這件事變得非常困難。但你猜怎么著(zhù)？在 Android SDK 中使用線(xiàn)程更加困難。如果你想要在一個(gè) Activity 中管理 Thread，那你就只能自求多福了。幸運的是，我們最終保留了 Fragments，這最終讓這件事變得容易了一些。但代價(jià)是在一開(kāi)始就需要使用 Fragments。

在我作為一名移動(dòng)開(kāi)發(fā)者的職業(yè)生涯中，我面試了一些高級 Android 開(kāi)發(fā)者。他們幾乎無(wú)一例外，都很難給出這些話(huà)題的正確答案。

我一直希望谷歌能更坦然地承認這些問(wèn)題，并且和社區一起解決。這些問(wèn)題可能隨著(zhù) Kotlin 的發(fā)布有所改善，但 Android 生態(tài)系統的根基仍然存在很多潛在的問(wèn)題。

開(kāi)發(fā)者很快就意識到，在 Android SDK 提供的抽象之上，構建一個(gè)真實(shí)世界的應用是不可能的。對此的解決方案是層出不窮的設計模式，甚至每周可能都會(huì )出現新的設計模式，我記得的包括：MVC、MVP、MVVM 和 MVI。而且由于無(wú)法使用普通的構造函數調用來(lái)管理依賴(lài)項，我們不得不在代碼庫的每個(gè)地方使用注解。這些本來(lái)并沒(méi)有必要。Java，甚至 Kotlin，本來(lái)就有足夠的能力可以對這些東西建模，更何況是以一種透明而直接的方式。但 Android 更喜歡 XML 定義和反射式實(shí)例化，因此開(kāi)發(fā)者不得不在代碼中使用注解和各種設計模式。實(shí)話(huà)實(shí)說(shuō)，我真的無(wú)法形容這到底有多麻煩。

在某種程度上，原生 iOS 和 Android 開(kāi)發(fā)都是作為平臺在與網(wǎng)頁(yè)端競爭。但 iOS 和 Android 擁有只屬于一家企業(yè)的巨大的平臺優(yōu)勢，相比之下，網(wǎng)頁(yè)端有許多利益相關(guān)者，這些利益相關(guān)者都想要根據他們的需要來(lái)影響網(wǎng)頁(yè)端的開(kāi)發(fā)。

然而，網(wǎng)頁(yè)端擁有更加活躍和創(chuàng )新的生態(tài)系統。只需要想想 React 的成功故事：基于組件的用戶(hù)界面，是我們目前提出的最簡(jiǎn)潔的抽象方法，這是無(wú)可否認的。多年以來(lái)，Android 并不理會(huì )這一趨勢，直到最近才宣布推出“Jetpack Compose”，但是這仍然僅支持在開(kāi)發(fā)者預覽模式下使用。同樣的事情也出現在 iOS 開(kāi)發(fā)中。

所以，現狀是我們仍然需要繼承 android.view.View 類(lèi)，這個(gè)類(lèi)有 1.5 萬(wàn)行代碼，和數十個(gè)生命周期函數，但同時(shí)我們還要嘗試注入自己的 merge XML 文件。iOS 和 Android 本來(lái)可以成為這個(gè)競爭中的引領(lǐng)者，但實(shí)際上，它們已經(jīng)被遠遠甩在了后面。

一個(gè)精美的應用的關(guān)鍵在于用戶(hù)界面（UI）。我在上文已經(jīng)吐槽了不少關(guān)于組件的問(wèn)題，但這些還不是最嚴重的。你是否曾經(jīng)調試過(guò)網(wǎng)站上的故障？通常的操作是：打開(kāi)瀏覽器的開(kāi)發(fā)工具，點(diǎn)擊有問(wèn)題的元素，然后使用 CSS 和 HTML 的屬性來(lái)調試。與此相比，Android 是一個(gè)無(wú)法訪(fǎng)問(wèn)的黑盒。老實(shí)說(shuō)，我一直沒(méi)有完全理解 Android 的主題和樣式機制，并且與 Web 相比，Android 的工具顯得毫無(wú)用處。

想要在這個(gè)框周?chē)砑雨幱皢?？沒(méi)問(wèn)題，請使用這個(gè)奇怪的.9.png 文件，或者依靠 API Level 21，你就可以正確渲染陰影了（盡管只有凸形陰影）。不好意思，你忘記實(shí)現自定義視圖四個(gè)構造函數的其中一個(gè)了。但我不會(huì )拋出編譯錯誤，我只會(huì )在運行時(shí)崩潰！現在有支持超高屏幕密度的手機了?？梢栽趹美锾砑?xxxhpi 的 assets 嗎？不行，不支持矢量圖，我們做不了這個(gè)?！獊?lái)自 Android SDK 的深夜獨白

在 Android 21（5.0）之前，Android 平臺根本不支持正確的矢量圖。這背后的原因是，多樣的 Android 設備導致了多種不同的屏幕密度，這要求圖像針對每種屏幕密度都做仔細的調整。務(wù)實(shí)的開(kāi)發(fā)者自然而然地開(kāi)發(fā)了轉換矢量圖的工具，將 logo.svg 轉換成 ldpi/logo.png，mdpi/logo.png，hdpi/logo.png，xhdpi/logo.png，xxhdpi/logo.png 以及 xxxhdpi/logo.png。幸運的是，最終谷歌改變了它們的想法，并提供了 VectorDrawble 來(lái)支持部分可縮放矢量圖形（SVG）。的確，這足夠減輕當時(shí)的痛苦。但仍然令我困惑的是，一個(gè)以能夠在任何設備配置上運行為優(yōu)勢的開(kāi)發(fā)環(huán)境，是如何在這么長(cháng)時(shí)間都不支持矢量圖的情況下活下來(lái)的？

這些年，我開(kāi)始越來(lái)越擔心我的知識會(huì )在不遠的將來(lái)過(guò)時(shí)。我學(xué)到的大多數知識都是 Android 開(kāi)發(fā)所特有的，很少適用于更廣泛的軟件開(kāi)發(fā)領(lǐng)域?？紤]到這些方面，我不認為原生的移動(dòng)開(kāi)發(fā)會(huì )一直存在，所以我開(kāi)始擔心所學(xué)到的技能的實(shí)用性。

當 Flutter 發(fā)布時(shí)，我非常激動(dòng)。它承諾將解決一些主要的 Android SDK 的缺陷，同時(shí)無(wú)償提供跨平臺支持。所以在我上一份工作中，我們開(kāi)始從原生 Android 遷移到 Flutter 上。我必須承認，Flutter 信守了它的承諾：

• Flutter 內置的渲染流水線(xiàn)完全解決了 Android 的碎片化問(wèn)題。

• 從一開(kāi)始，它就提供了詳盡的高質(zhì)量的 Material Design 組件庫。

• 熱重載功能的靈活性完全顛覆了我的認知。

• 你能獲得前所未有的高質(zhì)量界面外觀(guān)的跨平臺體驗。

但不幸的是，它也不完美。而且有點(diǎn)可惜的是，Flutter 遇到的問(wèn)題本可以通過(guò)一個(gè)全新的項目輕松避免。

• Dart 很糟糕：它還是一門(mén)相對年輕的語(yǔ)言，但它重蹈了不少它的前輩的覆轍（錯誤的類(lèi)型系統，Null，使用語(yǔ)句而不是表達式，等等）。

• Flutter SDK 中讓人不解的設計決策：它們本應創(chuàng )造一個(gè)更好的 React，但卻創(chuàng )造了一個(gè)更糟糕的。本可以通過(guò)簡(jiǎn)單的函數調用解決的問(wèn)題，往往需要通過(guò)有狀態(tài)的面向對象編程（OOP）機制才能解決。（我記得對話(huà)框的路由和處理在這個(gè)方面尤為痛苦）

在某一時(shí)刻，我清楚的意識到，我不想在這種技術(shù)上傾注心血了。我向自己許諾，絕不再在移動(dòng)平臺上編程。一個(gè)設計精美的、響應式的網(wǎng)站在今天已經(jīng)可以給你足夠好的體驗，所以這是我的不二之選。只需要一個(gè)代碼庫，它就能適用于每個(gè)客戶(hù)端。如果我還是不得不構建一個(gè)移動(dòng)應用程序，我仍然會(huì )選擇 Flutter，甚至是在我僅針對 Android 的情況下。我絕對不會(huì )再使用 Android SDK。

話(huà)雖如此，但要澄清一點(diǎn)，我還是非常喜愛(ài)和欣賞精心制作的原生應用的（無(wú)論是在移動(dòng)設備上還是桌面上）。我對那些使用現有工具就能創(chuàng )建出這樣的應用的開(kāi)發(fā)者，致以崇高的敬意。只是，我不想再成為他們中的一員。

關(guān)注我并轉發(fā)此篇文章，私信我“領(lǐng)取資料”，即可免費獲得InfoQ價(jià)值4999元迷你書(shū)！