如何評價uni-app？
矮胖老實人2022-02-18 17:31:14宣稱：uni-app，開發一次全端覆蓋（iOS、Android、H5、微信小程式、百度小程式、支付寶小程式）
uni-app官網
2020-05-10 12:35:30看了CEO本人的回答。我很奇怪，
案例數量多和好不好用
有什麼關係呢？或者換句話說，案例數量多是因為你們的技術成熟了嗎？我覺得不是。
假如你們做出來的東西是個網球發球機，宣稱是“uni-app牌發球機在手，做啥都不愁”。你們的網秋機10秒發一個球，對一般人來說沒啥問題了。但就有一些業務場景裡接球的是世界第一選手，需要1秒發一個球，你的發球機發不出來。面對開發者們的責問，你回答道：
世界上有幾百萬人在用我們的網球機，案例數量多得很。你覺得不好用，那你有給我列舉一下哪裡不好用
（我好一條條批判你）
。
當然括號裡的話你沒說出來，但從你的行動上看你大致就是這麼個意思。先跟你道個歉，我上面的例子舉的可能不是很好。但請你想一想，覺得 uni-app 不好用是開發者的錯嗎？
我覺得是，要怪就怪他們技術選型階段沒有結合自己的專案考慮和調研清楚。但仔細想想，他們說的沒錯，你的發球機對他們來說就是垃圾，同時對其他人來說可能也是寶貝。你不能把所有說uni-app垃圾的人都懟一遍吧？如果真有人這麼做，這個人的格局在技術圈確實算是小的可憐了。
jQuery用了十年了，夠成熟了吧？jQuery的成熟建立在優秀的文件、活躍的社群這些良好的生態的前提下。現在，jQuery經過了時間的考驗，活躍度下降到低點。但即使這時候有個新入行的想從jQuery學起，他一樣能解決他遇到的幾乎全部的問題，因為生態圈子好，社群活躍過，文件也沒落上灰塵。只要有網線，就能學會jQuery。
反過來看看無論是放棄治療的 MUI 還是 uni-app，都遠遠談不上成熟。你們的生態圈還沒活躍過，就想轉入“生活防疫階段”，就像評論裡 @劉子路 說到的，嗨呀，商業化太早了，我們玩不起啊。
再就是曾經看過你們對比 uni-app 、flutter 和 RN 的一篇文章。說實話，我第一次見到這樣對比技術和框架的文章：你們列舉的某些 flutter 和 RN 的劣勢甚至是 project-specific 的。這就有點像是 YTB 上把印度和中國做了個比較，避重就輕比一些奇奇怪怪的地方，最後得出結論印度和中國是不分伯仲的世界強國一樣令人有些匪夷所思。
我寫過程式碼，帶過團隊，翻譯過文件。我見過很多寫的糟糕的文件，但對於 Dcloud，你們有著幾百萬使用者的開源技術，文件還寫成這個樣子實在是令我摸不著頭腦。你們的文件能讓人把環境搭建好跑起demo來，但說句實在話，這文件太不專業了。處處充滿營銷的味道，行文語法和用詞總是頻頻讓人齣戲。就好比英文博士論文裡出來一段中國方言一樣讓人覺得不太對勁。
最後給個建議，對於大家已經不斷提出過很多次的問題，
別TM裝聾作啞了
。社群不活躍，怎麼辦？文件寫的不好，怎麼辦？生態圈子跟個十二級強風下的遮陽傘一樣形同虛設，怎麼辦。若是你不去解決大多數人的問題，就算有一天 uni-app 真的成熟了，又能怎樣呢
2020-06-17 11:27:53如果要同時開發兩端以上，總成本應該是比單獨用H5和小程式各做一遍要低。
上個月開始入坑uni-app，因為不喜歡rpx這種單位（我不喜歡隨解析度放大字型，喜歡自適應佈局），所以自己基於基礎元件封裝一套自定義元件。
但是過程中發現，坑實在是太多太多太多太多了，例如picker-view在popup中樣式混亂的問題；swiper沒有控制輪播滾動的方法；嗯，APP端還不支援slot插槽繫結動態的名稱，這對於自定義元件的封裝來說簡直是災難。
還有uni。createSelectorQuery（）這個控制佈局的方法，我開始以為這就是querySelector的變種寫法，沒想到是個閹割版的，總是不能跨元件、跨頁面選取物件，我想在自定義元件裡控制插槽裡的物件做互動就束手無策了。
對於寫慣了H5的人來說，用這個東西就有一種帶著鐐銬跳舞的感覺，每寫一個方法，都要查一遍文件，看看支不支援。
當然做跨端開發框架是非常困難的事情，我也能理解產品至今以來的各種缺陷，既然有迫切的跨端開發需求，而且又選擇相信他們，那我就只能作為開發者和他們的產品一起成長，碰到坑了，看一下原始碼，想辦法繞吧。
當然，我很害怕的是，當我透過各種不優雅的手段繞過了一些坑，日後官方產品最佳化後，我這些填坑的程式碼不知道會不會成為新的BUG。
—————————————— 4。30 更新 ——————————————————-
坑了一個月，基本上初版做出來了，然而三端裡面最流暢的是H5，可能因為沒用那些亂七八糟的庫，比我任何之前寫的任何一個H5都流暢，然而我以為體驗會最好的APP端卻是最糟糕的，這個APP的效能甚至遠遠不如我以前用5+APP打包的H5專案。
APP端據說是一個檢視層和邏輯層分離的JS執行器，但是表現真的不如瀏覽器的單執行緒JS，檢視渲染跟H5端相比總是慢半拍，甚至CSS3動畫都可以卡頓，真的是不理解其中的原理。
目前初步發現的一個規律是，只要我把耗時的JS操作寫在事件回撥中，例如swiper，picker的onchange回撥中，就會在APP端出現及其明顯的卡頓現象，但是我寫進去的耗時操作不過20ms而已。
等專案完成後，集中精力攻堅，看看能不能找到原因，實在不行就打算完全放棄基礎元件，自己用純前端實現算了。swiper、picker-view、scroller-view的坑真是讓人抓狂。
——————————————6。17 更新 ——————————————————-
我已經崩潰了，儘管我已經做完了專案，付出了巨大的精力，造了不少輪子，但我已經幾乎決定放棄這個框架了。
我用過不少開源的專案，能讓我專門寫建立個工程uni-bug，去集中復現框架的各種問題的產品，獨此一家。
比起某一個元件功能上的BUG，很多工程層面、框架層面、效能層面的問題和困難更讓人感到無力，並且看起來短時間內難以解決：
因為小程式的特殊性，相比起原生Web使用Vue開發，很多特性無法支援。無法完全統一功能、寫法、表現，這對於之前一直用Vue的開發者來說體驗非常惡劣，再加上文件不足夠詳細，沒有說清楚這其中的區別，至少我踩的坑在文件裡暫時沒找到有關內容。
1）。 自定義元件
透過prop傳遞引數時
，資料都會受到
JSON.stringify和JSON.parse
二連擊，也就是說，這種傳值方式
不支援帶有迴圈結構的JSON(樹形結構如果有雙向指標基本就被斃了)，不支援自定義的class(會變成原始Object，丟失所有prototype方法)，甚至連Date型別都無法支援。
我看了小程式的開發文件，文件指出prop確實只支援基本的JSON格式資料，這個確實是框架無法解決的問題，但是我認為文件應當著重體現，因為不一定每一個慕名而來的開發者都具有小程式原生的開發經驗。
我因為此坑，在小程式端執行時遇到了茫茫多的undefined報錯，為此不得不為很多物件方法都寫了一個static版本。這個怪我太菜，沒有小程式相關開發經驗。
2）。 小程式端的slot-scope是用自定義元件實現的，slot-scope在特定的情景下，會出現資料缺失、樣式缺失、繫結事件失效的情況，具體我已經在dcloud社群提出，但是我花了大量的精力去復現問題，卻收不到任何迴應，很讓人鬱悶。
https：//
ask。dcloud。net。cn/quest
ion/99063
2。 APP端也有很多的問題。
1）。 首先APP端的語法也僅僅只是Vue的子集，甚至有一些在小程式上都能實現的點，APP端卻不支援，例如
【報Bug】APP端還是不支援slot動態插槽名 - DCloud問答
2）。 對我來說，最最最痛苦而無法忍受的點就是這個，uni-app的APP效能表現極端的差勁，如果你的應用是增刪查改列表、電商等這種以靜態資料為主的頁面，那麼APP實現出來還是非常流暢的，尤其是翻頁動畫，確實相當絲滑。
但是你的應用如果短時間內需要頻繁更新頁面資料，而你的頁面複雜程度較高，存在上千萬個需要頻繁更新的節點的話，那麼APP的表現會讓你大跌眼鏡。不誇張的說，同樣的程式碼，APP端的效能比起小程式以及H5端差了1000%以上。推測是因為邏輯層和檢視層通訊帶來的損耗過多。
【延遲卡頓】uni-app APP檢視更新相比起H5和小程式有明顯延遲
我上網搜查了很多資料，發現Dcloud社群關於效能最佳化的討論不多，我很難從中找到能解決我疑惑的資訊，唯獨這篇文章感覺稍微有一點用。
uni-app： 從執行原理上面解決效能最佳化問題
然後我幾乎花了幾近重構的精力，又是抽離元件，又是修改渲染邏輯，沒用，只要節點數量下不來，頁面就是卡頓，只要刪掉節點多的模組，頁面立刻又流暢起來。
所以我認為uniapp這個APP引擎所謂的檢視層和邏輯層的分離方案，在實現上一定存在重大的破缺的，下限很高，上限很低。就不說別的，我就是用包一層Webview渲染網頁的方案，也不會卡成這個樣子。
我知道，這一切的根本原因都是我個人技術不精，經驗不足，再加上盲目冒進，技術選型出現失誤，開發時還抱有不切實際的執念造成的。
但是，從我遇到問題尋找解決方案的過程中，我意識到了uniapp的文件、社群與一些成熟的開源技術相比，還是有極大的差距的。也許我這個至今一直在白嫖、索取、尚未在社群產出內容的人沒有資格這麼評價，但是如果像我這樣的開發者遇到困難，沒有受到正確的引導，失望的離去了，那麼這一切恐怕永遠難以改善。我也想從當前這團亂麻中抽出身來，早點搞定業務，去學習原始碼，分享經驗啊。
最後我給有意入坑UNI-APP的其他開發者分享兩條個人使用經驗：
儘量用基礎的、簡單的Vue語法實現功能，儘量用官方推薦的、現有的元件實現業務，開發時多妥協，不要吹毛求疵，謹慎封裝自定義元件。
如果你的應用以展示靜態資料為主，那麼在注意第1點的前提下用uniapp還是比較推薦的，真的能節約不少成本，可能區域性需要注意一下長列表的最佳化。但是如果你的應用資料更新頻繁，互動較為複雜，頁面節點較多，做H5和小程式還是可以的，但是做APP請三思。
2021-07-20 18:44:14其實就是個站隊問題
如果你想開發大型app，native走起，不要猶豫，rn和flutter都不要想
如果你想開發小程式，尤其是微信小程式，第一步你要站隊
react你可以選taro
vue呢，mpvue似乎不得行，只能選uniapp了，現在你似乎也可以選擇taro了
