【51CTO.com快譯】一般而言，軟件應用服務的緩慢主要表現在兩個方面：一個是加載頁面的滯留、或長時間等待UI(用戶界面)的建立;另一方面則與UX(用戶體驗)有關，包括界面按鈕無法按照預期做出響應，或是用戶發(fā)現各種默認的手勢、動作及動畫無法生效。顯然，這兩者都會影響到用戶的使用體驗。在本文中，我將和您深入探討導致應用變慢的主要原因，以及如何通過跨平臺的應用框架來予以解決。

[[267502]]

跨平臺vs.原生

在日常研發(fā)過程中，人們經常會對跨平臺技術抱有成見。他們認為：由于并非原生，而是基于網絡，因此其整體效率會較為緩慢，當然也就注定會出錯。

但是，他們殊不知：如今，那些原生架構能夠實現的功能，跨平臺的應用框架基本都能實現，它們之間的運行效率通常取決于用戶是如何實現其程序代碼的。在實際項目中，我們經常會看到有的團隊使用Swift/Java，開發(fā)出了速度緩慢且時常崩潰的原生應用;而其他團隊則能夠使用Titanium之類的跨平臺技術，開發(fā)出了流暢的產品。

另外，無需用到混合式跨平臺工具，跨平臺的框架本身就能夠生成真正意義上的原生UI。因此，作為原生應用的開發(fā)人員，您過去遇到過的諸如內存泄漏等問題，在如今大多數跨平臺框架中已得到了***解決，而它們能夠協(xié)助開發(fā)人員實現了大部分的重量級加載任務。

可見，只有理解了您所使用的框架局限性，才是避免應用程序出現緩慢狀況的關鍵所在。下面，我將試著和您分析跨平臺應用在移動設備上運行緩慢、甚至無法響應的原因，并且?guī)椭业礁鞣N加速的辦法。作為代碼示例，我選用的是Titanium作為框架。當然，這些改進技巧也適用于其他類型的框架。

第1類原因：設計

通常情況下，在開發(fā)跨平臺的應用程序時，開發(fā)團隊往往趨向于將兩大平臺的版本合二為一。而這種設計理念恰恰是導致應用程序在長期運行后，變得緩慢的根本原因之一。

首先，您需要了解的是：不同平臺所對應的默認UI與UX(更為重要)是截然不同的。例如，iOS為每一個窗體“棧(stack)”都配置了打開/關閉動畫、以及幻燈片手勢。這些雖然看似微不足道，但是動畫的觸發(fā)，能夠給用戶帶來交互式使用的體驗。這種“讓用戶通過在手機屏幕上滑動手指，在窗體棧中切換應用內與應用間不同頁面”的想法，緩沖了跳轉的時間。用戶不會直觀地體會到點擊后退按鈕所可能碰到的緩慢問題。

因此，在為某個窗體設計不同的外觀時，開發(fā)人員應酌情考慮是否采用原生的顯示效果。如果想自定義的話，那么開發(fā)人員就需要通過一個事件偵聽器，來捕捉用戶是否在屏幕上滑動了手指，進而關閉相應的窗體。否則，動畫手勢的突然消失，會讓用戶生硬地感覺到整個UX的下降，進而產生應用變慢的感受。

除了上述動畫效果與UI上的不同之外，開發(fā)人員還應當注意跨平臺框架的垃圾回收問題，以防止出現自定義UI在運行過程中出現內存泄漏的漏洞。

同時，隨著用戶的廣泛使用、以及移動設備硬件性能的提升，他們會設置更多的自定義手勢與快捷方式，而您的移動應用需要捕捉、跟蹤與計算更多的手指軌跡。因此，您會發(fā)現數據的加載與計算的阻塞會相互影響，并形成惡性循環(huán)。以至于某些應用在上線一年之后，就失去了可維護性與可使用性，而開發(fā)團隊則不得不對程序進行重寫與重構。

解決方案

首先，在應用的設計階段，我們應當充分了解與接受平臺之間的差異性。通過針對兩套系統(tǒng)的產品設計，來發(fā)現不同平臺的用戶對于界面與效果的期待。在公司內部，您可以邀請長期使用Android手機和iPhone的兩類人，進行各種使用效果的實測。

其次，利用內置的UX/UI特征，嘗試著從原生平臺的角度，實現應用界面上的各項功能。例如：在大多數iOS應用中，按鈕一般會被放置在標題的左右兩側;而Android版本則通常會把按鈕放置在右邊，或者直接隱藏到菜單圖標的里面。另外，Android應用會內置有后退按鈕，而iOS則會有一個返回的手勢。通過支持這些基于不同移動平臺的特征，用戶就能夠直觀地理解您的應用，并產生一定的認同感。

第2類原因：加載太多

應用程序變慢的另一個主要原因是：在UI中一次性加載的元素太多。畢竟，移動設備的性能不及用戶電腦，很難同時處理多項任務需求。而且，不是所有的人都能使用***版本的iPhone、以及高端Android設備。其中仍在使用Android 4.4的用戶也不在少數。因此，要想在各類應用商店里脫穎而出，您的移動產品就應該具備在低端配置和老舊版本的設備上仍有不俗性能的能力。

