因為小程序自身的特殊性，導致 UI 規劃師不能夠如同規劃 App 一般自若。為了后續 UI 規劃師和小程序前端開發能削減溝通，返工成本，將在這兒和咱們聊聊小程序和 App 規劃的差異，以及差異具體的表現。
本文僅為個人作業學習心得，可能概述的較片面，有錯誤不當之處歡迎指出。
目錄
1.為什么有差異？
2.差異在哪里？具體表現
1.為什么有差異——缺乏自主性
1）功用支撐
小程序咱們都知道是基于微信的運用程序，開發必須依托微信給的接口（微信給啥便是啥），能完成的功用被大大的約束了。而且小程序上線也就2年的時分，還有一些功用不完善。
App 依托于手機系統，能夠完成雜亂且多的功用，App 開發現已有近10年的堆集，各類控件比較完善，換句話說便是開發者才能越大，展現作用越豐富。
2）內存體積
小程序代碼提交不能超過規定大小2M，這部分程度上約束了開發的可能性。
App 就不同了，沒有這部分的約束，咱們更新軟件的時分經?？吹綆资?，幾百兆，甚至游戲類的幾個G的下載體積。
3）體會及流暢
小程序的體會略遜于 App , 小程序運用時沒有那么穩定，簡單出現錯誤閃退，特別是在一些功用雜亂的運用中，雖然說小程序現已優化了很多，有時仍會出現卡頓感。
2.差異在哪里？具體表現
1）頂部導航欄
App：能夠保留導航欄，也能夠去掉，可拓展性強，靈活性高。
小程序：導航欄右側有個無法去除和修正的膠囊（titlebar），規劃時也不能在導航上添加其他功用。所以在 App 轉小程序時，導航欄的功用要換方位或許在放在導航欄下。
完成作用也略短缺一些，例如微信供給原生和自定義的兩種導航欄：
（一）原生的導航欄支撐更改色彩，但字體色彩僅支撐黑/白兩種；
（二）雖然自定義的導航欄能夠去除原生導航欄，支撐圖片通到導航欄上，但是一切頁面都需要從頭調整（原先導航欄的高度沒有了，界面元素會跟著上移），而小程序不支撐單個頁面修正。
這是目前較費事的地方，量級小的運用還能夠，量級大的導致作業量大大添加。
一起，自定義導航簡單帶來標題無法對齊、頁面機型不同安全區域不同、全局改寫時頁面會被整個下拉等等問題。
主張頁面多、雜亂的狀況，盡量削減運用自定義導航，也能夠運用像馬蜂窩相同，導航欄布景和圖片布景聯接，作用也不錯。
2）標簽欄
App：可支撐較少2個，較多5個的tab切換，圖標大小以及底部標簽欄高度可自定義。
小程序：也可支撐較少2個，較多5個的tab切換，運用原生控件時，要遵從 icon 尺度81*81px。
運用自定義標簽欄時，可支撐加入交互作用，例如提示數量氣泡等，但是體會相比原生差一點，如果標簽頁是首次進入的頁面，那么標簽欄切換會造成跳動，需要開發做躲避。
主張不帶有交互的狀況，盡量運用原生控件，就像站酷小程序 相同。
3）拖動排序
App：流暢、體會佳，例如發朋友圈時拖動照片排序。
小程序：除非必要，否則不主張運用拖動排序。圖片和列表拖動在 Android機型上體會不夠，會有卡頓的狀況。
主張運用上下按鈕替換上下拖動，或許圖片排序運用符號的方法來進行排序。
4）文本省掉
App：可完成日常所需的一切文字、階段作用。
小程序：文本約束行數，加省掉號，并且添加全文打開計劃完成有問題。無法預估到行尾方位省掉。
主張經過換行添加全文打開按鈕，或許操控字數，文本結尾添加全文打開。
5）原生組件
App：能夠自定義組件庫，對開發規劃約束低。
小程序：部分組件是由微信創立的原生組件，有系統相機、輸入框、地圖、文本輸入...等等，原生控件運用有必定的約束，不能在滾動、輪播、選擇器、拖動區域中運用，層級無法被覆蓋，可供修正的參數由微信供給。
主張在規劃時以原生控件為基礎修正，不要自造控件。一起留意運用場景，以免無法完成。
6）動畫完成
App：動畫流暢、無卡頓，想要的基本都能完成。
小程序：動畫才能低于 H5 和 App ，動畫對功能耗費大，尤其是在 Android 機型上，卡頓有稍顯明顯。當加載代碼包時，當微信以為這個小程序占用過多的內存，會把此小程序強行退出，以確保微信的正常運用。
主張動畫精簡，盡量做減法規劃。
3.總結
因為小程序自身的開發特殊性，在和 App 規劃的會有一些的不同之處，例如：
1.頁面多、雜亂的狀況，盡量削減運用自定義導航。
2.不帶有交互的狀況，盡量運用原生控件。
3.運用上下按鈕替換上下拖動，或許圖片排序運用符號的方法來進行排序。
4.經過換行添加全文打開按鈕，或許操控字數，文本結尾添加全文打開。
5.在規劃時以原生控件為基礎修正，不要自造控件。一起留意運用場景，以免無法完成。
6.動畫精簡，盡量做減法規劃。
