安卓手機aot怎麼解除綁定

① 安卓7.1有哪些新功能 安卓7.1系統新功能介紹

1、分屏多任務

其實這個功能，之前不少廠商已經做了，而谷歌終於讓7.0原生支持了它，從實際體驗來看，戶點擊多任慧彎清務按鍵後，長按其中一個應用，將其拖拽到屏幕頂部或底部，然後再點擊另外一個應用就可以實現分屏多任務功能。

2、「Data Saver」

這個功能簡單來說就是減少App在後台流量偷跑，用戶可以設置黑名單，當Data Saver開啟後，這些黑名單中的App將會受到流量限制措施，同時谷歌也減少一些圖像傳輸的解析度，限制移動流媒體服務的碼率，限制一些軟體的預緩存功能（自動讀取用戶並未請求的數據）。

3、號碼攔截

谷歌還在新系統中加入了號碼攔截功能，用戶可以更好攔截詐騙分子、營銷電話以及其他騷擾電話，而被封殺的電話號碼，將無法來電或者發送簡訊。

4、更便捷的通知中心

谷歌讓7.0系統的通知中心變的便捷且更強大，為了讓用戶節省更多的時間，首先下拉通知欄中最上方加入了快捷按鍵控制開關，同時通知中心能顯示更多的信息，其次用戶可以在通知中心內快速回復消息（免去再打開相應應用的繁瑣步驟了），最後就是消息的歸攏（就是同一個應用的通知變成「通知組」），如當你收到4封郵件，通知中會一一為你展現，你可以挨個或者分批處理（也可以類比QQ消息），很是方便。

5、夜間模式

准確來說，這並不是一個新鬧高功能，6.0預覽版中有，但正式版谷歌給剔除了，現在它又回來了。跟之前不太一樣的是，這次的夜間模式被放在了系統UI設置中，打開後系統會根據環境自動開啟。

6、增強的Java 8語言支持

7、畫中畫模式

這個畫中畫的展現方式跟iOS 9上的基本一致，不過安卓的這個主要是針對電視平台的，當然如果用戶不喜歡屏前前幕平分顯示的話，可以將其中一個窗口調整到設定的最小值。

② Android7.0怎麼樣安卓7.0有什麼新功能

1.主題皮膚管理器
在CM等一眾第三方系統中，早已支持便捷地修改壁紙、圖標和系統顏色。在商店和論壇中，也能找到不少優質的皮膚主題。
而當我們提到原生Android，似乎總是長著一張固定的臉。實際上，在Google自家的AOSP(即Android開源項目)中，早已內置了主題管理。
而在Android M 的開發者預覽版中，也加入了主題管理器(可惜被需要Root和特定方式才能激活)。既然系統內的皮膚主題框架早已搭建好，那就只等Google在Android系統中放出啦。

2.應用程序抽屜的消失
在2月26日，Google Map的官方Twitter發布了一條介紹視頻，其中的展示機Nexus 6P的系統界面中，似乎看不到底部的應用抽屜按鈕了。發現問題的同學也開始集體留言質問：『WHERE IS THE APP DRAWER?!?!』

而在之前也確實有傳聞爆料：在新版Android N 中，或許會將應用抽屜的設計去除，選擇採用iOS和MIUI的應用呈現方式，即全部在桌面首頁中展示。
去除二級菜單的做法，會帶來更加凌亂的桌面，還是更有效率的操作體驗?似乎很難定論，但作為Android玩家，大可選擇Nova啟動器等優秀的第三方桌面，而不必擔心我卓葯丸。
3.夜間模式會許要來了
在Android M 的開發者預覽版中，Dark Mode夜間模式曾短暫地出現過，而在正式版中又被砍去。
而最新的Android N 泄露圖中，黑色背景的右圖也表示著：夜間模式回歸Android了。

而更加值得期待的是，Google已經放出了夜間模式的開發代碼，開發者可以輕松地為自己的應用設定『暗色主題』。也許今後只需輕按『夜間模式』的按鈕，從系統到各個應用，都能直接更換成夜間模式。

這一改變，不僅對於越來越多AMOLED屏幕手機而言，是省電的好方法。對於經常深夜玩手機的同學來說，似乎也可以和刺眼的白光說再見了。
4.分屏多任務以及平板支持
在LG和三星都推出了『分屏模式』後，Google在Android N 中加入分屏功能也是眾望所歸了。同樣的，在上一個版本Android M 中，分屏模式也被隱藏起來，需要特定方式才能激活。
不負眾望，來自Google的Pixel C 團隊在接受Reddit AMA論壇訪談時，確認了『split screen is in the works』。

而分屏多任務，似乎在Android平板上也更加適用。值得一提的是，該團隊也宣稱Android系統的平板，在Android N 中將會更加好用，而不僅僅是將應用界面拉升就夠了。
但對於Chrome OS的聯動猜想、DPI切換和和界面的調整，似乎只能等Google I/O那
天，才知道答案。
5.支持觸控筆
在三星公布的文檔中，我們發現三星在Android N 中，採用了系統自帶的觸控筆介面，而不再使用原先的S PEN專屬介面。
而在Android 5.0 (開始支持節電助手)之前，三星關閉了自家的節電模式介面。在Android 6.0 (開始支持指紋識別)之前，又關閉了自家的指紋識別介面。而在Android 7.0公布之前，三星又再一次關閉了自家的觸控筆介面，這……

