摘要：文章从优化手机app的大小、app的API设计、架构设计、自适应显示、快速启动等方面比较全面的介绍了如何提高手机App的性能，以下是译文。
去年，我在从伦敦飞回的航班上，遇到一个从事手机行业的人。在过去20年里，他在一个堪称龙头企业的大公司里负责企业新技术的采用。
在我们一起飞行的8个小时里，他提到的一些事情，我最近还一直在思考。他认为移动应用程序及其性能只是不断的交付而已，事实上，他都没法审计手机应用程序的性能到底有了多少显著的提高。
当我在旧金山降落以后，我联络了更多手机行业内的人去了解这个事，发现他们都有类似的看法。代码质量和基础框架是大家讨论的唯一的东西。
我马上想到了该如何在Simform上构建App，去探索一些非常优秀的做法，遵循这些做法，建立基准，突破现有的应用程序，规模可达数十亿美元。
以下因素将大大影响手机应用程序的质量：
应用程序大小
应用程序性能
指定平台的准则
架构设计
現在，讓我們看看如何最佳化它們，以一種簡單的方式，易於採用的步驟，使手機應用程式更快。
最小化應用程式的大小
手機沒有強大的GPU,然而，低階配置的手機佔領著大多數的安卓市場份額。它們甚至不支援2G或3G,下載一個立刻就需要用到的大的應用程式將是用戶的惡夢。在這種低階手機上，應用程式佔用的空間越少越好。 
優化網絡
文字第一，圖片第二
優化網絡，先嘗試載入文字資料。然後，應用程式中基於圖像的內容顯示可以非同步載入。
避免重複的網路請求
那些安卓中被熟知的Volley應用程式會清楚更多關於這個請求的問題。當應用程式執行不力的時候，安卓應用程式可以使用Volley同時發送兩個請求到伺服器，你可以刪除一個請求，請求就會被刪除，但是應用程式的反應會是沒有這個請求了。不僅僅是功能性的問題，重複的請求也增加了系統的擁塞，降低了應用程式的效能，尤其是在有數百萬的應用程式使用者時。設想，如果增加一倍數量的請求，伺服器的數量就要增加兩倍，那麼當想降低成本的時候，就會非常得絕望。
了解並做出基於連接品質的調整
假定一個應用程式需要依據網路條件決定是否可用。應用程式可以根據使用者目前所處的網路條件改變交付的內容品質，以確保應用程式的使用不會失敗。
有效的API設計
一個API的設計方式將對應用程式效能產生巨大的影響。一個不完整的或惰性的API設計會增加應用程式的負擔。在API上的解決方法通常是對網路的限制施加了太大的壓力。
設計手機應用程式的API負載，確保應用程式具有以下特點：
一致性：開發人員應該了解預期，在API一致性的設計上，沒有任何迴旋的空間。
完整性：擁有簡化的解決方法。
從UI開始，一直到數據，都可以以一種偉大的方式來設計一個具有一致性和完整性的API負載，從而提高應用程式的效能。不要從手機發送所有請求到API，只發送實際所需的請求。
優化應用程式中的圖像
優化應用程式中的圖像，你可以：
使用向量圖像
提供動態大小的圖像
使用顏色過濾器，而不是使用不同的彩色圖像集
#使用映像快取
使用像Picasso 和Fresco這樣的函式庫
##為離線優化快取資料
當網路很差的時候，在取得數據的同時，顯示所有你已經取得的數據。這樣做會：
減少伺服器負載
#減少手機無線電使用次數，降低手機App的耗電量
#如果沒有一個任你支配的測試團隊，你可以試著將手機切換到飛航模式，測試應用程式的離線效能。
確保應用程式適合手機螢幕的大小
有許多關於螢幕尺寸的討論已經被提出來了，Android引起了一些大的關注，因為實際上有數以千計的設備，每個設備都有自己的解析度和螢幕尺寸。
作為最佳策略：
為中小螢幕建立
優化MDPI和HDPI
實作自適應的UI流
沒有成百台裝置測試解析度和螢幕尺寸？用仿真器配置測試。
安卓中的記憶體使用
為了提供手機用戶多任務的能力，安卓對每個應用程式使用多少記憶體做了限制，這些限制不是靜態的，是隨著手機應用程式的增加或減少而變化的。
要考慮到整個應用程式開發過程中的RAM限制，以及執行在背景的應用程式會佔用不必要的資源。
但是，你可以透過以下手段優化應用程式：
限制服務的有效期限，考慮採用intent service來限制服務的壽命
當使用者切換到不同的介面時，釋放UI資源
使用記憶體高效的程式碼架構
盡量減少外部庫的使用
應用程式啟動有多快？
在PlayStore上平均排名前25的應用程序，啟動時間從800ms到4.5s。現在，對於大多數用例來說，4.5S太多。
底線是，App需要快速啟動！
為了優化iOS應用程式的啟動時間，應該考慮以下內容：
嵌入少量的dylib
合併Objective-C類別
消除靜態的初始化軟體
使用更多的Swift，蘋果建議的
用DYLD_PRINT_STATISTICS衡量結果
#避免使用dlopen()
在安卓系統中，以下情況通常會影響應用程式啟動時間：
多視圖實例化
#消耗資源高的內容如解碼位圖
運行佈局
讓應用程式在安卓系統中更快啟動：
#不要在第一次啟動時顯示你不需要的UI部分，使用層次結構佔位符，以後可以隨意顯示
避免由於記憶體分配而產生的混亂，盡可能的做好垃圾收集
#使用像Apteligent的工具去監控和最佳化應用程式啟動時間
#避免在應用程式物件中初始化程式碼
記住，最近推出的一個應用程序，這個第一次推出的應用程式將會有不同的表現。
減少裝置喚醒
頻繁地喚醒手機會大幅降低系統效能。這會消耗系統資源。可以限制應用程式將會響應的喚醒意圖。
考慮低階安卓手機
並非所有的安卓用戶都擁有最新的2G+記憶體的手機。當我們尋找可用的安卓設備時，我們看到設備能力方面的高倍細分。
When most developers develop and optimize applications for performance, they make a big mistake. They optimize their apps for the wrong devices, often with high-end devices available for testing.
A good rule of thumb is that there should be a variety of devices used to optimize app performance. This way, developers can cross-test.
Various speeds
Interface and resolution
Low memory
Smooth frame rate
On iOS and Android, the maximum frame rate for displaying animations and gestures is 60fps.
If the frame rate is lower than 60fps, users will usually feel stuck.
In order to achieve a frame rate of 16ms (equivalent to 60fps), the code used for display in the application needs to be executed within 16ms. This is where you'll notice in Android, how expensive 5ms of garbage collection time is.
Let's evaluate how this will impact end users. When you miss the 16ms limit, you'll often get a slightly lower frame rate of ~59fps. No big deal, right?
wrong!
The reality is that if the application misses the 16ms limit once, it cannot use the window for the same frame and has to wait for the next frame.
Although the application only took 19ms to display, it missed the display window and the time displayed to the user became twice as long. You know, this way, users will think that the application is super bad.
Recovering User Data on New Devices
Users often spend a lot of time setting up applications on their phones so that they work the way they want. When reinstalling an application, most users expect their original settings to remain available.
Saving configuration data helps improve application quality:
Any configuration modified by the user
Push settings notification
Whether the user has seen it on the new screen Go to the Welcome Screen and Introduction
#Discover Potential Consumption
It is important to remove potential problems from your application. Potential problems can cause application errors and often break the entire application. Statistics show that if an application runs slowly, more than 50% of users will uninstall the application within 24 hours.
Effectively deal with potential related problems:
When the network condition is not good, you can limit the source of potential problem factors from third parties
Reduce the potential for use on mobile phones Requirements for Potentially Consumed APIs
Optimizing iOS Apps to Handle Multitasking
Assume there is a user using your application. The application will display well at 60fps and complete all the work in 9ms. As shown in the figure below: 
Now, when the user opens the second application on the phone, it also takes about 7ms to complete all the work. It now looks like the following picture: 
You can see that in order to display at a frame rate of 60fps, the two applications combined took 16ms.
Suppose the user opens another application at a frame rate of 60fps, and the work is completed in 10ms. The current time is 9+7+10=26ms, which means that the application's demo frame rate is 40fps instead of 60fps.
Users of the application began to notice lags in the application, and the same situation was almost the same with the GPU and memory.
Remember when apps kept crashing?
Okay, let's take a look at the scenario of an application running on the device.
Now, introducing another application into the scene, we are still doing well and still have some memory left.
When we introduce another application into the scene, the system has no memory to allocate. The system will kill a process to free up resources.
This is why app development is so challenging (for those who really care about it)
Solving these challenges requires a little understanding of the iOS ecosystem. Let’s look at how to optimize your application for multitasking:
You can use tools to identify and fix bugs
Prioritize your work level, do not block the main thread
Identification and management toolset
Use cache and respond to memory alerts
Use the virtual memory system to increase memory recycling
Make a good trade-off
If someone can follow 50% of this, you will find Application performance has been greatly improved.
以上是深入了解如何提高APP性能總結的詳細內容。更多資訊請關注PHP中文網其他相關文章！
