在App內潛入分享到微信好友或朋友圈的功能想必大家已經屢見不鮮了，比如Android分享一個網頁信息（URL）到微信客戶端的代碼：

 /**
 * 微信分享：分享網頁
 * @param context
 * @param url
 * @param title
 * @param description
 * @param scene
 */
 public static void shareToWeChatWithWebpage(Context context, String url,
 String title, String description, int scene){
 IWXAPI iwxapi = WXAPIFactory.createWXAPI(context, WXEntryActivity.WXAPI_APP_ID);
 if (!iwxapi.isWXAppInstalled()){
 ToastManager.getInstance(context.getApplicationContext()).showToast("您尚未安裝微信客戶端");
 return;
 }
 WXWebpageObject wxWebpageObject = new WXWebpageObject();
 wxWebpageObject.webpageUrl = url;
 WXMediaMessage wxMediaMessage = new WXMediaMessage(wxWebpageObject);
 wxMediaMessage.mediaObject = wxWebpageObject;
 wxMediaMessage.title = title;
 wxMediaMessage.description = description;
 wxMediaMessage.thumbData =
 ImageManager.bmpToByteArray(BitmapFactory.decodeResource(context.getResources(), R.mipmap.ic_share_invite), true);
 SendMessageToWX.Req req = new SendMessageToWX.Req();
 req.transaction = String.valueOf(System.currentTimeMillis());
 req.message = wxMediaMessage;
 req.scene = scene;
 iwxapi.sendReq(req);
 } 

雖然已經在不同的App內使用了N遍，但在最近的一個項目中還是出了錯：執(zhí)行完這段代碼，應用沒有任何反應，無法調起微信客戶端，并且沒有任何錯誤信息打印提示。不得已查看官方資料 —— [Android常見問題]，找到這樣一段提示： 

Q：調用wxapi.sendReq接口，返回true，但微信客戶端并未啟動，請檢查以下幾項：
A:
 1）微信是否安裝
 2）調用時的Apk包名和簽名是否與開放平臺填寫的一致，簽名請使用該工具：點擊下載，常發(fā)生在安裝了debug版本又安裝release版本情況，確定包名簽名后卸載微信重裝或者清除微信數(shù)據再做測試
 3）檢查發(fā)送時的縮略圖大小是否超過32k
 4）能夠調起微信到選擇好友列表，但是點擊發(fā)送后無響應，請檢查proguard配置是否對微信SDK代碼進行了混淆，建議不要對SDK對混淆，參考以下proguard配置：
 -keep class com.tencent.mm.sdk.** {
 *;
} 

經檢查，發(fā)現(xiàn)代碼iwxapi.sendReq(req);執(zhí)行過后返回了false，其實按照上面Q&A的寫法，已經不屬于該問題范疇了。但是還是照著這四點檢查了一遍，發(fā)送的縮略圖本地預覽大小只有不到20KB，其他配置也沒有問題，可還是出錯，到底問題出在哪里了呢？
 糾結，沉思，差點就懷疑人生了！最后冒著試一試的態(tài)度，我把縮略圖換成一張不到7KB的小圖，再次執(zhí)行代碼，結果驚人地發(fā)現(xiàn)：iwxapi.sendReq(req);返回true，并成功調起微信客戶端！當時心中一萬頭草泥馬奔騰而過?。?br />  一番激動之后，就開始研究了，為什么之前使用的縮略圖沒有超過官網文檔32K的限制，卻無法調起微信客戶端呢，難道官網文檔寫錯了，上限不是32KB？于是回歸源碼，打開微信SDK提供的類WXMediaMessage，找到如下定義的一系列常量：

public static final int THUMB_LENGTH_LIMIT = 32768;
private static final int TITLE_LENGTH_LIMIT = 512;
private static final int DESCRIPTION_LENGTH_LIMIT = 1024;
private static final int MEDIA_TAG_NAME_LENGTH_LIMIT = 64;
private static final int MESSAGE_ACTION_LENGTH_LIMIT = 2048;
private static final int MESSAGE_EXT_LENGTH_LIMIT = 2048; 