6.更好的Doze省電模式
Doze省電模式首次出現在Android M 中，其省電原理是在設備休眠時，關閉關閉應用後台，以達到省電的效果。
在親身體驗後，Doze模式確實發揮了很好的效果，起碼待機的時候不掉電了。但在目前這一功能，在操作體驗和用戶自定義方面，卻有些過於簡單了。
所以直到今天Android 6.0，我依然選擇綠色守護等第三方應用，去實現控制後台應用耗電的問題。但Root終歸有風險，而Android N 也有理由提供一個更好用的Doze省電模式。

7.重新設計的通知欄
在設計上，似乎能探尋的蛛絲馬跡，則是一張Android N 的通知欄模擬圖，國外媒體Android Police在看到開發樣機圖後，大致模擬出的新版界面截圖。
根據爆料，左圖通知欄目前已開始嘗試承載更多的信息量，長按後即可查看通知詳情。而在右圖顯示的快速設置頁面，將快捷按鈕鋪滿並支持分頁，而不像之前只支持固定數量的快捷按鈕。

8.更多玩法的指紋識別
隨著Nexus 5X和Nexus 6P的發布，Google終於開始為Android提供指紋的支持。在Android 6.0中，關於指紋的介面也正在逐步完善。
在目前看來，似乎指紋最常用也僅限於Play Store和鎖屏應用中。期待在Android N 中，能通過指紋解鎖完成更多的事情，在iOS的Touch ID上，有許多值得借鑒的場景。也許之後Androidi用戶能通過指紋，便捷地查看Google相冊中的隱私圖片，或者直接解鎖啟動私人應用。
9.為虛擬現實助力
我們知道，Google正嘗試著於打造一款，不需要額外硬體的頭戴式VR設備。
而反觀目前市面上大部分VR產品，軟體部分的開發似乎都與Android系統多少有些聯系，也許Google自家的VR設備也需要Android的支持。

所以我們有理由相信，Google會為新版本的Android系統，在VR方向上提供更多系統層面的支持。
10.Now on Tap
Now on Tap作為Android M 的重磅功能，在去年收獲了業界好評。大致功能則是基於不同情景而直接提供對應信息，通過識別你正在運行的app中的內容，提供針對性的建議和資料。
比如在網上聊天時，當聊到某部電影時，只需上滑Home鍵，關於電影的所有信息就能直接呈現。

而在Android N 中，我們期待它能發揮更大用處。畢竟Now on Tap中『上下文感知』和『基於情景』都是是人類智能的重要能力。
也許之後當我們打開相機，它就能為你找尋鏡頭中包含的關鍵信息。而不僅限於設定日歷提醒，或者幫你搜索維基網路那麼簡單。

綜上所述的大部分內容，都是我們作為Android老粉絲的期待和猜想。所有一切都要等到Google I/O 2016才會揭曉。
但不得不說的是，雖然在AppSo年度精選的Android榜中，絕大部分應用都採用了Material Design，但是直到今天，這一設計風格在動效和交互上，依然缺少一個完美的榜樣。
我們不會期待Android N 完全改頭換面，帶來全新的界面，但在圖標、按鈕、交互動畫和界面設計上，我們期待Google能做得更好。

③ 此時此刻，鴻蒙時刻——再說華為鴻蒙系統的那些事兒

2021年6月2日，對於華為和很多關心華為的人來說，都是一個重要的日子，因為千呼萬喚的華為鴻蒙操作系統（HarmonyOS）正式發布，雖遲但到。就像HDC 2019上鴻蒙初次發布那樣，准隨著它的爭議從未消失，且更隨著手機鴻蒙系統的推出在即，有愈演愈烈之勢。

在HDC 2019之後，我曾寫過一篇《關於華為鴻蒙系統的那些事兒》的文章，此時此刻，我覺得是時候再說說華為鴻蒙系統那些事兒了——雖然我知道，在這個當口，寫這樣一篇文章很可能給我自己挖一個大坑……

不搞懂Android，你就看不懂鴻蒙

關於鴻蒙的最大爭議點無非就是：「HarmonyOS是不是套殼Android？」要說不是，不服氣的人肯定大把，要說是，那也一樣不得了，那就一層層地說清楚。首先，讓我們看看Google手中的Android操作系統是怎麼回事。

回顧一下Android操作系統的起源。它是由知名IT人Andy Rubin於2003年10月成立的Android公司推出的產品，其本身是基於Linux內核開放源代碼的操作系統；2005年8月，Google收購了Android公司；2007年11月，Android操作系統首次亮相，同時Google宣布以Apache免費開源許可證的授權方式，發布Android的源代碼，Google牽頭的OHA也正式創立（OHA，Open Handset Alliance，該組織最初由34家手機製造商、軟體開發商、電信運營商以及晶元製造商共同組成）；2008年9月，Android 1.0版本正式推出，首款Android智能手機G1發布，宣告了一個新的時代開啟。現在，Android操作系統已經成為智能手機市場第一大操作系統，也廣泛使用在智能手機之外的很多設備上。

Android的起源和開源兩個字分不開。是的，Android系統底層所使用的Linux內核，是必須遵照GPL協議進行開源傳播的(GPL協議，General Public License，簡稱GPL，通用性公開許可證)。這個協議中的一項原則就是：確保軟體自始至終都以開放源代碼形式發布，保護開發成果不被竊取用作商業發售。

因此，採用Linux內核的Android操作系統，也不能違反這個協議， 前邊提到的Android免費開源許可證授權，就是指Google要向使用該操作系統的智能手機廠商提供開放的源代碼，即AOSP（Android Open Source Project），但這部分源代碼並不代表「Android」操作系統的全部。

