Android 9 Pie 正式版總結

豌豆射手_BiuBiu發表於2019-03-04
  • 先宣告下,以下的整理的資料一部分來源於公眾號谷歌開發者,一部分來源於谷歌安卓官方網站(不用翻牆,gogogo),還有小部分自己的理解。

    Android 9
  • 微信公眾號號谷歌開發者推送了 Android 9 Pie 現已面向全球正式釋出!,就去更新 Android API 28,想看看正式版那些功能,就發生瞭如下的故事

釘釘工作群

這是我的電腦IP地址

我的電腦IP.png
和領導的聊天記錄
  • 然後我的電腦就被限制速度了,為了同事們能夠好好工作,現在模擬器映象都不能下載了!哈哈
Android 9 Pie 正式版總結
  • 雖然不能完成Android 9有些 api的具體的效果,先mark下,後續再來添上

  • 今天我終於把API 28的原始碼下載下來了。哈哈!

動態電量管理

1、應用待機分組

  • Android P 新增加應用待機分組的功能,讓系統根據使用者的使用情況而限制應用呼叫CPU或網路等裝置的資源, 應用待機分組是 Android P 新新增的一項電量管理功能,它能根據應用的使用頻率或者最近一次使用時間,對其資源請求進行優先順序排序!
  • 優先分組 在預設的情況下,系統會更具應用的近期的使用的情況進行等級劃分,應用活躍度越高,所處的分組優先順序就越高,也更加容易獲取裝置的資源;第二種是系統安裝了通過利用機器學習預載入的應用,從而預測各個應用的使用概率,然後將他們編配值相應的群組,在我朝手機裝置廠商應該不會是這種。裝置廠商可以自行規定非活躍應用的群組劃分規則(我朝特色,廠商白名單)。請開發者不要試圖篡改應用所處的群組,而是專注於改善應用行為,確保應用被劃分至目標群組後,依舊能夠順利執行(小公司,好好提升技術,)
5個分組如下 活躍 (Active)、工作 (Working set)、 常用 (Frequent)、 極少 (Rare)、應用偶爾被使用 (App is not frequently used)
  • 活躍 (Active): 應用正在被使用 (每個應用都可以)
    1、啟動了一個Activity
    2、正在執行的前臺服務
    3、另外一個應用已關聯該應用
    4、 使用者點選了推送

  • 工作 (Working set): 應用使用頻率很高
    1、若應用的執行頻率很高,但目前並未處於“活躍”狀態,它就會被劃分至工作群組,例如使用者常用的社交媒體應用。此外,該群組還包括了那些被間接使用的應用。微信 QQ 支付寶 ,工作分組內的應用任務(Job)執行和鬧鈴受到系統的部分限制

  • 常用 (Frequent): 應用經常但不是每天被使用
    常用應用指使用者經常使用但不是每天使用的應用,比如使用者在健身房使用的打卡應用可能就屬於這一群組。跑步的APP系統對常用分組採用的限制更強,應用執行任務(job)和觸發鬧鈴的能力都會受到影響,而且接受的高優先性FCM訊息也有數量上限

  • 極少 (Rare): 應用偶爾被使用
    若應用的使用頻率很低,它就會被劃分至該分組,(比如說你去某個地方,訂酒店之類的APP,)該群組下的應用在任務 (job)、鬧鈴和高優先性FCM訊息的資源呼叫上都會受到嚴格的限制。此外,網路訪問能力也會受到影響

  • 應用偶爾被使用 (App is not frequently used)
    安裝後一次都未被使用過的應用將被劃分至 “從不” 這一特殊群組,並受到十分嚴格的系統限制 我們自己的手機上有這種的App 很多

  • 我們做應用層APP應該怎麼應對這幾種分組 ?

    • 每個模式下,都能開啟APP,確保App不能炸掉
    • 要確保有啟動的 Launcher Activity,如果沒有的話,有可能你的應用不會切換到活躍分組
    • 推送的訊息要具有可操作性,這個的意思就是說,點了通知欄要跳到應用去
    • 若應用在接受高優先順序的 FCM 訊息之後未能傳送推送,使用者將無法與應用產生互動並將其優先順序提升至 “活躍” 等級。
    • 如果使用者多次忽略某個App的推送,系統會去詢問使用者是否不再接受此推送 。所以不要亂去推送,為了保持活躍群組!
  • 後臺的限制 (微信經常這樣)當系統檢測到應用消耗過多的資源時,系統會發通知詢問使用者是否需要限制該應用的後臺的活動
    1、第一中期情況是,頻繁使用喚醒鎖 (wake locks):螢幕關閉後,區域性喚醒鎖 (Partial wake lock) 連續開啟 1 小時;
    2、過多的後臺服務:當應用目標 API 等級低於 26,且執行過多後臺服務。

  • Android P 進一步提升了省電模式的效能。需要由裝置的廠商來決定採用的具體的限制
    作為開發者 我們自己,我們需要在省電模式下測試應用。確保自己的應用能夠安全的上線和執行

        //使用 Android Debug Bridge 命令 https://mp.weixin.qq.com/s?__biz=MzAwODY4OTk2Mg==&mid=2652046811&idx=1&sn=f0340e6fabb07a3ee40db45bdd58e7b0&chksm=808ca59eb7fb2c883c6ae99be7c84460f48886cd79bb0de886a5bac84afa2d8050a58339cc89&scene=21#wechat_redirect
