这几天锤子科技新闻不断，成都市政府投资锤子科技6个亿，这也许是锤子科技要在成都建研发中心的一个重要缘由。而锤子科技没有落户在软件研发公司和人员聚集的高新区天府软件园，让我觉得有些“可惜”，可能老罗对锤子科技的定位超出我的想象。

政府的投资是否会有利于锤子科技的发展不得而知，不过段子倒是开始满天飞了，来一段吧（可能需要熟悉四川话的才好理解笑点）：

秘书问市长：“市长，我们还有6亿的市政基金，要投资什么吗？”
市长正忙着呢，回：“投个锤子！”
“哦”，秘书就拨通了老罗的电话。

回到正题，前两周我参加了两次锤子科技的面试，在市场上锤子手机比较推崇“工匠精神”，在面试上他们也比较精益求精，面试官是我遇到的能感受到技术和问问题都很不错的人。

有些问题上被问得也有点“尴尬”，细细思考也是自己没有做好“工匠”的事情，很多问题都没有认真深入，虽然我也一直在强调，不过我也只深入了一部分。

今天就来和大家谈谈，我在面试锤子科技时和面试官讨论的一道和Binder线程池相关的问题。

面试题：多个进程同时调用一个ContentProvider的query获取数据，ContentPrvoider是如何反应的呢？

我们知道像Activity这样的组件，它的生命周期回调函数是在UI线程中运行的，ContentProvider的onCreate()也是在UI线程运行，回答这个面试题前，我们要搞清楚ContentProvider的query()，insert()，delete()，update()这几个方法是在UI线程中运行的吗？

如果是，那么就等于说在这里做长时间的操作的话，就会有ANR的问题。如果不是，那是在一个工作线程还是多个线程中呢，即ContentProvider是否支持并发操作？

ContentResolver与ContentProvider类隐藏了实现细节，但是ContentProvider所提供的query()，insert()，delete()，update()都是在ContentProvider进程的线程池中被调用执行的，而不是进程的主线程中。因为那些方法可能同时被多个线程所调用，所以他们都应该是线程安全的。

ContentProvider实现了进程间通信也是基于Binder机制的，所以会回到Binder的线程处理问题。并不是每个ContentProvider都会有一个线程池，而一个进程会共有一个线程池，其实就是Binder线程池。

我之前看到过说明是，每个ContentProvider会有线程池在管理每个客户端ContentResolver的请求，每个线程池有16个线程，不过后来也一直没有在官网上找到资料印证。

实验

当我聊到这个16的数量问题时，面试官有一些疑问。需要我对这个数量的由来做一个说明。

如何证明这个线程池确实是16个线程呢？

有两种方法：

1. 直接查看ContentProvider或者Binder的相关源码证实；
2. 直接写一个应用Demo来证实。

我们来试试第2种方式，现在写一个简单的测试Demo，一个ContentProvider（里面操作数据的地方，我们让它sleep 10秒钟），一个调用者Activity同时发送几十个请求。在ContentProvider的方法中打出Log看运行在哪个线程，以及这几十个请求的执行情况。

ContentProvider代码：

public class MyContentProvider extends ContentProvider {

    private final static String TAG = "MyContentProvider";

    @Override
    public boolean onCreate() {
        Log.i(TAG, "onCreate() threadName= " + Thread.currentThread().getName()
                + " threadId=" + Thread.currentThread().getId());
        return false;
    }

    @Override
    public Uri insert(Uri uri, ContentValues values) {
        Log.i(TAG, "insert() threadName= " + Thread.currentThread().getName()
                + " threadId=" + Thread.currentThread().getId());

        try {
            Thread.sleep(10000); // 模拟耗时工作
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return null;
    }
......    

调用方Activity的代码：

public class MainActivity extends AppCompatActivity {

    private final static String TAG = "MainActivity";
    public static final Uri CONTENT_URI = Uri.parse("content://net.goeasyway.myprovider");

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        for (int i = 0; i < 50; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    getContentResolver().insert(CONTENT_URI, new ContentValues());
                }
            }).start();
        }

    }
}

测试结果分两种情况：
1、同一进程
ContentProvider和调用getContentResolver()在同一进程中的情况，即AndroidManifest.xml这样配置provider标签的：

    <provider
        android:authorities="net.goeasyway.myprovider"
        android:name=".MyContentProvider" />

测试结果发现，ContentProvider.insert()会生成一个新的线程去处理请求，所以getContentResolver().insert()请求了50次，就会ContentProvider的进程中产生50个新的线程去处理insert()操作。

I/MyContentProvider: insert() threadName= Thread-1 threadId=1304
I/MyContentProvider: insert() threadName= Thread-3 threadId=1306
I/MyContentProvider: insert() threadName= Thread-2 threadId=1305
I/MyContentProvider: insert() threadName= Thread-4 threadId=1307
I/MyContentProvider: insert() threadName= Thread-5 threadId=1308
I/MyContentProvider: insert() threadName= Thread-6 threadId=1309
I/MyContentProvider: insert() threadName= Thread-7 threadId=1310
I/MyContentProvider: insert() threadName= Thread-8 threadId=1311
I/MyContentProvider: insert() threadName= Thread-9 threadId=1312
......
I/MyContentProvider: insert() threadName= Thread-47 threadId=1350
I/MyContentProvider: insert() threadName= Thread-49 threadId=1352
I/MyContentProvider: insert() threadName= Thread-48 threadId=1351
I/MyContentProvider: insert() threadName= Thread-50 threadId=1353