Google當初看上Android，可不是想要將這個開源系統作為一個免費的「慈善」項目來推動，而是在意Android這個平台的商業化潛力。於是，在收購了Android系統之後，Google就按自己的設想打造Android系統，即在開源代碼的部分之外，基於自家在移動互聯網上強大的控制力，把Gmail、Maps、Google Play、YouTube、Chrome這些我們耳熟能詳的應用服務整合為GMS（Google Mobile Services）服務包植入，從而形成了這個系統的核心競爭力—— 簡單理解Android系統的本質，就是AOSP+GMS的合體。

換句話說，智能手機廠商可以自由使用AOSP提供的免費源代碼進行自家操作系統的開發，但想要賣得好，擁有更多的用戶，卻離不開GMS包含的應用，在Android的商業模式中，Google有一套嚴格的機制在免費開源與付費授權之間取得平衡的。

之前有數據顯示，從2008年~2016年間，Android操作系統為Google供貢獻了高達310億美元的營收，而利潤更是高達220億美元，也就是說，數以億計的搭載Android操作系列和GMS服務包的智能硬體們，都成為了Google帝國的現金奶牛。

只是，Google這個龐大的商業帝國，卻總有不能企及的地方——中國大陸。早年因為不願意服從法律監管，Google幾乎將整個互聯網服務都移出了中國大陸市場，但是Android操作系統卻隨著移動互聯網和智能手機的發展，在中國市場壯大。

這里有一個非常有意思的現象：因為Google不能在中國提供服務，中國的智能手機廠商們，早就習慣了自主開發沒有GMS，但又包含完整本地化服務的自主UI，但因為要面向全球市場，所以又會在自主UI中保留Google GMS框架，這樣就可以在海外市場很方便地接入GMS並激活一系列的服務。

因為GMS服務不能進入中國大陸市場，手機廠商們會在這個基礎上接入很多自己的服務，比如應用商店、主題商店、內容、支付、推送等，可是沒有Google Play的應用審核機制，國內的軟體生態是啥樣大家都看到的，到最後手機廠商自己都受不了了，才有了「統一推送聯盟」、「軟體綠色聯盟」之類的組織，且隨著國家監管力度的加強，現在已經好多了。

隨著Android的市場地位越來越強，Google也開始做一些小動作——畢竟這家公司的口號在2015年就從「Do not be evil」變成了「Do the right thing」。如將一些關鍵特性和重要代碼的更新放入GMS包的版本迭代中，比如部分組件、驅動等，有意拉開Android與AOSP的代數差距，從而凸顯自己的地位，進一步強化對Android生態的控制力。所以，為了能讓自家的UI能有更強的市場競爭力，智能手機廠商們對Android的魔改從來就沒有停止過。

回到華為。2019年5月16日，華為被美國商務部列入實體清單，被視為美國對華為終極打壓的開始，首當其沖的就是銷往全球的華為新款手機不能再使用Android系統。

是的，華為的確是不能使用Google的Android操作系統了，但更具體的描述應該是： 「華為不能在自家手機新品中內置GMS服務，但AOSP源代碼的使用絲毫不受影響」， 而非那段時間盛傳的華為手機從此變磚。但是，無法內置GMS，對於華為手機在全球市場的銷售影響是實實在在的，但好在對於系統本身進化影響並不大——現在讓我們來到第二個話題：「華為掏空Android。」

華為真的掏空了Android？

華為是否掏空了安卓？這應該是每過一段時間就會被拉出來遛一圈兒的問題。其實在我看來， 答案：是也不是。為什麼說不是？因為AOSP還在呢，華為從來沒有說過要排斥這個開源項目的，畢竟在這個軟體生態上運行著數以百萬計的應用，真要把這個掏了，難不成華為要自己做一個全新的軟體生態，腦子抽了還差不多。為什麼說是？因為華為對Android操作系統的改變也是真實的，很多谷歌做的東西，很多都被華為自己的東西替代了。

這個涉及一個主角， 即EMUI，華為自主開發的UI，或者說兩個主角也行，EMUI+HMS。 在這其中，現任華為消費者BG軟體部總裁王成錄王博帶領的EMUI團隊顯得尤其重要，從他2016年加入這個團隊之後，EMUI的根本性改變就發生了，用他的話說：「EMUI不僅僅是一個UI，而是一個平台。」EMUI是如何從UI變為平台的呢？簡單梳理一下：

-EMUI 4.X時代，主要的變化還只是TEE OS（即用於指紋的TustZone）以及SensorHub這樣基於硬體功能的模塊上；

-EMUI 5.X時代，這是一個戰略級別的關鍵版本。解耦Android底層組件，精簡各子模塊。虛擬機在這個版本也得到了優化，特別涉及了垃圾回收機制（GC）、AOT（運行前編譯）、資料庫優化（IO並行）等。在這個版本，新的文件系統F2FS（針對快閃記憶體推出，大幅度減少文件碎片），還有UltraMemory（即4GB運存達到友商6GB運存效果）的推出，通過對各個Android底層技術模塊的深度開發，讓EMUI團隊敢於將「十八月不卡頓」放到了公眾面前，沒記錯這就是EMUI第一個大爭議點出現；

-EMUI 8.X時代，人工智慧技術加入系統，iAware借著算力，整個系統的後台管理模式更合理，圖形引擎得到升級，即半路加入的GPU Turbo，這是EMUI對Android系統全棧圖形模塊修改的開始，EROFS超級文件系統也在此期間亮相開源社區；