複製程式碼

2、後臺限制

  • Android P新增後臺限制功能,如果應用出現 Android Vitals 裡面所描述的行為,系統將提醒使用者限制該應用的訪問裝置的資源!
  • Android Vitals:是谷歌提高Android裝置穩定性和效能的一項舉措。當選擇的使用者執行你的應用程式時,他們的Android裝置記錄各種度量,包括關於應用程式穩定性、應用程式啟動時間、電池使用時間、渲染時間和許可權拒絕的資料。谷歌播放控制檯聚集這些資料並將其顯示在Android虛擬儀表板中。儀表板突出了崩潰率、ANR率、過度喚醒和卡尾鎖:這是開發人員應該關注的核心。所有其他的vitals,當適用於你的APP或遊戲型別時,都應該被監控,以確保它們不會產生負面影響。如果產生了,應用的商店被發現的可能性低,說到底的意思就是,垃圾應用,我不幫你推薦!

3、省電模式的優化

  • Android P 優化了現在的省電助手的功能,在啟動該功能後,系統將對所有的後臺執行實施加以限制

4、低耗能模式, 當使用者一段時間沒有使用裝置時候,裝置將進入低耗電模式,所有的應用都將要受到影響。Android P並沒有針對低電耗模式做出改變.

  • 低耗電模式: 低電耗模式通過在裝置長時間處於閒置狀態時推遲應用的後臺 CPU 和網路 Activity 來減少電池消耗。應用待機模式可推遲使用者近期未與之互動的應用的後臺網路 Activity. 如果使用者裝置未插接電源、處於靜止狀態一段時間且螢幕關閉,裝置會進入低電耗模式。 在低電耗模式下,系統會嘗試通過限制應用對網路和 CPU 密集型服務的訪問來節省電量。 這還可以阻止應用訪問網路並推遲其作業、同步和標準鬧鈴.一旦使用者通過移動裝置、開啟螢幕或連線到充電器喚醒裝置,系統就會立即退出低電耗模式,並且所有應用都將返回到正常 Activity。
  • 有個例子。手機裝置8.0上,開啟視訊APP下載視屏,關閉螢幕,一會視屏App就會關閉,在以前的版本不會出現,這就是低電耗模式!

5、Slices App Actions

  • Google 想要透過ActionSlice 這兩個功能讓使用者減少操作動作,讓應用程式和操作行為更緊密結合,把以前需要操作四五下才能完成的事減少到操作兩三下或是操作一下就能自動完成。
  • App Actions是一種全新的應用推薦的方式,它能夠對應用語義意圖和使用場景進行分析,並根據分析結果在適當的時機向使用者推薦應用,比如說在使用者插入耳機的時候,推薦開啟 音樂App 等等 —>谷歌沒有公佈使用的方式
  • Slice: 的概念則是 Google Assistant 的延伸,讓使用者能快速使用到 app 裡的某個特定功能,只要開發者匯入 Slice 功能,使用者在使用搜尋、Google Play 商店、Google Assitant 或其他內建功能時都會出現 Slice 的操作建議。在go語言中 有個叫切片slice,它的意思是:在初始定義陣列時,我們並不知道需要多大的陣列,因此我們就需要“動態陣列”。在Go裡面這種資料結構叫slice.

