contextimplԴ??????

       深入探讨OpenHarmony代码学习中关于Ability子系统的源码解析，重点关注基于monthly_的码下代码架构与配置。

       在源码解析中，码下SystemAbility的码下配置sa_profile至关重要，它确保了以c++实现的码下SA在加载注册逻辑时能够完成SA的注册，反之，码下psd源码怎么设置未配置profile的码下System Ability将不会完成注册。可见abilitymgr等系统服务SA以特定方式运行，码下如.xml所示，码下ams的码下libabilityms.z.so在foundation进程中启动，并在启动后即向samgr组件注册SystemAbility，码下实现本地跨IPC访问。码下

       进一步，码下证券网源码分析AbilityManagerService作为SystemAbility的码下管理器，提供管理Ability生命周期的码下管理能力。以AbilityManagerService::StartAbility为起点，此方法支持4种Startability，其中IRemoteObject属于分布式软总线子系统的ipc组件，负责进程间通信。理解IPC与RPC机制，IPC与RPC在实现跨进程通信中扮演重要角色，IPC使用Binder驱动，适合设备内跨进程通信，而RPC采用软总线驱动，适用于跨设备跨进程通信。资金标枪指标源码客户端与服务器通过客户端-服务器模型进行通信，通过代理获取服务提供方的接口进行数据交互。三方应用通过FA提供的接口绑定服务提供方的Ability，获取代理，实现通信。

       在StartAbility中，callerToken由AbilityRuntime::AbilityContextImpl::StartAbility传入的AbilityContextImpl成员变量token_决定，通常指要启动的Ability。此调用链将在后续应用启动流程中总结，具体路径可参考官网介绍。

       继续深入代码分析，观察StartAbility中的c 膨胀腐蚀源码调用链，最终向BMS调用StartAbilityInner方法。根据ability类型的不同，启动方式也不同，已在代码段中进行了标注。在OpenHarmony代码学习中，PageAbility作为具备ArkUI实现的Ability，是最具直观性的用户可见并可交互的实例，通常由missionListManager启动。

ContentProvider 源码深入解析

       ContentProvider作为Android系统中核心组件之一，用于实现应用间数据共享。其工作流程始于ActivityManagerService启动新进程，此过程由startProcessLocked方法调用Process的u盘制作 源码start方法实现。ActivityThread的main方法作为整个流程的起点，创建ActivityThread实例后，通过attach方法进行一系列数据操作，开启主线程Looper循环。

       attach方法内部首先调用ActivityManagerService的attachApplication方法，经过attachApplicationLocked和ApplicationThread的bindApplication方法，实现进程间的调用。接着，通过handler发送消息给ActivityThread的handleBindApplication方法，从而创建ContextImpl与Instrumentation对象。

       整个启动过程中，installContentProviders方法起到关键作用，它遍历ProviderInfo列表，通过installProvider进行ContentProvider启动操作，并将启动的ContentProvider发布到AMS中。借助ClassLoader加载ContentProvider，完成对象创建。最终调用localProvider.attachInfo(c, info);方法，实现ContentProvider的onCreate操作，至此，ContentProvider完成启动过程，为其他应用提供访问途径。

       随着ContentProvider的启动，ActivityManager能够访问并利用其提供的接口，实现应用间的数据共享。这一机制简化了跨应用数据访问的复杂性，为Android系统的整体架构提供了高效的数据流通渠道。

Dubbo源码：跟着Demo学习基本使用

       Dubbo 是一款由阿里开源的高性能轻量级RPC框架，因其在各大企业如阿里、京东、小米、携程等的广泛应用而备受瞩目。本文将通过一个基础Demo，带你了解Dubbo的基本使用步骤。

       首先，你需要设置一个ZooKeeper服务器作为服务注册中心。ZooKeeper是Dubbo生产环境中的常见选择。下载并解压zookeeper-3.4..tar.gz包，然后修改conf/zoo.cfg配置，启动ZooKeeper服务。

       接下来，定义业务接口，即Dubbo Provider和Consumer之间的约定，如dubbo-demo-interface模块中的DemoService接口。它包含sayHello()和sayHelloAsync()方法。

       在dubbo-demo-xml模块中，提供了基于Spring XML的Provider和Consumer实现。在Provider端的dubbo-provider.xml中，配置DemoServiceImpl为Spring Bean，并暴露到ZooKeeper。在Consumer端的dubbo-consumer.xml中，配置ZooKeeper地址，并使用dubbo:reference引入DemoService，以便远程调用其提供的服务。

       启动Consumer端的Application，通过ClassPathXmlApplicationContext加载配置文件，即可实现服务的调用。如果你有任何问题或需求，欢迎留言互动，共同探讨。

       本文摘自公众号“勾勾的Java宇宙”，关注的朋友们可以分享你的学习需求和建议。

