建立支持多種屏幕尺寸的apk

時間  2019-11-30
標籤 建立 支持 多種 屏幕 尺寸 apk 欄目 Android 简体版
原文   原文鏈接

文章轉至:http://hell0android.iteye.com/blog/1899605html

建立對兩種以上屏幕尺寸的多apk支持（Creating Multiple APKs with 2+ Dimensions）

爲了在開發android應用程序的時候加以利用google安卓市場的多apk支持特性，剛開始就採起一些良好的措施去增長對多apk的支持，是很是重要的，這樣能夠在未來開發的過程當中減小沒必要要的麻煩。這一節將向您展現如何爲你的app建立多apk支持--不一樣的apk支持不一樣的屏幕大小。還將得到一些維護多apk代碼庫儘量的簡單的工具。android

確認您是否須要多apk支持

當你試圖建立一個支持跨多android設備的應用程序時，很天然的你但願你的應用程序能夠在全部的設備上都看起來最好。你既想利用大屏幕的空間，也但願能在小屏幕上運行，想利用新api的特徵，也想在最新設備上的看到的紋理特徵同時能在舊設備上一樣能夠看到。
剛開始的時候認爲經過建立多個apk去支持多設備是最好的解決方案，可是每每不是這樣。而是使用單個的apk去替代多個apk，開發指南中有去完成這個目標有用的信息，包括如何使用支持庫的信息。還能夠學習到如何寫只能運行在特定api版本的代碼的方法，而不去使用像反射這樣的很是消耗資源的技術。api

若是你能讓你的應用程序只使用一個apk，將有以下幾點好處：app

  • * 發佈和測試簡單
  • * 只需維護一個代碼庫
  • * 應用程序能夠適應不一樣配置的設備
  • * App能夠跨設備運行
  • * 你沒必要考慮market的要求，apk的升級或者apk屬於哪類設備

假設您已經研究了這個文檔，已經學習了連接頁面的內容，而且肯定多apk支持的程序是你須要的，那麼請繼續看下面的小節。eclipse

畫出你的需求

首先建立一個簡單的圖表來快速肯定你須要多少個APK, 每一個Apk覆蓋的屏幕尺寸範圍。雖然剛開始聽起來很是容易，可是每一個pai版本的apk去實現目標有是比較困難的，特別是常常有重疊的部分。幸運的是，經過本方法，你會很容易繪製出你的需求,供之後開發參考。讓咱們先討論一下如何根據屏幕尺寸和api版本，爲apk劃分對應的設備範圍。首先是建立一個圖表，行和列對應一個值，而且都用顏色填充，每種顏色表明一個apk。
1.jpgide

上面的例子有四個apk，藍色的是爲全部的small/normall屏幕設備的開發的，綠色的是爲全部的large屏幕設備開發的，紅色的是爲xlarge設屏幕設備開發的，這三種apk對應的API範圍是3-10。紫色的是一個特例，它能夠適應全部的屏幕大小，可是僅支持API11或者以上系統。更重要的一點是，當你瞅一眼這個圖表的時候，你能快速的看出來哪一個apk對應什麼API，對應什麼屏幕大小。此外你還能夠爲每個apk起一個很是拉風的開發代號。當咱們的團隊成員問咱們，「咱們是否是該測試紅色的那個apk了」，而不是說「咱們是否是該測試這個支持API3-10，支持xlarge屏幕，而且不是在摩托的Xoom平板上的apk了」，顯然，前一種方式更容易理解。還有，把這個需求圖表打印下來，分發給每個團隊成員。函數

把全部的共用代碼和共用資源放在同一個庫工程裏( Put All Common Code and Resources in a Library Project)

不管你是修改一個已經存在的Android應用程序仍是開始建立一個新的程序，首先最重要的任務就是建立一個共用代碼庫（如標題所說的庫工程）。把那些只需更新一次就能夠減小項目的開發時間，減小項目錯誤的代碼或者資源放進這個庫工程裏（好比能夠放在代碼庫裏的像本地化語言字符串，顏色主題，共用bug的修復等）。工具

注意： 如何建立庫項目的細節，不是本節要講解的範圍，您能夠經過下面的連接快速的瞭解如何建立庫工程：佈局

若是你想把已有的應程序轉成多apk的支持，須要從新組織你的代碼中的全部的本地化字符串文件，值列表，顏色主題，菜單圖標，佈局文件，這些跨apk的不會改變的資源文件，並把他們放到庫工程裏。還有把那些不會改變太多的代碼放到庫工程裏。這樣你將會發現，你能夠從一個apk繼承另外一個apk那些類的，擴展一到兩個方法（函數）。學習