6、文字識別與 Smart Linkify

  • 在 Android 9 中,我們對識別文字的機器學習模型進行了擴充套件,使其可以藉助 TextClassifier API 識別出類似日期或航班號這樣的資訊。此外, Smart Linkify 允許開發者通過 Linkify API 使用文字識別模組完成多項操作,比如對使用者可採取的操作提出建議。Smart Linkify 讓系統在文字識別精確度與速度上都有明顯的提升。
  • TextClassifier 後續更新下Demo 研究中
    demo.gif
        TextClassifier API
       https://developer.android.google.cn/reference/android/view/textclassifier/package-summary
      Linkify API
     https://developer.android.google.cn/reference/android/text/util/Linkify
複製程式碼

7、神經網路 API 1.1

  • Android 9.0 對神經網路 API 進行了擴充套件與改進,進一步優化 Android 對機器學習硬體加速的支援。神經網路 API 1.1 共增加了對 9 個新運算元的支援,它們分別是Pad、BatchToSpaceND、SpaceToBatchND、Transpose、Strided Slice、Mean、Div、Sub 和 Squeeze。TensorFlow Lite就是一個已經用上此 API 的典型機器學習框架。

人機互動

1、全新系統導航

  • Android 9迎來了全新的系統導航,讓多工切換及關聯應用探索變得更加簡單。您只需要向上滑動螢幕就可以全屏預覽最近使用過的應用,輕觸預覽頁後便可以切換至所選應用。
全新系統導航.gif

2、 凹口屏支援

  • 想起來 蘋果大佬 還是牛逼,劉海是為了屈服某種硬體的缺陷,然後谷歌就開始支援了
  • Android 9 中加入了凹口屏支援,讓您的應用可以充分利用最新全面屏,展現應用的獨特魅力。該功能可以在大部分應用中無縫工作,系統會通過調整狀態列高度將應用內容與螢幕缺口區域分開。如果您的應用含有沉浸式內容,您可呼叫display cutout APIs 確認缺口形狀與位置,然後請求圍繞缺口進行全屏佈局。另外,我們還加入了開發者選項來模擬任意裝置上的凹口形狀,從而極大簡化了應用支援凹口螢幕所需的構建以及測試流程。

3、 通知與智慧回覆

  • Android 9 進一步改善了通知的實用性與可操作性。訊息類應用可以呼叫新的 MessagingStyle API 來顯示對話,附加照片和表情,或者提供智慧回覆建議。
     // Create new Person.  完蛋了,這下在安卓中Person類有了,不僅僅是一個了
        val sender = Person()
                .setName(name)
                .setUri(uri)
                .setIcon(null)
                .build()
      // Create image message.
        val message = Notification.MessagingStyle.Message("Picture", time, sender)
                .setData("image/", imageUri)
        val style = Notification.MessagingStyle(getUser())
                .addMessage("Check this out!", 0, sender)
                .addMessage(message)
複製程式碼

4、文字放大鏡

  • Android 9 中新增文字放大鏡工具 (Magnifier widget),以提升文字選擇方面的使用者體驗。由於該放大器提供了可以在文字上方拖拽的文字放大皮膚,所以有助於使用者精準地定位游標或文字選擇手柄。該功能可以靈活運用在所有附加在視窗的檢視上,個性化小部件和定製文字呈現均是不錯的應用場景。
  • 該放大器工具還可以提供任何檢視或介面的放大版本,而不僅僅是文字。
    文字放大.gif

使用者安全與隱私

