『壹』 APP的兼容性如何提升

win7 的兼容性已經很不錯了
如果有的軟體運行不了嘗試右擊應用程序→屬性→兼容性
勾選以兼容模式運行這個程序，裡面選XP（sp3）或更早的系統
勾選高DPI設置時禁用顯示縮放
勾選以管理員身份運行這個程序

『貳』 有沒有什麼app能堅決兼容性問題

版本過低時通過手機官方OTA升級手機系統版本，如果手機版本比較超前，那就只能等待游戲推出新版本。

『叄』 app與蘋果手機不兼容怎麼辦

方法/步驟

  • 一般來說遇到「此app與您的設備不兼容」，有可能是系統原因，例如：手機當前系統低於目前軟體支持的系統版本，那麼在下載應用時就會出現這種提示。

  • 在一些蘋果其它應用中常常有一些軟體更新速度比蘋果App Store慢一些。如果這些應用上面還有留著舊的版本軟體，那麼趁著該軟體還沒有更新之前，趕緊通過這個途徑下載安裝蘋果舊版本軟體解決此app與您的設備不兼容的問題。

『肆』 大家在手機APP的兼容性測試中，最容易出現的是哪些兼容性問題

一般兼容性比較多出現的就是閃退、UI異常或者程序異常這類問題。在專TestBird的測試白皮屬書中，對近百萬個問題進行了分類統計，得出的結論是閃退問題佔比達到51.65%，之後是UI異常的問題，佔比11.20%。我想這應該是涉及面最廣的兩類兼容性問題了。

『伍』 怎麼給APP適配高版本的安卓系統

Android的最新版本會提供一些很棒的API，您的APP使用新版本API的同時也要兼容舊的Android版本，直到更多設備已更新到新版本的APP。本文檔將向您展示如何利用最新的API，同時繼續支持舊版本。

根據對訪問Google Play商店的設備數量的統計，平台版本分布表會進行定期更新，以顯示運行每個版本的Android設備的分布情況。一般來說，一個APP最好能支持大約90％的活動設備，同時使用最新的Android版本。

提示：為了在多個Android版本中提供最佳特性和功能，您應該在APP中使用Android Support Library，這樣可以在舊版本上使用幾種最新的平台API。

指定Minimum和Target API Levels

AndroidManifest.xml文件描述APP的詳細信息，並標識其支持的Android版本。具體來說，<uses-sdk>元素的minSdkVersion和targetSdkVersion屬性標識了APP兼容的最低和最高API級別。
隨著新版Android的發布，一些風格和行為可能會有所改變。為了讓您的應用程序能夠利用這些更改，並確保您的應用程序適合每個用戶設備的風格，您應該把targetSdkVersion的值設置為最新的Android版本。

在運行時檢查系統版本

Android在Build常量類中為每個平台版本提供了一個唯一的編碼。APP用這個編碼來確保只有系統支持高版本API時，才會執行依賴高版本API的代碼。
注意：解析XML資源時，Android會忽略當前設備不支持的XML屬性。因此，您可以安全地使用僅由較新版本支持的XML屬性，而不必擔心舊版本遇到該代碼時出錯。例如，如果您設置targetSdkVersion =「11」，則APP在Android 3.0及更高版本上默認包含ActionBar。如果要將menu項添加到action bar，您需要在menu資源XML中設置android：showAsAction =「ifRoom」。 在跨版本的XML文件中可以安全地執行此操作，因為較舊版本的Android只會忽略showAsAction屬性（即，不需要在res / menu-v11 /中添加一個單獨的menu資源）。

『陸』 如何解決APP兼容問題

你可以到測試平台上申請兼容性測試，我們團隊上次委託精靈雲測做的測試，報告還蠻清晰的

『柒』 關於IOSAPP向下兼容的問題，是怎麼理解的

一般來說，SDK只會向下兼容2個版本，也就是說現在的SDK是7.0，那麼自動會兼容到5.x和6.x，只版要在DemployTarget選一下就行了，然權後自己控制好代碼里的邏輯，不要用6.xOnly或7.xOnly，或者做好多版本的特殊處理。

『捌』 手機app兼容性測試，主要是針對哪些方面測試

APP的兼容測試主要就是測試APP的安裝、啟動、運行、卸載測試，以及安裝時間 、啟動時間、CPU佔用、內存佔用、流量耗用、電量耗用等性能上的測試。根據 愛內測的介紹，平台兼容性測試主要通過由後台控制器INT伺服器連接各手機， 當收到測試請求時，會根據申請機型自動將APK傳送給對應的機型，自動安裝運 行，卸載，並通過Monkey、UIT自動深度檢測UI等測試。

『玖』 如何做好app不同版本的伺服器兼容

伺服器端的設計，特別是資料庫方面的設計，一定要做到足夠抽象，足夠容納後期的可變性。（補充方法論：在項目啟動的時候，先畫大餅，想著5年後這個項目火成什麼樣子，如果要滿足那時的需求，後台現在應該怎麼設計。）
客戶端訪問的介面，通過命名空間隔開：
/api/1.0/users/register
/api/1.2/users/register
強制客戶端版本。另一個好處是，如果某版本有嚴重的bug，那麼當新版本發布後，強制某一個版本的用戶升級（強制升級必然是不會輕易觸發的，所以躲過審核毫無壓力）