2、不同进程
ContentProvider和调用getContentResolver()不在同一进程中的情况，配置provider标签时给它调置一个远程进程：

   <provider
        android:authorities="net.goeasyway.myprovider"
        android:name=".MyContentProvider"
        android:process=":remote"/>

这样配置MyContentProvider将运行在“包名:remote”的进程中，和MainActivity所在进程“包名”之间进程间通信。测试的结果发现MyContentProvider中的insert()方法运行在Binder线程池的线程中。

I/MyContentProvider: insert() threadName= Binder:10436_1 threadId=1285
I/MyContentProvider: insert() threadName= Binder:10436_2 threadId=1286
I/MyContentProvider: insert() threadName= Binder:10436_3 threadId=1288
I/MyContentProvider: insert() threadName= Binder:10436_4 threadId=1289
I/MyContentProvider: insert() threadName= Binder:10436_5 threadId=1290
I/MyContentProvider: insert() threadName= Binder:10436_6 threadId=1291
I/MyContentProvider: insert() threadName= Binder:10436_7 threadId=1292
I/MyContentProvider: insert() threadName= Binder:10436_8 threadId=1293
I/MyContentProvider: insert() threadName= Binder:10436_9 threadId=1294
I/MyContentProvider: insert() threadName= Binder:10436_A threadId=1295
I/MyContentProvider: insert() threadName= Binder:10436_B threadId=1296
I/MyContentProvider: insert() threadName= Binder:10436_C threadId=1297
I/MyContentProvider: insert() threadName= Binder:10436_D threadId=1298
I/MyContentProvider: insert() threadName= Binder:10436_E threadId=1299
I/MyContentProvider: insert() threadName= Binder:10436_F threadId=1300
I/MyContentProvider: insert() threadName= Binder:10436_10 threadId=1301

...... 

每次MyContentProvider的insert()只能在16个Binder线程中执行，只有等这16个线程有空闲之后才后处理剩下的getContentResolver().insert()的请求。

笔者经验分享：虽然去研究ContentProvider的启动和调用流程代码肯定也能得出上面的结论，但还是会有一些难度。所以，工作中有时候想太多还不如直接动手试一下，结论一下子就出来了。

和面试官的“争论”

这个结论是不是有问题呢？

当我聊到这个线程池中有16个线程可供使用时，面试官对这个结论提出了一些看法。一个进程创建后为了和在系统进程中的AMS（ActivityManangerService）通信，一个APK进程本身就是在Binder线程池中占用2个线程来维持Binder的通信。

那么，上面提到的第二种不同进程的案例中，ContentProvider能同时使用的线程数量应该是14个才对啊。怎么我们测试的结果会是16呢？

这一点我当时和面试官是有分歧的。因为我记得做过实验结果就是16个线程，但如过一个进程只维护一个Binder线程池的话，确实应该是14个线程才对。

在这点上，我确实没有理解清楚Binder的线程池，所以我知道了实际效果可以同时运行16个线程（假设自己的实验没出错），但却无法解释面试官提的“为什么不是14个的问题”。

我面试回来后，看一些说明和代码片段，一个初步的判断是，面试官提到的和AMS通信用到的线程并不会算在这个线程池中。
欢迎提出异议或者你认为正确的解释。

高级中的高级

可能很多读者会觉得面试官这样问有点吹毛求疵了，这不是为难人吗？

锤子科技把高级工程师还进行了细分，即高级中再来一个“初级、中级、高级”这类的级别，很多公司应该也有类似定级别的（比如有喜欢P的、有喜欢T的）。高级中的高级和高级中的初级，你觉得会差在哪里呢？

所以，作为面试者你应该仔细思考一下，很多时候面试官过问的细节往往就是差距所在。

“标准答案”

面试题：多个进程同时调用一个ContentProvider的query获取数据，ContentPrvoider是如何反应的呢？
标准答案：一个content provider可以接受来自另外一个进程的数据请求。尽管ContentResolver与ContentProvider类隐藏了实现细节，但是ContentProvider所提供的query()，insert()，delete()，update()都是在ContentProvider进程的线程池中被调用执行的，而不是进程的主线程中。这个线程池是有Binder创建和维护的，其实使用的就是每个应用进程中的Binder线程池。

面试题：你觉得Android设计ContentProvider的目的是什么呢？
标准答案：1. 隐藏数据的实现方式，对外提供统一的数据访问接口；
2.更好的数据访问权限管理。ContentProvider可以对开发的数据进行权限设置，不同的URI可以对应不同的权限，只有符合权限要求的组件才能访问到ContentProvider的具体操作。
3.ContentProvider封装了跨进程共享的逻辑，我们只需要Uri即可访问数据。由系统来管理ContentProvider的创建、生命周期及访问的线程分配，简化我们在应用间共享数据（进程间通信）的方式。我们只管通过ContentResolver访问ContentProvider所提示的数据接口，而不需要担心它所在进程是启动还是未启动。

面试题：运行在主线程的ContentProvider为什么不会影响主线程的UI操作?
标准答案：
ContentProvider的onCreate()是运行在UI线程的，而query()，insert()，delete()，update()是运行在线程池中的工作线程的，所以调用这向个方法并不会阻塞ContentProvider所在进程的主线程，但可能会阻塞调用者所在的进程的UI线程！

所以，调用ContentProvider的操作仍然要放在子线程中去做。虽然直接的CRUD的操作是在工作线程的，但系统会让你的调用线程等待这个异步的操作完成，你才可以继续线程之前的工作。

相关面试题：
Android面试一天一题（15 Day：ContentProvider）
Android面试一天一题（Day 44：实战美团--Java内存模型）