1、統一身份驗證對話方塊

  • 為了保障使用者在不同甘銀強和應用之間能夠獲得一致的體驗,Android P 引入了統一的身份驗證對話方塊,提醒使用者進行操作。應用可以不自行的設計,該API還支援面部識別虹膜識別技術 是基於眼睛中的虹膜進行身份識別,應用於安防裝置(如門禁等),以及有高度保密需求的場所。

    • 優點
      1.便於使用者使用;
      2.可能會是最可靠的生物識別技術;.
      3.不需物理的接觸;
      4.可靠性高。
    • 缺點
      1.很難將影像獲取裝置的尺寸小型化;
      2.裝置造價高,無法大範圍推廣;
      3.鏡頭可能產生影像畸變而使可靠性降低;
      4.兩大模組:硬體和軟體;
      5.一個自動虹膜識別系統包含硬體和軟體兩大模組:虹膜影像獲取裝置和虹膜識別演算法。分別對應於影像獲取和模式匹配這兩個基本問題。
  • 程式碼如下

 // TODO 一定要在 API 28的模擬器上跑 要不然 app 會直接奔潰掉
        val BiometricPrompt = BiometricPrompt.Builder(this)
                .setTitle("指紋驗證")
                .setDescription("描述")
                .setNegativeButton("取消", mainExecutor, DialogInterface.OnClickListener { dialogInterface, i -> Log.i(UserSecurityAndPrivacyActivity@ this.localClassName, "Cancel button clicked") })
                .build()
        val mCancellationSignal = CancellationSignal()
        mCancellationSignal.setOnCancelListener {
            CancellationSignal.OnCancelListener {
                fun onCancel() {
                    println("取消了啊")
                }
            }
        }
        val mAuthenticationCallback = object : BiometricPrompt.AuthenticationCallback() {
            override fun onAuthenticationError(errorCode: Int, errString: CharSequence) {
                super.onAuthenticationError(errorCode, errString)
                println("發生了 錯誤了啊")
            }

            override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
                super.onAuthenticationSucceeded(result)
                println("發生了 成功了啊")
            }

            override fun onAuthenticationFailed() {
                super.onAuthenticationFailed()
                println("發生了 失敗了")
            }
        }
        BiometricPrompt.authenticate(mCancellationSignal, mainExecutor, mAuthenticationCallback)
複製程式碼

2、Android Protected Confirmation

  • 安卓保護確認:執行Android 9或更高版本的支援裝置使您有能力使用Android保護的確認。使用此工作流時,應用程式向使用者顯示提示,要求使用者批准簡短語句。這個宣告允許應用程式重新確認使用者希望完成一個敏感的交易,例如支付。

3、KeyStore 加強金鑰安全保護

  • 加入了一個新的KeyStore 類 —— StrongBox,並提供相應的 API 來支援那些提供了防入侵硬體措施的裝置,比如獨立的 CPU,記憶體以及安全儲存。

4、 DNS over TLS 基於TLS的DNS

  • 大多的網路連線 –DNS查詢–》返回IP地址–》客服端就能連線上網頁了。網際網路的大佬們一直在致力於新的NDS的協議的開發,該協議就是NDS over TLS協議 TLS:安全傳輸層協議(TLS)用於在兩個通訊應用程式之間提供保密性和資料完整性
  • Android P 正式版內建對 DNS over TLS的支援,在 “網路和網際網路” 設定中新增了隱私 DNS (Private DNS) 模式。
  • NS over TLS 模式自動為所有系統上的應用提供安全 DNS查詢。不過,若應用未使用系統 API,而是自行執行 DNS 查詢,它們必須確保在系統進行安全連線情況下,不傳送不安全的 DNS 查詢。應用可以呼叫新的 API
 LinkProperties.isPrivateDnsActive()
複製程式碼

5、Android P預設使用了HTTPS

6、基於編譯器的安全緩解措施

  • Android 9 將進一步擴充套件編譯器級別的安全緩解措施,藉助執行時危險行為監測進一步加強平臺安全建設。Android 9通過控制流程完整性 (CFI) 技術解決了程式碼重用(code-reuse)和任意程式碼執行兩大漏洞,並擴充套件了CFI在媒體框架和其它關鍵安全元件內的使用範圍,如NFC 與藍芽。同時,Android 9還針對 Android 常見核心的 LLVM 編譯新增了 CFI核心支援。

7、使用者隱私

  • Android 9新加入多項機制,進一步加強了對使用者隱私的保護。系統禁止所有處於空閒狀態的應用對話筒、攝像頭和所有 SensorManager感測器的訪問。當應用的 UID 空閒時,麥克風將會報告 “無音訊訊號”,感測器將會停止報告事件,應用使用的攝像頭也會斷開連線,並在應用試圖訪問時生成錯誤。在大多數情況下,這些限制不會對現有應用造成新的問題,谷歌建議從應用中移除此類感測器請求。
  • Android 9 還讓使用者控制是否允許訪問平臺build.serial識別碼 (它被 READ_PHONE_STATE 許可權保護) ,裝置的唯一標識the hardware serial number.
    //獲取硬體序列號,如果可用的話。
        if (ActivityCompat.checkSelfPermission(this, Manifest.permission.READ_PHONE_STATE) != PackageManager.PERMISSION_GRANTED) {
            //注意需要在 高版本的 SDK的手機上執行
            val serial = Build.getSerial()
        }
複製程式碼

攝像和影音的全面升級