果不其然，微信SDK對于分享到微信的縮略圖大小、標題長度、描述長度等信息都做了限制。其中，縮略圖大小限制為32768，源碼中并沒有注釋寫明單位。好奇的我將其除以1024，剛好得到32，這不就是官網文檔提到的上限值32KB嘛（說明源碼中的數(shù)值單位為Byte）！那就是說官網文檔沒有寫錯，可是問題出在哪兒了呢？
 其實事關圖片的實際硬盤占用大小和內存占用大小問題。存放在電腦硬盤中的圖片文件，會根據不同圖片格式的壓縮規(guī)則進行壓縮，從而減少硬盤占用大小，比如常見如JPEG這種有損壓縮的圖片格式。而在Android系統(tǒng)中，將圖像讀取到內存當中所占用的內存大小與圖片存放在硬盤當中的實際大小沒有一點關系，可能更大，也可能更小，使用如下代碼即可獲取圖像所占用的內存大?。?br />

 private Bitmap decodeResource(Resources resources, int id) {
TypedValue value = new TypedValue();
resources.openRawResource(id, value);
BitmapFactory.Options opts = new BitmapFactory.Options();
opts.inTargetDensity = value.density;
Bitmap bitmap = BitmapFactory.decodeResource(resources, id, opts);
Log.i("Bitmap", "size is " + bitmap.getRowBytes() * bitmap.getHeight());
return bitmap;
} 

其中，bitmap.getRowBytes() * bitmap.getHeight()獲取的便是Bitmap的內存占用大小，單位為Byte，再除以1024，便可以轉換為BK單位。注意：上述從資源中獲取Bitmap對象的過程，并沒有直接使用decodeResource(Resources res, int id)含帶兩個參數(shù)的方法，是為了避免由于圖片存放在不同drawable或者mipmap文件夾下導致的內存占用不一致問題，對Android屏幕適配有所了解的朋友應該懂得這個，這里就不細說了，大家可以參考凱子哥的一篇文章 —— [關于Android中圖片大小、內存占用與drawable文件夾關系的研究與分析]。
 通過PS工具，修改縮略圖尺寸大小，然后通過上面這段代碼測試不同大小的圖片在Android手機中所占用的內存大小，同時查看是否可以調起微信客戶端。經過這樣的測試，最終發(fā)現(xiàn)，微信SDK和官方文檔中的32KB縮略圖上限大小指的是內存占用大小，而非圖片的硬盤占用大小。這樣，也就解決了前面我所遇到的問題。
 最后，還是得吐槽一下Android微信SDK的詬病，也是一些包括支付寶SDK在內其他第三方服務供應商的通用問題，別無他意，僅作發(fā)泄：
 •簽名唯一性
 做Android開發(fā)的都知道，開發(fā)過程中編譯打包并運行在手機或模擬器上的apk文件使用的是IDE提供的默認通用簽名，而正式上線發(fā)布的apk文件使用的是開發(fā)人員自定義的正式簽名文件。微信SDK在注冊應用時只能輸入一個簽名信息，導致必須在正式包中測試微信SDK相關功能，而正式包又無法做到跟蹤調試，非常不方便。當然你也可以這樣做，處于開發(fā)階段時，在微信開放平臺注冊測試包的簽名信息，上線時再修改成正式簽名文件信息；或者你也可以修改IDE的默認簽名文件。但是這些都不是很方便，如果微信開放平臺能夠像其他一些第三方服務供應商一樣，針對一個應用提供兩個或多個簽名信息的注冊，豈不快哉。
 •文檔不清晰
 很多大型的第三方服務供應商只管功能的提供，不管文檔的說明，甚至連Samples代碼都寫的亂七八糟的，導致我們開發(fā)人員在使用過程中連個完整的參考說明都沒有，出了問題也無從下手，白白浪費很多不必要的時間和精力。

文章有些啰嗦，主要是闡述了自己這次在開發(fā)微信分享時遇到問題、分析問題并解決問題的過程，希望給大家一些借鑒。

最新評論