如何解决android 5.0中出现的警告service intent must be expl

       æœ‰äº›æ—¶å€™æˆ‘们使用Service的时需要采用隐私启动的方式，但是Android 5.0一出来后，其中有个特性就是Service Intent must be explitict，也就是说从Lollipop开始，service服务必须采用显示方式启动。

       è€Œandroid源码是这样写的（源码位置：sdk/sources/android-/android/app/ContextImpl.java）：

       private void validateServiceIntent(Intent service) {

        if (service.getComponent() == null && service.getPackage() == null) {

        if (getApplicationInfo().targetSdkVersion >= Build.VERSION_CODES.LOLLIPOP) {

        IllegalArgumentException ex = new IllegalArgumentException(

        "Service Intent must be explicit: " + service);

        throw ex;

        } else {

        Log.w(TAG, "Implicit intents with startService are not safe: " + service

        + " " + Debug.getCallers(2, 3));

        }

        }

        }

       å¤åˆ¶ä»£ç 

       æ—¢ç„¶ï¼Œæºç é‡Œæ˜¯è¿™æ ·å†™çš„，那么这里有两种解决方法：

       1、设置Action和packageName：

       å‚考代码如下：

       Intent mIntent = new Intent();

       mIntent.setAction("XXX.XXX.XXX");//你定义的service的action

       mIntent.setPackage(getPackageName());//这里你需要设置你应用的包名

       context.startService(mIntent);

       å¤åˆ¶ä»£ç 

       æ­¤æ–¹å¼æ˜¯google官方推荐使用的解决方法。

       2、将隐式启动转换为显示启动：

       public static Intent getExplicitIntent(Context context, Intent implicitIntent) {

        // Retrieve all services that can match the given intent

        PackageManager pm = context.getPackageManager();

        List<ResolveInfo> resolveInfo = pm.queryIntentServices(implicitIntent, 0);

        // Make sure only one match was found

        if (resolveInfo == null || resolveInfo.size() != 1) {

        return null;

        }

        // Get component info and create ComponentName

        ResolveInfo serviceInfo = resolveInfo.get(0);

        String packageName = serviceInfo.serviceInfo.packageName;

        String className = serviceInfo.serviceInfo.name;

        ComponentName component = new ComponentName(packageName, className);

        // Create a new intent. Use the old one for extras and such reuse

        Intent explicitIntent = new Intent(implicitIntent);

        // Set the component to be explicit

        explicitIntent.setComponent(component);

        return explicitIntent;

        }

       å¤åˆ¶ä»£ç 

       è°ƒç”¨æ–¹å¼å¦‚下：

       Intent mIntent = new Intent();

       mIntent.setAction("XXX.XXX.XXX");

       Intent eintent = new Intent(getExplicitIntent(mContext,mIntent));

       context.startService(eintent);

Android UI线程

        先必须了解下面2个问题

        1.顾名思义 UI线程 就是刷新UI 所在线程

        2.UI是单线程刷新

        1.对Activity 来说 UI线程就是其主线程

        2.对View来说 UI线程就是创建ViewRootImpl所在的线程

        可以通过 WindowManager 内部会创建ViewRootImpl对象

        好了，进入主题。我们来慢慢揭开面纱。

        我们可以分别从几个方面切入

        我们可能都有使用过 runOnUiThread 现在来看看的源码实现。

        可以从上面的源码 看到

        不是UI线程 就用Handler切到Handler所在的线程中，如果是UI线程直接就调用run方法。

        Activity的创建：

        1.Activity创建：mInstrumentation.newActivity

        2.创建Context ：ContextImpl appContextcreateBaseContextForActivity(r)

        我们经常用这个方法干的事情就是，要么在onCreate中获取View宽高的值。要么就是在子线程中做一些耗时操作 ，然后post切到对应View所在的线程 来绘制UI操作。那么这个对应的线程就是UI线程了。

        那么这个UI线程就一定是主线程吗？

        接来继续来看。它的源码View:post

        mAttachInfo 在dispatchAttachedToWindow 中被赋值 ，也就是在ViewRootImpl创建的时候，所以是创建ViewRootImpl所在的线程。

        attachInfo 上面时候为null 呢？在ViewRootImpl 还没来得及创建的时候，ViewRootImpl 创建是在 “onResume" 之后。所以在 Activity 的 onCreate 去View.post 那么AttachInfo 是为null 。

        当 AttachInfo == null 那么会调用 getRunQueue().post(action) 。

        最终这个Runnable 被 缓存到 HandlerActionQueue 中。

        直到ViewRootImpl 的 performTraversals 中 调用dispatchAttachedToWindow(mAttachInfo, 0);， 那么才会去处理 RunQueue() 中的Runnable。

        来张图 便于理解这个流程

        我们有时候去子线程操作UI的时候(如：requestLayout)，会很经常见到下面的 报错日志：

Only the original thread that created a view hierarchy can touch its views

        为什么会报这个错误呢？

        翻译一下：只有创建视图层次结构的原始线程才能接触到它的视图。

也就是操作UI的线程要和ViewRootImpl创建的线程是同一个线程才行，并不是只有主线程才能更新UI啊。

        ViewRootImpl创建的线程？那么 ViewRootImpl 在哪里被创建的呢？

        从上图可以看到ViewRootImpl创建最开始是从 ActivityThread 的HandleResumeActivity中开始 一直 ViewRootImpl 创建，也就是说ViewRootImpl 对应的UI线程和 ActivityThread 在同一个线程 也就是主线程。

        好了 通过上面的讲解，上面的问题相信你可以自己回答啦~