1、多攝像頭的API的改進 –>

  • 從 Android 9 開始,您可以在支援多攝像頭 API 的裝置上通過兩個或更多實體攝像頭同時訪問視訊流;在配有雙前置或雙後置攝像頭的裝置上,實現單攝像頭無法實現的創新功能:如無縫變焦、散景和立體視覺。該 API 還允許您呼叫可以在兩臺或更多臺攝像頭之間自動切換的邏輯或混合攝像頭視訊流。

2、使用動態處理增強音訊–>降噪技術

  • iPhone手機的降噪技術:雙麥克風降噪技術,即手機中內建的兩個麥克風,一個保持清晰通話,另一個麥克風從物理上主動消除噪音,通過收集外界的噪聲,運用內部演算法進行處理後,發出與噪音相反的聲波,利用抵消原理消除噪音。其他手機估計也差不多!
  • 開發者可以呼叫 Dynamics Processing API對音訊進行動態處理,通過分離出特定頻率的聲音,降低過大的音量,或者增強過小的音量,來改善應用的音訊質量。比如說,即便說話者聲音小,離麥克風遠,而且外界環境十分嘈雜,您的應用依然可以有效捕捉並他/她的聲音,並進行相應優化。該 API 提供了多聲場、多頻段的動態處理效果,包括一個預均衡器、一個多頻段壓縮器,一個後均衡器以及一個串聯的音量限制器。

3、ImageDecoder API

  • ImageDecoder 通過一種更為簡單的方式將影像解碼為點陣圖或 drawableImageDecoder 允許您從位元組緩衝區、檔案或 URI 建立點陣圖或 drawable。它相比BitmapFactory有以下幾個優勢:支援精確縮放,支援單步解碼至硬體儲存器,支援解碼後處理,以及動畫影像解碼。

  • ImageDecoder:一個的可以將PNG, JPEG, WEBP, GIF, or HEIF格式的圖片的轉換成Drawable 或者Bitmap物件的類。

    • 1、正常的使用:得到drawable
    val file =File("filename")
         val source = ImageDecoder.createSource(file)
         val drawable = ImageDecoder.decodeDrawable(source)
    複製程式碼
    • 2、傳遞OnHeaderDecodedListener,這裡ImageInfo存放的是原始的圖片的寬和高。可以修改用來修改圖片寬高的時候修改SampleSize
    val listener = object : ImageDecoder.OnHeaderDecodedListener {
             override fun onHeaderDecoded(decoder: ImageDecoder, info: ImageDecoder.ImageInfo, source: ImageDecoder.Source) {
                 decoder.setTargetSampleSize(2)
             }
         }
         val drawable1 = ImageDecoder.decodeDrawable(source, listener)
    複製程式碼
    • 3、如果解碼的圖片是gif,會被解碼成AnimatedImageDrawable
     val drawable2 = ImageDecoder.decodeDrawable(source)
         if (drawable is AnimatedImageDrawable) {
             drawable.start()
         }
    複製程式碼
    • 4、解碼出來的bitmap是不可變,可以使用PostProcessor來新增一些自定義的效果
     val drawable3 = ImageDecoder.decodeDrawable(source) { decoder, info, src ->
             decoder.setPostProcessor { canvas ->
                 // This will create rounded corners.
                 //建立圓角照片
                 val path = Path()
                 path.setFillType(Path.FillType.INVERSE_EVEN_ODD)
                 val width = canvas.width
                 val height = canvas.height
                  // 最低的API的要求是 21 所以我的工程裡面的 API為 21
                 path.addRoundRect(0.toFloat(), 0.toFloat(), width.toFloat(), height.toFloat(), 20.toFloat(), 20.toFloat(), Path.Direction.CW)
                 val paint = Paint()
                 paint.setAntiAlias(true)
                 paint.setColor(Color.TRANSPARENT)
                 paint.setXfermode(PorterDuffXfermode(PorterDuff.Mode.SRC))
                 canvas.drawPath(path, paint)
                 PixelFormat.TRANSLUCENT
             }
         }
    複製程式碼
    • 5、如果解碼的照片是不完整的或者包含錯誤,解碼的時候會丟擲DecodeException,一些情況下,可能已經解碼出一部分的照片,這個時候傳遞OnPartialImageListener,並返回true,就只顯示解碼出來的部分,剩餘部分使用空白代替!
    val drawable5 = ImageDecoder.decodeDrawable(source) { decoder, info, src ->
             decoder.setOnPartialImageListener { e: ImageDecoder.DecodeException ->
                  true
             }
         }
    複製程式碼