-EMUI 9.X時代，也是「Turbo」的時代，GPU Turbo 2.0、CPU Turbo、LinkTurbo都是在這一代出現的，系統性能繼續優化，EROFS正式加入，連接能力得到強化。2019年MWC上，華為「1+8+N」智慧全場景戰略首次浮出水面，在這背後，鴻蒙的研發其實已經悄悄進行了不短的時間了；

-EMUI 10.X時代，分布式技術、軟匯流排、超級終端這一系列的概念出現了，它在HDC 2019上推出，伴隨著它一起發布的就是鴻蒙1.0，其時還是一個半成品，只能叫操作系統內核。只是因為2019年5月16日的事件，它不得不作為戰略產品提前亮相，在推出的時候，鴻蒙就直接宣布將會開源；

-EMUI 11.X時代，鴻蒙來到了2.0版本，但HDC 2020的主角是HMS和AppGallery，不但前邊提到的一系列系統底層的能力變化全部被涵蓋其中，連Google最引以自傲的營收來源GMS服務、Google Play也被替代了。

看完上邊這個簡單的梳理，你是不是對本章節開頭的那個問題概念更明晰了？ 如果說華為掏空了Android，沒錯，華為EMUI團隊覺得Google做得不好的地方，要麼魔改，要麼就乾脆換掉，比如底層連接協議。 特別是在2019年5月16日之後，即EMUI10和11兩代，這樣的動作愈加突出，幅度也越來越大。

要說華為沒有掏空Android，也沒錯， 因為現在華為完全自主運營的AppGallery應用商店，里邊的應用都是基於AOSP規范開發，但又置入了HMS服務的華為版，目的就是為了解決這些應用在沒有GMS支持下的消費者體驗問題。 畢竟在全球范圍內，華為已經積累了7億多終端用戶，在他們換機或是華為解決手機硬體產品問題之前，用戶還是要繼續使用這些華為手機和軟體服務的。

到這里，為什麼會有鴻蒙這個東西了應該也有答案了。 「低情商」的說法，它有點像是華為在EMUI進化過程中，用來解決多設備連接協作問題中的「副產品」；「高情商」的說法，它是包涵底層互聯協議、晶元能力調用、多設備協同過程中交互界面等全方位解決方案的集合體，高效率的連接（HiLink）、低時延（HiLink）以及微內核（比如LiteOS）是它的三大特點，所以，從軟硬體一體化的整體度來說，鴻蒙肯定就是一個全新的操作系統。

因為華為的工程師認為，當前物聯網的連接協議太過碎片化，從業廠商開發理解能力參差不齊，所以最後出來的產品也就五花八門，這樣的情況，將會嚴重影響華為「1+8+N」戰略的推進效果，「1+8」都是華為自己的好說，「N」怎麼辦呢？那就交給鴻蒙來解決吧。

這是發布會後宣布的消息：2020年和2021年，華為按計劃分兩次把HarmonyOS的核心基礎能力全部捐獻給開放原子開源基金會，由開放原子開源基金會整合其他參與者的貢獻，形成 OpenHarmony 開源項目——這和AOSP是不是差不多？這就是為了能讓其他有興趣加入華為「1+8+N」戰略的設備製造和服務提供商能更好的理解這個生態系統。在2021年5月18日上海的華為HarmonyOS Connect夥伴峰會上，華為消費者業務AI與智慧全場景業務部副總裁楊海松還提到了鴻蒙的商業模式，包括免費認證服務這些內容，我有整理專訪，大家有興趣也可以了解一下。

在2019年發布鴻蒙1.0的時候，華為的確是沒有那麼快的計劃將它放在智能手機上。HDC 2019之後對余承東的專訪中，他是這樣說的：「如果我們確認谷歌不再為華為提供操作系統，那麼，我們可以在一夜之間通過升級，將所有的華為手機操作系統的內核更換為鴻蒙，但是我們現在並不打算這么做，因為我們還是希望可以讓合作夥伴（主要是指美國公司）的利益最大化。」

但同時，他也說了三個「Ready」，意即華為是可以隨時這么做，而在6月2日的發布會上，華為手機的鴻蒙升級計劃是何等規模大家也看到了。同樣的問題王博早些時候的回答也是：「做操作系統並沒有難度，關鍵是商業模式的問題。」

時間來到2020年5月16日，美國針對華為的終極制裁到來，手機SoC晶元斷供，蓬勃發展的華為手機業務隨時面臨停擺的問題。雖然現在看，華為還可以通過購買第三方公司的晶元，在全球繼續推出4G手機產品，但GMS同樣不能使用，出貨量也會從過去的億級下降到千萬級，決定華為消費者業務未來的「1+8+N」也隨之面臨巨大的挑戰。兩年前還是商業模式的問題瞬間就變成生死存亡的關鍵，HarmonyOS變得意義更加重大，不得不發。

並肩前行的OpenHarmony和HarmonyOS

我相信有了前邊兩個部分的鋪墊，再進入第三個部分，很多人的困惑應該會少很多。華為目前對鴻蒙這個操作系統的定義是： 「HarmonyOS是新一代智能終端操作系統，為不同設備的智能化、互聯與協同提供了統一的語言」 ，它與我們使用的Android這種宏內核系統在思路上有著本質的區別。

