① 鴻蒙OS即將發布，會給我們帶來什麼變化，與安卓有哪些區別
隨著各種預熱的到來，華為的自主研發操作系統終於要面向消費者用戶提供服務。在五月二十四日更是將網路平台的EMUI賬號名稱更改為了HarmonyOS。在如今智能時代迅速發展的時代背景下，物聯網的快速發展促使華為正式把鴻蒙推向了 歷史 舞台，而這也是華為推出的「1+8+N」全場景布局的系統支持，你對此有哪些期待？
在今年的四月底鴻蒙OS開發者公測版就已經開始上線，所以已經有了很多使用體驗，原本的神秘面紗也已經逐漸展開。鴻蒙面對消費者來說它有著不變的地方和改變的地方，不變是為了更好地迎合當下消費者的使用習慣，而變化則是為了突出自身特色。
不變之處
1、在系統的交互邏輯以及UI設計上和當下華為用戶的emui 11並沒有太大的出入，在上手體驗上有著同樣的簡潔性和穩定性。
2、並不需要擔心，安卓應用無法使用的情況可以完美地兼容原有的安卓APP，在應用市場的下載過程中，所使用的APP版本也都均為安卓版本。
在原因上，第一為了照顧目前擁有的用戶群體的使用習慣節約了換機成本。第二，不同於iOS以及安卓系統開創性，鴻蒙應用生態還尚未建立起來，如果封閉性的設計無法使用安卓APP的話，在生態的發展過程中會造成很大的流量成本影響。
改變之處
1、在通知欄方面下滑板塊的設計會有不同的展示，比較符合當下統一設計潮流，但是這並不是根源性的改變。
2、鴻蒙版APP軟體體積相對較小在安裝包上有著很大的差距。另外去除了大部分的廣告，並且讓頁面設計更為的流暢動畫效果十分出色。
其實在更深層次的改變上是我們無法看到的，鴻蒙OS是打開物聯網全場景的一把鑰匙。這樣基於微內核面對生活、運動、辦公、開車等等多場景的分布式操作系統，根據你的需要來進行不同的架構部署。三層架構分別是內核基礎服務和程序架構，一個系統可以適配於手機、平板、電腦、智能 汽車 和可穿戴設備的多終端設備進行連接。
在現有的在現有的emui系統中，我們就體驗到了華為的多屏協同功能，以及現在已經是用的華為HiCar和手機的過度上感受到了分布式操作系統的便利。而在之後的過程中，也會融入到 健康 生活運動，智慧駕駛等多個方面，一碰即傳一個攝像頭可以展示多個設備的內容等等。
而讓我最有感觸的就是在運動 健康 方面，華為所做出的努力，隨著華為智能手錶的不斷推陳出新再加上鴻蒙OS的助力。在之後的過程中我們可以在智慧屏乃至 汽車 的中控屏幕上都能夠實時地了解到自己的運動 健康 。
但是了解了很多鴻蒙OS公測版的具體使用感之後看到了很多人對他的評價是安卓套皮，雖然兼容了安卓APP，那麼就等同於兩者大體相同嗎？
安卓操作系統與鴻蒙操作系統都是基於Linux進行開發的，但是二者所採用的架構卻是不同的，譯者是手機終端操作系統的開創者之而鴻蒙OS則是作為物聯網的打開的鑰匙他們的定位以及驅動型都是具有差異感的。 安卓系統採用的是Linux宏內核設計，鴻蒙系統則是採用的微內核設計。
二者的主要差別，其一是功能性和模塊的許可權設計上，以及系統的穩定性區分上。在這其中看到了華為新研發的方舟編譯器，可以保證模塊的出錯率降低，鴻蒙系統加上編譯器可以取代虛擬機來進行底層的通信功能。
而這樣的微內核設計，也正好是適應了分布式的場景設計，而同樣谷歌也正在開發基於微內核的分布式系統，但鴻蒙無疑是先行者，他的上限有多高？也需要我們在之後的使用中來進行體驗。
② android 手機應用開發一般採用什麼框架
android應用開發框架是 Application Framework. 其系統架構由5部分組成，分別是：Linux
Kernel、Android Runtime、Libraries、Application
Framework、Applications。第二部分將詳細介紹這5個部分。下面自底向上分析各層。
Android架構
1、Linux Kernel
Android
基於Linux 2.6提供核心系統服務，例如：安全、內存管理、進程管理、網路堆棧、驅動模型。Linux
Kernel也作為硬體和軟體之間的抽象層，它隱藏具體硬體細節而為上層提供統一的服務。
如果你學過計算機網路知道OSI/RM，就會知道分層的好處就是使用下層提供的服務而為上層提供統一的服務，屏蔽本層及以下層的差異，當本層及以下層發生
了變化不會影響到上層。也就是說各層各盡其職，各層提供固定的SAP（Service Access Point），專業點可以說是高內聚、低耦合。
如果你只是做應用開發，就不需要深入了解Linux Kernel層。
2、Android Runtime
Android
包含一個核心庫的集合，提供大部分在Java編程語言核心類庫中可用的功能。每一個Android應用程序是Dalvik虛擬機中的實例，運行在他們自己
的進程中。Dalvik虛擬機設計成，在一個設備可以高效地運行多個虛擬機。Dalvik虛擬機可執行文件格式是.dex，dex格式是專為Dalvik
設計的一種壓縮格式，適合內存和處理器速度有限的系統。
大多數虛擬機包括JVM都是基於棧的，而Dalvik虛擬機則是基於寄存器的。兩種架構各有優劣，一般而言，基於棧的機器需要更多指令，而基於寄存器的機
器指令更大。dx 是一套工具，可以將 Java .class 轉換成 .dex
格式。一個dex文件通常會有多個.class。由於dex有時必須進行最佳化，會使文件大小增加1-4倍，以ODEX結尾。
Dalvik虛擬機依賴於Linux 內核提供基本功能，如線程和底層內存管理。
3、Libraries
Android
包含一個C/C++庫的集合，供Android系統的各個組件使用。這些功能通過Android的應用程序框架（application
framework）暴露給開發者。下面列出一些核心庫： 系統C庫--標准C系統庫（libc）的BSD衍生，調整為基於嵌入式Linux設備
媒體庫--基於PacketVideo的OpenCORE。這些庫支持播放和錄制許多流行的音頻和視頻格式，以及靜態圖像文件，包括MPEG4、
H.264、 MP3、 AAC、 AMR、JPG、 PNG 界面管理--管理訪問顯示子系統和無縫組合多個應用程序的二維和三維圖形層
LibWebCore--新式的Web瀏覽器引擎,驅動Android 瀏覽器和內嵌的web視圖 SGL--基本的2D圖形引擎
3D庫--基於OpenGL ES 1.0 APIs的實現。庫使用硬體3D加速或包含高度優化的3D軟體光柵 FreeType
--點陣圖和矢量字體渲染 SQLite --所有應用程序都可以使用的強大而輕量級的關系資料庫引擎
4、Application Framework
通
過提供開放的開發平台，Android使開發者能夠編制極其豐富和新穎的應用程序。開發者可以自由地利用設備硬體優勢、訪問位置信息、運行後台服務、設置
鬧鍾、向狀態欄添加通知等等，很多很多。 開發者可以完全使用核心應用程序所使用的框架APIs。應用程序的體系結構旨在簡化組件的重用
，任何應用程序都能發布他的功能且任何其他應用程序可以使用這些功能（需要服從框架執行的安全限制）。這一機制允許用戶替換組件。
所有的應用程序其實是一組服務和系統，包括：
視圖（View）--豐富的、可擴展的視圖集合，可用於構建一個應用程序。包括包括列表、網格、文本框、按鈕，甚至是內嵌的網頁瀏覽器
內容提供者（Content Providers）--使應用程序能訪問其他應用程序（如通訊錄）的數據，或共享自己的數據
資源管理器（Resource Manager）--提供訪問非代碼資源，如本地化字元串、圖形和布局文件 通知管理器（Notification
Manager）--使所有的應用程序能夠在狀態欄顯示自定義警告 活動管理器（Activity
Manager）--管理應用程序生命周期,提供通用的導航回退功能
5、Applications
Android裝配一
個核心應用程序集合，包括電子郵件客戶端、SMS程序、日歷、地圖、瀏覽器、聯系人和其他設置。所有應用程序都是用Java編程語言寫的。更加豐富的應用
程序有待我們去開發！ 從上面我們知道Android的架構是分層的，非常清晰，分工很明確。Android本身是一套軟體堆迭(Software
Stack)，或稱為「軟體迭層架構」，迭層主要分成三層：操作系統、中間件、應用程序。從上面我們也看到了開源的力量，一個個熟悉的開源軟體在這里貢獻
了自己的一份力量。
③ 移動APP開發框架盤點2：Web移動前端框架大全
開源項目其實有一個成熟周期，這個周期大概是三年左右，自React框架在2013年發布並引爆了前端框架的大潮，這個屬於前端的周期就此開始了。
之後在2015年5月開源的React Native又開啟了屬於Web移動前端的周期，15-16年，18-19年，21-22年正好就是屬於移動前端的三個爆發點。
三年前，在第一個成熟收獲期，我盤點了移動開發框架。在這第二個成熟收獲期，理所當然要來盤點一波。
不過，當我點開github項目的code-frequency時，還是被這個准到嚇人的周期猜想驚呆了，先給你們看一波，剩下的自行驗證。
1、https://github.com/youzan/vant/graphs/code-frequency
2、https://github.com/quasarframework/quasar/graphs/code-frequency
再來說第二個比較有意思的發現，停止維護的項目絕大多數是Vue框架項目。
盤點開始的時候我還覺得React框架處於絕對劣勢，到完成時我發現React無論在選擇面還是成熟度上都超過了Vue。
原因我這里就不分析了，反正大家都有自己的看法。
網頁類框架就是前端組件框架，這一次雖然有大量項目停止維護，但是也有很多項目堅持了下來，而且還涌現出了一批新項目。
大廠佔了主導，因為這些年大廠在移動開發上的需求，遠高於其它方面。個人項目要堅持確實不易。
本來是想要做一個驗證項目，把所有框架都試用一遍並給出推薦度的。由於進度太慢，還是下一次再發吧。
這次的重點是漸進類框架，就是所謂多端同構框架（小程序框架）。這幾年國內的重點的各種小程序平台，所以多端框架的需求很是旺盛。
不過大多數先行者都沒挺過來還是讓我很意外，只有Taro成功了，想想還是有很多讓人唏噓的東西。
在這里還是先預測一波吧，因為這一類框架最變化最大，最終還是有很多框架要出局的。
漸進類框架是一個過渡性的產品，最終會變成橋接類框架的一部分，所以，與橋接類框架協同才是框架的出路。
這個賽道基本全是大廠了。
騰訊新一代跨端開發框架Hippy
Hippy一看就是淘寶Weex的對標項目，Kpi功能全面壓制。所以官方支持 React 和 Vue 兩種主流前端框架。在Weex2019年實質停更後發布，要不要這么卷？
Hippy 2.x 架構主要分成三層，UI(JS) 層 Hippy-React 和 Hippy-Vue 負責驅動 UI 指令生成；中間層 C++ HippyCore 負責抹平平台差異性和提供高性能模塊；渲染層 Android 和 iOS 負責提供終端底層模塊、組件，並與布局引擎通信。
對Weex慘遭遺棄，我上次就說過：「ReactNative提供工具，Weex提供框架，將平台差異化屏蔽（Write Once, Run Everywhere）。所以Weex則註定功能相對弱小，並且坑比較多。」Weex最終下馬也是必然的，淘寶又發布升級版北海，為了實現（Write Once, Run Everywhere），它採用自繪，而且是基於Flutter自繪。
所以Hippy3.x就一如既往的Kpi功能層層加碼，很有騰訊風格。在未來的 3.x 中業務與渲染層中的具體實現可根據用戶實際場景進行切換：業務層上不再局限於 JS 驅動，還可選擇（如：DSL/Dart/WASM 等）其它語言進行驅動；在渲染層中，渲染引擎除了支持現有原生（Native）渲染之外，還可以選擇其他渲染 Renderer，如 Flutter(Voltron) 渲染。
「Kraken 北海」是一款高性能Web渲染引擎。底層基於 Flutter 進行渲染。
Kraken 不限制上層開發者使用的框架，無論你是使用 Vue 、Rax 還是 React 都可以開發 Kraken 應用。
Kraken 的 runtime 通過 JS Engine Binding 的方式提供了一系列 Web 標準的 API 介面，調用相應 API 會執行相關邏輯並創建一系列需要發送給 Dart 層處理的指令。
Kraken 其實就是一個小程序平台，而且追求全平台完全一致。我雖然認為各平台不一致是很自然的事情，但是也表示理解，畢竟別人吹牛有當真的傳統（KFC表示認同）。
Kraken 現在也是一個小號瀏覽器，所以它的主要工作就是摳標准，畢竟它是一款基於 W3C 標準的高性能渲染引擎。
最後，我勸淘寶領導定Kpi要理智些，畢竟Hippy4我還蠻期待的。
滴滴出品的超輕量級動態化跨端開發框架，主打輕量和實用。
Hummer 以 JS 引擎為基石，目前已支持 JavaScriptCore、Hermers、QuickJS 等業內知名 JS 引擎（這里本來還有個V8的，我刪除了，源碼裡面沒有，Kpi需要）。再配合經過調優的 Yoga 布局引擎，抹平了兩端視圖布局差異（性能更佳的自研布局引擎開發中）。順便提一下，Hippy採用V8（功能更強）自研布局引擎（性能更佳）。
Hummer 的特點是拋棄了業界其他動態化跨端框架普遍使用的DSL層和VDOM層，因此原生 Hummer 不具備前端開發常用的響應式編程的能力，但同時換來的是接近原生開發的體驗和性能。再以原生 Hummer 為基礎，在此之上開發了一套基於MVVM架構的開發框架 —— Tenon ，通過 Tenon，可以把使用 Vue/React 編寫的代碼，轉換成原生 Hummer 的代碼。
Hummer也是一個小程序平台，而且超輕量。如果想要無限提升自己APP的能力，可以考慮嵌入Hummer。
Web移動前端框架正在迎來第三個高速發展期，各類框架得到極大繁榮。
個人在具體項目的貢獻已經微乎其微了，創新、架構創新是唯一制勝的手段，這也是我看好React的根本原因。
最後，還是想做點微不足道的 探索 ，現在前端組件庫層出不窮，更換組件庫帶來的代價有點大。想創建一個框架，來實現上次說的組件公約數和公倍數，無縫切換組件庫。理論上支持所有組件庫 ，也能為後來者提供彎道超車的機會。我想大廠可能沒有需求，也不會願意發布這種框架，畢竟都是平台部門說了算。
這個庫就是useMobile，當然分為useMobileReact和useMobileVue。下次先發布useMobileReact。等我發布後，再來填上面表中缺的推薦度。
原文地址： https://www.cnblogs.com/windfic/p/16019457.html
④ Android與iOS的區別
1、優先順序別不同：iOS最先響應屏幕
當我們使用iOS或者是Android手機時，第一步就是滑屏解鎖找到相應程序點擊進入。而這個時候往往是所有操控開始的第一步驟，iOS系統產品就表現出來了流暢的一面，但Android產品卻給人一種卡頓的現象，更別說後續深入玩游戲或者進行其它操控了。這是為什麼?
其實這與兩個系統的優先順序有關，iOS對屏幕反應的優先順序是最高的，它的響應順序依次為Touch--Media--Service--Core架構，換句話說當用戶只要觸摸接觸了屏幕之後，系統就會最優先去處理屏幕顯示也就是Touch這個層級，然後才是媒體(Media)，服務(Service)以及Core架構。而Android系統的優先順序響應層級則是Application--Framework--Library--Kernal架構，和顯示相關的圖形圖像處理這一部分屬於Library，你可以看到到第三位才是它，當你觸摸屏幕之後Android系統首先會激活應用，框架然後才是屏幕最後是核心架構。
可以看到優先順序的不同導致了iOS產品以及Android手機在操控過程中的表現差異，當你滑動屏幕進行操控的時候，iOS系統會優先處理Touch層級，而Android系統則是第三個才響應Library層級，這是造成它們流暢度不同的因素之一。不過優先順序對系統流暢性有有影響不假，但並不是最絕對的，造成兩系統之間流暢性不一的現象還有其它因素。
2、硬體工作配置不同：iOS基於GPU加速
目前智能手機硬體裝備競賽當中，其實處理器等配置已經達到了一個瓶頸期，各大旗艦產品在硬體比拼當中基本上沒有太大的區別，而這時候GPU就成為了一個凸顯差異的重要因素。一些大型軟體像是3D游戲對GPU性能要求都會比較高，蘋果iPhone產品採用的Power VR SGX系列GPU在當下來說非常的主流，跑分測試數據證明了它並不會比一些旗艦級別的Android產品差勁。
而iOS系統對圖形的各種特效處理基本上正好都是基於GPU硬體進行加速的，它可以不用完全藉助CPU或者程序本身，而是通過GPU進行渲染以達到更流暢的操控表現。但是Android系統產品則並非如此，因為Android需要適應不同的手機硬體，需要滿足各種差異配置，所以很多圖形特效大多都要靠程序本身進行加速和渲染，並嚴重依賴CPU運算的操作自然會加大處理器的負荷，從而出現卡頓的問題。雖然Android 4.0以及4.1等更高版本中進行了改進將硬體加速設為默認開啟，但依舊無法做到所有特效全部都靠GPU進行加速。在很多Android手機裡面都自帶有;是否開啟GPU渲染;這個功能選項，不過開啟之後的改善也是微乎其微。
屏幕最先響應的優先順序關系，再加上iSO本身GPU加速程序的特性，使得大家在操控過程中感覺iOS手機擁有著不錯的流暢性。因為它本身的整個流程都是在為最大化的流暢做服務，不管是第一印象的滑動接觸屏幕，還是你進一步使用程序之後的更深層操作都是如此。而GPU加速這點特性，應該是它優於Android系統流暢性的又一個因素。
3、開發機制不同：安卓機制效率低
Android的編程語言是JAVA，而iOS的則為Objective-C，不過要是說Android系統之所以有些卡頓是因為JAVA開發語言的關系，或者是拿它和Objective-C對比肯定會有人提出質疑。Objective-C的優勢是效率高但比較;唯一;，而JAVA的優勢則是跨平台不過運行效率相對偏低，其實這兩個編程語言所帶來的機制不同，就已經造成了各自系統之間的流暢性差異化。
iOS的Objective-C，編譯器gcc，而這個gcc編譯出來的代碼又被蘋果專為iOS架構優化到了極致，運行過程中也不需要虛擬機在中間插手，執行效率自然很高--引自網路。這一段話應該是iOS系統本身運行程序的執行過程，而Android是通過JAVA虛擬機來執行，並且系統需要佔用大量內存來換取執行速度，再加上不定期的內存自動回收機制，從而直接導致了卡頓現象的出現。
Android的JAVA編程本身運行效率比Objective-C低一些，而且再加上內存自動回收的機制，所以造成了一些卡頓不流暢的現象出現。但根據技術人員講解，現代的JAVA虛擬機效率已經不再是最大的瓶頸，Android 4.0系統版本之後的卡頓現象明顯得到了改善，所以這也是有用戶並沒有發現自己新買的Android手機出現太多卡頓現象的.原因。看來編程語言和機制已經被Android進行了改善，這同樣也不是造成它與iOS流暢性偏差的唯一因素，不過影響卻是實實在在存在著。
4、系統設計不同：安卓APP無法統一
有了優先順序的關系，有了GPU加加速的影響，還有兩個系統各自編程以及機制的問題，似乎已經可以說明為什麼iOS相比Android更為流暢的原因。但最終還有一個問題是就是應用程序，很顯然用戶覺得卡頓都是在運行軟體的過程中產生，畢竟沒有安裝任何應用的初始出廠手機基本上都不存在不流暢或者延遲等現象，而且一款智能手機不安裝任何應用程序那也不符合用戶的購買初衷和使用行為。所以歸根結底，Android相比iOS的應用程序，到底出了什麼問題?
因為iOS產品的封閉性，所以所有的APP運行對象都比較單一，因為每個應用程序都是被運行在iPhone，iPad等iOS產品當中，它們有著很高的硬體利用效率。因為iOS系統的配件供應商只有那麼幾家，CPU也是一年換一次，這點不像Android終端年年變月月變，開發者很難遇見未來終端解析度會包含多少種，GPU驅動會包含哪些等等，所以相對來說Android應用開發成本較高且收益較慢。而iOS應用開發則因為軟硬體垂直整合而受益，這樣一來蘋果自然就保證了應用本身其與硬體產品之間的完美結合程度。
其實Android和iOS兩大系統APP開發情況的不同，也正是它們開發和不開放的特性所造成的。如果要是拿旗艦Android手機加上一個專為這款旗艦產品設計的游戲，來和蘋果iPhone 5運行對比的話，你真的不會遇到Android旗艦機出現卡頓延遲的問題，為什麼因為這款游戲針對這款手機設計，在軟硬等方面都達到了最大化的兼容和優化，自然就不會出現停滯的現象。
而Android系統程序要被安裝在各種符合要求的手機上面，開發者也不可能針對所有的機器型號進行開發，只能在比較主流的機器上進行測試並保證運行效果，所以他們為了兼顧整個產品線只能不得不降低游戲體驗以達到高中低產品可以共用的效果。最後那些占據了Android終端份額的大量大眾用戶們由於自己的手機不是旗艦產品而得不到流暢的使用體驗，自然而然就會產生Android產品不如iOS流暢的抱怨。