你的Android应用完全不需要那么多的权限

Android系统的权限从用户的角度来看有时候的确有点让人摸不着头脑。有时候可能你只需要做一些简单的事情(对联系人的信息进行编辑),却申请了远超你应用所需的权限(比如访问所有联系人信息的权限)。

这很难不让用户对你保存戒备。如果你的应用还是闭源的那用户也没办法验证是否你的应用正在把他的联系人信息上传到应用服务器上面去。即使你向用户解释你为什么申请这个权限,他们最后也可能不会相信你。所以我在过去开发Android应用的时候避免去用一些奇技淫巧,因为这会额外去申请权限,用户也会对你不信任。

经过一段时间实践后,我有这样一个体会:你在完成某些操作的时候并不一定需要申请权限的

比如Android系统中有这样一个权限: android.permission.CALL_PHONE. 你需要这个权限来让你从你的应用中调用拨号器,对吗?下面的代码就是你如果拨打电话的,对吧?

Intent intent = new Intent(Intent.ACTION_CALL);
intent.setData(Uri.parse("1234567890"))
startActivity(intent);

错!这个权限可以让你的手机在没有用户操作的情况下打电话!也就是说如果我的应用用了这个权限,我可以在你不知情的情况下每天凌晨三点去拨打骚扰电话。

其实正确的做法是这样的——使用 ACTION_VIEW 或者 ACTION_DIAL:

Intent intent = new Intent(Intent.ACTION_DIAL);
intent.setData(Uri.parse("1234567890"))
startActivity(intent);

这个方案的动人之处在于你的应用就不用申请权限啦。 为什么不需要权限呢?因为你使用的这个 Intent 会启动拨号器,并将你设置好的号码预先拨号。比起之前的方案,现在还需要用户点击“拨号”来打电话,没有用户的参与,这个电话就打不出了。说实话,这让我感觉很好,现在很多应用申请的权限让人有点不知所措。


另外一个例子:我为我的妻子写了一个叫做 Quick Map 应用,这个应用主要是为了解决她对现有的导航应用的吐槽。她只想要一个联系人列表和一条导航到这些联系人所在地的路径。

看到这里你可能觉得我需要申请访问所有联系人信息的申请来完成这个应用:哈哈哈,你又错了!如果你看了我的源码,你就知道其实我用了 ACTION_PICK 这个Intent 启动相关应用来获取联系人地址的:

Intent intent = new Intent(Intent.ACTION_PICK);
intent.setType(StructuredPostal.CONTENT_TYPE);
startActivityForResult(intent, 1);

这意味着我的应用不但不需要申请权限,而且还不要额外的UI。这让应用的用户体验也提升了不少。


在我看来,Android系统最酷的部分之一就是 它的 Intent 系统。因为Intent 意味着我不需要任何东西都要自己来实现。每个应用都会在Android注册它所擅长处理的数据领域,比如电话号码,短信或者联系人信息。如果什么事情都要一个应用来解决,那么这个应用会变得十分臃肿。

Android系统另外一个优点就是我可以利用其它应用所申请的权限,这样我的应用就不需要再次申请了。Android系统中的以上两点可以让你的应用变得更加简单。拨号器需要权限来拨打电话,但是我只需要一个拨打电话的intent就行了,不需要权限。因为用户信任Android自带的拨号器,但不信任我的应用,这很好啊。

我写这篇博客的意义在于在你申请权限之前,你应该至少好好读读关于Intent的官方文档,看看是否可以通过其他应用来完成你的操作。如果你想更深入的了解,你可以研究一下这篇关于权限的官方文档,里面介绍更多更精细的权限。

总之,使用更少的权限不但可以让你获取更多的用户信任,对用户来说,也让他们获得了很好的用户体验。

source:Dan Lew  I don’t need your permission!

为什么不能往Android的Application对象里存储数据

在一个App里面总有一些数据需要在多个地方用到。这些数据可能是一个 session token,一次费时计算的结果等。通常为了避免activity之间传递对象的开销 ,这些数据一般都会保存到持久化存储里面

有人建议将这些数据保存到 Application 对象里面,这样这些数据对所有应用内的activities可用。这种方法简单,优雅而且……完全扯淡。