宏內核操作系統我們用得很多，電腦上的Windows、手機上Android都是，它最大的特點是設備要裝載這個操作系統，就得所有的系統組件全部加包一起裝載，不管用不用得著，同時在運行時，系統也會依據內存大小，自動載入組件，響應速度是提升了，但會消耗極大的系統資源。

到2021年我們已經能見到最高達18GB RAM的安卓手機了，而在當前主流的Android 11系統描述中寫到：「設備最小運行內存為512MB」。如果設備的運行內存小於512MB，要到不能用最新版本的Android系統，要麼就只能用老版本——這也是為什麼我們能看到有些車機還在跑Android 4.4版本……

但是鴻蒙的設想就恰恰是反過來，它從架構設計上就進行了全棧解耦，將龐大的操作系統打散，拆解成很小的顆粒，不同能力的設備只需要按自己的要求來選擇相應的模塊能力載入即可， 比如鴻蒙系統的前身LiteOS，它最小的體積只有10KB，你能相信它是操作系統么？可它就是！華為認為這是未來物聯網時代和必然趨勢，巧的是Google也同樣這樣認為，所以，足足被其孕育了5年的微內核操作系統Fuchsia，剛剛於近日才正式推送，它的目標就是替代Android和ChromeOS，從而更好地適應物聯網時代的多樣終端和生態。

為了更好地讓合作夥伴與開發者適配設備與系統的能力，華為將採用鴻蒙系統的設備從L0~L5做了6個分級，其中從L0~L2這三個級別的設備，要麼沒有交互界面，要麼交互和功能都非常簡單，家電、手環就算這種設備，運行內存也非常小，甚至低到KB級，其被定義為瘦終端，它們採用的鴻蒙系統，代碼百分之百來自華為，不包含AOSP的任何部分；而L3~L5這三個級別的設備，有交互界面，可應用擴展，手機、平板、筆記本電腦、車機、VR/AR等這些設備就屬於富終端的類別，它們採用的鴻蒙系統，就會引用AOSP的部分代碼。在這其中，手機無疑是功能最復雜的核心設備，會跑最多的應用，它引用AOSP順理成章。

所以，這次發布的HarmonyOS是何物就好解釋了。 華為軟體團隊開發出的OpenHarmony開源項目用來構建「1+8+N」生態的基礎，在這個基礎上，華為手機終端團隊加入HMS服務包，提供全套華為服務和連接能力，包括嵌入HMS服務的華為版應用，再加上部分AOSP開源代碼，支持Android廣泛的應用生態，保證消費者可以繼續無障礙地使用已有的應用 ，這就是今天發布的HarmonyOS。看到這里，是不是有人感覺眼熟？

沒錯，蘋果現在M1平台的MacBook就差不多是類似的情況，它既可以運行macOS應用，又可以運行iOS應用，而HarmonyOS呢，既可以運行原來的Android（APK）應用，又可以運行鴻蒙平台開發的應用（APK）。所以，6月2日發布會王博演講的最後一個環節的話不曉得各位注意到沒有： 「HarmonyOS是基於OpenHarmony的第一個公開發行版」 ，也算是把兩者的關系做了一個比較明確的定義了。

關於鴻蒙系統是否是完全自主開發，要是沒記錯，華為自己是從來沒有說過這樣的話，但「我們要站在巨人的肩膀上」之類的話倒是看到過不少， 這個巨人放在HarmonyOS上，就是AOSP。至於有人說到的鴻蒙上使用的代碼老舊，經過前邊兩個章節的介紹你應該明白，這對現在的華為和EMUI來說並不太重要，因為Android操作系統最核心的模塊，華為早就已經是脫離谷歌自己在做更新，包括HMS加入後，連應用驗證都自己在做，依賴度已經非常低了。

所以，現在EMUI 11還只基於Android 10版本的AOSP代碼，但其對比採用Android 11版本的友商系統體驗如何，相信大家心裡是有數的。只是因為環境的關系， 本來應該「慢工出細活」的事情，全部被按下了快進鍵，很多還沒來得做的事情，也都因為時間不夠沒有完成，比如代碼替換等，相信今年的HDC 2021上華為軟工團隊會有更多新消息放出。

選擇在現在推出HarmonyOS，對於華為也是有風險的，早年阿里YunOS與Android商業生態的沖突讓我們第一次理解到了Google對「開放」的態度。現在，HarmonyOS可能面臨的情況也差不多，但好在華為有HMS和初具規模的AppGallery可以進行一些對沖。

但對比這樣的風險，真正的風險還是時間。從2020年5月16日算起，到現在已經過去了一年，消費者的換機周期是28個月左右，留給華為以手機產品為中心推進「1+8+N」戰略的時間並不多，在餘下的短短1~2年時間里，華為除了繼續保留盡可能多的存量用戶，還需要完成去手機中心化的「1+8+N」戰略，還需要團結盡可能多的手機廠商來形成新的中心，從之前與楊海松的對話來看，新戰略中的「1」，很有可能就是App了。

但另一方面，楊海松也說過： 「華為擅長做產品而不擅長做生態」，這也是一個現實的問題，以前華為做產品，秉持的是「進入一個行業，就一定要做到世界第一」的「霸道」原則，現在做生態，華為應該想的是如何交到更多朋友，合作共贏，姿態非常重要……

寫在最後