網路連線與位置

1、使用 Wi-Fi RTT ,進行室內定位

  • Android 9IEEE 802.11mc Wi-Fi協議新增了平臺支援 (也稱為 Wi-Fi 往返時間,RTT),這可以讓您在應用中使用室內定位功能。在提供硬體支援的 Android 9 裝置上,在啟動位置服務並勾選 “允許獲取地理位置資訊” 選項後,應用就可以使用 RTT API 測量與附近 Wi-Fi 接入點 (AP) 的距離。裝置不需要連線到 AP 便可以使用 RTT,而且為了保護隱私,只有手機能夠確定距離,而 AP 不可以。
  • 通過測量從裝置到三個或更多 AP 的距離,您可以計算裝置位置至 1 到 2 米的精度。這種精確度允許您建立更多新的體驗:室內導航、基於位置的細粒度服務,例如,模糊語音控制 ( “開啟這裡的燈” ) ;以及基於位置的資訊服務 ( “這個產品有優惠活動嗎?” )。

2、JobScheduler 中的資料費用敏感度

  • Android 9中,JobScheduler 可以更好地幫助使用者處理與網路相關的任務,並與運營商單獨提供的網路狀態訊號相協調
  • JobSchedulerAndroid 的一項核心服務,它可以幫助您針對低耗電模式、應用待機模式以及後臺限制,妥善進行各種任務的排程。在 Android 9中,JobScheduler 可以更好地幫助使用者處理與網路相關的任務,並與運營商單獨提供的網路狀態訊號相協調。任務現在可以宣告預估資料量、訊號預取以及指定詳細的網路要求 —— 運營商可以報告網路狀況是擁塞還是不計量,然後 JobScheduler會根據網路狀態管理作業。例如,當網路擁塞時,JobScheduler 可能推遲大型網路請求;而在網路可以不計量使用時,則可以執行多種預載入作業 (例如,預讀標題) 來改進使用者體驗。

3、 用於 NFC 支付和安全交易的 Open Mobile API

  • Android 9GlobalPlatform Open Mobile API 的實現新增至平臺中。在支援的裝置上,應用可以使用 OMAPI API 訪問安全元素 (SE) ,以啟用智慧卡支付等安全服務。硬體抽象層 (HAL) 提供了必要的 API,用於列舉多種可用的 Secure Elements (如 eSE, UICC 等)。

更強勁的效能表現

1、ART 效能提升

  • ART是什麼?
  • AOT是”Ahead Of Time”的縮寫,指的就是ART(Anroid RunTime)這種執行方式。
  • JIT是執行時編譯,這樣可以對執行次數頻繁的dex程式碼進行編譯和優化,減少以後使用時的翻譯時間,雖然可以加快Dalvik執行速度,但是還是有弊病,那就是將dex翻譯為本地機器碼也要佔用時間,所以Google在4.4之後推出了ART,用來替換Dalvik。
  • ART的策略與Dalvik不同,在ART 環境中,應用在第一次安裝的時候,位元組碼就會預先編譯成機器碼,使其成為真正的本地應用。之後開啟App的時候,不需要額外的翻譯工作,直接使用本地機器碼執行,因此執行速度提高。
  • 當然ART與Dalvik相比,還是有缺點的。
    • ART需要應用程式在安裝時,就把程式程式碼轉換成機器語言,所以這會消耗掉更多的儲存空間,但消耗掉空間的增幅通常不會超過應用程式碼包大小的20%
    • 由於有了一個轉碼的過程,所以應用安裝時間難免會延長
    • 但是這些與更流暢的Android體驗相比而言,不值一提。
  • Android 9 藉助 ART 執行時顯著提高了應用的效能表現與執行效率。擴充套件了 ART對執行特徵的使用,以優化應用並減少已編譯應用程式碼的記憶體佔用量。ART 現可使用特徵檔案資訊在裝置上重寫 DEX 檔案,幫助多個常見應用的記憶體佔用減少高達 11%。我們期望藉此減少系統 DEX 記憶體使用量並加快應用啟動時間。

2、Kotlin 優化

  • Kotlin 是 Android 開發的一等程式語言,改進了一些編譯器優化,尤其是那些針對迴圈的編譯器優化,以實現更好的效能。

相關文章