假设把你的数据都保存到Application对象里面去了,那么你的应用最后会以一个NullPointerException 异常crash掉。

一个简单的测试案例

代码

Application 对象:

// access modifiers omitted for brevity
class MyApplication extends Application {
 
    String name;
 
    String getName() {
        return name;
    }
 
    void setName(String name) {
        this.name = name;
    }
}

第一个activity, 我们往application对象里面存储了用户姓名:

// access modifiers omitted for brevity
class WhatIsYourNameActivity extends Activity {
 
    void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.writing);
 
        // Just assume that in the real app we would really ask it!
        MyApplication app = (MyApplication) getApplication();
        app.setName("Developer Phil");
        startActivity(new Intent(this, GreetLoudlyActivity.class));
 
    }
 
}

 

第二个activity,我们调用第一个activity设置并存在application里面的用户姓名:

// access modifiers omitted for brevity
class GreetLoudlyActivity extends Activity {
 
    TextView textview;
 
    void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
 
        setContentView(R.layout.reading);
        textview = (TextView) findViewById(R.id.message);
    }
 
    void onResume() {
        super.onResume();
 
        MyApplication app = (MyApplication) getApplication();
        textview.setText("HELLO " + app.getName().toUpperCase());
    }
}

 

测试场景

  1. 用户启动app。
  2. 在 WhatIsYourNameActivity里面,要求用户输入姓名,并存储到 MyApplication。
  3. 在 GreetLoudlyActivity里面,你从MyApplication 对象中获得用户姓名,并且显示。
  4. 用户按home键离开这个app。
  5. 几个小时后,Android系统为了回收内存kill掉了这个app。到目前为止,一切尚好。接下来就是crash的部分了…
  6. 用户重新打开这个App。
  7. Android系统创建一个新的 MyApplication 实例并恢复 GreetLoudlyActivity
  8. GreetLoudlyActivity 从新的 MyApplication 实例中获取用户姓名,可得到的为空,最后导致NullPointerException。

为什么会Crash?

在上面这个例子中,app会crash得原因是这个 Application 对象是全新的,所以这个name 变量里面的值为 null,当调用String#toUpperCase() 方法时就导致了NullPointerException。

整个问题的核心在于:application 对象不会一直呆着内存里面,它会被kill掉。与大家普遍的看法不同之处在于,实际上app不会重新开始启动。Android系统会创建一个新的Application 对象,然后启动上次用户离开时的activity以造成这个app从来没有被kill掉得假象。

你以为你的application可以保存数据,却没想到你的用户在没有打开activity A 之前就就直接打开了 activity B ,于是你就收到了一个 crash 的 surprise。

有哪些替代方法呢?

这里没啥神奇的解决方法,你可以试试下面几种方法:

  • 直接将数据通过intent传递给 Activity 。
  • 使用官方推荐的几种方式将数据持久化到磁盘上。
  • 在使用数据的时候总是要对变量的值进行非空检查。

如果模拟App被Kill掉

更新: Daniel Lew指出,kill app更简单的方式就是使用DDMS里面“停止进程” 。你在调试你的应用的时候可以使用这招。

为了测试这个,你必须使用一个Android模拟器或者一台root过的Android手机。

  1. 使用home按钮退出app。
  2. 在终端里:
    # find the process id
    adb shell ps
    # then find the line with the package name of your app
     
    # Mac/Unix: save some time by using grep:
    adb shell ps | grep your.app.package
     
    # The result should look like:
    # USER      PID   PPID  VSIZE  RSS     WCHAN    PC         NAME
    # u0_a198   21997 160   827940 22064 ffffffff 00000000 S your.app.package
     
    # Kill the app by PID
    adb shell kill -9 21997
     
    # the app is now killed

     

  3. 长按home按钮回到之前的app。
    你现在是出于一个新的application实例中了。

总结

不要在application对象里面储存数据,这容易出错,导致你的app crash。
要么将你后面要用的数据保存到磁盘上面或者保存到intent得extra里面直接传递给activity 。

这些结论不但对application对象有用,对你app里面的单例对象(singleton)或者公共静态变量(public static)同样适用。

本文翻译自:http://www.developerphil.com/dont-store-data-in-the-application-object/