「華為推出HarmonyOS，中國驕傲」，發布會之後，以此為主題，各種各樣的雞血文章、小視頻又出現在各大內容平台上，好一場流量盛宴。類似的場景也出現在一年前，在他們口中，似乎華為能以一己之力，一夜之間釐清中國整個晶元產業的 歷史 欠賬。華為人並非沒有看到這些，但現在的他們，哪裡有功夫去理會這些論調，有太多事要做了。雖然這篇長文，也許看到的人和看完的人有限，但我覺得能把那些關於HarmonyOS的事兒解釋清楚，足矣。

④ 安卓art虛擬機在什麼位置

一、概述
我們知道Android的程序雖然也是使用Java/Kotlin語言編碼，並生成.class位元組碼，但並不能直接運行在JVM上，而是運行在自己的VM上。而Android程序之所以不能在JVM上運行的根本原因是.class位元組碼文件並不是Android的最終可執行文件(執行頌喚首效率問題)，而是一個過渡產物，最終會生成dex文件在Android VM上執行。

1.1 Android虛擬機分類：
Android VM大體分為兩種： Dalvik 虛擬機和 ART虛擬機。

Dilvik 虛擬機：Android 5.0 版本之前。
ART虛擬機：Android 5.0 版本全面使用。
1.2 虛擬機的演變及優化：
Android 1.0，使用Dalvik作為Android虛擬機運行環境，此時的虛擬機是一個解釋執行器。
Android 2.2，Android 虛擬機中加入了JIT編譯器（Just-In-Time Compiler）。
Android 4.4，全新的ART虛擬機運行環境誕生，此時ART和Dalvik是共存的，用戶可以在兩者之間進行選擇。
Android 5.0，ART全面取代了Dalvik成為了Android虛擬機運行環境，並使用AOT預編譯技術在安裝Apk時全量預編譯 。
Android 7.0，ART虛擬機採用 JIT/AOT混合編譯模式。
二、Dalvik
Dalvik是Google公司自己設計用於Android平台的虛擬機，它是Android平台的重要組成部分，支持dex格式（Dalvik Executable）的Java應用程序的運行。dex格式是專門為Dalvik設計的一種壓縮格式，適合內存和處理器速度有限的系統。Google對其進行了特定的優化，經過優化的Dalvik，具有高效、簡潔、節省資源的特點，同時還允許在有限的內存中同時運行多個虛擬機的實例，並且每一個Dalvik 應用作為一個獨立的Linux進程執行。獨立的進程可以防止在虛擬機崩潰的時候所有程序都被關閉。
2.1 Dalvik和JVM的區別
Dalvik 基於寄存器，而 JVM 基於棧。
指令數量：基於寄存器的操作指令，會增加操作數的大小(劣勢)，但是會大大減少操作指令的數量(優勢)
操作效率：基於寄存器(CPU上)的指令操作速度比基於操作數棧(主存)的速度快。
移植性：基於寄存器執行效率好，但是可移植性差，難跨平台。
Dalvik虛擬機有共享機制，不同應用之間在運行時可以共享相同的類，擁有更高的效率。
2.2 JIT（Just-In-Time Compile）
Android 2.2之前，Dalvik虛擬機是通過解釋器 (解釋器逐條讀入位元組碼 -> 逐條翻譯成機器碼 -> 執行機器碼)來執行程序的，效率低。針對這個問題，引進了JIT（即時編譯器）技術。它是一種優化手段。

JIT技術：將解釋過的機器碼緩存起來，下次再執行時到這個方法的時候，則直接從緩存裡面取出機器碼來執行。減少了讀取位元組碼和翻譯位元組碼的操作。以此來提高效率。JIT技術的引入使得Dalvik的性能提升了3~6倍。

注意： 並不是所有執行過的代碼對應的機器碼都會被緩存起來。而是只有被認定為熱點代碼（Hot Spot Code） 的代碼才會。這里所指的熱點代碼主要有兩類，包括：
被多次調用的方法
被多次執行的循環體（雖然只是循環體被多次執行，但仍是將整個方法的機器碼緩存起來）。

缺點： JIT技術的缺點：
每次重新啟動引用都需要重新編譯。
運行時比較耗電。
三、ART 虛擬機
ART虛擬機在Android 5.0開始替換Dalvik虛擬機，其處理應用程序執行的方式不同於Dalvik虛擬機，它不使用JIT而是使用了AOT（Ahead-Of-Time），也就是鏈伏提前編譯技術。並對垃圾收集器也進行了改進和優化。

預先編譯機制(AOT)可提高應用的性能。同時ART 還具有比 Dalvik 更嚴格的安裝時驗證。

3.1 AOT（Ahead-Of-Time）預先編譯技術
AOT(提前編譯技術)： 簡單來說就是提前將位元組碼轉換成本地機器碼，然後野數存儲在本地磁碟上，運行時可以直接執行，避免了Dalvik時期的應用運行時再來解釋位元組碼。運行時效率大大提高。

在Android 7.0 之前，Android系統安裝Apk時，會進行一次全量預編譯，將位元組碼預先編譯成本地機器碼，生成 oat文件，並存儲在本地磁碟上。這樣在App每次運行時就不需要重新編譯，可以直接使用編譯好本地機器碼，運行效率大大提升。但是這也使得安裝應用的時間大大增加，於是在Android7.0及之後，又重新引進了JIT技術，形成JIT/AOT混合編譯模式。

混合編譯的特點：

