tonylch wrote:
華為本身就有自己的APP商店，如果鴻蒙系統效能真的比Android高，所有 App都進華為商店，應該也有人會買單吧？..(恕刪)
在鴻蒙上跑Android APP要達到宣傳的那種效能，前提是(1) 這個APP是CPU bound的程式 (2) 開發商要願意用方舟編譯器重新編譯一個native code版本上架，並不是所有既有Android APP安裝到鴻蒙上，就會自動加速，不了解系統軟體的，很容易就會被華為發表會所用的話術誤導。
APP開發商通常會願意維護iOS跟Android兩大APP商店的兩個版本，若要推出第三個版本，並不是光進行編譯就好，後續要測試、要進版、要維護、要上架被抽成，這些對於軟體開發商，都是雞生蛋、蛋生雞的商業成本考量。
如果華為不得不在手機上導入鴻蒙，可以想見的是，華為會支付補貼費用，讓一些需要榨出CPU效能的熱門程式 (遊戲/benchmark測試程式) 開發商以及部分重量級APP原廠，將其應用程式移植到鴻蒙，這是新進作業系統廠商都會使用的作法， 微軟WP也是，三星Tizen也是，但是要形成蓬勃生態系，那完全是另一回事。
上世紀的程式 (如DOS/Windows/Macintosh/SunOS......等等作業系統下的程式)，都是編譯成特定處理器架構(如80x86、680x0、SPARC...等等) 的native code，或者說從電腦開始發展/有編譯器開始，一直就是這樣，甚至部分重要的routine，程式設計師會直接用低階組合語言來寫，以榨出最大效能。但組合語言程式缺點是不好寫/不好讀/難維護/沒有跨處理器架構的移植性，而用高階語言如C/C++寫的程式，在移植到其他平台時通常也要重編譯，因而後來才出現基於Java/.NET Framework這類運行在虛擬機上的程式，在不同的作業系統/處理器平台上，只需要有對應的虛擬機如Java VM， 就可以執行Java程式，APP廠商不需要重新開發/重新編譯；這也是因為這十幾年來PC/手機處理器效能，整體已發展到了一定的高水準，因此就算多了虛擬機那一層拖慢效能，使用者體驗還是可以接受的。
簡單講，鴻蒙+方舟編譯器所訴求的效能跟生態系，就是拿掉虛擬機那一層，盡可能走native code，但有利當然就會有弊，比如說：未來如果華為要押寶/轉移到RISC-V架構， 除了還要再推出RISC-V版本的鴻蒙作業系統/方舟編譯器，還得看所有抬轎的應用APP廠商，願不願意全部再重新編譯/再多維護一個RISC-V的APP版本，這又是成本，並不利於鴻蒙的生態系形成。
更何況，這次的"開發者"大會，不如說是PPT發表大會，進餐廳想吃飯，侍者光給幾道招牌菜的宣傳單，不給看完整菜單也不給點菜、更別說上菜，是怎樣？
處理器的L1/L2/L3快取大小比起主記憶體容量，通常小很多，乍看似乎作用不大，但一旦停用處理器快取，效能就會巨幅下降。處理器快取之所以能發揮功能，一個重要的學理是基於spatial locality跟temporal locality原則，也就是90%的處理器執行時間，大都花在10%的程式碼上面；而剛剛被執行過的程式碼，有很高機率會馬上再被執行到 (例如：迴圈)。
Android本身就可以用NDK開發程式，對於需要榨出處理器效能的應用程式，原本就可以編譯成native code衝效能 (特別是那些佔了90%執行時間的10%關鍵程式碼)，並非一定要鴻蒙+方舟編譯器才行，而且基於locality原則，本來就不用把Android所有程式全部都變成native code，大部分非CPU bound的routine，可用bytecode型式繼續運行在Android作業系統提供的JIT/AOT模式下，程式碼較好維護/移植，安裝占用的空間較小，端看APP的本身屬性跟開發商的選擇/程式架構規劃。
作業系統廠商的任務，是在作業系統本身提供有彈性的運行模式，跟維運對應的開發環境/開發工具，不是替應用程式開發商決定一定要用什麼模式，這才更容易吸引應用程式開發商自發性抬轎。大大小小千千萬萬應用程式開發商的自發性抬轎，才是形成生態系的門檻所在。
