由一条TransactionTooLargeException看binder传输过程中数据冗余的坑

去年我们公司开发了一款5.0的平板，当时应用组有程序员，通过getPackageInfo来获取应用的信息，
代码如下：

try {
    PackageInfo packageInfo = getPackageManager().getPackageInfo("com.tencent.mm",
            PackageManager.GET_ACTIVITIES);
    ActivityInfo[] activities = packageInfo.activities;
    for (ActivityInfo activityInfo: activities) {
        Log.d(TAG, "activityInfoname: " + activityInfo.name);
    }
} catch (PackageManager.NameNotFoundException e) {
    e.printStackTrace();
}

对于体量比较小的应用出现异常的概率比较小，但是在遇到体量较大的应用（比如QQ，微信）就很容易出现如下异常

 FATAL EXCEPTION: main
 Process: XXXXXXXXXXX, PID: 13306
 java.lang.RuntimeException: Package manager has died
     at android.app.ApplicationPackageManager.getPackageInfo(ApplicationPackageManager.java:112)
     at com.eebbk.virtualappdemo.TestActivity$3.onClick(TestActivity.java:90)
     at android.view.View.performClick(View.java:4830)
     at android.view.View$PerformClick.run(View.java:20043)
     at android.os.Handler.handleCallback(Handler.java:739)
     at android.os.Handler.dispatchMessage(Handler.java:95)
     at android.os.Looper.loop(Looper.java:135)
     at android.app.ActivityThread.main(ActivityThread.java:5314)
     at java.lang.reflect.Method.invoke(Native Method)
     at java.lang.reflect.Method.invoke(Method.java:372)
     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:969)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:764)
  Caused by: android.os.TransactionTooLargeException
     at android.os.BinderProxy.transactNative(Native Method)
     at android.os.BinderProxy.transact(Binder.java:496)
     at android.content.pm.IPackageManager$Stub$Proxy.getPackageInfo(IPackageManager.java:1821)
     at android.app.ApplicationPackageManager.getPackageInfo(ApplicationPackageManager.java:107)
     at XXXXXXXXXX(XXXXX.java:90) 
     at android.view.View.performClick(View.java:4830) 
     at android.view.View$PerformClick.run(View.java:20043) 
     at android.os.Handler.handleCallback(Handler.java:739) 
     at android.os.Handler.dispatchMessage(Handler.java:95) 
     at android.os.Looper.loop(Looper.java:135) 
     at android.app.ActivityThread.main(ActivityThread.java:5314) 
     at java.lang.reflect.Method.invoke(Native Method) 
     at java.lang.reflect.Method.invoke(Method.java:372) 
     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:969) 
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:764) 

在网上查找到有同样遇到这类问题的 有坑！Android新版QQ获取packageInfo引发异常崩溃

如这位博主所说的确可以通过修改flag避免异常，比如讲flag修改为GET_SIGNATURES。可以查看一下PMS的代码，此处返回值根据flag值会有所不同。但是由于我们应用需要获取到Activity里面的一些信息，所以还是绕不过这个坎。

那我们将demo放在新机器上运行的时候，发现是没有异常的，新机器是7.0版本。于是查找了下5.0到7.0之间的代码提交记录，最终找到如下提交 Avoid parceling redundant ApplicationInfo objects within PackageInfo 访问不了的话，可以查看下 CyanogenMod源码：Avoid parceling redundant ApplicationInfo objects within PackageInfo，通过这个提交我们发现实际上，7.0针对这个问题去除了ApplicationInfo的冗余，从而减小了binder中传输数据的大小。为了容易理解，还是上传一下类图吧，所以当我们在将Flag设置为GET_ACTIVITIES后会存在大量的数据冗余

增加打印查看下微信6.6.3获取的PackageInfo datasize

@Override
    public void writeToParcel(Parcel dest, int parcelableFlags) {
        dest.writeString(packageName);
        dest.writeStringArray(splitNames);
        dest.writeInt(versionCode);
        dest.writeString(versionName);
        dest.writeInt(baseRevisionCode);
        dest.writeIntArray(splitRevisionCodes);
        dest.writeString(sharedUserId);
        dest.writeInt(sharedUserLabel);
        if (applicationInfo != null) {
            dest.writeInt(1);
            applicationInfo.writeToParcel(dest, parcelableFlags);
        } else {
            dest.writeInt(0);
        }
        dest.writeLong(firstInstallTime);
        dest.writeLong(lastUpdateTime);
        dest.writeIntArray(gids);
        dest.writeTypedArray(activities, parcelableFlags | Parcelable.PARCELABLE_ELIDE_DUPLICATES);
        dest.writeTypedArray(receivers, parcelableFlags | Parcelable.PARCELABLE_ELIDE_DUPLICATES);
        dest.writeTypedArray(services, parcelableFlags | Parcelable.PARCELABLE_ELIDE_DUPLICATES);
        dest.writeTypedArray(providers, parcelableFlags | Parcelable.PARCELABLE_ELIDE_DUPLICATES);
        dest.writeTypedArray(instrumentation, parcelableFlags);
        dest.writeTypedArray(permissions, parcelableFlags);
        dest.writeStringArray(requestedPermissions);
        dest.writeIntArray(requestedPermissionsFlags);
        dest.writeTypedArray(signatures, parcelableFlags);
        dest.writeTypedArray(configPreferences, parcelableFlags);
        dest.writeTypedArray(reqFeatures, parcelableFlags);
        dest.writeTypedArray(featureGroups, parcelableFlags);
        dest.writeInt(installLocation);
        dest.writeInt(coreApp ? 1 : 0);
        dest.writeInt(requiredForAllUsers ? 1 : 0);
        dest.writeString(restrictedAccountType);
        dest.writeString(requiredAccountType);
        dest.writeString(overlayTarget);
        Log.d(TAG, "data size = " + dest.dataSize());
    }

修改前打印

system_process D/PackageInfo: data size = 1058620

修改后打印：

system_process D/PackageInfo: data size = 299344

修改前的Binder传输数据是1.0096M，更改后获取的Binder传输数据只有292K

简单记录下，方便以后回顾，此处提两点建议：

1.flag标记不要简单的传0或1，一定要根据需求传入对应值，避免接口变化导致异常

2.如果非必要不要使用getPackageInfo，getApplicationInfo完全可以满足需求