應用在安裝的時候，不進行AOT預編譯。
應用運行時直接通過解釋器翻譯位元組碼為機器碼然後執行。（在應用運行期間使用了JIT技術）並同時記錄熱點代碼信息到profile文件中。
手機進入空閑或充電狀態的時候，系統會掃描APP目錄下的profile文件，並通過AOT對熱點代碼進行編譯。
下一次啟動時，會根據profile文件來運行已編譯好的機器碼，避免在運行時對已經轉換為機器碼的方法又進行了JIT編譯。
應用運行期間會持續對熱點代碼進行記錄，以方便在空閑或充電時進行AOT，以此循環。
使用JIT編譯器來對AOT編譯器進行補充，降低了Apk安裝的時間，提升了運行時性能，節省了存儲空間，加快應用運行速度。

小結：
Android 7.0以前，採用AOT全量預編譯，Apk安裝時預編譯dex生成對應的機器碼文件。但預編譯量大導致Apk安裝時間長。
Android 7.0及之後，採用JIT/AOT混合編譯模式，根據對應的profile在空閑時進行AOT預編譯。

參考： 實現 ART 即時 (JIT) 編譯器

3.2 Dalvik與ART虛擬機的區別
Dalvik每次都要編譯再運行，Art只會安裝時啟動編譯(7.0之前全量預編譯)。
Art佔用空間比Dalvik大（原生代碼佔用的存儲空間更大），就是用「空間換時間」。
Art減少編譯，減少了CPU使用頻率，使用明顯改善電池續航。
Art應用啟動更快、運行更快、體驗更流暢、觸感反饋更及時。
3.3 Interpreter解釋器、JIT、AOT的在ART上的使用
解釋器： 逐條讀入位元組碼 -> 逐條翻譯成機器碼 -> 執行機器碼，重復執行同一代碼時需要重新翻譯執行。
JIT編譯器： 對運行時的熱點代碼(熱點代碼)進行編譯，且緩存在內存中，當下次繼續執行時，直接從內存中獲取，減少重復編譯。
AOT編譯器： 在運行前將位元組碼轉換為機器碼，在運行時直接運行轉換後的機器碼。

在這里插入圖片描述

3.4 垃圾回收方面的優化
Android虛擬機（Dalvik && ART）學習

四、Android中的幾種文件
4.1 Apk文件
APK 文件其實是 zip 格式，在Window平台上可以直接將後綴格式改為zip進行解壓。解壓後的目錄如下圖所示：
在這里插入圖片描述

文件名 說明
META-INF/ 信息描述，簽名等用途。編譯生成一個apk包時，會對所有要打包的文件做一個校驗計算，並把計算結果放在META-INF目錄下。而在Android手機上安裝apk包時，應用管理器會按照同樣的演算法對包里的文件做校驗，如果校驗結果與META-INF下的內容不一致，系統就不會安裝這個apk。這就保證了apk包里的文件不能被隨意替換
res/ 存放資源文件
libs/ 存放的是 ndk 編出來的 so 庫
AndroidManifest.xml 程序全局清單文件
classes.dex dalvik 位元組碼
resources.ars 編譯後的二進制資源文件，主要是對應的索引
assets/ 保留工程中assets目錄，其他工程下的、jar包中的assets也會合並到該assets目錄下。
4.2 dex文件
dex 文件是可被Dalvik虛擬機識別並執行的文件， Dalvik 會執行 .dex 文件中的 dalvik 位元組碼，但一般Dalvik在執行dex優化後的文件(即odex文件)。

dex文件特點：

dex文件是Android系統中的一種文件，是一種特殊的數據格式，和Apk、jar等格式文件類似。
文件更加緊湊：dex文件是能夠被DVM識別，載入並執行的文件格式。相比於Jar文件，dex會把所有包含的信息整合在一起，減少冗餘信息，從而降低了載入文件時的I/O耗時，提高類的查找速度。
dex文件包含應用程序的全部操作指令和運行時數據。
相對於PC上的JVM能運行 .class文件，Android上的Dalvik虛擬機能運行 .dex 文件。
.dex文件和 .class文件的格式對照：
在這里插入圖片描述
dex 文件結構：
在這里插入圖片描述

4.3 引起dex文件65535問題的原因
當Android系統啟動一個Apk時，會通過 dexopt 工具對dex進行優化。dexopt 的執行過程是在第一次載入dex文件的時候執行的。這個過程會生成一個odex文件，即Optimised Dex (執行odex的效率會比直接執行Dex文件的效率要高很多)。但早期Android系統中， dexopt 有一個問題(即65535問題)。dexopt會把每一個類的方法id檢索起來，存在一個鏈表結構裡面。但是這個鏈表的長度是用一個 short類型(2^16=65536)來保存的，導致了方法id的數目不能夠超過65536個。
4.4 odex文件 (Optimized DEX)
背景： 對Android dex文件進行優化來說，需要注意的一點是dex文件的結構是緊湊的，但是我們還是要想方設法進行運行速度的提高，因此我們仍然需要對dex文件進一步優化。
odex文件的使用場景：

安裝階段： Apk在安裝時，系統會進行驗證和優化，目的是為了校驗代碼合法性及優化代碼執行速度。當驗證和優化後，系統會從Apk中提取dex文件進行優化，並將優化後的產物(odex文件)保存到 data/dalvik-cache 目錄下。
運行階段： 當運行Apk的時候，會直接載入odex文件，避免重復驗證和優化，加快了Apk的響應時間。
odex 文件的生成過程：

Android 5.0之前：Dalvik虛擬機

Dalvik虛擬機會在執行dex文件前對dex文件做優化，生成可執行文件odex，保存到 data/dalvik-cache 目錄，最後把Apk文件中的dex文件刪除。