若是你剛開始建立一個新應用程序，首先要儘可能在一個庫工程中寫代碼，若是必要的狀況下作成一個獨立的apk。這樣在之後長時間的開發過程當中，長遠看來是很是容易管理的，能夠一點一點的添加共用代碼和資源，並在數月以後指出這些代碼或者資源在不經修改的狀況下是否該移動到庫裏。

建立新的APK工程（Create New APK Projects）

對於須要發佈的每一個APK，要分別爲每一個APK建立Android工程。爲了便於管理，把庫工程和全部相關的APK工程放在相同的父目錄下，同時須要記住每一個APK須要相同的包名，雖然他們在這個庫裏沒必要須去共享他們的包名。好比，若是你有4個APK，正如前面的規則所描述的，你的根目錄會像這樣：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
 
alexlucas:~/code/multi-apks-root$ ls

foo-blue

foo-green

foo-lib

foo-purple

foo-red

一旦這個工程建立以後，把這個庫工程引用到每一個APK工程，若是能夠的話，在庫工程裏定義啓動Activity，並在APK工程裏繼承這個Activity。有了這個在庫工程中定義的啓動Activity，能夠把你的全部應用程序的初始化工做放在一個地方，這樣一來每一個一個單獨的APK就不須要從新實現這些像初始化分析，運行許可檢查等其餘的一些初始化工做，不用一個個APK的去寫，維護起來也會簡單好多。

調整Manifests文件（Adjust the Manifests）

當用戶從google安卓市場下載對多APK支持的程序時，正確的APK使用兩個簡單規則：

1.maifest已經代表這個APK是合格的

2.對於全部的合格APK,支持的Android API版本號最高者優先被發現。

下面咱們將以舉例的方式講解，首先，假設咱們已經瞭解了前面所述的多APK的描述，而且這些apk支持全部的屏幕尺寸，而不是僅僅只支持目標尺寸的屏幕，讓咱們從新看一下前面的表格：
Since it’s okay for coverage to overlap, we can describe the area covered by each APK like so:
2.jpg

由於他們有重合的部分，咱們能夠像下面同樣去描述每一個apk

    • 藍色的覆蓋全部的屏幕尺寸，最低支持sdk是3
    • 綠色的覆蓋大屏幕或者更大的屏幕，最低的sdk是3。
    • 紅色的覆蓋的是超大屏幕的（日常的平板），最低支持sdk9
    • 紫色的覆蓋全部的屏幕尺寸，支持最低sdk11

請注意，在上述的規則中有不少重合的地方。舉個例子，一個xlarger屏幕的設備，系統版本是API11,這個4個apk全均可以在這個設備上運行，咱們根據最高版本優先被搜到的原則，咱們能夠把他們的優先級列出來：

紫色 ≥ 紅色 ≥ 綠色 ≥ 藍色

爲何容許重疊呢？
如今咱們進一步假設，紫色的apk須要一些必須的東西，而其餘的兩種apk不須要有。google安卓市場的開發者指南頁面上列出了全部的可能過濾掉你的程序的罪魁禍首。爲了更好的講解例子，咱們繼續假設，紫色的apk須要前置攝像頭，關鍵點就在於，必需要求有前置攝像頭，可是並非全部的API11或以上設備上都配有前置攝像頭，是否是很恐怖。

幸運的是，若是用戶在google安卓市場使用這樣的設備瀏覽軟件的時候，安卓市場的引擎首先會到manifest文件裏面去查看是否必需要有的前置攝像頭，若是必需要求有前置攝像頭，由於紫色的apk和設備不匹配，這個紫色的apk將會被忽略掉；而後再查看紅色的apk，由於紅色的apk即支持xlarger屏幕，對前置攝像頭也沒有硬性的要求，google play會認爲紅色的apk能夠和設備匹配，程序就能夠從google play上下載下來試用了，由於至少有一個支持這個設備的apk。

爲了把全部的apk分別處理，設定一個好的版本號使用規則特別重要，在開發者指南上有推薦的版本號規則Version Codes。這一部分仍是比較值得閱讀的，基本要點是爲一組apk設定規則，咱們用兩個數字表明最低支持的系統版本號，用兩個數字表明支持的最大或者最小屏幕大小，另外的三個數字表明本身的程序的版本。經過這種方式，當設備的系統升級的時候，好比從10升級到11，apk升級的時候，在全部的apk中，優先被升級的apk是當前安裝在設備上的那個apk。下面是一個版本號使用規則的一個例子，能夠定義成以下格式，

藍色: 0304001, 0304002, 0304003...

綠色: 0334001, 0334002, 0334003

紅色: 0344001, 0344002, 0344003...

紫色: 1104001, 1104002, 1104003...

這三種在程序的manifests文件中定義分別以下：
藍色:

1
2
3
4
5
6
7
8
 
 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="0304001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    <supports-screens android:smallScreens="true"
        android:normalScreens="true"
        android:largeScreens="true"
        android:xlargeScreens="true" />
    ...

綠色:

1
2
3
4
5
6
7
8
 
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    <supports-screens android:smallScreens="false"
        android:normalScreens="false"
        android:largeScreens="true"
        android:xlargeScreens="true" />
    ...

紅色:

1
2
3
4
5
6
7
8
 
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    <supports-screens android:smallScreens="false"
        android:normalScreens="false"
        android:largeScreens="false"
        android:xlargeScreens="true" />
    ...

紫色:

1
2
3
4
5
6
7
8
 
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="11" />
    <supports-screens android:smallScreens="true"
        android:normalScreens="true"
        android:largeScreens="true"
        android:xlargeScreens="true" />
    ...

注意一下，在技術上，一個apk要麼有支持的特定屏幕的標記，要麼有兼容性的屏幕的標記，支持的屏幕是優先考慮的。可是若是同時有這兩個標記是很很差的作法，這樣會增長額外的複雜性，增長機會性錯誤。同時還要注意，不要使用默認的值（small和normal默認狀況下老是true），在manifesets中應該明確指定屏幕大小的值。這樣會減小之後的麻煩---順便舉個例子，manifest的目標sdk要求小於9，若是使用默認值，xlarge自動設置爲false，xlarge的屏幕將不會支持，所以最好要明確指定。

發佈前的檢查(Go Over Pre-launch Checklist)

往google play上上傳程序以前，必定要根據下面的條目仔細的檢查下程序。記住，這些條目與多apk支持關係很是密，可是這裏並無列出全部的須要檢查清單。

  • * 全部的apk必須有相同的包名
  • * 全部的apk必須用相同的數字證書籤名
  • * 若是這些apk有系統版本重合的地方，最低系統版本號最大的那個apk必須有一個更高版本號（If the APKs overlap in platform version, the one with the higher minSdkVersion must have a higher version code）
  • * 任何一種你將有支持的屏幕大小都要在manifest中設置成true,若是不想支持的就設置成false。
  • * 仔細檢視manifest的過濾條件是否有衝突的地方（好比，一個apk只支持xlager的屏幕的設備，就不要被全部的設備看到）
  • * 每個apk的menifest必須至少支持一種屏幕，openGL texture或者系統版本。
  • * 每個apk至少在一個種設備上測試過。除非你是爲定製的設備開發程序。

把程序提交到google市場以前，還要對編譯過的程序進行檢查，確保沒有一些其餘的明顯的問題而影響你的程序在google市場上被發現。使用aapt（Android Asset Packaging Tool，是生成和打包android應用程序的重要構建工具）這個工具進行編譯檢查特別的簡單便利。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
 
>aapt dump badging
package: name='com.example.hello' versionCode='1' versionName='1.0'
sdkVersion:'11'
uses-permission:'android.permission.SEND_SMS'
application-label:'Hello'
application-icon-120:'res/drawable-ldpi/icon.png'
application-icon-160:'res/drawable-mdpi/icon.png'
application-icon-240:'res/drawable-hdpi/icon.png'
application: label='Hello' icon='res/drawable-mdpi/icon.png'
launchable-activity: name='com.example.hello.HelloActivity'  label='Hello' icon=''
uses-feature:'android.hardware.telephony'
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'small' 'normal' 'large' 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '120' '160' '240'

當你在檢查aapt的輸出時，確保支持的屏幕和兼容的屏幕的值不衝突，不要在manifest中的"uses-feature"添加一些你並不須要的系統權限.如上面的例子，這個apk不會被不少的設備看到。

爲何呢？例子中顯示，增長了SEND_SMS的權限要求，這個特徵須要增長android.hardware.telephony硬件支持。從api11 Honeycomb開始是針對平板電腦的系統，沒有打電話的硬件支持，Google play將會過濾掉不支持打電話的設備，只有API版本匹配，同時支持打電話的硬件支持纔不會被過濾掉。

能夠很是容易的在manifest中修復這個問題：

1
 
<uses-feature android:name="android.hardware.telephony" android:required="false" />

android.hardvare.touchscreen 權限要求也本不正確的加進去了，若是你想你的apk能被沒有觸碰功能的android系統的智能電視也能在市場上搜索到，進行以下設置：

1
 
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />v

當你完成了發佈前的檢查，你就能夠向google play上提交你的apk了。發佈完以後再去google play作最後一點檢查，去上面搜索你的程序，下載下來，以確保你的目標設備能夠搜到，並能使用。恭喜您，如今您已經完成了本節課程！！！

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程