例如，在iOS的應用商店內，如果您點開并選中“Today”標簽的話，它會迅速地載入五款應用標簽。接著，您在向下滑動時，請注意滾動條的位置和大小。您會不難發(fā)現：滾動條會以原來的大小滑向屏幕的底部，當接近屏底的20%處時，它會迅速縮小、甚至彈回到上方的某個位置。而屏幕上則開始顯示“第二頁”的數據。

可見，該應用商店并非一次性加載了所有數據。因此，在實際應用的設計與構建中，我們應該捫心自問：我們在讓用戶***看到推送內容時，是否一并加載了后續(xù)內容?您是否針對圖片進行了延遲加載?在預加載的數據中，有多少應該在ListVIEW中就顯示出來?100項還是200項?在應用啟動之處，您需要調用多少個API?我在TiSlack論壇里，有看過“在APP的啟動時，如何最有效地調用50個API”的帖子，以及“如何在ListVIEW中有效加載10000條信息”的留言。

在此，我的答案是：“不要這樣做!”沒有人能夠一次性查看這么多條信息。如果您希望用戶能夠滾動列表的話，那么請使用延遲加載(lazy-loading)以及分頁，哪怕數據已存放在設備的本地空間里。另外，如果想讓用戶進行搜索的話?那么也請您在服務端本地搜索完畢之后，再推送到用戶設備上。

解決方案

從上面蘋果應用商店的例子，我們可以了解到：在應用被***打開之后，數據內容才被進行加載。例如在默認的TabGroup中：

...

另外，我在首頁選項卡的窗體中添加了一個postlayout事件偵聽器。該函數的作用是調用窗體的初始化器，在為選項卡獲取相關數據之后，再進行加載。通過等待postlayout事件，您可以確保用戶看到的不是加載頁面，而是正常的應用內容。下面便是用來滯后進行初始化內容的簡單函數--handlePostlayout：

function handlePostlayout() { $.todayWindow.add( Alloy.createController('todayContent').getView() ); } 

如您所見，在Today標簽中，真實請求的內容、以及相關依賴項，并沒有馬上被初始化或加載，此舉無疑加快了應用程序的整體性能。

同時，對于其他選項卡而言，我們可以監(jiān)控屏幕窗體的“焦點(focus)”事件，只在窗體被聚焦時進行加載。同理，您也可以將該事件用在當前窗體被再次聚焦時，及時刷新數據;以及運用到Firebase Analytics(Android集成埋點分析)中。

記住：相對于那些用分頁或延遲加載的方式，來重新初始化整個頁面而言，僅下載數據的方式在量級上會更“輕”、速度會更快、也更節(jié)約CPU的計算力。

第3類原因：橋

此處的“橋”是一個源自Titanium和React Native之類跨平臺框架的概念。它表示：JavaScript代碼和原生代碼之間的每一次交互，都會產生開銷。例如：您在服務器進行API調用的時候，顯然，相對于花費100次調用API，而每次僅取回1條數據而言，我們更愿意僅調用1次API，并一次性地取回100條數據。

那么何為“過橋”呢?其實，我們在添加UI元素、更新UI元素、以及觸發(fā)動畫時都會產生調用。例如：在Titanium中的Ti.App.fireEvent流就需要用到過橋的概念。該類事件通常被用于在應用程序內觸發(fā)某些操作，進而實現初始化。另外，此類事件也會觸發(fā)UI的更新操作。因此，一個事件可能會觸發(fā)兩次過橋。

那么當所有的事情都同時發(fā)生，尤其處于循環(huán)觸發(fā)的狀態(tài)時，過橋進程就會變得“擁擠不堪”。而如果橋的帶寬容量又比較“狹窄”的話，您的應用就會產生大面積的延遲，甚至可能發(fā)生中斷事故，進而直接影響了用戶的使用體驗。

解決此類問題其實非常簡單。您只需要將UI的批處理組合在一起便可。因此，當需要修改ListTimes的整張表時，我們可以采用ListTeal.RePateTimeSt，來輕松地一次性重新插入整個數據集。而當您需要更改某個UI元素的一組屬性時，則完全可以使用applyProperties，而無需更改每個屬性的具體順序。

同時，您可以使用Backbone Events，來觸發(fā)整個應用程序中的各種事件，而不必采取過橋的方式。而且，我們很容易將當前的各種Ti.App事件遷移到Backbone Events上。

如下所示，我們首先將Backbone Events包括到alloy.js中。

Alloy.Globals.events = _.clone(Backbone.Events); 

然后，您將應用里任何曾經用到了Ti.App.fireEvent()的地方，替換為如下函數：

Alloy.Globals.events.trigger(); 

接著，以同樣的方式，您可以繼續(xù)將Ti.App.addEventListener()替換為：

Alloy.Globals.events.on() 

您甚至可以對自己的項目進行全局搜索與替換，以獲得立竿見影的性能提高效果。

結論

綜上所述，拖慢移動應用的原因有許多種，其中大部分與低效的代碼實現方式有關。因此，我們應該盡量采用原生的UI組件，盡可能少地加載數據，同時減少過橋的數量。***，我再次重申：跨平臺框架并不會注定比原生應用要慢。事實上，在各種應用商店中，您會發(fā)現有95%到99%的應用(不包括游戲應用)，都是采用Titanium之類的框架所構建的。

原文標題：3 Reasons Mobile Apps Can Be Slow，作者：Rene Pot

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】