注意： 此時生成的odex文件後綴依然是dex ，它是一個dex文件，裡面仍然是位元組碼，而不是本地機器碼。
Android5.0 <= Version < Android 8.0 (Android O)：ART虛擬機

Android5.0之後使用ART虛擬機，ART虛擬機使用AOT預編譯生成oat文件。oat文件是ART虛擬機運行的文件，是ELF格式二進制文件。oat文件包含dex和編譯的本地機器指令，因此比Android5.0之前的odex文件更大。

oat文件生成過程：
App在首次安裝的時候，dex2oat 工具默認會把 dex文件翻譯成本地機器指令，生成ELF格式的OAT文件，並將其放在了 /data/dalvik-cache 或 /data/app/packagename/ 目錄下，此時oat文件後綴格式為odex。
ART載入oat文件後不需要經過處理就可以直接運行，它在編譯時就從位元組碼裝換成機器碼了，因此運行速度更快。
Dalvik虛擬機執行程序dex文件前，系統會對dex文件做優化，生成可執行文件odex，保存到 data/dalvik-cache 目錄，最後把apk文件中的dex文件刪除。 (注意：此時生成的odex文件後綴依然是dex ，它是一個dex文件，裡面仍然還是位元組碼，而不是本地機器碼。)

注意： Android5.0及之後版本生成的 oat文件後綴還是odex，但是已經不是android5.0 及之前版本的文件格式，而是ELF格式封裝的本地機器碼。可以認為oat在dex上加了一層殼，可以從oat里提取出dex。
Android O及之後(>=Android 8.0)：ART虛擬機

Android 8.0及之後版本，dex2oat會直接生成兩個oat文件 (即vdex文件 和 odex文件)。其中 odex 文件是從vdex 文件中提取了部分模塊生成的一個新的可執行二進制碼文件，odex 從vdex 中提取後，vdex 的大小就減少了。

文件生成過程：
App在首次安裝的時候，odex 文件就會生成在 /system/app/<packagename>/oat/ 下。
在系統運行過程中，虛擬機將其 從/system/app 下 到 /data/davilk-cache/ 下。
odex + vdex = Apk 的全部源碼 （vdex 並不是獨立於odex 的，文件 odex + vdex 才代表一個Apk ）。
odex 的優點和缺點：

優點：
啟動快： 省去了系統第一次啟動應用時從Apk文件中讀取dex文件，並對dex文件做優化的過程。和
對RAM的佔用（Apk文件中的dex如果不刪除，同一個應用就會存在兩個dex文件：apk中和 data/dalvik-cache 目錄下）。
安全性：防止第三方用戶反編譯系統的軟體（odex文件是跟隨系統環境變化的，改變環境會無法運行；而apk文件中又不包含dex文件，無法獨立運行）
劣勢：
優化後的odex文件大小通常是原dex文件的1~4倍 (空間換時間)。
4.5 vdex文件
vdex文件是 Android O (Android 8.0) 新增的格式包，其目的是為了降低dex2oat時間。

dex2oat的觸發場景：

當系統OTA (系統升級) 後，用戶自己安裝的應用是不會發生任何變化的，但 framework 代碼已經發生了變化，因此就需要重新對這些應用也做dex2oat。如果沒有vdex文件，則需要重新校驗Apk里dex文件合法性；如果存在vdex文件，就可以省略校驗的過程，節省一部分時間。
當App的 JIT Profile 信息變化時，background dexopt會在後台重新做dex2oat，因為有了vdex，這個時候也可以直接跳過dex文件的校驗流程。
dex 文件直接轉化的可執行二進制碼文件：

App在首次安裝的時候，vdex文件就會生成在 /system/app/<packagename>/oat/下。
在系統運行過程中，虛擬機將其從 /system/app 下 到 /data/davilk-cache/ 下。
4.6 art文件
art文件是由虛擬機執行odex文件後，記錄虛擬機執行Apk啟動的常用函數地址信息後生成出來的文件(記錄函數地址信息方便定址)，目的 是用於加快應用啟動速度。通常會在data/dalvik-cache/ 目錄中保存常用的jar包的相關地址記錄。

第一次開機不會生成在 /system/app/<packagename>/oat/ 下，以後也不會。
odex 文件在運行時，虛擬機會計算函數調用頻率，進行函數地址的修改。
最後在 /data/davilk-cache/ 由虛擬機生成 art文件(art文件生成)。
生成 art文件後，/system/app 下的odex 和 vdex 會無效，即使你刪除，apk也會正常運行。
push 一個新的apk file 覆蓋之前 /system/app 下Apk file ，會觸發 PMS 掃描時下發 force_dex 的flag ，強行生成新的vdex 文件 ，覆蓋之前的vdex 文件，由於某種機制，這個新vdex 文件會到 /data/dalvik-cache/ 下，於是 art 文件也變化了。
4.7 oat文件
ART虛擬機運行的是oat文件，oat文件是一種Android私有ELF文件格式，oat文件包含有從dex文件翻譯而來的本地機器指令，還包含有原來的dex文件內容(如下圖所示)，因此oat文件比odex文件更大。APK在安裝的過程中，會通過dex2oat工具生成一個OAT文件(文件後綴還是odex)。對於apk來說，oat文件實際上就是對odex文件的包裝，即oat=odex。

注意： Android5.0 及之後的版本，oat文件的後綴還是odex，但是已經不是android5.0 之前的文件格式，而是ELF格式封裝的本地機器碼。可以認為oat在dex上加了一層殼，可以從oat里提取出dex。