作為Android 底層音影片和圖形渲染10年的開發者，華為底層系統 bug 極多。
這些 bug 很多來自於驅動層，而且找不到渠道反饋--他們的客服和論壇都是面向消費者的，明確的系統API Bug 無人處理。因此基本沒法指望他們能更新系統後解決問題。
當然說進步，還是有的。早期的麒麟，硬體解碼器造成宕機是常態，近些年好很多。但是這塊相容bug仍然層出不窮，適配費心費力。
圖形驅動這塊同樣是重災區，說多了都是淚。
與之對比，小米家的會好很多，尤其是用高通晶片的。當然類似的 Bug 仍然存在。
這塊不能完全說是華為的問題，Google 的 Android CTS 相容測試對多媒體框架層和圖形驅動層的測試嚴重覆蓋不足，所謂Android 系統就是各種五花八門的硬體開發板披上了一個長得一樣的皮，當應用行為依賴於硬體加速時，這個皮就被輕易戳破了。
補充:
FAQ
Q: 我用的 EMUI 就是比 MIUI 穩定
A: 答案討論的是底層系統的 bug，尤其是多媒體框架層和圖形驅動，這些 bug 並不一定在常用應用和系統自帶 app 中暴露。另一方面，第三方應用開發者在遇到系統 bug 後，都會嘗試繞過 bug，確保 app 能正常執行。
Q：既然 bug不會暴露，應用也會適配，那關使用者什麼事， 題目問的是 MIUI 和 EMUI 哪個體驗更好。你們所謂的底層程式設計師在這鑽牛角尖。
A：一般遇到特定某個手機廠家系統才出現的 bug，應用開發者會有多種處理方式：1） 調整程式邏輯，找到辦法完美避開系統 bug，沒有影響效能，也不影響其它沒有這個 bug 的手機的相容性。所有手機按照調整後一致的邏輯處理——這是比較完美的情況，但是並不都是這樣。
2） 這個 bug 沒有完美不影響效能的方式。只能遮蔽造成 bug 的系統介面的呼叫，採用其它方式實現——對於多媒體和圖形渲染，這往往意味著遮蔽了一些關鍵的硬體加速介面，結果是在一些場景上，app 效能大幅下降，發熱加重。
3） 調整程式邏輯，能夠針對發現 bug 的機器解決問題，並且不影響效能，但是這套邏輯“有副作用”，不能在其它手機上執行，否則會造成錯誤。
第3種情況，應用開發者比較糾結。因為同品牌手機型號很多，且不同系統版本行為也可能存在差異，因此可能很難準確判斷哪些型號的手機需要採用這種特殊帶副作用的。
最粗暴的解決方式，和 2 一樣，程式中檢測這臺手機的廠家名，一旦確定手機是這個廠家的，直接遮蔽造成 bug 的介面的使用。這意味著在這種場景下，這個品牌的所有手機效能都下降了，即便這個品牌很多手機沒這個 bug。
更精細的方式是，儘可能覆蓋測試，包括透過雲測，去覆蓋測試更多這個廠家的手機型號，建立一個名單，分名單採取不同措施，沒有 bug 的正常邏輯，有 bug 的儘可能透過“有副作用”但是能保證效能的方式執行，最後的方式才是直接遮蔽相關介面，以犧牲效能的方式來相容。這種方式可能還要考慮不同系統版本行為不一致帶來的風險，很難完全覆蓋測試一個廠家的所有手機型號，因此仍然存在 bug 被應用暴露出來的風險。
我想對於中小型公司，大部分開發團隊會傾向於使用最粗暴的解決方案，風險最小，需要人力最少。
但對使用者來說，這意味著，明明我手機的硬體效能，可以一分鐘剪輯生成一個影片，變成要兩分鐘三分鐘，而且手機還特別燙，掉電特別快。
因此，顯然，系統的 bug 是關乎於使用者的體驗的。
Q：所以你的意思就是 MIUI 開發團隊比 EMUI 牛咯？
A：無法得出這個結論。
上面我討論的這些 bug，有小部分是 ROM 開發者的 bug，但大部分，來自於多媒體處理驅動和圖形驅動。因此，這些底層 bug，如果在小米手機上出現，那邊一般也會在採用相同 SOC 的其它品牌手機上出現。
一般這些驅動並不是由 ROM 開發團隊開發，而是由 SOC 等方案提供方提供，並且閉源，ROM 開發者無法修改程式碼。
小米使用的是高通和 MTK 的SOC，上述驅動一般由高通和MTK提供，並不由小米自己開發。
而華為，在今年之前，普遍採用的是自家海思提供的麒麟晶片，相應的驅動也是自己開發。
因此，只能說，高通的相關驅動比麒麟的驅動更加穩定（MTK 問題不比麒麟少）。
Q：說了半天，都是第三方驅動決定的，那還扯什麼 MIUI 和 EMUI
A：無論 MIUI 還是 EMUI，對於使用者來說，都是一個完整的手機系統。
不論在系統內部是自研的方案還是第三方方案，都有責任確保系統的穩定性，儘可能減少 BUG。即便採用了第三方方案，不能直接修改原始碼解決，也要儘可能在出廠前做好相容和穩定性測試，將發現的問題反饋給方案提供方解決。
只要是使用 MIUI 和 EMUI 過程中的問題，就是 ROM 的問題。
